Wayne,

> When I was working for the first HP-3000 based credit union (TECU in early
> 80's), virtually all of the very large credit unions were moving towards
> Summit's (then known as ATA) software.

Did you hear me groan when I read the first line of your response?

TECU, later to become Wescom, deconverted from the HPe3000 based Summit
system last year, and went to a unix based system (RS6000) sold by Simitar.
They maintain one 979/300 for old history that they chose not to convert to
the new system, and I helped them migrate all their 3000 data onto an XP
array a few weeks back.  They use an EMC array and wanted to free up those
LUNs for use in their production environment.

Operationally, they are happy with their new system, with a few glitches
(can you say manual dial of modems for file transfer, or three steps for FTP
of a file?).  The fact that the system is new (i.e. no years of use and
abuse to degrade performance), and that their vendor is still throwing them
parties and giving them backrubs may have something to do with it.  Of
course, I could write a thesis on the "senior management raised on one
platform who insist on making a new system behave like their old system and
then bitch about the effects of their mindset, until they can convince their
board to convert to the system they already know" model, but I'm not bitter.
Really, I'm not.

Anywho, the largest credit union in the US (Navy Federal Credit Union) uses
its own home grown system, and employs a nice chunk of people to maintain
it.  Summit has a (higher than?) proportionate slice of the "Largest 100"
credit union pie, which I feel is based more on the flexibility and
scalability of their product than anything else.  A credit union can
literally become a Summit client when they have 1,500 members and grow with
the software until they have 500,000 members, with nothing but the requisite
hardware upgrades (and some accompanying operational changes) to accomplish
it.  (Actually the smallest InHouse client I ever worked with had just under
5000 members, but the idea is valid).

When I worked for Summit, it was as an analyst in their Installations
department.  I only got to see other vendors' systems when they were in
their death throws, so my experience is jaded.  I was always impressed with
the interactions I had with clients and their reactions to Summit's
software, especially when I got stuck wearing the "REPORT BOY" costume.  A
converting client's request "We need a report to show us members who do X."
would get the response "No you don't because Spectrum won't let your tellers
do that."  (Making excessive contributions to IRA accounts comes to mind, or
withdrawing funds below the defined minimum for the account type.)  The next
words out of the client's mouth were always "But we always get that report".
I especially loved the accompanying blank stare.

Summit has been working for some time on migrating their product to the
HP9000, HPUX, Eloquence model.  The convenience to the end user base (i.e.
changing to a different terminal emulator, but with all the screens staying
the same) will probably be the deciding factor in most clients staying put.
The added benefit of being able to get I.T. staff with knowledge of the
system (at least the operating system) more easily is a selling point as
well.  As well as, a known vendor, a known product offerring, and a history
in the industry.  In general, I would expect a very large percentage of
Summit clients to migrate to A or N class boxes next year, stay on MPE for
some time yet while Summit works the bugs out of the 9000 product and the
migration process, then migrate when the time is right.

I applaud Summit's efforts to date, and expect that these will be one of
many (groups of) steps they take with their software.  Keep in mind that
they have twenty plus years of development on the 3000.  There are probably
quite a few aspects of the software that were designed for the 3000/IMAGE
world which initially will have to be duplicated on the 9000, and then will
be engineered back out because they don't belong anywhere but on the 3000.
This will take some time, but Summit will get it done.

The lousy part about it all is the "Burn me once..." issue.  Summit will
probably target their on going development (and the removal of the 3000
oddities) to make their entire product line as platform independent as
possible.  By definition, that means taking advantage of no platform
dependent strengths.  The 3000 had many of these quirks, and Summit has used
most of them to its advantage.  Going forward (and to keep from having to do
this again), they will have to drop that idea altogether; while a software
vendor designing their product for (as an example) an IBM proprietary
version of Unix, can continue to design their code to take advantage of
their platform and won't have to worry about the rug being pulled out from
underneath them anytime soon.   Again, I'm not bitter, really.

In the long run, Summit will come out of this stronger.  Only Focus XP
(another credit union software vendor) has gone through anything like this
(when they started a few years ago to rewrite their entire product in XML).
Summit has been given the chance to take twenty years of experience and
redesign all the "twenty years growth worth of cludge" out of their own
product.

I really do hope that HP is taking better care of its ISVs than it seems to
be doing for its "little" clients.  Firms like Summit, Amisys, and
Smith-Gardener made the 3000 sales, but also developed a large group of very
loyal customers for HP.  Even if HP decides to drop the product, I hope they
are taking steps to help the firms that got them the customers to begin
with.  The effect is felt more clearly on the ISVs than on HP, but being an
"HP Partner" should still mean something.

By the way, BANK is a four letter word.

Rs~

Russ Smith
Systems Analyst, Cal State 9 Credit Union, Concord CA, rsmith AT
calstate9.comm
Programmer/Analyst, Problem Solved, Vacaville CA, rsmith AT cu-help.comm
3000L/SU-Talk participant, work AT rsmith.orgg

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *