On 15-Apr-2012 21:36 , John Yeung wrote:
So, it seems to me that (1) there is no *purely logical* reason not
to have a job time attribute, if there is such a thing as a job date
attribute [it would be the canonical "effective execution time" for
the job]; and (2) given that the job date can be modified, there is
no purely logical reason not to be able to modify the job time.

I suppose. Yet I doubt ever there would be a static Job Time attribute provided by the OS, similar to what is provided as the static Job Date attribute. There is probably less value to far fewer users for a static copy of TIME being maintained by applications, let alone by the OS for the benefit of such applications, such that I expect the capability would remain the onus of any applications that require that support. Presumably that would be the case, because a static DATE value has _minimal_ representation of a transition in time up to 24 hours in its lowest-order measurement; i.e. in its fullest representation YYYYMMDD. Compare that to a TIME which has _maximum_ representation of a transition in time up to only one hour in its highest-order measurement, but as its _minimal_ representation of a transition in time up to only one second [or sub millisecond] in its lowest-order measurement; i.e. in its fullest representation [HHMMSS.mmmmmm] or HHMMSS.

Accepting of the idea that the static Job Date is used to represent the [one] Day of the running job, there is surely a comparatively smaller value in having a static Job Time to represent the [one] Second of the running job; i.e. for sharing the same Second across multiple programs of an application to avoid seeing a transition to the next second, to be able to resubmit\restart a job to reference the same second as on a prior submission, or to submit work to appear to have run on some future second? While I can imagine a lot of work could complete in a particular second, I can imagine few cases needing to provide output to represent a particular second or needing to make decisions that are specific to a particular second, for which that work could take advantage of a static time feature. So while an OS provides services, probably not so often providing services that few if anybody will ever use; what I would expect to be the case, for a static Job Time.

Which is not to say I'm personally complaining about lack of job
time attribute. I just think it has equal logical footing as job
date.

Logical from a canonical perspective, as "effective execution time" to correspond to the "effective execution date", the /logical/ merit for the existence of both seems reasonable; i.e. for an apparent sake of completeness. With that I agree. So merely for /completeness/ a Job Time may have an "equal logical footing" with Job Date.

Momentarily ignoring the implication that a lack of "Job Time" is not a concern... perhaps for anyone else who might not have given that much thought: Yet without some evidence of actual user requirements, there is simply too little value for a static Job Time ever being implemented as a feature provided by the OS. That is, the user requirements will generally dictate the provided functions. Recognition\acknowledgment that a Job Time has an effective logical equivalence to Job Date for its existence, will by itself, not provide any rationale\justification for the inclusion of a similar static Job Time.

FWiW I do not expect much more than the already available DATETIME() "job local date and time" established for a job, irrespective any other messages which may have alluded to a still expanding level of overall system "time" support. What I would expect eventually however, is an ability either to start a job with or to change a job to use, a specific time offset; i.e. enabling control over the TIMZON setting of a job, which is only visibly associated with and retrievable from a job since v5r3, and is only ever set to\from the QTIMZON system value.

FWiW I had suspected that the TIMZON setting for the job would have been made available by now [i.e. 7.1], via LOCALE per the SETJOBATR [Locale Job Attributes] of the user profile; i.e. specific to a job, per user, although still probably with no ability to change. However all that I found in InfoCenter for IBM i 7.1 was the same implication I recall from earlier releases, that what is provided to deal with time offset specific to a job is available only from a Locale setting; i.e. available to whatever functions choose to honor that setting. However a LOCALE apparently still can not be the source for establishing the TIMZON [and thus the TIMOFFSET] of the job at the job initiation per no *TIMZON element available on the SETJOBATR parameter [although the locale and\or a user.timezone property apparently can be used to establish an override to QTIMZON for a JVM?]. So although some time-related functions performed within a job may access the time zone offset from the user locale, the job TIMZON is both immune to whatever LOCALE() is established for the job-level from the UsrPrf-level setting and incapable of being overridden to a value other than the QTIMZON system value; i.e. still nothing in any of the SETJOBATR [per user], CHGJOB, SBMJOB, *JOBD, etc. to have a job associated with anything other than QTIMZON.
Addendum: I see from other posts, others have clarified that the use of LOCALE makes little sense for a Time Zone... thus a *TIMZON on SETJOBATR should never be expected. So it seems only the "JOB" interfaces should ever be expected to get [and so maybe one day will eventually get] a TIMZON() parameter to establish the time zone for [and possibly the ability to change the time zone already established within] a job.?

Regards, Chuck

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2019 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].