Rob,

Not to disagree, but.... "So they don't have much further to go." might be 
a bit misleading.  To really have time zone suport at a job level implies 
quite a bit of additional work.  As a few examples:



1. You would want commands/APIs/panels that accept time input parameters 
to recognize that they are local time values and then normalize these 
values internally to a standard such as UTC.

2. You would want command/APIs/panels/reports that return time values to 
convert internal time values (UTC) to the proper time zone for the user 
job.

3. You would want commands and APIs that return time values to persistant 
objects such as *OUTFILES, *USRSPCs, etc. to add UTC time fields in 
addition to the current time fields (which would return local job time 
values for compatibility reasons). This is so that other jobs that might 
access the *OUTFILE, *USRSPC, etc would not have to concern themselves 
with knowing what time zone was in use when the *OUTFILE,*USRSPC was 
populated -- they can just use the new UTC fields and convert to whatever 
time zone they prefer to work in (conversion APIs were provided in V5R3). 
Retrieve interfaces may also be enhanced to return UTC fields but this is 
not as important is it is for *OUTFILEs and *USRSPCs -- you may however 
want a Retrieve interface such as retrieve journal entries to provide UTC 
values in addition to local values for the reasons given above.

4. You would want database to allow the definition of a timestamp field 
such that it is normalized at input/output/update to a standard time such 
as UTC. 
You would want applications reading the file tohave the time values 
automatically converted from the normalized value to the local job time 
zone value, and on update/output automatically converted from local job 
time to a standard time.  Conceptually this would be similiar to CCSID 
processing of character fields within database.

5. You would want extentions to existing objects and commands so that you 
can control what time zone a given job is running in. This might include 
area such as job descriptions, user profiles, commands such as SBMJOB, 
CHGJOB, etc.

You would most likely want a whole lot but the above gives a general feel 
for what's needed to do this type of support "right".   For sure I 
wouldn't say that "they don't have much further to go".  :)  And while 
there might be a big switch somewhere, I don't see how it could be flipped 
"on" until all the parts are in place.  Otherwise there would be a major 
incompatibility for any parts of the system that weren't ready when the 
switch was set and then tried to support job level time zones in a later 
release.

Speaking strictly for myself,
Bruce Vining



 



rob@xxxxxxxxx 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
04/12/2006 07:18 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: How to set multi timezone for user in one AS/400 ?






What Al Mac said was right.  If you don't have to support too many time 
zones you might consider LPAR but that opens up a host of support issues.

But, I'd keep hammering on IBM with Design Change Requests, or DCR's, to 
get them to fix this.  I was hoping for this kind of support in V5R4. 
There is already a bunch of underlying support built in.  Like RTVJOBA has
CL var for DATFMT 
CL var for DATSEP 
CL var for TIMSEP 
CL var for DATE 
CL var for CYMDDATE 
CL var for DATETIME 
CL var for TIMZON 
CL var for TIMZONABBR
CL var for TIMZONFULL
CL var for TIMOFFSET 
So they don't have much further to go.  They are getting close to flipping 

the switch.  Frankly I think they are so close (and this is pure 
speculation!) why not just ptf it out?  What's left?  CHGJOBD?  SBMJOB? 
CHGUSRPRF?  CHGDEVDSP?  Make the api's etc that retrieve system time 
respect the values in RTVJOBA?

Rob Berendt

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.