Click here for Integration Alliance Sponsor Message

MPE/iX 5.5: Too Good To Wait Any Longer

NewsWire Test Drive

Review by John Burke

In the September Test Drive I described some of the less publicized features of MPE/iX 5.5 and gave my first impressions of the release as a whole. My basic thesis was that MPE/iX was much more than an interim release and everyone should update as soon as possible. I promised to write more after the user community had gained some experience and re-visit my thesis.

If you are not sure what you gain by updating to MPE/iX 5.5, get a copy of my Septem ber article and the MPE/iX 5.5 Communicator and read both. If after that you are not chomping at the bit to update, there is no hope for you.

I have been running on MPE/iX 5.5 for about seven weeks now without any problems that would impact my daily production. MPE/iX 5.5 is not without flaws, but considering the complexity of MPE/iX and all the interdependent subsystems, this first release of MPE/iX 5.5 is amazingly stable. It is a tribute to everyone at CSY who had a hand in the release.

I know many people have been holding off updating to MPE/iX 5.5, preferring to wait for the first PowerPatch release to fix all the bugs in one place.

PowerPatch 1 (C.55.01 and officially titled "MPE/iX 5.5 Express 1 Power Patch Release") was released in mid-November. It contains support for new systems and peripherals and the full functionality of the Telnet/iX Server, closing a somewhat embarrassing hole in the original release (See related story in this issue). According to HP, "There has not been a significant accumulation of defect repair reports against MPE/iX 5.5 at this time. This PowerPatch does not contain fixes."

Actually, this statement agrees with my experience and the information I've collected from my various sources. The first PowerPatch containing bug fixes will probably not hit the streets until at least mid-January.

Since PowerPatch 1 does not contain bug fixes, it is worth looking at some of the more prominent problems and where they stand in the workaround/fix cycle. If the problems apply to your environment, you'll have to make use of workarounds or install patches as they become available (Check at http://us-support.external.hp.com for patch availability).

A word of caution: in addition to verifying the media, be sure to check your SUBSYS tape to ensure it contains all the products you are entitled to have. Be especially careful if you have purchased anything since your last general update.

In the past several years I've twice received SUBSYS tapes that were incorrect. One time it was missing IMAGE/SQL and another time NetWare/iX. Doing an update with either of those SUBSYS tapes would have been catastrophic. Taking a few minutes up front to check the accuracy of your SUBSYS tape could save you from a nightmarish OS back dating.

Network printing issues
Everyone, including HP, has been saying that the network printing solution built into MPE/iX 5.5 is limited. Now that 5.5 is out in the field, people are discovering just how limited. The limitations are not so much in functionality, but in the configuration supported. Provided you have the correct equipment (either a printer with an HP JetDirect card or an HP JetDirect EX box, or clone if any exist), setting up network printing is easy (npsamp1.pub.sys contains much of the information you need). And, with the exception of the leading blank page issue detailed below, it works well and interfaces well with the MPE/iX spooler.

Many people, myself included, assumed you could get an HP JetDirect EX with a serial printer interface. Wrong. Some also assumed that the JetDirect EX box gave you page level recovery. Also wrong.

If you want to hook up serial printers (say a 256x), you have two choices: place a parallel-to-serial converter between the JetDirect EX and your printer, or convert your printer to parallel (fairly expensive on the 256x, assuming you can even still obtain the conversion kit). In either case, you have a "dumb" network printer, whose only form of error recovery is to reprint the entire file. Page level recovery (i.e., :SPOOLER n;SUSPEND;NOW followed by :SPOOLER n;RESUME;OFFSET=-5) is only available for HP LaserJets (and clones) that support PJL. And PJL is only supported by the newer LaserJets. (See the 5.5 Communicator for a list).

Third-party network printing solutions are much more feature rich and offer interfacing to a much broader array of equipment.

Blank page output when
printing to network printer

This has been a known problem in MPE/iX 5.5 for a while, though as of this writing, there is no patch yet available. There is evidence that it was not initially viewed as a critical bug. Whether it is critical for you, probably depends on whether you use preprinted, numbered forms, and/or print in duplex and whether your applications use pre-spacing (COBOL for example). There is no practical workaround. There have also been some reports of similar behavior from serial printers, although I haven't personally seen it on either of our two serial printers. And anyway, network printers are controlled by OUTSPTJ.PUB.SYS, where the problem is known to be, while all other printers, including serial printers, are controlled by OUTSPOOL.PUB.SYS.

HP's Service Request 4701-328658 explains in more detail:

"OUTSPTJ does not distinguish control operations from data. So the initial FOPEN "sets" the TOF flag, but the data sent by MPE in response to a user's ENV= specification, or when the spooler processes a user-specified setup_file item, resets the TOF flag. Consequently, when the spooler processes the %61 which precedes the first user data in prespace mode, the spooler thinks we are no longer at TOF, and allows the low-level printer TOF codes to be sent to the printer. Since no data has been printed since the FOPEN, the result is a blank page.

"... this problem will occur for all user data created in prespace mode, and whose first record has a CCTL of %61. This is because the spooler always sends some environment information. Either the user has specified an ENV=, and that information is sent; or s/he has not, and the spooler has sent information from the setup_file specified in NPCONFIG.PUB.SYS; or (if no setup_file item exists), the spooler has sent setup information corresponding to the default MPE environment (landscape, 132 chars/line, 60 lines/page, etc.)."

A patch, MPEJXC1, is being developed for this defect.

Spooler error message
If you are on 5.5 (even PowerPatch 1), you've seen this one. At the end of printing ANY spoolfile the following appears on the console:

The last name component of the pathname does not exist ... HP DIRECTORY MSG 1

The official explanation is: "The cause of this problem has to do with internal changes to the code that causes a new 'checkpoint' file to be inserted into the directory to be saved as a 'permanent' file. The code checks that this file name isn't already in the directory and the directory routines properly return the above status. The changed code returns to the spooler in such a way that the spooler believes that this is an error and so reports it."

This is really annoying even though it causes no damage. And a bad PR move since it affects everyone. Shops with considerable printing have their console dominated by these messages. If you are not aware of this bug and first see it after updating to 5.5, the message is rather ominous sounding.

Fortunately there is a patch available, MPEJX99A as of this writing. (You should always check to see if there is a later patch). Too bad it was not made part of PowerPatch 1.

Back-referencing and ENV=
The following fails on 5.5 but works fine on 5.0 and earlier:

:file myenv=myenv.pub.acct
:file mylp;dev=lp,1;env=*myenv

This works on 5.5:

:file mylp;dev=lp,1;env=myenv.pub.acct

The first example does not put an ENV entry in the spoolfile.

This problem is not directly related to network printing though it may have crept into the code when modifications were made to handle network printing. The first report I saw of this problem involved serial printers connected to a DTC. The stated reason for using back-referencing was to reduce the size of file equations and to allow the easy switching of device types (i.e. Type 26 to Type 18).

An SR has been opened to track the problem: 4701-339614. A suggested workaround is to use CI variables instead of file equations:

:setvar myenv "myenv.pub.acct"
:file mylp;dev=lp,1;env=!myenv

Ping o' death
This is not strictly an MPE/iX 5.5 issue, in fact it is not even an MPE-only issue. Virtually any system, including even routers, that accept PING can be brought down if PINGed from a Windows 95 or Windows NT machine with a sufficiently large packet. (For complete details, including patch availability and temporary workaround strategies for numerous systems, check out "The Ping o' Death Page."

As one commenter to HP 3000-L noted after testing his MPE/iX 5.5 system, "That puppy will get a system abort in a New York minute." MPE/iX 4.0, 5.0 and 5.5 are known to be vulnerable. If your system crashes with "SYSTEM ABORT 3890 FROM SUBSYS 201" then you've probably been PINGed to Death.

As of 11/22, patches for MPE/iX had not yet been released . Patches are available for HP-UX,... sigh.

NMMGR and NS/VT: Ooops
One of the great new features of MPE/iX 5.5 is the dynamic configuration of DTS/TIO devices without rebooting the HP 3000 host. If you run NMMGR, make changes and VALIDATE DTS, you are now asked whether you want to make the changes effective immediately or later. At this point, if you are using a networked PC, you are screwed (a technical term). No matter what you answer, or even if you try to break and ABORT NMMGR, your session hangs and the only alternative is to abort the session from the console or somewhere else.

The workaround is to use a serial terminal or PC for NMMGR. As of 11/21, no patch had been released.

Documentation
In my September article, I took HP to task over the sorry state of the MPE/iX update process documentation in general, and, in particular, the "HP 3000 MPE/iX System Software Maintenance Manual". I pointed out that I was working with a draft version of the manual and hoped that the final version would be vastly improved. I am happy to say that this is the case in general. Many of the most obvious typos and other errors have been eliminated. The typos I still found would not cause a reasonably experienced user any problems.

However, portions of the manual are still confusing even for experienced users (for example, the exact order of events in "Creating the CSLT Using AUTOINST) and the task list for "Re-Install Using a CSLT" still goes horribly wrong toward the end. Obviously, you should take the time to thoroughly review the steps for any task you may need to perform. If anything is unclear, call the RC first before you proceed. It is a whole lot easier to get an answer at 2 p.m. on Friday than it is at 2 a.m. Sunday.

Interesting features, undocumented?
In the past, issuing the SHOWVAR command with no "pattern match" string would only display the users job/session variables. As of 5.5, issuing SHOWVAR from a networked PC yields, in addition to the job/session variables, the following "HP" variables:

HPSTDIN_ACCESS_TYPE = NS/VT
HPSTDIN_TERMINAL_TYPE = 0 (T_DATA_ENTRY(4)) HPSTDIN_TRANSPORT_TYPE = TCP/IP
HPSTDIN_NETWORK_NODE = JPB1.CONSHOHOCKEN.CCC HPSTDIN_NETWORK_ADDR = 192.1.1.101
HPSTDIN_LINK_ADDR = not set yet...
HPVT_CLIENT_VENDOR = WRQ_CONNECTION_3000_FOR_WINDOWS HPVT_CLIENT_OPSYS = MS_DOS
HPVT_CLIENT_MODE = MESSAGE_MODE
HPVT_CLIENT_TCP_PORT = 1635
HPVT_CLIENT_LDEV_NUM =
HPVT_CLIENT_JOB_NUM =
HPVT_CLIENT_JOB_NAME =

These are not CI variables, but are apparently being set by NS (the variables do not exist on serial devices). As you can see, they contain some interesting information.

Also, STORE seems to now explicitly show at the end of its listing each TurboIMAGE database stored (number of files stored and number of files not stored!). I discovered I had several orphan root files on my system just by looking at a STORE listing (the nonexistent datasets could not be stored).

Conclusion
While it appears that more sites than usual have become early adopters of MPE/iX 5.5, not even waiting for the first PowerPatch, others are holding back for various reasons. As I stated in September, MPE/iX 5.5 is much more than the usual interim release. And PowerPatch 1 closes the functionality holes that existed in the initial release of MPE/iX 5.5. There appear to be no real show stoppers, you can go directly to MPE/iX 5.5 PowerPatch 1 from MPE/iX 4.0 or MPE/iX 5.0. Once you are on MPE/iX 5.5, the patch process is much easier and less time-consuming. And, of course, configuring peripherals is a dream come true.

My September thesis has been proven. All in all, HP did a great job with MPE/iX 5.5.

John Burke is a longtime HP 3000 columnist and contributing editor to the 3000 NewsWire, editing our net.digest column. John has 18 years experience on the HP 3000, works as systems manager for Construction Computer Center and can be reached at tcdn96a@prodigy.com.


Copyright 1996, The 3000 NewsWire. All rights reserved.