View previous topic :: View next topic
|
Author |
Message |
Prakash Ramnani
New User
Joined: 02 Jun 2007 Posts: 5 Location: Rhode Island
|
|
|
|
Hi..
I have a CICS COBOL program which is calling other CICS COBOL program. I have initialized my entire copybook using INITIALIZE keyword on the 01 level. When the control goes to the other program, the other program has a group level move. In some of the fields proper data is getting moved while in some there is junk. These junk data values are moved in PIC S9(3) Comp 3 fields resulting in an abend. The junk values are ?????. When I check these values using HEX on option, I see the value is 40 means spaces. I need all the variables to be zeroes. If I INITIALIZE again, i.e if I re-initialized the entire copybook then the fields which have proper data will be initialized. Does anyone have any idea ? |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
Are the fields that have junk in them supposed to still be zeros from the initialize? If so, just before the call move zero to them and see if you still abend.
If they are supposed to have valid numeric data in them (which you moved to them), the problem need other tactics.
Initialize has some restrictions when it comes to redefines, could this be the problem? Sometime initialize followed by a few moves of spaces and zeros can take care of a complicated data description. |
|
Back to top |
|
|
Prakash Ramnani
New User
Joined: 02 Jun 2007 Posts: 5 Location: Rhode Island
|
|
|
|
Yes. I had Move zeroes to them after the call and it went through without abend. But only the trick is if there is some data coming from that group level moved and later I have moved zeroes to it, then there will be a problem. INITIALIZE has drawback that it does not initialize the fillers. I have junk in couple of filler's too.. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
If the fields are "really" filler, why does the content matter?
If you create a "fresh" level-01 that has all of the correct initial values (rather than using the INITIALIZE statement) and make sure that every byte has an acceptable value (even the fillers), you could move this new set of fields to the the data-name you now INITIALIZE. If you did this at the "start", and then later moved non-zero values to some fields, all would be preserved. This "fresh" field would only ever be moved from, replacing the INITIALIZE statememt(s) where ever they occur.
This may use a bit of extra working-storage space, but will save on performance at run-time. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
Like Dick says, sometimes initialize is not the answer.
If you realize that initialize genereate a series of moves of spaces and zeros, then just moving spaces and zeros makes the procedure division longer but is the same amount of machine code. As far as more procedure division, a "perform initialize-my-data-area" is a one liner too, and the actual paragraph can be buried way down at the bottom of the program. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Actually, if a second level-01 is defined with all of the "starter" values, a single move may be all that is needed at run-time. It would work like an INITIALIZE, but would have initial values that were more flexible than what INITIALIZE provides. It would also be a single move, rather than the series generated by an INITIALIZE to be executed at run-time. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
dick scherrer wrote: |
Actually, if a second level-01 is defined with all of the "starter" values, a single move may be all that is needed at run-time. |
Good choice, been there, done it, works great. |
|
Back to top |
|
|
Prakash Ramnani
New User
Joined: 02 Jun 2007 Posts: 5 Location: Rhode Island
|
|
|
|
Thanks all...
Can I check for ????? values in some of the variables after the call from a COBOL program and replace it with ZEROES. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
I don't really understand your reference to "????? values" but if you want to check for "valid" values is numeric fields, yes, you can check.
<teach on>
the whole point of an interactive system is to validate the input at some point and, after that trust the data. If the called program is getting "garbage", the calling program is falling down on its responsibility.
</teach off>
Oh, as an aside, make (VERY) sure that both programs are working from the same description of the data area. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Are they "really" question marks? If you "sent" valid values, called your code, and came back to your calling module, what generated the ?????(s)?
Some presentation tools show ???? for "invalid" values - might this be your case?
How are these fields that return with ???? defined? If you define a numeric field and modify it in some other bit of code, i'm not sure how the ????s get into the field. If you have a numeric field, i don't believe you will be able to test foe ????.
If you post some detail, we can take a look/ offer suggestions. |
|
Back to top |
|
|
|