On an IBM i you do not choose which disk a library goes on. The system spreads every object across all available units, and it does so by itself. The question that follows is: all the units of what?
The answer is the ASP — Auxiliary Storage Pool. It is the only level of choice the system leaves you over where data physically lands, and therefore the only tool you have for isolating it.
One set, or several
An ASP is a group of disk units treated as a single space. Inside an ASP, distribution is automatic; between ASPs there is no communication at all: they are compartments.
There are three kinds, and they are not variants of the same thing — they behave differently.
| Numbers | What it is | |
|---|---|---|
| System ASP | 1 | Always exists. Holds the operating system, QSYS, and everything not placed elsewhere |
| Basic ASPs | 2 to 32 | Additional sets, always active, tied to this machine |
| Independent ASPs | 33 to 255 | Switched on and off on their own, and movable from one machine to another |
The system ASP plus all basic ASPs form what the documentation calls SYSBAS. It is a term you meet often and worth recognising: it means "everything except independent ASPs".
Unit 1 of ASP 1 is the load source, the disk the system starts from. It stays there and does not move.
WRKDSKSTS
SELECT ASP_NUMBER, UNIT_NUMBER, UNIT_TYPE,
DEC(PERCENT_USED, 5, 1) AS PERCENTAGE
FROM QSYS2.SYSDISKSTAT
ORDER BY ASP_NUMBER, PERCENT_USED DESC
Basic ASPs
These are the oldest and simplest form: an extra set of disks, always on, always attached to this machine. An object lands there because somebody decided so when creating it.
CRTLIB LIB(ARCHIVE) ASP(2)
CRTJRNRCV JRNRCV(JRNLIB/RCV0001) ASP(3)
A basic ASP comes in two kinds, and the distinction is sharp:
- Library ASP — holds libraries and everything inside them. The normal form today.
- Non-library ASP — holds no libraries, only certain object types: journal receivers, save files and documents. This is the historical form, created for exactly the most common use case: keeping journal receivers out of the system ASP so that their growth does not fill it.
Overflow
This is the behaviour that surprises people, and it is worth knowing before meeting it.
When a basic ASP fills up, the system does not stop and does not refuse the write: objects overflow into the system ASP. Work carries on, and the compartment built so carefully is no longer there.
Warning
overflow is a silent failure of the worst kind. The system sends a message and moves on, so there is no visible symptom: no application error, no batch job stopping. It is usually noticed later, looking at system ASP space and not understanding why it grew. And getting overflowed objects back into their ASP is not automatic: once space is freed, the objects that spilled out have to be dealt with — in practice by saving and restoring them.
The defence is the occupancy threshold every ASP has, set from service tools (STRSST,
work with disk units). Past the threshold the system sends a message to QSYSOPR — which
helps only if somebody watches that queue, and is why the messages chapter recommends
creating QSYSMSG.
Independent ASPs
iASPs are a different thing, not a basic ASP with a higher number. Four differences matter.
They switch on and off. An iASP is a device, with a device description, and has to be made available:
VRYCFG CFGOBJ(IASPPROD) CFGTYPE(*DEV) STATUS(*ON)
WRKCFGSTS CFGTYPE(*DEV) CFGD(IASPPROD)
While off, its contents do not exist as far as the system is concerned. Varying on is not instant: the time grows with the number of objects held, because the database has to rebuild its cross-references. On a large iASP that is minutes, and they belong in your restart timings.
They move. That is why they exist. An iASP can be detached from one machine and attached to another — between partitions, between clustered systems, or replicated at a distance. It is the building block high availability is made of on this platform: the data lives in the iASP, and on failure it is the iASP that changes owner, rather than the data being copied at the worst possible moment.
They do not overflow. Unlike basic ASPs, a full iASP is full: operations needing space fail, with an error. That is worse to suffer and better to manage, because the problem shows itself instead of hiding.
They have a database of their own. An iASP appears as a separate relational database:
WRKRDBDIRE
From outside you connect by naming it, and from a job on the system you instead have to say explicitly that you want to work in there. This is where nearly everybody trips the first time.
The gotcha: SETASPGRP
A job does not see an iASP's libraries until it joins its ASP group.
SETASPGRP ASPGRP(IASPPROD)
From then on the iASP's libraries are reachable and can sit in the job's library list; before that, they simply do not exist.
Warning
without SETASPGRP, a program looking for a library in the iASP gets an
object-not-found error — CPF9801 — and whoever investigates becomes convinced the
library was deleted. The library is there, and is visible to another job that set the
group. It is exactly the same kind of misunderstanding as the library list, one floor
down: the name is right, the environment you are looking in is not.
In batch work the SETASPGRP line goes in the CL before anything else, or is declared in
the job description through the INLASPGRP parameter.
What cannot live there
An iASP cannot hold everything. User profiles stay in SYSBAS, and with them system objects and configuration: these belong to the machine, not to the data that moves between machines.
Important
this is the consequence to understand before designing a switch. If an iASP moves from one system to another, the data arrives but the user profiles do not — they must already exist on the other machine too, with the same names and the same authorities. Keeping profiles aligned across nodes is part of the work of running high availability, and the iASP does not do it for you.
Protection is per ASP
Mirroring and RAID are configured per unit, and therefore in practice per ASP: each set can have its own protection level.
From this follows the real reason isolating data is worth anything. If an unprotected unit fails, the ASP it belongs to is lost, not the whole system: the others remain. Losing a data ASP means restoring that ASP; losing the system ASP means rebuilding the machine.
Warning
isolation is worth as much as the compartments are genuinely separate. A basic ASP that has overflowed into the system ASP has already mixed its data with system data, and the separation you believed you had is gone.
When it is worth it, and when not
It is worth it to keep journal receivers in a separate ASP: they grow fast, and their filling up must not touch the system. It is worth isolating the data of an application with its own retention or recovery requirements. An iASP is worth it when there is, or will be, a high availability solution: without one, that road is travelled other ways, all of them more laborious.
It is not worth it to create ASPs to go faster. The intuitive reasoning — "separate the heavy data so it does not get in the way" — is nearly always wrong on this platform, because the system gains performance by spreading across as many arms as possible. Splitting ten disks into two ASPs of five gives each workload half the arms it had.
It is not worth it to create ASPs without deciding who watches the thresholds. A compartment nobody supervises is a compartment that sooner or later overflows, and at that point you have paid for the complication without getting the isolation.
Seeing where you stand
WRKDSKSTS
STRSST
SELECT ASP_NUMBER, ASP_TYPE, ASP_STATE,
TOTAL_CAPACITY_AVAILABLE, PERCENT_USED
FROM QSYS2.ASP_INFO
ORDER BY ASP_NUMBER
Releases. WRKDSKSTS and the service tools are on any release. QSYS2.SYSDISKSTAT and
QSYS2.ASP_INFO are part of IBM i Services, added at different releases and extended over
time: if a query answers SQL0204 — object not found — that view is not on this system,
and the same information is still available on screen. The CFGDEVASP command, which
creates and deletes an independent ASP without going through service tools, is more recent
than iASPs themselves: where it does not exist, configuration is done from STRSST.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up