|
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.
As an Amazon Associate we earn from qualifying purchases.
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.