|
View previous topic :: View next topic
|
| Author |
Message |
job1919
New User
Joined: 19 Jul 2010
Posts: 21
Location: Chennai
|
|
|
|
Hi ,
about the Corresponding Move , does this move happens based on line number as well . For Example
I have 2 files having the same copybook layout
File 1 - cpybk1 (rec len 1200)
File 2 - cpybk2 ( rec len 1300)
I am doing a Corresponding move from file1-rec to file2-rec for a group item A , however in File 1
03 group A ( position starts at 10 )
05 C
05 D
In File 2 ,
same level starts at position 15 ,
03 group B ( position at 15)
05 C1
05 C2
Now When i use Move Corr file-rec1 to file-rec2 , what would be the result.
I wanted to understand the scenarios in which the move happens. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
There is a link to manuals at the top of the page. You would be wise to click on it, find the COBOL Language Reference manual, and read it for awhile so you can answer questions like this yourself without asking a forum. The answer to your question is that nothing you have listed in your post would be moved. The reason is in the rules but I'll let you figure out which rule(s) apply:
| Quote: |
6.1.8.1 CORRESPONDING phrase
The CORRESPONDING (CORR) phrase causes ADD, SUBTRACT, and MOVE operations to be performed on elementary data items of the same name if the alphanumeric group item or national group item to which they belong is specified. A national group is processed as a group item when the CORRESPONDING phrase is used.
Both identifiers that follow the keyword CORRESPONDING must name group items. In this discussion, these identifiers are referred to as identifier-1 and identifier-2. identifier-1 references the sending group item. identifier-2 references the receiving group item.
Two subordinate data items, one from identifier-1 and one from identifier-2, correspond if the following conditions are true:
In an ADD or SUBTRACT statement, both of the data items are elementary numeric data items. Other data items are ignored.
In a MOVE statement, at least one of the data items is an elementary item, and the move is permitted by the move rules.
The two subordinate items have the same name and the same qualifiers up to but not including identifier-1 and identifier-2.
The subordinate items are not identified by the keyword FILLER.
Neither identifier-1 nor identifier-2 is described as a level 66, 77, or 88 item, and neither is described as an index data item. Neither identifier-1 nor identifier-2 can be reference-modified.
Neither identifier-1 nor identifier-2 is described with USAGE POINTER, USAGE FUNCTION-POINTER, USAGE PROCEDURE-POINTER, or USAGE OBJECT REFERENCE.
The subordinate items do not include a REDEFINES, RENAMES, OCCURS, USAGE INDEX, USAGE POINTER, USAGE PROCEDURE-POINTER, USAGE FUNCTION-POINTER, or USAGE OBJECT REFERENCE clause in their descriptions.
However, identifier-1 and identifier-2 themselves can contain or be subordinate to items that contain a REDEFINES or OCCURS clause in their descriptions.
The name of each subordinate data item that satisfies these conditions is unique after application of implicit qualifiers. |
|
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| So easy to test. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
And after you are through testing, remove the "corresponding" from the code. . .
Many organizations will not permit code with a "move corresponding" to be promoted to production. . . |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
MOVE CORR
is a lazy way to code and leads to errors
and as Dick has pointed out, many sites inhibit the use of this form of MOVE.
Moreover,
someone who writes like
| Job1919 wrote: |
For Example
I have 2 files having the same copybook layout
File 1 - cpybk1 (rec len 1200)
File 2 - cpybk2 ( rec len 1300) |
??same copybook layout? cpybk1 and cpybk2, different record lengths?
who obviously does not proof what he/she writes,
is someone who should develop skills set to generate (via Edit Macro)
the appropriate MOVEs instead of relying on MOVE CORR. |
|
| Back to top |
|
|
job1919
New User
Joined: 19 Jul 2010
Posts: 21
Location: Chennai
|
|
|
|
Here`s the reason for posting this .
I have a input file of different rec-len (1240) & the output file rec-len( 1300) . There is a corresponding move for a subordinate data items from file 1- file2 . The problem the output file contains Junk.
However the subordinate data item1 of file1<cpybk1> starts from pos 105 whereas the subordinate data items of file2 < cpybk2> starts from pos 150.
So after running the program , I get junk / bad data in to the output file. I am suspecting the culprit as corresponding move.
I might be wrong , so wanted to take experts opinion on this .
Thanks
job1919 |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
A move corresponding will not generate "junk" values . . .
Either the junk value(s) exist in the input or the output did not receive the value(s) from the input - one of the reasons to not use a corresponding move.
Run a test moving all '9' to the output record before the move corresponding and see if the "junk" is replaced with 9's. If the 9's are in the output, the data was not moved from the input. If the junk is still in the output, the input has junk. |
|
| Back to top |
|
|
job1919
New User
Joined: 19 Jul 2010
Posts: 21
Location: Chennai
|
|
|
|
thanks for the suggestion dick ,
I ll test it now..
thanks
job1919 |
|
| Back to top |
|
|
job1919
New User
Joined: 19 Jul 2010
Posts: 21
Location: Chennai
|
|
|
|
Yeah I got it now!! thanks moderators for the suggestions / help.
The rec len mismatch is the culprit. when i moved 9`s in to o/p file , and dia corresp move , upto position 104 it was fine but after that there is a mismatch in the items and hence bad data..
thanks all.
job1919 |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Good to hear it is working - thank you for letting us know 
d |
|
| Back to top |
|
|
dr_te_z
New User
Joined: 08 Jun 2007
Posts: 71
Location: Zoetermeer, the Netherlands
|
|
|
|
| On the mainframe there is a compile-option to punch the assembler code. Use this to see if the "move corr" behaves like expected. You do not have to be a system-programmer to figure it out. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Why might one want to "punch" the assembler code? Surely a listing would be sufficient. . .
Keeping in mind that "move corresponding" is usually NOT the best choice. . . |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| MOVE CORRESPONDING can have side effects many years down the road when someone changes the data structure for a new (or revised) requirement, and suddenly the program is not working correctly since some of the data is no longer being moved. As Dick said, you are almost always better off NOT using MOVE CORRESPONDING -- and many sites do not permit its use. |
|
| Back to top |
|
|
|
|
