On IBM i everything that runs is a job. Not a process: a job, with a name made of three parts, a description it takes its settings from, a log of its own, and a subsystem hosting it.
The full name is written number/user/name (for example 123456/JSMITH/CLOSE) and it is
the identifier to use wherever a specific job has to be named. Screens show it in three
separate columns: they need joining with slashes.
Job types
- Interactive: a terminal session, nowadays almost always an emulator. Born when somebody signs on, dead when they sign off.
- Batch: a job submitted to a queue, starting when there is room. This is the form all serious processing takes.
- Autostart: starts on its own when its subsystem starts: this is how services come up.
- Prestart: jobs sitting ready and waiting, so the cost of starting is not paid per request. These serve ODBC and JDBC connections and the network servers.
- System: the operating system's own, not yours to touch.
Subsystems
A subsystem is a run-time environment: a piece of memory, a set of rules about who may enter, and the jobs running inside it. The system ships several, and the names come up everywhere:
| Subsystem | What runs there |
|---|---|
QBASE or QCTL |
the controlling subsystem: it starts at IPL, and the operator controls the system through it from the console. The QCTLSBSD system value names it; the default is QBASE |
QINTER |
interactive sessions |
QBATCH |
batch jobs |
QSYSWRK |
the server daemons, except the file server and database server ones. Always started at IPL |
QUSRWRK |
the host server jobs: database, signon, remote command, data queue, network print |
QSERVER |
the file server daemon, its prestart jobs, and the database server daemon. If it is not active, connections to those servers fail |
QHTTPSVR |
web servers |
To see them, and who is inside:
WRKSBS
WRKSBSJOB SBS(QBATCH)
WRKACTJOB SBS(QINTER)
The subsystem description (an *SBSD object) holds the rules: which job queues it
serves and at what priority, how many jobs it may keep active at once, and which portion of
memory it runs them in.
Note
in many installations the application has a subsystem of its own, created years ago by whoever set the place up. Separating application work from QBATCH is not needless complication: it means being able to stop the application without stopping everything else, and giving that work memory and priority decided separately.
Job queues
A batch job does not start when you submit it: it enters a job queue (*JOBQ) and
waits. A subsystem draws from the queues on its list, up to the maximum number of active
jobs it is allowed.
SBMJOB CMD(CALL PGM(PRODLIB/CLOSE)) JOB(CLOSE) JOBQ(QBATCH)
WRKJOBQ JOBQ(QBATCH)
The queue is the simplest lever for controlling sequence: a queue served by one job at a time runs things in single file, which is exactly what is wanted for work that must not overlap; a period-end close, an archive reorganisation.
Warning
a held queue (HLDJOBQ, often during maintenance) accepts jobs and
starts none of them. It is not an error and shows up as no fault: jobs pile up politely
and next morning nothing has run. The same goes for a single held job in the queue, and
for a subsystem that was never started. Anyone investigating a batch that "did not run"
looks at WRKJOBQ before looking at the program.
Memory
Memory is divided into pools, and each subsystem runs its jobs in one. WRKSYSSTS
shows the pools with two numbers that matter more than the rest: the faulting rate and the
wait.
A pool that pages heavily is a pool too small for the work put into it, and the consequence shows up as general slowness rather than as an error.
Tip
the system can tune pools and activity levels by itself, with the QPFRADJ system
value, and by default it does: at restart and periodically afterwards. Sizing them by hand
makes sense in particular cases, and has to be redone whenever the workload changes.
Priorities
Every job has a run priority, coming from the class (*CLS) associated with the
subsystem, and changeable on the fly:
CHGJOB JOB(123456/JSMITH/CLOSE) RUNPTY(30)
Priority goes from 1 (highest) to 99 (lowest), and a class created with CRTCLS without saying
anything uses 50. IBM warns that the number is relative: a priority of 25 is not twice as
important as 50.
Tip
before raising the priority of a heavy batch job, remember that it competes for the processor with every other active job, sessions included: what it gains, the others lose. It is often more useful to lower the priority of a job that is causing trouble.
Watching, stopping, resuming
WRKACTJOB
WRKJOB JOB(123456/JSMITH/CLOSE)
HLDJOB JOB(123456/JSMITH/CLOSE)
RLSJOB JOB(123456/JSMITH/CLOSE)
ENDJOB JOB(123456/JSMITH/CLOSE) OPTION(*CNTRLD) DELAY(60)
Warning
ENDJOB with OPTION(*IMMED) closes the job without giving the program time to
finish: the system does its cleanup, the program does not (unless it handles the SIGTERM
signal). IBM writes that it can cause undesirable results if data has been partially updated,
and that it should be used only after a controlled end has been tried unsuccessfully.
*CNTRLD gives the program the time set in DELAY to finish on its own.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up