AS/400-iSeries Starter Kit

Your shiny new AS/400 is out of the box. The microcode is all there, the operating system is installed, and all your program products are loaded on the system. The vendor has finished installation and is packing up the tools.

Up to this point (if you have done your homework) you have committed, planned, and planned some more for your new AS/400. Planning is a significant portion of the total installation process, but it isn't nearly as much fun as that moment when you turn on the power, watch the little lights start blinking, hear the low hum of the disk drives, and bring the magical screen to life -- giving you access to your new toy (I mean business machine). That's the moment you live for as a midrange MIS professional!

Signing On for the First Time

Once the power is on, you might think your previous S/3X experience would let you just feel your way around the system menus and functions. But that's not the case. My experiences with AS/400 installation have taught me that you should take some immediate steps (Figure 2.1) to put your carefully made plans into action.

User ASPs and checksum configuration. First, examine your backup and recovery plan to see whether you have decided to use Auxiliary Storage Pools (ASPs) or checksum. If so, grab your vendor installation team before they leave because the preloaded software on your system is about to be destroyed! As I discussed in Chapter 1, the AS/400 has a S/38-like single-level storage architecture that spreads objects (i.e., programs and data) in auxiliary storage equally over the disk to increase performance during retrieval. When you create a user ASP, you remove a segment of a disk or one or more disk units from the single-level storage area. Therefore, you lose a portion of your objects, and the system must re-initialize the system ASP and start from scratch. This same situation exists when you reserve storage on your disk unit for checksum operations.

Thus, after creating a user ASP or checksum, you must reload the microcode, the operating system, and each program product. Work with the installation team to create user ASP(s), to implement checksum, and to reload everything afterward. (Make sure you have all the software product tapes you need. With the advent of preloaded software, the software media may not have been shipped to you with the system.) Reconfiguring your storage and reloading your software may be a pain, but it is much easier during installation than when your machine is working in its production environment. And if ASPs or checksum are part of your backup plans, you can begin breathing easier knowing you are already prepared for disasters.

Verify software installation and PTF levels. Next, verify that the program products you ordered are installed on the system. The vendor should assist you in loading these program products if they are not already preloaded on the system. (If you don't have your program products and manuals, make sure you follow up on their delivery.)

Then determine whether or not the latest available cumulative Program Temporary Fix (PTF) release is installed on your system. The vendor should know which is the latest PTF level available and can help you determine whether or not that level exists on your system. If you don't have the latest release, order the tape now so you can apply the PTFs before you move your AS/400 into the production phase of installation. For more information about PTFs and installing PTFs, see Chapter 6, "Introduction to PTFs."

Signing on. With ASPs and checksum configured and the latest PTFs installed, you are now ready to sign on to your AS/400. Use the user profile QSECOFR to sign on, and enter QSECOFR -- the preset password for that profile. But don't start playing with your new system yet! You have some important chores to do during your first session.

Set the security level. Your AS/400 is shipped with the security level set at 10. With level 10, anyone who turns on a workstation, receives a sign-on screen, and presses the Enter key has full access to all system objects and functions. Obviously, you need to reset the security level as the first step in implementing your security plan.

In the previous chapter, I strongly suggested that you operate your machine at a minimum of security level 30. Don't wait until you move into a production environment; by then, switching levels will be too much trouble for you and a pain for your users. Change the security level now by keying in the command

CHGSYSVAL SYSVAL(QSECURITY) VALUE(XX)

where XX is either 30, 40, or 50. The change will take effect when you IPL the system.

Because you must perform IPLs to implement a number of settings on your AS/400, you might as well practice one now to put level 30 into action. Make sure the key is in the AUTO position and then power down the system with an automatic restart by keying in

PWRDWNSYS OPTION(*IMMED) RESTART(*YES)

When the system is re-IPLed, you can feel confident your AS/400 will operate in a secure environment.

Enforce password format rules. The next important step in implementing your security plan is setting the system values that control password generation. You should already have decided on the password rules, and changing the system values to enforce those rules is relatively easy.

In Chapter 1, I recommended five rules to guarantee the use of secure passwords on your system. To implement Rule 1, passwords must be a minimum of seven characters and a maximum of 10 characters, enter the code

CHGSYSVAL SYSVAL(QPWDMINLEN) VALUE(7) 
CHGSYSVAL SYSVAL(QPWDMAXLEN) VALUE(10)

The system value QPWDMINLEN (Password Minimum Length) sets the minimum length of passwords used on the system, and system value QPWDMAXLEN (Password Maximum Length) specifies the maximum length of passwords used on the system.

To implement Rule 2, passwords must have at least one digit, enter

CHGSYSVAL SYSVAL(QPWDRQDDGT) VALUE('1')

Setting the system value QPWDRQDDGT to 1 requires all passwords to include at least one digit.

For Rule 3, passwords cannot use the same character more than once, enter

CHGSYSVAL SYSVAL(QPWDLMTREP) VALUE('1')

Setting the system value QPWDLMTREP (Limit Character Repetition) to 1 prevents characters from being repeated in immediate succession within a password.

For Rule 4, passwords cannot use adjacent digits, enter

CHGSYSVAL SYSVAL(QPWDLMTAJC) VALUE('1')

This prevents users from creating passwords with adjacent numbers, such as their social security number or phone number.

Implement Rule 5, passwords should be assigned a time frame for expiration, by entering the command

CHGSYSVAL SYSVAL(QPWDEXPITV) VALUE(60)

System value QPWDEXPITV (Password Expiration Interval) specifies the length of time in days that a user's password remains valid before the system instructs the user to change passwords. The value can range from 1 to 366. The password expiration interval can also be set individually for user profiles using the PWDEXPITV parameter of the user profile. This is helpful because there are certain profiles, such as the QSECOFR profile, that are particularly sensitive and should require a password change more often for additional security.

Change system-supplied passwords. OS/400 provides several user profiles that serve various system functions. Some of these profiles do not have passwords, which means you cannot sign on as that user profile. For example, the default-owner user profile QDFTOWN doesn't have a password because the profile receives ownership of objects when no other owner is available. However, every AS/400 is shipped with passwords for the system-supplied profiles listed below, and these passwords are preset to the profile name (e.g., the preset password for the QSECOFR profile is QSECOFR). Therefore, you must change the passwords for these profiles:

• QSECOFR (security officer)

• QPGMR (programmer)

• QUSER (user)

• QSYSOPR (system operator)

• QSRVBAS (basic service representative)

• QSRV (service representative)

To enter new passwords, sign on as the QSECOFR profile and execute the following command for each of the above user profiles:

CHGUSRPRF USRPRF(user_profile) PASSWORD(new_password)

This can also be accomplished using the SETUP menu provided in OS/400. Type GO SETUP and then select the "Change Passwords for IBM-supplied Users" option (option 11) to work with the panel shown in Figure 2.2.

You can assign a password of *NONE (you cannot change QSECOFR password to *NONE), or you can assign new passwords that conform to the password rules you have just implemented. After changing the passwords for the system-supplied profiles, it would be wise to write the new passwords down and store them in a safe place for future reference.

Set auto-configuration control. After you have taken steps to secure your system, the next important action concerns the system value QAUTOCFG, which controls device auto-configuration and helps you establish your naming convention.

When your system is delivered, the system value QAUTOCFG is preset to 1, which allows the system to configure devices (e.g., terminals) automatically when the power is turned on. The system identifies the device type, creates a description for that device, and assigns a name to the device. Having QAUTOCFG set to 1 is necessary because the AS/400 then configures itself for your initial sign-on session.

When the QAUTOCFG system value is set at its default value of 1, auto-configured devices are named according to the standard specified in the system value QDEVNAMING. The possible values for QDEVNAMING are *STD or *S36. If the system value is left at the default value of *STD, the AS/400 assigns device names according to its own standard (e.g., DSP01 and DSP02 for workstations; PRT01 and PRT02 for printers). If the option *S36 is specified, the AS/400 automatically names devices according to S/36 naming conventions (e.g., W1 and W2 for workstations; P1 and P2 for printers).

Although automatic configuration gives you an easy way to configure new devices (you can plug in a new terminal, attach the cable, and -- "Poof!" -- the system configures it), it can frustrate your efforts to establish a helpful naming convention for your new machine. Therefore, after the system has been IPLed and the initial configuration is complete, you should reset the value of QAUTOCFG to 0, which instructs the system not to auto-configure devices. You can reset auto-configuration by executing the command

CHGSYSVAL SYSVAL(QAUTOCFG) VALUE('0')

This change takes effect when you re-IPL the system. (If you haven't done so already, you should re-IPL the system now to put into effect the changes you have made for security level, password rules, and auto-configuration.) You must now configure devices yourself when needed.

Admittedly, configuring devices is much more of a pain than letting the system configure for you. But I recommend this approach because it usually requires more planning, better logic, better structure, a better naming convention, and better documentation. Configuring devices is beyond the scope of this chapter, but the subject is well documented in IBM's AS/400 Device Configuration Guide (SC41-8106).

Setting general system values. Several times now, you have set AS/400 system values. A system value is an object type found in library QSYS, and the AS/400 has many of these useful objects to control basic system functions. To further familiarize you with your new system, let's take a look at a few of the most significant system values. (You can use the WRKSYSVAL (Work with System Values) command to examine and modify system values.)

QABNORMSW is not a value that you modify; the system itself maintains the proper value. When your system IPLs, this system value contains a 0 if the previous end of system was NORMAL (meaning you powered the system down and there was no error). However, if the previous end of system was ABNORMAL (meaning there was a power outage that caused system failure, some hardware error that stopped the system, or any other abnormal termination of the system), this system value will be 1. The benefit of this system value is that during IPL, your initial start-up program can check this value. If the value is 1, meaning the previous end of system was ABNORMAL, you might want to handle the IPL and the start-up of the user subsystems differently.

QCMNRCYLMT controls the limits for automatic communications recovery. This system value is composed of two numbers. The first number controls how many attempts will be made at error recovery. The second number indicates how many seconds will expire between attempts at recovery. The initial values are '0' '0'. This instructs the system to perform no error recovery when a communications line or control unit fails. If left in this mode, the operator will be prompted with a system message asking whether error recovery should be attempted. The values '5' '5' would instruct the system to attempt recovery five times and wait five seconds between those attempts. Only at the end of those attempts would the operator be prompted with a system message if recovery has not been established.

A word about the use of QCMNRCYLMT: If you decide to use the system error recovery by setting this system value, you will add some work overhead to the system, because error recovery has a high priority on the AS/400. In other words, if a communications line or control unit fails and error recovery kicks in, you will see a spike in your response time. If you experience severe communications difficulties, reset this system value to the initial value of '0' '0' and respond manually to the failure messages.

QMAXSIGN specifies the number of invalid sign-on attempts to allow before varying that device off. The initial value is 15, but I recommend a value of 3 for tighter security. Setting QMAXSIGN to 3 means that after three unsuccessful attempts at signing onto the system (because of using an invalid user profile or password), the system will disable either the device or user profile being used (the action performed depends upon the value of the QMAXSGNACN system value). You will have to enable the device or user profile again to make it available.

QPRTDEV specifies which printer device is the default system printer. When a user profile is created, the output will default to this printer (unless a particular output queue or printer device is specified). The initial value is PRT01. If you have a printer device named SYSPRINT, you can change the value of QPRTDEV to SYSPRINT.

These are just a few of the system values available on the AS/400. For a list of system values and their initial values, consult IBM's AS/400 Programming: System Reference Summary (SX41-0028), or its AS/400 Programming: Work Management Guide (SC41-8078). It is worth your time to read about each of these values and determine which ones need to be modified for your particular installation.

Establishing Your Work Environment

Okay, you have covered a lot of ground so far. You've made the system secure, reset the auto-configuration value, and looked at some general system values. But it's not time for fun and games yet. Now you should establish your work environment.

When the system is shipped, your work environment is simple. Memory is divided into the machine pool, subsystem QBASE, and subsystem QSPL. The system uses the machine pool to interface with the hardware. Subsystem QBASE is a memory pool used to execute all the interactive, batch, and communications jobs. QSPL is the spooling subsystem that provides the operating environment (memory and processing priorities and parameters) for programs that read jobs onto job queues to wait for processing and write files from an output queue to an output device.

While this simple arrangement is functional, it may not be effective or efficient. For example, if the system value setting the machine pool size is too low, performance is slow; if the value is too high, you waste memory. Thus, you need to customize your work environment for your organization. Let's look at the most important work management objects.

QMCHPOOL is the system value that specifies the amount of memory allocated to the machine pool. Examine this value and compare it with the calculated value you arrive at based on the configuration you are operating. Figure 2.3 shows the formula for calculating the machine pool size, and Figure 2.4 shows a sample calculation that assumes you have an AS/400 with a main storage size of 32 MB, an estimated 150 active jobs, four SDLC communications lines, two controllers on each line, save/restore operations, and one Token-Ring adapter. The resulting machine pool size is 4,918 KB, which you might round off to 5,000 KB. Fudging a little on the calculations won't hurt if you monitor the performance of this pool under normal work loads and adjust either way. (For basic pool performance tuning information, see Chapter 13 of the Work Management Guide).

QBASPOOL specifies the minimum size of the base storage pool. Memory not allocated to any other storage pool stays in the base storage pool. This pool supports system jobs (e.g., SCPF, QSYSARB, QSYSWRK, QSPLMAINT, and subsystem monitors) and system transients (such as file OPEN/CLOSE operations). Enter the WRKSYSSTS (Work System Status) command to see the amount of storage the machine has reserved for these functions (the reserved value will appear on the display as RESERVED). You can use this value as a minimum value for QBASPOOL, but I recommend being a little more generous. For example, if the reserved size is 1,600 KB, you should set the QBASPOOL value higher (a good rule of thumb is to add 400 KB for each activity level QBASPOOL supports) because many more system jobs will be active under normal working conditions. As with QMCHPOOL, monitor the value of QBASPOOL to make sure it remains adequate.

QBASACTLVL sets the maximum activity level of the base storage pool. The initial value for QBASACTLVL depends on your AS/400 model. This default value should be adequate; however, if you elect to run batch jobs in this pool (instead of creating a separate private pool for batch processing), you should make sure that you adjust this value to allow for one activity level for each batch job that you will allow to process simultaneously. Monitor the performance of the base pool to determine whether additional memory or another activity level is required.

QMAXACTLVL sets the maximum activity level of the system by specifying the number of jobs that can compete at the same time for main storage and processor resources. By examining each subsystem, you can establish the total number of activity levels; this value must at least equal that number or be set higher. I suggest you set the QMAXACTLVL value to five above the total number of activity levels allowed in all subsystems, which will let you increase activity levels for individual subsystems for tuning purposes without having to increase QMAXACTLVL. However, if the number of subsystem activity levels exceeds the value in QMAXACTLVL, the system executes only the number of levels specified in QMAXACTLVL, resulting in unnecessary waiting for your users. Therefore, you must increase QMAXACTLVL if you increase the total number of activity levels in your subsystems or if you add subsystems.

QACTJOB is the system value that specifies the initial number of active jobs for which the system should allocate storage during IPL. The amount of storage allocated for each active job is approximately 110 KB (this is in addition to the auxiliary storage allocated due to the QTOTJOB system value, discussed below.) I suggest you set this number to approximately 10 percent above the average number of active jobs (i.e., any user or system job that has started executing but has not ended) that you expect to have on the system. For example, if you have an average of 50 active jobs, set the QACTJOB value at 55. Setting QACTJOB and QTOTJOB to values that closely match your requirements helps the AS/400 correctly allocate resources for your users at the system start-up time instead of continually having to allocate more work space (e.g., for jobs or workstations) and provides more efficient performance.

QTOTJOB specifies the initial number of jobs for which the system should allocate auxiliary storage during IPL. The number of jobs is the total possible jobs on the system at any one time (e.g., jobs in the job queue, active jobs, and jobs having spooled output in an output queue).

QADLACTJ specifies the additional number of active jobs for which the system should allocate storage when the number of active jobs in the QACTJOB system value is exceeded. Setting this value too low may result in delays if your system needs additional jobs, and setting it too high increases the time needed to add the additional jobs.

QADLTOTJ specifies the additional number of jobs for which the system should allocate auxiliary storage when the initial value in QTOTJOB is exceeded. As with QADLACTJ, setting this value too low may result in delays and interruptions when your system needs additional jobs, and setting it too high slows the system when new jobs are added.

You will need to document changes to these objects. I suggest you record any commands that change the work management system values (or any other IBM-supplied objects) by keying the same commands into a CL program that can be run each time a new release of the operating system is loaded. This ensures that your system's configuration remains consistent.

Establishing your subsystems. Selecting your controlling subsystem is the next task in establishing your work environment. When your system is shipped, the controlling subsystem for operations is QBASE. It supports interactive, batch, and communications jobs in the same memory storage pool. When the system IPLs, QBASE is started and an autostart job also starts the spool subsystem QSPL. This default configuration is simple to manage because these two subsystems are used apart from the machine pool and the base pool.

However, I recommend implementing separate subsystems for each type of job to provide separate memory pools for each activity. One memory pool can support all activities. But when long-running batch jobs run with interactive workstations that compete for the same memory, system performance is poor and the fight for activity levels and priority becomes hard to manage. My experience with AS/400s has taught me that establishing separate subsystems for batch, interactive, and communications jobs gives you much more control. Using QCTL as the controlling subsystem establishes separate subsystems for batch, interactive, and communications jobs and can be the basis for various customized subsystems. Use the following command to change the controlling subsystem from QBASE to QCTL:

CHGSYSVAL SYSVAL(QCTLSBSD) VALUE('QCTL QGPL')

or you can use the WRKSYSVAL command to modify the system value. (The above CHGSYSVAL command changes the value of QCTLSBSD, which is the system value that specifies what the controlling subsystem will be.) This will be effective after the next IPL.

Although the QCTL subsystem only supports sign-on at the console, QCTL also begins an auto-start job at IPL. The auto-start job then starts four system-supplied subsystems: QINTER, QBATCH, QCMN, and QSPL (the descriptions for these subsystems are in the QGPL library). The QINTER subsystem supports interactive jobs, QBATCH supports batch jobs, QCMN supports communication jobs, and QSPL still supports its normal functions as the spooling subsystem. You can thus allocate memory to each subsystem based on the need for each type of job and set appropriate activity levels for each subsystem. No system values control the memory pools and activity levels for individual subsystems, but the subsystem description contains the parameters that control these functions. For example, when you create a subsystem description with the CRTSBSD (Create Subsystem Description) command, you must specify the memory allocation and the number of activity levels. You can find more information about subsystem descriptions in Chapters 17, 18, and 19, and in the Work Management Guide, and more information about the CRTSBSD command in the Control Language Reference (SC41-0030).

Making QCTL the controlling subsystem will also help if you decide to create your own subsystems. For instance, if your system supports large numbers of remote and local users, you may want to further divide the QINTER subsystem into one subsystem for remote interactive jobs and another for local interactive jobs. Thus, you can establish appropriate execution priorities, time slices, and memory allocations for each type of job and greatly improve performance consistency.

Retrieving and modifying the start-up program QSTRUP. When you IPL your system, the controlling subsystem QBASE or QCTL, whichever you decide to use, submits an auto-start job that runs the program specified in the system value QSTRUPPGM. The initial value for that system value is QSTRUP QSYS. This program starts the appropriate subsystems and starts the print writers on your system.

However, you may want to modify QSTRUP to perform custom functions. For instance, you may have created additional subsystems that need to be started at IPL, or you may want to run a job that checks the QABNORMSW system value each time the system is started. Retrieve the CL source code for QSTRUP (Figure 2.5) by executing the command

RTVCLSRC PGM(QSYS/QSTRUP) SRCFIL(QGPL/QCLSRC)

After retrieving the source, use the SEU editor to change QSTRUP to perform other start-up functions for you. Figure 2.6 shows a sample user-modified start-up program that uses QCTL as the controlling subsystem for the additional subsystems of QPGMR, QREMOTE, and QLOCAL. The sample program also checks the status of the QABNORMSW system value.

Once you have modified QSTRUP, recompile the program into library QSYS under a different name or to a different library. (I suggest you leave the program in library QSYS, just in case someone deletes the library that contains your new start-up program.) Then change QSTRUPPGM to use your new program. Make sure you test your new start-up program before replacing the original program.

Now What?

You have made the most of your first session. You have secured your system, set the auto-configuration values, customized your work environment, established the controlling subsystem, and modified the start-up program. Now you need to create user profiles for your staff so they can begin working through the education programs in Tutorial System Support. Then you can create profiles for all the users and start customizing your system even further. I'll tell you how in Chapter 3.