This edition of net.digest is the “show” edition for
HPWorld 2003, the last HPWorld before the 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 from 10:40 - 11:50 AM Friday, August 15 in
room B315. I've subtitled the talk "What should an IT organization that
committed to the HP e3000 do now?" In fairness, HP from the beginning has
used the word “transition”. Somehow, though, it has come to be used
synonymously with “migration” by HP’s partners and even HP. “Migration”, however,
is not a synonym for “transition”. Learn this and other truths, all antidotes
to F.U.D., at my HPWorld 2003 talk.
I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse's behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.
When
does 1 + 1 not equal 2?
A system manager writes, "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."
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 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." Where before REPORT on my system was, for some
reason, displaying something very close to the true number of sectors under the
account including all HFS files and directories, it now essentially 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 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 hidden (follow the "Miscellaneous" link on the navigation bar). For example, all of the MPE/iX 5.5 documentation is available at http://docs.hp.com/mpeix/5.5/ and the MPE/iX 5.0 and previous Communicators are still available at http://docs.hp.com/mpeix/docs5/ixcomm.htm.
What does it mean when
BULDACCT doesn't?
Someone reported, "I found this message in our full back-up from this past weekend."
: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)
"What does
it mean?"
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 (> 1020) 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:
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 additonal 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 the list of files the thread originator proposed
storing was sufficient. Stan Sieler probably said it best:
“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
(nl, sl, xl are dumped in the CSLT portion,
no need to dump them in the STORE section;
DUMPAREA is a 32 MB 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 new SHUTDOWN command, introduced in MPE/iX 7.5 and ported back to MPE/iX 7.0, received a lot of attention on HP3000-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 MPE meeting and at the Customer Needs Panel that vCSY make the SHUTDOWN command available via a patch for MPE/iX 6.5.