Putting data in it’s place

MOVE is the most widely used verb in COBOL.  This verb is used to copy data from one place to another, but it also leaves the data in the initial location.  Perhaps a better name for this verb would have been COPY or DUPLICATE, but those names may have also been inappropriate, since MOVE sometimes alters the data to make it fit into its new home.

You can MOVE one field at a time, or you can MOVE an entire record.  You can also use the MOVE verb to change the format of data, or to rearrange the order of the fields in a record.  So, can you move any piece of data to any location?   No indeed.   These are the limitations of the MOVE verb that I’ve encountered:

1. You can’t MOVE a text field to a numeric field or a numeric-edited field
2. You can’t MOVE a numeric literal, a numeric field, or a numeric edited field to an alphabetic field
3. You can’t MOVE a numeric-edited field to a numeric or numeric-edited field.

Some compilers may be more forgiving and allow you to make these types of moves, but they definitely make my compiler complain.  I would suggest that you type the MOVE statement into your program, and then compile the program.   The compiler will quickly alert you to any illegal MOVES in your program.

Now let’s take a look at a simple program using the MOVE verb:

This program declares four simple numeric fields and then MOVES data to each of these fields.  Execution of this program will generate this output:

NUM-FIELD1 = 42 NUM-FIELD2 = 42 NUM-FIELD3 = 0000 NUM-FIELD4 = 0042

Notice that the picture clause for NUM-FIELD1 and NUM-FIELD2 declares these two variables as two numeric digits, and NUM-FIELD3 and NUM-FIELD4 as four numeric digits, which is reflected in our output when we run the program.

When you need to MOVE data from one location to another, you must be aware of three basic types of fields: non-numeric, numeric, and edited.  The simplest MOVE involves non-numeric data, since you can MOVE any text literal to a non-numeric variable, or move the contents of one non-numeric variable to another.  The only snag to this type of MOVE is the field lengths.  Be aware that if you move a non-numeric literal or variable to a field that is shorter in length, COBOL will simply truncate the data without complaining, and the result may be less than desirable.

So the output of this program will be:

LONG-FIELD = GONE WITH THE WIND

SHORT-FIELD = GONE WITH

Notice that we’ve lost the last 10 characters of the string since SHORT-FIELD is defined as being only 10 characters in length.   While the data isn’t “gone with the wind”, its certainly “gone with the move”.  This one will get you every time.

Let’s see what happens when we move a numeric field to another numeric field that is shorter in length:

The output of this program will be:

BIG-NUMBER = 12345.6789

LITTLE-NUMBER = 345.67

Well, that’s not what we wanted!  Notice that COBOL deletes the digits farthest from the decimal point on both the left and right sides to make it fit into its new home.   You must always be aware of your field sizes, and make them big enough to hold the entire value.  Is your program calculating a total value by adding several numbers together?   Make sure the field holding your total is big enough!   Check this out:

The output of this program will be:

GRAND-TOTAL = 037.01

You don’t have to be a math major to see that this result is incorrect.   The correct grand total is 1037.01, but, because our GRAND-TOTAL field is defined as the same size as our SUB-TOTAL field, the result is incorrect.    Once again. COBOL truncated the digit furthest from the decimal point.

The MOVE verb can also be used to  move entire records.

Notice that both INPUT-RECORD and OUTPUT-RECORD are defined as 50 characters in length, making the two records identical once the MOVE of the record is performed.  Also notice that I moved spaces to INPUT-RECORD before the READ of the INPUT-FILE.   This is important when reading a line sequential file, as COBOL tends to leave remnants of the previous record with each read.  Moving spaces to the input record before the read is done eliminates this problem.  Also notice the I moved spaces to the output record before I moved the input record to the output record for the same reason.  Its always advisable to clear the output record before moving data to it.  This can also be done using the INITIALIZE verb as shown below.

The INITIALIZE verb will move zeroes to all numeric fields, and spaces to all text fields, in one easy step.

Another nifty aspect of the MOVE verb is done with MOVE CORRESPONDING.  It works like this:

The result of this single MOVE CORRESPONDING statement will be exactly the same as if you had performed all of these MOVE statements:

As you can see, the MOVE CORRESPONDING statement can save you lots of time and keystrokes.