Why INITIAILIZE is not that preffered in COBOL.

OS/VS COBOL, COBOL II, Enterprise COBOL for z/OS. OpenCOBOL and OOCobol.
Post Reply
Om Prakash
Registered Member
Posts: 22
Joined: Tue Jul 23, 2013 3:22 pm

Why INITIAILIZE is not that preffered in COBOL.

Post by Om Prakash »

Hi,

Why INITIAILIZE is not that preffered in COBOL. At my shop they usually don't prefer as per good coding practice. What are your thoughts, please share.
William Collins
Global Moderator
Global Moderator
Posts: 490
Joined: Sun Aug 25, 2013 7:24 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by William Collins »

Well, what would you like to use INITIALIZE for, and why?

Is there some more detailed description than "not good coding practice" for the standards are your site?
Om Prakash
Registered Member
Posts: 22
Joined: Tue Jul 23, 2013 3:22 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by Om Prakash »

Per the shop standard they would like uto MOVE SPACES and ZEROS at the 01 level in working storage and keep this "initialized" version aside and use it whenever we need to IINITIALIZE the same 01 level again in the program isntead of using INITIALIZE again and again.
William Collins
Global Moderator
Global Moderator
Posts: 490
Joined: Sun Aug 25, 2013 7:24 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by William Collins »

Mmm... will it take a year to get the next response :-)

Although the performance of INITIALIZE has been improved over the years, and indeed is still being improved it is still slower than the method you have mentioned.

Perhaps more later...
Om Prakash
Registered Member
Posts: 22
Joined: Tue Jul 23, 2013 3:22 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by Om Prakash »

No,I'll try to be fast.

Looks like this site was blocked in our office that's one of the reasons I could not log in here for long.

Thanks for your explnation but why would it be slow, because it is "designed" this way?
nicc
Global Moderator
Global Moderator
Posts: 691
Joined: Wed Apr 23, 2014 8:45 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by nicc »

Just think about it for a moment. INITIALIZE has to determine the type of data it has to move to the variable. MOVE simply has to move what you specify. That is part of the performance hit.
Regards
Nic
William Collins
Global Moderator
Global Moderator
Posts: 490
Joined: Sun Aug 25, 2013 7:24 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by William Collins »

Here are some tables which INITIALIZE may be commonly be used on:

Code: Select all

01  2210M-ACCOUNT-MASTER-RECORD.
    05  2210M-ACCOUNT-NUMBER PIC X(8)
    .... another 43 items like that, including some packed-decimal fields, binary fields.

Code: Select all

01  GRAND-TOTALS.
    an OCCURS with some packed-decimal fields.

Code: Select all

01  GRAND-TOTALS.
    an OCCURS with some packed-decimal fields.

Code: Select all

01  TOTALS-BY-ACCOUNT.
    an OCCURS with some packed-decimal fields.
INITIALIZE seems to have somehow gained the reputation of being "magic". "My program is working, I use INITIALIZE". A lot of processing is just plain wasted on INITIALIZE.

Take the 2210M-ACCOUNT-MASTER-RECORD. People will routinely INITIALIZE an 01-level and then immediately have 43 MOVE statements to put content in each field subordinate to the 01. Which means the entire INITIALIZE was nothing but waste. Even MOVE SPACE or MOVE ZERO to the 01-level is faster, but wasted. INITIALIZE for a simple 01-level is just a waste. Even if one field is missed in the MOVE, it is hard to spot, because it has a "valid" value. It takes fewer than three seconds to check on the compile listing that each field is amended on a record-layout. Why just be sloppy and wasteful and use INITIALIZE all the time for that?

Next we have GRAND-TOTALS. Since this only needs an initial value once, it doesn't much matter how you do it. The most effective way to do it is the VALUE clause (these days it can be on the items with, or subordinate to, and OCCURS, in olden-times, that was not possible). But it doesn't matter how you do it, as it is done once.

Next, GRAND-TOTALS-BY-MONTH. Only going to be initialised 12 times, but I'd do it the way I'd do it for 100,000 times, since it is code that is likely to be copied.

Now, TOTALS-BY-ACCOUNT. That's going to be 100,000 times.

Originally INITIALIZE would work as a loop, the compiler would generate a loop, terminated by the number of the OCCURS, and would do individual moves of the data.

Over the years, INITIALIZE has got faster, but it is nowhere near the most efficient way to do it But INITIALIZE can be part of the most efficient way to do it (when it needs to be done).

Most efficient way is with, at the "start" of a program, storing the table in its initial state (for which INITIALIZE can be used, or VALUE, or pretty much any way, as it will only be done once) and then copying that initial data to a second table. When the point in the program arises to initialise the table, you move that copy (the initialised one) back to the original source.

In olden times, storage available for the WORKING-STORAGE was considerably tighter (one megabyte) so we tended not to duplicate the tables. The "offset-MOVE" is a slightly slower way, faster than INITIALIZE, and requiring no (or not much, depending on implementation) additional storage.

After all that, remember that setting anything to an initial value is a waste of time if it is immediately going to be set to something else without reference to its current content.

A table where data external to the table is simply MOVEd to it does not need to be initialised. A table of counts or cumulative figures does need to be initialised if/when you get a "control break".
William Collins
Global Moderator
Global Moderator
Posts: 490
Joined: Sun Aug 25, 2013 7:24 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by William Collins »

nicc, no. The compiler works it out. Effectively the INIITIALIZE will be one or more MOVE statements, possibly in a loop (depending on the data) and would, in general, perform about the same.

The latest performance improvements to INITIALIZE is to use a literal value to represent the initial value of all the combined fields in the OCCURS and do a single MOVE in a loop. They may soon get on to the "offset-MOVE" for a table (I've suggested it to IBM, but, for some entirely unfathomable reason, the don't take any notice of me...) but it will still be slower than a MOVE of a copy of the initialised table.
Om Prakash
Registered Member
Posts: 22
Joined: Tue Jul 23, 2013 3:22 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by Om Prakash »

William Collins wrote:After all that, remember that setting anything to an initial value is a waste of time if it is immediately going to be set to something else without reference to its current content.
But if something else is not "big enough" to fill the all bytes of the variable, will that still hold true? If the value, say, is 05 some-variable PIC 9(05). The previous vaue moved to it was "02256" while the new value to be moved is "25" - if we don't initialize the variable would not the current value become "02225" instead of "00025"?
William Collins
Global Moderator
Global Moderator
Posts: 490
Joined: Sun Aug 25, 2013 7:24 pm

Re: Why INITIAILIZE is not that preffered in COBOL.

Post by William Collins »

No. Although there are two cases where that could be true, which are down to the programmer to deal with. First, how things normally happen.

Code: Select all

01  an-alphanumeric-field PIC X(5) VALUE "ABCDE".
01  a-numeric-field PIC 9(5) VALUE 12345.

Code: Select all

MOVE "X" TO an-alphanumeric-field
an-alphanumeric-field will contain "X" followed by four spaces. When sending data is is shorter than receiveing data, for a PIC X (or PIC A if you ever see those) the receiving field will be space-padded to the right for the additional bytes.

Code: Select all

MOVE 1 TO a-numeric-field
a-numeric-field will contain 00001. For a numeric, if the data is shorter than the field, the data is right-justified and left-zero-filled.

The two other cases are:

1) when you use STRING, the target field is only changed for the number of bytes of the source field(s) that are transferred on that execution. Generally, if your data will be of variable length, then you MOVE SPACE to the destination field (the INTO on the STRING) first.
2) when you use reference-modification on the receiving field.

Code: Select all

MOVE "ABC" TO target-field ( 3 : 3 )
If target-field originally was "ABCDEFGHIJ" after that MOVE it will be "ABCABCGHIJ".

Code: Select all

MOVE "ABC" TO target-field ( 3 : 6 )
This time, with the target being longer than the source, the result will be "ABCABC___J", padded with space (underscore here) to the length defined in the reference-modification.

Code: Select all

MOVE "ABC" TO target-field ( 3 : )
This time the remaining length of the field being reference-modified is used, so the result will be "ABCABC____".
Post Reply

Create an account or sign in to join the discussion

You need to be a member in order to post a reply

Create an account

Not a member? register to join our community
Members can start their own topics & subscribe to topics
It’s free and only takes a minute

Register

Sign in

Return to “IBM COBOL, GnuCOBOL (OpenCOBOL), OOCobol.”