Here's the situation:

01  WS-NUM-OR-ALPHA.                                   06 WS-ALPHA-X01               PIC  X(001).                    06 WS-ALPHA-X30               PIC  X(030).                    06 WS-NUM                     PIC  9(001).                    06 WS-ALPHA REDEFINES WS-NUM  PIC  X(001).       77  WS-LENGTH                     PIC S9(004) COMP VALUE 1.              MOVE X'32'                     TO WS-ALPHA-X01MOVE X'32'                     TO WS-ALPHA-X30

In COBOL 4.2, compiled with NUMPROC(NOPFD), I get:

1. MOVE WS-ALPHA-X01              TO WS-NUM    --> X'F2'2. MOVE WS-ALPHA-X01(1:1)         TO WS-NUM    --> X'F2'         3. MOVE WS-ALPHA-X01(1:WS-LENGTH) TO WS-NUM    --> X'32' <--      4. MOVE WS-ALPHA-X30(1:1)         TO WS-NUM    --> X'F2'      5. MOVE WS-ALPHA-X30(1:WS-LENGTH) TO WS-NUM    --> X'32' <--    

In COBOL 5.1, compiled with OPT(0), ZONECHECK(MSG), ZONEDATA(NOPFD) and NUMPROC(NOPFD) I get:

1. MOVE WS-ALPHA-X01              TO WS-NUM    --> X'F2'2. MOVE WS-ALPHA-X01(1:1)         TO WS-NUM    --> X'F2'         3. MOVE WS-ALPHA-X01(1:WS-LENGTH) TO WS-NUM    --> X'F2' <--     4. MOVE WS-ALPHA-X30(1:1)         TO WS-NUM    --> X'F2'      5. MOVE WS-ALPHA-X30(1:WS-LENGTH) TO WS-NUM    --> X'F2' <--    

No runtime warning messages are given.

I was assuming the COBOL 5.1 options ZONEDATA(NOPFD) and NUMPROC(NOPFD) would produce the same result as COBOL 4.2 NUMPROC(NOPFD) did in this example. Wrong assumption...and the only way to identify this difference in behavior is to (manually) test/check the result.

I know it's all "invalid data" code. It was taken from a program with a "situation 5." in it and simplified/modified. WS-NUM is part of a record and was written to a file. The file is supposed to contain the value X'32'. The solution is to change all of the MOVEs in "MOVE xxxxxx TO WS-ALPHA" and thus create "valid code".
 

Is it possible to identify this type of "invalid data" code using one or more compiler options?

Hi Rene,

There is no option we provide that will allow you to identify the move of invalid data directly. The reason for this is that the move itself isn't invalid, especially in the case where the USAGE DISPLAY data item is redefined as alphanumeric, as you did in your example. It's only when you store non-numeric data in a numeric data item and then try to use that data that you've actually done something invalid. If you moved x'32' into WS-NUM but then only used WS-ALPHA, your program and data wouldn't be invalid at all!

We DO provide a way to detect uses of non-numeric USAGE DISPLAY data items. We added the ZONECHECK compiler option in May, 2015 (and have made a few improvements to it in recent PTFs). ZONECHECK(MSG) will display a message every time a USAGE DISPLAY item is used as a sender and isn't numeric, and ZONECHECK(ABD) will display a message and also abend.

Rene,

Can you run your sample code with this amended structure:

       01  WS-NUM-OR-ALPHA.
          05  WS-ALPHA-X01-G.
           06 WS-ALPHA-X01               PIC  X(001).
          05 WS-ALPHA-X30-G.
           06 WS-ALPHA-X30               PIC  X(030).
           05 WS-NUM                     PIC  9(001).
           05 WS-ALPHA REDEFINES WS-NUM  PIC  X(001).

And these two extra:

           MOVE WS-ALPHA-X01-G            TO WS-NUM
           DISPLAY WS-ALPHA

           MOVE WS-ALPHA-X30-G            TO WS-NUM
           DISPLAY WS-ALPHA

I would expect the output from those, for both V4 and V5, to be X'32'.

From the Language Reference

Reference modification creates a unique data item that is a subset of data-name-1 ... This unique data item is considered an elementary data item without the JUSTIFIED clause.

The MOVE of an alphanumeric elementary item to a numeric item should ensure a "positive" value in the receiving item (an F for unsigned, C for signed).

It looks to me that the code generated by V4 is treating the reference-modification with an evaluated expression for a length as a group-item in that context.

The V5 results look correct to me, and the amended program will confirm.

It is an unfortunate moment to illuminate an issue with the V4 compiler.

I would always test the reference-modified item for NUMERIC before the MOVE.

Bill,

Thanks four your reply. Your explanation makes sense.

I ran the amended code and both V4 and V5 show X'32' as the result for both DISPLAYs.

Thanks, I think that confirms it is an issue with the V4 compiler. Perhaps you'd like to raise a PMR with IBM, unless Mike wants to run with it :-)

With V4

Reference-modified field with expression for length evaluated at compile time: treated as elementary item

Reference-modified field with expression for length evaluated a run time: treated as group item

With V5

Reference-modified field with expression for length evaluated at compile time: treated as elementary item

Reference-modified field with expression for length evaluated a run time: treated as elementary item

COBOL 85 Standard and all related documentation indicates that the V5 treatment is correct. Oh, and simply thinking about it. Why would the same field, just resolved in different ways, give different results?

No-one's spotted it till now because mostly when using reference-modification with a numeric target field, "zoned decimal" numbers are the source, so you won't notice that the sign-establishment is missing.

A PMR in V4 would probably be closed as a permanent restriction.  Going back to the original question:  can this difference in behaviour be diagnosed?  I'm not too optimistic.  There is definitely a bug on V4.  We would have to detect the exact circumstances under which the bug arises and map that back to COBOL source.

We are trying to reconcile behavioural differences between V4 and V5.  Reference modification involving PIC X(1) linkage section items now work the same way.  Move a negative numeric edited to an unsigned zoned now works the same way. If we haven't already done it, I think we have a plan to moved index variables out of harms way.  There are a few others artifacts of V4 that are now mimicked in V5.  We won't be mimicking this one because it's just plain wrong!

If we haven't already done it, I think we have a plan to move index variables out of harms way

You mean the situation discussed here?: https://www.ibm.com/developerworks/community/forums/html/topic?id=c476d2c9-0d4e-4073-97c5-6384d8f381c0&ps=25

Compiler Signature Information Byte 24, bit 2, indicates whether a program uses reference-modification. However, if programs at your site use reference-modification a lot, that probably won't help so much.

You could "scan" your sources for expressions which must evaluate at runtime (which seems to be the problem), but note that it would be less easy to automatically identify numeric items as being the target of the reference-modified MOVE.

Yes, that's the situation.

Excellent, thanks. I'll let David know.

To be clear, the "support the B***dy Heuga Kitchen Tile add filler storage fix" fix hasn't been implemented yet.  But it is our intention to do so.

Do you know of cases where the same technique (adding filler storage) was used to handle the

MOVE 'stuff' To GRP2(300:320)     *>  This is illegal!

parameter mismatch case?  Do you know of cases where this technique was used to deliberately update a group other than the one that was passed in?

I have seen a couple of people attempt it deliberately ("I could see the data I wanted in the dump, my definition just wasn't long enough in the LINKAGE SECTION"), but soon squashed that. I'd say I wouldn't expect deliberate cases of that. Or not many. No-one would think that an expedient solution in any scenario. Or almost no-one.

Accidentally is a different issue. I've seen cases of storage being overwritten without it causing a problem, because the storage which was overwritten wasn't used after it was trashed.  The values doing the overwriting were not relevant to any logic (in one case there was a FILLER at the end of copybook, and a second FILLER at the same level in the LINKAGE SECTION, in another someone had "used some of the FILLER at the end" of a structure defined in the LINKAGE SECTION, without reducing its length - both utilising group moves). These type of programs "run normally" until someone adds some new storage at an unfortunate place in the CALLing program, so that now something significant is overwritten. Or until indexes magically appear...

So, deliberately (like the "table back-stop"), no. Accidentally, yes, I'd expect some "working" programs to be doing that, but they are already accidental accidents waiting to happen, and there won't be as many cases as the back-stop. Other than the nifty RDz checker, which would get some (not the wild reference-modification examples), there's no real forewarning possible on that.

And no, adding a FILLER in the CALLing program would not be a fix, as the problem only needs to be fixed in one place, the CALLed program. The data "defined" in the CALLed program was not good data. In the case of the table overflowing in the CALLed program, the data is good, just nowhere to put it, except by adding the spare in the CALLing program, until you can get around (if ever) to changing the 20 others which don't happen to have an overflow. Yet.

David is happy that the change is coming. He has said "That would be good news. Good many of my clients, while testing 5.X, have been stung by the s0c4 index clobber. Mostly older code."

The "mostly older code" fits with other anecdotal evidence I've seen. I think once the 1MB limit on WORKING-STORAGE was removed, people were happier to give wider safety-margins to tables, and this as well as with better practices (warning messages as tables start to get closer to filling, for instance) becoming more common, means that newer code is less likely to see the emergency back-stop tables.

The longevity of COBOL programs and systems means there's still a lot of "older code" around.