Viewing Objects

An object is an encapsulated abstraction of an entity, with encapsulated here implying that there is a specified interface for interacting with or using the object. For example, a ‘person’ object would accept input via the five senses, and a ‘shovel’ object would best be utilized through its handle, which is its primary interface. In the IBM i context, an object is named unit on which commands may be executed. Almost everything on the IBM i is an object.

Intrinsic to objects are the various object types. On the IBM i, different objects have different types. All objects are categorized by type. A library, type *LIB, is an object used to group related objects. Programs, type *PGM, are objects used for executed modules. Commands are objects as well; they have a type of *CMD and are stored in the system library.

When we create an object we can give it a name, but the object type is determined by the command used to create it. Most CL commands can only be used for objects of a specific type, although there are a few that can work with any type of object.

The Work with Objects command, WRKOBJ, shows us a list of objects from one or more libraries. The Work with Objects command has one required parameter, OBJ. We can specify *ALL for the OBJ parameter to view all objects in the libraries in our library list. To view all the objects in our current library, we issue the command WRKOBJ OBJ(*CURLIB/*ALL).  To view all the objects in library QSYS2, we issue the command WRKOBJ OBJ(QSYS2/*ALL). To view all of the objects in user libraries, meaning almost all of the libraries that do not start with ‘Q’, we enter the command WRKOBJ OBJ(*ALLUSR/*ALL). Finally, to view all of the objects on the system, we run the command WRKOBJ OBJ(*ALL/*ALL).

All objects have descriptions and we can view the description of an object from with the Work with Objects list screen by entering an 8 next to the object we wish to view and pressing Enter.

We can use the OBJTYPE parameter to indicate the object type we wish to view. For example, to display all of the programs stored in library QSYS, we would issue the command WKROBJ OBJ(QSYS/*ALL) OBJTYPE(*PGM).

The Display Object Description command, DSPOBJD, can be used to view the names and attributes of specific objects within libraries as well as the names and attributes of the libraries themselves. The main advantage of the Display Object Description command, DSPJOBD, over the Work with Objects command, WRKOBJ, is that the output from DSPJOBD can be sent to a file to view later, and the command can be executed in a batch program.

We can enter in the command DSPOBJD and then press F4 to prompt the command. The DSPOBJD command has two required parameters, OBJ and OBJTYPE. For example, to display the object description for the QBASE subsystem job queue, enter DSPOBJD OBJ(QGPL/QBASE) OBJTYPE(*JOBQ). This will take us to to the Display Object Description – Basic screen, which provides us with a list of objects matching the parameters. In this instance, there is one single object, since we provided a qualified name for the object and indicated the object type.

However, the DSPOBJD command can also be used to generate a list of multiple objects. For example, if we wanted to view all objects named QSYSOPR in library QSYS, we would issue the command DSPOBJD OBJ(QSYS/QSYSOPR) OBJTYPE(*ALL). Entering this command should list two different objects, the user profile for QSYSOPR and the message queue associated with that user profile.

The DETAIL parameter can be used to specify the level of information we wish to view. The three options for the DETAIL parameter are *BASIC, *FULL, and *SERVICE. A full attribute display shows all the attributes associated with an object, while the service attribute display shows information regarding saves, restores, and system information. To get the full attribute display for the QSYSOPR message queue, we enter the command DSPOBJD OBJ(QSYS/QSYSOPR) OBJTYPE(*MSGQ) DETAIL(*FULL).

Wanting to get the most out of your IBM i investment? Take a look at, the friendly IBM backup solution.

Viewing Objects

Displaying User Profiles

To the IBM i, a user profile is an object. The name of the user profile is the name the user needs to enter in order to sign on to the system. The attributes of a user profile object define the user to the system. User profiles have the object type *USRPRF. All user profiles reside in the system library QSYS, so as to ensure there are no duplicate user profiles in the system.

To quickly list the names of all the authorized system users, issue the Display Authorized Users command, DSPAUTUSR. Note that while this command primarily lists the user profile’s object name, a user profile is much more than just a name and an associated password.

A user profile contains a whole series of system information within it – the password, the initial menu to be displayed, the initial program to be called, special authorities, etc. The system security draws upon the user profile to verify the user’s authorization to sign on, run programs, read or update files, and perform certain tasks. To view this information, we can issue the Display User Profile command, DSPUSRPRF. We name the user profile we wish to view with the USRPRF parameter.

The QSYSOPR user profile comes with the system. We can sign on as QSYSOPR whenever we need to perform important system operator tasks, such as backing up and restoring libraries, or powering down the system. We can view the details of the QSYSOPR user profile by issuing the command DSPUSRPRF USRPRF(QSYSOPR).  Entering this command takes us to the Display User Profile – Basic screen, which lists a multitude of information.

The User Profile attribute shows us the name assigned to the user profile; in other words, the user ID.

The User Class attribute indicates the type of user associated with this user profile. There are five classes of user on the IBM i. The possible values for this attribute include Security Officer, *SECOFR, Security Administrator, *SECADM, Programmer, *PGMR, System Operator, *SYSOPR, and User, *USR. The *SECOFR class is given all object authority, security administrator authority, save system authority, job control authority, service authority, and spool control authority. The *SECADM class is given security administrator authority, save system authority, and job control authority.  The *PGMR and *SYSOPR classes are given save system authority and job control authority. The *USER class is given no special authorities. The QSYSOPR user profile’s class type is *SYSOPR. If we run the command DSPUSRPRF USRPRF(QSECOFR), we can see that the QSECOFR user profile’s class type is *SECOFR.

The Special Authority attribute lists the special authorities granted to a user. Special authorities are necessary for performing certain functions on the system. The Save System special authority, *SAVSYS, grants the ability to save, restore, and free storage for all objects on the system. The Job Control special authority, *JOBCTL, gives the power to change, display, hold, release, cancel, and clear all jobs that are running on the system or that are on a job or output queue. The Security Administrator special authority, *SECADM, grants the authority to create or change user profiles. The Service special authority, *SERVICE, allows the user to perform system service functions, such as save and restore. The All Object special authority, *ALLOBJ, grants the user the authority to access any system resource.The QSYSOPR user profile has both *SAVSYS and *JOBCTL special authorities. Note that the special authorities for the QSECOFR user profile cannot be removed.

Note that if we press Enter after running DSPUSRPRF USRPRF(QSYSOPR), we return to previous screen. By default, the DSPUSRPRF command displays the basic information contained in a user profile. To view all of the information for a user profile, we would use the TYPE parameter, and specify *ALL. For example, issuing the command DSPUSRPRF USRPRF(QSYSOPR) TYPE(*ALL) brings us to the Display User Profile – Basic screen, however if we press Enter, instead of being taken back to the previous screen, the Display Authorized Commands screen is presented. If we press Enter again, the Display Authorized Devices screen is shown, followed by the Display Authorized Objects screen, the Display Owned Objects screen, and then finally the Display Primary Group Objects screen.

To view the Display Authorized Commands screen directly, we can issue the DSPUSRPRF command with the parameter TYPE(*CMDAUT). The Display Authorized Commands screen shows us the commands that the user profile is allowed to execute.

To view the Display Owned Objects screen directly, we issue the command DSPUSRPRF with the parameter TYPE(*OBJOWN). The Display Owned Objects screen lists all the objects owned by a user profile; on most IBM i systems, the majority of objects are owned by a handful of user profiles. As an example, let’s display all of the objects owned by the QSYSOPR user profile by issuing the command DSPUSRPRF USRPRF(QSYSOPR) TYPE(*OBJOWN).

The QSYSOPR user profile is one of several IBM-supplied user profiles, known as default profiles, each of which starts with the letter Q. To quickly view all of the IBM-supplied user profiles on the system, we issue the command WRKUSRPRF USRPRF(Q*). The seven most famous of these profiles are QSECOFR, QPGMR, QSYSOPR, QUSR,  QSRV, and QSRVBAS. Note that the QSRV and QSRVBAS profiles are special profiles for IBM technicians to use when servicing the IBM i.

IBM-supplied user profiles can be overused. For example, the QSECOFR user profile is often unnecessarily set as the owner of an application, thus bloating the QSECOFR user profile and, more seriously, leading to potential security concerns. To see how many objects the QSECOFR user profile is the owner of, enter the command DSPUSRPRF USRPRF(QSECOFR) TYPE(*OBJOWN).

Wanting to get the most out of your IBM i investment? Take a look at, the friendly IBM backup solution.

Displaying User Profiles

Displaying Messages

There are two basic commands for viewing messages, Display Message, DSPMSG, and Work with Messages, WRKMSG. The two commands are virtually identical.

Type the Display Message command, DSPMSG, on the command line and press Enter to display messages. By default, the DSPMSG command displays the messages for your user profile’s message queue and the work station’s message queue. To view just the messages for our user profile, we can run the command DSPMSG MSGQ(*USRPRF). To view the messages for just the display station, we can enter the command DSPMSG MSGQ(*WRKSTN).

Messages typically have two levels of detail. Level one, the simplest, is what is listed when we enter the DSPMSG or WRKMSG commands. To get to level two, which provides a greater level of detail, set the cursor on the message text and press F1. The second level message will then be displayed. From the second level message, pressing F9 will give us even greater detail.

The command panel for the DSPMSG command has three function keys that will remove messages from the queue. We should be careful when using these function keys. If we move the cursor to a message and press F11, the system will then remove the message from the queue. F13 will remove all messages, including inquiry messages that have not been answered yet. F16 removes all messages, excluding inquiry messages that have yet to be answered.

The QSYSOPR system operator has its own message queue that is also named QSYSOPR. Error and informational messages about jobs that are running and require some sort of special intervention are sent to the QSYSOPR message queue. The QBATCH subsystem usually sends all system operator messages to the QSYSOPR message queue.

The QSYSOPR message queue is especially helpful in troubleshooting problems and confirming that system events actually occurred. We can display the messages in the QSYSOPR message queue using the Display Message command, DSPMSG. We supply QSYSOPR as the name of the message queue, so that the full command is DSPMSG MSGQ(QSYSOPR).

By default, the most recent messages are displayed first. If we want to start with the oldest messages, we can use the START parameter and specify *FIRST; this will display the messages in order from first received to last received. The default for the START parameter is *LAST, where the messages are displayed in order from last received to first received; this ordering ensures that we see the latest messages first. For example, issuing the command DSPMSG MSGQ(QSYSOPR) START(*FIRST) should list messages relating to the system IPL.

Messages are collected into logs, such as the job log. Each user in an interactive session has a job log that aggregates the messages and the commands that they run. We can quickly access the job log by issuing the DSPJOBLOG command. To view complete information for the messages in the job log, position the cursor over the desired message and press F1.

The IBM i also has a system-wide log called QHST.The QHST log provides us with a record of system activity. We can view the system log by executing the Display Log command, DSPLOG. The system log is a message queue object, *MSGQ. Note that the QHST system log has a fixed size. When the QHST system log is full, the system copies QHST in a database file and then clears it of all contents.

The QHSTLOGSIZ system value indicates the maximum number of records that can be kept in the history log. We can view this value by issuing the command DSPSYSVAL SYSVAL(QHSTLOGSIZ). We can specify a number or else *DAILY when modifying this value; the default is 5000. Please be aware that changes to this system value take effect only after a new history log is created.

Wanting to get the most out of your IBM i investment? Take a look at, the friendly IBM backup solution.

Displaying Messages

Working with Subsystems

The Work with Subsystems command, WRKSBS, brings up with Work with Subsystems list screen. By entering 4 next to the subsystem name  in the option column and pressing Enter, we can end that subsystem. Entering 5 instead and pressing Enter display’s the subsystem’s description, and entering 8 lets us work with that subsystem’s jobs.

It isn’t difficult to create new subsystems for batch, interactive, or server purposes. A subsystem definition consists of three major components, the subsystem attributes, the work entries, and the routing entries.

The subsystem description, *SBSD, is an object used to describe a subsystem and to control what tasks the subsystem can perform. Each time a subsystem is created, a subsystem description is required.

Subsystem attributes comprise the general definition of the subsystem and control its main storage allocations. This general definition includes the subsystem name, library, text description, the maximum number of jobs allowed to run on the subsystem, and the storage pool definitions. Main storage on the IBM i is divided into a number of different storage pools. The storage pool definition has a subsystem either share an existing pool of main storage, establish a private pool of main storage, or both. A private pool is created and named by the subsystem description, and it can only support one subsystem.

The Create Subsystem Description command, CRTSBSD, enables us to create a new subsystem description. Entering CRTSBSD and pressing Enter brings up the Create Subsystem Description screen. The first parameter is used to specify the qualified name of the subsystem description, which is the name of the library and the name of the subsystem itself. This parameter, SBSD, takes *CURLIB by default as the library. The second parameter, POOLS, is used to specify the storage pools used by the subsystem. The activity level for a pool indicates how many jobs on the subsystem can be run in that pool at a given time.  A maximum number of 10 storage pools can be assigned to the subsystem. The first pool is used to support the subsystem driver; for performance reasons, this pool should usually be *BASE.

The SBSD and POOLS parameters are the only required parameters when creating a new subsystem description. Thus, we can create a simple subsystem by issuing the command CRTSBSD SBSD(TESTSUB) POOLS((1 *BASE)), which creates a subsystem description in our current library named TESTSUB that uses the shared *BASE storage pool. We can then issue the command DSPSBSD SBSD(TESTSUB) to view the attributes of the TESTSUB subsystem description. At the top of the screen we will seen the name, library, and status of this subsystem description; as we can easily see, the subsystem’s status is INACTIVE.

The Maximum Jobs parameter, MAXJOBS, specifies the maximum number of jobs that can be run on the subsystem at any one time. We can put *NOMAX here to indicate that there is no limit to the number of jobs that can be run at once on the subsystem. In practice, it is often good to set a number here, to prevent the subsystem from potentially being flooded. Note the difference between Maximum Jobs and the Activity Level, the Maximum Jobs parameter specifies how many jobs are in the system, whereas Activity Level specifies how many of those jobs are actually working at one time.

Finally, the Text parameter, TEXT, enables us to give a text description for the subsystem. Both the MAXJOBS and TEXT parameters are optional; by default, MAXJOBS is set to *NOMAX and TEXT is set to *BLANK.

Let’s create a second subsystem named TESTSUB2. We will give this subsystem two storage pools, and set the maximum number of jobs to 15. Issuing the command CRTSBSD SBSD(TESTSUB2) POOLS((1 *BASE) (2 65536 8)) MAXJOBS(15) creates our second subsystem, with a secondary storage pool of 64K that can run eight jobs at once. Entering the command DSPSBSD SBSD(TESTSUB2) displays the subsystem description, which, like TESTSUB1, is inactive. Selecting option 2 will display the storage pools, of which there are two, just as we defined.

Subsystems do not become active until they are started. A subsystem definition is, in the end, only a definition of what resources should be allocated; to allocate the resources, we must activate the subsystem. We can activate a subsystem using the Start Subsystem command, STRSBS. The only parameter that must be specified is the subsystem to start, SBSD. If the subsystem is in a library that is in our library list, we can can omit the library name, otherwise we should include the library name before the name of the subsystem.

Let’s start our TESTSUB subsystem by issuing the command STRSBS SBSD(TESTSUB). Entering the command DSPSBSD SBSD(TESTSUB) will then show us that the subsystem is active. Let’s also start the second subsystem we have defined, TESTSUB2, by entering the command STRSBS SBSD(TESTSUB2). Note that as both TESTSUB and TESTSUB2 were created in our current library, *CURLIB, which is part of our library list, we do not have to insert the library name.

Use the End Subsystem command, ENDSBS, to shut down a subsystem. Typing in ENDSBS at the command line, we can press F4 to prompt for parameters. The system will prompt us for the name of the subsystem we want to end, and whether we want a controlled end, signified by *CNTRLD, or an immediate end, signified by *IMMED.

A controlled end, *CNTRLD, allows all active jobs to continue for a set period defined in seconds in the DELAY parameter. We can change the value of the Delay Time parameter, DELAY, to a given number of seconds, or, alternately, we can specify no maximum with *NOLIMIT, which lets active jobs continue indefinitely.

An immediate end to a subsystem, *IMMED, forces the system to take drastic measures to end jobs. If the jobs were updating files, especially keyed files, the IBM i operating system may have to repair the files the next time we IPL, which could incur a significant time penalty.

Let’s end the TESTSUB subsystem via the command ENDSBS SBS(TESTSUB) OPTION(*IMMED); this command will immediately shut down the TESTSUB subsystem. We can use the *IMMED option, as we know that there are no jobs being run in the TESTSUB subsystem. We’ll end the TESTSUB2 subsystem using a controlled end and a time delay of 180 seconds by issuing the command ENDSBS SBS(TESTSUB2) OPTION(*CNTRLD) DELAY(180).

We can also use the End Subsystem Option parameter, ENDSBSOPT, to improve the performance of ending subsystems. If we specify ENDSBSOPT(*NOJOBLOG), the subsystem will end without producing a job log for every job that was running in the subsystem, which can potentially save system resources. If we specify ENDSBSOPT(*CHGPTY *CHGTSL), the run priority and time slice for all jobs in the subsystem that end will be modified so as to consume less system resources than jobs that are still running in other subsystems.

All parameters specified on the Create Subsystem Description screen may be modified with the Change Subsystem Description command, CHGSBSD. Let’s start by issuing the command CGHSBSD SBSD(*CURLIB/TESTSUB) MAXJOBS(10); this command will alter the TESTSUB subsystem to have a maximum number of 10 jobs. We can then enter DSPSBSD SBDSD(TESTSUB) and then select option 1 to verify that the maximum number of jobs has been altered. Next, let’s modify the TESTSUB2 subsystem so that it has a third storage pool with approximately 32K of storage and an activity level of 5. To do this, we issue the command CHGSBSD SBSD(TESTSUB2) POOLS( (3 32000 5)).

We can then start up both subsystems by issuing the commands STRSBS SBSD(TESTSUB) and STRSBS SBSD(TESTSUB2). Next, let’s end the TESTSUB subsystem immediately and without writing job logs by entering the command ENDSBS SBS(TESTSUB) OPTION(*IMMED) ENDSBSOPT(*NOJOBLOG). Then, let’s end the TESTSUB2 subsystem with a six minute delay, no job log, and with jobs that will compete less aggressively for processor cycles than jobs running in other subsystems. To do this, enter the command ENDSBS SBS(TESTSUB2) OPTION(*CNTRLD) DELAY(360) ENDSBSOPT(*NOJOBLOG *CHGPTY *CHGTSL).

Finally, we need to be able to remove subsystem descriptions that we no longer need. To delete a subsystem description, we use the Delete Subsystem Description command, DLTSBSD. To delete TESTSUB and TESTSUB2, we issue the commands DLTSBSD SBSD(TESTSUB) and DLTSBSD SBSD(TESTSUB2). Please be aware that the associated subsystem must be inactive before it is deleted.

Wanting to get the most out of your IBM i investment? Take a look, the friendly IBM backup solution.

Working with Subsystems

The Controlling Subsystem

There are two subsystem controlling configurations supplied by IBM, QBASE and QCTL. The subsystem configuration the IBM i employs when the system is started is determined by the Controlling Subsystem system value, QCTLSBSD. To discover which subsystem we are using on startup, issue the command DSPSYSVAL SYSVAL(QCTLSBSD).

By default, most work is carried out by QBASE, as the IBM i is initially set up with QBASE as the controlling subsystem. The IBM i is also  shipped with an alternative controlling subsystem, QCTL. To view the subsystem description for QCTL, we enter the command DSPSBSD SBSD(QCTL), and then select option 30 from the subsequent menu to view all of the attributes, definitions, and entries for the subsystem. Note that the only storage pool defined for QCTL is *BASE; likewise, QCTL has only one job queue, which is named QCTL.

The QCTL subsystem starts four main system-supplied subsystems, QINTER, QBATCH, QCMN, and QSPL. The QINTER subsystem is for interactive jobs, QBATCH is for batch jobs, QCMN is for communication jobs, and QSPL is for spooling jobs.

We can change the controlling subsystem to QCTL by entering the command CHGSYSVAL SYSVAL(QCTLSBSD) VALUE(‘QCTL QSYS’). The change, however, will not take effect until after the next IPL. Just changing the system value will not automatically make the controlling subsystem switch from QBASE to QCTL. To complete the change, we must power down and restart the system. We can restart the system via the PWRDWNSYS RESTART(*YES) command.

QBASE and QCTL both start three basic subsystems for running server jobs, QSYSWRK, QUSRWRK, and QSERVER. The QSYSWRK subsystem is for server work not done on behalf of a specific user, the USRWRK subsystem is for user work, and the QSERVER subsystem is for file-serving work only. This set of jobs is started by the QSTRUPJD job; however, when started from QCTL, the additional subsystems QBATCH, QINTER, QCMN, and QSPL are also started.

During the system start, a CL program is usually called that starts all of the needed subsystems. The controlling subsystem, whether it is QBASE or QCTL, submits a job that runs the startup program.

The system value QSTRUPPGM contains the qualified name of the startup program. We can display the name of the startup program using the Display System Value command, DSPSYSVAL, by entering DSPSYSVAL SYSVAL(QSTRUPPGM).

If we change this system value, the IBM i will execute a different program during IPL. We can change this system value to reference any program name or else *NONE. The IBM i system ships with a program called QSTRUP located in the QSYS library that can be used either as is, or it can be tailored to fit our specific needs.

As an example, let’s change the system so that the controlling subsystem no longer calls a startup program. To do this, we issue the command CHGSYSVAL SYSVAL(QSTRUPPGM) VALUE(*NONE). We can then use the DSPSYSVAL command to verify that the change has been made. Next, let’s change the startup program to the default QSTRUP program with the command CHGSYSVAL SYSVAL(QSTRUPPGM) VALUE(‘QSTRUP QSYS’).

We can also make changes to the QSTRUPPGM system value using the Work with System Values command, WRKSYSVAL. Issuing the command WRKSYSVAL SYSVAL(QSTRUPPGM) brings up a list of system values that only contains the QSTRUPPGM system value. We can then select option 2 to change the system value or option 5 to simply display it.

Wanting to get the most out of your IBM i investment? Take a look at, the fast and frugal IBM backup solution.

The Controlling Subsystem

IPL-related System Values

Starting an IBM i is referred to as an initial program load, abbreviated IPL. There are three types of IPL that can be performed. The first type is an unattended IPL, which does not require an operator or any other user to be present. An unattended IPL uses the default IPL and system options to start the system. We can view the default IPL options using the Display IPL attributes command, DSPIPLA. The second type of IPL is the attended IPL, which requires an operator to be present. During an attended IPL, certain system options can be modified during the IPL process.The third type is an automatic IPL, which is similar to an unattended IPL, but occurs as a result of special circumstances, such as a power failure, or a remote IPL.

There are a number of system values that determine the IPL process.

The QIPLSTS system value describes the manner in which the system performed the last IPL. This value cannot be changed; it can only be displayed. To view this value, enter the command DSPSYSVAL SYSVAL(QIPLSTS).

The QIPLTYPE system value defines the type of IPL the system will perform when the partition is powered on manually during a normal IPL. If QIPLTYPE is set to 0, the system will perform an unattended IPL. If QIPLTYPE is set to 1, the system will perform an attended IPL with dedicated service tools. This option is useful when performing an upgrade or maybe when attempting to diagnose a problem. The third option is 2, which is an attended IPL in debug mode. This mode leaves the controller QCTL and device QCONSOLE varied on after an IPL. QIPLTYPE should really be set to 2 only at the direction of an IBM support technician. The default value for QIPLTYPE is 0.

The QABNORMSW system value indicates how the system last ended. This system value can be either a 0, indicating the system ended normally, or 1, indicating that the system ended abnormally. To view how the previous ending was handled, enter the command DSPSYSVAL SYSVAL(QABNORMSW).

The QRMTIPL system value determines whether or not a remote system can start the IBM i. Enter DSPSYSVAL SYSVAL(QRMTIPL) to display the value set for this system value. A value of 0 indicates that a remote system cannot start the IBM i, and a value of 1 indicates that a remote system can start the IBM i. Note that even if QRMTIPL is set to 1, a remote system can only restart the IBM i if it is powered down.

The QPWRRSTIPL system value determines if the system will automatically restart itself after a power failure. If QPWRRSTIPL is set to 1, then the system will restart itself; if it is set to 0, then the system will not restart itself.

The QPWRDWNLMT system value controls how long the system waits for jobs to finish when executing the PWRDWNSYS OPTION(*IMMED) command. We can check this value by issuing the command DSPSYSVAL SYSVAL(QPWTDWNLMT). The default for this system value is 600 seconds, which is 10 minutes. Note that if jobs are still executing when this time interval expires, the system will perform an abnormal system termination, and set QABNORMSW to 1.

The QUPSDLYTIM system value controls the length of time the system will wait before saving main storage and powering down the system in the event of a power failure. The default value is *CALC, which means that the wait time is calculated based on the system configuration. Note that leaving QUPSDLYTIM set to *CALC may defeat the whole purpose of having a UPS, as the system will essentially begin a controlled shutdown after a short fixed interval delay, typically 200 seconds.

The QIPLDATTIM system value determines the date and time when the system will IPL itself automatically. To display when, if ever, the system is scheduled for an automatic IPL, enter the command DSPSYSVAL SYSVAL(QIPLDATTIM). The default value for QIPLDATTIM is *NONE. The QIPLDATTIM system value will have the system perform an IPL if it is in a shutdown state. We can IPL the system automatically at a specified date and time by setting the system value QIPLDATTIM to a specific date and time.

Generally speaking, it’s better to use the submenus found under Power On and Off Tasks menu to define the QIPLDATTIM system value. To access the Power On and Off Tasks menu, issue the GO POWER command.

The controlling subsystem stays active even when all other subsystems are shut down for backups. The only time the controlling subsystem is shut down is when a PWRDWNSYS command has been successfully completed. QCTLSBSD contains the qualified name of the controlling subsystem description.

The initial value for QCTLSBSD is QBASE, which is more than adequate for smaller, less complex systems. With this setup, practically all work, including interactive and batch jobs, is performed by the QBASE subsystem.

Wanting to get the most out of your IBM i investment? Take a look at, the friendly IBM backup solution.

IPL-related System Values

Creating, Changing, and Deleting Libraries

Creating a library is easy. To create a library, we use the Create Library command, CRTLIB. Alternately, we can enter the GO LIBRARY command to go to the Libraries menu, and enter 2 to create a library.

There are three main parameters for the CRTLIB command, LIB, TYPE, and TEXT. The LIB parameter accepts the name we want to give the library. We should note here that whatever name we decide on ought not to begin with the letter Q.  The TYPE parameter can accept one of two types. The *TEST type indicates that the library will only contain test objects. A *TEST library does not protect its database files during debugging sessions. Production libraries, *PROD, can be protected from updates during debugging sessions. The IBM i system assumes TYPE(*PROD) by default. The TEXT parameter is used to give the library a text description, which we should enclose in single quotation marks. The description should be no more than 50 characters.

As an example, we could create a library called EXMPL by entering the command CRTLIB LIB(EXMPL) TEXT(‘an example library’). If the command is executed successfully, we will see the message “Library EXMPL Created” at the bottom of our screen. We can then verify that the library has been created by issuing the command DSPLIB LIB(EXMPL). We will then see that the library is of type *PROD, since that is the default type, and has 0 objects in it. We can also see a field labeled Create Authority. The Create Authority attribute, CRTAUT, specifies the default public authority that all objects in the library will have. The *SYSVAL parameter indicates that the QCRTAUT system value should be used to define the default public authority for new objects in the library.

To display the QCRTAUT system value, issue the command DSPSYSVAL SYSVAL(QCRTAUT). The QCRTAUT system value can have one of four possible values; *ALL, which means that the public can do anything with new objects in the library; *CHANGE, meaning that the public can modify new objects; *USE, which means the public may use, but not change, new objects; and *EXCLUDE, which means the public is not allowed to use new objects. The *CHANGE value is the default for the system value QCRTAUT when the IBM i is first set up.

We can use the four defined system authorities, *ALL, *CHANGE, *USE, and *EXCLUDE, as parameters for the CRTAUT parameter. If no specific authority is indicated, then the default of *SYSVAL is used.

Let’s create a second library named EXMPL2 that grants users all authority over newly created objects in the library. To do this, we issue the command CRTLIB LIB(EXMPL2) CRTAUT(*ALL) TEXT(‘A second example library’). We can then view this library by entering the command DSPLIB LIB(EXMPL2). We can list the two libraries we have just created by issuing the command WRKLIB LIB(EXMPL*).

We can use the WRKLIB command to modify libraries that have already been created. Entering the command WRKLIB LIB(EXMPL) and then entering the number 2 in front of the library listing  will enable us to modify the attributes of the EXMPL library. We can, for example, change the EXMPL library to a test library by entering *TEST in the field for the Library type attribute. After we press Enter, we can hit the F5 key to update the changes in the display.

We can modify a library directly using the Change Library command, CHGLIB. The CHGLIB command can be used to modify the library’s type attribute, its text description, its default authority value, and finally its default object auditing value.  The CHGLIB has one required parameter, the LIB parameter that specifies the library to be changed. We can then use the TYPE, TEXT, and CRTAUT parameters to modify the corresponding library attributes. For example, let’s change the TEXT value of EXMPL2 by entering the command CHGLIB LIB(EXMPL2) TEXT(‘here is some new text’). We can then use the Display Library Description command, DSPLIBD, to verify that the change has been made by issuing the command DSPLIBD LIB(EXMPL2).

We can delete a library with the Delete Library command, DLTLIB. The DLTLIB command requires one parameter, the name of the library to delete. Deleting a library not only deletes the library itself, it was also deletes all the objects within the library. Let’s delete the two libraries we have just created by entering the commands DLTLIB LIB(EXMPL) and DLTLIB LIB(EXMPL2).

All things being equal, we shouldn’t delete an IBM-supplied library with the Delete Library command, DLTLIB. Instead, if necessary, we can uninstall the library via the Licensed Programs menu, which we can reach by entering the command GO LICPGM.

Wanting to get the most out of your IBM i investment? Take a look, the friendly IBM backup solution.

Creating, Changing, and Deleting Libraries