Number 77 (Update of Volume 7, Issue 10)

HP's 3000 history, and its AS/400 lessons

Sometimes the lessons of history take years to reveal themselves. That's the way it appeared to us while doing research for our coverage of IBM's attempt to win HP 3000 customers into the AS/400 and iSeries community. We looked at what HP's top executives have said about the relationship between the 3000 and the AS/400 and found a set of beliefs that still seems to be applied today. HP believed, and still does, that application suppliers call the plays on platform choices. HP believed, and still does, that customers who don't want Unix complexity or NT unreliability will be looking for an alternative. We found those beliefs in a 1996 NewsWire interview with Glenn Osaka, an HP executive who led the 3000 division for awhile before moving upward to direct all HP business server activity. Alternatives are important to serving the most complete customer base. By next fall, however, only IBM will be offering an integrated alternative to 3000 customers who simply must have a big vendor to deal with.

Our interview illustrates what some people in the 3000 community believe -- HP's intentions haven't changed much about the server, that for a long time the system's been shut off in a niche, unable to grow beyond HP's limited view of the computer's potential. We believe that some in HP wanted the server to grow beyond that niche, but the limited view has finally prevailed inside the New HP. In our six-year-old interview we saw the seeds of that limited view. We were surprised to find HP admitting the AS/400 will work for some of its 3000 customers. How many customers is what IBM means to discover. The difference is that while Osaka dreamed up a plan to lure AS/400 customers to the HP 3000, HP never attempted it. Instead, the HP 9000 got offered rather than the 3000, showing a fundamental misunderstanding of what makes the 3000 great. HP's absolute belief is that applications dictate all platform choices. For the customer creating their own applications, however, this is less true than another belief: high integration breeds economy and efficiency.

Below is an excerpt from our 1996 interview. Osaka is gone from HP, as absent as any faith in the 3000's potential. Nothing has changed about the 3000 community's disdain for complex integration, however. That's why so many have done nothing to migrate, and why IBM has a fair chance of capturing those who are being forced to move by top management.

Q. When you were GM of CSY, you told me that your intention was to pick the "low-hanging fruit of AS/400 customers" for HP 3000 migrations. What ever happened to that plan?

Osaka: We executed that strategy with the HP 9000.

Q. Why the shift?

Osaka: When we went to look for the application partners, it turned out they were very conscious of being caught by IBM on a closed platform, and having their business dictated by IBM's whims. They were very interested in creating a situation where that would not happen again. Their perception of the 3000 was that it was just like the AS/400. At one level they liked it, because it was a better packaged solution overall than Unix ever will be. On the other side, they wanted new markets, new volume and more flexibility as they went into the future.

Q. A customer tells HP they're looking for an application they can't find on the 3000, and they don't want to invest in NT or HP-UX. They think the former is too new and doesn't scale, and the latter takes too much maintenance. What do you say to keep them from investing in an AS/400 if the application is there?

Osaka: They're going to buy an AS/400. Unless you can get the volume of the applications up on whatever platform, the customer will never get the support or the latest enhancements, in order to convince the source of that software to make it a compelling choice. I hate losing a customer like that. But in the places where this is the scenario, the customer's got no choice. They're running their business, and they don't care about their computer choice.

We try to optimize for places where we think there's going to be a great opportunity for us to generate new customer activity and support the add-on requirements of our existing customers. If we become too dominant in our view of playing one of those cards, we actually sub-optimize our overall capability.

OpenMPE extends its HP World meeting

Thousands of HP 3000 customers don't plan to leave the platform at all, and their rally point for the platform's future may become OpenMPE, Inc. The organization dedicated to extending the future of the 3000 just extended the length of its meeting at next month's HP World conference. A full two hours of presentation and question and answer opportunity is now on the conference schedule, starting at 4 PM Wednesday, Sept. 25. It's a busy day, what with morning speeches from HP's CEO Carly Fiorina and president and former Compaq leader Michael Capellas, and 3000 business manager Dave Wilde's update at 2 PM. Over lunch is the SIG-IMAGE/SQL meeting.

OpenMPE's chairman of the board Jon Backus announced the extended hour of the group's meeting, noting that HP liaisons will be attending as well. Backus said he's also been invited to sit on the SIG-MPE panel the following day at noon, where HP's representatives will also attend. We'll have a full Q&A interview with Backus for our September issue, and will provide full coverage of the HP World activities in our October issue and online at the NewsWire Web site.

Glum forecast for IT spending -- a silver lining for the 3000

Analysts at Merrill Lynch & Co., Gartner and IDC are all expecting IT spending to remain mostly flat, based on research that shows many businesses are underspending their budgets this year. Companies don't feel confident yet increasing any spending. Merrill Lynch reports that spending might decline slightly over the second half of 2002. HP 3000 suppliers say spending is frozen, stopped for a range of projects well beyond just 3000-related purchases. Finding a company willing to spend on a project with a payback longer than 9 months is tough this year.

Bear-ish economic news is often unsettling, even if the downturns weed out the weaker companies and give better organized suppliers more room to grow. But the slowdown might be acting like a hibernation of sorts for the Transition picture. Making a shift off the 3000 will be costly, and with spending down, managers are not hurrying to begin. That is good news for the homesteading customer who's been waiting months to see where 3000 solutions and the post-2003 systems will appear from. The lull in spending is giving homesteading options time to firm up. 3000 advocates are concerned that the homesteading market might be too deteriorated by the time HP weighs in with its plans to enable customers to stay on the systems. These seasons of slower spending look like they may preserve the 3000 customer base -- so when budgets heat up again there will be options for both homesteading as well as migration.

A tutorial on 3000 tape to tape copying

Making backups of backups is the kind of conservative IT management that's made the 3000 so reliable. We spotted a mini-tutorial out on the Internet about the subject, written by Allegro Consultants' Stan Sieler, whose company is getting into the backup business with ORBiT Software. The advice helps a 3000 manager think through what level of confidence they need when copying tape to tape. Sieler reports:

There are three ways of copying tapes:

1. With a program that understands the original tape format/contents;

(Note: it must either capable of handling reel switches at different points in the output than in the input *or* the output tape may need to be at least as long/large as the input tape.)

2. With a priv mode program that correctly copies generic tapes;

(Note: the output tape may need to be at least as long/large as the input tape.

3. With a non-priv mode program that copies ordinary tapes, but
will (usually quietly) fail to correctly copy some tapes;

(Note: the output tape may need to be at least as long/large as the input tape.)

Consider what happens if the output tape isn't *quite* as long as the input tape, and the input tape was 100 percent full ... you've got a problem unless the tape copying program can properly handle this case. For STORE tapes, that means emitting a "reel switch" marker at the correct spot in the output tape, asking for another reel/DDS/DLT, and synthesizing a correct "start of reel" record and a correct directory list for the start of the next output reel, then continuing the data from the end of the input reel. If the input was a multi-reel tape set, then when the end of the input reel is hit, the program must properly handle (perhaps by ignoring) the "reel switch" information from the input reel, and the start-of-next reel data. Whew! This isn't easy!

That's why I second Michael Berkowitz's suggestion: use the backup product's own "copy a backup set" feature, if it has one. (For STORE tapes, our X-Over product copies backup sets from one set of media to another.)

What if you don't have #1?

Then you have to use a generic tape copier.

But ... by definition, a generic copier won't know how to handle reel switches, so it would have to treat a multiple-reel set (STORE, BackUp, or whatever) as a bunch of separate reels.

This means that if an output reel/DDS/DLT isn't large enough to hold the entire input reel's data, the copy fails.

Reel/DDS/DLT tapes are sold in specified lengths...but that doesn't mean that two DDS tapes of the same ostensible size are 100 percent the same size. A variation of as little as a couple of inches, or a variation in the condition of the media, could result in two apparently identical tapes having a different capacity.

That's why #1 above is better than #2 or #3.

But, a second problem rears its head: the size of the data records on the tape. The MPE file system FREAD/FWRITE intrinsics (and POSIX read/write) have a maximum tape record size of 32766 16-bit words, or 65532 bytes ... or about 4 bytes short of 64 KB.

This means that if a tape has a record of exactly 64 KB, then a maximum FREAD (or read()) will quietly return 65532 bytes, and it won't tell the program that 4 bytes were lost. If the tape record was 70 KB, a maximum FREAD will quietly return 65532 bytes, and it won't tell the program that 6 KB were lost. (BTW, the next FREAD will start at the start of the next tape record.)

Some backup programs can create tapes using sendio (which requires priv mode). sendio allows extremely large tape records.

Type #2 copy programs use sendio to read/write, bypassing the file system limits.(Our TAPEDISK product, which includes TAPETAPE, is this kind of copier.
Info at www.allegro.com/products/hp3000/tapedisk.html)

Type #3 copy programs use FREAD/FWRITE, and are therefore subject to file system limits. HP's TAPECOPY is this kind of copier. Info at: jazz.external.hp.com/src

It's important for all three types of programs to always try to request a few more bytes than they expect to get. E.g., if I'm copying a tape that I think has 8Kb records, I'll do FREAD (or sendio read) requests of 8Kb + 2. If I get 8Kb+2 bytes back, then I report an error: I encountered a record larger than expected. If I had only requested 8 Kb, I'd never know that a larger record was on the tape.

Patchwatch: 6.5 users get more stable Telnet

HP's got a new patch out that appears to resolve lots of service requests around Telnet on the HP 3000. Patch PTDGDK4A went into General Release last month, resolving 29 SRs filed on Telnet. It's also the vehicle to provide echo option 45, known as Advanced Telnet because of its improved performance. Look up the patch details on the HP ITRC Web site www.itresourcecenter.hp.com. It's hard to say how many more patches on Telnet will surface from HP and gain General Release status, what with a general slowdown in customers' willingness to test the patches.

Robelle training arrives in the East

Jeff Kubler is offering training in Robelle's Suprtool next month, with classes offered out of the TechGroup University training facility in Hagerstown, Md. The training offerings in the week after Labor Day include a Sept. 12-13 class on using HP Eloquence with Suprtool and migration. Get details at http://www.techgroupmd.com or at www.kublerconsulting.com

Kubler is also offering training in Qedit from Robelle. That company has taken a pair of directions in the months following HP's intention to exit the community. While Robelle's enthusiasm for Eloquence is obvious from its columns in the NewsWire, the supplier is also ready to support customers who intend to remain on the 3000 regardless of HP's exit of the market. A recent press release from Robelle promoted its homesteading directions, saying that Robelle is a 3000 vendor, and will remain a 3000 vendor, with the flexibility to help your 3000 accommodate whatever your IT plans envision.

CEO Bob Green said, “I started on the HP 3000 before the first system was shipped from HP and I plan to be there long after the last 3000 is shipped. The 3000 and the people who know and support it will be around for a long time. Robelle, along with other committed friends of the HP 3000 like The 3000 Newswire, will continue to act as hubs for 3000 information." Be sure to check the Robelle Web site for 3000-related news.

Amisys sets fall user group meeting

HP 3000 Amisys users will get together for a three-day meeting next month to preview AMISYS Advance -- the replacement for the MPE-based healthcare application -- discuss conversion plans "and perhaps even seek advice from our fellow users on HIPAA implementation," according to user group official Kathy Childers.

The meeting is now scheduled for September 17 - 19, 2002 in Falls Church, Virginia at the Fairview Park Marriott. Rooms at the Amisys group rate of $129/night are available from September 16-19. Make reservations before Tuesday, September 3 to receive the group rate of $129/night for single or double occupancy. To make reservations by phone, call 800.228.9290.

Amisys users must register for the meeting by September 3, a $160 registration fee for all attendees. AMISYS LLC requests that payment be made at the time of registration. Please send payment to: WO180 AMISYS, LLC PO BOX 7777 Philadelphia, PA 19175-0180. In the left hand corner notate: AMISYS User Group Conference.