On 3/15/11 2:42 PM, Jerry Draper wrote:
We have a CL that is trying to determine the last instance for a
particular job.
The CL does a WRKJOB <job number> to *PRINT and then interrogates the
messages until the last job instance is discovered.
It looks like WRKJOB is showing instances by job number and not by
date.
We are at job number 900222 and we are wondering what will happen
when the job number rolls over to 000001.
What order will the jobs show up in for the WRKJOB command?
I am not sure of if\what is documented regarding the collation of the
jobs listed for the logged CPF0906 messages. However the logic to make
the decision for which job is of interest to the program could be made
within a program coded to receive\process _all_ of the diagnostic
CPF0906 messages in response to the CPF1069 escape that is issued when
duplicates are found for the specified JOB() generic. Without a
specific claim by the documentation noting the ordering of those
messages, the safest assumption is that there is no predictable order.
Perhaps someone can point to specific documentation clarifying
oldest-to-newest ordering, or something else.? The Retrieve Job
Information (QUSRJOBI) API can be used against each job named in a
CPF0906 message, to retrieve "Date and time job entered system" via the
JOBI0400 Format; of course the requesting user or by adopted authority
the program must be authorized to access the job named in the message.
An old message posted to the RPG list shows an example where someone
processed all of the diagnostic messages [but for CHGJOB, in a CLP] in
order to choose the "largest" job number. However I infer that would be
an improper conclusion as to which job is either newest or oldest, given
the impending condition of job numbers wrapping in the quoted case;
simply, the largest value is generally suspect for its potential value
to infer relative age, if the job numbers have ever wrapped:
http://archive.midrange.com/rpg400-l/200012/msg00475.html
Using the CHAR(13) date\time entered system from the QUSRJOBI might
be a reasonable replacement for the comparison for the "largest" value
test in that CLP.?
FWiW I just ran a test on v5r3 receiving the *DIAG messages [*FIFO
order] and the order of the jobs named in the message data of those
messages reflected the effective /start/ date [or at least by inference
seemed to; noting however that the "status" values were not consistent
across all jobs, so the first key for sorting could have been the status
shown versus the date shown] as displayed for the "Entered System" date
presented in the interactive *SELECT list, but for sure the results were
not ordered by the job number. That the order was not by job number can
be inferred from the following three interactive invocations and results:
<code>
WRKJOB MYSERVER DUPJOBOPT(*SELECT)
Entered
Job User Number Type ---Status--- System
MYSERVER SOMEUSER 813038 BATCH ACTIVE 01/27/11
MYSERVER CRPENCE 436100 BATCH OUTQ 03/16/11
// the former job was presumably started long ago before job
// numbers had wrapped [I had not authority to verify] and
// my job was started and ended only a minute before
WRKJOB MYSERVER DUPJOBOPT(*MSG) /* same msgs\order in above rqs */
A duplicate job named 813038/SOMEUSER/MYSERVER was found.
A duplicate job named 436100/CRPENCE/MYSERVER was found.
WRKJOB CRPXYZ DUPJOBOPT(*MSG) /* sbmjob jobs now in OUTQ sts */
A duplicate job named 436049/CRPENCE/CRPXYZ was found.
A duplicate job named 436050/CRPENCE/CRPXYZ was found.
</code>
Regards, Chuck
midrange.com
