RE: LINUX is the "one" ? .... Comments???

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: E Doc
>
> I have no idea what this means.  But I think it does indicate
> that IBM is as
> confused about the 400 as we are.  We all want to make it
> "better".  But what
> is "better"?  Linux?  Dumping DB/2?  Forcing everyone to migrate to a
> POSIX-compliant file system?  Ditching green screen?  Keeping
> green screen?
> Reducing the price of the system?  Keeping everything the same?
> Nobody knows,
> really.

Certainly nobody knows, Doc, but having been in the trenches long enough, we
have ideas and opinions on "good".  Mine is based on a simple predicate: the
AS/400 is still the best business logic server on the planet.  Everything
should spring from that.  What does that mean, though?

1. UI - The AS/400 should never have a native GUI.  The cycles spent on
making things pretty should always be on the client side.  And while PCs are
getting cheaper, nothing beats a $50 dumb terminal for sticking next to the
punch press, so there's always going to be a need for some direct-attach
devices.  5250 is as good as it gets for that, so it should never go away.
However, it can be greatly discouraged.

2. DB2/400 - Break this on fear of death.  Physical and logical files are
still (and frankly always will be) more powerful for certain types of
applications than SQL.  You want SQL on top of DB2/400, great, but leave me
the ability to design my own database and access paths and access them the
way I want to.  No matter how good an optimizer you have, it can never
compete with a good programmer who actually knows exactly how the database
will be used.

3. Client/server - This is probably the area that needs work.  Personally, I
would like to see a standard message-based access method that you could use
like a any other file in HLL languages.  You'd read a special "message
device file" and a message would come in, and would automatically get parsed
into the correct fields.  This would be a language enhancement, and have
nothing to do with XML.  The XML parsing, if necessary, would be a separate
layer.  This would allow fast transmission of data between two machines that
understood one another, and slower XML-based parsing for more disparate
machines.

There are other pieces.  A more UI independent display file would be nice -
it could be an adjunct to the message device file.  And a job-level API to
intercept workstation data management requests would be nice to help move us
along towards UI independence.

Joe