net.digest June 1999

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

The graying of 3000-L

I used to think I was one of the few grizzled old hands left in an industry that thrives on youthful energy, not to mention coke and pizza — I work with a lot of twenty-somethings, you see. Well, clearly the members of my generation (Woodstock, if you must know) are not all sitting in rockers drooling in our cups. We’re hanging out on 3000-L.

For a while this month, I thought HP3000-L was doubling as a Senior Activities Center since, before I lost count, there were no fewer than 63 postings about punch cards! Admittedly a couple were along the lines of “Why won’t this thread die?” But still … And some people seemed even to miss those days.

But I digress. Because in addition to Punch Card Trivia, SIB voting rights, bonus calculation algorithms, SETI, and a thread about 8-track audio tape players that I inadvertently started, there were still over 1200 postings meriting serious attention last month. Contained within those postings was a wealth of technical commentary too great to cover completely anywhere, even here. Some snippets that caught my eye:

Do I know you? Should I?

Here is a problem many of us have faced in some form one time or another:

“I’m still getting myself familiar with my environment, and unfortunately we had a slight accident where one of our folks restored some files using the DIRECTORY option. This is a brand new HP 3000 on MPE/iX 6.0, and I’m trying to determine which users are defaulted in the SYS account. So far I have these in red: “[a list of users in the SYS account followed — including some obviously not HP users].

I had a similar reaction and experience in checking my systems to that of Gavin Scott:

“At first glance my gut reaction was that only MANAGER.SYS and OPERATOR.SYS and maybe one or two others are official (HP-created) users in the SYS account, and therefore all of the others must be locally created users specific to this site. On checking a :LISTUSER @.SYS, of course I find that: NWIXUSER.SYS, PCUSER.SYS, RSBCMON.SYS, and SCOPE.SYS exist on all the machines that I checked, and several more may have been HP-created as well (FTP, MGR, and RJE perhaps?). It appears that one of these may have a default password (the same on all systems though?). The others have no password by default, and any one of them can be used to trivially leverage PM and SM capabilities once logged onto, unless more-than-typical security measures have been taken.

“Certainly many production sites use a security auditing tool to spot users with no passwords. I wonder how many systems don’t have any password on one or more of these users or how many people realize just how dangerous these ‘almost-no-capabilities’ users are should someone be able to log onto one of them!

“A final note: Creating lots of additional users for the SYS account is not a very good idea.”

Lars Appel suggested a great starting place to check for HP-created SYS account users: SUPACCT.PUB.SYS.

Ken Sletten then shared a painful memory:

“Gavin is right on, but I will add a caution that I learned from experience when I first stumbled on it a couple years back: Be careful deleting ‘external’ users on your machine (external meaning HP- or third party created). I had a number of users that I knew we did not need anymore, so without thinking it through very clearly I … purged them. Some months later I discovered THEY’RE BACK!

“Of course what happened is that in the interim I had done a major system upgrade, and since I had deleted some of the ‘standard’ HP users, the update process just re-created them WITH NO PASSWORDS!

“And it is not just HP that does this. One or more well-known third parties who have some otherwise excellent products have also been guilty of silently using the ‘; CREATE’ option in their install jobs to create new users with AM capabilities and even new accounts WITH NO PASSWORDS!

“The solution I adopted: Unless you are very sure that a particular user/group/

account will never be re-created by any standard HP or vendor install or update job, leave the user name in place, but with the best eight character alpha-numeric password you can think of. At least for the products we run, I have yet to see an install or update job that will change an EXISTING password on a user that is already in the directory.”

Mike Hornsby chimed in with another cautionary note:

“Prior to deleting users, the prudent action is to remove or alter any files created by that user. In my opinion, the PURGEUSER command should have this option as the default i.e. purgeuser xyz;newcreator=abc

“Without specifying the new creator, ‘orphaned’ files may exist. These files may be critical and will not be restored by default. Note, this usually goes unnoticed, because very rarely can one restore 100 percent of the files. As Stan Sieler indicated in a previous post, some system files can not be restored only ‘installed’ or ‘updated’ under the ISL.

“According to HELP RESTORE ALL...

“If CREATE=CREATOR is not used, the default behavior is: If the creator of the file is not found in the system directory, the file will not be restored. You will get an error message telling you that the creator does not exist. In order to restore this ‘orphan’ file, you must use the CREATOR option or the CREATE option.

“But if you do use the CREATE=CREATOR to get closer to restoring all of the files, then you will also get those users you deleted!

“The newcreator option could physically scan the files, or simply be part of the file system that is used at restore time to map an orphaned creator to an existing user.”

So, what should we all do? Don’t bother trying to make things too pretty by purging users. Take Ken’s advice and lock up every one of these users as tight as possible and then sleep the sleep of the just — or at least the secure.

Are you sure you accounted for everything?

Q: We’re thinking about using the account limit resource accounting capability on some of our machines. I’ve got some questions.

• Does it still work? I’m under the impression that most folks don’t use account limits.

• Do temporary files (file yadayada...;temp) ‘count’ against an account’s limit?

• What does happen if you try to exceed your account’s limit?

• What about HFS files? How do they figure in?

Numerous people contributed to this thread. The answers can be summarized as:

• Yes, account limits still work. And a good place to use them is to ride herd on OUT.HPSPOOL, since a runaway job can easily chew up all available disk space, causing a hung system or System Abort.

• Temporary files aren’t included in the accounting until you try to :SAVE them in the permanent domain.

• Exceeding the limit results in an OUT OF {ACCOUNT|GROUP} DISK message.

• HFS domain files are included in the accounting. And note that the directory entries will also consume space. HFS files do not show up in the REPORT command but are accounted for in the DISKUSE command.

Craig Fairchild (file system architect with HP) added the following detail behind resource accounting:

“The disk space accounting system that we have on MPE/iX today is a directory-based accounting scheme. It seeks to tally the amount of disk space consumed by all the objects that are descendants of either an ACCOUNT or GROUP directory file. (For historical compatibility reasons, the space occupied by GROUP directories does not count towards the ACCOUNT limit, but this is the only exception.)

“This means that ACCOUNT directories report the amount of space allocated to all objects that are descendants of the account, including files and directories (but not GROUPs) immediately under the account, as well as all the files and directories that are descended from those GROUPs and directories, and so on. Similarly, GROUP directories will report the amount of space allocated to all objects that are descended from the GROUP.

“An interesting point is that since the MPE/iX accounting system accumulates data only at the ACCOUNT and GROUP level (those directories have a special format that allows for the information to be stored directly in those directories), the ROOT directory and all non-ACCOUNT directories that are descended from ROOT are not accounted for. This is because the directory format for the ROOT directory and all HFS directories does not allow for disk space information to be stored in those directories.”

Now you see it and now you don’t

$OLDPASS and $NEWPASS have seemingly been around since Day One of MPE. For many, their only experience with these system files has been as part of the COMPILE/PREP/SAVE process on Classic MPE systems. Yet they remain an under-used convenience feature of MPE/iX. Someone asked for a discourse on the nuances of $OLDPASS and $NEWPASS and Leonard Berkowitz obliged.

“These are system-defined temporary files. $NEWPASS is the reference for creating a new file and $OLDPASS is the reference for reading an existing file. The file is opened with the name $NEWPASS, but closed with the name $OLDPASS. Thus, after creating $NEWPASS, the LISTFTEMP command will show only $OLDPASS.

“Here’s an example that will illustrate this. It uses CM KSAM COPYLIB to clean out deleted records:

FCOPY FROM=COPYLIB;TO=$NEWPASS;NEW FCOPY FROM=$OLDPASS;TO=COPYLIB

“The first line will FCOPY all good records, and only good records, from COPYLIB into a temporary file $NEWPASS.

“The second line will FCOPY these good records back into COPYLIB, resetting the EOF to the number of records in $OLDPASS (nee $NEWPASS).

“In another example, I have a production job that logs into (surprise) a production account. For testing, I need to run this job so it logs into a different account. I have read access to the production job library, but I cannot write to it.

:EDITOR TEXT PRODJOB.JOB.PROD CHANGE “PROD”,”DEV”,1 KEEP $NEWPASS,UNN;:STREAM $OLDPASS EXIT

“I could have separated the KEEP and the :STREAM into two lines in the Editor, but I wanted to emphasize the quick transition from $NEWPASS to $OLDPASS.

“$NEWPASS and $OLDPASS are very useful in creating quick, temporary files without having to think about names. Of course, successive writing to $NEWPASS will blow away $OLDPASS.”

To which I would add, you can also use $OLDPASS and $NEWPASS in command files or UDCs when you need a temporary file. It is a little tricky though, because after redirecting the first record to $NEWPASS you must append subsequent records to $OLDPASS. For example, a little command file to do a “SHOW .... ALL” on the supplied database:

parm db echo show !db all > $newpass echo exit >> $oldpass dbutil.pub.sys < $oldpass