AS/400-iSeries Starter Kit

IBM supplies a few user profiles with which to maintain the AS/400, such as QSECOFR (Security Officer), QDFTOWN (Default Owner), and QSRV (Service Profile used by the Customer Engineer). In addition to these profiles, you need profiles for your users so they can sign on to the system and access their programs and data. For this aspect of setting up your AS/400, you first need to understand user profiles and their attributes. With that knowledge you can, if you wish, turn over to a program the job of creating profiles for your users.

What Is a User Profile?

To the AS/400, a user profile is an object. While the object's name (e.g., WDAVIS or PGMR0234) is what you normally think of as the user profile, a user profile is much more than a name. The attributes of a user profile object define the user to the system, enabling it to establish a custom initial session (i.e., job) for that user at sign-on. To make the best use of user profiles, you must understand those attributes and how they can help you control access to your system.

You create a user profile using the CRTUSRPRF (Create User Profile) command. Only the security officer profile (QSECOFR) or another profile that has *SECADM (security administrator) special authority can create, change, or delete user profiles. You should restrict authority to the CRTUSRPRF (Create User Profile), CHGUSRPRF (Change User Profile), and DLTUSRPRF (Delete User Profile) commands to those responsible for the creation and maintenance of user profiles on your system.

The CRTUSRPRF and CHGUSRPRF commands have a parameter for each user profile attribute. If you prompt the CRTUSRPRF command and then press F10, the system will display the command's parameters (Figure 3.1).

But before you create any user profiles, you should first decide how to name them. In Chapter 1, I stressed the importance of developing a strategic naming convention for user profiles. Once you have performed this task, you are ready to create a user profile for each person who needs access to your system.

Creating User Profiles

Figure 3.1 represents all the available parameters for creating a user profile. Except for the user profile name (USRPRF) parameter, each parameter has a default value that will be accepted unless you supply a specific value to override that default. Following are the key user profile parameters that you will frequently change to customize a user profile.

USRPRF (User Profile)

The first parameter is USRPRF, which contains the user profile name you decided on. This is a required parameter and you will enter the name of the user profile you are creating.

PASSWORD (User Password)

As I mentioned in Chapter 1, passwords should be secret, hard to guess, and regularly changed. You cannot ensure that users keep their passwords secret, but you can help make them hard to guess by controlling password format, and you can make sure passwords are changed regularly.

This discussion assumes you allow users to select and maintain their own passwords. No one in MIS needs to know user passwords. The AS/400 does not allow even the security officer to view existing passwords. This would violate the first rule of passwords -- that they be secret!

The PASSWORD parameter lets you specify a value of *NONE, a value of *USRPRF, or the password itself. *NONE, which means that the user profile cannot sign on to the system, is recommended for group profiles, profiles of users who are on vacation and do not need access for a period of time, users who have been terminated but cannot be deleted at the time of termination, and for other situations in which you want to ensure that a profile is not used. The default value, *USRPRF, dictates that the password be the same as the user profile name. You should not use PASSWORD(*USRPRF); otherwise, you will forfeit the layer of security provided by having a password that differs from the user profile name.

You can control the format of passwords by using one or more of the password-related system values discussed in Chapter 2 or by creating your own password validation program (see the discussion of the QPWDVLDPGM in IBM's Security Reference manual (SC41-8083). The format you impose should encourage users to create hard-to-guess passwords but should not result in passwords that are so cryptic users can't remember them without writing them down within arm's reach of the keyboard. As I said in Chapter 1, I suggest the following guidelines:

• Enforce a minimum length of at least seven characters (use the QPWDMINLEN system value).
• Require at least one digit (use the QPWDRQDDGT system value).
• Do not allow adjacent numbers in a password (use the QPWDLMTAJC system value).
• Do not allow an alphabetic character to be repeated in a password (use the QPWDLMTREP system value).

To ensure that users change their passwords regularly, use system value QPWDEXPITV to specify the maximum number of days a password will remain valid before requiring a change. A good value for QPWDEXPITV is 60 or 90 days, which would require all users system-wide to change passwords every two or three months. You can specify a different password expiration interval for selected individual profiles using CRTUSRPRF's PWDEXPITV parameter, which I'll discuss later in this chapter.

PWDEXP (Set Password to Expired)

The PWDEXP parameter lets you set the password for a specific user profile to the expired state. When you create new user profiles, you may want to specify PWDEXP(*YES) to prompt new users to choose a secret password the first time they sign on. The same is true when you reset passwords for a users who forgot theirs.

STATUS (Profile Status)

This parameter specifies whether a user profile is enabled or disabled for sign-on. When the value of STATUS is *ENABLED, the system allows the user to sign on to the system. If the value is *DISABLED, the system does not allow the user to sign on until an authorized user re-enables it (changes the value to *ENABLED).

The primary use of this parameter is in conjunction with the QMAXSGNACN system value. If QMAXSGNACN is set to 2 or 3, the system will disable a profile that exceeds the maximum number of invalid sign-on attempts (the QMAXSIGN system value determines the maximum number of sign-on attempts allowed). When a user is disabled, the system changes the value of status to *DISABLED. An authorized user must reset the value to *ENABLED before the user profile can be used again.

USRCLS (User Class) and SPCAUT (Special Authority)

These two parameters work together to specify the special authorities granted to the user. Special authorities allow users to perform certain system functions, such as save/restore functions, job manipulation, spool file manipulation, and user profile administration (see the discussion of user classes and special authorities in Chapter 1).

The USRCLS parameter lets you classify users by type. Figure 3.2 shows the five classes of user recognized on the AS/400: *SECOFR (security officer), *SECADM (security administrator), *PGMR (programmer), *SYSOPR (system operator), and *USER (user). These classes represent the groups of users that are typical for an installation. By specifying a user class for each user profile, you can classify users based upon their role on the system.

When you assign user profiles to classes, the profiles inherit the special authorities associated with their class. Figure 3.2 also shows the default special authorities associated with each user class under security levels 30, 40, and 50. While you can override these special authorities using the SPCAUT (Special Authority) parameter, often the default authorities are sufficient.

The default for the SPCAUT parameter is *USRCLS, which instructs the system to refer to the user class parameter and assign the predetermined set of special authorities that appear in Figure 3.2. You can override this default by typing from one to five individual special authorities you want to assign to the user profile. After sending a message that the special authorities assigned do not match the user class, the system will create the user profile as you requested.

Here are two examples:

CRTUSRPRF USRPRF(B12ICJES) PASSWORD(password) USRCLS(*PGMR)

User profile B12ICJES will have *SAVSYS and *JOBCTL special authorities.

CRTUSRPRF USRPRF(B12ICJES) PASSWORD(password)USRCLS(*PGMR)+
          SPCAUT(*NONE)

In this case, user profile B12ICJES will be in the *PGMR class but will have no special authorities.

Figure 3.3 lists the values allowed for the SPCAUT parameter and what each means. Special authorities should be given to only a limited number of user profiles because some of the functions provided are powerful and exceed normal object authority. For instance, *ALLOBJ special authority gives the user unlimited access to and control over any object on the system -- a user with *ALLOBJ special authority can perform any function on any object on your system. The danger in letting that power get into the wrong hands is clear.

Generally speaking, no profile other than QSECOFR should have *ALLOBJ authority. This is why the security level of any development or production machine should be at least 30, where resource security and *ALLOBJ special authority can be controlled with confidence.

Your security implementation should be designed so it does not require *ALLOBJ authority to administer most functions. Reserve this special authority for QSECOFR, and use that profile to make any changes that require that level of authority.

The *SECADM special authority is helpful in designing a security system that gives users no more authority than they need to do their job. *SECADM special authority enables the user profile to create and maintain the system user profiles and to perform various administrative functions in OfficeVision/400. Using *SECADM, you can assign an individual to perform these functions without having to assign that profile to the *SECOFR user class.

The *SAVSYS special authority lets a user profile perform save/restore operations on any object on the system without having the authority to access or manipulate those objects. *SAVSYS shows clearly how the AS/400 lets you grant only the authority a user needs to do a job. What would it do to your system security if your operations staff needed *ALLOBJ special authority to perform save/restore operations? If that were the case, system operators could access such sensitive information as payroll and master files. *SAVSYS avoids that authorization problem while providing operators with the functional authority to perform save/restore operations.

*SERVICE is another special authority that should be guarded. Having *SERVICE special authority enables a user profile to use the System Service Tools. These tools provide the capability to trace data on communications lines and actually view user profiles and passwords being transferred down the line when someone signs on to the system. These tools also provide the capability to display or alter any object on your system. So be stingy with *SERVICE special authority.

The QSRV, QBASSRV, and QSECOFR profiles provided with OS/400 have *SERVICE authority. You should check whether or not your systems still have the default passwords for the system profile QSRV or QBASSRV. If they do, change the passwords to *NONE, and assign a password only when a Customer Engineer needs to use one of these profiles.

Initial Sign-On Options

CURLIB (Current Library)

INLPGM (Initial Program)

INLMNU (Initial Menu)

LMTCPB (Limit Capabilities)

Three user profile parameters work together to determine the user's initial sign-on options. The CURLIB, INLPGM, and INLMNU parameters determine the user profile's current library, initial program, and initial menu, respectively. Why are these parameters significant to security? They establish how the user interacts with the system initially, and the menu or program executed at sign-on determines the menus and programs available to that user. Let's look at a couple of examples:

Example 1

Consider the user profile USER, which has the following values:

Current library . . . . . . . . CURLIB        ICLIB    
Initial program to call . . . . INLPGM        *NONE    
  Library . . . . . . . . . . .                           
Initial menu  . . . . . . . . . INLMNU        ICMENU   
  Library . . . . . . . . . . .                 ICLIB     

When USER signs on to the system, the current library is set to ICLIB and the user receives menu ICMENU in library ICLIB. Any other menus or programs that can be accessed through ICMENU and to which USER is authorized are also available.

Example 2

Current library . . . . . . . . CURLIB        ICLIB    
Initial program to call . . . . INLPGM        ICUSERON 
  Library . . . . . . . . . . .                 SYSLIB    
Initial menu  . . . . . . . . . INLMNU        *SIGNOFF  
  Library . . . . . . . . . . .                           

When USER signs on to the system, ICLIB is the current library in the library list, and program ICUSERON in library SYSLIB is executed. Again, any other menus or programs accessible through ICUSERON and to which the user is authorized are also available.

The value of *SIGNOFF for the INLMNU parameter is worth some discussion. When a user signs on, OS/400 executes the program, if any, specified in the INLPGM parameter. If the user or user program has not actually executed the SIGNOFF command when the initial program ends, the system executes the menu, if any, specified in parameter INLMNU. Thus, if the default value MAIN were given for INLMNU and program SYSLIB/ICUSERON were to end without signing the user off, the system would present the main menu. When *SIGNOFF is the value for INLMNU, OS/400 signs the user off the system.

The CURLIB, INLPGM, and INLMNU parameters are significant to security because users can modify their value at sign-on. Users can also execute OS/400 commands from the command line provided on AS/400 menus. Obviously, allowing all users these capabilities is not a good idea from a security point of view, and this is where the LMTCPB parameter enters the picture. LMTCPB controls the user's ability to

• define (using the CHGUSRPRF command) or change (at sign-on) his own initial program,
• define (using the CHGUSRPRF command) or change (at sign-on) his own initial menu,
• define (using the CHGUSRPRF command) or change (at sign-on) his own current library,
• define (using the CHGUSRPRF command) or change (at sign-on) his own attention key program,
• execute OS/400 or user-defined commands from the command line on AS/400 native menus.

Production systems usually enforce LMTCPB(*YES) for most user profiles. The profiles that typically need LMTCPB(*NO) are MIS personnel who frequently use the command line from OS/400 menus. These user profiles can still be secured from sensitive data using resource security. Although you could specify LMTCPB(*PARTIAL) for those MIS personnel and thus ensure that they cannot change their initial program, they could still change their initial menu, which would be executed at the conclusion of the initial program.

System Value Overrides

DSPSGNINF (Display Sign-on Information)

PWDEXPITV (Password Expiration Interval)

LMTDEVSSN (Limit Device Sessions)

The system values QDSPSGNINF, QPWDEXPITV, and QLMTDEVSSN can be overridden through user profile parameters that control these functions.

You'll notice that each of these parameters has a default value of *SYSVAL. The default lets the system value control these functions. To override the system values, specify the desired values in the user profile parameters. The available choices are the same as those for the system values themselves.

Group Profiles

GRPPRF (Group Profile)

OWNER (Owner)

GRPAUT (Group Authority)

All the parameters discussed to this point are used to define profiles for individual users. The GRPPRF, OWNER, and GRPAUT parameters let you associate an individual with a group of user profiles via a group profile. When you authorize a group profile to objects on the system, the authorization applies to all profiles in the group.

How is this accomplished? You create a user profile for the group. The group profile should specify PASSWORD(*NONE) to prevent it from actually being used to sign on to the system -- all members of the group should sign on using their own individual profiles. For instance, you might create a profile called DEVPGMR to be the group profile for your programming staff. Then for each user profile belonging to a member of the staff, use the CHGUSRPRF command and the GRPPRF, OWNER, and GRPAUT parameters to place them in the DEVPGMR group.

The GRPPRF parameter names the group profile with which this user profile will be associated. If you create the group profile DEVPGMR, you would specify DEVPGMR as the GRPPRF value for the user profiles you put into that group.

The OWNER parameter specifies who owns the objects created by the group profile. The parameter value determines whether the user profile or the group profile will own the objects created by profiles that belong to the group. There is an advantage to having the group profile own all objects created by its constituent user profiles. When the group profile owns the objects, then every member of the group has *ALL authority to the objects. This is helpful, for instance, in a programming environment where more than one programmer works on the same projects. However, there is a way to provide authority to group members without giving them *ALL authority. If you specify OWNER(*USRPRF), individual user profiles own the objects they create. If a user profile owns an object, the group profile and other members in the group have only the authority specified in the GRPAUT parameter to the object.

The GRPAUT parameter specifies the authority to be granted to the group profile and to members of the group when *USRPRF is specified as the owner of the objects created. Valid values are *ALL, *CHANGE, *USE, *EXCLUDE, and *NONE. The first four of these values are authority classes, each of which represents a set of specific object and data authorities that will be granted; these values are discussed in detail in Chapter 4 as part of the discussion of specific authorities. If you specify one of the authority class values for the GRPAUT parameter, the individual user profile that creates an object owns it, and the other members of the group, including the group profile, have the specified set of authorities to the object.

*NONE is the value required when *GRPPRF is specified as the owner of objects created by the user. Because the group profile automatically owns the object, all members of the group will share that authority.

JOBD (Job Description)

The JOBD parameter on the CRTUSRPRF command determines the job description associated with the user profile. The job description specifies a set of attributes that determine how the system will process the job. Not only is the job description you specify used when the user profile submits a batch job to the system, but values in the job description determine the attributes of the user profile's workstation session. For instance, the initial library list that you specify for the job description becomes the user portion of the library list for the workstation session. If you don't specify a particular job description for the user profile on the JOBD parameter, the system defaults to JOBD(QDFTJOBD), an IBM-supplied job description that uses the QUSRLIBL system value to determine the user portion of the library list. The JOBD parameter does not affect any other portion of the library list. After the user profile signs on, the initial program can manipulate the library list.

One way to manage the user portion of the library list is to use QUSRLIBL to establish all user libraries. Then when someone signs on to the system, QUSRLIBL supplies all possible libraries, and users can always find the programs and data they need. However, this approach disregards security because it lets all users access all libraries, even those they don't need.

Another approach to setting up user libraries is to create a job description for each user type on the system. Then when you create the user profile, you can specify the appropriate job description for the JOBD parameter, and that job description's library list becomes the user library list when that profile signs on to the system.

The approach I recommend is to specify only general-purpose user libraries in QUSRLIBL. These libraries should contain only general utility programs (e.g., date routines, extended math functions, a random number generator). Each profile's initial program should then add only the application libraries needed by that particular user profile. You can use department name or some other trigger kept in a database file to determine library need.

SPCENV (Special Environment)

CRTUSRPRF's SPCENV parameter determines which operating environment the user profile is in after signing on. The values for SPCENV are *SYSVAL, *36, or *NONE. The value *SYSVAL indicates that the system value QSPCENV will be referenced to retrieve the operating environment. If you specify *S36, the user profile will enter the S/36 environment at sign-on. If you specify *NONE, the user profile will be in the native environment at sign-on and the user will have to enter either a STRS36E or CALL QCL command to enter the S/36 or S/38 environment.

Message Handling

MSGQ (Message queue)

DLVRY (Delivery)

SEV (Severity code filter)

When you create a user profile, the system automatically creates a message queue by the same name in library QUSRSYS. The user receives job completion messages, system messages, and messages from other system users via this message queue. Three CRTUSRPRF parameters relate to handling user messages. The MSGQ parameter specifies the message queue for the user. Except in very unusual circumstances, you should use the default value (*USRPRF) for this parameter. If you keep the message queue name the same as the user profile name, system operators and other users can more easily remember the message queue name when sending messages.

The DLVRY parameter specifies how the system should deliver messages to the user. The value *BREAK specifies that the message will interrupt the user's job upon arrival. This interruption may annoy users, but it does help to ensure that they notice messages. The value *HOLD causes the queue to hold messages until a user or program requests them. The value *NOTIFY specifies that the system will notify the job of a message by sounding the alarm and displaying the message-waiting light. Users can then view messages at their convenience. The value *DFT specifies that the system will answer with the default reply any message that requires a response; information messages are ignored.

The last parameter of the message group, SEV, specifies the lowest severity code of a message that the system will deliver when the message queue is in *BREAK or *NOTIFY mode. Messages of lower severity are delivered to the user profile's message queue but do not sound the alarm or turn on the message-waiting light. The default severity code is 00, meaning that the user will receive all messages. You should usually leave the SEV value at 00. But if you do not want certain users, because of their operational responsibilities, for instance, to be bothered by a lot of low-severity messages, you can assign another value (up to 99).

Printed Output Handling

PRTDEV (Print Device)

OUTQ (Output Queue)

The PRTDEV and OUTQ parameters are important to a basic understanding of directing printed output on the AS/400. If the user does not specifically direct a particular spooled output file to an output queue or device via an override statement (i.e., with an OVRPRTF (Override with Printer File) command; the S/36 environment procedure statements PRINT or SET; the OS/400 CHGJOB (Change Job) command; or by naming a specific output queue in a job description or print file), the system directs printed output according to the values of these two parameters.

PRTDEV specifies the name of the printer to which output is directed. This might be an actual printer name or the default value of *WRKSTN that instructs the system to get the name of the printer from the workstation device description. Although PRTDEV refers to a specific device, an output queue with the same name as the device specified for PRTDEV must exist on the system. If the device specified does not exist (and thus no output queue exists for that device), and if no output queue is specified in the OUTQ parameter of the user profile, then spooled output is sent to the default system printer specified in the system value QPRTDEV. If the value of PRTDEV is *SYSVAL, output also goes to the default system printer.

The OUTQ parameter specifies the qualified name of the output queue the profile will use. Here again the default value of *WRKSTN instructs the system to get the name of the output queue from the workstation device description. The OUTQ parameter takes precedence over the PRTDEV parameter. In other words, if the OUTQ parameter contains the name of a valid output queue (or *WRKSTN refers to an actual output queue), the system ignores the parameter PRTDEV for this user profile and places into the specified output queue any printed output not specifically directed (via an OVRPRTF or CHGJOB command during job execution) to another output queue or printer. When the OUTQ parameter has the value *DEV, the printed output file is placed on the output queue named in the DEV attribute of the current printer file (this attribute is determined by the DEV parameter of the CRTPRTF (Create Printer File), CHGPRTF (Change Printer File), or OVRPRTF (Override Printer File) command).

I follow two basic rules to determine who is on the system and to direct printed output. First, I use the user profile to determine who is on the system and the resources (e.g., libraries, menus, programs, authority) that user needs. Regardless of where users sign on to the system, they need to see their own menus, work with their usual objects, and have the same authority they always do. Those resources relate directly to the user's function. Second, I don't direct spooled output by user profile, but by the workstation being used. If a user signs on to a terminal in another department because his or her workstation is broken, spooled output should print according to the user's location. These two rules are good standards for setting up your system, yet they give you the flexibility to handle special cases, such as sending output to a printer that can handle a special form.

Documenting User Profiles

TEXT (Text Description)

The last parameter we will look at on the CRTUSRPRF command is TEXT. TEXT gives you 50 characters in which to meaningfully describe the user profile. The information you include and its format should be consistent for each user profile to ensure readability and usability. You can retrieve, print, or display this text to identify who requests a report or uses a program.

Before you actually create any user profiles, consider each parameter and develop a plan to best use it. Once you determine your company's needs, devise standards for creating your user profiles. Figure 3.5 creates a sample user profile for an order-entry clerk at branch location 01. Notice that I specified an output queue for the user profile in spite of my rule that the user's location at sign-on should control spooled output. I specified the output queue in this example so the directory will know where to send output when the user is using directory functions such as E-mail, network spooled files, or network messages. With minor changes in the user profile name, output queue, and text, I could use the same code to create user profiles for all order-entry clerks.

Before you create your user profiles, it helps to chart the various profile types and the parameter values you will use to create them. Figure 3.6 is a sample table that lists values you could use if your company had order entry, inventory control, accounting, purchasing, MIS operations, and MIS programming departments. A table such as this serves as part of your security strategy and as a reference document for creating user profiles.

Maintaining User Profiles

After you set up your user profiles, you will need to maintain them as users come and go or as their responsibilities change. You can change a user profile with the CHGUSRPRF (Change User Profile) command. As with CRTUSRPRF, you must have *SECADM special authority to use CHGUSRPRF. The CHGUSRPRF command is the same as the CRTUSRPRF command, except that the CHGUSRPRF command does not have an AUT (authority) parameter, and the parameter default values for CHGUSRPRF are the parameter values you assigned when you executed the CRTUSRPRF command.

Typically, you might employ CHGUSRPRF when a user forgets a password. Because the system won't display a password, you would need to use CHGUSRPRF to change the forgetful user's password temporarily and then require the user to choose a new password at the next sign-on. To accomplish this, execute the command

CHGUSRPRF USRPRF(profile_name) PASSWORD(password) PWDEXP(*YES)  

This command resets the password to a known value and sets the password expiration to *YES, so that the system prompts the user to choose a new secret password at the next sign-on.

It is not uncommon to delete a user profile. When an employee leaves, the security administrator should promptly remove the employee's user profile from the system, or at least set the password to *NONE. To delete a user profile, use the DLTUSRPRF (Delete User Profile) command. This command has been much improved since its introduction in S/38 CPF. Many S/38 shops share a mutual problem when a user leaves, especially an MIS staff member: The user profile cannot be deleted if it owns any objects. If there are no automated methods for deleting or transferring objects owned by the former user profile, this cleanup process can take several hours.

The OS/400 version of the DLTUSRPRF command has a parameter OWNOBJOPT that tells the system how to handle any objects owned by the user profile you asked to delete. The system will not delete a profile that owns objects if you specify the default *NODLT for OWNOBJOPT. However, you can specify *DLT to delete those objects. Avoid the option *DLT unless you have used the DSPUSRPRF (Display User Profile) command to identify the owned objects and are sure you want to delete them. Remember: A backup of these objects is an easy way to cover yourself in case of error.

The remaining option for OWNOBJOPT is *CHGOWN, which instructs the system to transfer ownership of any objects owned by the profile you want to delete. You must specify the new owner of these objects in the second part of this parameter. For instance, if a programmer owns some objects privately and you want to delete that programmer's profile, you might specify

DLTUSRPRF USRPRF(profile_name) OWNOBJOPT(*CHGOWN MIS)

to transfer ownership of the objects to your MIS group profile.

If you write a program to help you maintain user profiles, you may find the RTVUSRPRF (Retrieve User Profile) command helpful. You can use RTVUSRPRF to retrieve into a CL variable one or more of the parameter values associated with a user profile. (See IBM's AS/400 Programming: Control Language Reference (SC41-0030) for details about this command's parameters. You can also prompt this command on your screen and then use the help text to learn more about each variable you can retrieve.)

Figure 3.7 shows the prompt screen for RTVUSRPRF. The prompt lists the length of each variable next to the parameter whose value is retrieved in that variable. This command is valid only within a CL program because the parameters actually return variables to the program, and return variables cannot be accepted when you enter a command from an interactive command line. You might use this command to retrieve the user's actual user profile name for testing. For example, the code segment in Figure 3.8 retrieves the current user profile name into the variable &USRPRF and tests the first character to see whether or not it is the letter B. When this condition is met, the code might display a certain menu. Or you could use the test to determine what application libraries to put in the user's library list, based on user location or department.

Flexibility: The CRTUSR Command

One option for retaining certain information about past and current user profiles is to use a database file for that purpose. By modifying this database file, you can also use it to automate user profile creation and establish a session when a user signs on to the system.

Figure 3.9 shows sample Data Description Specifications for file USRINF. You can use the information in this file not only for audit purposes, but to track authorized users and to establish initial values for programs (such as providing the correct branch location number in an inquiry program) or to identify the user requesting printed output (the name can then be placed on the report). The USRPRF and AUTEDT fields together serve as the primary key. As a result, you can maintain one or more records for every system user profile.

Figure 3.10 shows the source for a user-written CRTUSR command. The command processing program (CPP), CRTUSRCL, actually creates the user profile on the AS/400 and calls RPG program CRTUSRR to write a record to file USRINF. The CPP (Figure 3.11 — 32 KB) begins by deriving the user's initials from the user's name and putting them into variable &INITS. Then the CPP uses variable &INITS and the variables &LEVEL (user's company level) and &LOCATION to create the user profile name, which is stored in variable &USRPRF. For example, if Jane P. Doe is a branch employee at the Kalamazoo branch office (office number 12), her user profile name becomes B12JPD. For regional employee Jack J. Jones at the Sacramento (20) office, the user profile name is R20JJJ.

After concatenating the user profile name, the program concatenates the user's first name, middle initial, and last name and stores the value in variable &NAME, which will be used to create the TEXT parameter for the CRTUSRPRF command. The CPP sets up the TEXT parameter by combining the values from variables &LEVEL (branch, regional, or corporate), &LOCATION, and &NAME, thus providing consistent text for every user profile and making it easy to identify one particular user profile from a list.

The next three variables -- &GRPPRF, &LMTCPB, and &USRCLS -- are all determined from the user's department. If the user works in the MIS department, the group profile becomes MIS and variable &LMTCPB is assigned the value *NO. The program further determines an MIS user's class by testing whether the user works in operations (OP) or on the programming staff (PG) and then assigning the appropriate value (*SYSOPR or *PGMR) to variable &USRCLS. The CPP assigns non-MIS personnel to the USERS group profile and to the *USER user class.

Next, if &DEPT is equal to OP or PG, the CPP checks whether or not a personal library and output queue already exist for the user profile being created. If these objects do not exist, the CPP creates them and transfers their ownership to the group profile.

The program then creates the user profile by executing the CRTUSRPRF command, substituting the variables established in the program. The CPP requires the user to have *SECADM special authority and authority to the CRTUSRPRF command. If the user does not have these authorities, the program must be compiled with the attribute USRPRF(*OWNER) to adopt the authority of the owner, who does have the proper authorities.

If an error occurs during the execution of the CRTUSRPRF command, the global message monitor passes control to label DIAG. When the command is successful, the program calls the RPG program CRTUSRR (Figure 3.12), which establishes the correct date for variable AUTBDT (authorization beginning date) and writes the record to disk. If an error occurs on the WRITE statement, the program sets field OFLAG (output flag) to 1, and control returns to the CPP. The system sends the appropriate message to the requester based on the value of the field &FLAG. Then the diagnostic routine reads any messages from the program queue and sends them to the requester, and the program ends.

The CRTUSR command ensures that you create each user profile similarly, according to shop standards. You can create your own CHGUSR and DLTUSR commands and programs to maintain the records in USRINF and to change or delete the user profile on the system. Keep in mind there will be exceptions you will have to handle individually. You should usually use these commands to create and maintain user profiles. Only in an exceptional case should you directly use the OS/400-supplied commands.

Making User Profiles Work for You

Whether you create user profiles with CL commands or employ user-written commands, it is important to plan. Careful planning saves literally hundreds of hours during the system's lifetime. If you maintain a database file like USRINF with the appropriate user information, it provides essential historical data for auditing and a way to extract significant information about the user profile during a workstation session. You will have a consistent method for creating and maintaining user profiles, and you can easily train others to create and maintain user profiles for their departments. Moreover, you will be able to retrieve information from file USRINF via a high-level language program; and you can use that information in applications to establish the work environment, library list, and initial menu for a user profile.

When you set up your AS/400, take the time to examine your current standards for establishing user profiles, and make your user profiles work for you!