RE: Job submitted in Qstrup

>  Tom Liotta:
>An auto-start job will have the same issue if 
>QPGMR is the profile named on the auto-start 
>job description. You must specify a profile for 
>an auto-start jobd.

As I said -- "Create the job description using GAL as the user profile..."

>Perhaps the major problem with an auto-start job 
>would be determining which subsystem description 
>it should be associated with. This becomes important 
>if the jobd request needs services that haven't started 
>yet. If the request needs TCP/IP and TCP/IP isn't 
>active yet for some reason, then the subsystem with 
>the auto-start job shouldn't be started yet. This 
>is somewhat equivalent to placing SBMJOB commands 
>in QSTRUP at a point after services are verified as 
>started. In short, don't issue STRSBS for that 
>subsystem until the proper time.

One way to deal with this issue is to code the program to check for the
dependent service and wait.  I've seen more primitive processes written to
just delay for five minutes, under the assumption that everything should be
up by then.  I try to set up QSTRUP so that ASYNC and the batch subsystems
come up last, giving all services time to start.  You never know what type
of job is going to be sitting on a job queue when the system comes up.

>Also keep in mind that auto-start jobs don't 
>necessarily run only at IPL or return from 
>restricted state. The jobs are started every 
>time that subsystem starts, regardless of 
>whether they _should_ be one-time or not.

I've never tried adding an autostart job to the QCTL subsystem, but it would
deal with the one-time issue handily.  On the flip side, one of the benefits
of an autostart job in a user subsystem over a SBMJOB in QSTRUP is that you
can test the autostart job by ending and restarting the user subsystem,
rather than waiting for the next IPL.

-Jim

James P. Damato
Manager - Technical Administration
Dollar General Corporation
<mailto:jdamato@xxxxxxxxxxxxxxxxx>