Problem:

Mainframe Express (MFE) is not returning an abend like the Mainframe when an invalid packed field is being used in a computation.

For example on the mainframe a S0C7 is received with this information:

ADD FUND-UNITS IN SCHEDULE-SEGMENT (UNIT-SUB)

UNIT-SUB value of 1

SCHEDULE-SEGMENT value of (along with the hex content):

'20040201......SA..V...................V..............'

X'F2F0,F0F4,F0F2,F0F1,0000,0000,000C,E2C1,521C,E500,...

When in MFE there is no abend or anything to show that there was an invalid field.

Resolution:

The problem here is that the customer used GNT code. We do validation of data for INT code by default, not for GNT code. One has to pass the directive CHECKNUM for GNT code for any programs you might suspect of passing bad data.  We expect one to debug the user code using INT code and then use GNT code for previously tested code. So our default for GNT code is to not check data.  Actually, IBM has long documented that programs should validate data before using it. See this strong statement from IBM in its VS Cobol II manual and a more 'favorable politically correct' one from their z\\OS Compiler.   

Title: VS COBOL II Application Programming Guide

Document Number: SC26-4045-05

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYA1101/3.3.2?SHELF=IGYSH007&DT=19930312141355

Notice the last sentence of the second paragraph:

It is your responsibility to ensure that the contents of a data item

conform to its PICTURE and USAGE clauses before using

the data item in any further processing steps.

IBM has since made this more 'politically correct' in their latest compiler

manuals saying:

  Title: Enterprise Cobol for z\\OS and OS390

         Programming Guide Version 3 Release 2

Document Number: SC27-1412-01

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG10/1.3.7?SHELF=IGY3SH10&DT=20020923143836

Again, last sentence of second paragraph:

  Ensure that the contents of a data item conform to its PICTURE

and USAGE clauses before using the data item in any further

processing steps.

So IBM is saying that all data must be valid before using it, but it is

doublespeak because their default numeric processing compiler option

is NUMPROC(NOPFD), which means they will perform sign validation

processing trying to 'fix up' the user's data. This was done for

compatibility with the old IBM OS/VS Cobol compiler, but it doesn't always work.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG10/2.4.34?SHELF=IGY3SH10&DT=20020923143836

Secondly, Micro Focus, on the other hand, believes that good code

passes good data. So we will stop you when the contents of a field

are not conforming to its PICTURE and USAGE definition. We have added

many directives to our compiler and made many runtime fixes to try

and emulate IBM's elusive behavior. We are close, but we will never

achieve it because they do not document all their anomalies. And no one

can guarantee when a S0C7 will happen on the host and when it will not.

The bulk of our data validation work has been for INT code since we

debug that and then use GNT code as our final version in MFE.

Thirdly, this case involves the use of uninitialized storage. IBM supplies

a runtime switch to initialize storage via their LE common runtime for

Cobol, C, Fortran, and PL/I. The switch is named STORAGE. It is

described in the LE Programming Reference:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3140/CONTENTS?SHELF=&DT=20040112111350#2.3.52

in section 2.3.52:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA3140/2.3.52?DT=20040112111350

But also reference 2.3.52.3 to read what IBM says about

performance with this option. The default Micro Focus for

INT code and GNT code uses a directive named DEFAULTBYTE(00)

which sets uninitialized storage to binary Zeroes (x'00'), but

like IBM's option, this doesn't mean that the data is now correct.

The best answer is to use an IF NUMERIC test prior to any

arithmetic operations in your programs.