× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.