Administering an IBM i: how the system works · Chapter 3 of 10

Objects, libraries and the file system

6 min read · Software

Reviewed on Verified on IBM i 7.5

Log in to save

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. A library cannot hold two objects with the same name and the same type; with different types it can, and they do not get in each other's way.

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 *LIB lives in QSYS.
  • QGPL: the general purpose library. An object created without naming a library ends up here when the job has no current library (*CURLIB). That is why on a system with many years behind it it is a good place to look for things created without much thought.
  • 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. For example the message queue CRTUSRPRF creates for each user, named after the profile, lives here.

Warning

IBM says to use QSYS for system objects only, because whatever is added to it is lost when a new release is installed. The same caution applies to the other IBM libraries beginning with Q: your own objects belong in your own libraries.

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: PRODLIB becomes /QSYS.LIB/PRODLIB.LIB and 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 file system of documents and folders from the old document management.

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 does not appear in the library lists people habitually check. The same goes for spool. A periodic space check, with WRKLNK or with SELECT * FROM TABLE(QSYS2.IFS_OBJECT_STATISTICS(...)), avoids the surprise.

Sources

Back to the guide index

#oggetti #librerie #ifs
← Back to blog

You might also like

Comments

No comments yet. Be the first to comment!

You need an account to comment. Log in · Sign up