The MOVE statement transfers data from one area of storage to one or more other areas.
Format 1: MOVE statement .--------------. V | >>-MOVE--+-identifier-1-+--TO----identifier-2-+---------------->< '-literal-1----'
Format 2: MOVE statement with CORRESPONDING phrase >>-MOVE--+-CORRESPONDING-+--identifier-1--TO--identifier-2----->< '-CORR----------'
CORR is an abbreviation for, and is equivalent to, CORRESPONDING.
When format 1 is specified:
When format 2 is specified:
Data items described with the following types of usage cannot be specified in a MOVE statement:
A data item defined with a usage of INDEX, POINTER, FUNCTION-POINTER, PROCEDURE-POINTER, or OBJECT REFERENCE can be part of an alphanumeric group item that is referenced in a MOVE CORRESPONDING statement; however, no movement of data from those data items takes place.
The evaluation of the length of the sending or receiving area can be affected by the DEPENDING ON phrase of the OCCURS clause (see OCCURS clause).
If the sending field (identifier-1) is reference-modified or subscripted, or is an alphanumeric or national function-identifier, the reference-modifier, subscript, or function is evaluated only once, immediately before data is moved to the first of the receiving operands.
Any length evaluation, subscripting, or reference-modification associated with a receiving field (identifier-2) is evaluated immediately before the data is moved into that receiving field.
For example, the result of the statement:
MOVE A(B) TO B, C(B).
is equivalent to:
MOVE A(B) TO TEMP. MOVE TEMP TO B. MOVE TEMP TO C(B).
where TEMP is defined as an intermediate result item. The subscript B has changed in value between the time that the first move took place and the time that the final move to C(B) is executed.
For further information about intermediate results, see Intermediate results and arithmetic precision in the Enterprise COBOL Programming Guide.
After execution of a MOVE statement, the sending fields contain the same data as before execution.
Usage note: Overlapping operands in a MOVE statement can cause unpredictable results.
An elementary move is one in which the receiving item is an elementary data item and the sending item is an elementary data item or a literal.
Valid operands belong to one of the following categories:
Any necessary conversion of data from one form of internal representation to another takes place during the move, along with any specified editing in, or de-editing implied by, the receiving item. The code page used for conversion to or from alphanumeric characters is the one in effect for the CODEPAGE compiler option when the source code was compiled.
The following rules outline the execution of valid elementary moves. When the receiving field is:
Alphabetic:
Alphanumeric or alphanumeric-edited:
DBCS:
External floating-point:
Internal floating-point:
National or national-edited:
Numeric or numeric-edited:
Usage notes:
The following table shows valid and invalid elementary moves for each category. In the table:
Alpha- betic | Alpha- numeric | Alpha- numeric edited | Numeric | Numeric- edited | External floating- point | Internal floating- point | DBCS1 | National, national- edited | |
---|---|---|---|---|---|---|---|---|---|
Alphabetic and SPACE sending item | Yes | Yes | Yes | No | No | No | No | No | Yes |
Alphanumeric sending item2 | Yes | Yes | Yes | Yes3 | Yes3 | Yes8 | Yes8 | No | Yes |
Alphanumeric-edited sending item | Yes | Yes | Yes | No | No | No | No | No | Yes |
Numeric integer and ZERO sending item4 | No | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
Numeric noninteger sending item5 | No | No | No | Yes | Yes | Yes | Yes | No | No |
Numeric-edited sending item | No | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes |
Floating-point sending item6 | No | No | No | Yes | Yes | Yes | Yes | No | No |
DBCS sending item7 | No | No | No | No | No | No | No | Yes | Yes |
National sending item9 | No | No | No | Yes | Yes | Yes | Yes | No | Yes |
National-edited sending item | No | No | No | No | No | No | No | No | Yes |
|
If the sending item is specified as a year-last date field, then all receiving fields must also be year-last date fields with the same date format as the sending item. If a year-last date field is specified as a receiving item, then the sending item must be either a nondate or a year-last date field with the same date format as the receiving item. In both cases, the move is then performed as if all items were nondates.
Table 2 describes the behavior of moves involving non-year-last date fields. If the sending item is a date field, then the receiving item must be a compatible date field. If the sending and receiving items are both date fields, then they must be compatible; that is, they must have the same date format, except for the year part, which can be windowed or expanded.
This table uses the following terms to describe the moves:
Nondate receiving item | Windowed date field receiving item | Expanded date field receiving item | |
Nondate sending item | Normal | Normal | Normal |
Windowed date field sending item | Invalid | Normal | Expanded |
Expanded date field sending item | Invalid | Normal1 | Normal |
|
The successful execution of an OPEN statement for a given file makes the record area for that file available. You can move data to or from the record description entries associated with a file only when the file is in the open status. Execution of an implicit or explicit CLOSE statement removes a file from open status and makes the record area unavailable.
A group move is any move in which an alphanumeric group item is a sending item or a receiving item, or both. The following are group moves:
A group move is treated as though it were an alphanumeric-to-alphanumeric elementary move, except that there is no conversion of data from one form of internal representation to another. In a group move, the receiving area is filled without consideration for the individual elementary items contained within either the sending area or the receiving area, except as noted in the OCCURS clause. (See OCCURS clause.)