...same player shoots again ;-)

Here's the situation:

77  WS-LENGTH                  PIC S9(004) COMP.

01  WS-ALPHABET-UPPER-LOWER.                                        
    06 WS-UPPER-1ST-HALF       PIC  X(013) VALUE 'ABCDEFGHIJKLM'.   
    06 WS-UPPER-2ND-HALF       PIC  X(013) VALUE 'NOPQRSTUVWXYZ'.   
    06 WS-LOWER-1ST-HALF       PIC  X(013) VALUE 'abcdefghijklm'.   
    06 WS-LOWER-2ND-HALF       PIC  X(013) VALUE 'nopqrstuvwxyz'.   
    06 WS-ALPHABET-AND-MORE    PIC  X(010) VALUE '!@#$%/&*()'.      
                                                                     
01  WS-RECEIVER-GROUP.                                              
    06 WS-RECEIVE              PIC  X(007).                      
    06 WS-RECEIVE-OVERFLOW     PIC  X(055). 

MOVE some-value TO WS-LENGTH
MOVE ALL '1234567890' TO WS-RECEIVE-GROUP.
MOVE WS-UPPER-1ST-HALF TO WS-RECEIVE(1:WS-LENGTH)

The value of WS-ALPHABET-UPPER-LOWER is:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!@%/&*()"

The value of WS-RECEIVER-GROUP (before the MOVE) is:
"12345678901234567890123456789012345678901234567890123456789012"

When using a value for WS-LENGTH > 13, i.e. larger than the sending(!) data item, I get different results:

         COBOL- 
LENGTH   VERSION   WS-RECEIVER-GROUP

 0 ?!     4.2     "12345678901234567890123456789012345678901234567890123456789012" 
          5.1     "12345678901234567890123456789012345678901234567890123456789012" = equal (no modification)

13 ?!     4.2     "ABCDEFGHIJKLM4567890123456789012345678901234567890123456789012"
          5.1     "ABCDEFGHIJKLM4567890123456789012345678901234567890123456789012" = equal

20 ?!     4.2     "ABCDEFGHIJKLM       123456789012345678901234567890123456789012" <--  7 SPACEs
          5.1     "ABCDEFGHIJKLMNOPQRST123456789012345678901234567890123456789012"

60 ?!     4.2     "ABCDEFGHIJKLM                                               12" <-- 47 SPACEs
          5.1     "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!@#$%/&*12"

I know it's all "illegal" code; the manual states that length must be a positive nonzero integer and <=  #characters in that data item.
When those illegal values are hard-coded into the source, the compiler gives error messages.

This situation is taken from a program that ABENDs (0C7) in COBOL 5.1 and didn't do so in COBOL 4.2.
The "overflowed" area has a NUMERIC data-item and the overflowing SPACEs in COBOL 4.2 are handled "better" than the overflowing "rubbish" that COBOL 5.1 puts in.
The programmer never noticed the "overflow" situation and got away with it in COBOL 4.2. (un)Fortunately the program even took all the right paths and the outcome was "correct".
Not so in COBOL 5.1 (in this case).

The ZONECHECK option helps to determine invalid data at run-time.
Is there an option to have the program to perform a check for an invalid length in the reference moficication at run-time?

Hi Rene,

The SSRANGE option performs runtime checks on reference modifications; it's existed in Enterprise COBOL for a while (e.g. previous to COBOL V5.1).

We have also corrected the behaviour of V5.1 and later compilers so that in the specific situation you describe, the compiler will use the behaviour from V4.2, to ease migration efforts. This has been updated in recent PTFs for V5.1 and V5.2, and will be released in the first V6.1 PTF as well.

Thanks !

 I'll give the SSRANGE a try.

If you want a permanent runtime check for this, bear in mind that there is no way to limit the checks to a particular use - it affects all non-literal subscripting or reference-modification in the program where SSRANGE is used.

Best is to not let it happen, by coding, and use SSRANGE only during program (Unit) testing (just in case you pigged-up that code).

Just to note that with the latest SSRANGE options, a zero-length MOVE can be allowed. The effect of this is as you have shown. Nothing happens, at least if the targe lengtht is zero (if the source length is zero, there will of course be padding to the length of the target).

It is a formalisation of the behaviour of pre-V5 Enterprise COBOL (undocumented) when SSRANGE was not used, although I'd guess mostly these would be program errors (it is not often you need to deliberately MOVE ... TO "nothing" when you can't identify that and just... not do it).

Thanks for the explanation.

We'll use the SSRANGE option to find pigged-up code only and code the runtime checks ourselves; just as you suggested.

At our site we use COBOL 5.1. Our latest installed PTF is the "Compiler October 2015 PTF", Date Released: 05 November 2015.
Can you identify the 5.1 APAR/PTF that corrects the specific situation?

This is the change to SSRANGE, with new sub-options, from January 2016, for V5.2: http://www-01.ibm.com/support/docview.wss?uid=swg1PI53044

I don't know the intricacies/delicacies of how it does or doesn't get from there to V5.1.

I think Mike or Allan are the best bet for knowing the detailsof the return-to-pre-V5-behaviour for reference-modification outside the storage the modification is coded on (behaviour of those references which would trip on the SSRANGE). The first I knew of it was your previous discussion in March and I haven't noticed any specific fixes since. No fixes at all for V6.1 yet, so Mike may have been referring to near-future resolution.

The zero-length fix is here, again as V5.2: http://www-01.ibm.com/support/docview.wss?uid=swg1PI46490

You should be up-to-date on that one, and I think the data you've shown confirms it.

I use this: http://www-01.ibm.com/support/docview.wss?uid=swg27041164

Sorry, that's all I know :-)

Hi Rene and Bill,

The fixes to provide compatible behaviour were delivered in the March 2016 V5.2 PTF (http://www-01.ibm.com/support/docview.wss?uid=swg1PI59330), April 2016 V5.1 PTF (http://www-01.ibm.com/support/docview.wss?uid=swg1PI57812), and will be in the first V6.1 PTF, coming soon.

Hi Mike,

Thanks for the links to the fixes.

I'll ask our infra team to install all of the PTF's that were released after the "Compiler October 2015 PTF" and do a re-run after that. This will take some time but I'll inform you of the results.