RE: executing jobs in sequence

["Jones, John \(US\)" <John.Jones@xxxxxxxxxx>]

Well, we've gone down the path of the first suggestion: Let each job be
self-contained and submit them to a single-threaded job queue.  So I
can't really say definitely what the dis/advantages would be to using an
overall program to drive the batch load.

I would guess, though, that the main issues would be:
- Error handling.  It may be easier to do one super-error-handler for
the CL instead of writing/copying an error routine in all of the
individual jobs.
- Job/task restarts.  The CL code wouldn't be the prettiest. OTOH it
would ensure parms and other run-time necessities are always done
correctly
- If the CL ran all of the jobs inline then the job log could become
unwieldy.  Examining it (if necessary) would be an effort. 
- If the CL submitted the jobs v. running them inline then it'd need the
right logic for monitoring those jobs.  Not impossible by any stretch;
just takes more effort to develop.
- If the parameters of the inline/submitted jobs change, you'd have to
either change the CL program or have it read parameters from another
file.  Again, not impossible but may be a little inconvenient compared
to updating a parm in a scheduler.  Of course, if the parms change, they
have to be changed _somewhere_ so this may be a matter of 6 of one and a
half dozen of the other.
- The CL would make it easier to add new jobs to the run.  The code for
the new job can easily be added exactly where desired.  If using a
scheduler or other tool to do submits for all of the tasks then the
timing may need to be adjusted (moved back) to insert a new task.
- Depending on your change management testing methodology, more testing
may be required if using the CL approach than the scheduler approach.
It's a much bigger job to test and each test run will take longer if
using the CL compared to running the single (new/changed) job.
Basically unit testing v. testing the whole thing at once.

Others who have done the CL approach can hopefully chime in.