net.digest November 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

Mea culpa

Elsewhere in this issue I rail at CSY for not keeping what I see as its promises from three years ago about network printing. And now I am about to renege on my promise of just last month to discuss Mark Bixby’s Patchman script and how it can help you manage reactive patches. I’ve got two reasons for postponing this topic for a month. First, CSY not only officially announced, but also actually implemented what has been unofficially known for several months: the conversions of downloadable patches from MOVER format to store-to-disk (STD) format (that sound you hear is beleaguered MPE/iX System Administrators loudly cheering).

No more worries about whether you need the EOF 635, 539 or 651 version of MOVER to unpack a patch set. It happened so fast that Mark has not yet been able to update Patchman to handle this new format. Second, I’ve been spending the month applying MPE/iX 5.5 PowerPatch 7 or MPE/iX 6.0 PowerPatch 1 to my systems and frankly have not been in the mood to deal with reactive patches.

In addition to applying PowerPatches, I also had to rebuild a user volume set on one system this month. Interestingly, there was quite a bit of traffic on HP3000-L about creating SLTs (necessary if you are doing either of the above) and how to recover from a failed drive in the system volume set. So those will be the dual themes this month.

Of course, in addition to the technical discourse, we were treated to discussions about the correct spelling of Harry Truman’s full name, the relationship between rockets, horses’ behinds and Y2K, and whether and when to use the silver bullet “e-mail Carly”. Also, the correct version of the phrase “lies, damned lies and statistics”, and, oh yes, whether to rename the HP 3000.

I would 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. Are you seeing a pattern here? You can reach me at john.burke@paccoast.com or john_burke@pacbell.net.

Before you do any modifications to your system, whether software patching or hardware replacement, you need to be prepared. That means a good System Load Tape (SLT), good backups and good documentation. Let’s consider the SLT and documentation.

SLT: What HP tells you it is, and what it should really be

The following question generated quite a bit of comment: “It has been suggested that when I create an SLT tape I include some additional files and the system directory. While I have found in the manual how to add additional files, I am unclear as to how I can add the system directory. Does anyone have the command format that is necessary?”

HP’s documentation tells us we need to have a current SLT. And that it can be created using the TAPE command within SYSGEN. If you look hard enough you will also find the warning that the CSLT you may have created when doing an update or manage patch is not adequate. That is about it for SLT recommendations.

Is this recommendation correct? Well, in the sense that it is necessary to have an SLT created by the TAPE command, then, yes, it is correct. You can re-install your system in the event you lose a drive in the system volume set using this SLT and appropriate other backups. But is this recommendation complete? I think not.

As has been proven countless times, the people who write manuals (and not just at HP) are not out in the real world. They are not running shops where if you get a six-hour maintenance window once a month you consider yourself lucky. They are not running shops where you have to have procedures that can be understood and followed by someone with only basic training in system operation. They are not running shops where pagers and cell phones go off like July 4th fireworks as soon as anything unusual happens.

One of the great advantages of HP3000-L is we are able to share our real world experience of what works and what does not work in practice. By doing this we all benefit.

So, climbing down off my soapbox, here are the consensus tips and tricks for creating the optimum SLT.

To efficiently re-create your fully functional HP 3000 system from a SYSGEN SLT tape you need, at a minimum, the following:

• The SYSGEN files (the TAPE command).

• The SYS account minus those files already stored by SYSGEN TAPE.

• The TELESUP account (Certain programs in TELESUP are version- and, sometimes, patch-level specific. Consider CHECKSLT and FSCHECK. Also, if you have any problems, the RC will likely want to run utilities from TELESUP).

• The system directory.

The following are technically optional, but I would not create an SLT without including these:

• The directories for any user volume sets.

• Copies of the two jobs produced by BULDACCT (unless already included above).

• Any site-specific utility groups/accounts, including third-party utilities such as backup software needed to restore user files (also unless already included above). Note that if you include TELESUP, you should exclude any old dumps that might be out there.

I like to STORE the directories for all volume sets on the SLT tape because if you have to rebuild a volume set, restoring its directory is the quick and easy way to get the appropriate accounting structure in place before the reload of files. I successfully used this very approach several weeks ago, so I speak from experience. I find this much more convenient than BULDACCT, though I run it also just to cover all bases.

Basically, the thought is that the SLT should contain everything required to get the system up and operational. (Note: the system not the applications.) The reason that it is important to store these critical files on the SLT is because the normal SLT does not contain all of the subsystems and configurations required to fully recover the system and the network. This information is hopefully contained on your full system backup, but if you backup your system with @.@.@, then the SYS account is near the end of the backup.

What you need to recover first may be at the end. My full backup stores the SYS account first to avoid this problem, but since we keep these tapes offsite there would be a delay in getting the tapes required to start a recovery. I always keep a current SLT on site for emergencies.

If everything you need to recover the system is on your SLT, then once the install is complete, rebuild the system volume set and restore @.@.@ with the “DIRECTORY” option (and optionally ONVS) off of your SLT, perform a START NORECOVERY and your system is operational. When your backup tapes arrive from their offsite storage you can simply restore @.@.@ with the “KEEP”, “DIRECTORY” and “ONVS” options to recover the user data. For this approach to work your custom SLT tape must be kept current. Most people recommend creating a SLT before and after all patches and creating an SLT at least every two to four weeks, keeping it where you can get to it. If you possibly can, create two copies.

The following job stream will create an SLT according to the above rules (assuming the BULDACCT jobs and any site-specific utilities are in either the SYS or TELESUP accounts). Note that the STORE parameter on the TAPE command references an indirect file that contains the actual TurboSTORE statement for a system with three user volume sets (uvs1, uvs2 and uvs3). Note also that you should create the SLT on the SAME drive you may have to read it on if at all possible.

!job slt,manager.sys;hipri
!comment the following assumes LDEV 7 is the alternate boot path and
!comment has autoreply enabled (otherwise, respond to a tape request)
!file sysgtape;dev=7
!sysgen
tape verbose store=^slt.indirect.sys
e
!tell manager.sys; slt complete
!tellop slt complete
!eoj

:print slt.indirect.sys

@.pub.sys,@.@.sys @.pub.sys,@.@.telesup;show;directory;onvs=mpexl_system_volume_set,uvs1 ,uvs2,uvs3

The indirect file may look a little confusing in print because it is actually all one line. This is because continuation lines are not supported; however, you are also not limited to just 72 or 80 characters. Also, in case you are concerned about HFS files, we have this from HP’s Jeff Vance:

When the first filename component of a fileset name in the STORE command is “@”, the name is converted to an HFS (Posix) name, such that all HFS and MPE-named files are selected. E.g.,

STORE @ becomes STORE ./@/
STORE @.G becomes STORE /ACCT/G/ ( the trailing “/” means ‘here and below’)
STORE @.@.A becomes STORE /A/
STORE @.@.@ becomes STORE / (all files, groups, accts and directories) are selected.

Okay, you’ve created your SLTs. Can you sleep the sleep of the fully prepared? No! You must first validate your SLT, first using CHECKSLT.MPEXL.TELESUP on the SLT part and then VSTORE on the STORE part. Now you can rest.

Well, maybe not just yet.

Real nerds don’t do documentation —
but do if they want to be employed

Here is my checklist on system documentation for each system:

• A list of all hardware by system with model number and serial number and with support contract numbers and contacts
• A list of all software by system with license information and with support contract numbers and contacts
• DSTAT ALL for each system
• DISCFREE C for each system
• A SYSGEN listing for each system
• An NMMGR listing for each system
• A SYSINFO.PRVXL.TELESUP listing for each system (WARNING! This program can create a system abort on even a moderately loaded system. Use with extreme caution.)

Here is a CI command file I use to create a SYSGEN listing:

parm outf=”lp”,outp=”1”
purge temp > $null
purge temp,temp > $null
file sysglist;dev=!outf,!outp
echo io > temp
echo lc dest=offline >> temp
echo ld dest=offline >> temp
echo lp dest=offline >> temp
echo lv dest=offline >> temp
echo e >> temp
echo misc >> temp
echo sh all dest=offline >> temp
echo e >> temp
echo lo >> temp
echo sh all dest=offline >> temp
echo e >> temp
echo sh all dest=offline >> temp
echo sy >> temp
echo sh all dest=offline >> temp
echo e >> temp
echo e >> temp
save temp
sysgen < temp
reset sysglist

Here is a command file I use to get a listing from NMMGR:

parm outf=”lp”,outp=”1”
purge temp > $null
purge temp,temp > $null
file formlist;dev=!outf,!outp
echo openconf nmconfig.pub.sys > temp
echo summaryconf dts >> temp
echo all >> temp
echo e >> temp
echo exit >> temp
save temp
file nmmgrcmd=temp,old
nmmgr
reset formlist
purge temp > $null
reset nmmgrcmd