While not completely devoid of surprises, the Y2K cutover was the greatest anticlimax in the history of computing, as HP 3000 sites handled the transition to 2000 with relative ease. One HP engineer attached to CSY had said the flow of calls had been “really quiet” just days before Dec. 31, and the actual transition uncovered few details that HP or its 3000 partners hadn’t anticipated. Early on January 1 some customers reported their systems were displaying a STRING OVERFLOW (PASCERR 650) message, a soft error that had no impact on programs or systems. The problem turned out to be related to HP Predictive Support, the program that communicates potential problems to HP via a 3000’s support modem. It’s fixed with Predictive patch OSPKXP0 (for MPE/iX 5.5) and OSPKXT7 (for 6.0); the patches are available from HP’s IT Support Center Web site. The patch is also included in the PowerPatch 7 release of 5.5.

Some other application programs could be seen gasping in the light of the New Year. GrowthPower, a manufacturing/ERP application written in Basic and still running on some HP 3000s, caused some HP 3000s to seize up if orders were entered with 1999 dates after Jan. 1. GrowthPower’s technical support notified customers that the program will be posting incorrect dates without HP patch BSIJXA4A, a patch for the Basic compiler. Customers soon reported that the patch didn’t resolve the problem unless a site had the Basic compiler installed on the system, a rare occurrence indeed given the age of the Basic product on the 3000. The application had the following modules failing after January 1: Maintain Sales Orders, Maintain Cash Receipts, Maintain Disbursements, Process MRP, Manufacturing Transaction Reports and GL Write Your Own Report. Pivital Solutions said confirmed fixes were available for all of the problems except the Manufacturing Transaction Reports, since transactions with zero in the first date position cause errors.

HP had one other report of MPE Y2K misbehavior as we went to press, a defect in an obsolete option of the Posix shell’s date command as described in Service Request JAGac29334. If you use the option +%D, the year is reported as 100 rather than zero. It’s not technically a bug, since it has a workaround of using the more current syntax of +%x or %m/%d/%y instead. Still, HP was making a patch available in the week of Jan. 10. See http://jazz.e xternal.hp.com/year2000/patches.html for more details, and look for patch IDs PX2LX20A (for MPE/iX 5.5) and PX2LX20B (for MPE/iX 6.0) to resolve the Posix shell error.