RAC Sponsor Message

September 2004

net.digest tracks each month’s 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

HP World vs. HP’s World, it is official; HP World 2005 will be a wholly Interex-run affair. HP World 2005 will take place during mid-August of 2005 in beautiful San Francisco. One month later, in New Orleans (watch out for those hurricanes in that month), HP will hold its first HP Technology Forum, officially splitting from its long-time user group. Apparently HP can promote Open Systems and Open Source (as long as it is Linux and not MPE) but general openness – well that is just too scary. As Stan Sieler noted, altering Pogo’s famous line, “HP has seen the enemy, and it is us.” A number of long-time Interex volunteers took special exception (with good reason) to HP’s calling its new captive conference “the first conference to deliver qualified, consistent education and training opportunities across HP’s broad base of customers, partners and employees.” What do you suppose it thinks Interex was doing all these 30 years?

I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you spot something on 3000-L and would like someone to elaborate on it, let me know. You can reach me at john@burke-consulting.com.

MPE/iX’s Legendary Reliability and Robustness?

We’ve all heard the stories about systems that haven’t been rebooted in a year or more, and then only to update system software (my little 9x7 test and development machine — and host of www.burke-consulting.com — is coming up on one year of uptime). How many times have you said about one of your HP 3000s, “It never fails?” However, there is a little gotcha that has been in MPE/iX since its beginning that will abort a system in a heartbeat. There are undoubtedly many systems in production right now that are vulnerable.

Scott Hirsh first reported in 1999 on 3000-L that if you have a tape drive configured with an LDEV > 255 and try to access a labeled tape, you will get a SYSTEM ABORT 2559 FROM SUBSYSTEM 99 with COMPATABILITY MODE SUDDENDEATH 8606. The code that handles labeled tapes was never converted to NM. HP stated it had no plans to convert this code to NM to fix the problem.

What is unconscionable is HP never did anything to ameliorate the problem. Why not a simple trap before calling the CM code? At the very least, there should have been a warning in every Communicator under the heading “Known Problems.” This gotcha nabbed an expert system administrator recently. Will you be next? Forewarned is forearmed.

DBXBEGIN/DBXEND: Underused and Under-appreciated

Someone asking if DBXBEGIN/DBXEND/DBXUNDO could be used to protect the unloading of millions of database records started this thread. It became clear from the questions and comments that followed that many MPE/iX users do not understand Dynamic Rollback Recovery (see docs.hp.com/cgi-bin/doc3k/B3039190010.17091/60). Using MPE/iX’s transaction manager (XM), “uncommitted logical transactions can be rolled back dynamically (online) while other database activity is occurring. The dynamic transaction can be rolled back in the following ways:

“1. Programmatically with a call to the DBXUNDO intrinsic, or;

“2. Automatically when the application aborts or a system failure occurs within the transaction.”

Brian Donaldson gave a good programmer’s perspective on the use of Dynamic Rollback Recovery (See raven.utc.edu/cgi-bin/WA.EXE?A2=ind0408D&L=hp3000-l&D=0&P=2797.) Finally, Goetz Neumann noted, “The limit (XM user transaction size) is hard-coded and used to be 4 MB. It was increased to 32MB in release 6.5 and higher. For details see docs.hp.com/mpeix/onlinedocs/30216-90291/00/00/43-con.html.”

Logging: Underused and Under Appreciated,
But Getting a New Life

The requirements of Sarbanes-Oxley have a number of people scrambling to implement IMAGE logging and log reporting. Up on the Web there’s an IMAGE FAQ that covers logging: www.beechglen.com/pub/imagefaq.txt.

Cathlene McRae, of the HP Response Center, offered, “There are several notes on the itrc.hp.com about IMAGE logging. They cover the basics [KBRC00000222] to the more complex recovery from a different account [KBRC00011624]. There are more then 20 documents that cover the subject of logging as well as recovery (since they are related). Most are up to date.”

For reporting from IMAGE log files, the options range from the free CATCHLOG program available on jazz (jazz.external.hp.com/src/ and scroll down to CATCHLOG) to the commercial DBAUDIT product from Bradmark.

Since when did disaster recovery testing
count as a business critical need?

More than a few eyebrows were raised over this posting to 3000-L: “Could someone tell me the relative performance for an HP 3000 N4000-800-550 server? The box is an HP 9000 that HP converted to an HP e3000 for our disaster recovery testing.” Duane Percox quickly responded asking if it was a trick question since HP never made an 8-way 550. We soon were informed that it was in fact an “rp7400/N4000-400-440”. Since N4000-400-440 systems were sold several people were able to report that the system has an RPU rating of 57.

However, eyebrows were still raised over why HP performed this conversion in the first place. In its statement about making HP 9000 to HP 3000 conversions, HP stated, “We have decided that, under very select circumstances, HP, or an HP-authorized channel, will perform the conversion of a used HP 9000 into an HP 3000. We will only consider such conversions on a case-by-case basis when HP determines that a customer or partner has a business critical need, and there is a clear shortage of used HP e3000 systems within resale channels to meet that need.”

It appears that in this case, the “very select circumstances” had more to do with the customer (a large Amisys shop with system administration outsourced to Perot Systems) then with the specific business critical need or the availability of used systems. Did anyone really think it would be otherwise?

Web-Based MPE/iX HELP

In early 2001, Mark Bixby contributed a perl script to the community that parsed the MPE/iX HELP file, CICAT.PUB.SYS, creating an html file for each command, function and variable. But, it did not create an index for the HTML files. Donna Garverick rectified this with a pair of CI Command Files to create an index page for the MPE/iX HELP html files.

One advantage of this over the online HELP is that the description for long commands such as STORE is delivered together all at once – you can easily scroll down in your browser to find what you are looking for. Another advantage is that, when made part of a Web site, HELP is searchable. I used Bixby’s and Garverick’s scripts, with only mild tweaking, to create a Web-based, searchable MPE/iX HELP catalog for MPE/iX 6.0 in early 2001 and made it available for all at www.burke-consulting.com/htdocs/ mpe60/cicat/index.html.

The events of 9/11/2001 and 11/14/2001 affected all of us to varying degrees. People forgot about my publicly available HTML catalog and I neglected to update it. That is until last month, when someone asked a question on 3000-L about creating HTML help. Before I could get my act together, Doug Werth used Bixby’s perl script to create a folder of 7.0-based html HELP files on the Web. Not knowing about Garverick’s command files, Werth created his own index. I eventually added the MPE/iX 6.5 catalog (www.burke-consulting.com/htdocs/mpe65/cicat/index.html). For those of you who would like to “roll-your-own” (MPE/iX 7.5?) Web HELP catalog, I have packaged slightly modified versions of Bixby’s perl script and Garverick’s CI command files in a store-to-disk file translated into Reflection “Labels” format for easy transfer. You can pick it up at www.burke-consulting.com/default.htm.

Maybe I was asleep – or was too busy
trying to figure out life after MPE

Perhaps others were asleep too, and, like me, did not notice the publication of an updated White Paper on Storage Arrays and MPE/iX Performance. Fortunately, in response to a query for help configuring an XP512 for maximum performance, Walter McCullough, MPE/iX High Availability Architect, noted, “You might want to read a White Paper on MPE performance with various storage and configuration options, written last January.” (jazz.external.hp.com/mpeha/papers/off_white_2004.html.) McCullough is much too modest. You DO want to read this White Paper, regardless of the type of storage you are using with your HP 3000.

In addition to some fascinating information on MPE/iX disk IO and the various storage arrays, the paper has this to say about MPE/iX architecture (emphasis mine), “The current (and last) incarnation of MPE and its lowest (machine dependent) layer was specifically designed for the PA-RISC architecture. This thin layer allowed the MPE lab to create an operating system that had very little shielding from the hardware layer. While the HP-UX approach was to create a (thicker) layer, which allowed for greater hardware independence, MPE’s approach allowed operations to move more expeditiously through the computer, thus giving it the ability to do more (and generate more IO).

“The disadvantage (for the HP e3000) of this thinner machine dependent hardware layer or shielding is that MPE is limited to the PA-RISC architecture. Meanwhile, HP-UX’s thicker shielding allowed it much more freedom and flexibility to move to newer faster computer architectures.”

I wonder who made the decision to tie MPE so closely to the PA-RISC chip? Did they really believe there would be nothing after PA-RISC? Or, was this actually the beginning of the end for MPE because HP did not want to spend the money to build a hardware abstraction layer that would have made future ports easier? This White Paper seems to confirm my belief that when HP realized the port to Itanium was going to mean a horribly expensive rewrite of the OS, it started to seriously consider eliminating the HP 3000. Had HP not committed to Itanium to replace PA-RISC, it would probably still be selling HP 3000s today with no end in sight.