How to retrieve system timestamp?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

Provided there is no DB2 installed, I want to retrieve 26bytes system timestamp in cobol program, how to do it ?

we all know that if DB2 is avaible, we can issue below statement to retrieve it.

Robert Sample · Posted: Fri Aug 24, 2012 7:28 am

First question: just how precise does your time value need to be? LE callable service goes to thousandths of a second. If you need more precision than that, you are pretty much going to have to code up an assembler routine to grab the time, since neither COBOL nor LE will get you better precision.

Bill O'Boyle · Posted: Fri Aug 24, 2012 7:47 am

In Assembler/Batch, you can retrieve a date/time stamp using a sub-program which issues the MVS "TIME" Macro (LINKAGE=SYSTEM) and returns a 10-byte hex-format, one of which is X'CCYYMMDDHHMMSSTHMIJU'. You can then convert this to either packed-decimal or display-numeric.

The "MIJU" portion of this value represents "Milliseconds", "Ten Thousandths", "Hundred Thousandths" and "Microseconds", respectively.

Also in Assembler/Batch, you could use the MVS "STCKCONV" Macro to convert a current or previous "STCK" to several different formats.

The MVS "TIME" Macro or "STCKCONV" Macro should not be used in CICS.

The LE Callable Service routine "CEELOCT" (can be used in both Batch and CICS) returns a 17-byte display-numeric format of C'CCYYMMDDHHMMSSTHM'.

dick scherrer · Posted: Fri Aug 24, 2012 7:58 am

Hello,

ridgewalker58 · New User Joined: 26 Sep 2008 Posts: 51 Location: New York

The CICS command ASKTIME is usually coupled with the FORMATTIME
command to obtain Date and Time (HHMMSS). Prior to issuing the FORMATTIME -- Simply take the LAST 4 digits of the result of the ASKTIME and us it as your millisecond value. Append this to the result of your FORMATTIME

ASKTIME

ABSTIME(data-area)
specifies the data area for the time, in packed decimal, since 00:00 on 1 January 1900 (in milliseconds rounded to the nearest hundredth of a second).
You can use FORMATTIME to change the data into other familiar formats.

Examples

For example, after execution of:

________________________________________________________________________
| |
| EXEC CICS ASKTIME ABSTIME(utime) |
| |
|________________________________________________________________________|

"utime" contains a value similar in format to 002837962864820.

Mickeydusaor · Posted: Fri Sep 07, 2012 11:04 pm

a DB2 timestamp has the following format 2012-10-02-10.31.48.000001

in a Cobol program you can do the following which will give you the same
but without the dash and periods.

Akatsukami · Posted: Fri Sep 07, 2012 11:08 pm

No, that will not give the same result. The resolution of CURRENT-DATE is only to the centi-second, and the returned string includes the offset of WULT from GMT.

As Mr. Scherrer says, I'd want to know why the application needs the time with microsecond resolution. A reason of "Because that's the requirement" should engender the reply "It's also the requirement that I have a competent team lead".

Mickeydusaor · Posted: Fri Sep 07, 2012 11:11 pm

and what makes you thing that it will not give the same results.????
the last 3 field the use will just not use, and if they need the dashes and periods the just need to string this into a field that matches the DB2 timestamp layout.

Akatsukami · Posted: Fri Sep 07, 2012 11:18 pm

As you see, I expanded on my objections whilst you were typing your rebuttal.

dejunzhu insists on microsecond resolution. I don't know why he thinks he needs it, but this thread is essentially about ways to get the resolution without using DB2. CURRENT-DATE does not give it to him.

Mickeydusaor · Posted: Fri Sep 07, 2012 11:20 pm

yes, you are correct in that regards

dbzTHEdinosauer · Posted: Fri Sep 07, 2012 11:33 pm

banks are the only business that worries
about things happening at the microsecond level
(even though they happen at the sub-nanosecond level).

you know the banker motto:
never pass-up a chance to overdraft.

Bill O'Boyle · Posted: Sun Sep 09, 2012 3:26 am

Dejunzhu,

After researching this topic, using the MVS "TIME" Macro, with LINKAGE=SYSTEM, is OK to use in CICS as it uses Cross-Memory Services as opposed to an SVC (LINKAGE=SVC is an SVC 11). With Cross-Memory Services, the usage is a consistent synchronous link, without an interrupt as opposed to the SVC, which will generate an interrupt and can only return a Julian-Date of P'0CYYDDD' and a Time of X'HHMMSSTH', in R1 and R0, respectively.

In the sub-program (must be CICS/Assembler), which is accessed via a LINK-API, the PPT execution key must be CICS and the 16-Bytes of storage used for the Macro, must be GETMAINed using CICSKEY. This GETMAIN is necessary, so that a S0C4 is not raised if "Storage Protection" is active in the SIT. Note that the default KEY for CICS/Assembler Dynamic-Storage (DSECT DFHEISTG) is USER (Key 9), even though the PPT execution key is defined as CICS (Key 8). It is advisable that you issue a FREEMAIN of the 16-byte area before returning to the LINKING program.

Using this Macro, you can then build a TOD stamp and return it to the LINKING program in the commarea as a PIC X(20) VALUE 'CCYYMMDDHHMMSSTHMIJU' as a substitute for the DB2 TOD. Just add edit-characters and you're done.

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

thank you all.

The main concern of using 'SELECT CURRENT TIMESTAMP FROM SYSIBM.SYSDUMMY1' is the performance. As we know, this SQL
statments costs quite a lot of DB2 resource.

But as an alternative, by calling a subprogram, I suppose the performance is no better than using SQL.

dbzTHEdinosauer · Posted: Sun Sep 09, 2012 8:12 am

your attention is drawn to the last comment of this thread:
www.dbforums.com/db2/1627530-select-current-timestamp.html

Bill O'Boyle · Posted: Sun Sep 09, 2012 8:17 am

I think we were all under the impression (at least, I was) that you needed a DB2-Like Date/Timestamp because your environment was not DB2?

I guess you fooled us again and I'm not very pleased

For future posts, please explain your issue a little better. Otherwise, you run the risk of alienating yourself

dick scherrer · Posted: Sun Sep 09, 2012 10:19 am

Hi Bill,

Sorry for your frustration. Many of us have been dealing with this kind of question and subsequent dialog from TS for years now and what is most disconserting is they have not improved over time - no matter which part of the forum . . .

enrico-sorichetti · Posted: Sun Sep 09, 2012 12:06 pm

razesh84 · Posted: Mon Sep 10, 2012 2:05 am

Hi dejunzhu,

If performance is the issue then you can use the below query for the same result

SET :WS-TIMESTAMP = CURRENT TIMESTAMP

I ran both set & select query 10million times under DBv10 but didnt find any difference in CPU but 2-3 years back when we're migrated to v8 from v7 our performance team made it mandatory to not use SYSDUMMY1 or any other dummy-table for such operation.

The reason they gave was 'Since it looks like just another query DB2 optimizer tries to explain this too.thereby not taking full utilization of DB2 registers.'

Note : At that time I was just a fresher & didn't have guts to go against their recommendations.If you feel its performance issue you can test both queries & publish the result.All I want to say that the same thing was also said to me.

dick scherrer · Posted: Mon Sep 10, 2012 2:17 am

Hello,

Did you test this before posting? (rhetorical question - obviously it was not tested to meet the required date format).

Please make sure that when you post a suggestion, you have made sure it can do what has been requested. You suggestoin was specifically mentioned as NOT probiding what was wanted.

Thank you, though, for mentioning the results of timing tests - most of us were reasonably sure that the cost would be nearly non-existent