Girish, you're not quite correct in saying that things worked in COBOL 2.2. It has always been invalid to move HIGH-VALUES or LOW-VALUES to a USAGE DISPLAY or USAGE COMP-3/PACKED-DECIMAL data item, and IBM has never guaranteed any particular behaviour when invalid data was used in a program (until clients started having invalid data problems in COBOL 5/6 and we had to add options to provide the same behaviour with invalid data as clients observed in COBOL 4.2/earlier).
What's really going on is that:
- While the COBOL language doesn't specify what the behaviour should be for invalid data, the instructions chosen in COBOL 4.2/earlier DO imply certain behaviours. That's because the hardware instructions, unlike the COBOL language, must specify what happens for any and all inputs, valid or otherwise.
- Clients observe that "When I use this kind of invalid data in this way, I get X behaviour" with their old compiler. This doesn't mean that things "worked"; it means that they behaved in a certain unintentional way, because of the instructions the older compiler chose
- COBOL 5.1 introduced a new code generator and optimizer. This is good for performance, and the new code generator takes advantage of new hardware instructions
- This means that COBOL 5/6 may generate different instructions for a COBOL statement than COBOL 4.2 did. (And because each new hardware release adds further new instructions for the compiler to use, you may get different instructions from different versions of 5 and 6. And, this also varies with OPT level in some cases: different optimizations may lead to different instruction choices).
- We've made sure that the new instruction choices in COBOL 5 and 6 provide correct behaviour for valid data, but in some cases, such as the one you've observed, a new instruction choice may have different behaviour for invalid data than an old compiler.
While we do recommend correcting invalid data, especially in cases like this where it's just your COBOL source that needs to change (as opposed to data residing elsewhere or coming from non-COBOL sources), there are ways to detect problems or get compatible behaviour with COBOL 4.2 (specifically for cases we've identified, not a full COBOL 4.2 compatibility mode in general). I say COBOL 4.2 because that's generally what we've experienced in helping clients migrate from older versions, but you'd generally have the same behaviour in COBOL 2.2 as you do in 4.2.
I also highly recommend you pause your migration and watch a recorded version of the migration webinar I've presented many times in the past. You can find a recording here. We strongly recommend having a plan when migrating from COBOL 4.2 or earlier up to COBOL 6; this webinar will help you with that, as would the COBOL Migration Guide. Once you've done so, feel free to contact me directly (mike.chase@ca.ibm.com) with any migration questions you might still have.
Just to avoid confusion, it's probably best not to say that 9999999 is HIGH-VALUES (as HIGH-VALUES is, specifically, all bits set to 1, as many bytes of x'FF' as is needed for the length of the data item(s) in question), but Gary's suggestion of using 9999999 is one possibility.
------------------------------
Mike Chase
Enterprise COBOL Developer
mike.chase@ca.ibm.com------------------------------
Original Message:
Sent: Thu July 20, 2023 08:06 AM
From: Jon Butler
Subject: Moving High-Values from Comp-3 - COBOL Ver 6.4
Congratulations on the upgrade. Every 30 years whether it needs it or not, eh? ;¬))
Yes, you have run into the non-numeric trap with COBOL 5 and 6, where variables defined as numeric can only hold....numbers! Low-values x'00' and high-values x'FF' are not valid numbers for Packed Decimal variables (COMP-3). You could use the INITIALIZE on the level-1 structure name to get past your problem. Also check out the INITIALIZE ALL TO VALUE option.
IMHO this is something that IBM should never have allowed, but we are where we are. You can also use the new TEST-NUMVAL intrinsic (built-in) functions to vet data read into a field from a file or perhaps BMS or MFS map before moving it to a numeric field.
------------------------------
Jon Butler
Original Message:
Sent: Wed July 19, 2023 12:06 PM
From: Girish Kumar
Subject: Moving High-Values from Comp-3 - COBOL Ver 6.4
Hi,
We are trying to execute the below code, but 6.4 version is throwing SOC7, whereas 2.2 version is running fine. I wanted to know is there any doc which explain this case...!
Prog code is as follows.
Working storage section.
01 WS-COMP3-VAR.
05 WS-COMP3-VAR1 PIC S9(7) COMP-3.
01 WS-NOR-VAR PIC 9(7).
PROCEDURE DIVISION.
MOVE HIGH-VALUES TO WS-COMP3-VAR. --> High values are moved to group variable
MOVE WS-COMP3-VAR1 TO WS-NOR-VAR --> COMP-3 variable is moving to normal variable causing SOC7.
Compilation is fine - no waning message or so. But the execution is causing SOC7 in 6.4 version only. in 2.2 version it is working fine.
Actually, we have a proj running to upgrade cobol ver from 2.2 to 6.4.
------------------------------
Girish Kumar
------------------------------