Re: WRKJOB duplicate jobs -- MIDRANGE-L

Suggesting the sequence is merely "descending" seems insufficient IMO. On what keys [on which attributes] is sequencing performed, seems the more appropriate primary question; ascend\descend is secondary, and specific to each attribute which is keyed.

I purposely included two examples in a prior message; with what I hoped appeared to show a conflict in sequencing by "job number". One example showed results were descending by job number, although perhaps sequenced ascending by date [the job entered the system]. The second example showed the results are ascending by job number, although could also [instead or additionally] be ascending by date [the job entered the system]. I posited the job status might also have been a key [attribute] used in collation.

A statement that the code will be modified to handle wrapping job numbers makes the following comments irrelevant, so merely FWiW...

I noted that I am not aware of documentation stating as fact [any particular ordering], but if the results are ascending by date, then the "last job" submitted would be the last message retrieved using *FIFO. Coded as described, and maintaining that sequencing assumption, the program should work as coded to infer the last message received represents the most recent job irrespective of job number. There may be someone whose code has successfully operated under this assumption over many job number wraps, from which one might get comfort that even without a documented sequence, the assumption did and will continue to hold.... or as I noted, someone who does know of specific documentation.

Lacking any documentation to support that inference\assumption, adding the QUSRJOBI or other means to ensure the best-fit for which job number [qualified job name] will be chosen, is probably much more appropriate than just depending on the assumption. Presumably how the program will be changed to remove any assumptions, to "handle the wrapping of the job numbers", or perhaps change to use the QUSLJOB or similar job\Work Management API.?

Regards, Chuck

On 3/16/11 10:57 AM, Jerry Draper wrote:

Yes, it appears that the sequence is descending and that's the
issue.

The code currently just takes the last message as the most current
run of the job.

The code must handle the wrapping of the job numbers when it resets
to 000001. It doesn't do that now. But it will.

On 3/16/2011 10:46 AM, Jack Kingsley wrote:

looks like the sequence is descending.

On Wed, Mar 16, 2011 at 1:19 PM, Jerry Draper wrote:

This CL doesn't use the *print output, as noted by Chuck, but
checks the messages (<ed> RCVMSG) to find the last job.

I believe it needs a tweak and not a rewrite.

On 3/16/2011 9:38 AM, CRPence wrote:

On 3/16/11 5:22 AM, rob@xxxxxxxxx wrote:

Your first problem is that you are using a command (WRKJOB),
telling it OUTPUT(*PRINT), and trying to analyze that
output.

<<SNIP>>

Not necessarily. For the subject "duplicate jobs" case, that
condition causes the CL WRKJOB request to fail with the escape
message CPF1069 "End of duplicate names." while having produced
_no output_ except possibly the "Select Job" panel presented in
an interactive job; but even that can be avoided by specifying
DUPJOBOPT(*MSG) on the Work with Job request. Thus for that
case, WRKJOB OUTPUT(*NULL) /* if it were supported */ might
suffice for what is intended\analyzed.

The messaging can be used as a means to infer something about
the specified generic JOB() without having to use any spooled
output or an API; just limited in the capabilities that method
provides, and CHGJOB of a mundane attribute might be a better
choice since no output is produced when only one job [i.e. no
duplicate job name] exists. Little different than a coded wait
and looping on ENDSBS requests versus a coded wait and looping
on job status inquiries of the subsystem monitor after just one
ENDSBS request, awaiting completion of the CL ENDSBS request.