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.
These date items do show their history - the values for job date and
system in the PSDS are numbers, not date fields. The RTVJOBA brings the
date back as a character value, I think - certainly not a date field.
I'm sure you know how to find the start time - I expect it to be in the
QUSRJOBI API but haven't verified that. It is also in the message data
for the CPF1124 message that
Printer files and display files have the TIME keyword - the latter is
always the current time - well, it may be the time the screen was
displayed or the printer file was opened - haven't verified actual
behavior here, especially in printer files. Both of these are probably
in the numeric format, not true date or time fields.
So to get the "real" thing, we really want true date/time fields. And if
you want the combined value, you have the timestamp, which is different
from, say, Excel's implementation - something you referred to earlier,
with its time as the fraction of the day.
I guess that if the purpose is to use the time in a report, that the
existing keywords provide a lot - albeit in an older format and style.
Regards and soon to sleep!
On 4/15/2012 11:36 PM, John Yeung wrote:
Well, thanks for yet another detailed explanation, Chuck.
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.
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.