RE: SMBJOB - with delay

Rob,

The reason for the separate job is you can't hold the AJS job while it running, can't hold yourself, nothing to do with authority.
Your class idea sounds good, but for some reason the Default wait time is not working.
The file has a Maximum record wait time . . . . . . . . . : WAITRCD 60
The class Default wait time in seconds . . . . . . . . . . : 30

This should have worked.

The BRCSFTBCS job, which has the lock, did the SBMJOB HLDJOBJS, submitted at 11/12/14 08:33:24.662770
The lock occurred at 11/12/14 08:33:24.694388, a few micro seconds too soon.
The BRCSFTBCS job ended at 08:33:24; 723366

CPF5027 Sender copy 30 11/12/14 08:33:24.694388 QDBSIGEX QSYS 0252 QDBSIGEX QSYS 0252
Message . . . . : Record 40 in use by job 545328/CPASFTPC/BRCSFTBCS.

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, November 12, 2014 4:04 PM
To: Midrange Systems Technical Discussion
Subject: RE: SMBJOB - with delay

Let me guess, the reason you aren't doing a DO loop around the HLDJOBJS, but instead you are submitting it, is because you are also submitting the job under some other user profile? If that is the case then I think the job that does the submit should be modified so that it adopts, or profile switches, so that it has the authority to do the HLDJOBJS instead of submitting it.
Either that or you should write a job that does a do loop around HLDJOBJS and submit that job instead of just submitting the command HLDJOBJS.

Or, one other idea, when you SBMJOB the HLDJOBJS make sure that it uses a job description with a special class (see WRKCLS)
Default wait time . . . . . . . *nomax


Rob Berendt