IBM Mainframe Forum

Hello,

there is a filed WS-AAA PIC S9(4) COMP, if there is a statement MOVE -32767 TO WS-AAA, do you have some idea how to check
the real value in memory for WS-AAA , thanks,

Helen

First, the value stored in memory will depend upon the compile option TRUNC. TRUNC(STD) limits a binary (COMP) variable's value to the PICTURE size, while TRUNC(BIN) allows the binary (COMP) variable's value to reflect the memory size instead of the PICTURE size.

Second, if you read the COBOL Language Definition and Programming Guide manuals, you do not have to "check the real value in memory" because you will know with TRUNC(BIN) it will be X'8001' and with TRUNC(STD) it will be X'F531'.

If you really want to see the actual memory usage, you can call CEE3DMP (make sure you use compile option TEST or TEST(h,SYM) as appropriate).

thank you Robert for your quick response,
could you tell me what is difference TRUNC(BIN) and TRUNC(STD)？

Since I've already told you the difference, I highly recommend you bookmark http://www-01.ibm.com/support/docview.wss?uid=swg27036733 and learn how to look things up on your own. The Language Reference and Programming Guide manuals are ones you'll need to reference frequently to find out how Enterprise COBOL treats variables (among other things). The Programming Guide goes through EVERY possible compiler option and what the various values mean, while the Language Reference is the definitive source of how COBOL on the mainframe handles language constructs. From there, you may wind up needing other manuals (such as the Language Environment manuals) but start with the basics.

Hello Robert,

as your suggestion, I read the link you mentioned, and I built a sample for WS-AAA binary field PIC S9(4) COMP.
after "move -4096 to WS-AAA", I checked the dump and got the hex value x'F000' for WS-AAA, it's correct,
but when I display WS-AAA, got the output result is 4090,
it's wired, do you know why? thanks,

Helen

You have to read more carefully. You don't get 4090 you get 409O. Do you see the difference? The letter O is showing that you have a negative number ending with six.

thanks BillyBoyo for your detail explain, do you know why the letter O stand for "a negative number ending with 6"? thanks again,

do you know why the letter O stand for "a negative number ending with 6"?

The Language Reference manual explains, in detail, the internal representation of numbers for zoned decimal, packed decimal, and binary. Read it.

Asking "why" questions is rarely worthwhile on this or any forum. Assuming your question is a "how" question (as in how does O represent a negative 6), you have your answer already. Assuming your question is a "why" question (as in why zoned decimals code the sign in the last byte, or why D was chosen for negative numbers), Enrico's answer is the best you'll get. Why design decisions were made the way we see them requires going back more than 50 years and also requires a knowledge of prior coding systems such as BCD. Rather than ask why, just accept that this is the way it is and move on.

ACCEPT and DISPLAY in Enterprise COBOL and prior IBM Mainframe COBOLs are very limited (and Standard) in their operation. They are not intended for general-purpose use in producing/consuming formatted data.

If you define a numeric-edited field and MOVE the binary value to that, and then DISPLAY the numeric-edited field, you'll get a much more "friendly" output.

01 to-show-a-signed-binary PIC -99999. (five digits in case you have TRUNC(BIN), else four).

If you were to DISPLAY a binary defined with decimal places, you wouldn't get any in your output. Again, define a numeric edited field to show those if you ever have them.

Without using numeric-edited fields, you are getting output which distinguishes between + and -, but without showing you are sign (which sign would you want, leading, trailing, CR/DB)?

If you try it, you'll find a similar thing with zoned-decimal and packed-decimal. Instead of relying on the default values for the representation of DISPLAY, use numeric-edited if you want to see the value which would be represented on a report or screen, and REDEFINES the field as a PIC (or have the fields subordinate to a group-item) and DISPLAY that field (and use HEX when looking at the output) if you want to see the internal representation - the value prior to what was produced by the editing (useful if you feel there may be bad data in your field).