Also, IBM COBOL for z/OS v6 does not generate a TP to check for IF NUMERIC.
This is the generated code for an IF NUMERIC test at
OPT(0),ARCH(10),NUMPROC(NOPFD):
The COBOL code is:
01 work-areas.
05 out-field pic s9(3) packed-decimal.
move x'125F' to work-areas.
if out-field is numeric
display 'numeric'
else
display 'not numeric'
end-if.
goback.
The IS NUMERIC generated code:
LA R6,240(,R13) # TS2=5
LA R4,236(,R13) # TS2=6
XR R2,R2
TRT 152(2,R9),184(R3) # OUT-FIELD
ST R1,0(,R6) #
STC R2,0(,R4) #
BRC 13,L0005
TM 236(,R13),X'3F' #
BRC 7,L0005
-----Original Message-----
From: IBM Mainframe Assembler List <[email protected]> On Behalf
Of Schmitt, Michael
Sent: Monday, February 14, 2022 11:12 AM
To: [email protected]
Subject: Re: Rules for Zoned Overpunch
Yes, IF NUMERIC will catch non-preferred signs when compiled with NUMPROC(PFD).
So will the NUMCHECK option, which adds run-time checks -- it is like there's a
"IF NOT NUMERIC DISPLAY A WARNING" on use of a numeric field.
Where this came up a few weeks ago was with a program that was calling an
assembler utility that I thought we could trust, so we had no reason to be
testing its output fields.
> Can you provide an example?
Yes, but of what? An example case where the wrong (in COBOL's view) sign nybble
will create an incorrect processing result?
It is actually simple: COBOL wants to generate CLC & MVC instead of CP & ZAP
when it can.
FWIW, we started compiling with NUMPROC(PFD) in 2015. We do hit problems, but
not enough to go back to the slower code. An example problem is when code is
moving spaces to a packed-decimal field and expecting it to be processed like a
zero. That works with NUMPROC(NOPFD) but not with preferred signs!
-----Original Message-----
From: IBM Mainframe Assembler List <[email protected]> On Behalf
Of Binyamin Dissen
Sent: Monday, February 14, 2022 6:16 AM
To: [email protected]
Subject: Re: Rules for Zoned Overpunch
On Fri, 11 Feb 2022 18:40:42 +0000 "Schmitt, Michael"
<[email protected]> wrote:
:>What do you want to do if it is /not/ FACEBD?
:>Also, while the machine instructions consider F to be positive, IBM COBOL
since VS COBOL II really wants 3 signs: F, C, D, where F is UNSIGNED. So it
does make a difference when a packed or zoned field is being returned from an
assembler program; the value really should match how the COBOL program is
expecting it.
:>That is, if the COBOL program is expecting PIC S9(3) PACKED-DECIMAL but the
value is x'123F', or the COBOL program expects PIC 9(3) PACKED-DECIMAL and the
value is x'123C', that would be bad. Really bad.
:>From a practical standpoint it would prevent the COBOL program from being
able to generate maximally efficient NUMPROC(PFD) code -- you wouldn't be able
to use that compile option.
:>This is called "COBOL Preferred Signs", and started in 1992 or so.
I would assume that by now the IF NUMERIC for a packed field would generate a
TP, so I don't see why there would be an issue if a non-prefered sign is
provided as a parameter or return value.
Can you provide an example?
