IBM Mainframe Forum

Hi Every one,
I have a group variable as defined below. which is having 3100 fields... at 05 level.
01 XXXXXXXX.
02 YYYYY.
05 Z11111 PIC S9(04) COMP VALUE 0000.
05 Z22222 PIC S9(04) COMP VALUE 0000.
05 Z33333 PIC S9(04) COMP VALUE 0000.
05 Z44444 PIC S9(04) COMP VALUE 0000.
. .
.
3100 variables at 05 level.
02 AAAAA REDEFINES YYYYY OCCURS 3100 TIMES
05 BBBBBBBBBB PIC S9(04) COMP.

We are using key word INITIALIZE in cobol code to initiliase whole group(INITIALIZE XXXXXXXX) and we are doing this around 20 times in a single program which is critical module and cosumes much of CPU.. we are in process of fine tune it.

If we replace INITIALIZE with MOVE ZEROS to XXXXXX, Will there be any impact .. ?, if so what are possible issue we will come across.

Thanks,

Yes. Program will stop working. Try with "MOVE LOW-VALUES..."

If we replace INITIALIZE with MOVE ZEROS to XXXXXX, Will there be any impact .. ?, if so what are possible issue we will come across.

You change the initialization value from X'0000' to X'F0F0' (-3856) and you're seriously asking if there will be any impact???

Mann_B wrote:We are using key word INITIALIZE in cobol code to initiliase whole group(INITIALIZE XXXXXXXX) and we are doing this around 20 times in a single program which is critical module and cosumes much of CPU..

Possibly define an "equivalent varaible" in working-storage, INITIALIZE the XXXXXXXX once, move this initialized-variable to the "equivalent varaible". At rest of the 19 places use this "equivalent varaible" to MOVE to XXXXXXXX instead of INITIALIZE.

Why do you ask, just go on test it and analyze the results!

Hi All,
I hv done the changes as suggested above with different options.We are not seeing much saves with this changes. Thanks alot for different ideas

If you have a whole bunch of COMP fields, and no others, subordinate to a group item, there will be no quicker way to initialise them than by moving low-values to the group item.

If that gives you no benefit, then the intlialisation was never a problem. Perhaps what the COMP fields are being used for, and how, is the problem?

If you give details, we'll have suggestions.

Mann_B, the first question to ask is "Is your process I/O-BOUND or CPU-BOUND?" If you do not know this, do not attempt anything else since you are just as likely to have no impact or make things worse rather than better.

If the process is I/O-BOUND, then changing the initialization -- even reducing the intiialziation time to zero -- will have NO IMPACT upon the program. An I/O-BOUND program is waiting for I/O to complete, and reducing CPU usage will not affect that program (unless the I/O is impacted).

Only if the program is CPU-BOUND can changing initialization possibly have any impact. AND there will be an impact if -- and only if -- the initialization is part of the code that is CPU-BOUND. If the initialization code is not part of the CPU-BOUND code, then again you could reduce the initialization time to zero and not have any material impact on how long the program runs.

In other words, unless you've done a LOT more research than you have shown so far in your posts, the results you are seeing would be expected. Changing random parts of a program to improve performance is a futile exercise. And code is not always predictable -- I had a development manager some years ago that was 100% convinced we needed to buy faster disk drives because the program was I/O-BOUND. I got access to STROBE and ran the program through it -- and discovered the program was heavily CPU-BOUND. We spent a week making changes to the appropriate section of code and cut the overall elapsed time by 80%, which saved about 4 hours a day. If we had bought faster disk drive, they would not have improved the program's run time one percent -- and they cost a lot of money!