Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
In the fine IBM Cobol manual, it says, if you want to call PL/I or Fortran from your Cobol program, you have to set a compiler option which allows "non-preferred" signs in decimal fields.
So, instead of just C/D and F, the option allows A, B, C, D, E and F to be valid for a zoned- or packed-decimal.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
I haven't got the foggiest idea. In the 25 years of using PL/I, I've never ever seen any A, B or E signs in any PL/I fixed decimal, even getting F signs n PL/U is pretty rare.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Thanks Prino, that was quick :-)
Now, where's the FORTRAN forum....?
Here's the quote from the Programmer's Guide:
Quote:
Using NUMPROC(PFD) can affect class tests for numeric data. You should use
NUMPROC(NOPFD) or NUMPROC(MIG) if a COBOL program calls programs written in
PL/I or FORTRAN.
Perhaps the IBM Cobol people don't trust the results that might come back from PL/I or FORTRAN? Could it actually be something for LE?
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Bill Woodger wrote:
In the fine IBM Cobol manual, it says, if you want to call PL/I or Fortran from your Cobol program, you have to set a compiler option which allows "non-preferred" signs in decimal fields.
So, instead of just C/D and F, the option allows A, B, C, D, E and F to be valid for a zoned- or packed-decimal.
Does anyone know why?
OS/360 and 360/n machines did define any non-decimal digit in the sign nybble to be valid; A,C, and E were positive, B and D were negative, and F was unsigned.
It has, as Mr. Prins intimates, been decades since anything running on a 360 or successor has actually produce a packed decimal number with an A, B, or E in the sign nybble. But it's still technically valid, and therefore must be handled.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
From the POP.
Quote:
The preferred sign codes are 1100 for plus and 1101 for minus. These are the sign codes generated for the results of the decimal-arithmetic instructions and the CONVERT TO DECIMAL instruction.
Alternate sign codes are also recognized as valid in the sign position: 1010, 1110, and 1111 are alternate codes for plus, and 1011 is an alternate code for minus. Alternate sign codes are accepted for any decimal source operand, but are not generated in the completed result of a decimal-arithmetic instruction or CONVERT TO DECIMAL. This is true even when an operand remains otherwise unchanged, such as when adding zero to a number. An alternate sign code is, however, left unchanged by MOVE NUMERICS, MOVE WITH OFFSET, MOVE ZONES, PACK, and UNPACK.
So, if anyone does call PL/I or FORTRAN from Cobol, either compile the program with NUMPROC(NOPFD/MIG) (as IBM suggests) or, if you don't want to use NOPFD/MIG,
Code:
ADD ZERO TO data-name GIVING data-name
for each decimal (zoned or packed) returned from the called program. That will take care of the non-preferred signs, should they ever appear.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Bill Woodger wrote:
So, if anyone does call PL/I or FORTRAN from Cobol, either compile the program with NUMPROC(NOPFD/MIG) (as IBM suggests) or, if you don't want to use NOPFD/MIG,
Code:
ADD ZERO TO data-name GIVING data-name
for each decimal (zoned or packed) returned from the called program. That will take care of the non-preferred signs, should they ever appear.
Of course this will only happen if the compiler isn't smart enough to optimize the whole statement away, a it really should be doing!
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
prino wrote:
Bill Woodger wrote:
So, if anyone does call PL/I or FORTRAN from Cobol, either compile the program with NUMPROC(NOPFD/MIG) (as IBM suggests) or, if you don't want to use NOPFD/MIG,
Code:
ADD ZERO TO data-name GIVING data-name
for each decimal (zoned or packed) returned from the called program. That will take care of the non-preferred signs, should they ever appear.
Of course this will only happen if the compiler isn't smart enough to optimize the whole statement away, a it really should be doing!
I'll have to check that out, but I think it will keep it, because of what the POP says. It is not only adding zero (or doing nothing, as another way of putting it, so suitable for removal) it is also ensuring that the sign is "preferred", so doing "something" (so not suitable for removal).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
prino wrote:
Of course this will only happen if the compiler isn't smart enough to optimize the whole statement away, a it really should be doing!
Away from Scrabble for the moment.
Code:
00037A F822 D0F0 D0F0 ZAP 240(3,13),240(3,13)
This is a little doozy actually generated by the Cobol compiler to do the sign "fixing" (with a particular compiler option) of non-preferred to preferred. This, for definite, the optimiser does not remove. The ADD ZERO... is the closest I can get in Cobol code to the same thing.
"Doctor, doctor, I think I might have a non-preferred sign!", "Oh, go ZAP yourself!".
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
Bill Woodger wrote:
prino wrote:
Bill Woodger wrote:
So, if anyone does call PL/I or FORTRAN from Cobol, either compile the program with NUMPROC(NOPFD/MIG) (as IBM suggests) or, if you don't want to use NOPFD/MIG,
Code:
ADD ZERO TO data-name GIVING data-name
for each decimal (zoned or packed) returned from the called program. That will take care of the non-preferred signs, should they ever appear.
Of course this will only happen if the compiler isn't smart enough to optimize the whole statement away, a it really should be doing!
I'll have to check that out, but I think it will keep it, because of what the POP says. It is not only adding zero (or doing nothing, as another way of putting it, so suitable for removal) it is also ensuring that the sign is "preferred", so doing "something" (so not suitable for removal).
I think that that indicates the difference between "abstract COBOL" and "COBOL as she is implemented". In the abstract, that statement does do nothing, and so can be optimized away. To the left, the pseudo-assembler generated by the compiler does not do nothing (it generates a ZAP, which rectifies the sign), and thus a really smart optimizer would leave it. An optimizing COBOL compiler written for a non-z machine might not generate anything analogous to a ZAP, and could thus really optimize that statement to a comment.
