Replying to myself....
> -----Original Message-----
> From: Chase, John
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List On Behalf Of Art Celestini
> >
[ snip ]
> > 01 WS-HEXWORK-AREA.
> > 05 WS-HEX-INPUT-AREA.
> > 10 WS-HEX-INPUT-ARG PIC X(4).
> > 10 FILLER PIC X.
> > 05 WS-HEX-INPUT-COMP3 REDEFINES WS-HEX-INPUT-AREA
> > PIC S9(9) COMP-3.
> > ...
> > MOVE WS-HEX-INPUT-COMP3 TO WS-HEX-OUTPUT-DISPLAY.
> > INSPECT WS-HEX-OUTPUT CONVERTING
> > X'FAFBFCFDFEFF' TO 'ABDCEF'.
>
> PP 5655-G53 IBM Enterprise COBOL for z/OS 3.3.1
> ...
> 000018 MOVE
> 000386 5820 912C L 2,300(0,9) BLW=0
> 00038A F844 D0E8 2000 ZAP 232(5,13),0(5,2) TS2=0
WS-HEX-INPUT-COMP3
> 000390 F384 2005 D0E8 UNPK 5(9,2),232(5,13)
WS-HEX-OUTPUT-DISPLAY TS2=0
> 000019 INSPECT
> 000396 DC07 2005 A018 TR 5(8,2),24(10)
WS-HEX-OUTPUT PGMLIT AT +20
It just occurred to me that the ZAP instruction generated for the COBOL
MOVE statement could lead to S0C7s, so I checked the PoPs manual:
"Only the second operand is checked for valid sign and digit codes."
What's significant here is that the second operand IS checked.
Suppose the "second operand" (WS-HEX-INPUT-ARG) is initially the SNA
sense code x'087D0001'. The fact that it's redefined as a COBOL COMP-3
field does not make it so. I believe the ZAP in this instance would
"choke" on the 'D' in the middle of the "number".
What's needed here is a means to generate the UNPK instruction without
the ZAP, and I can't think of any....
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
