|
June 2004 net.digest tracks each months message traffic on the 3000-L mailing list and comp.sys.hp.mpe Internet newsgroup. Advice offered from the messages here comes without warranty; test before you implement. Edited by John Burke
I noted last month that a new OpenMPE Board had been seated and was busily working to advance the goals of the OpenMPE community. This month we posted a letter on the OpenMPE-L mailing list from the Board indicating how we have decided to handle HPs confidentiality requirements, a controversial topic in the election campaign. This will hopefully be the first of many regular reports to the membership. The coming year is going to be a critical one for OpenMPE. We need to energize the MPE-IMAGE community and set up an OpenMPE funding stream. Supporting OpenMPE is the best shot you have for MPE-IMAGE to exist post-2006 in some supportable and maintainable form. If you have not joined OpenMPE and are not planning to, contact me. Give me a chance to talk you into changing your mind. In May we had many off-topic political and religious threads on 3000-L, but in general the total number of off-topic (OT) posts was down comparatively. In fact, the total number of OT postings for May was down considerably. One wag even pointed out we went over 24 hours during the middle of one week without a single off-topic posting! Perhaps the chief OT posters (you know who you are) are finally getting tired? We can only hope. 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.
Homesteaders: Get rid of that internal DDS tape drive Several people complained recently of problems with internal DDS tape drives in systems located in remote areas with little onsite expertise, problems that led to frequent drive replacements and downtime. It reminds me of the old vaudeville joke where the patient comes to the doctor with a complaint, Doc, it hurts when I do this. The doctor replies, Then dont do that. HP 3000 gurus have been cautioning for years that people should not use internal tape or disk drives in 9x7, 9x8 or 9x9 production systems. The most likely failure is a tape drive and the next most likely failure is a disk drive. Everything else in the system cabinet could easily run for a decade without needing service or replacing. When an internal tape or disk drive fails you are looking at serious downtime while the case is opened and the drive is replaced. A common urban legend says that the primary boot device (LDEV 1) and the secondary boot device (usually LDEV 7) must be internal. Not true. Bite the bullet now. Remove, or at least disconnect (both power and data cables) all internal drives. Replace the internal DDS drive with an external DDS3 or DDS4 drive. In the case of the DDS drive, you will not even need to make any configuration changes if you set the SCSI ID to 0 on the external drive. Usually, the internal DDS drive is at SCSI ID 0 (for a 9x7, this is 52.0.0; for a 9x8, this is 56/52.0.0; and, for a 9x9, it is something like 10/4/20.0.0). If you do not want to open the case even to disconnect the drives, you can probably set the SCSI ID on the external DDS drive to 1 since this is usually not used. On 9x9s, SCSI ID 2 is used for the CD-ROM. Disk drive addresses will vary with the system, but even if you replace the internal disk drives with external JBOD, you are still ahead of the game. Remember, if you have to change SCSI IDs, you will have to change your SYSGEN configuration and your boot device paths. Someone also asked whether if you changed the boot path you should immediately create a new SLT. Technically, the answer is No since the SLT contains no information about boot paths. However, if you have not created an SLT since the device was added (and why not?), then by all means create a new SLT. It should also be noted that DDS drives are notorious for not being able to read tapes created on other DDS drives. So, if you do not think you have time to create a new SLT, at least use CHECKSLT to verify you can read your existing SLT on your new drive. If you cannot read your existing SLT, then MAKE TIME to create a new SLT. Your standard procedures should include regularly creating and SLT and checking it. Take it from someone with over 25 years of IT management experience, if anything can go wrong, it will, and at the most inconvenient time. So protect yourself and your organizations IT.
Google is your best friend when looking for information about MPE There are many MPE/iX features/enhancements/procedures that are only informally documented if at all. Frequently this documentation appears on forums such as 3000-L, etc. The various LISTF(ILE) abbreviations above are one recent example. Another example that came up this month is NSSWITCH. A poster said, Wouldnt it be nice if MPE/iX supported NSSWITCH? I do not know if he checked docs.hp.com, but I did, and got no hits for NSSWITCH and MPE. Of course I already knew the enhancement had been announced and discussed several years ago on 3000-L, so I advised him to check the 3000-L archives. Jeff Kell, who through the University of Tennessee at Chattanooga sponsors and maintains 3000-L, suggested using Google instead of 3000-Ls (ravens) search engine. Not only is it faster (ravens search is single threaded) but it obviously covers more territory, though Jeff pointed out Google does not seem to index every 3000-L posting. I tried Google and, sure enough, it brought up links to the 3000-L postings in an instant. It also brought up links to the Hidden Value columns where I consolidated information about NSSWITCH. Duh!
Accounting structure and user volumes, or, Why cant I add this group? This is another one of those things that seems to have slipped through the cracks for many system managers. The group is the basic file container for MPE/iX. As long as you only have one volume set, MPEXL_SYSTEM_VOLUME_SET, the whole process of managing accounts and groups is relatively straightforward. The confusion comes in when you add one or more user volumes. The primary accounting structure for groups is housed in the MPEXL_SYSTEM_VOLUME_SET directory. However, for a group residing on a user volume set, some directory information also resides on the user volume set. In this case, you have to add (or delete) a group twice, once for the system volume set directory and once for the user volume set directory. If you do not follow this procedure, you can end up with directory group fragments on your user volume sets, as the poster to 3000-L did. He was unable to add a new group because the group already existed in the user volume set directory. This is one feature of MPE/iX that is well documented, in this case in the Volume Management manual (docs.hp.com/mpeix/pdf/32650-90491.pdf). Several years ago, Jeff Vance put together a set of UDCs to replace the MPE/iX NEWGROUP, etc. commands so that you do not have to remember to do the NEWGROUP and PURGEGROUP commands twice. Many users have found these UDCs quite helpful and have made them a part of their regular system administration toolkit. The UDCs are available on the HP Jazz server, jazz.external.hp.com. STORE-to-disk, another poorly understood and under-utilized feature STORE-to-Disk (StD) is one of those really useful HP 3000 product features that most people have, but many people are unaware they have. Even some people who know they have it are unaware of its power. This feature allows you to treat a disk file the same as a tape drive, storing information to disk in the same format, and with most of the same options, available when storing to tape. It came up in two different contexts this month. Originally, STORE-to-disk was not part of FOS STORE, but was only delivered with the extra cost TurboSTORE II. However, it was made part of FOS STORE during the MPE/iX 6.5 time frame with patches available to add it to MPE/iX 6.0 systems. One of the key attributes of StD is it gives you the ability to move files either within a system or between systems without the use of external media, all the while maintaining all the file information, including timestamps. On a single system, it give you an easy way to move file sets to different groups, or even the same group on a different volume set, without resorting to tape or changing any file characteristics. For different systems, you package your files together as one big file, FTP it to the other system, and then RESTORE the files from the package. This is how the HP Response Center has handled patches now for several years. Another way to use StD is to have a JBOD volume set dedicated to backups. Instead of storing directly to tape, you do your backups to disk (much faster), and then copy them to tape when convenient. In addition to cutting downtime, this makes unattended backups much less risky.
Copyright The 3000 NewsWire. All rights reserved. |