Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

move corresponding in cobol

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> Mainframe Interview Questions
View previous topic :: :: View next topic  
Author Message
dipti85
Currently Banned

New User


Joined: 11 Jun 2009
Posts: 6
Location: chennai

PostPosted: Sat Jun 20, 2009 1:40 am    Post subject: move corresponding in cobol
Reply with quote

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............
Back to top
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sat Jun 20, 2009 2:06 am    Post subject: Reply to: move corresponding in cobol
Reply with quote

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,
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7931
Location: Bellevue, IA

PostPosted: Sat Jun 20, 2009 3:24 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1239
Location: Richfield, MN, USA

PostPosted: Sun Jun 21, 2009 6:54 am    Post subject:
Reply with quote

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:
Code:
01.
    05  WS-DATE-CCYYMMDD.
        10  WS-DATE-CCYY  PIC  9(4).
        10  WS-DATE-MM    PIC  99.
        10  WS-DATE-DD    PIC  99.
    05  WS-DATE-MM-DD-CCYY.
        10  WS-DATE-MM    PIC  99.
        10                PIC  X  VALUE '/'.
        10  WS-DATE-DD    PIC  99.
        10                PIC  X  VALUE '/'.
        10  WS-DATE-CCYY  PIC  9(4).
.
.
.
    MOVE CORRESPONDING WS-DATE-CCYYMMDD TO WS-DATE-MM-DD-CCYY.
Once the MOVE is done though, the elementary names have to be qualified because of the duplicate definitions, so there is a tradeoff that has to be considered.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Tue Jun 23, 2009 6:10 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1239
Location: Richfield, MN, USA

PostPosted: Tue Jun 23, 2009 6:25 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7931
Location: Bellevue, IA

PostPosted: Tue Jun 23, 2009 7:15 am    Post subject:
Reply with quote

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?
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Wed Jun 24, 2009 4:02 am    Post subject:
Reply with quote

Quote:
I don't think it's a question of inefficiency;

Neither do I, Terry. I just find it interesting that there's NO o'head involved (how often does IBM do something like that?) and it served as a convenient intro for my 2nd point.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Jun 24, 2009 5:49 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> Mainframe Interview Questions All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Executing OO COBOL program invoking J... Virendra Shambharkar COBOL Programming 2 Tue Jan 10, 2017 6:37 pm
No new posts OO COBOL compile error Virendra Shambharkar COBOL Programming 3 Tue Jan 10, 2017 6:05 pm
No new posts Need Suggestion on COBOL program vickey_dw COBOL Programming 5 Thu Jan 05, 2017 10:55 pm
This topic is locked: you cannot edit posts or make replies. How to move a long alphanumeric data ... lind sh COBOL Programming 8 Mon Dec 05, 2016 7:51 pm
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us