>>>>>>>>>>>>>>>>>> Urspr=FCngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 27.07.05, 11:14:30, schrieb "Kasperer" <john_kasperer@[EMAIL PROTECTED]
>=20=
zum Thema Playing with STCKCONV, STCKEVAL parameter:
> Has somebody already played with STCKCONV, STCKEVAL parameter?
> 1) With a tod value equal to x'FFFFFFFFFFFFFFFF':
> STCKCONV STCKEVAL=3DETODSTMP,CONVVAL=3DTMEDTE,
> TIMETYPE=3DDEC,DATETYPE=3DMMDDYYYY
> ETODSTMP DC XL16'00FFFFFFFFFFFFFFFF00000000000000'
> Resulting time & date: 23534737 09172042 (09/17/2042)
> 2) With a larger tod value:
> STCKCONV STCKEVAL=3DETODSTMP,CONVVAL=3DTMEDTE,
> TIMETYPE=3DDEC,DATETYPE=3DMMDDYYYY
> ETODSTMP DC XL16'01000000000000001100000000000000'
> Resulting time & date: 00000000 01011900 (01/01/1900)
> Now, my impression was that STCKCONV with STCKEVAL
> was especially designed to convert tod values larger
> than 64 bits. Or did I do something wrong? Thanks.
Hello
no -- if you take a look of EIBDATE in CICS, you will see the century=20=
bit. There is a compatibility to IBM-360 systems for yaer 2000=20
problem :-)
yes -- I think, there are a lot of bits to calculate the clock. The=20
counter is designed between the cost of bits and the range to=20
calculate. :-) would you live since 2053 :-)
one other question: why does several unix-systems does there base at=20=
01.01.1971 (i think, but it can be a mistake) and take a rollover at=20=
2021 (that can be a mistake too) - its the cost of bits
so you can see: it is the count of bits, which can represent the count=20=
of TOD :-))
bitte nicht ganz so ernst nehmen (sorry, i could not say this sentence=20=
in english, i am not perfect) my answer is a - good meaning - type of=20=
comic....
Einen schoenen Tag
Andreas Lerch
--=20
some days in assembler, some days in date-/time-calculation - since=20
1976 :--))
|
