tags:

views:

610

answers:

2

On the rare occasion that people say nice things about cobol, they often mention "copy corresponding" (and "move corresponding").

I'd really like to know more about these -- what are their semantics? Is it the same as:

(Perl)

for my $key (keys %foo) {
 $bar{key} = $foo{key} if exists $bar{key};
}

Or is there something deeper than that? Cobol records are strongly typed, right? How does that work?

+3  A: 

According to the AcuCOBOL docs (which I use):

When the CORRESPONDING phrase is used, selected elementary items in source-group are moved to corresponding items in dest-group. This is treated as a series of Format 1 MOVE statements, one for each corresponding pair of data items.

A Format 1 move looks like the following:

MOVE source-item TO {dest-item}

Given the following file and working storage definition

DATA DIVISION.
FILE SECTION.
FD  PRODUCT-INFO-FILE.
01  PRODUCT-INFO-RECORD.
    03 PI-HOLD-PROD                 PIC  x(12).
    03 PI-HOLD-DESC                 PIC  x(30).
    03 PI-HOLD-DISC                 PIC  9(01).
    03 PI-HOLD-TOTAL                PIC  9(08)V99.

WORKING-STORAGE SECTION.
01  HOLD-FIELDS-DEST.
    03 WS-HOLD-PROD                 PIC  x(12).
    03 WS-HOLD-DESC                 PIC  x(30).
    03 WS-HOLD-DISC                 PIC  9(01).
    03 WS-HOLD-TOTAL                PIC  9(08)V99.

Doing this:

MOVE CORRESPONDING PRODUCT-INFO-RECORD TO HOLD-FIELDS-DEST.

would be the same as doing this:

MOVE PI-HOLD-PROD  TO WS-HOLD-PROD.
MOVE PI-HOLD-DESC  TO WS-HOLD-DESC.
MOVE PI-HOLD-DISC  TO WS-HOLD-DISC.
MOVE PI-HOLD-TOTAL TO WS-HOLD-TOTAL.

That saved 3 lines of code. A lot of files are wider than that.

EDIT: This is also from the same set of docs...

The following table outlines the combinations of source-item and dest-item that are allowed by the MOVE statement. The numbers in the table are the "General Rules" numbers in this section where each combination is described:

Sending Category:   Receiving Item Category:
        Alphabetic Alphanumeric/Alphanumeric Edited Numeric /Numeric Edited
Alphabetic     Yes (12) Yes (13)          No (15)
Alphanumeric     Yes (12) Yes (13)       Yes (14)
Alphanumeric Edited Yes (12) Yes (13)       No (15)
Numeric Integer  No (15)  Yes (13)       Yes (14)
Numeric
Non-integer   No (15)  No (15)        Yes (14)
Numeric Edited   No (15)  Yes (13)       Yes (14)

'12. When dest-item is alphabetic, justification and space filling occur according to the standard alignment rules.

'13. When dest-item is alphanumeric or alphanumeric edited, justification and space filling occur according to the standard alignment rules. If source-item is signed numeric, the operational sign is not moved. If the sign occupies a separate character position, that sign character is not moved, and the size of source-item is treated as being one less.

'14. When dest-item is numeric or numeric edited, decimal point alignment and zero filling occur according to the standard alignment rules. If source-item is unsigned, it is treated as being positive. If dest-item is unsigned, the absolute value of source-item is moved. If dest-item is signed, its sign is set to the sign of source-item. If source-item is numeric edited, it is "de-edited" first such that dest-item receives the same numeric value.

'15. The following moves are illegal: An alphabetic or alphanumeric edited data item may not be moved to a numeric or numeric edited data item. A numeric or numeric edited data item may not be moved to an alphabetic item. A non-integer numeric data item cannot be moved to an alphanumeric or alphanumeric edited data item.

Buggabill
Do the PIC formats have to match up? Or will it coerce?
Sean McMillan
I have added more from the docs. In short they do not always need to match up. There are restrictions. I do believe that the destination item needs to of equal or greater size or a compiler error will occur.
Buggabill
The field names in the source record must be exactly the same for a move corrosponding to work. The above examples would compile but nothing would be moved!
James Anderson
+3  A: 

Actually, the element names have to be exactly the same for 'MOVE CORRESPONDING' to work. The computer I work on uses the short cut of 'MOVE CORR'. I actually saw 'ADD CORR' when I was looking for examples.

DATA DIVISION.
FILE SECTION.
FD  PRODUCT-INFO-FILE.
01  PRODUCT-INFO-RECORD.
    03 PI-HOLD-PROD                 PIC  x(12).
    03 PI-HOLD-DESC                 PIC  x(30).
    03 PI-HOLD-DISC                 PIC  9(01).
    03 PI-HOLD-TOTAL                PIC  9(08)V99.

WORKING-STORAGE SECTION.
01  HOLD-FIELDS-DEST.
    03 PI-HOLD-PROD                 PIC  x(12).
    03 PI-HOLD-DESC                 PIC  x(30).
    03 PI-HOLD-DISC                 PIC  9(01).
    03 PI-HOLD-TOTAL                PIC  9(08)V99.

There can be more than one variable with the same name because the are qualified by the '01' level. To reference one of the two fields, one has to say PI-HOLD-PROD OF HOLD-FIELDS-DEST.

To move all of the values, one would use

MOVE CORRESPONDING PRODUCT-INFO-RECORD TO HOLD-FIELDS-DEST.

This is very useful when moving fields around in a new record or variable.

01 WS-DATE-YMD.
   03  YY             PIC 99.
   03  MM             PIC 99.
   03  DD             PIC 99.

01 WS-DATE-MDY.
   03  MM             PIC 99.
   03  FILLER         PIC X VALUE "/".
   03  DD             PIC 99.
   03  FILLER         PIC X VALUE "/".
   03  YY             PIC 99.


MOVE CORR WS-DATE-YMD TO WS-DATE-MDY.
Cathy Sullivan