IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Need Unique Time for Transaction Pairs


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
MtClimber

New User


Joined: 31 Aug 2007
Posts: 5
Location: Milwaukee WI

PostPosted: Wed Jan 28, 2009 11:10 pm
Reply with quote

Hi;
I checked the archives and apparently no one has had a similar problem to what I'm having.

We have a CICS transaction that can create up to 20 pairs of transactions that get passed to a sub-program that writes them to a VSAM file. The key is time followed by tran type. The transaction pairs are coded 600 and 620.

like this:
0120125 600
0120125 620

Up until now, we've been relying on the timestamp to keep the pair together. Lately we've been getting two pairs with the same timestamp. This causes the two 600 transactions to be sorted together and the two 620's sorted together.

like this:
0120125 600
0120125 600
0120125 620
0120125 620

We are using:
EXEC CICS ASKTIME
ABSTIME(WS-CICS-ABSTIME)
END-EXEC.

followed by:
MOVE EIBTIME TO PCOM-D-TRAN-TIME.

According to the manual the ASKTIME function updates the EIBTIME and I'm confident that it is otherwise we would be getting tons of dups.

Here are how the key fields are defined:
WS-CICS-ABSTIME is PIC S9(16) COMP.
PCOM-D-TRAN-TIME is PIC S9(7).

It would appear that when the sub-program gets the 40 transactions (20 pairs) it is running so fast that occasionally it will write two pairs with the same timestamp. Apparently the S9(7) does not hold a small enough time imcrement for each one to be unique.

I cannot change the record layout to increase the size of the PCOM-D-TRAN-TIME field. My thought was to use the low order 7 bytes of the WS-CICS-ABSTIME field for the timestamp in the transactions instead of EIBTIME.
In your opinion, would this be unique enough to solve our duplicate problem?
Can you suggest a method that would guarantee us a unique time for each transaction pair?

Dan
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Wed Jan 28, 2009 11:44 pm
Reply with quote

Look at the manual again -- EIBTIME is 0HHMMSS+, so if you get more than one a second you'll get duplicates. Using the last 7 digits of ASKTIME ABSTIME will remove this problem as that has the time to the nearest 1/100th of a second. You could still get dups if you're pumping a LOT of data through the transactions but it's much less likely.
Back to top
View user's profile Send private message
MtClimber

New User


Joined: 31 Aug 2007
Posts: 5
Location: Milwaukee WI

PostPosted: Thu Jan 29, 2009 3:22 am
Reply with quote

Thank you, Robert. I appreciate your quick response. I'll go ahead and try using the 7 low order digits and see if that eliminates our duplicate problem.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Thu Jan 29, 2009 6:14 am
Reply with quote

A small Assembler sub-program, which issues the TIME Macro can give you very granular results.

Check out the following LINK (watch the wraparound) -

publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A990/77.0?SHELF=IEA2BK90&DT=20080601235844

For CICS environments, it is recommended that the PPT entry for this sub-program be CICSKEY (Parm=EXECKEY) and it should be accessed from a HLL via a LINK-API, passing a 16-Byte commarea.

Also, the 16-Byte parm required for the Macro should be obtained via a CICS GETMAIN (CICSDATAKEY) and not the default of USERDATAKEY.

Cross-Memory services (LINKAGE=SYSTEM) will most likely go belly up (S0C4) if Storage Protection is "ON" in the SIT and the above 16-Byte parm being used is obtained from USERDATAKEY.

After completing the Cross Memory service, the 16-Byte parm will contain X'HHMMSSTHMIJU' in the first 8-Bytes and the date (whatever format you've chosen) in the last 8-Bytes. Note that both of these values are packed-decimal without a sign.

Do NOT use LINKAGE=SVC (or let it default to this), as this will expand to an SVC 11, a big no-no in CICS.

Even though the PPT Execution Key may specify CICSKEY, DFHEISTG is always allocated in USER Key.

As part of the cleanup process, move the 16-Byte components to the commarea, issue a FREEMAIN, load R15 with a return-code (hopefully, it's F'0') and use the DFHEIRET Macro to return to the Linker with the R15 value.

Then (assuming this is a COBOL Linker) the RETURN-CODE SPECIAL-REGISTER can be checked for success or failure.

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

JCL Moderator


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

PostPosted: Thu Jan 29, 2009 6:15 am
Reply with quote

I had a similar situation several years ago. I needed to assign the same DB2 timestamp to all of the detail rows associated with a header row. I used the CCYY-MM-DD-HH.MM.SS portion of DB2s time stamp and generated my own value of microseconds for the details. When the HH.MM.SS value changed, I'd reset the microseconds to 000000. You could use a method similar to that to generate your own value of time insuring the same value of time for your 600 and 620 records.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS

 


Similar Topics
Topic Forum Replies
No new posts To get the the current time DFSORT/ICETOOL 13
No new posts RC query -Time column CA Products 3
No new posts C Compile time time stamps Java & MQSeries 10
No new posts Parallelization in CICS to reduce res... CICS 4
No new posts How to identify the transaction categ... IMS DB/DC 3
Search our Forums:

Back to Top