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

On 13-Apr-2012 09:18 , John Yeung wrote:

Personally, I don't know why "date" is a job attribute. What is
this attribute really supposed to *mean*? What is its purpose?
(I'm not trying to be difficult; I fully expect the answers to be
reasonable; I just don't know what they are.)

AFaIK the "Job Date" exists merely as a convenience for applications, mostly for use in presentation of [spooled] output, though additionally for logic flow. The attribute is a static date value which effectively represents the "one day" on which the job is running. Static, in that the value is established at job initiation, and the OS will not update that value [even though the system clock continues to change to each new day\date]; yet, the value may be changed by the user applications via the "change job" command or API.

Because that Job Date value remains unchanged, each program of an application can retrieve the same Job Date value even while running over multiple days, for example, in a multiple-days long-running batch job. Such an application might be used for some End-of-Month processing in which logic of the programs might purposely fail or react differently when the date is not the last day(s) of the month. Having used the system clock instead to make such decisions, the window of opportunity to perform such work is limited, as are recovery options if any rework\re-submission is required; i.e. the expression "the clock is ticking" may be applicable, when using the system clock\date versus a static job date. Even for an application that runs in less than a day... The Job Date could represent a date\day sometime in the past, for example to resubmit a failed and only partially complete batch run which wants, for consistency, to output [and make decisions based upon] the same date value that was used in the first run. Or the Job Date could represent a date\day sometime in the future, for example to submit a job to generate printed paychecks on which the "date" will appear, but those checks will not be available officially, until that future date which appears on the checks.

Of course because most jobs or applications could set or obtain such a [static and shared] value from anywhere, by a plethora of other means than as an attribute of the job, there is little reason for a Job Date value to exist explicitly as an OS-supplied feature... other than the convenience factor.? But that is really just the general situation with computers; that is, the OS provides services that may be valuable to the programmers and users... even if some will never find any value in using some of those services.

Why the Job Date value can be changed, seems to me, to be the odder aspect; as compared to existence of the attribute. I can only infer that both because various "DATE" functions [a /keyword/ for DDS] exist to return the Job Date very conveniently and because of the /expense/ associated with the creation of a new job, the ability to update the Job Date of an existing job is just another convenience. That is, a new job need not be started, just to get the new Job Date in that job. For example, a daemon\NEP job could be updated easily and inexpensively to have the desired Job Date, versus the pain of end\restart to effect the same. And interestingly [as I have read; not actually used], for those applications desiring an even /more static/ date value, the RPG even has an additionally static "job date" capability which even avoids seeing the effect of a CHGJOB DATE(newvalue); a capability provided via its "User Date" features.

Regards, Chuck