Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.
Good morning. I know there is a TAATOOLS command for checking whether or not a job is active, but we don't have TAATOOLS. Is there any other way to check for a job running in batch? What I'm doing is creating a process that will submit jobs automatically as the previous job completes.
Thanks!
You can do something like this. Do a wrksbsjob to a print file, copy the print file to a PF. Read the PF looking for the job you want. this is only part of the cl but I think it gives you an idea
RTVJOBA JOB(&JOB) USER(&USER) NBR(&NUMBER)
WRKSBSJOB SBS(QBATCH) OUTPUT(*PRINT)
MONMSG MSGID(CPF1003) EXEC(DO)
GOTO CMDLBL(ENDIT)
enddo
/* Copy the Spool File to a Physical File */
CPYSPLF FILE(QPDSPSBJ) TOFILE(CHK_CRMP) +
JOB(&NUMBER/&USER/&JOB) SPLNBR(*LAST) +
/* Read the file and insure that the interface is running */
/* If it is not send an e-mail */
READ: RCVF
MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(ENDIT))
IF COND(&Sub_Job *eq 'Job Name') THEN(Do)
CHGVAR VAR(&GOT_IT) VALUE('1')
GOTO CMDLBL(READ)
ENDDO
IF COND(&Sub_Job *eq ' ') then(Do)
GOTO CMDLBL(READ)
enddo
CHGVAR VAR(&Check) VALUE(%sst(&sub_job 1 7))
IF COND(&Got_it *eq '1') then(Do)
If Cond(&Check *eq 'CRM1000') then(do)
CHGVAR VAR(&COUNT) VALUE(&count + 1)
enddo
enddo
GOTO CMDLBL(READ)
Chris, how do you know what job it is that you want to check?
Hi Bob. I just need to check based on submit job name.
Perhaps there may even be something I can do within the activation group??? You see, the program I'm writing submits a job to batch, then I want it to wait until that job finishes before it submits the next job,etc.....
I use an API in the RTVSBMJOBA (Retrieve Submitter's Job Attributes) command that does the other way round--perhaps you can use it to do what you want--assuming you know the job name. I'll look at my tool kit over the weekend and see what I have that might be helpful.
Thanks, Bob. I appreciate it. Have a great weekend.
After reading your entire question it seems to me that you are looking for something like the Send Scope Message (QMHSNDSM) API. This API allows you to determine when a program or job ends.
Using this API you can start another job when the previous job ends.
Chris, is there some reason the RTVJOBA command doesn't give you what you want?
Or do you not have the job name/info? In other words, you need a generic lookup/test for active?
Does RTVJOBA give the current status (*JOBQ, *ACTIVE, *OUTQ)?
I've used QUSRJOBI. JOBI0100 has job status at offset 50 dec. (Don't confuse this with active job status in JOBI0200.)
I don't think RTVJOBA is what he's looking for. He says that TAATOOLS has a command for checking whether or not a job is active. Think about that...he is wanting to see if another job is still running or not.
He then goes on to say he is creating a process that will submit jobs automatically as the previous job completes. He wants to create a process that reacts to jobs ending by submitting new jobs.
This is why I suggested the Scope Message API and why RTVJOBA is not what he's looking for.
Fish, right, but RTVJOBA accepts a JOB parameter so he could check the other job's state. However he would need to know the full job/name/nbr/user info that a "Check if a job with this job name is running" command would not.
But the QMHSNDSM API is a wonderful solution if he wants to call a program when the job ends--which would then do something to notify his "waiting to submit" routines.
I agree...I was just thinking that using QMHSNDSM might save him some development time.
For job I just sumbitted information, I used to receive the "Job Submitted" message, pull the MSGDTA for the job information -gives you job name/user id/job number. From that point on I can use this information for anything I choose.
We used to use the information to record on a file that a job had been submitted, time/date, etc. Then when the job completed it would update the record as complete. We used the file to determine if the job had run for the day, where only a single occurrance was allowed to run if we could submit it. And a host of operations task can be run validations.
> Fish, right, but RTVJOBA accepts a JOB parameter so he could check the other job's state.
Since when? AFAIK, it only gets info the job running that command, not other jobs on the system. I'm on 6.1.
I use the QUSRJOBI API with format JOBI0400.
Never mind, I just read this: "Hi Bob. I just need to check based on submit job name."
Can you get the full JOBNAME/JOBUSER/JOBNUMBER? When I submit a job, I either grab the job info from the CPC1221 message or have an RPG that is running in new job write a record to a PF.
Chris Ringer
Here is what he said 4 days ago..."the program I'm writing submits a job to batch, then I want it to wait until that job finishes before it submits the next job,etc....."
The best technique would be to use the Scope Message API that I suggested and let the system do all the work. All you need to do is call the API to register the exit point to call a CL program when the current job ends. The CL that is called by the system would submit the "next job" and that job may also use the Scope Message API to kick off yet another job.
Using the RTVJOBA, or the equivilant API, would mean that some additional program would have to be developed and some additional job would have to be active to monitor all these other jobs. You can do it this way, but it sure sounds like a lot of extra work to make this happen. If you do it this way then also remember that whatever job will do a RTVJOBA and submit the next job would have to be active until ALL your jobs have completed.
In places I have worked, most folks seem to like using a data area to store a set of jobs status flags, with the submitting job checking the flags each couple of minutes to see when the status is set to allow submit of the next job. This also helps if a job needs to complete successfully, since the status will not update if the job fails.
My personal thought on this would be to use a data queue, as the waiting job does not need to cycle, check, wait (repeat) until the data area status is what it needs to be, you can check the data queue message the moment it arrives. And you still have the completed successfully safety.
The problem with checking to see if a job is not active, is you do not know if it completed successfully, failed or was killed by user/operator action. And if I don't care on the completion status then I would use a jobq with single entry to the subsystem and have the jobs just queued there so that one becomes active as soon as the current ends.
That is a good point Neil. I didn't think about him needing to know if the job ended normally or abnormally. I was thinking that I had done that in the past so I dug out my code...here is what I do (maybe this will help):
Using a file that contains a job stream ID we store the program calls and/or command strings that need to be ran and in what order they must run. Each also has a flag that tells us whether to stop if the command fails or continue to the next command. We also have a field for a command to call when it fails abnormally (most people simply use SNDMSG or SENDEMAIL to tell someone that it failed). Other fields include job de!--script--ion names, job queue names, etc.
I have a generic RPG wrapper that we can either pass a job stread ID or command strings to. It registers a program using the QMHSNDSM API to handle abnormal ends, if necessary. Then I call the command/program that needs to be ran. I use the QCAPCMD API for this. When control is returned to my RPG program I delete the scope message if one was previously sent. I monitor and check for errors and, if necessary, call the program to handle abnormal ends.
If a second program should be submitted when the current program ends normally then my generic RPG program issues a SBMJOB to itself passing the new command string and all the other new parameters for processing. Another option allows the same job to grab the next program/command and just continue looping until all programs have been processed. This is sometimes preferred when we don't wont jobs to get backed up in a job queue.
We can start up one of these processes from a menu option, a job scheduler, or from a start command embedded in a CL program.