Re: How do I change the time in a job?

On 16-Apr-2012 15:08 , John Yeung wrote:

On Mon, Apr 16, 2012 at 3:25 AM, Vern Hamberg wrote:

I'm still curious - how would you use this "job time"? First, do
you want it to be the time at which the job started? To me, that is
not as interesting or useful as the date on which the job started.

Very reasonable questions. Honestly, when I hear the term "job
date", what goes through my mind is "date the job started". To me,
it doesn't make a lot of sense to be able to futz with this value.
At least, in anything that I would personally write, I would
*either* want the actual start date of the job, *or* the current
system date. If my logic needs to handle the case where the execution
of the job spans multiple calendar days, then I should compare the
actual start date with the current system date and handle the
situation appropriately. I have absolutely no interest in some
fabricated date.

Should be easy enough to simply ignore the existence of the Job Date given that feature does not fulfill any stated or implied requirements.

Thus, for my purposes, the concept of "job date" should not be
distinct from "start date", and "start date" should absolutely not
be modifiable.

Use a command exit or some other means to prevent the CHGJOB DATE(value) activity.

Thus, for my purposes, the concept of "job time" would simply be
derived from, or a component of, the "job timestamp", which would be
the actual date and time at which the job started.

So it seems the static Job Date is of little value, and instead the "Date and time job became active" of JOBI0400 Format for the Retrieve Job Information (QUSRJOBI) API would suffice for the described purposes.

And yet there is this modifiable job date attribute, which clearly
*is* distinct from the actual job start date. So I have to imagine
how reasonable this is. And my conclusion is, however reasonable it
is to have a futzable job date, it is equally reasonable to have a
futzable job time. (Both of these would be components of the
futzable "job timestamp".)

Yet even having the time included, apparently still no stated requirements would be fulfilled by its existence. So with only an expressed reasonableness of being able to change a static job time in addition to the static job date, rather than any actual requirement to _use_ such a value, there would seem little reason to be at all concerned for the existence or non-existence of the extended [timestamp versus just date] support. All the more reason to just ignore the Job Date.

Regards, Chuck