move corresponding in cobol

dipti85 · New User Joined: 11 Jun 2009 Posts: 6 Location: chennai

01 a.
02 b pic 9(2).

01 a1.
02 b pic A(2).

move corresponding a to a1 what will be the output?

o1 c.
02 b pic x(2).

01 c1.
02 b pic 9(2).

move corresponding c to c1 what will be output? is it give any error...

I'll try myself but i don't have mainframe.............

so i just want to clear my confustion............

Bill O'Boyle · Posted: Sat Jun 20, 2009 2:06 am

You may have an issue when you MOVE CORRESPONDING C to C1 because when a PIC 9 Display-Numeric field is populated, COBOL ensures that the last byte has a Zone-Nibble of 'F', but the Numeric-Nibble remains untouched.

So, let's say field B of group C is equal to "1D". After the move, field B of group C1 will equal 14 (X'F1F4'). The 'D' (X'C4') has it's Zone-Nibble "OR'd" with B'1111' to ensure it's a 4-Bit 'F'.

However, (although I'm not an advocate), if you move field B of group C to field B of group C1 using reference modification, you'll retain the value of "1D", but this could be misconstrued as a Display-Numeric negative 14. If the field gets packed, it will pack as a Packed-Decimal negative 14 and if it then gets converted to binary, it will equal X'FFFFFFF2' as a fullword-value (a negative binary 14).

I'm not a big fan of MOVE CORRESPONDING as it has its definite pitfalls....

Regards,

Robert Sample · Posted: Sat Jun 20, 2009 3:24 am

MOVE CORRESPONDING A TO A1 won't move anything since the MOVE rules prohibit moving a 9 field to an A field (and vice versa).

MOVE CORRESPONDING C TO C1 will move variable B but as Bill said you may get side effects. Also, you may get a S0C7 abend upon attempting to do arithmetic with B OF C1 unless B OF C contains two numeric characters when the MOVE is done.

If you haven't done so, click on the Manuals link at the top of the page and read up on CORRESPONDING and MOVE in the COBOL Language Reference -- there's a lot of good information in there.

Terry Heinze · Posted: Sun Jun 21, 2009 6:54 am

I would normally try to stay away from the CORR option of the MOVE statement except in the case of reformatting a date as in:

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

I read somewhere that a MOVE CORR is perfectly efficient, in that it generates the same Assembler code as the individual MOVEs.

I guess that a corollary to the above, is that all the rules and caveats for individual MOVEs also apply.

Terry Heinze · Posted: Tue Jun 23, 2009 6:25 am

I don't think it's a question of inefficiency; it's maintainability. Adding an additional elementary field to, or removing a field from, either of the group names, could cause unexpected results. In addition, as I mentioned, referring to any of the elementary fields requires qualification.

Robert Sample · Posted: Tue Jun 23, 2009 7:15 am

There's definitely problems maintaining code with CORRESPONDING. Just using a REDEFINE can cause moves that were working fine to stop working -- and since the CORRESPONDING can be quite a distance away from the data definition, these types of errors are a real pain to find and fix. Exhaustive testing can help find them before moving into production, but how many "quick fixes" go through the full exhaustive testing suite again?

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

dbzTHEdinosauer · Posted: Wed Jun 24, 2009 5:49 am

COBOL is a high-level language:

MOVE CORR
INITIALIZE
READ
WRITE
UPDATE

Alot of the assembler generated for these instructions.

I have heard that the INITIALIZE is not effecient,
but it does populate each field according to data type.

Those of us who learned computer programming via assembler appreciate
the 'power' (automatic code layed for you) of COBOL instructions.

But I am off subject and certainly do not want to be considered an advocate of MOVE CORR.