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
 

 

Move statement Vs Move corresponding for DATE reformatting

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

New User


Joined: 16 Jun 2008
Posts: 40
Location: bangalore

PostPosted: Thu Mar 04, 2010 2:47 pm    Post subject: Move statement Vs Move corresponding for DATE reformatting
Reply with quote

Hi,
In our date routine, one of the requirement is to convert the date format from DDMMYYYY to DD-MM-YYYY. Say input variable is
WS-DATE PIC 9(08).

We have following options:

1) Define working storage variables as below and use MOVE CORRESPONDING

03 DATE-IN.
05 W-DAY PIC 99.
05 W-MONTH PIC 99.
05 W-YEAR PIC 9999.

03 DATE-OUT.
05 W-DAY PIC 99.
05 PIC X VALUE '-'.
05 W-MONTH PIC 99.
05 PIC X VALUE '-'.
05 W-YEAR PIC 9999.

MOVE WS-DATE TO DATE-IN
MOVE CORRESPONDING DATE-IN TO DATE-OUT

2) Define working storage variables as below and use simple MOVE

03 DATE-IN.
05 W-DAY PIC 99.
05 W-MONTH PIC 99.
05 W-YEAR PIC 9999.

03 DATE-OUT.
05 W-DAY-1 PIC 99.
05 PIC X VALUE '-'.
05 W-MONTH-1 PIC 99.
05 PIC X VALUE '-'.
05 W-YEAR-1 PIC 9999.

MOVE WS-DATE to DATE-IN
MOVE W-DAY to W-DAY-1
MOVE W-MONTH to W-MONTH-1
MOVE W-YEAR to W-YEAR-1

3) Use string operation
STRING
WS-DATE(1:2) DELIMITED BY SIZE
'-' DELIMITED BY SIZE
WS-DATE(3:2) DELIMITED BY SIZE
'-' DELIMITED BY SIZE
WS-DATE(5:4) DELIMITED BY SIZE
END-STRING

Now which option would you go for (And why if possible) if you were told above operation is going to be performed more than 1 million times a day?

I used MOVE CORRESPONDING and during code walk-through, the review comment was to change it to MOVE statement.
I went through some of the threads and suggestions were both for and aganist MOVE CORRESPONDING.

Would you please suggest me which of the three would be best approach considering performance.

Thanks,
Senthil
Back to top
View user's profile Send private message

Ronald Burr

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Thu Mar 04, 2010 6:23 pm    Post subject:
Reply with quote

Suggest that you compile a program with each version ( straight MOVEs and MOVE CORRESPONDING ) with the COBOL compiler option LIST and look at the generated assembler code to see which version generates the most efficient code.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Thu Mar 04, 2010 6:29 pm    Post subject:
Reply with quote

Hi Senthil,

I have not done any testing, but can give u my assumptions....

When u take the MOVE CORRESPONDING you are asking the system to do some "thinking" of its own... which basically means it should have some comparisons which will take time compared to a normal data movement...

Even though not as much as MOVE CORRESPONDING ... my guess is the STRING operation should also behave in the same way internally but probably not as much as the CORRESPONDING statement...

So my vote is for simple MOVE statements... No "thinking" required... No "comparisons" required... Just move the contents from one area to another...

There is a good chance i could be wrong... Please do pardon me if I have made some incorrect statements... icon_cool.gif
Back to top
View user's profile Send private message
Ronald Burr

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Thu Mar 04, 2010 7:01 pm    Post subject:
Reply with quote

Binop, your chances of being wrong are 100%.

1) your "assumption" about MOVE CORRESPONDING is erroneous. Any extra "thinking" required for MOVE CORRESPONDING is performed at compile time, not execution time.

2) your "assumption" about STRING behaving the same way as MOVE CORRESPONDING internally is also erroneous. Whether via independent MOVE instructions or via MOVE CORRESPONDING, the resultant moves are done as numeric moves, since both sending and receiving elements have numeric picture clauses, wheras with a STRING instruction, the resultant moves are done as alphanumeric moves, since the target field is a GROUP item.
Back to top
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Thu Mar 04, 2010 7:16 pm    Post subject:
Reply with quote

Hi Ronald,

Quote:
Any extra "thinking" required for MOVE CORRESPONDING is performed at compile time, not execution time
Didn't think of this possibility... icon_redface.gif yeah... certainly this makes more sense...

Quote:
your "assumption" about STRING behaving the same way as MOVE CORRESPONDING internally is also erroneous
What i meant was with respect to the comparisons that would be required... and not with respect to data types.. anyway which is wrong...

Thanks Ronald for corrections ...
Apologies to all readers who have / might read my previous post... icon_redface.gif

Guess its time for me to take a break and put my "thoughts" to some rest !!!
Back to top
View user's profile Send private message
Ronald Burr

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Thu Mar 04, 2010 7:46 pm    Post subject:
Reply with quote

To save further anguish:

1) The assembler code generated for MOVE CORRESPONDING is 100% identical to the code generated for individual MOVEs. However, each numeric move requires both a move instruction for the data itself, and an OR instruction to guarantee a valid sign in the last byte of the target element - namely 6 assembler instructions in total.
2) the assembler code generated for the STRING requires only 5 assembler instructions: one move instruction for each of the date elements, and one move instruction for each of the '-' constants. No sign validation is performed, since all moves are done alphanumerically.

So, the question really becomes "Is the input date guaranteed to be valid?".
If it is NOT guaranteed to be valid, then either individual MOVEs or MOVE CORRESPONDING could conceivably alter the data during the move, since invalid data in the sign nibble of an input element would be changed ( to a valid sign ) during the move.
If it IS guaranteed to be valid then STRING would be the fastest method.

BUT, if the input date IS guaranteed to be valid, then additional speed could be achieved by NOT doing the move from WS-DATE to DATE-IN, by simply redefining WS-DATE as a group item ( ala DATE-IN ) and doing the MOVEs or STRING directly from that input date field.
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Thu Mar 04, 2010 8:36 pm    Post subject:
Reply with quote

Ronald Burr wrote:
BUT, if the input date IS guaranteed to be valid, then additional speed could be achieved by NOT doing the move from WS-DATE to DATE-IN, by simply redefining WS-DATE as a group item ( ala DATE-IN ) and doing the MOVEs or STRING directly from that input date field.
Or just using reference modification to move the data......
Back to top
View user's profile Send private message
Ronald Burr

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Thu Mar 04, 2010 8:40 pm    Post subject: One last thought.
Reply with quote

CICS Guy has a valid point. If speed is really important, and assuming that the input value of WS-DATE is valid, you can achieve the entire process in 3 assembler instructions by doing this ( leaving DATE-OUT as-is, eliminating the MOVE of WS-DATE to DATE-IN, and eliminating the DATE-IN group item and its subordinates altogether ):

Code:
MOVE WS-DATE(1:2) TO DATE-OUT(1:2).
MOVE WS-DATE(3:2) TO DATE-OUT(3:2).
MOVE WS-DATE(5:4) TO DATE-OUT(5:4).


No validation, no intermediate moves, no in-line literals - just 3 straight alphanumeric moves.
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Thu Mar 04, 2010 8:54 pm    Post subject: Reply to: Move statement Vs Move corresponding for DATE refo
Reply with quote

why not run a silly benchmark ??
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: Thu Mar 04, 2010 9:59 pm    Post subject:
Reply with quote

Hello,

Many organizations no longer permit MOVE CORRESPONDING - suggest you check if this is even permitted on your system.

Quote:
if you were told above operation is going to be performed more than 1 million times a day?
It is very good to be concerned about performance, but amount of system resource required to do set of 3 simple MOVEs a million times is negligible (ran a little test on one of my systems - it took less than one second of cpu time).
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Thu Mar 04, 2010 10:05 pm    Post subject:
Reply with quote

Quote:
Now which option would you go for (And why if possible) if you were told above operation is going to be performed more than 1 million times a day?
I would say that with modern mainframes, there will be almost no difference -- and almost certainly no NOTICEABLE difference -- no matter how you code it. Our system can execute over 10 million COBOL statements in one second of CPU time (I know because I've measured it), and our system is nowhere near as fast as a z10 box. You've probably spent more time and resources worrying about performance than you could save in the next 10 years. Just pick a method and go with it!
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1238
Location: Richfield, MN, USA

PostPosted: Fri Mar 05, 2010 10:20 am    Post subject:
Reply with quote

Unless I missed it, no one has mentioned an important consideration so far. By using the MOVE CORRESPONDING, you have identical field names in the source and destination. Any reference to the individual destination names will need to be qualified during the rest of the program which might infuriate the next maintainer(s). icon_smile.gif
Code:
W-DAY   OF DATE-OUT
W-MONTH OF DATE-OUT
W-YEAR  OF DATE-OUT
If not for that drawback, I'd prefer the MOVE CORRESPONDING if allowed at the site.
Back to top
View user's profile Send private message
ssk1711

New User


Joined: 16 Jun 2008
Posts: 40
Location: bangalore

PostPosted: Fri Mar 05, 2010 2:00 pm    Post subject: Reply to: Move statement Vs Move corresponding for DATE refo
Reply with quote

Hi,

Discussion is good and helped to understand the working these statements. Thank you!

The review team advised me to use MOVE statement for this. They sited the below reasons for this -
1) 'MOVE CORRESPONDING' cannot be used according to the standards in our shop.
2) They thought it would be good to keep it simple. (I don't know what is complicated with 'MOVE CORR'..icon_smile.gif

Thank you all once again!

Thanks,
Senthil
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Fri Mar 05, 2010 2:34 pm    Post subject: Reply to: Move statement Vs Move corresponding for DATE refo
Reply with quote

Quote:
I don't know what is complicated with 'MOVE CORR'


Terry told You!
Back to top
View user's profile Send private message
Ronald Burr

Active User


Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.

PostPosted: Fri Mar 05, 2010 6:26 pm    Post subject:
Reply with quote

Quote:
I would say that with modern mainframes, there will be almost no difference -- and almost certainly no NOTICEABLE difference -- no matter how you code it.

With all due respect, Robert, a statement like this reminds me of the story about a village in Italy where each family was expected to bring one liter of their new wine to add to the village vat, after which the entire village would partake in a festival celebrating the harvest. One family concluded that if they were to substitute a liter of WATER instead of WINE, they could save the wine and no one would be the wiser, after everything was mixed together.

Unfortunately, it seems that EVERY family had the same thought.

I personally think that programming is like adding wine to the village vat - if EVERYONE thinks that inefficiency in THEIR code "won't matter" in the big Iron, mega-mips mix, they are as foolish as those villagers.

Just sayin'.
Back to top
View user's profile Send private message
Terry Heinze

JCL Moderator


Joined: 14 Jul 2008
Posts: 1238
Location: Richfield, MN, USA

PostPosted: Fri Mar 05, 2010 6:35 pm    Post subject:
Reply with quote

Senthil,
Over the years performance, although still relevant, has taken a back seat to maintainability. Saving a millisecond of CPU time pales in comparison to the amount of time spent trying to understand the code. Good thing to keep in mind.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Fri Mar 05, 2010 7:03 pm    Post subject:
Reply with quote

Quote:

With all due respect, Robert, a statement like this reminds me of the story about a village in Italy where each family was expected to bring one liter of their new wine to add to the village vat, after which the entire village would partake in a festival celebrating the harvest. One family concluded that if they were to substitute a liter of WATER instead of WINE, they could save the wine and no one would be the wiser, after everything was mixed together.

Unfortunately, it seems that EVERY family had the same thought.

I personally think that programming is like adding wine to the village vat - if EVERYONE thinks that inefficiency in THEIR code "won't matter" in the big Iron, mega-mips mix, they are as foolish as those villagers.


I wonder what Enrico is going to say about that icon_smile.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Fri Mar 05, 2010 7:17 pm    Post subject:
Reply with quote

Ronald, I agree -- and don't agree -- with what you're saying. If nobody worries about performance there can be issues. However, until an issue is identified with performance, worrying about performance in advance is pretty much useless. If the program this person is writing does only the one set of MOVE statements, and runs when average CPU utilization is 83%, for example, then there won't be a performance issue -- ever -- with this code, no matter how written. If the code will be executed 5 million times a day when CPU utilization is hitting 100%, then yes there will be a performance issue.

The concern I've got is that performance cannot be considered out of context -- if your program won't be running during a critical period of CPU usage, it generally won't matter how it performs. On the other hand, if your program raises the 4-hour rolling average by 8%, that would be a major problem. But looking to fix performance problems before you know they are problems is almost certainly a huge waste of time.
Back to top
View user's profile Send private message
CICS Guy

Senior Member


Joined: 18 Jul 2007
Posts: 2150
Location: At my coffee table

PostPosted: Fri Mar 05, 2010 9:38 pm    Post subject:
Reply with quote

Oh my god....
How to split this off to a more heady topic????
We all (should) be striving for the most efficient code, but we (oldies) are guilty of some bad practices in our prior lives..... icon_redface.gif
Sometimes temporary code fixes lived longer than the humans that created them... icon_rolleyes.gif
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Sat Mar 06, 2010 11:56 am    Post subject:
Reply with quote

I've read that there's NO performance issue w/MOVE CORR - it's perfectly efficient. The generated code is identical to that generated by the individual moves.

In Senthil's case, I don't see a downside since the move is reformatting the date and I'd guess the individaul elements of the date won't be referenced again.

That being said, MOVE CORRing large strings of data can cause all kinds of headaches. But in this instance I don't see a problem.
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 -913/-911 Deadlock during UPDATE stat... NoSleep319 DB2 5 Fri Nov 18, 2016 12:37 am
No new posts TOT & DATE parameter in ICEMAN hemanthj642 DFSORT/ICETOOL 4 Mon Nov 14, 2016 5:19 am
This topic is locked: you cannot edit posts or make replies. How to pass the previous month date i... Suganya87 DFSORT/ICETOOL 5 Mon Oct 31, 2016 4:13 pm
No new posts Protection Exception while move 0 to ... Kevin Vaz CICS 10 Tue Oct 18, 2016 4:19 pm
This topic is locked: you cannot edit posts or make replies. Get correct date and time when curren... balaji81_k DB2 24 Fri Oct 14, 2016 10:40 pm


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