Everything that exists on the system is an object, and every object lives in a library. Those are the two sentences the rest of this chapter follows from.
The types you actually meet
There are dozens of object types, but the ones a sysadmin sees daily are few:
| Type | What it is |
|---|---|
*LIB |
a library |
*FILE |
a file: data, source, display, printer |
*PGM |
a compiled program |
*USRPRF |
a user profile |
*JOBD |
a job description: where a job takes its settings from |
*OUTQ |
an output queue, where printouts end up |
*JOBQ |
a queue of jobs waiting to start |
*SBSD |
a subsystem description |
*MSGQ |
a message queue |
*DTAARA |
a data area: a value that outlives the job |
The type is stated in commands, and it has to be: DLTF deletes a file, DLTPGM a
program, and generic commands like WRKOBJ ask for OBJTYPE because two objects of
different types can share a name in the same library without conflict.
Note
a data file contains members. It is the most visible legacy of the record
model: a source file holds one per program, and a data file can hold more than one too,
something seen today almost only in historical archive files. Many commands therefore
have an MBR parameter, and when MBR(*FIRST) is not what you want, the behaviour is
inexplicable until you notice the parameter.
Libraries are one level deep
A library contains objects. It does not contain other libraries. There is no path, no
hierarchy, no sublevel to descend into: an object's full address is LIBRARY/OBJECT and
that is the end of it.
Anyone arriving from a file system finds this awkward for a week and then realises the hierarchy's job is done by something else — the library list, which is the next chapter, and which is the real reason one level is enough.
Some libraries are always there and are worth recognising:
- QSYS — the system library. It holds every command, every operating system program,
and — the single exception to the rule — libraries themselves: an object of type
*LIBlives in QSYS. - QGPL — the general purpose library. The warehouse for whatever found no other home. On a system twenty years old it is the first place to look to see what was done in a hurry.
- QTEMP — a library private to each job, created when the job starts and deleted when it ends. Two jobs creating a file of the same name in QTEMP cannot see each other. It is the right place for work files, and also the most common trap: an object put in QTEMP by one program no longer exists for the next one if that runs in a different job.
- QUSRSYS — system data belonging to the installation rather than to IBM: user message queues, lists, some configuration.
Warning
putting your own objects inside libraries beginning with Q is a habit that
gets paid for at upgrade time. IBM libraries are replaced, and whatever was added to them
is not guaranteed to survive. QGPL and QUSRSYS are the exceptions meant for this; the
others are not.
Looking at what is there
The interactive way:
WRKLIB LIB(PROD*)
WRKOBJ OBJ(PRODLIB/*ALL) OBJTYPE(*FILE)
DSPOBJD OBJ(PRODLIB/ORDERS) OBJTYPE(*FILE) DETAIL(*FULL)
The same in SQL, which is the route to take when the result needs sorting, filtering, or feeding into a program:
SELECT OBJNAME, OBJTYPE, OBJOWNER,
OBJSIZE / 1024 / 1024 AS MB,
LAST_USED_TIMESTAMP, OBJTEXT
FROM TABLE(QSYS2.OBJECT_STATISTICS('PRODLIB', '*ALL'))
ORDER BY OBJSIZE DESC
Tip
every object has a free-text description field, the text. It is by far the
most useful documentation on the system, because it travels with the object and shows up
wherever the object does. It is worth filling in — with CHGOBJD ... TEXT('...') — and
worth reading before wondering what some object you stumbled on is for.
The other file system
Alongside libraries the system has a genuine hierarchical file system, the IFS (Integrated File System), with directories, paths, permissions and long names. Web server logs live there, along with files exchanged with the outside world, PDFs, scripts, Java.
The IFS is organised as separate file systems all visible under the root /:
/— the hierarchical part, the one you expect;/QSYS.LIB— libraries seen as directories:PRODLIBbecomes/QSYS.LIB/PRODLIB.LIBand a file/QSYS.LIB/PRODLIB.LIB/ORDERS.FILE. It exists so that tools which only understand paths can reach objects;/QOpenSys— a case-sensitive file system, for software ported from Unix;/QDLS— the old document system, at this point history.
The commands are different: WRKLNK instead of WRKOBJ, CPY instead of CPYF, CHGAUT
instead of GRTOBJAUT. Anyone connecting over SSH or through ACS moves around the IFS with
the usual Unix commands.
Warning
the IFS grows without anyone noticing, because it appears in none of the
lists people habitually check. Spool and IFS are the two most frequent causes of a disk
filling up on an otherwise quiet system. A periodic space check, with WRKLNK or with
SELECT * FROM TABLE(QSYS2.IFS_OBJECT_STATISTICS(...)), avoids the surprise.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up