Working with Message Queues

A message queue is an object on the system; its object type is *MSGQ. A message queue is like a mail box, it stores incoming messages until they can be handled. When a user profile is created, the system automatically creates a message queue by the same name in the library QUSRSYS. To list all of the message queues in QUSRSYS, we can use the Display Object Description command, DSPOBJD. Issuing the command DSPOBJD OBJ(QUSRSYS/*ALL) OBJTYPE(*MSGQ) will display the message queue names, their sizes, and an optional short text description of the queue.

Messages are sent to a user message queue or a workstation message queue. Generally speaking, during an interactive session each workstation has a message queue with the same name as the workstation ID, and each user has a message queue with the same name as the user ID.

We can view messages by issuing the Display Message command,  DSPMSG, with the MSGQ parameter; this parameter defaults to the value *WRKUSR. The *WRKUSR value indicates that messages from the work station’s message queue and the current user’s user profile message queue are shown. If we only want to see messages associated with our current user profile, we issue the command DSPMSG MSGQ(*USRPRF).

The Display Messages screen shows messages in descending order based on the time they were delivered to the message queue. Each message contains the date and time that the message was sent. To view more information about a message, place the cursor over the message and press the F1 key. To erase a message, position the cursor at the appropriate message and press the F11 key.

The QSYSOPR message queue is a very busy message queue, as QSYSOPR receives many messages from all kinds of jobs running on the system.  To view the messages in the QSYSOPR message queue, enter the command DSPMSG MSGQ(QSYSOPR). To view the details of a message, put the cursor over the message and press F1.

Few diagnostic messages are sent to a regular user’s message queue, with the exception of batch jobs. The ending status for batch jobs is sent, by default, to the user who submitted the job.

Certain messages, called inquiry messages, require a reply. These messages are identified in the Display Messages screen by the underlined input field directly beneath the message. To list all of the inquiry messages associated with our profile and session, we enter the command DSPMSG MSGTYPE(*INQ). If we delete an inquiry message that has not been responded to, the system will assume the default reply.   

To work with multiple message queues, we can use the Work with Message Queues command, WRKMSGQ. To list all the message queues on the system, we use the command WRKMSGQ MSGQ(*ALL). To work with all the message queues in the QUSRSYS library, we enter the command WRKMSGQ MSGQ(QUSRSYS/*ALL). From the Work with Message Queue screen, we can select option 2 to change a message queue; this option calls the Change Message Queue command, CHGMSGQ. Option 4 will remove a message queue from the system; this option calls the Delete Message Queue command, DLTMSGQ. Option 14 will clear the messages in the message queue; this option calls the Clear Message Queue command, CLRMSGQ.

The system automatically creates message queues for user profiles, but we can also create our own. Generally speaking, it is a good idea when creating user profiles to leave the default value for the message queue name so that the message queue is named after the user profile itself.

We can create a message queue with the Create Message Queue command, CRTMSGQ. Once created, messages can be sent to and retrieved from the message queue. The CRTMSGQ command has one required parameter, MSGQ, for which we specify the name of the message queue, and optionally the library we wish to place the MSGQ in. For instance, to create the message queue MORTY in library QUSRSYS, we can issue the command CRTMSGQ MSGQ(QUSRSYS/MORTY). If we do not specify a library, then the system defaults to *CURLIB.

One message queue that is worth creating is the optional QSYSMSG queue. The QSYSMSG can be used to monitor specific system messages that indicate potential system problems. Important system messages are sent to the QSYSOPR message queue where they can get lost among many other messages of a noncritical nature. If the QSYSMSG has been created, messages that require immediate attention will be directed to it instead of, or in addition to, the QSYSOPR message queue.

To create the QSYSMSG message queue, we enter the command CRTMSGQ MSGQ(QSYS/QSYSMSG) TEXT(‘Option MSGQ for important system messages’). Once the QSYSMSG queue has been created, certain specific system messages will be directed there.

The inactive job message queue system value, QINACTMSGQ, specifies the action the system takes when an interactive job has been inactive for a specified length of time. We can issue the command DSPSYSVAL SYSVAL(QINACTMSGQ) to view the value set for this system value. The QINACTMSGQ can have one of three values set, *ENDJOB, which ends the interactive job, *DSCJOB, which disconnects the interactive job, or the name of a message queue to receive Message CPI1126; if the specified message queue does not exist or is damaged, the message is instead sent to the QSYSOPR message queue.

We can change the characteristics of a message queue using the Change Message Queue command, CHGMSGQ. The two main parameters for the CHGMSGQ command are MSGQ, to specify the message queue to alter, and DLVRY parameter, which determines how the reception of messages should be announced to the user.

The DLVRY parameter accepts one of four values, *BREAK, *NOTIFY, *HOLD, and *DFT. The *BREAK value specifies that when a message is received, the screen will clear and the message will break into the display.  This is used at a message queue level primarily for system operations, and can be overridden if a program was specified to handle the message condition. The *HOLD value acts as a silencer; the message will be placed on the message queue, which retains the message until the user requests to view the message using the Display Messages command, DSPMSG, or the Work with Messages command, WRKMSG.

A third important parameter for the Change Message Queue command, CHGMSGQ, is the Severity parameter, SEV. The SEV parameter determines whether a message has a level equal to or greater than the severity value that has been established. The Severity level is set via a numeric value from 00 to 99.

As an example, to have all messages be delivered as break messages to the current user, we use the command CHGMSGQ MSGQ(*USRPRF) DLVRY(*BREAK) SEV(00).

Individual messages can be deleted when viewed by placing the cursor over them and pressing the F11 key. To remove all the messages from a message queue, use the Clear Message Queue command, CLRMSGQ. The CLRMSGQ command has one required parameter, MSGQ, and an optional parameter, CLEAR. The CLEAR parameter refers to which messages should be cleared; the default for this parameter is a value of *ALL, which will remove all messages from the queue. For example, to remove all messages from the workstation’s message queue, we can enter the command CLRMSGQ MSGQ(*WRKSTN). To delete all but the unread messages from the MORTY message queue, we issue the command CLRMSGQ MSGQ(QUSRSYS/MORTY) CLEAR(*KEEPUNANS). The *KEEPUNANS value will tell the system to keep all messages that have not yet been answered.

When a message queue is no longer required, we can remove it from the system with the Delete Message Queue command, DLTMSGQ. As an example, to delete the message queue MORTY that we created earlier, we enter the command DLTMSGQ MSGQ(QUSRSYS\MORTY).

UBD (Universal Backup Device) is a backup appliance that plugs into your IBM i and appears as a tape device

Working with Message Queues

Viewing Hardware Resources and Device Descriptions

The Hardware Resources menu, HARDWARE, can be accessed from the command line of any menu by entering GO HARDWARE. The Hardware menu itemizes all the resources that can be displayed; so, from this menu we can select  an option corresponding to the resource we would like to work with.

We can view the system’s hardware components by issuing commands via the Hardware Resources Commands menu. To access the Hardware Resources Commands menu, enter GO CMDHDWRSC.

Use the Display Hardware Resources command, DSPHDWRSC, to display the hardware currently installed on the system. The Display Hardware Resources command, DSPHDWRSC, is usually not restricted. With it, hardware resources can only be displayed, their configuration cannot be altered.

To get a list of all system unit components as well as peripheral devices, enter the command DSPHDWRSC TYPE(*AHW). The *AHW parameter stands for All Hardware; using this parameter will display the combined contents of all hardware resource records. After entering this command, we will be presented with a screen labeled Display All Hardware Resources.

Note that although the Display All Hardware Resources screen does not show the physical relationship between the components, the physical location of each component can be viewed by typing 7 next to the item we wish to view and then pressing Enter.

To list all available communication resources, we issue the command DSPHDWRSC TYPE(*CMN). Using the *LWS type instead of *CMN will display the local work station resource information. To list all the storage device resource information, issue the command DSPHDWRSC TYPE(*STG).  To display all of the processor resources, enter the command DSPHWDRSC TYPE(*PRC).

To get an overview of system resources and their usage, we can use the Display System Status command, DSPSYSSTS. The DSPSYSSTS command will display for us the processor usage, as well as storage usage, referred to as the ASP, the auxiliary storage pool.

Every device attached to the IBM i must be described to the system with a device description. Most hardware is considered by the IBM i to be a device. A device description contains the attributes of the device it describes, including the type of device, the name of the controller to attach with, and the device’s unique address. Device descriptions have the object type *DEVD.

The Work with Device Descriptions command, WRKDEVD, enables us to display and work with device descriptions. Entering this command brings up the Work with Device Descriptions screen, which lists all of the device descriptions to which we have access. We optionally can use the DEVD parameter to specify a device description type to list. For example, entering the command WRKDEVD DEVD(*TAP) will list all of the tape devices on the system.  As another example, issuing the command WRKDEVD DEVD(*DSP) will list the device descriptions for all display stations.

We can display an individual device description with the Display Device Description command, DSPDEV. For example, if there is a device description called TAP01, we can enter the command DSPDEVD DEVD(TAP01).

UBD (Universal Backup Device) is a backup appliance that plugs into your IBM i and appears as a tape device

Viewing Hardware Resources and Device Descriptions

Creating User Profiles on the IBM i

Before a user can sign on and use the IBM i, a user profile must be created and assigned to the user.

We create user profiles using the Create User Profile command, CRTUSRPRF. Only the security officer profile, QSECOFR, or another profile that has security administrator special authority, *SECADM, can create, change, or delete user profiles.

The user profile parameter, USRPRF, is the only required parameter and is meant to hold the user profile name decided on for the new user. For example, to create the user profile THX1138, we enter the command CRTUSRPRF USRPRF(THX1138). We can then verify that the user profile has been created by issuing the command DSPUSRPRF USRPRF(THX1138). Doing this, we can see that there are in fact a cornucopia of options for creating and defining a user profile, which in this case were filled out using the defaults for the CRTUSRPRF command.

A password is assigned at the time of creation of the user profile. The Password parameter, PASSWORD, allows us to set a password for a new user. The default value for this parameter is *USRPRF, which dictates that the password be the same as the user profile name. The *NONE special value makes it so that the user cannot in fact sign in to the system; this is recommended for workers who have are on vacation, or have recently left the organization. For example, to create a user profile, LASERVAULT, that cannot be logged in to, we would issue the command CRTUSRPRF USRPRF(LASERVAULT) PASSWORD(*NONE).  

To test this, let’s issue the SIGNOFF command to sign out of our current user profile. At the log in screen, first we attempt to log in as the LASERVAULT user, where we are greeted with the message “No password associated with user LASERVAULT”. Next, we sign in as the user THX1138, remembering here that the username and password are the same. Finally, we sign out again using the SIGNOFF command, then sign back in as with our regular user profile.

The password length is determined by two system values, the Password Maximum Length system value, QPWDMAXLEN, and the Password Minimum Length system value, QPWDMINLEN. To display the minimum length allowed for a password, we execute the command DSPSYSVAL SYSVAL(QPWDMINLEN). A value from 1-10 is allowable, but the longer the password, the better.

The Set Password to Expired parameter, PWDEXP, lets us set the password for a specific user profile to be expired. The two values we can use for this parameter are simply *YES and *NO. When the password is set to expired, the user profile will be prompted to enter a new password when they sign on. When creating a new profile, administrators usually set the PWDEXP field to *YES to indicate that the password should be changed by the user when they sign on. To create a user profile HAL9000 that will have to create a new password after signing on to the system, we issue the command CRTUSRPRF URSPRF(HAL9000) PWDEXP(*YES).

We can then test the effectiveness of the PWDEXP(*YES) parameter by singing off from our user profile via the SIGNOFF command and singing in as HAL9000, remembering here that by default the password is the same as the user profile name. As soon as we sign in we are taken to the Change Password screen. We can also access this screen, and change  our password, by issuing the Change Password command, CHGPWD.

The Profile Status parameter, STATUS, specifies whether a user profile is enabled or disabled for sign-on. The STATUS parameter can be either *ENABLED, in which case the system allows the user to sign on to the system, or *DISABLED, in which case the system will not allow the user to sign on until an authorized user re-enables the profile by changing the value to *ENABLED.

The special authorities parameter, SPCAUT, is used to assign the special authorities to a user. Special authorities are needed to perform certain functions on the system. The all object authority, *ALLOBJ, grants the user the authority for accessing any system resource. The security administrator authority, *SECADM, grants the authority to create or change user profiles. The save system  authority, *SAVSYS, is used to save, restore, and free storage for all objects on the system. The job control authority, *JOBCTL, is used to change, display, hold, release, cancel, clear all jobs that are on the system, and stop active subsystems. The service authority, *SERVICE, allows the user to perform system service functions, such as save and restore. The audit authority, *AUDIT, allows the user to change the system values that control auditing, as well as change the auditing for specific objects and users. Finally, the spool control authority, *SPLCTL, grants the user the ability to manipulate other user’s spooled files.

The two other special values for the SPCAUT parameter are *NONE, where no special authorities are granted, and *USRCLS, where special authorities are given based on the value entered in the user class parameter.

The user class parameter, USRCLS, specifies the type of user to associate with the user profile. The possible values are security officer, *SECOFR, security administrator, *SECADM, programmer, *PGMR, system operator, *SYSOPR, and user, *USR. The user classes represent convenient ways to assign special authorities to different types of users. When we assign user profiles to classes, the profiles inherit the special authorities associated with the class. The security officer, *SECOFR, is granted all object authority, security administrator authority, save system authority, job control authority, and spool control authority. The security administrator, *SECADM, is given security administrator authority. The system operator, *SYSOPR, is given save system authority and job control authority. The programmer and user classes, *PGMR and *USER, are given no special authorities.

As an example, we can create a user, PLYRONE, and assign them to the user class by issuing the command CRTUSRPRF USRPRF(PLYRONE) USRCLS(*USER). We can then use the DSPUSRPRF command to verify that the user PLYRONE has been assigned to the *USER class.

The Initial Menu parameter, INLMNU, indicates the name of the menu that is shown when the user signs on to the system. The default value for the Initial Menu parameter, INLMNU, is MAIN. As an example, let’s say we wanted to define a user profile for doing backups. We could assign such a user to the system operator class, *SYSOPR, and assign them the Backup menu, BACKUP, as their initial menu. To do this, we would issue the command CRTUSRPRF USRPRF(BCKUPMGR) USRCLS(*SYSOPR) INLMNU(BACKUP). Signing in as the user BCKUPMGR takes us directly to the BACKUP menu, which we can exit by pressing F9.

UBD (Universal Backup Device) is a backup appliance that plugs into your IBM i and appears as a tape device

Creating User Profiles on the IBM i

General IBM i Security System Values

The general security-related system values provide a variety of system-level security functions.

The Allow Restoring of Security-Sensitive Objects security system value, QALWOBJRST, determines whether objects that are security-sensitive are allowed to be restored to the system. Use it to prevent anyone from restoring a system state object or an object that adopts authority. To view this value, enter the command DSPSYSVAL SYSVAL(QALWOBJRST). The default value of *ALL will let any object, including security-sensitive objects, to be restored by a user with the appropriate authority. Entering the value of *NONE will prevent restoration of either system state objects or programs that adopt authority. To allow users to restore system state objects, but not programs that adopt authority, we issue the command CHGSYSVAL SYSVAL(QALWOBJRST) VALUE(*ALWSYSSTT). To allow restoration of programs that adopt authority, but not system state objects, we run the command CHGSYSVAL SYSVAL(QALWOBJRST) VALUE(*ALWPGMADP).

The Create Authority system value, QCRTAUT, specifies the default public authority. Any new public object created with the authority set to *SYSVAL, which is the default, will reference the value set in QCRTAUT. The default value for the QCRTAUT system value is *CHANGE. To view the current value, we issue the command DSPSYSVAL SYSVAL(QCRTAUT). Security auditors may ask for the QCRTAUT value to be set to *USE, which allows users to view, but not change, newly created objects. Be aware that existing objects are unaffected by a change to the QCRTAUT value.

Setting the QALWOBJRST security system value to *NONE allows us to have maximum control over the restoration of system state objects and programs that adopt authority. Note, however, that before installing a new licensed product, applying PTFs, or recovering the system, we should change the QALWOBJRST system value to *ALL. Otherwise, those operations may fail. Setting QALWOBJRST to the *ALWPTF value would allow restoring security-sensitive objects as part of a PTF, but reports from the field indicate that this does not always work as intended.

The Remote Sign-on Value, QRMTSIGN, determines how our system handles any automatic passthrough request that it receives. The default value for QRMTSIGN is *FRCSIGNON, which requires the user to go through the normal sign on procedure when accessing the IBM i remotely. To allow the bypass signon feature for IBM’s Client Access software, we should set QRMTSIGN to *VERIFY. If the value is not set to *VERIFY, we will not be able to bypass the sign on display. Note that automatic passthrough requests must contain a valid user profile and the valid password for that profile.

The Limit Device Sessions security system value, QLMTDEVSSN, determines if a user can have more than one workstation occurring at one time. A value of 0 allows a user profile to work at more than one workstation simultaneously. The initial value for QLMTDEVSSN is 0, which allows users to sign on to more than one device. To limit users to only one session, we issue the command CHGSYSVAL SYSVAL(QLMTDEVSSN) VALUE(‘1’).

The Inactive Job Time-out Interval system value, QINACTITV, controls the inactive job time-out interval. The initial value is *NONE. We can set the value to any length of time between 5 and 300 minutes. Note that FTP jobs are not covered under this system value.

The Allow User Domain Objects in These Libraries system value, QALWUSRDMN, specifies which libraries allow user domain objects to be located in them. User domain objects include those of type User Index, *USRIDX, User Queue, *USRQ, and User Space, *USRSPC. The default value for QALWUSRDMN is *ALL; removing *ALL requires the definition of the libraries that we want to allow user domain objects to be created in, such a list must include QTMP. It might also be a good idea to include library QRPLOBJ.

The Automatic Virtual Device Creation system value, QAUTOVRT, controls the number of virtual devices configured for pass-through in a remote communications environment. A virtual device is simply a device description that does not have hardware associated with it. To allow the maximum number of virtual devices to be created, we use the special value *NOMAX and issue the command CHGSYSVAL SYSVAL(QAUTORVT) VALUE(*NOMAX).

UBD (Universal Backup Device) is a backup appliance that plugs into your IBM i and appears as a tape device

General IBM i Security System Values

Sending Messages on the IBM i

An impromptu message is not predefined and is not stored in a message file. An impromptu message can be sent from one user to another; these messages may have no preset reply value. The message can be informational or for inquiry. We can send an impromptu message using the Send Message command, SNDMSG. The SNDMSG command only works with messages whose text is included within the MSG parameter of the command.

To send a message to a user, we use the TOUSR parameter. We can enter a specific user profile name or a special value; the special values that are allowed for this parameter are *SYSOPR, *ALLACT, and *REQUESTER. The *SYSOPR special value indicates the system operator’s message queue. The *ALLACT special value indicates all currently signed-on user profiles’ message queues. The *REQUESTER special value indicates the user profile currently running this interactive job.

To broadcast a message to all active user profiles, we would issue the command SNDMSG MSG(‘All active users will receive this message.’) TOUSR(*ALLACT). To send a message to the system operator, we issue the command SNDMSG MSG(‘This goes to the system operator’s message queue.’) TOUSR(*SYSOPR). Finally, to send a message to ourselves, for example as a reminder of things to do the next day, we can enter the command SNDMSG MSG(‘Bring donuts tomorrow.’) TOUSR(*REQUESTER).

As an alternative to sending the message to a user, we can send the message to a message queue using the TOMSGQ parameter. The disadvantage to using the TOMSGQ parameter is that we must know the name of the message queue assigned to the user; although, by default the message queue and the user name are the same. The advantage to using the TOMSGQ parameter is that we can send the same message to multiple specific users. The TOMSGQ parameter can accept a list of up to 50 values. As an example, we could issue the command SNDMSG MSG(‘The meeting time has been changed to Friday.’) TOUSR(ADALOV CBAB) to send a message to the ADALOV and CBAB users.

Be aware that the TOMSGQ and TOUSR parameters are mutually exclusive.

We can use the SNDMSG command to send an inquiry message. An inquiry message is a type of message we can send when we want the recipient to acknowledge and respond to the message. To send an inquiry message, we use the MSGTYPE parameter with the *INQ special value. The MSGTYPE parameter defaults to *INFO, which means the message is just informational. For example, to send an inquiry message to the security officer, we would issue the command SNDMSG MSG(‘Why is a raven like a writing desk?’) TOUSR(QSECOFR) TYPE(*INQ). Note that the MSGTYPE(*INQ) is invalid if TOUSR(*ALLACT) is specified or if TOMSGQ contains multiple values.

If the MSGTYPE(*INQ) is specified, we can identify a message queue to receive the reply with the RPYMSGQ parameter. The default value of the RPYMSGQ parameter is *WRKSTN. If *WRKSTN is used, the reply is sent back to the workstation message queue associated with the interactive job that sent the message, unless the job is a batch job, in which case the reply is sent to the QSYSOPR message queue.

As messages are not displayed the moment they are received, there can be a delay of indeterminate length between the time we send a message and the time the recipient actually reads it. If the message is urgent, we can send a break message. To send a break message, we use the Send Break Message command, SNDBRKMSG. Unless the message queue has been altered with a program to handle break messages, the message interrupts the interactive job of the recipient.

The Send Break Message command, SNDBRKMSG, delivers messages only to a workstation message queue. The SNDBRKMSG command has two required parameters, MSG and TOMSGQ. To send a break message to all active workstations, we issue the command SNDBRKMSG MSG(‘Photons be free!’) TOMSGQ(*ALLWS). The *ALLWS special value used here indicates all work station message queues.

Please note that the Send Program Message, SNDPGMMSG, and the Send User Message, SNDUSRMSG, commands can be used only from within a CL program.

The LV DMS10 system offers enterprise level functionality at one low price

Sending Messages on the IBM i

Working with Library Lists on IBM i

The library list provides an effective way for programs to locate objects on the system. The library list a list of system and user libraries. Library lists provide a means for the IBM i to search through designated libraries to find objects that we need.

Every job and user has an associated library list. When a user or program issues a command or names an object without specifying a library, the system uses the library list to find an object with a matching name. The library list can have a maximum of forty libraries and is scanned from top to bottom.

The library list is made up of four components, System Libraries, Product Libraries, the Current Library, and the User Library. The System Libraries section must exist and must at least contain the QSYS system library. It can have from one to fourteen other libraries. The system value QSYSLIBL contains this section. To display this value, issue the command DSPSYSVAL SYSVAL(QSYSLIBL).

The Product Libraries section is optional and can be temporary. The Product Libraries section comes into state when a menu or command is invoked that uses a product library. The Current Library section is optional as well. It contains the name of a single library that is considered to be current at the time.

The User Library section is required. This section will at least have the QTEMP library in it and can contain between 1 to 25 library names. Each user can have a different user library section. The system value QUSRLIBL contains the user portion of the library list. To display this value, issue the command DSPSYSVAL SYSVAL(QSYSLIBL).

We can view the commands associated with the library list by bringing up the Library List Command menu, which can be done by entering the command GO CMDLIBL. This menu lists six commands in total. The first is the Add Library List Entry command, ADDLIBLE. The second is the Change Library List command, CHGLIBL. The third command is the Change System Library List command, CHGSYSLIBL.

We can use the Display Library List command, DSPLIBL, to view the library list for the current interactive job. The libraries will be listed ordered by type and then alphabetically within the each type section.  This is the order that will be used to search for an object with an unqualified name. A search always begins with the library with the lowest sequence number, and goes up each sequence number until the object has been found. Note that the system libraries precede the user libraries.

On the screen brought up by the DSPLIBL command, the library name will be displayed, one library per line, along with the library’s type and the text description of the library. A system library is identified by SYS. A product library is identified by PRD. A user’s current library is identified by CUR, and the remaining user libraries are identified by USR. The DSPLIBL command offers one option; this option is option 5, which executes the DSPLIB command, allowing us to the view descriptions of the objects in the library.

Users can add libraries to or remove libraries from the user part of the library list, and can also change their sequence. There are three commands available for changing our library list, the Add Library List Entry command, ADDLIBLE, the Remove Library List Entry command, RMVLIBLE, and the Edit Library List command, EDTLIBL. The EDTLIBL command includes the functionality of both the ADDLIBLE and RMVLIBLE commands.

The Add Library command, ADDLIBLE, lets us add a library to the user portion of the library list. To start, let’s create an example library with the name TEMPLIB1 by executing the command CRTLIB LIB(TEMPLIB1). We can then add this new library to our library list with the command ADDLIBLE LIB(TEMPLIB1). Running the DSPLIBL command shows us that TEMPLIB1 has in fact been added to the library list.

The Add Library command, ADDLIBLE, has a POSITION parameter that enables us to specify where in the library list to add a new library. This parameter accepts the special values *FIRST, the default, *LAST, *BEFORE, *AFTER, and *REPLACE. The *BEFORE, *AFTER, and *REPLACE special values all use a reference library parameter for placing the new library relative to it. As an example, let’s create three new libraries, TEMPLIB2, TEMPLIB3, and TEMPLIB4 via the CRTLIB command. Next, let’s add TEMPLIB2 to our library list by issuing the command ADDLIBLE LIB(TEMPLIB2). If we then run the DISPLIBL command, we can see that TEMPLIB2 has been placed above TEMPLIB1, as *FIRST is the default position parameter. Next, let’s run the command ADDLIBLE LIB(TEMPLIB3) POSITION(*LAST). Executing the DSPLIBL command will show us that TEMPLIB3 has been added to the very end of the library list. Finally, let’s run the command ADDLIBLE LIB(TEMPLIB4) POSITION(*AFTER TEMPLIB2). Running the DISPLIBL command will then show us that TEMPLIB4 has been placed after TEMPLIB2, and before TEMPLIB1.

The Remove Library List Entry command, RMVLIBLE, requires only one parameter, the name of the library to be removed from the user portion of the library list. Let’s remove the library TEMPLIB1 from the library list by issuing the command RMVLIBLE LIB(TEMPLIB1).

One of the drawbacks of modifying the library list is that once we sign off the changes are lost. The next time we sign in the library list will be rebuilt with the libraries contained in the system values QSYSLIBL, for the system libraries, and QUSRLIBL, for the user libraries.

The Edit Library List command, EDTLIBL, provides the functions of both the ADDLIBLE and RMVLIBLE commands together. The EDTLIBL command doesn’t require any parameters, so we can just enter EDTLIBL and press Enter. Note that the EDTLIBL command can only be used in interactive mode, and it only displays the user portion of the library list.

The Change Library List command, CHGLIBL, allows us to change the user portion of the library list entirely. The LIBL paramter allows us to specify the names of the libraries to be placed in the user portion of the library list. For example, entering the command CHGLIBL LIBL(QGPL QTEMP) will replace the existing user portion of the list with the two libraries QGPL and QTEMP.

It’s also possible to alter our job’s copy of the system portion of the library list with the Change System Library List command, CHGSYSLBL. It only affects our job; it doesn’t affect other jobs on the system.The CHGSYSLIBL command lets us add a library at the very top of the system portion of the library list; we cannot control where in the system portion we are adding the library. For example, running the command CHGSYSLIBL LIB(TEMPLIB1) will add the library TEMPLIB1 to the top of the system library portion of the list. Running DSPLIBL will show that TEMPLIB1 is at the top of the list; unless the system value QSYSLIBL has been altered, this will place TEMPLIB1 above the library QSYS. We can remove a library from the system portion of the library list with the OPTION parameter; to remove the library TEMPLIB1 we would issue the command CHGSYSLIBL LIB(TEMPLIB1) OPTION(*REMOVE).

Instantly replace your tape backup with faster more reliable disk for IBM i and iSeries systems:

Working with Library Lists on IBM i

Viewing Active Jobs on the IBM i

The system value QACTJOB sets the initial number of active jobs for which memory is allocated during IPL. To view this value, enter DSPSYSVAL SYSVAL(QACTJOB).

To view the CPU usage of individual jobs, we bring up the Work with Active Jobs screen by entering the command WRKACTJOB. The Work with Active Jobs screen shows what jobs are currently active. The Work with Active Jobs screen lists the jobs are running on the system, and enables us to change, hold or end the jobs or associated subsystems.

There are several types of active jobs, including autostart jobs, ASJ, batch jobs, BCH, batch immediate jobs, BCI, interactive jobs, INT, prestart jobs, PJ, subsystem monitor jobs, SBS, and system jobs, SYS. In the Work with Active Jobs screen we can see these codes listed in the Type column.

In the Status column, we can see a number of different status codes, the most common of which are CNDW, DEQW, EVTW, RUN, SELW, SIGW, and TIMW. The CNDW status means that the job is waiting for the handle-based conditions. The DEQW status means that the job is waiting for the completion of a dequeue operation. The EVTW status means that the job is waiting for an event. The SELW status means that the job is in a select wait. The SIGW status means that the job is waiting for a signal. The TIMW status means that the job is waiting for a time interval to end.

The WRKACTJOB command’s SBS parameter enables us to view the jobs from a particular subsystem. For instance, to view all the jobs currently running in the QSERVER subsystem, we run the command WRKACTJOB SBS(QSERVER). The QSERVER subsystem is for file-serving work. File server jobs and the database host server daemon job, QZDASRVSD, run in this subsystem.

The Work with User Jobs command, WRKUSRJOB, displays jobs by user profile name, and the Work with Subsystem Jobs command, WRKSBSJOB, displays jobs by subsystem name.

We can use the Work with User Jobs command, WRKUSRJOB, to segregate jobs that a particular user is running, no matter what status they have. Entering WRKUSRJOB without a parameter lists all of our jobs that are currently running or that have ended.  The Status column displays the status of our various jobs. If the Status is OUTQ, then the job is on an output queue. A job on the output queue typically has been completed. Type ‘5’ next to the desired entry and press Enter to see the Work with Job screen for that particular job. Entering the command WRKUSRJOB USER(*ALL) displays all of the jobs for all of the users, and entering the command WRKUSRJOB USER(*ALL) STATUS(*ACTIVE) displays all of the active jobs for all of the users on the system.

We can use the Work with Subsystem Jobs command, WRKSBSJOB, to segregate the jobs that are executing on a particular subsystem. For example, to view all jobs running in subsystem QBASE, we would issue the command WRKSBSJOB SBS(QBASE). This displays a list of active jobs in the subsystem QBASE; we can enter ‘5’ next to any of the listed jobs to work with it in greater detail.

You can view the runtime attributes of a job by running the Work with Job command, WRKJOB. Entering the command WRKJOB JOB(QTCPIP) will display a list of all jobs named QTCPIP. Entering 5 next to the job will take us to the Work with Job screen for that job. QTCIP normally runs in the QSYSWRK subsystem, and is the TCP/IP base program that must be running for any TCP/IP services to be used.

Entering the command WRKJOB JOB(QPWFSERVSD) will display a list of jobs named QPWFSERVSD. The QPWFSERVSD job is a Client Access server job, specifically the job running the file server daemon. Entering ‘1’ next to the job will bring up the Work with Job screen; at the top of this screen are the three elements that make up a job name on the IBM i: the name, the user, and the system-assigned job number. There is a menu of further options below. Entering ‘1’ here will show us the job status attributes.

The Display Job command, DSPJOB, shows information about a job that is in the system, irrespective of whether it is active or inactive. The default for the DSPJOB command is to display the current job, which is our interactive session. Entering ‘1’ at the Display Job screen will show the job status attributes for the selected job.

Network based backup for IBM i and iSeries systems:

Viewing Active Jobs on the IBM i