A “submitted” job is a batch job. I assume that the statement means that each step is submitted interactively rather than having a complete ‘process’ that controls when or if the next step starts.

A SBMJOB command includes a MSGQ() parameter. When the job completes, either a CPF1241 normal completion or a CPF1240 ended abnormally message will be sent to the message queue that you name on that parameter. The message data for those messages includes the fully-qualified name of the job.

Also, when a SBMJOB command runs, it returns a CPC1221 message to the job that does the submit. That message also contains a fully-qualified job name in its message data.

So, by creating a message queue for this sequence of steps and using its name on the SBMJOB commands, your interactive process can know which jobs are related to which steps, which ones have been submitted, which ones haven’t completed yet, which ones completed normally and which ones ended abnormally.

Depending on exactly how you wanted all of it handled, a pretty robust external control could be set up. (Or a simple one.) Essentially none of the submitted programming would need any changing at all. The interactive menu would be where changes were made.

Tom

If these are in fact sequential processes, then as others have said, you have more security by controlling the execution and recovery within a single itemp of Control Language Program code (CLP – clue is in the name)

Incidentally, an excellent choiuce for a return code is 7 bytes – you can retuirn a meesage ID, which gives you an immediate mens of informing the user of, what, 2500 bytes of helpful text, which can also be recorded in the joblog.

If you wish to apply multiple parallel processes and ensure synchronicity you will need to be more imaginative. Rather than the existence of a data area, set locks onto an object for the duration of a process. Following processes check for the object being locked. If so, they wait. As the lock will dissolve if the locking job fails, recovery/restart is automatic. You will arange for completion codes to be used to ensure that a failing job doesn’t then allow others to start.
Naturally, you will be providing some form of audit file which records the start and end and results of each process – by timestamp, and this may form the basis of some control activity, or indeed be the entire control.

Much simpler to write some trashy JCl that manages the whole thing in one go though.

There are good possibilities that haven’t been mentioned yet. But the most important question from CharlieBrowne hasn’t been answered — “What is the definition of sucessful?”

When that’s clear, it’ll be much easier to know what to do.

Tom

Thanks for all suggestions. I got the idea of what I need to do to achieve this.

“CL/400 with restart option”

http://itknowledgeexchange.techtarget.com/itanswers/cl400-with-restart-option/

DanF

If these programs cannot be put in a single CL because work needs to be done inbetween the jobs, I would create a file or *DTAARA that would be updated when a job completed sucessfully. Each program would check the file to see if it was OK to run.
If they are submitting from a menu, you can check the file when the SBMJOB is about to happen.
Also you should send out a message if one of the jobs fail. It should include the reason for the failure.