MVSFORUMS.com

anita_m · Posted: Wed May 23, 2007 8:23 pm Post subject: data type conversion in cobol

How can I format a PIC 9(9) field into PIC 9(5)V9(4) COMP-3 in cobol.

kolusu · Posted: Thu May 24, 2007 10:03 am Post subject:

anita_m,

Is this a trick question?

a Simple move

MOVE <PIC 9(9)> TO <PIC 9(5)V9(4) COMP-3>

will solve it.

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

Nic Clouston · Posted: Thu May 24, 2007 10:14 am Post subject:

Kolusu - there were loads of responses here earlier - Dick and I both had responses. Dick posed the Q. does the PIC9(9) field have an implied decimal point in it? In which case a division by a power of 10 would be needed during the assignment.
_________________
Utility and Program control cards are NOT, repeat NOT, JCL.

dbzTHEdinosauer · Posted: Thu May 24, 2007 10:28 am Post subject:

Nic, check the dinosaur forum.
_________________
Dick Brenholtz
American living in Varel, Germany

Nic Clouston · Posted: Thu May 24, 2007 10:31 am Post subject:

I think I got here whilst it was in transit because there was nothing flagged there when I came in here.
_________________
Utility and Program control cards are NOT, repeat NOT, JCL.

anita_m · Posted: Thu May 24, 2007 11:30 am Post subject:

No 9(9) does not have an implied decimal.

Assuming IN-VAR -> 118030000

Nic Clouston · Posted: Thu May 24, 2007 11:39 am Post subject:

In fact IN-VAR does have an 'IMPIED' decimal because WS-VAR-R is redefing IN-VAR to be 5.4 so by using WS-VAR-R your 118030000 becomes 11803.0000. by moving IN-VAR to OUT-VAR you are moving 9(9)V to 9(5)V9(4). This can only handle up to 99999.9999 so your high-order bytes are being dropped hence the 30000000 which is really 30000.0000. If OUT-VAR was a DISPLAY variable wth the decimal point coded then it would be displayed as 30000.0000. Hope I got the right number of zeros in all that!
_________________
Utility and Program control cards are NOT, repeat NOT, JCL.

Phantom · Posted: Thu May 24, 2007 11:40 am Post subject:

Anita_M,

You have shown two different ways of converting yourself. Now what is your actual query ??? If you wanted the last 4 digits of 9(09) to be considered as decimals then the REDEFINES option or DIVISION by 10000 would solve the problem.

Else, you would get truncated result - when you move 9(09) to 9(5)V9(4). Both are correct - as per the rules of COBOL.

So, what is your question ?

Thanks,
Phantom

anita_m · Posted: Thu May 24, 2007 2:06 pm Post subject:

When IN-VAR = 118030000

MOVE IN-VAR TO OUT-VAR.
DISPLAY 'OUT-VAR' -> 300000000

I wanted to know the reason.

kolusu · Posted: Thu May 24, 2007 2:15 pm Post subject:

Phantom · Posted: Thu May 24, 2007 2:17 pm Post subject:

Good question....

You need to understand the basics. Though IN-VAR and OUT-VAR are defined to have 9 digits (on total), COBOL processes the Implied decimal provided in the declaration of OUT-VAR (9(05)V9(04)) carefully and knows that It can hold max of 5 numeric digits.

But you are trying to move 9 numeric digits to OUT-VAR, so the truncation happens. It actually moved last 5 digits which is '30,000' to numeric portion of OUT-VAR. Now, since there are no decimal places in the source field, COBOL puts the default value of '0' in the decimal portion of the receiving field.

So, it pads 4 decimals after '30,000' - Now you get '30,000.0000' which COBOL displays as 300000000 - since you did not use any EDIT characters.

Try moving OUT-VAR to some edited variable in the format ZZ,ZZZ.9999 and then see the displays.

Hope this answers your question

Thanks,
Phantom