How to access your AS/400

From Try-AS/400
Revision as of 10:00, 28 May 2018 by PoC (talk | contribs) (→‎Today: Client Setup)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Today, there are multiple ways to access an AS/400. They all have in common that the transmission of cursor position, text, fields and their attributes as well as other data is transferred according to a definition called 5250 data stream. This is somewhat analog to the well known VT100 protocol.

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 byte-oriented transmissions

However, a huge difference between those is that the user is presented with a form, to look at and/or fill out. If he makes changes, these are only made locally, in the memory of the terminal (or emulator). When everything is finished, the form is transmitted in its entirety back to the host. This is quite like a HTML form being displayed and filled out in a browser, getting transferred back in its entirety by pressing the submit-button.[1]
This is in stark contrast to terminals in the Unix world, where the host is handling communications and screen appearance. Every keypress will go back to the host, trigger an action which ultimately sends data back to the terminal.

Block oriented protocols like 5250 (and 3270) were useful when computing resources were always scarce. Imagine hundreds of users typing and thus interrupting the CPU for simple cursor movement. 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 and the application narrows possible matches is not possible in block oriented mode.[2]


Historically, all access to the machine involved terminal session which were established with, well, terminals. Today, they're called dumb but since they needed logic for local processing of input, they're not quite as dumb as, say, an 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 but rock solid.

An AS/400 could utilize at least one twinax controller with at least four independent ports for daisy chaining terminals. 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, 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.

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.


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

There are multiple 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:

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).

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:[3]

  • Device name.


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. 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.


  1. It is rarely labelled like that today.
  2. Through special programming techniques, it is indeed possible to achieve such a high grade of interactivity. But since the whole machine and OS are built around this block-oriented approach, it is ugly to implement, creates additional burden on the machine and most likely will affect other users on the same machine.
  3. Without knowing the implications.