How to display the actual value of a comp variable in cobol

Vikas picture Vikas · Aug 19, 2013 · Viewed 26k times · Source

I have the following variable in COBOL program which gets its value from a file, when it is read:

01 Employee-number PIC 09(8) comp
01 Employee-number-x redefines 
   Employee-number PIC x(04)

I have another variable in the same program:

01 D-element-number PIC 9(04)

Now,

Move Employee-number to D-element-number

Then I write this D-element-number to a file

value read from input file is :

0013 
0024

so this value comes to Employee-number and Employee-number-x and I move this value to D-Element-number and write this variable to a output file.

But I get this in the output file:

4660
FFFF
4660

4660 is the decimal equivalent of X'1234'

But I want to see something like:

1234
FFFF
1234

How can I achieve this ?

I am allowed to change the definition of D-element-number but nothing else.

Answer

Bill Woodger picture Bill Woodger · Aug 19, 2013

Assuming that when you have X'00001234' you want C'00001234', have a look here. http://ibmmainframes.com/viewtopic.php?p=234231#234231

Ignore the rest of the discussion for now, just concentrate on that post.

This is the key part:

       PERFORM UNTIL X-WS-1000 > X-WS-1000-MAX
           MOVE WS-1000-BYTE-TBL (X-WS-1000)
                                   TO WS-PACKED-X (1:1)
           MOVE WS-PACKED          TO WS-DISPLAY
           MOVE WS-DISPLAY-X       TO WS-2000-BYTE-TBL (X-WS-2000)
           SET  X-WS-1000          UP BY 1
           SET  X-WS-2000          UP BY 1
       END-PERFORM

You need the exact storage definitions to go with it (don't "correct" anything).

It works by getting the compiler to use the "unpack" instruction (UNPK). This one is working one byte at a time, so simple to explain.

X'12' (an example on-byte field) is put in a two-byte field. X'12ii' (where the value of ii is "irrelevant").

UNPK will then turn this "packed" number into a "zoned" number. A "Zone" is the first four bts of a byte, and for a Zoned number, the four bits are all set to one. So you get an F. Then you get the left-most digit from the first byte. Then you get the second output byte, first four bits set to F, then the second input digit.

Then the UNPK continues with the final byte, which contains one irrelevant digit, and an irrelevant sign. For a Zoned number, the sign and right-most digit occupy the same byte (the sign in the zone) so you get a whole byte of irrelevance.

X'12' -> X'12ii' -> X'F1F1ii'.

The first two bytes of the three-byte output are C'12'.

Nos, what is all fine for numbers, but letters make a mess:

X'AB' -> X'ABii' -> X'FAFBii'

Although F and a digits gives a displayable number, for F and a letter, the result does not mean much directly.

Now the INSPECT ... CONVERTING comes to the rescue: FA gets translated to C'A' (X'C1), and the same for the letters through to F.

Your results after the CONVERTING will be C'AB'.

Should give you enough to work on.

There are other methods, but this is a fair COBOL approximation to the classic Assembler technique with UNPK and a TRANSLATE (TR) and a table of translation values.

If you use your favourite search engine. you should be able to fine more methods, using calculation (more than one), table-lookups, I've even seen a 256-WHEN EVALUATE that "works", but I guess it is a little on the "slow" side.

Thinking further, you actually have a BCD (Binary Coded Decimal) don't you? This is a Packed Decimal, without the sign. You don't have any alphas in your field.

This is even simpler to convert.

01  the-converted-value PACKED-DECIMAL PIC 9(8)V9 VALUE ZERO.
01  FILLER REDEFINES the-converted-value.
    05  the-binary-value PIC X(4).
    05  FILLER PIC X.

MOVE Employee-number-x TO the-binary-value
MOVE the-converted-value TO D-element-number (with Gilbert's correction to PIC 9(8)).

The "decimal place" is the ii, the ignore value and ignore sign. You no longer need the INSPECT ... CONVERTING ... as you only have numeric digits. If you have a BCD...

A really good way for you to have answered your own question would have been to find out how the number was created in the binary field in the first place.