INITIALISE VS MOVE SPACES.



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

INITIALISE VS MOVE SPACES.

Postby Mann_B » Tue Feb 14, 2012 7:40 pm

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,
Mann_B
 
Posts: 79
Joined: Wed Mar 31, 2010 11:48 am
Has thanked: 0 time
Been thanked: 0 time

Re: INITIALISE VS MOVE SPACES.

 

Re: INITIALISE VS MOVE SPACES.

Postby BillyBoyo » Tue Feb 14, 2012 7:43 pm

Yes. Program will stop working. Try with "MOVE LOW-VALUES..."
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: INITIALISE VS MOVE SPACES.

Postby Robert Sample » Tue Feb 14, 2012 7:57 pm

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???
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: INITIALISE VS MOVE SPACES.

Postby Anuj Dhawan » Fri Feb 17, 2012 3:39 pm

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.
Anuj
Anuj Dhawan
 
Posts: 274
Joined: Mon Feb 25, 2008 3:53 am
Location: Mumbai, India
Has thanked: 6 times
Been thanked: 4 times

Re: INITIALISE VS MOVE SPACES.

Postby Monitor » Mon Feb 20, 2012 12:02 pm

Why do you ask, just go on test it and analyze the results!
Monitor
 
Posts: 98
Joined: Wed Jan 18, 2012 8:59 pm
Has thanked: 0 time
Been thanked: 7 times

Re: INITIALISE VS MOVE SPACES.

Postby Mann_B » Thu Feb 23, 2012 9:18 pm

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
Mann_B
 
Posts: 79
Joined: Wed Mar 31, 2010 11:48 am
Has thanked: 0 time
Been thanked: 0 time

Re: INITIALISE VS MOVE SPACES.

Postby BillyBoyo » Thu Feb 23, 2012 9:26 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: INITIALISE VS MOVE SPACES.

Postby Robert Sample » Thu Feb 23, 2012 10:20 pm

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!
Robert Sample
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times


Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post