ASPs: how the system divides the disks

On an IBM i you do not choose which disk a library goes on. The system spreads data across all the units of the set it belongs to, and does so by itself. The question that follows is: which set?

The answer is the ASP, Auxiliary Storage Pool, which IBM's graphical interface calls a disk pool: a software definition of a group of disk units, which need not match how they are physically arranged. It is the only level of choice the system leaves you over where data lands, and therefore the only tool you have for isolating it.

The kinds of ASP

IBM splits them in two: the system ASP and user ASPs. User ASPs in turn are basic or independent, and the two behave differently.

A basic ASP gets its number from whoever creates it; an independent ASP is given a name, and the system assigns the number.

The system ASP plus all basic ASPs form what the documentation calls SYSBAS: it means "everything except independent ASPs".

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

SYSDISKSTAT has one row per disk unit: PERCENT_USED is how full that unit is.

Basic ASPs

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:

• Library ASP: holds libraries, documents and certain object types.
• Non-library ASP: holds no libraries, only three object types: journals, journal receivers and save files. The object's library must be in the system ASP; the object's storage, and everything added to it later, is in the user ASP.

CRTSAVF FILE(SAVFLIB/DSTSAV) ASP(4)

Overflow

When a basic ASP fills up, data overflows into the system ASP: the ASP enters overflowed status. Work carries on, but the isolation and protection the ASP was meant to give are lost.

Bringing overflowed objects back into their ASP, without an IPL, goes like this:

1. find the overflowed objects: DSPOBJD with DETAIL(*FULL) and OUTPUT(*OUTFILE) on every library in the ASP; in the output file the ODOASP field is 1 for overflowed objects;
2. save them to scratch media;
3. delete them (journals, journal receivers and physical files need extra steps first);
4. check that the ASP is no longer overflowed: a message in QSYSOPR says so.

For basic ASPs, automatic overflow recovery can also be enabled from System i Navigator disk management.

The defence is the occupancy threshold, which every ASP has and which defaults to 90%. It is changed from service tools: STRSST, option 3 (Work with disk units), option 2 (Work with disk configuration), option 3 (Work with ASP threshold). The message goes to QSYSOPR, which helps only if somebody watches that queue: this is why the messages chapter recommends creating QSYSMSG.

On a non-library ASP it is also worth watching how individual objects grow: IBM points to the MAXRCDS parameter of CRTSAVF and THRESHOLD of CRTJRNRCV.

Independent ASPs

iASPs are a different thing, not a basic ASP with a higher number. Four differences matter.

They are made available and unavailable. 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)

It plays no part in the IPL: the system checks that all its disk units are present when it is varied on. Until then its data cannot be reached.

Varying on is not instant, and IBM says what it depends on. If most user data is in the iASP and SYSBAS holds mainly the operating system, times are shortest; if a lot of data stays in SYSBAS, varying on takes more work, because database information has to be merged with the group's. After an abnormal vary off, rebuilding access paths also counts, and CHGRCYAP can limit it.

They move. In a cluster, an iASP associated with a switchable device moves from one system to another with no IPL: varied off on one node and on on the other. The data belongs to the iASP, not to the machine, which is why it is the building block of high availability on this platform. Copying to a second site (cross-site mirroring) and FlashCopy also exist.

They do not overflow. A full iASP does not spill into the system ASP: if it did it would lose its independence. When it nears its threshold you add disk units or delete objects.

They are a database of their own. Every iASP group is a separate relational database, with its own entry in the relational database directory:

WRKRDBDIRE

From outside you connect by naming it; from a job on the system you instead have to say explicitly that you want to work in there.

A job sees the iASP only with SETASPGRP

A job does not see an iASP's libraries until it sets its ASP group.

SETASPGRP ASPGRP(IASPPROD)

From then on the iASP's libraries are part of the thread's library name space, together with those of the system ASP and basic ASPs, and can be named with the ordinary LIBRARY/OBJECT syntax. Before that they are not there.

What cannot live there

An iASP cannot hold everything. Among the object types IBM lists as not supported are user profiles (*USRPRF), authorization lists (*AUTL), device, line and controller descriptions, job schedules (*JOBSCD), documents and folders (*DOC, *FLR). Libraries, files, programs, job and message queues, journals and journal receivers are.

Protection and failures

Mirrored protection is configured per ASP: one, some or all can be protected.

A separate ASP limits what has to be restored, not the outage. iASPs can in some situations also isolate a disk unit failure within them, and on an offline independent ASP mirroring or parity protection can be started without taking the system to DST.

When it is worth it

Journal receivers in a separate ASP are the classic case: they grow fast, and a non-library ASP exists precisely to keep them out of the system ASP. IBM uses the same example for iASPs: a group with the primary ASP for data and journals, and a secondary ASP for the receivers.

An iASP makes sense when there is, or will be, a high availability solution, but also on a single system: to keep rarely used data offline, shorten IPL and RCLSTG, save and restore by ASP, separate the data of an application or a group of users.

Not to go faster. Inside an ASP the system spreads data across all its units: splitting the disks into several ASPs gives each one fewer units to spread across. If speed is the goal, the split has to be measured, not assumed.

Not without somebody watching the thresholds. A basic ASP nobody supervises overflows sooner or later, 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, NUMBER_OF_DISK_UNITS,
       DEC(100 - (DEC(TOTAL_CAPACITY_AVAILABLE, 19, 0) * 100
                  / NULLIF(TOTAL_CAPACITY, 0)), 5, 1) AS PERCENT_USED,
       STORAGE_THRESHOLD_PERCENTAGE AS THRESHOLD
  FROM QSYS2.ASP_INFO
 ORDER BY ASP_NUMBER

ASP_INFO is a view with one row per ASP. It carries no ready-made usage percentage: it carries total and free capacity, in megabytes, and the percentage is computed. NUMBER_OF_DISK_UNITS counts a mirrored pair as one unit. ASP_TYPE is SYSTEM, USER, PRIMARY, SECONDARY or UDFS.

STORAGE_THRESHOLD_PERCENTAGE is the threshold: once reached, the system sends CPF0907 for the system ASP and CPI0953 for a user ASP. Putting it next to the real percentage says not only how full an ASP is, but how far it is from the point where somebody will notice.

Example. The numbers are made up, to show how it reads: a basic ASP 2 at 87% with its threshold at 90% is three points from the first message in QSYSOPR; if the row says 95% and the threshold is still 90%, the message has already gone out, and if nobody saw it the ASP may be close to overflowing.

Releases. WRKDSKSTS and the service tools are on any release. The IBM pages cited below are the 7.5 ones. QSYS2.SYSDISKSTAT and QSYS2.ASP_INFO are part of IBM i Services: 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 creates and deletes an independent ASP, and its device description, without going through service tools.

Sources

• IBM: Types of disk pools
• IBM: Basic disk pools
• IBM: Contrasting basic and independent disk pools
• IBM: Working with nonlibrary user ASPs and Creating objects in a nonlibrary user ASP
• IBM: Recovering an overflowed user ASP and Resetting an overflowed user ASP without an IPL
• IBM: Changing the storage threshold for an ASP
• IBM: Reducing the time to vary on independent disk pools
• IBM: Benefits of independent disk pools and Disk pool groups
• IBM: User databases on independent ASPs
• IBM: Set ASP Group (SETASPGRP) and Configure Device ASP (CFGDEVASP)
• IBM: Supported and unsupported object types
• IBM: How mirrored protection works
• IBM: ASP_INFO view and SYSDISKSTAT view