First suggestion is to show us what you have so far. It’s much easier to see if a few minor changes can fix something that already exists than have some unknown number of others try to write code that they might never use from specs that aren’t precise. You might get ten examples, and none will do what you need. — Tom

My CLP is very simple, but this is what I have.PGMRUN PGM(abc1234) OPTIONS(abc1234) RUN PGM(abc1234) OPTIONS(def5678)RUN PGM(abc1234) OPTIONS(ghi901)RUN PGM(abc1234) OPTIONS(jkl234)ENDPGMPerhaps if the CLP can read the program job log and watch for “END OF JOB” to know it completed successfully before continuing to the next PGM. And if the job log doesn’t display “END OF JOB” to display a custom message to notify me, require a reply to acknowledge, then terminate the CLP without continuing to the next PGM.

Your program executes “RUN” commands. What is that command? What does it do? It’s not a native command. — Tom

It’s not necessary to read the joblog. Your program will know if the inner programs failed. But the methods are different depending on how “RUN” works. — Tom

Hmm… I guess that RUN command is part of the Premier software.

It isn’t much, but I found out that RUN starts the programs one at a time. The next program doesn’t start until the first one is done (either successfully or not). If I was to replace RUN with SUBMIT, it would kick off all the programs at the same time. I need them to run one at a time consecutively so RUN is used in this circumstance.

How is “RUN” different from simply using a CALL command? The “RUN” command wouldn’t seem to have any reason to exist unless it does some specific useful work that CALL doesn’t do. One thing I would certainly expect would be some useful messaging (or a return code of some kind) that your CL could use. — Tom

I tried replacing RUN with CALL, but it seems to be showing an error. I’m using PDM to edit and compile the CL’s, if that is any different.

I tried replacing RUN with CALL, but it seems to be showing an error.
 
We can’t tell much unless we know what the error is and where and when you see it.
 
To tell us what the error is, we first need to know the message identifier. The basic text can also be helpful. To say where you see it, it will be shown on the display or in a joblog. To say when you see it, it will be immediate when you type the command and press <enter>, or it might be when you compile the program, or it might be when you run the program.
 
We don’t know what the “RUN” command does yet, so we don’t know how CALL might be used. We can see that “RUN” has a parameter named OPTIONS(), but we don’t know what that parameter does. And we also know that CALL does not have an OPTIONS() parameter.
 
The CALL command cannot be a direct replacement for “RUN”. We need to know what “RUN” does.
 
Does it cause programs to run in batch? Does it log activity in a database? Does do completion tests? Does it control later programs? Does it send messages? If we don’t know how it works, we can’t do anything with it.
 
The full help text for the command should tell you what it does. And there should be documentation for the product that tells you how to use it. We don’t have the product, so we can’t learn what to do. You have to research the command.
 
Tom