• Subject: Re: AS/400 vs. NT
  • From: DAsmussen@xxxxxxx
  • Date: Wed, 27 Oct 1999 23:09:06 EDT

Booth,

In a message dated 10/27/99 4:53:33 PM Eastern Daylight Time, 
boothm@earth.goddard.edu writes:

> I wonder how we can make the green screen applications intuitive, easy to 
>  use, pleasing to look at, and easily supported? 

Short answer - code them that way.  Straight 5250 is ugly, so we cannot 
address your "pleasing to look at" request.  However, we _CAN_ add 
intuituion, ease of use and "easy" support.  As most know, I _HATE_ the fact 
that IBM carried 5250 over to the AS/400 for reasons other than to support 
clients with large investments in it.  The advent of the AS/400 _SHOULD_ have 
been a great time to introduce a new protocol had IBM's terminal group not 
still been looking for a way to make a buck off of 20 year old 5250 and 3270 
technology at the time.  Newer (than 1993) DDS keywords make it far easier to 
determine cursor position and the like, so take advantage of them!  If only 
5250 worked like PC's when it came to the use of cursor positioning keys like 
<TAB> and <BACKTAB>...

>  The idea of an HTML and 5250 combining into a snazzy interface makes a lot 
>  of sense but man, it needs a lot of additional function to be accepted.

Indeed.

>  What does the AS/400 solution offer that NT doesn't?  We know that 
>  reliability is a non-issue -  too many NT servers are running way to well 
>  and way to long for us to throw up the reliability smoke screen anymore, 
>  and the AS/400 itself is way to complicated for most shops today. 

Not really.  In order to have the ultra-reliable NT servers mentioned 
earlier, you have to have ultra-GOOD NT administrators -- often at ultra-good 
prices.  NT is _STILL_ not as scalable as its' network competition.  One of 
my current clients is a case in point.  They run NT server and NT Workstation 
on the desktop (I've often said that NT Workstation is more reliable than '95 
or '98).  The network is _very_ reliable BUT, very slow for the number of 
users on it.  My last two clients contrast that by using Novell as their WAN, 
which crashed at least once a week -- but they were running FOUR TIMES THE 
VOLUME, users in the thousands instead of the hundreds.  What would have 
happened had management at the Novell clients not accepted the frequent 
crashing as "the norm" and instead canned some people until the network quit 
crashing?  Problem is, Micro$oft has convinced people that crashing is normal 
and that reloading the OS from scratch is an acceptable diagnostic tool.

The difference between the AS/400 and any LAN/WAN is that any idiot can run 
an AS/400.  With an idiot running it, the AS/400 might not be as fast as it 
could be, but it will still run without going down unless there is a hardware 
problem.  With an idiot running NT, Novell, Banyan, etc., uptime is a 
question mark.

>  So, what is there to offer?

Talk to your users, and ask them what they want.  The _REAL_ users, not the 
one that's in charge of them and never touches a terminal.  I've seen 
"visual" work well when the application was developed in concert with the 
users (using touch screens), but I've more often seen it fail because it 
implemented what "management" wanted to see.  GUI is good, but GUI for GUI's 
sake is destined for failure...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"The only stupid question is the one you were too proud to ask." -- Me
+---
| 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-2019 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].