JES2 has never made a guarantee about job execution order. Job numbers do not guarantee input order, since job numbers wrap. Also, if the job comes in from NJE then the local JES2 system will try to use the origin node's job number.
If you need your jobs to run in a specific order, you have 3 choices: 1. Have JOB1 submit JOB2. 2. Submit JOB2 with a hold status, and then have JOB1 release JOB2. 3. Buy or write something that will do the above under the covers. (Mellon Mods, the new BEFORE/AFTER sample code that comes with JES2 z/1.7, Thruput Manager, a scheduling package, etc.) If you have something like IOF or SDSF, doing #2 is really pretty easy. Those products can be run in batch, understand your security rules, and have a programmable interface. In our case, I have a small assembler program that takes a parm of jobname. (The syntax is a hold-over from our MVT days.) The program invokes a clist that calls IOF to release (or cancel) the highest priority named job that the user is allowed to manipulate. By default, modern JES2 systems run with 10 converter tasks on each member of your shared spool. (It has been a very long time since JES2 only ran one converter task per member.) More complicated jobs take longer to convert. Jobs with JCLLIB will take longer, since the library has to be opened. If the JCLLIB has been migrated, or if there is an ENQ on it, you have an even longer wait. If you have converter exit code that looks up datasets, that takes time. etc., etc. Even if two jobs are identical, if they start conversion at the same time, there is a 50-50 chance that job2 will end conversion first! /jack ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
