Re: Local time in C on z/OS
Thanks gil, perfect. I was trying various combinations of bpxwunix and enviroment(TZ,xxx) etc. Dana On Fri, 23 Aug 2019 14:16:12 -0500, Paul Gilmartin wrote: > >Call your Rexx exec (not the one above, which is woefully ISPF-dependent) >from .profile using command substitution, then assign and export that result. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Fri, 23 Aug 2019 14:46:03 -0400, Joe Monk wrote:
>/* get the local offset from GMT */
>days_diff = mvsvar('SYMDEF','LYR4') - mvsvar('SYMDEF','YR4')
>if days_diff = 0 then
>days_diff = mvsvar('SYMDEF','LJDAY') - mvsvar('SYMDEF','JDAY')
>
>hours_diff = mvsvar('SYMDEF','LHR') -,
>mvsvar('SYMDEF','HR') + 24 * days_diff
>
>min_diff = right(abs(mvsvar('SYMDEF','MIN') -,
>mvsvar('SYMDEF','LMIN')),2,'0')
>
>sign = substr('+-',(hours_diff < 0)+1,1)
>
>gmt_offset_hhmm = sign || right(abs(hours_diff),2,'0')min_diff
>
I don't see where that sets an environment variable. Please enlighten us.
With some trivial tailoring, that could be put in POSIX format, but
it's still not in the environment.
>On Fri, Aug 23, 2019 at 2:40 PM Dana Mitchell wrote:
>
>> We don't have C, I'd like to do something like this in REXX and run it
>> from ~/.profile or /etc/profile, but I can't figure out how to set the TZ
>> environment variable in the REXX.
Call your Rexx exec (not the one above, which is woefully ISPF-dependent)
from .profile using command substitution, then assign and export that result.
I'll note that a couple desktop systems do not set TZ in the
environment, but set a default otherwise (which POSIX allows).
Linux:
557 $ echo ${TZ-not set}; date; ls -l /etc/localtime
not set
Fri Aug 23 13:09:24 MDT 2019
lrwxrwxrwx 1 root root 34 Aug 15 17:46 /etc/localtime ->
/usr/share/zoneinfo/America/Denver
MacOS:
508 $ echo ${TZ-not set}; date; sudo systemsetup -gettimezone
not set
Fri Aug 23 13:09:22 MDT 2019
Time Zone: America/Denver
IBM ought to fall in step with the pervasive UNIX convention (yes,
not a standard) and provide for a default setting of local timezone.
IBM doesn't care.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
/* get the local offset from GMT */
days_diff = mvsvar('SYMDEF','LYR4') - mvsvar('SYMDEF','YR4')
if days_diff = 0 then
days_diff = mvsvar('SYMDEF','LJDAY') - mvsvar('SYMDEF','JDAY')
hours_diff = mvsvar('SYMDEF','LHR') -,
mvsvar('SYMDEF','HR') + 24 * days_diff
min_diff = right(abs(mvsvar('SYMDEF','MIN') -,
mvsvar('SYMDEF','LMIN')),2,'0')
sign = substr('+-',(hours_diff < 0)+1,1)
gmt_offset_hhmm = sign || right(abs(hours_diff),2,'0')min_diff
Joe
On Fri, Aug 23, 2019 at 2:40 PM Dana Mitchell wrote:
> We don't have C, I'd like to do something like this in REXX and run it
> from ~/.profile or /etc/profile, but I can't figure out how to set the TZ
> environment variable in the REXX.
>
> Dana
>
> On Sun, 18 Aug 2019 15:08:25 +0800, David Crayford
> wrote:
>
> >I once wrote some C code that sets the TZ, _TZ variables from the time
> >zone offset, leap second offset values in the CVT.
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
We don't have C, I'd like to do something like this in REXX and run it from ~/.profile or /etc/profile, but I can't figure out how to set the TZ environment variable in the REXX. Dana On Sun, 18 Aug 2019 15:08:25 +0800, David Crayford wrote: >I once wrote some C code that sets the TZ, _TZ variables from the time >zone offset, leap second offset values in the CVT. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
> I suppose that they could also have the C library provide a "default" for TZ > (if not specified) that derives it from the CVT. +1 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, August 20, 2019 11:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local time in C on z/OS David, I really like what you have done for non-POSIX environments. We have code that runs in blind-dubbed POSIX environments, and what we do is to manually read /etc/init.options and set any environment variables from there (that are not already set/overridden).Seems like a good idea for us to extend this to do what you are doing (derive TZ from CVT) in the case that it isn't already set and not set in /etc/init.options doesn't set TZ. Of course, IBM could solve many problems with usability if they chose to. My RFE seems like an obvious usability and simplification item, for this and other problems with blind-dubbed environment variables in general. I suppose that they could also have the C library provide a "default" for TZ (if not specified) that derives it from the CVT. On Tue, Aug 20, 2019 at 5:20 AM David Crayford wrote: > On 2019-08-20 1:23 AM, Paul Gilmartin wrote: > >>> ... Localtime() expects time() to have accounted for leap seconds, so > they should not > >>> appear in TZ. An example on Linux (TZ value simulated by hand): > >>> 510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date > >>> Sun Aug 18 21:45:02 IST 2019 > >>> Sun Aug 18 21:44:35 GMT 2019 > >> My code is intended to be run in environments where the TZ environment > >> variable has not been set. As it works as expected I'm not sure > >> that time() has accounted for leap seconds. > >> > > From: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 > > 4.16 Seconds Since the Epoch > > ... > > the value is related to a Coordinated Universal Time name according to > the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and > tm_year are all integer types: > > > > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + > > (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - > > ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > > ... > > As represented in seconds since the Epoch, each and every day shall be > accounted for by > > exactly 86400 seconds. > > > > (I.e. seconds since the epoch, used by time() accounts for leap > seconds. -- gil) > > Kirk Wolf already articulated the TZ issue very well in a previous post. > For C programs that are not dubbed as UNIX processes they are basically > naked so the POSIX rules don't apply. > I would love to rely on configuration but it's not possible in all > environments which is why I wrote the code to solve that problem for one > of our products. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
David, I really like what you have done for non-POSIX environments. We have code that runs in blind-dubbed POSIX environments, and what we do is to manually read /etc/init.options and set any environment variables from there (that are not already set/overridden).Seems like a good idea for us to extend this to do what you are doing (derive TZ from CVT) in the case that it isn't already set and not set in /etc/init.options doesn't set TZ. Of course, IBM could solve many problems with usability if they chose to. My RFE seems like an obvious usability and simplification item, for this and other problems with blind-dubbed environment variables in general. I suppose that they could also have the C library provide a "default" for TZ (if not specified) that derives it from the CVT. On Tue, Aug 20, 2019 at 5:20 AM David Crayford wrote: > On 2019-08-20 1:23 AM, Paul Gilmartin wrote: > >>> ... Localtime() expects time() to have accounted for leap seconds, so > they should not > >>> appear in TZ. An example on Linux (TZ value simulated by hand): > >>> 510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date > >>> Sun Aug 18 21:45:02 IST 2019 > >>> Sun Aug 18 21:44:35 GMT 2019 > >> My code is intended to be run in environments where the TZ environment > >> variable has not been set. As it works as expected I'm not sure > >> that time() has accounted for leap seconds. > >> > > From: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 > > 4.16 Seconds Since the Epoch > > ... > > the value is related to a Coordinated Universal Time name according to > the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and > tm_year are all integer types: > > > > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + > > (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - > > ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > > ... > > As represented in seconds since the Epoch, each and every day shall be > accounted for by > > exactly 86400 seconds. > > > > (I.e. seconds since the epoch, used by time() accounts for leap > seconds. -- gil) > > Kirk Wolf already articulated the TZ issue very well in a previous post. > For C programs that are not dubbed as UNIX processes they are basically > naked so the POSIX rules don't apply. > I would love to rely on configuration but it's not possible in all > environments which is why I wrote the code to solve that problem for one > of our products. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Tue, 20 Aug 2019 18:19:54 +0800, David Crayford wrote: >>> >> From:http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 >> 4.16 Seconds Since the Epoch >> ... >> As represented in seconds since the Epoch, each and every day shall be >> accounted for by >> exactly 86400 seconds. >... >For C programs that are not dubbed as UNIX processes they are basically >naked so the POSIX rules don't apply. > OK. I stand corrected: z/OS Version 2 Release 4 XL C/C++ Runtime Library Reference IBM SC14-7314-40 ... time(),time64() — Determine current UTC time ... Standards ISO C POSIX.1 XPG4 XPG4.2 C99 Single UNIX Specification, Version 3 Language Environment ... time() returns the current value of the time-of-day (TOD) clock value obtained with the STCK instruction, rounded off to the nearest second, and normalized to the POSIX Epoch, January 1, 1970. The TOD clock value does not account for leap seconds. If you need more accuracy, use the STCK instruction or the TIME macro which does account for leap seconds using whatever value the system operator has entered for number of leap seconds in the CVT field. I'm astonished and dismayed. This directly contradicts the POSIX requirement I excerpted above. Has no one complained? At least they could remove the duplicitous mention of POSIX. I think I'll submit an RCF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On 2019-08-20 1:23 AM, Paul Gilmartin wrote: ... Localtime() expects time() to have accounted for leap seconds, so they should not appear in TZ. An example on Linux (TZ value simulated by hand): 510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date Sun Aug 18 21:45:02 IST 2019 Sun Aug 18 21:44:35 GMT 2019 My code is intended to be run in environments where the TZ environment variable has not been set. As it works as expected I'm not sure that time() has accounted for leap seconds. From:http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 4.16 Seconds Since the Epoch ... the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 ... As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. (I.e. seconds since the epoch, used by time() accounts for leap seconds. -- gil) Kirk Wolf already articulated the TZ issue very well in a previous post. For C programs that are not dubbed as UNIX processes they are basically naked so the POSIX rules don't apply. I would love to rely on configuration but it's not possible in all environments which is why I wrote the code to solve that problem for one of our products. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Mon, 19 Aug 2019 18:54:13 +, Jon Perryman wrote: > Paul, the iana.org time database is one of many attempts at solving the time > issue. Databases and other multi-user products have their own implementations > to deal with their specific situation. Mysql is open source so you can see > their implementation. > At: https://dev.mysql.com/downloads/timezones.html I read: Please don't use this package if your system includes zoneinfo files (e.g. Linux, FreeBSD, Sun Solaris) So, apparently MySQL chooses to use the iana.org time database where available, like those systems named and most of the civilized world. >For the difficult situations, we just accept an acceptable solution. > "Acceptable" is subjective (as is "better"). Here, I'd go with the majority's choice, not IBM's. >On Saturday, August 17, 2019, 08:05:22 PM PDT, Paul Gilmartin wrote: > >This is addressed by: https://www.iana.org/time-zones -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Paul, the iana.org time database is one of many attempts at solving the time issue. Databases and other multi-user products have their own implementations to deal with their specific situation. Mysql is open source so you can see their implementation. For the difficult situations, we just accept an acceptable solution. Jon. On Saturday, August 17, 2019, 08:05:22 PM PDT, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: On Sat, 17 Aug 2019 23:43:34 +, Jon Perryman wrote: > If time were as simple to solve as UTC and a 1 byte UTC offset, then this > problem would have been solved a long time ago. As I said before, everyone > assumes the time zone is fixed. What happens when the time zone is at the > time the data is reference instead of created. > This is addressed by: https://www.iana.org/time-zones >As for localtime better than the z/OS implementation, that's silly. First, bad >is still bad. Second, C local time is a language feature instead of OS >feature. > Only because you call it so. The TIME macro is a language (HLASM) feature instead of OS feature. Third, it was designed around a specific Unix feature (environment variables). It needs redesign for use in CICS, IMS and most z/OS components. > There are other ways to pass such a parameter. It could be a PARMLIB entry. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Mon, 19 Aug 2019 17:09:22 +0800, David Crayford wrote: >>> ... >>> // set the time zone offset and apply the leap second offset >>> int64_t ldto = cvt->cvtext2->cvtldto - cvt->cvtext2->cvtlso + adjust; >>> >> Is this intended to be used with localtime() and strftime()? Localtime() > >Yes, and it works perfectly :) > >> ... Localtime() expects time() to have accounted for leap seconds, so they >> should not >> appear in TZ. An example on Linux (TZ value simulated by hand): >> 510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date >> Sun Aug 18 21:45:02 IST 2019 >> Sun Aug 18 21:44:35 GMT 2019 > >My code is intended to be run in environments where the TZ environment >variable has not been set. As it works as expected I'm not sure >that time() has accounted for leap seconds. > From: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 4.16 Seconds Since the Epoch ... the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 ... As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. (I.e. seconds since the epoch, used by time() accounts for leap seconds. -- gil) My employers briefly enabled leap seconds by setting the IBM-recommended value in CVTLSO. Legacy code and products from vendors were so inconsistent that they regressed to setting TOD to UTC and CVTLSO=0. IBM fixed such an error in IEBCOPY by PTF in response to my APAR. Have you tested in an environment where CVTLSO is nonzero? >> ... Also, the zone name, GMT, is wrong. Correct is IST. > >Does IST work on z/OS? > If TZ is set to the correct POSIX value, "IST-5:30", rather than a crudely synthesized value, it should. >> What happens if a DST transition, or even a leap second, occurs between >> such a setting of TZ and your program's formatting of current time? > >For our purposes we don't need to be that robust so we don't care :) > For general purposes, a user might want better, as non-IBM systems provide. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On 2019-08-19 12:41 AM, Paul Gilmartin wrote:
I once wrote some C code that sets the TZ, _TZ variables from the time
zone offset, leap second offset values in the CVT.
...
// set the time zone offset and apply the leap second offset
int64_t ldto = cvt->cvtext2->cvtldto - cvt->cvtext2->cvtlso + adjust;
Is this intended to be used with localtime() and strftime()? Localtime()
Yes, and it works perfectly :)
expects time() to have accounted for leap seconds, so they should not
appear in TZ. An example on Linux (TZ value simulated by hand):
510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date
Sun Aug 18 21:45:02 IST 2019
Sun Aug 18 21:44:35 GMT 2019
My code is intended to be run in environments where the TZ environment
variable has not been set. As it works as expected I'm not sure
that time() has accounted for leap seconds.
... I claim the former is correct. Also, the zone name, GMT, is wrong.
Correct is IST.
Does IST work on z/OS?
...
// if minutes have been specified then calculate them
uint64_t mins = ldto % STCK_UNIT_HOUR;
( My C skill fails me. What kind of statement is that? An assignment?
I'd not expect two tokens left of "=". A cast? I'd expect "( ... )", and
a cast has no L-value. A declaration with initialization? It would be out
of place. )
compile it using C99:
c99 -o settimezone settimezone.c
What happens if a DST transition, or even a leap second, occurs between
such a setting of TZ and your program's formatting of current time?
For our purposes we don't need to be that robust so we don't care :)
...
setenv("TZ", tzone, 1); // for POSIX
setenv("_TZ", tzone, 1); // for non-POSIX
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
A variable declaration. They can come anywhere (more or less) in C++, not just
at the start of a block. I guess David should have written "I once wrote some
C++ code that sets ..." The slash-slash comments might have been a giveaway,
but some C compilers do have an option to allow those.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Sunday, August 18, 2019 10:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS
On Sun, 18 Aug 2019 10:17:49 -0700, Charles Mills wrote:
>
>It is a type declaration. Uint64_t is a type of integer, like long or short.
>Picture int mins = whatever;
>
You mean a variable declaration with initialization? I'd not expect that
in the middle of executable code.
Or a type definition such as?:
typedef enum{ False, True } Boolean;
On Sun, 18 Aug 2019 15:08:25 +0800, David Crayford wrote:=
>...
> tz_offset_hours = ldto / STCK_UNIT_HOUR;/* Assignment; executable.
> [gil] */
> // if minutes have been specified then calculate them
> uint64_t mins = ldto % STCK_UNIT_HOUR;/* Declaration?? WTF!? [gil]
> */
> ...
Clearly, I'm still confused.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Sun, 18 Aug 2019 10:17:49 -0700, Charles Mills wrote:
>
>It is a type declaration. Uint64_t is a type of integer, like long or short.
>Picture int mins = whatever;
>
You mean a variable declaration with initialization? I'd not expect that
in the middle of executable code.
Or a type definition such as?:
typedef enum{ False, True } Boolean;
On Sun, 18 Aug 2019 15:08:25 +0800, David Crayford wrote:=
>...
> tz_offset_hours = ldto / STCK_UNIT_HOUR;/* Assignment; executable.
> [gil] */
> // if minutes have been specified then calculate them
> uint64_t mins = ldto % STCK_UNIT_HOUR;/* Declaration?? WTF!? [gil]
> */
> ...
Clearly, I'm still confused.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
> I'd not expect two tokens left of "=". A cast? I'd expect "( ... )", and a
> cast has no L-value.
It is a type declaration. Uint64_t is a type of integer, like long or short.
Picture int mins = whatever;
> Why do those names need to be different? Conway's law?
Ask IBM, not David LOL! They just are.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Sunday, August 18, 2019 9:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS
On Sun, 18 Aug 2019 15:08:25 +0800, David Crayford wrote:
>I once wrote some C code that sets the TZ, _TZ variables from the time
>zone offset, leap second offset values in the CVT.
>...
> // set the time zone offset and apply the leap second offset
> int64_t ldto = cvt->cvtext2->cvtldto - cvt->cvtext2->cvtlso + adjust;
>
Is this intended to be used with localtime() and strftime()? Localtime()
expects time() to have accounted for leap seconds, so they should not
appear in TZ. An example on Linux (TZ value simulated by hand):
510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date
Sun Aug 18 21:45:02 IST 2019
Sun Aug 18 21:44:35 GMT 2019
... I claim the former is correct. Also, the zone name, GMT, is wrong.
Correct is IST.
> ...
> // if minutes have been specified then calculate them
> uint64_t mins = ldto % STCK_UNIT_HOUR;
>
( My C skill fails me. What kind of statement is that? An assignment?
I'd not expect two tokens left of "=". A cast? I'd expect "( ... )", and
a cast has no L-value. A declaration with initialization? It would be out
of place. )
What happens if a DST transition, or even a leap second, occurs between
such a setting of TZ and your program's formatting of current time?
>...
> setenv("TZ", tzone, 1); // for POSIX
> setenv("_TZ", tzone, 1); // for non-POSIX
>
Why do those names need to be different? Conway's law?
A Modest Proposal: Isn't the HMC a PC running Linux? Shouldn't
it have zoneinfo installed. Then the last line of each zoneinfo
entry is the POSIX-formatted TZ string. Examples from my
desktop Linux guest:
505 $ cd /usr/share/zoneinfo
506 $ tail -1 America/New_York
EST5EDT,M3.2.0,M11.1.0
507 $ tail -1 Australia/Canberra
AEST-10AEDT,M10.1.0,M4.1.0/3
512 $ tail -1 Asia/Calcutta
IST-5:30
508 $ ls -l /etc/localtime
lrwxrwxrwx 1 root root 34 Aug 15 17:46 /etc/localtime ->
/usr/share/zoneinfo/America/Denver
509 $ tail -1 /etc/localtime
MST7MDT,M3.2.0,M11.1.0
Wouldn't it be great if HMC passed such a string to z/OS UNIX
at startup, to be used in formatting times elsewhere? The
syntax is such that it could easily be parsed as a source for
CVTLDTO, etc., so everything could be set once, consistently,
in a human-friendly format, on the HMC.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Sun, 18 Aug 2019 15:08:25 +0800, David Crayford wrote:
>I once wrote some C code that sets the TZ, _TZ variables from the time
>zone offset, leap second offset values in the CVT.
>...
> // set the time zone offset and apply the leap second offset
> int64_t ldto = cvt->cvtext2->cvtldto - cvt->cvtext2->cvtlso + adjust;
>
Is this intended to be used with localtime() and strftime()? Localtime()
expects time() to have accounted for leap seconds, so they should not
appear in TZ. An example on Linux (TZ value simulated by hand):
510 $ TZ=Asia/Calcutta date; TZ=GMT-5:29:33 date
Sun Aug 18 21:45:02 IST 2019
Sun Aug 18 21:44:35 GMT 2019
... I claim the former is correct. Also, the zone name, GMT, is wrong.
Correct is IST.
> ...
> // if minutes have been specified then calculate them
> uint64_t mins = ldto % STCK_UNIT_HOUR;
>
( My C skill fails me. What kind of statement is that? An assignment?
I'd not expect two tokens left of "=". A cast? I'd expect "( ... )", and
a cast has no L-value. A declaration with initialization? It would be out
of place. )
What happens if a DST transition, or even a leap second, occurs between
such a setting of TZ and your program's formatting of current time?
>...
> setenv("TZ", tzone, 1); // for POSIX
> setenv("_TZ", tzone, 1); // for non-POSIX
>
Why do those names need to be different? Conway's law?
A Modest Proposal: Isn't the HMC a PC running Linux? Shouldn't
it have zoneinfo installed. Then the last line of each zoneinfo
entry is the POSIX-formatted TZ string. Examples from my
desktop Linux guest:
505 $ cd /usr/share/zoneinfo
506 $ tail -1 America/New_York
EST5EDT,M3.2.0,M11.1.0
507 $ tail -1 Australia/Canberra
AEST-10AEDT,M10.1.0,M4.1.0/3
512 $ tail -1 Asia/Calcutta
IST-5:30
508 $ ls -l /etc/localtime
lrwxrwxrwx 1 root root 34 Aug 15 17:46 /etc/localtime ->
/usr/share/zoneinfo/America/Denver
509 $ tail -1 /etc/localtime
MST7MDT,M3.2.0,M11.1.0
Wouldn't it be great if HMC passed such a string to z/OS UNIX
at startup, to be used in formatting times elsewhere? The
syntax is such that it could easily be parsed as a source for
CVTLDTO, etc., so everything could be set once, consistently,
in a human-friendly format, on the HMC.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
"It needs redesign for use in CICS, IMS and most z/OS components."
The time in CICS can be gotten in C very easily:
"EXEC CICS ASKTIME ABSTIME(utime)"
C char data_area[8];
ABSTIME(data-area) Specifies the data area for the number of milliseconds
since 00:00 on 1 January 1900, which is known as absolute time. The time is
taken from the system time-of-day clock, adjusted for leap seconds and to
apply the local timezone offset (including daylight saving time), truncated
to the millisecond, and returned as a packed decimal of length 8 bytes.
You can then get the time in any format:
EXEC CICS FORMATTIME ABSTIME(utime)
DATESEP('-') DDMMYY(date)
TIME(time) TIMESEP(':')
Joe
On Sat, Aug 17, 2019 at 11:05 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Sat, 17 Aug 2019 23:43:34 +, Jon Perryman wrote:
>
> > If time were as simple to solve as UTC and a 1 byte UTC offset, then
> this problem would have been solved a long time ago. As I said before,
> everyone assumes the time zone is fixed. What happens when the time zone is
> at the time the data is reference instead of created.
> >
> This is addressed by: https://www.iana.org/time-zones
>
> >As for localtime better than the z/OS implementation, that's silly.
> First, bad is still bad. Second, C local time is a language feature instead
> of OS feature.
> >
> Only because you call it so. The TIME macro is a language (HLASM) feature
> instead of OS feature.
>
> Third, it was designed around a specific Unix feature (environment
> variables). It needs redesign for use in CICS, IMS and most z/OS
> components.
> >
> There are other ways to pass such a parameter. It could be a PARMLIB
> entry.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
I once wrote some C code that sets the TZ, _TZ variables from the time
zone offset, leap second offset values in the CVT.
#define STCK_UNIT_HOUR 0xD693A40LLU
#define STCK_UNIT_MIN 0x393870LLU
#define STCK_UNIT_SEC 0xF424LLU
void set_time_zone(int64_t adjust) {
char tzone[30] = "GMT";
char sign = '+';
int tz_offset_hours = 0;
int tz_offset_mins = 0;
int tz_offset_secs = 0;
// get the time zone offset from the CVT
const CVT * cvt = *((CVT **)CVTPTR);
// set the time zone offset and apply the leap second offset
int64_t ldto = cvt->cvtext2->cvtldto - cvt->cvtext2->cvtlso + adjust;
// if the time set offset is 0 (GMT) then no need to continue. But
// still set the time zone to GMT just in case the operator has changed
// the system clock with a console command.
if (ldto != 0) {
if (ldto < 0) {
sign = '+'; // west of the meridian
ldto = -ldto; // make it positive for the divide
}
else {
sign = '-'; // east of the meridian
}
tz_offset_hours = ldto / STCK_UNIT_HOUR;
// if minutes have been specified then calculate them
uint64_t mins = ldto % STCK_UNIT_HOUR;
if (mins > 0) {
tz_offset_mins = mins / STCK_UNIT_MIN;
// if seconds have been specified then calculate them
uint64_t secs = mins % STCK_UNIT_MIN;
if (secs > 0) {
tz_offset_secs = secs / STCK_UNIT_SEC;
}
}
// format the environment variable and set the time zone
sprintf(tzone, "GMT%c%d:%d:%d",
sign, tz_offset_hours, tz_offset_mins, tz_offset_secs);
}
setenv("TZ", tzone, 1); // for POSIX
setenv("_TZ", tzone, 1); // for non-POSIX
tzset();
}
On 2019-08-16 8:22 AM, Charles Mills wrote:
The Dignus runtime main() start-up from a BATCH or TSO start examines the
CVTTZ value and constructs a TZ that offers the proper offset
Good approach IMHO. I know I tried doing that and ran into some sort of
issue.
The fact is that the LE approach is poor. I don't say that because I am a
configuration genius and could have done better. I say that because in 8
years of supporting an STC written in C++ we encountered customer after
customer with whom we had the following dialog:
"Your product is broken. The times are wrong."
"You just need to set the local time offset in /etc/whatever."
"No, we have the local offset. Every other product gets it right. Your
product is broken."
"That's in CLOCKxx. You need to set the local time zone variable with ENVAR
in /etc/whatever."
"Why should we have to do that. Every other product gets it right. Your
product is broken."
The default for USS startup should be the offset in SYS1.PARMLIB(CLOCKxx),
and let UNIX-sophisticated customers override that as they wish.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Thursday, August 15, 2019 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS
Phil Smith III wrote:
I have a C POSIX application that writes timestamps on its output. It's
always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly,
so I thought maybe I could fix it.
The fundamental problem with "local time" is the definition of "local".
If we make the assumption that the machine clock is kept in UTC (GMT), then
the local time is simply the different from UTC to where one might be at
that
moment on the globe.
Now - consider the problem of a terminal connected to a fairly remote
system.
The user may consider himself in a different timezone from the system; hence
his idea of "local" is different than the, say, the operator console
which happens
to be physically adjacent to the actual hardware device that keeps track
of the
time.
This is why UNIX/POSIX has the TZ environment variable - one user can set a
different timezone than another. And this is also why a "global"
setting of
TZ in, say, /etc/rc isn't always the right idea. You may have multiple
users in
multiple timezones.
Some systems might go as far as keeping a database of sorts for
terminals, and
having the /etc/rc script make a good guess as to what the proper TZ setting
might be.
This is also why the ssh (and other remote-connect-over-the-internet
protocols)
have mechanisms for passing the value of the TZ environment variable to the
remote shell. The user connecting can say "hey - when you connect, set
this
to be my TZ value."
All that is well and good - but then we run into the problem of programs
being
dub'd without going thru the typical UNIX start-up... what TZ should
they get then?
The Dignus runtime main() start-up from a BATCH or TSO start examines
the CVTTZ
value and constructs a TZ that offers the proper offset from UTC (again,
this assumes
the machine's clock is set to UTC and that CVTT
Re: Local time in C on z/OS
On Sat, 17 Aug 2019 23:43:34 +, Jon Perryman wrote: > If time were as simple to solve as UTC and a 1 byte UTC offset, then this > problem would have been solved a long time ago. As I said before, everyone > assumes the time zone is fixed. What happens when the time zone is at the > time the data is reference instead of created. > This is addressed by: https://www.iana.org/time-zones >As for localtime better than the z/OS implementation, that's silly. First, bad >is still bad. Second, C local time is a language feature instead of OS >feature. > Only because you call it so. The TIME macro is a language (HLASM) feature instead of OS feature. Third, it was designed around a specific Unix feature (environment variables). It needs redesign for use in CICS, IMS and most z/OS components. > There are other ways to pass such a parameter. It could be a PARMLIB entry. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
If time were as simple to solve as UTC and a 1 byte UTC offset, then this problem would have been solved a long time ago. As I said before, everyone assumes the time zone is fixed. What happens when the time zone is at the time the data is reference instead of created. As for localtime better than the z/OS implementation, that's silly. First, bad is still bad. Second, C local time is a language feature instead of OS feature. Third, it was designed around a specific Unix feature (environment variables). It needs redesign for use in CICS, IMS and most z/OS components. Jon. On Friday, August 16, 2019, 07:42:44 AM PDT, Seymour J Metz wrote: IMHO the right way is to log both the time in UTC and the local zone offset. From: Paul Gilmartin On Thu, 15 Aug 2019 23:11:48 +, Jon Perryman wrote: > >C offer's localtime and UTC but not z/OS time. The OP wants the z/OS time. > As the OP observed, localtime is not well defined; worst on z/OS. >"where are you" is too simplistic. Time is relative to the problem being >solved. C and z/OS take the simplistic approach that there is a single time >zone involved. C assumes this time zone is customizable where as z/OS has a >single timezone for the system. The C assumption works well for Unix where >user's run their programs in a process. This paradigm starts having problems >in products such as SAP, Peoplesoft and others. I suspect IBM decided on a >single timezone because z/OS encounters these types of issues. > "single"? Doesn't z/OS provide two? There's a right way to address this problem. Such products should log UTC, which is always available. Conversion for display at the users' discretion. Enforcing standards for such as printed reports is a management issue, not a systems issue. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Seymour J Metz wrote: >IMHO the right way is to log both the time in UTC and the local zone offset. I don't even disagree with that, although it's a bit late for me to change this particular item (and it's just debugging info, not likely to matter; the issue was that people either look at it instantly, in which case the timestamps don't matter, or they look at it much later, in which case they're trying to map it to something in the system log, and then the offset is confusing). I'd note (not Shmuel's fault!) that this suggestion still would have left me with the original problem: getting the MVS time! (Which, I agree, is a better term than "local time".) Again, thanks to those who led me to salvation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
[SUSPECTED SPAM] Re: Local time in C on z/OS
On 2019-08-16 10:42, Seymour J Metz wrote: IMHO the right way is to log both the time in UTC and the local zone offset. +1 -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
IMHO the right way is to log both the time in UTC and the local zone offset. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Thursday, August 15, 2019 7:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local time in C on z/OS On Thu, 15 Aug 2019 23:11:48 +, Jon Perryman wrote: > >C offer's localtime and UTC but not z/OS time. The OP wants the z/OS time. > As the OP observed, localtime is not well defined; worst on z/OS. >"where are you" is too simplistic. Time is relative to the problem being >solved. C and z/OS take the simplistic approach that there is a single time >zone involved. C assumes this time zone is customizable where as z/OS has a >single timezone for the system. The C assumption works well for Unix where >user's run their programs in a process. This paradigm starts having problems >in products such as SAP, Peoplesoft and others. I suspect IBM decided on a >single timezone because z/OS encounters these types of issues. > "single"? Doesn't z/OS provide two? There's a right way to address this problem. Such products should log UTC, which is always available. Conversion for display at the users' discretion. Enforcing standards for such as printed reports is a management issue, not a systems issue. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
> The Dignus runtime main() start-up from a BATCH or TSO start examines the CVTTZ value and constructs a TZ that offers the proper offset Good approach IMHO. I know I tried doing that and ran into some sort of issue. The fact is that the LE approach is poor. I don't say that because I am a configuration genius and could have done better. I say that because in 8 years of supporting an STC written in C++ we encountered customer after customer with whom we had the following dialog: "Your product is broken. The times are wrong." "You just need to set the local time offset in /etc/whatever." "No, we have the local offset. Every other product gets it right. Your product is broken." "That's in CLOCKxx. You need to set the local time zone variable with ENVAR in /etc/whatever." "Why should we have to do that. Every other product gets it right. Your product is broken." The default for USS startup should be the offset in SYS1.PARMLIB(CLOCKxx), and let UNIX-sophisticated customers override that as they wish. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Thomas David Rivers Sent: Thursday, August 15, 2019 1:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local time in C on z/OS Phil Smith III wrote: >I have a C POSIX application that writes timestamps on its output. It's always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I thought maybe I could fix it. > > > > The fundamental problem with "local time" is the definition of "local". If we make the assumption that the machine clock is kept in UTC (GMT), then the local time is simply the different from UTC to where one might be at that moment on the globe. Now - consider the problem of a terminal connected to a fairly remote system. The user may consider himself in a different timezone from the system; hence his idea of "local" is different than the, say, the operator console which happens to be physically adjacent to the actual hardware device that keeps track of the time. This is why UNIX/POSIX has the TZ environment variable - one user can set a different timezone than another. And this is also why a "global" setting of TZ in, say, /etc/rc isn't always the right idea. You may have multiple users in multiple timezones. Some systems might go as far as keeping a database of sorts for terminals, and having the /etc/rc script make a good guess as to what the proper TZ setting might be. This is also why the ssh (and other remote-connect-over-the-internet protocols) have mechanisms for passing the value of the TZ environment variable to the remote shell. The user connecting can say "hey - when you connect, set this to be my TZ value." All that is well and good - but then we run into the problem of programs being dub'd without going thru the typical UNIX start-up... what TZ should they get then? The Dignus runtime main() start-up from a BATCH or TSO start examines the CVTTZ value and constructs a TZ that offers the proper offset from UTC (again, this assumes the machine's clock is set to UTC and that CVTTZ is properly set.) This basically gives you a "local time" for the machine, the user would need to set TZ to something else if they are not in the same locality as the machine. Under a USS start-up, we inherit the TZ environment variable from the BPX environment. Thus - the entire question about "what time is it" is totally answered when you can reliably answer the question of "where are you?" - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Thu, 15 Aug 2019 16:56:32 -0400, Thomas David Rivers wrote: >... >The Dignus runtime main() start-up from a BATCH or TSO start examines the CVTTZ >value and constructs a TZ that offers the proper offset from UTC (again,this >assumes >the machine's clock is set to UTC and that CVTTZ is properly set.) This >basically > According to the PoOp, the proper setting for the machine clock is not UTC but TAI minus 10 seconds. Sometimes a half-minute (and growing) matters. What happens if that startup and the program's STCK straddle a Daylight Saving boundary? >gives you a "local time" for the machine, the user would need to set TZ to >something >else if they are not in the same locality as the machine. Under a USS >start-up, we >inherit the TZ environment variable from the BPX environment. > >Thus - the entire question about "what time is it" is totally answered when you >can reliably answer the question of "where are you?" > Which can be complicated. Arizona, sort of within Mountain time, does not observe DST. The Navajo Nation, mostly within AZ observes DST. The Hopi Reservation, an enclave entirely surrounded by the Navajo Nation follows the AZ convention. Things are worse for the Autonomous Republic of Crimea. IBM really ought to: o Provide initialization of TZ in all cases. o Provide a single point of control for /etc/rc, /etc/init.options, CVTTZ, and CVTLDTO so they don't get out of sync because of careless sysadmins. IBM doesn't care. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
You left off the rest ... This function is sensitive to time zone information which is provided by: - The TZ environmental variable when POSIX(ON) and TZ is correctly defined, or by the _TZ environmental variable when POSIX(OFF) and _TZ is correctly defined. - The LC_TOD category of the current locale if POSIX(OFF) or TZ is not defined. Joe On Thu, Aug 15, 2019 at 2:22 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 15 Aug 2019 14:07:42 -0400, Joe Monk wrote: > > >Code is right here > > > > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm > > > Which says: > ... > 1. This function is sensitive to time zone information ... > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
And did not work for the OPoster, hence the OPost. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, August 15, 2019 11:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local time in C on z/OS On Thu, 15 Aug 2019 14:07:42 -0400, Joe Monk wrote: >Code is right here > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm > Which says: ... 1. This function is sensitive to time zone information ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Thu, 15 Aug 2019 14:07:42 -0400, Joe Monk wrote: >Code is right here > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm > Which says: ... 1. This function is sensitive to time zone information ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Code is right here
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxbd00/localt.htm
/* CELEBL07
This example queries the system clock and displays the local time.
*/
#include
#include
int main(void)
{
struct tm *newtime;
time_t ltime;
time();
newtime = localtime();
printf("The date and time is %s", asctime(newtime));
}
On Thu, Aug 15, 2019 at 12:49 PM Phil Smith III wrote:
> Jon Perryman wrote:
>
> >The op wants the machine local time as seen in the system log instead of
>
> >all the exceptions that are allowed in the C standard. If the op doesn't
>
> >get an acceptable solution, then call the assembler macro's directly
>
> >from C.. It's a simple call to time or whatever macro you need.
>
>
>
> Yep, that's where I wound up. Sort of amazing that 50 years after OS/360,
> there's no standard way to get the current time as hh:mm:ss. How many
> thousands of us have had to write that same code.
>
>
>
> Thanks to all who helped!
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
IBM seems to have a unique ability to make complicated the inherently simple. "Alexa, what time is it?" "The time is ten twenty-eight AM." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Thursday, August 15, 2019 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Local time in C on z/OS Jon Perryman wrote: >The op wants the machine local time as seen in the system log instead of >all the exceptions that are allowed in the C standard. If the op doesn't >get an acceptable solution, then call the assembler macro's directly >from C.. It's a simple call to time or whatever macro you need. Yep, that's where I wound up. Sort of amazing that 50 years after OS/360, there's no standard way to get the current time as hh:mm:ss. How many thousands of us have had to write that same code. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Jon Perryman wrote: >The op wants the machine local time as seen in the system log instead of >all the exceptions that are allowed in the C standard. If the op doesn't >get an acceptable solution, then call the assembler macro's directly >from C.. It's a simple call to time or whatever macro you need. Yep, that's where I wound up. Sort of amazing that 50 years after OS/360, there's no standard way to get the current time as hh:mm:ss. How many thousands of us have had to write that same code. Thanks to all who helped! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Are you POSIX ON or OFF? For POSIX OFF the variable is named _TZ . Try that.
Check the return code from setenv(). Unlikely it is failing, but who knows?
My notes indicate that the environment variable timezone_name *may* be
needed.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Thursday, August 15, 2019 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Local time in C on z/OS
Gil provided a promising-looking code snippet, which I tried. Alas, no
change! (I did have to fix the %s to %S, so I'm 100% sure I picked up the
change-I'm cross-compiling using Dignus, which always adds that bit of
vagary: did you get the right object? Etc.).
I don't think I missed anything (I'm still forcing CST6CDT; once I get it
working, I'll worry about how to set that):
time_t ltime;
static char hhmmss[9];
struct tm *tmptr;
time(); /* Get the time */
setenv("TZ","CST6CDT",1);
tzset();
tmptr = localtime(); /* Convert to local time */
strftime( hhmmss, 9, "%H:%M:%S\0", tmptr );
return(hhmmss);/* Return the hh:mm:ss */
I still get GMT. This is making me feel VERY stupid. I will look at using
MVS TIME next.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
The op wants the machine local time as seen in the system log instead of all
the exceptions that are allowed in the C standard. If the op doesn't get an
acceptable solution, then call the assembler macro's directly from C.. It's a
simple call to time or whatever macro you need.
As mentioned before, time is complicated. z/OS adds machine local time as
displayed in syslog and most other places.
Jon.
On Wednesday, August 14, 2019, 07:24:47 PM PDT, Kirk Wolf
wrote:
IMO, the underlying problem with z/OS Unix localtime() is that environment
variable initialization is brain dead in z/OS. In other Unix/Posix
implementations, /etc/rc initializes environment variables for the "init"
process (usually pid=1). All other processes inherit from it.
In z/OS, along with /etc/rc there is /etc/init.options which initializes
the environment for the init process, but only *some* z/OS Unix processes
inherit from it.
z/OS Unix Processes that are "blind dubbed" do not. These include normal
batch jobs and started tasks that use z/OS Unix services.
What does this mean? Well, you should be able to set TZ in /etc/rc or
/etc/init.options and have *all* processes inherit it in their
environment. Then all of the localtime() calls get the same system
default timezone. from one place.
In z/OS however, you have to manually configure TZ for each job that
doesn't inherit its environment from the init process. This can cause
all sorts of problems in z/OS Unix, but TZ is an easy one to understand.
(BTW: You only need to call tzset() if you want to change the current
process' timezone after the process starts).
I submitted this RFE back in 2014, and it was marked "uncommitted
candidate" in 2016, but it doesn't look to me like it made it into V2R4.
So I'm not holding my breath.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=59716
On Wed, Aug 14, 2019 at 8:06 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 14 Aug 2019 18:48:22 -0400, Phil Smith III
> wrote:
>
> >Poked around some more, found
> >
> >
> https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
> >
> >which looked promising, but this:
> > [ ... ]
> A few suggestions:
> Do you also need the date? That should be derived from the same
> call to time(); lest midnight intrude.
>
> 615 $ cat when.c
> #include
> #include
> #include
> #include
>
> time_t ltime;
>
> static char hhmmss[9];
>
> struct tm *tmptr;
>
> int main( int argc, char **argv ) {
> time();
>
> if ( ! getenv( "TZ" ) ) /* Support caller's setting of TZ. */
> setenv("TZ","CST6CDT",1);
>
> tzset();
>
> tmptr = localtime();
>
> /* timeptr = asctime(tmptr);
> memcpy(, timeptr+11, 8);
> hhmmss[8] = 0;
> Deprecated; see
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html#tag_16_21_07
> So: */
> strftime( hhmmss, 9, "%H:%M:%s\0", tmptr );
>
> printf( "%s\n", hhmmss); /* show result. */
> return( 0 );
> }
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Gil provided a promising-looking code snippet, which I tried. Alas, no change!
(I did have to fix the %s to %S, so I'm 100% sure I picked up the change-I'm
cross-compiling using Dignus, which always adds that bit of vagary: did you get
the right object? Etc.).
I don't think I missed anything (I'm still forcing CST6CDT; once I get it
working, I'll worry about how to set that):
time_t ltime;
static char hhmmss[9];
struct tm *tmptr;
time(); /* Get the time */
setenv("TZ","CST6CDT",1);
tzset();
tmptr = localtime(); /* Convert to local time */
strftime( hhmmss, 9, "%H:%M:%S\0", tmptr );
return(hhmmss);/* Return the hh:mm:ss */
I still get GMT. This is making me feel VERY stupid. I will look at using MVS
TIME next.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
You can supply TZ via JCL parm, (LE) parm or OVMS shell variable or /etc/init or /etc/rc -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, August 14, 2019 5:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Local time in C on z/OS I have a C POSIX application that writes timestamps on its output. It's always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I thought maybe I could fix it. Looking at the code, it's using ctime(). Ok, hey, localtime() should be gooderT! Nope, per IBM doc: * The ctime(), localtime(), and mktime() functions now return Coordinated Universal Time (UTC) unless customized locale information is made available, which includes setting the timezone_name variable. * In POSIX you can supply the necessary information by using environment variables. Gee, thanks (and what does "now" mean in that first sentence? As opposed to tomorrow?? Last week???). I'm not in a position to set environment variables for this. I know the hardware is set to UTC, but there's a system timezone offset at some level. Is there no simple way to just say "Gimme the same time as the operator's console would show"? Searching sure hasn't found one, hoping someone knows better! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
IMO, the underlying problem with z/OS Unix localtime() is that environment
variable initialization is brain dead in z/OS. In other Unix/Posix
implementations, /etc/rc initializes environment variables for the "init"
process (usually pid=1). All other processes inherit from it.
In z/OS, along with /etc/rc there is /etc/init.options which initializes
the environment for the init process, but only *some* z/OS Unix processes
inherit from it.
z/OS Unix Processes that are "blind dubbed" do not. These include normal
batch jobs and started tasks that use z/OS Unix services.
What does this mean? Well, you should be able to set TZ in /etc/rc or
/etc/init.options and have *all* processes inherit it in their
environment. Then all of the localtime() calls get the same system
default timezone. from one place.
In z/OS however, you have to manually configure TZ for each job that
doesn't inherit its environment from the init process.This can cause
all sorts of problems in z/OS Unix, but TZ is an easy one to understand.
(BTW: You only need to call tzset() if you want to change the current
process' timezone after the process starts).
I submitted this RFE back in 2014, and it was marked "uncommitted
candidate" in 2016, but it doesn't look to me like it made it into V2R4.
So I'm not holding my breath.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=59716
On Wed, Aug 14, 2019 at 8:06 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 14 Aug 2019 18:48:22 -0400, Phil Smith III
> wrote:
>
> >Poked around some more, found
> >
> >
> https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
> >
> >which looked promising, but this:
> > [ ... ]
> A few suggestions:
> Do you also need the date? That should be derived from the same
> call to time(); lest midnight intrude.
>
> 615 $ cat when.c
> #include
> #include
> #include
> #include
>
> time_t ltime;
>
> static char hhmmss[9];
>
> struct tm *tmptr;
>
> int main( int argc, char **argv ) {
>time();
>
>if ( ! getenv( "TZ" ) ) /* Support caller's setting of TZ. */
>setenv("TZ","CST6CDT",1);
>
>tzset();
>
>tmptr = localtime();
>
> /* timeptr = asctime(tmptr);
>memcpy(, timeptr+11, 8);
>hhmmss[8] = 0;
>Deprecated; see
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html#tag_16_21_07
>So: */
>strftime( hhmmss, 9, "%H:%M:%s\0", tmptr );
>
>printf( "%s\n", hhmmss); /* show result. */
>return( 0 );
> }
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Wed, 14 Aug 2019 18:48:22 -0400, Phil Smith III wrote:
>Poked around some more, found
>
>https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
>
>which looked promising, but this:
> [ ... ]
A few suggestions:
Do you also need the date? That should be derived from the same
call to time(); lest midnight intrude.
615 $ cat when.c
#include
#include
#include
#include
time_t ltime;
static char hhmmss[9];
struct tm *tmptr;
int main( int argc, char **argv ) {
time();
if ( ! getenv( "TZ" ) ) /* Support caller's setting of TZ. */
setenv("TZ","CST6CDT",1);
tzset();
tmptr = localtime();
/* timeptr = asctime(tmptr);
memcpy(, timeptr+11, 8);
hhmmss[8] = 0;
Deprecated; see
http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html#tag_16_21_07
So: */
strftime( hhmmss, 9, "%H:%M:%s\0", tmptr );
printf( "%s\n", hhmmss); /* show result. */
return( 0 );
}
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Wed, 14 Aug 2019 15:32:59 -0700, Charles Mills wrote: >It's complicated. To the best of my grokking, z/OS maintains two totally >independent time offsets. If the POSIX locale is not set, then any UNIX-ey >type calls do not know the local time offset. > More than two. There are multiple startup scripts which independently, not necessarily consistently, specify TZ. >You're free to call MVS TIME. > There are lots of other things I'd like to call MVS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Poked around some more, found
https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
which looked promising, but this:
time_t ltime;
static char hhmmss[9];
struct tm *tmptr;
char* timeptr;
time();
setenv("TZ","CST6CDT",1);
tzset();
tmptr = localtime();
timeptr = asctime(tmptr);
memcpy(, timeptr+11, 8);
hhmmss[8] = 0;
return(hhmmss);
.produces the same results as before! Note that I hard-coded the CST6CDT after
my first attempt made no difference, on the theory that maybe the TZ variable
wasn't set in the runtime environment.
Now someone can laugh and point out the stupid mistake I made (I hope).
From: Phil Smith III [mailto:li...@akphs.com]
Sent: Wednesday, August 14, 2019 6:10 PM
To: ibm-m...@bama.ua.edu
Subject: Local time in C on z/OS
I have a C POSIX application that writes timestamps on its output. It's always
produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I
thought maybe I could fix it.
Looking at the code, it's using ctime(). Ok, hey, localtime() should be
gooderT! Nope, per IBM doc:
* The ctime(), localtime(), and mktime() functions now return Coordinated
Universal Time (UTC) unless customized locale information is made available,
which includes setting the timezone_name variable.
* In POSIX you can supply the necessary information by using environment
variables.
Gee, thanks (and what does "now" mean in that first sentence? As opposed to
tomorrow?? Last week???).
I'm not in a position to set environment variables for this. I know the
hardware is set to UTC, but there's a system timezone offset at some level. Is
there no simple way to just say "Gimme the same time as the operator's console
would show"? Searching sure hasn't found one, hoping someone knows better!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Wed, 14 Aug 2019 18:10:12 -0400, Phil Smith III wrote: >I have a C POSIX application that writes timestamps on its output. It's always >produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I >thought maybe I could fix it. > >Looking at the code, it's using ctime(). Ok, hey, localtime() should be >gooderT! Nope, per IBM doc: > >* The ctime(), localtime(), and mktime() functions now return Coordinated >Universal Time (UTC) unless customized locale information is made available, >which includes setting the timezone_name variable. > >* In POSIX you can supply the necessary information by using environment >variables. > >Gee, thanks (and what does "now" mean in that first sentence? As opposed to >tomorrow?? Last week???). > >I'm not in a position to set environment variables for this. I know the >hardware is set to UTC, but there's a system timezone offset at some level. Is >there no simple way to just say "Gimme the same time as the operator's console >would show"? Searching sure hasn't found one, hoping someone knows better! > (Actually, the hardware is set, not to UTC, but to TAI - 10 seconds. See PoOp.) I believe "now" means "current release". They seem to be reserving the right to change. Is this for your own site, or distribution to customers? "environment" variables are local to your execution image. You can set and change them without affecting the outside world. Investigate tzset(). z/OS is woefully inconsistent intreatment of timezones. It seems compelled to regard Classic and UNIX as separate, noninteracting worlds. Other UNIX-like systems provide a sytem default timezone, e.g.: 580 $ ls -l /etc/localtime lrwxr-xr-x 1 root wheel 40 Jul 20 09:58 /etc/localtime -> /var/db/timezone/zoneinfo/America/Denver I tried to report this as a defect in an SR. WAD. It must remain broken for compatibility with AIX. You might be able to spawn() (BPX1SPN) a shell command to return what the site's shell sees as TZ. Java may do it better. And it uses the zoneinfo data base. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
It's complicated. To the best of my grokking, z/OS maintains two totally independent time offsets. If the POSIX locale is not set, then any UNIX-ey type calls do not know the local time offset. You're free to call MVS TIME. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Wednesday, August 14, 2019 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Local time in C on z/OS I have a C POSIX application that writes timestamps on its output. It's always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I thought maybe I could fix it. Looking at the code, it's using ctime(). Ok, hey, localtime() should be gooderT! Nope, per IBM doc: * The ctime(), localtime(), and mktime() functions now return Coordinated Universal Time (UTC) unless customized locale information is made available, which includes setting the timezone_name variable. * In POSIX you can supply the necessary information by using environment variables. Gee, thanks (and what does "now" mean in that first sentence? As opposed to tomorrow?? Last week???). I'm not in a position to set environment variables for this. I know the hardware is set to UTC, but there's a system timezone offset at some level. Is there no simple way to just say "Gimme the same time as the operator's console would show"? Searching sure hasn't found one, hoping someone knows better! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
