Administering an IBM i: how the system works

2 min read · Software

Reviewed on Verified on IBM i 7.5

Log in to save

Coming to an IBM i from Linux or Windows you meet different words, such as library, subsystem, output queue, library list, and different ideas beneath the words: the system is built on a model of its own.

This guide explains that model. It is not a list of commands to memorise: it is the map that makes those commands predictable, and each chapter carries the commands and queries to look at things on your own system.

Who it is for

Anyone handed an IBM i who has to start answering for it: the sysadmin who has just lost the person who looked after the machine, the developer who has always worked inside the application and now has to understand what sits underneath, the consultant walking into an environment they did not build.

No RPG required. What is required is access to a system, even read-only, because almost everything written here can be looked at on your own.

How it is organised

Read the chapters in order the first time: each one uses terms defined in the ones before. After that they work on their own.

Part Chapters
How the machine is built what an IBM i is, ASPs
How data is organised objects and libraries, the library list
How it works jobs and subsystems
Who may do what profiles, authorities and security levels
What whoever runs it answers for messages and the job log, the spool, saving, routine maintenance

Each chapter lists at the end the IBM pages it rests on, for release 7.5.

A note on names

The operating system was called OS/400, then i5/OS from V5R3, and since 2008 IBM i; the machines have changed name several times. On site people still say "the AS/400" about any generation. This guide uses IBM i for the operating system and AS/400 where that is the name the thing goes by; the releases, one by one, are under Releases.

Chapters in this guide

  1. What an AS/400 is, and why it resembles nothing else The operating system does not talk to the hardware, and programs do not talk to memory. Almost everything else follows from those two choices.
  2. ASPs: how the system divides the disks System, basic and independent ASPs: what differs between the three, what happens when one fills up, and why a job can fail to see a library that exists.
  3. Objects, libraries and the file system Where things live on an IBM i: one level of libraries, no folders inside folders, and alongside it a file system that behaves the way you expect.
  4. The library list The mechanism that explains why the same program works for you and not at night. If one thing in this guide is worth understanding properly, it is this.
  5. Jobs, subsystems and queues How the system decides where a job runs, with how much memory and at what priority. This is the part you touch when something is slow.
  6. Profiles, authorities and security levels Special authorities, object authorities, groups, lists and adopted authority, the QSECURITY levels. With the queries to see who can do what.
  7. Messages, QSYSOPR and the job log Message queues, QSYSMSG, automatic replies and the job log: why it is sometimes missing, and how to find the first error in it with SQL.
  8. The spool: printing and output queues On an IBM i you do not print: you produce spool. Understanding the difference also explains why the disk fills up.
  9. Saving and restoring What has to be saved, what journals recover, and the question you must be able to answer before it matters: how much work gets lost.
  10. Routine maintenance PTFs and groups, IPL and sides A and B, disk space, system values and schedules: what to check, with which query, and how often.
#sistema #amministrazione #base
← 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