|
View previous topic :: View next topic
|
| Author |
Message |
ssk1711
New User
Joined: 16 Jun 2008
Posts: 40
Location: bangalore
|
|
|
|
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 |
|
 |
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| 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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
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...  |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
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 |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
Hi Ronald,
| Quote: |
| Any extra "thinking" required for MOVE CORRESPONDING is performed at compile time, not execution time |
Didn't think of this possibility...  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...
Guess its time for me to take a break and put my "thoughts" to some rest !!! |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
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 |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| 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 |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
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 |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| why not run a silly benchmark ?? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
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). 
| 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 |
|
|
ssk1711
New User
Joined: 16 Jun 2008
Posts: 40
Location: bangalore
|
|
|
|
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'..
Thank you all once again!
Thanks,
Senthil |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| I don't know what is complicated with 'MOVE CORR' |
Terry told You! |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| 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 |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
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 |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| 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 |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
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.....
Sometimes temporary code fixes lived longer than the humans that created them...  |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
|
|
