Ron writes:

> Wow. It's been awhile since I've had an idea called both "rubbish"
>  and "dumb" in the same draft. Feels like I may have hit a nerve.

While my previous posting came off harsher than I intended it to be, I stand
by my arguments. If you hit a nerve with me, it was the idea that certain
third-parties deserve a protected market. That's the idea that I deemed
"rubbish." And I'll say it again, even though I mean absolutely no personal
insult.

Any third-party worth his salt knows from the very first day that his product
is likely to only have a limited lifetime when he offers a stopgap solution
(something such as a network printing solution), before HP does itself. If he
isn't prepared to abandon that product, or canabilize it, at a moment's
notice, he hasn't done his homework. One of the central themes taught in
business schools for the last twenty years have been case studies of all of
those organizations and companies that continued to manufacture and build
products (vaccuum tubes, natural rubber tires, etc.) long after they should
have abandoned them. When the adaptive topography shifts and the market
disappears out from underneath you, you either adapt or die. There's nothing
unfair about this process. As Tom Brandt wrote, "That's life".

"HP is not in business to provide marketing
opportunities to other companies, it is in business to satisfy its own
markets, and must put its interests first, or see itself founder.  If HP,
due to market demand, decides to plug a hole in its products that was being
filled by thrid parties, well, that's life."

The more fundamentally important a stopgap product you build, the more likely
that it will be supplanted by a major vendor's solution. If you didn't
anticipate this event when you began, it would be hard to call you a
businessman.

The genius of Microsoft is not their ruthlessness, as their competitors like
to trumphet, but their capacity to look down the road a little further and be
very attentive to potential shifts in the adaptive topography. Bill Gates
pays an enormous amount of attention to the history of technological shifts,
if for no other reason than he was a party to one of the greatest shifts in
American corporate history, if only partly by accident, and he knows how
easily it can occur, especially when no one is paying attention. No one in
the world in 1980 would have ever anticipated that a small company the size
of Microsoft (12 people) would have unseated IBM's dominance of the computer
industry just a very few years later.

Microsoft, at the moment, is extremely worried about the most recent
technological shift: the rise of internet-based applications. While it is
common practice for Microsoft to say something of the nature that they don't
have the slightest idea how they're going to convert their Office-based
products (their second largest revenue stream) to the web, or how they're
going to make any money in this new paradigm, in this case, I believe them. I
think they're as confused as everybody else.



>  I'm just guessing, but it looks like somebody is relying on MPE's
>  networked printing for an application and needs it fixed.

If you're presupposing that it's us, it's not.

Everything we do works well with our applications. Further, I am a person of
nearly infinite patience. So long as printing begins within a tenth of second
after I press the RETURN key, I'm perfectly happy. Anything that takes longer
than that, and I begin to get antsy. All in all, I am extremely happy with
network printing on the HP3000. During the last year, I have helped convert
at least a hundred sites to solely HP3000 network printing.

The source of my irritation and embarassment are the PJL messages that clog
up the system console when printing to any of the "modern" printers, at two
messages per print job:

========================================

15:04/42/Output spooler, LDEV #300:  The PJL information returned from
the printer contains a syntax error.  The first 52 (max) bytes are shown:
@PJL USTATUS DEVICE
CODE=10001
DISPLAY="MPE/iX O17
Native Mode Spooler message 9621

15:04/42/Output spooler, LDEV #300:  The PJL information returned from
the printer contains a syntax error.  The first 52 (max) bytes are shown:
@PJL USTATUS DEVICE
CODE=10023
DISPLAY="PROCESSING
Native Mode Spooler message 9621

=========================================

I have been apologizing to our customers about these messages for a year and
a half now -- and I'm beginning to tire of it. It is behavior that is wholly
unnecessary and completely inappropriate to a system that I consistently tell
our customers is the finest commercial database transaction engine available.
Moreover, the spooler problem has to be relatively easy to correct, somewhere
between a day's and week's worth of work, and that makes its continued
existence all the more unacceptable.

To be fair, the problem isn't only CSY's. The various divisions that build
PJL/PCL-based printers cannot seem to get their act together. There is a
simplified schematic of our LAN environment that we use for training purposes
at:

     http://aics-research.com/qc/schema.html

We've constructed our office as a model to be emulated by our customers,
composed of the simplest, most efficient, most responsive, TCP/IP-based LAN
architecture that you can now put together. Every PC can print to every
printer, using HP's JetAdmin software. Every HP3000 can print to every
printer, using the 3000's network printing. And every PC can talk to every
HP3000 using telnet. There is no network operating system. There are no
slaved printers. Everything is as simple as it possibly can be. And it's
unbelievably fast and cheap, even running at only 10Mbs.

If an HP3000 prints to any of the HP4M printers, there are no error messages
of any sort, displayed anywhere. Indeed, if an HP3000 prints to a non-HP
device, such as our Tektronix color laser, we have no errors because we have
an external HP JetDirect EX card connected to the parallel port of the
Tektronix. But, if an HP3000 prints to an HP4000, you get the messages
displayed above. But as I said earlier, these are only irritating problems.

Much worse is the fact that some HP printers won't work at all. The HP755CM
large format color printer (the one that was used for creating the World's
Largest Poster) simply won't work with the 3000's network printing. Although
the printer is shown in the schematic as connected directly to the network,
in reality there is an external JetDirect EX card (an additional $230 per
printer) in between the network and the printer, connected to its parallel
port. More recently, two of our customers have purchased HP's new 8500DN
color laser (a $6000 to $10,000 device, depending on options). It too seems
incapable of working with the HP3000 -- and I have recommended to both
customers to abandon the internal network connection and purchase JetDirect
EX cards and connect them to their printers' parallel ports. Similarly, I can
turn an HP4000 into a well-behaved printer by performing the same trick.

The JetDirect EX cards behave well with the 3000's network printing,
emulating exactly the behavior that you would expect (and do get) from an HP
LaserJet 4M. For the last several months, my recommendation to our customers
has been not to purchase their printers with internal network cards, but
rather buy auxiliary JetDirect EX cards and connect them to their printers'
parallel ports. It's a workaround, but it provides for a mechanism to create
a well-behaved network printing solution on the HP3000.

Of interest in all of this is a fact that only adds to my irritation: in
constrast to the HP3000's network spooler, the JetAdmin software on our PCs
prints easily and well to all of the devices, in their native modes of
operation.


>  I hope this fix doesn't slow down any of the other things customers
>  are still waiting for: support for MPE Java classes on the 3000
>  (available, but not supported). A secure Web server. Mirroring the
>  system_volume_set. A supported C++ compiler, to let application
>  developers port software to the platform. An object strategy built
>  into the 3000's operating system like CORBA or COM (only recently
>  available through a third party product). FTP that works like the
>  rest of the world's. Advanced Telnet. Access to ODBC directly from
>  TurboIMAGE, without using Allbase/SQL. Some are in development, but
>  none delivered yet.

Of all of the things mentioned in this list, nothing will affect more
customers than a well-designed HP3000 network printing solution. There is no
behavior more fundamental to running a computer than being able to have it
print well and reliably.

Wirt Atmar