• Subject: Re: Computerworld: Scarcity of AS/400 resources a concern
  • From: email@xxxxxxxxxxxxxxxxxxx (James W Kilgore)
  • Date: Thu, 11 Mar 1999 00:41:21 -0800
  • Organization: Progressive Data Systems, Inc.

Thanks for the "heads up" on the article.

IMHO, Walt Ling is singing the company song.  As a former BP, (did I
stress former?) being told to sell the sizzle instead of the steak was
when I made a business decision to split sheets.  New applications
-require- JAVA/NT/UNIX? Give me a break.

But in spite of all of the "concerns" stated in the article, a 10%
growth, by any measure, is very respectable.

BTW, I'm confident that Progressive Data Systems in not the only Y2K
compliant MRP application vendor on the planet! :-)

To top it all off 47k isn't that much to ask in this profession.  AP
clerks get 40k and can't even balance their own check book!

Personally, I take such articles with a grain of salt.  "Concerns" make
headlines, success rarely does.

To balance this article, I've just spent the past week and a half
upgrading a 5363 user to a 150.  First we tossed in our Y2K compliant
version of AP. GL. PR and JC for a highway paving company.  Layered on
top of that their customized S/36 code, did some tweaking and sure
enough pay checks were out on time today.

Our biggest problem has been getting Netwolf and win95 to cope with
pitch and nonspooled print.  IMHO, never, never, never spool checks. 
The "best" deadline was noon, the panic point was 3PM, it all came
together by 2PM.

What took 35 minutes (pay check calculation) on the 5363 only took 5
minutes on the 150 which took a huge load off of the test/repeat cycle.

This client is my company's smallest installation.  They started with a
5364 in 1986.  We chose to do business with them because they
represented a market segment that we were after. (5-10M/yr sales, one
man-year HW/SW)

When they learned that their 5363 could never be Y2K compliant they
shopped around for alternatives to their business needs.  They looked
into Walt Ling's JAVA/NT/UNIX offerings and found them ALL lacking. Sort
of like S/38 offerings in 1982.  Oh, sure, ported S/34 code or a few

They made a choice to evolve to the AS/400, purely on the readily
available application migration that solved their business needs.

It was not a platform decision, it was a results decision.

Fortunately for IBM, Progressive Data Systems happened to provide the
results via AS/400. (this time)

By 2002, when JAVA either grows up or eats dust, we'll make the mega
buck commitment to -any- platform that supports our pure JAVA product
and IBM may or may not win.

Having said that, I will concede that, although Big Blue may enter late
in the game, when they do, a standard is set that all others follow. 
Can we spell VM? How about PC?

Don't get me wrong, PDS has been true Blue for over 20 years and in
spite of any rants I may go off on, I still have a high confidence that
IBM will continue to provide rock solid foundations for application

Thanks for bearing with me,
James W. Kilgore

P.S. As a former BP, the jumping of hoops, ass kissing, sucking up,
whatever, did not further my company's goal of customer satisfaction. 
The mere comment that JAVA/NT/UNIX as -THE- Walt/IBM solution is just
another marketing game that ignores the business consumer need to solve
a problem and spends to much energy on the method instead of the
results. (sizzle vs steak)

Sorry, I got off on another rant.

Chuck Lewis wrote:
> Check it out online, per Computerworld !
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].