MOVE question 1

[nxm150]

I am moving a PIC 9(13) field to PIC S9(13)V COMP-3 field.
My value of the sending field is (with hex underneath)

010009151857.
FFFFFFFFFFFF4
010009151857B

and the value of my receiving field is

010009151857:
FFFFFFFFFFFFF
010009151857B

Why is my decimal point being translated to a FB?

 

[MarcLodge]

I'm not sure I understand your post. If you're moving from a PIC 9(13) field, why has it got a decimal point in it? Also if you are moving to a signed COMP-3 field, surely the hexadecimal value would be 0000009151857C or D depending on whether it was positive or negative, not the alphanumeric hexadecimal that you quoted ?

Please clarify your question a little further and I'm sure we can help.

Regards,

Marc

 

[nxm150]

Since I don't have an input file defined as

IN-CLAIM-YR-MTH PIC S9(09) COMP.
IN-CLAIM-UID PIC S9(13)V COMP-3.

I am creating an input file with
IN-CLAIM-YR-MTH PIC 9(06).
IN-CLAIM-UID PIC 9(13).

I am trying to do my move from PIC 9(13) to PIC S9(13)V COMP-3.

Since my receiving field has implied decimal point, I was thinking I needed a decimal point on my sending field.

 

[StephenJSpiro]

fIRST, YOU DO not NEED (YOU CANNOT HAVE) a real decimal point in a non-edited numeric field. The period is NOT a numeric chatacter. The period is assumed to be at the end of a numeric field which does not contain a "V".

Please show us your actual W-S and Procedure Division code. The snippets are not enough. I know what you are doing, but I want to show you where your code is wrong.

Stephen J Spiro
Member, ANSI COBOL Standards Committee

 

[RonaldB]

The decimal point in the sending field causes the MOVE to be regarded as alphanumeric, not numeric, which probably causes the receiving field to be filled strangely.
Get the sending field to contain actual numeric data and you'll be fine. --------
Regards,
Ronald.

 

[nxm150]

OK, I wrote a very simple program that will read a input file and write it out in packed format.

Input defined as
01 INFILEREC.
05 IN-CLAIM-YR-MTH PIC 9(06).
05 IN-CLAIM-UID PIC 9(13).
05 FILLER PIC X(77).

Output defined as
01 OUTFILEREC.
05 OUT-CLAIM-YR-MTH PIC S9(9) USAGE COMP.
05 OUT-CLAIM-UID PIC S9(13)V USAGE COMP-3.
05 FILLER PIC X(85).

Procedure division is
0000-MAIN-PROCESSING.
PERFORM 4100-OPEN-FILES.
PERFORM 4300-READ-INPUT
PERFORM 4400-CLOSE-FILES.

4300-READ-INPUT.
READ INFILE
AT END
CONTINUE
NOT AT END
DISPLAY 'READING RECORDS'
MOVE IN-CLAIM-YR-MTH TO OUT-CLAIM-YR-MTH
MOVE IN-CLAIM-UID TO OUT-CLAIM-UID
WRITE OUTFILEREC
END-READ.

INPUT FILE is
1998010010009151857
FFFFFFFFFFFFFFFFFFF
1998010010009151857

OUTPUT FILE is
...`...j.e@
00070109587
03C9000115C

My output is correct except for the @ sign. I need it to cotain a decimal point.

 

[MarcLodge]

nxm150,
Forgive me if you know what I'm about to say, but here goes anyway......

You'll never actually see a decimal point in a COMP-3 field, as it is implied. For instance the value +12345 and +123.45 will both look the same in hex:
00135
0024C

If you wish to see a decimal point in the output file, then the field must be defined as an 'edited' field ie. PIC 999.99

From your example I'm guessing that the reason you are seeing an @ sign is that 7C is the hexadecimal equivalent of an @ sign.

Once again, if you wish to see a decimal point in the output file, you must define an edited field.

Hope this helps
Marc

 

[SteveMillman]

Hey guys, maybe I am bit rusty, but wouldnt the pic 9(13) data need to be moved to a s9(13) comp-3 if he wanted it to remain the same; but packed?

If he wanted two decimal places before in the receiving field, wouldn't he want it to be s9(11)v99.

If he wanted a real decimal place would he want the output to be comp-3?

I guess I am a bit confused by what is being asked. Why would one code the output as s9(13)v ? Would that output to 7 bytes or 8?

I no longer have access to a mainframe; but wonder what is being asked.

Is the question merely about the signage changing with the signed output field?

A confused old mainframer,

Steve

 

[StephenJSpiro]

The "V" is an IMPLIED decimal point. It has no impact on the internal storage.
You can have
O5 FIELD1 PIC S9999 COMP-3.
05 FIELD2 PIC S999V9 COMP-3.
05 FIELD3 PIC S99V99 COMP-3.
05 FIELD4 PIC S9V999 COMP-3.

IF YOU MOVE 1234 TO FIELD1
OR 123.4 TO FIELD2
OR 12.34 TO FIELD3 ....etc
THEY WILL ALL HAVE THE SAME INTERNAL REPRESENTATION!
(01234C)

S9999 is the same as S9999V!

if you move 1234 to FIELD3, it will be 03400C (the high order digits are truncated; there was nothing after the decimal point.)

S9(13)V is 7 bytes; the IMPLIED decimal point never occupies storage.

Stephen J Spiro
ANSI COBOL Standards Committee

 

[SteveMillman]

Steve,

Thanks for the clarification. I have never seen anyone stick a V at the end of a picture clause like that. It threw me.

Take care,

Steve