How to access your AS/400: Difference between revisions
(→Today: Client Setup) |
(Reworked) |
||
| Line 1: | Line 1: | ||
Today, there are multiple ways to access an AS/400. | {{FIXME|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 ''[[wikipedia:IBM 5250|5250 data stream]]''. This is somewhat analog to the well known [[wikipedia:VT100|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]]. | 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 | == Block- versus character-oriented transmissions == | ||
However, a huge difference between those is that the user is presented with a form, to look at and/or fill out. | 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.<br /> | ||
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 | 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.<ref>It is rarely labelled like that today.</ref> | ||
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 | 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.<br /> | ||
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.<ref>Through special programming techniques, it is indeed possible to achieve such a high grade of interactivity. It is simply based on really frequent data exchange with the host. But since the whole machine and OS are built around this block-oriented approach, it is ugly to implement, creates additional processing load on the machine and thus will most likely affect other users on the same machine.</ref> | |||
== History == | == History == | ||
Historically, all access to the machine involved terminal | 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.<ref>IBM 3486.</ref> 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.<br /> | ||
Terminals were attached through [[wikipedia:Twinaxial cabling|Twinaxial Cables]], thick as a small finger with bulky connectors. The whole system was expensive, complicated to run through a building but rock solid. | Terminals were attached through [[wikipedia:Twinaxial cabling|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 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. | 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.<ref>Compare that with the 9600 bps of standard ASCII terminals of that era.</ref> 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 [[Your own AS/400#Console|Console]]. | 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 [[Your own AS/400#Console|Console]]. | ||
=== Twinax without terminals === | === Twinax without terminals === | ||
IBM and other manufacturers built [[wikipedia:Industry Standard Architecture|ISA cards]] and provided software for MS-DOS and early Windows versions for accessing | IBM and other manufacturers built [[wikipedia:Industry Standard Architecture|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. | 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.<ref>Transferring binary stream files to or from IFS with FTP over a standard 10 Mbit/s adapter easily brings the CPU of a 9401-150 to 100 % load. Transferring data with SNADS over 16 Mbit/s Token Ring yields about 30 % CPU load.</ref> 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. | |||
* ''[https://en.wikipedia.org/wiki/Microsoft_Host_Integration_Server 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 == | ||
Today, most accesses to terminal sessions will take place over ordinary LAN attachment, IP as transport and tn5250 as high-level protocol. | 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. | 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: | See also: | ||
| Line 35: | Line 60: | ||
* Hostname or IP address to connect to, | * Hostname or IP address to connect to, | ||
* TCP-Port to connect to, | * TCP-Port to connect to, | ||
* SSL yes or no, (mostly no for self-owned boxes, SSL needs additional setup). | * SSL yes or no, (mostly no for self-owned boxes, SSL needs additional setup on the AS/400 itself). | ||
You '''may''' change secondary parameters: | You '''may''' change secondary parameters: | ||
| Line 45: | Line 70: | ||
=== Telnet === | === 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. In practice this effect is negligible, especially when there were only half a dozen users working. | 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 | 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 > <code>F12</code> cannot be accessed. Additionally, special command keys like System Request or Attention have no equivalent on a standard PC keyboard. | ||
== Footnotes == | == Footnotes == | ||
<references /> | <references /> | ||
Revision as of 16:49, 31 December 2018
|
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.[1]
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.[2]
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.[3] 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.[4] 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.[5] 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:
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:[6]
- 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.
Footnotes
- ↑ It is rarely labelled like that today.
- ↑ Through special programming techniques, it is indeed possible to achieve such a high grade of interactivity. It is simply based on really frequent data exchange with the host. But since the whole machine and OS are built around this block-oriented approach, it is ugly to implement, creates additional processing load on the machine and thus will most likely affect other users on the same machine.
- ↑ IBM 3486.
- ↑ Compare that with the 9600 bps of standard ASCII terminals of that era.
- ↑ Transferring binary stream files to or from IFS with FTP over a standard 10 Mbit/s adapter easily brings the CPU of a 9401-150 to 100 % load. Transferring data with SNADS over 16 Mbit/s Token Ring yields about 30 % CPU load.
- ↑ Without knowing the implications.