Mr. Ross,
Is there going to be a corresponding PACKCHECK compiler option? It is
very difficult to locate all of the assembler code that took liberty in
fixing positive pack decimal fields with a sign of "F" instead of
determining if the result field was signed or not. After all everybody
would use a hardware internal decimal instruction (AP, CP, DP, MP, SP,
and ZAP etc.) to access/process a pack decimal field! Who would have
ever guessed that one of the future compilers would be smart enough to
make a determination/assumption that you could just use a compare
logical character instruction (CLC) to determine equality between two
pack decimal fields?
Or, should we just take the performance hit and use NUMPROC(NOPFD) for
the life of COBOL? Maybe we could petition for the reinstatement of
NUMPROC(MIG). I guess we are all wondering just how much anguish
NUMPROC(MIG) is causing IBM? Because, it appears to be very beneficial
to some of us and less overhead than NUMPROC(NOPFD). If I remember
correctly NUMPROC(MIG) only fixed signs "on input" and NUMPROC(NOPFD)
does additional sign fixing.
Thank you for your time
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
