We've been using V5.2 in our test environment for a few weeks now, and after setting NUMPROC(NOPFD) and ZONEDATA(NOPFD) we haven't had any complaints from our developers, but yesterday it was brought to my attention that a MOVE from a Z(x) to a S9(x) with invalid numeric data (LOW-VALUES) causes a S0C7 with V5.2 whereas V4.2 chugs along happily.

I'd just like to know whether this is expected and unavoidable behaviour or not, so I can inform the devs what to expect from now on.

Hi Brian,

In order to provide a performance increase, V5.2 generates different sequences of instructions than V4.2, and these can sometimes lead to different results when there is invalid data; with valid data, the results should be the same. One area you will notice more S0C7s with invalid data is in computations and comparisons using USAGE DISPLAY numbers at ARCH(10) (zEC12) and higher, as the compiler uses Decimal Floating Point arithmetic as a performance boost, and the instructions that convert to DFP don't tolerate invalid digits and sign codes, so a comparison that might have "worked properly" in V4.2 might now abend in V5/V6. There are other similar situations where this is also true.

In general, you shouldn't be producing or using invalid data, and the compiler is not generally designed to provide compatibility with V4.2; IBM generally doesn't test for or correct invalid data. However, when we're made aware of a migration blocker like this and there's no performance penalty in doing so, we do attempt to generate code that produces the same behaviour as V4.2 even when the data is invalid. In this case, you are moving invalid data into a USAGE DISPLAY field, but that should generally be fine as long as you aren't subsequently USING the data. You should correct your data, but I also recommend you open a PMR, so we can track this issue and get the necessary context to see if this is something we can address.

Roger that - we'll open a PMR and see what happens. 

Thank you for replying.

FYI - we filed a PMR and after much ado, someone at IBM wrote:

  I was able to recreate the s0c7 at COBOL V5.2 compiler ptf level     

UI36448 and earlier - as the generated code includes a ZAP instruction,

which results in the s0c7 with invalid data.  However, at ptf level    

UI38258 and UI39594, an MVC instruction is being generated instead of  

the ZAP.  The MVC instruction is similar to the code that was generated

for V4.2.                                                              

  To resolve the problem, please apply UI38258 or UI39594. For the     

complete list of COBOL optf's (for compiler and run-time, please refer 

to the following url :                                                 

  http://www.ibm.com/support/docview.wss?uid=swg27041164              

AndI'm happy to report that it fixed our issue - V5.2 here we come :)