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 http://laservault.com/lv-ubd/iseries-tapeless-backup-and-restore/

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 http://laservault.com/lv-ubd/iseries-tapeless-backup-and-restore/

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 http://laservault.com/lv-ubd/iseries-tapeless-backup-and-restore/

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 http://laservault.com/lv-ubd/iseries-tapeless-backup-and-restore/

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 http://laservault.com/document-management/scan-and-retrieval-solution-dms10/

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: http://laservault.com/lv-ubd/iseries-tapeless-backup-and-restore/

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: http://laservault.com/lv-backup/as400-backup-and-recovery-software-about-lvb/

Viewing Active Jobs on the IBM i

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 www.laservault.com, 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 www.laservault.com, 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 www.laservault.com, the friendly IBM backup solution.

Displaying Messages