KR edition 189 - 190

KR-189* (MOVE CORRESPONDING)

Hi everyone,

We'll take a look at something that is not really used much in COBOL codes these days (but is quite often asked in puzzles and exams)..."move corresponding":

What is Move corresponding?

• General misconception is that "move corresponding" will simply move the elements of a group variable to another group variable blindly based on the position of the elements. But this move is actually a normal group move and not move corresponding.

• Move corresponding is used to move one group variable to another group variable but the difference from a simple move is that this will move elements of the group variable based on their names - it will not do a blind move based on positions.

For example:
01 WS-GRP-01.
05 WS-GRP1-EMP PIC X(5) VALUE 'FIRST'.
05 WS-GRP1-NUM PIC 9(5) VALUE 11111.
05 WS-GRP1-NUM2 PIC 9(5) VALUE 11111.
05 WS-GRP1-NUM3 PIC 9(5) VALUE 11111.

01 WS-GRP-02.
05 WS-GRP2-NUM PIC 9(5) VALUE 22222.
05 WS-GRP1-EMP PIC X(7) VALUE 'SECODEN'.
05 WS-GRP1-EMP2 PIC X(9) VALUE 'SECODEN'.

MOVE CORRESPONDING WS-GRP-01 TO WS-GRP-02

The contents of the two variables after the statement will be:

WS-GRP-01 :FIRST111113333355555
WS-GRP-02 :22222FIRST SECODEN

Note: Even though WS-GRP1-EMP in both group variables has different formats the move statement is still accepted since we are only moving from a character string to another character string.

That's all for this edition...Suggestions and KR's welcome;
Have you wondered: "Can we redefine a smaller item by a larger item and vice versa?"

KR-190* (Redefining smaller by larger?)

Hi everyone,
There is a frequent doubt which arises when we talk of redefines in COBOL - can we redefine a smaller area by a larger area? And the normal answer that pops up in mind is "No. It is not possible".

• Our reasoning goes as follows: "A larger area can be redefined by a smaller item - it's just that the extra space of the larger item will not be used by the smaller one. So when a smaller size is redefined by a larger one the original item is small; so how can a larger area occupy that? Where will the extra bytes of the larger item go?" This reasoning is incorrect.

• Actually it doesn't make any difference whether we do a larger redefining a smaller or vice versa.

• It is all done at compile time - so the compiler is perfectly aware of the sizes of the 2 items and accordingly takes care.

• So when redefining a smaller item by a larger one, the compiler will allocate memory space for the item which occupies more memory space.

• Basically on encountering a redefine, the compiler will place both variables as starting from the same memory address.

CODE SNIPPET:

01 WS-LARGER-ORG.
05 WS-LARGE-ORG-NUM1 PIC 9(4) VALUE 1111.
05 WS-LARGE-ORG-NUM2 PIC 9(5) VALUE 22222.
01 WS-SMALLER-R REDEFINES WS-LARGER-ORG PIC X(5).

01 WS-SMALLER-ORG.
05 WS-SMALL-ORG-NUM1 PIC 9(3) VALUE 777.
05 WS-SMALL-ORG-NUM2 PIC 9(2) VALUE 66.
01 WS-LARGER-R REDEFINES WS-SMALLER-ORG PIC X(8).

MOVE '99998888' TO WS-LARGER-R

RESULT (giving displays before the move and after):

LARGER-ORG : 111122222X
SMALLER-R : 11112X
SMALLER-ORG: 77766X
LARGER-R : 77766 X

AFTER MOVING 99998888 TO WS-LARGER-R

SMALLER-ORG: 99998X
LARGER-R : 99998888X

Note: X character above is just used to denote the end of the display statement.

Announcement: From next edition onwards Sachin Sebastian would be anchoring the KR series.

Go back to the main contents page