How to move a 9(11) variable to 9(9)v99.

balasu · New User Joined: 10 Jul 2008 Posts: 23 Location: bangalore

Hi,
I had a requirement of moving a value from the input file to a amount field. Pleas help me out on this.
ex., Input value:
112345678911 - input value
I want to move this i/p value to a amount field of 9(9)v99, since the value from input file is a amount value. When i try to move this value to a variable of 9(9)v99, Last two digit is truncated and getting as 234567891100 as the output. Please help me out on this.
Thanks,
bala.M

Robert Sample · Posted: Sat Jan 31, 2009 8:14 pm

Use REDEFINES to convert the 9(9)V99 to 9(11) and move to the 9(11) field. Then the 9(9)V99 will contain the correct value.

Or, COMPUTE 9(9)V99 = 9(11) / 100.

TIMTOWTDI

balasu · New User Joined: 10 Jul 2008 Posts: 23 Location: bangalore

See the input is of 99999999999 and i need to make it as 999999999.99.

balasu · New User Joined: 10 Jul 2008 Posts: 23 Location: bangalore

FYI:

VALUE BEF MOVE 00000050979
after move: AMOUNT: 000050979.00
I am getting like this. Please advise robert..

Robert Sample · Posted: Sat Jan 31, 2009 8:57 pm

Have you bothered trying either of the methods I posted? What were your results?

balasu · New User Joined: 10 Jul 2008 Posts: 23 Location: bangalore

Robert you asked me to convert 9(9)v99 to 9(11). but mine is opposite.
How to conver 9(11) to 9(09)v99, without lost of data.or with out any truncation happens??please advise.

Robert Sample · Posted: Sat Jan 31, 2009 9:10 pm

COMPUTE 9(09)V99 = 9(11) / 100 takes an 11-byte field and divides it by 100 giving 9 digits before the decimal point and 2 digits after the decimal point. The REDEFINES allows you to exactly the same thing in a different way. Your original problem statement is to take an 11-byte number and change it to 9(9)V99 without losing the decimal digits.

Perhaps before you criticize a solution you haven't tested yet, you should either try it or figure out what it does first.

dick scherrer · Posted: Sat Jan 31, 2009 11:16 pm

Hello,

If you don't yet have this working, try this:

balasu · New User Joined: 10 Jul 2008 Posts: 23 Location: bangalore

Hi robert & Dick,
I got it.
Many a Thanks,

Thanks,
Bala.M

abin · Active User Joined: 14 Aug 2006 Posts: 198

I have a question.

112345678911 - input value
When moving i/p value to a amount field of 9(9)v99 why is it coming as 234567891100 as the output.

Robert Sample · Posted: Sun Feb 01, 2009 1:12 am

Because COBOL aligns to the decimal point. PIC 9(11) is implied PIC 9(11)V so the decimal points are aligned and digits before the decimal are moved, truncating the first two digits. The digits after the decimal point are filled with zero since they don't exist on the sending field.

Shashank.kapoor · New User Joined: 14 Jan 2009 Posts: 24 Location: Mumbai

Hi,

In addition to the Robert post, numeric variable has Right to left movement.
Therefore, PIC 9(11) will try to move 11 bytes in 9 bytes of output field.
First 2 bytes of input field will truncate.
'V' in PIC clause implies the inclusive of decimal point.
To see the decimal point in output you need to use Editing picture clause.

Thanks & Regards,
Shashank

Robert Sample · Posted: Mon Feb 02, 2009 6:15 pm

Shashank: have you any proof for your statement of

Shashank.kapoor · New User Joined: 14 Jan 2009 Posts: 24 Location: Mumbai

Hi Robert,

[quote="Robert Sample"]Shashank: have you any proof for your statement of [quote]

Please find below the test run details to support my statement.

Robert Sample · Posted: Mon Feb 02, 2009 7:26 pm

Sorry, all you've shown is lack of understanding of how COBOL works. If you use the LIST compile option and review the generated code for each of your MOVE statements you will find that Assembler MVC instructions are used. MVC is a left to right instruction. You will see that the generated MVC instructions use different starting position because COBOL aligns to the decimal and generates the MVC based on how many bytes to move; it does not start at the decimal point and move bytes right to left.

Shashank.kapoor · New User Joined: 14 Jan 2009 Posts: 24 Location: Mumbai

Hi Robert,

Definitely I am unaware of the assembler instructions that how exactly it works.
My post was on the output basis.

Request you to share some more points on this MVC instructions i.e.
1) On what basis cobol decides that from where it needs to truncate the data i.e. either from Right or Left?
2) As we can see in output if the input is more than the output in numeric field then data gets truncated from left. Similarly in case of decimal part data gets truncated from Right.

Thanks for bringing this in notice.

-------------
Shashank

Robert Sample · Posted: Mon Feb 02, 2009 9:11 pm

1) COBOL aligns to the decimal -- wherever the V (or .) is (and there is always a V since it is implied after the rightmost digit if not otherwise specified). Once that is done, COBOL will truncate or pad with zeros left or right depending on the picture clauses of the sending and receiving fields. Truncation or padding will not occur if the field components are the same size (number of digits).
2) There are four possibilities:
- If the sending field integer part (before the V) is larger than the receiving field integer part, the extra digits are truncated off the left.
- If the sending field integer part is smaller than the receiving field integer part, there are zeroes padded on the front of the receiving field
- If the sending field decimal part (after the V) is larger than the receiving field decimal part, the extra digits are truncated off the right
- If the sending field decimal part is smaller than the receiving field decimal part, there are zeros padded on the end of the receiving field.

Be aware the rules are slightly different for numeric edited fields (which has PIC clauses including -, +, Z, etc).

dick scherrer · Posted: Tue Feb 03, 2009 12:46 am

Hello,

Anuj Dhawan · Posted: Tue Feb 03, 2009 10:12 am

Hello,

Shashank.kapoor · New User Joined: 14 Jan 2009 Posts: 24 Location: Mumbai

Thanks Robert!!

-------------
Shashank

Debabrata Pruseth · Posted: Wed Feb 04, 2009 11:26 am

Hi Robert

I am afraid my understanding is similar to Shashkant . Alphanumeric values are left justified and numeric values are right justified till the decimal point and after the decimal point left justified. So when the movement happens from one variable to another the movement starts from that justified direction to the opposite ie right to left ; or left to right accordingly. This is however in literal sense.

I think MVC may be generating instruction for left to right movement in general however there might be some other internal final adjustment must be happening to give the final output that we have been discussing.

dick scherrer · Posted: Wed Feb 04, 2009 11:40 am

Hello,

Robert Sample · Posted: Wed Feb 04, 2009 6:02 pm

Debabrata: as Dick said, your understanding is faulty. Some specifics from your post: there is LEFT justification (usual alphanumeric variables), RIGHT justification (alphanumeric variables with JUST RIGHT), and numeric justification -- which is neither left nor right but DECIMAL aligned. For numeric fields, the COBOL compiler determines how many bytes to move to the receiving field, and the conversion (if any is required), and generates pseudo assembler to move the bytes correctly If you move a PIC 9(7) to a PIC 9(3) field, COBOL generates a 3-byte move -- the last 3 bytes of the sending field are moved to the receiving field via an MVC (left to right move) instruction. What about the first 4 bytes? Not touched, not moved, not even considered for a move. Literally, there is no right to left move instruction. From the COBOL Language Reference manual, note that the manual on numeric data moves does not talk about left or right justification but decimal alignment:

Debabrata Pruseth · Posted: Wed Feb 04, 2009 6:06 pm

Thanks a lot Robert and Dick for the information . This explains everything.

Anuj Dhawan · Posted: Wed Feb 04, 2009 6:33 pm

These guys (and many more here in this forum) seem to be "walking Encyclopedia"..

Regards,
Ad