RE: Linux and V5R2

On Wed, 7 May 2003, Goodbar, Loyd (ETS - Water Valley) wrote:

> There probably isn't anything intrinsic to the AS/400 that prevents an X
> server from running. X is a large system, and takes *forever to compile (if
> you chose). But I imagine it would work in the AIX/PASE environment. But...
> How do you get at it? You would need the C API calls for X (or the toolkits
> QT/GTK+ if you used them) or write RPG wrappers for them. But that's another
> story.

While it is probably true that there isn't anything intrinsic to the
AS/400 that prevents it from running an X server, it is true that the
design of OS/400 makes it difficult.  The batch/interactive design of
OS/400 runs counter to the design of unix (on which X11 was developed) and
therefore X11 itself.  While not covering exactly the topic of OS/400 and
X11, the following article gives some insight into why OS/400 and X11 may
not be a good mix by looking at why linux and mainframes are not always a
good mix:

http://www.linuxworld.com/site-stories/2002/0416.mainframelinux.html

On unix there is no such thing as batch or interactive.  There are some
interfaces that make some things behave like batch to the user (like the
'&' operator or a shell script) but it really isn't batch.  Since there is
no batch there isn't an interactive, either.  Processes can run with
different run priorities, but a low priority isn't the same as batch,
either.  Basically, on unix the kernel uses all available resources all
the time to do the all work[1].

X11 generates a work load that doesn't fit well with OS/400's
batch/interactive design.  To move a window around the screen requires a
lot of computing to be done immediately.  You don't want CFINT kicking in
every time you slide the windows around or change their size.  And you
certainly don't want anything queued in the OS/400 sense.  On the other
hand unix is designed for the kind of workloads X11 creates.  Not because
unix was designed for X11, but more likely because X11 was designed on
unix.

> The practical reason I would give is "The AS/400 isn't designed to do
> that.", by which I mean until a few years ago, the AS/400 didn't have the
> raw processing power to do everything X needs to handle. Also, the AS/400
> was optimized for certain kinds of operations (read disk/transactional ops),
> not CPU intensive interpretation of Perl. Ref. the Linux LPARs, PASE, etc.
> especially with interpreted languages such as net.data, PHP, Perl, Python,
> etc. all require what I would consider more raw power than compiled
> RPG/CL/COBOL/MI code.

It has had enough power, but that power is put to uses that don't fit well
with the X11 paradigm (basically what you said "the AS/400 was optimized
for certain kinds of operations").

> The AS/400 doesn't have built-in graphic hardware, so you would need a PC or
> smart terminal/thin client terminal to take advantage of a GUIzed
> environment. That's a somewhat expensive device to put on the shipping dock
> that's more exposed to the weather, or on the shop floor in an misty/oily
> environment.

The inclusion of X11 doesn't require a GUI client.  It certainly doesn't
on unix.  But even it you did choose to put GUI abilities on the shipping
dock, there is no reason to make that be a PC.  X11 terminals can be had
for the same as a 5250 terminal and are just as reliable.

> And then... Why?

I'm sure if the ability was there we would have plenty of things using it.
"If you build it they will come."

James Rich

[1]  There are some neat tricks done by the kernel scheduler (not the same
as the job scheduler on OS/400) to detect processes as "interactive", i.e.
an X11 application creating widgets, destroying them, changing pixels on
the screen, and give these processes priority.  But these kernel scheduler
tricks don't equate to the OS/400 and mainframe concepts of batch and
interactive.