Whether my MOVE CORRESPONDING will work or not

daves · New User Joined: 30 Mar 2007 Posts: 7 Location: Bangalore

Hi ,

I just want to know whether my MOVE CORRESPONDING will work or not?If NO then why???

superk · Posted: Wed May 16, 2007 10:39 pm

What happened when you tested your code?

William Thompson · Posted: Wed May 16, 2007 10:53 pm

Off hand I'd say no......
Though a little redefinition could get it to work.

"The two subordinate items have the same name and the same qualifiers up to but not including identifier-1 and identifier-2."

daves · New User Joined: 30 Mar 2007 Posts: 7 Location: Bangalore

Hi,

I haven't tested this yet though i doubt it will work

TG Murphy · Posted: Thu May 17, 2007 12:46 am

daves,

These are the types of things that you should try yourself. Write a small program that does it. If you get into that habit of doing this you will never forget.

By the way, MOVE CORRESPONDING is considered a bad practice. We have many millions of lines of COBOL here and I have yet to see it used.

dick scherrer · Posted: Thu May 17, 2007 12:57 am

Hello,

As has already been posted, a very good practice is to have a "little bit of test code" that is used for this kind of testing. Not an application program, but something you can experiment with. If you run your test and then try variations, you can learn much.

As far as this

daves · New User Joined: 30 Mar 2007 Posts: 7 Location: Bangalore

Hi.

i got it tested with minor redefinition and it's now working.

Thanks all for your advices

William Thompson · Posted: Thu May 17, 2007 2:12 am

TG Murphy · Posted: Wed May 23, 2007 7:47 pm

Daves,

Several of us have cautioned you that MOVE CORRESPONDING is considered bad practice. We could explain to you why this is so but I notice you didn't ask.

Does your shop conduct code walkthroughs? If not, then no need to worry about any of this.

William Thompson · Posted: Wed May 23, 2007 8:16 pm

shane · Posted: Wed May 23, 2007 8:22 pm

Hi,

I also want to know why using MOVE CORRESPONDING is considered a bad practice.
Can you plzz explain it for us???

TG Murphy · Posted: Thu May 24, 2007 6:18 pm

1. Readability.

2. Impact Analysis.

Example: Find out which programs use the variable PENSION-AMT. To do this you search your source code. You can imagine how the use of MOVE CORRESPONDING will cause you to miss references to PENSION-AMT.

3. Error Diagnosis

Your MOVE CORRESPONDING statement abends on a data exception. Which MOVE caused the abend? Might be hard to say.

Bottom Line: MOVE CORRESPONDING = small convenience at big cost

William Thompson · Posted: Thu May 24, 2007 8:52 pm

Phrzby Phil · Posted: Fri May 25, 2007 6:01 pm

I used MOVE CORRESPONDING very nicely (in a one-time program) to convert records with lots of packed-dec fields to display. By duplicating the record layouts and changing the target PIC's, MOVE CORRESPONDING was a good solution.

BUT - it does not handle tables, so I still had to code loops for the OCCUR's in the record.

TG Murphy · Posted: Fri May 25, 2007 7:29 pm

William,

1. Yes - a single line might be "easy" to read but what does it mean? It is the meaning behind the line that is hard to read.

2. Group moves. Good point. Impossible to avoid using group moves. I guess we could add REDEFINED fields to this list as well. However, this does not change the fact that MOVE CORRESPONDING is NOT good for impact analysis. It's bad bad bad...

3. I have no "real life" experience debugging MOVE CORRESPONDING so I can't really say how much weight to give this risk. I don't think it is a big deal.

Do a google search on "cobol programming standards" and you will see a clear consensus against using MOVE CORRESPONDING. I'm not making this stuff up guys. I understand that you may be comfortable using it but eventually most of the code you write will be passed on to others.

The existence of MOVE CORRESPONDING in your program will trigger closer scrutiny during code walkthroughs. For example, whenever we see commented code (without comments explaining why it was commented) in brand new programs, the alarm bells go off.

Once the alarm bells go off we scrutinize these program to death. MOVE CORRESPONDING is another one of the those things that triggers the alarm bells.

Anyways guys - my intention isn't to get into a pissing match but rather encourage daves to be more curious about what he does.

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

Move corresponding has gotten a bad wrap like go to. Go to exit is desirable as is move corresponding at the 01 level. As for impact analysis goes, your impact analysis tool should use the field name to get the 01 level and then go from there. If you're missing impacts due to move corresponding, it's because you're impact analysis methodology needs work IMO.

I can't count the bugs I've seen caused from banning move corresponding. This is especially common in cases with long record descriptions of several hundreds of fields. The issue it's too easy to miss a field in this cases.

Here is a link that talks a bit about some of the 'standards' in use in some shops that don't make sense anymore(if they ever did).

www.idinews.com/cobolStds.html

I would limit the use however to 01 levels. Using it with reckless abandon is ill advised.