In message <000701c94776$5eb96090$240010ac@nike>, Matthew Perdue
<[log in to unmask]> writes
>Quoting Roy Brown (in part):
>
>"The current working ratio is that what it takes the HP3000 two minutes to
>generate, it takes Oracle an hour to digest."
>
>Isn't it sweet....
>
>"But the surprising limitation that I hit with MPE/iX, which Linux and even
>Windows brush off effortlessly, was trying to run a system across several
>timezones, and have everyone see everything in their local time.
>
>Even using Hourglass or something similar - which shouldn't be needed for
>this anyway - I was never able to figure out how it could be done.
>
>I could get close, within an application that I could change the code of,
>but I couldn't get all the way there.
>
>I eventually concluded it was impossible to do with MPE :-( "
>
>Not true, there is a way. There's always a way. :)
>
>A|PUB.SYS:SHOWTIME
>SAT, NOV 15, 2008, 4:50 PM
>[^^^notice the system local time]
>
>A|PUB.SYS:SHOWVAR TZ
>TZ = CST6CDT
>[time zone variable set for time zone where the system is located]
>
>A|PUB.SYS:RUN SHOWCLKS.PUBXL.TELESUP
>
>SHOWCLKS/XL A.10.00
>DEBUG/iX C.45.05
>
>HPDEBUG Intrinsic at: 206.00007258 PROGRAM+$198
>PRIV=$3 := $0
>
> *************************************************************
> *** ***
> *** Greenwich Mean Time : SAT, NOV 15, 2008, 10:50 PM ***
> *** GMT/MPE offset : -6:00:00 ***
> *** MPE System Time : SAT, NOV 15, 2008, 4:50 PM ***
> *** ***
> *************************************************************
>
> **** C Library Information ****
>
> Current value of Time Zone(TZ) variable : CST6CDT
> CTIME function return : Sat Nov 15 16:50:26 2008
>
>END OF PROGRAM
>[notice the system time is still the local system time, and the function
>CTIME returns the time based upon the setting of the TZ variable... (you'll
>see it change in the following example) ]
>
>A|PUB.SYS:SETVAR TZ "PST8PDT"
>[change the time zone variable to Pacific]
>
>A|PUB.SYS:SHOWTIME
>SAT, NOV 15, 2008, 4:50 PM
>[notice the system time is still the local time, it hasn't changed]
>
>A|PUB.SYS:RUN SHOWCLKS.PUBXL.TELESUP
>
>SHOWCLKS/XL A.10.00
>DEBUG/iX C.45.05
>
>HPDEBUG Intrinsic at: 206.00007258 PROGRAM+$198
>PRIV=$3 := $0
>
> *************************************************************
> *** ***
> *** Greenwich Mean Time : SAT, NOV 15, 2008, 10:50 PM ***
> *** GMT/MPE offset : -6:00:00 ***
> *** MPE System Time : SAT, NOV 15, 2008, 4:50 PM ***
> *** ***
> *************************************************************
>
> **** C Library Information ****
>
> Current value of Time Zone(TZ) variable : PST8PDT
> CTIME function return : Sat Nov 15 14:50:48 2008
>
>END OF PROGRAM
>[AHA! Notice the CTIME function returns the Pacific time according to the
>setting in the TZ variable, but no other users are affected as system local
>time remains the same]
>
>A|PUB.SYS:SHOWVAR TZ
>TZ = PST8PDT
>[yep, TZ variable set to Pacific]
>
>A|PUB.SYS:SETVAR TZ "CST6CDT"
>[reset TZ variable to system local time zone]
>
>Each session or job can set their own instance of the time zone variable TZ
>(which must be "TZ" as that's what the CTIME function looks for) without
>affecting other users and jobs. The users's job or session program can then
>call the C library functions to determine the time.
>
>Voila! Everybody has the time according to their own time zone settings!
>
>Now wasn't that easy.... :)
>
Nice.
But before I try this tomorrow:
With my own local TZ, will LISTF,3 show me file timestamps in my own
local time, not the system time, on files written by other users with
other TZs?
and will STREAM AT (local time) be automatically translated into the
appropriate system time in the job queue?
and for extra credit:
if I look at the subsequent STDLIST, will the times shown be dynamically
modified from the TZ applicable when the job was run (wherever that was
and whatever the TZ was set to) to the TZ I'm using when I look at it?
Unix and Windows (of the NT/2000/XP/Vista family) will certainly do both
of the first two things, though I'm not sure about the third one; that
would rely on them being able to detect a date/time as a date/time.
But the first two rely on timestamps being stored in UTC, and translated
into local time on the fly. And unless I miss my guess, MPE stores
timestamps in system time, and LISTF, etc. merely report what they see.
(Windows 3, 95, 98 and ME had this issue, causing confusion at DST
change points and if you took your laptop into another timezone).
As I said, I could get close with any application I could change the
code of, and I could even wrapper LISTFs and STREAMs and SHOWJOBs....
but the list just got longer and longer :-(
Regards
Roy
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
