We just loaded 6.0 onto our system this weekend and figured we would explore
the new feature that allows us to have multiple job queues.  In exploring
this we ran into an unusual result as the jobs were being submitted.  Here's
the full scenario -

1.  12 jobs running on a full-time basis on the system with the overall  job
limit set to 20 and the default job queue of HPSYSJQ left at the default
limit of 3500.
2.  5 job queues added via the NEWJOBQ command each with a limit of 1 so
that jobs are single-threaded into the system.

We then streamed a single job which streams 5 jobs - one for each of created
queues.

The 5 jobs then stream 3 jobs each into the same queue (e.g. JOB1 runs in
QUEUE1 and streams jobs
JOB1A, JOB1B, and JOB1C in QUEUE1; JOB2 runs in QUEUE2 and streams jobs
(JOB2A, JOB2B, etc).)

All of these jobs are submitted at the same INPRI of 2.

Now he is where things go a little strange on us.....rather than  JOB1A job
being executed first like one might expect JOB1C is submitted first....or in
other words the last job streamed is the first one in even though a SHOWJOB
executed on the system shows the remaining jobs listed in the correct order
in a WAIT state.  Things get a little stranger from this point on but in
order to keep this posting short I just say that we seem to consistently
find that the job that is put into an EXEC state within a queue is always
the last job submitted.

Any theories on what in the world might be going on here?  Did we miss
something?
--
******************************************************************
* Kevin J. Mullins       Phone:  281-897-3626                    *
* MIS Manager            Fax:    281-469-3226                    *
* Interconex,Inc.        E-mail: [log in to unmask]  *
* Houston, TX. USA       URL:    http://www.interconex.com       *
******************************************************************