AS/400-iSeries Starter Kit

With the AS/400, IBM has tried to graft the S/36's ease of use onto the S/38's integrated database and productivity features. In many respects, Big Blue has succeeded -- the AS/400 provides extensive help text, highly developed menu functions, on-line education, and electronic customer support. But the machine's friendliness stops short of "plug and go" installation, especially for shops converting from a non-IBM system or migrating from an IBM system other than a S/38.

Even S/38 migration is not completely plug and go, although the AS/400 has inherited many S/38 characteristics: a complex structure of system objects used to support security, work environment, performance tuning, backup, recovery, and other functions. These objects let you configure a finely tuned and productive machine, but they do not readily lend themselves to education on the fly. As a result, the AS/400 requires thought, foresight, planning, and preparation for a successful installation.

Believe me, I know. I have experienced the AS/400 planning and installation process as both a customer and a vendor, and I'd like to share what I've learned by suggesting a step-by-step approach for planning, installing, and configuring your AS/400. First I discuss the steps you can and should take before your system arrives. In subsequent chapters, I take you through your first session on the machine, address how to establish your work environment, and show you how to customize your system.

I have outlined the installation process in the AS/400 setup checklist in Figure 1.1. You might want to use this checklist as the cover page to a notebook you could put together to keep track of your AS/400 installation.

Before You Install Your System

The first step in implementing anything complex -- especially a computer system -- is thorough planning. A successful AS/400 installation begins long before your system rolls in the door. The first section of the setup checklist in Figure 1.1 lists tasks you should complete before you install your system -- preferably even before it arrives. These items may seem like a great deal of work before you ever see your system, but this work will save you and your company time and trouble when you finally begin installing, configuring, securing, and using your new system. Let's look at each item in this section of the checklist individually.

Develop an Installation Plan

A good installation plan serves as a road map. It guides you and your staff and keeps you focused on the work ahead.

Figure 1.2 shows a sample installation plan that lists installation details and lets you track the schedule and identify the responsible person for each task. [Although the installation plan includes important considerations about the physical installation -- e.g., electrical, space, and cooling requirements -- these requirements are well documented in IBM manuals, and I do not discuss them here. For details about physical installation, refer to the AS/400 Physical Planning Guide -- Version 2 (GA41-0001), the AS/400 Physical Planning Guide and Reference -- Version 2 (GA41-9571), the AS/400 Migrating from S/36 Planning Guide -- Version 2 (GC41-9623), or the AS/400 Migrating from S/38 Planning Guide -- Version 2 (GC41-9624).] An overall installation plan helps you put the necessary steps for a successful AS/400 setup into writing and tailor them to your organization's specific needs. The plan also helps you identify and involve the right people and gives you a schedule to work with.

Identifying and involving the right people is critical to creating an atmosphere that assures a smooth transition to your new system. Management must commit itself to the installation process and must understand and agree to the project's priority. Other pending MIS projects should be examined and assigned a priority based on staff availability in light of the AS/400's installation schedule. Management and the departments you serve must understand and agree on these scheduling changes.

On the MIS side, your staff must commit to learning about the AS/400 in preparation for installation and migration. Your staff must also commit itself to completing all assigned tasks, many of which (e.g., time spent verifying the migration or conversion of programs and data) may require extra hours.

The time frame outlined in your installation plan will probably change as the delivery date nears. But even as the schedule changes and is refined, it provides a frame of reference for the total time you need to install, configure, and migrate to the new system.

You must also answer an important question as part of your plan: Can you run the old and new systems parallel for a period of time? If you can run parallel, you can greatly reduce the time needed for the installation process. Running parallel also reduces the risk factor involved in your migration and conversion process.

Plan Education

I can hear you now: "We don't have time for classes! We're too busy to commit our people to any education." I'm sure this will be your response to the suggestion that you plan for training now. I'm also sure that those statements are absolutely true. But education is a vital part of a successful AS/400 installation. Realistically, then, you must schedule key personnel for education.

What key groups of personnel need training? The end users, for one. Their education should focus on PC Support and on the AS/400 Office products they will work with. But you and your operations and programming staff will also need some training. If you move to an AS/400 from a S/36, you will see the familiar sign-on screen, the friendly menu format, and the extensive help text associated with the S/36. But the AS/400 also has some unfamiliar territory: You must learn new security concepts, how to modify your work environment to improve performance, and how to control printer output. Training in relational database design and implementation will improve the applications you migrate or write, and learning something about the AS/400's fast-path commands will help you feel more at home and productive in the native environment.

If you are moving from a S/38, you will recognize the fast-path commands (with some minor changes), the command entry display (once you find it), the relational database, the work environment objects, and the security concepts. However, you will need additional knowledge about how to implement new security options, the "current library," the Programming Development Manager (PDM), available menus, and other new concepts. You'll also have to learn about the new program products and operations on the AS/400.

If all this sounds complicated, then you're getting the point: You need system-specific education for a smooth transition to the AS/400.

Where can you get such education? Begin by asking your vendor for educational offerings. If you buy from a third party, training support will vary from vendor to vendor. You can also arrange to attend courses at an IBM Guided Learning Center.

Another place to get AS/400 education is on the AS/400 itself. To supplement vendor training support, each AS/400 comes with Tutorial System Support (TSS) installed. This on-line tutorial help provides self-paced lessons for programmers, clerical workers, executives, systems analysts, and others (Figure 1.3 lists the various audience paths available by using TSS lessons). You may be able to begin TSS training before your AS/400 arrives by working through your hardware or software vendor.

You can also find a variety of educational offerings in seminars, automated courses, study guides, one-on-one training sessions, and classroom training courses. The key to successful education is matching education to the user. Matching ensures productive use of the time employees spend away from their daily duties.

Prepare Users for Visual and Operational Differences

It would be nice if you could assure all your users that they will not find anything different when they sign on to the AS/400 for the first time, but you probably can't. You would be wise to give some thought to the visual and operational differences and explain them to your users in advance. For example, S/38 users used to a single-level sign-on (just entering a password) may be surprised (and unhappy) to find they must sign on to the AS/400 with both a user profile name and a password. Consequently, you could find yourself waist deep in phone calls and complaints on your first day of operation unless you tell your users what to expect. A communication describing the user profile and password and their roles on the system would go a long way toward smoothing the transition for such users.

You may encounter another potential problem in the panel interface differences between your former system and the SAA-compliant AS/400. Command key differences, print-control screen differences, help screen differences, and others may cause some initial concern and confusion among your users. The Operation Assistant (OA) interface provided for end-user interaction with the AS/400 is friendly, but telling your users about these differences before installation will prepare them, head off many complaints, and protect your position.

Develop a Migration Plan

The next step in pre-installation planning is to develop a migration or conversion plan. Converted applications almost always make better use of system resources than migrated applications, but you can successfully operate in the AS/400's S/36 or S/38 environment for as long as you need to. Although your goal ultimately should be to "go native," most shops choose to migrate first. Migration eases the transition considerably, particularly for S/36 shops, and allows conversion to proceed at a more leisurely pace. For this reason, I recommend most shops migrate first and then convert as time permits.

Even if you buy software written for the AS/400 and use your software vendor's expertise to migrate the data, you must still migrate user profiles, your system configuration, and any custom software or utilities on your system. A migration plan organizes this process and, as you carry out the plan, helps you become familiar with the AS/400 and the new features it offers.

Figure 1.4 shows a sample migration plan. The key to a successful S/36 migration is knowing what will migrate and what won't. The S/36 Migration Aid software identifies objects that will not migrate to the S/36 environment and keeps audit trails of what has and has not been migrated. The sooner you know what will not migrate, the sooner you can start developing AS/400 solutions for those objects.

One common problem in S/36 migration is expecting all applications to run better in the AS/400's S/36 environment. Unfortunately, the AS/400 cannot cure bad software. Badly written software that runs poorly on your S/36 will still run poorly in the AS/400's S/36 environment. In fact, the AS/400 may accentuate poor performance. IBM has made a commitment to maintain the S/36 environment on the AS/400. Nevertheless, you can -- and should -- gradually convert from the S/36 environment as you find applications that conversion will improve.

Successful S/38 migration also begins with the Migration Aid software. As with the S/36, the Migration Aid identifies the objects and products that will not migrate and helps keep track of the migration process. The key to understanding the S/38 migration process is knowing that all S/38 objects are "object compatible" with the AS/400. Migration is thus a relatively simple process in which you save the objects from the S/38 and restore them onto the AS/400. When a S/38 object is restored onto the AS/400, the system attaches the suffix "38" to the object attribute, as shown in Figure 1.5. The AS/400 uses the suffix to identify the proper environment for the object. For example, when the AS/400 executes a CL program (e.g., SAMPLECL in Figure 1.5), the system uses S/38 environment commands in response to the suffix on the object attribute. If you were to remove the suffix and attempt to recompile the CL program, you would get errors on any S/38 commands that do not exist in the same form on the AS/400 (e.g., DSPOUTQ, DSPACTJOB).

Whether you migrate from a S/36 or a S/38, running parallel for a while greatly reduces the risk involved. You can migrate your applications in stages, testing and verifying each program as you go. If you can't run parallel, you must complete your migration process on the first try, a much trickier proposition.
In this case, I recommend that you seek an experienced outside source for assistance in the migration and conversion process.

If you decide to begin conversion immediately, be sure you know what you're getting into. Depending on your current system, conversion could involve one week to six months of work for your staff. With S/36 conversions, for example, your staff must work through a complete education plan before even beginning to tackle the conversion process. Again, a good outside consultant, used in a way that provides educational benefits for your staff, could be an immense help. True, you could simply pay a consultant to convert your database and programs for you, but that approach doesn't educate your staff about the new system.

Also, let me offer you a warning: If you plan to replace your existing system and completely remove it before installing your AS/400, you are absolutely asking for trouble! If you find yourself forced into such a scenario, get help. Hire a consultant who has successfully migrated systems to the AS/400.

Develop a Security Plan

With your migration plan in writing, you are ready to tackle a security plan. Imagine for a moment that you have your AS/400 fully installed and smoothly running -- and that you haven't altered the security settings yet. In this case, the system is at security level 10, and anyone who turns on a workstation, receives a sign-on screen, and presses Enter has full access to all system objects and functions. Obviously, you need a security plan, and you need to implement it as soon as possible after your system is installed.

System Security Level

Figure 1.6 shows a basic security plan. The first and most significant step in planning your security is deciding what level you need. The AS/400 provides five levels of security: 10, 20, 30, 40, and 50.

Security Level 10 -- As I implied, system security level 10 might more aptly be called security level zero, or "physical security only": At level 10, the physical security measures you take, such as locking the door to the computer room, are all you have. If a user has access to a workstation with a sign-on screen, (s)he can simply press Enter, and the system will create a user profile for the session and allow the user to proceed. The profile the system creates in this case has *ALLOBJ (all object) special authority, which is sufficient for the user to modify or delete any object on the system.

Although user profiles are not required at level 10, you could still create and assign them and ask each user to type in her assigned user profile at sign-on. You could then tailor the user profiles to have the appropriate special authorities -- you could even grant or revoke authorities to objects. But there is no way to enforce the use of those assigned profiles, and thus no way to enforce restricted special authorities or actual resource security. Level 10 provides no security.

Security Level 20 -- Security level 20 adds password security. At level 20, a user must have a user profile and a valid password to gain access to the system. Level 20 institutes minimum security by requiring that users know a user profile and password, thus deterring unauthorized access. However, as with level 10, the default special authorities for each user class include *ALLOBJ special authority, and therefore resource security is, by default, bypassed.

Although you can tailor the user profile, the inherent weakness of level 20 remains: the fact that, by default, resource security is not implemented. The *ALLOBJ special authority assigned by default to every user profile bypasses any form of resource security. To implement resource security at level 20, you must remove the *ALLOBJ special authority from any profiles that do not absolutely require it (only the security officer and security administrator need *ALLOBJ special authority). You must then remember to remove this special authority every time you create a new user profile. This method of systematically removing *ALLOBJ authority is pointless since, by default, level 30 security does this for you. On a production system, you must be able to explicitly authorize or deny user authority to specific objects. Therefore, level 20 security is inadequate in the initial configuration, requiring you to make significant changes to mimic what level 30 provides automatically.

Security Level 30 -- Level 30 by default supports resource security (users do not receive *ALLOBJ authority by default). Resource security allows objects to be accessed only by users who have authority to them. The authority to work with, create, modify, or delete objects must be either specifically granted or received as a result of existing default public authority.

All production systems should be set at security level 30 or higher (levels 40 or 50). Production machines require resource security to effectively safeguard corporate data, programs, and other production objects and to prevent unintentional data loss or modification.

Security Level 40 -- The need for level 40 security centers on a security gap on the S/38 that the AS/400 inherited. This gap allowed languages that could manipulate Machine Interface (MI) objects (i.e., MI itself, C/400, and Pascal) to access objects to which the user was not authorized by stealing an authorized pointer from an unsecured object. In other words, an MI program could access an unsecured object and use its authorized pointer as a passkey to an unauthorized object.

To level 30's resource security, level 40 adds operating system integrity security. System integrity security strengthens level 30 security in four ways:

• By providing program states and object domains

• By preventing use of restricted MI instructions

• By validating job initiation authority

• By preventing restoration of invalid or modified programs

You might wonder what level 40 buys you. In truth, most systems today could run at level 30 and face no significant problems. But in the future, as you purchase more third-party software and as more systems participate in networks, operating-system integrity will become more important.

Level 40 provides the security necessary to prevent a vendor or individual from creating or restoring programs on your system that might threaten system integrity at the MI level, thus ensuring an additional level of confidence when you work with products created by outside sources. Yet, if the need arises to create a program that infringes upon system integrity security, you can explicitly change the security level to 30. The advantage of using level 40 is that you control that decision.

During installation, set your system level to 30, and monitor the security audit journal for violations that level 40 guards against. If you find none, go to level 40 security. If violations are logged, review them to determine their source. Some packaged software (e.g., some system tools) will require access to restricted MI instructions and will fail. In these cases, you can ask the vendor when his product will be compatible with level 40 and decide what to do based on his response.

Security Level 50 -- IBM introduced security level 50 in OS/400 Version 2, Release 3. The primary purpose of security level 50 is to enable OS/400 to comply with the Department of Defense C2 security requirements. IBM added specific features into OS/400 to comply with DOD C2 security as well as to further enhance the system integrity security introduced in level 40. In addition to all the security features/functions found at all prior OS/400 security levels (e.g., 30, 40), level 50 adds

• Restricting user domain object types (*USRSPC, *USRIDX, and *USRQ)

• Validating parameters

• Restricting message handling between user and system state programs

• Preventing modification of internal control blocks

• Making the QTEMP library a temporary object

If your shop requires DOD C2 compliance, you can get more information concerning security level 50 and other OS/400 security features (e.g., auditing capabilities) in two new AS/400 publications: Guide to Enabling C2 Security (SC41-0103) and A Complete Guide to AS/400 Security and Auditing: Including C2, Cryptography, Communications, and PC Implementation (GG24-4200).

Password Format Rules

Your next task in security planning is to determine rules for passwords. In other words, what format restrictions should you have for passwords? Without format requirements, you are likely to end up with passwords such as "joe," "sue," "xxx," and "12345." But are these passwords secret? Will they safeguard your system?

You can strengthen your security plan's foundation by instituting some rules that encourage users to create passwords that are secret, hard to guess, and regularly changed. However, you also must remember that sometimes "hard to guess" translates into "hard to remember" -- and then users simply write down their passwords so they won't forget. The following password rules will help establish a good starting point for controlling password formats:

Rule 1 is that passwords must be a minimum of seven characters and a maximum of 10 characters. This rule deters users who lack the energy to think past three characters when conjuring up that secret, unguessable password.

Rule 2 builds on Rule 1: Passwords must have at least one digit. This rule makes passwords become more than just a familiar name, word, or place.

Rule 3 can deter those who think they can remember only one or two characters and thus make their password something like "XXXXX6" or "X1X." Rule 3 simply states that passwords cannot use the same character more than once. On a similar note, Rule 4 states that passwords cannot use adjacent digits. This prevents users from creating passwords such as "1111," "1234," or even using their social security number.

With these four rules in place, you can feel confident that only sound passwords will be used on the system. But you can enhance your password security still further with one additional rule. Rule 5 says that passwords should be assigned a time frame for expiration. You can set this time frame to allow a password to remain effective for from one to 366 days, thus ensuring that users change their passwords regularly.

Passwords are a part of user profiles, which you will create to define the users to the system after the AS/400 is installed. Laying the groundwork for user profiles is the next concern of your security plan.

Identifying System Users

Before you install the new machine, you should identify the people who will use the system. Obtain each user's full name and department and the basic applications the user will require on the system. Some users, such as operators and programmers, will need to control jobs and execute save/restore functions on the system. Other users, such as accounts receivable personnel, only need to manipulate spooled files and execute applications from menus.

Once you identify the users and determine which system functions they need access to, you can assign each user to one of the following classes (the authorities discussed with each class are granted when the system security level is set to 30 or 40):

• SECOFR (security officer) grants the user all authorities: all object, security administrator, save system, job control, service, spool control, and audit authorities (each of these special authorities is explained below).

• SECADM (security administrator) grants security administrator, save system, and job control authorities.

• PGMR (programmer) grants save system and job control authorities.

• SYSOPR (system operator) grants save system and job control authorities.

• USER (user) grants no special authorities.

Your MIS staff members normally will have either the SYSOPR or the PGMR user class. Your end users should all reside in the USER user class. The USER class carries no special authorities, which is appropriate for most users. They can work within their own job and work with their own spooled files.

One rule of thumb when assigning classes is that you should never set up your system such that a user performs regular work with SECOFR authority. The AS/400 has a special QSECOFR profile; when the security officer must perform a duty, the person responsible should sign on using the QSECOFR profile to perform the needed task. Using security officer authority to perform normal work is like playing with a loaded gun. As you plan user profiles, you also need to consider the special authorities you want to grant to the user profiles and user classes. Special authorities allow users to perform certain system functions; without special authority, the functions are unavailable to the user. The AS/400 provides six special authorities:

• ALLOBJ (all object authority) lets users access any system object. This authority alone, however, does not allow the users to create, modify, or delete user profiles.

• SECADM (security administrator authority) allows users to create and change user profiles.

• SAVSYS (save system authority) lets users save, restore, and free storage for all objects.

• JOBCTL (job control authority) allows users to change, display, hold, release, cancel, and clear all jobs on the system. The user can also control spooled files in output queues where OPRCTL(*YES) is specified.

• SERVICE (service authority) means users can perform functions from the System Service Tools, a group of executable programs used for various service functions (e.g., line traces and run diagnostics).

• SPLCTL (spool control authority) allows users to delete, display, hold, and release their own spooled files and spooled files owned by other users.

• AUDIT (audit authority) allows users to start and stop security auditing as well as control security auditing characteristics.

When you use security level 30, 40, or 50, the AS/400 automatically assigns special authorities based on user class as shown in Figure 1.7. When you create user profiles, you can use the special authorities parameter to override the authorities granted by the user class, allowing you to tailor authorities as appropriate for specific users. For instance, a user profile might have a user class of SYSOPR, which grants the user special authorities for job control and save/restore functions. By entering only *SAVSYS for the special authorities parameter, you can instruct the system to grant only this special authority, ignoring the normal defaults for the *SYSOPR user class.

You must also plan specific authorities, which control the objects a user can work with (e.g., job descriptions, data files, programs, menus). Going through the remainder of the pre-installation security planning process -- checking your applications for security provisions -- will also help you decide which users need which specific authorities and help you finish laying the groundwork for user profiles on your new system.

Develop a Backup and Recovery Plan

Although it may seem premature to plan for backup and recovery on your as-yet-undelivered AS/400, I assure you it is not. First, you should not assume that the backup and recovery plan for your existing system will still work with the AS/400. Second, the AS/400 has a variety of powerful backup and recovery options that you may not be familiar with. Some of these options are difficult and time-consuming to install if you wait until you've migrated your applications and data to the new system.

Checksum is a case in point. The AS/400's single-level storage minimizes disk head contention and eliminates the need to track and manage the Volume Table of Contents. But single-level storage can also create recovery problems. Because single-level storage fragments objects randomly among all the system's disks, the loss of any one disk can result in damage to every object on the system.

After complete backup, checksum is your best protection against this weakness in single-level storage. With checksum, you configure disk units (i.e., one disk actuator arm and its associated storage) into checksum sets, with no more than one unit from each disk device in a single checksum set. Then, if a disk fails, the system can compare the data in the failed unit in each checksum set with the data in the other (intact) units and can reconstruct the data on the failed unit.

This description of how checksum works is (obviously) not complete, but should give you an idea of how valuable it can be. Because checksum installation on an installed system requires that you save your entire system and reload everything, don't pass up this opportunity to consider installing checksum when you install your new AS/400.

An auxiliary storage pool (ASP) is another of those features that are much easier to implement when you install your system rather than later. An ASP is a group of disk units. Your AS/400 will be delivered with only the system ASP (ASP 1) installed. Figure 1.8a shows auxiliary storage configured only as the system ASP. The system ASP holds all system programs and most user data.

You can customize your disk storage configuration by partitioning some auxiliary storage into one or more user ASPs (Figure 1.8b). Like checksum, user ASPs provide protection from disk failures, because you can segregate specific user data or backup data onto user ASPs. Thus, if you lose a disk unit in the system ASP, your restore time is reduced to a minimum time of restoring the operating system and the objects in the system ASP, while data residing in the user ASPs will be available without any restore. If you lose a disk unit in a user ASP, your restore time will include only the time it takes to restore the user data in that user ASP.

You can use user ASPs for journaling and to hold save files. Journaling automatically creates a separate copy of file changes as they occur, thus letting you recover every change made to journaled files up to the instant of the failure. If you have on-line data entry -- such as orders taken over the phone -- that lacks backup files for the data entered, you should strongly consider journaling as a part of your backup and recovery plan. Although you do not need user ASPs to implement journaling, they do make recovery (which is difficult under the best of circumstances) easier. If you do not journal to a user ASP, you should save your journal receivers (i.e., the objects that hold all file changes recorded by journaling) to media regularly and frequently.

User ASPs also protect save files from disk failures. A save file is a special type of physical file to which you can target your backup operation. Save files have two major advantages over backing up to media. The first is that you can back up unattended, since you don't have to change diskette magazines or tapes. The second advantage is that backing up to disk is much faster than backing up to tape or diskette. The major (and probably obvious) disadvantage is that save files require additional disk storage. Nevertheless, save files are worthwhile in many cases; and when they are, isolating save files in a user ASP provides that extra measure of protection.

User ASPs are required as part of the disk-mirroring feature the AS/400 offers. User data is placed on various user ASPs. Each ASP uses a set of mirrored disk drives. The mirroring protects the user data in the ASP, and the fact that ASPs are used protects the larger system from a complete loss due to any one single disk failure. While disk mirroring has a substantial initial investment for the additional disk drives, the protection offered is significant for companies that rely on providing 24-hour service.

One last option to consider is RAID protection. IBM and other AS/400 DASD vendors currently offer either RAID 1 or RAID 5 disk protection. RAID 1 is similar to OS/400's system mirroring option, except that the disk subsystem handles all the necessary read/write operations instead of OS/400. You duplicate each disk drive to protect against a single disk drive failure. If one disk fails, the system still has access to the mirrored disk.

RAID 5 protection is similar to OS/400's checksum; however, the disk subsystem handles all the read/write operations. RAID 5 stores parity information on additional disk space and uses that parity information to reconstruct the data in the event that one of the disks in a RAID 5 set fails.

The point of this discussion is that you need to plan ahead and decide which type of disk protection you will employ so you can be ready to implement your plan when the system is first delivered, when the disk drives are not yet full of information you would have to save before making any storage configuration changes.

For more information about save/restore, and an introduction to a working save/restore plan, see Chapters 15 and 16, "AS/400 Save and Restore Basics," and "Backup Without Downtime."

Establish Naming Conventions

Naming conventions vary greatly from one MIS department to the next. The conventions you choose should result in names that are syntactically correct and consistent, yet easily remembered and understood by end users and programmers alike. A good standard does more than simply help you name files, programs, and other objects; it also helps you efficiently locate and identify objects and devices on your system. If your naming conventions are in place before you install your system, they will help installation and migration go smoothly and quickly.

The naming convention you choose should be meaningful and should allow for growth of your enterprise. Let's look at an example:

• You have three locations for order entry: Orlando, Florida; Atlanta, Georgia; and Montgomery, Alabama.

• You have five order entry clerks at each location.

• You have one printer at each location.

You could let the AS/400 automatically configure all your workstations and printers, which would result in names such as W1, W2, and P1, or DSP02, DSP03, and PRT02. But, by configuring the devices yourself and assigning meaningful names, your devices can have names such as GADSP01, GADSP02, ALDSP01, ALDSP02, FLPRT01. Because these names contain a two-letter abbreviation for the state, they are more meaningful and useful than the names the AS/400 would assign automatically. But this convention would pose a problem if you had two offices in the same state. So instead, to allow for growth of the enterprise, you might incorporate the branch office number into the names, resulting in names such as C01DSP01 to identify a control unit for branch office 01, display station 01. Such a naming convention would help your operations personnel locate and control devices in multiple locations.

You will also need a standard for naming user profiles. There are those who believe that a user profile name should be as similar as possible to the name of the person to whom it belongs (e.g., WMADDEN, MJONES, MARYM, JOHNZ). This method can work well when there are only a few end users. Under such a strategy, only one profile is needed per user, which simplifies design and administration of the security system and lets operations personnel identify employees by their user profiles. The drawback to this method is that it results in profiles that are easily guessed and thus provides a door for unauthorized sign-ons, leaving only the password to guess. A friend of mine was bragging about his new LAN one evening and wanted to show me how it worked, but he did not know his user profile or password. We were sitting at his secretary's desk, so I asked him what her name was. Within one minute we were signed on using her first name as the profile and her initials as the password. Good guess? No. Bad profile and password.

Another opinion holds that user-profile names should be completely meaningless (e.g., SYS23431, Q83S@06Y7B, 2LR50M3ZT4) and should be maintained in some type of user information file. The use of meaningless names makes profiles difficult to guess and does not link the name to a department or location that might change as the employee moves in the company. The user information file documents security-related information such as the individual to whom the profile belongs and the department in which the user works. This method is the most secure; but it often meets with resistance from the users, who find their profiles difficult to remember.

A third approach is to use a naming standard that aids system administration. Under this strategy, each user profile name identifies the user's location and perhaps function in order to sharpen the ability to audit the system security plan. For instance, if you monitor the history log or use the security journal for auditing, this approach enables you to quickly identify users and the jobs they're doing.

To implement this strategy, your naming convention should incorporate the user's location or department and a unique identifier for the user's name. For example, if John Smith works as one of the order entry clerks at the Georgia location, you might assign one of the following profiles:

GAJSMITH In this profile, the first two letters represent the location (GA for Georgia), and the remainder consists of the first letter of the user's first name followed by as much of the last name as will fit in the remaining seven characters.

GAOEJES This example is similar, but the branch is followed by the department (OE) and the user's initials. This method provides more departmental information while reducing the unique name identifier to initials.

B12OEJES This example is identical to the second, but the Georgia branch is numbered (B12).

When profile names provide this type of information, programs in your system that supply user menus or functions can resolve them at run time based on location, department, or group. As a result, both your security plan and your initial program drivers can be dynamic, flexible, and easily maintained. In addition, auditing is more effective because you can easily spot departmental trends; and user profile organization and maintenance are enhanced by having a naming standard to follow. However, such profiles are less secure than meaningless profiles because they are easy to guess once someone understands the naming scheme. This leaves only the password to guess, thus rendering the system less secure.

As you will discover in Chapter 3, I also believe in maintaining user profiles in a user information file. Such a file makes it easy to maintain up-to-date user-profile information such as initial menus, initial values for programs (e.g., initial branch number, department number), and the user's full name formatted for use in outgoing invoices or order confirmations. When a user transfers to another location or moves to a new department, you should deactivate the old profile and assign a new one to maintain a security history. A user information file helps you keep what amounts to a user profile audit trail. Furthermore, your applications can retrieve information from the file and use it to establish the work environment, library list, and initial menu for a user.

A final consideration in choosing a naming convention for user profiles is whether or not your users will have access to multiple systems. If they will, you can simplify Display Station Passthrough functions by using the same name for each user's profile on all systems. To do this, you must consider any limitations the other systems in the network place on user profile names and apply those limitations in creating the user profiles for your system. For instance, another platform in your network may limit the number of characters allowed for user profile names. To allow your user profiles to be valid across the network, you will have to abide by that limitation.

You need to determine what user profile naming convention will work best for your environment. For the most secure environment, a "meaningless" profile name is best. User profiles that consist of the end user's name are the least secure and are often used in small shops where everyone knows (and is on good terms with) everyone else. A convention that incorporates the user's location and function is a compromise between security and system management and implementation that suits many shops.

What Next?

Okay, you have made it this far. You have planned and prepared, and then planned some more. You have planned education, scheduled classes, and started to prepare your users for the differences they will encounter with the AS/400. You have planned for migration, security, and backup and recovery, and you know how you will name the objects on your system. You feel ready to begin the installation. But after your vendor helps you install the hardware, how do you go about implementing all those carefully made plans? In the next chapter, I'll go into what happens once the power is on.