Performance issue in cobol while MOVE

srebba · New User Joined: 26 Apr 2007 Posts: 37 Location: USA

Hi,

is there any diference in perforamance while move statement below.

MOVE ZEROS TO VAR1
MOVE ZEROS TO VAR2
MOVE ZEROS TO VAR3
MOVE ZEROS TO VAR4
MOVE ZEROS TO VAR5
MOVE ZEROS TO VAR6
MOVE ZEROS TO VAR7
MOVE ZEROS TO VAR8

OR

MOVE ZEROS TO VAR1
VAR2
VAR3
VAR4
VAR5
VAR6
VAR7
VAR8

Thank you,
Sree

Anuj Dhawan · Posted: Fri Sep 24, 2010 3:05 pm

Why do you think that there will be any performance issue?

srebba · New User Joined: 26 Apr 2007 Posts: 37 Location: USA

We will have to think.. then we can increase the program performance...

Bill O'Boyle · Posted: Fri Sep 24, 2010 4:03 pm

If you're having performance issues, MOVE statements are the least likely to be the culprits.

You may want to begin reviewing file access, buffering, etc.

For example, too many Random KSDS "Writes" can be a problem, especially if they're causing "CA" splits.

You have to live with "CI" splits....

Bill

Robert Sample · Posted: Fri Sep 24, 2010 4:51 pm

Why do you think you need to improve program performance?

Kjeld · Posted: Fri Sep 24, 2010 5:38 pm

Without actual testing it, I am sure the difference between the 2 alternatives are unmesurable.

Anyway, these statements should not be the first target for optimisation, if you need to improve processing.

Phrzby Phil · Posted: Fri Sep 24, 2010 5:58 pm

In my humble opinion, to become an expert programmer in a compiled language like COBOL, you should have at least an intro course in assembler language programming.

When you know what can be done at that level, then you know how a multiple MOVE vs. separate MOVE's might be implemented in machine/assembler language.

In addition, you can look at the PMAP compiler output and actually see what is happening to your code.

A great example I experienced was a S0C7 abend on a COBOL statement doing arithmetic on PIC S9(5)V99. Note, this is not COMP-3, yet I got a S0C7, which is a packed-decimal abend. The generated code showed that since my PIC was signed, the generated code (for some reason I do not remember) converted to packed-decimal, did the arith, including an OI (or-immediate), then converted back to DISPLAY.

I also had the pleasure, when a summer programmer at IBM while in college, of finding a code generation error in the old FORTRAN H compiler. That's another story.

Traveler · Posted: Mon Sep 27, 2010 8:50 pm

Not sure the OP was asking about performance improvement. Is there a difference in performance between the move statement as structured in the example presented. 35 years ago I attended the Prudential Insurance Programmers Course. It was required part of the training and you learned Pru-Cobol. Complete with coding restrictions and code layout requirements.

One thing that was required of all program initializations sections was the use of working storage fields with values of zero that matched size and type of the field being initialized. The reason given was performance, less instructions were being executed. So wsfield-ps999v9999-comp3 was moved to fields that matched that size and were zoned decimal. Binary was moved to comp and so on. When they did the formal walk through of code changes if they found a MOVE ZEROS to it was rejected.
These programs were part of a massively large modularized system known as the Advanced Ordinary System (AOS) and ran 7 days a week from 6:00 PM to 3:AM it was the main policy support system.

Bill O'Boyle · Posted: Mon Sep 27, 2010 9:49 pm

As opposed to a HLL, such as PL/I, COBOL utilizes Figurative Constants, which are allocated and defined to the compiler and stored in the TGT.

So, when you move ZERO to a field, the compiler uses the proper Figurative Constant, depending on the data-type and therefore, reduces the literal-pool.

Thirty-Five years ago, OS/VS COBOL (non-reentrant I might add) was the version/release being used. Cycle reduction was a major consideration, as there was quite a farm of 360's still around. Not too sure when COBOL was updated with the 370 Instruction set, such as MVCL, SRP, ICM, etc, so perhaps this was the reason for Prudential's approach. Also, Mainframes back then were draconian in speed as compared to today's processors.

In pre-VS/COBOL II, the WS fields that included a VALUE clause, were really DC's (under the covers) instead of DS's (VS/COBOL II and greater).

Phil said it best; In order to understand the nuances of a given HLL, basic knowledge of Assembler should be a requirement, if not a mandate.

Bill

dbzTHEdinosauer · Posted: Mon Sep 27, 2010 11:04 pm

the two cobol statements will generate the same assembler.

Craq Giegerich · Posted: Tue Sep 28, 2010 1:04 am

dick scherrer · Posted: Tue Sep 28, 2010 2:41 am

pawaria · New User Joined: 06 Apr 2006 Posts: 7 Location: Noida

Both statements will run the same. Only your written style is different but both statements will be seen as identical by compiler.

Suggestion:
You can better use VALUE ZERO in the working storage
or
Use INITIALIZE

instead of all these MOVE statements.

dbzTHEdinosauer · Posted: Tue Sep 28, 2010 4:40 pm

pawaria,

why do you think INITIALIZE will be better than the MOVE?

Alex Bruzzone · New User Joined: 18 Aug 2010 Posts: 4 Location: Ottawa

A possibility, but only if VAR1 to VAR8 were defined as COMP and under an 01-level dataname, would be to write