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
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') -,
/* 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 =
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
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 environmen
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
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
>>
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
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
>
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
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()
>
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 -
llow 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 M
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
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 A
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
"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
oduct 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
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
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
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
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:
;
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 defi
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 t
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
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
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
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;
h 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 a
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
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
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
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
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
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
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
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
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();
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,
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
41 matches
Mail list logo
