Admin Alert: More on Safely Deleting User Profiles
November 17, 2004 Joe Hertvik
In the last “Admin Alert,” I presented a checklist of items to review before deleting i5, iSeries, or AS/400 user profiles. Because of OS/400’s design, the checklist was incomplete, since there are so many OS/400 processing functions that can launch jobs running under a particular user profile. Fortunately, my readers came to the rescue on this one with more items to add to the checklist.
User profiles usually own objects, they can be used in running regularly scheduled jobs or in client/server situations, or they may be group profiles that other user profiles depend on for program and file authorization. Such situations should be considered before deleting a profile, and my checklist provided techniques for safely locating functions that use a profile. The checklist wasn’t all-inclusive, however, and here are some valuable additions that readers sent me.
Has the user profile recently been used?
John Earl of The PowerTech Group came up with a way to determine the last time a user profile was used. John uses the Display Object Description (DSPOBJD) command to retrieve the full set of object attributes for a user profile object. To do this for a user profile named Joe, for example, you would run DSPOBJD like this:
DSPOBJD OBJ(JOE) OBJTYPE(*USRPRF) DETAIL(*FULL)
This command lists several interesting pieces of information, including the last date and time the profile was used. For older disabled profiles, this information is valuable because it gives you a clue as to whether the profile is still in use for various jobs. If the profile was used today, for example, the Last used date field would contain today’s date.
The Last used date is useful because you can prepare a profile for deletion, disable it, and then let it sit for a period of time, like a month. If after a month of inactivity the user profile hasn’t been used, chances are good that it can be deleted. The only way you would get burnt in this situation is if the user profile is used in quarterly jobs, yearly jobs, or other jobs that don’t run very often.
It’s important to remember that the Last used date is different from the Previous sign-on date displayed when you view a user profile. The Last used date refers to the last time the user profile was used in any capacity (to run batch jobs, in an ODBC connection, to sign on to OS/400), while the Previous sign-on date refers to the last time the user profile actually signed on to an OS/400 session. For our purposes, the Last used date gives the correct answer.
Are there messages or spool files being created for this user profile on a regular basis?
Like Hansel and Gretel walking through the forest, an active user profile will leave breadcrumbs behind it as it is being used. This tip was provided by David Morris, who reminded me that messages and spool files are activity indicators for jobs that use specific user profiles. All of which makes a review of the user profile’s message queue or generated spool files an easy place to find jobs that run under that particular profile.
To find job messages that were generated for a specific user, you can use the Display Message (DSPMSG) command like this:
DSPMSG MSGQ(user profile message queue name)
In most cases, the user profile message queue name will have the same name as the user profile. But if you want to double-check the message queue name, you can find its name under the Message Queue (MSGQ) parameter of the user profile.
The drill is simple. If a user profile has been disabled for a set period of time and job messages are still appearing for that profile, you can use those messages to determine which jobs are still running under the profile.
Similarly, you can find any spool files that were generated by jobs running under your target user profile by using the Work with Spooled Files (WRKSPLF) command, like this:
WRKSPLF SELECT(user profile name)
This shows you all the spool files generated for this user. If you’re lucky, you might find information about the job that produced them inside the user data field of each spool file. But it’s easier to identify the job that created a spool file by entering ‘8’=Attributes in front of the spool file entry and looking at the upper left-hand portion of the Work with Spool File Attributes screen that appears; this is where the job name, user, and job number of the job that created the spool file are listed.
There is one drawback to locating user jobs through their spool files. Many jobs don’t create spool files at all, and most jobs don’t create job logs unless the program ends abnormally. So the spool file technique has its limits, and I wouldn’t recommend using it as the final authority for locating all jobs that run under your target user. But it’s a helpful indicator for finding some jobs.
What other “gotchas” should you watch out for?
|
Unfortunately, there are plenty. Here are several tricky ones that other readers told me about:
- Jobs running under your target user that were submitted through a Submit Job (SBMJOB) command embedded in a batch CL program. You might have a shot at finding these by looking through the user’s message queue or spool files.
- Scheduled jobs set up through Operations Navigator’s Advanced Job Scheduler program.
- Hidden user profiles and passwords used in scripting functions on remote computers. Your target user profile can be embedded in a Windows script, an automated FTP session on another machine, a DDM connection, or a Visual Basic, Java, or another program. Prior documentation of these situations is the best locator, but after deleting a user profile you may discover that some functions on remote computers are no longer able to communicate with your i5, iSeries, or AS/400.
- Programs that use APIs to switch to another user profile.
As far as I know, there is no easy way to locate deleted user profile names and passwords in these situations. But if any enterprising reader can think of an easy way to solve these or any other gotcha situation, I’ll be glad to mention them in a future column.
Click here to contact Joe Hertvik by e-mail.
