RFC 2877
5250 Telnet Enhancements
RFC 2877: 5250 Telnet Enhancements 💖
okay bestie, this one is all about IBM's 5250 Telnet server and how clients can ask for specific devices, auto-signon, and printers 🖨️✨
Here's the title block tea 🫶
- Request for Comments: 2877
- Category: Informational (so it's sharing info, not an Internet standard 💅)
- Authors: T. Murphy, Jr., P. Rieth, and J. Stevens
- Organisation: IBM Corporation
- Network Working Group
- Date: July 2000
- Updates: RFC 1205 (the title block doesn't list anything it obsoletes)
Status of this Memo 🧾
this memo gives info to the Internet community 🌸 it's not a standard of any kind, and anyone can distribute it freely 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract ✨
okay so this memo describes the interface to the IBM 5250 Telnet server, which lets a client Telnet ask for a terminal or printer session with a specific device name 🎀 if that device name isn't available, there's a way to retry with a new one 🔁 it also covers how to request certain Telnet session settings and auto-signon 🔑
the main reason this is so iconic: when the client picks the device name, the 5250 Telnet server opens the door for applications to set and/or pull out useful info about that client 🤯 some examples are 1) picking a custom device name tied to a user profile for National Language Support or subsystem routing 🌍, 2) hooking up PC and network printers as clients 🖨️, and 3) auto-signon using clear-text or DES-encrypted password exchange 🔐
applications might need to use system APIs on the AS/400 to get Telnet session settings out of the device name description 💻 check out the Retrieve Device Description (QDCRDEVD) API in the AS/400 System API book [3] to see how to pull that info using the DEVD0600 and DEVD1100 templates 📖
this memo also explains how the IBM 5250 Telnet server supports Work Station Function (WSF) printers using 5250 Display Station Pass-Through 🦋 when a WSF printer session starts or fails, the Telnet server sends back a response code to say which one happened ✅❌
Table of Contents 📚
1. Enhancing Telnet Negotiations...................... 3
2. Standard Telnet Option Negotiation................. 3
3. Enhanced Telnet Option Negotiation................. 4
4. Enhanced Display Emulation Support................. 7
5. Enhanced Display Auto-Signon and Password
Encryption......................................... 8
5.1 Password Substitutes Processing.............. 12
5.2 Handling passwords of length 9 and 10........ 14
5.3 Example Password Substitute Calculation...... 15
6. Device Name Collision Processing................... 15
7. Enhanced Printer Emulation Support................. 16
8. Telnet Printer Terminal Types...................... 18
9. Telnet Printer Startup Response Record for Printer
Emulators.......................................... 20
9.1 Example of a Success Response Record......... 20
9.2 Example of an Error Response Record.......... 21
9.3 Response Codes............................... 22
10. Printer Steady-State Pass-Through Interface........ 23
10.1 Example of a Print Record.................... 25
10.2 Example of a Print Complete Record........... 27
10.3 Example of a Null Print Record............... 27
11. End-to-End Print Example........................... 28
12. Authors' Note...................................... 33
13. References......................................... 33
14. Security Considerations............................ 35
15. Authors' Addresses................................. 35
16. Relation to Other RFC's............................ 35
17. Full Copyright Statement........................... 36List of Figures 🖼️
Figure 1. Example of a success status response
record....................................... 20
Figure 2. Example of an error response record.......... 21
Figure 3. Layout of the printer pass-through
header....................................... 23
Figure 4. Server sending client data with a print
record....................................... 26
Figure 5. Client sending server a print complete
record....................................... 27
Figure 6. Server sending client a null print
record....................................... 281. Enhancing Telnet Negotiations 🎀
the 5250 Telnet server lets clients negotiate both terminal and printer device names through Telnet Environment Options Negotiations 💅 that's defined in the Standards Track RFC 1572 [13] 🧚
RFC 1572 is all about swapping environment info using a set of standard or custom variables 🌈 by mixing standard VAR's with custom USERVAR's, the 5250 Telnet server lets the client ask for a pre-defined specific device by name 🎯
if there's no pre-defined device, the device gets created 🪄 and the client can still negotiate device attributes, like the code page, character set, keyboard type, etc. 💖
printers can be negotiated as device names now too, so there are new terminal types for requesting them 🖨️ for example, you can negotiate "IBM-3812-1" and "IBM-5553-B01" as valid TERMINAL-TYPE options [11] 🍓
last but not least, the 5250 Telnet server lets the client exchange user profile and password info, and the password can be clear-text or encrypted 🔐 if the profile and password combo is valid, the client gets to skip the sign-on panel 🙈 for that bypass to work, the QRMTSIGN system value has to be either *VERIFY or *SAMEPRF 👑
2. Standard Telnet Option Negotiation 🌸
usually, Telnet server option negotiation kicks off when the server invites the client into terminal type negotiation (DO TERMINAL-TYPE) [11] 💌 the client and server then go through a series of sub-negotiations to figure out what level of terminal support they'll use ✨
once the terminal type is agreed, the client and server normally negotiate a set of extra options (EOR [12], BINARY [10], SGA [15]) that are needed for "transparent mode" or full screen 5250/3270 block mode support 🦋 as soon as those required options are negotiated, the server pauses further negotiations and starts initializing the actual virtual device on the AS/400 🧠 a typical exchange might look like this:
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
IAC DO TERMINAL-TYPE -->
<-- IAC WILL TERMINAL-TYPE
IAC SB TERMINAL-TYPE SEND
IAC SE -->
IAC SB TERMINAL-TYPE IS
<-- IBM-5555-C01 IAC SE
IAC DO EOR -->
<-- IAC WILL EOR
<-- IAC DO EOR
IAC WILL EOR -->
.
.
(other negotiations) .here's what those bytes look like in hex 🤓
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
FF FD 18 -->
<-- FF FB 18
FF FA 18 01 FF F0 -->
FF FA 18 00 49 42 4D 2D
35 35 35 35 2D 43 30 31
<-- FF F0
FF FD 19 -->
<-- FF FB 19
<-- FF FD 19
FF FB 19 -->
.
.
(other negotiations) .some negotiations are symmetrical between client and server, and some only go one way 🔄 it's also totally allowed and super common to bundle more than one request or response together, or mix a request with a response 🫶 so what you see in real life might look different from the examples above 👀
3. Enhanced Telnet Option Negotiation ✨
okay so, to make room for the new environment option negotiations, the server is gonna bundle an environment option invitation right alongside the usual terminal type invitation request to the client 💖
a client should either send a negative acknowledgment (WONT NEW-ENVIRON), or at some point after finishing terminal-type negotiations (but before finishing the full set of negotiations required for 5250 transparent mode), do environment option sub-negotiation with the server. a max of 1024 bytes of environment strings can be sent to the server 🫶 here's a recommended sequence that might look like this:
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
IAC DO NEW-ENVIRON
IAC DO TERMINAL-TYPE -->
(2 requests bundled)
<-- IAC WILL NEW-ENVIRON
IAC SB NEW-ENVIRON SEND
VAR IAC SE -->
IAC SB NEW-ENVIRON IS
VAR "USER" VALUE "JONES"
USERVAR "DEVNAME"
VALUE "MYDEVICE07"
<-- IAC SE
<-- IAC WILL TERMINAL-TYPE
(do the terminal type
sequence first)
IAC SB TERMINAL-TYPE SEND
IAC SE -->
IAC SB TERMINAL-TYPE IS
<-- IBM-5555-C01 IAC SE
(terminal type negotiations
completed)
IAC DO EOR -->
(server will continue
with normal transparent
mode negotiations)
<-- IAC WILL EOR
.
.
(other negotiations) .the actual bytes in that example look like this in hex, so you can see exactly what's going over the wire 👀
FF FD 27
FF FD 18 -->
(2 requests bundled)
<-- FF FB 27
FF FA 27 01 00 FF F0 -->
FF FA 27 00 00 55 53 45
52 01 4A 4F 4E 45 53 03
44 45 56 4E 41 4D 45 01
4D 59 44 45 56 49 43 45
<-- 30 37 FF F0
<-- FF FB 18
(do the terminal type
sequence first)
FF FA 18 01 FF F0 -->
FF FA 18 00 49 42 4D 2D
35 35 35 35 2D 43 30 31
<-- FF F0
FF FD 19 -->
(server will continue
with normal transparent
mode negotiations)
<-- FF FB 19
.
.
(other negotiations) .RFC 1572 defines 6 standard VARs: USER, JOB, ACCT, PRINTER, SYSTEMTYPE, and DISPLAY. the USER standard VAR holds the value of the AS/400 user profile name that gets used in auto-signon requests 🔑 the Telnet server won't make any direct use of the other 5 VARs, and none of them are required to be sent. every standard VAR and its value the Telnet server receives gets stashed in a buffer, along with any USERVARs it gets (more on those below), and handed over to a registered initialization exit program, which can use them for whatever it wants ✨
there are some good reasons you might want to send NEW-ENVIRON negotiations before TERMINAL-TYPE negotiations 🧚 with the AS/400 TELNET server, you can negotiate several virtual device modes: 1) VTxxx device, 2) 3270 device, and 3) 5250 device (which includes Network Station). the virtual device mode depends on the TERMINAL-TYPE negotiated, plus any other TELNET option negotiations needed to support those modes. the AS/400 TELNET server creates the desired virtual device at the first opportunity it thinks it has all the requested attributes it needs, which can be as early as the moment TERMINAL-TYPE negotiations finish.
for Transparent mode (5250 device), the moment TERMINAL-TYPE, BINARY, and EOR options are negotiated, the TELNET server goes and creates the virtual device. if NEW-ENVIRON negotiations come in after those option negotiations are done, they'll have no effect on device attributes, because the virtual device already exists by then 😭
so, for Transparent mode, NEW-ENVIRON negotiations are effectively closed once EOR is negotiated, since EOR is generally the last option done 🔒
for other device modes (like VTxxx or 3270), you can't be sure when the AS/400 TELNET server thinks it has all the attributes it needs to create the device. remember, NEW-ENVIRON negotiations are optional, so the AS/400 TELNET server doesn't need to wait for any NEW-ENVIRON options before creating the virtual device. it's in the client's best interest to send NEW-ENVIRON negotiations as soon as possible, preferably before TERMINAL-TYPE is negotiated. that way, the client can be sure the requested attributes were received before the virtual device gets created 💅
4. Enhanced Display Emulation Support 🌈
RFC 1572 style USERVARs have been defined so a compliant Telnet client gets more control over the Telnet server virtual device on the AS/400 👑 these USERVARs let the client Telnet create or select a previously created virtual device. if the virtual device doesn't exist and has to be created, the USERVARs are used to create and initialize the device attributes. if the virtual device already exists, the device attributes get modified.
the USERVARs defined for this are:
USERVAR VALUE EXAMPLE DESCRIPTION
-------- ---------------- ---------------- -------------------
DEVNAME us-ascii char(x) MYDEVICE07 Display device name
KBDTYPE us-ascii char(3) USB Keyboard type
CODEPAGE us-ascii char(y) 437 Code page
CHARSET us-ascii char(y) 1212 Character setx - up to a maximum of 10 characters y - up to a maximum of 5 characters
for a description of the KBDTYPE, CODEPAGE and CHARSET parameters and what values they're allowed to have, check out Chapter 8 in the Communications Configuration Reference [5], and also Appendix C in National Language Support [16] 📚
the CODEPAGE and CHARSET USERVARs must be associated with a KBDTYPE USERVAR. if either CODEPAGE or CHARSET gets sent without KBDTYPE, they'll default to system values. you can send a default value for KBDTYPE to force the CODEPAGE and CHARSET values to be used 🎀
heads up bestie: AS/400 system objects like device names, user profiles, clear-text passwords, programs, libraries, etc. are required to be specified in English Upper Case (EUC). that covers all of these:
Any letter (A-Z), any number (0-9), special characters (# $ _ @)so, wherever us-ascii is specified for VAR or USERVAR values, it is recommended that you send upper-cased ASCII values, which the Telnet server will convert to EBCDIC for you 🍓
a special case happens for encrypted passwords (covered in the next section 🙈). both the initial password and the user profile used to build the encrypted password must be EBCDIC English Upper Case, so the Telnet server can authenticate them properly 🔐
5. Enhanced Display Auto-Signon and Password Encryption ✨
Okay so bestie, auto-signon is where things get spicy 🔐 The 5250 Telnet server is gonna define a few server-specific USERVAR's. One carries a random seed for DES (Data Encryption Standard) password encryption, and the other carries the encrypted copy of the password 🎀 It uses the same 7-step DES-based password substitution scheme that APPC and Client Access already use, so it's not a brand-new vibe. If you want the DES details, check out Federal Information Processing Standards Publications (FIPS) 46-2 [17] and 81 [18], over at the FIPS Publications link:
http://www.itl.nist.gov/div897/pubs/by-num.htm
For the 7-step password substitution scheme, go look at these IBM Customer Support FTP Server links 💜
ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps
ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps.Z
ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.zipIf encrypted password exchange isn't required, clear-text password exchange is permitted using the same USERVAR's defined for encryption 🌸 In that case the random client seed should be set to either an empty value (RFC 1572 preferred method) or to hexadecimal zeros, which tells the server the password isn't encrypted and is just clear-text.
It should be noted that security of clear-text password exchange cannot be guaranteed unless the network is physically protected or a trusted network (such as an intranet). If your network is vulnerable to IP address spoofing or directly connected to the Internet, you should engage in encrypted password exchange to validate a clients identity. 🚨💀
Extra VAR's and USERVAR's have also been defined so an auto-signon user gets more control over their startup environment 🧚 It's similar to what you get with the Open Virtual Terminal (QTVOPNVT) API [3], so it's giving familiar energy.
The standard VAR's supported to accomplish this are:
VAR VALUE EXAMPLE DESCRIPTION
-------- ---------------- ---------------- -------------------
USER us-ascii char(x) USERXYZ User profile namex - up to a maximum of 10 characters
The custom USERVAR's defined to accomplish this are:
USERVAR VALUE EXAMPLE DESCRIPTION
-------- ---------------- ---------------- -------------------
IBMRSEED binary(8) 8-byte hex field Random client seed
IBMSUBSPW binary(10) 10-byte hex field Substitute password
IBMCURLIB us-ascii char(x) QGPL Current library
IBMIMENU us-ascii char(x) MAIN Initial menu
IBMPROGRAM us-ascii char(x) QCMD Program to callx - up to a maximum of 10 characters
So here's how the seed handshake goes 🦋 To get the server random seed over to the client, the server requests a USERVAR name made of a fixed part (the 8 characters "IBMRSEED") immediately followed by an 8-byte hexadecimal variable part, which is the server random seed. The client makes its own 8-byte random seed, then uses both seeds to encrypt the password. Both the encrypted password and the client random seed are sent back to the server for authentication. RFC 1572 rules need to be followed when transmitting the client random seed and substituted password values to the server. Specifically, since a typical environment string is a variable length hexadecimal field, the hexadecimal fields are required to be escaped and/or byte stuffed according to RFC 854 [8], because any single byte could be mis-construed as a Telnet IAC or other Telnet option negotiation control character. The client must escape and/or byte stuff any bytes which could be seen as a RFC 1572 [13] option, specifically VAR, VALUE, ESC and USERVAR. Main character energy 👑
The following illustrates the encrypted case:
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------------
IAC DO NEW-ENVIRON -->
<-- IAC WILL NEW-ENVIRON
IAC SB NEW-ENVIRON SEND
USERVAR "IBMRSEEDxxxxxxxx"
USERVAR "IBMSUBSPW"
VAR USERVAR IAC SE -->
IAC SB NEW-ENVIRON IS
VAR "USER" VALUE "DUMMYUSR"
USERVAR "IBMRSEED" VALUE "yyyyyyyy"
USERVAR "IBMSUBSPW" VALUE "zzzzzzzz"
<-- IAC SE
.
.
(other negotiations) .In this example, "xxxxxxxx" is an 8-byte hexadecimal random server seed, "yyyyyyyy" is an 8-byte hexadecimal random client seed and "zzzzzzzz" is an 8-byte hexadecimal encrypted password. If the password is not valid, then the sign-on panel is displayed. If the password is expired, then the Change Password panel is displayed. 🙈
Actual bytes transmitted in the above example are shown in hex below, where the server seed is "7D3E488F18080404", the client seed is "4E4142334E414233" and the encrypted password is "DFB0402F22ABA3BA". The user profile used to generate the encrypted password is "44554D4D59555352" (DUMMYUSR), with a clear-text password of "44554D4D595057" (DUMMYPW).
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
FF FD 27 -->
<-- FF FB 27
FF FA 27 01 03 49 42 4D
52 53 45 45 44 7D 3E 48
8F 18 08 04 04 03 49 42
4D 53 55 42 53 50 57 03
00 FF F0 -->
FF FA 27 00 00 55 53 45
52 01 44 55 4D 4D 59 55
53 52 03 49 42 4D 52 53
45 45 44 01 4E 41 42 33
4E 41 42 33 03 49 42 4D
53 55 42 53 50 57 01 DF
B0 40 2F 22 AB A3 BA FF
<-- F0The following illustrates the clear-text case:
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
IAC DO NEW-ENVIRON -->
<-- IAC WILL NEW-ENVIRON
IAC SB NEW-ENVIRON SEND
USERVAR "IBMRSEEDxxxxxxxx"
USERVAR "IBMSUBSPW"
VAR USERVAR IAC SE -->
IAC SB NEW-ENVIRON IS
VAR "USER" VALUE "DUMMYUSR"
USERVAR "IBMRSEED" VALUE
USERVAR "IBMSUBSPW" VALUE "yyyyyyyy"
<-- IAC SE
.
.
(other negotiations) .In this example, "xxxxxxxx" is an 8-byte hexadecimal random server seed, "yyyyyyyyyy" is a 10-byte us-ascii client clear-text password. If the password has expired, then the sign-on panel is displayed. 💅
Actual bytes transmitted in the above example are shown in hex below, where the server seed is "7D3E488F18080404", the client seed is empty and the clear-text password is "44554D4D595057" (DUMMYPW). The user profile used is "44554D4D59555352" (DUMMYUSR).
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
FF FD 27 -->
<-- FF FB 27
FF FA 27 01 03 49 42 4D
52 53 45 45 44 7D 3E 48
8F 18 08 04 04 03 49 42
4D 53 55 42 53 50 57 03
00 FF F0 -->
FF FA 27 00 00 55 53 45
52 01 44 55 4D 4D 59 55
53 52 03 49 42 4D 52 53
45 45 44 01 03 49 42 4D
53 55 42 53 50 57 01 44
<-- 55 4D 4D 59 50 57 FF F05.1 Password Substitutes Processing ✨
okay so APPC and Client Access both use the well-known DES encryption algorithms to make encrypted passwords 🔐. A Network Station or Enhanced Client can make compatible encrypted passwords too, as long as it follows these steps. You can find the details in the Federal Information Processing Standards 46-2 [17] 🎀
Step 1: Padded_PW. Padded_PW = Left justified user password padded to the right with '40'X to 8 bytes.
The user password has to be left justified in an 8 byte variable and padded to the right with '40'X up to 8 bytes. If the password is already 8 bytes, there's no padding at all. For passwords of 9 and 10 bytes, check out the section "Handling passwords of length 9 and 10" below 💖. Passwords shorter than 1 byte or longer than 10 bytes are not valid 🙅♀️. Also, if the password isn't in EBCDIC, it must be converted to EBCDIC uppercase.
Step 2: XOR_PW. XOR_PW = Padded_PW xor '5555555555555555'X
The padded password gets Exclusive OR'ed with 8 bytes of '55'X 🌸.
Step 3: SHIFT_RESULT. SHIFT_RESULT = XOR_PW << 1
The whole 8 byte result gets shifted 1 bit to the left. The leftmost bit is discarded, and the rightmost bit is cleared to 0 🦋.
Step 4: PW_TOKEN. This is where the magic happens ✨
PW_TOKEN = DES_ECB_mode(SHIFT_RESULT, /* key */
userID_in_EBCDIC_uppercase /* data */ )The shifted result is used as the key for the Data Encryption Standard (Federal Information Processing Standards 46-2 [17]) to encipher the user identifier. When the user identifier is less than 8 bytes, it's left justified in an 8 byte variable and padded to the right with '40'X. When it's 9 or 10 bytes, it's first padded to the right with '40'X to a length of 10 bytes. Then bytes 9 and 10 get "folded" into bytes 1-8, using this algorithm:
Bit 0 is the high-order bit (i.e. has value of '80'X).
Byte 1, bits 0 and 1 are replaced with byte 1, bits 0 and 1
Exclusive OR'ed with byte 9, bits 0 and 1.
Byte 2, bits 0 and 1 are replaced with byte 2, bits 0 and 1
Exclusive OR'ed with byte 9, bits 2 and 3.
Byte 3, bits 0 and 1 are replaced with byte 3, bits 0 and 1
Exclusive OR'ed with byte 9, bits 4 and 5.
Byte 4, bits 0 and 1 are replaced with byte 4, bits 0 and 1
Exclusive OR'ed with byte 9, bits 6 and 7.
Byte 5, bits 0 and 1 are replaced with byte 5, bits 0 and 1
Exclusive OR'ed with byte 10, bits 0 and 1.
Byte 6, bits 0 and 1 are replaced with byte 6, bits 0 and 1
Exclusive OR'ed with byte 10, bits 2 and 3.
Byte 7, bits 0 and 1 are replaced with byte 7, bits 0 and 1
Exclusive OR'ed with byte 10, bits 4 and 5.
Byte 8, bits 0 and 1 are replaced with byte 8, bits 0 and 1
Exclusive OR'ed with byte 10, bits 6 and 7.User identifiers longer than 10 bytes or shorter than 1 byte don't produce this encryption result, which is known as PW_TOKEN in the paper 🙈.
Step 5: Increment PWSEQs and store it. 💅
Each LU has to keep a pair of sequence numbers for ATTACHs sent and received on each session. Every time an ATTACH is generated (and password substitutes are in use on the session), the sending sequence number, PWSEQs, gets incremented and saved for next time. Both values get set to zero at BIND time, so the first use of PWSEQs is 1, and it goes up by one with each use. A new field gets added to the ATTACH to carry this sequence number. Here's the tricky bit: in certain error conditions, the sender might increment the sequence number while the receiver doesn't. When the sender sends a later ATTACH, the receiver will notice a missing sequence. That's allowed 🫶. Still, the sequence number received must always be larger than the previous one, even if some are missing.
The maximum number of consecutive missing sequence numbers allowed is 16. If that gets exceeded, the session is unbound with a protocol violation 💀.
Note: The sequence number must be incremented for every ATTACH sent. However, the sequence number field is only required to be included in the FMH5 if a password substitute is sent (byte 4, bit 3 on).
Step 6: RDrSEQ. RDrSEQ = RDr + PWSEQs /* RDr is server seed. */
The current PWSEQs gets added to RDr, the random value received from the partner LU on this session. That gives you RDrSEQ, which is basically a predictably modified version of the random value the partner LU sent at BIND time 🧚.
Step 7: PW_SUB. Here's the final encryption 🔥
PW_SUB = DES_CBC_mode(PW_TOKEN, /* key */
(RDrSEQ, /* 8 bytes */
RDs, /* 8 bytes */
ID xor RDrSEQ, /* 16 bytes */
PWSEQs, /* 8 bytes */
) /* data */
)PW_TOKEN is used as the key for the DES function to generate an 8 bytes value for the following inputs. The DES CBC mode Initialization Vector (IV) is 8 bytes of '00'X.
- RDrSEQ: the random data value received from the partner LU plus the sequence number.
- RDs: the random data value sent to the partner LU on BIND for this session.
- A 16 byte value, created by:
- padding the user identifier with
'40'Xto a length of 16 bytes. - Exclusive OR'ing the two 8 byte halves of the padded user identifier with the RDrSEQ value.
- Note: the User ID must first be converted to EBCDIC uppercase.
- padding the user identifier with
- PWSEQs: the sequence number.
This works a lot like the process used for LU-LU verification, as described in the Enhanced LU-LU Bind Security. The resulting enciphered random data is the 'password substitute' 🌈.
5.2 Handling passwords of length 9 and 10 🍓
- Make PW_TOKENa by using characters 1 to 8 of the password and steps 1-4 from the previous section.
- Make PW_TOKENb by using characters 9 and 10 and steps 1-4 from the previous section. In this case, Padded_PW from step 1 will be characters 9 and 10 padded to the right with
'40'X, for a total length of 8. PW_TOKEN = PW_TOKENa xor PW_TOKENb- Now compute PW_SUB by performing steps 5-7 from the previous section.
5.3 Example Password Substitute Calculation 🧁
ID: USER123
Password: ABCDEFG
Server seed: '7D4C2319F28004B2'X
Client seed: '08BEF662D851F4B1'X
PWSEQs: 1 (PWSEQs is a sequence number needed in the
7-step encryption, and it is always one)
Encrypted Password should be : '5A58BD50E4DD9B5F'X6. Device Name Collision Processing 🎀
okay this one is so relatable 😭. Device name collision happens when a Telnet client tells the Telnet server the virtual device name it wants to use, but that device is already in use on the server. When that happens, the Telnet server asks the client to try a different device name 🙅♀️. The environment option negotiation uses the USERVAR name DEVNAME to pass along the virtual device name. Here's how the Telnet server asks the Telnet client to send a different DEVNAME when a collision happens 👀.
AS/400 Telnet server Enhanced Telnet client
-------------------------- -------------------------
IAC SB NEW-ENVIRON SEND
VAR USERVAR IAC SE -->
Server requests all environment variables be sent.
IAC SB NEW-ENVIRON IS USERVAR
"DEVNAME" VALUE "MYDEVICE1"
USERVAR "xxxxx" VALUE "xxx"
...
<-- IAC SE
Client sends all environment variables, including DEVNAME. Server
tries to select device MYDEVICE1. If the device is already in use,
server requests DEVNAME be sent again.
IAC SB NEW-ENVIRON SEND
USERVAR "DEVNAME" IAC SE -->
Server sends a request for a single environment variable: DEVNAME
IAC SB NEW-ENVIRON IS USERVAR
<-- "DEVNAME" VALUE "MYDEVICE2" IAC SE
Client sends one environment variable, calculating a new value of
MYDEVICE2. If MYDEVICE2 is different from the last request, then
server tries to select device MYDEVICE2, else server disconnects
client. If MYDEVICE2 is also in use, server will send DEVNAME
request again, and keep doing so until it receives a device that is
not in use, or the same device name twice in row.7. Enhanced Printer Emulation Support ✨
okay so the RFC 1572 style USERVAR variables are the real MVP here 💅 They give a compliant Telnet client way more control over the Telnet server virtual device on the AS/400. The client can pick a virtual device that already exists, or ask for a brand new one with the attributes it wants 🖨️
This is giving choice. Any Telnet client that chooses to support the new negotiations gets these enhancements, so it's basically an open invitation 🦋
The USERVAR's defined to make this happen are:
USERVAR VALUE EXAMPLE DESCRIPTION
------------- ---------------- ---------------- -------------------
DEVNAME us-ascii char(x) PRINTER1 Printer device name
IBMIGCFEAT us-ascii char(6) 2424J0 IGC feature (DBCS)
IBMMSGQNAME us-ascii char(x) QSYSOPR *MSGQ name
IBMMSGQLIB us-ascii char(x) QSYS *MSGQ library
IBMFONT us-ascii char(x) 12 Font
IBMFORMFEED us-ascii char(1) C | U | A Formfeed
IBMTRANSFORM us-ascii char(1) 1 | 0 Transform
IBMMFRTYPMDL us-ascii char(x) *IBM42023 Mfg. type and model
IBMPPRSRC1 binary(1) 1-byte hex field Paper source 1
IBMPPRSRC2 binary(1) 1-byte hex field Paper source 2
IBMENVELOPE binary(1) 1-byte hex field Envelope hopper
IBMASCII899 us-ascii char(1) 1 | 0 ASCII 899 support
IBMWSCSTNAME us-ascii char(x) *NONE WSCST name
IBMWSCSTLIB us-ascii char(x) *LIBL WSCST libraryx - up to a maximum of 10 characters
The "IBM" prefix on the USERVAR's is how you know it's AS/400 specific 🧚
The DEVNAME USERVAR is used for both displays and printers 🌸 The IBMFONT and IBMASCII899 are only used for SBCS environments, so no DBCS drama there ✨
For a description of most of these parameters (drop the "IBM" from the USERVAR) and their permissible values, check out Chapter 8 in the Communications Configuration Reference [5]. It's the source of truth bestie 📚
The IBMIGCFEAT takes variable DBCS language identifiers in position 5. Positions 1-4 must be '2424', and position 6 must be '0':
'J' = Japanese 'K' = Korean
'C' = Traditional Chinese 'S' = Simplified ChineseThe IBMTRANSFORM and IBMASCII899 values correspond to:
'1' = Yes '2' = NoThe IBMFORMFEED values correspond to:
'C' = Continuous 'U' = Cut 'A' = AutocutThe IBMPPRSRC1, IBMPPRSRC2 and IBMENVELOPE custom USERVAR's do NOT map directly to their descriptions in Chapter 8 of the Communications Configuration Reference [5]. Use the index below to map them. This is the one place you can't just guess 🙈
IBMPPRSRC1 HEX IBMPPRSRC2 HEX IBMENVELOPE HEX
---------- ----- ---------- ----- ----------- -----
*NONE 'FF'X *NONE 'FF'X *NONE 'FF'X
*MFRTYPMDL '00'X *MFRTYPMDL '00'X *MFRTYPMDL '00'X
*LETTER '01'X *LETTER '01'X *B5 '06'X
*LEGAL '02'X *LEGAL '02'X *MONARCH '09'X
*EXECUTIVE '03'X *EXECUTIVE '03'X *NUMBER9 '0A'X
*A4 '04'X *A4 '04'X *NUMBER10 '0B'X
*A5 '05'X *A5 '05'X *C5 '0C'X
*B5 '06'X *B5 '06'X *DL '0D'X
*CONT80 '07'X *CONT80 '07'X
*CONT132 '08'X *CONT132 '08'X
*A3 '0E'X *A3 '0E'X
*B4 '0F'X *B4 '0F'X
*LEDGER '10'X *LEDGER '10'XNote 1: For IBMPPRSRC2, *CONT80 and *CONT132 support starts at V3R7.
Note 2: For IBMPPRSRC1 and IBMPPRSRC2, *A3, *B4 and *LEDGER support starts at V3R7.
8. Telnet Printer Terminal Types 🖨️
okay this part is so fun 🎀 New Telnet options get defined for the printer pass-through mode. To turn printer pass-through mode on, the client and server must both agree to support at least the Transmit-Binary, End-Of-Record, and Terminal-Type Telnet options. The new terminal types for printers are:
TERMINAL-TYPE DESCRIPTION
------------- -------------------
IBM-5553-B01 Double-Byte printer
IBM-3812-1 Single-Byte printerThe specific characteristics of the IBM-5553-B01 or IBM-3812-1 printers are set through the USERVAR IBMMFRTYPMDL, which specifies the manufacturer type and model 💅
Here's an example of a typical negotiation to establish printer pass-through mode. The server kicks things off by sending the DO TERMINAL-TYPE request ✨
For DBCS environments, if IBMTRANSFORM is set to 1 (use Host Print Transform), the virtual device created is 3812, not 5553. So IBM-3812-1 should be negotiated for TERMINAL-TYPE, not IBM-5553-B01. Don't mix those up 🙈
AS/400 Telnet server Enhanced Telnet client
-------------------------- --------------------------
IAC DO NEW-ENVIRON -->
<-- IAC WILL NEW-ENVIRON
IAC SB NEW-ENVIRON SEND
VAR USERVAR IAC SE -->
IAC SB NEW-ENVIRON IS
USERVAR "DEVNAME" VALUE "PCPRINTER"
USERVAR "IBMMSGQNAME" VALUE "QSYSOPR"
USERVAR "IBMMSGQLIB" VALUE "*LIBL"
USERVAR "IBMTRANSFORM" VALUE "0"
USERVAR "IBMFONT" VALUE "12"
USERVAR "IBMFORMFEED" VALUE "C"
USERVAR "IBMPPRSRC1" VALUE ESC '01'X
USERVAR "IBMPPRSRC2" VALUE '04'X
USERVAR "IBMENVELOPE" VALUE IAC 'FF'X
<-- IAC SE
IAC DO TERMINAL-TYPE -->
<-- IAC WILL TERMINAL-TYPE
IAC SB TERMINAL-TYPE SEND
IAC SE -->
IAC SB TERMINAL-TYPE IS IBM-3812-1
<-- IAC SE
IAC DO BINARY -->
<-- IAC WILL BINARY
IAC DO EOR -->
<-- IAC WILL EORA few things to notice about that example 👀 The IBMPPRSRC1 value needs to be escaped with ESC, following RFC 1572 [13]. The IBMPPRSRC2 doesn't need an ESC character, since '04'X doesn't clash with any RFC 1572 options. And to send 'FF'X for the IBMENVELOPE value, you escape it by sending another 'FF'X (this is called "doubling"), so it doesn't get read as a Telnet character per RFC 854 [8]. Doubling is the move 🫶
Here are the actual bytes sent in the example above, in hex:
AS/400 Telnet server Enhanced Telnet client
-------------------------- --------------------------
FF FD 27 -->
<-- FF FB 27
FF FA 27 01 00 03 FF F0 -->
FF FA 27 00 03 44 45 56
4E 41 4D 45 01 50 43 50
52 49 4E 54 45 52 03 49
42 4D 4D 53 47 51 4E 41
4D 45 01 51 53 59 53 4F
50 52 03 49 42 4D 4D 53
47 51 4C 49 42 01 2A 4C
49 42 4C 03 49 42 4D 54
52 41 4E 53 46 4F 52 4D
01 30 03 49 42 4D 46 4F
4E 54 01 31 32 03 49 42
4D 46 4F 52 4D 46 45 45
44 01 43 03 49 42 4D 50
50 52 53 52 43 31 01 02
01 03 49 42 4D 50 50 52
53 52 43 32 01 04 03 49
42 4D 45 4E 56 45 4C 4F
<-- 50 45 01 FF FF FF F0
FF FD 18 -->
<-- FF FB 18
FF FA 18 01 FF F0 -->
FF FA 18 00 49 42 4D 2D
<-- 33 38 31 32 2D 31 FF F0
FF FD 00 -->
<-- FF FB 00
FF FD 19 -->
FF FB 199. Telnet Printer Startup Response Record for Printer Emulators 🧚
so once Telnet negotiation for 5250 pass-through mode is done, the 5250 Telnet server starts a virtual printer power-on sequence on behalf of the Telnet client 💖 The server then sends a Startup Response Record to the client, with the status of that power-on sequence. It says whether the virtual printer powered on successfully or not 🔥
This section has an example of two Startup Response Records. The source device is a type 3812 model 01 printer named "PCPRINTER" on the target system "TARGET" 🖨️
Figure 1 is a successful response, and Figure 2 is an error response.
9.1 Example of a Success Response Record 🌈
The response record in Figure 1 was sent by an AS/400 at Release V4R2. It's a textbook example of the target sending back a successful Startup Response Record ✨
+------------------------------------------------------------------+
| +----- Pass-Through header |
| | +--- Response data |
| | | +---- Start diagnostic information|
| | | | |
| +----------++----------++--------------------------------------- |
| | || || |
| 004912A090000560060020C0003D0000C9F9F0F2E3C1D9C7C5E34040D7C3D7D9 |
| | | T A R G E T P C P R |
| +------+ |
| Response Code (I902) |
| |
| ---------------------------------------------------------------- |
| |
| C9D5E3C5D9400000000000000000000000000000000000000000000000000000 |
| I N T E R |
| |
| +------- End of diagnostic information |
| | |
| -----------------+ |
| | |
| 000000000000000000 |
+------------------------------------------------------------------+Figure 1. Example of a success response record.
Here's the breakdown, bit by bit 🔍
'0049'X= Length pass-through data, including this length field'12A0'X= GDS LU6.2 header'90000560060020C0003D0000'X= Fixed value fields'C9F9F0F2'X= Response Code (I902)'E3C1D9C7C5E34040'X= System Name (TARGET)'D7C3D7D9C9D5E3C5D940'X= Object Name (PCPRINTER)
9.2. Example of an Error Response Record 🚨
okay so the response record in Figure 2 is the one that reports an error 😭🎀 The virtual device named "PCPRINTER" is not available on the target system "TARGET" because the device is not available. You'd normally run into this one if the printer was already assigned to another Telnet session 💀
+------------------------------------------------------------------+
| +----- Pass-Through header |
| | +--- Response data |
| | | +---- Start diagnostic information|
| | | | |
| +----------++----------++--------------------------------------- |
| | || || |
| 004912A09000056006008200003D0000F8F9F0F2E3C1D9C7C5E34040D7C3D7D9 |
| | | T A R G E T P C P R |
| +------+ |
| Response Code (8902) |
| |
| ---------------------------------------------------------------- |
| |
| C9D5E3C5D9400000000000000000000000000000000000000000000000000000 |
| I N T E R |
| |
| +------- End of diagnostic information |
| | |
| -----------------+ |
| | |
| 000000000000000000 |
+------------------------------------------------------------------+Figure 2. Example of an error response record.
Here's how the pieces break down, bestie 🧚
'0049'X= Length pass-through data, including this length field'12A0'X= GDS LU6.2 header'90000560060020C0003D0000'X= Fixed value fields'F8F9F0F2'X= Response Code (8902)'E3C1D9C7C5E34040'X= System Name (TARGET)'D7C3D7D9C9D5E3C5D940'X= Object Name (PCPRINTER)
9.3. Response Codes 💅
Let's talk codes, because these are literally the vibes 🔥 First up are the Start-Up Response Record success response codes:
CODE DESCRIPTION
---- ------------------------------------------------------
I901 Virtual device has less function than source device
I902 Session successfully started
I906 Automatic sign-on requested, but not allowed.
Session still allowed; a sign-on screen will be
coming.Now the Start-Up Response Record error response codes. There's a lot here, so grab a snack 🍓
CODE DESCRIPTION
---- ------------------------------------------------------
2702 Device description not found.
2703 Controller description not found.
2777 Damaged device description.
8901 Device not varied on.
8902 Device not available.
8903 Device not valid for session.
8906 Session initiation failed.
8907 Session failure.
8910 Controller not valid for session.
8916 No matching device found.
8917 Not authorized to object.
8918 Job canceled.
8920 Object partially damaged.
8921 Communications error.
8922 Negative response received.
8923 Start-up record built incorrectly.
8925 Creation of device failed.
8928 Change of device failed.
8929 Vary on or vary off failed.
8930 Message queue does not exist.
8934 Start-up for S/36 WSF received.
8935 Session rejected.
8936 Security failure on session attempt.
8937 Automatic sign-on rejected.
8940 Automatic configuration failed or not allowed.
I904 Source system at incompatible release.10. Printer Steady-State Pass-Through Interface 🦋
okay so this section is all about what's going on after the startup confirmation records are done ✨ Everything here applies to the passthrough session from that point on, so it's basically the main stage 💖
Here's the printer header interface Telnet uses 👑
+------------------------------------------------------------------+
| +-- Length of structure (LLLL) |
| | |
| | +-- GDS identifier |
| | | |
| | | +-- Data flow record |
| | | | |
| | | | +-- Length of pass-through specific header (LL) |
| | | | | |
| | | | | +-- Flags |
| | | | | | |
| | | | | | +-- Printer operation code |
| | | | | | | |
| | | | | | | +-- Diagnostic field - zero pad to|
| | | | | | | | LL specified |
| | | | | | | | |
| | | | | | | | +-- Printer data |
| | | | | | | | | |
| +--+ +--+ +--+ ++ +--+ ++ +----------+ +----------------+ |
| | | | | | | || | | || | | | | |
| xxxx 12A0 xxxx xx xxxx xx xxxxxxxxxxxx ... print data ... |
| |
+------------------------------------------------------------------+Figure 3. Layout of the printer pass-through header
Now let's go byte by byte, because the details are the whole point 🎀
BYTES 0-1: Length of structure including this field (LLLL)
BYTES 2-3: GDS Identifier ('12A0'X)
BYTE 4-5: Data flow record
This field holds flags that describe what type of data pass-through should expect to find after this header. Generally, bits 0-2 in the first byte are mutually exclusive, which means that if one of them is set to '1'B, the rest will be set to '0'B. The bits and what they mean are below 🌈
BIT DESCRIPTION
0 Start-Up confirmation
1 Termination record
2 Start-Up Record
3 Diagnostic information included
4 - 5 Reserved
6 Reserved
7 Printer record
8 - 13 Reserved
14 Client-originated (inbound) printer record
15 Server-originated (outbound) printer recordBYTE 6: Length printer pass-through header including this field (LL)
BYTES 7-8: Flags
BYTE 7 BITS:
xxxx x111 --> Reserved
xxxx 1xxx --> Last of chain
xxx1 xxxx --> First of chain
xx1x xxxx --> Printer now ready
x1xx xxxx --> Intervention Required
1xxx xxxx --> Error IndicatorBYTE 8 BITS:
xxxx xxxx --> ReservedBYTE 9: Printer operation code
'01'X Print/Print complete
'02'X Clear Print BuffersBYTE 10-LL: Diagnostic information (1)
If BYTE 7 = xx1x xxxx, then bytes 10-LL may contain:
Printer ready C9 00 00 00 02If BYTE 7 = x1xx xxxx, then bytes 10-LL may contain: (2)
Command/parameter not valid C9 00 03 02 2x
Print check C9 00 03 02 3x
Forms check C9 00 03 02 4x
Normal periodic condition C9 00 03 02 5x
Data stream error C9 00 03 02 6x
Machine/print/ribbon check C9 00 03 02 8xIf BYTE 7 = 1xxx xxxx, then bytes 10-LL may contain: (3)
Cancel 08 11 02 00
Invalid print parameter 08 11 02 29
Invalid print command 08 11 02 28Diagnostic information notes: ⭐
- LL is the length of the structure defined in Byte 6. If no additional data is present, the remainder of the structure must be padded with zeroes.
- These are printer SIGNAL commands. Further information on these commands may be obtained from the 5494 Remote Control Unit Functions Reference guide [2]. Refer to your AS/400 printer documentation for more specific information on these data stream exceptions. Some 3812 and 5553 errors that may be seen:
Machine check C9 00 03 02 11
Graphics check C9 00 03 02 26
Print check C9 00 03 02 31
Form jam C9 00 03 02 41
Paper jam C9 00 03 02 47
End of forms C9 00 03 02 50
Printer not ready C9 00 03 02 51
Data stream - class 1 C9 00 03 02 66 loss of text
Data stream - class 2 C9 00 03 02 67 text appearance
Data stream - class 3 C9 00 03 02 68 multibyte control error
Data stream - class 4 C9 00 03 02 69 multibyte control parm
Cover unexpectedly open C9 00 03 02 81
Machine check C9 00 03 02 86
Machine check C9 00 03 02 87
Ribbon check C9 00 03 02 88- These are printer negative responses. Further information on these commands may be obtained from the 5494 Remote Control Unit Functions Reference guide [2].
The print data will start in byte LL+1 💜
10.1 Example of a Print Record ✨
Okay so Figure 4 shows the server sending the client data with a print record 🖨️ This is normally seen right after a Success Response Record, like the one in Figure 1 💖
+--------------------------------------------------------------------+
| +-- Length of structure (LLLL) |
| | +-- GDS identifier |
| | | +-- Data flow record |
| | | | +-- Length of pass-through specific header (LL) |
| | | | | +-- Flags |
| | | | | | +-- Printer operation code |
| | | | | | | +-- Zero pad to LL specified (0A) |
| | | | | | | | +-- Printer data |
| | | | | | | | | |
| +--+ +--+ +--+ ++ +--+ ++ +----------+ +---------------------------|
| | | | | | | || | | || | | | |
| 0085 12A0 0101 0A 1800 01 000000000000 34C4012BD20345FF2BD2044C0002|
| |
| ------------------------------------------------------------ |
| |
| 2BD2040D00002BD20A8501010201030204022BD20309022BD2061100014A |
| |
| ------------------------------------------------------------ |
| |
| 402BD20601010000012BD306F60000FFFF2BD20A48000001000000010100 |
| |
| ------------------------------------------------------------ |
| |
| 2BD10705000B0090012BD2044900F02BD206404A403DE02BD2041500F034 |
| |
| end of printer data |
| -------------------------+ |
| | |
| C4012BD10381FF002BC8034001 |
+--------------------------------------------------------------------+Figure 4. Server sending client data with a print record
'0085'X= Logical record length, including this byte (LLLL)'12A0'X= GDS LU6.2 header'0101'X= Data flow record (server to client)'0A'X= Length of pass-through specific header (LL)'1800'X= First of chain / Last of chain indicators'01'X= Print'000000000000'X= Zero pad header to LL specified'34C401'X= First piece of data for spooled data- Remainder is printer data/commands/orders
10.2 Example of a Print Complete Record 💅
Figure 5 shows the client sending the server a print complete record 🫶 This would normally come right after a print record, like the example in Figure 4. It basically says the print request went through successfully 🎀
+-------------------------------------------------------------------+
| +-- Length of structure (LLLL) |
| | +-- GDS identifier |
| | | +-- Data flow record |
| | | | +-- Length of pass-through specific header (LL) |
| | | | | +-- Flags |
| | | | | | +-- Printer operation code |
| | | | | | | |
| +--+ +--+ +--+ ++ +--+ ++ |
| | | | | | | || | | || |
| 000A 12A0 0102 04 0000 01 |
+-------------------------------------------------------------------+Figure 5. Client sending server a print complete record
'000A'X= Logical record length, including this byte (LLLL)'12A0'X= GDS LU6.2 header'0102'X= Data flow response record (client to server)'04'X= Length of pass-through specific header (LL)'0000'X= Good Response'01'X= Print Complete
10.3 Example of a Null Print Record 🌈
Figure 6 shows the server sending the client a null print record 🧚 The null print record is the last print command the server sends to the client for a print job, and it tells the printer there is no more data 😭 The null data byte '00'X is optional, and in some cases may be omitted (in particular, this scenario occurs in DBCS print streams) 🙈
This example would normally follow any number of print records, such as the example in Figure 4. It indicates successful completion of a print job 🔥 The client normally responds to this null print record with another print complete record, such as in Figure 5 💜
+------------------------------------------------------------------+
| +-- Length of structure (LLLL) |
| | +-- GDS identifier |
| | | +-- Data flow record |
| | | | +-- Length of pass-through specific header (LL) |
| | | | | +-- Flags |
| | | | | | +-- Printer operation code |
| | | | | | | +-- Zero pad to LL specified (0A) |
| | | | | | | | +-- Printer data |
| | | | | | | | | |
| +--+ +--+ +--+ ++ +--+ ++ +----------+ ++ |
| | | | | | | || | | || | | || |
| 0011 12A0 0101 0A 0800 01 000000000000 00 |
+------------------------------------------------------------------+Figure 6. Server sending client a null print record
'0011'X= Logical record length, including this byte'12A0'X= GDS LU6.2 header'0101'X= Data flow record'0A'X= Length of pass-through specific header (LL)'0800'X= Last of Chain'01'X= Print'000000000000'X= Zero pad header to LL specified'00'X= Null data byte
11. End-to-End Print Example 🎀
okay bestie, this is the full print exchange between a Telnet client and server for a 526 byte spooled file 🖨️✨ the hex streams are hard to read on their own, so I've pulled out the Telnet negotiations and the ASCII/EBCDIC characters to make it easier to follow. Telnet negotiations are wrapped in ( and ) parentheses, and ASCII/EBCDIC conversions are wrapped in | vertical bars 💜
AS/400 Telnet server Enhanced Telnet client
------------------------------- ---------------------------------
FFFD27 -->
(IAC DO NEW-ENVIRON)
<-- FFFB27
(IAC WILL NEW-ENVIRON)
FFFD18FFFA270103 49424D5253454544
7EA5DFDDFD300404 0003FFF0 -->
(IAC DO TERMINAL-TYPE
IAC SB NEW-ENVIRON SEND USERVAR
IBMRSEED xxxxxxxx VAR USERVAR
IAC SE)
<-- FFFB18
(IAC WILL TERMINAL-TYPE)
FFFA1801FFF0 -->
(IAC SB TERMINAL-TYPE SEND IAC
SE)
FFFA27000349424D 52534545447EA5DF
DDFD300404000344 45564E414D450144
554D4D5950525403 49424D4D5347514E
414D450151535953 4F50520349424D4D
5347514C4942012A 4C49424C0349424D
464F4E5401313103 49424D5452414E53
464F524D01310349 424D4D4652545950
4D444C012A485049 490349424D505052
5352433101020103 49424D5050525352
433201040349424D 454E56454C4F5045
01FFFF0349424D41 5343494938393901
<-- 30FFF0
(IAC SB NEW-ENVIRON IS USERVAR
IBMRSEED xxxxxxxx VAR
USERVAR DEVNAME VALUE DUMMYPRT
USERVAR IBMMSGQNAME VALUE QSYSOPR
USERVAR IBMMSGQLIB VALUE *LIBL
USERVAR IBMFONT VALUE 11
USERVAR IBMTRANSFORM VALUE 1
USERVAR IBMMFRTYPMDL VALUE *HPII
USERVAR IBMPPRSRC1 VALUE ESC '01'X
USERVAR IBMPPRSRC2 VALUE '04'X
USERVAR IBMENVELOPE VALUE IAC
USERVAR IBMASCII899 VALUE 0
IAC SE)
<-- FFFA180049424D2D 333831322D31FFF0
(IAC SB TERMINAL-TYPE IS
IBM-3812-1 IAC SE)
FFFD19 -->
(IAC DO EOR)
<-- FFFB19
(IAC WILL EOR)
FFFB19 -->
(IAC WILL EOR)
<-- FFFD19
(IAC DO EOR)
FFFD00 -->
(IAC DO BINARY)
<-- FFFB00
(IAC WILL BINARY)
FFFB00 -->
(IAC WILL BINARY)
<-- FFFD00
(IAC DO BINARY)
004912A090000560 060020C0003D0000 | - { |
C9F9F0F2C5D3C3D9 E3D7F0F6C4E4D4D4 |I902ELCRTP06DUMM| (EBCDIC)
E8D7D9E340400000 0000000000000000 |YPRT |
0000000000000000 0000000000000000 | |
0000000000000000 00FFEF --> | |
(73-byte startup success response
record ... IAC EOR)
00DF12A001010A18 0001000000000000 | |
03CD1B451B283130 551B287330703130 | E (10U (s0p10| (ASCII)
2E30306831327630 733062303033541B |.00h12v0s0b003T |
287330421B266440 1B266C304F1B266C |(s0B &d@ &l0O &l|
303038431B266C30 3035431B28733070 |008C &l005C (s0p|
31372E3130683130 7630733062303030 |17.10h10v0s0b000|
541B283130551B28 73307031372E3130 |T (10U (s0p17.10|
6831307630733062 303030541B287330 |h10v0s0b000T (s0|
421B2664401B266C 314F1B266C303035 |B &d@ &l1O &l005|
431B287330703137 2E31306831307630 |C (s0p17.10h10v0|
733062303030541B 266C314F1B287330 |s0b000T &l1O (s0|
7031372E31306831 3076307330623030 |p17.10h10v0s0b00|
30541B2873307031 372E313068313076 |0T (s0p17.10h10v|
3073306230303054 1B266C30303543FF |0s0b000T &l005C |
EF --> | |
(... 223-byte print record ...
... first of chain ...
... last of chain ... IAC EOR)
<-- 000A12A001020400 0001FFEF
(10-byte print complete header)
031012A001010A10 0001000000000000 | |
03FFFF1B451B2831 30551B2873307031 | E (10U (s0p1| (ASCII)
372E313068313076 3073306230303054 |7.10h10v0s0b000T|
1B287330421B2664 401B266C314F1B26 | (s0B &d@ &l1O &|
6C303035431B266C 31481B266C314F1B |l005C &l1H &l1O |
266C3032411B266C 31431B266C303030 |&l02A &l1C &l000|
38451B266C303038 431B266C30303439 |8E &l008C &l0049|
461B266130521B26 6C303035430A0A0A |F &a0R &l005C |
0A0A0A0A1B26612B 3030303130561B26 | &a+00010V &|
6C303035431B2661 2B30303231364820 |l005C &a+00216H |
2020202020202020 2020202020202020 | |
2020202020205072 696E74204B657920 | Print Key |
4F75747075742020 2020202020202020 |Output |
2020202020202020 2020202020202020 | |
2020202020205061 6765202020310D0A | Page 1 |
1B26612B30303231 3648202020203537 | &a+00216H 57|
3639535331205634 52334D3020393830 |69SS1 V4R3M0 980|
373203FFFF392020 2020202020202020 |72 9 |
202020202020454C 4352545030362020 | ELCRTP06 |
2020202020202020 202030332F33312F | 03/31/|
3939202031363A33 303A34350D0A1B26 |99 16:30:45 &|
612B303032313648 0D0A1B26612B3030 |a+00216H &a+00|
3231364820202020 446973706C617920 |216H Display |
4465766963652020 2E202E202E202E20 |Device . . . . |
2E203A2020515041 444556303033510D |. : QPADEV003Q |
0A1B26612B303032 3136482020202055 | &a+00216H U|
73657220202E202E 202E202E202E202E |ser . . . . . .|
202E202E202E202E 203A202052434153 | . . . . : RCAS|
54524F0D0A1B2661 2B3030323136480D |TRO &a+00216H |
0A1B26612B303032 313648204D41494E | &a+00216H MAIN|
2020202020202020 2020202020202020 | |
2020202020202020 20202041532F3430 | AS/40|
30204D61696E204D 656E750D0A1B2661 |0 Main Menu &a|
2B30303203FFFF31 3648202020202020 |+002 16H |
2020202020202020 2020202020202020 | |
2020202020202020 2020202020202020 | |
2020202020202020 2020202020202020 | |
2020202020202053 797374656D3A2020 | System: |
20454C4352545030 360D0A1B26612B30 | ELCRTP06 &a+0|
3032313648205365 6C656374206F6E65 |0216H Select one|
206F662074686520 666F6C6C6F77696E | of the followin|
673A0D0A1B26612B 3030323136480D0A |g: &a+00216H |
1B26612B30303231 3648202020202020 | &a+00216H |
312E205573657220 7461736B730D0A1B |1. User tasks |
26612B3030323136 4820202020202032 |&a+00216H 2|
2E204F6666696365 207461736B730D0A |. Office tasks |
1B26612B30303231 36480D0A1B26612B | &a+00216H &a+|
3030323136482020 20202020342E2046 |00216H 4. F|
696C65732C206C69 627261726965732C |iles, libraries,|
20616EFFEF | an |
(... 784-byte print record ...
... first of chain ... IAC EOR)
<-- 000A12A001020400 0001FFEF
(10-byte print complete header)
020312A001010A00 0001000000000000 | |
64206603FFFF6F6C 646572730D0A1B26 |d f olders &| (ASCII)
612B303032313648 0D0A1B26612B3030 |a+00216H &a+00|
3231364820202020 2020362E20436F6D |216H 6. Com|
6D756E6963617469 6F6E730D0A1B2661 |munications &a|
2B3030323136480D 0A1B26612B303032 |+00216H &a+002|
3136482020202020 20382E2050726F62 |16H 8. Prob|
6C656D2068616E64 6C696E670D0A1B26 |lem handling &|
612B303032313648 202020202020392E |a+00216H 9.|
20446973706C6179 2061206D656E750D | Display a menu |
0A1B26612B303032 3136482020202020 | &a+00216H |
31302E20496E666F 726D6174696F6E20 |10. Information |
417373697374616E 74206F7074696F6E |Assistant option|
730D0A1B26612B30 3032313648202020 |s &a+00216H |
202031312E20436C 69656E7420416363 | 11. Client Acc|
6573732F34303020 7461736B730D0A1B |ess/400 tasks |
26612B3030323136 480D0A1B26612B30 |&a+00216H &a+0|
303231364803ED20 2020202039302E20 |0216H 90. |
5369676E206F6666 0D0A1B26612B3030 |Sign off &a+00|
323136480D0A1B26 612B303032313648 |216H &a+00216H|
2053656C65637469 6F6E206F7220636F | Selection or co|
6D6D616E640D0A1B 26612B3030323136 |mmand &a+00216|
48203D3D3D3E0D0A 1B26612B30303231 |H ===> &a+0021|
36480D0A1B26612B 3030323136482046 |6H &a+00216H F|
333D457869742020 2046343D50726F6D |3=Exit F4=Prom|
707420202046393D 5265747269657665 |pt F9=Retrieve|
2020204631323D43 616E63656C202020 | F12=Cancel |
4631333D496E666F 726D6174696F6E20 |F13=Information |
417373697374616E 740D0A1B26612B30 |Assistant &a+0|
3032313648204632 333D53657420696E |0216H F23=Set in|
697469616C206D65 6E750D0A1B26612B |itial menu &a+|
3030323136480D0A 1B26612B30303231 |00216H &a+0021|
36480D0CFFEF |6H |
(... 515-byte print record ...
IAC EOR)
<-- 000A12A001020400 0001FFEF
(10-byte print complete header)
001412A001010A00 0001000000000000 | |
03021B45FFEF | E | (ASCII)
(... 20-byte print record ...
IAC EOR)
<-- 000A12A001020400 0001FFEF
(10-byte print complete header)
001112A001010A08 0001000000000000
00FFEF -->
(... 17-byte NULL print record ...
... last of chain ... IAC EOR)
<-- 000A12A001020400 0001FFEF
(10-byte print complete header)12. Authors' Note 🌸
okay so the last bit is the bit where you find the people to actually talk to 🫶 discussion of this memo should happen on one of these mailing lists:
- TN3270E List (Roger Fajman raf@cu.nih.gov). To subscribe, send an e-mail with "subscribe tn3270e your_full_name" to listserv@list.nih.gov.
- Midrange-L List (David Gibbs david@midrange.com). To subscribe, send an email with "subscribe midrange-l your_internet_address" to majordomo@midrange.com.
- Telnet Working Group Mailing List: to subscribe, send an email with "subscribe telnet-ietf" to telnet-ietf-request@bsdi.com. 💜
13. References ✨
Okay bestie, here's the reading list, the whole stack of docs this spec leans on 📚
[1] IBM, "IBM 5250 Information Display System, Functions Reference Manual", SA21-9247-6, March 1987.
[2] IBM, "5494 Remote Control Unit, Functions Reference", SC30-3533-04, August 1995.
[3] IBM, "AS/400 System API Reference", SC41-5801-01, February 1998.
[4] IBM, "AS/400 TCP/IP Configuration and Reference", SC41-5420-02, September 1998.
[5] IBM, "AS/400 Communications Configuration", SC41-5401-00, August 1997.
[6] IBM, "SNA Formats", GA27-3136-13, November 1993.
[7] IBM, "Using the Pageprinter 3812 with System/36 or System/38", S544-3343-01, September 1997.
[8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[9] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
[10] Postel, J. and J. Reynolds, "Telnet Binary Transmission", STD 27, RFC 856, May 1983.
[11] VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091, February 1989.
[12] Postel, J. and J. Reynolds, "Telnet End of Record Option", RFC 885, December 1983.
[13] Alexander, S., "Telnet Environment Option", RFC 1572, January 1994.
[14] Chmielewski, P., "5250 Telnet Interface", RFC 1205, February 1991.
[15] Postel, J. and J. Reynolds, "Telnet Supress Go Ahead Option", STD 29, RFC 858, May 1983.
[16] IBM, "AS/400 National Language Support", SC41-5101-01, February 1998.
[17] Data Encryption Standard (DES), Federal Information Processing Standards Publication 46-2, January 22, 1988.
[18] DES Modes of Operation, Federal Information Processing Standards Publication 81, December 1980.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[20] IBM, "IBM Pageprinter 3812 Programming Reference", S544-3268.
14. Security Considerations 🔐
Okay, security is a whole thing and we are NOT skipping it 🙈 Passwords get their own deep dive, so check out Section 6 for the tea on those.
15. Authors' Addresses 💌
Here's who wrote this, and how to reach them if you have questions 🫶
Thomas E. Murphy, Jr.
IBM Corporation
1701 North Street
Endicott, NY 13760
Phone: (607) 752-5482
Fax: (607) 752-5421
EMail: murphyte@us.ibm.com
Paul F. Rieth
IBM Corporation
1701 North Street
Endicott, NY 13760
Phone: (607) 752-5474
Fax: (607) 752-5421
EMail: rieth@us.ibm.com
Jeffrey S. Stevens
IBM Corporation
1701 North Street
Endicott, NY 13760
Phone: (607) 752-5488
Fax: (607) 752-5421
EMail: jssteven@us.ibm.com16. Relation to Other RFC's 🦋
UPDATES
This memo updates RFC 1205 [14], which describes the 5250 Telnet Interface. This update enhances that description to include device negotiation as well as printer support.
This memo makes use of RFC 1572 [13] to enhance communications with 5250 Telnet clients. RFC 1572 is currently on the Standards Track as a Proposed Standard, and is listed in Assigned Numbers [19].
17. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally the reason this whole library exists 💜
📦 where this page comes from
- ietf: rfc2877 2000-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms