Keeping Up the Links to the HP 3000

Sawmills and mines stood at the start of Rich Corn’s computer career, but one of the most natural resources in his life has been the HP 3000. More than 20 years ago he developed print software for the platform, and his solution has been sold as continuously as the form-feed paper that was in vogue in 1984 when he launched his company, RAC Consulting. Now HP wants to step up and replicate some of RAC’s solution in one of its last enhancements for the system, an improvement on network printing features that led the users’ voting on the last SIB ballot. It’s another example of how a third party can solve 3000 problems sooner than HP, but will then watch the vendor catch up later on.

Corn has watched the HP 3000 mature like the trees at his first computer job, timber felled for a California sawmill. When the mill put in a computer-controlled log cutting system, Corn was taken with process control. After discovering computer programming, software became the focus of his career.

He worked in a service bureau after his software schooling, a programmer developing business applications. While evaluating an IBM 4300, Corn got a look at an HP 3000 and was taken with the simplicity and power of the platform. He got the contract changed and the bureau took delivery of the first HP 3000 Corn used.

When Corn put that HP 3000 to work he uncovered some of MPE’s missing elements, such as a tool with mainframe-class power to manage print files. His skunk-works project created such a tool and ESPUL was born. He then posted one stretch of his career working for a coal mine in Olympia developing business applications, including one of the first touchscreen industrial applications and the first in a coal mine.

In 1984 Corn purchased the rights to ESPUL and formed RAC Consulting. When the time came to leave the coal mine, he went full-time into two decades of success as a vendor and consulting on the HP 3000 platform. Ten years ago Minisoft began reselling his print solutions as NP92. Now as HP plans its path to delivering better networked print services for some 3000 customers, we wanted to ask Corn about the nuances of a solution elegant enough to link printers to HP hosts for more than 20 years. HP’s networked print improvements will surface over the next two years — just about all of the remaining lifespan of the vendor’s support for that improvement. Corn’s third party alternative, like many, has an open-ended future. We spoke in late June, in the weeks before HP rolled out its 2004 update to MPE/iX 7.5.

How did you get started working on the problem of networked printing for MPE?
Networking of printers was launched by HP with the release of the first JetDirect card. Users did not take long to see the advantages of getting printers off DTCs and located where the network cable went. And it did not take vendors long to see that users wanted support for this technology on the HP 3000. It seemed a very natural expansion area for ESPUL.

How have things changed in the networked printing sector for enterprise computer managers?
The biggest change is the explosion of choice in terms of how you approach printing as an significant component of a computing infrastructure and the number of products to choose from in implementing the approach you follow.

What’s been the impact of JetDirect?
In my mind, JetDirect launched network printing and still leads the market today in terms of the combination of price, ease of use and reliability. I think it’s one of HP’s great products and very complimentary to the LaserJet and its impact on the printer market.

Where does the HP implementation of networked printing on MPE fall short today?
First, though this is going to change, PRINTPATH has always supported any printer you wanted to use with the HP 3000. Second, and this remains, PRINTPATH supports the Unix LPD/LPR print protocol for those cases where this is needed to communicate with some printers and just about any other server/host system you want to exchange print jobs with. One other advantage you get with PRINTPATH is support that is ready to solve your printing problem no matter what hardware or software is involved.

Is networked printing something that another OS, like Unix or Windows, can be put in charge of for HP 3000 applications?
If you only have an HP 3000, then I don’t think you gain that much over 3000-based products though there might be advantages in specific cases. If you have a heterogenous environment, then a centralized print management scheme probably makes a lot of sense. Many users are moving in this direction. If you have several servers, mixed Unix/windows/mainframe/PCs then a centralized, standardized printing model offers a lot of advantages.

Where can the SIB request for non-HP networked printing, as stated, fall short?
Well, I think it will be helpful to users. But you have to understand what is being provided. HP is removing an impediment to using non-HP printers with MPE. It is not “supporting” non-HP printers. To the extent that the current use of PCL by the MPE spooler is your problem, this is a good thing. If you have other issues, then this will not help. This will not help with integration with print server/host systems that require LPD/LPR.
I am a bit concerned about the exact meaning of “no...handling of CCTL information would be done” in the statement of the SIB request and making the final form feed become the user’s responsibility. If this is what is delivered, then it may well require programming changes, which will prove problematic for many users. If nothing comes out but what’s in the data file, that isn’t going to be a good thing. 3000 people depend on the spooler to print files correctly. Some may still need a tool that handles non-HP printers transparently.

HP has faced 3000 customer requests for networked printing before, requests that had an impact on your business. What are the motivations of a third party solution provider versus a system vendor’s?
The system vendor is always trying to do things as cheaply as possible. If a third party is doing an acceptable job of filling a need, the vendor will typically leave you alone. But if you have a legitimate groundswell in the user base — like they don’t like paying for a solution — pressure can be brought to bear on the vendor to do something about that.

While HP was figuring out the absolute minimum that they could do to answer that [networked printing] groundswell, I have to admit HP was as good as I could have expected in terms of how they behaved toward us in that process. The bottom line was they were going to do this. They tried to do it in the way that was the least damaging to us, but still achieved their needs. We knew how to talk about it, to highlight the things we were doing that we knew they could not.

In terms of something we could do in a solution that HP cannot, there is no such thing. The question is whether it’s in the interests of the system vendor to do it. They try to ensure their user base has the right perception of them.

Is there an advantage the smaller supplier can retain for HP 3000 sites?
One thing the smaller vendor can do is respond quicker. The big vendor may catch up, but usually we can respond the next day when a customers calls and says, “Such-and-such printer doesn’t work with my 3000.” We’ve been able to respond to those things in days.

Do you have an end of support deadline today for PrintPath, or ESPUL?
There is no deadline. As long as we remain in business we will do our best to support the users that remain with us.

What’s the latest challenge you’re facing for your customers?
HP’s new printer, the LaserJet 3500, is quite different than other LaserJets. That’s because HP has moved the rendering engine completely off the printer and into the host driver. We’ve been able to make a lot of things happen for HP 3000s because there was intelligence in the printer. Now there’s much less intelligence in the 3500. This printer wants the host driver to send it a rasterized image of the print job. The printer can accept basic ASCII text, but will not accept basic escape sequences and it ignores any print job that contains them. They’re taking the approach that this printer will be used with PCs and they have CPU cycles to burn. I think it’s a questionable design. I’m not going to add support for rasterizing print jobs on the HP 3000 at this point in time, so this will be the first LaserJet we have not supported in our 20-year history.

How has working in the 3000 community influenced your career?
The HP 3000 showed me at an early point in my career that powerful systems and software don’t necessarily have to be complex or unreliable. Poor design or unreliability is a choice, not a fact of life. The reason for IT is to support business operations and the efficiency of the HP 3000’s design and quality of manufacture allowed me to put more focus on adding value to the business. With some other systems, the focus seems to be too much on making the hardware or software work.

HP’s had a history of developing software that third parties were already selling. Didn’t you overcome this challenge once before?
Actually, no. The addition of network printing to MPE killed a vibrant and growing business for us. We then focused on the things we did that MPE did not and continued to do business on that front, but that was really just a holding action. In fact, by the mid-1990s, the MPE tool space was quite mature. The only expansion area for third party vendors was network tools to bring MPE fully in line with other operating systems. When network printing was impacted, we looked to go in this direction, but it was clear pretty quickly that HP would either provide these solutions or encourage porting of free tools to MPE. So we opted to go in the direction of getting off of the HP 3000 and into the larger Windows/Unix market and something other than printing. To be fair, other major companies have proven more likely to eat their partners than HP.

What’s been the best thing about working with MPE and the 3000?
It was a joy to work with a system designed to be simple, logical, resilient, efficient. The various designers/maintainers of MPE deserve our gratitude for creating a platform where we lived happily for many years and created some great software solutions.

If OpenMPE’s virtual lab needed any help in its efforts to keep MPE viable, would you be available to consult?
Certainly.