On Mon, 10 Mar 2008 18:11:39 -0500, William H. Blair wrote: > >> I believe this is in contrast to the z/OS STCKCONV service. >> however, I can not find in the docmentation ("z/OS V1R7.0 MVS >> Assembler Services Reference IAR-XCT") whether STCKCONV >> returns local time or GMT nor how Daylight Saving and Leap >> Seconds are handled (possibly in accord with the table in >> the PoOP?) The programmer ought to be given the choice of >> either. Perhaps I'll submit an RCF. > >STCKCONV returns neither. It returns what it has been given. > >If it is given local time, then the result will be local time. > >If it is given GMT, then the result will be GMT. > >It is just a conversion service, whose input is either a 64-bit >TOD clock value or a 128-bit ETOD clock value. > I'm confused. I thought STCKCONV takes as input a TOD clock value, and if you operate as IBM recommends, TOD clock values are always GMT.
>To get a TOD clock value corrected for the local time zone and >leap seconds for input to STCKCONV, you would need to execute >code such as this: > > TIME STCK,STCKGMT CURRENT GMT TOD CLOCK > STCKCONV STCKVAL=STCKGMT, CONVERT GMT TIME + > CONVVAL=GMTTIMED, TO + > TIMETYPE=DEC, HHMMSSTHMIJU0000 + > DATETYPE=YYYYMMDD YYYYMMDDXXXXXXXX >* How can the below give the correct result if STCKGMT is read from a log file written on the other side of a Daylight/Standard or Leap Second boundary? > L R4,CVTPTR LOAD CVT ADDRESS > USING CVT,R4 CVT ADDRESSABILITY > L R5,CVTEXT2 OS/VS2 COMMON EXTENSION > USING CVTXTNT2,R5 CVTXTNT2 ADDRESSABILITY > LM R14,R15,CVTLDTO DATE/TIME ZONE OFFSET > LM R2,R3,CVTLSO LEAP SECONDS CORRECTION > LM R0,R1,STCKGMT TOD CLOCK STCK VALUE >* >* CALCULATE LOCAL TIME = GMT TOD + CVTLDTO - CVTLSO >* > ALR R1,R15 CORRECT GMT BY LDTO > BC 8+4,TOD1 IF CARRY, > AL R0,=F'1' ADD 1 TO HOW > ALR R0,R14 ADD LDTO HOW >* >TOD1 SLR R1,R3 SUBTRACT LSO LOW > BC 2+1,TOD2 IF NO CARRY, > BCTR R0,0 SUBTRACT 1 FROM HOW > SLR R0,R2 SUBTRACT LSO HOW >* >TOD2 STM R0,R1,STCKLCL TOD CLOCK LOCAL TIME > STCKCONV STCKVAL=STCKLCL, CONVERT LOCAL TIME + > CONVVAL=LCLTIMED, TO + > TIMETYPE=DEC, HHMMSSTHMIJU0000 + > DATETYPE=YYYYMMDD YYYYMMDDXXXXXXXX > LA R1,GMTTIMED > BAS R14,HEXPRT > MVC GMTWTO+12(24),PHEX > LA R1,LCLTIMED > BAS R14,HEXPRT > MVC LCLWTO+12(24),PHEX > WTO MF=(E,GMTWTO) WTO GMT > WTO MF=(E,LCLWTO) WTO LCL > > ... > >HEXPRT UNPK PHEX+00(8+1),00(4+1,R1) > UNPK PHEX+08(8+1),04(4+1,R1) > UNPK PHEX+16(8+1),08(4+1,R1) > TR PHEX+00(24),HEXTAB-C'0' > BR R14 > >PHEX DS CL25 >GMTWTO WTO ' GMT: ....+....1....+....2....',MF=L >LCLWTO WTO ' LOCAL: ....+....1....+....2....',MF=L >STCKGMT DS D >STCKLCL DS D >LCLTIMED DS XL16 >GMTTIMED DS XL16 >HEXTAB DC C'0123456789ABCDEF' > CVT DSECT=YES CVT map > >This produces the following output today (for the Central >Daylight Savings Time Zone) [with punctuation characters >manually inserted]: > > GMT: 22:57:14.9007710000 2008/03/10 > LOCAL: 15:56:51.9007710000 2008/03/10 > >The above illustrates the fact that both the LDTO (time zone >offset) and LSO (leap seconds correction factor) have been >PROPERLY taken into account in the calculation of the local >time. Some folks get it wrong. The CVTLDTO field must be >ADDED to the GMT TOD Clock value, but the CVTLSO field must >be SUBTRACTED from the GMT TOD Clock value to get the right >local timestamp. > >> The programmer ought to be given the choice of either. > >Not an issue. It just converts whatever you give it. > >> Perhaps I'll submit an RCF. > >Not a bad idea. It would be nice if the documentation made >clear that it's just a _conversion_ service. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html