× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> 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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.