A well-kept IBM i asks for little, and that is its danger: it asks for so little that people forget to look at it, and the things that go wrong all go wrong together after years of silence.
This chapter is the list of things to look at while nothing is happening.
Fixes: PTFs
Fixes are called PTFs (Program Temporary Fix) and come in three forms: individual, collected in a cumulative package, or grouped by area — Db2, HIPER, TCP/IP, Java, security. Group PTFs are the ones followed in practice, because IBM updates them periodically and each has a running level.
WRKPTFGRP
SELECT PTF_GROUP_NAME, PTF_GROUP_LEVEL, PTF_GROUP_STATUS
FROM QSYS2.GROUP_PTF_INFO
WHERE PTF_GROUP_STATUS <> 'NOT APPLICABLE'
The level should be compared with the current one published by IBM: it is the quickest way to know whether a system is up to date or has been standing still for years. The security group deserves separate attention, because it is the one where falling behind costs most.
Note
some PTFs apply immediately, others are delayed and become active only at the next IPL. That is why an update campaign is planned together with an IPL, and why a system that is never restarted can have PTFs loaded but not active.
The restart
A restart is called an IPL (Initial Program Load). An IBM i can stay up for years, and many do; a planned periodic restart is still good practice, because it activates delayed PTFs and returns the system to a clean state.
PWRDWNSYS OPTION(*CNTRLD) DELAY(600) RESTART(*YES)
Warning
OPTION(*IMMED) powers down without giving jobs time to close. On a system
with active work it is the last resort, not the first: *CNTRLD with an adequate delay
lets what is half done finish.
Whoever runs the machine also needs to know two things that live outside the operating system: the mode and the IPL side (A, B, C, D), set from the panel or the HMC console. Side B is the one that starts with temporarily applied PTFs, and it is the normal one; side A is without. It is a distinction first met during a restore — that is, at the wrong moment to discover it.
Disk space
The number to watch is the percentage used on the system ASP.
WRKSYSSTS
SELECT UNIT_NUMBER, UNIT_TYPE,
DEC(PERCENT_USED, 5, 1) AS PERCENTAGE
FROM QSYS2.SYSDISKSTAT
ORDER BY PERCENT_USED DESC
Above 80% it is worth acting, and well before 90% an answer should already be ready: the system behaves badly when space runs out, and the threshold beyond which it stops working altogether is not somewhere you want to arrive.
The causes, in order of frequency: spool never deleted, journal receivers never detached, an IFS grown unchecked, and test libraries forgotten from a project that ended three years ago.
System values
These are the machine's global settings, some harmless and some decisive.
WRKSYSVAL
DSPSYSVAL SYSVAL(QSECURITY)
The ones worth knowing by name have already appeared in earlier chapters: QSECURITY and
QPWDLVL for security, QSYSLIBL and QUSRLIBL for library lists, QPFRADJ for memory,
QRCLSPLSTG for spool, QAUDCTL for auditing.
Tip
a listing of the system values saved once a year and compared with last year's is a form of documentation costing five minutes. The question "who changed this, and when" is among the most frequent and among the hardest to answer after the fact.
Schedules
The system has a scheduler of its own:
WRKJOBSCDE
ADDJOBSCDE JOB(CLOSE) CMD(CALL PGM(PRODLIB/CLOSE)) +
FRQ(*MONTHLY) SCDDATE(*MONTHEND) SCDTIME(230000)
Warning
a held entry is the number one cause of "it did not run last night".
Somebody holds them during maintenance and nobody releases them. A morning check listing
held entries —
SELECT SCHEDULED_JOB_NAME, STATUS FROM QSYS2.SCHEDULED_JOB_INFO WHERE STATUS = 'HELD' —
costs half an hour of work and closes an entire class of failures.
What to look at, and how often
Not a rule; a reasonable starting point to adapt to the installation.
| When | What |
|---|---|
| Every morning | messages in QSYSOPR and QSYSMSG, outcome of the night batch, held schedule entries |
| Every week | disk space, backup outcomes, job logs of failed jobs |
| Every month | PTF group levels, spool and IFS growth, long-idle profiles |
| Every year | a restore test, review of profiles with special authorities, comparison of system values |
Tip
every one of these items is a query or a command, and nearly all of them can run on their own and be emailed. A check somebody has to remember to perform is a check that, sooner or later, does not get performed — and it is always in the month it mattered.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up