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/

Advertisements
General IBM i Security System Values

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

IPL-related System Values

Working with Date and Time System Values

The date and time values, *DATTIM, lets us view, set, and change the date and time the system stores and makes available to applications and utilities.

The system value that hold the current date for the system is QDATE. The QDATE value includes the day, month, and year. To see the current date on the system, run the command DSPSYSVAL SYSVAL(QDATE). The day, month, and year are set individually by the subvalues QDAY, QMONTH, and QYEAR, respectively. We can also view what century the IBM i platform thinks it is via the QCENTURY system value.

Screenshot (132)

The current time of day is stored in the QTIME system value. Time can be further divided into QHOUR, QMINUTE, and QSECOND. The current system time as an offset of Coordinated Universal Time (UTC) is set in the system value QUTCOFFSET.

The system date and time are stored in the value QDATETIME. To see both the current date and time, run the command DSPSYSVAL SYSVAL(QDATETIME).

The day of the week is defined by the system value QDAYOFWEEK; therefore, to see what day of the week it is, we would issue the command DSPSYSVAL SYSVAL(QDAYOFWEEK). The days of the week are indicated by the special values *SUN, *MON, *TUE, *WED, *THU, *FRI, and *SAT.

We can change the date and time system values using the CHGSYSVAL command, for which we need to specify two parameters, the first being the name of the system value we wish to change, and the second being the value we wish to change it to. To change the current year on the system, we would issue the command CHGSYSVAL SYSVAL(QYEAR) followed by the VALUE parameter, and the year we wish to set QYEAR to. For example, we could travel into the future by setting the date to the year 2042 by issuing the command CHGSYSVAL SYSVAL(QYEAR) VALUE(’42’). Note that we place the year value in single quotation marks. So, to change the date to April 21, 2015, we would issue the command CHGSYSVAL SYSVAL(QDATE) VALUE(‘042115’). Note again that we place the date value in single quotation marks.

We can modify the entire date at once by changing the system value QDATE. However, before changing QDATE using the CHGSYSVAL command, we should check the Date Format system value, QDATFMT. The QDATFMT system value determines the format in which a date can be specified. To view the date format, let’s issue the command DSPSYSVAL SYSVAL(QDATFMT). In the United States and outlying territories, this value will be MDY, indicating that the date format is month, day, and then year. To set the format to day, month, year, we issue the command CHGSYSVAL SYSVAL(QDATFMT) VALUE(DMY).

The system time is stored in QTIME and related subvalues. We can change the time to 5 PM, for instance, by issuing the command CHGSYSVAL SYSVAL(QHOUR) VALUE(‘17’). We should note well that the system value for time is set in 24-hour increments. The QTIME system value is six characters in length, and follows the format hours-minutes-seconds. Therefore, if we wanted to change the time to 5:20 in the morning, we would issue the command CHGSYSVAL SYSVAL(QTIME) VALUE(‘052000’).

Finally, we can always list all of the system values by entering the Work with System Value command,  WRKSYSVAL, at the prompt. Entering the command WRKSYSVAL SYSVAL(*DATTIM) will list all of the date and time system values.

Screenshot (133)
Want to get the most out of your IBM i system? Take a look at LaserVault, the friendly backup solution.

Working with Date and Time System Values

Getting Basic Info for IBM and Third-Party Vendors

When attempting to troubleshoot problems with IBM or third-party vendors, it can often be necessary to provide them with information regarding the machine model number, the processor code, and the serial number. We can access this information via the system control system values.The system control system values consist of values such as the console name for the system, QCONSOLE, and the system’s assistance level, QASTLVL.

Values of this type can be viewed by issuing the Work with System Values command, WRKSYSVAL. To list the system values, enter the command WRKSYSVAL SYSVAL(*SYSCTL). We are looking for three values in particular; QSRLNBR, the system’s serial number; QMODEL, the system model number; and QPRCFEAT, the system processor feature. In the list of values, under option, designated by Opt,  put the number 5 next to these three values, then hit Enter to display them.

wrksysval

We can, of course, access these system values individually as well by running the Work with System Values command, WRKSYSVAL, and using each of the desired system value names as parameters.

To display the system model number, key the command DSPSYSVAL SYSVAL(QMODEL). The QMODEL system value stores the model number of the system. Although the QMODEL system value is stored in a four-character length field, the value itself is usually three digits.

The QSRLNBR system value holds the system’s serial number, which is an alphanumeric code seven characters in length that uniquely identifies the IBM i system. To view the serial number system value, enter the command DSPSYSVAL SYSVAL(QSRLNBR).

dspsysval

The QPRCFEAT system value contains the system’s processor feature code, which is used to identify the processor used on the system. To view the processor feature code for the system, issue the command DSPSYSVAL SYSVAL(QPRCFEAT).

IBM and third-party vendors are also often interested in knowing the system’s serial number and processor group value for licensing purposes. The system serial value, QSRLNBR, and the processor group, which is an IBM designation that loosely groups related processors so as to facilitate tiered pricing, can be accessed by running the Work with License Information command, WRKLICINF. The system serial number and processor group values will be displayed at the top of the screen.

wrklicinf

Interested in getting the most out of your IBM i / iSeries system? Take a look at LaserVault, the friendly backup solution.

Getting Basic Info for IBM and Third-Party Vendors