IBM Mainframe Forum

BillyBoyo:
The table has 14 fields, with a total 142 bytes and occurs 4000.
Here are the compiler options:
PP 5655-G53 IBM Enterprise COBOL for z/OS 3.4.1 Da
Invocation parameters:
,NOTEST,LIB,LIST,SOURCE,OPTIMIZE,DATA(31),DYNAM,RENT,OBJECT,APOST,MAP,XREF
Options in effect:
NOADATA ADV APOST ARITH(COMPAT) NOAWO BUFSIZE(4096) NOCICS CODEPAGE(1140) NOCOMPILE(S) NOCURRENCY
DATA(31) NODATEPROC DBCS NODECK NODIAGTRUNC NODLL NODUMP DYNAM NOEXIT NOEXPORTALL NOFASTSRT
FLAG(I,I) NOFLAGSTD INTDATE(ANSI) LANGUAGE(EN) LIB LINECOUNT(60) LIST MAP NOMDECK NONAME NSYMBOL(NATIONAL)
NONUMBER NUMPROC(NOPFD) OBJECT NOOFFSET OPTIMIZE(STD) OUTDD(SYSOUT) PGMNAME(COMPAT) RENT RMODE(AUTO)
SEQUENCE SIZE(MAX) SOURCE SPACE(1) NOSQL SQLCCSID NOSSRANGE NOTERM NOTEST NOTHREAD TRUNC(STD) NOVBREF
NOWORD XREF(FULL) YEARWINDOW(1900) ZWB
Thanks a lot for all your effort in help me!

Hello,

FWIW, my suggestion would have Neither intitalize statements Nor any moving to the array fields - only the entire array.

Why is there an INITIALIZE in the called module?

Dick:
The routine access to same DB2 tables and fill the array with the results. Then process this data against another and return the results to the main pgm.
If we don´t initialize this array, we're not going to be sure about the data procesed and retrieved.
Thanks!

Hello,

Of course the table/Array has to be refreshed for each call. But NOT using initialize . . .

You have completely misunderstood what i suggested you do . . . .

In the calling program, define this as 2 complete arrays. One that will be initialized at the start of the calling module. The other will only have data MOVEd to it immediately before the call (from the one initialized array). Each time thru there will only be one (1) move. Which will basically eliminate the cpu for this. In the called module the actual work will be done to load the array from the databasae.

I think the million times is just to compare methods. IF X initialiasations take place, is it better to do method A or method B.

Yes, with the correct table size, I'm getting the single MOVE going significantly slower than the INITIALIZE (but I've only defined two fields for the INITIALIZE).

This is using an MVCL which is "interruptible". The "offset move" goes even worse, resorting to a run-time routine to do the MOVE. I'll have to look into it more when I can.

On the one hand, your 1m INITIALIZEs don't use much CPU. How many are you doing to cause a problem with CPU time?

On the other hand, if the table is just receiving data, rather than having amounts accumulated, you won't actually need INITIALIZE (or anything else) at all. You need to use your index/subscript to make sure you don't look at anything not "current", but you need to do that anyway.

Hello,

This is using an MVCL which is "interruptible". The "offset move" goes even worse, resorting to a run-time routine to do the MOVE. I'll have to look into it more when I can.

Just because the long move is interruptable, i don't believe this would change the cpu time?

On the one hand, your 1m INITIALIZEs don't use much CPU. How many are you doing to cause a problem with CPU time?

The last time i did any timing tests on things like this was quite some time ago. IIRC, the INITIALIZE generated a move for each receiving field (with whatever compiler was used then). The long move was just a single move (again, iirc). The long move blew the doors off any other way we tried - especially if much to be initialized was numeric.

Maybe things have changed.

Time permitting, i'll try to run a couple of tests over the weekend. Looks to be a bit hectic, but Hey, this is for fun

I remembered reading this:

From IBM Enterprise COBOL Version 3 Release 1 Performance Tuning, 2002

VS COBOL II Release 3.1 provides improved performance over VS COBOL II Release 3.0 for:
INITIALIZE (for tables with many subordinate items)
INSPECT, STRING, and UNSTRING (some additional cases are done in-line)

Then there is this:

From IBM Enterprise COBOL Version 4 Release 2 Performance Tuning, 2010

Initializing Data
The INITIALIZE statement sets selected categories of data fields to predetermined values. It is functionally equivalent to one or more MOVE statements. However, it is inefficient to initialize an entire group unless you really need all the items in the group to be initialized. If you have a group that contains OCCURS data items and you want to set all items in the group to the same character (for example, space or x'00'), it is generally more efficient to use a MOVE statement instead of the INITIALIZE statement.
Performance considerations for INITIALIZE on a program that has 5 OCCURS clauses in the group:
When each OCCURS clause in the group contained 100 elements, a MOVE to the group was 8 % faster than an INITIALIZE of the group.
When each OCCURS clause in the group contained 1000 elements, a MOVE to the group was 23%
faster than an INITIALIZE of the group.

Doesn't say anything about size of table, just number of items. Note that the MOVE referred to is of a "figurative constant" rather than anything else.

Hello,

Just ran a couple of timing tests. Following is the cpu used.

With:

This cpu was used:

And using:

This cpu was used:


The only difference in the code should be using the MOVE versus using the INITIALIZE. As expected, the MOVE blows the doors off the INITIALIZE.

If any other tests might be informative (that don't take much coding<g>) let me know and i'll try to run them later tonight or in the morning while the system is fairly quiet.

Hello Dick,

Can you make the OCCURS 35000 please? That'll put the size of the 01 up to around the same as TS. With a "smaller" table my results went with yours. Then with the bigger table mine went with TS's

Cheers,

Although there is an academic interest in a possible "cross-over" point between INITIALIZE and the MOVE of a table with initial values...

The thing is...

Unless you have a table where you are storing amounts/values which are summed/otherwise calculated upon their previous value - you don't need to INITIALIZE.




The above is what you might see for someone preparing an output record for writing. THE INITIALIZE IS A TOTAL WASTE OF TIME.

If there is a table-entry with 20 subordinate items and all that happens to them is MOVE then there is no need to INITIALIZE.

If you are calculating into a value in a table using the current value as part of the calculation, then your value in the table needs to be initialised to zero. So you have a table which has exactly those type of values and you don't go INITIALIZEing other things.



Vs


The results will be identical. The CPU consumed will be more in the first.

If your existing code can be "abstracted" to the above, just remove the INITIALIZE and any other attempts to set to an initial value and you'll have your CPU saving.

And yes, there will be untolled hours of CPU time wasted daily around the world by people who use INITIALIZE routinely to just consume CPU and who then say things like "I got a S0C7 return code and I don't know why because I used INITILIZE"