Re: WRKJOB duplicate jobs

[Jack Kingsley <iseriesflorida@xxxxxxxxx>]

If you change it now to sort them how you want, you should be set once it
rolls I would think.

On Wed, Mar 16, 2011 at 1:57 PM, Jerry Draper <midrangel@xxxxxxxxxxxxx>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.
>
> Jerry
>
>
>
> 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<midrangel@xxxxxxxxxxxxx
> > wrote:
> >
> > > This CL doesn't use the *print output as noted by Chuck but checks the
> > > messages (RTVMSG) to find the last job.
> > >
> > > I believe it needs a tweak and not a rewrite.
> > >
> > > Jerry
> > >
> > > 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.
> > > > Regards, Chuck
>
> --
> Jerome Draper, Trilobyte Software Systems
> iSeries, Network, and Connectivity Specialists -- iSeries, LAN/WAN/VPN
> Representing WinTronix, Synapse, Netopia, HiT, and others .....
> (415) 457-3431 . www.trilosoft.com
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.