View previous topic :: View next topic
|
Author |
Message |
pmvino
New User
Joined: 22 Aug 2008 Posts: 20 Location: india
|
|
|
|
Hi,
I am writing a cobol-DB2 stored procedure. I need current date and time in the program.
Which one is the best for CPU utilisation
1) ACCEPT WS-CURRENT-DATE FROM DATE
ACCEPT WS-CURRENT-TIME FROM TIME
or
2) EXEC SQL SET :CURR-TIME = CURRENT_TIMESTAMP END-EXEC
Thanks,
Vinodh P M |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Why do you care about CPU utilization? Unless you are executing your code BILLIONS or TRILLIONS of times, the difference in execution time will be so small you couldn't tell the difference. Current COBOL compiled code executes tens or even hundreds of millions of COBOL statements per second of CPU time on z machines, so worrying about CPU utilization is completely archaic and obsolete -- unless the program is discovered to have a problem. Such a problem, however, would NOT be with using ACCEPT versus the database to get date / time.
Invoking the database to get date / time would tend to use more overall CPU since the ACCEPT statements are 30 pseudo-assembler instructions using the COBOL V3R4 compiler. However, if you have coded your program to use one or the other, don't change it since you would use more CPU time to recompile the code than you are likely to save in years of execution. |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
With accept there is a very slight chance that the date could change between the two calls so you would end up with time that doesn't go with the date. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Quote: |
With accept there is a very slight chance that the date could change between the two ... |
Yes, but it'll never happen until the first month-end/year-end run in Production.... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
time-stamping is a peeve of many auditors usually ending in a <religion> war
according to many of them all the <events> of a process should have the <same> timestamp in order to be able to relate them
the picky ones sometimes insist on two timestamps one related to the <process> and one related to the <event>
the double time-stamp might make sense significant when there are <concurrent> updates
from different <sources> and one process spans a looong time interval
where a process is a unit of work, an online transaction or a batch program |
|
Back to top |
|
|
NahuelTori
New User
Joined: 29 Sep 2008 Posts: 9 Location: Argentina
|
|
|
|
With the SQL command, you have to had the spacial care to control the SQLCODE of the execution. It is common to have this as the first SQL command executed in the program, leading to possible unreacheable Abends due to -805 bind errors. |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
The precision needed of date and time might be the deciding factor as to which ones you choose. |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
I agree with Robert that unless you are executing your code BILLIONS or TRILLIONS of times, the difference in execution time will be so small you couldn't tell the difference.
However, with the information in hand read is as the only DB2 statement in the program is for TIMESTAMP, choose:
Code: |
ACCEPT WS-CURRENT-DATE FROM DATE
ACCEPT WS-CURRENT-TIME FROM TIME |
This next statement of mine might call in for a long argument, though, if time component is not that critical part for your LUW, COBOL ACCEPT is a preferred way to go compared to DB2 timesstamp - why? Nahuel has explained that already. But if your program runs once a day, the "savings" might be too small to be called as savings. |
|
Back to top |
|
|
|