Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Which Text-Based UI to Replace AS/400 with Linux?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • R.Daugherty
    replied
    Which Text-Based UI to Replace AS/400 with Linux?

    I saw this comment on Slashdot and replied. They already have terminals, which need to be used. That's an amazingly bad assumption. They have an AS/400 which in this day talks to PC's running a 5250 terminal emulation program. The fact that the company wants to use serial terminals is only an indication they want to go as cheap a route as possible. A post or two in this thread jumped on a "they have serial port terminals to use" thing because any other possibility is sort of stupid. But it is what it is. rd

    Leave a comment:


  • R.Daugherty
    replied
    Which Text-Based UI to Replace AS/400 with Linux?

    That's not the real thread title on Slashdot, but that's what it should be. This was my response: ...a management software system with text based user interface as the replacement of an older one running on AS/400. Despite my attempts towards a web UI, the customer is actually willing to have a text based UI. The main reasons are the need for a very low bandwidth and the ability to run on serial terminals. All this in the 21st century! Host systems will be Linux, the language will be C or C++. I'm an AS/400 guy, used to be a PC programmer. I'm trying to understand this, any comments appreciated. What's clear to me is the company is converting from an AS/400 to Linux (yes, Linux runs concurrently in partitions on the AS/400, now called system i after several name changes, but I'm also assuming they want a cheap Linux server). I remember in some early programming (I was original programmer for Melita Electronics, later International, they did well hooking Wyse serial terminals to a PC and controlling multiple terminals from a PC with a multi-serial port board. The AS/400 of course has not had serial terminals, they have 5250 terminals or PC terminal emulators over TCP/IP now, IBM networking before that. So I take it this serial port thing is a throwback to what I used to do because this company says, we have a Linux PC server, let's hook up cheap serial port terminals? With serial communications limitations and dirt cheap PC's able to run any kind of terminal emulation cheaply, something very strange about that to me. The best I can tell from this is the purpose of NCURSES would be to emulate 5250 PC emulation with a serial port terminal emulator. But like I say, any clarifying comments welcome. The replacing a "management software system" equivalent to what they had on the AS/400 in C++ on Linux would seem to be quite a job in itself. All of the work that NCURSES does is taken care of by our 5250 I/O subsystem. That's quite a lot of I/O detail that he will have to insert into the replacement. By the way, NCURSES doc says it runs on any POSIX platform, and the AS/400 (which is usually called iseries now) has a C++ compiler and is POSIX compliant. The C++ modules can be bound together with modules from any other language on the iseries into an i5/OS program. It could communicate with anything over TCP/IP, but I would have to check if we can rig up serial ports for terminals. rd

    Leave a comment:


  • R.Daugherty
    replied
    Which Text-Based UI to Replace AS/400 with Linux?

    Yes, that seems to be what the company is thinking, go cheap with serial port terminals or terminal emulation from Linux to replace their AS/400 with 5250 terminals or terminal emulation. I had posted late last night and realize that I didn't mention where NCURSES comes from. The Slashdot poster, the consultant implementing this, asked if there was anything else he should consider besides NCURSES, Basically, the answers have been NCURSES or something similar, or does the company have any idea what they're doing? I would say no. rd

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Which Text-Based UI to Replace AS/400 with Linux?

    This sounds like a return to the days of old VT-52/VT-100 terminals. Most of those old serial devices were ASCII units and not commonly used in the (at the time) System 32/34/36/38 world. I've got a strange feeling that there's going to be a lot of "reinventing the wheel" going on here. For what purpose? When you want a low-cost system, that's a counterproductive strategy. Ditch the terminals. Are they even made anymore? Use cheap PC's and telnet in if you insist on a character interface. Or, you can use some of the current "thin client" devices that are still in production. Just don't expect to save a whole lot of money by doing so--their advantages these days relate more to centralized management and security on the client side. You certainly shouldn't be writing communications code. Communications management is a task long relegated to communications support libraries. That's all to the good. Still, the whole project reeks of someone who understood the old ways of writing computing systems, disliked how that world changed, and got their chance to recreate the past. Even real-time, process control, embedded and SCADA systems have made the leap to more modern, graphical environments.

    Leave a comment:


  • Which Text-Based UI to Replace AS/400 with Linux?

    The post mentioned a "text based user interface". The question is an interface to what?? Dave
Working...
X