IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Standard Init for PIC 9 defined fields


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Andi1982

New User


Joined: 27 Mar 2008
Posts: 42
Location: Karlsruhe / Germany

PostPosted: Mon Jun 16, 2008 7:16 pm
Reply with quote

Hi,

i have a modul compiled a long time ago. There are several numeric fields, defined like that:

Code:
134400 01 ANZAHL         PIC      99       .   


I use this field to count something. (I know that comp-3 would be better, but that is not the problem here).

Code:
199200     ADD     1    TO   ANZAHL 


I do not explicit initialize this filed before i use the add. This worked fine for a few years.

But now i had to change something in this modul and compiled it. After that i got an abend 0C7 during execution. In the XPediter I saw that the field ANZAHL is not initialized with X'F0F0' but X'0000'. So the 0C7 abend by adding 1 is comprehensible.

We think that something changed on the compiler options or the compiler. But we can't find the option to set the standard initialize of PIC 99 fields to X'F0F0'.

Does anyone know a reason why this is wrong know?

Best Regards
Andi
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Jun 16, 2008 8:29 pm
Reply with quote

One possibility is Language Environment. CEEDOPT and CEECOPT control the batch and CICS, respectively, run-time options. Specifically, STORAGE=((00,00,00,0K),OVR) would initialize storage to LOW-VALUES and could be the source of the difference.

If so, your problem is that CEEDOPT and CEECOPT are set at installation time and should the system programmer specify NONOVR, they cannot be overridden. If this is a batch program, try overriding with STORAGE=('0','0','0') (or STORAGE=(F0,F0,F0) in your PARM= and see if the override works.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Jun 16, 2008 9:08 pm
Reply with quote

Hello,

Quote:
Does anyone know a reason why this is wrong know?
You were "lucky" before. . . It would have been better had the code abended on the first test, long ago. . .

It is a good idea to specifically assign an initial value to all working-storage fields. To do otherwise opens the door to the old IBM caution "The results may be unpredictable".
Back to top
View user's profile Send private message
Andi1982

New User


Joined: 27 Mar 2008
Posts: 42
Location: Karlsruhe / Germany

PostPosted: Mon Jul 07, 2008 5:05 pm
Reply with quote

We have found the mistake...

With the new compiler, some standard compiler options changed. Among others things the NUMPROC option changed from NOPFD to MIG.

After correcting that option, it works fine again!

Thanks for your answers!

Regards Andi
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Jul 07, 2008 5:16 pm
Reply with quote

whew! Thought for a second that they would have to professionally correct the problem. Thank heavens IBM provides parms to make up for slopply coding.
Back to top
View user's profile Send private message
Antonio Barata
Warnings : 1

New User


Joined: 04 Apr 2007
Posts: 37
Location: Lisbon, Portugal

PostPosted: Mon Jul 07, 2008 6:49 pm
Reply with quote

Andi1982 wrote:
We have found the mistake...
After correcting that option, it works fine again!
Regards Andi

I agree with Dick
It is always a good idea to assign an initial value to working-storage variables or alternatively use the INITIALIZE statement.
Some time later if there is another change and you or someone else doesn't remember what happened, you can have the same problem again.

Regards
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Jul 07, 2008 8:59 pm
Reply with quote

Hello,

Quote:
We have found the mistake...
After correcting that option, it works fine again!
Nonsense. The mistake is the numeric field that was not initialized properly. It is still a mistake.

Places with good programming standards would not allow such code to be promoted. . .
Back to top
View user's profile Send private message
Andi1982

New User


Joined: 27 Mar 2008
Posts: 42
Location: Karlsruhe / Germany

PostPosted: Tue Jul 08, 2008 10:55 am
Reply with quote

Yes ok, the real mistake is the uninitialized num-field, you are right. icon_smile.gif

But i can not search such fields in hundret of moduls. It was much easier to change this compiler option. We will correct the moduls step by step. Some run since 1988.

Mybe we will change in Test-Region this option back, so every developer has to modify such bad moduls before placing in Prod-Region.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Concatenate 2 fields (usage national)... COBOL Programming 2
No new posts how to get list of all VSAM/non-VSAM ... JCL & VSAM 13
No new posts Cobol COMP-2 fields getting scrambled... Java & MQSeries 6
No new posts Converting unpacked fields to pack us... SYNCSORT 4
No new posts using based or defined variables PL/I & Assembler 2
Search our Forums:

Back to Top