Another side effect of the ZAP is that the sign halfbyte will be X'C' or
X'D'
after the ZAP, no matter what it was before (CAFE or DB); that is,
ZAP forces the sign halfbyte to the preferred values.
I recall that there are some COBOL compiler options that deal with this.
Kind regards
Bernd
Am 13.12.2015 um 21:53 schrieb David Speake:
A coworker posed the following question.
Given a COBOL statement that moves a field defined as S9(9) comp-3
to a field defined S9(8) comp-3, the generated assembler code looks like this:
01A598 D204 5E58 17B3 MVC 3672(5,5),1971(1)
01A59E 940F 5E58 NI 3672(5),X'0F'
01A5A2 F844 5E58 5E58 ZAP 3672(5,5),3672(5,5)
I know the following:
1. The program was compiled with the TRUNC option
2. The source and target field are the same length (5 bytes)
3. the first line does the actual move
4. the second line is generated because the TRUNC compile option
So why is IBM generating the ZAP instruction?
The only use to this is to abend with S0C7 if the data is garbage.
Right?
I too can see no good reason for ZAP.
Not a pressing issue, just both puzzled.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
