Check for active jobs
Does anyone have a simple CL to check for active jobs in a subsystem before ending it?
Software/Hardware used:
Software/Hardware used:
ASKED:
July 28, 2005 4:07 PM
UPDATED:
October 31, 2009 7:14 AM
Answer Wiki:
Not actual CL to do it neatly as it doesnt allow u to output to a file. Try this in your CL
1) Run the WRKSBSJOB and specify *PRINT. this will produce a report
2) Use CPYSPLF to copy the current spool file to an output text file w all the headings and footings
3) Use SQL to cut&trim out the "dirty" bits,
4) U then use SQL to output to a "cleaner" file w/o headings, footings but w these 4 columns
JobName, User, Number, Type, Status
An "Active" in status column indicates job is active
*NOTE: Since the system is very dynamic, there is no easy way to say for sure that at that pt u ran the report, if job is active, it will still be active 10secs later.
If u are just checking to end the subsystems, u can do a hold instead when there are no jobs running in that subsystem. Its just too much effort to do this via CL.
If u are shutting system down, use direct systems command to WRKACTJOB then sendmessage to all active terminals. Kill those active users that showed up as "QPADExxxxx" in QINTER. If there are active jobs running, u may want to let those run to completion, u can hold those jobqueues to disallow later jobs to be run (u dont hold a running job!, just hold the jobq will do. Active jobs will continue to run in background, but once jobq is held, anyjobs wont run on its own steam!)
After all jobqs are held, Then do a system shutdown for backup purposes. Any jobs submitted to that subsystem will wait till u released it and wont "get lost"
Its probably a good idea to get thru discussed w your boss on policies and make very sure that every user is aware of the cut-off times. This will save you from getting unnecessary complaints and misunderstandings
eg of SQL to take out the headings,
SELECT LTRIM(RTRIM(SUBSTR(PTEXT,1,10))) JOBLV1,
LTRIM(RTRIM(SUBSTR(PTEXT,17,10))) JOBLV2,
LTRIM(RTRIM(SUBSTR(PTEXT,47,10))) JOBLV3,
LTRIM(RTRIM(SUBSTR(PTEXT,59,2))) SYSTEM,
LTRIM(RTRIM(SUBSTR(PTEXT,75,3))) SYSVER,
LTRIM(RTRIM(SUBSTR(PTEXT,92,32))) JOBDES,
FROM S2KLIB/MNUFILE
WHERE LTRIM(RTRIM(SUBSTR(PTEXT,82,60)))
NOT LIKE 'Description%' AND
LTRIM(RTRIM(SUBSTR(PTEXT,82,60))) NOT LIKE '%2000%' AN
LTRIM(RTRIM(SUBSTR(PTEXT,82,60))) NOT LIKE 'Page%' AND
LTRIM(RTRIM(SUBSTR(PTEXT,82,60))) <>'' AND
LTRIM(RTRIM(SUBSTR(PTEXT,82,60))) NOT LIKE '==%' AND
LTRIM(RTRIM(SUBSTR(PTEXT,82,60))) NOT LIKE '**%'
AND LTRIM(RTRIM(SUBSTR(PTEXT,1,15))) NOT LIKE 'QTEMP%'
Basically, u take out the parts that are headings and the text statements (the SQL i provided is meant for another spool report). The format of the report will look like this:
5769SS1 V4R2M0 980228 Work with Subsystem Jobs
Subsystem . . . . . . . . . : QBATCH
Job Name User Number Type -----Status----- Function
No jobs to display.
5769SS1 V4R2M0 980228 Work with Subsystem Jobs
Subsystem . . . . . . . . . : QCMN
Job Name User Number Type -----Status----- Function
QACSOTP QUSER 379782 PJ ACTIVE
QLZPSERV QUSER 379807 PJ ACTIVE
QNMAPINGD QUSER 379778 PJ ACTIVE
QNMAREXECD QUSER 379781 PJ ACTIVE
QNPSERVR QUSER 379806 PJ ACTIVE
======================================================
Essentially never process a spooled file to gather system information. It's a waste of time and system resources, and the format of printed system info is never guaranteed. API output can be assumed to be the same in future releases and is definitely immune to such external elements as CHGPRTF from a well intentioned co-worker. Further, it's usually easier to call the appropriate API and to process its returned info. Even further, the info from an API stands a greater chance of being accurate and current simply because it will be available to the calling program sooner.
In this case, the API is the <a href="http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/apis/qwdrsbsd.htm">Retrieve Subsystem Information (QWDRSBSD) API</a>. The link is for V5R4, but it's appropriate for V2R1 and later.
<pre>
pgm ( +
&pSbs +
&pSbsLib +
&pJobCnt +
)
dcl &pSbs *char 10
dcl &pSbsLib *char 10
dcl &pJobCnt *int 4
dcl &Sbs *char 10
dcl &SbsLib *char 10
dcl &rcvvar *char 76
dcl &qSBSNam *char 20
/* Save parms... */
chgvar &Sbs &pSbs
chgvar &SbsLib &pSbsLib
/* Retrieve subsystem status info... */
chgvar &qSBSNam ( &Sbs *cat &SbsLib )
call QWDRSBSD ( +
&rcvvar +
x'0000004C' +
'SBSI0100' +
&qSBSNam +
x'00000000' +
)
/* Extract job count for return... */
chgvar &pJobCnt %bin( &rcvvar 73 4 )
Exit:
return
endpgm
</pre>
That may be compiled as a program or as a procedure. An example of calling it as a program:
<pre>
pgm
dcl &Sbs *char 10 value( 'QSERVER' )
dcl &SbsLib *char 10 value( '*LIBL' )
dcl &JobCnt *int 4
call RTVSBSJOBS ( +
&Sbs +
&SbsLib +
&JobCnt +
)
dmpclpgm
return
endpgm
</pre>
The example retrieves the count of currently active jobs in a subsystem named QSERVER. The library is required, but *LIBL may be used. If the subsystem description is not in a library in the library list, the API call will return an error. Errors can be monitored after the CALL.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
What will you be doing once you know? If all you need to do is to let jobs finish you can do a controlled end:
.
. endsbs your_sbs
.
Assumning you haven’t changed the command defaults that translates to:
.
. ENDSBS SBS(QBATCH) OPTION(*CNTRLD) DELAY(*NOLIMIT)
.
and would prevent new jobs from starting and active ones to finish.
If you simply want to know whether a named SBS has active jobs at any given time, use the QWDRSBSD API. This API will tell you the number of current, active jobs in a SBS.
jaicee asks “Why?” Reason for asking are given after. If the intention is to end the subsystem if no jobs are active, then simply go ahead and end it, with a delay. Jobs that are properly programmed will detect the ending subsystem and shut themselves down in an orderly fashion or they reach their natural point of ending before the delay expires. Jobs that aren’t properly programmed are going to have to be cancelled anyway.
And as jaicee noted, an ending subsystem won’t allow new jobs to start. It will, however, allow its jobs to finish — as long as they do so before the delay time runs out. When the time expires, jobs get an ‘end job’ signal sent to them pretty much exactly like an operator issuing ENDJOB.
One minor note — a subsystem won’t end until all of its jobs end first. And a subsystem can’t be restarted until it has ended.
Tom