How to access your AS/400

This article isn't finished yet or needs to be revised. Please keep in mind that thus it may be incomplete. Reason: Provide more web links to mentioned topics.

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 other data 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. 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 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 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 with supported eight-port bricks as well. Bigger machines could have multiple twinax controllers inside.

Today, the twinax attachment is still a necessity with old hardware, since it provides console services, for installing and for 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 attachment to communication controllers attached to a mainframe. Unfortunately, there seems to be no software support for the twinax port.

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 one way of investment protection. They handled the steady interrupts from user typing and protocol conversion from 5250 to vt100 and other then-standard protocols of that era.

Network-attached gateway solutions

For very old 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) 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.
• Microsoft SNA Server is a gateway solution for SNA communications running on Microsoft Windows. 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 integrated 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 such a share 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.

Branch Office Solutions

IBM and other vendors offered terminal multiplexors for twinax-based 5250 terminals, to enable a single leased line being shared by multiple terminals in a branch office. Leased-line capable modems provided the physical connection. Attachment to the AS/400 usually was accomplished via SDLC.

Cisco Systems offers some features within their router software, IOS, which enables routers to emulate a SDLC connection over existing IP communication paths.

More modern attempts are LAN-attached terminal servers, having Twinax-Ports for Terminals 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 VPN networks for Twinax-Terminal access.

Today

Today, most accesses to terminal sessions will take place over ordinary LAN attachment, IP as transport and tn5250 as high-level protocol.

Some manufacturers built smart terminals with an integrated tn5250 emulator and IP based attachment to the AS/400.

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.

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 documentation, 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,
• TCP-Port 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:

• EBDIC Code page, (for umlauts, etc.)
• 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.