Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Performance issue in cobol while MOVE

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
srebba
Warnings : 1

New User


Joined: 26 Apr 2007
Posts: 37
Location: USA

PostPosted: Fri Sep 24, 2010 12:16 pm    Post subject: Performance issue in cobol while MOVE
Reply with quote

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
Back to top
View user's profile Send private message

Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6258
Location: Mumbai, India

PostPosted: Fri Sep 24, 2010 3:05 pm    Post subject:
Reply with quote

Why do you think that there will be any performance issue? icon_neutral.gif
Back to top
View user's profile Send private message
srebba
Warnings : 1

New User


Joined: 26 Apr 2007
Posts: 37
Location: USA

PostPosted: Fri Sep 24, 2010 3:07 pm    Post subject: Reply to: Performance issue in cobol while MOVE
Reply with quote

We will have to think.. then we can increase the program performance...
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri Sep 24, 2010 4:03 pm    Post subject: Reply to: Performance issue in cobol while MOVE
Reply with quote

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.... icon_wink.gif

Bill
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7908
Location: Bellevue, IA

PostPosted: Fri Sep 24, 2010 4:51 pm    Post subject:
Reply with quote

Why do you think you need to improve program performance?
Back to top
View user's profile Send private message
Kjeld

Active User


Joined: 15 Dec 2009
Posts: 365
Location: Denmark

PostPosted: Fri Sep 24, 2010 5:38 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Phrzby Phil

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Fri Sep 24, 2010 5:58 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Traveler

New User


Joined: 12 Aug 2010
Posts: 8
Location: Highlands, NJ

PostPosted: Mon Sep 27, 2010 8:50 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Sep 27, 2010 9:49 pm    Post subject: Reply to: Performance issue in cobol while MOVE
Reply with quote

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
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Sep 27, 2010 11:04 pm    Post subject:
Reply with quote

the two cobol statements will generate the same assembler.
Back to top
View user's profile Send private message
Craq Giegerich

Senior Member


Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA

PostPosted: Tue Sep 28, 2010 1:04 am    Post subject: Re: Reply to: Performance issue in cobol while MOVE
Reply with quote

Bill O'Boyle wrote:

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


I agree with you on a basic knowledge of Assembler but now days it is even a basic knowledge of COBOL that is in short supply.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Sep 28, 2010 2:41 am    Post subject: Reply to: Performance issue in cobol while MOVE
Reply with quote

Quote:
but now days it is even a basic knowledge of COBOL that is in short supply.

And JCL, and Utilities, and Data Formats, and Access Methods, and . . .

Quite scary. . . icon_neutral.gif
Back to top
View user's profile Send private message
pawaria

New User


Joined: 06 Apr 2006
Posts: 7
Location: Noida

PostPosted: Tue Sep 28, 2010 3:42 pm    Post subject: Reply to: Performance issue in cobol while MOVE
Reply with quote

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.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Tue Sep 28, 2010 4:40 pm    Post subject:
Reply with quote

pawaria,

why do you think INITIALIZE will be better than the MOVE?
Back to top
View user's profile Send private message
Alex Bruzzone

New User


Joined: 18 Aug 2010
Posts: 4
Location: Ottawa

PostPosted: Sat Oct 02, 2010 9:36 pm    Post subject:
Reply with quote

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

Code:

01 ALL-VARS.
    02 VAR1    PIC S9(8) COMP.
.
    02 VAR8    PIC S9(8) COMP.
.
.

MOVE LOW-VALUES TO ALL-VARS


Otherwise, define an identical 01-level already initialized to zeros, and the just code:

Code:
MOVE ZEROED-VARS TO ALL-VARS


Any of these two Moves I'm suggesting will perform better than the two different formats for the eight separate Moves suggested by the original poster.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts How to move a long alphanumeric data ... lind sh COBOL Programming 6 Mon Dec 05, 2016 7:51 pm
No new posts PL/I code tuning/Performance improvement Virendra Shambharkar PL/I & Assembler 4 Mon Dec 05, 2016 11:57 am
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts DFHRESPONSE returns issue divated CICS 3 Wed Nov 02, 2016 6:32 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us