net.digest December 1997

Click here for RAC sponsor message

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

Analysis by John Burke

Don’t throw caution to the wind

Here is a tale of woe told on HP3000-L along with comments from the list. Hopefully it will help keep someone else from suffering the same fate:

“Just a word of caution for all you HP 3000 system managers, just in case you ever try something as foolish as I did over the weekend. In preparing to upgrade the operating system on our HP3000 959/200 from MPE/iX 5.0 to MPE/iX 5.5, I moved some files from LDEV1 to make room for the upgrade. Little did I know that the system would allow me to move files from LDEV1 that are needed to perform a START NORECOVERY. Here is the scenario:

“The UPDATE to install the factory SLT for MPE/iX 5.5 step barked about file directory problems but completed successfully.

“I then performed a START NORECOVERY NOSYSSTART as instructed by the upgrade procedures. The START failed, saying it could not find file PERFLOG.MPEXL.SYS. The reason it could not find the PERFLOG file was because I had moved it from LDEV1. The system could not mount any disc drives other than LDEV1 because the files IO@.CONFIG.SYS were also moved off of LDEV1.

“I contacted HP and discussed the situation. I ended up performing an UPDATE CONFIG using my CSLT from Friday. The default of the UPDATE utility is NOCONFIG. This UPDATE CONFIG restored the IO@.CONFIG.SYS files to LDEV1. START NORECOVERY worked fine.

“Three hours after the initial UPDATE to 5.5 began, I started a successful upgrade to MPE/iX 5.5 Moral of the story – Do NOT move files in the SYS account from LDEV1.

Question: Why does the operating system allow me to move files off of LDEV1 that are needed to boot and start the system?”

The comments started with:

“Since MPE doesn’t have a command to move files from one LDEV to another, you used Vesoft’s MPEX, which will allow you to move anything anywhere. I don’t think you can blame HP for this one.

“Or can you? If you blame VESOFT, you’ll eventually arrive at the question “what files have to stay on LDEV 1, anyway?” and you’ll discover that there isn’t an official, definitive answer. One starting point is to go into :SYSGEN, >SYSFILE, >SHOW; all of the files listed have to stay on LDEV 1. But that isn’t quite enough.

“The short, easy answer is to leave all files in PUB.SYS, MPEXL.SYS, and DIAG.SYS alone. That should still leave you with enough files you can safely move off LDEV 1 to do the trick.”

They continued with:

“MPE did not allow you to move the files. You used a highly privileged, non-HP utility program to do it. Also, MPEX generally takes the Unix philosophy of quickly and efficiently implementing whatever stupidity we users feed into it.

“I’m kind of surprised that the system didn’t come up, as the UPDATE process (as you saw) will restore files even if the previous versions have been moved off LDEV 1, and are thus inaccessible during the UPDATE when only LDEV 1 (not the whole MPEXL_SYSTEM_VOLUME_SET) is available. It gives you an error about one or more extents of the file not being on LDEV 1 and then removes the directory entry for the old file without deallocating the disk space for the file. I’m not sure if this space gets recovered automaticaly on a subsequent START, or whether it’s gone forever.

“Apparently UPDATE doesn’t actually bring in every file required for a successful START, and START itself was unable to deal with the file in question being unopenable in single-disk mode, which I would classify as a bug in START, especially since this doesn’t exactly sound like a life-or-death kind of file.”

And then:

“Actually, an UPDATE does NOT bring in the I/O configuration file (usually in CONFIG.SYS) which needs to reside on LDEV 1. A subsequent START would fail as a consequence. This also explains why an UPDATE CONFIG corrects the problem by depositing ALL necessary LDEV 1 files in their proper location – including those in CONFIG.SYS.

“Of course, if your SLT tape is not current with respect to your configuration, you may be facing a whole different set of problems.”

Then a question came in: “OK, then what about a RESTORE of the SYS account? Files will go all over the place if you are not careful. You can blame HP for that one!”

And the responses:

“Not really. If you ever need to restore the SYS account – without the KEEP option – you should immediately follow it with an UPDATE CONFIG from a current SLT tape. OTOH, maybe you can blame HP for not clearly specifying that - somehow and somewhere.”

And:

“Files can be built with either an LDEV or a Device Class as the location of the file in the file label. Files that MUST be on LDEV 1 are built ‘;DEV=1’ (most files are built ‘;DEV=DISC’). STORE preserves this information, and RESTORE puts the files back correctly. Unless you go out of your way to mess it up. Usually.”

Getting back on the track:

“There exists a ‘PROTECTED’ indicator in the flags area of a file label. If I recall, the memory dump file which is required to be on LDEV 1 has this flag set, so that the file cannot be easily moved into another LDEV. Perhaps HP should use this to lockdown all files required to be on LDEV 1, and the various tools which go underneath the file system should ‘honor’ this flag?”

And finally, from an HP engineer:

“We believed up to this point that we had ‘protected’ all necessary files. And, in fact, the configuration files required to boot your system were preserved. They just weren’t the files you expected.

“Whenever you do a START NORECOVERY [GROUP=<config group>], a new configuration group is established. If you don’t specify the GROUP parameter, the new configuration group is CONFIG. During the boot process, the OS makes a copy of the specified or default configuration files in BOOTUP.SYS. A subsequent START [RECOVERY] uses the files from the original configuration group UNLESS they have been modified or no longer exist, in which case MPE uses the files in BOOTUP. None of the configuration groups are considered protected, and they don’t need to be. The current configuration is always in BOOTUP.SYS and those files ARE protected. In fact, once you realized your mistake, you could have done a START NORECOVERY GROUP=BOOTUP. Then, after booting, you could have fixed the CONFIG.SYS group and re-booted with a START NORECOVERY.

“Now, that doesn’t explain the problem with PERFLOG.MPEXL.SYS. The OS was designed to boot successfully even if the only disk online is LDEV 1. Sounds to me like PERFLOG now prevents MPE from working as designed. So, either 1) PERFLOG needs to be protected like other boot files, or 2) code needs to be changed to allow the system to boot even if no PERFLOG exists.”

Original material copyright 1998, The 3000 NewsWire. All rights reserved.




		Click here for RAC sponsor message
		Net.digest summarizes helpful technical discussions on the HP 3000-L Internet mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your production or development HP 3000s. Analysis by John Burke Don’t throw caution to the wind Here is a tale of woe told on HP3000-L along with comments from the list. Hopefully it will help keep someone else from suffering the same fate: “Just a word of caution for all you HP 3000 system managers, just in case you ever try something as foolish as I did over the weekend. In preparing to upgrade the operating system on our HP3000 959/200 from MPE/iX 5.0 to MPE/iX 5.5, I moved some files from LDEV1 to make room for the upgrade. Little did I know that the system would allow me to move files from LDEV1 that are needed to perform a START NORECOVERY. Here is the scenario: “The UPDATE to install the factory SLT for MPE/iX 5.5 step barked about file directory problems but completed successfully. “I then performed a START NORECOVERY NOSYSSTART as instructed by the upgrade procedures. The START failed, saying it could not find file PERFLOG.MPEXL.SYS. The reason it could not find the PERFLOG file was because I had moved it from LDEV1. The system could not mount any disc drives other than LDEV1 because the files IO@.CONFIG.SYS were also moved off of LDEV1. “I contacted HP and discussed the situation. I ended up performing an UPDATE CONFIG using my CSLT from Friday. The default of the UPDATE utility is NOCONFIG. This UPDATE CONFIG restored the IO@.CONFIG.SYS files to LDEV1. START NORECOVERY worked fine. “Three hours after the initial UPDATE to 5.5 began, I started a successful upgrade to MPE/iX 5.5 Moral of the story – Do NOT move files in the SYS account from LDEV1. Question: Why does the operating system allow me to move files off of LDEV1 that are needed to boot and start the system?” The comments started with: “Since MPE doesn’t have a command to move files from one LDEV to another, you used Vesoft’s MPEX, which will allow you to move anything anywhere. I don’t think you can blame HP for this one. “Or can you? If you blame VESOFT, you’ll eventually arrive at the question “what files have to stay on LDEV 1, anyway?” and you’ll discover that there isn’t an official, definitive answer. One starting point is to go into :SYSGEN, >SYSFILE, >SHOW; all of the files listed have to stay on LDEV 1. But that isn’t quite enough. “The short, easy answer is to leave all files in PUB.SYS, MPEXL.SYS, and DIAG.SYS alone. That should still leave you with enough files you can safely move off LDEV 1 to do the trick.” They continued with: “MPE did not allow you to move the files. You used a highly privileged, non-HP utility program to do it. Also, MPEX generally takes the Unix philosophy of quickly and efficiently implementing whatever stupidity we users feed into it. “I’m kind of surprised that the system didn’t come up, as the UPDATE process (as you saw) will restore files even if the previous versions have been moved off LDEV 1, and are thus inaccessible during the UPDATE when only LDEV 1 (not the whole MPEXL_SYSTEM_VOLUME_SET) is available. It gives you an error about one or more extents of the file not being on LDEV 1 and then removes the directory entry for the old file without deallocating the disk space for the file. I’m not sure if this space gets recovered automaticaly on a subsequent START, or whether it’s gone forever. “Apparently UPDATE doesn’t actually bring in every file required for a successful START, and START itself was unable to deal with the file in question being unopenable in single-disk mode, which I would classify as a bug in START, especially since this doesn’t exactly sound like a life-or-death kind of file.” And then: “Actually, an UPDATE does NOT bring in the I/O configuration file (usually in CONFIG.SYS) which needs to reside on LDEV 1. A subsequent START would fail as a consequence. This also explains why an UPDATE CONFIG corrects the problem by depositing ALL necessary LDEV 1 files in their proper location – including those in CONFIG.SYS. “Of course, if your SLT tape is not current with respect to your configuration, you may be facing a whole different set of problems.” Then a question came in: “OK, then what about a RESTORE of the SYS account? Files will go all over the place if you are not careful. You can blame HP for that one!” And the responses: “Not really. If you ever need to restore the SYS account – without the KEEP option – you should immediately follow it with an UPDATE CONFIG from a current SLT tape. OTOH, maybe you can blame HP for not clearly specifying that - somehow and somewhere.” And: “Files can be built with either an LDEV or a Device Class as the location of the file in the file label. Files that MUST be on LDEV 1 are built ‘;DEV=1’ (most files are built ‘;DEV=DISC’). STORE preserves this information, and RESTORE puts the files back correctly. Unless you go out of your way to mess it up. Usually.” Getting back on the track: “There exists a ‘PROTECTED’ indicator in the flags area of a file label. If I recall, the memory dump file which is required to be on LDEV 1 has this flag set, so that the file cannot be easily moved into another LDEV. Perhaps HP should use this to lockdown all files required to be on LDEV 1, and the various tools which go underneath the file system should ‘honor’ this flag?” And finally, from an HP engineer: “We believed up to this point that we had ‘protected’ all necessary files. And, in fact, the configuration files required to boot your system were preserved. They just weren’t the files you expected. “Whenever you do a START NORECOVERY [GROUP=<config group>], a new configuration group is established. If you don’t specify the GROUP parameter, the new configuration group is CONFIG. During the boot process, the OS makes a copy of the specified or default configuration files in BOOTUP.SYS. A subsequent START [RECOVERY] uses the files from the original configuration group UNLESS they have been modified or no longer exist, in which case MPE uses the files in BOOTUP. None of the configuration groups are considered protected, and they don’t need to be. The current configuration is always in BOOTUP.SYS and those files ARE protected. In fact, once you realized your mistake, you could have done a START NORECOVERY GROUP=BOOTUP. Then, after booting, you could have fixed the CONFIG.SYS group and re-booted with a START NORECOVERY. “Now, that doesn’t explain the problem with PERFLOG.MPEXL.SYS. The OS was designed to boot successfully even if the only disk online is LDEV 1. Sounds to me like PERFLOG now prevents MPE from working as designed. So, either 1) PERFLOG needs to be protected like other boot files, or 2) code needs to be changed to allow the system to boot even if no PERFLOG exists.” Original material copyright 1998, The 3000 NewsWire. All rights reserved.