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
midrange.com
