System Values

by Craig Pelkie

Among all of the aspects of the AS/400 that you must learn, there is an unobtrusive yet potentially profound entity known as a "system value." IBM groups the many system values into eight categories. Some of these values are set as part of the "shipped system," meaning that the value is initially assigned when you install OS/400. Other values are set as the result of system operations. You can query the current setting of all system values, and you can change most, but not all, to different values.

If you are unfamiliar with system values, you should read this article as well as the section in the Work Management Guide (SC21-8078) that describes them. Sometimes a change that you want to make to your system is done by setting a system value, and if you don't know about it, it can be quite vexing to try to determine how to make the system behave the way you want it to.

Short and Sweet

System values are not "objects," so they are unlike anything else that is stored in the system. Regardless, each system value comprises two elements: the name of the system value and the current value. In keeping with AS/400 conventions, all system value names begin with the letter "Q" and use a more or less mnemonic convention for the rest of the name. For example, the name of the autoconfiguration system value is QAUTOCFG. If you are familiar with AS/400 command naming conventions, you will see the similarity between command and system value names. However, unlike commands, it is difficult to "guess at" system value names.

Prior to Release 3, you would usually have to refer to one of the charts to determine the name and meaning of a system value. One of the nice ease-of-use features that is new with Release 3 is the WRKSYSVAL (Work with System Value) command. That command displays a list of system values, the type of system value, and a description of the value. You can use options on the display to change or display the actual value.

You generally set system values when you install a new release of OS/400. If you are updating from a previous release, you will want to make a note of any system values that you changed, since you will have to change them after the release is installed. For the system values that you can change, you can change them at any time, using either the WRKSYSVAL display or the CHGSYSVAL (Change System Value) command. You can use the CHGSYSVAL either interactively or in a CL program.

When you change a system value, the change may take effect immediately, at job initiation time, or at the next IPL. You must review the manual for each value that you change to determine when the change takes effect. If you are one of those shops that seldom IPLs, be aware of this, as you may have to IPL to get the new value to take effect.

Types of System Values

IBM groups system values into eight types. Date and time values are used to set the system date and time. Editing values are used in your programs or by OS/400 to control the currency symbol, the decimal and date formats. An especially lengthy and interesting group of system values are the System Control values, which are concerned with configuration, IPL, and other operational features. Library List system values let you set the system library list and the user library list. Allocation system values are used to set initial numbers of active jobs, spooling control, and message queue sizing. Message and Logging values are used to control history and problem logging. Storage system values can have a great impact on system performance; they determine the size and activity level of system storage pools. And finally, security values are used to control sign-on and passwords, among other things.

Rather than discuss all of the system values, I will point out the ones that may be of immediate interest. Many of the values are used to control aspects of the system that, in themselves, warrant entire articles, which we will cover in Midrange Computing in the future.

Setting the Clock

In the United States, and, for all I know, in other parts of the world, there is a need to adjust the clock twice a year. You can set the clock by using the CHGSYSVAL command (or the WRKSYSVAL display). For example, if the current system clock is set to 10:00 AM, you can change it to 11:00 AM with this command: CHGSYSVAL QHOUR '11'. Oddly enough, the QHOUR value is a character value, not numeric, so you have to enclose it in quotes. If you forget the quotes, the system does not accept the command. The charts in the Work Management Guide tell you whether a value is character or numeric, as well as the length of the value. You also must enter valid values; for example, you cannot enter QHOUR as '25'. You can also set QMINUTE, and if you are very precise, QSECOND, or you can set all of these at once with QTIME. (QTIME lets you specify to the thousandth of the second. I am happy if my clock is within a few minutes of the "right" time.)

You can also set the year, month and day, separately or all together, with QYEAR, QMONTH, QDAY and QDATE. If you have a preference for a different date format or date separator character, you can set those with QDATFMT (date format) and QDATSEP (date separator). The date format in the U.S. is MDY, month, day, year, and the separator is the "/" character. You can specify DMY or YMD for the date format, and you can set the separator to any character you want. You will see the effect of the date separator on system displays that show the date; that character is also used when you use the "Y" edit code in RPG programs.

System Control

There are a few system values for System Control that you may want to investigate. One of the problem areas that some sites have is with the autoconfiguration capability of the AS/400. If you do not want to let the system automatically create device descriptions for you, you can set QAUTOCFG to '0' (most of the system values that have "yes" or "no" responses use "1" and "0" to indicate those settings). Closely allied with QAUTOCFG is QDEVNAMING, device naming convention. You have three choices here: "*NORMAL" for AS/400 standards (such as DSP01 and PRT01), "*S36" for a System/36 type scheme (W1, P1) and "*DEVADR" which makes up a name from the device address. Many of the complaints that people have about automatic configuration is that the device names are not that meaningful to them; for example, many sites assign device name based on department or location. Obviously, the AS/400 knows nothing about your preferences in naming, so it offers these three alternatives. Another value that will have a great effect on you is QSPCENV, default special environment. This can be either "*S36" or "*NONE". The *S36 setting means that you are put into the S/36 environment when you sign on. If you are migrating from an actual S/36 to the AS/400 S/36 Environment, and then to native AS/400, you may want to keep this value in mind. Someday you will want to change it.

One of the values that can generate a great deal of discussion is QPFRADJ, performance adjustment. If this is set on (1), then your system will adjust various pool sizes and activity levels at the next IPL. If you are trying to control those settings yourself, you will certainly want to change this to "0", since the shipped setting is "1".

For software vendors, two interesting system values are QMODEL, machine model number, and QSRLNBR, system serial number. These are "read only" values, meaning that they can't be changed with the CHGSYSVAL or WRKSYSVAL commands. The usual practice with these types of values is to retrieve them in a CL program with the RTVSYSVAL command. The setting of the retrieved system value can be placed into a CL variable, which is then used like any other variable.

There are some other system control values that you may want to investigate. Some of them are used if you have a UPS attached to your system. Others control various activities at IPL time, such as running a start-up program, starting print writers, and assigning a controlling subsystem.

Library Lists

You can set the system and user parts of the library lists with the QSYSLIBL and QUSRLIBL commands. You should review the September 1990 issue of Midrange Computing for a discussion of library lists in the "AS/400 Basics" article.

System Security

Within the security type of system values, there are several values that you will want to consider. Of primary importance is QSECURITY, the security level indicator. This is 10, 20, 30 or 40, and the implications of each setting are worthy of many articles. You probably have already set this, but if you have not, and are still operating at security level 10 (the shipped value), this is where it is.

Another interesting value is QMAXSIGN, maximum number of invalid sign-on attempts. This is shipped at a rather high 15; many installations that I have seen set this to 3. Granted, it may be difficult to enter a nondisplay password, but three tries should be enough.

An interesting combination that may solve an age-old problem is QINACTITV and QINACTMSGQ. QINACTITV sets a time-out interval in minutes for inactive jobs. For example, if your users get up and wander away from a signed-on terminal, you can indicate that somewhere between 5 and 300 minutes, you want to know about it. This value is initially shipped as "*NONE", meaning that the system is not monitoring jobs for inactivity. You control how you get to know about it with QINACTMSGQ, the message queue to receive job inactive messages. You can indicate that the message for the inactive job is sent to a specific message queue, where you would presumably have a program monitoring the arrival of the message. You can then programmatically take control of the inactive job. You can also cause the job to end by specifying "*ENDJOB" or to disconnect by specifying "*DSCJOB." If you use "*DSCJOB," you can control how long the disconnected job remains disconnected before it is forced to end, by placing a time interval in system value QDSCJOBITV. Using this disconnect approach over the end job approach can give you security without concern about the interactive job being terminated.

Also in the security category of system values, there are several values that control how passwords are formulated and changed. This seems to have migrated down from the mainframe folks, and you will have to review these settings to decide if you want to get that involved with password rules.

Dealing with System Values

The easiest way to work with system values is WRKSYSVAL. That displays the name and description of the value, and allows easy access to the setting. You can still use the DSPSYSVAL (Display System Value) command, but you have to type in the name of the value, and you get to see only one value per usage of the command.

Because system values are not objects, you cannot save them with the SAVOBJ or SAVLIB command. You can use SAVSYS to save them, but I do not know if you can restore them by themselves, or only if you restore the entire system. That is a strong reason to make a note of any changes you make to system values, so that you can reset them as needed. If nothing else, write the current settings and any changes you make in the Work Management Guide, on the chart of the system values. When you do make a change, note the reason for the change also D particularly with performance values that you may want to reconsider at some later date.

Another way is to print all system values with the WRKSYSVAL command, specifying OUTPUT(*PRINT) every time you change a system value. The best way to document system values is by writing a CL program that contains nothing but CHGSYSVAL commands. Then this program can be executed to "restore" the system values.

As mentioned above, you can retrieve system values within a program. You need to use the CL command RTVSYSVAL (Retrieve System Value). You retrieve the system value that you want into a CL program variable. The variable must be defined as the type of the system value, and must be long enough to accommodate it. For example, do not retrieve QDATE into a 3-digit variable; instead, retrieve it into a character field of length 6 (or 5 if you are using Julian dates).

You can change a system value either interactively or in a CL program. Interactively, you use the WRKSYSVAL or CHGSYSVAL commands; in a CL program, you use CHGSYSVAL. In my experience, I have only seen system value changes for the storage system values, which affect system performance. This is one of the techniques used in automatic tuning programs, although such programs also need to work with other configuration parameters.

Summary

If you are new to the AS/400, or if you have not thought about system values for a while, you may want to review the meaning and settings of the values. New values are added with each release of OS/400, so you ought to stay current with the changes.

Also Read

IBM i Has Now Had More Life Than the AS/400 Did

IBM i in 2020: It’s Not Just AS/400

New IBM i Technology Refreshes…Sort Of