Admin Alert: Eternal Users: A Common Problem With IBM i Batch Jobs
September 19, 2012 Joe Hertvik
|
Many IBM i shops have problems with eternal users. Eternal users are user profiles previously used by former IBM i power users that are still on the system. Although these users have left your organization, you can’t delete their user profiles, because the profiles are used in IBM i functions used to run batch jobs. This week, let’s look at eternal users and how to weed them out of your system. How The Gotcha Gets Ya Eternal users happen when administrators use their own or other power user profiles for submitting batch work to the system. Batch jobs are frequently submitted under a power user profile because that profile is configured correctly to run that particular batch job. This is a fairly commonplace practice. Using an active power user to run batch jobs works great. . . until the user leaves the company. Best practices and auditing procedures may force you to delete the user profile within a specified time period, such as 30 days. Sometimes you’ll find that after you delete a power user profile, many of your automated jobs stop working. This holds up production and can even cause data corruption if the scheduled job failure affects processing in other scheduled jobs. To avoid problems, many shops leave terminated administrator and power user profiles on their systems instead of deleting them, to avoid the risk of key batch processing crashing unexpectedly. The result is the eternal user who can’t be deleted for fear the user’s absence will crash the system. This is a fairly common IBM i problem. To avoid littering your system with eternal users and to cure any jobs currently running under eternal user profiles, my personal best practices for dealing with this issue are the following: 1. Create a batch user profile that has enough authority to run any automated procedure in your job scheduling functions. You can set the user up so that they can never sign on to the system by running the following Change User Profile (CHGUSRPRF) command, after the batch user is configured with the proper authorities. CHGUSRPRF USRPRF(user_name) PASSWORD(*NONE) PWDEXP(*NO) STATUS(*DISABLED) This command takes away the batch user’s ability to sign on to the system by: 1) disabling the user profile (setting the Status parameter to *DISABLE); and 2) making sure no password is associated with this user profile (setting the User Password parameter to *NONE). Notice that I’ve also set the “Set password to expired” parameter to *NO (non-expired) for this user. This is because you can’t expire a user profile that doesn’t have a password, at least not in the IBM i 6.1 system I tested this article on. The key is that while a disabled user without a password can’t sign on to the system, it can be used to run batch jobs. Most auditors will understand the concept of using a non-active batch user profile to run batch jobs, instead of using IBM system profiles such as QSECOFR or active power user profiles. And because the batch user profile can never sign on to your system, it’s usually not an issue to leave it on your system forever. 2. Stop designating live user profiles as the profiles that your batch jobs will be submitted under. Start specifying the designated batch user profile in the following functions that can submit jobs on an IBM i system.
This step can be used to stop the practice of using a live profile to start batch jobs. Make it a firm rule in your shop that it’s no longer acceptable to use live user profiles for scheduled jobs and you’ll cut down on the problem before too long. 3. Start weeding out live user profiles in batch jobs, as time permits. It can be a daunting task to audit all the entries in your job scheduler, plus your job descriptions, and replace eternal user profiles with batch user profiles that have the authorities you need to still run your jobs. I don’t recommend that you attempt to change all your batch jobs at once. Take it slow and go through these jobs a few at a time to orderly transition your batch job structure to user profiles that will never be deleted. The biggest issue with eternal users in batch jobs is that it’s hard to know when you’re finished. But if you take prudent steps to stop the problem from spreading using non-active batch profiles and then weed out terminated user profiles from submitting jobs in your system, you’ll eventually minimize the problem so that you no longer have to fear deleting terminated users from your system. More On Checking IBM i PTF Level Status Regarding my recent article on checking IBM i OS and PTF Level Status for Sarbanes-Oxley Documentation, a few readers wrote in with additional information I didn’t mention in the article. First, several readers pointed out that I incorrectly said that there was no option in the i 6.1 Work with PTF Group (WRKPTFGRP) command to produce a spooled file report of current PTF group status. They wrote in to tell me that if you press the F6=Print function key off the WRKPTFGRP screen, the command will produce a PTF Group status printout of all the PTF groups on your system, similar to what’s shown on this screen.
(Click graphic to enlarge.) This works and I should have noticed this feature when I wrote the article. I apologize for the omission. The readers also mentioned that if you’re looking for a list of all the installed PTFs for any particular group, you can also enter a “6=Print” in front of the group you’re interested in. This feature will produce a printout showing all the PTFs that are applied for the selected PTF group. Here’s what this report looks like if I take an option 6 to display all the PTFs for SF99354, TCP/IP Group PTFs on one of my machines.
(Click graphic to enlarge.) Another good tip came from an IBM reader who pointed that out when looking for up to date PTF information, my readers should check out the IBM Preventive Service Planning – PSP website. This site also lists out the latest PTF Groups by Release (i5/OS V5R4, i 6.1 and i 7.1) and the PTF Groups by Latest Update. The “PTF Groups by Latest Update” selection is nice in that it shows the release dates for all current PTF group releases and the PTF groups that were released on each date. So it’s a nice way to see which PTF groups are the most recent. Here’s what the IBM screen looks like:
(Click graphic to enlarge.) So between this IBM screen and the IT Jungle System i PTF Guide, which I referenced last issue, there are two great locations for looking up the latest PTF group release dates. Follow Me On My Blog, On Twitter, And On LinkedIn Check out my blog at joehertvik.com, where I focus on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else he come across. You can also follow me on Twitter @JoeHertvik and on LinkedIn. Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002. RELATED STORIES Checking IBM i OS and PTF Level Status for Sarbanes-Oxley Documentation Using OS/400 Autostart Jobs for Repetitious Server Processing
|
