They say you can always count on two things: death and taxes. In the world of business, there is at least one other-an employee's resignation. With the growing popularity of the AS/400, the shortage of qualified AS/400 programmers (especially those with the skills needed to tackle the Y2K issue), and the frantic pace of AS/400 salaries, you can probably count on a sizeable number of your employees jumping ship to seek new jobs.

When the inevitable happens, you'll need to address many issues, including asking yourself how this employee's leaving impacts your systems, plans, and remaining personnel, as well as what steps you can take to ensure that you have not left yourself and your business open to holes and sabotage.

Your job is made slightly easier when it's a programmer who quits. A programmer's work can be more easily quantified than, say, someone's in R & D. There are certain things you will immediately need to learn and actions you will need to take both when he tenders his resignation and after he actually leaves. With that in mind, I would like to suggest some things you can do to ease the transition. Of course, this list will probably not be comprehensive enough for every shop, but it should serve as a good starting point.

First of all, don't panic. Even though you may have been counting on that person to lead the big project you have coming up, don't worry. It will still get done. You're probably going to need to alter your plans, but very few projects or shops are dependent upon just one person. Schedule some time to sit down with that person and discuss what projects he was working on and what his immediate plans were. You or his supervisor need to get a feel for what he was responsible for. When possible, try to allocate some time for that employee, away from his normal daily tasks, in which he can focus his attention on creating for you a detailed list of the status of his projects.

If you do this, make sure you give the employee enough time to put this list together without distractions. His motivation for his current job is liable to be pretty low by this time, and you

want to make sure that the information he is compiling for you will be useful and not just a time- filler. Giving him time away from daily interruptions will help make sure you get the information you need.

If the employee has projects in progress, it might be a good idea not to rush him to complete them. Chances are, even if he does complete them, he will have been more likely to cut corners. Instead, assign him to work with one of your other programmers to explain where he was on the project and what still needs to be done. Then, follow up on this to make sure both people are on the same wavelength. The likelihood of a successful implementation will greatly increase if you give ownership of the project(s) to one of your staff who will still be there after the other person is gone.

Have the departing employee create a list of his in-house and external contacts.

In-house contacts could include departmental supervisors for ongoing projects, key users responsible for testing or accumulating data for projects in development, and other programmers who may be working on modules associated with what that programmer was working on.

External contacts might include electronic data interchange (EDI) coordinators at the companies you trade electronic documents with, software support representatives for your canned software packages, and even hardware support people. The latter is more likely if yours is a smaller shop and your people wear many hats. Whoever they are, make sure you get a list of names, telephone numbers, and preferred communication times. This information alone could save you hours of digging through the employee's desk after he is gone.

Once you have a handle on what he was working on, you can begin the task of reassigning his workload and smoothing any feathers that may be ruffled by his leaving. This may not only be the departing programmer's coworkers, who may feel they are being unfairly burdened by the workload of the person leaving. It could also include users in other departments who were counting on a system being done on time. It may even extend beyond company boundaries if you have outside clients who depended on that person. This is especially true in consulting firms whose entire business depends on outside clients. You may need to make a few "house calls" to salve some nerves. Calming the waters around you is probably best done by quickly reassigning the workload. Do you have enough qualified people on staff who also have the time to take on the extra work, or will you need to go outside the company for a replacement programmer?

Those are the tough issues, and there is no one right way to handle any of them. Each case will be as different as the personality and the capability of the person who is leaving. However, you can do many things from a purely technical standpoint to ensure that, when the programmer departs, you are not left holding the bag.

It's always better to be prepared and to avoid problems before they happen. You may have the utmost faith and trust in the person who is leaving, but why take chances? It never hurts to take some simple precautions to protect yourself from future problems.

When a programmer leaves under any circumstances, it's a good idea to change all of the Q* user passwords. This would include QSECOFR, QPGMR, QSYSOPR, QUSER, and QDFTOWN. While you are changing passwords, you should also change the password of the user profile of the programmer who left. If you wanted to take that a step further, you could institute a policy

whereby all passwords are changed when a programmer leaves. This standard can help you avoid singling out individuals, and it's always possible that the programmer knew other users' passwords as well. If you set the Password parameter to *NONE, you ensure that it cannot be used to sign on unless someone resets it. This also has the advantage of leaving that user profile out there for jobs that may be referencing it. You can go back later, when you have more time, and change ownership of the objects from the old profile to a new one.

Eventually, you must delete the old user profile. When you delete a user profile, OS/400 finds the objects you own and allows you to transfer ownership to another user profile. You can make this change via the Owned object option (OWNOBJOPT) parameter on the Delete User Profile (DLTUSRPRF) command. This option allows you to make one mass change of all objects owned by the old profile and transfer ownership to a new profile instead of manually changing ownership. You can save yourself days of work with this one command.

If you have loaned software to the programmer, make sure you get it back before he goes. This may include, as part of his exit interview, having him sign an affidavit stating that he does not currently have any copies of your software on his personal system. Client Access/400 would be a good example of the type of software a programmer might want to take with him. Sure, he can probably get a fresh copy of it at his new job, but why make it easier than necessary for him to have access to your system? The same holds true for any hardware you may have loaned out. Laptop computers, modems, and backpack CD-ROM drives are all good examples of commonly loaned out hardware. You probably already have some sort of internal inventory system for all of your hardware and software, so tracking what that person has shouldn't be too much of a problem. If you don't, now might be a good time to implement one.

Also, how about physical security? Do you feel the need to change the door locks to your installation? How about the access codes you use to get into your computer room? You may even want to change the alarm system codes. Sometimes, it can be a good idea to notify your outside clients and contacts that this person no longer works for you. You wouldn't want to have him misrepresenting your company once he leaves. Again, these decisions will probably depend on the circumstances, the personality of the person leaving, and how much you trust that person. Some people need to be escorted off the premises immediately upon announcing their resignation, while others could work right up to the last minute and never cause problems.

The following is a list of common AS/400 commands you can run to determine what the programmer was working on and what you may need to do to avoid potential problems.

The Work with Object Owner (WRKOBJOWN) command should be the first one you run after the programmer is gone. This will give you a list of every object owned by his user profile on your system. Armed with this list, you can begin an analysis of what that person was working on during his time with the company.

Use the Display Object Description (DSPOBJD) command to create a list of all objects on your system. If you list this data to an outfile, you will be better able to get a handle on what you are seeing. You can then query this data to see what objects were created by, owned by, or modified by the user profile of the person leaving. Look for this information in the fields Created by User (ODCRTU), Owned by (ODBOW) and Modified by User (ODUMOD) in the outfile you created. If you sort this report in reverse date sequence, using either the object Creation Date

(ODCTDAT) or the object Changed Date (ODLDAT), you can get an accurate picture of what that person had his hands on recently. If you use a query to select objects of type *USRPRF owned by the user ID of the person who left, you can also see what user profiles he created. Creating a phony user ID and giving it *ALLOBJ or *SECADM authority would be the easiest way of breaking into your system. You may disable the profile of the person who is leaving, but if you don't know about the others he created, you could be leaving yourself wide open.

The Display User Authorities (DSPUSR-AUT) utility command (see "Keep an Eye on User Authorities!," MC, September 1997) will allow you to create a report of what authority a particular user ID has to a given object in a selected library. When you run this utility, you will be presented with a list of objects a user ID has authority to and what level of authority that ID owns. You can select objects of type *ALL, which I would recommend for this purpose, or select a valid AS/400 object type.

The Display Authorized Users (DSP-AUTUSR) command will give you a list, either displayed or printed, of active user profiles on your system. This will show you if any of those user profiles have group profiles assigned to them. It will also show the last time the passwords were changed. This can also alert you to user profiles that shouldn't exist on your system. If you do find user profiles that shouldn't be there, go back and query the DSPOBJD data you accumulated earlier, looking for objects created or owned by the unauthorized user profiles. You may need to remove or change objects on your system that either shouldn't be there or may now be contaminated.

Use the Print User Profile (PRTUSRPRF) command to list which user profiles have special authorities. Do this by specifying PRTUSRPRF SELECT(*SPCAUT) SPCAUT(*ALL). This will show you which user profiles have authority levels of *ALLOBJ, *SERVICE, *IOSYSCFG, *SECADM, and *SPLCTL. You should already have a good feel for which user profiles on your system need these security levels. Any unexpected user profiles with these levels demands immediate attention.

Use the Display Object Authority (DSPOBJAUT) command to create a list of authorized users to an object and their authority levels. You must run this command for each object individually, so you will probably want to use this only for objects that you suspect may have been tampered with.

New to V3R7 is the Print Job Description Authority (PRTJOBDAUT) command, which will list job descriptions in a selected library that do not have a public authority of *EXCLUDE and that also have a user profile in the job description's USER parameter. Use this command to list job descriptions that can allow someone to run a job using someone else's authority. Also check out the following new commands in V3R7: Print Public Authority (PRTPUBAUT) to list objects that have other than *EXCLUDE public authority; Print Private Authority (PRTPVTAUT) to list the private authority of objects; Print Queue Authority (PRT-QAUT) to list output queue and job queue authority; and Print Subsystem Description Authority (PRTSBSDAUT) to list subsystem descriptions that contain a user profile in the default USER parameter. (For more information on these, see "Security Report Commands," TechTalk, MC, August 1997.)

Use the Display File Description (DSPFD) command to display source file information. If you set the Type parameter to member list (*MBRLIST), you will receive a listing of all members in that source file, along with their creation, changed, and last-used dates. This information can tell

you if source members have been changed or modified. It's possible for a programmer to plant a time bomb in source code that "explodes" at some later date and brings your system to its knees. Perhaps the programmer was aware of an impending mass compile or knew of a specific change being made to a specific program and felt confident that his changes wouldn't be detected before the program was compiled.

The Find String PDM (FNDSTRPDM) command may not be as obviously useful as the other commands, but it can really save your system if your departing programmer was up to no good. For example, a programmer could hard code his name, user profile, or other identifying data in a source program, thereby granting himself access to your system later on. Use the FNDSTRPDM to scan for all members matching his name, user profile, or any other personally descriptive data. With that thought in mind, check to see if any unexpected data areas are being accessed in your source members. These would be ideal places to store unauthorized security information that could be accessed by a program.

When a programmer leaves a shop, it creates the potential for many problems. By being aware of what those problems are ahead of time, you can be prepared to ward off disaster. Not every shop will need to implement every one of these suggestions, but it's nice to at least be aware of them in case you ever do need them. It's much easier to have never rung the bell than it is to unring it.

Shannon O'Donnell is a technical editor for Midrange Computing and a senior consultant with Computer Applications Solutions, Inc. in Springfield, Illinois. He has been in applications development on the AS/400 since V1R1. He can be reached at ORION@ auburnctnet.com.

OS/400 CL Reference Commands - DATA through RPLxxx V3R7 (SC41-4725-01, CD-ROM QBJAU401)

OS/400 CL Reference Commands - RQSxxx through WRKxxx V3R7 (SC41-4726-01, CDROM QBJAU501)