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
