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 |
|---|---|
QCTL |
the controlling subsystem, the first to start |
QINTER |
interactive sessions |
QBATCH |
batch jobs |
QSYSWRK |
system service jobs |
QUSRWRK |
work the system does on behalf of users |
QSERVER |
file and database access servers |
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
on nearly all modern systems it is better to let the system do it, with
QPFRADJ set so it tunes the pools itself, than to size them by hand. Manual tuning
makes sense in particular cases and has to be redone whenever the workload changes; the
automatic kind follows the workload on its own.
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)
Lower values mean higher priority. Interactive jobs typically run at 20, batch at 50.
Warning
raising a heavy batch job to interactive priority does not meaningfully make it finish sooner, but it does slow everybody's sessions down. In practice priority is more often useful for lowering that of a job causing trouble than for raising that of an urgent one.
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 letting it finish what
it was doing. If it had a transaction open under commitment control, the transaction is
rolled back — which is the right behaviour — but if the program tracks processing state
its own way, you are left half done, and putting things right is manual work. *CNTRLD
with a sensible delay is worth trying first.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up