| Front Page | News Headlines | Technical Headlines | Planning Features | Advanced Search |
Bradmark graphic
Click for Bradmark Sponsor Message News Icon

October 1999

No. 43 (update of September 1999 issue)

Welcome to our 43rd edition of Online Extra -- the e-mail update of our articles in recent issues of the 3000 NewsWire, plus items that have surfaced since we mailed our previous First Class issue (September). We e-mail subscribers this file between the First Class issues you receive by mail, updating the stories you've read and adding articles that have developed between issues.

IN THIS MONTH'S EXTRA

How to set that clock back in the US next weekend
Hear Y2K advice from HP for free
HP outlines end of life dates for 3000 systems
Patch that fork of death on the 3000
It's hard to measure AutoRAID's speed just yet
Do a fast search with the DLT4000
Go to 6.0 Express 1 for a new date intrinsic
Make plans to move off HP-IB

How to set that clock back in the US next weekend

Sites across the US will find a use for the SETCLOCK command in MPE/iX next weekend, when the country shifts from daylight savings time to standard time. For a complete review of what to do to keep your 3000 on-time, browse to the NewsWire's subscriber Web site to read John Burke's article on the time change shuffle:

http: //www.3kassociates.com/newswire/subscribers/netdigest9710.html

You need to be sure your timezone is set correctly. Shawn Gordon explained how his scheduled job takes care of that:

"You only have to change TIMEZONE. For SUNDAY in my job scheduler I have the following set up to automatically handle it:

IF HPMONTH = 10 AND HPDATE > 24 THEN
ECHO We are going back to Standard Time
SETCLOCK TIMEZONE = W8:00
ENDIF
IF HPMONTH = 4 AND HPDATE < 8 THEN
ECHO Setting clock for Daylight Savings Time
SETCLOCK TIMEZONE = W7:00
ENDIF

3000 customers are reporting that the help text for SETCLOCK can be confusing:

SETCLOCK {DATE= date spec; TIME= time spec [;GRADUAL | ;NOW]}
{CORRECTION= correction spec [;GRADUAL | ;NOW]}
{TIMEZONE= time zone spec}
{;CANCEL}

:setclock correction=10;gradual
The NOW or GRADUAL option requires both DATE and TIME. (CIERR 11705)

Obit Software's Paul Taffel reworked the company's pocket guide for MPE/iX this summer, and explained what the help text really means:

"The ORBiT pocket guide shows the correct syntax. In this case, ;GRADUAL and ;NOW may only be applied as modifiers to the DATE=; TIME= keywords, not to ;CORRECTION=."

"Take a closer look at the Pocket Guide: there are quite a few cases where we don't describe syntax the same way that MPE's HELP does."

Orbit will send you a pocket guide for $9.95 (free if you're an Orbit customer). Send them e-mail at sales@orbitsw.com to get yours.

Hear Y2K advice from HP for free

Most of you might be well finished with your Year 2000 work, but if you want to check it, dial into the audio conference HP is offering on Tuesday, Oct. 19. "Final Preparations and Best Practices for Y2K" is being held from 1-2pm Central time. HP's Installed Base Investment Protection team is sponsoring the audio conference "to give customers a final opportunity to hear their peers and HP discuss Y2K solutions, compliance and testing. A best practice sharing discussion includes a review of two customers' best practices (Boeing and Continental). This discussion also includes Y2K actions to date, contingency plans and a review of the next 2+ months." To register Call: 1-800-289-0593 or 1-719-457-2550, Reference # 775604.

HP outlines end of life dates for 3000 systems

Finding out when HP 3000 models and products go off support can sometimes be difficult, but HP makes the information available to its channel partners. We spotted an Aug. 30 version of this information out on the 3kworld.com Web site. The full list is at

http://www.3kworld.com/newsroom.asp?appmode=itemDetail&news_p k=1510

It also includes Y2K readiness reports on the 3000s. Don't be surprised to see some Classic HP 3000s on the Year 2000 safe list. You need Release 3P or 4.0 of MPE V to make those oldies but goodies run predictably after the end of December. HP doesn't support them anymore.

Patch that fork of death on the 3000

Mark Bixby, HP's 3000 engineer recruited from the ranks of system managers this summer, recently posted notice of a patch that repair problems with the Apache Web server on HP 3000s. The subject was dear to Bixby's heart, since he was the porting guru who brought the Apache shareware across to the HP 3000. Here's Bixby's notes on the patch:

"6.0 beta patch MPEKXX9A is now available to fix one of the "fork()s of death" which results in an SA614 when you fork() with one of the system files stdin/stdout/stderr redirected to an HFS filename which exceeds 89 bytes in length.

I personally encountered this one when I wrote a shell script to perform HTML cleanup on a deeply nested Apache htdocs directory tree. Other people have encountered this problem with the verbose filenames favored by Java.

This fix has already been submitted to 6.5. If you have experienced this problem on 6.0 or would just like to be proactive, contact the HPRC and ask for beta patch MPEKXX9A."

It's hard to measure AutoRAID's speed just yet

An Express 1 release of MPE/iX 6.0 will probably signal more acceptance of the latest HP 3000 operating system, one that supports the new AutoRAID-based Model 12H arrays for mass storage. Bill Lancaster, whose Lancaster Consulting helps support the new arrays at HP 3000 and HP 9000 site, weighed in with some timely comments on the new arrays' suitability for the 3000. While compatibility issues seem nil, it looks like performance guidelines are still being nailed down in field use. Here's Lancaster's analysis:

"I have been working with the AutoRAID devices on MPE for a number of months now with one particular customer. As with any technology, there is a good side and a bad side. The good side of the 12H is that it will ultimately be the most highly available high availability choice for the money on MPE. This is taking into account price, performance, RAID technology, etc. The bad side is (as with any high availability choice) there is a potential performance penalty. Also, though this element will go away with time, "official" support is for 6.0 and not 5.5. The reason for this is that the current AutoRAID Manager (ARM) software runs natively on 6.0. If you run on 5.5 you need to have a separate NT server, with a SCSI connection, to manage those boxes. Not an ideal situation.

There isn't a lot of good performance information about AutoRAID on MPE, and probably won't be for some time. The main reason for this is that the 12H is highly configurable so, unlike Mirrored Disk/iX for example, the 12H performance characteristics will vary widely from site-to-site. It's likely to be some time before there are a large number of these devices in the community.

That all being said, I'm very happy with how the 12H's are working at my client's site. We are running, I think, seven fully populated boxes there, in a variety of environments. We are preparing to move these into the primary production environment in the next several weeks."

Lancaster, who also serves on the High Availability Forum and the MPE Forum in Interex, can be reached at http://www.proaxis.com/~bill or at 541.926.1542.

Do a fast search with the DLT4000

HP has recently released a patch that gives HP 3000 sites using DLTs much faster search capabilities of the stores written onto the DLT media. Restoring individual files from a DLT4000 "can take hours due to the lack of fast-search capability," according to a message from the HP Support Center. This patch [MPEJXX0D] provides DLT fast-search for labeled tapes. MPEJXT7 provides the same functionality for unlabeled tapes."

Due to the nature of the code changes made to implement DLT fast- search for labeled tapes, labeled tapes created using this version of STORE will not be FCOPYable by default. If there is a need to create labeled store tapes which are FCOPYable, use the new ;FCOPY option on the :STORE command, which will cause STORE to create labeled tapes without fast-search enabled, allowing the tapes to be FCOPYed."

Go to 6.0 Express 1 for a new date variable

HP has reworked some of its date variables in the latest release of MPE/iX, giving you a more streamlined way of getting full dates now that the century digits are rolling over. The old !HPMONTH!HPDATE!HPYEAR, when used on 01/01/99, returns 1199. When used with a system date of 01/01/00 and 01/01/01 the variables, the concatenation returns 110 and 111 respectively.

CSY engineer Jeff Vance points out that "on 6.0 Express 1 you can use the new HPYYYYMMDD string variable.
On the above dates, you would get:
:showvar HPYYYYMMDD
HPYYYYMMDD = 20000101

An advantage of using this new variable versus concatenating the full date from HPYYYY + HPMONTH + HPDAY, is that you do not need to be concerned if your job is running at a day, month or year boundary. The concatenation approach results in the wrong final date if the day rolls to the next month in the middle of the equation.

Make plans to move off HP-IB

We've said it before in a roundup of the hardware release plans in our September issue -- but it bears repeating again: HP-IB won't be supported as of the 6.5 release of MPE/iX. Our best guess on when this release will come available is sometime next fall, but it's notable that it will mean some older HP 3000s will not run the latest version of the operating system. This kind of thing is commonplace in the world of Unix HP systems, but quite rare on HP 3000s.

The solution means moving along to newer hardware: either upgrading your older HP 3000s, or to convert any HP-IB interfaces on your peripherals to SCSI. One commonplace peripheral is the HP 7980 tape drives. HP has a part number for the kit to do this. Rocky Constantino of Computer Design & Integration (201.767.8786) pointed out the process:

"The 7980XC's can still be converted to SCSI. There is an orderable part number for the conversion kit. [88707S Opt. 081]. Be careful with regards to the firmware revision on the SCSI controller for the 7980. There was a release that was incompatible with MPE/iX. There has been a fix (firmware update) out for about six months."

 


Copyright The 3000 NewsWire. All rights reserved.