On Sun, 13 Dec 2015 14:53:27 -0600, David Speake <[email protected]> wrote:
>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. I had meant to reply to this earlier, but unfortunately, work and the holidays intervened! :-)> The TRUNC option only applies to Binary (COMP) fields, not Packed (COMP-3) fields. The generated code is the result of compiling the program with the NOOPTimize option. If OPTimize(STD) or OPTimize(FULL) is used, then the generated code will only contain an MVC instruction. We have our default set to OPT(STD) as this generates better code but still allows Debug and Fault Analyzer to work. The ZAP instruction will also appear in instructions that add/subtract to/from Packed fields. The reason is because COBOL II (and beyond) will sometimes use CLC to compare two Packed fields instead of a Compare Packed (CP) instruction. This introduces a potential problem if the result of the computations is negative zero! For example, two S9(3) COMP-3 fields, (FLD1 = -999 and FLD2 = -1), are added together, the result is negative zero with the overflow flag set. The ZAP will change -0 to +0, but leave other values unchanged. Thus zero fields would always compare equal with CLC. If ON SIZE ERROR is used on the ADD or SUBTRACT, then the ZAP instruction is not generated. The performance gain of using CLC instead of CP is somewhat offset by having the extra ZAP instruction added. IMNSHO, Packed fields should always be defined with an odd number of digits in COBOL programs. Packed fields always contain an odd number of digits so why would you create extra work for the compiler and the programmer by defining a Packed field with an even number of digits? If you want an even number of digits on report, then define the edited output field with even number of digits. In COBOL V5.2 they have added a new RULES compiler option and one of the new rules that can be used is NOEVENPACK. NOEVENPACK will issue Warning messages for Packed fields with an even number of digits! -- Dale R. Smith ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
