A Beginner’s Guide to IBM i System Administration

IBM i automatically handles many system administration tasks and comes equipped with a number of built-in functions and utilities that, on other operating systems, would require a large team to manage.

Here are ten system utilities where IBM i gives you a boost in system administration, along with our recommendations to maximize management.

History Log

Since day one, the system has been shipped with the system value QHSTLOGSIZ set to 5000, the number of records allowed in a single QHST log file before starting a new one.

It used to be that there was very little activity on the system so 5000 was an acceptable limit. Today, we have hundreds—even thousands—of users accessing the system and its data via various methods. Add to that the fact that much more information is being logged on IBM i, equating to a new QHST file being created every few minutes.

Recommendation: Set the QHSTLOGSIZ value to *DAILY so the operating system generates a new QHST file automatically each day.

Message Queues

IBM i is great at logging events, which typically go to the history log, audit journal, or message queues, but did you know that a message queue can contain as many as 75,000 messages at maximum? Without any housekeeping, these message queues can quickly become full, potentially resulting in jobs or processes stopping.

There is a system value QJOBMSGQFL that allows you to dictate, at a system level, what should occur when a queue is full. The system value is shipped with *NOWRAP (do not wrap).

Recommendation: Consider changing the system value to *WRAP. This can also be overridden on a queue-by-queue basis using the CHGMSGQ command.

If you’re relying heavily on QSYSOPR, you should know that this queue is cleared at IPL time, wiping away your audit trail.

Recommendation: Consider using the QSYSMSG message queue. QSYSMSG is not cleared during IPL, creating a permanent audit trail. Plus, only significant, relevant messages appear on it, not application- or hardware-related messages of little or no relevance.

Create the QSYSMSG message queue using this command: CRTMSGQ MSGQ(QSYS/QSYSMSG) TEXT('Critical Messages')

Learn more about message queue management here >

Disk Space

Large IBM i estates find that their disk space occupancy grows organically by 30 percent year on year, but it’s harder to see what’s actually growing and (more importantly) what can you do about it.

The system automatically generates a “CPF0907 Serious storage condition may exist” message on QSYSOPR and QHST when the system auxiliary storage pool *SYSBAS reaches a threshold, which can be set within System Service Tools and defaults to 90 percent.

Outside of this message, there are no other real-time notifications for object or libraries sizes. So how should you keep a handle on disk space occupancy?

Recommendation: These two IBM i commands can provide you with some high-level statistics as to what’s occupying the space:
 

RTVDSKINF – Retrieve Disk Information

This command should be submitted to batch at a quiet time on the system. It looks at every object on the system and collates data such as size, last changed, last used, percentage of disk it occupies, and owner.

PRTDSKINF – Print Disk Information

This command works in tandem with RTVDSKINF. Once the Retrieve Disk Information job has completed, you're free to extract the data via the Print Disk Information command focusing on libraries, folders, object owners, objects, or system information, optionally selecting the sizes and names of particular areas of interest.

If you would like a graphical view of storage vs. a report, take a look: Learn more about disk space management here >

Memory

In theory, you could run your whole application in memory on Power9 or 10, but memory comes at a price and should be closely managed.

The system value QPFRADJ (Performance Adjustment) is shipped turned on and adjusts system memory pool sizes and activity levels (maximum number of threads that can concurrently use the processor) both at IPL and automatically as and when required to achieve optimum performance.

Recommendation: Try the WRKSYSSTS (Work with System Status) command. You can observe the system pool sizes and the maximum number of threads allowed per pool, both of which can be manually adjusted should you have reason to change them.

In addition, if you use the <F11> key, you can toggle round to see the Wait to Ineligible and Active to Ineligible values. Normally these values should be 0. Anything other than 0 tends to indicate that threads have either been waiting or active before being paged out with work still outstanding. In which case, further analysis is strongly advised.

If you need to tune private memory pools, we do have a memory manager: Learn more about our memory manager here >

Exit Points

System administrators often overlook IBM i exit points despite auditors who are quick to shine a light on gaps. As of IBM i 7.2, there are 133 exit points. These are parts of the operating system where control is passed to one or more programs (exit programs).

Of these 133, there are really only 27 that you need to be concerned about. Of those, only 12 provide systems or data access. Do you know who’s accessing your system and what they’re accessing?

Recommendation: Since exit points provide routes into the system, they are extremely powerful and should be managed carefully with an exit point manager tool. This way you can both audit and control traffic traveling through them.

Learn more about exit point security here >

Object Size

There really are no housekeeping utilities in the IBM i operating system to maintain the integrated file system (IFS) so it can grow quite rapidly. One gigabyte of small IFS objects takes longer to save (and restore) than a one-gigabyte large IFS object so it’s important to be equally aware of larger IFS objects and smaller objects that have not been used for a long time.

There is a little-known limit of 360,000 objects allowed within a library in the QSYS.LIB file system. Your application will continue to work normally if this limit is reached, but you will no longer be able to back up the library.

When attempting to save the library, the system won’t really generate a warning or escape message other than “CPF3770 No objects saved or restored for library &1”, which doesn’t exactly scream out at you.

Recommendation: Ensure that your libraries do not hit the 360,000 objects limit or you may find yourself unable to recover your application in the event of a failure. Refer back to the system utilities discussed in the Disk Space section to identify object sizes and number of objects residing in libraries.

Spooled Files

The “jobs in system” figure visible on the WRKSYSSTS display is comprised of all jobs that are queued to run, jobs that are currently running, and jobs that have already run and have spooled files. IBM i has to look after each and every job in the system so it stands to reason that the more jobs there are, the more processing it takes to manage them.

Job logs and general system output can be adequately maintained via the options provided on the Operational Assist menu, where you can define the number of days to keep these spooled files.  

Recommendation: Keep user- and application-generated spooled files on the system no longer than one to two months. Any longer and spooled files can become cumbersome to locate, at which point we advise you should look into a specific tool for spooled file archive and retrieval and/or use BRMS. 

Journal Receivers

With system availability at the top of everybody’s wish list, high availability applications are now commonplace. Many of them use journaling to help keep the production and standby systems synchronized.

Journal receivers can become very large very quickly. It’s not uncommon for journals to process in excess of 300,000 entries per minute.

Recommendation: IBM i allows you to define whether you want journal receivers to be automatically deleted once the system no longer requires them for IPL recovery on a journal-by-journal basis. Use the DLTRCV parameter on the CHGJRN or CRTJRN command.

Runaway or Looping Jobs

IBM i has an unrivalled number of switches and controls that allow you to manage the way the system handles various workloads. There is, however, still room for improvement, especially for runaway or looping jobs. These jobs utilize excessive systems resources and negatively impact the end user experience and overall system throughput.

Recommendation: Consider IBM Performance Tools for i to collect historical performance data and analyze it or run an advisor tool over it. Use the GO PERFORM command to get started.

Learn more about job monitoring here >

Elevated Profiles

There are four user profiles that are shipped with access to all IBM i system objects (Special Authority *ALLOBJ): QLPAUTO, QLPINSTALL, QSECOFR, and QSYS. Take a look at your system. Do you still have only four user profiles with *ALLOBJ authority?

Experience tells us that it’s easier to copy and adjust a profile than create it new from scratch, which is why many system administrators take existing user profiles and base new ones on them when on-boarding new staff. As a result, many organizations end up with tens or even hundreds of powerful profiles.

Some of the user profiles with *ALLOBJ authority may be Group Profiles that can pass along elevated privileges via the GRPPRF parameter set on their profile.

Recommendation: Giving a user *ALLOBJ authority essentially provides that user with access to all objects and functions provided by the system and should be done with extreme caution. There are some very useful system utilities on the IBM i Security Tools menu. Use GO SECTOOLS to get started.

Learn more about *ALLOBJ authority here >