|
View previous topic :: View next topic
|
| Author |
Message |
Binop B
Active User
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...  |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10900
Location: italy
|
|
|
|
what about using EIBDATE and EIBTIME
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 ) |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
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). |
|
| Back to top |
|
|
Binop B
Active User
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... |
|
| Back to top |
|
|
Binop B
Active User
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 ? |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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.
HTH....
Bill |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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 ,
|
Bill |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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.
Bill |
|
| Back to top |
|
|
Binop B
Active User
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... 
Thanks again Bill... |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Coding in a DSECT, how is that executed? |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1216
Location: Dublin, Ireland
|
|
|
|
| Quote: |
| Coding in a DSECT, how is that executed |
Where is there code shown in a DSECT ? I think you'll find that the DFHEIENT macro will generate CSECT.
Garry. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
I stand corrected. I had the feeling it would, but didnt know for sure.
Should have looked it up. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
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.
Bill |
|
| Back to top |
|
|
Binop B
Active User
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...  |
|
| Back to top |
|
|
|
|
  |
All times are GMT + 6 Hours |
|
