Transoft Sponsor Message

August 2003

Net.digest summarizes helpful technical discussions on the comp.sys.hp.mpe Internet newsgroup and 3000-L 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

This edition of net.digest is the “show” edition for HP World 2003, the last HP World before HP’s end of sales of the HP e3000. If you are standing around the Georgia World Congress Center in Atlanta reading this, let me put in a plug for SIG MPE Wednesday at 2:50 PM in room C102. We’ve got a very full program planned with a number of guest speakers and many important decisions to make. Perhaps even a surprise. Our theme is “Let’s all come to praise MPE, not to bury it.”

As long as I am plugging, let me put in a really blatant, shameless plug for my talk, “Build, Buy, Port or Stay? Choosing a winning strategy for your HP e3000 transition.” I’ll be speaking at 10:40AM Friday, August 15 in room B315. Learn this and other truths, all antidotes to Fear, Uncertainty and Doubt, at my talk. [Ed. Note: John is summarizing his talk in this issue and next of the NewsWire, too. See the first part on page 22.]

I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. You can reach me at john@burke-consulting.com.

When does 1 + 1 not equal 2?

A system manager wrote on the mailing list, “I’ve got a question about the REPORT command. For user volumes, if I do a report t.@;onvs=user_vol it appears to work as expected. I see the accounts homed to that volume and their file space in sectors. I’ve relied on this file space number for years to give me a quick idea of how big an account is.

“For one particular account, however, the sectors are way off, at least compared to the result I get from diskuse /ACCT/. This is a normal MPE account with no HFS directories, no HFS files and no group residing on a different volume.”

This one stumped me, because I am among those who have just assumed the REPORT command was always correct. Gilles Schipper and Craig Lalley replied, “Perhaps the filespace statistics are ‘out-of-sync’ for that account. You can use the FSCHECK ‘SYNCACCOUNTING’ command to rectify. This command is quite innocuous and should not cause your system to crash while being accessed by multiple users. Having said that, I would recommend doing it during a fairly inactive period.”

When I read this, I looked up this SYNCACCOUNTING command in the MPE/iX System Utilities Reference Manual and found the following: “This command synchronizes the account and group disk space accounting with the disk space information found in the file labels of all files on a specified volume set. For system volume sets containing HFS directories, disk space accounting is done for the account and group structure only. After performing SYNCACCOUNTING, the information reported by the REPORT command will coincide with the information reported by the LISTF command.”

I was curious to learn more, so I ran FSCHECK SYNCACCOUNTING against all the volume sets on my R&D machine. The program helpfully points out every group and account it corrects and was surprisingly fast taking only about one minute per volume set. I was literally stunned at the number of accounts/groups which it “corrected.” Virtually all the discrepancies, and all the significant discrepancies, were in accounts that existed for ported applications from the Posix world, perl, Apache, Samba, htdig, xntp, etc. The Apache account went from 374,192 sectors to 11,424 sectors and perl from 1,121,936 sectors to 25,920 sectors!

Then it occurred to me that 11,424 and 25,920 were way too small for Apache and perl, respectively. Let’s look back at the last sentence about the SYNCACCOUNTING command: “After performing SYNCACCOUNTING, the information reported by the REPORT command will coincide with the information reported by the LISTF command.” And from HELP REPORT, “The file space usage count reflects the number of sectors used at the time the REPORT command is issued. Note that it does not account for disc space taken up by root, account, and group directory files, any directories and/or files that are not descended from an MPE/iX account, label tables, transaction management logs and other internal system objects.”

So, whereas before REPORT was in fact displaying something very close to the true number of sectors under the account including all HFS files and directories, it now effectively only displays the sectors reported by LISTF. Somehow this does not seem to be an improvement.

Where, oh where, has the documentation gone?

The number two-ranked item on this year’s System Improvement Ballot (SIB) was about making MPE/iX documentation available over the Internet so that things do not get “lost” over time. One thread on the list this month showed why this is so important. Someone had a question about Remote Procedure Call (RPC), a component of the Open Systems Foundation Distributed Computing Environment (OSF/DCE). Mike Hornsby noted that OSF/DCE was introduced in the MPE/iX 5.5 Communicator but that the links to documentation for OS versions prior to MPE/iX 6.0 have been removed from docs.hp.com. Some of the documents are still there however, at least for the time being.

Mike was able to find the MPE/iX 5.5 Communicator by using the search function. A feature of www.burke-consulting.com is a page with direct links to the older documentation still on docs.hp.com, but not in an obvious place anymore. (Follow my “Miscellaneous” link on the navigation bar to get the HP links.) For example, all of the MPE/iX 5.5 documentation is available at docs.hp.com/mpeix/5.5, and the MPE/iX 5.0 and previous Communicators are still available at docs.hp.com/mpeix/docs5/ixcomm.htm.

What does it mean when BULDACCT doesn’t?

Someone reported to the list, “I found this message in our full backup from this past weekend. What does it mean?”

:Run BULDACCT.PRIVATE.SYS;INFO=”@”

BUILD ACCOUNT PROGRAM FOR DIRECTORY MIGRATION. Version A.50.22

*** HIERARCHICAL DIRECTORIES WILL be processed. ***

*** ROOT HIERARCHICAL DIRECTORIES WILL be processed. ***

Groups with PRIV VOL=YES will have HOMEVS= and ONVS= options.

Cannot write to the stdlist file. (CIERR 9166)

End of output file reached. Some output may have been lost. (CIERR 9445)

Bill Cadier replied, “This is fixed by patch MPELXP3, version A for MPE/iX 6.5 and version B for MPE/iX 7.0. It’s fixed in MPE/iX 7.5, so no patch for that version. Both patches are general-released. The patch documentation states: ‘BULDACCT can fail when there are HFS directories which themselves contain a large number (more than 1,020) of directories. Typically this is seen on high-end systems with large configurations where the online diagnostics have created a large number of directories.’”

Frankly, I’ve never liked BULDACCT for anything other than moving files from one volume set to another, carrying along the directory information. I’ve always felt that in a reload situation, even if only a single volume set, the ;DIRECTORY= option of STORE, once you understand how it works, is much quicker and more accurate. Of course, “once you understand how it works” is critical. For some unknown reason ;DIRECTORY defaults to just MPEXL_SYSTEM_VOLUME_SET. If you have user volumes (you do have user volumes, don’t you?) you must use the “;DIRECTORY=” form and explicitly list all volume sets, including the system volume set. Which brings us to our next item.

Creating the perfect CSLT

The question was about creating a CSLT for a Disaster Recovery test but turned into a general discussion about what the perfect CSLT should look like. The originator of the thread wanted to use the STORE option on the SYSGEN TAPE command to store additional files onto the CSLT he was creating for his DR test but was running into trouble trying to specify STORE options as part of the SYSGEN TAPE command. In particular, he wanted to simply add ;SHOW to get a listing of all files stored.

Several people offered up the answer to his original question, which is to use an indirect file, as in

sysgen>TAPE MODE=VERBOSE DEST=OFFLINE STORE=

^CSLT.INDIRECT.SYS

where the indirect file contains whatever STORE directives you want in addition to the file list.

One contributor applauded his efforts to get a listing: “A backup tape is of limited value without a listing. For Disaster Recovery purposes it is also a good idea to have the original HP tapes/CDs and patches with you as it is possible to create an SLT that does not install or work on a different HP 3000 system.” This same contributor also suggested creating a disk file with a listing of all the stored files.

However, several people questioned whether this list of files which the thread originator had proposed storing was sufficient. Stan Sieler probably said it best in this extended posting:

“I’d put much more in the STORE section, at the minimum:

/SYS - /SYS/MPEXL/DUMPAREA - /SYS/PUB/NL - /SYS/PUB/SL -/SYS/PUB/XL.

(To explain, NL, SL, XL are dumped in the CSLT portion, so no need to dump them in the STORE section; DUMPAREA is a 32Mb file created at INSTALL time and there’s absolutely no need to dump it to a tape.)

/TELESUP - /TELESUP/DUMPS (or wherever you put your dumps.)

/ALLEGRO, /LPSTOOLS, /REGO, /ROBELLE, /VESOFT (It’s surprising how much you might want tools at an early stage.)

“If most of your user data is in one or two accounts, other than SYS, TELESUP, and the rest of the system might fit well onto one DDS/DLT, you might find it more useful to do:

/ - /USERS - /SALES (where USERS, SALES are the ‘user’ accounts)

“Why? It guarantees you’ll get everything you’re likely to need in a recovery/install situation (except, of course, for the major portion of the user’s data). I’d also specify:

;show;directory=MPEXL_SYSTEM_VOLUME_SET,…etc.; progress;partialdb

“Depending upon your own tests and tape drive features, and whether or not you’ve purchased the fancy version of TurboSTORE, you may want to add ‘;compress’.”

SHUTDOWN command? Come on down

The HP 3000’s new SHUTDOWN command, introduced in MPE/iX 7.5 and ported back to MPE/iX 7.0, received a lot of attention on 3000-L lately. Unfortunately, as a number of people pointed out, the command was never ported back to MPE/iX 6.5. This is pure speculation on my part, but the decision not to port to 6.5 was probably because MPE/iX 6.5 was supposed to drop off support much sooner than now. Official support for MPE/iX 6.5 now expires at the end of 2004.

It also appears that many people with older, pre A- and N-Class systems are standardizing on MPE/iX 6.5 for however long they intend to keep their HP 3000s running. My understanding is there are no technical reasons preventing the SHUTDOWN command from being ported to MPE/iX 6.5 so, putting on my co-chair SIG MPE hat, I will suggest at the SIG meeting and at HP World’s Customer Needs Panel that vCSY make the SHUTDOWN command available for MPE/iX 6.5.

John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.