Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi All,
Have a requirement where in I need to get the GMT time or atleast the difference between the GMT and LOCAL time.
The existing program is in Assembler with CICS.
Is there any way to get the information ?
I have looked into using the LE routines but for an assembler CICS program it seems to be a bit complicated with a lot of initial setup required...
At this point looking for an easier option...
but be aware of the consistency issues about timestamps...
for example if You need to timestamp all the records/rows updated by a transaction
is generally wrong to build the timestamp just before the udates
it would be difficult to correlate them ( the updates I mean )
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Which version of CICS? The version 3.2 Application Programming Reference manual (link at the top of the page) has FORMMATTIME command option STRINGFORMAT(RFC1123) which returns GMT -- so EXEC CICS ASKTIME followed by EXEC CICS FORMATTIME will do it.
The TIME Assembler macro has ZONE=LT or ZONE=GMT to determine which to return, but I don't recall if it can be invoked by a CICS program (probably not, but my coffee hasn't kicked in yet so I'm not committing to anything).
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi Enrico,
Thank you for your reply...
Quote:
what about using EIBDATE and EIBTIME
They EIBDATE and EIBTIME seems to have the LOCAL time and dates. As mentioned we wanted the time difference so we were thinking of using the EIB date and time to calculate the difference from the LOCAL time.
Quote:
but be aware of the consistency issues about timestamps...
for example if You need to timestamp all the records/rows updated by a transaction
is generally wrong to build the timestamp just before the udates
it would be difficult to correlate them ( the updates I mean )
thanks a lot for the suggestion... ... but as mentioned just interested in the time difference ... This is not used for any reports...
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi Robert,
Thanks for the reply... and yes option STRINGFORMAT(RFC1123) is giving me the GMT time...
Would like a small clarification on this.
Actually this option I had tested in one environment ( specific to my company ). When i tested here, it was giving me the same time - i.e. both EIBTIME and STRINGFORMAT(RFC1123).
But after Robert's suggestion I tried using the same in the client environment and its working.
After some research, the only place where I could find some difference is when i tried issuing the CECI INQ MONITOR statement in which the TIME option was returning a value 604 ( GMT ) in the client environment while the other enviroment was returning 605 ( LOCAL ). Is it because of this ?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
If you make the CICS/Assembler routine LE compliant or use CEEPIPI to make it temporarily LE compliant, then you can call LE Callable Service routine "CEEGMTO", which will return the hours/minutes difference between GMT and Local, in two separate binary-fwords.
There are 3600000 milliseconds in an hour and 60000 milliseconds in a minute.
Note that (for example) your CPU was located in the US EST (which is currently GMT-0500), the value in the hours-fword will be a negative five (=F'-5). So you would need to set this value (temporarily and save the original as a failsafe) as a positive five (CVD into a DBLWORD), multiply the DBLWORD BY 3600000, issue an ASKTIME ABSTIME and add the calculated DBLWORD to the ABSTIME millisecond value.
A FORMATTIME can then be used against the adjusted ABSTIME value, resulting in dates/times which reflect local date/time plus their GMT offset (in other words, GMT).
Having said this, LE also offers "CEEGMT" and (an alias to "CEEGMT", named "CEEUTC") which will return the date/time as GMT, in a fword and dblword format.
One other tidbit is if your TOD clock is set to GMT, you could calculate the offset between a STCK and the local date/time converted to a local STCK value.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
This is a sub-program, which will return the hours millisecond-adjustment DBLWORD, which needs to be added to an ABSTIME value. Note that the sign-nibble is either positive or negative, so the ADD will work, regardless.
Code:
PRINT NOGEN SUPPRESS MACRO EXPANSION
CVT DSECT=YES,LIST=YES GENERATE 'CVT' DSECT
PRINT GEN ACTIVATE MACRO EXPANSION
DFHEISTG DSECT DYNAMIC-STG (R13)
DBLWORD DS D ALIGNED-DBLWORD WORKAREA
WRKCVTTZ DS F CVTTZ-SAVEAREA
RETNCODE DS H RETURN-CODE HWORD
GETOFFST DFHEIENT CODEREG=R3,DATAREG=R13,EIBREG=R11
MVC RETNCODE,=H'16' SET 'BAD' RETURN-CODE
LH R15,EIBCALEN ACTUAL COMMAREA-LGTH
CHI R15,L'DBLWORD MINIMUM COMMAREA-LGTH?
BL CICSRETN NO, RETURN TO CALLER
L R7,DFHEICAP LOAD COMMAREA-ADDRESS
L R15,CVTPTR CVT-ADDRESSABILITY
L R15,CVTTZ-CVT(,R15) LOAD INTO R15
ST R15,WRKCVTTZ STORE IN FWORD
LPR R15,R15 MAKE IT POSITIVE
CVD R15,DBLWORD MAKE IT DECIMAL
MP DBLWORD,=P'1048576' CALCULATE NBR-OF-SECONDS
SRP DBLWORD,(64-6),0 DIVIDE BY 1000000/NO ROUNDING
CVB R14,DBLWORD MAKE IT BINARY
SRDA R14,32 PREPARE FOR BINARY-DIVIDE
D R14,=F'3600' CALCULATE HOURS
CVD R15,DBLWORD MAKE IT DECIMAL
MP DBLWORD,=P'3600000' CALCULATE MSECS-ADJUSTMENT
MVI RETNCODE+L'RETNCODE-1,X'00'
TM WRKCVTTZ,X'80' ORIGINALLY NEGATIVE?
BO UPDTCOMA YES, UPDATE COMMAREA
OI DBLWORD+L'DBLWORD-1,X'01'
UPDTCOMA EQU *
MVC 0(L'DBLWORD,R7),DBLWORD
CICSRETN EQU *
LH R15,RETNCODE LOAD HWORD RETURN-CODE
DFHEIRET RCREG=R15 RETURN TO CALLER
LTORG ,
YREGS ,
GETOFFST AMODE 31
GETOFFST RMODE ANY
END ,
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Just found an error in the above sub-program. The BZ following the TM -
Code:
TM WRKCVTTZ,X'80' ORIGINALLY NEGATIVE?
BZ UPDTCOMA NO, UPDATE COMMAREA
Needs to be changed to -
Code:
BO UPDTCOMA YES, UPDATE COMMAREA
When the DBLWORD is added to the ABSTIME, it will always be correct, because if the original the GMT Offset were NEGATIVE (behind GMT), then the DBLWORD must remain as POSITIVE. Otherwise, if the offset were POSITIVE and greater than zero (ahead of GMT), the sign-nibble of DBLWORD must be set to NEGATIVE.
I did leave out consideration for sites (primarily Britain) which sit directly on GMT and so, their DBLWORD value must be set to P'0', because GMT and LOCAL are the same.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi Bill,
Thanks a ton for the suggestions, ideas and the code...
As mentioned in my previous post, I think I will use the STRINGFORMAT option in the FORMATTIME to get the value as it is working in my client environment.
I am certainly going to have a look into LE suggestions and supporting code and try understand the logic. I am still at a stage in Assembler where each instruction I need to go back to the manual and understand what it is doing... .. it will take some time... but hope I will get there soon...
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Binop B wrote:
Hi Bill,
Thanks a ton for the suggestions, ideas and the code...
Binop,
The introduction of GMT calculation was not until TS 3 (3.1 or 3.2, can't recall).
So, the sub-program can be used in any CICS version/release and can be LINKED-TO by Assembler, PL/I or COBOL (with an 8-byte commarea), returning the adjustment in the 8-byte commarea, defined as 8-bytes packed-decimal, which will either be a positive (when the offset is behind GMT) or negative (when the offset is ahead of GMT and greater than P'0').
The sub-program doesn't deal with offset-minutes, but it gives someone the basis of performing this calculation, with a little bit of ingenuity, providing offset-minutes are non-zero, such as in India, Newfoundland and other areas of the globe.
Joined: 18 Jun 2009 Posts: 407 Location: Nashville, TN
Hi,
Quote:
The sub-program doesn't deal with offset-minutes, but it gives someone the basis of performing this calculation, with a little bit of ingenuity, providing offset-minutes are non-zero, such as in India, Newfoundland and other areas of the globe.
Yup... didn't miss the trick... ... as soon as I saw your code, we were using it as a basis for the calculation and since our client are US... hours is all that's required...
.. it will take some time... but hope I will get there soon... 
... as soon as I saw your code, we were using it as a basis for the calculation and since our client are US... hours is all that's required... 
