Accurate systemtime i.e. without ACCEPT

[OIS]

I'm looking for a way to read the systemtime from the MVS control blocks in order to get a more precise systemtime.
With trial and error I managed this
LINKAGE section.
01 CTLBLK-001.
05 PTR001 pointer occurs 256.
01 CTLBLK-002.
05 PTR002 pointer occurs 256.
PROCEDURE division.
*PSA control block
set address of CTLBLK-001 to NULL
*TCB control block
set address of CTLBLK-001 to PTR001(136)
move CTLBLK-001(873:8) to TODANM
TODANM contains the date/time in microseconds since 1900-01-01 (TOD-format).
This works OK in the batch environment but not in a CICS-environment. Probably because the offset is outside the TCB control block.
Is there anybody out there who has a cobol or assembler solution to get the systemdate.

 

[prakal]

Here is sample of an LE callable service:

Working storage:
01 CEE-CALL-INTERFACE.
02 WS-LILIAN-FMT PIC S9(9) BINARY.
02 WS-LILIAN-SEC COMP-2.
02 WS-GREG-FMT PIC X(17).
01 WS-FC.
02 WS-COND-TOKEN.
COPY CEEIGZCT.
03 WS-ERROR-OUT.
04 WS-ERROR-SEV PIC S9(4) BINARY.
04 WS-MSG-NO PIC S9(4) BINARY.
03 FILLER PIC X(04).
02 FILLER PIC S9(9) BINARY.

Procedure division:
CALL "CEELOCT" USING WS-LILIAN-FMT, WS-LILIAN-SEC,
WS-GREG-FMT, WS-FC.
IF CEE000 OF WS-FC
CONTINUE
ELSE
DISPLAY 'CEELOCT CALL FAILED'
END-IF

CEELOCT return the local date and time. WS-GREG-FMT is the output whose format is CCYYMMDDHRMMSSNNN.

Hopefully this helps.

 

[OIS]

Thank you prakal,

it works (of course) but what I really want is the format you see in SMF-records or in a DB2-timestamp. That is '2004-08-31-10.00.00.000000'. I'm now reading a DB2-timestamp but that uses 5-7 times more resources (CPU) than methods like you suggested.

 

[wahlers]

Just out of curiosity...

Why is it so important to be accurate to a microsecond?

I know millisecond is a thousand times less accurate but for (normal) logging purposes this usually is not an issue.

I used an accurate time (same as you request now - microseconds) once myself. But this was because I wanted to know the exact(!) instruction executed of an unknown erroronuous program on a mainframe (multi-user/multi-tasking).

An additional tip for the solution described by 'prakal':
Isolate your solution in a single dynamically called simple program. Doing so you can always replace your current solution with the next best solution.
Additional advantage: You can return the date/time in any form you like.


Regards, Wim Ahlers.

 

[prakal]

Thanks for your tip Wim.

Prakal