As we board the train on our trip through HP 3000 System Management Hell, our first stop, Worst Practice #1, must be Unplanned Account Structure. By account structure I am referring to the organization of accounts, groups, files and users. (To keep this discussion simple and typical I will discuss the standard MPE name space, not the Posix name space.) I maintain that the worst of the worst practices is the failure to design an account structure, then put it into practice and stick with it. If instead you wing it, as most system managers seem to do, you ensure more work for yourself now and in the future. In other words, you are trapped in System Management Hell.
Whats the big deal about account structure? The account structure is the foundation of your system, from a management perspective. Account structure touches on a multitude of critical issues: security, capacity planning, performance, and disaster recovery, to name a few. On an HP 3000, with all of two levels to work with (account and group), planning is even more important than in a hierarchical structure where the additional levels allow one to get away with being sloppy (although strictly speaking, not planning your Unix or NT account structure will ultimately catch up with you, too). In other words, since we have less to work with on MPE, making the most of what we have is compelling.
As system managers, when not dozing off in staff meetings, the vast majority of our time is spent on account structure-related activities: ensuring that files are safely stored in their proper locations, accessible only to authorized users; ensuring there is enough space to accommodate existing file growth as well as the addition of new files; and occasionally, even today, file placement or disk fragmentation can become a performance issue, so we must take note of that.
In the unlikely event of a problem, we must know where everything is and be able to find backup copies if necessary. Periodically we are asked (perhaps with no advance notice) to accommodate new accounts, groups, users and applications. We must respond quickly, but not recklessly, as this collection of files under our management is now ominously referred to as a corporate asset.
You wouldnt build a house without a design and plans, you wouldnt build an application without some kind of specifications, so why do we HP 3000 system managers ignore the need for some kind of consistent logic to the way we organize our systems? A logical, adaptable, documented account structure is a huge time saver in many respects. As most of us now manage multiple systems, we have no time to waste chasing down lost files, working with convoluted file sets, struggling to keep access under control or reacting to full volume sets.
I once had a conversation with a co-worker who was an avid outdoorsman. He was discussing rock climbing and I asked him about exciting rock climbing experiences. His reply: In rock climbing, anything exciting is bad. I would say the same thing about system management. By getting your account structure under control, you build a solid system management foundation that translates into much more pleasant work.
If this were a best practices column, we would discuss the best ways to clean up your systems account structure. But this is worst practices, so lets look at the no-nos.
No naming standards, bad naming standards
Oscar Wilde once said, Consistency is the last resort of the unimaginative. Do you think he was referring to HP 3000 system management? If so, not much has changed since Oscars day.
In one account the jobs are located in group JCL. In another account, group JOBS. The developers keep special jobs in a group you never heard of in the critical application account. And just to make things more interesting, all your so-called production jobs are kept in an account called JCL, containing all kinds of groups, including TEMP.
By having consistency across accounts I control, I can easily find what I need when I need it. If jobs are always in the same group across accounts, I can LISTF @.JOBS.@, etc. Backups/recoveries are easier, updates are easier, training new operators is easier. Sure, consistency is boring, but we must resist the lure of adrenaline.
Im going out on a limb here, but my guess is that your UDCs, the few you have left, are in a different place in every account. Why is that? And your system UDC (singular) is located in the SYS account, right? Because its the SYStem UDC, of course! Maybe its not such a bad thing to have another, non-SYS account for globally accessible files. Whats the catch? The system UDC file needs to be in the system volume set, for obvious reasons (learned that one the hard way).
An MPE file name consists of a whopping maximum of eight characters. That should make every character count, right? So why do jobs that live in a group called JCL or an account called JCL all start with the letter J? File that under the department of redundancy department.
We manage the systems, so we make the rules, right? Wrong. If we want the rules followed, if we want the best rules possible, we must get input and buy-in from all the others who will be expected to honor our rules. Ignoring users when its time to develop naming standards and other system policies is a classic Worst Practice, and a good way to ensure continued chaos. And dont forget that upper management will need to be involved when a little gentle persuasion is required.
Trespassing in Vendor Accounts
What is it about the SYS account that system managers cant resist? Heres a hint: it belongs to HP. I know its tempting to park files here, like any PUB group, because its so public. The peoples account! A good place to put files you want to share with everyone. Well, not really. Theres actually a tiny sign inside this account, barely visible. It says, This account subject to change without notice. Its bad enough that third-party software vendors litter this account with install programs. Dont pile on.
Your third-party accounts are also hands off. Consider them the exception to all the rules you lay down on what goes where and what its called. In fact, its a worst practice to try and reorganize a third-party software account.
Account structure-driven security
MPE security is more flexible than it once was, with the ability now to save across accounts, plus all the new Posix tricks. But I think it pays to stick with the old rules, many of which were described by VESOFTs Eugene Volokh in his book, Thoughts and Discourses on HP 3000 Software. [Ed. note: we have copies of this book available at the NewsWire. Contact us to get yours.] Because all the action is at the group level, leaving the account level at ANY access is one less thing to worry about. So once again, the way we organize our account structure is going to weigh heavily on system security.
We havent had a problem in 15 years, so dont worry about system security. (I have actually been told this). No problem, but do you leave your car unlocked in front of your house? Do you leave your front door unlocked at night? Why not? As they say in the investing business: Past performance is no guarantee of future results. This argument usually boils down to Ive been getting away with murder for 15 years; dont start messing with me now.
The SYS account belongs to HP. So why hang out in there? Youre just going to trash the place and you know it (especially if youre a guy). Why not set yourself up in your own account, where you can do your system manager thing with impunity?
And while were at it, stop the insanity and take SM away from your users. But we must have it! theyll say, while threatening the end of the world as we know it. Perhaps if we straighten out the account structure and apply proper file access, everything will work out after all. One world, one sky, one user with SM capability.
But lets not stop there: Hey, you! No developers messing around in production accounts! Do your thing on the development box or in the development account, then operations will move in the addition/change/fix (with change control software, of course). Were trying to run a business around here.
If everyone logs on as a generic user (e.g., ENTRY), then all files created by that user will have the same ownership. Not the worst practice in the world, but we need to be aware of that when it comes time to do some spring cleaning. Sure, security programs allow you to distinguish for security purposes (by session prefix) one generic user from another. But thats only half the story. Having many files created by user ENTRY will make it more difficult to weed out the dead soldiers later on. And if you need to debug a problem, determining which log file was created by which ENTRY user will be a time-consuming chore.
Nice guys finish last
Theres nothing wrong with being a control freak if youre ultimately held responsible for areas ostensibly under your control. In other words, dont blame me for being uptight about disk space if youre quick to scream at me when your volume set runs out of space. We all want to be liked, but sometimes the system management truth hurts.
The only way I know of without third-party software, anyway to keep track of connect time and disk space is at the group level, as provided by the REPORT command. So doesnt it make sense to try to work with that limitation? Im assuming you check at least once per year for users who have zero connect time. And I know you care about how much disk space everyone is using. So unless you can somehow restrict your users to certain groups for logon purposes and disk space purposes, you will have trouble controlling disk space by user and you will be unable to easily determine which users should be removed for inactivity.
Another obvious tie-in to account structure is volume sets. Groups reside on volume sets, not accounts, so the way you organize your groups correlates to your efforts to manage disk space at the volume set level. The good news is that system managers seem to be aware of the UDCs on HPs Jazz Web server for managing accounts and groups (NEWACCT, NEWGROUP), which makes assigning and enforcing volume set standards much easier. If you are not aware of these UDCs, check out http://jazz.external.hp.com/src/index.html.
A best practice says do this; a worst practice, dont do this. So dont put off your initiative to get your account structure under control. Dont be a system management slob. Kick the adrenaline habit and give yourself a break.
Work with everyone who has the potential to undermine your efforts toward system management. Reach consensus on what groups you should have for jobs, executables, UDCs, etc. Collectively decide on a naming convention for accounts, groups, files and users. Have everyone sign off, and get upper management to agree to enforce these standards (on penalty of death, if possible). Document everything, and monitor for compliance. Dont backslide.
In summary, dont be
afraid to be consistent, dont be afraid to be boring. In system
management, boring is good.
Copyright The 3000 NewsWire. All rights reserved.