BizNetTech.net Sponsor Message

Shaky Foundation

By Scott Hirsh

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.

What’s 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 wouldn’t build a house without a design and plans, you wouldn’t 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 system’s account structure. But this is worst practices, so let’s 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 Oscar’s 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.

• I’m 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 it’s the SYStem UDC, of course! Maybe it’s not such a bad thing to have another, non-SYS account for globally accessible files. What’s 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 it’s time to develop naming standards and other system policies is a classic Worst Practice, and a good way to ensure continued chaos. And don’t 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 can’t resist? Here’s a hint: it belongs to HP. I know it’s tempting to park files here, like any PUB group, because it’s so… public. The people’s account! A good place to put files you want to share with everyone. Well, not really. There’s actually a tiny sign inside this account, barely visible. It says, “This account subject to change without notice.” It’s bad enough that third-party software vendors litter this account with install programs. Don’t 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 it’s called. In fact, it’s 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 VESOFT’s 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 haven’t had a problem in 15 years, so don’t 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 “I’ve been getting away with murder for 15 years; don’t start messing with me now.”

• The SYS account belongs to HP. So why hang out in there? You’re just going to trash the place and you know it (especially if you’re a guy). Why not set yourself up in your own account, where you can do your system manager thing with impunity?

• And while we’re at it, stop the insanity and take SM away from your users. “But we must have it!” they’ll 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 let’s 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). We’re 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 that’s 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

There’s nothing wrong with being a control freak if you’re ultimately held responsible for areas ostensibly under your control. In other words, don’t blame me for being uptight about disk space if you’re 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 doesn’t it make sense to try to work with that limitation? I’m 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 HP’s 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.

Final Rants

A best practice says “do this;” a worst practice, “don’t do this.” So don’t put off your initiative to get your account structure under control. Don’t 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. Don’t backslide.

In summary, don’t be afraid to be consistent, don’t be afraid to be boring. In system management, boring is good.

Scott Hirsh, former chairman of the SIG-SYSMAN Special Interest Group, is a partner at Precision Systems Group, an authorized HP Channel Partner which consults on HP OpenView, Maestro, Sys*Admiral and other general HP 3000 and HP 9000 automation and administration practices.