How to access your AS/400

Today, there are multiple ways to access an AS/400. This article is mainly about terminal access.

Terminal access is defined by transmission of cursor position, text, fields and their attributes as well as data from database tables, transferred according to a definition called 5250 data stream. This is somewhat analog to the well known VT100 protocol in character-based terminal systems.

Additionally, recent implementations of OS/400 feature ssh-Access. But it's different than one would think: This facility provides shell access to the built-in UNIX environment, called PASE. See The Split Personality of OS/400.

Block- versus character-oriented transmissions

However, a huge difference between those is that with the former, the user is presented with a form, to look at and/or fill out. Changes are only made locally, in the memory of the terminal or emulator. When everything is finished, a special key is pressed and the form is transmitted in its entirety back to the host for processing.
This is quite like a HTML form being displayed and filled out in a browser window, getting also transferred back in its entirety by pressing the submit-button.

This is in stark contrast to terminals in the Unix world, where the host is handling communications and screen appearance itself. Every single keypress will go back to the host, trigger an action, based on which appropriate data will be sent back to the terminal for updating on-screen content.

Block oriented protocols like 5250 (and 3270) were useful when computing resources were scarce. Imagine hundreds of users typing data into fields of forms and thus interrupting the CPU for simple cursor movement and character-echoing.
On the other hand, block-oriented transmissions have drawbacks in interactivity. The user can only do what the protocol permits locally. Such stuff as incremental search as one types a search string while the application narrows possible matches with every additional character from that string is not possible in block oriented mode.

History

Historically, all access to the machine involved terminal sessions which were established with, well, terminals: A combination of a CRT display, a controller chip and a keyboard. Rarely accompanied by the possibility to connect a PS/2 mouse. Today, they're called dumb which is plainly wrong. These terminals included a basic SNA stack and coded logic for local processing of input and screen appearance. They're not quite as dumb as, say, a VT100.
Terminals were attached through Twinaxial Cables, thick as a small finger with bulky connectors. The whole system was expensive, complicated to run through a building (because of a large minimum bending radius) but rock solid.

An AS/400 could utilize at least one twinax controller (board) with at least four independent ports for daisy chaining terminals. Because the terminals ran a subset of SNA, they could be daisy chained, easing cabling requirements somewhat. Transmission rate was 1 Mbit/s per port, providing almost instant screen updates. There were controllers available with supported eight-port bricks as well. Bigger machines could have multiple twinax controllers inside to support hundreds of terminals simultaneously.

Today, the twinax attachment is still a necessity with old hardware, since it provides console services, for OS installation and running backups without any users keeping files open. And for troubleshooting, of course. See also details to the Console.

Twinax without terminals

IBM and other manufacturers built ISA cards and provided software for MS-DOS and early Windows versions for accessing AS/400 terminal sessions over twinax. These combination behaved like a true hardware terminal.

Apple once built a combined coax/twinax card. The coax port was used for connecting to communication controllers attached to a mainframe, to support 3270 terminal sessions. Unfortunately, there seems to be no software support for the twinax port ever being implemented.

ASCII Terminals

IBM provided expansion cards for SPD-slot based machines called ASCII Workstation Controller. These boards and SLIC integrated firmware allowed the attachment of standard serial terminals (vt100 and the like) to the AS/400, as a way of investment protection. They handled the steady data flow from users typing and protocol conversion from 5250 to vt100 and other then-standard protocols of that era.

Network-attached gateway solutions

For very slow machines it could be of certain interest to minimize the usage of IP on the machine itself, to save CPU cycles for processing of actual data. Multiple solutions exist(ed) for communicating solely via SNA to AS/400s, and mainframes:

• Apple SNA•ps was the outcome of a collaboration with IBM in the early 1990s. Orion Software programmed a gateway and client applications for terminal access and printing in both 5250 and 3270 worlds, which permitted en-/decapsulating APPC traffic in/from AppleTalk. Hardware attachment was provided by a combined Coax/Twinax-Card, a Token Ring Card or a multiport Serial Card for SDLC transport. Each of these NuBus cards featured their own m68k CPU and between 0.5 to 2.5 MiB of local RAM. Part of the gateway software runs on that CPU.
  Included is additional software and documentation for developing custom solutions based on APPC over AppleTalk.
• Microsoft SNA Server is a gateway solution for SNA communications running on Microsoft Windows Server systems. It provides protocol conversion between SNA and IP based telnet protocols (tn3270, tn5250) as well as printing services by obtaining spooled files from AS/400 printer queues and either saving it as a local text file or sending it to the Windows printing system. It also provides protocol conversion services for database access via OLE and ODBC. Additionally, it exploits the AS/400 shared folder subsystem to re-export folders within /QDLS with standard Windows SMB protocol provided by the Windows operating system. Microsoft SNA Server evolved to the Microsoft Host Integration Server, which is still in active development.
• Novell Netware for SAA was an enhancement for Netware installations. Details will be provided when I had time to install and test this software.
• IBM Communications Manager/2 was an enhancement for OS/2, providing similar services.

Branch Office Solutions

IBM and other vendors offered terminal multiplexors for twinax-based 5250 nodes, to enable a single leased line being shared by multiple terminals in a branch office. Leased-line capable modems provided the physical connection. The protocol involved SNA over SDLC.

Cisco Systems offers some features within their router software, IOS, to help integrate IBM SNA into the conventional LAN and WAN world. There are certain combinations of Routers and IOS Features in a given image, sometimes accompanied by the need to purchase a license key, which enable to exploit this SNA integration services. See the Cisco Feature Navigator for finding appropriate combinations. A selection of probably interesting solutions:

• STUN provides a transparent back to back serial port connection for SDLC communication over existing IP networks. This involves the addition of compatible serial port add-on cards with appropriate cabling to the router.
• (Remote) Source Route Bridging provides the extension of physical token ring media via virtual bridges over Ethernet or even TCP connections. Unfortunately, this facility proved to be sensitive to outages of the intermediate network connection and most often involves a router reload to re-establish the virtual connection.
• SNA Switching Services provide PU (physical unit), LU (logical unit) and session services to SNA hosts to eliminate the need for bridging whole networks over WAN links. Usually, connections are initiated from the IBM hosts over Token Ring, Ethernet and probably other media. This enables a router to be the central hub of an APPN network. Every node just needs a connection (PU) definition to the router while the router handles establishment of direct LU-LU APPC connections between peers.
  SNAsw can be combined with (R)SRB or Enterprise Extender to provide true APPN functionality over WAN (VPN) connections. Unfortunately, this code proved to be in bad shape. Certain combinations of configuration parameters tend to crash IOS in such a way that a power cycle is necessary to get the router back to life. Worse, this crashes aren't easy to relate to certain network activity: Routers may run for days until they halt for no apparent reason. Sometimes, they just reload when initiating a bulk data transfer.

More modern solutions are provided by LAN-attached terminal servers, having Twinax-Ports for Terminals or Printers and an Ethernet-Port for LAN attachment. Communication takes place via tn5250 on the LAN side which makes it possible to use existing IP based VPNs for providing remote access. One notable example is the BOSCOM e-Twin@x-Controller.

Today

Today, most accesses to terminal sessions will take place over ordinary LAN (Ethernet) attachment, IP as transport and tn5250 as high-level protocol. See above for possible drawbacks of this.

Some manufacturers built so called smart terminals with an integrated tn5250 emulator and an ordinary ethernet port for integration in today's IP networks.

There are multiple software-based tn5250 clients available, for free and for a fee, and for many operating systems. I strongly recommend utilizing one of those because they usually just work. My favorite is Mocha TN5250 for macOS. It runs very stable, has a sensible mapping of special keys and a support which at least answers to email requests.

See also:

• Editing Database Files and other Data,
• Getting Data in and out of your AS/400.

Client Setup

Since tn5250 is a protocol with proper standardization, clients share some configuration options. For starters, I strongly recommend to leave any settings at default. You must change connection relevant parameters, though:

• Hostname or IP address to connect to,
• SSL yes or no, (mostly no for self-owned boxes, SSL needs additional setup on the AS/400 itself).

You may change secondary parameters, if necessary:

• EBDIC Code page, (for umlauts, etc.)
• TCP-Port to connect to, (if not running on default)
• Terminal type, (monochome/color and 24×80 only vs. additionally 27×132)

You should not change:

• Device name.

Telnet

It is indeed possible to use plain VT100 over telnet to access AS/400s. The machine (or part of it) will see increased load because of the host based protocol handling when just typing into a terminal. In practice this effect is negligible, especially when there were only half a dozen users working.

Depending on the emulator software (the client) there may be issues with special chars in other languages than english. Sometimes, Function Keys will not work or function keys > F12 cannot be accessed. Additionally, special command keys like System Request or Attention have no equivalent on a standard PC keyboard.

For these reasons, I strongly recommend utilizing a real 5250 client.

Weblinks

• Apple SNA•ps Konfiguration für 5250-Sitzungen, PoCnet Knowledgebase.
• Apple Real-time Operating System Environment, Wikipedia.
• Bridging and IBM Networking Configuration Guide, PDF.