Jim "seMPEr" Wowchuk wrote:
 
<snip>
 
>Imagine if HP marketed the HP3000/MPE/Image the way Microsoft markets Windows!
>
>1)  HP would include the 'C' compiler with all systems so that anyone even
>    considering developing would have the minimum tools necessary to talk
>    with the rest of the world.  Adding TCP/IP was a good start but they
>    stopped too short.  Make the 3000 popular for the same reason Unix boxes
>    were - a wealth of free & low-cost software through the collaborative
>    efforts of an all too willing user-base.
>
 
<begin rant mode>
 
A GREAT idea - and it wouldn't cost HP much.  One of the problems facing the
Navy project that I work on is that there is almost zero budget for
purchasing compilers, utilities, etc. for existing systems.  The existing HP
3000's (which are in need of upgrades and must either be upgraded or
replaced) don't have C compilers, but the competition includes a C compiler
with their hardware (or at least the deal they will make with the Navy
includes it).  It is hard to make good use of the POSIX feature of MPE/iX
without the C compiler and the POSIX developer's kit.  If HP looses RFP's to
other vendors because there are not enough "off the shelf" products
available for the HP 3000, then HP should court software developers.  One
small and inexpensive step would be including the C compiler and POSIX
developer's kit with FOS.  A byproduct of including the C compiler and POSIX
developer's kit with FOS would be that companies who use the HP 3000 and are
in businesses other than software development would have the opportunity to
develop new applications in the POSIX environment.  Some of those
applications may even make make names for themselves and make it to market.
The Virginia Tech Library System comes to mind as an example of a "classic"
(CM) application that sold many HP 3000's years ago.  Another small step HP
could take would be the often requested two user HP 3000 (you can't test
locking and other "sharing" environments very well with a single-user system).
 
>2)  Providing a RPC run-time license would not only be free, but highly
>    promoted for intersystems compatibility.
>
 
Hmmm.  Maybe with RPC run-time more HP 3000's could be plugged in as
replacements for other vendor's hardware.  Hmmm...
 
>3)  Ship millions of CDs to anyone that wants to signup for a relatively
>    low-cost developer program.  Include on these CDs all general manuals,
>    system guides, internal training, AIF specs and internal manuals for
>    everything from Debug Macro languages through Patch process languages.
>    Include some products like AIF libraries, RPC developer, etc.
>    They might also record major conference papers, presentations and even
>    screen simulators.
>
 
One of the ways the "classic" HP 3000's grew was through features added by
software developers who wrote PM code.  The AIF's have put a little crimp in
what software developers can do, but system stability is improved and the
fear of what will happen to your third party code when you update MPE is
greatly diminished.  Funny, but the more people know of HOW something works
and WHY it works the way it does and what TOOLS there are available, the
better the applications end up being.  I see this with the Navy all the
time.  The people who use the GFE (Government Furnished Equipment) and GFM
(Government Furnished Materials [like manuals]) write code on one level.
Those who get frustrated with using MPE V/E manuals on an MPE/iX system
running 5.0 and shell out their own money for manualy (which they keep at
home so they don't "disappear") write code on a far better level.  Imagine
the improvement in HP 3000 applications if the average programmer had access
to current manuals from his MPE session.  And I don't mean via a Novell
server with the HP manual CD (or CDs) on it.  I don't know how reliable
Novell is for others, but the Navy's Novell servers crash frequently.  So
frequently that with about sixty HP 3000's in the network and two Novell
servers (used mainly for GroupWise email), the trouble desk logs more
"Novell server crashed" problems than "HP crashed" problems.  Make them
available through HELP.  Make them available as HTML pages.  Do something so
that the manuals are available from the software developer's PC (is there
anyone still coding from a terminal rather than a PC?).  In summary, MAKE
GOOD SOFTWARE DEVEOPMENT EASY!
 
>4)  Forget about support! Well almost...if there is a large enough user base
>    out there who have all the necessary support material, then there's a
>    good chance they will be able to solve a number of the problem before
>    some of the HP technots.  I'm constantly amazed at the knowledge out there
>    already, even with the current very limited access.  If this collective
>    knowledge can be channelled (eg Developer programs), then as demonstrated
>    already with this list, the results can be amazing.
>
 
Perhaps broaden support.  There are many customers for whom the Response
Center is their only recourse.  They must be able to say "because the HP
expert at the Response Center said so" when they walk into a meeting.  I see
no end for the Response Center.  Instead there could perhaps be more contact
between the Response Center and the lab engineers.
 
In my personal experience, contact between the Response Center personnel and
the lab engineers was greater in the 70's and 80's.  Sometimes I'd get a
call directly from a lab engineer when I had a particularly nasty problem.
I don't think I've received a call back from a lab person relating to a
Response Center call since '88 or '89.  I can understand that the lab people
need to be working on new software and software maintenance, not "how do I"
calls, but they are the people with the source code and for some problems,
they are the only people who will have the answer.
 
Then there are others who don't have access to the Response Center.  This
list works VERY well.  I'm convinced that most of the great minds working
with the HP 3000 (both inside and outside HP) frequent this list.  HP's
input to this list and solved many problems around the world.  Hopefully,
our problems, questions, and "what if's" have helped HP improve MPE/iX.
 
>5)  Don't penalize people for wanting to learn more about the HP3000 by making
>    advanced training classes excessively dear.  Sure, make some money on the
>    rudimentary ones, but provide others the chance to do the same. Make
>    advanced technical advice through the wide media.
>
 
I remember when HP encouraged people to learn more about their HP 3000.
There were internal classes open to the HP 3000 customers also.  I'm sure
that there are still a number of us left that went to those classes and
became die-hard HP 3000 fans as a result.  Those classes opened up new
possibilities for us.  HP personnel described the inner workings of the file
system, dispatcher, interrupt control stack, ... etc., the "guts" of the HP
3000 over three weeks.  The classes were not cheap, but they were good, and
a lot of utilities and products were launched by people who attended those
classes (read: "more off the shelf software").  If I remember correctly, Ben
Norton of Boeing (author of many utilities) attended the Internals class I
attended in spring of 1980.
Remember a book titled something like "Computers and their Preists"?  Give
one programmer a CD-ROM with a compiler he/she has never seen before, and
specs for a program you need.  Give another programmer a CD-ROM with a
compiler he/she has never seen before, a one week class, and specs for a
program you need.  Which will most likely have the program completed and
debugged first?  Which programmer will be most likely to come back and say
"by the way, while I'm at it I could add a feature to ..."?
 
Wow!  Look at the time.  Guess I'd better get back to rebuilding Windows
(from my backup tapes) so I can once again try installing that "educational"
(yea, I'm learning some new words myself!) Windows program for the children.
Gee, if only there were some printed documentation other than "1) Insert
CD-ROM in CD-ROM drive.  2) From Program Manager, File, select RUN.  3) type
D:\INSTALL.  4) Enjoy!", or maybe a "README.TXT" file on the CD-ROM that
would note all the .INI files the INSTALL process destroys.
 
<end rant mode>
 
John
--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.
 
The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.