That’s true. But since the message queue support doesn’t require modifying the submitted jobs, why do it?

The message queue can hold thousands of messages. The submitted jobs may even send their own status (tracking? debug?) messages if modification is possible. Sending one message doesn’t erase previous messages as would happen with a data area.

And unless the data area is expanded to hold more info that the submitted CL must format and put there, there’s no identification of the source nor the time. A message will automatically include sender identification and timestamp.

So, simply by specifying a message queue on the SBMJOB command, the base actions are all handled automatically by the system. Once the base is in place, it can be expanded for almost any future need.

I would use CRTMSGQ with MSGQFULL(*WRAP) to allow the queue to wrap if there was ever any reason that messages might not be received from it for an extended time.

Tom

When JobA starts it updates the data area with ‘JOBA STARTING’

The last step JobA updates the data area with ‘JOBA ENDED SUCCESSFULLY’

The First Step of JobB checks the value in the data area
if it contains’JOBA ENDED SUCCESSFULLY’ continue with JobB
else send message and ??? wait/end???

The second step of JobB updates the data area with ‘JOBB STARTING’

The last step of JobB updates the data area with ‘JOBB ENDED SUCCESSFULLY’

The First Step of JobC checks the value in the data area
if it contains ‘JOBB ENDED SUCCESSFULLY’ continue with JobC
else send message and ??? wait/end???

The second step of JobC updates the data area with ‘JOBC STARTING’

The last step of JobC updates the data area with ‘JOBC ENDED SUCCESSFULLY’

Phil

No.

RTVJOBA can only be used by a job to find out things about itself. It can’t be used to find out about any other job.

The simplest way to find the status of a submitted job is by calling the Retrieve Job Status (QWCRJBST) API. But that will only tell you if the job has finished; it won’t tell you if it was a successful completion.

And in order to call that API, you will need to know enough to identify which job the API should return status for. When your program submitted the other job, a CPC1221completion message was sent to your program’s message queue. You can use the RCVMSG command to receive that message and then extract the fully qwualified job name from the message data.

You’ll need to use that message data for just about any function that will return status information about a job that you submitted.

One function that you won’t need to use that message data for is if you simply receive messages from the message queue that you specify in the SBMJOB MSGQ() parameter. Sufficient status information will simply appear in the message queue as soon as its available from the system — assuming that all you need to know is whether the job is finished yet and whether it failed or not.

Tom

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

Happy Coding
DanF

I hope u got my answer.

Thanks
priya

• Specifies the message queue to which a completion message is sent when the submitted job has completed running, either normally or abnormally. If an abnormal ending occurs, the help information for the completion message specifies the possible causes.

The purpose of that parameter is so that the submitting job can monitor the submitted job and be notified when the job completes, and be notified about some conditions of the completion.

If you want JobA to submit JobB and to know when JobB completes, then submit JobB with a message queue specified. After the SBMJOB command completes, just have JobA wait for a completion message to arrive at the specified message queue.

Create a simple message queue in the application library and name it MONJOBB, or whatever name makes sense. Use that message queue just for this purpose.

Tom