SOLVED! Re: Weird problem with *USRQ creation and job submission

The clues:

Job C wasn't becoming active until JOB V had timed out, deleted the *USRQ,
and terminated.
Job C wasn't just failing intermittently; it was failing when there were
already 3 other instances of Job C running.

The solution:

The job description for Jobs V and C was submitting the jobs through a
*JOBQ that could only have a limited number of jobs active in the
subsystem. When it was changed to submit through a *JOBQ with *NOMAX
active jobs for the subsystem, it worked fine.

Once again, here's the scenario:

> Job V holds a socket connection. It is about to submit Job C, and pass
> the socket connection on to it. So (following the accepted protocol), it
> creates a *USRQ, using QUSCRTUQ, submits Job C, passing it the name of
> the *USRQ, then waits for a job identifier to come in on the *USRQ, so
> it can transfer the socket connection.
>
> Job C, as soon as it starts, resolves a system pointer to the *USRQ
> whose name it was passed, stuffs its job identifier into the *USRQ, and
> waits for the socket to be passed.
>
> The problem: for some reason, Job C intermittently fails to resolve the
> system pointer to the *USRQ.

--
JHHL