|
<snip> 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 persistent 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 to have 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 similar to CCSID processing of character fields within database. 5. You would want extensions 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. </snip> So do we think IBM has put some thought in to this particular topic??? It never fails to amaze me when we make suggestions on how to change something as simple as the time of a job, that the full ramifications of doing it on an integrated system like the System i can get so involved. As for me, I can wait for IBM to do it right.. Thanks for the short course of internal time management Bruce! Since LPAR is so easy and becoming relatively inexpensive, I think LPAR is the best method for now. Jim
As an Amazon Associate we earn from qualifying purchases.
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.