TCP/IP Configuration and Reference

TCP/IP Configuration and Reference
AS/400e
IBM
TCP/IP Configuration and Reference
Version 4
SC41-5420-03
AS/400e
IBM
TCP/IP Configuration and Reference
Version 4
SC41-5420-03
Note
Before using this information and the product it supports, be sure to read the information in “Notices” on page 595.
Fourth Edition (May 1999)
This edition replaces SC41-5420-02. This edition applies only to reduced instruction set computer (RISC) systems.
© Copyright International Business Machines Corporation 1997, 1999. All rights reserved.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
About TCP/IP Configuration and Reference
TCP/IP Topics in the Information Center . .
Who should read this book . . . . . . .
AS/400 Operations Navigator . . . . . .
Installing Operations Navigator. . . . .
Prerequisite and related information . . . .
How to send your comments . . . . . .
(SC41-5420)
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Chapter 1. TCP/IP on AS/400 . . . . . . .
Linking Networks Together . . . . . . . .
Internetwork Communications . . . . . . .
Internet Addresses . . . . . . . . . . .
Accessing the Internet . . . . . . . . .
IP Security . . . . . . . . . . . . .
Classes of Networks . . . . . . . . .
IP Subnets . . . . . . . . . . . . . .
Subnetworks and Subnet Masks . . . . . .
Broadcast Addresses . . . . . . . . . .
Domain Name System (DNS) . . . . . . .
Domain and Host Name . . . . . . . .
Naming Conventions for Domain Names and
Routing . . . . . . . . . . . . . . .
Introduction to TCP/IP Protocols on AS/400 . .
Application Protocols . . . . . . . . . .
Application Protocol Standards. . . . . .
OS/400 Network File System Support . . .
Application Program Interfaces (APIs) . . .
Transport Protocol . . . . . . . . . . .
Transmission Control Protocol (TCP) . . . .
User Datagram Protocol (UDP) . . . . . .
TCP and UDP Ports . . . . . . . . .
Point-to-Point TCP/IP . . . . . . . . .
Internetwork Protocol . . . . . . . . . .
Internet Protocol . . . . . . . . . . .
Internet Control Message Protocol . . . .
Internet Group Management Protocol . . .
Address Resolution Protocol . . . . . .
AnyNet/400 . . . . . . . . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
Host
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xv
xv
xv
xvi
xvi
xvii
xvii
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Names
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
3
4
4
5
6
8
9
9
10
12
12
13
13
15
15
16
16
17
17
17
18
18
19
19
19
19
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
(X.25)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
22
22
23
24
26
27
29
30
30
32
36
36
Chapter 2. Configuring TCP/IP . . . . . . . . . .
What you need to know before you can configure TCP/IP .
Planning for TCP/IP Installation and Configuration . . .
Gathering Information About your Network . . . . .
Installing the TCP/IP Application Programs . . . . . .
TCP/IP Addressing . . . . . . . . . . . . . . .
Using the TCP/IP Administration Menu . . . . . . . .
Using the Configure TCP/IP Menu . . . . . . . . .
Configuring TCP/IP using the Command Line Interface . .
Step 1—Configuring a Line Description . . . . . .
Step 2—Configuring a TCP/IP Interface . . . . . .
Step 3—Configuring TCP/IP Routes . . . . . . . .
Step 4—Configuring TCP/IP attributes . . . . . . .
Step 5—Configuring TCP/IP Remote System Information
© Copyright IBM Corp. 1997, 1999
iii
Step 6—Configuring TCP/IP Host Table Entries
Step 7—Configuring the Local Domain and Host
Step 8—Starting TCP/IP and TCP/IP Servers .
Step 9—Verifying the TCP/IP Connection . . .
Verifying Additional TCP/IP Connections . . .
Step 10—Saving Your TCP/IP Configuration . .
TCP/IP Planning Checklists . . . . . . . .
Sample Network Drawing. . . . . . . . .
iv
. . .
Name
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
42
43
46
47
50
51
52
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
56
59
60
63
64
72
73
73
74
75
75
76
76
78
78
78
79
79
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
Network Status . . . . . . . . . . . . . . . . . . . .
Work with TCP/IP Network Status Menu . . . . . . . . . .
Work with TCP/IP Interface Status . . . . . . . . . . . .
Display TCP/IP Route Information . . . . . . . . . . . .
Work with TCP/IP Connection Status . . . . . . . . . . .
Working with Configuration Status . . . . . . . . . . . .
Displaying TCP/IP Network Status Information . . . . . . . .
TCP/IP Host Tables . . . . . . . . . . . . . . . . . . .
Managing TCP/IP Host Tables . . . . . . . . . . . . . . .
Host File Formats . . . . . . . . . . . . . . . . . .
Tips for Merging Host Tables . . . . . . . . . . . . . .
Merging TCP/IP Host Tables . . . . . . . . . . . . . .
Managing the Host Table from a Central Site . . . . . . . .
Domain Name System (DNS) Server . . . . . . . . . . . .
IP Routing and Internet Control Message Protocol (ICMP) Redirecting
Dead Gateway Processing . . . . . . . . . . . . . . . .
Negative Advice from TCP or the Data Link Layer . . . . . .
How IP Responds to Negative Advice . . . . . . . . . . .
Multihoming Function . . . . . . . . . . . . . . . . . .
Example: A Single Host on a Network over a Communications Line
Example: Multiple Hosts on the Same Network over the Same
Communications Line . . . . . . . . . . . . . . . .
Example: Multiple Hosts on the Same Network over Multiple
Communications Lines . . . . . . . . . . . . . . . .
Example: Multiple Hosts on Different Networks over the Same
Communications Line . . . . . . . . . . . . . . . .
Example: Multiple Hosts on Different Networks over Multiple
Communications Lines . . . . . . . . . . . . . . . .
Example: The Multihoming function . . . . . . . . . . . . .
Type of Service (TOS) . . . . . . . . . . . . . . . . .
Multiple Routes . . . . . . . . . . . . . . . . . . .
TCP/IP Port Restriction . . . . . . . . . . . . . . . . .
Configuring TCP/IP Port Restrictions . . . . . . . . . . .
Related Tables and the Host Table . . . . . . . . . . . . .
Using X.25 PVC instead of SVC . . . . . . . . . . . . . .
IP Multicasting. . . . . . . . . . . . . . . . . . . . .
Multicast Application Programming Information . . . . . . . .
Multicast Restrictions . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
82
83
84
85
86
88
91
91
91
92
Chapter 4. Configuring Point-to-Point TCP/IP
Networks and Point-to-Point Connections . . .
PPP versus SLIP. . . . . . . . . . . .
Requirements for AS/400 SLIP. . . . . . .
Point-to-Point Request for Comments (RFC) .
Line Pools . . . . . . . . . . . . . .
Configuring Point-to-Point Network Connections
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
94
95
95
95
96
OS/400 TCP/IP Configuration and Reference V4R4
(PPP
. .
. .
. .
. .
. .
. .
and
. .
. .
. .
. .
. .
. .
SLIP)
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . 80
. . . . 80
. . . . 81
Configuring PPP Connection Profiles . . . . . . . . . . .
Accessing Point-to-Point functions through Operations Navigator .
Checking for existing PPP Connection Profiles . . . . . . . .
PPP Configuration Scenarios . . . . . . . . . . . . . .
Example: Configuring Windows 95/98 to an AS/400 using a PPP
Example: Connecting to the Internet using an ISP . . . . .
Example: Connecting two AS/400s using dial-on-demand . . .
Example: AS/400 Office-to-Office Scenarios . . . . . . . .
Example: Remote LAN Access with Transparent Subnetting . .
Example: Remote LAN Access with Dynamic Routing (RIP) . .
Monitoring Activity . . . . . . . . . . . . . . . . . .
Point-to-Point Jobs . . . . . . . . . . . . . . . . .
Connection Alternatives . . . . . . . . . . . . . . . .
Analog Phone Lines . . . . . . . . . . . . . . . .
Digital Data Service . . . . . . . . . . . . . . . . .
DDS . . . . . . . . . . . . . . . . . . . . . .
Switched-56 . . . . . . . . . . . . . . . . . . .
ISDN . . . . . . . . . . . . . . . . . . . . . .
T1/E1 . . . . . . . . . . . . . . . . . . . . . .
Fractional T1 . . . . . . . . . . . . . . . . . . .
Using an Asynchronous Modem or ISDN Terminal Adapter . . .
PPP ISDN Support . . . . . . . . . . . . . . . . .
Configuring SLIP Connection Profiles . . . . . . . . . . .
Writing Connection Dialog Scripts . . . . . . . . . . . .
Connection Script Considerations for SLIP . . . . . . . .
Connection Script Considerations for PPP . . . . . . . .
NLS Considerations. . . . . . . . . . . . . . . . .
Using SLIP with an Asynchronous Line Description . . . . . .
Connection Dialog Scripts . . . . . . . . . . . . . .
Configuring AS/400 Point-to-Point for SLIP . . . . . . . .
Monitoring Point-to-Point Activity . . . . . . . . . . . .
PPP/SLIP over *PPP . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Connection
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
96
96
96
97
97
97
98
100
104
107
109
110
111
112
112
112
113
113
114
115
115
115
115
118
118
124
125
126
127
127
134
156
Chapter 5. Telnet Client . . . . . . . . . . . . . . .
5250 Full-Screen Mode Considerations . . . . . . . . .
TN5250—Start TCP/IP Telnet Command . . . . . . . .
TN5250—Screen Size . . . . . . . . . . . . . . .
3270 Full-Screen Mode Considerations . . . . . . . . .
TN3270—Start TCP/IP Telnet Command . . . . . . . .
Using a Display Station during Telnet 3270 Full-Screen Mode
TN3270—Screen Size . . . . . . . . . . . . . . .
TN3270—Cursor Select Key . . . . . . . . . . . .
TN3270—Messages . . . . . . . . . . . . . . .
TN3270—Handling Null Characters . . . . . . . . . .
VTxxx Full-Screen Mode Considerations . . . . . . . . .
Operational Differences . . . . . . . . . . . . . .
Keyboard Issues . . . . . . . . . . . . . . . . .
Screen Issues . . . . . . . . . . . . . . . . . .
VTxxx—Screen Size . . . . . . . . . . . . . . .
VTxxx—Character Attributes . . . . . . . . . . . .
VTxxx—Start TCP/IP Telnet Command. . . . . . . . .
Changing the VTxxx Keyboard Map . . . . . . . . . .
VTxxx—National Language Support . . . . . . . . . .
VTxxx—Multinational Mode . . . . . . . . . . . . .
VTxxx—National Mode . . . . . . . . . . . . . .
System Functions Available during a Telnet Client Session . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
159
159
159
159
159
160
160
161
162
162
162
163
163
164
165
166
166
166
167
179
180
180
182
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
v
Print . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
vi
Chapter 6. Telnet Server . . . . . . . . . . . . . . . . . .
Setting Up the Telnet Server . . . . . . . . . . . . . . . . .
Determining Which Emulation Is Negotiated . . . . . . . . . . .
5250 Full-Screen Mode . . . . . . . . . . . . . . . . . . .
Examples of 5250 Server to 5250 Full-Screen Telnet Client . . . . .
3270 Full-Screen Mode . . . . . . . . . . . . . . . . . . .
Setting up for 3270 Full-Screen Mode . . . . . . . . . . . . .
Break Messages in 3270 Full-Screen Mode . . . . . . . . . . .
Input-Inhibited Light . . . . . . . . . . . . . . . . . . . .
Defining Capabilities for 3270 Devices . . . . . . . . . . . . .
VTxxx Full-Screen Mode . . . . . . . . . . . . . . . . . . .
Setting up for VTxxx Full-Screen Mode . . . . . . . . . . . .
VTxxx Automatic Wrap. . . . . . . . . . . . . . . . . . .
System Request Processing for VTxxx Sessions . . . . . . . . .
Error Conditions on 5250 Keyboard . . . . . . . . . . . . . .
Display Screens and VTxxx Support. . . . . . . . . . . . . .
VT220 Control Characters . . . . . . . . . . . . . . . . .
Some Practical Examples . . . . . . . . . . . . . . . . .
ASCII Line Mode . . . . . . . . . . . . . . . . . . . . . .
Setting up for ASCII Line Mode . . . . . . . . . . . . . . .
Telnet Printer Pass-Through Mode . . . . . . . . . . . . . . .
Setting Up for Telnet Printer Pass-Through Mode . . . . . . . . .
Telnet Printer Pass-Through Mode Server to Client Access Win95 Telnet
Client . . . . . . . . . . . . . . . . . . . . . . . .
Ending a Telnet Server Session . . . . . . . . . . . . . . . .
Starting Cascaded Telnet or DSPT Sessions . . . . . . . . . . .
Using System Request Options . . . . . . . . . . . . . . .
Telnet Scenarios for Establishing Cascaded Sessions . . . . . . .
System Request Processing—Scenarios . . . . . . . . . . . .
Using a Group Job—Scenario . . . . . . . . . . . . . . . .
Workstation Type Negotiations and Mappings . . . . . . . . . .
System API Enhancement . . . . . . . . . . . . . . . . . .
Dynamic Application Printing with TCP/IP . . . . . . . . . . . .
Exit Point Performance . . . . . . . . . . . . . . . . . . .
Work Management . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
183
183
183
183
183
186
187
195
195
195
196
196
207
207
207
208
208
209
210
211
216
217
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
220
220
220
220
225
227
229
231
231
233
233
Chapter 7. File Transfer Protocol (FTP) Client . . . . . . . . . .
Functions Supported by FTP Client . . . . . . . . . . . . . . .
Functions Not Supported by FTP Client . . . . . . . . . . . . .
FTP Client and Server-Overview . . . . . . . . . . . . . . . .
Starting the FTP Client Session . . . . . . . . . . . . . . . .
Alternative Start Commands. . . . . . . . . . . . . . . . .
Connecting to Another Server without Ending the FTP Session . . . . .
Ending the FTP Client Session. . . . . . . . . . . . . . . . .
Transferring Files with File Transfer Protocol (FTP) . . . . . . . . .
Naming Format Indicator for AS/400 Names . . . . . . . . . . . .
File Naming for the Library File System (QSYS.LIB) . . . . . . . .
Names for Document Library Services (QDLS) Folders and Documents
Names for “root,” QOpenSys, QLANSrv and QFileSvr.400 File Systems
Localfile and Remotefile Parameters for FTP Client Subcommands . . .
Default File Names for Client Transfer Subcommands . . . . . . . .
FTP Client Subcommands . . . . . . . . . . . . . . . . . .
FTP Examples. . . . . . . . . . . . . . . . . . . . . .
FTP Considerations (for Both Client and Server) . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
235
235
235
235
237
237
240
240
241
241
242
242
242
242
242
244
244
258
OS/400 TCP/IP Configuration and Reference V4R4
FTP Client Considerations . . . . . . . . . . . . . . . . . . . 266
FTP as Batch Job . . . . . . . . . . . . . . . . . . . . . . 269
Exit Points for FTP . . . . . . . . . . . . . . . . . . . . . . 277
Chapter 8. File Transfer Protocol (FTP) Server . . .
FTP Server-What It Does and Does Not Support . . .
Functions Supported by AS/400 FTP Server . . . .
Functions Not Supported by FTP Server . . . . .
Configuring FTP Servers . . . . . . . . . . . .
Starting FTP Servers . . . . . . . . . . . . .
Available FTP Servers . . . . . . . . . . . .
Ending FTP Servers . . . . . . . . . . . . .
Ending and Restarting FTP Server Jobs . . . . .
FTP Server Subcommands . . . . . . . . . . .
FTP Server Considerations . . . . . . . . . . .
FTP Server Considerations for Non-AS/400 Clients .
FTP Server NAMEFMT . . . . . . . . . . .
Exit Points for FTP Server Security and Anonymous FTP
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
279
279
279
280
280
280
281
281
282
282
282
282
283
284
Chapter 9. Post Office Protocol (POP) Mail Server . . . . . .
How the POP Server Works. . . . . . . . . . . . . . . .
The POP Server and Client Access-based Mail . . . . . . . .
How to Get the POP Server Up and Running . . . . . . . . .
Setting Up Your System and Users . . . . . . . . . . . . .
Adding POP Mail Users to the System Distribution Directory . . .
POP Mailboxes . . . . . . . . . . . . . . . . . . .
Setting Up Standard POP Mail Clients . . . . . . . . . . .
Setting Up Client Access-Based Mail Clients . . . . . . . .
Configuring the POP Server. . . . . . . . . . . . . . . .
Configuring POP for Client Access-Based Mail Users . . . . . .
Removing POP Mail Users from the System. . . . . . . . .
Setting the Number of SNA Servers . . . . . . . . . . . .
Starting the POP Server . . . . . . . . . . . . . . . . .
Ending the POP Server . . . . . . . . . . . . . . . . .
Supported POP Verbs . . . . . . . . . . . . . . . . . .
How the POP Server Uses the Mail Server Framework. . . . . .
Exchanging Mail with OfficeVision . . . . . . . . . . . . .
Configuring Both POP and SMTP . . . . . . . . . . . .
Using *ANY Support with the POP Server . . . . . . . . .
MIME Mail Sent To OfficeVision . . . . . . . . . . . . .
Long Line Conversion . . . . . . . . . . . . . . . . .
Data Area Values. . . . . . . . . . . . . . . . . . .
MIME Content Types . . . . . . . . . . . . . . . . .
Supported Content Types of the POP Server . . . . . . . .
How the File Name is Derived . . . . . . . . . . . . . .
MIME Content Types . . . . . . . . . . . . . . . . .
What Happens When You Send OfficeVision Mail to POP Clients . .
Setting Up MIME Headers to Differentiate between Recipients . .
Sending MIME (POP Server) Mail across a SNADS Network . . .
How SNADS Tunneling Works . . . . . . . . . . . . . .
How to Configure System Distribution Directory Entries for SNADS
Tunneling. . . . . . . . . . . . . . . . . . . . .
Address Types . . . . . . . . . . . . . . . . . . . .
AS/400 Address Book . . . . . . . . . . . . . . . . . .
The Address Book Cache . . . . . . . . . . . . . . .
ASCII-EBCDIC Conversion and National Language Support . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
285
285
287
288
289
289
292
292
293
293
294
295
295
296
296
296
297
297
297
297
298
299
299
302
303
305
305
305
307
308
308
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
308
310
311
312
313
Contents
vii
EBCDIC-to-ASCII Conversion . . . . . . . . . . . . . . . . . . 314
ASCII-to-EBCDIC Conversion . . . . . . . . . . . . . . . . . . 315
Chapter 10. Workstation Gateway Server . . . . . . . . . . .
Accessing Workstation Gateway Functions through Operations Navigator
Starting the Workstation Gateway Server . . . . . . . . . . . .
Automatically Starting the Workstation Gateway Server. . . . . . .
Ending the Workstation Gateway Server . . . . . . . . . . . .
Configuring the Workstation Gateway Server . . . . . . . . . .
Managing Virtual Devices for the Client . . . . . . . . . . . .
Changing the Workstation Gateway Configuration. . . . . . . . .
Number of Clients per Server (NBRCLT) . . . . . . . . . . .
Inactivity Timeout (INACTTIMO) . . . . . . . . . . . . . .
Data Request Timeout (DTARQSTIMO) . . . . . . . . . . .
Display Sign-on Panel (DSPSGN) . . . . . . . . . . . . .
Access Logging (ACCLOG) . . . . . . . . . . . . . . . .
Top Banner URL (TOPBNRURL) . . . . . . . . . . . . . .
Bottom Banner URL (BOTBNRURL). . . . . . . . . . . . .
Help Panel URL (HLPPNLURL) . . . . . . . . . . . . . .
Coded Character Set Identifier (CCSID) . . . . . . . . . . .
Server Mapping Tables (TBLWSGOUT) and (TBLWSGIN) . . . . .
Workstation Gateway Exit Point for Accessing a User Profile Directly .
Granting Access to the Web Browser Online Help Information . . . .
Customizing Web Browser Online Help Information . . . . . . .
Managing the Access Log . . . . . . . . . . . . . . . . .
The QATMTLOG File . . . . . . . . . . . . . . . . . .
Accessing the Workstation Gateway from a Web Browser. . . . .
Security . . . . . . . . . . . . . . . . . . . . . . .
Workstation Gateway — Requirements . . . . . . . . . . .
How the 5250 Display is Formatted for the Workstation Gateway . .
Configuration Examples . . . . . . . . . . . . . . . . .
Online Help Information . . . . . . . . . . . . . . . . .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
319
319
320
320
320
321
322
323
324
325
325
325
327
327
327
327
328
328
329
329
330
330
330
332
334
335
335
337
338
Chapter 11. Line Printer Requester (LPR) . . . . . . . . . . . . .
LPR Command . . . . . . . . . . . . . . . . . . . . . . .
Client (LPR) and Server (LPD) Relationship . . . . . . . . . . . . .
Configuration Requirements for LPR . . . . . . . . . . . . . . .
Sending a Spooled File (LPR) . . . . . . . . . . . . . . . . . .
Step 1 — Locate the Spooled File that you Want to Send . . . . . . .
Step 2 — Start the Spooled File Transfer . . . . . . . . . . . . .
Sending Spooled Files to an AS/400 at V2R3 or V3R0M5. . . . . . .
How the System Sends a Spooled File from an AS/400 System to Another
AS/400 System . . . . . . . . . . . . . . . . . . . . .
How the System Sends a Spooled File from an AS/400 System to a
Non-AS/400 System . . . . . . . . . . . . . . . . . . . .
Transformation of Spooled Files . . . . . . . . . . . . . . . .
Sending Spooled File — Tips . . . . . . . . . . . . . . . . .
Sending Large Spooled Files . . . . . . . . . . . . . . . . .
Printer Pass-Through . . . . . . . . . . . . . . . . . . . . .
Setup . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting Printer Pass-Through . . . . . . . . . . . . . . . . .
Configuring for a RISC System/6000 System — Scenario . . . . . . . .
Setting Up for LPD on the RISC System/6000 System — Scenario . . .
Configuring Device and Virtual Printer for AIX Printing . . . . . . . .
Verifying LPD Started on the RISC System/6000 System . . . . . . .
Verifying Your Configuration on the RISC System/6000 System. . . . .
.
.
.
.
.
.
.
.
345
345
345
346
346
346
347
348
OS/400 TCP/IP Configuration and Reference V4R4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 348
.
.
.
.
.
.
.
.
.
.
.
.
349
350
353
353
353
354
355
356
356
356
358
359
Print Services Facility/6000 Function . . . . . . . . . . . . . . . . 360
Configuring PSF/6000 Function . . . . . . . . . . . . . . . . . 360
Verifying Your Configuration of PSF/6000 . . . . . . . . . . . . . . 361
Chapter 12. Line Printer Daemon (LPD) . . . . . . . . . . . .
Configuring for Line Printer Daemon (LPD) . . . . . . . . . . . .
How the Destination System Receives a Spooled File . . . . . . . .
How an AS/400 System Receives a Spooled File from Another AS/400
System . . . . . . . . . . . . . . . . . . . . . . .
How an AS/400 System Receives a Spooled File from a Non-AS/400
System . . . . . . . . . . . . . . . . . . . . . . .
How Spooled Files are Named on the Destination AS/400 . . . . .
Starting an LPD Server Job . . . . . . . . . . . . . . . . .
Ending an LPD Server Job . . . . . . . . . . . . . . . . .
Attributes of the Received Spooled File . . . . . . . . . . . .
User Profile Library Lists . . . . . . . . . . . . . . . . . .
How the Ownership of Spooled Files Is Determined . . . . . . . .
How an LPD Server Selects an Output Queue for a File . . . . . .
How Authority for Putting Spooled Files on Output Queue is Determined
Using LPD to Print ASCII Files . . . . . . . . . . . . . . . .
Using LPD to Print ASCII Files Converted to EBCDIC . . . . . . .
Authority Required to Receive Spooled Files . . . . . . . . . .
. . 363
. . 363
. . 363
. . 364
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
365
366
366
367
367
367
370
370
372
373
373
375
Chapter 13. BOOTP Server . . . . . . . . . . . . . .
Accessing BOOTP Functions through Operations Navigator . . .
Starting the BOOTP Server . . . . . . . . . . . . . . .
Automatically Starting the BOOTP Server. . . . . . . . . .
Ending the BOOTP Server . . . . . . . . . . . . . . .
Configuring the BOOTP Server . . . . . . . . . . . . .
Changing BOOTP Attributes. . . . . . . . . . . . . . .
Working with the BOOTP Table . . . . . . . . . . . . .
Adding IBM Network Stations to an Existing BOOTP Environment.
Adding Network Stations with the Command Line Interface . .
Adding Network Stations with Operations Navigator . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
377
377
378
378
378
378
379
379
379
380
380
Chapter 14. TFTP Server . . . . . . . . . . . . . .
Accessing TFTP Functions through Operations Navigator . . .
Starting the TFTP Server . . . . . . . . . . . . . . .
Automatically Starting the TFTP Server . . . . . . . . .
Ending the TFTP Server . . . . . . . . . . . . . . .
Changing TFTP Attributes . . . . . . . . . . . . . .
Server and Client Ports . . . . . . . . . . . . . . .
TFTP Extensions . . . . . . . . . . . . . . . . . .
TFTP Transfer Size Option . . . . . . . . . . . . .
TFTP Subnet Broadcast Option . . . . . . . . . . .
Configuring TFTP for Clients other than IBM Network Station
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
383
383
383
383
384
384
385
385
385
385
389
Chapter 15. RouteD Server . . . . . . .
Accessing RouteD Functions through Operations
Starting the RouteD Server . . . . . . . .
Automatically Starting the RouteD Server . . .
Ending the RouteD Server . . . . . . . .
Configuring the RouteD Server . . . . . .
Working with RouteD Configuration . . . . .
RouteD Configuration Scenario . . . . . .
RIP_INTERFACE Statement . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
391
391
391
392
392
392
393
393
394
Contents
ix
. . . .
Navigator
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Supply Values . . . . .
DIST_ROUTES_IN . . .
Metric . . . . . . . .
Community . . . . . .
Additional Parameters . .
Changing RouteD Attributes .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chapter 16. REXEC Server . . . . . . . . . . . .
Accessing REXEC Functions through Operations Navigator .
Starting the REXEC Server from the Command Line Interface
Automatically Starting the REXEC Server . . . . . . . .
Ending the REXEC Server . . . . . . . . . . . . .
Changing Attributes . . . . . . . . . . . . . . . .
REXEC Command Considerations . . . . . . . . . .
Selecting a Command Processor . . . . . . . . . . .
REXEC Connection Usage . . . . . . . . . . . . .
For AS/400 CL command processing . . . . . . . .
For Qshell and spawned path command processing . . .
Spooled Output Considerations . . . . . . . . . . .
Client Considerations . . . . . . . . . . . . . . .
REXEC Server Jobs and Job Names . . . . . . . . .
Creating REXEC Server Spooled Job Logs . . . . . . .
Exit Points for Controlling REXEC Server . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
395
395
395
396
396
397
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
399
399
399
400
400
400
400
401
401
401
401
402
402
402
403
403
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
405
405
405
406
408
412
413
414
415
415
415
416
416
417
417
417
417
.
.
.
.
.
.
.
.
.
.
.
.
418
419
420
420
Chapter 17. DHCP Server . . . . . . . . . . . . . . . . .
DHCP Overview . . . . . . . . . . . . . . . . . . . . .
What is DHCP? . . . . . . . . . . . . . . . . . . . .
Planning for DHCP . . . . . . . . . . . . . . . . . . .
Setting Up a DHCP Network . . . . . . . . . . . . . . .
Specifying DHCP Options . . . . . . . . . . . . . . . .
Request for Comment and Internet Draft Documents . . . . . .
Accessing DHCP Functions through Operations Navigator . . . . .
Starting and Ending the DHCP Server from the Command Line Interface
Starting the DHCP Server . . . . . . . . . . . . . . . .
Automatically Starting the DHCP Server . . . . . . . . . . .
Ending the DHCP Server . . . . . . . . . . . . . . . . .
Changing DHCP Attributes . . . . . . . . . . . . . . . . .
Exit Points for a DHCP Server . . . . . . . . . . . . . . . .
Examples of DHCP Configurations . . . . . . . . . . . . . .
Configuring DHCP for a Local Area Network. . . . . . . . . .
Configuring DHCP for a Local Area Network with a Router . . . .
Using DHCP to Configure Clients Attached to a Twinax Workstation
Controller. . . . . . . . . . . . . . . . . . . . . .
Migrating an Existing BOOTP Configuration . . . . . . . . . . .
DHCP Relay Agent . . . . . . . . . . . . . . . . . . . .
Adding Network Stations . . . . . . . . . . . . . . . . . .
Chapter 18. AS/400 Domain Name System (DNS) . . . . . . . . . . . 421
How DNS works . . . . . . . . . . . . . . . . . . . . . . . . 421
Additional DNS documentation. . . . . . . . . . . . . . . . . . . 422
Chapter 19. Client SOCKS Support . . . . . . . . . . . . . . . . 423
Accessing SOCKS Functions through Operations Navigator . . . . . . . . 423
Chapter 20. TCP/IP Performance . . . . . . . . . . . . . . . . . 425
*BASE Pool Size . . . . . . . . . . . . . . . . . . . . . . . . 425
x
OS/400 TCP/IP Configuration and Reference V4R4
TCP/IP Jobs . . . . . . . . . . . . . .
TCP/IP Protocol Support Provided by IOP . . .
Merge Host Table Performance . . . . . . .
Running TCP/IP Only: Performance Considerations
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
425
425
427
427
Chapter 21. TCP/IP Problem Analysis . . . . . . . . .
General TCP/IP Problems . . . . . . . . . . . . . .
PING Command Considerations . . . . . . . . . . .
Working with the Job Log and Message Queues . . . . .
Determining Problems for SNMP . . . . . . . . . . . .
Determining Problems for Serial Line Internet Protocol (SLIP) .
Problem: SLIP Connection Is Failing . . . . . . . . .
Problem: SLIP Job ’Hung’ with STRSSN Status . . . . .
Problem: SLIP Connection Complete but Unable to PING . .
Materials Required for Reporting SLIP Problems . . . . .
Determining Problems with TELNET. . . . . . . . . . .
Materials Needed when Reporting TELNET Problems . . .
Determining Problems with FTP . . . . . . . . . . . .
Materials Required for Reporting FTP Problems . . . . .
Tracing FTP Server . . . . . . . . . . . . . . . .
Tracing FTP Client . . . . . . . . . . . . . . . .
Getting a Copy of an FTP Server Job Log . . . . . . .
Determining Problems for SMTP . . . . . . . . . . . .
Determining Problems for SMTP When Using OfficeVision .
Determining Problems for SMTP Without Using OfficeVision .
Tracing SMTP Distributions . . . . . . . . . . . . .
Materials Required for Reporting SMTP Problems . . . .
Cleaning Up Unprocessed SMTP Distributions . . . . . .
Determining Problems with the POP Server . . . . . . . .
Problems with Mail Delivery . . . . . . . . . . . . .
Problem Determination Flows . . . . . . . . . . . .
Determining Problems with the Workstation Gateway Server. .
First Failure Data Capture (FFDC) . . . . . . . . . .
Determining Problems for DNS Server . . . . . . . . . .
Problem Determination Tools . . . . . . . . . . . .
Problem Determination Flows . . . . . . . . . . . .
Determining Problems for LPR . . . . . . . . . . . . .
LPR Command Considerations . . . . . . . . . . .
Common Error Messages . . . . . . . . . . . . .
Determining Problems for LPD . . . . . . . . . . . . .
Materials Required for Reporting LPD Problems . . . . .
Determining Problems with REXEC . . . . . . . . . . .
Materials Required for Reporting REXEC Problems . . . . .
Getting a Copy of an REXEC Server Job Log . . . . . . .
Tracing the REXEC Server . . . . . . . . . . . . . .
Tracing TCP/IP Protocol Layer Problems . . . . . . . . .
APPC Over TCP/IP Debugging Capabilities . . . . . . . .
Tracing APPC over TCP/IP Problems . . . . . . . . .
Collecting a Communications Trace . . . . . . . . . . .
Planning to Set up a Trace . . . . . . . . . . . . .
Starting a Communications Trace. . . . . . . . . . .
Stopping a Communications Trace . . . . . . . . . .
Formatting and Saving the Communications Trace . . . .
Verifying the Contents of the Communications Trace. . . .
Using the Product Activity Log for TCP/IP Problem Analysis . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
429
430
437
438
439
439
439
442
442
442
443
445
450
452
453
456
456
457
462
464
469
475
475
476
476
477
480
480
482
482
483
486
486
486
487
489
489
491
491
491
492
492
493
493
493
495
498
499
501
503
Contents
xi
Appendix A. Configuring a Physical Line for TCP/IP Communication
Configuration Steps . . . . . . . . . . . . . . . . . . . .
Creating the Line Description . . . . . . . . . . . . . . .
Setting the Maximum Transmission Unit . . . . . . . . . . .
Determining the Maximum Size of Datagrams . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
505
506
506
507
507
Appendix B. TCP/IP Security . . . . . .
TCP/IP Command Security . . . . . . .
Object Security for Network Configuration.
IBM-Written Programs Security . . . .
Customer-Written Programs Security . .
User-Supplied Mapping Tables . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
509
509
513
513
514
514
Appendix C. Mapping Tables Associated with TCP/IP Function
National Language Support Mapping . . . . . . . . . . .
Summary of Mapping Tables . . . . . . . . . . . . . .
Creating ASCII and EBCDIC Mapping Tables . . . . . . . .
Creating a Source Member for Incoming Data . . . . . . .
Creating a Source Member for Outgoing Data . . . . . . .
Creating a Mapping Table . . . . . . . . . . . . . .
Specifying User-Defined ASCII and EBCDIC Mapping Tables .
Creating 3270 Mapping Tables . . . . . . . . . . . . . .
Creating a Source Member for Incoming Data . . . . . . .
Creating a Source Member for Outgoing Data . . . . . . .
Creating a Mapping Table . . . . . . . . . . . . . .
Using Mapping Tables for 3270 Full-Screen Mode . . . . .
Reading a Mapping Table . . . . . . . . . . . . . . .
Changing a Mapping Table . . . . . . . . . . . . . . .
Sample Mappings . . . . . . . . . . . . . . . . . .
EBCDIC and ASCII Character Sets . . . . . . . . . . . .
USA Standard 7-Bit ASCII Character Set . . . . . . . . .
EBCDIC-to-ASCII Mapping Table . . . . . . . . . . . .
ASCII-to-EBCDIC Mapping Table . . . . . . . . . . . .
ASCII Line Drawing Character Set . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
517
517
518
518
519
519
520
520
521
521
522
522
523
523
523
523
524
526
527
529
530
Appendix D. TELNET 3270 Keyboard Mappings . . . . . . . . . . . 531
AS/400 CL Programs for the CHGKBDMAP Command . . . . . . . . . . 531
Appendix E. TCP/IP Application Exit Points and Programs . . . .
TCP/IP Exit Points and Exit Programs . . . . . . . . . . . . .
OS/400 Registration Facility . . . . . . . . . . . . . . . . .
TCP/IP Application Exit Points . . . . . . . . . . . . . . . .
Creating Exit Programs . . . . . . . . . . . . . . . . . .
Adding Your Exit Program to the Registration Facility . . . . . .
Removing Exit Programs . . . . . . . . . . . . . . . . .
TELNET Exit Points. . . . . . . . . . . . . . . . . . . .
Telnet Device Initialization Exit Program . . . . . . . . . . .
TELNET Device Termination Exit Program . . . . . . . . . . .
Required Parameter Group . . . . . . . . . . . . . . . .
Exit Point Interfaces for TCP/IP Application Exit Points . . . . . . .
TCP/IP Application Request Validation Exit Point Interface . . . .
TCP/IP Application Server Logon Exit Point Interface . . . . . .
Remote Execution Server Command Processing Selection Exit Point
File Transfer Protocol (FTP) Exit Points . . . . . . . . . . . .
Considerations and Recommendations for FTP Exit Programs . . .
FTP Exit Program—Scenario . . . . . . . . . . . . . . .
xii
OS/400 TCP/IP Configuration and Reference V4R4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
535
535
535
536
537
537
540
541
541
546
547
547
547
551
551
553
554
554
Sample FTP Server Logon Exit Program (C Language) . . . . .
Anonymous FTP . . . . . . . . . . . . . . . . . . . . .
Sample Scenario for Anonymous FTP . . . . . . . . . . . .
Workstation Gateway Server (WSG) Exit Point . . . . . . . . . .
Workstation Gateway Server Sign-on Exit Point Interface (QAPP0100)
Required Parameters . . . . . . . . . . . . . . . . .
Descriptions of Required Parameters for the WSG Exit Point Interface
(QAPP0100) . . . . . . . . . . . . . . . . . . . .
Using a WSG exit progam to bypass the AS/400 Sign-on Display . .
Sample WSG Server Logon Exit Program . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
555
568
569
569
. . . 569
. . . 570
. . . 571
. . . 572
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Programming Interface Information . . . . . . . . . . . . . . . . . 596
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Bibliography . . . . . . . . .
Client Access Books . . . . . .
Communications Manuals . . . .
Integrated Netfinity Server Manuals .
Internet Connection Server Manuals.
Programming Manuals . . . . . .
Security . . . . . . . . . . .
System Manuals . . . . . . . .
Systems Network Architecture (SNA)
Request For Comments (RFC). . .
Other Information . . . . . . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Display
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Stations
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
599
599
599
600
600
600
601
601
601
602
602
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Readers’ Comments — We’d Like to Hear from You. . . . . . . . . . 635
Contents
xiii
xiv
OS/400 TCP/IP Configuration and Reference V4R4
About TCP/IP Configuration and Reference (SC41-5420)
|
|
|
|
This book contains information about configuring and using Transmission Control
Protocol/Internet Protocol (TCP/IP) and writing programs to the TCP/IP application
interface. Some topics have moved to the Information Center. See “TCP/IP Topics
in the Information Center”.
TCP/IP Packaging:
|
|
|
When you purchase OS/400, the ordering system automatically places an order for
the TCP/IP Utilities Licensed Program (LP). The TCP/IP Utilities LP is shipped with
OS/400 at no additional charge. However, you must install the TCP/IP Utilities LP
separately by using normal installation support.
TCP/IP Topics in the Information Center
|
|
|
|
|
These related topics are described in the AS/400e Information Center instead of in
this book:
Under the TCP/IP heading:
v Getting started with TCP/IP
v Connecting two systems with Point-to-Point Protocol (PPP)
|
|
|
v Logging on to a remote computer (Telnet)
v Managing host names with Domain Name System (DNS)
v Sending and receiving e-mail
v Transferring files with File Transfer Protocol (FTP)
Under the Internet and Secure Networks heading:
v Client SOCKets
v IP packet security
|
|
|
|
|
v Virtual Private Network (VPN)
|
|
|
|
|
You can access the Information Center from the AS/400e Information Center
CD-ROM (English version: SK3T-2027) or from one of these Web sites:
|
|
To find out more about the Information Center, see “Prerequisite and related
information” on page xvii.
http://www.as400.ibm.com/infocenter
http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm
Who should read this book
This book is intended for the following audience:
v Users who configure TCP/IP and its associated applications
v Users who use TCP/IP functions or commands
v Programmers who write to the sockets applications programming interface, or
API. For details on the AS/400 sockets API see System API Reference,
SC41-5801-03. For additional information about sockets, including sample
programs, see the Sockets Programming, SC41-5422-03 book. For information
© Copyright IBM Corp. 1997, 1999
xv
about firewall concepts and an IBM firewall product for the AS/400 system, see
the Getting Started with IBM Firewall for AS/400, SC41-5424-02 book or go to
http://www.as400.ibm.com/firewall.
You need to be familiar with, or have previous experience in, the following areas:
v TCP/IP. If this is your first experience with TCP/IP, consider reading some of the
material listed in the Bibliography.
v AS/400 menus and commands.
v Operations Navigator. Some of the applications require the use of this function.
v Writing applications on the AS/400 system. If you plan to write programs to the
TCP/IP application program interface, you must know how to write applications
on the AS/400 system.
AS/400 Operations Navigator
AS/400 Operations Navigator is a powerful graphical interface for Windows clients.
With AS/400 Operations Navigator, you can manage and administer your AS/400
systems from your Windows desktop.
You can use Operations Navigator to manage communications, printing, database,
security, and other system operations. Operations Navigator includes Management
Central for managing multiple AS/400 systems centrally.
Figure 1 shows an example of the Operations Navigator display:
Figure 1. AS/400 Operations Navigator Display
This new interface has been designed to make you more productive and is the only
user interface to new, advanced features of OS/400. Therefore, IBM recommends
that you use AS/400 Operations Navigator, which has online help to guide you.
While this interface is being developed, you may still need to use a traditional
emulator such as PC5250 to do some of your tasks.
Installing Operations Navigator
To use AS/400 Operations Navigator, you must have Client Access installed on your
Windows PC. For help in connecting your Windows PC to your AS/400 system,
consult Client Access Express for Windows - Setup, SC41-5507-00.
xvi
OS/400 TCP/IP Configuration and Reference V4R4
AS/400 Operations Navigator is a separately installable component of Client Access
that contains many subcomponents. If you are installing for the first time and you
use the Typical installation option, the following options are installed by default:
v Operations Navigator base support
v Basic operations (messages, printer output, and printers)
To select the subcomponents that you want to install, select the Custom installation
option. (After Operations Navigator has been installed, you can add subcomponents
by using Client Access Selective Setup.)
1. Display the list of currently installed subcomponents in the Component
Selection window of Custom installation or Selective Setup.
2. Select AS/400 Operations Navigator.
3. Select any additional subcomponents that you want to install and continue with
Custom installation or Selective Setup.
After you install Client Access, double-click the AS400 Operations Navigator icon
on your desktop to access Operations Navigator and create an AS/400 connection.
Prerequisite and related information
Use the AS/400 Information Center as your starting point for looking up AS/400
technical information. You can access the Information Center from the AS/400e
Information Center CD-ROM (English version: SK3T-2027) or from one of these
Web sites:
http://www.as400.ibm.com/infocenter
http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm
The AS/400 Information Center contains important topics such as logical
partitioning, clustering, Java, TCP/IP, Web serving, and secured networks. It also
contains Internet links to Web sites such as the AS/400 Online Library and the
AS/400 Technical Studio. Included in the Information Center is a link that describes
at a high level the differences in information between the Information Center and
the Online Library.
For a list of related publications, see the “Bibliography” on page 599.
How to send your comments
Your feedback is important in helping to provide the most accurate and high-quality
information. If you have any comments about this book or any other AS/400
documentation, fill out the readers’ comment form at the back of this book.
v If you prefer to send comments by mail, use the readers’ comment form with the
address that is printed on the back. If you are mailing a readers’ comment form
from a country other than the United States, you can give the form to the local
IBM branch office or IBM representative for postage-paid mailing.
v If you prefer to send comments by FAX, use either of the following numbers:
– United States and Canada: 1-800-937-3430
– Other countries: 1-507-253-5192
v If you prefer to send comments electronically, use one of these e-mail addresses:
– Comments on books:
About TCP/IP Configuration and Reference (SC41-5420)
xvii
[email protected]
IBMMAIL, to IBMMAIL(USIB56RZ)
– Comments on the AS/400 Information Center:
[email protected]
Be sure to include the following:
v The name of the book.
v The publication number of the book.
v The page number or topic to which your comment applies.
xviii
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 1. TCP/IP on AS/400
Transmission Control Protocol/Internet Protocol (TCP/IP) refers to a specific set
of protocols that allows computers to share resources and exchange information in
a network. Because TCP and IP are two of the best-known protocols in this set, the
term TCP/IP has become the standard name for the whole family.
TCP/IP support on AS/400 contains many of the commonly used protocols in the
TCP/IP family. Some of the protocols provide low-level and high-level data delivery
functions that are needed by several applications.
Most applications require Internet Protocol (IP), Transmission Control Protocol
(TCP), and User Datagram Protocol (UDP), which are low-level functions. High-level
functions or applications provide services such as file transfer, mail, and remote
logon. File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), and
TELNET are examples of high-level protocols.
TCP/IP is used to interconnect networks on a global basis across universities,
research institutions, businesses and industries, and military installations. The term
Internet applies to this entire set of interconnected networks. Because these
networks are interconnected, information is sent from one to another as security
restrictions permit. The Internet is governed by a central authority, which is
responsible for assigning network addresses to new users and subnetworks. Many
smaller private networks around the world use TCP/IP protocols, without connecting
to the Internet. TCP/IP provides a good solution for these smaller networks.
Linking Networks Together
Networks are linked together by sharing a common node system that routes
packets from one network to another. This common system is often referred to as
an IP router, or simply as a router. A router is a computer that directly attaches to
two or more IP networks and, as its name implies, routes packets from one network
to the other.
The networks connected by a router may use the same or different physical
network protocols. For example, one network could be an Ethernet LAN, and the
other might be a token ring. If necessary, the router transfers packets from one
network protocol to another. In this way, the system passes the packets from one
router to another. The system continues transfer attempts until it delivers the packet
to the final destination system directly across one physical network.
The terms gateway and router are often used interchangeably, particularly in this
publication. However, be aware that gateway often implies a more specialized
system. A gateway typically performs extra functions beyond the mere routing of
packets. For example, a gateway might provide a firewall.
You can use a bridge to connect networks. A bridge connects two or more networks
at the physical network level by forwarding data from one network to another. A
bridge differs from IP routers because a bridge uses physical addresses instead of
internet addresses. A bridge does not have an assigned internet address while an
IP router does. Therefore, a bridge is transparent in the TCP/IP network. A set of
bridged networks (or segments) appears and acts as a single physical network.
© Copyright IBM Corp. 1997, 1999
1
A network to which a node system is physically connected is a local network for
that system. A network that a system reaches only after passing through one or
more IP routers is called a remote network.
Internetwork Communications
An internetwork or internet is a collection of packet-switched physical networks that
are connected by routers to form a single, large virtual network. Simply, it is a
network of networks. Packets are units of data that are sent across
packet-switched networks. All nodes in the internet communicate as if they are on
the same physical network, regardless of their specific hardware or specific
software architecture. This cooperation among otherwise incompatible networks and
systems is known as interoperability.
Figure 2 shows how networks can be connected in an internet.
Figure 2. An Internetwork
The network connection of each node on an internetwork is assigned a unique
address. This internet address differs from a physical hardware address in that the
hardware address is often preset by the manufacturer, whereas you can assign or
reassign an internet address by standard conventions. Also, internet addresses are
in a standard form, while different hardware types use different address lengths and
formats.
Internet Addresses
Each node on a network is known as a host and has a unique address called an
internet address. This address is a 32-bit integer. An address is expressed in the
form nnn.nnn.nnn.nnn, where each field is the decimal representation of one byte,
or 8 bits, of the address. For example, the address whose hexadecimal
representation is X'82638001' is expressed as 130.99.128.1.
2
OS/400 TCP/IP Configuration and Reference V4R4
Within your own networks, you can assign your own addresses. However, if you
want to connect to the Internet, then your network addresses and domain names
that need to be visible on the Internet must be officially assigned by a central
authority. The authority at the time of this writing is Network Solutions, Inc. The
address is:
Network Solutions, Inc.
ATTN: InterNIC Registration Services
505 Huntmar Park Drive
Herndon, VA 20170
USA
1-703-742-4777
FAX: 1-703-742-9552
E-mail: [email protected]
URL: http://rs.internic.net/
Information about how to register a new domain name through the InterNIC is found
at the URL address which is listed above. This address contains registration tools
and forms for online registering, and an overview on domain name registration.
The Internet Assigned Numbers Authority, or IANA, has allocated a block of Internet
network addresses for use only in private networks, or intranets. The addresses are
dispensed through the InterNIC registration process. IANA guarantees that the
addresses within this range are not used as valid host internet addresses on the
Internet. The reserved addresses within this block are as follows:
10.0.0.0
172.16.0.0
192.168.0.0
-
10.255.255.255
172.31.255.255
192.168.255.255
Accessing the Internet
To obtain Internet access you must purchase it through an Internet Service Provider
(ISP). If you need assistance, the InterNIC provides you with contact information for
ISPs in the United States and other countries. See “Internet Addresses” on page 2
for address information to contact the InterNIC Registration Services.
Once you have selected an ISP to work with, the ISP obtains an internet address
for you. If you choose not to connect to the Internet through an ISP but plan to do
so directly, you still need to apply to the InterNIC for a domain address and an IP
network ID. However, in order to apply to the InterNIC without the assistance of an
ISP, you must be either a service provider or a large global corporation.
IBM also offers ISP services as part of its Internet Connection family of service
offerings. To contact IBM within the United States, call 1-800-IBM-4YOU
(1-800-426-4698), or you may call your local IBM office.
In addition, the following IBM Redbooks offer more information about choosing an
Internet Service Provider:
v Cool Title About the AS/400 and the Internet, SC24-4815
v Accessing the Internet, SG24-2597
v Using the Information Super Highway, GG24-2499
Chapter 1. TCP/IP on AS/400
3
IP Security
After choosing an Internet Service Provider (ISP) and setting up your Internet
connection, you will also need to create and implement a security policy. Such a
policy can be used to incorporate the rules governing computer resources and
communications resources within your organization. The inherent security features
of AS/400, when properly configured, provide you with the ability to minimize many
risks. However, when you connect to the Internet, you should consider additional
security measures to further ensure the safety of your AS/400 system and your
network.
The first step in developing a security policy is that you understand the risks that
are imposed by each service you intend to use or provide. Once you have identified
these risks and created a security policy in response to them, you will be prepared
to take the necessary steps to enforce them. To name a few, these steps may
include employee training and the purchase of additional hardware or software.
As you create a security policy and outline security objectives for your organization,
the following resources may be helpful:
v The book, Tips and Tools for Securing Your AS/400, SC41-5300-03
v The AS/400e Information Center offers a list of current topics about using the
Internet. Look there for information about IP packet filtering and network address
translation (NAT). It is located at the following URL address:
|
|
|
|
|
http://publib.boulder.ibm.com/html/as400/infocenter.html
Classes of Networks
Each internet address is comprised of a pair of numbers that correspond to its
network address, or network ID and host address, or host ID. The network ID
represents the network within the internet, and the host ID specifies an individual
host or router within the network.
internet address = <network ID><host ID>
The value of the first byte of the Internet address specifies how the Internet address
should be separated into its network and host part, as shown in Table 1. The 4-byte
address is divided between network ID and host ID in five different ways or classes.
The five classes of Internet addresses are: A, B, C, D, and E. Also shown is the
maximum number of hosts per network for each class.
Table 1. Classes of Networks
Network Class
1
Network ID
Host ID
Maximum Number
of Hosts per
Network Class
Class A
0 to 127
First byte
Last 3
bytes
16 777 214
Class B
128 to 191
First 2 bytes
Last 2
bytes
65 534
Class C
192 to 223
First 3 bytes
Last byte
254
Class D
224 to 239
Multicast
240 to 255
Reserved for future
use
2
Class E
4
Range of First
Byte
OS/400 TCP/IP Configuration and Reference V4R4
Table 1. Classes of Networks (continued)
Network Class
Range of First
Byte
Network ID
Host ID
Maximum Number
of Hosts per
Network Class
Notes:
1. Although 127 is a class A network ID, it is reserved for loopback addresses and cannot
be assigned.
2. Not supported by AS/400 except for the limited broadcast address of 255.255.255.255.
If the first byte of an Internet address is in the range 0 to 127, it is a Class A
network. These are very large networks. The host IDs can range from 0.0.1 to
255.255.254, which allows for a maximum of 16,777,214 hosts. An example of a
class A Internet address is 9.5.1.2. The network ID is 9 and the host ID is 5.1.2.
If the first byte of an Internet address is in the range 128 to 191, it is a Class B
network. These are medium-size networks. The host IDs can range from 0.1 to
255.254, which allows for a maximum of 65,534 hosts. An example of a class B
Internet address is 150.244.1.241. The network ID is 150.244 and the host ID is
1.241.
If the first byte of an Internet address is in the range 192 to 223, it is a Class C
network. These are relatively small networks. The host IDs can range from 1 to 254,
which allows for a maximum of 254 hosts. An example of a class C Internet
address is 221.6.1.244. The network ID is 221.6.1 and the host ID is 244.
If the first byte of an Internet address is in the range 224 to 239, it is a Class D
network. These addresses identify multicast networks. The first 4 bits in a class D
Internet address identify the Internet address as a multicast address. The rest of the
bits (28) identify a specific multicast group.
If the first byte of an Internet address is in the range 240 to 255, it is a Class E
network. These addresses are undefined and experimental at this time. AS/400
does not support class E Internet addresses except for the limited broadcast
address of 255.255.255.255.
Understanding network classes and how the Internet address is divided into
different classes is important for the discussion of subnetworks in the following
topic.
IP Subnets
An IP subnet is the division or split of a TCP/IP network. When you divide an IP
network into multiple subnets, you avoid having to request additional IP network
addresses and alleviate the waste of existing addresses. ″Subnetting″ is frequently
performed on class A and B internetworks because they are larger and contain
more available host address space.
Also worth noting is the fact that subnets can be assigned locally and the process
of subnetting can remain transparent to remote networks.
Chapter 1. TCP/IP on AS/400
5
Subnetworks and Subnet Masks
A class A, B, or C network can be further divided into multiple smaller networks that
are called subnetworks. These smaller networks are identified or addressed by a
subnet ID. With an Internet address of any class we can subdivide the host ID bits
to provide identification of the subnet ID. The subnetwork is identified by combining
the network ID and subnet ID. This combining of the network ID and subnet ID is
defined as a subnet mask.
A subnet mask further specifies for the host the exact number of bits that are to be
used for the subnet ID and the number to be used for the host ID. Overall, subnet
masks make it easier to divide a single network without wasting internet addresses
and as a result, increase the performance of the network.
For example, consider a class B internet address that has a network ID portion
equal to 144.22. This class B address has 16 bits allocated for the network ID and
16 bits allocated for the host ID as shown in Figure 3:
Figure 3. Standard Class B
If the high-order byte of the host ID portion of the class B internet address is used
for a subnet ID, then the host ID can be divided into an 8-bit subnet ID and an 8-bit
host ID as shown in Figure 4:
Figure 4. Subnetted Class B
The class B 144.22 network, using this identification of the subnet ID, can be
divided into 254 subnetworks ranging from 144.22.1 through 144.22.254.
Figure 5. Subnetted Class B with Subnetworks
The subnet mask that identifies the subnetwork in this example would be
255.255.255.0.
Therefore, an internet address can be shown as consisting of the following:
internet address = <network id><subnet id><host id>
6
OS/400 TCP/IP Configuration and Reference V4R4
Note: The subnet ID does not have to be identified by contiguous bits in the host
ID portion of the internet address. The subnet ID can be identified by using
noncontiguous bits in the host ID portion of the internet address. It is strongly
recommended to use contiguous bits to identify the subnet ID.
Assume, for example, two networks where subnetting is used: subnetwork 9.4.70
and subnetwork 9.4.73.192. The first byte of the internet address is 9, which makes
it a class A network. 9.4.70 is an example of a network where two complete bytes
of the host ID have been used for the subnet ID. 9.4.73.192 is an example where
two complete bytes and part of a third byte of the host ID have been used for the
subnet ID. For 9.4.70, the range of host IDs available is 9.4.70.1 through
9.4.70.254. For 9.4.73.192, the range of host IDs available is 9.4.73.193 through
9.4.73.254.
A subnet mask is used to distinguish between a subnet ID and a host ID. Bits in the
subnet mask are set to 1 if the network treats the corresponding bit in the internet
address as part of the network ID and subnet ID and to 0 if it treats the bit as part
of the host ID. For example, a subnet mask of:
Subnet mask
=
11111111
11111111
11111111
00000000
specifies that the first three bytes identify the subnetwork and the fourth byte
identifies the host. Remember that the network portion of the internet address is
based on the class of internet address (A, B, C, D or E). The subnet mask must at
a minimum mask off the network portion of the address. In this case, because we
are discussing a class A address, the first byte must be all 1s. A subnet mask would
normally be specified in the same dotted decimal notation as an internet address.
Because the second and third bytes are being used to identify the subnet ID, those
two bytes should also be all 1s. Thus, in this example, the subnet mask is
255.255.255.0. If an internet address of 9.4.70.254 is compared against the subnet
mask:
Subnet mask
= 11111111 11111111 11111111 00000000
Internet address = 00001001 00000100 01000110 11111110
(logical and)
-------- -------- -------- -------Subnetwork
= 00001001 00000100 01000110 00000000
the subnetwork is 9.4.70 and the host ID is 254.
In the second example, the subnet mask for subnetwork 9.4.70 is 255.255.255.0.
The subnet mask for subnetwork 9.4.73.192 is 255.255.255.192. This is an example
of a subnetwork where part of a host ID byte has been used for the subnet ID. In
this case, the upper 2 bits of the fourth byte are used as part of the subnet ID. In bit
form, the subnet mask is:
Subnet mask
=
11111111
11111111
11111111
11000000
This means that the first 3 bytes and the first 2 bits of the fourth byte identify the
subnetwork, and the last 6 bits of the fourth byte identify the host. If an internet
address of 9.4.73.212 is compared against the above subnet mask:
Subnet mask
= 11111111 11111111 11111111 11000000
Internet address = 00001001 00000100 01001001 11010100
(logical and)
-------- -------- -------- -------Subnetwork
= 00001001 00000100 01001001 11000000
The subnetwork is 9.4.73.192 and the host ID is 20.
It is also possible to have a subnet mask where the network ID part is not
contiguous. For example:
Chapter 1. TCP/IP on AS/400
7
Subnet mask
=
11111111
11111111
01100000
01000000
This method is not normally used and is not recommended.
For AS/400 business computing systems in the above network, the full route table
could be:
Work with TCP/IP Routes
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
_
_
_
Route
Destination
______________
*DFTROUTE
9.4.70.0
System:
SYSNAM01
5=Display
Subnet
Mask
______________
*NONE
255.255.255.0
Next
Hop
______________
9.4.73.193
9.4.73.194
Preferred
Interface
*NONE
*NONE
F3=Exit
F5=Refresh
F6=Print list
F10=Work with IP over SNA routes
F11=Display type of service F12=Cancel
F17=Top
F18=Bottom
Bottom
Figure 6. AS/400 TCP/IP Subnet and Subnet Mask
The default is to route all traffic to the router associated with that subnetwork. No
routing configuration is required within the same subnetwork.
All hosts in the same subnetwork must use the same subnet mask.
Broadcast Addresses
Broadcast addresses are used to address multiple recipients on a network as
opposed to addressing a single recipient, which is done through unicast addresses.
Another type of IP address used for the purpose of sending a message to multiple
nodes on a network is the muliticast address. In the paragraphs that follow,
broadcast addresses are discussed. For more information about IP multicasting,
see “IP Multicasting” on page 91.
While there are several types of broadcast addresses, they can be separated into
two categories: the limited broadcast address and the directed broadcast address.
On each physical network, a limited broadcast address is an internet address that
consists of all 1 bits (255.255.255.255.). A directed broadcast address is an
internet address with a valid network ID and a host ID of all 1 bits. There are
different types of directed broadcast addresses, including network-directed,
subnet-directed, and all-subnets-directed.
8
OS/400 TCP/IP Configuration and Reference V4R4
Limited broadcasts only apply to the physical network. Packets addressed to the
limited broadcast address are not forwarded beyond the physical network of origin.
Domain Name System (DNS)
An Internet address is used to establish a connection between your system and
another system in a network. Because Internet addresses can sometimes be
difficult to remember, another naming convention is used. This naming convention is
called the Domain Name System (DNS). DNS names provide an easier way to
identify systems in a network.
When DNS is configured to run as part of TCP/IP, it is referred to as a DNS server.
For more information about AS/400 DNS server configuration and functions, see
“Chapter 18. AS/400 Domain Name System (DNS)” on page 421.
Domain and Host Name
A domain name identifies where your system is located within a hierarchy of
groups of systems. Domain names consist of labels that are separated by periods
(for example, ABC.DEF.XYZ). Within a domain represented by a domain name, there
can be many systems, and each must have a unique host name. A system’s host
name can be used by remote servers to associate an Internet address with the
system. Since host names are only unique within a domain, a host name is usually
combined with a domain name in the form host.domain, which is called a
fully-qualified host name.
Note: SMTP often refers to the host or host.domain combination as a domain. For
clarity, it is refered to in this publication as a SMTP domain.
When a network is small, the host names can be a sequence of characters without
any further structure. The advantage of this kind of name is that it is convenient and
easy to remember. The disadvantage is that it is not suitable for large sets of
machines for the following reasons:
v When the number of sites increases, the potential for conflicting names
increases.
v The authority for adding new names must rest at a single site, and the
administrative work load increases as the number of sites increase.
v The name-to-address bindings change frequently, and the cost of maintaining
correct copies at each site is high.
The answer to these problems is the decentralization of the naming process by
delegating authority for parts of the network. The name area of the network is
partitioned at the top level. The top level delegates authority (where it has some
authority) for the partitions. The top level need not be bothered by changes within
the different partitions.
The syntax of hierarchically assigned names reflects the hierarchical delegation of
authority used to assign them. For example, the names of the form local.site mean
that site is the top level of the hierarchy and this name has been authorized by the
central authority; local is a host name controlled by the site. The authority can be
further subdivided at each level. In this example, the site can be divided into two
groups:
v Production
Chapter 1. TCP/IP on AS/400
9
v Marketing
Syntactically, adding a new level introduces another subdivision to the name. In this
example, the machine can belong to the marketing group with the name:
local.market.site. Local is the host name, and market.site is the domain name.
Naming Conventions for Domain Names and Host Names
Normally the hierarchical machine names are assigned according to the structure of
organizations that obtain authority for parts of the namespace, not according to the
structure of the physical network interconnections.
A domain name or a host name can be a text string having 2 to 255 characters.
Domain names consist of one or more labels separated by periods. Each label can
contain up to 63 characters. The following characters are allowed in domain names:
v Alphabetical characters A through Z
v Digits 0 through 9
v Underline (_)
Note: The Underline character (_) is not fully supported by all implementations
outside of AS/400.
v Minus sign (-)
v Period (.). Periods are only allowed when they separate labels of domain style
name (refer to RFC 1034, Domain Names - Concepts and Facilities.).
Other naming conventions for domain names and host names include the following:
v Uppercase characters and lowercase characters are allowed, but no significance
is attached to the case.
v The first character of each part of the name separated by periods must be an
alphabetic character (uppercase A-Z or lowercase a-z).
v The last character of each part of the name separated by periods must be an
alphabetic character (uppercase A-Z or lowercase a-z) or a numeric character
(0-9).
v Blanks cannot be embedded.
v Only the special characters period (.), minus sign (-), and underline (_) are
allowed.
v Parts of the name separated by periods (.) cannot exceed 63 characters.
v Each part of the name must be at least 1 character.
v Fully-qualified host names including all periods cannot be more than 255
characters.
v Advanced program-to-program communications (APPC), over TCP/IP (part of
AnyNet/400) uses the host name to map location names to Internet addresses.
The host name must be in the form:
location.netid.SNA.IBM.COM
Where location is the remote location the program is opening to, and netid is the
network identifier for this connection. SNA.IBM.COM is the qualifier that
designates this as the APPC over TCP/IP domain.
Location names support characters that cannot be present in host names.
Therefore, the APPC application can open only to locations that fulfill the TCP/IP
host name syntax. This limits location names used for APPC over TCP/IP to the
10
OS/400 TCP/IP Configuration and Reference V4R4
characters A-Z (uppercase and lowercase), 0-9, $ (dollar), @ (at sign), and #
(number sign). The location name must begin with an alphabetic character.
v Try to limit your domain name labels to 12 characters because shorter labels are
easier to remember.
v It is a common practice to use hierarchical names that allow predictable
extensions for change and growth. Domain names normally reflect the delegation
of authority or hierarchy that is used to assign them.
For example, the name SYS1.MFG.ABC.COM can be broken down into the
following:
– COM: All commercial networks.
– ABC.COM: All systems in the ABC company’s commercial network.
– MFG.ABC.COM: All manufacturing systems in the ABC company’s commercial
network.
– SYS1.MFG.ABC.COM:
A host that is named SYS1 in the manufacturing area of the ABC company’s
commercial network.
The COM designation is one of several domain names that are used when
connecting to the Internet. Some of the other domain names are as follows:
ARTS Entities with activities related to culture and entertainment
COM
Commercial organizations
Country code
Countries that may be other than US
EDU
Educational institutions
FIRM
Business or firm
GOV
Government institutions
INFO
Entities that provide information services
MIL
Military groups
NET
Major network support centers (Internet)
NOM
An individual or personal nomenclature
ORG
Organizations
REC
Entities with activities related to recreation and entertainment
STORE
Businesses offering goods to purchase
WEB
Entities with activities related to the world wide web
For example, one of the domain names used in this book
(SYSNAM01.SALES.ABC.COM) indicates the following:
- The Internet authority has assigned company “ABC” into the commercial
organizations group.
- Company ABC authority has assigned this address to the group named
SALES.
- Company ABC authority has assigned SYSNAM01 as the name for this
IBM AS/400 business computing system.
Chapter 1. TCP/IP on AS/400
11
Routing
Routing is the process of mapping a path to send a packet to its destination
Internet address. Routing can be direct or indirect. Direct routing is used when the
source and destination nodes are on the same physical network. When direct
routing is used, the source node sends the packet on the network with the
destination hardware address in the link layer protocol header. The destination node
hardware detects its own address in the packet header and accepts the packet.
Indirect routing is used when the source and destination nodes are not on the same
physical network. The source node uses its routing tables to determine which router
will forward packets to the destination node. The packet is put on the network with
the router’s hardware address in the network header, and the destination’s Internet
address in the IP header. Thus, the router hardware receives the packet from the
network, and the router IP software determines the packet’s destination from the IP
header.
Introduction to TCP/IP Protocols on AS/400
Network protocols are sets of rules that control the communication and transfer of
data between two or more devices in a communications system. The term TCP/IP
refers to a family of nonproprietary network protocols, of which TCP, providing
host-to-host transmission, and IP, providing data routing from source to destination,
are two important parts.
The topics that follow discuss only those protocols that are available on the AS/400
business computing system.
TCP/IP consists of a layered structure of protocols that range from low-level,
hardware-dependent programs, to high-level applications. Each TCP/IP layer
provides services to the layer above it and uses the services provided by the layer
below it.
The layers are defined as follows:
Application
Provides a way for a process to cooperate with another process on the
same or a different host.
Transport
Provides communication from one application program to another. Such
communication is often called end-to-end data transfer.
Internetwork
Makes the entire physical network seem like a single virtual network. This is
achieved by shielding the higher levels from the underlying network
architecture.
Network Interface or Data Link
Provides the interface to the actual network hardware. Examples are
token-ring and Ethernet.
Hardware
This layer is not part of the TCP/IP family and is represented by dotted
lines. This layer consists of the hardware-specific network protocols.
12
OS/400 TCP/IP Configuration and Reference V4R4
Application Protocols
Application protocols are the highest-level protocols within the application layer. The
application layer overall consists of several independent protocols that put into
effect commonly used applications.
These protocols are able to communicate with applications on the same host or on
different hosts. They serve as the user-visible interface to the TCP/IP protocol suite
and use UDP and TCP protocols as methods for data transmission. Some of the
most frequently used application protocols include FTP, SMTP, and TELNET.
Application Protocol Standards
The TCP/IP protocols include standards for many common applications. A
discussion of each follows.
File Transfer Protocol (FTP)
FTP is an AS/400 TCP/IP application that enables you to transfer files between
local and remote hosts. It does this through the use of the FTP subcommands, GET
and PUT. FTP transfers files by using either an ASCII or EBCDIC mode. ASCII
mode transfers data sets that contain only text characters.
Remote Printing (Line Printer Requester and Line Printer
Daemon)
AS/400 TCP/IP provides client support and server support for remote printing. The
client, line printer requester (LPR), allows the user to send spooled files to a remote
system that is running a remote printer daemon (LPD) server.
Bootstrap Protocol (BOOTP)
BOOTP is a TCP/IP protocol that allows for booting systems remotely to the
network. BOOTP is used to support the IBM Network Station for AS/400.
Trivial File Transfer Protocol (TFTP)
Trivial File Transfer Protocol (TFTP) is a simple protocol and is used solely to
provide basic file transfers to and from a remote server. TFTP is used to support
the IBM Network Station for AS/400.
Route Daemon (RouteD) Server
The Route Daemon provides support for the Routing Information Protocol (RIP) on
AS/400. RIP is the most widely used routing protocol today. RIP is an Internet
Gateway Protocol used to assist TCP/IP in the routing of IP data packets.
Remote Execution (REXEC) Server
The Remote Execution server allows a client user to submit system commands to a
remote server system.
Simple Mail Transfer Protocol (SMTP)
AS/400 TCP/IP provides for the exchange of electronic mail between host servers
running TCP/IP by using SMTP. The SMTP application is based on end-to-end
delivery, which means that an SMTP client contacts the destination host’s SMTP
Chapter 1. TCP/IP on AS/400
13
server directly in an effort to deliver the mail. The SMTP client will actually retain
and retry transmission until the mail item is successfully delivered to the intended
destination or recipient.
Post Office Protocol (POP) Mail Server
The POP server is the AS/400 implementation of the Post Office Protocol (POP)
Version 3 mail interface. This server is a store-and-forward mail system that
provides electronic mailboxes on AS/400 from which clients can retrieve mail. POP
allows users to exchange multimedia mail.
The POP application allows AS/400 systems to act as POP servers for any clients
that support the POP mail interface, including clients running on Windows, OS/2,
AIX and Macintosh.
TELNET Protocol (TELNET)
AS/400 TCP/IP TELNET provides client and server support that allows remote
logon to hosts within an internet.
Simple Network Management Protocol (SNMP)
AS/400 TCP/IP SNMP provides a means for managing an internet environment.
SNMP allows network management by elements, such as routers and hosts.
Network elements act as servers and contain management agents that perform the
management functions requested. Network management stations act as clients;
they run the management applications that monitor and control the network. SNMP
provides a means of communicating between these elements and stations to send
and receive information about network resources.
AS/400 can be an agent in an SNMP network. That is, the AS/400 system gathers
information about the network and performs the management functions that are
requested by some remote SNMP manager. At this time, AS/400 cannot be an
SNMP manager in a TCP/IP network.
Simple Network Management Protocol (SNMP) is used predominately in TCP/IP
networks. However, OS/400 AnyNet support allows OS/400 SNMP support to be
used in a SNA network.
For additional information about SNMP, see the Simple Network Management
Protocol (SNMP) Support, SC41-5412-00 book.
5250/Hypertext Markup Language (HTML) Workstation Gateway
The 5250/Hypertext Markup Language (HTML) Workstation Gateway (WSG) server
is an application that automatically transforms AS/400 5250 applications to
Hypertext Markup Language (HTML). This allows users to run AS/400 applications
from any PC that has a WEB browser, and allows for TCP/IP network connectivity
to the AS/400 host.
Domain Name System Server (DNS)
The Domain Name System (DNS) server is used by applications to translate
domain names of hosts to IP addresses. The Domain Name System is the network
naming service of intranets and the Internet.
14
OS/400 TCP/IP Configuration and Reference V4R4
Dynamic Host Configuration Protocol (DHCP)
The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing
configuration information to hosts on a TCP/IP network.
DHCP can function either as a DHCP server or a BOOTP/DHCP Relay Agent.
If DHCP functions as a DHCP server, it processes DHCP packets on the local
system. If DHCP functions as a BOOTP/DHCP Relay Agent, it then relays DHCP
and BOOTP packets on the local system, but does not process them.
Point-to-Point Protocol (PPP)
PPP is a method of transmitting datagrams over serial point-to-point links for wide
area network (WAN) connectivity.
OS/400 Network File System Support
OS/400 Network File System (NFS) Support is a replacement for the TCP/IP File
Server Support/400 (FSS/400) licensed program offering. Users who are
accustomed to working with FSS/400 will notice many similarities between FSS/400
and NFS. It is important to note, however, that FSS/400 and NFS are not
compatible with each other. At any given time, only one of these applications may
be executing.
NFS support allows the AS/400 system to function as a file server on the Internet. It
does this by making remote objects stored in a file system appear to be local, as if
they reside in the local host.
With NFS, all systems in a network can share a single set of files. This eliminates
the need for duplicate file copies on every network system. Using NFS aids in the
overall administration and management of users, systems, and data. For more
information about the Network File System see the book, OS/400 Network File
System Support, SC41-5714-01.
Application Program Interfaces (APIs)
Many times an enterprise has unique interoperability requirements for its private
networks. This means that the enterprise must provide its own applications to fulfill
these unique requirements. On AS/400, this is accomplished with several
application programming interfaces (APIs).
For helpful reference information about all of the OS/400 APIs, see the System API
Reference, SC41-5801-03.
Sockets Interface
A sockets interface (sockets) allows you to write your own applications to
supplement those that are supplied by TCP/IP. Sockets allow unrelated processes
to exchange data locally and over networks. Both connection-oriented and
connectionless communications are provided for TCP/IP. With this support you can
write applications to the TCP, UDP, and IP protocols directly. The TCP/IP
applications that run on sockets are FTP, SMTP, SNMP, LPR, LPD, BOOTP, TFTP,
RouteD, and REXEC. The sockets interface operates over TCP/IP or AnyNet/400.
Chapter 1. TCP/IP on AS/400
15
For additional information about sockets, see the Sockets Programming,
SC41-5422-03 book.
Send MIME Mail API
The Send MIME Mail API allows applications to use SMTP and TCP/IP to send mail
to the Internet.
Pascal API
The TCP/UDP programming interface was originally developed to provide system
programmers with a programming interface to the TCP or UDP protocols via a set
of procedure calls from an AS/400 Pascal program. This interface is no longer
documented in this publication because the AS/400 Pascal compiler is no longer
available. For information about the withdrawal of support for the Pascal compiler
see, New Release Planning for V3R7, SA41-4100.
The run-time support for the Pascal API is still included in the program product IBM
TCP/IP Connectivity Utilities for AS/400 (5769-TC1). Existing applications that use
the Pascal API can continue to be used. However, any new AS/400 TCP/IP
applications should use the sockets API.
Important Note:
Because of changes made to AS/400 TCP/IP in V3R1, pre-V3R1 TCP/IP
applications that use the Pascal API must be recompiled to function correctly
in V3R1 or later.
Multiprotocol Transport Networking Architecture
The Multiprotocol Transport Networking (MPTN) architecture implementation on
AS/400 allows Common Programming Interface Communications (CPI
Communications), intersystem communications function (ICF), and sockets to flow
over either TCP/IP, Systems Network Architecture (SNA), or Internetwork Packet
Exchange (IPX). On AS/400, the MPTN architecture is put into effect as AnyNet/400
support. For more information about AnyNet/400, see “AnyNet/400” on page 19.
Transport Protocol
This layer provides the end-to-end data transfer. This layer allows communication
between application programs. Example protocols that provide transport services
are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
Transmission Control Protocol (TCP)
TCP is a widely used connection-oriented protocol that enables the transfer of data
from a source to a destination. TCP provides a reliable delivery of a stream of bytes
in sequence. TCP takes a stream of data, breaks it into segments (a TCP header
and application data), sends each one individually (using IP), and then reassembles
the segments back into the original stream. If any segments are lost or damaged
during the transmission, TCP detects this fact and resends the missing segments.
Most of the user application protocols, such as TELNET, FTP and SMTP, use TCP.
16
OS/400 TCP/IP Configuration and Reference V4R4
User Datagram Protocol (UDP)
UDP allows your application programs to send datagrams to other programs on
other systems with a minimum of protocol overhead. UDP does this through the use
of ports. Unlike TCP, UDP is datagram oriented and does not guarantee the
delivery of data in sequence. Datagrams may possibly be dropped or reordered as
they travel from the source to the destination. UDP can be used instead of TCP
when the application does not want to incur the overhead of TCP connecting and
disconnecting. It then becomes the responsibility of the application to ensure
reliable data transfer and sequencing of datagrams.
The following TCP/IP applications use UDP:
v SNMP
v TFTP
v DNS
AS/400 UDP also includes multicast support, beginning with Version 4 Release 2.
TCP and UDP Ports
A port is an integer value from 1 to 65535 that is used to identify a TCP/IP
application. TCP and UDP protocols use ports to identify a unique origin or
destination of communication with an application. There are two unique sets of
ports. One set is for TCP processing, and the other is for UDP processing. They are
completely independent sets of ports and have no relationship to one another.
Well-known Ports
Commonly used protocols and applications, such as FTP and SMTP, have assigned
port numbers. These assigned port numbers are called well-known ports. TCP and
UDP port numbers 1 to 1023 are reserved for the well-known ports and should not
be used by user application programs. If the user specifies one of these ports, it
can affect the operation of those applications. Refer to RFC 1700, entitled,
Assigned Numbers, for a list of well-known ports.
To see the list of ports currently defined on AS/400, perform the following steps:
1. Use the Configure TCP/IP (CFGTCP) command to get to the Configure TCP/IP
menu
2. Select option 21 (Configure related tables)
3. Select option 1 (Work with service table entries)
Point-to-Point TCP/IP
Dial-up TCP/IP, known as point-to-point TCP/IP, is used to dial into remote systems,
or allow remote systems to dial into AS/400 over a telephone line using a modem.
Null modem or non-switched connections are also supported. The Serial Line
Internet Protocol (SLIP) and the Point-to-Point Protocol (PPP) are supported on
AS/400.
Chapter 1. TCP/IP on AS/400
17
Internetwork Protocol
This layer provides the virtual network image of the physical network. This layer
shields the higher levels from the typical network architecture below it. Internet
Protocol (IP) is the most important protocol at this level. IP is a connectionless
protocol that does not provide reliability, flow control, or error recovery, and does not
assume reliability from the lower layers. An example of a protocol at this level is the
Internet Control Message Protocol (ICMP).
Internet Protocol
The Internet Protocol (IP) provides the basic transportation rules for communication
between hosts on the different networks that make up an internet. A host is a node
on the network that has a unique internet address and an associated system name.
IP is responsible for routing packets from a host on one network through a series of
routers to a host on the same or another network.
In IP-based networks, information is transmitted between nodes in the form of
packets. A packet includes an IP header and data. A packet or network frame can
contain a complete IP datagram or a fragment of an IP datagram. A datagram is
the basic unit of information in the TCP/IP protocol, consisting of a source address,
destination address, and data. At the internet level, all addressing is host-to-host,
using fixed-length addresses to identify source and destination hosts. The protocol
layers above only need to know each host’s internet address to make a connection.
See Figure 7 and Figure 8 for illustrations of the terms packet, datagram, and
segment.
If there is a transmission on the network:
Figure 7. Packet and Frame Terminology
Before the IP is broken into pieces or after IP reassembly:
Figure 8. Segment and Datagram Terminology
After packets are received, they are passed to the IP layer. Datagrams are
reassembled if necessary, and stripped of the header before being passed on to the
next higher protocol layer. IP does not acknowledge receiving a datagram, nor is it
responsible for retransmitting or providing flow and error control. Reliable delivery
18
OS/400 TCP/IP Configuration and Reference V4R4
must be ensured by a higher level protocol, such as TCP. Integral to every IP
implementation is the Internet Control Message Protocol (ICMP), which is used for
reporting errors, congestion reporting, and first-hop router redirection.
Internet Control Message Protocol
The Internet Control Message Protocol (ICMP) provides for error and control
messages between host systems (peer computers in a network) and routers.
Routers and host systems use ICMP to send reports of problems. ICMP also
includes an echo request or reply message that is used to test whether a
destination can be reached and is responding. This is commonly known as PING
(Packet InterNet Groper).
Internet Group Management Protocol
The Internet Group Management Protocol (IGMP) is used by IP hosts to report their
host group memberships to neighboring multicast routers. Multicast routers send
Host Membership Query messages to discover which host groups have members
on their attached networks. Hosts respond to a Query by generating Host
Membership Reports, reporting each host group to which they belong. The multicast
routers use this information to determine where multicast datagrams need to be
forwarded.
Address Resolution Protocol
The Address Resolution Protocol (ARP) dynamically associates internet addresses
to physical hardware addresses on a local network. ARP relies on the broadcast
capabilities of the underlying media to provide this function.
AnyNet/400
AnyNet/400 is part of the AnyNet family of products. AnyNet products allow
application programs written for one communications protocol to run over non-native
protocols without changing (or recompiling) the application programs. The
destination address determines if the request is sent over the native protocol or
through the AnyNet code and on to a non-native protocol.
AnyNet/400 allows sockets, intersystem communications function (ICF), CPI
Communications (CPI-C), and CICS/400 applications to run over APPC, TCP/IP,
and Internetwork Packet eXchange (IPX). AnyNet/400 is based on the Multiprotocol
Transport Network (MPTN) architecture, and is designed to allow any application to
run over any networking protocol. You can use AnyNet/400 to:
v Access APPC using TCP/IP if your applications were developed for system
network architecture (SNA) but you are using TCP/IP to connect the systems
v Access APPC using IPX if your applications were developed for SNA but you are
using IPX to connect the systems
v Access sockets using SNA if your sockets applications were developed for
TCP/IP but you are using SNA to connect the systems
v Access sockets using IPX if your sockets applications were developed for TCP/IP
but you are using IPX to connect the systems.
AnyNet/400 is shipped with the AS/400 base operating system, OS/400.
Chapter 1. TCP/IP on AS/400
19
Accessing APPC Using TCP/IP (SNA Over IP)
AnyNet/400 APPC over TCP/IP allows you to extend intersystem communications
function (ICF), common programming interface for communications (CPI-C), and
CICS/400 applications to TCP/IP users without adding a separate APPC network.
You can also allow any OS/400, ICF, CICS/400 or CPI-C application (such as
DRDA) to communicate across a TCP/IP network.
The Communications Configuration, SC41-5401-00 book, tells you how to configure
AnyNet/400 APPC over TCP/IP.
Accessing APPC Using IPX (SNA Over IPX)
AnyNet/400 APPC over IPX allows you to extend ICF, CPI-C or CICS/400
applications to IPX users without adding a separate APPC network. You can also
allow any OS/400, ICF, CICS/400 or CPI-C application (such as DRDA) to
communicate across an IPX network.
Accessing Sockets Using IPX (IP Over IPX)
AnyNet/400 Sockets over IPX allows you to add Berkeley Software Distribution
(BSD) Sockets applications to existing IPX networks, without adding a separate
TCP/IP network. This allows OS/400 users to use most Sockets applications (such
as FTP, SMTP and SNMP) across an IPX network.
The book Internetwork Packet Exchange (IPX) Support, SC41-5400-00, tells you
how to configure and use the Novell protocol suite with OS/400.
Accessing Sockets Using SNA (IP over SNA)
AnyNet/400 Sockets over SNA allows you to add BSD Sockets applications to
existing SNA networks without adding a separate TCP/IP network. This allows
OS/400 users to use most sockets applications (such as FTP, SMTP and SNMP)
across an SNA network.
The book Sockets Programming, SC41-5422-03, describes how to use both AnyNet
and non-AnyNet sockets.
20
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 2. Configuring TCP/IP
This chapter explains how to configure an AS/400 business computing system for
Transmission Control Protocol/Internet Protocol (TCP/IP). If this is the first time that
you have configured TCP/IP on an AS/400 system, you should read the entire
chapter before performing any of the configuration tasks.
If you are unfamiliar with TCP/IP, consider reading Chapter 1. TCP/IP on AS/400.
For a complete formal description of TCP/IP, you can read the Request for
Comments (RFC). Or, refer to any of the TCP/IP references that are listed in
“Request For Comments (RFC)” on page 602. Information about how to order an
RFC is also listed within that topic.
What you need to know before you can configure TCP/IP
Before you start configuring TCP/IP, you must ensure that the TCP/IP Connectivity
Utilities for AS/400 licensed program (LP) is installed on your system. See
“Installing the TCP/IP Application Programs” on page 23 for more information.
The AS/400 has many commands and menus available to help you configure
TCP/IP on AS/400. Before you begin this task, take time to review the TCP/IP
Administration (TCPADM) menu, Figure 9 on page 26, and the Configure TCP/IP
(CGFTCP) menu, Figure 10 on page 28.
The initial displays and menus that are shown when you configure TCP/IP on your
system may not contain any entries. The sample command line interface displays in
this chapter may already contain data, which was entered for the purpose of
example in previous configuration steps.
Performing configuration tasks on a single network or even a simple multiple
network requires that you do some planning before configuring TCP/IP on any
system in that network, including an AS/400. To help you get started with setting up
TCP/IP, this chapter includes complete planning details and checklists.
Once you have designed a plan, follow the step-by-step process that is outlined for
you in this chapter. Each step guides you through TCP/IP installation and
configuration on your system, defines various terms, and describes how these
terms relate to TCP/IP.
Using the Operations Navigator interface: You can configure TCP/IP through the
Operations Navigator interface wizard. Information related to Operations Navigator
is located in the online help. See the online help in Operations Navigator for
information about the following TCP/IP functions:
v Configuring TCP/IP, including basic functions such as starting and stopping
TCP/IP
v Creating a new Ethernet line
v Creating a new token-ring line
v Working with TCP/IP interfaces, including configuring a TCP/IP route
v Working with TCP/IP host tables, including configuring a TCP/IP host name and
domain name
v Verifying a TCP/IP connection (PING)
© Copyright IBM Corp. 1997, 1999
21
Planning for TCP/IP Installation and Configuration
If you are in charge of configuring an AS/400 system for TCP/IP communications
you will, in most cases, include your AS/400 system in an existing TCP/IP network.
Before you are able to start configuring, you will need to collect all of the required
information.
Start by contacting the person responsible for the TCP/IP network of your company,
your TCP/IP network administrator. When talking to the administrator, you may want
to use Table 3 on page 51 and Table 4 on page 51 as checklists to record the
necessary information.
Gathering Information About your Network
After collecting the preliminary information about your network, plan the installation
and configuration of TCP/IP by using the steps that are listed below:
1. Draw a diagram of your network: A diagram similar to that shown in Figure 32
on page 53 will help you decide how you want to attach your AS/400 system to
the other systems in the network. Include other data that relates to your
network, such as:
v Line description information
v Internet Protocol addresses and domain names
v The number of route entries that are required
Refer to Table 3 on page 51.
2. Identify the names of the systems in your network: For example, do either
of the following:
v Build a local host table.
v Identify a Domain Name System (DNS) server for maintaining host table
entries.
3. Install the appropriate hardware and software: You must install the
appropriate hardware adapters in your AS/400 system if you are going to
connect to the following networks:
v X.25 packet-switching
v Frame relay
v Token-ring
v Ethernet
v
v
v
v
v
Fiber distributed data interface (FDDI)
Shielded twisted pair distributed data interface (SDDI)
Wireless local area network (LAN)
Synchronous or asynchronous communications line
Twinaxial data link support (TDLC)
You also need to make sure that the appropriate software is installed on all the
systems. On the AS/400 system, the OS/400 licensed program and the TCP/IP
Connectivity Utilities for AS/400 licensed program must be installed.
4. Assign names and Internet addresses: If you are attaching to an existing
network, you need to know the Internet addresses and names used by the other
systems. An existing network usually has an administrator who keeps such
22
OS/400 TCP/IP Configuration and Reference V4R4
information. If this person is someone other than you, have that individual
provide you with the Internet address to use for your system.
Depending on the size of your network and its complexities, determine whether
a host table or a DNS server is the preferred method for maintaining and
updating host name and IP address associations. In this chapter, refer to “Step
6—Configuring TCP/IP Host Table Entries” on page 38. For information about
configuring and using a DNS server, see page 421.
5. Obtain X.25 network addresses: If you plan to use TCP/IP on an X.25 private
or public data network, you need to know whether you will be using a switched
virtual circuit (SVC) or permanent virtual circuit (PVC).
v To use an SVC, you need to know the network address of each remote
system in the network with which you want to communicate.
v To use a PVC, you need to know the related logical channel identifier. You
can have a network address or a permanent virtual circuit, but not both, for a
remote system information entry.
If a remote system is an AS/400 system, you can determine its network
address by using the Display Line Description (DSPLIND) command on that
remote system.
6. Familiarize yourself with the TCP/IP Administration Menu: The TCP/IP
Administration menu (Figure 9 on page 26) provides easy access to common
functions associated with administering TCP/IP.
To get to this menu, enter the GO TCPADM command from the AS/400 Main
Menu.
7. Familiarize yourself with the Configure TCP/IP Menu: The Configure TCP/IP
menu (Figure 10 on page 28) guides you through all the tasks for configuring
your AS/400 system to communicate with other systems in a TCP/IP network.
You can reach this menu in two ways:
v Select option 1 on the TCPADM menu.
v Enter the Configure TCP/IP (CFGTCP) command.
Once you have documented configuration information, you are ready to install the
TCP/IP program on your AS/400 system. The information in the section that follows
will help you do that. See “Installing the TCP/IP Application Programs”.
For information about TCP/IP addressing and connecting to the Internet, see
“TCP/IP Addressing” on page 24. This topic discusses the methods for assigning
addresses within your own network and offers an example.
Installing the TCP/IP Application Programs
Important
To determine whether the TCP/IP LP is already installed, enter GO LICPGM
(Go Licensed Program) on the command line and then select Option 10 to
display the installed licensed programs. If the TCP/IP Connectivity Utilities LP
is not installed on your system, continue by following the instructions in this
section to perform the installation.
Installing TCP/IP on your AS/400 allows you to connect an AS/400 to a network.
Chapter 2. Configuring TCP/IP
23
Perform the following steps to install TCP/IP on your AS/400 system:
1. Insert your installation media for TCP/IP into your AS/400. If your installation
media is a CD-ROM, insert it into your optical device. If your installation media
is a tape, insert it into your tape drive.
2. Type GO LICPGM at the command prompt and press Enter to access the Work
with Licensed Programs display.
3. Select option 11 (Install licensed programs) on the Work with Licensed
Programs display to see a list of licensed programs and optional parts of
licensed programs.
4. Type 1 in the option column next to 5769TC1 TCP/IP Connectivity Utilities for
AS/400 licensed program. The Confirm Licensed Programs to Install display
shows the licensed program you selected to install. Press Enter to confirm.
5. Fill in the following choices on the Install Options display:
v Installation Device
Type OPT01, if installing from a CD drive.
Type TAP01, if installing from a tape drive.
v Objects to Install
The Objects to Install option allows you to install both programs and
language objects, only programs, or only language objects.
v Automatic IPL
The Automatic IPL option determines whether the system automatically starts
when the installation process has completed successfully.
When TCP/IP successfully installs, either the Work with Licensed Programs
menu or the Sign On display appears.
Note: For more detailed information about installing software, including
objects to install and the automatic IPL option, refer to the Software
Installation, SC41-5120-03 book.
6. Select option 50 (Display log for messages) to verify that you have installed the
licensed program successfully. If an error occurs, you will see the message Work
with licensed program function not complete on the bottom of the Work with
Licensed Programs display.
To use TCP/IP, you must configure it after you have completed the installation. See
“Configuring TCP/IP using the Command Line Interface” on page 29.
TCP/IP Addressing
TCP/IP addressing uses a unique Internet Protocol (IP) address for a specific node
in a TCP/IP network. Each node on a network is known as a host and has a unique
address.
You can assign your own addresses within your own network. To connect to the
Internet, the InterNIC assigns your network addresses and domain names. For
more information about how to contact the InterNIC registration services, see
Table 1 on page 4.
TCP/IP addressing is comprised of two parts: The TCP/IP address itself and the
subnet mask. The TCP/IP address is a 32-bit integer that contains both a network
portion and a host portion. This address is usually expressed in the decimal form
24
OS/400 TCP/IP Configuration and Reference V4R4
xxx.xxx.xxx.xxx, where xxx is an integer between 0 and 255. The subnet mask is a
bit mask that determines which bits in the TCP/IP address designate the network
versus the host part of the address.
IP protocol works closely with the network and host portions of the address as well
as the subnet mask.
TCP/IP addressing reflects your licensing and networking needs. The size of your
network is the starting point for determining your TCP/IP addressing.
The following TCP/IP example is based on six existing networks you might have in
your company:
v Network 1 needs 100 IP addresses.
v Network 2 needs 90 IP addresses.
v
v
v
v
Network
Network
Network
Network
3
4
5
6
needs
needs
needs
needs
40
50
50
50
IP
IP
IP
IP
addresses.
addresses.
addresses.
addresses.
For this example, if you are going to use class C addressing, you need to have two
class C addresses. You could use Networks 1 and 2 for one class C address and
Networks 3, 4, 5, and 6 for the other class C address. This arrangement allows for
future expansion of the networks.
Continuing with this example, assume that the class C addresses are 192.1.1.x and
192.1.2.x. Here is how TCP/IP addressing could work in this example:
Network 1:
Network: 192.1.1.0
Subnet mask: 255.255.255.128
Usable range of IP addresses for hosts: 192.1.1.1 through
192.1.1.126.
Network 2:
Network: 192.1.1.128
Subnet mask: 255.255.255.128
Usable range of IP addresses for hosts: 192.1.1.129 through
192.1.1.254.
Network 3:
Network: 192.1.2.0
Subnet mask: 255.255.255.192
Usable range of IP addresses for hosts: 192.1.2.1 through
192.1.2.62.
Network 4:
Network: 192.1.2.64
Subnet mask: 255.255.255.192
Usable range of IP addresses for hosts: 192.1.2.65 through
192.1.2.126.
Network 5:
Network: 192.1.2.128
Subnet mask: 255.255.255.192
Usable range of IP addresses for hosts: 192.1.2.129 through
192.1.2.190.
Network 6:
Chapter 2. Configuring TCP/IP
25
Network: 192.1.2.192
Subnet mask: 255.255.255.192
Usable range of IP addresses for hosts: 192.1.2.193 through
192.1.2.254.
The domain name for the entire network could be xyz.com. Lower-level domain
names could be group1.xyz.com for Networks 1 and 2 and group2.xyz.com for
Networks 3, 4, 5, and 6. In this example, only the local routers know that the
networks are actually different, physical networks.
Note: If you need further assistance with planning for TCP/IP addressing, refer to
RFC 1219, On the Assignment of Subnet Numbers.
Using the TCP/IP Administration Menu
The TCP/IP Administration menu (Figure 9) is a starting point for the configuration
tasks. To display the menu, enter GO TCPADM from the AS/400 Main Menu.
TCPADM
TCP/IP Administration
Select one of the following:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
System:
RC
Configure TCP/IP
Configure TCP/IP applications
Start TCP/IP
End TCP/IP
Start TCP/IP servers
End TCP/IP servers
Work with TCP/IP network status
Verify TCP/IP connection
Start TCP/IP FTP session
Start TCP/IP TELNET session
Send TCP/IP spooled file
20. Work with TCP/IP jobs in QSYSWRK subsystem
Selection or command
===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
Figure 9. TCP/IP Administration Menu
Following are descriptions of the menu options.
v Option 1. Configure TCP/IP: Displays the Configure TCP/IP menu. Use the
options on this menu to configure your local AS/400 system to communicate with
other systems in a TCP/IP network.
v Option 2. Configure TCP/IP applications: Displays the Configure TCP/IP
Applications menu. Use the options on this menu to configure the TCP/IP
licensed program (5769-TC1) applications installed on your system.
v Option 3. Start TCP/IP: Select this option to issue the Start TCP/IP (STRTCP)
command. This command initializes and activates TCP/IP processing, starts the
TCP/IP interfaces, and starts the TCP/IP server jobs.
v Option 4. End TCP/IP: Select this option to issue the End TCP/IP (ENDTCP)
command. This command is used to end all TCP/IP processing on this system.
26
OS/400 TCP/IP Configuration and Reference V4R4
v Option 5. Start TCP/IP servers: Select this option to issue the Start TCP/IP
Server (STRTCPSVR) command. This command is used to start the TCP/IP
application servers that are shipped with OS/400 or the TCP/IP licensed program
(5769-TC1). This command starts the TCP/IP application server jobs in the
QSYSWRK subsystem.
v Option 6. End TCP/IP servers: Select this option to issue the End TCP/IP
Server (ENDTCPSVR) command. This command is used to end the TCP/IP
application servers that are shipped with OS/400 or the TCP/IP licensed program
(5769-TC1). This command ends the TCP/IP application server jobs in the
QSYSWRK subsystem.
v Option 7. Work with TCP/IP network status: Select this option to issue the
Work with TCP/IP Network Status (WRKTCPSTS) command. This command is
used to view and manage the status information of your TCP/IP and IP over
Systems Network Architecture (SNA) interfaces, routes, and connections. This
command is the AS/400 version of the TCP/IP NETSTAT (Network Status)
command. NETSTAT is also shipped as an AS/400 command.
v Option 8. Verify TCP/IP connection: Select this option to issue the Verify
TCP/IP Connection (VFYTCPCNN) command. This command tests the TCP/IP
connection between your system and a remote system. The VFYTCPCNN
command is the AS/400 version of the TCP/IP PING (Packet InterNet Groper)
command. PING is also shipped as an AS/400 command.
v Option 9. Start TCP/IP FTP session: Select this option to issue the Start
TCP/IP FTP (STRTCPFTP) command. This command is used to start a file
transfer using TCP/IP. This command is the AS/400 version of the TCP/IP FTP
(File Transfer Protocol) command. FTP is also shipped as an AS/400 command.
v Option 10. Start TCP/IP TELNET session: Select this option to issue the Start
TCP/IP TELNET (STRTCPTELN) command. This command is used to start a
TELNET client session with a remote system. This command is the AS/400
version of the TCP/IP TELNET command. TELNET is also shipped as an AS/400
command.
v Option 11. Send TCP/IP spooled file: Select this option to issue the Send
TCP/IP Spooled File (SNDTCPSPLF) command. This command sends a spooled
file to be printed on a remote system. The remote system must be running
TCP/IP. The SNDTCPSPLF command is the AS/400 version of the TCP/IP LPR
(line printer requester) command. LPR is also shipped as an AS/400 command.
v Option 20. Work with TCP/IP jobs in QSYSWRK subsystem: Select this
option to work with the status and performance information for the active TCP/IP
jobs in the QSYSWRK subsystem. This option issues the Work with Active Jobs
(WRKACTJOB) command with these parameters:
WRKACTJOB SBS(QSYSWRK) JOB(QT*)
Using the Configure TCP/IP Menu
The Configure TCP/IP menu is shown here (Figure 10 on page 28) so that you are
familiar with all of the options available during configuration of the TCP/IP network.
To get to this menu, select option 1 on the TCPADM menu or enter the Configure
TCP/IP (CFGTCP) command.
Chapter 2. Configuring TCP/IP
27
CFGTCP
Configure TCP/IP
Select one of the following:
1.
2.
3.
4.
5.
System:
SYSNAM890
Work with TCP/IP interfaces
Work with TCP/IP routes
Change TCP/IP attributes
Work with TCP/IP port restrictions
Work with TCP/IP remote system information
10. Work with TCP/IP host table entries
11. Merge TCP/IP host table
12. Change TCP/IP domain information
20. Configure TCP/IP applications
21. Configure related tables
22. Configure point-to-point TCP/IP
Selection or command
===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
Figure 10. Configure TCP/IP Menu
Following are descriptions of the Configure TCP/IP menu options.
v Option 1. Work with TCP/IP interfaces: Select this option to add TCP/IP
interface information to the list of current interfaces or to display, change, print, or
remove TCP/IP interface information that you have already added. Select this
option to start or end a TCP/IP interface.
v Option 2. Work with TCP/IP routes: Select this option to add route information
or to display, change, print, or remove route information that you have already
added.
v Option 3. Change TCP/IP attributes: Select this option to run the Change
TCP/IP Attributes (CHGTCPA) command.
With this option you can change User Datagram Protocol (UDP) checksum
processing, IP datagram forwarding, IP time-to-live values, and other attributes
that relate to the TCP/IP protocol stack.
v Option 4. Work with TCP/IP port restrictions: Select this option to add port
restrictions or to display, remove, or print port restrictions that you have already
added.
v Option 5. Work with TCP/IP remote system information: Select this option to
add or remove X.25 data network addresses or to print the list.
v Option 10. Work with TCP/IP host table entries: Select this option to add host
IP addresses and their associated host names to the host table or to display,
change, print, rename, or remove items that you have already added.
v Option 11. Merge TCP/IP host table: Select this option to merge or replace a
local host table by using the Merge TCP/IP Host Table (MRGTCPHT) command.
v Option 12. Change TCP/IP domain information: Select this option to change
TCP/IP domain information.
Note: Prior to Version 4 Release 2, the Configure TCP/IP menu contained both
an option 12 and an option 13. In Version 4 Release 2, the functions of
options 12 and 13 were combined, and option 13 (Change Remote name
28
OS/400 TCP/IP Configuration and Reference V4R4
server) was removed from the menu. Option 12, formerly Change local
domain and host names, was renamed to Change TCP/IP domain
information.
v Option 20. Configure TCP/IP applications: Select this option to configure the
TCP/IP applications that are installed on your system. The list of applications
varies depending on whether the TCP/IP licensed program is installed on your
system. If the TCP/IP licensed program is not installed on your system, you can
configure only the following server applications:
– Simple Network Management Protocol (SNMP)
– Bootstrap Protocol (BOOTP) server
– Trivial File Transfer Protocol (TFTP) server
– Route Daemon (RouteD)
If the TCP/IP licensed program is installed on your system, you can configure the
following server applications:
– Simple Mail Transfer Protocol (SMTP)
– File Transfer Protocol (FTP), TELNET
– Post Office Protocol (POP) Version 3 mail server
– Line Printer Daemon (LPD)
– Remote Execution (REXEC) server
– Workstation gateway applications
– Simple Network Management Protocol (SNMP)
For information about configuring SNMP, see the Simple Network Management
Protocol (SNMP) Support book.
v Option 21. Configure related tables: Select this option to configure the tables
related to TCP/IP. These tables are:
– Protocol table
Contains a list of protocols used in the Internet.
– Services table
Contains a list of services and the specific port and protocol a service uses.
– Network table
Contains a list of networks and the corresponding IP addresses for that
network.
v Option 22. Configure point-to-point TCP/IP: Select this option to define,
change, or display your TCP/IP point-to-point (SLIP) configuration.
Configuring TCP/IP using the Command Line Interface
The following steps using the command line interface will guide you through
configuring TCP/IP on your AS/400 system:
1. Configuring line descriptions
2. Configuring TCP/IP interfaces
3. Configuring TCP/IP routes
4. Configuring TCP/IP attributes
5. Configuring remote system information (X.25)
6. Configuring host table entries
Chapter 2. Configuring TCP/IP
29
Note: For information about using a DNS server to manage entries, in place
of host tables, refer to 421.
7. Configuring local domain and host name
8. Starting TCP/IP
9. Verifying TCP/IP connection
10. Saving the TCP/IP configuration
Important Note:
To perform the configuration steps discussed throughout this chapter, you
need the special authority of *IOSYSCFG defined in your user profile.
Step 1—Configuring a Line Description
AS/400 TCP/IP supports various local area network (LAN) and wide area network
(WAN) connection types: Ethernet, token-ring, SDDI and FDDI, wireless LAN, X.25
SVC, and permanent virtual circuit (PVC), Async (for SLIP), Point-to-Point (PPP)
and frame relay. Refer to Appendix A. Configuring a Physical Line for TCP/IP
Communication for information about how to configure an Ethernet line for TCP/IP
communications.
These are the important parameters for configuring a line description:
v Line description name
v Resource name
v Local adapter address
v Ethernet standard
v Source service access point (SSAP) list.
The SSAP X'AA' required for an IEEE 802.3 Ethernet is automatically allocated if
you use the *SYSGEN special value.
When TCP/IP starts an interface, the line, controller, and device descriptions are
varied on automatically. If the controller and device descriptions for a line do not
exist, TCP/IP creates them automatically when it attempts to start an interface using
that line. This happens at TCP/IP startup time if the TCP/IP interface that is
associated with the newly configured line is set to AUTOSTART *YES.
Step 2—Configuring a TCP/IP Interface
In an AS/400 system, each line that connects to a TCP/IP network must be
assigned to at least one Internet address. You do this by configuring, or adding a
TCP/IP interface. The additional interfaces are logical interfaces, not physical ones.
These logical interfaces are associated with a line description.
An interface identifies a direct connection to a network using TCP/IP and a physical
medium (communications line). You must consider the following when defining an
interface:
Internet address
A 32-bit address assigned to hosts using TCP/IP. It is associated with the
line description.
30
OS/400 TCP/IP Configuration and Reference V4R4
Subnet mask
Defines which part of an Internet address forms the subnet (subnetwork)
field of an Internet address. An example of a single-network subnet mask is:
255.255.255.128.
Line description
Contains information describing a communications line that is attached to
the AS/400 system, as defined previously in “Step 1—Configuring a Line
Description” on page 30.
To find the names of the currently defined line descriptions, use the Work
with Line Descriptions (WRKLIND) command.
Associated local interface
Allows the network to which this interface is attached appear to be part of
the same network that the associated local interface is attached to. This is
referred to as transparent subnetting.
Transparent subnetting allows TCP/IP traffic to flow between the two
physical networks without defining additional routing. This is only valid for
broadcast-capable networks. This also requires the Internet address for Add
TCP/IP Interface (ADDTCPIFC) to be configured in the same network as
the associated local interface. An additional requirement is for the subnet
mask that is defined for the associated local interface.
Automatic start
Refers to whether the TCP/IP interface is started automatically whenever
TCP/IP is started. The default setting is *YES. If you choose *NO, you must
start the interface yourself by using the STRTCPIFC command or by
selecting option 9 (Start) on the Work with TCP/IP Interfaces display, as
shown in Figure 12 on page 32.
To add a TCP/IP interface, do the following:
1. Enter GO TCPADM to get the TCP/IP Administration menu.
2. Select option 1 to get to the Configure TCP/IP menu.
3. Select option 1 on the Configure TCP/IP menu.
The Work with TCP/IP Interfaces display is shown in Figure 12 on
page 32.
4. Type option 1 (Add) at the input-capable top list entry on this display to
go to the Add TCP/IP Interfaces (ADDTCPIFC) display, as shown in
Figure 11 on page 32.
(You can go directly to this display by typing ADDTCPIFC command on
any command line and pressing F4.)
AS/400 TCP/IP supports multihoming, which allows you to specify multiple
interfaces for each line description. For example, multihoming can be used to
assign multiple Internet addresses to a single physical line description. See
“Multihoming Function” on page 79 for further information.
Chapter 2. Configuring TCP/IP
31
Add TCP/IP Interface (ADDTCPIFC)
Type choices, press Enter.
Internet address . . . . . . . .
Line description . . . . . . . .
Subnet mask . . . . . . . . . .
Associated local interface . . .
Type of service . . . . . . . .
Maximum transmission unit . . .
Autostart . . . . . . . . . . .
PVC logical channel identifier
+ for more values
X.25 idle circuit timeout . . .
X.25 maximum virtual circuits .
X.25 DDN interface . . . . . . .
TRLAN bit sequencing . . . . . .
F3=Exit
F4=Prompt
F24=More key
F5=Refresh
Name, *LOOPBACK, *VIRTUALIP
*NONE
*NORMAL
*LIND
*YES
*MINDELAY, *MAXTHRPUT...
576-16388, *LIND
*YES, *NO
001-FFF
60
64
*NO
*MSB
1-600
0-64
*YES, *NO
*MSB, *LSB
F12=Cancel
Bottom
F13=How to use this display
Figure 11. Add TCP/IP Interfaces Display
When you are finished adding entries, the Work with TCP/IP Interfaces display
looks like Figure 12.
Work with TCP/IP Interfaces
Type options, press Enter.
1=Add
2=Change 4=Remove
Opt
-
5=Display
9=Start
System:
SYSNAM890
10=End
Internet
Address
Subnet
Mask
Line
Description
Line
Type
9.4.73.129
255.255.255.128
ETHLINE
*ELAN
Figure 12. Work with TCP/IP Interfaces Display
Note: Any change to the TCP/IP interfaces configuration, except for the automatic
start parameter, takes effect immediately.
Step 3—Configuring TCP/IP Routes
Do you need to add routes at all?
If you have several individual networks to which the AS/400 is not directly
attached, you must add routing entries to allow the AS/400 to reach these
remote networks.
If your AS/400 is attached to a single network, if there are no IP routers in
your network, you do not need to add routes.
To reach remote networks, at least one routing entry is required. If no routing
entries are manually added, your AS/400 cannot reach systems that are not on the
32
OS/400 TCP/IP Configuration and Reference V4R4
same network that the AS/400 is attached to. You must also add routing entries to
allow TCP/IP clients that are attempting to reach your AS/400 system from a remote
network to function correctly.
For example, suppose that someone using a PC is using the TELNET application to
start a remote terminal session on your AS/400 system. The application on the PC
must know the route or path to reach the AS/400 system. Your AS/400 system must
also be able to determine the route back to the PC. If the PC and your AS/400
system are not on the same network, a routing entry must exist on the PC and on
AS/400.
Note: You should plan to have the routing table defined so that there is always an
entry for at least one default route (*DFTROUTE). If there is no match on
any other entry in the routing table, data is sent to the IP router specified by
the first available default route entry. The only exception to this is if you
intend to dial out over a SLIP link to an Internet Service Provider or another
remote host. See “Using SLIP with an Asynchronous Line Description” on
page 126 for details.
Before adding routing entries, familiarize yourself with the following terms:
Route destination
The network ID portion of an Internet address. The network ID portion is
composed of the first byte, the first two bytes, or the first three bytes of the
Internet address (depending on the network class). The remaining bytes
define the host ID portion of the Internet address.
If subnetting is used, route destination includes the subnet part as well. In
other words, the route destination equals the address of a TCP/IP
network to be reached.
Subnet mask
A bit mask that defines which part of an Internet address forms the network
and the subnetwork.
The technique known as subnet addressing, subnet routing, or
subnetting allows a single network ID to be used on multiple physical
networks. This technique lets you define separate routes to different sets of
Internet addresses within a specific network.
For more information about subnet masks and subnetworks, refer to
“Subnetworks and Subnet Masks” on page 6.
Next hop
The Internet address of the first system in the route between your system
and the destination network. The next hop value is always an Internet
address. Next hops need to be hosts on a directly connected TCP/IP
network defined by the TCP/IP interfaces.
Maximum Transmission Unit (MTU) size
The maximum size (in bytes) of IP datagrams sent on a route. If you specify
*IFC, the size is calculated for you based on values found in the AS/400
line description. The maximum size specified for a particular route must not
be larger than the smallest MTU supported by any router or bridge in that
route. If you specify a larger size, some datagrams may be lost.
In addition, the MTU specified for a particular route should not be larger
than the smallest MTU supported by any system used as an IP router for
that route. If you specify a larger size, performance may degrade as
systems attempt to divide the IP datagrams into smaller fragments.
Chapter 2. Configuring TCP/IP
33
For additional information about setting the MTU, see Appendix A.
Configuring a Physical Line for TCP/IP Communication.
Preferred binding interface
The preferred binding interface allows administrators to choose which of the
TCP/IP interfaces that they prefer the route to be bound to or on. This
provides the administrator with more flexibility to route traffic over a specific
interface. The interface is preferred because the route is bound to the
indicated interface if the interface is active. If the indicated interface is not
active, then a best-match-first algorithm is used in determining which
interface the route is bound.
In Figure 13, a preferred binding interface of *NONE has been defined. By
using this definition, the user allows the TCP/IP protocol stack to choose an
interface to bind this route to, using a best-match-first algorithm.
Adding TCP/IP routes
You must define routes for any TCP/IP network, including subnetworks, with
which you want to communicate. You do not need to define routes for the
TCP/IP network that your AS/400 system is directly attached to when you
are using an AS/400 adapter.
Manual configuration of the routes that tell TCP/IP how to reach the local
networks is not required. AS/400 TCP/IP generates these routes
automatically from the configuration information for the interfaces every time
TCP/IP is started. In other words, the direct route to the network, which has
an interface attached, is automatically created when you add the interface.
To display all routing entries, including direct routes, use the Network Status
(NETSTAT) command after starting TCP/IP.
To add a route, type option 2 on the Configure TCP/IP menu. The Work
with TCP/IP Routes display (Figure 13) is shown.
Work with TCP/IP Routes
Type options, press Enter.
1=Add
2=Change
4=Remove
System:
SYSNAM890
5=Display
Route
Subnet
Opt Destination
Mask
_
________________ _______________
_
*DFTROUTE
*NONE
Next
Hop
_______________
9.4.73.193
Preferred
Interface
*NONE
Figure 13. Work with TCP/IP Routes Display
Type option 1 (Add) at the input-capable top list entry on that display to go
to the Add TCP/IP Route (ADDTCPRTE) display, as shown in Figure 14 on
page 35.
(To go directly to this display, type the ADDTCPRTE command on any
command line and press F4.)
34
OS/400 TCP/IP Configuration and Reference V4R4
Add TCP/IP Route (ADDTCPRTE)
Type choices, press Enter.
Route destination . . . . .
Subnet mask . . . . . . . .
Type of service . . . . . .
Next hop . . . . . . . . . .
Preferred binding interface
Maximum transmission unit .
Route metric . . . . . . . .
Route redistribution . . . .
Duplicate route priority . .
F3=Exit
F4=Prompt
F24=More keys
.
.
.
.
.
.
.
.
.
. > '9.4.6.128'
. > '255.255.255.128'
. *NORMAL
*MINDELAY, *MAXTHRPUT...
. > '9.4.73.193'
.
*NONE
.
576
576-16388, *IFC
.
1
1-16
.
*NO
*NO, *YES
.
5
1-10
F5=Refresh
F12=Cancel
Bottom
F13=How to use this display
Figure 14. Add TCP/IP Routes Display
Note: Any changes that you make to the routing information take effect
immediately.
Work with TCP/IP Routes
Type options, press Enter.
1=Add
2=Change
4=Remove
5=Display
Opt
_
_
_
Route
Destination
________________
*DFTROUTE
9.4.6.128
Subnet
Mask
_______________
*NONE
255.255.255.128
Next
Hop
_______________
9.4.73.193
9.4.73.193
Preferred
Interface
*NONE
Figure 15. Work with TCP/IP Routes Display
Multiple Default Routes
Default routes are used to route data that is being addressed to a remote
destination and that does not have a specific route defined. Default routes
are based on the availability of the next hop router and the type of service
(TOS). If no specific TOS is requested, the first available default route with
TOS of *NORMAL is used.
If a default route is not defined, only the networks explicitly defined by any
non-default routes appear as though TCP/IP can reach them, and
datagrams bound for any undefined networks are not sent.
Note: A default route cannot have a subnetwork; therefore, you must leave
the subnet mask at the default value of *NONE.
Consult “Multiple Routes” on page 84 for further information about multiple
default routes and the type of service (TOS) parameter.
Chapter 2. Configuring TCP/IP
35
Step 4—Configuring TCP/IP attributes
To configure the TCP/IP attributes, type option 3 on the Configure TCP/IP menu.
The Change TCP/IP Attributes (CHGTCPA) display is shown (Figure 16).
Change TCP/IP Attributes (CHGTCPA)
Type choices, press Enter.
TCP keep alive . . . . .
TCP urgent pointer . . .
TCP receive buffer size
TCP send buffer size . .
UDP checksum . . . . . .
IP datagram forwarding .
IP source routing . . .
IP reassembly time-out .
IP time to live . . . .
ARP cache timeout . . .
Log protocol errors . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
120
*BSD
8192
8192
*YES
*YES
*YES
10
64
5
*YES
1-40320, *SAME, *DFT
*SAME, *BSD, *RFC
512-8388608, *SAME, *DFT
512-8388608, *SAME, *DFT
*SAME, *YES, *NO
*SAME, *YES, *NO
*SAME, *YES, *NO
5-120, *SAME, *DFT
1-255, *SAME, *DFT
1-1440, *SAME, *DFT
*SAME, *YES, *NO
Figure 16. Change TCP/IP Attributes Display
For information about the various parameters for this command, see the online
help. In this step only the IP Datagram Forwarding (IPDTGFWD) parameter is
discussed.
IP Datagram Forwarding
Specifies whether your system should forward datagrams destined for other
networks. The default value is *NO.
Step 5—Configuring TCP/IP Remote System Information (X.25)
Note: If you are not using use X.25, then proceed to “Step 6—Configuring TCP/IP
Host Table Entries” on page 38.
If you use an X.25 connection to reach TCP/IP hosts with a public or private packet
switched data network (PSDN), you need to add remote system information for
each remote TCP/IP host. You must define the X.25 network address of each
system if you use a switched virtual circuit (SVC). If a permanent virtual circuit
(PVC) is set up by the network connecting your system with your remote TCP/IP
partner, you need to know the local logical channel identifier of this PVC.
Adding Remote System Information (X.25)
To add an X.25 remote system address, type option 5 on the Configure
TCP/IP menu. The Work with the TCP/IP Remote System Information
display appears, as shown in Figure 17 on page 37.
36
OS/400 TCP/IP Configuration and Reference V4R4
Work with TCP/IP Remote System Information
Type options, press Enter.
1=Add
4=Remove
5=Display
Opt
_
Internet
Address
_______________
Network
Address
PVC
System: SYSNAM890
Reverse
Charges
(No remote system information)
Figure 17. Work with Remote System (X.25) Information
Type option 1 (Add) at the input-capable top list entry to go to the Add TCP/IP
Remote System (ADDTCPRSI) display, as shown in Figure 18.
Add TCP/IP Remote System (ADDTCPRSI)
Type choices, press Enter.
Internet address . . . . . . . . > '9.4.73.66'
Network address . . . . . . . . > 40030002
PVC logical channel identifier
X.25 reverse charge . . . . . . *NONE
001-FFF
*NONE, *REQUEST, *ACCEPT
Additional Parameters
Default packet size:
Transmit packet size
Receive packet size
Default window size:
Transmit window size
Receive window size
F3=Exit
F4=Prompt
F24=More keys
. . . . .
. . . . .
*LIND
*LIND
*LIND, 64, 128, 256, 512...
*LIND, *TRANSMIT, 64, 128...
. . . . .
. . . . .
*LIND
*LIND
1-15, *LIND
1-15, *LIND, *TRANSMIT
F5=Refresh
F12=Cancel
Bottom
F13=How to use this display
Figure 18. Add Remote System (X.25) Information
The network controller used by AS/400 TCP/IP does not allow you to specify X.25
user facilities. However, some of the values usually configured on a controller, using
the ADDTCPRSI command, allow you to configure each X.25 remote system.
These values include reverse charging, packet sizes, and window sizes.
Use the following CL command is used to enter the information as shown in the
display above:
ADDTCPRSI INTNETADR('9.4.73.66')
NETADR(40030002)
Notes:
1. Specifying remote system information for an X.25 DDN interface causes that
information to be used instead of the DDN conversion algorithm. The DDN
conversion algorithm is used only for a connection with DDN specified as *YES
when you try to connect to a host that is not defined in the remote system
Chapter 2. Configuring TCP/IP
37
information. If DDN is specified as *YES on the X.25 connection, you should not
specify remote system information for that interface or its associated DDN
network systems.
2. A routing error occurs when both of the following are true:
v The remote system information associated with the Internet address is an
extended data terminal equipment (DTE) address.
v The configured X.25 interface’s line does not support X.25 extended
addressing.
Note: Any changes that you make to the remote system information take effect
immediately.
Step 6—Configuring TCP/IP Host Table Entries
Each computer system in your network is called a host. The host table allows you
to associate a host name to an Internet address. This step gives instruction for
configuring a host table and host table entries. However, you should determine
early in the configuration planning if a host table or a Domain Name System (DNS)
server is the best option for you in managing host name and IP address
translations.
Whenever possible, a DNS server should be used as a replacement for, or in
addition to, the local host table. The DNS server is a single source for host names,
which is one reason that it is often preferred over host tables, especially for larger
networks. For more information about DNS server support for your AS/400 system,
see “Chapter 18. AS/400 Domain Name System (DNS)” on page 421.
The local host table on your AS/400 system contains a list of the Internet addresses
and related host names for your network. Host tables map Internet addresses to
TCP/IP host names. Host tables allow users to use an easily remembered name for
a system in a network without having to remember the Internet address.
To configure the mapping of host names to Internet addresses, you can use three
different options on the Configure TCP/IP menu. You can use only one or a
combination of all three to obtain the host name processing you need for your
network. The three options on the Configure TCP/IP menu related to Internet
address mappings are:
1. Option 10 (Work with TCP/IP host table entries) to create your own host table.
The Work with Host Table Entries display is shown in Figure 19 on page 39.
2. Option 11 (Merge TCP/IP host table) to merge or convert a host table sent from
another system.
For more information about merging and converting host tables, see “Merging
TCP/IP Host Tables” on page 75.
3. Option 12 (Change TCP/IP domain information) to call the following new
command, CHGTCPDMN.
Note: You can start TCP/IP client functions, such as FTP, by specifying the Internet
address directly without using the host table.
For more information about managing host tables, including host file formats, and
merging host tables, see “Managing TCP/IP Host Tables” on page 73.
38
OS/400 TCP/IP Configuration and Reference V4R4
Adding an Entry to the Host Table
The Add TCP/IP Host Table Entry display provides fields for an Internet address,
associated host name, and an optional text description.
To add an entry to your local host table, type option 10 on the Configure TCP/IP
menu. The Work with TCP/IP Host Table Entries display is shown in Figure 19.
Work with TCP/IP Host Table Entries
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
_
_
Internet
Address
_______________
127.0.0.1
5=Display
System: SYSNAM890
7=Rename
Host
Name
LOOPBACK
LOCALHOST
Figure 19. Work with TCP/IP Host Table Entries Display
Note: Just as AS/400 TCP/IP automatically creates a LOOPBACK interface, it also
automatically adds an entry to your local host table to associate the IP
address 127.0.0.1 with the host names LOOPBACK and LOCALHOST. Type
option 1 (Add) at the input-capable top list entry to show the Add TCP/IP
Host Table Entry display.
Work with TCP/IP Host Table Display
Figure 20 and Figure 21 on page 40 show how the host table looks after you enter
all hosts explicitly known.
Work with TCP/IP Host Table Entries
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
_
_
_
_
_
_
_
_
_
_
_
_
_
_
Internet
Address
_______________
9.4.6.129
9.4.6.134
9.4.6.138
9.4.6.252
9.4.73.65
9.4.73.66
9.4.73.129
9.4.73.130
9.4.73.193
9.4.73.198
9.4.73.206
9.4.73.207
9.4.73.208
5=Display
System:
SYSNAM890
7=Rename
Host
Name
ROUTER2
HPUX
SPARKY
MVAX
XSYSNAM890
XSYSNAM456
ESYSNAM890
ESYSNAMRS
ROUTER1
SYSNAMRS
ITALY
HOLLAND
ENGLAND
More...
Figure 20. Work with Host Table Entries, Display 1 of 2
Chapter 2. Configuring TCP/IP
39
Work with TCP/IP Host Table Entries
Type options, press Enter.
1=Add
2=Change 4=Remove
Opt
_
_
_
_
_
_
Internet
Address
_______________
9.4.73.211
9.4.73.212
9.4.73.214
9.4.191.76
127.0.0.1
5=Display
System:
SYSNAM890
7=Rename
Host
Name
BERN
SYSNAM890
MACIAN
DNS
LOOPBACK
LOCALHOST
Figure 21. Work with Host Table Entries, Display 2 of 2
The AS/400 TCP/IP host table is shipped with the LOOPBACK entry. The
LOOPBACK entry has an Internet address of 127.0.0.1 and two host names:
LOOPBACK and LOCALHOST.
The 127.0.0.1 Internet address can be changed (CHGTCPHTE) and a different one
can be added (ADDTCPHTE). The local table command processing programs
ensure that any LOOPBACK host name added or changed in the host table is in
the range of 127.0.0.1 to 127.255.255.254. Multiple loopback host table entries are
allowed in the AS/400 host table.
You may alter the LOOPBACK host name or add additional host names using the
(CHGTCPHTE) command.
If the LOOPBACK or LOCALHOST name is changed or removed from the host
table, the name is not valid, unless the domain name server has a LOOPBACK
entry that specifies this value as a host name.
You can define up to four names for each Internet address. If the TCP/IP host is in
your local domain, then it is not necessary to qualify the host with the domain
name. As long as a TCP/IP host is in your local domain, you need only to enter the
host name with the host table entry.
However, if you would like to add TCP/IP hosts that are outside of your local
domain, you need to add these TCP/IP hosts as fully qualified. The fully qualified
host name of SYSNAMEND.ENDICOTT.IBM.COM shows this as an example in Figure 22
on page 41.
40
OS/400 TCP/IP Configuration and Reference V4R4
Work with TCP/IP Host Table Entries
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
_
_
_
_
_
_
_
Internet
Address
_______________
9.4.73.211
9.4.73.212
9.4.73.214
9.4.191.76
9.125.87.127
127.0.0.1
5=Display
System:
SYSNAM890
7=Rename
Host
Name
BERN
SYSNAM890
MACIAN
DNS
SYSNAMEND.ENDICOTT.IBM.COM
LOOPBACK
LOCALHOST
Figure 22. Example of a Fully Qualified Host Table Entry
Additional host names are useful as alternative nicknames. See the examples in
Figure 23.
Host names need not be unique. When searching the host table with a duplicate
host name, the result is random. However, IP addresses have to be unique. The
uniqueness of the IP address is enforced at the time you try to add a new entry to
the host table.
Note: An IP address cannot be used as a host name.
Work with TCP/IP Host Table Entries
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
_
_
_
_
_
_
5=Display
System:
SYSNAM890
7=Rename
Internet
Host
Address
Name
_______________
9.4.73.211
BERN
9.4.73.212
SYSNAM890
M03
F25
MYSYSTEM
9.4.73.214
MACIAN
9.4.191.76
DNS
9.4.73.198
SYSNAMRS
Figure 23. Multiple Host Names
To remove one of the additional host names, select option 2 to change the selected
host table entry. Type *BLANK over the host name to remove it.
Note: The fully qualified host name is used when sending mail between two
TCP/IP hosts.
Notice in the example that the name of AS/400 system SYSNAM890 is in the host
table too. There are several reasons to put your host name in the host table:
v You may want to use your host name when using FTP, TELNET, or PING to test
your own system’s configuration.
Chapter 2. Configuring TCP/IP
41
v Simple Mail Transfer Protocol (SMTP) requires your host name to be in the host
table or on a domain name server.
v You may want to use your host table on other systems in the network. Your host
name must be in the host table on those systems so they can refer to your
system by name.
v Applications written to use host table lookup routines may require this
information.
When you are finished working with the host table, press F3 (Exit) or F12 (Cancel).
AnyNet/400: APPC over TCP/IP
Advanced program-to-program communication (APPC) over TCP/IP support allows
Common Programming Interface (CPI) Communications or Intersystem
Communications Function (ICF) applications to run over TCP/IP with no changes.
To use the APPC over TCP/IP support, the logical unit (LU) name or the remote
location that your application uses must be mapped to an Internet address. For
APPC over TCP/IP support, the host table is configured to map Internet addresses
to LU names. To do this, you can update the TCP/IP host table using the
configuration menus. The format for the host name is:
LUNAME.NETID.SNA.IBM.COM
Step 7—Configuring the Local Domain and Host Name
Within TCP/IP, the primary name associated with your system (your system can
have more than one name) is called your local domain and host name. The
combination of the local domain and host name forms a fully-qualified host name.
The fully qualified host name is the name by which your system is known and
identified in the TCP/IP domain. The local domain name is also used by sockets to
help in host name resolution at the Domain Name System (DNS) server. The Post
Office Protocol (POP) and Simple Mail Transfer Protocol (SMTP) mail servers
require that the local domain and host name be configured. It is used, but not
required, by line printer requester (LPR), File Transfer Protocol (FTP), and Simple
Network Management Protocol (SNMP).
A domain name consists of labels that are separated by periods, for example,
SYSNAM890.ROCHESTER.IBM.COM. For hosts, the first label in a domain name
is the name of a host that belongs in the domain identified by the other labels. In
this example, host SYSNAM890 belongs to the domain ROCHESTER.IBM.COM.
SYSNAM890.ROCHESTER.IBM.COM is known as the host’s fully qualified domain
name.
To define a local domain name and a host name, use option 12 (Change TCP/IP
domain information) from the Configure TCP/IP menu (Figure 10 on page 28). Refer
to “Domain and Host Name” on page 9 for a more detailed discussion of domain
names.
You may need to configure the local domain name if you use a DNS server that
requires a fully qualified host name to resolve an Internet address. “Chapter 18.
AS/400 Domain Name System (DNS)” on page 421 provides more information on
how to do that.
The AS/400 TCP/IP applications concatenate the local domain name to the host
name if a period is not used at the end of the domain name. See “Concatenating
the Domain Name to the Host Name” on page 437 for an example.
42
OS/400 TCP/IP Configuration and Reference V4R4
To change the local domain name, type option 12 on the Configure TCP/IP menu.
The Change TCP/IP domain information display is shown in Figure 24.
Change TCP/IP Domain (CHGTCPDMN)
Type choices, press Enter.
Host name . . . . . . . . . . .
SYSNAM890
Domain name . . . . . . . . . .
SYSNAM123.IBM.COM
Host name search priority . . .
Domain name server:
Internet address . . . . . . .
*LOCAL
*REMOTE, *LOCAL, *SAME
'9.4.73.129'
Figure 24. Change TCP/IP Domain Information (CHGTCPDMN)
Notes:
1. Changes that you make using the Change TCP/IP domain information
(CHGTCPDMN) command take effect immediately.
2. The local domain name is used by many applications including PING. PING
appends the local domain to a host name if a domain is not specified or if a
period (.) does not appear at the end of the specified host name.
Domain Name System (DNS) Server
The conversion from host name to Internet address can be performed by using the
host table on the local system or by defining a Domain Name System server, or
DNS server.
In large networks with large host tables, it is more convenient to have DNS servers
than to have a complete copy of the host table on every host in the network.
A DNS server maintains the host table for an entire TCP/IP domain. This prevents
each single host from having to maintain its own local host table.
You can configure your AS/400 system to use both a DNS server and your local
host table, but they are not mutually exclusive. You can also specify whether the
domain name server or your local host table is searched first.
For more information about how the Domain Name System works and how to
configure a DNS server, see “Chapter 18. AS/400 Domain Name System (DNS)” on
page 421.
Step 8—Starting TCP/IP and TCP/IP Servers
Before any TCP/IP services are available on the AS/400 system, TCP/IP processing
must be initialized and activated. To start TCP/IP, you have two options:
1. Select option 3 from the TCP/IP Administration menu (GO TCPADM),
2. Enter the Start TCP/IP (STRTCP) command.
Chapter 2. Configuring TCP/IP
43
The STRTCP command initializes and activates TCP/IP processing, starts the
TCP/IP interfaces, and starts the TCP/IP server jobs. Only TCP/IP interfaces with
AUTOSTART *YES are started at STRTCP time. Allow a few moments for TCP/IP
to start, and then check to see if the QTCPIP job has started.
Option 20 of the TCP/IP Administration menu allows you to display the jobs related
with TCP/IP. You can also use the following command:
WRKACTJOB SBS(QSYSWRK) JOB(QT*)
The job QTCPIP should be displayed.
Messages indicating that TCP/IP has been started are sent to the QTCP and
QSYSOPR message queues. To check for the successful start of TCP/IP, enter
either of these commands:
DSPMSG QSYSOPR
DSPMSG QTCP
Figure 25 contains a sample of the messages that are issued.
STRTCP issued by job 007138/DJONES/DSP02.
QTCPIP job started.
127.0.0.1 interface started.
QTCPIP job starting 9.5.5.162 interface.
127.0.0.2 interface started.
SNMP Server starting.
TELNET Server starting
FTP Server starting
SMTP Server starting
POP Server starting
LPD Server starting
9.5.5.162 interface started.
STRTCP completed successfully.
Figure 25. Sample Messages from STRTCP with All Applications Autostarted
If the QTCPIP job does not start, look for spooled job logs. Generally, the user for
these job logs is QTCP. Use the Work with Spooled Files (WRKSPLF) command
and specify QTCP for the user (WRKSPLF QTCP) to find the logs.
Application Servers: The TCP/IP application server jobs run under subsystem
QSYSWRK. Several types of TCP/IP server jobs run in the QSYSWRK subsystem.
They are the server jobs for TELNET, POP, FTP, SMTP, LPD, BOOTP, TFTP,
RouteD, REXEC, and SNMP.
The STRTCP command starts the server jobs for an application if the automatic
start attribute for that server is equal to *YES. To change the autostart attribute for
an application, do either of the following:
v Select option 2 from the TCP/IP Administration menu
v Option 20 from the TCP/IP Configuration menu
Using the Start TCP/IP Server (STRTCPSVR) command starts the servers
individually or together. You can monitor the jobs with option 20 (Work with TCP/IP
jobs in QSYSWRK subsystem) from the TCP/IP Administration menu.
If you want TCP/IP processing and any related TCP/IP servers to start automatically
at the initial program load (IPL), add STRTCP to the QSTRUP CL program.
44
OS/400 TCP/IP Configuration and Reference V4R4
Note: If they are installed, the Client Access host servers are automatically started
when TCP/IP is started.
|
|
|
|
|
Changing the IPL Start-Up Program The autostart job in the controlling subsystem
transfers control to the program specified in the system value QSTRUPPGM. You
can tailor this program. For instructions on how to create your own IPL start-up
program, see the OS/400 Work Management book located in the AS/400 Online
Library at the following URL address: http://www.as400.ibm.com/infocenter.
REMINDER: Host Table Conversion: If you had a pre-V3R1M0 version of TCP/IP
installed on your AS/400 and you had a local host table with more than 75 entries,
use one of the host table configuration commands, such as CHGTCPHTE or
MRGTCPHT before you run the STRTCP command. Using the host table
configuration commands converts pre-V3R1M0 host tables to the new format
without affecting the performance of the STRTCP command processing.
TCP/IP Jobs
Jobs started by the Start TCP/IP (STRTCP) command are listed in Table 2.
Table 2. Jobs Used by TCP/IP
|
Job Name
Description
QAPPCTCP
APPC over TCP/IP applications
QTBOOTP
BOOTP server
QTCPIP
Main TCP/IP job
QTFTPxxxxx
FTP server (there may be several)
QTGTELNETS
TELNET server (there may be several)
QTRTDxxxxx
RouteD server
QTRXCxxxx
REXEC server (there may be several)
QTSMTPCLNT
SMTP client
QTSMTPSRVR
SMTP server
QTSMTPBRCL
SMTP bridge client
QTSMTPBRSR
SMTP bridge server
QTTFTxxxxx
TFTP server (there may be several)
QTMSNMP
SNMP server
QTMSNMPRCV
SNMP server
QSNMPSA
SNMP server
QTLPDxxxxx
LPD server (there may be several)
QTPOxxxxxx
POP server (there may be several)
QTPPANSxxx
Dial-in (*ANS) support (PPP)
QTPPDIALxx
Dial-out (*DIAL) support (PPP)
ADMIN and DEFAULT
ICS (HTTP) server
QTWSGxxxxx
Workstation gateway (there may be several)
Chapter 2. Configuring TCP/IP
45
Table 2. Jobs Used by TCP/IP (continued)
Job Name
Description
Note:
1. There may be other jobs running in the QSYSWRK subsystem that have nothing to do
with TCP/IP.
2. The TCP/IP jobs in QSYSWRK run under the QTCP user profile, with two exceptions:
the TFTP server runs under the QTFTP profile, and the workstation gateway server runs
under the QTMTWSG profile.
3. To use APPC over TCP/IP applications, you must set the network attribute Allow AnyNet
(ALWANYNET) to *YES.
End TCP/IP (ENDTCP):
ATTENTION!
No confirmation display appears when you enter ENDTCP is entered.
Therefore, you must use the ENDTCP command carefully. The default for the
ENDTCP command is to immediately end all TCP/IP processing on the
AS/400 system that you are working on.
Use the End TCP/IP (ENDTCP) command to end all TCP/IP processing.
The command can be issued from the command line or by using option 4 on the
TCP/IP Administration menu. To display this menu, enter GO TCPADM on the
command line.
Step 9—Verifying the TCP/IP Connection
To verify the TCP/IP connection from your AS/400 system to the network, use the
PING (VFYTCPCNN) function.
1. To test the TCP/IP code without sending anything out of the token-ring adapter,
specify the special host name LOOPBACK as follows:
PING LOOPBACK
2. To test the TCP/IP code, token-ring adapter, and token-ring connection, specify
the Internet address of the local adapter, as defined in the host table, as follows:
PING RMTSYS(*INTNETADR)
INTNETADR('9.4.73.212')
Or you may enter:
PING RMTSYS(SYSNAM890)
This command sends data out onto the token-ring line, which the local adapter
receives again as if the data is from the TCP/IP network.
Figure 26 on page 47 shows the results from a successful connection
verification.
46
OS/400 TCP/IP Configuration and Reference V4R4
> ping '9.4.73.212'
Verifying connection to host system 9.4.73.212.
PING request 1 from 9.4.73.212 took 24 ms. 256 bytes.
PING request 2 from 9.4.73.212 took 11 ms. 256 bytes.
PING request 3 from 9.4.73.212 took 31 ms. 256 bytes.
PING request 4 from 9.4.73.212 took 11 ms. 256 bytes.
PING request 5 from 9.4.73.212 took 12 ms. 256 bytes.
Round-trip (in milliseconds) min/avg/max = 11/17/31
Connection verification statistics: 5 of 5 successful
TTL
TTL
TTL
TTL
TTL
64.
64.
64.
64
64.
(100 %).
Figure 26. Successful PING Messages
3. If the PING operation is successful, you should see messages similar to those
in Figure 26.
If the PING operation is unsuccessful, you should see messages similar to
those in Figure 27.
If you receive an unsuccessful PING message, check your configuration steps.
Also check that the configuration at the remote system is correct and that the
remote system is not powered down. For additional information about identifying
the cause for an unsuccessful connection verification, see 437.
> ping '9.4.73.198'
Verifying connection to host system 9.4.73.198.
No response from host within 1 seconds for connection
No response from host within 1 seconds for connection
No response from host within 1 seconds for connection
No response from host within 1 seconds for connection
No response from host within 1 seconds for connection
Connection verification statistics: 0 of 5 successful
verification
verification
verification
verification
verification
(0 %).
1.
2.
3.
4.
5.
Bottom
Figure 27. Unsuccessful PING Messages
Note: A datagram sent by TCP or UDP to a system with the name LOOPBACK
does not actually leave the system. The IP layer, instead, returns the
datagram to the TCP or UDP layer from which it came. The other layers then
treat the datagram as a normal incoming datagram. The LOOPBACK host
name can be used with any TCP/IP command requiring a system name,
such as PING or FTP (or any TCP or UDP application including user-written
applications). Using the LOOPBACK default host name provides an ability to
test TCP/IP applications without actually connecting to a physical network.
The AS/400 system defines LOOPBACK as the default host name by automatically
creating an entry in the local host table.
Verifying Additional TCP/IP Connections
Once TCP/IP is configured on the AS/400 system, and the initial connection is
verified, you will probably want to add more systems to your network. When you
connect additional systems to your network, you also need to verify their TCP/IP
connection. The examples in the following paragraphs show you how to verify a
remote TCP/IP connection.
Chapter 2. Configuring TCP/IP
47
Use the system menus or the Verify TCP/IP Connection (VFYTCPCNN or PING)
command to verify your system’s ability to communicate with a remote system using
TCP/IP.
Note: PING uses the Internet Control Message Protocol (ICMP) to send data to a
host’s Internet address and waits for a response. The user command to
perform this verification is called PING (Packet InterNet Groper) on
non-AS/400 systems. On an AS/400 system, use either the PING command
or the VFYTCPCNN command.
To verify TCP/IP connections, perform the three steps below in the order in which
they are listed:
1. Type VFYTCPCNN and then press F4.
The display for the VFYTCPCNN command appears (Figure 28).
2. Type the name of a remote system as defined in your host table or as defined
by your domain name server.
If you prefer to use an Internet address, type the address enclosed in
apostrophes. You can also type *INTNETADR to be prompted for the Internet
address.
3. Press F10 to view or change the additional parameters.
As you can see in Figure 29 on page 49, the system defaults are to send five
packets of 256 bytes each and to wait 1 second for a response on each packet.
Verify TCP/IP Connection (VFYTCPCNN)
Type choices, press Enter.
Remote system . . . . . . . . . ____________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
Figure 28. Verify TCP/IP Connection
48
OS/400 TCP/IP Configuration and Reference V4R4
Verify TCP/IP Connection (PING)
Type choices, press Enter.
Remote system . . . . . . . . . sysnam36.sysnam123.ibm.com__________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
Remote internet address . . . . _____________________________
Additional Parameters
Message mode:
Response message detail . .
Summary, if response errors
Packet length (in bytes) . . .
Number of packets . . . . . .
Wait time (in seconds) . . . .
Local internet address . . . .
Type of service . . . . . . .
IP time to live . . . . . . .
F3=Exit
F4=Prompt
F24=More keys
.
.
.
.
.
.
.
.
F5=Refresh
*VERBOSE
*VERBOSE, *QUIET
*COMP
*COMP, *ESCAPE
256
8-512
5
1-999
1
1-120
*ANY________
*NORMAL
*MINDELAY, *MAXTHRPUT...
*DFT
1-255, *DFT
F12=Cancel
More...
F13=How to use this display
Figure 29. Verify TCP/IP Connection, Additional Parameters
Verifying TCP/IP Connections with Host Name—Example
In this example, sending five packets of 256 bytes each verifies the connection to
the remote system SYSNAM36. The local system waits 1 second for a response to
each packet that is sent.
Chapter 2. Configuring TCP/IP
49
Verify TCP/IP Connection (PING)
Type choices, press Enter.
Remote system . . . . . . . . . > SYSNAM36.SYSNAM123.IBM.COM_____________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
Additional Parameters
Message mode:
Response message detail . .
Summary, if response errors
Packet length (in bytes) . . .
Number of packets . . . . . .
Wait time (in seconds) . . . .
Local internet address . . . .
Type of service . . . . . . .
IP time to live . . . . . . .
F3=Exit
F4=Prompt
F24=More keys
.
.
.
.
.
.
.
.
F5=Refresh
*VERBOSE
*VERBOSE, *QUIET
*COMP
*COMP, *ESCAPE
256
8-512
5
1-999
1
1-120
*ANY________
*NORMAL
*MINDELAY, *MAXTHRPUT...
*DFT
1-255, *DFT
F12=Cancel
More...
F13=How to use this display
Figure 30. Verifying Connection to Remote System SYS1
Verifying TCP/IP Connections with Internet Address—Example
In this example, (Figure 30) the connection to the remote system at Internet
address 9.4.191.76 is verified using the system defaults for packet length, number
of packets, and wait time.
Verify TCP/IP Connection (PING)
Type choices, press Enter.
Remote system . . . . . . . . . *intnetadr___________________________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
Remote internet address . . . . > '9.4.191.76'
Figure 31. Verifying Connection to Remote System at Internet Address 9.4.191.76
Step 10—Saving Your TCP/IP Configuration
To save your TCP/IP configuration files, use the following command:
SAVOBJ OBJ(QATOC* QATM*) LIB(QUSRSYS)
DEV(TAP01) OBJTYPE(*FILE)
The associated line descriptions are not saved with this command. Configuration
objects are saved with the system.
To maintain consistency, save all TCP/IP configuration files together.
50
OS/400 TCP/IP Configuration and Reference V4R4
Note: You do not have to end TCP/IP in order to save the configuration files.
However, you should end TCP/IP before any TCP/IP configuration files are
restored.
TCP/IP Planning Checklists
The following checklists (Table 3 and Table 4) can help you prepare for the
installation and configuration of TCP/IP on your network
v Line description parameters
v Local TCP/IP host information
Line Description Parameters Checklist
Table 3. Line Description Parameters
Line Type
*ELAN
*TRLAN
*WLS
*DDI
Resource name
R
R
R
R
Local adapter address
O
O
O
O
O
O
O
O
Speed
*FR
SSAP (session services
access point)
O
O
O
O
O
Maximum frame size
O
O
O
O
O
Local manager mode
*X25
*ASYNC
*PPP
R
R
R
O
O
O
O
O
O
*TDLC
O
Attached non-switched
NWI name
R
Data link connection ID
R
Network controller
R
Connection type
R
Logical channel identifier
R
Logical channel type
R
PVC (permanent virtual
circuit) controller
R
Local network address
R
Physical interface type
O
Packet size
O
Window size
O
Attached workstation
controller
R
Note:
R means the parameter is required
O means OS/400 suggests a default value
Local TCP/IP Host Information Checklist
Table 4. Local TCP/IP Host Information
Interfaces to Local TCP/IP Networks
Interface #1
Interface #2
Interface #3
Chapter 2. Configuring TCP/IP
51
Table 4. Local TCP/IP Host Information (continued)
Internet address
Line description name
Subnet mask
Interface MTU
Local host name
Local domain name
Domain name server (Internet address)
Default route/next hop (Internet address)
IP datagram forwarding (yes or no)
Explicit Routes to Remote TCP/IP Networks
Route #1
Route #2
Route #3
Internet address
Subnet mask
Next hop (Internet address)
MTU size
Local Host Table Entries: Remote TCP/IP Hosts
Internet address
Host Name #1
Host Name #2
Host Name #3
X.25 / Remote System Information
Host #1
Host #2
Host #3
Internet address
X.25 network address
PVC channel ID
Packet or window size
Sample Network Drawing
The following network illustration can help you as you begin to draw your own
network diagram. By performing this exercise, you will have a clear idea of how to
attach your AS/400 system to the other systems in the network.
52
OS/400 TCP/IP Configuration and Reference V4R4
Figure 32. Sample TCP/IP Network
Chapter 2. Configuring TCP/IP
53
54
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 3. TCP/IP: Operation, Management, and Advanced
Topics
This chapter discusses managing your network by using the NETSTAT command,
and the maintenance of host tables. In addition, this chapter covers other topics
beyond those that are required to configure and use TCP/IP on AS/400. This
information may help you to understand and maximize your usage of the AS/400
TCP/IP support.
TCP/IP on an AS/400 system can also be managed by Simple Network
Management Protocol (SNMP). For information about SNMP, see the book, Simple
Network Management Protocol (SNMP) Support, SC41-5412-00.
Network Status
The network status function on the AS/400 system allows you to get information
about the status of TCP/IP network interfaces, routes, and connections on your
local system. This function also allows you to end TCP/IP connections and to start
or end TCP/IP interfaces.
NETSTAT displays the current TCP/IP protocol stack information. This information
does not necessarily match the configuration data you see when using the
Configure TCP/IP (CFGTCP) menu. In most cases, the NETSTAT command
displays more information than the configuration data. In some cases, the
configuration data might even change.
The reason for such a change is that the AS/400 TCP/IP dynamically creates some
information, such as *DIRECT routes, when TCP/IP starts. A change may also
occur if the configuration data that was sent to TCP/IP when it starts is changed
dynamically by TCP/IP applications that run after you start TCP/IP. Several types of
processing alter the initial TCP/IP configuration:
v Internet Control Message Protocol (ICMP) requests
v Sockets ioctl system calls
v Simple Network Management Protocol (SNMP) requests
v AS/400 TCP/IP internal processing
Work with TCP/IP Network Status Menu
The Work with TCP/IP Network Status menu allows you to work with the various
network status functions.
To display the Work with TCP/IP Network Status menu, take these steps:
1. Type the WRKTCPSTS (Work with TCP/IP Network Status) command or the
NETSTAT (Network Status) command.
2. Press the Enter key. (See Figure 33 on page 56.)
© Copyright IBM Corp. 1997, 1999
55
Work with TCP/IP Network Status
Select one of the following:
System:
SYSNAM04
1. Work with TCP/IP interface status
2. Display TCP/IP route information
3. Work with TCP/IP connection status
Figure 33. Work with TCP/IP Network Status
Work with TCP/IP Interface Status
The Work with TCP/IP Interface Status display, as shown in Figure 34, provides the
most current summary of interface activity. This display allows you to view TCP/IP
interface information for selected interfaces and to start or end TCP/IP interfaces.
To view the Work with TCP/IP Interface Status display, take these steps:
1. Type 1 on the command line of the Work with TCP/IP Network Status menu or
enter the WRKTCPSTS *IFC command.
2. Press the Enter key.
Work with TCP/IP Interface Status
Type options, press Enter.
5=Display details 8=Display associated routes
12=Work with configuration status
Opt
Internet
Address
9.125.87.10
9.125.87.222
127.0.0.1
F3=Exit
F4=Prompt
F13=Sort by column
Network
Address
9.125.87.0
9.125.87.0
127.0.0.0
System:
9=Start
SYSNAM04
10=End
Line
Interface
Description Status
TRNLINE
Active
TESTTRN
Active
*LOOPBACK
Active
F5=Refresh
F11=Display line information
F24=More keys
Bottom
F12=Cancel
Figure 34. Work with TCP/IP Interface Status, Display 1 of 2
Press F11 to change the contents of the display to include the subnet mask, type of
service, maximum transmission unit (MTU), and line type, as shown in Figure 35 on
page 57.
56
OS/400 TCP/IP Configuration and Reference V4R4
Work with TCP/IP Interface Status
Type options, press Enter.
5=Display details
8=Display associated routes
12=Work with configuration status
Opt
Internet
Address
9.125.87.10
9.125.87.222
127.0.0.1
Subnet
Mask
255.255.255.0
255.255.255.0
255.0.0.0
Type of
Service
*MAXTHRPUT
*NORMAL
*NORMAL
System:
9=Start
SYSNAM04
10=End
Line
MTU Type
1989 *TRLAN
1989 *TRLAN
576 *NONE
Figure 35. Work with TCP/IP Interface Status, Display 2 of 2
Starting TCP/IP Interfaces
TCP/IP interfaces are started in one of the following ways:
v The Work with TCP/IP Interface Status displays are reached by:
– Option 1 on the Configure TCP/IP (CFGTCP) menu
– Option 1 on the Network Status (NETSTAT or WRKTCPSTS) menu
v The Start TCP/IP Interface (STRTCPIFC) command
v Using the Operations Navigator interface
Note: You can start TCP/IP interfaces through the Operations Navigator
interface wizard. However, this chapter does not document any of the
Operations Navigator functions. See the online help in Operations
Navigator for this information.
To start a TCP/IP interface from the Work with TCP/IP Interface Status menu, type
9 in the option field for each interface that you want to start and press the Enter
key.
To start a TCP/IP interface using the STRTCPIFC command, take these steps:
1. Type STRTCPIFC on the command line and press F4 (Prompt).
2. Type the Internet address of the interface that you want to start and press the
Enter key.
Option 9 on the Work with TCP/IP Interface Status display is used to start both
TCP/IP interfaces and Internet Protocol (IP) over Systems Network Architecture
(SNA) interfaces. For information about starting IP over SNA interfaces, see the
STRIPSIFC (Start IP over SNA Interface) command in the CL Reference (Abridged),
SC41-5722.
Note: When starting the first TCP/IP interface associated with an Integrated
Netfinity Server for AS/400 (also known as File Server Input/Output
Processor and FSIOP) network server description, a considerable amount of
time may pass before the interface becomes active. This is because TCP/IP
activation includes starting the network server. The amount of time that is
required depends mainly on machine use and the size of the processor. To
determine whether the interface has started, view the messages in the
QTCPIP job log and the QSYSOPR message queue.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
57
Ending TCP/IP Interfaces
The ENDTCPIFC (End TCP/IP Interface) command ends an existing TCP/IP
interface immediately. As a result, all TCP/IP connections using this interface also
end immediately. However, the operation of any other TCP or IP over SNA
interface, using the same line description as the interface that is ending, is not
affected.
TCP/IP interfaces can be ended in one of two ways:
v Using the Work with TCP/IP Interface Status display, which is reached by:
– Option 1 on the Configure TCP/IP (CFGTCP) menu
– Option 1 on the Network Status (NETSTAT or WRKTCPSTS) menu
v Using the ENDTCPIFC (End TCP/IP Interface) command
To end a TCP/IP interface from the Work with TCP/IP Interface Status menu:
1. Type 10 in the option field for each interface that you want to end.
2. Press the Enter key.
To
1.
2.
3.
end a TCP/IP interface using the ENDTCPIFC command:
Type ENDTCPIFC on the command line.
Press F4 (Prompt).
Type the Internet address of the interface that you want to end.
4. Press the Enter key.
Option 10 on the Work with TCP/IP Interface Status display is used to end both
TCP/IP interfaces and IP over SNA interfaces. For information about ending IP over
SNA interfaces, see the ENDIPSIFC (End IP over SNA Interface) command in the
CL Reference (Abridged), SC41-5722-03.
Route-to-Interface Binding: Interfaces define direct paths to networks or
subnetworks to which an AS/400 system is directly attached. Routes define indirect
paths. A route identifies the first hop on the path to a network or subnetwork to
which an AS/400 system is not directly attached.
Routes are bound to interfaces through the use of a best-match-first algorithm. This
algorithm is based on the state of the interface, and on the type of service (TOS)
specified for the route and interface. When you end an interface, the routes
associated with the interface can move to another existing active interface if the
following conditions are satisfied:
v If the TOS for the route is something other than *NORMAL, the algorithm looks
for an interface with the same TOS. If an interface with the specified TOS is not
found, an interface with TOS *NORMAL is sought. Again, if one is not found, that
route will not be moved.
v The MTU value for the route that is being moved must be less than or equal to
the MTU value for the active interface.
v The network ID of the interface must be equal to the logical AND of the next hop
for the route and the subnet mask for the interface.
Notes:
1. If the next hop of a route is identical to an interface’s IP address, that route will
never be bound to another interface.
2. When starting interfaces (if all interfaces are currently inactive) routes are bound
to the interfaces with the same best-match-first algorithm. An exception is if the
58
OS/400 TCP/IP Configuration and Reference V4R4
route is defined with a preferred binding interface. In this case, an attempt is
made to bind the route to the interface that is indicated. If the binding attempt
fails, then the best-match-first algorithm is used.
Display TCP/IP Route Information
The display TCP/IP route information function allows you to view information about
TCP/IP routes.
To display TCP/IP route information:
1. On the Work with TCP/IP Network Status menu, type 2 on the command line or
enter the WRKTCPSTS *RTE command.
2. Press the Enter key.
The first of the two Display TCP/IP Route Information displays appears, as shown in
Figure 36.
Display TCP/IP Route Information
System:
Type options, press Enter.
5=Display details
Opt
Route
Destination
9.125.87.0
9.125.87.0
9.125.109.3
127.0.0.0
*DFTROUTE
*DFTROUTE
F3=Exit
F5=Refresh
F13=Sort by column
Subnet
Mask
255.255.255.0
255.255.255.0
*HOST
255.0.0.0
*NONE
*NONE
F6=Print list
F17=Top
Next
Hop
*DIRECT
*DIRECT
9.125.87.17
*DIRECT
9.125.87.169
9.125.87.250
SYSNAM04
Route
Available
*YES
*YES
*YES
*YES
*YES
*YES
F11=Display route type
F18=Bottom
Bottom
F12=Cancel
Figure 36. Display TCP/IP Route Information, Display 1 of 2
To view the second display, press F11 (Display route type). The route information is
presented as shown in Figure 37 on page 60. To return to the first display, press
F11 (Display next hop).
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
59
Display TCP/IP Route Information
Type options, press Enter.
5=Display details
Opt
Route
Destination
9.125.87.0
9.125.87.0
9.125.109.3
127.0.0.0
*DFTROUTE
*DFTROUTE
F3=Exit
F5=Refresh
F13=Sort by column
Type of
Service
*MAXTHRPUT
*NORMAL
*MINDELAY
*NORMAL
*MAXTHRPUT
*NORMAL
F6=Print list
F17=Top
Route
MTU
1989
1989
576
576
1989
1989
System:
SYSNAM04
Route
Route
Type
Source
*DIRECT
*CFG
*DIRECT
*CFG
*HOST
*ICMP
*DIRECT
*CFG
*DFTROUTE *CFG
*DFTROUTE *CFG
F11=Display next hop
F18=Bottom
F12=Cancel
Bottom
Figure 37. Display TCP/IP Route Information, Display 2 of 2
To view detailed information about a specific route, type 5 in the option field next to
the route and press the Enter key.
Routes listed on the Display TCP/IP Route Information display differ from the routes
that are displayed on the Work with TCP/IP Routes display. Only routes with a route
source of *CFG and a route type that is not *DIRECT can be changed with the
Work with TCP/IP Routes display. Similarly, only routes that meet these conditions
can be changed or removed with the CHGTCPRTE or RMVTCPRTE commands.
*CFG means the route was added using AS/400 configuration commands or is a
*DIRECT route. *DIRECT means that the route is to a network or subnetwork to
which this system has a direct physical connection. This route is not defined with an
add route command.
Work with TCP/IP Connection Status
The Work with TCP/IP Connection Status display allows you to display or end a
TCP/IP connection between a local system and a remote system.
To display the Work with TCP/IP Connection Status display:
1. Type 3 on the command line of the Work with TCP/IP Network Status menu or
enter the WRKTCPSTS *CNN command.
2. Press the Enter key.
The first of the three Work with TCP/IP Connection Status displays, as shown in
Figure 38 on page 61.
To display the second and third Work with TCP/IP Connection Status displays,
press F11 (see Figure 39 on page 61 and Figure 40 on page 62). To display port
numbers instead of port service names, press F14.
In Figure 38 on page 61, the connections indicate that the FTP server, SMTP
server, and TELNET server are active and ready to receive connection attempts.
60
OS/400 TCP/IP Configuration and Reference V4R4
Because no connection has been established yet, the Remote Address and Remote
Port fields contain an asterisk (*). When an application requests a connection to a
listening socket, a new connection is created. The remote Internet address and
remote port are shown for the new connection. The listening socket always remains
in the list of connections.
Work with TCP/IP Connection Status
Local internet address . . . . . . . . . . . :
*ALL
System:
SYSNAM04
Type options, press Enter.
4=End
5=Display details
Opt
Remote
Address
*
*
*
*
*
*
*
*
*
*
9.5.1.180
Remote
Port
*
*
*
*
*
*
*
*
*
*
1211
Local
Port
ftp-con >
telnet
telnet
smtp
lpd
1049
1050
1051
1052
1070
telnet
Idle Time
000:20:41
001:39:00
000:14:27
000:55:23
002:36:29
001:31:01
001:28:02
001:12:05
001:09:52
000:35:53
000:10:17
State
Listen
Listen
Listen
Listen
Listen
*UDP
*UDP
*UDP
*UDP
Listen
Established
F5=Refresh
F11=Display byte counts
F13=Sort by column
F14=Display port numbers
F22=Display entire field
F24=More keys
More...
Figure 38. Work with TCP/IP Connection Status, Display 1 of 3
Work with TCP/IP Connection Status
Local internet address . . . . . . . . . . . :
*ALL
System:
SYSNAM04
Type options, press Enter.
4=End
5=Display details
Opt
Remote
Address
*
*
*
*
*
9.5.1.131
9.5.1.180
9.5.15.134
9.5.15.141
9.130.38.18
9.130.38.74
Remote
Port
*
*
*
*
*
1954
1211
1024
1027
2099
1125
Local
Port
ftp-con >
telnet
telnet
lpd
1070
telnet
telnet
telnet
telnet
telnet
telnet
User
QTCP
QTCP
QTCP
QTCP
BILANSKY
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
Bytes Out
0
0
0
0
0
48583
32319
403415
3831
509788
680
F5=Refresh
F11=Display connection type
F13=Sort by column
F14=Display port numbers
F22=Display entire field
F24=More keys
Bytes In
0
0
0
0
0
815
4704
226141
236
15394
34
More...
Figure 39. Work with TCP/IP Connection Status, Display 2 of 3
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
61
Work with TCP/IP Connection Status
Local internet address . . . . . . . . . . . :
*ALL
System:
SYSNAM04
Type options, press Enter.
4=End
5=Display details
Opt
Remote
Address
*
*
*
*
*
9.5.1.131
9.5.1.180
9.5.15.134
9.130.38.18
9.130.38.74
9.130.38.74
Remote
Port
*
*
*
*
*
1954
1211
1024
2099
1125
1126
Local
Address
*
*
*
*
9.125.87.222
9.125.87.10
9.125.87.10
9.125.87.10
9.125.87.222
9.125.87.10
9.125.87.222
Local
Port
Type
ftp-con > *TCP
telnet
*TCP
telnet
*TCP
lpd
*TCP
1070
*TCP
telnet
*TCP
telnet
*TCP
telnet
*TCP
telnet
*TCP
telnet
*TCP
telnet
*TCP
F5=Refresh
F11=Display connection state
F13=Sort by column
F14=Display port numbers
F22=Display entire field
F24=More keys
More...
Figure 40. Work with TCP/IP Connection Status, Display 3 of 3
Ending TCP/IP Connections
TCP/IP connections and User Datagram Protocol (UDP) sockets can be ended from
the Work with TCP/IP Connection Status display. To do so:
1. Type 4 in the option field for the lines containing the connections that you want
to end.
2. Press the Enter key.
The Confirm End of TCP/IP Connections displays is then presented as shown in
Figure 41 on page 63.
62
OS/400 TCP/IP Configuration and Reference V4R4
Confirm End of TCP/IP Connections
Local internet address . . . . . . . . . . . :
*ALL
System:
SYSNAM04
Press Enter to confirm your choices for 4=End.
Press F12 to return to change your choices.
Remote
Opt Address
4
9.5.15.134
Remote
Port
1024
F11=Display connection state
F22=Display entire field
Local
Address
9.125.87.10
F12=Cancel
Local
Port
telnet
Type
*TCP
F14=Display port numbers
Bottom
Figure 41. Confirm End of TCP/IP Connections
To end the TCP/IP connections, press the Enter key from the Confirm End of
TCP/IP Connections display.
If you decide not to end a TCP/IP connection or if you want to change your choices,
press F12 (Cancel).
Working with Configuration Status
To work with the line description used by an interface:
1. On the Work with TCP/IP Interface Status menu, type 12 in the option field for
each interface that you want to work with.
2. Press the Enter key.
This option issues the WRKCFGSTS (Work with Configuration Status) command for
the line description associated with the interface. Using the options shown in
Figure 42 on page 64 you can vary a line description on or off, display the Work
with Job menu, and display the line description or mode status.
This option cannot be used for IP over SNA interfaces because IP over SNA does
not use specific line descriptions.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
63
Work with Configuration Status
Position to . . . . .
Starting characters
04/26/94
SYSNAM04
15:55:58
Type options, press Enter.
1=Vary on
2=Vary off
5=Work with job
9=Display mode status ...
8=Work with description
Opt
-------------Job--------------
Description
TRNLINE
TRNLINET
TRNLITCP
Status
ACTIVE
ACTIVE
ACTIVE
QTCPIP
QTCP
007936
Figure 42. Work with Configuration Status
Displaying TCP/IP Network Status Information
In addition to working with network status functions, the Work with TCP/IP Network
Status menu allows you to display current information about your TCP/IP network,
including multicast groups, TCP/IP interfaces, and associated routes, to name a
few.
Display Multicast Groups
To display the multicast groups associated with an interface:
1. On the Work with TCP/IP Interface Status display, type 14 in the option field for
each interface for which you want to see the associated multicast groups.
2. Press the Enter key.
Figure 43 on page 65 illustrates the display of the multicast groups for an Ethernet
interface.
If you have requested multicast group information for more than one interface,
press the Enter key to review the remaining displays.
64
OS/400 TCP/IP Configuration and Reference V4R4
Display Multicast Host Groups
Interface internet address . . . . . . . . . . . :
Host Group
224.0.0.1
225.4.5.6
233.32.40.51
224.0.0.9
229:200:100:1
F3=Exit
F5=Refresh
F12=Cancel
Hardware Address
01:00:5E:00:00:01
01:00:5E:04:05:06
01:00:5E:20:28:33
01:00:5E:00:00:09
01:00:5E:48:64:01
F6=Print
System:
10.5.5.55
Host Group
F9=Command line
SYSNAM04
Hardware Address
Bottom
F11=Hide hardware address
Figure 43. Display Multicast Host Groups
Displaying TCP/IP Interfaces
To display more detailed information about the TCP/IP interface status for specific
interfaces:
1. On the Work with TCP/IP Interface Status display, type 5 in the option field for
each interface about which you want more information.
2. Press the Enter key.
If you requested status for a token-ring interface, the information displays, as shown
in Figure 44 on page 66.
If you have requested interface status information for more than one interface,
press the Enter key to view the remaining displays.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
65
Display TCP/IP Interface Status
Interface host name . . . . .
Internet address . . . . . .
Subnet mask . . . . . . . .
Network address . . . . . .
Host address . . . . . . .
Directed broadcast address
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
System:
SYSNAM04
sysnam04.endicott.ibm. >
9.125.87.10
255.255.255.0
9.125.87.0
0.0.0.10
9.125.87.255
Interface status . . . .
Change date/time . . . .
Line description . . . .
Line type . . . . . . . .
Type of service . . . . .
Maximum transmission unit
Automatic start . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
Active
04/26/94 14:32:32
TRNLINE
*TRLAN
*MAXTHRPUT
1989
*YES
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TRLAN bit sequencing . . . . . . . . . . . . :
*MSB
Figure 44. Display TCP/IP Interface Status for a Token-Ring Interface
Displaying Associated Routes
To display information about the routes associated with a specific interface:
1. On the Work with TCP/IP Interface Status display, type 8 in the option field for
each interface for which you want to see the associated routes information.
2. Press the Enter key.
The first of two displays with associated route information is shown in Figure 45 on
page 67.
If you have requested associated route information for more than one interface,
press the Enter key to view the remaining displays.
66
OS/400 TCP/IP Configuration and Reference V4R4
Display Associated Routes
Interface internet address . . . . . . . . . :
System:
9.125.87.10
SYSNAM04
Type options, press Enter.
5=Display details
Opt
Route
Destination
9.125.87.0
*DFTROUTE
F3=Exit
F5=Refresh
F13=Sort by column
Subnet
Mask
255.255.255.0
*NONE
F6=Print list
F17=Top
Next
Hop
*DIRECT
9.125.87.169
Route
Available
*YES
*YES
F11=Display route type
F18=Bottom
Bottom
F12=Cancel
Figure 45. Associated Route Information, Display 1 of 2
Press F11 to show the display that includes the type of service (TOS), maximum
transmission unit (MTU), type, and source.
Displaying Route Details Option
To display detailed information about the route:
1. On the Display Associated Routes display, type 5 in the option field for each
route about which you want more information.
2. Press the Enter key.
Figure 46 on page 68 and Figure 47 on page 68 are examples.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
67
Display TCP/IP Route Details
Route information:
Route destination . . . . . . .
Subnet mask . . . . . . . . . .
Next hop host name . . . . . .
Next hop . . . . . . . . . . .
Type of service . . . . . . . .
Route available . . . . . . . .
Route type . . . . . . . . . .
Route source . . . . . . . . .
Change date/time . . . . . . .
Route maximum transmission unit
Reference count . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
Local interface information:
Internet address . . . . . . . . . . . . . :
Subnet mask . . . . . . . . . . . . . . . :
Network address . . . . . . . . . . . . . :
System:
9.125.87.0
255.255.255.0
sysnam04.endicott.ibm. >
*DIRECT
*MAXTHRPUT
*YES
*DIRECT
*CFG
04/26/94 14:32:32
1989
0
9.125.87.10
255.255.255.0
9.125.87.0
Press Enter to continue.
F3=Exit
F6=Print
F12=Cancel
SYSNAM04
More...
F22=Display entire field
Figure 46. Display TCP/IP Route Details, Display 1 of 2
Display TCP/IP Route Details
Interface status . . . . . . . . . . . . . :
Line description . . . . . . . . . . . . . :
Line type . . . . . . . . . . . . . . . . . :
Active
TRNLINE
*TRLAN
System:
SYSNAM04
Figure 47. Display TCP/IP Route Details, Display 2 of 2
Displaying TCP/IP Route Information
To display TCP/IP route information:
1. On the Work with TCP/IP Network Status menu, type 2 on the command line or
enter the WRKTCPSTS *RTE command.
2. Press the Enter key.
The first of the two Display TCP/IP Route Information displays is presented as
shown in Figure 48 on page 69.
68
OS/400 TCP/IP Configuration and Reference V4R4
Display TCP/IP Route Information
System:
Type options, press Enter.
5=Display details
Opt
Route
Destination
9.125.87.0
9.125.87.0
9.125.109.3
127.0.0.0
*DFTROUTE
*DFTROUTE
F3=Exit
F5=Refresh
F13=Sort by column
Subnet
Mask
255.255.255.0
255.255.255.0
*HOST
255.0.0.0
*NONE
*NONE
F6=Print list
F17=Top
Next
Hop
*DIRECT
*DIRECT
9.125.87.17
*DIRECT
9.125.87.169
9.125.87.250
SYSNAM04
Route
Available
*YES
*YES
*YES
*YES
*YES
*YES
Bottom
F12=Cancel
F11=Display route type
F18=Bottom
Figure 48. Display TCP/IP Route Information, Display 1 of 2
To view the second Display TCP/IP Route Information display, press F11 (Display
route type). The route information is presented in Figure 49. To return to the first
display, press F11 (Display next hop).
Display TCP/IP Route Information
Type options, press Enter.
5=Display details
Opt
Route
Destination
9.125.87.0
9.125.87.0
9.125.109.3
127.0.0.0
*DFTROUTE
*DFTROUTE
F3=Exit
F5=Refresh
F13=Sort by column
Type of
Service
*MAXTHRPUT
*NORMAL
*MINDELAY
*NORMAL
*MAXTHRPUT
*NORMAL
F6=Print list
F17=Top
Route
MTU
1989
1989
576
576
1989
1989
System:
SYSNAM04
Route
Route
Type
Source
*DIRECT
*CFG
*DIRECT
*CFG
*HOST
*ICMP
*DIRECT
*CFG
*DFTROUTE *CFG
*DFTROUTE *CFG
F11=Display next hop
F18=Bottom
F12=Cancel
Bottom
Figure 49. Display TCP/IP Route Information, Display 2 of 2
To view detailed information about a specific route, type 5 in the option field next to
the route and press the Enter key. See Figure 46 on page 68 and Figure 47 on
page 68.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
69
Displaying TCP/IP Connections
You can request more detailed information about TCP/IP connections shown on the
Work with TCP/IP Connection Status display. This information includes timing
information and transmission statistics for the connection displayed.
To display more information about the listed TCP/IP connections:
1. Type 5 in the option field for each connection about which you want more
information.
2. Press the Enter key.
A series of up to three displays for each connection appears. Press the Page Down
key to view the remaining displays.
The contents of the displays vary depending on the type of connection, whether
*TCP, *UDP, or *IPS. (Figure 50,Figure 51 on page 71, and Figure 52 on page 71
show displays for a TCP connection.)
Display TCP Connection Status
Connection identification:
Remote host name . . . . . . . . . .
Remote internet address . . . . . .
Remote port . . . . . . . . . . . .
Local host name . . . . . . . . . . .
Local internet address . . . . . .
Local port . . . . . . . . . . . .
Associated user profile . . . . . . .
TCP programming interface information:
State . . . . . . . . . . . . . . . .
Connection open type . . . . . . . .
Timing information:
Idle time . . . . . . . . . . . . . .
Last activity date/time . . . . . .
Round-trip time . . . . . . . . . . .
Round-trip variance . . . . . . . . .
Press Enter to continue.
F3=Exit
F5=Refresh
F14=Display port numbers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
OS/400 TCP/IP Configuration and Reference V4R4
SYSNAM04
drfun.rchland.ibm.com
9.5.15.134
1025
sysnam04.endicott.ibm. >
9.125.87.143
telnet
QTCP
. . . . :
. . . . :
Established
Passive
.
.
.
.
000:00:00.381
05/25/94 14:38:11
.133
.016
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
More...
F6=Print
F10=Display IP options
F22=Display entire field
Figure 50. Display TCP/IP Connection Status, Display 1 of 3
70
System:
F12=Cancel
Display TCP Connection Status
Bytes out . . . . . . . .
Outgoing bytes buffered
User send next . . . .
Send next . . . . . . .
Send unacknowledged . .
Outgoing push number .
Outgoing urgency number
Outgoing window number
Bytes in . . . . . . . .
Incoming bytes buffered
Receive next . . . . .
User receive next . . .
Incoming push number .
Incoming urgency number
Incoming window number
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
System:
57692
0
3270868150
3270868150
3270868150
3270868149
3270868149
3270896558
1021
0
1545153023
1545153023
1545153023
1545153022
1545160742
SYSNAM04
More...
Press Enter to continue.
F3=Exit
F5=Refresh
F14=Display port numbers
F6=Print
F10=Display IP options
F22=Display entire field
F12=Cancel
Figure 51. Display TCP/IP Connection Status, Display 2 of 3
Display TCP Connection Status
Retransmission information:
Total retransmissions . . . . .
Current retransmissions . . . .
Send window information:
Maximum size . . . . . . . . .
Current size . . . . . . . . .
Last update . . . . . . . . . .
Last update acknowledged . . .
Congestion window . . . . . . .
Slow start threshold . . . . .
Precedence and security:
Precedence . . . . . . . . . .
Initialization information:
Maximum segment size . . . . .
Initial send sequence number .
Initial receive sequence number
Press Enter to continue.
F3=Exit
F5=Refresh
F14=Display port numbers
System:
. . . . . . . :
. . . . . . . :
8
0
.
.
.
.
.
.
28672
28408
1545153004
3270868150
2704
1281
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
. . . . . . . :
0
. . . . . . . :
. . . . . . . :
. . . . . . . :
536
3270810457
1545152001
SYSNAM04
Bottom
F6=Print
F10=Display IP options
F22=Display entire field
F12=Cancel
Figure 52. Display TCP/IP Connection Status, Display 3 of 3
Displaying Connection Totals
To display a summary of TCP and UDP counts, press F10 on the Work with TCP/IP
Connection Status display. The counts provided are a cumulative summary of all
TCP and UDP activity since the last time the STRTCP (Start TCP) command was
issued.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
71
The information in Figure 53 and Figure 54 shows TCP and UDP counts that are
maintained for Simple Network Management Protocol (SNMP). For additional
information about SNMP, see the Simple Network Management Protocol (SNMP)
Support book.
Display TCP/IP Connection Totals
TCP connection information:
Currently established . . .
Active opens . . . . . . .
Passive opens . . . . . . .
Attempted opens that failed
Established and then reset
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
System:
1
0
0
0
0
TCP send information:
Segments sent . . . . . . . . . . . . . . . :
Retransmitted segments . . . . . . . . . . :
Reset segments . . . . . . . . . . . . . . :
108
10
0
TCP receive information:
Segments received . . . . . . . . . . . . . :
Segments received in error . . . . . . . . :
117
0
More...
Press Enter to continue.
F3=Exit
F5=Refresh
SYSNAM04
F6=Print
F12=Cancel
Figure 53. Display TCP/IP Connection Totals, Display 1 of 2
Display TCP/IP Connection Totals
UDP send information:
Datagrams sent . . . . . . . . . . . . . . :
UDP receive information:
Datagrams received . . . . .
Datagrams not delivered . . .
Application port not found
Other datagrams in error .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
System:
SYSNAM04
0
0
0
0
0
Figure 54. Display TCP/IP Connection Totals, Display 2 of 2
TCP/IP Host Tables
Host tables are a method for mapping host names to IP addresses. This is done by
using a hosts file for name-to-address resolution. Because the host table lacks the
structure to list names in any hierarchical order, names assigned to hosts must be
unique. In the topics that follow, you will find discussions about the overall
management of TCP/IP host tables. Instructions for merging host tables and
managing a host table from a central site are included.
Successful TCP/IP host table maintenance also includes periodically evaluating
whether or not to use a DNS server to manage your network. The DNS server is
often the preferred alternative to host tables for the purpose of managing IP
addresses and host names, particularly in large network environments. However,
72
OS/400 TCP/IP Configuration and Reference V4R4
even some small organizations that access the Internet require a DNS server to
meet their name-service needs. See “Chapter 18. AS/400 Domain Name System
(DNS)” on page 421 for more information.
Managing TCP/IP Host Tables
In a large network, it can be more efficient to administer AS/400 TCP/IP from a
central site. Working with the host table would be time consuming if each system is
individually updated with the TCP/IP configuration menu. Updates can be made
more quickly on one system and then copied to others.
AS/400 TCP/IP is designed to protect configuration files, including the host table.
You cannot change the host table file unless you use the Configure TCP/IP menu or
the MRGTCPHT, ADDTCPHTE, RNMTCPHTE, CHGTCPHTE, or RMVTCPHTE
commands. However, you can still import and use a host table from a central site
by using the MRGTCPHT command.
The following host table file types can be imported and merged with the AS/400
host table:
v Host table type *AS400, generated by AS/400 TCP/IP Version 3 Release 1
Modification 0 (V3R1M0) or later
v Host table type *AIX, generated by AS/400 TCP/IP Version 3 Release 0
Modification .5 (V3R0M5), Version 2 Release 3 (V2R3) or earlier, or many other
IBM and non-IBM systems
v Host table type *NIC, host table format used by public domain systems
You can merge or replace the local AS/400 host table with the imported host table.
The name of the database file containing the local host table is QATOCHOST with
member HOSTS in library QUSRSYS. This file is used directly by AS/400 TCP/IP;
no conversion into an internal version takes place.
Host File Formats
If you receive a host file and want to use it on your system, the MRGTCPHT
(Merge TCP/IP Host Table) command allows you to specify which format you are
using. You can use host information files that are in either the *NIC format, the *AIX
format, or the *AS400 format. The record length of the imported host table file is not
limited.
Host Table Information with *AIX Files
Table 5 shows the *AIX format supported on the AS/400 system.
Table 5. *AIX Supported on the AS/400 System
Delimiter
Meaning
# (pound sign)
Indicates the beginning of a comment. The text following
the pound sign is a comment and is not part of the host
table.
blank, tab
Indicates a field delimiter.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
73
Host Table Information with *NIC Files
The *NIC format is often used by hosts in the public domain. A record in a *NIC file
has the following format:
HOST : 128.12.19.1 : Host2.lan.ibm.com,Host2 : PC-AT : DOS : TCP/IP
This entry describes one host (at address 128.12.19.1) with two names
(Host2.lan.ibm.com) and (Host2). The host is an IBM Personal Computer AT
computer running MS-DOS and supporting TCP/IP.
A complete description of the *NIC format is found in Request for Comment (RFC)
952, Internet Host Table Specification. The subset supported on the AS/400 system
is shown in Table 6. The *NIC continuation characters are not supported because
the record length of the file can be up to 512 bytes.
Table 6. *NIC Subset Supported on the AS400 System
Delimiter
Meaning
1
; (semicolon)
Indicates the beginning of a comment. The text following
the semicolon is a comment and is not part of the host
table.
NET2
A keyword introducing a network entry.
GATEWAY
A keyword introducing a gateway entry.
HOST
A keyword introducing a host entry.
: (colon)
A field delimiter.
:: (two colons)
Indicates a null field.
, (comma)
A data element delimiter.
Notes:
1. If any line in the *NIC table contains a semicolon as the first column value, then that line
is not merged into the AS/400 host table.
2. These entries are not merged into the AS/400 host table.
Host Table Information with *AS400 Files
The *AS400 file format is the format of the local AS/400 host table file used by
AS/400 TCP/IP directly. The name of the file is QATOCHOST with member HOSTS
in library QUSRSYS. A single record contains an Internet address, up to four
host/domain names and a text description field. For more details regarding record
and file formats, use the DSPFFD (Display File Field Description) command.
This file can be exchanged between AS/400 systems. However, there is no function
to convert from *AS400 to *AIX or *NIC format.
Tips for Merging Host Tables
A maximum of four host names per IP address is allowed when host tables are
merged. For example, if the local host table already has three host names and the
physical file member to be merged has two additional host names, only the first
host name in the physical file is merged into the final host table.
Host names that exist for the same Internet address are not duplicated. If the same
host name is found for Internet addresses that are different, then that host name is
accepted, but a warning message is displayed.
74
OS/400 TCP/IP Configuration and Reference V4R4
The original copy of the local host table is not saved by the MRGTCPHT (Merge
TCP/IP Host Table) command. To save the original host table, create a copy of the
file QUSRSYS/QATOCHOST.HOSTS by using the Copy File (CPYF) command. Do
this before issuing the MRGTCPHT command.
Merging TCP/IP Host Tables
You can use imported host tables in two ways:
v Overwrite the current host table. To do this, specify Replace Host Table (*Yes)
on the Merge Host Table display.
v Merge the information of the imported host table with the information that was
entered by using option 10 (Work with TCP/IP host table entries) from the
Configure TCP/IP menu. To merge the information, specify Replace Host Table
(*No) on the Merge Host Table display.
You can merge an imported host table with the local host table while TCP/IP is
running by using the CFGTCP (Configure TCP/IP) command. The changes take
affect the next time a TCP/IP application accesses the host table.
Select option 11 to merge an imported host table with the local AS/400 host table.
You can also use the Merge TCP/IP Host Table (MRGTCPHT) command from any
command line.
Example: Successful Host Table Merge
The following example shows the command to merge an imported host table with
the local host table.
MRGTCPHT FROMFILE(QUSRSYS/M02HOSTS) FILEFMT(*AS400) REPLACE(*NO)
File M02HOSTS, member *FIRST, successfully merged with host
table.
Example: Partly Successful Host Table Merge
The following example shows the command to merge an imported host table with
the local host table.
MRGTCPHT FROMFILE(QUSRSYS/M03HOSTS) FILEFMT(*AS400) REPLACE(*NO)
Duplicate host name SPARKY.SYSNAM123.IBM.COM at address 9.4.6.138
found host table.
Duplicate host name MVAX.SYSNAM123.IBM.COM at address 9.4.6.252
found host table.
File M03HOSTS, member *FIRST, merged with host table: however,
error occurred.
In this example, the host table contains entries with the same host name, which
shows in the message as duplicate host names.
Managing the Host Table from a Central Site
If your network has multiple AS/400 systems, you can define the TCP/IP host table
on one system and share that table with the other systems. This saves you the
effort of having to define the host table on each system. To do this, follow these
steps:
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
75
Step 1—Create the Host Table on Your Central System
Use the CFGTCP command to configure your host table. Select option 10 (Work
with TCP/IP host table entries). Your system’s host table is stored in member
HOSTS of file QATOCHOST in library QUSRSYS.
Step 2—Start FTP to a Remote System
For example, if your host table defines the remote system as SYSNAM02, type the
FTP command as follows:
ftp sysnam02
Step 3—Tell FTP to Send the Host File to the Remote System
Type the following FTP subcommand:
put qusrsys/qatochost.hosts qusrsys/m03host.hosts
Note: Do not use FTP to put the host file directly into file QATOCHOST containing
the AS/400 host table.
Step 4—Merge the File
Type the following FTP subcommand:
quote rcmd mrgtcpht fromfile(qusrsys/m03host) frommbr(host)
Domain Name System (DNS) Server
The conversion from host name to Internet address can be performed by using the
host table on the local system or by defining a Domain Name System server, or
DNS server.
In large networks with large host tables, it is more convenient to have DNS servers
than to have a complete copy of the host table on every host in the network. As a
single source for host names, a DNS server is capable of storing the name and
address translations for all of the computers on your network. The DNS server is
the preferred alternative to managing host tables.
This chapter does not document DNS server functions. However, if you are
interested in more detailed information about Domain Name System server (DNS)
support on your AS/400 and configuring a DNS server see “Chapter 18. AS/400
Domain Name System (DNS)” on page 421.
IP Routing and Internet Control Message Protocol (ICMP) Redirecting
Internet routing tables usually remain static for long periods. TCP/IP generates
routing tables at activation time from configuration data and adjusts the routing
tables based on ICMP redirects, SNMP manager requests, dead gateway
processing and socket routing requests.
If network interconnections change, routing tables in a particular host may become
incorrect. Because gateways exchange routing information periodically to
accommodate network changes and to keep their routes up to date, a gateway
usually knows better routes than a host. When a gateway detects that a host is
using a route that is not optimum, the gateway sends an ICMP redirect message to
76
OS/400 TCP/IP Configuration and Reference V4R4
that host. It also forwards the original datagram on to its destination. Redirect
messages are limited to interactions between a gateway and a host on the same
network.
If the host that sends the original datagram is an AS/400, it receives the ICMP
redirect message from the gateway and uses this information to update its internal
routing table. The next datagram is then sent using the more optimum route
received from the gateway. You can see the updated routing table by using
NETSTAT, option 2. A route created by the ICMP redirect mechanism is recorded in
the IP dynamic routing table and remains there as long as an upper level protocol is
using it. When the last upper-level protocol user has completed its unit of work
using a route created by the ICMP redirect mechanism, the route is then removed
from the routing table. When TCP/IP is restarted, this process is repeated.
In Figure 55, host A1 in network 2 is an AS/400 system that sends a message to
host A2 in network 3. The routing table in host A1 indicates that the first hop to host
A2 is through gateway G1, which connects networks 1 and 2. When this gateway
receives the datagram, it forwards the datagram to gateway G2, which sends it to
the host A2. Gateway G1 then sends an ICMP redirect message to host A1 to
inform it that a better route to host A2 is to use gateway G2 as the first hop. This
information updates the internal routing table in host A1, and the next datagram to
host A2 in network 3 is sent to gateway G2 as the first hop. The gateway then
sends the datagram to host A2. When the TCP/IP services are stopped, the
collected routing information is deleted and host A1 starts the learning process
again.
Figure 55. Example of ICMP Redirect
To see routing changes due to ICMP redirect messages, select NETSTAT menu 2
or NETSTAT *RTE and then press PF11. Comparing the next hop in this display
with the next hop present in the routing table, you can verify whether a route has
been dynamically changed.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
77
Dead Gateway Processing
RFC-1122, Requirements For Internet Hosts - Communication Layers, requires the
IP layer to include a dead gateway algorithm to manage suspected gateway
failures. This section is intended to give you an overview of dead gateway
processing.
Two types of gateway failures can occur:
v Failure of a first-hop gateway. A first-hop gateway is the gateway that is specified
in an IP route. First-hop gateways must be on a directly-connected network. This
type of failure can be detected by either TCP or the data link layer.
v Failure of a gateway other than the first-hop gateway. The path between source
and destination TCP/IP hosts can traverse multiple gateways. This type of failure
can be detected only by TCP.
Dead gateway processing is initiated when IP receives a negative advice indicator
from either TCP or the data link layer. These indicators from TCP and the data link
layer are referred to as advice since they may result from transient conditions as
well as from a serious gateway failure.
Negative Advice from TCP or the Data Link Layer
Retransmissions on a TCP connection occur as a result of transient or non-transient
problems somewhere along the path to a destination host. When TCP notices
excessive retransmissions on a TCP connection, a TCP negative advice indicator is
sent to IP.
The data link layer passes a negative advice indicator to IP when it is unable to
transmit data to a first-hop (directly-connected) gateway. In most cases, negative
advice from the data link layer means that the Address Resolution Process (ARP)
processing performed by the data link layer was unable to resolve the location of
first-hop gateway on the directly connected physical network. (ARP is not performed
on all physical network types. Some physical network types, such as X.25, use an
alternative scheme for this purpose.)
Negative advice, whether from TCP or the data link layer, is always expressed in
terms of the first-hop gateway. Dead gateway processing on a given host only
attempts to verify the first-hop gateway. However, gateways also carry out their own
dead gateway processing for other adjacent gateways. In this way, all of the
gateways along the path to a destination host are taken care of.
How IP Responds to Negative Advice
When receiving negative advice from TCP or the data link layer concerning a next
hop gateway, IP marks all routes that use this gateway as suspect. IP attempts to
deliver data destined for the suspect gateway via routes that use other gateways (if
any are configured). Next, an IP process is started that uses periodic PING
requests to attempt to contact the suspect next-hop gateway. If the suspect
gateway continues to be unresponsive for an extended period of time, the
frequency of the PING requests is reduced.
When any PING response is received from a suspect gateway, the gateway is
considered active and the routes are restored.
78
OS/400 TCP/IP Configuration and Reference V4R4
Notes about IP Responses to Negative Advice:
1. If an ICMP redirect message is received during dead gateway processing,
routes to a suspect gateway may be temporarily restored. However, dead
gateway PING processing is not interrupted, and subsequent negative advice
forces the IP routing table back to its previously adjusted state.
2. Responses from user-initiated PINGs can also indicate that a suspect gateway
is active.
3. Negative advice is not passed from the UDP or RAW IP protocol machines.
Applications using these protocols must use other mechanisms to detect and
respond to apparent network problems. However, data link layer-negative advice
is still used to manage problems with the first-hop gateway.
Multihoming Function
A multihomed host has multiple IP addresses, which we may think of as logical
interfaces. These logical interfaces may be associated with one or more physical
interfaces, and these physical interfaces may be connected to the same or different
networks.
The AS/400 TCP/IP implementation supports multihoming. This allows you to
specify either a single interface or multiple interfaces for a line description. You can
have your AS/400 appear as any one or combination of the following scenarios:
v A single host on a network over a communications line
v Multiple hosts on the same network over the same communications line
v Multiple hosts on the same network over multiple communications lines
v Multiple hosts on different networks over the same communications line
v Multiple hosts on different networks over multiple communications lines
Note: The maximum number of interfaces that can be active on a line description
at any given time is 128. This is true for all line types (for example,
token-ring, Ethernet, frame relay, and so forth).
Example: A Single Host on a Network over a Communications Line
Your AS/400 system uses one adapter for TCP/IP to attach to a LAN or WAN
network. You add one TCP/IP interface. This TCP/IP interface includes the Internet
address of your AS/400 system. With this single Internet address, your AS/400
system is part of a single TCP/IP network (Figure 56).
Figure 56. Multihoming - Single Host, Single Network, Single Line
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
79
Example: Multiple Hosts on the Same Network over the Same
Communications Line
Your AS/400 system uses one adapter for TCP/IP to attach to a LAN or WAN
network. You add multiple TCP/IP interfaces. Each of these TCP/IP interfaces
includes an Internet address of the same TCP/IP network. With these multiple
Internet addresses your AS/400 system appears as multiple hosts in a single
TCP/IP network (Figure 57).
This can be a migration scenario.
Figure 57. Multihoming - Multiple Hosts, Single Network, Single Line
Example: Multiple Hosts on the Same Network over Multiple
Communications Lines
Your AS/400 system uses more than one adapter for TCP/IP to attach to the same
LAN or WAN network. You add multiple TCP/IP interfaces. At least one interface is
assigned to each adapter/line description. Each of these TCP/IP interfaces includes
an Internet address of the same TCP/IP networks. With these multiple Internet
addresses, your AS/400 system appears as multiple TCP/IP hosts in the same
TCP/IP network (Figure 58).
Figure 58. Multihoming - Multiple Hosts, Single Network, Multiple Lines
This scenario can be helpful for backup or to improve performance. However, there
is no dynamic backup or performance balance function.
80
OS/400 TCP/IP Configuration and Reference V4R4
Example: Multiple Hosts on Different Networks over the Same
Communications Line
Your AS/400 system uses one adapter for TCP/IP to attach to a LAN or WAN
network. You add multiple TCP/IP interfaces. Each of these TCP/IP interfaces
includes an Internet address of different TCP/IP networks. With these multiple
Internet addresses, you participate in different TCP/IP networks (Figure 59).
Figure 59. Multihoming - Multiple Hosts, Multiple Networks, Single Line
|
|
|
|
Imagine a public X.25 network. With this physical network, you can run multiple
different TCP/IP networks, for example the company intranet, and connections with
business partners and service providers. For each of these different TCP/IP
networks, your AS/400 system must configure a unique Internet address.
Running multiple TCP/IP networks within a single local area network (LAN) is also
supported. In most situations, however, one designs a single TCP/IP network per
physical LAN only.
Example: Multiple Hosts on Different Networks over Multiple
Communications Lines
Your AS/400 system uses more than one adapter for TCP/IP to attach to multiple
LAN or WAN networks. You add multiple TCP/IP interfaces. At least one interface is
assigned to each adapter/line description. Each of these TCP/IP interfaces includes
an Internet address of different TCP/IP networks. With these multiple Internet
addresses, you take part in different TCP/IP networks (Figure 60 on page 82).
This example is a combination of all of the previous examples discussed.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
81
Figure 60. Multihoming - Multiple Hosts, Multiple Networks, Multiple Lines
Example: The Multihoming function
Assume AS/400 systems SYSNAM02 and SYSNAM03 are connected with a public
or private X.25 network. The Internet address of this network is 9.4.73.64.
In this example, the AS/400 system SYSNAM03 connects with a service provider by
using TCP/IP and the same X.25 network attachment (Figure 61). The Internet
address assigned by the service provider for the AS/400 system is 223.1.1.17.
Figure 61. Multihoming TCP/IP Network
The multihoming function supports multiple networks with the same adapter. AS/400
system SYSNAM03 must handle two different Internet addresses on the same
attachment. To do this, an additional TCP/IP interface needed to be specified
(Figure 62 on page 83).
82
OS/400 TCP/IP Configuration and Reference V4R4
Work with TCP/IP Interfaces
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
__
__
__
__
5=Display
Internet
Subnet
Address
Mask
_______________
9.4.73.65
255.255.255.192
127.0.0.1
255.0.0.0
223.1.1.17
255.255.255.0
F3=Exit
F12=Cancel
F5=Refresh
F17=Top
F6=Print list
F18=Bottom
9=Start
System:
SYSNAM03
10=End
Line
Description
Line
Type
X25LINE
*LOOPBACK
X25LINE
*X25
*NONE
*X25
F11=Display interface status
Figure 62. Work with TCP/IP Interfaces Display, Multihoming
Type of Service (TOS)
Type of Service (TOS) is a parameter defined to indicate a quality of the service
desired by an application program. It is specified within a single octet of the IP
datagram header, and it is used to select Internet service. It denotes how the
Internet hosts and routers should make trade-offs between throughput, delay,
reliability, and cost.
TOS is used to identify and select the actual transmission characteristics for a
particular network, the interface, and the route to be used when routing an Internet
datagram. The TOS values are mapped into the actual TOS value of the particular
network a datagram is going through. All of the values are mutually exclusive.
The TOS values are defined through the Add TCP/IP Interface (ADDTCPIFC) and
Add TCP/IP Route (ADDTCPRTE) commands. The possible selections are as
follows:
*NORMAL
Normal service is used for delivery of datagrams.
*MINDELAY
Minimize delay means that prompt delivery is important for datagrams with this
indication.
*MAXTHRPUT
Maximize throughput means that high data rate is important for datagrams with
this indication.
*MAXRLB
Maximize reliability means that a higher level of effort to ensure delivery is
important for datagrams with this indication.
*MINCOST
Minimize monetary cost means that lower cost is important for datagrams with
this indication.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
83
The following table shows which type of services AS/400 uses for some of the
TCP/IP applications:
Table 7. AS/400 TCP/IP applications and Type of Services
Protocol or Application
Type of Service Used
TELNET
Normal
FTP (control connection)
Minimize delay
FTP (data connection)
Maximize throughput
SMTP (command phase)
Minimize delay
SMTP (data phase)
Maximize throughput
POP (all phases)
Maximize throughput
SNMP
Maximize reliability
Thus, TOS is a suggestion, not a demand, to the interface (if more than one is
present in the system) and to the routing algorithms. If a TCP/IP subsystem knows
more than one interface and more than one possible route to a given destination, it
uses the TOS to select one with characteristics closest to that desired.
TOS Example
For example, suppose the system can select between a low-capacity nonswitched
line or a high-bandwidth (but high delay) satellite connection:
v Datagrams carrying keystrokes from a user to a remote computer could have the
type of service set to *MINDELAY, requesting that they be delivered as quickly as
possible.
v Datagrams carrying a bulk file transfer could have the type of service set to
*MAXTHRPUT, requesting that they travel across the high-capacity satellite path.
It is up to the network administrator to define TOS values when defining interfaces
and routes in the TCP/IP configuration. Based on the administrator’s knowledge of
the hardware technologies available on systems and networks used, TOS values for
the routes must also be defined according to the interface’s TOS value. This means
that if a *MINDELAY value is defined in the interface definition, at least one route
definition must have the *MINDELAY TOS value defined.
Note: A TCP/IP network does not guarantee the TOS requested. However,
datagram transmission is never denied.
Multiple Routes
You can have multiple routes in your routing table (by using the ADDTCPRTE
command). You can have more than one route for the same destination Internet
address with the same type of service or a different type of service. If you have
multiple routes with the same types of service, they are used in the order specified.
If a particular next hop router is not available, the subsequent specified next hop
router is used. This continues until an entry that is active is found or the list of next
hop values is exhausted. If you have multiple routes with different TOS, the one
with the TOS equal to the one requested by applications with TOS octet in IP
datagram is used. If no match is found in any specified routes, the route with the
closest TOS or *NORMAL TOS is used.
You can have *DFTROUTE, and specific route destination addresses. Default
routes are used only when data is sent to a remote destination system that does
84
OS/400 TCP/IP Configuration and Reference V4R4
not have a specific route defined. The system allows up to eight default routes, but
each route must have a unique next hop value.
An example of a multiple route table can be found in Figure 63.
Work with TCP/IP Routes
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
_
_
_
_
_
_
_
Route
Destination
______________
*DFTROUTE
*DFTROUTE
*DFTROUTE
9.4.70.0
9.4.70.0
9.4.70.0
System:
SYSNAM003
5=Display
Subnet
Mask
______________
*NONE
*NONE
*NONE
255.255.255.0
255.255.255.0
255.255.255.0
Next
Hop
______________
9.4.73.193
9.4.73.197
9.4.73.196
9.4.73.194
9.4.73.195
9.4.73.198
F3=Exit
F5=Refresh
F6=Print list
F11= Display type of service F12=Cancel
Preferred
Interface
*NONE
*NONE
*NONE
*NONE
*NONE
*NONE
Bottom
F10=Work with IP over SNA routes
F17=Top
F18=Bottom
Figure 63. Work with TCP/IP Routes Display
TCP/IP Port Restriction
TCP and UDP protocols use ports to identify a unique origin or destination of
communication with an application. Each port is assigned a small integer. You can
configure port information if you want to restrict the use of a TCP or UDP port to
one or more user IDs.
The range of port numbers is from 1 to 65535. However, ports 0-1023 are reserved
as well-known port numbers, which are controlled and assigned by the Internet
Assigned Numbers Authority (IANA). Only those applications that have been
assigned one of these ports should use a number within this range. Refer to the
current Assigned Numbers RFC for a list of the port assignments.
Because this range of port numbers, 0-1023, is reserved for the well-known ports,
they should not be used by user application programs because it could affect the
operation of TCP/IP. For example, restricting the use of ports 21, 23, or 25,
prevents other users from using FTP, TELNET, or SMTP, respectively.
The AS/400 Add TCP/IP Port Restriction (ADDTCPPORT) command allows you to
restrict usage of a single port or a range of ports to a particular AS/400 user profile.
Restricting ports is like allocating ports to a specific user profile. When a socket
application issues the bind() system call, or when a TCP/UDP Pascal API
application issues a call to the TcpOpen, TcpWaitOpen, or UdpOpen function, the
job’s user profile is checked against the list of user profiles that are associated with
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
85
the specified port. If no match is found, the requesting program is not allowed to
use the specified port. If any port in the 1-1023 range is restricted, the following
message is posted:
Port restriction added but may affect TCP/IP processing
If no user profiles are associated with a specific port, there are no restrictions.
It is not necessary to configure port restrictions unless you are writing your own
TCP/IP applications and you want to reserve the use of the applications to certain
user profiles.
Note: For an installation in which user-written programs use ports other than the
well-known ports, you can consider restricting the use of the well-known
ports to the user profiles running the server application. As an example, for
File Transfer Protocol (FTP), this would be user profile QTCP.
Configuring TCP/IP Port Restrictions
To configure TCP/IP port restrictions, type option 4 on the Configure TCP/IP menu.
The Work with TCP/IP Port Restrictions display is shown (Figure 64).
Work with TCP/IP Port Restrictions
Type options, press Enter.
1=Add
4=Remove
Opt
_
F3=Exit
--Port Range--Lower
Upper
_____
*ONLY
1050
1059
F5=Refresh
Protocol
____
*TCP
F6=Print list
System:
SYSNAM03
User
Profile
__________
PAOLO
F12=Cancel
F17=Top
F18=Bottom
Bottom
Figure 64. Work with TCP/IP Port Restrictions Display
Type option 1 (Add) at the input-capable top list entry to get to the Add TCP/IP Port
Entry (ADDTCPPORT) display shown in Figure 65 on page 87. You can go directly
to this display by typing ADDTCPPORT on any command line and pressing F4.
86
OS/400 TCP/IP Configuration and Reference V4R4
Add TCP/IP Port Restriction (ADDTCPPORT)
Type choices, press Enter.
Range of port values:
Lower value . . . .
Upper value . . . .
Protocol . . . . . . .
User profile . . . . .
F3=Exit
F4=Prompt
F24=More keys
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1060
. > *ONLY
. *tcp
. gerry
F5=Refresh
1-65535
1-65535, *ONLY
*UDP, *TCP
Character value
F12=Cancel
Bottom
F13=How to use this display
Figure 65. Add TCP/IP Port Restriction Display
Let us assume we have an application that uses Port 1060 in the TCP layer and we
want to restrict its use to user profile GERRY. Type the information as shown in
Figure 65.
Figure 66 shows what the display looks like after you enter port information for both
user profiles PAOLO and GERRY.
Changes to the port restrictions take effect immediately. However, applications that
are already active are not affected until they are restarted.
Work with TCP/IP Port Restrictions
Type options, press Enter.
1=Add
4=Remove
Opt
_
F3=Exit
--Port Range--Lower
Upper
_____
*ONLY
1050
1059
1060
*ONLY
F5=Refresh
Protocol
____
*TCP
*TCP
F6=Print list
System:
SYSNAM03
User
Profile
__________
PAOLO
GERRY
F12=Cancel
F17=Top
F18=Bottom
Bottom
Figure 66. Work with TCP/IP Port Restrictions Display
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
87
Related Tables and the Host Table
Socket applications require a set of tables from which they can retrieve specific
TCP/IP network data when needed. These are as follows:
v Host table
v Service table
v Protocol table
v Network table
The host table contains a list of host names and corresponding Internet addresses.
Socket applications requesting host data obtain it either from the AS/400 host
database file or from the domain name server.
The service table contains a list of services and the specific port and protocol a
services uses. The protocol table contains a list of protocols used in the TCP/IP
network. The network table contains a list of networks and the corresponding
Internet addresses.
UNIX** systems traditionally store this information in the following files:
v
v
v
v
/etc/hosts - host table
/etc/protocols - protocol table
/etc/services - service table
/etc/networks - network table
AS/400 TCP/IP maintains the service, protocol, and network tables as database
files. AS/400 TCP/IP refers to these three tables as related tables. To configure or
view the protocol, services, or network tables, select option 21 (Configure Related
Tables) on the Configure TCP/IP menu. You are shown the display in Figure 67 .
Configure Related Tables
Select one of the following:
System:
SYSNAM03
1. Work with service table entry
2. Work with protocol table entry
3. Work with network table entry
Selection or command
===> ___________________________________________________________________
________________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
Figure 67. Configure Related Tables Menu
88
OS/400 TCP/IP Configuration and Reference V4R4
You can change the services, protocols, and network files using the options from
this display.
The services table stores the mapping of services to ports or ports to services as
shown in Figure 68. The mapping information is usually accessed with the
getservbyname() and getservbyport() socket functions.
Work with Service Table Entry
System:
Type options, press Enter.
1=Add
4=Remove
5=Display
Opt
Service
echo
finger
finger
ftp-control
ftp-control
ftp-data
ftp-data
gopher
gopher
graphics
graphics
pop3
Port
7
79
79
21
21
20
20
70
70
41
41
110
Parameters for options 1 and 4 or command
===>
F3=Exit
F4=Prompt
F5=Refresh
F6=Print list
F17=Top
F18=Bottom
SYSNAM03
Protocol
udp
tcp
udp
tcp
udp
tcp
udp
tcp
udp
tcp
udp
tcp
F9=Retrieve
More...
F12=Can
Figure 68. Work with Service Table Entry Display
The protocol table stores the mapping of protocol names to protocol numbers and
protocol numbers to protocol names. Socket applications use getprotobyname() and
getprotobynumber() functions to access this table (Figure 69 on page 90).
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
89
Work with Protocol Table Entry
System:
Type options, press Enter.
1=Add
4=Remove
5=Display
Opt
_
_
_
_
_
Protocol
_____________________________
icmp
ip
tcp
udp
SYSNAM03
Protocol
number
1
0
6
17
Bottom
Parameters for options 1 and 4 or command
===> ______________________________________________________________________
F3=Exit
F4=Prompt
F5=Refresh
F6=Print list
F9=Retrieve
F12=Cancel
F17=Top
F18=Bottom
Figure 69. Work with Protocol Table Entry Display
The network table contains the networks and the Internet address associated with
the network. Socket applications use the getnetbyname() and getnetbyaddr()
functions to access the information in the network table (Figure 70).
Work with Network Table Entry
Type options, press Enter.
1=Add
4=Remove
5=Display
Opt
_
_
Network
_____________________________________
IBM
System:
SYSNAM03
Internet
address
_______________
9.0.0.0
Bottom
Parameters for options 1 and 4 or command
===> ______________________________________________________________________
F3=Exit
F4=Prompt
F5=Refresh
F6=Print list
F9=Retrieve
F12=Cancel
F17=Top
F18=Bottom
Figure 70. Work with Network Table Entry Display
The protocols and services tables that are shipped contain standard information.
The network tables do not contain any information. The network IBM information
has been added in Figure 70, as an example.
90
OS/400 TCP/IP Configuration and Reference V4R4
For additional information about sockets, refer to the Sockets Programming,
SC41-5422-03 book.
Using X.25 PVC instead of SVC
In “Step 5—Configuring TCP/IP Remote System Information (X.25)” on page 36 you
were shown how to define the X.25 network address of each system that uses a
switched virtual circuit (SVC).
To replace the X.25 SVC with an X.25 permanent virtual circuit (PVC) connection,
the example below is helpful. The following CL commands will look different:
CRTLINX25, ADDTCPIFC, and ADDTCPRSI.
Use the same X.25 line description, but replace the first of the four SVCs with a
PVC.
CRTLINX25 LIND(X25LINE) RSRCNAME(LIN051)
LGLCHLE((001 *PVC) (002 *SVCBOTH)
(003 *SVCBOTH) (004 *SVCBOTH))
NETADR(40030003) CNNINIT(*LOCAL)
TEXT('ITSO X.25 Network')
The TCP/IP interface now points to a specific PVC instead of a pool of SVCs.
ADDTCPIFC INTNETADR('9.4.73.65') LIND(X25LINE)
SUBNETMASK('255.255.255.192') PVCLGLCHLI(001)
MAXSVC(0)
The TCP/IP remote system information no longer includes the X.25 address to be
called. Instead, the entry points to the PVC channel ID.
ADDTCPRSI INTNETADR('9.4.73.66')
PVCLGLCHLI(001)
IP Multicasting
IP multicasting is the process of transmitting an IP datagram to a host group. The
hosts that are in the group may reside on a single subnet or on different subnets
that are connected by multicast-capable routers. Hosts may join and leave groups
at any time. There are no restrictions on the location or number of members in a
host group. For more information about IP multicasting, refer to RFC 1112, Host
Extensions for IP Multicasting.
Note: The AS/400 cannot act as a multicast-capable router.
Multicast Application Programming Information
An application program can send or receive multicast datagrams by using the
Sockets API and connectionless, SOCK_DGRAM type sockets. Multicasting is a
one-to-many transmission method. You cannot use connection-oriented sockets of
type SOCK_STREAM for multicasting. When a socket of type SOCK_DGRAM is
created, an application can use the setsockopt() function to control the multicast
characteristics associated with that socket. The setsockopt() function accepts the
following IPPROTO_IP level flags:
v IP_ADD_MEMBERSHIP: Joins the multicast group specified.
Chapter 3. TCP/IP: Operation, Management, and Advanced Topics
91
v IP_DROP_MEMBERSHIP: Leaves the multicast group specified.
v IP_MULTICAST_IF: Sets the interface over which outgoing multicast datagrams
should be sent.
v IP_MULTICAST_TTL: Sets the time to live (TTL) in the IP header for outgoing
multicast datagrams.
v IP_MULTICAST_LOOP: Specifies whether or not a copy of an outgoing multicast
datagram should be delivered to the sending host as long as it is a member of
the multicast group.
For additional information about sockets, including sample programs, see the
Sockets Programming, SC41-5422-03 book. The System API Reference,
SC41-5801-03 documents the sockets API.
Multicast Restrictions
Multicast does not map well to all types of physical lines. For this reason, it is not
supported on all lines. For example, a switched network such as X.25 does not lend
itself to multicast applications because no mechanism exists for transmitting a
single packet to all systems in the network that have joined a group. IP multicast is
supported on broadcast capable networks and on SLIP/PPP interfaces, but it is not
supported on multi-access nonbroadcast networks. IP multicast is also not currently
supported on Frame Relay, FDDI/SDDI, or ATM networks. To determine whether an
interface supports multicast, enter option 14 on the Work with TCP/IP Interface
Status display. If the interface supports multicast, there will be at least one Host
Group entry for the All Hosts group 224.0.0.1. Otherwise, the interface does not
support multicast.
The 2626 token-ring input-output processor (IOP) requires manual configuration to
receive multicast datagrams. In particular, you must specify the token-ring address,
C00000040000, on the functional address parameter for the token-ring line
description. To add this address to a line description that is named TRNLINE, use
the following command:
CHGLINTRN LIND(TRNLINE)
FCNADR(C00000040000)
The 2617 Ethernet IOP also requires manual configuration in order to receive
multicast datagrams. The Ethernet group addresses to be received need to be
specified on the group address parameter (GRPADR) for the Ethernet line
description. A 4-byte IP multicast address is mapped to a 6-byte Ethernet group
address by placing the low-order 23 bits of the IP multicast address into the
low-order 23 bits of the Ethernet group address 01005E000000. For example, to
receive multicast datagrams with a destination address of 224.255.0.2, the
GRPADR parameter for the 2617 Ethernet line description must include
01005E7F0002.
92
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
|
|
|
|
Important note: A thorough and in-depth explanation of Point-to-Point is beyond
the scope and purpose of this document. The majority of material on Point-to-Point
is covered in the AS/400e Information Center under the TCP/IP topic. For more
information see “TCP/IP Topics in the Information Center” on page xv.
|
|
|
|
|
This chapter focuses on conceptual and reference information for the TCP/IP
Point-to-Point Protocol (PPP) and briefly describes its predecessor, the Serial Line
Internet Protocol (SLIP). This chapter does not document the procedures for AS/400
configuration and implementation of the PPP protocol. Those procedures are
covered in the AS/400e Information Center under the TCP/IP topic.
Networks and Point-to-Point Connections
When only two systems are physically connected, this is typically referred to as a
point-to-point connection or link. Several different protocols, such as PPP, SLIP,
X.25, and frame relay, can be viewed as point-to-point protocols. Support for
Point-to-Point (PPP) protocol is included in AS/400 as part of wide area network
(WAN) connectivity. A common example is a PPP connection that is established
periodically over a phone line from a remote office to a central office in order to
exchange data between the locations. This connection could be from a laptop
computer. Remote systems can access AS/400 applications such as Lotus Notes
over a PPP TCP/IP link. Figure 71 illustrates AS/400 responding to incoming calls.
Figure 71. Remote Systems Dial-in to an AS/400
Another common example of a PPP WAN connection is a dial-out connection that
your system establishes to an Internet Service Provider (ISP), such as the IBM
Global Network (IGN) (see Figure 72 on page 94.)
© Copyright IBM Corp. 1997, 1999
93
Figure 72. AS/400 Dial-out to an ISP
A wide area network (WAN) is usually distinguished from a local area network
(LAN) in that physical communications is limited to two systems. The
communications line between the two systems can be a direct connection such as a
leased telephone line. However, it is more common to connect two systems by a
dial-up telephone connection. A dial-up connection between systems is also known
as a switched connection. For a switched line, the connection turns on or off
depending on whether a phone connection has been established. In the case of a
leased line, the connection between the two systems is always available.
PPP versus SLIP
Serial Line Internet Protocol (SLIP) is the result of early attempts to connect two
systems using TCP/IP over an asynchronous line. SLIP is described in Request for
Comment (RFC) 1055, A Nonstandard For Transmission of IP Datagrams Over
Serial Lines: SLIP. This RFC defines a simple framing method for IP packets
flowing over a serial line. SLIP is not an Internet standard.
The SLIP RFC never became an Internet standard because it has several
deficiencies that are discussed in the RFC. Some of those deficiencies are as
follows:
v No standardized mechanism for hosts to communicate addressing information
v No support for network protocols other than TCP/IP
v No support for system authentication
v No support for packet error detection, error correction, or compression
While SLIP is still used today, IBM does not encourage you to use it. PPP corrects
all of the SLIP deficiencies. PPP is an Internet standard and the predominant
connection protocol used today among Internet Service Providers.
94
OS/400 TCP/IP Configuration and Reference V4R4
One goal of PPP is to allow interoperability among the remote access software of
different manufacturers. Another goal is to allow the same physical communication
line to be used by multiple network communication protocols.
Requirements for AS/400 SLIP
You need two or more computers that support the SLIP protocol. The following is a
summary of AS/400 requirements for Serial Line Internet Protocol (SLIP):
v The correct communications ports and adapters must be installed on AS/400.
v A connection must be established using either a switched line or a direct leased
line.
v A modem to send and receive data over the connection. “Connection
Alternatives” on page 111 contains a brief overview of data transmission
equipment available at the time of this writing.
v If you plan to connect to the Internet, you must have a dial-up account with an
Internet Service Provider (ISP).
Note: Many PCs have an internal modem that is equipped with the serial port.
AS/400 does not support an internal modem. You must use an external
modem connected to your AS/400 by one of the required I/O Adapters (IOA).
Point-to-Point Request for Comments (RFC)
A sample of related Request for Comments (RFC) are:
v RFC 1661, The Point-to-Point Protocol (PPP), describes the base structure for
PPP communications.
v RFC 1662, PPP in HDPC-like Framing, describes PPP packet encapsulation over
asynchronous and synchronous communication lines.
v RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP),
describes system authentication.
Line Pools
In the Point-to-Point Protocol (PPP), a line pool is a list of lines that are used by a
connection profile.
You can use a line pool instead of defining a particular line description to a
connection profile. The connection profile selects an available line from the line pool
when the profile is started.
Advantages of using line pools:
v You are not committing a line resource to a connection profile until it is started.
For connection profiles using a specific line, the connection profile ends if the line
is not available. For connection profiles that use a line pool, only one line in the
line pool must be available when the profile is started.
v You can use dial-on-demand profiles with line pools to use resources more
efficiently.
A line is selected from the line pool only when a dial-on-demand connection is
required. At other times, the same line can be used by other connection profiles.
v You can start more profiles than you have resource to support.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
95
Let us say your environment needs four dial-on-demand connection profiles, but
you only need two lines available at one time. You could create a line pool for
two of the four lines, so two connections profiles are active at any time. By using
a line pool, you do not need to have four lines available at the same time.
Configuring Point-to-Point Network Connections
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
Configuring PPP Connection Profiles
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
Accessing Point-to-Point functions through Operations Navigator
You can access Point-to-Point (PPP) functions from a command line interface or
Operations Navigator (graphical user interface). Not all PPP functions are available
on both interfaces, and most PPP functions are available only through Operations
Navigator. Operations Navigator functions are not documented here.
To access the Point-to-Point Profile Properties dialogs, perform the following
tasks:
1. Start Operations Navigator.
2. Double-click your AS/400 server in the main tree view of Operations Navigator.
3. Double-click Network.
4. Double-click Point-to-Point.
5. Right-click Connection Profiles to open a context menu.
6. Select New Profile to open the New Point-to-Point Profile Properties dialog.
Click the desired tab to define properties.
Checking for existing PPP Connection Profiles
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
96
OS/400 TCP/IP Configuration and Reference V4R4
PPP Configuration Scenarios
Example: Configuring Windows 95/98 to an AS/400 using a PPP
Connection
|
|
|
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Example: Connecting to the Internet using an ISP
You can connect an AS/400 to the Internet by using an Internet Service Provider
(ISP). While there are many ISPs in service today, this example uses the IBM
Global Network (IGN) as a service provider. IGN requires an account, user ID, and
password. Other Internet Service Providers (ISP) may have different requirements.
The connection to the ISP is switched line-dial.
Access Point-to-Point functions through Operations Navigator.
From the General page, perform the following tasks:
v Specify DialIGN in the ″Name″ text box.
v Specify IGN (IGN-ISP) in the ″Description″ text box to describe the connection
profile in more detail.
v Select PPP under Type.
v Select Switched line-dial under Mode. This allows you to dial out to the remote
system.
Click the Connection tab.
v To specify the remote phone number for the IGN or another ISP, click Add and
specify the phone number.
If you need to dial a special number to reach an outside line, typically the outside
line number is followed by several commas. The commas determine how many
seconds the modem must wait for the dial tone before it begins dialing. You can
also use dashes in the phone number.
A remote phone number can be any of the following:
– Local company extension (for example, 34567)
– Outside phone number (for example, 9,1234567)
– Long distance number (for example, 1-800-1234567)
v In the ″Name″ field, select the appropriate line name, such as IGN_Dial.
If you need to configure a new line description, specify the name and click Open.
For more information, see “Configuring Point-to-Point Network Connections” on
page 96.
v You can disconnect from the ISP after a certain period of time by overriding the
line inactivity timeout. To do this, select ″Override line activity timeout″ and
specify the ″Timeout″ value in seconds. In this way, you will not be charged by
the ISP for idle time.
Click the TCP/IP Settings tab.
v Select Dynamically assign to indicate that you want IGN to dynamically assign
both the local and remote IP addresses.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
97
v Click Routing to open the Routing dialog.
v For static routing, specify Add remote system as the default route. Since you
do not know the range of destination IP addresses, you need a default route.
This is the desired configuration when AS/400 dials in to an ISP such as IGN.
The default route forwards packets to the ISP router, which in turn routes the
packets throughout the Internet.
Click the Authentication tab.
v Check ″Enable local system identification.″ IGN requires customers to use the
Password Authentication Protocol (PAP) for authentication. This verifies the
identity of the customer who is using an unencrypted password.
v Specify both a user ID and a password. In this example, the user name is
internet.account.userid. Other ISPs may use CHAP, which uses an encrypted
password. Consult your ISP to learn its requirements for specifying a user name
and password.
Click the Domain Name Server tab.
v Specify the IP address for the Domain Name Server. In this example, the IP
address is 10.11.27.5. When you use an Internet Service Provider (ISP) to
connect to the Internet, you will receive a name server address from the ISP.
This allows you to connect using host names instead of IP addresses for remote
sites. A host name is a way of identifying a system and its IP address.
Example: Connecting two AS/400s using dial-on-demand
In this example, System 1 is a local system with IP address 10.11.25.1 and System
2 is a remote system with IP address 10.11.25.2. To establish a connection:
1. Configure a Dial-only connection profile on System 1.
2. Configure a Switched line-answer connection profile on System 2.
3. Start connection profiles on System 1 and System 2 by using Operations
Navigator.
4. Verify configurations on System 1 and System 2 by using TELNET.
Configure a Dial-only connection profile on System 1
1. Access Point-to-Point functions through Operations Navigator.
2. From New Point-to-Point Profile Properties dialog, click the General tab and
do the following:
v Type DODBP in the Name text box.
v Type Basic Dial on Demand Profile in the Description text box.
v Under Type, select PPP.
v Under Mode, select Dial-on-demand (dial only).
3. Click the Connection tab and do the following:
v Type the phone number of the remote system.
v Under Line, select a line pool from the Name list.
v Select Override line activity timeout and specify 300 seconds, or five
minutes, as the Timeout value.
4. Click the TCP/IP Settings tab and then do the following:
v Under Local IP Address, click the radio button and type 10.11.25.1 in the
text box.
v Under Remote IP Address, the Remote IP Address is 10.11.25.2.
98
OS/400 TCP/IP Configuration and Reference V4R4
v Check Allow IP forwarding.
5. Click the Authentication tab and then ensure that local and remote system
identification are not checked.
6. Click OK to save the configuration.
Configure a Switched line-answer connection profile on System
2
1. Access Point-to-Point functions through Operations Navigator.
2. From New Point-to-Point Profile Properties dialog, click the General tab and
then do the following:
v Type DODANS in the Name text box.
v Type Basic Answer Profile in the Description text box.
v Under Type, select PPP.
v Under Mode, select Switched line-answer.
3. Click the Connection tab and then select a line description from the Name list.
4. Click the TCP/IP Settings tab and do the following:
v Under Local IP Address, click the radio button and type 10.11.25.2 in the
text box.
v Under Remote IP Address, the Remote IP Address is 10.11.25.1.
v Check Allow IP forwarding.
5. Click the Authentication tab and then ensure that local and remote system
identification are not checked.
6. Click OK to save the configuration.
Start connection profiles on System 1 and System 2
Once you have started the connection profiles, each connection profile has the
following status:
v System 1: DODBP connection profile: Waiting for dial-Switched line-dial on
demand
v System 2: DODANS connection profile: Waiting for incoming call
Verify configurations on System 1 and System 2 using TELNET
Use TELNET to verify that you can dial and connect to System 2 from System 1
using the DODBP and DODANS connection profiles.
v From the command line on System 1, type
TELNET '10.11.25.2'
and press Enter.
The AS/400 logon screen on System 2 displays if the connection is successful.
The TELNET session ends after 5 minutes of inactivity. Both connection profiles are
reset and wait for the next call.
While the DODBP profile is in the Waiting for dial — Switched line-dial on demand
status, System 1 will dial System 2 when IP packets arrive for System 2.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
99
Example: AS/400 Office-to-Office Scenarios
In this scenario, AS400 (LCL400) is set up to answer incoming calls from one of the
following:
v Another AS400 (RMT400), along with its Ethernet and token-ring network
v A remote gateway, along with the Ethernet network attached to it
v An individual remote user
Figure 73. Office-to-Office Remote Connection
This can be accomplished using one connection, such as a phone line with an
attached modem, and only one point-to-point connection profile on LCL400. This is
done by configuring LCL400 to administer different remote IP addresses and routes
based on the incoming caller’s user ID. Since the user ID is used, the remote
system dialing in must use some sort of authentication. For SLIP, this would be
done with a connection script.
This example uses a PPP connection using CHAP authentication. This
authentication protocol was chosen to ensure that only encrypted authentication
information is passed between the systems.
You can configure LCL400 to accept calls from many other user IDs as well, giving
it the flexibility of having tailored IP address and routes for each caller’s
environment. Figure 73 shows an example of this configuration.
Scenario Definitions
Office-to-Office Connection (RMT400 - LCL400)
RMT400 is a remote office with a Token Ring and Ethernet network attached to
it. Either periodically or for a specified time period during the day, RMT400 dials
into LCL400 using a PPP connection. The users in the remote office need to be
able to access LCL400 as well as the 10.1.1.0 Ethernet network attached to
LCL400. Conversely, the users on the 10.1.1.0 network need access to the
10.2.1.0 and 10.2.2.0 networks attached to RMT400. Information about how to
configure both LCL400 and RMT400 to accomplish this task is covered shortly.
Remote User to Office (LCL400)
A remote user could be any user who dials into LCL400 from a PC or
workstation. For example, a remote user is someone who is travelling and
wishes to connect to the home office. The user dialing in also needs access to
the 10.1.1.0 Ethernet network that is attached to LCL400.
100
OS/400 TCP/IP Configuration and Reference V4R4
Remote Network to Office (LCL400)
Remote Gateway (non-AS400) is a gateway that is attached to an Ethernet
network. Remote Gateway could call LCL400 during the night to allow systems
on the Remote Gateway’s Ethernet network (192.68.2.0) to transfer files to
either LCL400 or its attached network. Remote Gateway also allows the
forwarding of mail to a mail server on the 192.68.2.0 network.
Configuring LCL400 for all Scenarios
Access Point-to-Point functions through Operations Navigator.
From the General page, perform the following tasks:
v
v
v
v
Specify a profile name (LCL400 for this example).
Select PPP as the ″Type.″
Specify Switched line-answer as the ″Mode.″
(Optional) Specify a description.
From the Connection page, perform the following tasks:
v Select an existing PPP line from the drop-down box and click Open. In this
example, the line 400ANSWER is used.
If an existing line does not exist, you can create a new one by specifying the
name and clicking New.
v From the Modem page on the Line Properties dialog, select a modem from the
modem name pull-down box and click OK.
From the Authentication page, perform the following tasks:
v Select ″Require remote system identification.″
v Ensure that CHAP only is selected.
v Select an existing validation list from the validation list drop-down box and click
Open. In this example, the validation list OFFICE_400 is used.
If a new validation list is required, create a new one by specifying the name and
clicking New.
Figure 74 shows the Validation List dialog.
Figure 74. Validation List
The following values hold true for this example of the Validation List dialog:
v The user IDs RMTOFFICE and RMTGATEWAY have been added for CHAP
authentication.
v RMTOFFICE is the user ID for RMT400 to dial in to LCL400.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
101
v RMTGATEWAY is the user ID that is used by the remote gateway to dial in to
LCL400.
From the TCP/IP Settings page, perform the following tasks:
v Set your local IP address. In this example, the existing Ethernet interface
10.1.1.1 is selected from the ″Local IP address″ pull-down box.
v Set your remote IP address. In this example, ″Route specified″ is selected. This
signifies that remote IP addresses will be defined from entries that are defined
from the Routing dialog.
Note: ″Route specified″ is valid only for Switched Line-Answer profiles.
v Check ″Allow IP forwarding.″ IP packets that originate from the remote system
will be allowed to flow through LCL400 to the 10.1.1.0 network.
v Click Routing to add the ″Route specified″ IP addresses.
Figure 75 shows the Routing dialog.
Figure 75. Routing
The following values hold true for this example of the Routing dialog:
v RMTGATEWAY user ID (from the Remote Gateway)
When user RMTGATEWAY dials in, he or she receives IP address 192.168.2.6. A
subnet mask of 255.255.255.0 was used to allow LCL400 to add a direct route to
the 192.168.2.0 network that is attached to the Remote Gateway.
v RMTOFFICE user ID (from system RMT400)
When user RMTOFFICE dials in, he or she receives IP address 10.2.1.1. A
subnet mask of 255.255.255.0 was used to allow LCL400 to add a direct route to
the 10.2.1.0 network that is attached to RMT400.
A route was defined for RMTOFFICE. The destination network is 10.2.0.0 with a
subnet mask of 255.255.0.0. This route is added when RMTOFFICE dials in and
allows LCL400 to have access to any 10.2.x.x network that is attached to
RMT400. In this scenario, this would include the 10.2.1.0 network, which is also
covered by the direct route that was added for the interface, as well as the
10.2.2.0 network. If any other 10.2.x.x networks are added to RMT400, the
necessary route to reach them is already defined.
102
OS/400 TCP/IP Configuration and Reference V4R4
In this scenario, the IP addresses that are used for the PPP connection allow for
what is known as an ’Unnumbered Net.’ It is called this because no new
networks or IP addresses were created for the connection. The IP address of the
Ethernet connection to LCL400 (10.1.1.1) is used as the remote address for
RMT400. The IP address of the Ethernet connection to RMT400 (10.2.1.1) is
used as the remote address for LCL400.
v If a user other than RMTOFFICE or RMTGATEWAY dials in, then he or she
receives IP address 10.1.1.99. This is accomplished by using the wildcard user
entry * (asterisk), which indicates that if the caller’s user ID is not found in the
list, then this IP address is used as the default. This action assumes the user has
been previously added to the OFFICE_400 validation list.
In the scenario, the remote user receives 10.1.1.99 as the IP address. He or she
also has access to the 10.1.1.0 network with no additional routing required.
Note: 10.1.1.99 has a subnet mask of 255.255.255.255 and is a subset of the
local 10.1.1.0 network. This is known as ″transparent subnetting″ (also
known as Proxy ARP) and allows for the remote user to appear to be on
the same Ethernet network that is attached to LCL400. See the example
in “Example: Remote LAN Access with Transparent Subnetting” on
page 104 for additional information about transparent subnetting.
If only explicitly defined callers can dial in, then you should omit the * entry. All
other callers are then denied access to LCL400.
Configuring RMT400 to Dial into LCL400
Access Point-to-Point functions through Operations Navigator.
From the General page, perform the following tasks:
v Specify a profile name (RMT400 for this example).
v Select PPP as the ″Type.″
v Specify Switched line-dial as the ″Mode.″
v You have the option of specifying a description.
From the Connection page, perform the following tasks:
v In this example, the phone number to connect to LCL400 is 798-1234. The (dash) is optional.
v Select an existing PPP line from the drop-down box and click Open. In this
example, the line 400DIAL is used.
If an existing line does not exist, you can create a new one by specifying the
name and clicking New.
v From the Modem page on the Line Properties dialog, select a modem from the
modem name pull-down box and click OK.
From the Authentication page, perform the following tasks:
v Select ″Enable local system identification.″
v Ensure that CHAP only is selected.
v The user ID that will be used to identify RMT400 when it dials a remote system
is RMTOFFICE.
Note: The user ID and password must be the same as those that you defined in
the OFFICE_400 validation list on LCL400.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
103
From the TCP/IP Settings page, perform the following tasks:
v Set your local IP address. In this example, the existing Ethernet interface
10.2.1.1 is selected from the ″Local IP address″ pull-down box.
v Set your remote IP address. In this example, ″Dynamically assigned″ is selected.
The remote system, LCL400, defines the address that RMT440 uses when the
connection is established.
The remote address of 10.1.1.1, which is the local Ethernet IP address for
LCL400, could have been defined statically for RMT400. If this address ever
changes, however, you must update the profile. The value ″Dynamically
assigned″ allows it to work for whatever address LCL400 has specified.
v Since you need to define additional routes, click Routing.
Figure 76 shows the Routing dialog.
Figure 76. Routing
The following values hold true for this example of the Routing dialog:
v Select ″Use static routes″ Static routing. If RMT400 only ever called LCL400,
then you could have selected ″Add remote system as the default route.″ This
ensures that all TCP/IP traffic would go to LCL400 if not otherwise defined. In
this example, however, assume that RMT400 has other point-to-point profiles that
can call other remote systems at the same time. Therefore, we want to define
network routes to the remote networks.
v A route is defined for remote network 10.1.0.0 with a subnet mask of
255.255.0.0. This route is added when the connection is made with LCL400. All
TCP/IP traffic for hosts on the 10.1.x.x network are sent to LCL400. Currently,
this is only 10.1.1.0. If other 10.1.x.x networks are added to LCL400 in the future,
then no further routing will need to be defined to reach hosts on the other
networks.
Example: Remote LAN Access with Transparent Subnetting
Transparent Subnetworking allows remote clients who are on separate LANs to
communicate with one another as if they were on the same physical network. To
accomplish transparent subnetworking from the home network, you must partition
blocks of addresses for each remote site. The subnet and the host are the two
levels of hierarchical addressing. The boundary between them is arbitrary.
104
OS/400 TCP/IP Configuration and Reference V4R4
For example, you can have 255 partitions with each partition having 255 host
addresses available. You can then manage which partitions are assigned to remote
networks. Each remote network partition is mapped to the subnet (see Figure 77).
AS/400 hides the fact that the remote networks are physically located behind
AS/400. It will then act as a proxy and forward the datagram packets to the remote
networks. When transparent subnetting is put into effect, the remote host appears
to be part of the physical corporate network.
Transparent subnetworking is useful in environments in which it is either impractical
or impossible to run routing protocols. Such a situation might occur in a bridged
network or in networks that are running unsupported proprietary dynamic routing
protocols. This is best suited for leased line connections when remote sites need to
communicate with one another. If remote sites do not need to communicate with
each other, however switched line connections are viable.
Figure 77 shows an example of how an network configuration could use transparent
subnetting for remote LAN access.
Figure 77. Example Configuration for Remote LAN Access with Transparent Subnetting
Note: This diagram shows PPP links carrying out unnumbered networking. The IP
address that is used to connect the home network (10.5.0.0) to AS/400
(10.5.0.1) with a subnet mask of 255.255.0.0 is the same local IP address
that is used for all remote dial-up connections. No IP addresses are required
to be assigned to the PPP links.
The following steps are an example of how to configure AS/400 to connect to
multiple LAN subnets. The example uses a single PPP answer profile to put
transparent subnetting into effect, based on Figure 77.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
105
Creating a Point-to-Point Profile for LAN Transparent Subnetting
Access Point-to-Point functions through Operations Navigator.
From the General page, perform the following tasks:
v Specify a profile name (REMOTE_ABC for this example).
v Specify a description for the connection profile (Answer profile For Remote Box
A, B, or C in this example).
v Select PPP as the ″Type.″
v Select Switched line-answer as the ″Mode.″
From the TCP/IP Settings page, perform the following tasks:
v Specify your ″Local IP address.″ Since this example is Unnumbered Net, an
existing token-ring interface, 10.5.0.1, is selected from the ″Local IP address″
pull-down box.
v Specify your ″Remote IP address.″ In this example, Route specified is selected.
Remote IP addresses will be defined from the entries that are defined in the
Routing dialog.
Note: Route specified is valid only for switched line-answer profiles.
v Check ″Allow IP forwarding.″ IP packets that originate from the remote LAN are
allowed to flow through AS/400 to the ″Corporate Network″ or other remote
LANs.
Click Routing to add entries to the Route specified IP addresses. From the
Routing page, perform the following tasks:
v For ″Dynamic routing,″ select None. Routing will be carried out through static
routing.
v For ″Static routing,″ select Use static routes:
– Caller REMOTE_A receives IP address 10.5.1.1. A subnet mask of 255.255.255.0
allows AS/400 to add a direct route to the 10.5.1.0 network.
– Caller REMOTE_B receives IP address 10.5.2.1. A subnet mask of 255.255.255.0
allows AS/400 to add a direct route to the 10.5.2.0 network.
– Caller REMOTE_C receives IP address 10.5.3.1. A subnet mask of 255.255.255.0
allows AS/400 to add a direct route to the 10.5.3.0 network.
Note: You can add more routes if additional LANs are attached to AS/400
through subnetting.
Figure 78 on page 107 shows the Routing dialog.
106
OS/400 TCP/IP Configuration and Reference V4R4
Figure 78. Example Routing for Transparent Subnetting
Validation List: Click the Authorization tab; then click New or Open to enter
authorization information.
1. Add a validation list for remote LANs A, B, and C by using PAP or CHAP
authentication.
2. Click OK when the validation list is completed.
3. Click OK to close the connection profile properties page.
Example: Remote LAN Access with Dynamic Routing (RIP)
Remote LAN access with dynamic routing allows remote clients on separate LANs
to communicate with one another as if they were on the same routing domain. It
enables any host in the corporate network to communicate with any remote LAN
host. Dynamic routing from the home network places no address restrictions on the
remote network. Further, there is no need for a hierarchical address scheme or
relationship from the host to the home address space.
The home network is able to learn about the remote networks by using a dynamic
routing algorithm within the home network using RIP 1 or 2. This is accomplished
by the home network updating its routing tables as information is extracted from the
remote networks static routing table.
The number of remote networks directly affects the size of the dynamic routing
tables. No dynamic routing protocols run on the remote PPP links. Instead, they are
run by AS/400 and the corporate network. The routing protocol automatically
redistributes remote routes throughout the corporate network.
A solution where the corporate network is running RIP 1 or 2 as its routing protocol
and the remote links are connecting to a small amount of networks would be to
implement remote LAN access with dynamic routing. If RIP 1 or 2 is being run in
AS/400, the static routes will automatically be redistributed. This eliminates the
need to run RIP over the remote links.
Figure 79 on page 108 shows an example of how a network configuration could use
RIP for remote LAN access.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
107
Figure 79. Example Configuration for Remote LAN Access with Dynamic Routing (RIP)
Creating a Point-to-Point Profile for LAN Access with Dynamic
Routing (RIP)
Access Point-to-Point functions through Operations Navigator.
From the General page, perform the following tasks:
v Specify a profile name (REMOTE_ABC for this example).
v Select PPP as the ″Type.″
v Select Switched line-dial as the ″Mode.″
From the TCP/IP Settings page, perform the following tasks:
v Specify your ″Local IP address.″ Since this example is Unnumbered Net, an
existing token-ring interface, 10.5.0.1, is selected from the ″Local IP address″
pull-down box.
v Specify your ″Remote IP address.″ In this example, Route specified is selected.
Remote IP addresses are defined from the entries that are defined in the
Routing dialog that appears when you click Routing.
Note: Route specified is valid only for switched line-answer profiles.
v Check ″Allow IP forwarding.″ IP packets that originate from the remote LAN are
allowed to flow through AS/400 to the ″Corporate Network″ or other remote
LANs.
Click Routing to add entries to the Route specified IP addresses. From the
Routing page, perform the following tasks:
v For ″Dynamic routing,″ select None. Routing will be accomplished through static
routing. RIP is used within the ″Corporate Network″ but not on remote links.
v For ″Static routing,″ select Use static routes:
– Caller REMOTE_A receives IP address 192.168.4.1. A subnet mask of
255.255.255.0 allows AS/400 to add a direct route to the 192.168.4.0 network.
108
OS/400 TCP/IP Configuration and Reference V4R4
– Caller REMOTE_B receives IP address 192.168.139.1 A subnet mask of
255.255.255.0 allows AS/400 to add a direct route to the 192.168.139.0
network.
– Caller REMOTE_C receives IP address 192.168.57.1. A subnet mask of
255.255.255.0 allows AS/400 to add a direct route to the 192.168.57.0
network.
Note: You can add more routes if additional LANs are attached to AS/400
through subnetting.
Figure 80 shows the Routing dialog.
Figure 80. Example Routing for Dynamic Routing
Monitoring Activity
You use Operations Navigator to create, change, view, start or stop a PPP
connection profile using the new PPP line type. After you configure a PPP
connection profile, you can start, stop, or delete it. To do this, right click the
connection profile you want in Operations Navigator’s tree view. Then, select Start,
Stop, or Delete from the context menu.
The Connection Profile list also allows you to monitor several things about a
point-to-point job by scrolling left or right on the window. The Status indicator tells
whether the connection is starting, in use, or ending. A value of Inactive specifies
that no jobs are currently running for that profile. A value of Ended - information
available, on the other hand, indicates that the connection has ended and that
information is available for that job. Examples of other status values that occur
while the job is running include Session job starting, Waiting for incoming call,
and Active.
Scroll to the right in the Connection Profile list to display more information. From
here, information can be gathered about a particular job. By using a combination of
the values for Job number, Job user, and Job, you can look at additional information
such as Point-to-Point Messages, Jobs, and Printer Output information. For
additional information, see “Point-to-Point Jobs” on page 110.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
109
Point-to-Point Jobs
You can look at messages and jobs in Operations Navigator’s tree view.
Messages
To display a list of messages as a result of a job, click Messages in Operations
Navigator tree view.
The first time you display this dialog, the messages will be for the current user.
However, these jobs run in the QSYSWRK subsystem under user QTCP. Therefore,
it is necessary to display the messages for QTCP to see the messages for the job.
To display messages for QTCP, select Include from the Options menu.
Select ″User name″ and specify QTCP in the space. Click OK. You will be returned to
the Include dialog. Click OK. ″Messages for QTCP″ will be displayed in the
message line. From here, you will be able to see messages pertaining to the profile
that you have started or stopped. Find the message that you are interested in and
double-click it in the From user column. This will bring up the detailed message
information dialog with a thorough explanation of the message.
Jobs
To look at information for an active job or a job that has completed, click Jobs in
Operations Navigator tree view. You will now have to perform a similar search as
you did for messages.
Select Include from the Options menu. For an active job, fill in ″User″ with QTCP,
″Job name″ with All, and click OK. In addition for a completed job, select Yes for
″Show completed jobs with printer output.″
A list of all jobs for QTCP will be displayed on the right side of the window. From
here, you can look at the information that is available for the job.
Point-to-point job names start with the string QTPP, where dial-out jobs are
QTPPDIALnn and dial-in jobs are QTPPANSnn. The number string nn is sequential
from 1 to 99. Find your job name in the list and right-click the desired job name.
From the context menu, select Job Log for an active job.
Double-clicking a Message ID value displays detailed message information.
Double-clicking the Output name value displays a viewer dialog with information on
the completed job.
Printer Output
To look at printer output for a job that has completed, click Printer Output in
Operations Navigator tree view. Next, select Include from the Options menu. Fill in
the user with QTCP as explained in “Messages” and click OK. From here, you can
look at the User specified data column and find your job name. Double-clicking the
Output name value displays information about the job.
110
OS/400 TCP/IP Configuration and Reference V4R4
If you wish to narrow your search and do not wish to see all QTCP jobs, you can
specify AS/400 job name on the Include dialog. The job name consists of three
parts: Job number, Job user, and Job name.
Optional Monitoring of Point-to-Point Activity
An optional method to monitor activity for Point-to-Point connection profiles is to
invoke option 14 from the Work with Point-to-Point TCP/IP (WRKTCPPTP)
command on a 5250 AS/400 console. For more information about this option, see
“Monitoring Point-to-Point Activity” on page 134.
Connection Alternatives
This section provides you an overview of the link layer connection alternatives
available to you.
Point-to-point links establish a physical connection between a local and remote
host. When connected, these links provide dedicated bandwidth and come in a
variety of data rates and protocols. With point-to-point links, you can choose from
dial-up analog modem connections, leased analog lines, and switched and leased
digital services of various kinds.
PPP is a method of transmitting datagrams over serial point-to-point links. PPP
enables interconnection of multiple vendor equipment and multiple protocols by
standardizing point-to-point communications. The PPP data link layer uses
HDLC-like framing for encapsulating datagrams over both asynchronous and
synchronous point-to-point telecommunication links.
While PPP supports a wide range of link types, SLIP is limited to asynchronous link
types. SLIP is generally employed only for analog links.
Local telephone companies offer traditional telecommunications services in an
ascending scale of capabilities and cost. These services use existing telephone
company voice network facilities between customer and central office. A comparison
of communication services and their relative costs is shown in Table 8. The costs
shown are not intended to reflect current pricing. Instead, they are intended to
show relative differences between services. Cost rates on leased lines are usually
distance-based, while the switched lines may also be time-based.
Note: The following table is for illustration purposes only. It does not include all
supported AS/400 configurations. The costs shown are not intended to reflect
current pricing.
Table 8. Comparison of communication services and relative costs
Service
Line Speed
Required
Equipment
DTE/DCE
Interface
Relative Cost
(per month)
Analog (leased
and switched)
33.4Kbps or less Modem
RS232
asynchronous
Digital Data
Service (DDS)
56.0Kbps or less CSU/DSU
X.21/V.35/RS$50-$500
449 synchronous
Switched-56
56.0Kbps
CSU/DSU with
V.25bis dial
V.35/RS-449
synchronous
$20-$150
$50-$250
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
111
Table 8. Comparison of communication services and relative costs (continued)
Line Speed
Required
Equipment
DTE/DCE
Interface
ISDN switched
56, 64, 112, or
128Kbps
ISDN terminal
adapter
RS232
asynchronous
Fractional T1
56Kbps to
1.544Mbps
CSU/DSU or T1
mux
X.21/V.35/RS449
$100-$2,000
synchronous
T1/E1
56Kbps to
1.544/2.048
Mbps
CSU/DSU or T1
mux
X.21/V.35/RS449
$350-$2,000
synchronous
Service
Relative Cost
(per month)
$50-$250
Analog Phone Lines
The analog connection, which uses modems to carry data over leased or switched
lines, sits at the bottom of the point-to-point scale. Leased lines are full-time
connections between two specified locations, while switched lines are regular
voice-phone lines.
The fastest modems today operate at an uncompressed rate of 33.6Kbps. Given
the signal-to-noise ratio on unconditioned voice-grade telephone circuits, though,
this rate is often unattainable. Modem manufacture claims of higher bit-per-second
(bps) rates are usually based on a data compression (CCITT V.42bis) algorithm that
is utilized by their modems.
Although V.42bis has the potential to achieve as much as four-fold reduction in data
volume, compression depends on the data and rarely reaches even 50%. Data
already compressed or encrypted may even increase with V.42bis applied.
Emerging technology referred to as X2 or 56Flex extends the bps rate to 56k for
analog telephone lines. This is a hybrid technology that requires one end of the
PPP link to be digital while the opposite end is analog. Additionally, the 56Kbps
applies only when you are moving data from the digital toward the analog end of
the link. This technology is well suited for connections to ISPs with the digital end of
the link and hardware at their location.
Typically, you can connect to a V.24 analog modem over an RS232 serial interface
with an asynchronous protocol at rates up to 115.2Kbps.
Digital Data Service
With digital, data travels all the way from the sender’s computer to the central office
of the telephone company, to the long distance provider, to the central office, and
then to the computer of the receiver in digital form. Digital signaling offers much
more bandwidth and higher reliability than analog signaling. A digital signaling
system eliminates many of the problems that analog modems must deal with, such
as noise, variable line quality, and signal attenuation.
DDS
The most basic of digital services is called Digital Data Services (DDS). DDS links
are leased, permanent connections, running at fixed rates of up to 56Kbps. This
service is also commonly designated as DS0.
112
OS/400 TCP/IP Configuration and Reference V4R4
You can connect to DDS using a special box called Channel Service Unit/Data
Service Unit (CSU/DSU), which replaces the modem in the analog scenario. DDS
has physical limitations that are primarily related to the distance between the
CSU/DSU and the Telephone Company Central Office. DDS works best when
distance is less than 30,000 feet. Telephone companies can accommodate longer
distances with signal extenders, but this service comes at higher cost. DDS is best
suited for connecting two sites that are served by the same Central Office. For long
distance connections that span different Central Offices, mileage charges can
quickly add up to make DDS impractical. In such cases, Switched-56 may be better
solution.
Typically, you can connect to a DDS CSU/DSU over V.35, RS449, or X.21 serial
interface with synchronous protocol at rates up to 56Kbps.
Switched-56
When you do not need a full-time connection, you can save money by using
switched digital service, which is generally called Switch-56 (SW56). An SW56 link
is similar to DDS setup in that the DTE connects to the digital service by way of
CSU/DSU. An SW56 CSU/DSU, however, includes a dialing pad from which you
enter the phone number of the remote host.
SW56 lets you make dial-up digital connections to any other SW56 subscriber
anywhere in the country or across international borders. An SW56 call is carried
over the long distance digital network just like a digitized voice call. SW56 uses the
same phone numbers as the local telephone system, and usage charges are the
same as those for business voice calls.
SW56 is available only in North American networks, and it is limited to single
channels that can only carry data. SW56 is an alternative for locations where ISDN
is unavailable.
Typically, you can connect to a SW56 CSU/DSU over V.35 or RS 449 serial
interface with synchronous protocol at rates up to 56Kbps. With a V.25bis
call/answer unit, data and call control flow over a single serial interface.
ISDN
Like Switched-56, ISDN also provides switched end-to-end digital connectivity.
Unlike other services, however, ISDN can carry both voice and data over the same
connection.
There are different types of ISDN services, with Basic Rate Interface (BRI) being
the most common. BRI consists of two 64Kbps B channels to carry customer data
and a D channel to carry signaling data. The two B channels can be linked together
to give a combined rate of 128Kbps. In some areas, the phone company may limit
each B channel to either 56Kbps or 112Kbps combined.
There is also a physical constraint in that the customer location must be within
18,000 feet of the central office switch. This distance can be extended with
repeaters.
You can connect to ISDN with a device called a terminal adapter. Most terminal
adapters have an integrated network termination unit (NT1) that allows direct
connection into a telephone jack. Typically, terminal adapters connect to your
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
113
computer over an asynchronous RS232 link and use the AT command set for setup
and control, much like conventional analog modems. Each brand has its own AT
command extension for setting up parameters that are unique to ISDN. In the past,
there were many interoperability problems between different brands of ISDN
terminal adapters. These problems were due mostly to the variety of rate adaptation
protocols that were available in V.110 and V.120 as well as bonding schemes for
the two B channels. The industry has now converged to synchronous PPP protocol
with PPP multilink for linking two B channels.
Some terminal adapter manufactures integrate V.34 (analog modem) capability into
their terminal adapters. This enables customers with a single ISDN line to handle
either ISDN or conventional analog calls by taking advantage of the simultaneous
voice/data capabilities of ISDN services. New technology also enables a terminal
adapter to operate as the digital server side for 56K(X2/56Flex) clients.
Typically, you would like to connect to an ISDN terminal adapter over an RS232
serial interface using asynchronous protocol at rates up to 230.4Kbps. However, the
maximum AS/400 baud rate for asynchronous over RS232 is 115.2Kbps.
Unfortunately, this restricts the maximum byte transfer rate to 11.5k bytes/sec, while
the terminal adapter with multi-linking is capable of 14/16k bytes uncompressed.
Some terminal adapters support synchronous over RS232 at 128Kbps, but AS/400
maximum baud rate for synchronous over RS232 is 64Kbps. The AS/400 is capable
of running asynchronous over V.35 at rates up to 230.4Kbps, but terminal adapter
manufacturers generally do not offer such a configuration. Interface converters that
convert RS232 to V.35 interface could be a reasonable solution for the problem, but
this approach has not evaluated for AS/400. Another possibility is to use terminal
adapters with V.35 interface synchronous protocol at rate of 128Kbps. Although this
class of terminal adapters exists, it does not appear that many offer synchronous
Multilink PPP.
T1/E1
A T1 connection bundles together twenty-four 64Kbps (DS0) time division
multiplexed (TDM) channels over 4-wire copper circuit. This creates a total
bandwidth of 1.544Mbps. An E1 circuit in Europe and other parts of the world
bundles together thirty-two 64Kbps channels for a total of 2.048Mbps.
TDM allows multiple users to share a digital transmission medium by using
pre-allocated time slots. Many digital PBXs take advantage of T1 service to import
multiple call circuits over one T1 line instead of having 24 wire pairs routed between
the PBX and telephone company.
It is important to note that T1 can be shared between voice and data. A company’s
telephone service may come over a subset of a T1 link’s 24 channels, for instance,
leaving remaining channels available for internet connectivity.
A T1 multiplexer device is needed to manage the 24 DS0 channels when a T1 trunk
is shared between multiple services. For a single data-only connection, the circuit
can be run unchannelized (no TDM is performed on the signal). Consequently, a
simpler CSU/DSU device can be used.
Typically, you can connect to a T1/E1 CSU/DSU or multiplexer over V.35 or RS 449
serial interface with synchronous protocol at rates at a multiple of 64Kbps to
1.544Mbps or 2.048Mbps. The CSU/DSU or multiplexer provides the clocking in the
network.
114
OS/400 TCP/IP Configuration and Reference V4R4
Fractional T1
With Fractional T1 (FT1), a customer can lease any 64Kbps sub-multiple of a T1
line. FT1 is useful whenever the cost of dedicated T1 would be prohibitive for the
actual bandwidth customer uses.
With FT1 you pay only for what you need. Additionally, FT1 has the following
feature that is unavailable with a full T1 circuit: Multiplexing DS0 channels at the
telephone company’s central office. The remote end of an FT1 circuit is at a Digital
Access Cross-Connect Switch that is maintained by the telephone company.
Systems that share the same digital switch can switch among each other’s DS0
channels. This scheme is popular with ISPs that use a single T1 trunk from their
location to the telephone company’s digital switch. In these cases, multiple clients
can be served with FT1 service.
Typically, you can connect to a T1/E1 CSU/DSU or multiplexer over V.35 or RS 449
serial interface with synchronous protocol at some multiple of 64Kbps. With FT1,
you are pre-allocated a subset of the 24 channels. The T1 multiplexer must be
configured to fill only the time slots that are assigned for your service.
Using an Asynchronous Modem or ISDN Terminal Adapter
|
|
|
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
PPP ISDN Support
|
|
|
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Configuring SLIP Connection Profiles
This section covers sample property sheets for configuring a Serial Line Interface
Protocol (SLIP) Point-to-Point network connection profile using Operations
Navigator. There is very little difference in how a SLIP connection profile is created
and used from how a PPP connection profile is created and used. This section will
mainly point out any features that are unique to SLIP. Refer to previous PPP
sections for more details on the property pages. You can also refer to the PPP
scenarios in the previous section. These scenarios will also work for SLIP.
Note: This section does not cover how to create SLIP point-to-point connection
profiles (which use *ASYNC lines). For more information on creating SLIP
point-to-point connection profiles, see “Using SLIP with an Asynchronous
Line Description” on page 126.
The General page allows you to define the following general attributes of a
connection profile:
v Name of the profile
v Optional description for the profile
v Which protocol to use (SLIP in this example)
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
115
v Operating mode which helps to define the physical connection (switched
line-answer in this example)
The Connection page allows you to define the line description that will be used for
the connection. For switched dial profiles, this page also allows you to specify the
remote phone number or numbers required to connect to the remote system. For
SLIP, the ″Maximum transmission units″ is configurable. This determines the size in
bytes of each Packet that is sent to the remote system.
The TCP/IP Settings page allows you to define the local and remote IP addresses
that will be used for this connection. It also allows you to define additional TCP/IP
attributes.
For the remote IP address, ″Route specified″ is enabled only for switched
line-answer profiles. This gives the administrator greater flexibility in selection of
remote IP addresses. If the IP forwarding option is selected, then this allows the
remote user to send IP datagrams to the network that is connected to this AS/400.
If this is not desirable, then disable this feature. VJ header compression is not
configurable on the answer side since the client determines if VJ header
compression will be used.
Dynamically assigned IP addresses require the use of a connection script. For more
information, see “Writing Connection Dialog Scripts” on page 118.
Use the Script page to specify whether you want to use a connection script for the
connection profile.
A Connection script allows AS/400 and remote systems to exchange information.
This is the only method of passing user ID, password, and IP address information
for SLIP. For more information, see “Writing Connection Dialog Scripts” on
page 118.
Use the Domain Name Server page to define the domain name server to use for a
connection profile. The page is enabled for switched line-dial and leased
line-initiator connection profiles only.
You may want to configure the Domain Name Server (DNS) under the following
conditions:
v You want to have automatic host-name-to-IP-address resolution
v The remote system has a DNS available
If authentication is required, use the Authentication page to define which users
may connect to this system.
Figure 81 on page 117 is an example of a switched answer or leased line terminator
authentication page for a SLIP connection profile. If authentication is enabled, then
a connection script must be used to prompt for and accept the user name and
password information from the remote system. For more information on connection
scripts, see “Writing Connection Dialog Scripts” on page 118.
116
OS/400 TCP/IP Configuration and Reference V4R4
Figure 81. SLIP Connection Profile Properties - Authentication (Answer)
The validation list name is the name of the validation list object that contains a list
of the user names that may connect to this system as well as their passwords. To
open a validation list name, click Open on the Authentication page.
Figure 82 is an example of a switched dial or leased line initiator authentication
page for a SLIP connection profile. This page is used to define the user name and
password that will be used to identify this system when connecting to a remote
system.
Figure 82. SLIP Connection Profile Properties - Authentication (Dial)
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
117
If authentication is enabled, then a connection script must be used to pass the user
name and password information to the remote system. For more information on
connection scripts, see “Writing Connection Dialog Scripts”.
Writing Connection Dialog Scripts
A connection dialog script is information in an AS/400 source file that AS/400 uses
to exchange data prior to establishing a SLIP (or in some cases a PPP) connection.
Note: Your AS/400 does not support the capability to select SLIP or PPP service
from a connection dialog script when a remote system dials AS/400.
The configuration profile determines which connection script is used. The dialog text
must exactly match the connection sequence that is exchanged between AS/400
and a remote system.
Each connection script contains the dialog text required for the exchange of
authorization and connection parameters with a remote host. The configuration
profile determines which connection script is to be used. The dialog text must be an
exact match for the connection to be established between the client and server or
client and ISP.
Note: AS/400 expects each input line of dialog text from the remote system to end
with an end-of-line character. See “Rules for Creating and Changing
Connection Scripts” on page 119 for further details.
Connection Script Considerations for SLIP
For SLIP on an AS/400, connection dialog scripts commonly perform the following
functions:
v Exchange sign-on and password information to authorize an AS/400 to connect
to a remote host or ISP
v Exchange sign-on and password information to authorize a remote host to
connect to an AS/400
v Select the type of service requested (for example SLIP or PPP) from an ISP
v Allow the dynamic assignment of an IP address by an ISP to an AS/400
v Allow AS/400 to assign an IP address dynamically to a remote host
If you do not require these functions for SLIP connections to or from an AS/400,
you do not need to use a connection script. If you do not use connection dialog
scripts, though, AS/400 will establish SLIP connections without user ID or password
authentication.
Creating and Changing Connection Scripts
You cannot change the default connection script file QUSRSYS/QATOCPPSCR.
You must first create your own connection script file. Do this by copying the default
file as follows:
CPYF FROMFILE(QUSRSYS/QATOCPPSCR)
TOFILE(lib/file) FROMMBR(*ALL)
TOMBR(*FROMMBR) MBROPT(*ADD)
CRTFILE(*YES)
118
OS/400 TCP/IP Configuration and Reference V4R4
where lib/file represents your own new file, such as QUSRSYS/SLIPSCRIPT.
This creates a new file that uses the existing default connection script file as the
base and that contains all of the same data. You can now change the data for your
use.
You must refer to the new connection script file name in the TCP/IP point-to-point
configuration profile that will use the new connection script.
If you need to use characters in your connection script file that are not supported by
EBCDIC CCSID 500, which is the CCSID of the default connection script, then go
to “NLS Considerations” on page 125.
Rules for Creating and Changing Connection Scripts
There are many special rules for creating and changing connection scripts. The
rules are as follows:
v Column 1 of each line in the connection script may contain a control character.
The control character specifies the action to be taken by AS/400 system. Column
2 may be left blank.
– The AS/400 system ignores comment lines.
Comment lines begin with either an asterisk (*), or are completely blank.
– Output lines for the remote system begin with an ampersand (&)
– To send an asterisk (*) to the remote host, put an ampersand (&) in column 1
followed by an asterisk in column 2.
To send an ampersand (&) to the remote host, put an ampersand in column 1
followed by an ampersand in column 2.
v
v
v
v
– A blank line with an ampersand in column 1 will not be sent to the remote
host. Refer to the (PROMPT) keyword for this operation.
The AS/400 system interprets any non-blank line that does not contain one of the
previously described control characters as input from the remote host.
You can mix upper-case and lower-case in a line that contains expected input
from the remote host.
AS/400 translates all input to upper-case before comparing the dialog match text.
AS/400 expects each line of dialog text from the remote system to end with an
end-of-line character, such as a carriage return, New Line, or Line Feed. If this is
not possible, dialog match text may be changed to achieve a match. For
example, if the remote server host prompts for a password with ″Password:″,
then the match text in the connection script may be shortened to ″Pass″ or
″Password″ (the colon character has been omitted).
Fields enclosed in parentheses () contain the keywords that describe an input or
an output operation.
You cannot define the keywords. However, you can control the operations
performed during the connection dialog. To control the operations and the order
in which they run, create a unique connection script using appropriately placed
keywords.
v You cannot change the default connection scripts.
If you need a connection script that is different from all the default ones, you
must copy the default connection scripts and change the copy.
The valid keywords are:
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
119
(USERID)
When remote systems dial in, AS/400 uses this keyword to validate the user ID
that the remote system is using to connect to AS/400. The keyword is only valid
if an access authorization list is configured.
When an AS/400 user dials out to a remote system, AS/400 uses this keyword
to pass the user ID to the remote server for connection validation.
If the remote system requires both an account name and a user ID, configure
both as described in “Remote System Access Information” on page 152.
(PASSWORD)
For dial-in sessions, AS/400 uses this keyword to validate the password for the
user ID that was received on the (USERID) keyword. AS/400 uses this keyword
only when an access authorization list is configured.
For dial-out sessions, AS/400 uses this keyword to send the password to the
remote server for connection validation.
(IPADDR)
The IP address to be exchanged and activated to set up a session.
(IPGATE)
The gateway IP address to be exchanged and activated to set up a session.
(PROMPT)
Specifies that AS/400 is to either:
v Pause for input on an input line, or
v Send a blank followed by a carriage return and a line feed for an output line.
This keyword is useful for synchronizing a connection script with a remote
system. Placing this keyword on the input line of a connection script causes the
host to pause until input is received before continuing the dialog. Placing this
keyword on the output line of a connection script causes the host to signify
readiness to continue the dialog. Typically this keyword is placed on the first
line of the connection script to synchronize the host to host connection before
beginning the connection dialog.
Some ISPs may look for specific responses to initiate a SLIP connection. For
example, specific characters like @ , &, or a carriage return without any text may
be required.
To change what AS/400 sends, use the following command:
& (PROMPT) 'xxyy'
where 'xxyy' is the two-digit hexadecimal representation for any ASCII
characters that you wish to send.
For example, & (PROMPT) '4053' would cause AS/400 to send the characters
’@S’, and & (PROMPT) '0D' would cause AS/400 to send only a carriage return.
The hexadecimal representation of the characters to be sent must be two digits
each and represent valid ASCII characters.
(WAIT)
Causes AS/400 to wait 1 second before resuming.
You can cause a time delay from 1 to 99 seconds. To change the time delay,
use the following command:
120
OS/400 TCP/IP Configuration and Reference V4R4
(WAIT) 'xx'
where xx is the delay value in seconds. This keyword works the same on both
input and output lines, and is useful for controlling the rate and timing of the
dialog.
You do not need to include all of the connection dialog in the connection script. For
input lines containing a keyword, it is good practice to include some text preceding
the keyword to help AS/400 system locate the expected keyword input. Also, as
previously described, it may be necessary to shorten input match text in order to
obtain a match when connecting to systems that do not send end-of-line characters
at the end of a line.
Location of Default Connection Scripts: You can find the default connection
scripts contained in Table 9. The members are in file QATOCPPSCR.
SLIP Connection Scripts-Examples
The connection scripts in Table 9 are examples for the following:
v Dialing out from AS/400 to a remote host.
v Dialing in to AS/400 from a remote host.
Each member has a different purpose, stated in the comment. Each script is placed
in its own member in file QATOCPPSCR in some connection script library.
Table 9. SLIP Client Connection Scripts-Examples
Client (Dial-Out) Examples
Member DIAL400 in File QATOCPPSCR
Server (Dial-In) Examples
*******************************************************
* CLIENT CONNECTION SCRIPT EXAMPLE
* FOR AS/400 WITH LOGIN AND PASSWORD PROMPT
*******************************************************
& (PROMPT)
login:
& (USERID)
password:
& (PASSWORD)
* END OF CLIENT CONNECTION SCRIPT EXAMPLE
Member ANS400 in File QATOCPPSCR
Member DIAL400I in File QATOCPPSCR
Member ANS400I in File QATOCPPSCR
*******************************************************
* CLIENT CONNECTION SCRIPT EXAMPLE
* FOR AS/400 WITH DYNAMIC IP ADDRESS
*******************************************************
& (PROMPT)
login:
& (USERID)
password:
& (PASSWORD)
YOUR IP ADDRESS IS (IPADDR) MY IP ADDRESS IS (IPGATE)
* END OF CLIENT CONNECTION SCRIPT EXAMPLE
*******************************************************
* SERVER CONNECTION SCRIPT EXAMPLE
* FOR AS/400 WITH DYNAMIC IP ADDRESS
*******************************************************
(PROMPT)
& login:
(USERID)
& password:
(PASSWORD)
& YOUR IP ADDRESS IS (IPADDR) MY IP ADDRESS IS (IPGATE)
* END OF SERVER CONNECTION SCRIPT EXAMPLE
*******************************************************
* SERVER CONNECTION SCRIPT EXAMPLE
* FOR AS/400 WITH LOGIN AND PASSWORD PROMPT
*******************************************************
(PROMPT)
& login:
(USERID)
& password:
(PASSWORD)
* END OF SERVER CONNECTION SCRIPT EXAMPLE
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
121
Table 9. SLIP Client Connection Scripts-Examples (continued)
Client (Dial-Out) Examples
Server (Dial-In) Examples
Member DIALAIX in File QATOCPPSCR
Member ANSAIX in File QATOCPPSCR
*******************************************************
* CLIENT CONNECTION SCRIPT EXAMPLE
* FOR AIX 4.1 SLIPLOGIN SCRIPT
*******************************************************
&(PROMPT)
login:
&(USERID)
password:
&(PASSWORD)
Called system's address is (IPGATE)
Calling system's address is (IPADDR)
discipline
* END OF CLIENT CONNECTION SCRIPT EXAMPLE
*******************************************************
* SERVER CONNECTION SCRIPT EXAMPLE
* FOR AIX 4.1 SLIPCALL SCRIPT
*******************************************************
(PROMPT)
& login:
(USERID)
& password:
(PASSWORD)
& Called system's address is (IPGATE)
& Calling system's address is (IPADDR)
& The netmask is 255.255.255.0
& Activating slip line discipline
* END OF SERVER CONNECTION SCRIPT EXAMPLE
Member DIALIGN in File QATOCPPSCR
Member ANSWIN95 in File QATOCPPSCR
*******************************************************
* CLIENT CONNECTION SCRIPT EXAMPLE FOR
* IBM GLOBAL NETWORK (IGN) INTERNET SERVICE
*******************************************************
& &
Enter dial script version ==>
& 1.1
Enter service ==>
& INTERNET
Enter account userID password
& (USERID) (PASSWORD)
(IPADDR) is your IP address.
& (PROMPT)
(IPGATE) is the gateway IP address.
Begin TCP/IP communication now.
* END OF CLIENT CONNECTION SCRIPT EXAMPLE
*******************************************************
* SERVER CONNECTION SCRIPT EXAMPLE
* Windows 95 system with Microsoft Plus for Windows 95
* installed dialing into AS/400 *ANS session.
*******************************************************
(PROMPT)
& Userid:
(USERID)
& Password?
(PASSWORD)
& InternetLR/E>
(PROMPT)
& (IPGATE) IS AS/400 IP ADDRESS.
& (IPADDR) IS IP ADDRESS OF SYSTEM CALLING AS/400.
* END OF SERVER CONNECTION SCRIPT EXAMPLE
Creating SLIP Client (Dial-Out) Connection Scripts-Examples
This topic explains how to create connection scripts for dial-out connections.
The following is an example of a client connection script for a generic (non-IBM
Global Network) ISP:
1.
2.
3.
4.
5.
* Generic client connection script example
& (PROMPT)
Username:
& (USERID)
Password:
6. & (PASSWORD)
7. Protocol:
8.
9.
10.
11.
SLIP
The gateway address is (IPGATE)
Your IP address is (IPADDR)
* End of Generic client script example
After the modem dials and connects, AS/400 reads the connection script. Each line
in the connection script causes AS/400 to send or receive data as follows:
1. Comment line.
2. AS/400 sends a blank followed by a carriage return to the remote system that
AS/400 called.
122
OS/400 TCP/IP Configuration and Reference V4R4
3. AS/400 waits for the Username: prompt from the called system.
4. AS/400 sends the value specified in the configuration profile’s Remote service
access name field to the called system.
5. AS/400 waits for the Password: prompt from the called system.
6. AS/400 sends the value specified in the configuration profile’s Remote service
access password field to the called system.
7. AS/400 waits for the Protocol: prompt from the called system.
8. AS/400 sends the value slip to the called system to indicate that the SLIP
protocol will be used.
9. AS/400 waits for the The gateway address is prompt from the called system.
When this prompt is received, the next value received matches the (IPGATE)
keyword in the script. AS/400 uses this value as the IP address of the called
system for this point-to-point connection.
10. AS/400 waits for the Your IP address is prompt from the called system.
When this prompt is received, the next value received matches the (IPADDR)
keyword in the script. AS/400 uses this value as the local IP address of AS/400
for this point-to-point connection.
11. Comment line.
Creating SLIP Client (Dial-Out) Connection Scripts — Example: The following
example describes in detail how to create a client connection script to an Internet
Service Provider. The IBM Global Network is used as the ISP in the example.
When you open a new account with the IBM Global Network or with any ISP, the
ISP should provide you with either:
v A connection dialog example
v An actual connection dialog script
The connection dialog for the IBM Global Network looks like the following example:
&
****************************************
Welcome to the IBM Global Network
****************************************
Enter dial script version ==>
1.1
Gateway: IBMT2YA0 Port: 22
Select one of the following services:
INTERNET
Enter service ==>
INTERNET
Enter account userID password [\new_password] ==>
usinet barrier password
129.37.3.150 is your IP address.
129.37.1.10 is the Gateway IP address.
Begin TCP/IP communication now.
Use the keywords and rules for creating AS/400 connection scripts (shown in “Rules
for Creating and Changing Connection Scripts” on page 119) to convert the
connection dialog for IBM Global Network into a client connection script.
* IBM Global Network Client Script Example
& &
version ==>
& 1.1
service ==>
& INTERNET
password
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
123
& (USERID) (PASSWORD)
(IPADDR) is your IP address.
(IPGATE) is the Gateway IP address.
ication now.
* End of IBM Global Network Client Script Example
Notice that this example differs from the supplied DIALIGN connection script in
Table 9 on page 121. This is because a connection script needs to contain only
sufficient text to allow AS/400 to locate and interpret the keywords and keyword
responses between the two hosts. You must carefully ensure that enough text
remains to maintain send/receive synchronization. The single word password and
the last partial line ication now. demonstrate this concept.
If you cannot obtain a connection dialog for the server any other way, do the
following:
1. Establish an interactive connection using a PC and copy down the dialog.
2. Use the dialog to create your client connection script.
Creating SLIP Server (Dial-In) Connection Scripts-Example
The following example is a server connection script for AS/400 to AS/400 SLIP
connections:
1.
2.
3.
4.
5.
* Server connection script example
(PROMPT)
& ENTER ACCOUNT/PASSWORD ==>
(USERID)/(PASSWORD)
& YOUR IP ADDRESS IS (IPADDR)
6. & (WAIT)’2’
7. & YOUR GATEWAY IP ADDRESS IS (IPGATE)
8. & BEGIN TCP/IP COMMUNICATION NOW
9. * End of Server connection script example
After the modem answers and connects, AS/400 reads the connection script. Each
line in the connection script causes AS/400 to send or receive data as follows:
1. Comment line.
2. Waits for any input from the client before beginning dialog.
3. Sends the prompt for account and password.
4. Waits for the user ID and password from the client.
5. Sends the IP address to be used by the client.
6. Waits 2 seconds before proceeding.
7. Sends the IP address of the server host to the client.
8. Sends confirmation of the client-to-server connection.
9. Comment line.
Connection Script Considerations for PPP
For PPP on an AS/400, you can use connection dialog scripts to perform the
following functions:
v Exchange sign-on and password information to authorize an AS/400 to connect
to a remote host or ISP
124
OS/400 TCP/IP Configuration and Reference V4R4
v Exchange sign-on and password information to authorize a remote host to
connect to an AS/400
v Select the type of service requested (for example SLIP or PPP) from an ISP
Normally, all of these functions are performed when a PPP connection is negotiated
by AS/400. However, some ISPs may require user authorization or a type of service
selection prior to negotiating the PPP connection. Additionally, you will need to take
into account the following considerations:
v If a connection to or from an AS/400 is authenticated using a connection dialog
script, then the user ID and password that will be used is the one that was
specified in the connection profile for PAP validation. If the remote host does not
support validation when PPP is negotiated, then you must deactivate this
selection after you specify the PAP user ID and password.
v Connection validation with CHAP for PPP may also be requested after the initial
authentication. This is accomplished using the connection dialog script with a
different and more secure user ID and password.
v Any dynamic IP addresses that are exchanged during the connection dialog will
not be used by AS/400.
NLS Considerations
Once a SLIP connection is established, the application, such as TELNET or FTP,
that is running over the connection, must manage the ASCII to EBCDIC and
EBCDIC to ASCII translation.
If you are not using a connection script to establish a SLIP connection to or from a
remote system, then no other NLS considerations are necessary. If you are using a
connection script then it may be important to understand how AS/400 translates
connection scripts from EBCDIC to ASCII to be transmitted back and forth over the
connection.
Connection scripts on AS/400 are stored in EBCDIC format. However, most
systems that will connect to AS/400 are probably ASCII systems that will send their
connection script data in ASCII format. Therefore, AS/400 must translate the ASCII
data that is coming in to AS/400 over the connection from ASCII to EBCDIC.
AS/400 can then compare the connection script to the EBCDIC connection script
that is stored on AS/400.
Before AS/400 can send data to a remote system over the SLIP connection, AS/400
must translate the connection script data from EBCDIC to ASCII. The default
EBCDIC and ASCII CCSID values that AS/400 uses to translate connection scripts
are described below. The default values cover most needs, but you can change the
default values if you need support for other characters.
The default connection scripts that are shipped with AS/400 are located in members
in file QUSRSYS/QATOCPPSCR. See “Connection Dialog Scripts” on page 156 for
details on using connection scripts and for the member names.
This default connection script file, QATOCPPSCR, uses a CCSID of 500, which
means character set 697 and code page 500. Therefore, all character data in each
connection script member have a hex code point that this CCSID supports. AS/400
uses the EBCDIC CCSID value to translate connection script data when AS/400
sends the connection script data to or receives the connection script data from a
remote system.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
125
AS/400 obtains the ASCII CCSID from the TCP/IP point-to-point configuration profile
that is being used for the SLIP session. You can configure this value in the Script
source information section of the profile, which is shown in “Use Connection
Dialog Script” on page 145. The default ASCII CCSID value is 00819 (ISO 8859,
part1 Latin Alphabet No.1). This ASCII CCSID covers most 8-bit languages that use
character set 697. All of the code points that are defined for ASCII CCSID 00819
support translations to the EBCDIC CCSID 500. This default covers most
translations. However, if you must use characters that are not supported in EBCDIC
CCSID 500 and ASCII CCSID 00819, then you must do the following:
1. Change the ASCII CCSID defined in the TCP/IP point-to-point profile that you
plan to use to a value that supports all of the characters that you require.
2. Create a connection script file with a CCSID that supports all of the characters
that you require and that is compatible with the ASCII CCSID that you have
selected.
Create the new connection script file as follows:
v Create the file with the desired EBCDIC CCSID:
CRTSRCPF FILE(lib/file) MBR(*NONE)
RCDLEN(128) AUT(*USE)
CCSID(your_ccsid)
v Copy the default connection script file information into the new file:
CPYF FROMFILE(QUSRSYS/QATOCPPSCR)
TOFILE(lib/file) FROMMBR(*ALL)
TOMBR(*FROMMBR) MBROPT(*ADD)
FMTOPT(*MAP)
Notes:
a. If you use FMTOPT(*MAP), AS/400 database attempts to automatically
translate the CCSID 500 code points in the default connection script file to
the equivalent code points of the new CCSID in the new connection script
file.
b. If you do not want this automatic translation of data from CCSID 500 to your
new CCSID, then use FMTOPT(*NOCHK).
c. If you do not want to copy or use the default connection script members,
then omit the step for CPYF. The SCRSRCPF step will suffice.
The ASCII and EBCDIC CCSID values that you select must be compatible CCSIDs.
If the CCSIDs are not compatible, AS/400 issues message TCP8373 'Unable to
convert data from CCSID &1' to CCSID &2' and ends the SLIP session. See
National Language Support, SC41-5101 for information that can help you determine
which CCSID to use and which ASCII and EBCDIC CCSIDs are compatible.
Using SLIP with an Asynchronous Line Description
This section discusses how to create a SLIP connection profile that uses an
asynchronous line description.
Beginning in V4R2 support was added for the PPP line type. It is possible to create
a SLIP connection profile using either a PPP line description or an asynchronous
line description. While connection profiles using the older asynchronous line
description type can still be used, we strongly recommend that you use the new
PPP line type instead.
126
OS/400 TCP/IP Configuration and Reference V4R4
You configure a SLIP connection profile using a PPP line description with
Operations Navigator. You configure SLIP over an asynchronous line description
using the CL command line interface.
See “Configuring SLIP Connection Profiles” on page 115 for working with a SLIP
connection profile that uses a PPP line description.
SLIP over an asynchronous line description uses the following four CL commands:
v
v
v
v
CFGTCPPTP - Configure Point-to-Point TCP/IP
ENDTCPPTP - End Point-to-Point TCP/IP
STRTCPPTP - Start Point-to-Point TCP/IP
WRKTCPPTP - Work with Point-to-Point TCP/IP
With these commands, you can start and end SLIP activity on AS/400. But more
importantly, you can create and use connection profiles and connection dialog
scripts.
Connection Dialog Scripts
Connection dialog scripts (or, simply, connection scripts) allow AS/400 and remote
systems to exchange sign-on and password information before a remote client may
connect to AS/400 system. Connection dialog scripts also allow you to authorize
users for connection, so that the system is protected from unwanted users.
Another common use of connection scripts is to dynamically assign an IP address
to the remote SLIP client. If you do not require these functions, you can bypass
script processing.
Other point-to-point protocols such as X.25 and frame relay, do not have connection
script support.
Configuring AS/400 Point-to-Point for SLIP
Before You Configure AS/400 for SLIP - Checklist
To create a SLIP connection profile that uses the older asynchronous line
description, you need the following:
An asynchronous line description on AS/400.
See “Step 1 - Configure an Asynchronous Line Description” on page 129 to
check for or create an asynchronous line description.
Your modem make and model, if you are using a modem. Also, make sure that
you have the owner’s manual for your modem.
See “Step 2 - Configure AS/400 For Your Modem” on page 130 to check for or
create a modem entry.
Information to complete your SLIP configuration profile.
See “Step 3 - Determine Configuration Profile Type” on page 132 to check for or
create various SLIP connection profiles.
There are other options you may choose to configure. See “Dial-In (*ANS)
Point-to-Point Profile Parameters” on page 140 and “Dial-Out Point-to-Point Profile
Parameters” on page 147 for details about the connection profiles.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
127
Hardware Requirements for the Asynchronous Line Description
To use the SLIP protocol, you must establish a serial asynchronous connection with
the remote system. To establish this connection, the appropriate adapters and I/O
Processor (IOP) that support serial (RS232) ports must be installed.
The following two families of adapters that can be used:
v You can use the I/O adapters listed below only with a SLIP connection that uses
an asynchronous line description. You cannot use these IOAs with the new PPP
line description.
– 2609 -- Two-line EIA 232/V.24 adapter
– 2612 -- One-line EIA 232/V.24 adapter
v You can use the I/O adapters listed below with either the PPP line description or
the asynchronous line description. These IOAs can be used with either PPP or
SLIP connections.
– 2699 -- Two Line WAN IOA
– 2720 -- PCI WAN/Twinaxial IOA
– 2721 -- PCI Two-Line WAN IOA
To find out what adapters are installed on your system, do this on the command
line:
===> go hardware
The Hardware Resources Display shown in Figure 83 is shown.
HARDWARE
Hardware Resources
System:
Select one of the following:
1.
2.
3.
4.
5.
6.
7.
8.
Work
Work
Work
Work
Work
Work
Work
Work
with
with
with
with
with
with
with
with
SYSNAM
communication resources
local workstation resources
storage resources
processor resources
token-ring LAN adapter resources
DDI LAN adapter resources
all LAN adapter resources
coupled system adapter
70. Related commands
Selection or command
===> 1
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F16=AS/400 Main menu
(C) COPYRIGHT IBM CORP. 1980, 1996.
F13=Information Assistant
Figure 83. Hardware Display
Select option 1., to get the display shown in Figure 84 on page 129. Three 2609
communications adapters are configured on the 2623 communications processor.
Each 2609 adapter has two ports, to which you can attach modems.
128
OS/400 TCP/IP Configuration and Reference V4R4
Work with Communication Resources
Type options, press Enter.
2=Edit
4=Remove
5=Work with configuration descriptions
Opt
Resource
CC02
LIN08
LIN081
LIN082
LIN05
LIN051
LIN052
LIN06
LIN061
LIN062
CMB01
F3=Exit
F5=Refresh
F12=Cancel
Type
2623
2609
2609
2609
2609
2609
2609
2609
2609
2609
2615
System:
SYSNAM
Text
Comm Processor
Comm Adapter
V.24 Port Enhanced
V.24 Port
Comm Adapter
V.24 Port Enhanced
V.24 Port
Comm Adapter
V.24 Port
V.24 Port
Combined function IOP
F6=Print
More...
F11=Display resource addresses/statuses
Figure 84. Hardware Support for SLIP-Example
Step 1 - Configure an Asynchronous Line Description
You must use the line description name when you add the dial-in or dial-out profile
for the line in “Step 3 - Determine Configuration Profile Type” on page 132.
To check for existing asynchronous line descriptions, enter the following:
WRKLIND LIND(*ASYNC)
If line descriptions exist, AS/400 displays them as shown in Figure 85 on page 130.
If no line descriptions exist, or if you prefer to create a new one, do either of the
following:
v Press F6=Create from the Work with Line Descriptions display.
v Enter the CRTLINASC on the command line and press F4, then F9.
Continue at “Asynchronous Line Description Parameters” on page 152. Then return
to “Step 2 - Configure AS/400 For Your Modem” on page 130.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
129
Work with Line Descriptions
Position to . . . . .
Starting characters
Type options, press Enter.
2=Change
3=Copy
4=Delete
5=Display
8=Work with status
9=Retrieve source
Opt
_
_
_
_
_
_
Line
ASCDIAL7
ASCNONSW4
ASCSWIT6
ASCSWIT7
MODEMLIN
Type
*ASYNC
*ASYNC
*ASYNC
*ASYNC
*ASYNC
6=Print
System:
SYSNAM
7=Rename
Text
Switched line to modem. DIALCMD(*OTHER)
Switched line to modem. DIALCMD(*OTHER)
Switched line to modem. DIALCMD(*OTHER)
Sample line to modem in this book
Parameters or command
===>
F3=Exit
F4=Prompt
F5=Refresh
F14=Work with status
Bottom
F6=Create
F9=Retrieve
F12=Cancel
Figure 85. Work with Asynchronous Line Descriptions
Step 2 - Configure AS/400 For Your Modem
Check to see if a sample configuration exists for your modem. Type CFGTCPPTP,
then select option 11 to view the default modem entries on AS/400. If your modem
is listed, go on to the next configuration step. If your modem is not listed, you can
do either of the following:
v Try the $generic hayes modem entry.
v Add an entry for your modem.
To determine which option is best, check the user manual for your modem. Look for
the following settings for command strings:
v Modem reset to factory defaults: This is often AT&F or AT&Z
v Modem initialization – Some of the options you should set are as follows:
– Display Verbal Result Codes: Often this is Q0 and V1
– Normal CD and DTR modes: Often this is &C1 and &D2
– Echo mode off: Often this is E0
– Data Set Ready (DSR) to follow Carrier Detect: Often, this is &S1
– Enable hardware flow control (RTS/CST)
– Enable error correction and optionally, compression
– Ensure DTE-DCE line speed is enabled to run at fixed 19.2K
– If the modem supports it, optionally enable the inactivity timer
v Modem answer mode:
– Answer after n rings: Often this option is S0=n
– Disconnect if no carrier (connection) after m seconds: Often this option is S7=m
v Modem dial type: This is usually ATDT, which selects tone dialing. To compare,
ATDP selects pulse dialing.
130
OS/400 TCP/IP Configuration and Reference V4R4
If your modem and the $generic hayes modem entry match for these settings, then
you can most likely use the $generic hayes modem entry. If your modem supports
different command entries, then you should create a new modem entry.
Note: Although there is much consistency between AT-compatible modems, each
one often has unique settings. Therefore, be aware that these are
recommendations. Your modem user’s guide contains the details that you
need.
To add new modem information, enter option 1:
Work with Point-to-Point TCP/IP Modem Information
Type option, press Enter.
1=Add
2=Change
3=Copy
4=Remove
5=Display
Opt Name
1
My Modem
$generic hayes
GVC 28800
Hayes 14400 Accura
Hayes 28800 Accura
IBM 9600 7855
IBM 28800 7852-010
IBM 28800 7852-013
IBM 7852-400
IBM 7852-400 (2609 or 2612 EIA 232/V.24 adapter)
IBM 7857-017
MaxTech 28800
MultiTech 28800 Multimodem
USRobotics 14400 Sportster
USRobotics 28800 Sportster
F3=Exit
F5=Refresh
F9=Command line
F12=Cancel
6=Print
Source
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
DEFAULTS
MORE...
F17=Position to
Work with Point-to-Point TCP/IP Modem Information
Type option, press Enter.
1=Add
2=Change
3=Copy
Opt
4=Remove
5=Display
Name
ZOOM 14400
ZOOM 28800
6=Print
Source
DEFAULTS
DEFAULTS
Figure 86. Adding a Modem Entry-Display 1
Figure 87 on page 132 shows the default values that you get if you add modem
information for your modem. Change the defaults as needed.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
131
Add TCP/IP Point-to-Point Modem Information
Modem information name:
My Modem
„1…
Type changes, press Enter.
Modem initialization string
AT
Modem reset string
AT
Modem dial command
ATDT
Modem answer command
ATS0=2S7=30
F3=Exit
„2…
F12=Cancel
Figure 87. Adding a Modem Entry-Display 2
„1…
To add your own modem, you need the owner’s manual from the modem to
complete the prompts in this display.
Optionally, to add your own modem, copy the $generic hayes modem entry,
and change the prompt information to match the information required for
your modem.
„2…
The default modem answer command instructs the modem to answer an
incoming call after one ring and then wait a maximum of 30 seconds for a
connection. If you need more time to establish connections, you must
change this command.
Step 3 - Determine Configuration Profile Type
There are two kinds of connection profiles, *ANS and *DIAL profiles. Use *ANS
profiles for dial-in support. These profiles are called *ANS profiles because AS/400
uses them to answer incoming calls from remote systems.
Use *DIAL profiles for dial-out support. These profiles are called *DIAL profiles
because AS/400 uses them to dial out to remote systems.
For each modem attached to AS/400, you need at least one configuration profile.
For each line attached to the modem, you need an asynchronous line description.
If you are using the same modem to dial in and to dial out, you need two profiles
for that modem. You need a *ANS profile for dial-in support, and a *DIAL profile for
the dial-out support. If the modem has only one line attached, you need only one
line description.
Only one caller at a time can use a given asynchronous line and its associated line
description.
To add a dial-in profile, go to “Step 4 - Add a Dial-In (*ANS) Configuration Profile”
on page 133.
132
OS/400 TCP/IP Configuration and Reference V4R4
To add a dial-out profile, go to “Step 5 - Add a Dial-Out (*DIAL) Configuration
Profile”.
Step 4 - Add a Dial-In (*ANS) Configuration Profile
Before you add a profile, have the following information ready:
The IP address this profile uses for the remote system that is connecting to this
AS/400 system.
The name of the *ASYNC line this connection will run over (from “Step 1 Configure an Asynchronous Line Description” on page 129).
Modem information, if you are going to use a modem. (from “Step 2 - Configure
AS/400 For Your Modem” on page 130).
The name of an authorization list, if you want to restrict use of the profile to a
specific group of users. See “System Access Authorization List” on page 146 for
details.
Other information is also required, depending on the choices you make when
configuring the profile. Review the information about the dial-in profile, in “Dial-In
(*ANS) Point-to-Point Profile Parameters” on page 140 to determine if you are ready
to add the profile.
To add a profile:
1. Choose Option 1 - Work with point-to-point TCP/IP from the Configure
Point-to-Point TCP/IP display.
2. Type 1 in the Opt column
3. Type a name for the profile
4. Type *ANS to add a dial-in profile
Step 5 - Add a Dial-Out (*DIAL) Configuration Profile
Dial-out connection profiles are called *DIAL profiles. You use them to dial out to
remote systems. Before you start entering information on the following displays, you
need to have some information ready. For example, write down the following:
The name of the *ASYNC line this connection will run over (from “Step 1 Configure an Asynchronous Line Description” on page 129).
Modem information, if you are going to use a modem. (from “Step 2 - Configure
AS/400 For Your Modem” on page 130).
The information for accessing the remote system, such as the modem telephone
number, a user ID, and a password. See “Remote System Access Information”
on page 152 for details.
Other information is also required, depending on the choices that you make when
you configure the profile. To help determine if you need more information for your
configuration profile, see the following:
v Figure 99 on page 147 contains a sample display for adding profile EEL.
v “Dial-Out Point-to-Point Profile Parameters” on page 147 contains information
about each parameter.
To add the profile:
1. Type 1 in the Opt column
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
133
2. Type a name for the profile
3. Type *DIAL to create a dial-out profile
Step 6 - Start the Configuration Profile
Figure 88 shows a number of SLIP *DIAL profiles. Use the option 9=Start to start a
profile.
Work with Point-to-Point TCP/IP
Type option, press Enter.
1=Add
2=Change
3=Copy
4=Remove
9=Start
10=End
12=Work with line status
5=Display details
6=Print
14=Work with session job
Opt
Name
Mode
Type
Status
Line
Description
Line
Type
9__
___
___
___
___
___
___
___
___
MOLEANS1
NIMROD
PEBBLES
AS8TO7NSW
BAMBAM
DIALW31
IBMIGNSP
IBMIGNSP1
IBMIGNSP2
*ANS
*ANS
*ANS
*DIAL
*DIAL
*DIAL
*DIAL
*DIAL
*DIAL
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
INACTIVE
STRSSN
RINGW
INACTIVE
INACTIVE
INACTIVE
ACTIVE
INACTIVE
INACTIVE
ASCSWIT6
ASCSWIT4
ASCSWIT8
ASCNONSW3
ASCNONSW3
ASCSWIT5
ASCSWIT7
ASCSWIT7
ASCSWIT7
*ASYNC
*ASYNC QTPPANS021
*ASYNC QTPPANS020
*ASYNC
*ASYNC
*ASYNC QTPPDIAL90
*ASYNC QTPPDIAL93
*ASYNC QTPPDIAL83
*ASYNC QTPPDIAL89
F8=Work with modems
F11=Display text
Job
Name
More...
F9=Command line
F10=Local interface status
F12=Cancel
F14=Work with session jobs
F24=More keys
Figure 88. Work with Point-to-Point TCP/IP-Starting a SLIP Profile
Before you start a profile that is defined for a given line description, make sure that
the line description is not already being used by a different profile. Only one profile
at a time can use a given line.
When you start a profile by using option 9 from this display, you run the
STRTCPPTP command with its default settings. Other settings are available for
your use. For example, you may want to send an inquiry message that requires a
response before AS/400 releases the job. For example, use the inquiry message if
you are doing problem analysis and need to start the System Licensed Internal
Code (SLIC) component trace, tracing the ASCII device and controller. If AS/400 is
creating the device and controller names automatically at SLIP profile startup, you
need a way to pause the SLIP session job so you can display the object names. Or
you may want to keep the controller and device descriptions that AS/400 created
automatically, so that the jobs can be reused.
|
|
|
|
|
|
|
|
|
|
If your configuration profile does not start, you can print the script dialog that occurs
during start by specifying the *ERROR or *PRINT options on the STRTCPPTP
command. For information about using the *ERROR and *PRINT parameters, see
“Point-to-Point Jobs That Are Not Active” on page 139.
Monitoring Point-to-Point Activity
Use the Work with Point-to-Point TCP/IP (WRKTCPPTP) command to monitor and
manage SLIP activity.
134
OS/400 TCP/IP Configuration and Reference V4R4
Options From WRKTCPPTP
Using Figure 89 as a reference, the following is a summary of selected
management tasks you can do from this display. This information is a supplement to
the information provided in the online help information for the various options. This
information is not intended to be a complete summary of the online text. Be sure
the profile that you want to change, copy, or remove is not active.
Work with Point-to-Point TCP/IP
Type option, press Enter.
1=Add
2=Change
3=Copy
4=Remove
9=Start
10=End
12=Work with line status
5=Display details
6=Print
14=Work with session job
Opt
Name
Mode
Type
Status
Line
Description
Line
Type
___
___
___
___
___
___
_14
___
___
MOLEANS1
NIMROD
PEBBLES
AS8TO7NSW
BAMBAM
DIALW31
IBMIGNSP
IBMIGNSP1
IBMIGNSP2
*ANS
*ANS
*ANS
*DIAL
*DIAL
*DIAL
*DIAL
*DIAL
*DIAL
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
*SLIP
INACTIVE
STRSSN
RINGW
INACTIVE
INACTIVE
INACTIVE
ACTIVE
INACTIVE
INACTIVE
ASCSWIT6
ASCSWIT4
ASCSWIT8
ASCNONSW3
ASCNONSW3
ASCSWIT5
ASCSWIT7
ASCSWIT7
ASCSWIT7
*ASYNC
*ASYNC QTPPANS021
*ASYNC QTPPANS020
*ASYNC
*ASYNC
*ASYNC QTPPDIAL90
*ASYNC QTPPDIAL93
*ASYNC QTPPDIAL83
*ASYNC QTPPDIAL89
F8=Work with modems
F11=Display text
Job
Name
More...
F9=Command line
F10=Local interface status
F12=Cancel
F14=Work with session jobs
F24=More keys
Figure 89. Work with Point-to-Point TCP/IP-Working With a Specific Job
Option 1 (Add)
Use this option to add a new configuration profile. See “Step 3 - Determine
Configuration Profile Type” on page 132 for information about the connection
profiles.
Option 2 (Change)
Use this option to change the information associated with a configuration profile
that is not active.
Option 3 (Copy)
Use this option to add a new profile that has the exact same characteristics as
the one being copied.
Option 4 (Remove)
Use this option to remove a configuration profile that is not active.
Option 5 (Display)
Use this option to display a configuration profile.
Option 6 (Print)
Use this option to print the same information about the configuration profile that
you see on the display when you select option 5.
Option 9 (Start)
Use this option to start a point-to-point session for a particular configuration
profile. This option calls the Start Point-to-Point TCP/IP (STRTCPPTP)
command with the name of the profile. If you enter the command and press
F4=Prompt, you can specify:
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
135
v Which profile to start.
v Whether to capture any errors that occur while establishing the Point-to-Point
session.
v Whether to capture the complete connection script dialog in a spooled file.
F8 (Work with modems)
Displays the Work with TCP/IP Point-to-Point Modem Information display
(shown in Figure 86 on page 131).
F10 (Local interface status)
Displays the Work with TCP/IP Interface display. From this display you can
display information about particular interfaces and associated routes, start or
end a TCP/IP interface, or work with configuration status.
F14 (Work with session jobs)
Runs the Work with Active Jobs (WRKACTJOB) command for active jobs with
job names that start with the characters QTPP. This displays a list of any active
point-to-point TCP/IP jobs and allows you to work directly with these jobs. For
more information about managing jobs, see “Working With Point-to-Point Jobs”.
Working With Point-to-Point Jobs
SLIP jobs are Point-to-Point jobs that run in the QSYSWRK subsystem. In general,
you can work with the Point-to-Point jobs just as you work with any other jobs
running on AS/400. The Work Management book contains detailed information
about how to manage AS/400 jobs. You can work with individual SLIP jobs for
profiles that have a job name associated with them as seen on the WRKTCPPTP
display ( Figure 89 on page 135). To work with a job, select 14=Work with session
job. If you select option 14 against a profile that does not have a job associated
with it, such as MOLEANS1, AS/400 displays an error message.
Point-to-Point Job Names: The Point-to-Point job names for SLIP start with the
string QTPP, where dial-out jobs (*DIAL) are QTPPDIALnn, and Dial-In jobs (*ANS)
are QTPPANSnnn. The number string nn or nnn is a sequential number from 1 to 99
for *DIAL jobs and 1 to 999 for *ANS jobs. The AS/400 system starts a new job for
each SLIP profile that you start.
Point-to-Point Job Status Indicators: This topic summarizes the job status
indicators that Point-to-Point jobs can have. Some of the status indicators show you
what AS/400 is doing as a connection is starting, in use, or ending. Other status
indicators show error conditions. The jobs displayed in Figure 89 on page 135 show
some of the possible status indicators.
INACTIVE
No jobs are currently running for this profile. However, if a job is listed in under
Job Name on the Work with Point-to-Point TCP/IP display, you can display the
spooled file output for the job. To do this, select option 14 (Work with session
job). Option 14 runs the WRKJOB command for the configuration profile.
SBMERR
An error occurred during the submission of the job. If a SBMJOB fails (SLIP
status SBMERR), then no job name exists. The job name and job number are
generated if the SBMJOB actually completes and the job is added to the job
queue. If SBMERR occurs, look at the messages in the job log of the job that
ran the STRTCPPTP command to determine what caused the error.
136
OS/400 TCP/IP Configuration and Reference V4R4
OUTQ
The connection has ended, and job information is available. Select option 14 to
display the job information.
JOBQ
A request to start the connection was submitted. The job is waiting on the job
queue.
STRSSN
A job is starting for this profile, but has not yet completed.
ENDSSN
The connection for this profile is ending.
JOBLOG
The connection for this profile has ended, and AS/400 is placing information in
the job log for this job.
ADDTCPCFG
TCP/IP interface address information is being added for the connection.
RMVTCPCFG
TCP/IP interface information is being removed from the connection.
MSGW
An inquiry message was sent to either the QTCP or to the QSYSOPR message
queue. Job connection processing is suspended until you respond to the inquiry
message.
SSNERR
An error occurred while the connection was established. To find out more about
the error, type option 14 next to the configuration profile name to run the
WRKJOB command.
STRTCPCMN
Starting TCP/IP communications. AS/400 is starting the SLIP protocol jobs.
ENDTCPCMN
Ending TCP/IP communications.
DIAL
AS/400 is calling the remote system to establish the connection.
RINGW
For a *ANS session that is waiting for someone to call.
CNNDIALOG
Connection dialog information is being exchanged over this connection.
ACTIVE
Connection has been made, and the job is running.
ICFERR
An error occurred during intersystem communications function (ICF)
communications. To find out more about the error, type option 14 next to the
configuration profile name to run the WRKJOB command.
Active Point-to-Point Jobs: Figure 90 on page 138 shows some active
point-to-point jobs that AS/400 displays when you do either of the following:
v Press F14 from the WRKTCPPTP display.
v Select option 2 from the Configure Point-to-Point TCP/IP display.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
137
To display the jobs, AS/400 runs the WRKACTJOB command. If no SLIP profiles
are started, AS/400 displays the following message:
No active jobs to display.
Work with Active Jobs
CPU %:
11.4
Elapsed time:
Type options, press Enter.
2=Change
3=Hold
4=End
8=Work with spooled files
Opt
__
__
__
Subsystem/Job User
QTPPANS020 QTCP
QTPPANS021 QTCP
QTPPDIAL93 QTCP
07:17:29
Active jobs:
5=Work with
6=Release
13=Disconnect ...
Type
BCH
BCH
BCH
CPU %
.0
.0
.0
7=Display message
Function
PGM-QTOCPPSM
PGM-QTOCPPSM
PGM-QTOCPPSM
Parameters or command
===>
F3=Exit
F5=Refresh
F10=Restart statistics
F12=Cancel
F23=More options
F24=More keys
59
Status
ICFW
RUN
ICFW
Bottom
F11=Display elapsed date
Figure 90. Work with Active Jobs-Displaying SLIP Jobs
Figure 91 shows the WRKJOB display for job QTPPDIAL93. For active
point-to-point jobs, option 10 from the WRKJOB display shows you the current job
log. You can use the job log to monitor the job while the job is running.
Work with Job
Job:
QTPPDIAL93
User:
QTCP
Number:
System:
009919
SYSNAM
Select one of the following:
1.
2.
3.
4.
10.
11.
12.
13.
14.
15.
16.
Display job status attributes
Display job definition attributes
Display job run attributes, if active
Work with spooled files
Display job log, if active or on job queue
Display call stack, if active
Work with locks, if active
Display library list, if active
Display open files, if active
Display file overrides, if active
Display commitment control status, if active
Selection or command
===> 10
F3=Exit
F4=Prompt
F9=Retrieve
Figure 91. Working with a Job
138
OS/400 TCP/IP Configuration and Reference V4R4
F12=Cancel
More...
Point-to-Point Jobs That Are Not Active: To work with point-to-point jobs that
are not active, type option 14 next to the job in the Work with Point-to-Point
TCP/IP display. Then select option 4 from the WRKJOB menu to work with the
spooled file output from the job. The spooled file output includes a spooled file for
the job log and possibly a spooled file for the connection script dialog that occurred
between AS/400 and the remote system. AS/400 creates spooled file output for the
connection script dialog for connections that:
v Use a connection script, and
v Run with the output parameter on the STRTCPPTP command set to either of the
following:
– *ERROR (the default), and an error occurs during the connection dialog
between the local AS/400 system and the remote system.
– *PRINT, which puts the complete dialog into a spooled file.
Figure 93 on page 140 contains an example of a spooled file that contains
connection dialog.
Figure 92 shows the Work with Job Spooled Files (WRKSPLF) display. The display
results when you use option 4 from the WRKJOB display for a SLIP job that is not
active. In this case, job QTPPDIAL90, which is associated with SLIP profile
DIALW31, has two spooled files. You can display the output by using option 5
(Display).
Work with Job Spooled Files
Job:
QTPPDIAL90
User:
QTCP
Number:
Type options, press Enter.
1=Send
2=Change
3=Hold
4=Delete
5=Display
8=Attributes
9=Work with printing status
Opt
5
_
File
DIALW31
QPJOBLOG
Device or
Queue
PRT01
QEZJOBLOG
User Data
QTPPDIAL90
QTPPDIAL90
Status
RDY
RDY
Parameters for options 1, 2, 3 or command
===>
F3=Exit
F10=View 3
F11=View 2
F12=Cancel
Total
Pages
2
6
009524
6=Release
Current
Page
7=Messages
Copies
1
1
Bottom
F22=Printers
F24=More keys
Figure 92. Work with Job Spooled Files-Spooled Output for SLIP Jobs
The spooled file DIALW31 in Figure 92 is illustrated in Figure 93 on page 140.
v The leftmost column indicates the time a command, response, or informational
message was recorded.
v The next column from the left indicates the type of information that is recorded.
– === indicates that informational text follows
– ==> indicates outbound text follows
– <== indicates inbound text follows
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
139
v The remaining text on a line is one of the following:
– Modem command or response
– Informational message
– Inbound or outbound text itself
Figure 93 shows an example of the information AS/400 places into the connection
dialog script spooled file output.
Display Spooled File
File . . . . . : DIALW31
Page/Line
Control . . . . .
Columns
Find . . . . . .
10:21:57 === Attempting modem reset.
10:21:57 ==> AT&FS0=0
10:21:57 === Reading modem response.
10:21:58 <==
10:21:58 <== OK
10:22:02 === Attempting modem initialization.
10:22:02 ==> AT&D2&C1X4V1Q0S7=70&#172;N6&K3%C1E0&S1
10:22:02 === Reading modem response.
10:22:02 <== AT&D2&C1X4V1Q0S7=70&#172;N6&K3%C1E0&S1
10:22:02 <== OK
10:22:06 === Attempting modem dial/answer.
10:22:06 ==> ATDT9,,752-4622
10:22:07 === Reading modem response.
10:22:12 === Reading modem response.
10:22:37 <==
10:22:37 <== CONNECT 19200/V42BIS
10:22:37 ==>
10:22:41 <== login:
10:22:41 ==> sliptest8
10:22:45 <== password:
10:22:45 ==> ********
10:22:45 === Establishing remote host connection.
10:27:08 === Remote host connection ended.
1/6
1 - 78
Figure 93. Work With Job Spooled Files-Spooled Output From a SLIP Job
You can use the connection script spooled file output to accomplish the following:
v Debug connection scripts.
v Ensure that the commands being sent to the modem are correct.
v Ensure that the expected modem responses are returned.
Dial-In (*ANS) Point-to-Point Profile Parameters
This topic provides explanations of the parameters available on the dial-in profile.
Enter CFGTCPPTP on the command line to get the display shown in Figure 94 on
page 141.
140
OS/400 TCP/IP Configuration and Reference V4R4
Work with Point-to-Point TCP/IP
Type option, press Enter.
1=Add
2=Change
3=Copy
4=Remove
9=Start
10=End
12=Work with line status
Opt Name
1
EDITH
Mode
*ANS
Type
5=Display details
6=Print
14=Work with session job
Line
Description
Status
Line
Type
Job
Name
Figure 94. Add *ANS Configuration Profile for SLIP
Figure 95 shows the default entries you get when you first access the display.
Add TCP/IP Point-to-Point *ANS Profile
Name:
Text
EDITH
System:
SYSNAM
„1…
Type choices, press Enter.
TCP/IP information:
Protocol type . . . . . .
Local interface address .
Remote IP address . . . .
Maximum transmission unit
Allow proxy ARP . . . . .
Add default route . . . .
.
.
.
.
.
.
Physical line information:
Line description . . . .
Line type . . . . . . . .
Autocreate controller and
Remote location name .
. . . . .
. . . . :
device
. . . . .
F2=Change modem information
F12=Cancel
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
.
.
.
.
.
F3=Exit
*SLIP
576
N
N
*ASYNC
Y
F4=List
„2…
„3…
„4…
„5…
„6…
Address, F4 for list
Address
576-1006
Y=Yes, N=No
Y=Yes, N=No
„7…
Name
„8…
„9…
Y=Yes, N=No
Name
More...
F9=Command line
Figure 95. Creating a *ANS Configuration Profile-Display 1
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
141
Add TCP/IP Point-to-Point *ANS Profile
Name:
Text
EDITH
System:
SYSNAM
Type choices, press Enter.
Modem information:
Use a modem . . . . . . . . . . . .
Modem information name
Script source information:
Use connection dialog script . .
Member . . . . . . . . . . . .
File . . . . . . . . . . . . .
Library . . . . . . . . . . .
ASCII character set identifier
F2=Change modem information
F12=Cancel
.
.
.
.
F3=Exit
Y
„10…
Y=Yes, N=No
F4 for list
N
„11…
ANS400
QATOCPPSCR
QUSRSYS
00819
Y=Yes, N=No
Name
Name
Name
1-65533, *DFT
F4=List
More...
F9=Command line
Figure 96. Creating a *ANS Configuration Profile-Display 2
Add TCP/IP Point-to-Point *ANS Profile
Name:
Text
EDITH
System:
SYSNAM
Type choices, press Enter.
Local system security:
Allow IP datagram forwarding . . .
System access authorization list
F2=Change modem information
F12=Cancel
F3=Exit
N
*NONE
F4=List
„12…
„13…
F9=Command line
Figure 97. Creating a *ANS Configuration Profile-Display 3
Text:
„1…
Enter descriptive text for this configuration profile
Local Interface Address:
„2…
You can do one of the following:
v Enter a new interface address.
The new address can be:
142
OS/400 TCP/IP Configuration and Reference V4R4
Y=Yes, N=No
*NONE, Name
Bottom
– A new interface address, or
– An interface address on the same network as an existing interface.
v Choose an existing address.
To find these existing addresses, press F4 (List) when the cursor is in
this field. Then select the interface you want to use.
Note: Using this option allows this AS/400 system to serve as a proxy
for ARP requests for the remote IP address of the system dialing
in.
For more information about proxy ARP, see “Allow Proxy ARP”.
Remote IP Address:
„3…
If you choose an existing interface address for the local interface address,
then AS/400 uses the remote interface address for TCP/IP communications
over the point-to-point connection. If you define a new local interface
address, then AS/400 uses the remote interface address only for routing to
the remote system.
If the remote system that is dialing in expects the IP address to be passed
back to it, then the remote system uses the remote address defined here as
its local interface address for the connection.
Note: If you choose to use proxy address resolution (ARP), then this
remote IP address must be on the same subnet as the local
interface address. See “Subnetworks and Subnet Masks” on page 6
for more information about subnets.
Maximum Transmission Unit:
„4…
This is the size in bytes of the largest packet that AS/400 can send over the
physical line that this interface uses. Ensure that the size of the MTU is no
larger than the maximum buffer size (MAXBUFFER) parameter that is
specified for the *ASYNC line you select for this *SLIP interface.
Allow Proxy ARP:
„5…
Select Y if you plan to use the local interface for proxy ARP. The local
interface must be an existing interface address.
Proxy ARP-Definition: Proxy ARP is a technique that allows one machine, the
proxy agent, to answer ARP requests that are actually destined for a different
machine. Proxy ARP is useful with SLIP because it allows a remote SLIP client to
logically appear to be part of a local network. This provides automatic connectivity
between the SLIP client and all hosts on a local network.
Proxy ARP-Example: Consider AS/400 with an IP address of 9.4.24.93, attached
to the 9.4.24 subnet. A remote workstation dials in to AS/400. AS/400 assigns an IP
address of 9.4.24.193. to the remote workstation. AS/400 sends data for 9.4.24.193
over the SLIP line. But to all other 9.4.24.x hosts on the local LAN, 9.4.24.193
appears to be attached to the local LAN. To send data to 9.4.24.193, the other
hosts send an ARP request to 9.4.24.193. SLIP connections do not support ARP.
Without proxy ARP, the remote workstation has no way to respond to the ARP
request. If AS/400 is configured to allow proxy ARP, AS/400 answers the ARP
request for 9.4.24.193. AS/400 receives the IP packet from the originating host, and
forwards the packet on over the SLIP connection to the remote client.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
143
If you want AS/400 to do this, set the Proxy ARP parameter (“Allow Proxy ARP” on
page 143 ) to Y.
Notes:
1. Only interface types that support ARP can be used with Proxy ARP. Interface
types that support ARP include token-ring, Ethernet, and FDDI. Point-to-point
interface types such as X.25 and *SLIP do not support ARP.
2. Proxy ARP does not mean proxy gateway. PCs connected directly to the LAN
cannot use AS/400 system as a gateway for Internet access through SLIP.
Be sure that the local interface is active before you start the configuration profile.
The start fails if the local interface is not active when you start the point-to-point
TCP/IP profile. To determine if the interface is active, type the following:
NETSTAT *IFC
Add Default Route:
„6…
Select Y to add a default route to the system. AS/400 adds the route when
the SLIP session is started. The local interface address specified in this
configuration profile is the next hop for the default route that is added.
Note: Only one default route can be active at a time. If you run the Start
Point-to-Point TCP/IP (STRTCPPTP) command for a configuration
profile that specifies Y to add a default route, and a default route is
already active, the session cannot start.
Use this option for *ANS profiles if you want to do the following:
v Connect two networks together and use a SLIP connection to do so
v Use an automatic default route to the other network
Otherwise, do not automatically add routes for your *ANS profiles.
Line Description:
„7…
Type the name of the line description to be used for this connection.
See “Step 1 - Configure an Asynchronous Line Description” on page 129 for
information about how to create or find the line description.
Autocreate Controller and Device:
„8…
Specify the default value of Y to have AS/400 automatically create the
controller and device descriptions for the line description specified in 7 (
“Line Description”). If you specify N, you must specify a remote location
name. See “Remote Location Name” on page 145.
Notes:
1. The setting for this parameter does not affect and is not affected by any
of the autoconfiguration system values (QAUTOCFG, QAUTORMT and
QAUTOVRT).
2. AS/400 creates controller and device descriptions only if they do not
already exist.
If Start Point-to-Point TCP/IP (STRTCPPTP) is issued with
AUTODLTCFG(*YES), then the controller and device description are
deleted when the point-to-point connection ends. The next time you
start a point-to-point connection using this profile the controller and
device descriptions are created again.
144
OS/400 TCP/IP Configuration and Reference V4R4
However, if STRTCPPTP is issued with AUTODLTCFG(*NO), AS/400
does not delete the controller and device descriptions when the
connection ends. The next time the profile is used the previously
created controller and device descriptions are re-used.
Remote Location Name:
„9…
If Autocreate Controller and Device is N then this field must specify the
remote location name defined in the device description of the controller and
device description pair to use when Start Point-to-Point TCP/IP
(STRTCPPTP) is issued for this configuration profile. If Autocreate
Controller and Device is Y, then any name entered in this field is ignored.
Specify a value for this field only when using a specific controller and
device description pair that you created.
Notes:
1. The value specified is the same value specified for the Create
Asynchronous Device Description (CRTDEVASC) command
RMTLOCNAME parameter on the device description you want to use
when activating this point-to-point connection.
2. The controller and device description that you create must have status
VARIED ON prior to starting the TCP/IP point-to-point connection.
3. The TCP/IP point-to-point connection cannot start if the device
description is already in use.
Modem Information:
„10…
You must specify modem information if you are using a modem. For most
modems, you can select one of the entries that appears when you press
F4.
Note: You can change modem information by pressing F2 on the Add
TCP/IP Point-to-Point *ANS Profile display. If no modem
information is found, go to “Step 2 - Configure AS/400 For Your
Modem” on page 130.
Use Connection Dialog Script:
„11…
The remote system that is dialing in must provide the information required
by the server connection script. The remote system can do this by doing
either of the following:
v Using a matching connection script on its system.
v Providing the information interactively.
Note: Not all systems support the option to provide the information
interactively.
You determine whether a script is used by specifying Y or N on this
parameter. The most common use of scripts is to exchange sign-on and
password information before a remote client may connect to AS/400
system. Another common use is to dynamically assign an IP address to the
remote SLIP client. See “NLS Considerations” on page 125 for information
about the ASCII character set identifier used in scripts.
Allow IP Datagram Forwarding:
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
145
„12…
Use IP datagram forwarding to forward IP datagrams that come from a
remote host, but are not meant for the local IP address.
The default is N (No). Datagrams from the remote system that are not
destined for this address are discarded.
Note: You can disable datagram forwarding for all TCP/IP interfaces on this
system by using the command CHGTCPA IPDTGFWD(*NO). When
you do this, the value set in configuration profiles is ignored, and no
IP datagrams are forwarded. Once a remote system is connected to
AS/400 and the user signs on to AS/400 using TELNET or FTP, then
the user can access the other systems in the network that is
connected to this AS/400 system. The user has access because the
interface address for the user is now from this AS/400 system and
not from the original remote client.
To determine the current value for system datagram forwarding, enter
CHGTCPA and press F4. The AS/400 prompter will show the current value
for the parameter.
For information about security for AS/400 support of the SLIP protocol, see
the Tips and Tools for Securing Your AS/400 book.
PING-ing your local IP address: After establishing a point-to-point connection
with a remote system, it is typical to try to PING both the remote and local IP
addresses defined for the connection. This is done to ensure the connection to the
remote system is actually operational. If the connection is complete, the PING to
the remote IP address should complete successfully. However, a PING to your local
IP address may or may not work, depending on whether the remote system
forwards IP datagrams or not.
When a PING is done on a local IP address for point-to-point links such as SLIP,
X.25, and so on, the PING ECHO request will actually leave the local system and
travel to the remote system. The remote system will then look at the PING ECHO
request and determine that the PING address is not its own. If the remote system is
capable of forwarding IP datagrams, it will resend the PING ECHO request back out
over the point-to-point link to the local system. When the local system receives the
PING ECHO request, it determines that the PING address is its own and replies
back with a PING ECHO reply completing the PING request. However, if the remote
system does not do IP datagram forwarding, then a PING of your local IP address
will not work since the PING ECHO request will be thrown out.
PING time metrics will normally show that a PING to the local IP address takes
twice as long to complete as a PING to the remote IP address because all PING
requests to the local address have to travel through the remote system first.
System Access Authorization List:
„13…
Enter the name of an AS/400 authorization list if you want to allow only the
user profiles that are specified in the authorization list to connect to this
AS/400 from a remote system over SLIP.
Note: If ’Use connection dialog script’ (see “Use Connection Dialog Script”
on page 145) is set to N (No), you must set the system access
authorization list to *NONE. Authorization list checking is only done
as part of a connection dialog script.
146
OS/400 TCP/IP Configuration and Reference V4R4
Use the Create Authorization List (CRTAUTL) command to create an
authorization list. Use the Add Authorization List Entry (ADDAUTLE)
command to add user profile entries to the list.
For more information about how and when to use authorization lists, see
the Tips and Tools for Securing Your AS/400 book.
Dial-Out Point-to-Point Profile Parameters: To create a dial-out (*DIAL) profile,
enter WRKTCPPTP. AS/400 displays the Work with Point-to-Point TCP/IP display
shown in Figure 98. Enter the following:
1. Option 1 to add a profile.
2. A name for the profile.
3. *DIAL for a dial-out profile.
Work with Point-to-Point TCP/IP
Type option, press Enter.
1=Add
2=Change
3=Copy
4=Remove
9=Start
10=End
12=Work with line status
Opt Name
1
EEL
Mode
*DIAL
Type
5=Display details
6=Print
14=Work with session job
Line
Description
Status
Line
Type
Job
Name
Figure 98. Add *DIAL Configuration Profile for SLIP
Figure 99, Figure 100, Figure 101, and Figure 102 show the default entries that
AS/400 displays for adding a *DIAL profile.
Add TCP/IP Point-to-Point *DIAL Profile
Name:
Text
EEL
System:
SYSNAM
Type choices, press Enter.
TCP/IP information:
Protocol type . . . . . . .
Local interface address . .
Remote IP address . . . . .
Request header compression
Maximum transmission unit .
Add default route . . . . .
Additional name server . .
F2=Change modem information
F12=Cancel
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
.
.
.
.
.
.
F3=Exit
*SLIP
Y
576
N
*NONE
F4=List
„1…
„2…
„3…
„4…
„5…
„6…
Address, *DYNAMIC
Address, *DYNAMIC
Y=Yes, N=No
576-1006
Y=Yes, N=No
Address, *NONE
F9=Command line
More...
Figure 99. Creating a *DIAL Configuration Profile-Display 1
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
147
Add TCP/IP Point-to-Point *DIAL Profile
Name:
Text
System:
EEL
SYSNAM
Type choices, press Enter.
Physical line information:
Line description . . . .
Line type . . . . . . . .
Autocreate controller and
Remote location name .
. . . . .
. . . . :
device
. . . . .
Modem information:
Use a modem . . . . . . . . . . . .
Modem information name
F2=Change modem information
F12=Cancel
F3=Exit
*ASYNC
Y
Y
F4=List
„7…
Name
„8…
„9…
Y=Yes, N=No
Name
„10…
Y=Yes, N=No
F4 for list
More...
F9=Command line
Figure 100. Creating a *DIAL Configuration Profile-Display 2
Add TCP/IP Point-to-Point *DIAL Profile
Name:
Text
EEL
System:
SYSNAM
Type choices, press Enter.
Script source information:
Use connection dialog script . .
Member . . . . . . . . . . . .
File . . . . . . . . . . . . .
Library . . . . . . . . . . .
ASCII character set identifier
F2=Change modem information
F12=Cancel
.
.
.
.
F3=Exit
„11…
N
DIAL400
QATOCPPSCR
QUSRSYS
00819
F4=List
Y=Yes, N=No
Name
Name
Name
1-65533, *DFT
F9=Command line
Figure 101. Creating a *DIAL Configuration Profile-Display 3
148
OS/400 TCP/IP Configuration and Reference V4R4
More...
Add TCP/IP Point-to-Point *DIAL Profile
Name:
Text
EEL
System:
SYSNAM
Type choices, press Enter.
„12…
Remote system access information:
Remote service phone number
*NONE
Remote service access name
*NONE
Remote service access password
*NONE
F2=Change modem information
F12=Cancel
F3=Exit
F4=List
F9=Command line
Bottom
Figure 102. Creating a *DIAL Configuration Profile-Display 4
Local Interface Address:
„1…
This address is the local interface address to be used by this AS/400 for
point-to-point communications.
You can do one of the following:
v Enter a new interface address.
v Enter a new interface address on the same network as an existing
interface when you want to tie two AS/400 systems together.
v Choose *DYNAMIC.
Use the special value *DYNAMIC when the remote system specifies a
local interface address for your system. If you specify *DYNAMIC, you
must use a connection dialog script. Both the connection dialog script
and the remote system must support IP address passing.
Remote IP Address:
„2…
Enter the IP address of the remote system for this profile. This address is
the local interface address on the remote system.
Specify *DYNAMIC to allow the remote address to be determined
dynamically. You need this special value when the remote system specifies
a remote IP address for your system.
Note: *DYNAMIC requires use of a connection dialog script.
Request Header Compression:
„3…
The default, Y, indicates this system compresses header information when it
establishes the point-to-point connection. If the remote system does not
support the header compression, which is called Van Jacobson (VJ) header
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
149
compression, 1 AS/400 establishes a session that does not use header
compression. Therefore, you should not need to change this value.
Using header compression improves the performance of the serial line,
which is usually slow anyway.
Maximum Transmission Unit:
„4…
The maximum transmission unit (MTU) is the size in bytes of the largest
packet that is to be sent over the physical line that this interface uses.
Note: The MTU size cannot be larger than the maximum buffer size
(MAXBUFFER) on the *ASYNC line description that this *SLIP
interface uses.
Add Default Route:
„5…
If you change this value to Y (Yes), AS/400 adds a default route to the
remote system when the session is started. The local interface address
specified in this configuration profile becomes the next hop for the default
route that is added. Turn this option off when you know to which host this
AS/400 system will connect.
Note: There can be only one active default route. If the Start Point-to-Point
TCP/IP (STRTCPPTP) command is issued for a configuration profile
that specifies Y for Add default route field, and a default route is
already active, the session cannot start.
Additional Name Server:
„6…
Enter the IP address of a name server that is accessed through the
point-to-point connection to the remote system.
If you specify a name server address, AS/400 adds the name server
address to the end of any existing list of name servers when this
configuration profile is started. This field is valid only for *DIAL point-to-point
TCP/IP profiles.
If you use an ISP to connect to the Internet, you may receive a name
server address from the ISP. Then when you connect, you can use host
names instead of IP addresses for remote sites.
If you add an additional name server for this connection, then you must fully
qualify any host names on this connection. Otherwise, the domain of your
local AS/400 is appended to the unqualified host name. If this occurs, the
additional name server cannot find the host entry.
Note: There can only be one active point-to-point session with an
additional name server address defined. If the Start Point-to-Point
TCP/IP (STRTCPPTP) command is issued for a profile that specifies
Y for the Additional Nameserver field, and a point-to-point profile is
already active with an additional name server address, the session
cannot start. The default value for this field is *NONE. The list of
name servers is not changed.
This name server provides limited support when connecting to a remote
network. Most sockets applications that were activated prior to establishing
1. SLIP support with header compression is also called CSLIP, or Compressed Serial Line Internet Protocol.
150
OS/400 TCP/IP Configuration and Reference V4R4
the *DIAL connection to a remote system will not see this name server
unless they are ended and restarted. In particular, you will need to restart
SMTP after establishing a remote connection in order to use a name server
that has been dynamically added.
Line Description:
„7…
Type the name of the line description to be used for this connection.
See “Step 1 - Configure an Asynchronous Line Description” on page 129 for
information about how to create or find the line description.
Autocreate Controller and Device:
„8…
Specify the default value of Y to have AS/400 automatically create the
controller and device descriptions for the line description specified in 7
(“Line Description”). If you specify N, you must specify a remote location
name (see “Remote Location Name”).
Notes:
1. The setting for this parameter does not affect and is not affected by any
of the autoconfiguration system values (QAUTOCFG, QAUTORMT and
QAUTOVRT).
2. AS/400 creates controller and device descriptions only if they do not
already exist.
If Start Point-to-Point TCP/IP (STRTCPPTP) is issued with
AUTODLTCFG(*YES), then when the point-to-point connection ends the
controller and device description are deleted. The next time you start a
point-to-point connection using this profile the controller and device
descriptions are created again.
However, if STRTCPPTP is issued with AUTODLTCFG(*NO), AS/400
does not delete the controller and device descriptions when the
connection ends. The next time the profile is used the previously
created controller and device descriptions are re-used.
Remote Location Name:
„9…
If Autocreate Controller and Device is N then this field must specify the
remote location name defined in the device description of the controller and
device description pair to use when Start Point-to-Point TCP/IP
(STRTCPPTP) is issued for this configuration profile. If Autocreate
Controller and Device is Y, then any name entered in this field is ignored.
Specify a value for this field only when using a specific controller and
device description pair that you created.
Notes:
1. The value specified is the same value specified for the Create
Asynchronous Device Description (CRTDEVASC) command
RMTLOCNAME parameter on the device description you want to use
when activating this point-to-point connection.
2. The controller and device description that you create must have status
VARIED ON prior to starting the TCP/IP point-to-point connection.
3. The TCP/IP point-to-point connection cannot start if the device
description is already in use.
Modem Information:
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
151
„10…
You must specify modem information if you are using a modem. For most
modems, you can select one of the entries that appears when you press
F4.
If your modem does not appear in the list, go to “Step 2 - Configure AS/400
For Your Modem” on page 130.
Script Source Information:
„11…
You determine whether a connection script is to be used by specifying Y or
N. If you specify Y, the remote system that is dialing in must provide the
information required by the server connection script that you specify. The
remote system can do this by either of the following:
v Using a matching connection script on its system.
v Providing the information interactively.
Note: Not all systems support the option to provide the information
interactively.
The most common uses of scripts are for exchanging sign-on and password
information before permitting the remote client to connect to AS/400 system.
Another common use is to dynamically assign an IP address to the remote
SLIP client. If you do not require these functions, you can bypass script
processing.
For information about the ASCII character set identifier, see “NLS
Considerations” on page 125.
For examples of scripts, see “Connection Dialog Scripts” on page 156.
Remote System Access Information:
„12…
The remote system access information consists of the following:
v The remote service telephone number.
v The remote service access name.
v The remote service access password.
The remote service telephone number is the number that the modem calls
to contact the remote system. Use the remote service access name to
provide a user ID when the remote system requires this information before
allowing you to connect. If the remote system requires an account name in
addition to the user ID, then enter both values into the Remote service
access name field, separated by a blank as follows:
account userID
Use the remote service access password when the remote system also
requires you to provide a valid password for the user ID or account name.
If the remote system requires a user ID and password information, then you
must use a connection script and include the user ID and PASSWORD
keywords.
For examples of scripts, see “Connection Dialog Scripts” on page 156.
Asynchronous Line Description Parameters: There are many parameters for
AS/400 Create Line Description Asynchronous (CRTLINASC) command. This topic
152
OS/400 TCP/IP Configuration and Reference V4R4
describes the parameters that you must specify to use an asynchronous line
description with AS/400 TCP/IP point-to-point configuration profiles. This topic also
discusses parameters and parameter values that differ from the command defaults.
For more information about the parameters options for the CRTLINASC command,
see the Communications Configuration book.
Two examples of commands to create asynchronous line descriptions follow. The
line MODEMLIN using resource LIN011 is an example for a line that is connected to
a modem. The line description NOMODEMLIN using resource LIN022 is an
example of a direct connection. That is, the physical line for NOMODEMLIN is
directly connected to the remote system through a null modem adapter.
CRTLINASC Parameters When Using a Modem: The following topic discusses a
command that was used to create an asynchronous line description that is named
MODEMLIN. MODEMLIN uses resource LIN011. It was created to be used with
AS/400 point-to-point TCP/IP. Figure 103 on page 155 shows the parameters that
you should use for an asynchronous line that is attached to a modem.
CRTLINASC
LIND(MODEMLIN)
LINESPEED(19200)
CNN(*SWTPP)
SWTCNN(*DIAL)
AUTODIAL(*YES)
RSRCNAME(LIN011)
MAXBUFFER(1500)
DIALCMD(*OTHER)
AUTOANS(*NO)
INACTTMR(*NOMAX)
LIND(MODEMLIN)
The name of the line description- you specify this name in any AS/400 TCP/IP
point-to-point configuration profile that uses this line.
RSRCNAME(LIN011)
The unique name that is assigned by AS/400 to identify the physical
communications port attached to your system. This example uses LIN011 as
the name AS/400 has associated with the communications port. For information
about how to determine the resource name you need, see “Hardware
Requirements for the Asynchronous Line Description” on page 128.
LINESPEED(19200)
The line speed of the asynchronous line in bits per second (bps). If your
modem supports data rate conversion, you should be able to use line speed
19200. Most modems that support error correction also support data rate
conversion. If your modem does not support data rate conversion, then the
asynchronous line speed must match the rate that the modem connects to the
remote system.
Note: The 19,200 line speed is used for illustration here because this value
can be specified on any AS/400 system using any adapter and IOP
combination. If both your modem and AS/400 hardware support a higher
line speed, use this value instead.
See “Step 2 - Configure AS/400 For Your Modem” on page 130 for more
information on configuring your modem.
MAXBUFFER(1500)
The maximum size of any single data packet sent across the line. This value
must always be at least as large as the value specified for the Maximum
Transmission Unit (MTU) in any TCP/IP point-to-point profile that uses this line.
Note: The value MAXBUFFER(1500) is used in this example because the
value 1500 is larger than any MTU value that could be specified in a
TCP/IP point-to-point configuration profile.
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
153
CNN(*SWTPP)
Specifies that this is a switched point-to-point asynchronous line. The line
description must be specified as a switched line when using a modem.
DIALCMD(*OTHER)
Specifies that this asynchronous line is attached to a modem that uses the
Hayes AT command set. Only AT command modems are supported for use with
AS/400 TCP/IP point-to-point connection profiles. You must use this value if
SLIP is to use the asynchronous line.
SWTCNN(*DIAL)
You must specify this value when you specify DIALCMD(*OTHER).
Note: Do not confuse the value specified for SWTCNN with the operating
mode of your configuration profile. It does not matter whether line
description will be used with an operating mode *DIAL configuration
profile or a *ANS profile. You must always specify SWTCNN(*DIAL) for
the line.
AUTOANS(*NO)
Specifies that the support in AS/400 line description for automatic answering is
not used. You must specify this value when you specify SWTCNN(*DIAL).
Note: AS/400 TCP/IP Point-to-Point uses the Auto Answer Mode capability of
your modem to answer incoming calls to an *ANS Operating Mode
configuration profile. AUTOANS(*NO) does not affect the ability of
AS/400 SLIP to respond to an incoming call.
AUTODIAL(*YES)
You must specify this value when you specify DIALCMD(*OTHER).
INACTTMR(*NOMAX)
You must specify this value when you specify DIALCMD(*OTHER).
154
OS/400 TCP/IP Configuration and Reference V4R4
Create Line Desc (Async) (CRTLINASC)
Type choices, press Enter.
Line description . . . .
Resource name . . . . .
Online at IPL . . . . .
Physical interface . . .
Connection type . . . .
Switched network backup
Vary on wait . . . . . .
Autocall unit . . . . .
Data bits per character
Type of parity . . . . .
Stop bits . . . . . . .
Duplex . . . . . . . . .
Echo support . . . . . .
Line speed . . . . . . .
Modem type supported . .
Switched connection type
F3=Exit
F4=Prompt
F24=More keys
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F5=Refresh
LIND
>
RSRCNAME
>
ONLINE
INTERFACE
CNN> *SWTPP
SNBU
VRYWAIT
AUTOCALL
BITSCHAR
PARITY
STOPBITS
DUPLEX
ECHO
LINESPEED
>
MODEM
SWTCNN> *DIAL
F12=Cancel
MODEMLIN
LIN011
*YES
*RS232V24
*NO
*NOWAIT
*NO
8
*NONE
1
*FULL
*NONE
19200
*NORMAL
More...
F13=How to use this display
Create Line Desc (Async) (CRTLINASC)
Type choices, press Enter.
Autoanswer . . . . . . . . . . . AUTOANS> *NO
Autodial . . . . . . . . . . . . AUTODIAL> *YES
Dial command type . . . . . . . DIALCMD> *OTHER
Autocall resource name . . . . . ACRSRCNAME
Calling number . . . . . . . . . CALLNBR
*NONE
Inactivity timer . . . . . . . . INACTTMR> *NOMAX
Maximum buffer size . . . . . . MAXBUFFER
> 1500
Flow control . . . . . . . . . . FLOWCNTL
*NO
XON character . . . . . . . . . XONCHAR
11
XOFF character . . . . . . . . . XOFFCHAR
13
End-of-Record table:
EORTBL
End-of-Record character . . .
00
Trailing characters . . . . .
0
+ for more values
Figure 103. Creating an Asynchronous Line Description for a Line With a Modem-Example
CRTLINASC Parameters For a Direct Connection: This topic provides a sample
asynchronous line description for a direct connection. The line description name is
NOMODEMLIN. NOMODEMLIN uses resource LIN022. It was created to be used
with AS/400 point-to-point TCP/IP. This example assumes that asynchronous ports
of AS/400 and the remote system are directly connected through a NULL modem
adapter.
CRTLINASC LIND(NOMODEMLIN)
LINESPEED(19200)
CNN(*NONSWTPP)
RSRCNAME(LIN022)
MAXBUFFER(1500)
LIND(NOMODEMLIN)
The name of the line description- you specify this name in any AS/400 TCP/IP
point-to-point configuration profile that uses this line.
RSRCNAME(LIN022)
The unique name that AS/400 has assigned to identify the physical
communications port attached to your system. This example uses LIN022 is the
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
155
name AS/400 has assigned to the communications port. To determine the
resource name you need, see “Hardware Requirements for the Asynchronous
Line Description” on page 128.
LINESPEED(19200)
The line speed of the asynchronous line in bits per second (bps). The line
speed you specify must be compatible with the modem attached to the line. In
this example, the line speed is set to 19,200 bps.
Note: When using a direct connection, both systems must specify the same
value for the line speed.
MAXBUFFER(1500)
The maximum size of any single data packet sent across the line. This value
must always be at least as large as the value specified for the Maximum
Transmission Unit (MTU) in any TCP/IP point-to-point profile that uses this line.
Note: The value MAXBUFFER(1500) is used in this example because the
value 1500 is larger than any MTU value that could be specified in a
TCP/IP point-to-point configuration profile.
CNN(*NONSWTPP)
Specifies that this is a non-switched point-to-point asynchronous line. The line
description must be specified as a non-switched line when two systems are
directly connected with a NULL modem adapter.
Connection Dialog Scripts: To control whether AS/400 uses a connection script,
you configure the Use connection dialog script field on the point-to-point
configuration profile. Valid values for this field are:
N
No login sequence is required beyond the physical modem connection.
Y
A connection dialog script is required. Each connection script contains a
text template that outlines the exchange of authorization and connection
parameters with a remote host.
Security: For information about security for AS/400 support of the SLIP protocol,
see the Tips and Tools for Securing Your AS/400 book.
PPP/SLIP over *PPP
You must use the Operations Navigator to configure and administer PPP and
SLIP profiles using a *PPP linetype.
If you use the command line interface to control Dial-in and Dial-out operations,
you can still use these functions:
|
|
|
|
|
v STRTCPPTP to START *PPP profiles
v ENDTCPPTP to END *PPP profiles
v
v
v
v
v
|
|
|
|
156
WRKTCPPTP to Work with *PPP profiles, but only in a limited capacity:
9 (Start)
10 (End)
12 (Work with line status)
14 (Work with session job)
OS/400 TCP/IP Configuration and Reference V4R4
|
|
Note: You can perform these panel options only by using AS/400 Operations
Navigator: 2 (Change), 3 (Copy), 4 (Remove), and 5 (Display details).
|
|
|
Basically, you can control the operational aspects of PPP from the command line
interface, but for configuration tasks that are PPP specific, you need to use
Operations Navigator.
Work with Point-to-Point TCP/IP
Type option, press Enter.
1=Add
2=Change
3=Copy
4=Remove
5=Display details
12=Work with line status
14=Work with session job
9=Start
10=End
Opt
Name
Mode
Type
Status
Line
Description
Line
Type
___
___
___
___
___
___
___
___
______
BAMBAM
BARNEY
BETTY
DINO
PEBBLES
FRED
WILMA
____
*ANS
*ANS
*ANS
*ANS
*ANS
*DIAL
*DIAL
*SLIP
*SLIP
*PPP
*PPP
*SLIP
*SLIP
*PPP
STRSSN
ACTIVE
INACTIVE
OUTQ
CALLW
INACTIVE
ACTIVE
ANSWERIT4
ANSWERIT1
ANSWERIT2
ANSWERIT5
ANSWERIT3
DIALOMATIC
ALTDIAL
*ASYNC QTPPANS002
*ASYNC QTPPANS001
*PPP
QTPPANS003
*PPP
QTPPANS010
*PPP
QTPPANS004
*ASYNC
*PPP
QTPPDIAL01
F3=Exit
F5=Refresh
F11=Display status
Job
Name
Bottom
F9=Command line
F10=Local interface status
F12=Cancel
F14=Work with session jobs
F24=More keys
Figure 104. Sample Work with Point-to-point TCP/IP panel with *PPP profiles
Chapter 4. Configuring Point-to-Point TCP/IP (PPP and SLIP)
157
158
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 5. Telnet Client
|
|
|
|
Important note: A thorough and in-depth explanation of Telnet is beyond the scope
and purpose of this document. The majority of material on the Telnet client
application is covered in the AS/400e Information Center under the TCP/IP topic.
For more information see “TCP/IP Topics in the Information Center” on page xv.
|
|
The topics that remain in this chapter include conceptual and reference information
on the Telnet client 3270 and VTxxx full-screen modes.
5250 Full-Screen Mode Considerations
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
TN5250—Start TCP/IP Telnet Command
The following optional parameters on the STRTCPTELN or Telnet command are
applicable during a 5250 full-screen mode session:
v Timeout wait for host (INZWAIT)
v Keyboard language type (KBDTYPE) (See “TN3270 or TN5250—Specifying
Keyboard and Character Sets” on page 160)
v Port number of the remote host server application (PORT)
TN5250—Screen Size
Telnet 5250 full-screen mode supports the following screen sizes:
v 1920-character (24 x 80) on all 5250 display stations.
v 3564-character (27 x 132) on 3180 Model 2; 3197 Models D1, D2, W1, W2; and
3477 Models FA, FC, FD, FE, FG, FW.
3270 Full-Screen Mode Considerations
The 3270 full-screen mode is activated by negotiating 327x workstation support with
the remote Telnet server application. A typical example of a Telnet client 3270 mode
environment is shown in Figure 105.
AS/400 System
Display
Device
Physical
Device
Description
IBM or Other System
TELNET
Client
Support
TCP/IP
TELNET
3270
Server
Support
RV3H025-0
Figure 105. Typical Telnet 3270 Mode Environment (Telnet Client)
3270 full-screen support is negotiated with any Telnet server application that
supports 3270 full-screen (rather than 5250) applications. An example of such a
© Copyright IBM Corp. 1997, 1999
159
system is the System/370 or System/390* system. All workstation types are
negotiated to the 3278 Model 2 workstation when Telnet is in 3270 full-screen
mode. The exceptions to this rule are:
v Remote 3277 workstations are negotiated as a 3277 Model 2
v Remote 3279 workstations are negotiated as a 3279 Model 2
When the Telnet session is started, your display station is controlled by the remote
system application. You receive the same displays and enter data in the same way
that you do for other 3270 devices attached to the remote system.
TN3270—Start TCP/IP Telnet Command
The following optional parameters on the STRTCPTELN or Telnet command are
applicable during a 3270 full-screen mode session:
v Keyboard language type (KBDTYPE) (See “TN3270 or TN5250—Specifying
Keyboard and Character Sets”)
v Page up (roll down) key (PAGEUP)
v Page down (roll up) key (PAGEDOWN)
v Cursor select key (CSRSLT)
v Outgoing 3270 translation table (TBL3270OUT)
v Incoming 3270 translation table (TBL3270IN)
v Timeout wait for host (INZWAIT)
v Numeric lock keyboard (NUMLCK)
v Change how nulls are handled (NULLS)
Using a Display Station during Telnet 3270 Full-Screen Mode
When using a display station during a Telnet 3270 full-screen session, you should
be aware of keyboard and display differences. Other special considerations for
Telnet 3270 mode include number of input fields, error messages, and ending a
session.
TN3270 or TN5250—Specifying Keyboard and Character Sets
The keyboard language type you specify for your work station, using the keyboard
language type parameter on the STRTCPTELN command, must be the same as
the keyboard language type parameter of the remotely attached workstation. If you
specify a keyboard language type that does not match, some of the characters are
not displayed as expected.
For a description of different keyboard language types, see the Local Device
Configuration book.
5250 and 3270 Keyboards
The placement and function of keys is different on the 5250 keyboard (3196G, 3180
Model 2, or 5291) than on the 3278 keyboard. Differences between these
keyboards are shown in the 3270 Device Emulation Support book.
Note: For the Telnet client operating in a 3270 full-screen mode, the 3270 Clear
function defaults to the key sequence Shift-Cmd-Backspace.
160
OS/400 TCP/IP Configuration and Reference V4R4
Keyboard differences for the following keyboards are shown in the System
Operation for New Users book.
v IBM-enhanced keyboard
v 122-key typewriter keyboard
v 5250 keyboard
v Personal computer or personal computer AT style keyboard
v Personal computer or personal computer AT 5250 style keyboard
v IBM-enhanced personal computer keyboard
Personal Computer Keyboards
If your personal computer uses the Client Access Workstation Function (WSF), you
can display the layout of your 5250 keyboard using the Work Station Function Keys
(WSFKEYS) command. You can alter the style using the Configure Work Station
Function (CFGWSF) command. These commands are discussed in the Client
Access/400 for DOS with Extended Memory Setup book. If your personal computer
does not use the workstation function, refer to the appropriate documentation for
your emulator (for example, OS/2 CM/2) to view or change the keyboard style.
TN3270—Minus Sign
If you specified the value *YES for the numeric lock keyboard parameter of the
STRTCPTELN command, if you are using a data entry keyboard, and if the cursor
is located in a numeric-only field, then do the following to display a minus sign.
To display a 5250 minus sign:
1. Press the Num (Numeric) key.
2. Press the minus sign (−) key.
To display a 3278 minus sign, press the minus sign key.
TN3270—Page Down and Page Up
If the 3270 application has a display that does not allow all the input data fields to
be viewed, use the 5250 Page Down and Page Up keys to enter data when the
maximum number of input fields on the display is exceeded.
You can also assign PF and PA functions to the page keys by specifying their use
on the STRTCPTELN command.
The cursor always appears as an underline on both 5250 and 3270 displays.
TN3270—Screen Size
Telnet 3270 full-screen mode requirements:
v If the negotiated 3270 device type requires 1920 characters, the AS/400 Telnet
client code will run with any 5250 device type as the client terminal.
v If the negotiated 3270 device type requires 3564 characters, the AS/400 Telnet
client code requires either a 3180 Model 2, 3197 Model D1, D2, W1, W2, or
3477 Model FA, FC, FD, FE, FG, or FW 5250 device type as the client terminal.
Chapter 5. Telnet Client
161
TN3270—Cursor Select Key
The existing Cursor Select key is disabled if you choose to emulate the Cursor
Select key. The Cursor Select key is emulated if you specify one of the following
parameters for the STRTCPTELN command:
Parameter
Page Up (Roll Down) key
Page Down (Roll Up) key
Cursor Select key
Value
*CSRSLT
*CSRSLT
*F-key (specify a function key *F1 to *F24)
TN3270—Messages
Several types of error messages may be displayed when you are using Telnet 3270
full-screen mode.
v Key entry errors appear as flashing 4-digit numbers on the lower left corner of
the display. Press the Help key or F1 (Help) to obtain more information about the
message. See the System Operation book if you cannot correct the error.
v System messages include Telnet messages and are issued from the AS/400
system.
v For information on messages sent from the remote system, see the remote
system documentation.
TN3270—Handling Null Characters
All null characters are removed when a data stream is sent from a 3270 display
station. Specify one of the following values for the handle nulls (NULLS) parameter
on the STRTCPTELN command:
*REMOVE
Removes beginning and embedded null characters
*BLANK
The default value; changes beginning and embedded null characters to blanks
Trailing null characters are always removed for both values. For example, assume
the data consists of the following (0 indicates a null):
0x0yz000
The data stream sent from a 5250 display station running Telnet 3270 full-screen
with the default *BLANK would contain the following:
œxœyz
The data stream sent from a 3270 display station or from a 5250 display station
running a Telnet 3270 full-screen session when the value *REMOVE is specified
would contain the following:
xyz
The value *REMOVE is valid for the following devices:
v Any locally attached display
v Displays attached to a remote 5394 controller
v Personal computer displays using the workstation function
162
OS/400 TCP/IP Configuration and Reference V4R4
VTxxx Full-Screen Mode Considerations
VT220 and VT100 terminals are ASCII full-screen terminals manufactured by Digital
Equipment Corporation (DEC) and are the full-screen terminal types supported by
AS/400. A typical example of a Telnet client VTxxx mode environment is shown in
Figure 106.
AS/400 System
Display
Device
Physical
Device
Description
IBM or Other System
TELNET
Client
Support
TCP/IP
TELNET
VTxxx
Server
Support
RV3H026-0
Figure 106. Typical Telnet VTxxx Mode Environment (Telnet Client)
When the VT220 terminal type is negotiated, there are several operating modes
that are supported:
v VT200 mode, 7-bit controls is the default mode and uses the standard ANSI
functions. This mode provides the full range of VT220 capabilities in an 8-bit
communications environment with 7-bit controls. This mode supports the DEC**
multinational character set or national replacement character (NRC) sets,
depending on the character set mode selected.
v VT200 mode, 8-bit controls uses the standard ANSI functions and provides the
full range of VT220 capabilities in an 8-bit communications environment with 8-bit
controls. This mode supports the DEC multinational character set or national
replacement character (NRC) sets, depending on the character set mode
selected.
v VT100 mode uses standard ANSI functions. This mode restricts the use of the
keyboard to VT100 keys. All data is restricted to 7 bits, and only ASCII, national
replacement characters (NRC), or special graphics characters are generated.
v VT52 mode uses DEC private functions (not ANSI). This mode restricts the use
of the keyboard to VT52 keys.
If VT220 mode is negotiated, then an initial operating mode for Telnet client is
selected using the ASCII operating mode (ASCOPRMOD) parameter of the
STRTCPTELN or Telnet command.
Telnet VTxxx support allows AS/400 users to sign on to non-AS/400 systems as if
they were on a VTxxx terminal locally attached to the system and to access
full-screen VTxxx applications. VTxxx client support allows an AS/400 user to sign
on to any remote system in a TCP/IP network that supports the VTxxx terminal data
stream.
Operational Differences
As an AS/400 Telnet user, you should be aware of physical and operational
differences between VTxxx and 5250 terminals.
The 5250 is a block mode terminal. Data typed on a 5250 is accumulated in a
buffer and only sent to the AS/400 system when an AID (attention identifier) key is
Chapter 5. Telnet Client
163
pressed. An AID key on a 5250 keyboard is a key that initiates a function. The
following are the AID keys on a 5250 keyboard:
v Clear
v Command Function 1 through 24
v Enter/Rec Adv
v Help
v Print
v Record Backspace Function
v Roll Down (Page Up)
v Roll Up (Page Down)
VTxxx terminals operate in a character mode. Characters are sent immediately to
the host when a key is pressed.
Another difference is the way the data arrives on the display. Data is written to a
VTxxx terminal one character at a time, and you see the data arrive as streams of
characters. With the 5250, data is written in blocks, and all or part of the display
changes at once.
Keyboard Issues
You should avoid using the 5250 cursor movement keys. Instead, you should use
the function keys associated with the *CSRUP, *CSRDOWN, *CSRRIGHT, and
*CSRLEFT keywords. By default these are keys F13, F14, F15 and F16
respectively. If you use the 5250 cursor movement keys, the VTxxx application you
are using may not function as expected because the results of using these keys are
not transmitted to the remote system until an attention identifier (AID) key is
pressed.
For example, using Telnet to the RISC System/6000 and obtaining VT220
emulation, the SMIT command provides a menu driven interface to AIX. Here the
function keys associated with *CSRxx keywords perform as you would expect the
cursor movement keys to do. However, the 5250 cursor movement keys, while
physically moving the cursor down the screen and correctly selecting the SMIT
option, do not cause the selected option to be highlighted. The highlighting in
reverse video remains with the first option on the SMIT menu, regardless of the key
position.
Typing a control character on an AS/400 keyboard is different than typing a control
character on an actual VTxxx terminal. On a VTxxx terminal, the control key is
pressed and held down while the character associated with the control function is
pressed. For example, the VTxxx Control-C function is entered by pressing the
following key sequence:
CTRL
C
RV2H015-1
Figure 107. VTxxx Control-C Sequence
When using the AS/400 Telnet support, the equivalent is achieved by typing a
two-character control indicator followed by pressing the function key associated with
the *SENDWOCR (Send without Carriage Return) default function (the F11 key).
164
OS/400 TCP/IP Configuration and Reference V4R4
For example, if the default keyboard map and the default STRTCPTELN command
parameters are in effect, the VTxxx Control-C function can be entered by typing &C
followed by pressing the F11 key. (It can also be entered simply by <F12> using the
default keyboard map, but in case you are using an application where <F12> is
remapped, this example is included, and illustrates the principle of the
*SENDWOCR key.
The character used to indicate a control character can be selected on the
CTLCHAR parameter of the STRTCPTELN command. The default is &. The &C
characters must be the last characters typed before pressing the *SENDWOCR
function key or the &C is not interpreted as a control character. A control character is
only sent when the *SENDWOCR function key is pressed. You can assign
frequently used VTxxx control characters to a function key. An example of the Ctrl-C
command can be described as follows. When using Telnet client to connect to an
RS/6000 system, VT220 emulation will typically be negotiated. The Ctrl-C sequence
is an important one in AIX to end long running commands, such as PING. It is,
therefore, important that you know how to do this before issuing any RS/6000
commands. By default the sequence is &C <F11>. Note that these keys have to be
entered quickly, and it may take several attempts before the RS/6000 task accepts
the input.
If you do not want the characters that are being typed to be displayed, the function
key associated with the *HIDE function should be pressed (F6 on the default
keyboard map). This function should be used when typing a password.
If you want the characters that have been typed to be sent to the remote system for
processing without pressing the Enter key, you should press the function key
associated with the *SENDWOCR function (F11 on the default keyboard map).
It is often useful to be able to recall previously entered commands. On the AS/400
F9 often provides this function. On AIX, this can be activated by typing the
command set -o vi and pressing Enter. After this, you can start retrieving commands
with the sequence EscK. To perform this sequence using the default keyboard map
while in VTxxx emulation, you should use the sequence <F5>k<F11>. The Esc
character starts the command retrieval. The k can then be used to retrieve further
commands. While operating in this mode, the commands H for right, L for left, X for
delete, I for insert, and R for replace apply. The sequence <F5>i<F11> switches this
facility off.
Screen Issues
The character in the position just before the cursor position will always be blank.
The actual character is saved internally and is displayed when the display is
refreshed with the cursor in a different position.
A VTxxx application that uses row 1, column 1 of the display does not work the
same when using AS/400 Telnet client support. Most 5250-type display stations do
not allow input to row 1, column 1. If the VTxxx application positions the cursor at
row 1, column 1, the AS/400 system puts the cursor at row 1, column 2,
automatically.
Due to architectural differences, certain VTxxx commands or sequences are not
supported and are ignored. An example is downstream loadable character sets.
Chapter 5. Telnet Client
165
VTxxx—Screen Size
Telnet VTxxx full-screen mode supports the following screen sizes:
v On 3180 display stations:
– 24 x 80 VTxxx screens should display as 24 x 80.
– 24 x 132 VTxxx screens should display as 24 x 132.
v On 5250 display stations:
– 24 x 80 VTxxx screens should display as 24 x 80.
– 24 x 132 screens require the function key assigned to *SHIFTDSP (F10 on
the default keyboard map) to move the information on the screen right or left.
VTxxx—Character Attributes
A VTxxx terminal supports the following attributes:
v Blink
v Bold
v Reverse video
v Underline
v Any combination of the above
The 5250 data stream supports the previous attributes so that all of the VTxxx
attributes can be represented on a 5250 display station. However, there are some
limitations.
v The 5250 data stream can only support three of the character attributes at the
same time. If all VTxxx attributes are selected at the same time by the remote
system, the underline, blink, and reverse video attributes are displayed. Also, the
combination of underline, bold, and reverse image cannot be displayed on a
5250 display station. When a VTxxx application selects this combination,
underline and reverse image are displayed.
v The attribute byte takes up a space on the 5250 display stations that do not
support extended attributes. Attributes do not take up space on a VTxxx terminal.
This means that you do not see all of the data shown on the 5250 display if
character attributes are selected. When VTxxx data is received that is to be
displayed with character attributes, the position before the data is overlaid with
the 5250 attribute byte. The character that was displayed there is lost. If a
character is to be displayed in row 1, column 1 with the attributes set, that
character is not displayed. You can choose not to have the character attributes
displayed by specifying DSPCHRATTR(*NO) on the STRTCPTELN command.
This allows you to see all of the data on the display without attributes.
Note: This restriction is not applicable for displays that support extended attributes
such as the 3477 display.
VT100—Keyboard Indicator
A VT100 terminal has an L1 indicator that can be programmed for different
applications. This indicator is not emulated by the AS/400 Telnet support.
VTxxx—Start TCP/IP Telnet Command
The following optional parameters on the STRTCPTELN or Telnet command are
applicable during a VTxxx full-screen mode session:
166
OS/400 TCP/IP Configuration and Reference V4R4
v
v
v
v
v
Control characters (CTLCHAR)
Incoming ASCII translation table (TBLVTIN)
Outgoing ASCII translation table (TBLVTOUT)
Special table out (TBLVTDRWO)
Special table in (TBLVTDRWI)
v
v
v
v
v
v
v
Options selected (VTOPT)
Display character attributes (DSPCHRATTR)
Page scroll feature (PAGESCROLL)
Answerback feature (ANSWERBACK)
Tab stops (TABSTOP)
Timeout wait for host (INZWAIT)
Coded character set identifier (CCSID)
v ASCII operating mode (ASCOPRMOD). This parameter applies to initializing a
VT220 session only and has no effect on negotiations. See “VTxxx Full-Screen
Mode Considerations” on page 163 for a description of the operating modes that
are supported.
v Port number of the remote host server application (PORT)
If unexpected characters appear, the remote server system may not be configured
correctly. Some server systems use a workstation-type system value to define the
capabilities of the client workstation. If you are connected to such a server system,
verify that the workstation-type value is set to an appropriate value for a VTxxx
full-screen mode workstation.
You can also use the set term command to change the full-screen mode of the
connection. For example, if you use Telnet to sign on to a RISC System/6000
(RS/6000) system, you should type:
set term=vt100
after the connection has been established. This should correctly map the
unexpected characters.
Changing the VTxxx Keyboard Map
The client session support for both the VT100 and VT220 modes provides a
primary and alternate keyboard mapping. This method of providing the keyboard
mapping is done to accommodate the additional keypad capabilities of the VT220
mode. All changes to these keyboard mappings can be saved for later sessions
using the F6 key from the Change VTxxx ... Keyboard Map display. The data is
saved in the user profile, and once saved will automatically apply the next time
Telnet VTxxx emulation is activated.
The keyboard option that you select from the Send Telnet Control Functions menu
determines which keyboard mapping you use. The following displays show the
VTxxx functions that correspond to the 5250 AID key.
v Option 6 (Change VT100 Primary Keyboard Map), shown in Figure 108 on
page 168 and Figure 109 on page 169.
v Option 7 (Change VT100 Alternate Keyboard Map), shown in Figure 110 on
page 169 and Figure 111 on page 170.
v Option 8 (Change VT220 Primary Keyboard Map), shown in Figure 112 on
page 170 and Figure 113 on page 171.
Chapter 5. Telnet Client
167
v Option 9 (Change VT220 Alternate Keyboard Map), shown in Figure 114 on
page 171 and Figure 115 on page 172.
The level of support negotiated between the AS/400 system and the server system
determines which options are displayed on the Send Telnet Control Functions
menu. If the VT100 full-screen mode support is negotiated initially, options 6 and 7
are displayed. If the VT220 full-screen mode support is negotiated initially, options 8
and 9 are displayed.
If you have previously installed TCP/IP at Version 2 Release 2, and upgrade to a
later version, and if you previously used VT100 emulation, then if the server system
is capable of negotiating the VT220 level of support, then the VT100 keyboard map
previously used on the AS/400 system is no longer used. Instead the VT220
keyboard map would be used.
Note: There are no differences in the default values of the VT100 primary and
alternate keyboard mappings.
The following figures show the default keyboard mappings. You can change any of
the values. If you press the Enter key, your changes are saved for the current
session only. If you press F6 (Save), your changes are permanently saved and are
in effect the next time you start a VTxxx Telnet session.
Change VT100 Primary Keyboard Map
Type changes, press Enter:
5250 key
VT100 function
Function Key 1 . . .
*PF1
Function Key 2 . . .
*PF2
Function Key 3 . . .
*PF3
Function Key 4 . . .
*PF4
Function Key 5 . . .
*ESC
Function Key 6 . . . *HIDE
Function Key 7 . . .
*TAB
Function Key 8 . . .
*CTLA
Function Key 9 . . .
*CTLB
Function Key 10 . .
*SHIFTDSP
Function Key 11 . .
*SENDWOCR
Function Key 12 . .
*CTLC
Function Key 13 . .
*CSRUP
Function Key 14 . .
*CSRDOWN
Function Key 15 . .
*CSRRIGHT
Function Key 16 . .
*CSRLEFT
F3=Exit
F6=Save
F12=Cancel
Figure 108. Change VT100 Primary Keyboard Map (Display 1)
168
OS/400 TCP/IP Configuration and Reference V4R4
More...
Change VT100 Primary Keyboard Map
Type changes, press Enter:
5250 key
VT100 function
Function Key 17 . .
*CTLD
Function Key 18 . .
*CTLE
Function Key 19 . .
*CTLF
Function Key 20 . .
*CTLG
Function Key 21 . .
*CTLH
Function Key 22 . .
*CTLI
Function Key 23 . .
*CTLJ
Function Key 24 . .
*CTLK
Rollup key . . . . . *CTLL
Rolldown key . . . .
*CTLM
F3=Exit
F6=Save
F12=Cancel
Bottom
Figure 109. Change VT100 Primary Keyboard Map (Display 2)
Change VT100 Alternate Keyboard Map
Type changes, press Enter:
5250 key
VT100 function
Function Key 1 . . . *PF1
Function Key 2 . . .
*PF2
Function Key 3 . . . *PF3
Function Key 4 . . .
*PF4
Function Key 5 . . . *ESC
Function Key 6 . . . *HIDE
Function Key 7 . . . *TAB
Function Key 8 . . . *CTLA
Function Key 9 . . . *CTLB
Function Key 10 . .
*SHIFTDSP
Function Key 11 . .
*SENDWOCR
Function Key 12 . .
*CTLC
Function Key 13 . .
*CSRUP
Function Key 14 . .
*CSRDOWN
Function Key 15 . .
*CSRRIGHT
Function Key 16 . .
*CSRLEFT
F3=Exit
F6=Save
F12=Cancel
More...
Figure 110. Change VT100 Alternate Keyboard Map (Display 1)
Chapter 5. Telnet Client
169
Change VT100 Alternate Keyboard Map
Type changes, press Enter:
5250 key
VT100 function
Function Key 17 . .
*CTLD
Function Key 18 . .
*CTLE
Function Key 19 . .
*CTLF
Function Key 20 . .
*CTLG
Function Key 21 . .
*CTLH
Function Key 22 . .
*CTLI
Function Key 23 . .
*CTLJ
Function Key 24 . .
*CTLK
Rollup key . . . . .
*CTLL
Rolldown key . . . .
*CTLM
F3=Exit
F6=Save
F12=Cancel
Bottom
Figure 111. Change VT100 Alternate Keyboard Map (Display 2)
You can switch between the primary and alternate keyboard mappings during a
VTxxx session using the function key assigned to the *KEYPRI and *KEYALT
keywords. You can assign these keywords to any of the available 5250 function
keys. It is recommended that you assign *KEYPRI to the Page Up 5250 function
key and *KEYALT to the Page Down 5250 function key for both the primary and
alternate keyboard mappings.
Change VT220 Primary Keyboard Map
Type changes, press Enter:
5250 key
VT220 function
Function Key 1 . . .
*PF1
Function Key 2 . . .
*PF2
Function Key 3 . . .
*PF3
Function Key 4 . . .
*PF4
Function Key 5 . . .
*ESC
Function Key 6 . . . *HIDE
Function Key 7 . . .
*TAB
Function Key 8 . . .
*CTLA
Function Key 9 . . .
*CTLB
Function Key 10 . .
*SHIFTDSP
Function Key 11 . .
*SENDWOCR
Function Key 12 . .
*CTLC
Function Key 13 . .
*CSRUP
Function Key 14 . .
*CSRDOWN
Function Key 15 . .
*CSRRIGHT
Function Key 16 . .
*CSRLEFT
F3=Exit
F6=Save
F12=Cancel
Figure 112. Change VT220 Primary Keyboard Map (Display 1)
170
OS/400 TCP/IP Configuration and Reference V4R4
More...
Change VT220 Primary Keyboard Map
Type changes, press Enter:
5250 key
VT220 function
Function Key 17 . .
*CTLD
Function Key 18 . .
*CTLE
Function Key 19 . .
*CTLF
Function Key 20 . .
*CTLG
Function Key 21 . .
*CTLH
Function Key 22 . .
*CTLI
Function Key 23 . .
*CTLJ
Function Key 24 . .
*CTLK
Page up (rolldown) .
*KEYPRI
Page down (rollup) .
*KEYALT
F3=Exit
F6=Save
Bottom
F12=Cancel
Figure 113. Change VT220 Primary Keyboard Map (Display 2)
Change VT220 Alternate Keyboard Map
Type changes, press Enter:
5250 key
VT220 function
Function Key 1 . . . *PF1
Function Key 2 . . .
*PF2
Function Key 3 . . . *PF3
Function Key 4 . . .
*PF4
Function Key 5 . . . *ESC
Function Key 6 . . . *HIDE
Function Key 7 . . . *TAB
Function Key 8 . . . *CTLA
Function Key 9 . . . *CTLB
Function Key 10 . .
*SHIFTDSP
Function Key 11 . .
*SENDWOCR
Function Key 12 . .
*CTLC
Function Key 13 . .
*CSRUP
Function Key 14 . .
*CSRDOWN
Function Key 15 . .
*CSRRIGHT
Function Key 16 . .
*CSRLEFT
F3=Exit
F6=Save
F12=Cancel
More...
Figure 114. Change VT220 Alternate Keyboard Map (Display 1)
Chapter 5. Telnet Client
171
Change VT220 Alternate Keyboard Map
Type changes, press Enter:
5250 key
VT220 function
Function Key 17 . .
*CTLD
Function Key 18 . .
*FINDKEY
Function Key 19 . .
*INSERTKEY
Function Key 20 . .
*REMOVEKEY
Function Key 21 . .
*SELECTKEY
Function Key 22 . .
*PREVSCN
Function Key 23 . .
*NEXTSCN
Function Key 24 . .
*CTLK
Rollup key . . . . .
*KEYPRI
Rolldown key . . . .
*KEYALT
F3=Exit
F6=Save
Bottom
F12=Cancel
Figure 115. Change VT220 Alternate Keyboard Map (Display 2)
There are several types of VTxxx information that you can enter.
v Character data. You can assign a character string to a function key. For
example, you are on the AS/400 system and are using Telnet to establish a
connection with an RS/6000 system. To assign the character string set
term=vt100 to the following function key:
Function Key 24
. .
*CTLK
from the AS/400 system you would type:
Function Key 24
. .
'set term=vt100'
This allows you to press a function key rather than always having to type in that
character string.
When you press the function key during a VTxxx session, the character string
assigned to the function key is sent to the remote system with the carriage
return, line feed characters added. If you type data before pressing the function
key, the character string is added to the data that you type. This allows you to
assign a frequently used command string to a function key. The character data
typed is mapped from EBCDIC to ASCII before being transmitted to the remote
system.
v Control key keywords. You can assign a VTxxx control keystroke to a function
key using a defined keyword. For example, if you wanted to assign a different
VTxxx control keystroke to the following function key:
Function Key 24
. .
*CTLK
. .
*CTLZ
you would type:
Function Key 24
When you press the function key, the new control character assigned to the
function key is sent to the remote system. If you type data before pressing the
function key, the control character is added to the typed data and sent to the
remote system.
v Hexadecimal data. You can assign a hexadecimal string to a function key. When
you press the function key, the hexadecimal data is sent to the remote system.
172
OS/400 TCP/IP Configuration and Reference V4R4
The carriage return, line feed characters are not added to hexadecimal data. If
you type data before pressing the function key, the hexadecimal data is added to
the typed data and sent to the remote system. This allows you to type a
character that is not on the 5250 keyboard (for example, square brackets).
Hexadecimal data is entered by typing X followed by a quoted string of
hexadecimal characters, for example, X'1A1A'. The hexadecimal data is not
mapped before being transmitted to the remote system.
v Local AS/400 control functions. You can assign a keyword to be handled
locally within the AS/400 Telnet client session. These assignments or mappings
may not result in ASCII data stream traffic being sent to the remote Telnet server
session. These local control functions are *HIDE, *SHIFTDSP, *KEYPRI, and
*KEYALT. The *SENDWOCR function is a local function, but ASCII data streams
are sent to the remote Telnet server session.
Figure 116 shows the VT100 keyboard. Figure 117 on page 174 shows the VT220
keyboard. Table 10 on page 174 shows the valid control codes that are sent. The
CTRL key is used in conjunction with other keys on the keyboard to generate
control codes.
ONLINE
SET/
CLEAR
TABS
SETUP
ESC
!
1
TAB
CTRL
CAPS
LOCK
SHIFT
CLEAR LINE/
ALL TABS LOCAL
@
2
#
3
Z
C
L2
T
&
7
L4
8
N
,
{
[
:
;
L
<
+
=
P
O
K
M
_
-
)
0
I
J
H
B
(
9
*
U
Y
BELL
G
V
L3
TOGGLE TRANSMIT RECEIVE 80/132
I/O
SPEED SPEED COLUMNS RESET
^
6
F
D
X
L1
%
5
R
E
S
A
SETUP
A/B
$
4
W
Q
KBD
LOCKED
LOCAL
>
.
PF2
PF3
7
8
9
4
5
6
1
2
3
PF4
-
‘
}
]
"
’
?
/
~
PF1
RETURN
SHIFT
|
\
LINE
FEED
0
’
.
RV2H014-2
Figure 116. VT100 Keyboard
Chapter 5. Telnet Client
173
Function Keys
Hold
Screen
Print
Screen
Data/
Talk
Set-up
Break
F6
F7
F8
F9
F11
(ESC)
F10
F12
(BS)
F13
(LF)
F14
Hold Screen
Lock Compose
Help
~
!
@
‘
1
2
Q
Tab
Ctrl
#
3
>
<
Shift
4
W
A
Lock
E
S
Z
%
5
$
R
D
X
^
&
*
(
)
_
+
6
7
8
9
0
-
=
T
F
Y
G
C
V
H
B
I
U
K
J
N
M
P
O
:
;
L
’
’
.
.
"
’
?
/
F17
F18
F19
F20
PF4
Do
Find
Insert
Here
Remove
PF!
PF2
PF3
Select
Prev
Screen
Next
Screen
7
8
9
4
5
6
’
1
2
3
Enter
Return
}
{
Wait
|
\
Shift
0
Compose
Character
_
.
Editing
Keypad
Auxiliary
Keypad
Main Keypad
RV2N452
Figure 117. VT220 Keyboard
Table 10. VT100 and VT220 Control Character Keywords
Control Character
Description
Key Pressed with CTRL
Key Down
Keyword
Hex Character
Transmitted
Null
Spacebar
*NUL
X'00'
Start of heading
A
*SOH,*CTLA
X'01'
Start of text
B
*STX,*CTLB
X'02'
End of text
C
*ETX,*CTLC
X'03'
End of transmission
D
*EOT,*CTLD
X'04'
Enquire
E
*ENQ,*CTLE
X'05'
Acknowledge
F
*ACK,*CTLF
X'06'
Bell
G
*BEL,*CTLG
X'07'
Back Space
H
*BS,*CTLH
X'08'
Horizontal tabulation
I
*HT,*CTLI
X'09'
Line feed
J
*LF,*CTLJ
X'0A'
Vertical tab
K
*VT,*CTLK
X'0B'
Form feed
L
*FF,*CTLL
X'0C'
Carriage return
M
*CR,*CTLM
X'0D'
Shift out
N
*SO,*CTLN
X'0E'
Shift in
O
*SI,*CTLO
X'0F'
Data link escape
P
*DLE,*CTLP
X'10'
Device control 1
Q
*DC1,*CTLQ
X'11'
Device control 2
R
*DC2,*CTLR
X'12'
Device control 3
S
*DC3,*CTLS
X'13'
Device control 4
T
*DC4,*CTLT
X'14'
Negative acknowledgement
U
*NAK,*CTLU
X'15'
174
OS/400 TCP/IP Configuration and Reference V4R4
Table 10. VT100 and VT220 Control Character Keywords (continued)
Control Character
Description
Key Pressed with CTRL
Key Down
Keyword
Hex Character
Transmitted
Synchronous idle
V
*SYN,*CTLV
X'16'
End of transmission block
W
*ETB,*CTLW
X'17'
Cancel previous word or
character
X
*CAN,*CTLX
X'18'
End of medium
Y
*EM,*CTLY
X'19'
Substitute
Z
*SUB,*CTLZ
X'1A'
Escape
[
*ESC
X'1B'
File separator
\
*FS
X'1C'
Group separator
]
*GS
X'1D'
Record separator
∼
*RS
X'1E'
Unit separator
?
*US
X'1F'
*DEL
X'7F'
Delete
Table 11 shows the keys on the auxiliary keypad that normally transmit the codes
for the numerals, decimal point, minus sign, and comma.
Table 11. Numeric Keypads
Keyword
*NUM0
Hex Character Transmitted
Numeric keypad 0 key (VT52 mode)
1
Numeric keypad 0 key (VT100 or VT220 7-bit mode)
X'30' or X'1B3F70'
X'30' or X'1B4F70'
2
Numeric keypad 0 key (VT220 8-bit mode)
X'30' or X'8F70'
*NUM1
1
Numeric keypad 1 key (VT52 mode)
1
Numeric keypad 1 key (VT100 or VT220 7-bit mode)
X'31' or X'1B3F71'
X'31' or X'1B4F71'
2
Numeric keypad 1 key (VT220 8-bit mode)
X'31' or X'8F71'
*NUM2
1
Numeric keypad 2 key (VT52 mode)
1
Numeric keypad 2 key (VT100 or VT220 7-bit mode)
X'32' or X'1B3F72'
X'32' or X'1B4F72'
2
Numeric keypad 2 key (VT220 8-bit mode)
X'32' or X'8F72'
*NUM3
1
Numeric keypad 3 key (VT52 mode)
1
Numeric keypad 3 key (VT100 or VT220 7-bit mode)
X'33' or X'1B3F73'
X'33' or X'1B4F73'
2
Numeric keypad 3 key (VT220 8-bit mode)
X'33' or X'8F73'
*NUM4
1
Numeric keypad 4 key (VT52 mode)
1
Numeric keypad 4 key (VT100 or VT220 7-bit mode)
X'34' or X'1B3F74'
X'34' or X'1B4F74'
2
Numeric keypad 4 key (VT220 8-bit mode)
X'34' or X'8F74'
*NUM5
1
Numeric keypad 5 key (VT52 mode)
1
Numeric keypad 5 key (VT100 or VT220 7-bit mode)
X'35' or X'1B3F75'
X'35' or X'1B4F75'
2
Numeric keypad 5 key (VT220 8-bit mode)
X'35' or X'8F75'
*NUM6
1
Numeric keypad 6 key (VT52 mode)
1
Numeric keypad 6 key (VT100 or VT220 7-bit mode)
X'36' or X'1B3F76'
X'36' or X'1B4F76'
2
X'36' or X'8F76'
Control Character Description
1
Numeric keypad 6 key (VT220 8-bit mode)
Chapter 5. Telnet Client
175
Table 11. Numeric Keypads (continued)
Keyword
*NUM7
Hex Character Transmitted
Numeric keypad 7 key (VT52 mode)
1
Numeric keypad 7 key (VT100 or VT220 7-bit mode)
X'37' or X'1B3F77'
X'37' or X'1B4F77'
2
Numeric keypad 7 key (VT220 8-bit mode)
X'37' or X'8F77'
*NUM8
1
Numeric keypad 8 key (VT52 mode)
1
Numeric keypad 8 key (VT100 or VT220 7-bit mode)
X'38' or X'1B3F78'
X'38' or X'1B4F78'
2
Numeric keypad 8 key (VT220 8-bit mode)
X'38' or X'8F78'
*NUM9
1
Numeric keypad 9 key (VT52 mode)
1
Numeric keypad 9 key (VT100 or VT220 7-bit mode)
X'39' or X'1B3F79'
X'39' or X'1B4F79'
2
Numeric keypad 9 key (VT220 8-bit mode)
X'39' or X'8F79'
*NUMMINUS
1
Numeric keypad minus key (VT52 mode)
1
Numeric keypad minus key (VT100 or VT220 7-bit mode)
X'2D' or X'1B3F6D'
X'2D' or X'1B4F6D'
2
Numeric keypad minus key (VT220 8-bit mode)
X'2D'or X'8F6D'
*NUMCOMMA
1
Numeric keypad comma key (VT52 mode)
1
Numeric keypad comma key (VT100 or VT220 7-bit mode)
X'2C' or X'1B3F6C'
X'2C' or X'1B4F6C'
2
Numeric keypad comma key (VT220 8-bit mode)
X'2C' or X'8F6C'
*NUMPERIOD
1
Numeric keypad period key (VT52 mode)
1
Numeric keypad period key (VT100 or VT220 7-bit mode)
X'2E' or X'1B3F6E'
X'2E' or X'1B4F6E'
2
*PF1
X'2E' or X'8F6E'
Numeric keypad period key (VT220 8-bit mode)
X'1B50'
Numeric keypad PF1 key (VT52 mode)
X'1B4F50'
Numeric keypad PF1 key (VT100 or VT220 7-bit mode)
2
*PF2
X'8F50'
Numeric keypad PF1 key (VT220 8-bit mode)
X'1B51'
Numeric keypad PF2 key (VT52 mode)
X'1B4F51'
Numeric keypad PF2 key (VT100 or VT220 7-bit mode)
2
*PF3
X'8F51'
Numeric keypad PF2 key (VT220 8-bit mode)
X'1B52'
Numeric keypad PF3 key (VT52 mode)
X'1B4F52'
Numeric keypad PF3 key (VT100 or VT220 7-bit mode)
2
*PF4
Control Character Description
1
X'8F52'
Numeric keypad PF3 key (VT220 8-bit mode)
X'1B53'
Numeric keypad PF4 key (VT52 mode)
X'1B4F53'
Numeric keypad PF4 key (VT100 or VT220 7-bit mode)
2
X'8F53'
Numeric keypad PF4 key (VT220 8-bit mode)
Notes:
1. A single-character is transmitted when in keypad numeric mode; a 3-character sequence is sent when in keypad
application mode.
2.
This sequence is a shortened version of the 7-bit sequence. It is either presented when operating in 8-bit mode,
which can be called by the remote VT220 host or server, or it may be specified in the ASCOPRMOD parameter
of the STRTCPTELN CL command.
Table 12 on page 177 shows the keys that transmit the codes for the function keys
on the top row of the VT220 keyboard.
176
OS/400 TCP/IP Configuration and Reference V4R4
Table 12. Top Row Function Keys
Keyword
Hex Character Transmitted
Control Character Description
*F6
X'1B5B31377E'
Top row F6 function key (VT220 7-bit mode)
X'9B31377E'
*F7
1
X'1B5B31387E'
X'9B31387E'
*F8
1
X'1B5B31397E'
X'9B31397E'
*F9
1
X'1B5B32307E'
X'9B32307E'
*F10
X'1B5B32317E'
X'9B32317E'
*F11
*F16 or *DO
*F17
*F18
*F19
*F20
1
X'1B5B32367E'
X'9B32367E'
*F15 or *HELP
1
X'1B5B32357E'
X'9B32357E'
*F14
1
X'1B5B32347E'
X'9B32347E'
*F13
1
X'1B5B32337E'
X'9B32337E'
*F12
1
1
Top row F6 function key (VT220 8-bit mode)
Top row F7 function key (VT220 7-bit mode)
Top row F7 function key (VT220 8-bit mode)
Top row F8 function key (VT220 7-bit mode)
Top row F8 function key (VT220 8-bit mode)
Top row F9 function key (VT220 7-bit mode)
Top row F9 function key (VT220 8-bit mode)
Top row F10 function key (VT220 7-bit mode)
Top row F10 function key (VT220 8-bit mode)
Top row F11 function key (VT220 7-bit mode)
Top row F11 function key (VT220 8-bit mode)
Top row F12 function key (VT220 7-bit mode)
Top row F12 function key (VT220 8-bit mode)
Top row F13 function key (VT220 7-bit mode)
Top row F13 function key (VT220 8-bit mode)
Top row F14 function key (VT220 7-bit mode)
Top row F14 function key (VT220 8-bit mode)
X'1B5B32387E'
Top row F15 function key (also HELP key) (VT220 7-bit
mode)
X'9B32387E'1
Top row F15 function key (also HELP key) (VT220 8-bit
mode)
X'1B5B32397E'
Top row F16 function key (also Do key) (VT220 7-bit mode)
X'9B32397E'1
Top row F16 function key (also Do key) (VT220 8-bit mode)
X'1B5B33317E'
Top row F17 function key (VT220 7-bit mode)
X'9B33317E'1
Top row F17 function key (VT220 8-bit mode)
X'1B5B33327E'
Top row F18 function key (VT220 7-bit mode)
X'9B33327E'1
Top row F18 function key (VT220 8-bit mode)
X'1B5B33337E'
Top row F19 function key (VT220 7-bit mode)
X'9B33337E'1
Top row F19 function key (VT220 8-bit mode)
X'1B5B33347E'
Top row F20 function key (VT220 7-bit mode)
X'9B33347E'
1
Top row F20 function key (VT220 8-bit mode)
Notes:
1.
This sequence is a shortened version of the 7-bit sequence. It is only presented when operating in 8-bit mode,
which can be called by the remote VT220 host or server, or it may be specified in the ASCOPRMOD parameter
of the STRTCPTELN CL command.
Table 13 on page 178 shows the keys that transmit codes for the editing keypad
keys.
Chapter 5. Telnet Client
177
Table 13. Editing Keypad
Keyword
Hex Character Transmitted
Control Character Description
*CSRUP
X'1B41'
Cursor-up key (VT52 mode)
X'1B5B41'
Cursor-up key (VT100 or VT220 7-bit Cursor Key Mode
Reset)
X'9B41'
Cursor-up key (VT220 8-bit Cursor Key Mode Reset)
X'1B4F41'
Cursor-up key (VT100 or VT220 7-bit Cursor Key Mode Set)
X'8F41'
Cursor-up key (VT220 8-bit Cursor Key Mode Set)
X'1B42'
Cursor-down key (VT52 mode)
X'1B5B42'
Cursor-down key (VT100 or VT220 7-bit Cursor Key Mode
Reset)
X'9B42'
Cursor-down key (VT220 8-bit mode Cursor Key Mode
Reset)
X'1B4F42'
Cursor-down key (VT100 or VT220 7-bit Cursor Key Mode
Set)
X'8F42'
Cursor-down key (VT220 8-bit mode Cursor Key Mode Set)
X'1B43'
Cursor-right key (VT52 mode)
X'1B5B43'
Cursor-right key (VT100 or VT220 7-bit Cursor Key Mode
Reset)
X'9B43'
Cursor-right key (VT220 8-bit Cursor Key Mode Reset)
X'1B4F43'
Cursor-right key (VT100 or VT220 7-bit Cursor Key Mode
Set)
X'8F43'
Cursor-right Key (VT220 8-bit Cursor Key Mode Set)
X'1B44'
Cursor-left key (VT52 mode)
X'1B5B44'
Cursor-left key (VT100 or VT220 7-bit Cursor Key Mode
Reset)
X'9B44'
Cursor-left key (VT220 8-bit Cursor Key Mode Reset)
X'1B4F44'
Cursor-left key (VT100 or VT220 7-bit Cursor Key Mode Set)
X'8F44'
Cursor-left key (VT220 8-bit Cursor Key Mode Set)
*CSRDOWN
*CSRRIGHT
*CSRLEFT
*FINDKEY
X'1B5B317E'
X'9B317E'
*INSERTKEY
X'1B5B327E'
X'9B327E'
*REMOVEKEY
1
X'1B5B367E'
X'9B367E'
178
1
X'1B5B357E'
X'9B357E'
*NEXTSCN
1
X'1B5B347E'
X'9B347E'
*PREVSCN
1
X'1B5B337E'
X'9B337E'
*SELECTKEY
1
1
OS/400 TCP/IP Configuration and Reference V4R4
Editing keypad Find key (VT220 7-bit mode)
Editing keypad Find key (VT220 8-bit mode)
Editing keypad Insert Here key (VT220 7-bit mode)
Editing keypad Insert Here key (VT220 8-bit mode)
Editing keypad Remove key (VT220 7-bit mode)
Editing keypad Remove key (VT220 8-bit mode)
Editing keypad Select key (VT220 7-bit mode)
Editing keypad Select key (VT220 8-bit mode)
Editing keypad Prev Screen key (VT220 7-bit mode)
Editing keypad Prev Screen key (VT220 8-bit mode)
Editing keypad Next Screen key (VT220 7-bit mode)
Editing keypad Next Screen key (VT220 8-bit mode)
Table 13. Editing Keypad (continued)
Keyword
Hex Character Transmitted
Control Character Description
Notes:
1. This sequence is a shortened version of the 7-bit sequence. It is only presented when operating in 8-bit mode,
which can be called by the remote VT220 host or server, or it may be specified in the ASCOPRMOD parameter
of the STRTCPTELN CL command.
Table 14 shows the keywords that are handled locally within the AS/400 Telnet
client session.
Table 14. Local AS/400 Function Keys
Keyword
*SENDWOCR
*SHIFTDSP
*HIDE
*KEYPRI
*KEYALT
Hex Character Transmitted
Control Character Description
None
1
VT100 and VT220 control key
None
2
Shift display
None
3
Hide input
None
4
Call primary keyboard mapping of 5250 function keys
None
4
Call alternate keyboard mapping of 5250 function keys
Notes:
1. The data that has been typed is sent to the remote system without appending the carriage return and line feed
characters.
2. The *SHIFTDSP keyword is used when the remote system has selected 132-column mode and the 5250 terminal
only has 80 columns. When the function key that has the *SHIFTDSP function assigned to it is pressed, the
rightmost 80 columns or the leftmost 80 columns are shown depending on what is currently on the display.
3.
The *HIDE keyword is used when the user does not want typed characters shown on the display, for example,
when typing a password.
4. The *KEYPRI and *KEYALT keywords signal the TELNET client session to dynamically call the respective
full-screen ASCII keyboard map. The *KEYPRI mapping calls the primary keyboard map, and *KEYALT calls the
alternate keyboard map. By default, they are assigned to the Page Down (Roll Up) and the Page Up (Roll Down)
5250 function keys. When the requested keyboard map is already in effect, no action is taken.
VTxxx—National Language Support
There are alternative methods of selecting character mapping between the client
and server systems with VTxxx emulation. These are:
v Coded character set identifier (CCSID)
v Multinational mode
v National mode
If none of these modes is suitable, you may set up and specify your own
user-defined mapping tables.
Note: VTxxx support is limited to a subset of single-byte character set (SBCS)
languages. A list of the supported languages is found later in this section.
Any of these supported single-byte language translation tables can be
modified to map any single-byte language that is preferred, then identified in
the appropriate parameter for starting Client Telnet.
Mode selection is done with the CCSID parameter of the Start TCP/IP Telnet
(STRTCPTELN) command. The incoming ASCII/EBCDIC table (TBLVTIN) and
outgoing EBCDIC/ASCII table (TBLVTOUT) parameters of this command allow the
Chapter 5. Telnet Client
179
specification of user-defined mapping tables. If these are not required, the default
value of *CCSID allows for character mapping by using the mode specified in the
CCSID parameter.
VTxxx—Multinational Mode
The multinational mode supports the DEC multinational character set, which is an
8-bit character set that contains most characters used in the major European
languages. The ASCII character set is included in the DEC multinational character
set. The DEC multinational character set is used by default.
VTxxx—National Mode
The national mode supports the national replacement character set, which is a
group of 7-bit character sets. Only one national character set is available for use at
any one time. VT220 also supports the standard 7-bit ASCII character set as part of
the national mode. The VT220 terminal supports the following 7-bit ASCII national
language character sets:
v British
v Dutch
v Finnish
v French
v French/Canadian
v
v
v
v
v
v
German
Italian
Norwegian Danish
Spanish
Swedish
Swiss
v US English
To use a national mode, mapping tables are required to map incoming ASCII data
into EBCDIC and outgoing EBCDIC data into ASCII when operating in VTxxx
full-screen mode.
A national mode (NLS mapping table) may be selected with the CCSID parameter
on the Telnet command (see “VTxxx—Start TCP/IP Telnet Command” on page 166).
A numeric value representing a registered CCSID value in the range 1-65553 may
be entered to identify the appropriate mapping table. Details of registered CCSIDs
are found in the International Application Development book.
The NLS mapping tables are built dynamically to a remote system the first time
Telnet is used, and are based on DEC national replacement character sets.
Because the character sets are based on 7 bits, they can contain only the unique
characters from one country. Because the DEC multinational character set is based
on 8 bits, it has sufficient bits to allow the unique characters from a group of
countries to be included.
180
OS/400 TCP/IP Configuration and Reference V4R4
Identifying Table Objects
You can identify the table objects (*TBL) using the Work with Object command:
WRKOBJ OBJ(QUSRSYS/Q*) OBJTYPE(*TBL)
All of the system table objects are in QUSRSYS library.
The table objects are named Qxxxyyyzzz where xxx is the FROM code page, yyy is
the TO character set and zzz is the TO code page.
For the outgoing (EBCDIC-to-ASCII) table:
v The FROM code page ID is taken from the code page ID in QCHRID of message
description CPX8416 (use WRKMSGD CPX8416 to display), 037 in Figure 118
from a US English based system.
v The TO character set and code page are derived from the CCSID parameter
used with the Telnet command. See Table 15 for the IDs used.
For the incoming (ASCII-to-EBCDIC) table:
v The FROM code page ID is derived from the CCSID parameter used with the
Telnet command. See Table 15 for the IDs used.
v The TO character set and code page are taken from the character set ID and
code page ID in QCHRID of message description CPX8416 (use WRKMSGD
CPX8416 to display), 697 and 037 in Figure 118 from a US English based
system.
Message ID . . . . . . . . . :
Message file . . . . . . . . :
Library . . . . . . . . . :
System:
CPX8416
QCPFMSG
QSYS
Message . . . . :
QCHRID
697 37
QCURSYM
QDECFMT
QLEAPADJ
0 QCCSID
37
QCNTRYID
US QIGCCDEFNT *NONE
$ QDATFMT
QTIMSEP
SYSNAM01
MDY QDATSEP
/
: QLANGID
ENU
Figure 118. Example CPX8416 Message
Table 15. ASCII/EBCDIC Translation Table Naming
Character Set
CCSID
MULTINAT
BRITISH
1292
1293
289
1192
265
293
1297
1195
1296
1193
Actual ID
1290
1291
A07
A08
289
A8E
265
293
BAB
A8H
BAA
A8F
Table ID
A05
A06
1102
1103
1104
1020
1011
1012
1107
1023
1106
1021
Code Page
Actual ID
1100
1101
A5W
A5X
A5Y
A3M
A3D
A3E
A52
A3P
A51
A3N
Table ID
A5U
A5V
Chapter 5. Telnet Client
181
For example, on a British system with a QCHRID of 697 285 (character set 697
code page 285) in message CPX8416 that uses Telnet with CCSID(*BRITISH), the
tables would have the following names:
v Outgoing (EBCDIC-to-ASCII) Q285A06A5V
v Incoming (ASCII-to-EBCDIC) QA5V697285
User-Defined Mapping Tables (ASCII Mode)
Where the multinational or NLS mapping tables do not meet the requirements of a
user, user-defined character mapping tables can be created and used.
You also have the ability to specify user-defined mapping tables using the outgoing
ASCII-to-EBCDIC table (TBLVTOUT) and incoming ASCII-to-EBCDIC table
(TBLVTIN) parameters of the STRTCPTELN command. You can specify a
user-defined mapping table for either the outgoing mapping table or the incoming
mapping table and then use the system default value for the other.
For details on how to create user-defined mapping tables, see Appendix C. Mapping
Tables Associated with TCP/IP Function.
System Functions Available during a Telnet Client Session
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
Print
Press the 5250-mode Print key to start the printing function and produce a printed
copy of the display. Press the Reset key to return to the Telnet session. The Print
key is always processed on the client system, so the spooled file created by the
Print key is placed on the job output queue on the client system. Refer to the
System Operation book for more information about working with and printing
spooled files.
182
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 6. Telnet Server
|
|
|
|
Important note: A thorough and in-depth explanation of Telnet is beyond the scope
and purpose of this document. The majority of material on the Telnet server is
covered in the AS/400e Information Center under the TCP/IP topic. For more
information see “TCP/IP Topics in the Information Center” on page xv.
|
|
|
The topics that remain in this chapter include conceptual and reference information
on the Telnet server 3270 and VTxxx full-screen modes, and ASCII line and Printer
pass-through modes. Also in this chapter, you will find the following topics:
|
|
|
|
v Telnet scenarios for establishing cascaded sessions
v workstation type negotiations and mappings
v system API enhancement, including a discussion on dynamic application printing
with TCP/IP
|
Setting Up the Telnet Server
|
|
|
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Determining Which Emulation Is Negotiated
To determine which type of emulation an autoselected Telnet client session
negotiates, the type of virtual device that is created should be examined by the
WRKDEVD QPADEV* command. For both VT220 and VT100, the virtual device
type that is created is V100. For virtual printer sessions, the device type that is
created is 3812 for single byte and 5553 for double byte.
5250 Full-Screen Mode
|
|
|
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Examples of 5250 Server to 5250 Full-Screen Telnet Client
This topic describes some practical experiences of a 5250 full-screen Telnet server
with different 5250 clients.
OS/2
Apple Macintosh
OS/2 5250 Full-Screen Telnet Client
IBM TCP/IP Version 2.0 for OS/2 provides a 5250 full-screen Telnet client (TN5250).
TN5250 can be started either by clicking on the TN5250 icon or from an OS/2
command line. For example:
[C:\]tn5250 sysnam123
The session is ended by selecting Exit from the menu bar.
© Copyright IBM Corp. 1997, 1999
183
Keyboard Mapping: The default keyboard map can be changed by creating a file
named TN5250.KEY by using a text editor. For example, the following would map
the PS/2 Enter key (Enter key on numeric keypad) to the AS/400 Enter key
function:
enter enter
TN5250.KEY is searched for (and used if found) when TN5250 is called. OS/2 looks
for this file first in the current directory and then in the ETC directory. There is a list
of valid PS/2 keys and AS/400 functions plus a listing of the default keyboard map
in the IBM TCP/IP Version 2.0 for OS/2 User’s Guide.
Character Mapping: The PS/2 is an ASCII-based device. 5250 Telnet data
streams are in EBCDIC format. The PS/2 must, therefore, translate all incoming
data from EBCDIC to ASCII and all outgoing data from ASCII to EBCDIC. A default
mapping table is provided to do this. User-defined mapping tables can also be
created. A sample table (5250XLT.SAM) is provided in the ETC directory. The table
includes both ASCII-to-EBCDIC and EBCDIC-to-ASCII translation. A user-defined
mapping table is selected using the -tx option when starting a session, for example:
[C:\]tn5250 sysnam123 -tx 5250xlt.sam
Apple Macintosh 5250 Full-Screen Telnet Client
Apple SNAvps 5250 provides 5250 connectivity for Apple Macintosh computers.
Version 1.2 adds support for AppleTalk and TCP/IP. The TCP/IP support is used in
conjunction with TCP/IP Connection for Macintosh (M8113Z). This support provides
a TN5250 client that allows Apple Macintosh computers to connect directly (the
gateway support is SNA/APPC only) to an AS/400. Token-ring and Ethernet are
supported. LocalTalk/Ethernet gateways are available from third parties.
Once installed, the Macintosh TCP/IP support is configured using three displays in
two steps:
1. The first two displays are selected with the MacTCP control panel icon. Having
selected the type of network adapter to be used (token-ring or Ethernet) from
the first display, click on more for the second display. The following is configured
with the second display:
v
v
v
v
The gateway internet address
Your domain name
The name server internet address
Your internet address
The internet address of the gateway in our network example was 9.4.73.193.
This was entered in the Gateway Address field under Routing Information. Our
domain name of RCHLAND.IBM.COM was entered in the Domain field under
Domain Name Server Information. The name server internet address
(9.4.191.76 in our network example) was entered in the IP Address field, also
under Domain Name Server Information.
The IP Address section is used to enter your own internet address. Enter your
network class (A in our network example). The slider will now move to show the
bits allocated to the network ID (Net), 8-bits in our class A network example
(see Figure 119 on page 185). The slider bar must now be moved to correctly
divide the remaining section into Subnetwork ID (Subnet) and Host ID (Node).
The subnet mask in our network example was 255.255.255.192. As you move
the slider bar, the subnet mask ID is dynamically updated. You should now
move the bar until the subnet mask ID matches yours. At this point, the number
184
OS/400 TCP/IP Configuration and Reference V4R4
of bits in the subnet and in the node in your network are shown. In the example
here, this equates to 18-bits allocated to the Subnet and 6-bits allocated to the
Node. For information on subaddressing, see “Subnetworks and Subnet Masks”
on page 6
Now enter your local internet address by entering information in the network ID
(Net), Subnetwork ID (Subnet), and Host ID (Node) fields. The information is
entered in these fields in decimal format. In our example the local IP address
in the more normal dotted decimal format was 9.4.73.214. This information was
entered as follows: 9 in the Net field, 5399 in the Subnet field and 22 in the
Node field. The example below shows how these numbers are derived from the
dotted decimal IP address once the internet address has been divided into Net,
Subnet and Node:
9
|
0 0 0 0 1 0 0 1
5
0 0 0 0 0 1 0 1
|
69
0 1 0 0 0 1 0 1
|
214
1 1 0 1 0 1 1 0
Net (class A)
|
Subnet (255.255.192)
|
Node
|
|
<----8-bits---->|<---------------18-bits---------------->|<-6-bits-->
|
|
9
|
5399
|
22
Figure 119. Class A Network Example
Note:
The arithmetic involved in converting a dotted decimal address to the
required decimals for the subnet and node can be tedious. If you are
unsure of the value to put here, enter what you think it should be and
click on OK. An IP address will be displayed (corresponding to the
numbers you have entered) in the more normal dotted decimal format on
the previous panel. By now correcting the IP Address on this panel, and
selecting more again (do not press the Enter key after correcting the IP
address), you will see that the Macintosh has calculated the correct
Subnet and Node values on the next panel.
Once you are satisfied with this, click on OK and you are returned to the first
panel where your IP address is shown in dotted decimal format.
Having completed the above, close the MacTCP control panel and start the
Macintosh again.
2. The Macintosh host table information is configured with the third panel. Select
the SNAvps TCP/5250 option from the Apple Menu control panels option. Add
host names and addresses as required. Click on ADD to add a name entered to
the table.
To
1.
2.
3.
4.
5.
start a TN5250 session:
Select TCP/IP with SNAvps 5250 from the SNAvps folder.
Select Session from the menu bar
Select Connection from the menu bar
Select a Connection Type of 5250 Access/TCP.
Select the required host name from the list of configured Hosts.
Chapter 6. Telnet Server
185
6. Click on tn5250 on the right side of the screen.
7. Click on Connect.
8. You should then be presented with an AS/400 sign-on display.
When the AS/400 sign-on display appears, it is inside a Macintosh Window. Along
the top of the window is a menu bar, where you see various options. Most of these
need not concern us. However, you should take note of the following:
Note: To end the session, select Session and then Disconnect from the menu bar.
Keyboard Mapping: A function key can be selected either with the mouse or with
the keyboard. To select a function key with the mouse, use the Keypad option from
the menu bar. A default keypad is provided (Standard Keypad). Others can be
created as required that might include Autokeys for example. To display the current
keyboard map, select Preferences and then Keyboard Map from the menu bar. The
keyboard map can also be changed from the panel presented using a ’drag and
drop’ process.
Character Mapping: The Apple Macintosh is an ASCII-based device. Because the
TN5250 data stream is EBCDIC-based, the Macintosh must do ASCII-to-EBCDIC
character translation. The translation table used is changed by selecting an
appropriate host language. To do this, select Session and then Host Language from
the menu bar. A list of the languages that are supported is presented from which a
language can be selected.
For more detailed information about configuring an Apple Macintosh to connect to
the AS/400 with both TCP/IP and SNA, see Using Apple Macintosh with the AS/400,
GG24-4071.
3270 Full-Screen Mode
3270 full-screen support allows Telnet client users to sign on and run AS/400 5250
full-screen applications even though 3270 full-screen support is negotiated. 3270
full-screen support is negotiated with any Telnet client application that supports
3270 full-screen applications rather than 5250 full-screen applications. An example
of a system that negotiates 3270 full-screen support is the System/390 family.
TN5250 delivers the data stream between the two systems as EBCDIC. Because
the 3270 data streams are translated into 5250 data streams, the workstation
devices operate as a remote 5251 display to the AS/400 system and application
programs.
Figure 120 on page 187 shows a network configuration using the AS/400 3270
Telnet server support.
186
OS/400 TCP/IP Configuration and Reference V4R4
IBM System
Devices
3277
3278
3279
TCP/IP
AS/400 System
TELNET
Server
Support
Other System
Virtual
Device
Description
TCP/IP
Non-IBM
Terminal
TELNET
3270
Client
Support
RV2H000-2
Figure 120. Configuration Example of 3270 Telnet Server Support
Setting up for 3270 Full-Screen Mode
You can use the CFGTCPTELN command to set up your 3270 full-screen mode
session.
Configure TCP/IP TELNET
Select one of the following:
System:
SYSNAM01
1. Change TELNET attributes
6. Display 3270 keyboard map
7. Change 3270 keyboard map
8. Set 3270 keyboard map
Work with associated system values:
10. Autoconfigure virtual devices
11. Limit security officer device access
12. Inactive job time-out
13. Inactive job message queue
14. Limit device sessions
15. Action to take for failed sign-on attempts
16. Maximum sign-on attempts allowed
Selection or command
===>
F3=Exit
F4=Prompt
F9=Retrieve
More...
F12=Cancel
Figure 121. CFGTCPTELN in 3270 Full-Screen Session
Step 1—3270—Starting the Telnet Server Job
The server job for a TCP/IP application must be started in the QSYSWRK
subsystem. The Start TCP/IP Server (STRTCPSVR) command starts the servers
that are shipped with the TCP/IP Utilities licensed program.
Even though the Change Telnet Attributes (CHGTELNA) command has an
AUTOSTART parameter, that parameter is overridden or ignored by the
STRTCPSVR command.
Chapter 6. Telnet Server
187
Step 2—3270—Setting the Number of Virtual Devices
The server system uses virtual devices to direct output to devices on your system.
AS/400 Telnet server support automatically selects (and creates, if necessary) these
devices for you. You may also choose to create your own virtual device under the
QVIRCDnnnn virtual controller. Note that virtual devices that you create under
QVIRCDnnnn will not be auto-selected. This would require a user exit program or
client subnegotiation to select this device.
The option is available for you to allow the Telnet server support on the AS/400
system to automatically configure virtual controllers and devices. The QAUTOVRT
system value specifies the maximum number of devices that are automatically
configured by the system. Use the Change System Value (CHGSYSVAL) command
to change the value of the QAUTOVRT system value. For example, entering the
following command string changes the number of virtual devices that can be
allocated on a system to 50:
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(50)
Note: QAUTOVRT has been modified for Version 4 Release 2 to support numeric
values of 0 through 32500, and a special value of *NOMAX.
To determine and set the maximum number of users you want signed on to the
AS/400 system at any time, do the following:
1. Set the QAUTOVRT value to 32500, the maximum value allowed, or use the
*NOMAX value.
2. Let your users use pass-through, Telnet, the virtual terminal application program
interface and Telnet Printer pass-through until you decide that the number of
virtual devices created is sufficient for normal system operation.
3. Change the QAUTOVRT value from 32500 to the number of virtual devices you
require for normal system operation.
If you have never allowed automatic configuration of virtual devices on your system,
the QAUTOVRT value is 0. A Telnet connection attempt with a dependence on
automatic creation of the virtual device then fails because the Telnet server does
not create more than the specified QAUTOVRT devices (zero). If you try to connect,
you receive a message (TCP2504) indicating that the Telnet client session has
ended and the connection is closed. In addition, the QTGTELNETS job in the
QSYSWRK subsystem on the AS/400 Telnet server sends a message (CPF8940)
indicating that a virtual device cannot be automatically selected.
If you change the QAUTOVRT value to 10, the next Telnet connection attempt
causes the Telnet server to create a virtual device. This virtual device is created
because the number of virtual devices on the controller (0) is less than the number
specified in the QAUTOVRT (10). Even if you change the specified number to 0
again, the next user attempting a Telnet connection succeeds. When a Telnet
connection attempt fails, the CPF87D7 message is sent to the system operator
message queue on the Telnet server system. The CPF87D7 message indicates that
the AS/400 server is not able to create a virtual device.
The Telnet server uses the following conventions for naming virtual controllers and
devices:
v Virtual controllers are named QPACTLnn.
188
OS/400 TCP/IP Configuration and Reference V4R4
v Virtual device descriptions can be a name selected by the user. If a valid device
name is communicated to the Telnet server either via user exit or a Telnet client,
a device by that name will be created, if necessary, under virtual controller
QVIRCDnnnn.
The virtual controller descriptions (QPACTLnn) have the 5250 data stream
optimization switch (OPTDTASTR) set to *YES by default. There is no reason to
change this for use by 3270 Telnet.
Security Considerations for 3270 Full-Screen Mode: The number of sign-on
attempts allowed increases if virtual devices are automatically configured. The
number of sign-on attempts is equal to the number of system sign-on attempts
allowed multiplied by the number of virtual devices that can be created. The number
of system sign-on attempts allowed is defined by the QMAXSIGN system value.
The number of virtual devices that can be created is defined by the QAUTOVRT
system value.
In Version 4 Release 2, the following level of support has been added with regard
to security of virtual devices:
v With a user-supplied exit program, you can audit the number of sign-on attempts
v You have the ability to deny connections
v You have the ability to allow bypassing of the sign-on screen
For more information on Telnet exit points and how to use them, see “TELNET Exit
Points” on page 541 in Appendix E. TCP/IP Application Exit Points and Programs.
Telnet and SNA 5250 Pass-Through Considerations for 3270 Full-Screen
Mode: The AS/400 system supports 5250 pass-through. 5250 pass-through is
similar to Telnet but runs on an SNA (Systems Network Architecture) protocol
network rather than a TCP/IP network. 5250 pass-through uses virtual displays to
direct output to the physical devices just as Telnet does. In 5250 pass-through, the
AS/400 system automatically creates virtual devices in the same way that it does
for Telnet. Therefore, the QAUTOVRT system value controls the number of
automatically configured virtual devices for both 5250 pass-through and Telnet. For
more information about 5250 pass-through, see the Remote Work Station Support
book.
Step 3—3270—Setting the QLMTSECOFR Value
The OS/400 licensed program supports the limit security officer (QLMTSECOFR)
system value, which limits the devices the security officer can sign on to. If the
QLMTSECOFR value is greater than zero, the security officer must be authorized to
use the virtual device descriptions. However, when this value is 0, the system does
not limit the devices users with *ALLOBJ or *SERVICE special authority can sign on
to.
On AS/400 systems with a QSECURITY value of 30 or greater, a user with security
officer authority (*ALLOBJ) must be authorized to use devices before the system
allows the user to use those devices. For example, each display device that a
security officer wants to sign on to (local, remote, or virtual), must have had the
following authority specified with the Grant Object Authority (GRTOBJAUT)
command:
GRTOBJAUT
OBJ(display_name) OBJTYPE(*DEVD)
AUT(*CHANGE) USER(QSECOFR)
Chapter 6. Telnet Server
189
|
This procedure is very important because Telnet automatically configures virtual
devices. If the QLMTSECOFR value is set to 0, all devices automatically configured
by Telnet can be used by the security officer. If you set the QLMTSECOFR value to
1, your security officer is not able to use the virtual devices created by Telnet unless
you grant object authority to the security officer for that virtual device. The automatic
configuration support can delete and re-create the virtual device. If this occurs,
authority must be granted to the security officer each time the virtual device is
created.
|
Step 4—3270—Working with Associated System Values
|
|
|
|
|
|
|
In addition to the QAUTOVRT and QLMTSECOFR, the following system values are
available for you to work with from the Configure TCP/IP Telnet (CFGTCPTELN)
menu:
|
|
v
v
v
v
v
v
v
|
v QDSCJOBITV: Time interval before disconnected jobs end
|
Figure 122 on page 192 shows the Configure TCP/IP Telnet (CFGTCPTELN) menu.
|
|
Setting the Telnet Timemark Timeout Value: You should also take into
consideration the TIMMRKTIMO parameter.
|
|
|
The Telnet timemark timeout (TIMMRKTIMO) parameter specifies the number of
seconds between TIMEMARK commands sent by the Telnet server. If Telnet is
unable to send the TIMEMARK command, it closes the connection.
|
QINACTITV: Inactive job time-out
QINACTMSGQ: Inactive job message queue
QLMTDEVSSN: Limit device sessions
QMAXSGNACN: Action to take for failed sign-on attempts
QMAXSIGN: Maximum sign-on attempts allowed
QRMTSIGN: Remote sign-on control
QDEVRCYACN: Device I/O error action
Step 5—3270—Creating Virtual Controllers and Devices
You can create virtual controllers and devices. If you create your own virtual
devices, by allowing the system to automatically select the device name, you must
be aware of the following:
v The virtual controller must be named QPACTLnn, where nn is a decimal number 01
or greater.
v The virtual device should be named QPADEVxxxx, where xxxx is an alphanumeric
character from 0001 to ZZZZ.
Note: Starting with Version 4 Release 2, the xxxx are no longer only numeric
characters, but also alphanumeric characters from 0001 to ZZZZ, allowing
a maximum of 1,679,615 unique names (devices).
If you want to use more than 32500 devices, which is the maximum value
for the QAUTOVRT system, you can set the QAUTOVRT system value to
*NOMAX to allow additional devices to be created.
v The Telnet server reuses available existing virtual devices that were auto-created
by selecting virtual devices of the same device type and model. When there are
no more device type and model matches, but there are still available virtual
devices, then the device type and model will be changed to match the client
190
OS/400 TCP/IP Configuration and Reference V4R4
device and model negotiated. This is true only for auto-created (QPADEVnnn)
virtual devices. Typically, the auto-created virtual device will use the AS/400
system values for keyboard type, character set, and code page. Optionally, these
display device attributes may be more specifically defined through the exit
program or device specified client subnegotiation. Devices can also be selected
via the exit program interface as opposed to being negotiated.
Step 6—3270—Defining Workstations to Subsystems
When you use Telnet to sign-on to an AS/400 server, the sign-on screen may not
be displayed on your workstation. Before a user can sign on to the AS/400 server,
the workstation must be defined to the subsystem. If the workstation has not been
defined to the subsystem, you need to add a workstation entry to the subsystem
description under which you want your job to run on the AS/400 server. The
workstation in this case is the virtual display device automatically created by the
Telnet server (QPADEVxxxx). The workstation name or the workstation type must
be specified in the subsystem description on the AS/400 server. Use the Display
Subsystem Description (DSPSBSD) command to see the workstation entries
defined to a subsystem. (This only applies to display devices. Printer devices
typically run in the QSPL subsystem.) The following command can be used to add
all workstation types to a subsystem named QINTER:
ADDWSE SBSD(QINTER) WRKSTNTYPE(*ALL)
Note: The Add Work Station Entry (ADDWSE) command can be done when the
subsystem is active. However, the changes may or may not take effect
immediately. You may need to end and restart the subsystem.
Step 7—3270—Activating the QSYSWRK Subsystem
The QSYSWRK subsystem must be active. Use the Work with Subsystem
(WRKSBS) command to display the status of the subsystem.
The Telnet server must also be started. The interactive subsystem, QINTER, which
is used in previous examples in this chapter, needs to be started to run interactive
jobs for Telnet sessions. The spooling subsystem (QSPL) needs to be active to run
printer pass-through sessions.
Step 8—3270—Creating User Profiles for Telnet Users
At the server system, create one or more user profiles for Telnet users from other
systems. The default user profile is *SYS. The following example shows a sample
user profile:
CRTUSRPRF
USRPRF(CLERK1)
PASSWORD(unique-password)
JOBD(CLERKLIB/CLERKL1)
TEXT('User profile Clerks Group 1')
Step 9—3270—Checking the QKBDTYPE System Value
When the AS/400 Telnet server automatically creates virtual display devices, it uses
the QKBDTYPE system value to determine the keyboard type for the virtual device.
If the initial creation of the virtual device fails using the QKBDTYPE system value,
the Telnet server attempts to create the device again, using a keyboard type value
of USB. If the second attempt to create the virtual display device fails using the
value of USB, then a message (CPF87D7) indicating that the virtual device cannot
be automatically selected is sent to the system operator message queue.
Chapter 6. Telnet Server
191
Step 10—3270—Setting the Default Keyboard Mapping
A 3270 display station connected to an AS/400 system using Telnet appears to be a
5251 display station to an AS/400 system. The 3270 display station keyboard has a
5251-equivalent keyboard map associated with it which allows it to complete
5251-equivalent functions on the AS/400 system.
When a Telnet client system user first signs on in 3270 full-screen mode, the
AS/400 system automatically assigns the default keyboard map to the user’s 3277,
3278, or 3279 keyboard (unless a user-defined keyboard map has been set up to
be automatically included in the user’s profile sign-on procedure). This supplies the
mapping needed for the 3270 keyboards to do most of the same functions as their
5250-equivalent keyboards do.
Note: If you are satisfied with the default keyboard mapping supplied when you
sign on, you may skip the remainder of this topic and go to the next topic,
“Break Messages in 3270 Full-Screen Mode” on page 195.
Configure TCP/IP TELNET
Select one of the following:
System:
SYSNAM11
1. Change TELNET attributes
6. Display 3270 keyboard map
7. Change 3270 keyboard map
8. Set 3270 keyboard map
Work with associated system values:
10. Autoconfigure virtual devices
11. Limit security officer device access
12. Inactive job time-out
13. Inactive job message queue
14. Limit device sessions
15. Action to take for failed sign-on attempts
16. Maximum sign-on attempts allowed
Selection or command
===>
F3=Exit
F4=Prompt
F9=Retrieve
More...
F12=Cancel
Figure 122. Configure TCP/IP TELNET Menu—TN3270
Displaying a Keyboard Map: Table 16 shows the default PF key assignments to
perform the various 5250 functions. You can use the Display Keyboard Map
(DSPKBDMAP) command to see the current keyboard mapping or use option 6
(Display 3270 keyboard map) on the Configure TCP/IP Telnet menu, while your
terminal is in 3270 emulation mode.
Table 16. Default Keyboard Mapping
5250 Key Function
Help
3270 Help
Clear
Print
Display Embedded Attributes
Test Request
192
OS/400 TCP/IP Configuration and Reference V4R4
Default 3270 Keys to Select Function
PF1
PF2
PF3
PF4
PF5
PF6
Table 16. Default Keyboard Mapping (continued)
5250 Key Function
Default 3270 Keys to Select Function
Roll Down
PF7
Roll Up
PF8
Error Reset
PF10 (System/38), PF10 or Enter (System/36 and
AS/400 system)
Sys Req
PF11
Record Backspace
PF12
F1 through F12
Press PA1, then one of the following: PF1 through
PF121
F13 through F24
Press PA2, then one of the following: PF1 through
PF12, or PF13 through F24 (if present)
Field Exit
Erase EOF, then Field Tab
Attention
For 3277 use Test Request, then PA1. For
3278/3279 use Attn key
Notes:
1. For example, to start F3, press PA1, wait for the system to respond, and then press PF3.
Changing a Keyboard Map: If you want to make either minor changes to the
default keyboard map or to set a new keyboard map, use the Change Keyboard
Map (CHGKBDMAP) or the Set Keyboard Map (SETKBDMAP) command. These
commands are available from the Configure TCP/IP Telnet menu as option 7
(Change 3270 keyboard map) and option 8 (Set 3270 keyboard map), while your
terminal is in 3270 emulation mode. The key assignments you specify are in effect
until you use these commands again to specify new key assignments or until you
sign off.
Note
The difference between CHGKBDMAP and SETKBDMAP is that with
SETKBDMAP the system defaults are taken and then the changes in the
SETKBDMAP are applied. With CHGKBDMAP, the system defaults plus any
changes you have previously made during this session are taken and then the
changes in the CHGKBDMAP are applied.
The following example of a CL program sets the keyboard mapping for a 327x-type
terminal that is using Telnet to go to an AS/400 system. This program maps the
AS/400 function keys to their equivalent function keys on the 327x terminal. The
CPF8701 message is received if you attempt a CHGKBDMAP command from a
terminal not in 3270 emulation mode. By monitoring for it, the rest of the program is
not used in these circumstances.
PGM
MONMSG
MSGID(CPF8701 CPF0000)
CHGKBDMAP PF1(*F1) PF2(*F2) PF3(*F3) PF4(*F4) PF5(*F5)
PF6(*F6) PF7(*DOWN) PF8(*UP) PF9(*F9)
PF10(*F10) PF11(*F11) PF12(*F12)
PA1PF1(*HELP) PA1PF2(*HLP3270)
PA1PF3(*CLEAR) PA1PF4(*PRINT)
PA1PF5(*DSPATR) PA1PF6(*TEST) PA1PF7(*F7)
PA1PF8(*F8) PA1PF9(*ATTN) PA1PF10(*RESET)
PA1PF11(*SYSREQ) PA1PF12(*BCKSPC)
ENDPGM
By storing this CL source as part of the QCLSRC file in library TCPLIB as member
CHGKBD, you can create the CL program CHGKBD into the TCPLIB library by
using the following CL command:
Chapter 6. Telnet Server
193
CRTCLPGM PGM(TCPLIB/CHGKBD) SRCFILE(TCPLIB/QCLSRC)
TEXT('Change the keyboard mapping for 327x terminals')
The CHGKBD program can then be called by anyone using Telnet to an AS/400
system. It can also be called automatically at sign-on time by specifying the
CHGKBD program for the Initial program parameter on the CHGUSRPRF command
or the CHGKBD program can be called by the profile’s initial program.
PA1 and PA2 Keys on a PC Keyboard: The PA1 and PA2 keys do not appear on
a PC keyboard. The function of these 3270 keys on a PC keyboard is provided by a
keyboard mapping in your 3270 emulator.
These keys are used by the default 3270 Telnet keyboard mapping, so it is
important that you know where these keys are on the keyboard before starting a
3270 Telnet session. This is especially important if you are planning to start a
session without changing the keyboard mapping. You should refer to your emulator
documentation for the keys or keystrokes required to provide these functions.
There are some 5250 key sequences for which there is no supported 3270 key
sequence and, therefore, it is not possible to set using the keyboard mapping
commands. These key sequences are:
v Field Plus
v Field Minus
v Erase all input fields
The 5250 Field Exit Key function is performed on a 3270 keyboard using the Erase
EOF key and then the tab key.
Note: When using Telnet 3270 full-screen mode from the 3270 terminal and before
the default mapping for the terminal is changed, the keys PF1 to PF12 might
be emulated by the key sequence PA1 PFx. Prior to creating a new
keyboard map, as in the previous example, instructions like Press PF3 or
Press PF4 should read: Press PA1 PF3 and Press PA1 PF4. In this case,
depending on the installation of the Telnet client for the host (VM Telnet client
for example), when pressing PA1 the user might get the instruction TELNET
command: at the bottom line of the display. If this instruction is displayed, then
type: PA1, press the Enter key, move the cursor to the command line and
press the desired PF key. In this case PF1 to PF12 might be emulated by:
1. Press PA1, get the Telnet instruction TELNET command:
2. Type PA1, press the Enter key.
3. Move the cursor to the command line.
4. Press the desired PF key.
For additional keyboard mapping information, see Appendix D. TELNET 3270
Keyboard Mappings.
Note: The Host Command Facility (HCF) is a feature available on System/370,
43xx, and 30xx host systems that enables a user on the host system to use
applications on an AS/400 system or other systems as if they were using
remotely attached 5250-type display stations. If you use HCF to connect to
an AS/400 system and then use Telnet to sign on to another AS/400 system
from that AS/400 system, you are in a 3270 full-screen mode session. The
keyboard is mapped twice, once for the initial HCF session and once for the
Telnet session. To use your PF keys the way you normally would, you must
194
OS/400 TCP/IP Configuration and Reference V4R4
change the keyboard mapping on both AS/400 systems, making sure that
you use the same keyboard mapping on each AS/400 system.
Break Messages in 3270 Full-Screen Mode
When your workstation message queue is in break mode (you must specify
*BREAK on the CHGMSGQ command), messages appear on the 3270 device
exactly as they appear on the 5250 display. When your workstation is not in break
mode, the following message is displayed: A message has arrived on a message
queue. To continue, press the function key assigned to the help function or the
function key assigned the error reset function. Then use the Display Message
(DSPMSG) command or the function key assigned to the system request function
followed by option 4 (Display message) to view the waiting message. Set the
workstation message queue to break mode to see the messages as they arrive.
Input-Inhibited Light
When using an AS/400 system from a 5250-type terminal, pressing certain keys in
certain situations causes input to be inhibited and the input-inhibited light to be
displayed on the 5250 terminal. When using Telnet server 3270 full-screen mode,
the input-inhibited light is indicated by two asterisks shown in the lower right corner
of the display (see Figure 123).
F3=Exit
F4=Prompt
F5=Refresh
F24=More keys
FUNCTION KEY NOT ALLOWED.
F12=Cancel
Bottom
F13=How to use this display
**
Figure 123. Input-Inhibited Light
When the keyboard is inhibited, any keys mapped to the AS/400 function keys are
ignored. The keyboard must be reset by pressing the Enter key or by pressing the
key mapped to the AS/400 Reset key.
Defining Capabilities for 3270 Devices
Table 17 lists the capabilities of the 3270 devices supported by Telnet.
Make sure that your Telnet client 3270 is negotiating one of the supported 3270
terminal types. The supported terminal types are shown in Table 19 on page 230.
Table 17. 3270 Device Capabilities
Device Type
Device Capabilities
3277
This display station supports generic 3270 data streams. Extended
attributes, such as underlining, blinking, reverse image, or color are not
supported.
Chapter 6. Telnet Server
195
Table 17. 3270 Device Capabilities (continued)
Device Type
Device Capabilities
3278
This display station supports extended attributes, such as blinking, reverse
image, and underlining if requested by the OS/400 DDS (data description
specifications) keywords.
Notes:
1. Extended attributes are not supported by some client implementations
of TELNET 3270 full-screen mode (TN3270).
3279
2. DBCS terminals that negotiate a 3278-2-E terminal type are
supported.
This display station supports color attributes and the extended data
stream attributes sent for a 3278 device. The color attributes are
determined (in the same manner as a 5292 Full Color Display) by
interpreting the DDS attributes as blinking, high intensity, or the DDS color
keywords.
VTxxx Full-Screen Mode
VTxxx server support allows Telnet client users to log on and run AS/400 5250
full-screen applications even though VTxxx full-screen support is negotiated. The
Telnet client application must be able to negotiate VTxxx terminal support. When
VTxxx full-screen mode is negotiated, the AS/400 Telnet server is responsible for
mapping 5250 functions to VTxxx keys and vice versa.
Although the AS/400 Telnet server supports VTxxx clients, this is not the preferred
mode to use because the AS/400 system is a block mode system, and the VTxxx
terminal is a character mode device. Most Telnet implementations support a
TN3270 or TN5250 client that should be used when connecting to an AS/400 Telnet
server.
In general, when a key on a VTxxx terminal is pressed, the hexadecimal code
associated with that key is immediately transmitted to the Telnet server. The Telnet
server must process that keystroke and then echo that character back to the VTxxx
terminal to be displayed. This results in a large amount of overhead associated with
each keystroke. In contrast, the 5250 and 3270 block mode devices buffer all
keystrokes at the client system until an Attention Identifier (AID) key is pressed.
When an AID key is pressed, the client sends the buffered input to the server for
processing. The block mode devices result in less overhead per keystroke and
generally provide better performance than a character-mode device, such as the
VTxxx terminal.
VTxxx delivers the data between the two systems as ASCII.
Setting up for VTxxx Full-Screen Mode
You can use the CFGTCPTELN command to set up your VTxxx full-screen mode
session.
196
OS/400 TCP/IP Configuration and Reference V4R4
Configure TCP/IP TELNET
Select one of the following:
1.
2.
3.
4.
5.
System:
SYSNAM01
Change TELNET attributes
Set VT mapping tables
Display VT keyboard map
Change VT keyboard map
Set VT keyboard map
Work with associated system values:
10. Autoconfigure virtual devices
11. Limit security officer device access
12. Inactive job time-out
13. Inactive job message queue
14. Limit device sessions
15. Action to take for failed sign-on attempts
16. Maximum sign-on attempts allowed
More...
Selection or command
===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
Figure 124. CFGTCPTELN in VTxxx Full-Screen Session
Step 1—VTxxx—Starting the Telnet Server Job
The server job for a TCP/IP application must be started in the QSYSWRK
subsystem. The Start TCP/IP Server (STRTCPSVR) command starts the servers
that are shipped with the TCP/IP Utilities licensed program.
Even though the Change Telnet Attributes (CHGTELNA) command has an
AUTOSTART parameter, that parameter is overridden or ignored by the
STRTCPSVR command.
Step 2—VTxxx—Setting the Number of Virtual Devices
Virtual devices are used by the server system to direct output to devices on your
system. AS/400 Telnet server support automatically selects (and creates, if
necessary) these devices for you. You may also choose to create your own virtual
device under the QVIRCDnnnn virtual controller.
The option is available for you to allow the Telnet server support on the AS/400
system to automatically configure virtual controllers and devices. The QAUTOVRT
system value specifies the maximum number of devices that are automatically
configured by the system. Use the Change System Value (CHGSYSVAL) command
to change the value of the QAUTOVRT system value. For example, entering the
following command string changes the number of virtual devices that can be
allocated on a system to 50:
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(50)
Note: QAUTOVRT has been modified for Version 4 Release 2 to support numeric
values of 0 through 32500, and a special value of *NOMAX.
To determine and set the maximum number of users you want signed on to the
AS/400 system at any time, do the following:
Chapter 6. Telnet Server
197
1. Set the QAUTOVRT value to 32500, the maximum value allowed, or use the
*NOMAX value.
2. Let your users use pass-through, Telnet, and the virtual terminal application
program interface until you decide that the number of virtual devices created is
sufficient for normal system operation.
3. Change the QAUTOVRT value from 32500 to the number of virtual devices you
require for normal system operation.
If you have never allowed automatic configuration of virtual devices on your system,
the QAUTOVRT value is 0. A Telnet connection attempt with a dependence on
automatic creation of the virtual device then fails because the Telnet server does
not create more than the specified QAUTOVRT devices (zero). If you try to connect,
you receive a message (TCP2504) indicating that the Telnet client session has
ended and the connection is closed. In addition, the QTGTELNETS job in the
QSYSWRK subsystem on the AS/400 Telnet server sends a message (CPF8940)
indicating that a virtual device cannot be automatically selected.
If you change the QAUTOVRT value to 10, the next Telnet connection attempt
causes the Telnet server to create a virtual device. This virtual device is created
because the number of virtual devices on the controller (0) is less than the number
specified in the QAUTOVRT (10). Even if you change the specified number to 0
again, the next user attempting a Telnet connection succeeds. When a Telnet
connection attempt fails, the CPF87D7 message is sent to the system operator
message queue on the Telnet server system. The CPF87D7 message indicates that
the AS/400 server is not able to create a virtual device.
Security Considerations for VTxxx Full-Screen Mode: The number of sign-on
attempts allowed increases if virtual devices are automatically configured. The
number of sign-on attempts is equal to the number of system sign-on attempts
allowed multiplied by the number of virtual devices that can be created. The number
of system sign-on attempts allowed is defined by the QMAXSIGN system value.
The number of virtual devices that can be created is defined by the QAUTOVRT
system value.
In
to
v
v
v
Version 4 Release 2, the following level of support has been added with regard
security of virtual devices:
With a user-supplied exit program, you can audit the number of sign-on attempts
You have the ability to deny connections
You have the ability to allow bypassing of the sign-on screen
For more information on Telnet exit points and how to use them, see “TELNET Exit
Points” on page 541 in Appendix E. TCP/IP Application Exit Points and Programs.
Telnet and SNA 5250 Pass-Through Considerations for VTxxx Full-Screen
Mode: The AS/400 system supports 5250 pass-through. 5250 pass-through is
similar to Telnet but runs on an SNA (Systems Network Architecture) protocol
network rather than a TCP/IP network. 5250 pass-through uses virtual displays to
direct output to the physical devices just as Telnet does. In 5250 pass-through, the
AS/400 system automatically creates virtual devices in the same way that it does
for Telnet. Therefore, the QAUTOVRT system value controls the number of
automatically configured virtual devices for both 5250 pass-through and Telnet. For
more information about 5250 pass-through, see the Remote Work Station Support,
SC41-5402-00 book.
198
OS/400 TCP/IP Configuration and Reference V4R4
Step 3—VTxxx—Setting the QLMTSECOFR Value
The OS/400 licensed program supports the limit security officer (QLMTSECOFR)
system value, which limits the devices the security officer can sign on to. If the
QLMTSECOFR value is greater than zero, the security officer must be authorized to
use the virtual device descriptions. However, when this value is 0, the system does
not limit the devices users with *ALLOBJ or *SERVICE special authority can sign on
to.
On AS/400 systems with a QSECURITY value of 30 or greater, a user with security
officer authority (*ALLOBJ) must be authorized to use devices before the system
allows the user to use those devices. For example, each display device that a
security officer wants to sign on to (local, remote, or virtual), must have had the
following authority specified with the Grant Object Authority (GRTOBJAUT)
command:
GRTOBJAUT
OBJ(display_name) OBJTYPE(*DEVD)
AUT(*CHANGE) USER(QSECOFR)
|
This procedure is very important because Telnet automatically configures virtual
devices. If the QLMTSECOFR value is set to 0, all devices automatically configured
by Telnet can be used by the security officer. If you set the QLMTSECOFR value to
1, your security officer is not able to use the virtual devices created by Telnet unless
you grant object authority to the security officer for that virtual device. The automatic
configuration support can delete and re-create the virtual device. If this occurs,
authority must be granted to the security officer each time the virtual device is
created.
|
Step 4—VTxxx—Working with Associated System Values
|
|
|
|
|
In addition to the QAUTOVRT and QLMTSECOFR, the following system values are
available for you to work with from the Configure TCP/IP Telnet (CFGTCPTELN)
menu:
v QINACTITV: Inactive job time-out
v QINACTMSGQ: Inactive job message queue
|
|
|
|
|
|
v QLMTDEVSSN: Limit device sessions
v QMAXSGNACN: Action to take for failed sign-on attempts
v QMAXSIGN: Maximum sign-on attempts allowed
|
Figure 124 on page 197 shows the Configure TCP/IP Telnet (CFGTCPTELN) menu.
|
|
Setting the Telnet Timemark Timeout Value: You should also take into
consideration the TIMMRKTIMO parameter.
|
|
|
The Telnet timemark timeout (TIMMRKTIMO) parameter specifies the number of
seconds between TIMEMARK commands sent by the Telnet server. If Telnet is
unable to send the TIMEMARK command, it closes the connection.
v QRMTSIGN: Remote sign-on control
v QDEVRCYACN: Device I/O error action
v QDSCJOBITV: Time interval before disconnected jobs end
Chapter 6. Telnet Server
199
Step 5—VTxxx—Creating Virtual Controllers and Devices
You can create virtual controllers and devices. If you create your own virtual
devices, by allowing the system to automatically select the device name, you must
be aware of the following:
v The virtual controller must be named QPACTLnn, where nn is a decimal number 01
or greater.
v The virtual device should be named QPADEVxxxx, where xxxx is an alphanumeric
character from 0001 to ZZZZ.
Note: Starting with Version 4 Release 2, the xxxx are no longer only numeric
characters, but also alphanumeric characters from 0001 to ZZZZ, allowing
a maximum of 1,679,615 unique names (devices).
If you want to use more than 32500 devices, which is the maximum value
for the QAUTOVRT system, you can set the QAUTOVRT system value to
*NOMAX to allow additional devices to be created.
v The Telnet server reuses available existing virtual devices that were auto-created
by selecting virtual devices of the same device type and model. When there are
no more device type and model matches, but there are still available virtual
devices, then the device type and model will be changed to match the client
device and model negotiated. This is true only for auto-created (QPADEVnnn)
virtual devices. Typically, the auto-created virtual device will use the AS/400
system values for keyboard type, character set, and code page. Optionally, these
display device attributes may be more specifically defined through the exit
program or device specified client subnegotiation. Devices can also be selected
via the exit program interface as opposed to being negotiated.
v The Device Type for a virtual device with VTxxx emulation is V100.
Step 6—VTxxx—Defining Workstations to Subsystems
When you use Telnet to sign-on to an AS/400 server, the sign-on screen may not
be displayed on your workstation. Before a user can sign on to the AS/400 server,
the workstation must be defined to the subsystem. If the workstation has not been
defined to the subsystem, you need to add a workstation entry to the subsystem
description under which you want your job to run on the AS/400 server. The
workstation in this case is the virtual display device automatically created by the
Telnet server (QPADEVxxxx). The workstation name or the workstation type must
be specified in the subsystem description on the AS/400 server. Use the Display
Subsystem Description (DSPSBSD) command to see the workstation entries
defined to a subsystem. (This only applies to display devices. Printer devices
typically run in the QSPL subsystem.)
Note: The Add Work Station Entry (ADDWSE) command can be done when the
subsystem is active. However, the changes may or may not take effect
immediately. You may need to end and restart the subsystem.
Step 7—VTxxx—Activating the QSYSWRK Subsystem
The QSYSWRK subsystem must be active. Use the Work with Subsystem
(WRKSBS) command to display the status of the subsystem.
200
OS/400 TCP/IP Configuration and Reference V4R4
The Telnet server must also be started. The interactive subsystem, QINTER, which
is used in previous examples in this chapter, needs to be started to run interactive
jobs for Telnet sessions. The spooling subsystem (QSPL) needs to be active to run
printer pass-through sessions.
Step 8—VTxxx—Creating User Profiles for Telnet Users
At the server system, create one or more user profiles for Telnet users from other
systems. The default user profile is *SYS. The following example shows a sample
user profile:
CRTUSRPRF
USRPRF(CLERK1)
PASSWORD(unique-password)
JOBD(CLERKLIB/CLERKL1)
TEXT('User profile for Clerks Group 1')
Step 9—VTxxx—Checking the QKBDTYPE System Value
When the AS/400 Telnet server automatically creates virtual display devices, it uses
the QKBDTYPE system value to determine the keyboard type for the virtual device.
If the initial creation of the virtual device fails using the QKBDTYPE system value,
the Telnet server attempts to create the device again, using a keyboard type value
of USB. If the second attempt to create the keyboard type fails, then a message
(CPF87D7) is sent to the QTCPIP job log, indicating that the virtual device cannot
be automatically selected. This message is also sent to the system operator
message queue.
Step 10—VTxxx—Setting the Default Keyboard Mapping
When a Telnet session is negotiated in VTxxx full-screen mode, a default keyboard
map is used. To display the default keyboard map for VTxxx, use the Display VT
Keyboard Map command (DSPVTMAP) (see “Displaying a VTxxx Keyboard Map”
on page 205). To change the VTxxx keyboard map, use the Change VT Keyboard
Map (CHGVTMAP) command (see “Changing a VTxxx Keyboard Map” on
page 206) or the Set VT Keyboard Map (SETVTMAP) command (see “Setting a
VTxxx Keyboard Map” on page 206).
Because the VTxxx keyboard does not have the same keys as a 5250 keyboard, a
keyboard mapping must exist between the VTxxx keys and the AS/400 functions.
The AS/400 server assigns a default keyboard mapping when a VTxxx session is
first established. In some cases there can be more than one key or key sequence
that maps to a particular AS/400 function. In these cases, you can use any of the
defined keys to call the desired AS/400 function. Table 18 on page 202 shows the
5250 functions along with the default VTxxx key or key sequences that are mapped
to these functions.
Notes:
1. Each control character is a one-byte value that is generated from a VTxxx
keyboard by holding down the CTRL key while pressing one of the alphabetic
keys. Both shifted and unshifted control characters generate the same
hexadecimal values.
2. The escape sequences are multiple byte codes that are generated by pressing
the Esc key followed by the characters that make up the desired sequence.
3. The AS/400 server ignores the case of all alphabetic characters in an escape
sequence. You can type alphabetic characters in escape sequences in either
uppercase or lowercase.
Chapter 6. Telnet Server
201
4. The AS/400 F1-F12 functions are mapped to the Esc key followed by one of the
keys in the top row of a VTxxx keyboard. The F13-F24 functions are mapped to
the Esc key followed by a shifted key in the top row of a VTxxx keyboard.
5.
Some Telnet VTxxx client systems use Ctrl-S and Ctrl-Q for flow control
purposes. This is generally referred to as XON/XOFF flow control. If you are
using a client system that has XON/XOFF enabled, you should not use the
values *CTLS and *CTLQ in your keyboard mapping.
Table 18. Special Values for VTxxx Keys
Default 5250 Function
Special Value
VTxxx Keys
Hexadecimal Value1
Attention
*CTLA
<CTRL-A>
X'01'
*ESCA
<ESC><A>
X'1B41'
Backspace
*BACKSPC
<Backspace or CTRL-H>
X'08'
Clear Screen
*ESCC
<ESC><C>
X'1B43'
Cursor Down
*CSRDOWN
<Down Arrow>
X'1B5B42'
Cursor Left
*CSRLEFT
<Left Arrow>
X'1B5B44'
Cursor Right
*CSRRIGHT
<Right Arrow>
X'1B5B43'
Cursor Up
*CSRUP
<Up Arrow>
X'1B5B41'
Delete
*DLT
<Delete>
X'7F'
*RMV
<Remove>
X'1B5B337E'2
X'9B337E'3
Duplicate
*ESCD
<ESC><D>
X'1B44'
Enter
*RETURN
<Return or CTRL-M>
X'0D'
Erase Input
*CTLE
<CTRL-E>
X'05'
Error Reset
*CTLR
<CTRL-R>
X'12'
*ESCR
<ESC><R>
X'1B52'
Field Advance
*TAB
<TAB or CTRL-I>
X'09'
Field Backspace
*ESCTAB
<ESC><Tab or CTRL-I>
X'1B09'
Field Exit
*CTLK
<CTRL-K>
X'OB'
*CTLX
<CTRL-X>
X'18'
*ESCX
<ESC><X>
X'1B58'
Field Minus
*ESCM
<ESC><M>
X'1B4D'
Help
*CTLQST
<CTRL-Question Mark>
X'1F'
*ESCH
<ESC><H>
X'1B48'
Home
*CTLO
<CTRL-O>
X'0F'
Insert
*ESCI
<ESC><I>
X'1B49'
*ESCDLT
<ESC><Delete>
X'1B7F'
*INS
<Insert Here>
X'1B5B327E'2
X'9B327E'3
New Line
202
*ESCLF
OS/400 TCP/IP Configuration and Reference V4R4
<ESC> <Line Feed or
CTRL-J>
X'1B0A'
Table 18. Special Values for VTxxx Keys (continued)
Default 5250 Function
Special Value
VTxxx Keys
Hexadecimal Value1
Page Down (Roll Up)
*CTLD
<CTRL-D>
X'04'
*CTLF
<CTRL-F>
X'06'
*NXTSCR
<Next Screen>
X'1B5B367E'2
X'9B367E'3
Page Up (Roll Down)
*CTLB
<CTRL-B>
X'02'
*CTLU
<CTRL-U>
X'15'
*PRVSCR
<Prev Screen>
X'1B5B357E'2
X'9B357E'3
Print
*CTLP
<CTRL-P>
X'10'
*ESCP
ESC
X'1B50'
*CTLL
<CTRL-L>
X'0C'
*ESCL
<ESC><L>
X'1B4C'
*CTLC
<CTRL-C>
X'03'
*ESCS
<ESC><S>
X'1B53'
Test Request
*CTLT
<CTRL-T>
X'14'
Toggle Indicator Lights
*ESCT
<ESC><T>
X'1B54'
F1
*ESC1
<ESC><1>
X'1B31'
Redraw Screen
System Request
*F1
<F1>
5
X'1B5B31317E'2
X'9B31317E'3
*PF1
<PF1>
X'1B4F50'2
X'8F50'3
F2
*ESC2
*F2
<ESC><2>
<F2>
5
X'1B32'
X'1B5B31327E'2
X'9B31327E'3
*PF2
<PF2>
X'1B4F51'2
X'8F51'3
F3
*ESC3
*F3
<ESC><3>
<F3>
5
X'1B33'
X'1B5B31337E'2
X'9B31337E'3
*PF3
<PF3>
X'1B4F52'2
X'8F52'3
F4
*ESC4
*F4
<ESC><4>
<F4>
5
X'1B34'
X'1B5B31347E'2
X'9B31347E'3
*PF4
<PF4>
X'1B4F53'2
X'8F53'3
F5
*ESC5
*F5
<ESC><5>
<F5>
5
X'1B35'
X'1B5B31357E'2
X'9B31357E'3
Chapter 6. Telnet Server
203
Table 18. Special Values for VTxxx Keys (continued)
Default 5250 Function
Special Value
VTxxx Keys
Hexadecimal Value1
F6
*ESC6
<ESC><6>
X'1B36'
*F6
<F6>
X'1B5B31377E'2
X'9B31377E'3
F7
*ESC7
<ESC><7>
X'1B37'
*F7
<F7>
X'1B5B31387E'2
X'9B31387E'3
F8
*ESC8
<ESC><8>
X'1B38'
*F8
<F8>
X'1B5B31397E'2
X'9B31397E'3
F9
*ESC9
<ESC><9>
X'1B39'
*F9
<F9>
X'1B5B32307E'2
X'9B32307E'3
F10
*ESC0
<ESC><0>
X'1B30'
*F10
<F10>
X'1B5B32317E'2
X'9B32317E'3
F11
*ESCMINUS
<ESC><Minus>
X'1B2D'
*F11
<F11>
X'1B5B32337E'2
X'9B32337E'3
F12
*ESCEQ
<ESC><Equal>
X'1B3D'
*F12
<F12>
X'1B5B32347E'2
X'9B32347E'3
F13
*ESCEXCL
<ESC><Exclamation>
X'1B21'
*F13
<F13>
X'1B5B32357E'2
X'9B32357E'3
F14
*ESCAT
<ESC><At sign>
X'1B40'
*F14
<F14>
X'1B5B32367E'2
X'9B32367E'3
F15
*ESCPOUND
<ESC><Pound>
X'1B23'
*F15
<F15>
X'1B5B32387E'2
X'9B32387E'3
F16
*ESCDOLLAR
<ESC><Dollar>
X'1B24'
*F16
<F16>
X'1B5B32397E'2
X'9B32397E'3
F17
*ESCPCT
<ESC><Percent>
X'1B25'
*F17
<F17>
X'1B5B33317E'2
X'9B33317E'3
F18
*ESCCFX
<ESC><Circumflex Accent> X'1B5E'1
*F18
<F18>
X'1B5B33327E'2
X'9B33327E'3
204
OS/400 TCP/IP Configuration and Reference V4R4
Table 18. Special Values for VTxxx Keys (continued)
Default 5250 Function
Special Value
VTxxx Keys
Hexadecimal Value1
F19
*ESCAMP
<ESC><Ampersand>
X'1B26'
*F19
<F19>
X'1B5B33337E'2
X'9B33337E'3
F20
*ESCAST
<ESC><Asterisk>
X'1B2A'
*F20
<F20>
X'1B5B33347E'2
X'9B33347E'3
F21
*ESCLPAR
<ESC><Left Parenthesis>
X'1B50'
F22
*ESCRPAR
<ESC><Right Parenthesis>
X'1B51'
F23
*ESCUS
<ESC><Underscore>
X'1B5F'
F24
*ESCPLUS
<ESC><Plus>
X'1B2B'
See note 4
*FIND
<Find>
X'1B5B317E'
X'9B317E'
See note 4
*SELECT
<Select>
X'1B5B347E'
X'9B347E'
Notes:
1. Unless otherwise identified, the hexadecimal value is in the VT100 mode.
2. VT220 7-bit control mode.
3. VT220 8-bit control mode.
4. There is no 5250 function key that maps to this VT key.
5. The keys F1 through F5 are not available on a VT220 terminal. However, many VT220 emulators send these
hexadecimal values when the F1 through F5 keys are pressed.
Displaying a VTxxx Keyboard Map: You can display the current keyboard
mapping with the Display VT Keyboard Map (DSPVTMAP) command. There are no
parameters for the DSPVTMAP command. You are shown the VTxxx keys that are
mapped to the AS/400 functions.
The DSPVTMAP command is only valid when called from within an AS/400 Telnet
server session operating in VTxxx full-screen mode.
Type DSPVTMAP to see the following display, and then press the Page Down key
to see the additional displays. You can display the VT keyboard map using option 3
from the Configure TCP/IP Telnet menu.
Chapter 6. Telnet Server
205
5250 Function
5250 Attention . . .
5250 Help . . . . .
Page Down (Roll Up)
Page Up (Roll Down)
System Request . . .
Insert . . . . . . .
Delete . . . . . . .
Enter . . . . . . .
Backspace . . . . .
Duplicate . . . . .
Erase Input . . . .
Error Reset . . . .
Field Exit . . . . .
Field Minus . . . .
Home . . . . . . . .
New Line . . . . . .
F1=Help
F3=Exit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Display VT Keyboard Map
VT100/VT220 key(s)
*CTLA
*ESCA
*CTLQST
*ESCH
*CTLD
*CTLF
*NXTSCR
*CTLB
*CTLU
*PRVSCR
*CTLC
*ESCS
*ESCI
*ESCDLT
*DLT
*RETURN
*BACKSPC
*ESCD
*CTLE
*CTLR
*ESCR
*CTLK
*CTLX
*ESCX
*ESCM
*CTLO
*ESCLF
F12=Cancel
More
Setting a VTxxx Keyboard Map: You can change the default keyboard mapping
using the Set VT Keyboard Map (SETVTMAP) command or using option 5 (Set VT
keyboard map) from the Configure TCP/IP Telnet menu while your terminal is in
VTxxx emulation mode. When the command is used without any user-specified
parameters, the default keyboard mapping specified in Table 18 on page 202 is
restored. You can specify up to four of the defined special values for each
parameter. A special value cannot be used to specify more than one AS/400
function.
Type SETVTMAP to show the keyboard mapping displays. You are shown the
following initial display. Use the Page Down key to see the remainder of the
displays.
Set VT Keyboard Map (SETVTMAP)
Type choices, press Enter.
5250 Attention . . . . . . . . . *CTLA
*CTLA, *CTLB, *CTLC...
+ for more values
*ESCA
5250 Help . . . . . . . . . . . *CTLQST
*CTLA, *CTLB, *CTLC...
+ for more values
*ESCH
Page Down (Roll Up) . . . . . . *CTLD
*CTLA, *CTLB, *CTLC...
*CTLF
+ for more values
*NXTSCR
Page Up (Roll Down) . . . . . . *CTLB
*CTLA, *CTLB, *CTLC...
*CTLU
+ for more values
*PRVSCR
System Request . . . . . . . . . *ESCS
*CTLA, *CTLB, *CTLC...
+ for more values
*CTLC
Insert . . . . . . . . . . . . . *ESCI
*CTLA, *CTLB, *CTLC...
*ESCDLT
+ for more values
*INS
More...
F3=Exit
F4=Prompt F5=Refresh
F12=Cancel
F13=How to use this display
F24=More keys
You can press F4 (Prompt) to display the parameter values.
Changing a VTxxx Keyboard Map: Like the SETVTMAP command, the Change
VT Keyboard Map (CHGVTMAP) command allows you to customize the keyboard
mapping when connected to an AS/400 Telnet server operating in VTxxx mode. The
difference between these two commands is that the parameters for the SETVTMAP
command default to the shipped values while the parameters for the CHGVTMAP
command default to the currently set values. Except for this distinction, the two
commands are identical.
206
OS/400 TCP/IP Configuration and Reference V4R4
The CHGVTMAP command is only valid when called from within an AS/400 Telnet
server session operating in VTxxx full-screen mode. You can change the VT
keyboard map using option 4 from the Configure TCP/IP Telnet menu.
Step 11—VTxxx—Setting the DFTNVTTYPE Value
The DFTNVTTYPE (default network virtual terminal type) parameter specifies the
mode to be used when the Telnet server is not able to negotiate one of the
supported terminal types. Use the CHGTELNA command to set the value for this
parameter to either *VT100 for VT100 or VT220 mode or *NVT for ASCII line mode.
Step 12—VTxxx—Setting the ASCII/EBCDIC Mapping Tables
The AS/400 Telnet server uses default ASCII-to-EBCDIC and EBCDIC-to-ASCII
mapping tables based on the CCSID parameter in the TCP/IP Telnet attributes. The
default is to use the DEC multinational character set (*MULTINAT). Other 7-bit and
8-bit ASCII CCSIDs can also be used as well as any of the 7-bit DEC national
replacement character sets. These are discussed in “VTxxx—National Mode” on
page 180.
Note: For VT220 8-bit mode, the mapping tables are not available. The DEC
replacement character sets must be used. For the VT220 7-bit mode, you
can use either the mapping tables or the DEC replacement character sets.
You can change the default by changing the CCSID parameter, or by specifying
different values for the VTxxx outgoing (TBLVTOUT) and incoming tables
(TBLVTIN) using the CHGTELNA command, or by changing the default for the
current session using the Set VT Mapping Tables (SETVTTBL) command. This
command can also be accessed with option 2 on the CHGTCPTELN command
when in VTxxx emulation.
VTxxx Automatic Wrap
The AS/400 VTxxx server requires the VTxxx client to have the automatic wrap
(autowrap) option turned on. When automatic wrap is on, a character written to
column 80 of the VTxxx causes the cursor to move to the first column of the next
line. Please refer to your VTxxx client documentation for details of how to set on
this option.
System Request Processing for VTxxx Sessions
The system request processing for the VTxxx sessions is slightly different than that
for a normal 5250 workstation. When the System Request key is pressed on a 5250
workstation, a system request command line appears at the bottom of the display. If
you press the Enter key, the System Request menu appears. For VTxxx sessions,
the system request command line is not displayed when the system request
function is called. Instead, the System Request menu is displayed immediately.
Error Conditions on 5250 Keyboard
Certain error conditions cause a 5250 keyboard to lock and an error code to be
displayed on the operator error line, for example, typing when the cursor is not in
an input field. For VTxxx sessions, these errors cause a bell to sound on the VTxxx
terminal and the keyboard to remain unlocked.
Chapter 6. Telnet Server
207
Certain AS/400 applications also lock the 5250 keyboard and turn on the 5250
input-inhibited light. The user is then required to press the Error Reset key before
the keyboard is unlocked. For VTxxx sessions, the locking of the 5250 keyboard
causes a bell to sound on the VTxxx terminal whenever a key is pressed. To unlock
the keyboard, the VTxxx key that is mapped to the Error Reset key must be
pressed. In the default VTxxx keyboard map, the key CTL-R is mapped to the Error
Reset key.
Display Screens and VTxxx Support
When VTxxx support is negotiated, the Telnet server transmits screens that are a
maximum of 24 rows by 80 columns. The VTxxx client system sees these screens
in much the same way as they appear on a 5251 Model 11 workstation. However,
there are some differences.
v A 5251 display has indicator lights on the right side that indicate:
– System Available
– Message Waiting
– Keyboard Shift
– Insert Mode
– Input-Inhibited
The VTxxx server support emulates the System Available, Message Waiting,
Insert Mode, and Input-Inhibited lights by putting an asterisk in column 80 of rows
9, 11, 13, or 15, respectively. When an asterisk is displayed, the asterisk
overwrites the character that was previously displayed at that screen location. By
default, the VTxxx server does not display the indicator lights. You can enable or
disable these indicators by typing the key sequence that is mapped to the toggle
indicator lights function. The default key sequence for this function is ESC-T.
Note: When using a VTxxx client to attach to the AS/400 Telnet, note that the
Insert Mode and the Input-Inhibited lights may not always display as
described above. 5250 supports the attachment as a local function while
the VTxxx has no such facility. The System Available and Message
Waiting indicators, however, will display correctly.
v A 5251 display supports a screen attribute known as a column separator. The
column separator is a vertical line displayed between characters. This line does
not take up a character space. The VTxxx does not support such an attribute. If
an AS/400 application generates a screen that uses the column separator
attribute, that screen is displayed on the VTxxx client system with the column
separator mapped to the VTxxx underline attribute.
VT220 Control Characters
When VT220 8-bit emulation is negotiated, the range of characters X’80’ - X’9F’ are
protected as C1 control characters as architecturally defined in DEC VT220
Programmer Reference Manual This may result in the succeeding characters in a
data stream being interpreted as data in relation to these characters. If VT220 7-bit
or VT100 is negotiated, then the full range of characters from X’80’ - X’FF’ is
available for character translation. X’80 - X’9F’ must be interpreted as C1 control
characters in VT220 8-bit control mode only.
This has particular relevance to NLS support, as several non-English languages use
these values for language specific characters, and so in these cases, the VT220
8-bit emulation may not function as anticipated.
208
OS/400 TCP/IP Configuration and Reference V4R4
Some Practical Examples
This topic discusses using TCP/IP Telnet VTxxx emulation with the following clients:
DEC MicroVAX
Sun Sparc Classic
HP705 Apollo
DEC MicroVAX VT100 Full-Screen Telnet Client
The VT100 Telnet client provided by the Wollongong MicroVAX TCP/IP package
was tested to the AS/400 VTxxx Telnet server. Although this testing was by no
means thorough, the connection appeared to work satisfactorily providing the Telnet
session was initiated in the following way:
$ TELNET
TELNET> xon
Data flow control characters processed locally.
TELNET> promptmode
Will show 'TELNET>' prompt when connected.
TELNET> open 9.4.73.251
Trying 9.4.73.251.....
Connected to 9.4.73.251
Escape character is '|]'.
An AS/400 sign-on display was then received from SYSNAM123.
Note: Without xon turned on, the AS/400 display was corrupted.
The Telnet session from the MicroVAX could either be ended by using SIGNOFF
ENDCNN(*YES) or by Entering QUIT or CLOSE at the TELNET prompt. To obtain
the Telnet prompt, Enter the ’escape character’ (Ctrl-] by default). ’Promptmode’
must be enabled to obtain the Telnet prompt.
The connection was initiated from a VT320 terminal attached to the MicroVAX. The
results may be different for different terminal types and the previous information is
provided for guidance only. During testing, a requirement for a change to the default
keyboard map became apparent because the F6 function key on the VT320
terminal being used appeared to perform a local function (Interrupt). The
SETVTMAP command or the CHGVTMAP command maps this function to another
key if it were not possible to override this key being a local function.
Sun Sparc Classic VT100 Full-Screen Telnet Client
The VT100 Telnet client provided by the Sun UNIX TCP/IP package was tested to
the AS/400 VTxxx Telnet server. Although this testing was by no means thorough,
the connection appeared to work satisfactorily using the default Telnet command
parameters:
# TELNET
TELNET> open 9.4.73.251
Trying...
Connected to 9.4.73.251
Escape character is '|]'.
An AS/400 sign-on display was then received from SYSNAM123.
Chapter 6. Telnet Server
209
The Telnet session from the Sun system could either be ended by using SIGNOFF
ENDCNN(*YES) or by entering QUIT or CLOSE at the Telnet prompt. To obtain the
Telnet prompt, Enter the ’escape character’ (Ctrl-] by default).
The connection was initiated from a console attached to the Sun system. The
results may be different for different terminal types and the above information is
provided for guidance only. During testing a requirement for a change to the default
keyboard map became apparent. The F11 and F12 function keys did not appear to
perform the normal AS/400 functions. (F11 resulted in a print screen function and
F12 did nothing.) The SETVTMAP command or the CHGVTMAP command maps
these functions to other keys.
HP 705 Apollo VT100 Full-Screen Telnet Client
The VT100 Telnet client provided by the HP UNIX TCP/IP package was tested to
the AS/400 VTxxx Telnet server. Although this testing was by no means thorough,
the connection appeared to work using the default Telnet command parameters
from an xterm session on the HP X Window display:
# TELNET
TELNET> open 9.4.73.251
Trying.....
Connected to 9.4.73.251
Escape character is '|]'.
An AS/400 sign-on display was then received from SYSNAM123.
Note: An xterm session is initiated by typing the xterm command from an hpterm
session.
The Telnet session from the HP system could be ended by using SIGNOFF
ENDCNN(*YES) or by entering QUIT or CLOSE at the TELNET prompt. To obtain
the Telnet prompt, Enter the ’escape character’ (Ctrl-] by default).
The connection was initiated from an HP X-station attached to the HP system. The
results may be different for different terminal types and the previous information is
provided for guidance only. During the testing a requirement for a change to the
default keyboard map became apparent because the HP X-station appeared to
have function keys F1 to F8 only. The SETVTMAP command or the CHGVTMAP
command maps these functions to other keys.
ASCII Line Mode
If 5250 full-screen mode or 3270 full-screen mode cannot be negotiated, and if the
AS/400 Telnet server is not configured to default to VT mode, ASCII line mode is
used. ASCII line mode is the standard Telnet network virtual terminal (NVT) support.
The AS/400 Telnet server supports interaction with Telnet clients in ASCII line mode.
A network virtual terminal (NVT) is a type of AS/400 virtual display station that
represents an ASCII line-mode type of physical display station when the AS/400
system is the server in a TCP/IP Telnet connection.
Because the AS/400 system operates in full-screen mode and has screens with
many input fields, it is difficult to map these screens to a line mode device.
Therefore, consider the following when using ASCII line mode support for the
AS/400 Telnet server:
210
OS/400 TCP/IP Configuration and Reference V4R4
v You cannot sign on to the AS/400 system from a non-IBM system and use
workstation functions unless the non-IBM system provides Telnet 3270, Telnet
5250, VT100, or VT220 support.
v A sign-on screen for the AS/400 system is not automatically displayed when
ASCII line mode is negotiated.
v You must create a controller description for virtual workstations and device
descriptions for NVT workstations.
v You must have an application program running that opens a display file to the
NVT workstation devices.
v The programming language chosen for the application program must support
display files.
v Your application program must use a user-defined data stream (UDDS) to
interact with the device. UDDS is a data stream in which the user has defined
and embedded all device characters and allows AS/400 users to send their own
workstation data stream to a display device. This interface is described in the
Application Display Programming book.
v Your application program must format all data and provide security. Your
application code must control access to the NVT device (provide password
control, for example).
v If your application program does not acquire a virtual device before the Telnet
inactivity timer expires, the AS/400 server system ends the connection. A virtual
device is a device description that does not have hardware associated with it. It
is used to form a connection between a user and a physical workstation attached
to a remote system.
v Data is passed to the application without being mapped from ASCII to EBCDIC.
Setting up for ASCII Line Mode
To set up the Telnet server for ASCII line mode, you need to set the number of
automatically created virtual devices.
To run a workstation application in ASCII line mode, you must create and vary on a
controller description for a virtual workstation and a device description for a network
virtual terminal (NVT) display. The Telnet server support selects an NVT device
description that is varied on and not being used by another user. Your Telnet server
application must open a display file that uses the selected NVT device.
You should already have read “Setting Up the Telnet Server” on page 183. In
addition to the steps discussed in that topic, you need to perform the following:
1. Create a controller description for a virtual workstation.
2. Create a network virtual device.
3. Create an NVT application program.
Step 1—ASCII—Starting the Telnet Server Job
The server job for a TCP/IP application must be started in the QSYSWRK
subsystem. The Start TCP/IP Server (STRTCPSVR) command starts the servers
that are shipped with the TCP/IP Utilities licensed program.
Even though the Change Telnet Attributes (CHGTELNA) command has an
AUTOSTART parameter, that parameter is overridden or ignored by the
STRTCPSVR command.
Chapter 6. Telnet Server
211
Step 2—ASCII—Setting the Number of Virtual Devices
Virtual devices are used by the server system to direct output to devices on your
system. AS/400 Telnet server support automatically selects (and creates, if
necessary) these devices for you. You may also choose to create your own virtual
device under the QVIRCDnnnn virtual controller.
The option is available for you to allow the Telnet server support on the AS/400
system to automatically configure virtual controllers and devices. The QAUTOVRT
system value specifies the maximum number of devices that are automatically
configured by the system. Use the Change System Value (CHGSYSVAL) command
to change the value of the QAUTOVRT system value. For example, entering the
following command string changes the number of virtual devices that can be
allocated on a system to 50:
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(50)
Note: QAUTOVRT has been modified for Version 4 Release 2 to support numeric
values of 0 through 32500, and a special value of *NOMAX.
To determine and set the maximum number of users you want signed on to the
AS/400 system at any time, do the following:
1. Set the QAUTOVRT value to 32500, the maximum value allowed, or use the
*NOMAX value.
2. Let your users use pass-through, Telnet, and the virtual terminal application
program interface until you decide that the number of virtual devices created is
sufficient for normal system operation.
3. Change the QAUTOVRT value from 32500 to the number of virtual devices you
require for normal system operation.
If you have never allowed automatic configuration of virtual devices on your system,
the QAUTOVRT value is 0. A Telnet connection attempt with a dependence on
automatic creation of the virtual device then fails because the Telnet server does
not create more than the specified QAUTOVRT devices (zero). If you try to connect,
you receive a message (TCP2504) indicating that the Telnet client session has
ended and the connection is closed. In addition, the QTGTELNETS job in the
QSYSWRK subsystem on the AS/400 Telnet server sends a message (CPF8940)
indicating that a virtual device cannot be automatically selected.
If you change the QAUTOVRT value to 10, the next Telnet connection attempt
causes the Telnet server to create a virtual device. This virtual device is created
because the number of virtual devices on the controller (0) is less than the number
specified in the QAUTOVRT (10). Even if you change the specified number to 0
again, the next user attempting a Telnet connection succeeds. When a Telnet
connection attempt fails, the CPF87D7 message is sent to the system operator
message queue on the Telnet server system. The CPF87D7 message indicates that
the AS/400 server is not able to create a virtual device.
Security Considerations for ASCII Full-Screen Mode
The number of sign-on attempts allowed increases if virtual devices are
automatically configured. The number of sign-on attempts is equal to the number of
system sign-on attempts allowed multiplied by the number of virtual devices that
can be created. The number of system sign-on attempts allowed is defined by the
QMAXSIGN system value. The number of virtual devices that can be created is
defined by the QAUTOVRT system value.
212
OS/400 TCP/IP Configuration and Reference V4R4
In
to
v
v
v
Version 4 Release 2, the following level of support has been added with regard
security of virtual devices:
With a user-supplied exit program, you can audit the number of sign-on attempts
You have the ability to deny connections
You have the ability to allow bypassing of the sign-on screen
For more information on Telnet exit points and how to use them, see “TELNET Exit
Points” on page 541 in Appendix E. TCP/IP Application Exit Points and Programs.
Telnet and SNA 5250 Pass-Through Considerations for ASCII
Full-Screen Mode
The AS/400 system supports 5250 pass-through. 5250 pass-through is similar to
Telnet but runs on an SNA (Systems Network Architecture) protocol network rather
than a TCP/IP network. 5250 pass-through uses virtual displays to direct output to
the physical devices just as Telnet does. In 5250 pass-through, the AS/400 system
automatically creates virtual devices in the same way that it does for Telnet.
Therefore, the QAUTOVRT system value controls the number of automatically
configured virtual devices for both 5250 pass-through and Telnet. For more
information about 5250 pass-through, see the Remote Work Station Support book.
Step 3—ASCII—Setting the QLMTSECOFR Value
The OS/400 licensed program supports the limit security officer (QLMTSECOFR)
system value, which limits the devices the security officer can sign on to. If the
QLMTSECOFR value is greater than zero, the security officer must be authorized to
use the virtual device descriptions. However, when this value is 0, the system does
not limit the devices users with *ALLOBJ or *SERVICE special authority can sign on
to.
On AS/400 systems with a QSECURITY value of 30 or greater, a user with security
officer authority (*ALLOBJ) must be authorized to use devices before the system
allows the user to use those devices. For example, each display device that a
security officer wants to sign on to (local, remote, or virtual), must have had the
following authority specified with the Grant Object Authority (GRTOBJAUT)
command:
GRTOBJAUT
OBJ(display_name) OBJTYPE(*DEVD)
AUT(*CHANGE) USER(QSECOFR)
|
This procedure is very important because Telnet automatically configures virtual
devices. If the QLMTSECOFR value is set to 0, all devices automatically configured
by Telnet can be used by the security officer. If you set the QLMTSECOFR value to
1, your security officer is not able to use the virtual devices created by Telnet unless
you grant object authority to the security officer for that virtual device. The automatic
configuration support can delete and re-create the virtual device. If this occurs,
authority must be granted to the security officer each time the virtual device is
created.
|
Step 4—ASCII—Working with Associated System Values
|
|
|
|
|
In addition to the QAUTOVRT and QLMTSECOFR, the following system values are
available for you to work with from the Configure TCP/IP Telnet (CFGTCPTELN)
menu:
v QINACTITV: Inactive job time-out
v QINACTMSGQ: Inactive job message queue
Chapter 6. Telnet Server
213
|
|
|
|
|
v
v
v
v
v
|
v QDSCJOBITV: Time interval before disconnected jobs end
|
|
Setting the Telnet Timemark Timeout Value: You should also take into
consideration the TIMMRKTIMO parameter.
|
|
|
The Telnet timemark timeout (TIMMRKTIMO) parameter specifies the number of
seconds between TIMEMARK commands sent by the Telnet server. If Telnet is
unable to send the TIMEMARK command, it closes the connection.
QLMTDEVSSN: Limit device sessions
QMAXSGNACN: Action to take for failed sign-on attempts
QMAXSIGN: Maximum sign-on attempts allowed
QRMTSIGN: Remote sign-on control
QDEVRCYACN: Device I/O error action
Step 5—ASCII—Creating Virtual Controllers and Devices
You can create virtual controllers and devices. If you create your own virtual
devices, by allowing the system to automatically select the device name, you must
be aware of the following:
v The virtual controller must be named QPACTLnn, where nn is a decimal number 01
or greater.
v The virtual device should be named QPADEVxxxx, where xxxx is an alphanumeric
character from 0001 to ZZZZ.
Note: Starting with Version 4 Release 2, the xxxx are no longer only numeric
characters, but also alphanumeric characters from 0001 to ZZZZ, allowing
a maximum of 1,679,615 unique names (devices).
If you want to use more than 32500 devices, which is the maximum value
for the QAUTOVRT system, you can set the QAUTOVRT system value to
*NOMAX to allow additional devices to be created.
v The Telnet server reuses available existing virtual devices that were auto-created
by selecting virtual devices of the same device type and model. When there are
no more device type and model matches, but there are still available virtual
devices, then the device type and model will be changed to match the client
device and model negotiated. This is true only for auto-created (QPADEVnnn)
virtual devices. Typically, the auto-created virtual device will use the AS/400
system values for keyboard type, character set, and code page. Optionally, these
display device attributes may be more specifically defined through the exit
program or device specified client subnegotiation. Devices can also be selected
via the exit program interface as opposed to being negotiated.
Step 6—ASCII—Defining Workstations to Subsystems
When you use Telnet to sign-on to an AS/400 server, the sign-on screen may not
be displayed on your workstation. Before a user can sign on to the AS/400 server,
the workstation must be defined to the subsystem. If the workstation has not been
defined to the subsystem, you need to add a workstation entry to the subsystem
description under which you want your job to run on the AS/400 server. The
workstation in this case is the virtual display device automatically created by the
Telnet server (QPADEVxxxx). The workstation name or the workstation type must
be specified in the subsystem description on the AS/400 server. Use the Display
Subsystem Description (DSPSBSD) command to see the workstation entries
defined to a subsystem. (This only applies to display devices. Printer devices
214
OS/400 TCP/IP Configuration and Reference V4R4
typically run in the QSPL subsystem.) The following command can be used to add
all workstation types to a subsystem named QINTER:
ADDWSE SBSD(QINTER) WRKSTNTYPE(*ALL)
Note: The Add Work Station Entry (ADDWSE) command can be done when the
subsystem is active. However, the changes may or may not take effect
immediately. You may need to end and restart the subsystem.
Step 7—ASCII—Activating the QSYSWRK Subsystem
The QSYSWRK subsystem must be active. Use the Work with Subsystem
(WRKSBS) command to display the status of the subsystem.
The Telnet server must also be started. The interactive subsystem, QINTER, which
is used in previous examples in this chapter, needs to be started to run interactive
jobs for Telnet sessions. The spooling subsystem (QSPL) needs to be active to run
printer pass-through sessions.
Step 8—ASCII—Creating User Profiles for Telnet Users
At the server system, create one or more user profiles for Telnet users from other
systems. The default user profile is *SYS. The following example shows a sample
user profile:
CRTUSRPRF
USRPRF(CLERK1)
PASSWORD(unique-password)
JOBD(CLERKLIB/CLERKL1)
TEXT('User profile for Clerks Group 1')
Step 9—Creating a Controller Description for a Virtual
Workstation
To create a controller description for a virtual workstation, use the Create Controller
Description (Virtual Work Station) CRTCTLVWS command as follows:
CRTCTLVWS CTLD(NVTCTL)
TEXT('VIRTUAL CONTROLLER FOR NVT DEVICES')
Step 10—Creating a Network Virtual Device
To create a network virtual device, use the Create Device Description (Display)
(CRTDEVDSP) command as follows:
CRTDEVDSP DEVD(NVT1) DEVCLS(*VRT)
TYPE(*NVT) MODEL(0) CTL(NVTCTL)
TEXT('NVT Display Device for Telnet')
Note: When an ASCII line mode session is negotiated, the AS/400 server system
tries to find an NVT workstation device on the system. If no NVT workstation
device is available, or if no customer application is active and using the NVT
workstation device, the Telnet connection ends.
Keyboard Mapping: When in Telnet ASCII line mode, there is no keyboard
mapping.
Chapter 6. Telnet Server
215
Telnet Printer Pass-Through Mode
The Telnet printer pass-through mode (TPPT) allows the AS/400 user with a Telnet
client that supports printer emulation, to attach printer devices on the AS/400 over
the network. This support is accomplished by negotiating the 3812 or 5553 device
type support with the remote client Telnet application.
If you intend to use the TCP/IP Telnet printer pass-through, check with the client
vendor or with third parties that are known to provide 5250 clients for the availability
of the printer pass-through function.
Clients that support this function are:
v IBM Client Access for Win95
v Personal Communications Version 4 Release 2
Telnet Printer Pass-Through (TPPT) delivers the printer data stream between the
two systems as either EBCDIC or ASCII depending on the preferences of the
requesting client.
This topic explains the special considerations for a Telnet user operating in TPPT
mode.
Figure 125 shows a typical Telnet TPPT-mode environment.
Figure 125. Telnet Printer Pass-Through-Mode Environment
TPPT printing support can only be negotiated with a Telnet client application on a
system that supports Telnet printer emulation, for example, Client Access for Win95.
|
|
|
Note: When using Telnet printer pass-through, the print data must be spooled to a
printer writer queue. (Direct printing to the device is not supported.) To
ensure this, the print file used must specify *YES for the SPOOL parameter.
|
Telnet printer pass-through mode supports the following generic EBCDIC printer
devices:
v IBM-3812-1 for single byte character set support (SBCS)
v IBM-5553-B01 for double byte character set devices (DBCS)
216
OS/400 TCP/IP Configuration and Reference V4R4
|
|
|
You can specify either of these generic device types more completely by requesting
the AS/400 Host Print Transform (HPT) function and selecting the specific
manufacturing type. AS/400 sends the printer data stream in ASCII.
Setting Up for Telnet Printer Pass-Through Mode
You can use the CFGTCPTELN command to set up your TPPT mode session.
Step 1—Telnet Printer Pass-Through—Starting the Telnet Server
Job
The server job for a TCP/IP application must be started in the QSYSWRK
subsystem. The Start TCP/IP Server (STRTCPSVR) command starts the servers
that are shipped with the TCP/IP Utilities licensed program.
Even though the Change Telnet Attributes (CHGTELNA) command has an
AUTOSTART parameter, that parameter is overridden or ignored by the
STRTCPSVR command.
Step 2—Telnet Printer Pass-Through—Setting the Number of
Virtual Devices
Virtual devices are used by the server system to direct output to devices on your
system. AS/400 Telnet server support automatically selects (and creates, if
necessary) these devices for you. You may also choose to create your own virtual
device under the QVIRCDnnnn virtual controller.
The option is available for you to allow the Telnet server support on the AS/400
system to automatically configure virtual controllers and devices. The QAUTOVRT
system value specifies the maximum number of devices that are automatically
configured by the system. Use the Change System Value (CHGSYSVAL) command
to change the value of the QAUTOVRT system value. For example, entering the
following command string changes the number of virtual devices that can be
allocated on a system to 50:
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(50)
Note: QAUTOVRT has been modified for Version 4 Release 2 to support numeric
values of 0 through 32500, and a special value of *NOMAX.
To determine and set the maximum number of users you want signed on to the
AS/400 system at any time, do the following:
1. Set the QAUTOVRT value to 32500, the maximum value allowed, or use the
*NOMAX value.
2. Let your users use pass-through, Telnet, the virtual terminal application program
interface and Telnet Printer pass-through until you decide that the number of
virtual devices created is sufficient for normal system operation.
3. Change the QAUTOVRT value from 32500 to the number of virtual devices you
require for normal system operation.
If you have never allowed automatic configuration of virtual devices on your system,
the QAUTOVRT value is 0. A Telnet connection attempt with a dependence on
automatic creation of the virtual device then fails because the Telnet server does
not create more than the specified QAUTOVRT devices (zero). If you try to connect,
you will receive a message (TCP2504) that indicates that the Telnet client session
has ended and the connection is closed. In addition, the QTGTELNETS job in the
Chapter 6. Telnet Server
217
QSYSWRK subsystem on the AS/400 Telnet server sends a message (CPF8940)
indicating that a virtual device cannot be automatically selected.
If you change the QAUTOVRT value to 10, the next Telnet connection attempt
causes the Telnet server to create a virtual device. This virtual device is created
because the number of virtual devices on the controller (0) is less than the number
specified in the QAUTOVRT (10). Even if you change the specified number to 0
again, the next user attempting a Telnet connection succeeds. When a Telnet
connection attempt fails, the CPF87D7 message is sent to the system operator
message queue on the Telnet server system. The CPF87D7 message indicates that
the AS/400 server is not able to create a virtual device.
Security Considerations for Telnet Printer Pass-Through Mode
Printer sessions are always made active, immediately after session initialization,
which means that sign-on attempts are not necessary.
In Version 4 Release 2, the following level of support has been added with regard
to security of printer devices:
v You have the ability to deny connections
For more information on Telnet exit points and how to use them, see “TELNET Exit
Points” on page 541 in Appendix E. TCP/IP Application Exit Points and Programs.
Telnet and SNA 5250 Pass-Through Considerations for Telnet
Printer Pass-Through Mode
The AS/400 system supports 5250 pass-through. 5250 pass-through is similar to
Telnet; it runs on an SNA (Systems Network Architecture) protocol network rather
than a TCP/IP network. 5250 pass-through uses virtual displays to direct output to
the physical devices just as Telnet does. In 5250 pass-through, the AS/400 system
automatically creates virtual devices in the same way that it does for Telnet.
Therefore, the QAUTOVRT system value controls the number of automatically
configured virtual devices for both 5250 pass-through and Telnet. Other applications
use virtual devices also, for example, printer pass-through, Workstation Gateway,
and other IBM and non-IBM applications. For more information about 5250
pass-through, see the Remote Work Station Support book.
Step 3–Setting the Telnet Timemark Timeout Value
You should take into consideration the TIMMRKTIMO parameter.
The Telnet timemark timeout (TIMMRKTIMO) parameter specifies the number of
seconds between TIMEMARK commands sent by the Telnet server. If Telnet is
unable to send the TIMEMARK command, it closes the connection.
Step 4—Telnet Printer Pass-Through—Creating Virtual
Controllers and Devices
You can create virtual controllers and devices. If you create your own virtual
devices, by allowing the system to automatically select the device name, you must
be aware of the following:
v The virtual controller must be named QPACTLnn, where nn is a decimal number 01
or greater.
v The virtual device should be named QPADEVxxxx, where xxxx is an alphanumeric
character from 0001 to ZZZZ.
218
OS/400 TCP/IP Configuration and Reference V4R4
Note: Starting with Version 4 Release 2, the xxxx are no longer only numeric
characters, but also alphanumeric characters from 0001 to ZZZZ, allowing
a maximum of 1,679,615 unique names (devices).
If you want to use more than 32500 devices, which is the maximum value
for the QAUTOVRT system, you can set the QAUTOVRT system value to
*NOMAX to allow additional devices to be created.
v The Telnet server uses (existing) virtual devices only if the device type and model
are the same as the device type and model negotiated between the client and
server systems. Devices can also be selected via the exit program interface as
opposed to being negotiated.
Step 5—Telnet Printer Pass-Through—Activating the QSYSWRK
Subsystem
The QSYSWRK subsystem must be active. Use the Work with Subsystem
(WRKSBS) command to display the status of the subsystem.
The Telnet server must also be started. The interactive subsystem, QINTER, which
is used in previous examples in this chapter, needs to be started to run interactive
jobs for Telnet sessions. The spooling subsystem (QSPL) needs to be active to run
printer pass-through sessions.
Telnet Printer Pass-Through Mode Server to Client Access Win95
Telnet Client
This topic describes some practical experiences of a TPPT mode Telnet server with
the Client Access for Win95 client.
TPPT Mode Server to Client Access Win95 Telnet Client
The IBM Client Access for Win95 client provides both display emulation, 5250
full-screen Telnet client, and printer emulation. A printer session can be started by
selecting:
1. ″IBM for AS/400 Client Access″, ″Accessories″, ″Start or Configure Session″
from the program start menu
2. Select the name of an AS/400 system to connect to from the System name
pull-down
Use the workstation ID field to specifically request an AS/400 virtual device name or
leave it blank and the Telnet server will auto-select a compatible virtual device
(QPADEVxxxx) and return the name on the printer control panel.
For type of emulation:
1. Choose printer
2. Click on the set-up box to bring up the PC5250 printer emulation set-up screen
From the set-up screen, you may configure things such as font, the AS/400
message queue where printer messages are to be sent, and the ″transform print
data to ASCII on AS/400″ (HPT) host function. If HPT is selected, this enables other
configuration items, such as printer model and media tray selection options. There
is also an auto-reconnect option, and an option to override the default AS/400
Telnet port number (23).
Chapter 6. Telnet Server
219
The session is ended by selecting ″communication″ followed by ″disconnect″ from
the menu bar.
Ending a Telnet Server Session
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
Starting Cascaded Telnet or DSPT Sessions
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
Using System Request Options
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
|
|
|
Telnet Scenarios for Establishing Cascaded Sessions
In Figure 126, you are establishing a Telnet session from Tokyo to Geneva after you
have established a Telnet session with Chicago.
1. From the Tokyo system, type STRTCPTELN CHICAGO.
2. From the Chicago system, type STRTCPTELN GENEVA.
Figure 126. Establishing a Telnet Session with Three Systems
You now decide to return to the Tokyo system as shown in Figure 127 on page 221.
1. Press the System Request key.
2. Select option 13 (Start system request at home system). You are shown the
System Request menu on the Tokyo system.
220
OS/400 TCP/IP Configuration and Reference V4R4
Figure 127. Returning to Home System
You can also return to the home system (Tokyo) using option 14 (Transfer to home
system), shown in Figure 128.
1. Press the System Request key.
2. Select option 14 (Transfer to home system). You return to the alternate job on
the Tokyo system.
Figure 128. Returning to Alternate Job
Your Telnet sessions between Tokyo and Chicago and Chicago and Geneva are still
active.
From the Geneva system you want to return to the Chicago system (Figure 129).
1. Press the System Request key.
2. Select option 10 (Start system request at previous system). You are shown the
System Request menu on the Chicago system.
Figure 129. Starting System Request at Previous System
You can also return to the alternate job on the previous system (Chicago) using
option 11 (Transfer to previous system), shown in Figure 130 on page 222.
1. Press the System Request key.
Chapter 6. Telnet Server
221
2. Select option 11 (Transfer to previous system). You return to the alternate job on
the Chicago system.
Figure 130. Transferring to Previous System
Now you want to end the sessions with Geneva and Chicago and return to the
Tokyo system (Figure 131).
1. To end the session on the Chicago system from the Geneva system, type
SIGNOFF ENDCNN(*YES).
2. To end the session on the Tokyo system from the Chicago system, type SIGNOFF
ENDCNN(*YES). You return to the Tokyo system.
Figure 131. Ending a Session among Three Systems
In Figure 132, you are establishing a Telnet session from Tokyo to Chicago.
1. From the Tokyo system, type STRTCPTELN CHICAGO.
Figure 132. Establishing a Telnet Session between Two Systems
After establishing a Telnet session to Chicago, you want to return to the System
Request menu at Tokyo (Figure 133 on page 223).
1. Press the System Request key.
2. Select option 10 (Start system request at previous system). You return to the
System Request menu on the Tokyo system.
222
OS/400 TCP/IP Configuration and Reference V4R4
Figure 133. Starting the System Request at Previous System
You can also return to the Tokyo system using option 11 (Transfer to previous
system). Option 11 sends you to the alternate job at the Tokyo system (Figure 134).
1. Press the System Request key.
2. Select option 11 (Transfer to previous system). You return to the Tokyo system.
Figure 134. Transferring to the Previous System
From the alternate job at Tokyo, you now want to return to the Chicago system
(Figure 135). You can return to the Chicago system using one of the following:
v SIGNOFF command
v TFRSECJOB command
You can use the Transfer Secondary Job (TFRSECJOB) command to transfer
from an alternate job at a client system to the original job, which is running
Telnet; therefore, you end up at the server system. In Figure 135, the
TFRSECJOB command transfers you to your original job on the Tokyo system,
which is still running Telnet; therefore, you end up on the Chicago system.
v Option 1 on the System Request menu (Display sign on for alternative job)
Figure 135. Transferring a Secondary Job
You want to return to the Chicago system after going back to the Tokyo System
Request menu (Figure 136 on page 224). Do one of the following to return to the
Chicago system:
v From the Tokyo System Request menu, press F3 (Exit).
v From the Tokyo System Request menu, select option 15 (Transfer to end
system).
Chapter 6. Telnet Server
223
Figure 136. Returning to the End System
Now you want to end the session with Chicago and return to the Tokyo system
(Figure 137).
1. From the Chicago system, type SIGNOFF ENDCNN(*YES). You return to the Tokyo
system.
Figure 137. Ending a Session between Two Systems
Notes:
1. There is no limit to the number of systems to which you can establish a Telnet
session.
2. You can mix Telnet and pass-through (DSPT) sessions. For example, you could
go from Tokyo to Chicago using pass-through (DSPT) and from Chicago to
Geneva using Telnet.
You can only use the TFRPASTHR command at a target system using the
pass-through (DSPT) function. You cannot use it at a server system using
Telnet. For information on using display station pass-through (DSPT), see the
Remote Work Station Support book.
3. You can only have one pass-through (DSPT) or Telnet session per job. If you
want to have multiple sessions from your home system, see “Using a Group
Job—Scenario” on page 227.
4. The home system intercepts System Request options 13 and 14 if entered on
the System Request input line. This function may be helpful if you establish a
Telnet session with a system to which you cannot sign on. In this case, you can
end the session to that system by doing the following:
a. Press the System Request key.
b. Type 13 (Start system request at home system) on the System Request
input line.
c. Type 2 (End previous request) on the System Request menu.
All pass-through (DSPT) and Telnet sessions are stopped and you are returned
to the home system.
5. If you use Telnet from a home system to another system, and want to establish
a Telnet session with a third or an additional system, there is no requirement
that the home system be at a certain release level. However, to pass through
from an end system to another system, the end system must be running
OS/400 Version 2 Release 3 or later. Similarly, to use System Request options
13, 14, and 15, the end system must be running OS/400 Version 2 Release 3 or
later. And, finally, System Request options 10 and 11 work differently on
systems prior to OS/400 Version 2 Release 3 (as described in the following
topic).
224
OS/400 TCP/IP Configuration and Reference V4R4
System Request Processing—Scenarios
The system request processing for Telnet can differ from the system request
processing for display station pass-through (DSPT) in all the following scenarios
with the exception of the first scenario.
Scenario 1
All systems are AS/400 systems at Version 2 Release 3 (V2R3) or later. The
system request processing for Telnet works the same as the system request
processing for the pass-through (DSPT) support.
Figure 138. All AS/400 Systems at Version 2 Release 3 or later
Scenario 2
System A is an AS/400 system at Version 2 Release 2 (V2R2) or earlier.
Figure 139. System A at Version 2 Release 2 or Earlier
The system request processing is the same as for the Version 2 Release 3 or later
options in the first scenario with these exceptions:
v The System Request menu displayed on System A (the home system) uses
option 11 instead of option 15 to transfer to the end system.
v If you type option 10 at the barred-input line at the bottom of the System Request
menu, the System Request menu for System A is shown. If you type option 11,
an alternate job is started on System A.
System request processing differs from the processing that occurs if you press
the following keys: System Request, Enter, then type either option 10 or 11. In
this case option 10 shows the System Request menu for System C, and option
11 starts an alternate job on System C.
Scenario 3
System D is an AS/400 system at Version 2 Release 2 or earlier.
Chapter 6. Telnet Server
225
Figure 140. System D at Version 2 Release 2 or Earlier
The System Request menu for the end system will not have options 13 and 14. As
a result, you can only use option 10 (or 11) to start a system request on (or transfer
to) the previous system (System C). However, options 13 and 14 are available on
the System Request menus of the intermediate systems.
Scenario 4
System A is a non-AS/400 system using 3270 or VTxxx Telnet.
Figure 141. System A Is a Non-AS/400 System
The system request processing works like the first scenario except System B is
considered the home system. All system requests sent to the home system are
processed on System B.
Scenario 5
System D is a non-AS/400 system using 3270 or VTxxx Telnet.
Figure 142. System D Is a Non-AS/400 System
The system request processing works like the first scenario except System C is
considered to be the end system for all system request processing. If you press the
System Request key, and then press the Enter key, the System Request menu for
System C is shown.
Scenario 6
System C is a non-AS/400 system using 3270 or VTxxx Telnet.
226
OS/400 TCP/IP Configuration and Reference V4R4
Figure 143. Non-AS/400 System Is an Intermediate System
The system request processing works like the first scenario except System B is
considered the end system for system request processing. If you press the System
Request key and then press the Enter key, the System Request menu for System B
is shown.
If you want to send a system request to System E, you can map a function key on
System D to the System Request key. If the mapping function is done, then System
E is considered the end system, and System D is considered the home system.
Figure 144. Non-AS/400 System Is an Intermediate System with Mapping Function
As an example of this mapping function for an AS/400 3270 Telnet server, the
default keyboard mapping identifies the System Request key as a 3270 PF11 key.
For an AS/400 3270 Telnet client, the F11 key is mapped to the 3270 PF11 key. If
System C is a system using the 3270 data stream, pressing F11 maps to the
System Request key on System D. The system request is sent to System E, and
the System Request menu for System E is shown.
Note: This mapping function is complex especially if you are using the VTxxx data
stream and are mapping between block data and character data.
Using a Group Job—Scenario
You can use Telnet and the alternate job to connect to multiple systems from your
home system. Consider the following example:
Chapter 6. Telnet Server
227
Telnet is used to establish a session from System A to System B. You also want to
go to System C and remain connected to System B. You can start an alternate job
on System A using System Request option 11. Use the Telnet command to establish
a session to System C. You can get to another system (System D, for example) by
starting another Telnet session from System B or System C.
An alternative to using the alternate job is to use a group job. A group job is one of
up to 16 interactive jobs that are associated in a group with the same workstation
device and user. To set up a group job, do the following:
1. Change the current job to a group job using the Change Group Attributes
(CHGGRPA) command.
CHGGRPA GRPJOB(home)
2. Start a group job for System B using the Transfer to Group Job (TFRGRPJOB)
command.
TFRGRPJOB GRPJOB(SYSTEMB) INLGRPPGM(QCMD)
3. Establish a Telnet session to System B.
Telnet SYSTEMB
4. Return to your home system by pressing the ATTN Key. Pressing the ATTN key
shows you the Send Telnet Control Functions menu.
5. On the command line for the Send Telnet Control Functions menu, type:
TFRGRPJOB GRPJOB(home)
This returns you to your original job.
Other group jobs and Telnet sessions can be started similarly.
The TFRGRPJOB GRPJOB(*SELECT) command can be used to select which
group job you want. For example, if group jobs are started with the names
SYSTEMB, SYSTEMC, SYSTEMD, and SYSTEME, the TFRGRPJOB
GRPJOB(*SELECT) command shows the following display:
Transfer to Group Job
System: SYS198
Active group job . . . : HOME
Text . . . . . . . . . :
Type option, press Enter.
1=Transfer to group job
----------------------Suspended Group Jobs----------------------Opt
Group Job
Text
_
SYSTEME
_
SYSTEMD
_
SYSTEMC
_
SYSTEMB
Bottom F3=Exit
F5=Refresh
F6=Start a new group job
F12=Cancel
You can then use Telnet to establish a session with each system from the
appropriate job. The group job scenario would look like this:
228
OS/400 TCP/IP Configuration and Reference V4R4
When you want to end the group job, use the End Group Job (ENDGRPJOB)
command.
When you are in a Telnet session, you can switch to another group job by pressing
the ATTN key and then typing TFRGRPJOB on the command line.
Workstation Type Negotiations and Mappings
Table 19 shows a list of virtual display stations that the server system uses to match
the physical display stations of the client system.
If you are not sure what emulation package you are running, you need to determine
what your virtual display device is. You can use the Work with Job (WRKJOB)
command to find out what it is. You are shown the job name at the top of the
display. This is the name of the virtual display device associated with your job. By
default, the naming convention is QPADEVxxxx, where xxxx is an alphanumeric
character.
To determine the device type, type:
WRKCFGSTS *DEV QPADEVxxxx
You can work with your device description. Type an 8 (Work with description) next
to the name of the device. You are shown the device type. You can then determine
from the device type whether you are running in full-screen mode for 3270, 5250,
VT100, or VT220.
Chapter 6. Telnet Server
229
Table 19. Full-Screen Workstation Mappings
Supported
Workstation and
(Model)1
Equivalent Type and
(Model)
5251 (11)
5291 (1)
5291 (2)
5292 (2)
3196 (A1)
3196 (A2) 3196 (B1)
3196 (B2) 3476 (EA)
3486 (BA)
2
3487 (HA)
2
3487 (HG) 3487
(HW)2
3487 (HC)2
Internet Specification Description
IBM-5251-11
24 X 80 monochrome display
IBM-5291-1
24 X 80 monochrome display
IBM-5292-2
24 X 80 color graphics display; this
workstation type is also emulated by a
graphics workstation function.
IBM-3196-A1
24 X 80 monochrome display; this
workstation type is also emulated by a
monochrome workstation function.
IBM-3486-BA
24 X 80 monochrome display
IBM-3487-HA
24 X 80 monochrome display; this
workstation type is also emulated by a
monochrome workstation function.
IBM-3487-HC
24 X 80 color display; this workstation type is
also emulated by a color workstation
function.
3179 (2)
3197 (C1) 3197 (C2)
3476 (EC) 5292 (1)
IBM-3179-2
24 X 80 color display; this workstation type is
also emulated by a color workstation
function.
3180 (2)
3197 (D1) 3197 (D2)
3197 (W1) 3197 (W2)
IBM-3180-2
27 X 132 monochrome display
5555 (B01)
5555 (E01)
IBM-5555-B01
24 X 80 double-byte character set (DBCS)
monochrome display; this workstation type is
emulated by a workstation function that
supports DBCS display.
5555 (C01)
5555 (F01)
IBM-5555-C01
24 x 80 DBCS color display; this workstation
type is emulated by a workstation function
that supports DBCS display.
5555 (G01)
IBM-5555-G01
24 X 80 double-byte character set (DBCS)
monochrome, graphics display; this
workstation type is emulated by a workstation
function that supports DBCS display.
5555 (G02)
IBM-5555-G02
24 x 80 DBCS color graphics display; this
workstation type is emulated by a workstation
function that supports DBCS display.
3477 (FC)
IBM-3477-FC
27 X 132 wide-screen color display
3477 (FG)
3477 (FA) 3477 (FD)
3477 (FW) 3477 (FE)
IBM-3477-FG
27 X 132 wide-screen monochrome display
3277 (0)3
3277 (DHCF)
IBM-3277-2
24 X 80 monochrome display
3278 (DHCF)
IBM-3278-2
3, 4
3277 (0)
5
IBM-3278-2-E
24 x 80 monochrome display
3
IBM-3278-3
24 x 80 monochrome display
3
IBM-3278-4
24 x 80 monochrome display
3
IBM-3278-5
24 x 80 monochrome display
IBM-3279-2
IBM-3279-2-E5
24 X 80 monochrome display
IBM-3279-3
24 x 80 color display
3278 (0)
3278 (0)
3278 (0)
3278 (0)
3
3279 (0)
3279 (0)3
230
24 X 80 monochrome display
3
3279 (DHCF)
OS/400 TCP/IP Configuration and Reference V4R4
Table 19. Full-Screen Workstation Mappings (continued)
Supported
Workstation and
(Model)1
Equivalent Type and
(Model)
6
Internet Specification Description
DEC-VT100 VT1007
VT102 DEC-VT102
DEC-VT200
DEC-VT220 VT2007
VT2207
VT100 (*ASCII)
24 x 80 monochrome ASCII display
Notes:
1. All 5250 workstations, except 5555 (B01) and 5555 (C01), can operate as 5251-11 workstations.
2. This workstation can be configured to be either 24 x 80 or 27 x 132. You must determine the mode of the
workstation before setting the workstation type parameter value.
3. The AS/400 system supports only 24 X 80 screens in remote 327x workstations. Remote 3277 (both distributed
host command facility (DHCF), and regular) workstations are mapped to IBM-3277-2. Remote 3278 workstations
are mapped to IBM-3278-2. Remote 3279 workstations are mapped to IBM-3279-2.
4. Some TELNET 3270 full-screen (TN3270) or 3278-2 emulator packages do not support write structured fields
correctly. Because of this, 3278-2 type devices are mapped to 3277-2 devices by the AS/400 TELNET server
implementation to allow the AS/400 system to work with those TN3270 implementations.
5. The extended attributes highlighting is supported. Underline, blink, and reverse video are included. 3270 DBCS
processing is also supported.
6. The VT100 virtual device supports VT220 devices.
7. VT100, VT200, and VT220 are not official terminal type names. However, some implementations negotiate using
these names as the terminal type value.
System API Enhancement
The System API QDCRDEVD (Retrieve Device Description) provides the IP address
of the Telnet client. There are new fields for display (*DSP) and print (*PRT)
devices:
1. Network protocol
2. Network protocol address
3. IP internet address in dotted decimal form
These fields supply sockets level information to your application about the client’s
TCP/IP connection.
Dynamic Application Printing with TCP/IP
AS/400 TCP/IP supplies essential application print support to help control and direct
printing over your TCP/IP networks. This includes dynamic print support for clients
with variable Internet Protocol (IP) addresses. This support is supplied in the form
of a system API enhancement that allows your applications to retrieve the IP
address of your Telnet client.
The determination of a client’s location through its IP address is an improvement
over SNA- based pass-through connections which relied on the virtual device name.
The AS/400 Telnet server stores the IP address of the client in the virtual device
description.
Chapter 6. Telnet Server
231
IP Address Mapping
When you use the QDCRDEVD API, your application can map the IP address of
the client to a particular printer. This allows your application to control where and
how to send the print file. This mapping sends print files back to the client’s
workstation, to a network printer or to a printer on the application system.
Printer
Print IP
Client IP
User
DestType
Transform
Type/Model
hpjet
5.6.7.22
5.6.7.*
STEVENS
*OTHER
*YES
*HP560C
QPRINT
5.6.7.23
5.6.8.*
QUSER
OS400
*NO
IBM4029
LPTL
*CLIENT
*.*.*.*
MURPHY
*OTHER
*YES
IBM42011
IP Address Mapping Rules
1. A ’*’ in column 1 is a comment line, a ’|’ is a field delimiter.
2. A ’*’ character can be used as a wildcard in IP address hops.
3. *CLIENT for the printer IP field means substitute the client IP .
4. DestType must be: *SAME or a valid DESTTYPE parameter value.
5. Transform must be: *SAME or a valid TRANSFORM parameter value.
6. Type/Model must be: *SAME or a valid MFRTYPMDL parameter value.
Figure 145. IP Address Mapping
IP Address Mapping Scenarios
IP address mapping can support a variety of application controlled printing options
as indicated in the three client scenarios that follow. Individual applications are not
limited to these scenarios. It is up to you to decide what you need from your own
application. Overall, the information included in this section provides you with the
tools to restrict , track, or re-route print files as your business dictates.
Client 1: In this scenario, client 5.6.7.8 is at the office and is on subnet 5.6.7.*. All
clients on subnet 5.6.7.* want printouts on a local network printer, hpjet at 5.6.7.22.
This mapping program modifies the default *OUTQ for client 5.6.7.8 with the
command:
CHGOUTQ OUTQ(default) RMTSYS('5.6.7.22') RMTPRTQ('hpjet')
AUTOSTRWTR(1) CNNTYPE(*IP) TRANSFORM(*YES) MFRTYPMDL(*HP560C)
DESTTYPE(*OTHER)
Client 2: In this second scenario, clients on subnet 5.6.8.* handle confidential
information and require a graphics printer that supports overlays (IFPDS type
spooled files). All clients on subnet 5.6.8.* want printouts to secured printer QPRINT
at 5.6.7.23. This mapping program modifies the default *OUTQ for this client with
the command:
CHGOUTQ OUTQ(default) RMTSYS('5.6.7.23') RMTPRTQ('QPRINT')
AUTOSTRWTR(1) CNNTYPE(*IP) TRANSFORM(*NO) MFRTYPMDL(*IBM4029)
DESTTYPE(*OS400)
Client 3: In this third scenario, client 1.2.3.4 is located at home and is using an
Internet Service Provider (ISP). This person wants printouts sent to the LPD server
running on their workstation. To do this, you could use all wildcards as a catchall
entry (use it as the last one) for ISP clients, and have the IP printer address
mapped to the same as the client workstation. This mapping program modifies the
default *OUTQ for this client with the command:
232
OS/400 TCP/IP Configuration and Reference V4R4
CHGOUTQ OUTQ(default) RMTSYS('1.2.3.4') RMTPRTQ('hpjet')
AUTOSTRWTR(1) CNNTYPE(*IP) TRANSFORM(*YES) MFRTYPMDL(*IBM42011)
DESTTYPE(*OTHER)
Firewalls: Firewalls and other tools can mask or manipulate IP addresses to
appear other than the true Internet address. For that reason, the security of the
client IP address is only as good as the security of your TCP/IP network. For
information on firewall concepts and on an IBM firewall product for the AS/400, see
the Getting Started with IBM Firewall for AS/400, SC41-5424-02 book or go to
http://www.as400.ibm.com/firewall.
Exit Point Performance
The Telnet server response time for your initial session request will include any time
that it takes for the QIBM_QTG_DEVINIT user exit program to be called, executed
and returned. If your exit program is doing significant processing, the performance
impact may result in a longer wait before your session is established.
Once the Telnet program is established by way of a sign-on panel or other AS/400
panel, there is no performance impact. When this occurs, the user exit program is
no longer in the Telnet path. Established Telnet sessions experience no delays due
to the QIBM_QTG_DEVINIT user exit program.
There is no user-visible performance impact that is associated with disconnecting
the session. Disconnecting means that you end your terminal emulation session,
not that you sign-off and return to the sign-on panel. If you disconnect, then the
QIBM_QTG_DEVTERM user exit program is invoked, which will perform the
termination processing for your session. Users will not see this because it occurs
after the connection is broken.
Work Management
Key work management issues can be solved by using a Telnet exit program. These
issues include the capability to request device descriptions other than
QPADEVxxxx, opening up the door for work management control of interactive
virtual terminal jobs and routing those jobs to specific subsystems.
Subsystem routing and device name selection
It is recommended that no more than 300 users be serviced by any given
subsystem, for example, QBASE, QCMN, or QINTER. In the past, for Telnet, this
posed problems because workstation entries did not work due to the QPADEVxxxx
naming convention which meant that there was no way to subdivide the jobs easily.
Beginning with Version 4 Release 2, users can take advantage of better Telnet
virtual device names and configure their interactive subsystems to subdivide the
work, if necessary. This is done by using the Add Work Station Entry (ADDWSE)
command to specify which devices a subsystem should or should not allocate a
particular name of virtual terminal devices.
The following command has QINTER allocate all QPADEV* workstations, which
means that all such devices are routed to the QINTER subsystem:
ADDWSE SBSD(QINTER) WRKSTN(QPADEV*) AT(*SIGNON)
Chapter 6. Telnet Server
233
The following command has QINTER not allocating all QPADEV* workstations,
which means that these devices can be allocated to a different subsystem:
ADDWSE SBSD(QINTER) WRKSTN(QPADEV*) AT(*ENTER)
Users can develop their own device naming conventions to subdivide the work. For
example, one kind of subdivision is to route certain devices to national language
support (NLS) related subsystems in two locations.
Example
For the purpose of this example, the two users are located in Endicott and
Rochester. The users are assigned to AS/400 subsystems ENDICOTT and
ROCHESTER, respectively, according to their geographic location. The
characteristics of this example include:
v The IP addresses for Endicott start with 1.2.3.* .
v The IP addresses for Rochester start with 2.3.4.*.
v In order for all of the Endicott Telnet sessions to run in the ENDICOTT
subsystem and the Rochester Telnet sessions to run in the ROCHESTER
subsystem, the user exit program is employed to create a virtual device name
that starts with ’ENDICOT’ for all Telnet connections from 1.2.3. * and a virtual
device name that starts with ’ROCHEST’ for all connections from 2.3.4.*
v The user exit program assigns the virtual device name ’ENDICOT047’ for an IP
address of 1.2.3.47 and a virtual device name of ’ROCHEST048’ for an IP
address from 2.3.4.48 (using the last three digits of the IP address to complete a
unique name for every user).
To insure that virtual devices ENDICOT047 and ROCHEST048 go into subsystems
Endicott and Rochester, respectively, the workstations entries are set up as follows:
ADDWSE SBSD(QINTER) WRKSTN(ENDICOT*) AT(*ENTER)
ADDWSE SBSD(QINTER) WRKSTN(ROCHEST*) AT(*ENTER)
ADDWSE SBSD(ENDICOTT) WRKSTN(ENDICOT*) AT(*SIGNON)
ADDWSE SBSD(ROCHESTER) WRKSTN(ROCHEST*) AT(*SIGNON)
234
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 7. File Transfer Protocol (FTP) Client
The File Transfer Protocol (FTP) client function allows you to send and receive
copies of files to or from remote systems across a TCP/IP network. In addition, FTP
client subcommands are provided for renaming, appending to, and deleting files.
The majority of File Transfer Protocol (FTP) Client documentation material is
covered in the AS/400e Information Center under the TCP/IP topic. For more
information see “TCP/IP Topics in the Information Center” on page xv.
Functions Supported by FTP Client
v Transferring files that are found in the Root, QOpenSys, QLANSrv file, and
QFileSvr.400 systems.
v Running FTP unattended in batch.
v The automatic creation of sequence numbers when transferring data to a source
physical file on AS/400 business computer systems.
v Sending or receiving save files and members in physical files, logical files,
Distributed Data Management (DDM) files, and source physical files.
v Sending text files in EBCDIC format or converting them to ASCII (the default
format).
v Transferring binary files as is.
v Transferring folders and document in the document library services (QDLS) file
system.
v Double-byte character set (DBCS) support.
v Coded character set identifier (CCSID) support.
Functions Not Supported by FTP Client
v Transferring selected records within files.
v Selection or omission of fields within records when transferring files. You must
transfer an entire physical or logical record.
FTP Client and Server-Overview
FTP consists of two parts, the client and the server as shown in Figure 146 on
page 236.
© Copyright IBM Corp. 1997, 1999
235
Figure 146. Relationship between FTP Client and FTP Server
The client has a user interface from which you can enter client subcommands for
making requests to an FTP server. The results of these requests are then
displayed.
One may interact with the client online or run the FTP client in an unattended batch
mode where client subcommands are read from a file and the responses to these
subcommands are written to a file.
To transfer files between the client and the server, two connections are established.
The control connection is used to request services from the server with FTP server
subcommands. The server sends replies back to the client to indicate how the
request was handled. The second connection, called the data connection, is used
for transferring lists of files and the actual file data.
Both the client and the server have a data transfer function that interfaces to the
resident file systems. These functions read or write data to the local file systems
and to and from the data connection.
Requests for transferring files originate from the client. The user makes these
requests with the FTP client subcommands that are read by the client user interface
function. The client subcommands are interpreted by the client protocol interpreter,
which translates them into appropriate FTP server subcommands. The server
protocol interpreter receives the subcommands from the control connection and
processes it. The results of each server subcommand are transmitted back to the
client in the form of an FTP server reply.
236
OS/400 TCP/IP Configuration and Reference V4R4
The distinction between FTP client and FTP server is from the viewpoint of where
the FTP commands are initiated, and not from the viewpoint of where the data
resides. Thus, the commands are initiated from the FTP client session, while the
files being transferred may initially reside on either system.
Starting the FTP Client Session
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Alternative Start Commands
There are several ways to start an FTP client session:
v Use the Start TCP/IP File Transfer Protocol (STRTCPFTP) command (the
instructions for using this command follow).
v The AS/400 system allows you to use the FTP command. This command
performs the same functions as the STRTCPFTP command.
v Select option 9 (Start TCP/IP FTP session) from the TCP/IP Administration menu.
To get to the TCP/IP Administration menu, type GO TCPADM on the command
line of the AS/400 Main menu.
To start an FTP client session using the STRTCPFTP command:
1. Type STRTCPFTP on the command line.
2. Press F4 (Prompt). The prompt for the remote system is displayed as shown in
Figure 147.
Start TCP/IP File Transfer (STRTCPFTP)
Type choices, press Enter.
Remote system . . . . . . . . . ___________________________________
_______________________________________________________________________
_______________________________________________________________________
_______________________________________________________________________
Figure 147. Prompt for the Remote System
3. Type in the name or internet address of the remote system with which you want
to start your FTP session.
4. Press the Enter key.
A prompt for the coded character set identifier (CCSID) is displayed as shown in
Figure 148 on page 238.
The CCSID parameter is displayed with the value *DFT. This parameter specifies
the ASCII CCSID to be used for single-byte character set (SBCS) ASCII file
transfers when the FTP TYPE mode is set to ASCII. When *DFT is specified, the
default CCSID value is 819 (ISO 8859-1 8-bit ASCII).
For some AS/400 systems, character conversion between the EBCDIC CCSID
specified by your job and the default CCSID 819 may not be available. When this is
Chapter 7. File Transfer Protocol (FTP) Client
237
the case, the STRTCPFTP command displays message TCP3C14: Unable to
convert data from CCSID &1 to CCSID &2. The following sample message shows
that &1 is the job CCSID and &2 is the ASCII CCSID specified in the STRTCPFTP
command.
UNABLE TO CONVERT DATA FROM CCSID 5026 TO CCSID 819
In this situation, the STRTCPFTP command must be run again with an ASCII
CCSID for which character conversion is supported. CCSID 850, which contains the
PC Latin-1 coded character set and supports character conversion for all valid job
CCSID values, is suggested.
Start TCP/IP File Transfer (STRTCPFTP)
Type choices, press Enter.
Remote system . . . . . . . . . > SYSNAM08.ENDICOTT.IBM.COM______________
_______________________________________________________________________________
_______________________________________________________________________________
_______________________________________________________________________________
"Internet address . . . . . . . ." _______________________________
Coded character set identifier
*DFT
1-65533, *DFT
Figure 148. Prompt for the Internet Address
After typing a remote system name or an internet address and pressing the Enter
key, an FTP client session is started and the FTP client session user interface
display is shown (Figure 149 on page 239). In the history area (Previous FTP
subcommands and messages) are displayed messages indicating that a connection
to the server host has been initiated and replies from the server acknowledging that
a connection has been established. Also, messages that indicate the inactivity
time-out value and the remote host operating system may be included.
If the only message that appears is the first one, ’Connecting...’, it is possible that
TCP/IP or the FTP server has not been started on the remote host. Also, it is
possible that the network connection is not available. This can be verified using the
PING command.
238
OS/400 TCP/IP Configuration and Reference V4R4
File Transfer Protocol
Previous FTP subcommands and messages:
Connecting to host name SYSNAM08 at address 9.125.87.146 using port 21.
220-QTCP at sysnam08.endicott.ibm.com.
220 Connection will close if idle more than 5 minutes.
Enter login ID (itso):
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 149. FTP Session Acknowledgement and Logon Prompt to the Remote System
Logon to the Remote System (Server)
When the connection to the server is established, the client automatically initiates a
USER subcommand and prompts you for a logon ID. The logon prompt shows your
client AS/400 system logon ID (itso in Figure 149). If your ID on the remote server
is the same, press the Enter key. This ID is used by the AS/400 FTP client to log
you on to the remote server. If you do not have this ID on the remote server, you
should type your logon ID on the remote FTP server at the logon prompt before
pressing Enter. Depending on the security at the remote server, it may request a
password to complete the logon.
If your logon attempt fails because you did not type your user ID or password
correctly, you can try to sign on again by doing the following:
1. Type the USER subcommand followed by your user ID.
2. Press the Enter key.
3. Type your password (if requested)
4. Press the Enter key.
Chapter 7. File Transfer Protocol (FTP) Client
239
File Transfer Protocol
Previous FTP subcommands and messages:
Connecting to host name SYSNAM08 at address 9.125.87.146 using port 21.
220-QTCP at sysnam08.endicott.ibm.com.
220 Connection will close if idle more than 5 minutes.
>
331 Enter password.
230 ITSO logged on.
OS/400 is the remote operating system.
250 Now using naming format "0".
257 "QGPL" is current library.
The TCP/IP version is "V3R1M0".
Enter password:
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 150. Successful Logon to FTP Session
As is shown in Figure 150, the FTP server sends replies that are preceded by a
three-digit numeric code to the client host as a response to each subcommand. For
example, a 331 response may be sent to request a password when the user ID is
entered, and a 230 response is sent after a successful logon.
If the server is an AS/400, the server replies show the current library (directory) and
the file name format in use on the server.
When the logon process has completed, you can enter the FTP subcommands that
are described in this chapter.
Connecting to Another Server without Ending the FTP Session
The CLOSE subcommand can also be used to close the connection with the
remote server. This subcommand does not end the FTP client session. The OPEN
subcommand can then establish a connection with another server. For example, the
following opens a connection to SYSNAM01:
OPEN SYSNAM01
When the OPEN is successful, the FTP client prompts for a user ID, as it does at
FTP startup.
Ending the FTP Client Session
The FTP session is ended with the QUIT subcommand. The QUIT subcommand
closes the connection with the remote host and ends the FTP session on the
AS/400 system. Alternatively, you can press F3 (Exit) and then confirm to end the
FTP client session.
240
OS/400 TCP/IP Configuration and Reference V4R4
Transferring Files with File Transfer Protocol (FTP)
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Naming Format Indicator for AS/400 Names
A naming indicator, called NAMEFMT, enables the user to specify library file system
names in either the format used by FTP prior to V3R1 or in a path name format as
used by the integrated file system. The user selects the desired format by assigning
either a one or zero to the NAMEFMT value.
0
indicates that the name is in the original format that is supported by FTP for the
library file system prior to V3R1. Only library file system names can be entered
when NAMEFMT is 0.
1
indicates that a path name format is being used for the file name. This format
applies to all AS/400 file systems supported by FTP, including the library file
system (QSYS.LIB). This name format complies with the Integrated File System
naming rules.
The generic format for NAMEFMT=1 is:
[/filesystemname/]{directory/}filename
Notes:
1. On AS/400 FTP servers prior to V3R1, the NAMEFMT is assumed to be ’0’. For
V3R1 and subsequent releases, AS/400 FTP servers may have a NAMEFMT of
’0’ or ’1’. For non-AS/400 servers, the NAMEFMT value is considered as
unknown. The value of the server NAMEFMT value affects the default file
names created by the FTP client.
2. A fully-qualified name in NAMEFMT=1 begins with a slash followed by the name
of the file system. For example:
/QDLS/FOLDER/DOCUMENT
3. For NAMEFMT = 0, a fully-qualified name begins with the library name. For
example:
LIBNAME/FILENAME.MBRNAME
4. For NAMEFMT = 1, a partially-qualified name does not begin with a slash and
does not include the name of the file system. For example:
FOLDER/DOCUMENT
(where the working directory is /QDLS)
LIBNAME.LIB/FILEXYZ.FILE/MEMBER1.MBR
(where the working directory is /QSYS.LIB)
5. For NAMEFMT = 0, a partially-qualified name begins with the file name without
any slash. For example:
FILENAME.MBRNAME
(where the working directory is LIBNAME)
6. The NAMEFMT is set to “0” when an FTP session is started.
Chapter 7. File Transfer Protocol (FTP) Client
241
File Naming for the Library File System (QSYS.LIB)
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Names for Document Library Services (QDLS) Folders and Documents
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Names for “root,” QOpenSys, QLANSrv and QFileSvr.400 File Systems
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Localfile and Remotefile Parameters for FTP Client Subcommands
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Default File Names for Client Transfer Subcommands
The majority of this material is covered in the AS/400e Information Center under
the TCP/IP topic. For more information see “TCP/IP Topics in the Information
Center” on page xv.
Table 20 shows an example of default names.
Notes:
1. Save files do not have members. Therefore, default names for save files do not
have a member part.
2. Default names are displayed when the DEBUG mode is turned on.
Table 20. Example Default Names for the PUT, APPEND, and MPUT Subcommands
Source Host (AS/400 Client)
Name
Format
File Sys
Target Host (Server)
Name
Format
File Name
File Sys
Default Name
0
QSYS.LIB
libnam/ffff.mmmm
0
QSYS.LIB
ffff.mmmm
0
QSYS.LIB
libname/ffff
0
QSYS.LIB
ffff.ffff1
1
QSYS.LIB
libX.lib/ffff.file/mmmm.mbr
0
QSYS.LIB
ffff.mmmm2
0
QSYS.LIB
libname/ffff.mmmm
—3
—3
ffff.mmmm
3
3
ffff
3
0
QSYS.LIB
libname/ffff
—
—
1
QSYS.LIB
libX.lib/ffff.file/mmmm.mbr
—
—
ffff.mmmm2
0
QSYS.LIB
libx/ffff
0
QSYS.LIB
ffff4
242
OS/400 TCP/IP Configuration and Reference V4R4
3
Table 20. Example Default Names for the PUT, APPEND, and MPUT Subcommands (continued)
Source Host (AS/400 Client)
Name
Format
File Sys
Target Host (Server)
Name
Format
File Name
File Sys
Default Name
1
QSYS.LIB
libx.lib/ffff.savf
0
QSYS.LIB
ffff4
1
QSYS.LIB
libx.lib/ffff.file
0
QSYS.LIB
ffff4
1
QSYS.LIB
libx.lib/ffff.savf
1
QSYS.LIB
ffff.SAVF4
1
QSYS.LIB
libx.lib/ffff.file
1
QSYS.LIB
ffff.FILE4
0
QSYS.LIB
libx/ffff
1
QSYS.LIB
ffff.SAVF4
1
QDLS
libname/filename.ext
1
QDLS
filename.ext
1
QDLS
libname/filename
1
QDLS
filename
1
“root”
/Directory1/FileA
1
QOpenSys
FileA5
1
QOpenSys
/QOpenSys/Direct/fileABC
1
“root”
fileABC5
Notes:
1. Shows that the default member name is the same as the file name when no member name is specified. The PUT
subcommand attempts to send a member of the same name as the file name.
2. Occurs when the server is an AS/400 that does not support NAMEFMT 1.
3. Indicates unknown. The name format is not defined for non-AS/400 servers and is considered unknown.
4. Illustrates how a save file is processed. A save file default name does not have a member name because save
files do not have members.
5. The case of the characters in the default name is the same as that of the entered file name for the “root,”
QOpenSys, and QLANSrv file systems.
Table 21. Example Default Names for the GET and MGET Subcommands
Source Host (Server)
Name
Format
File Sys
Target Host (AS/400 Client)
Name
Format
File Name
File Sys
Default Name
0
QSYS.LIB
libname/ffff.mmmm
0
QSYS.LIB
FFFF.MMMM
0
QSYS.LIB
libname/ffff
0
QSYS.LIB
FFFF.FFFF
0
QSYS.LIB
libname/ffff
1
QSYS.LIB
FFFF.FILE/FFFF.MBR
0
QSYS.LIB
libname/ffff.mmmm
1
QSYS.LIB
FFFF.FILE/MMMM.MBR
1
QSYS.LIB
libX.lib/ffff.file/mmmm.mbr
0
QSYS.LIB
FFFF.MMMM
QSYS.LIB
libX.lib/ffff.file/mmmm.mbr
1
QSYS.LIB
FFFF.FILE/MMMM.MBR
—
abcdefghigjk
0
QSYS.LIB
ABCDEFG.ABCDEFG2
—1
—1
abcdefghigjk.lmnolpgrst
0
QSYS.LIB
ABCDEFG.LMNOPQR2
—1
—1
abcd
1
QSYS.LIB
ABCD.FILE/ABCD.MBR2
—1
—1
abcd.efgh
1
QSYS.LIB
ABCD.FILE/EFGH.MBR2
—1
—1
abcdefghijk
1
QDLS
ABCDEFGH2
—1
—1
abcdefghijkl.mnopqrs
1
QDLS
ABCDEFGH.MNO2
1
QOpenSys
/QOpenSys/Directory/FileA
1
“root”
FileA3
1
“root”
/Directory/fileABC
1
QOpenSys
fileABC3
1
—
1
1
Chapter 7. File Transfer Protocol (FTP) Client
243
Table 21. Example Default Names for the GET and MGET Subcommands (continued)
Source Host (Server)
Name
Format
File Sys
File Name
Target Host (AS/400 Client)
Name
Format
File Sys
Default Name
Notes:
1. Server name format and system name is not defined. This is the typical case for non-AS/400 servers.
2. Illustrate how names are formed for a GET when the server is not an AS/400.
3. The case of the characters in the default name are the same as that of the entered file name for the “root,”
QOpenSys and QLANSrv file systems.
FTP Client Subcommands
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
FTP Examples
This topic shows four specific scenarios of using FTP to put and get files.
v AS/400 to AS/400
v AS/400 to VAX**/Wollongong
v AS/400 to AIX (UNIX)
v AS/400 to OS/2 using QDLS file names
The process of running FTP to other hosts is the same as running FTP to another
AS/400. However, there are differences in file naming structures, directory
structures, and the operation of some of the FTP subcommands on those hosts.
These differences may vary the results for some FTP subcommands. For example,
most other systems do not have file structures that have file members. Therefore,
when file members are transferred from an AS/400 to other systems, each AS/400
file member creates or replaces a separate file on the other system.
This section describes how to transfer data to and from different remote system
servers using the PUT, MPUT, GET, and MGET subcommands. The AS/400 objects
that can be transferred with these subcommands can be one of the following:
v Members of physical files (source and data)
v Logical files (put and get operations of a logical file create a physical file
according to the view defined in the logical file)
v Save files
v Objects in Hierarchical File Systems (HFS) such as those in QDLS folders and
documents.
The following examples illustrate how to put AS/400 database file members and get
remote files into database file members.
Note: The restrictions and considerations noted in the following topics were
discovered from tests on the particular systems. The results may be different
for other software releases or implementations.
244
OS/400 TCP/IP Configuration and Reference V4R4
AS/400-to-AS/400
This example shows how to transfer physical file members to and from another
AS/400.
Put a File: The FTP subcommand PUT is used to copy a local file member into a
file at the remote host.
To copy a local file member into a file at the remote host, you need write authority
for the library where the file is put. A library at the AS/400 system is a logical
placeholder for other objects such as programs, files, and commands. A library can
be compared to a directory on other systems.
The syntax of the PUT subcommand is as follows:
PUT localfile [remotefile]
The remotefile is optional. If omitted, the current library (or current directory for
QDLS objects) on the remote AS/400 is used with the file having the same name.
You can change the current library or directory on the remote AS/400 with the CD
subcommand.
For the AS/400 system, the syntax of a file name, using NAMEFMT 0 is:
library/file.member
For the AS/400 system, the syntax of a file name, using NAMEFMT 1 is:
/QSYS.LIB/libname.LIB/filename.FILE/mbrname.MBR
This refers to the same file as the NAMEFMT 0 example above.
On the AS/400 system, files may have one or more members. Each file member
can consist of data records, or each may contain other records such as source
programs or database definitions.
An example of the PUT subcommand is shown in Figure 151, below.
File Transfer Protocol
> put ITSOTST1/scrncpy.scrncpy itsotst2/scrncpy.scrncpy
200 PORT subcommand request successful.
150 Sending file to member SCRNCPY in file SCRNCPY in library ITSOTST2.
250 File transfer completed successfully.
286412 bytes transferred in 12.595 seconds. Transfer rate 22.741 KB/sec.
Enter an FTP subcommand.
===> put ITSOTST1/scrncpy.scrncpy itsotst2/scrncpy.scrncpy
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 151. FTP PUT Display
The PUT subcommand copies the file member SCRNCPY in file SCRNCPY in
library ITSOTST1 at the local host to member SCRNCPY in file SCRNCPY in library
ITSOTST2 on the remote system. If the member already exists at the remote host,
the remote system will overwrite the existing member.
Chapter 7. File Transfer Protocol (FTP) Client
245
If you want to transfer several files to the remote host, the MPUT subcommand may
be used to do this:
mput libm01/filem01.*
The subcommand MPUT sends multiple file members to the remote host. The
MPUT subcommand copies all members in the file FILEM01 in library LIBM01 to file
FILEM01 in the current library of the remote host. The local file name is required,
but the library name may be omitted. If the library name is not specified, the local
user’s current library is used. If the member name is not specified, the file name is
used as the member name
Note that it is not possible to specify the library name at the remote host on the
MPUT command itself. The remote user’s current library is used. This is set
automatically to the one specified in the user’s profile at sign-on time. The PWD
subcommand may be used to determine the current library. The CD subcommand
may be used to change it, as shown in Figure 152, prior to issuing the MPUT
command.
File Transfer Protocol
Previous FTP subcommands and messages:
> PWD
257 "QGPL" is current library.
> CD ITSOLIB1
250 Current library changed to ITSOLIB1.
Enter an FTP subcommand.
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 152. FTP Determine and Change Server’s Current Library
Note: On other systems, the current library may be called the current directory.
If an existing remote file and member name are specified, the old member may be
replaced or a new member may be written depending on the setting of the
SUNIQUE option. When FTP is started, this option is set off. The option can be
toggled on and off by the SUNIQUE subcommand as shown in Figure 153 on
page 247.
When SUNIQUE is off, the old member is replaced. When SUNIQUE is on, a new
file member is created. The name of the new member is the same as was
specified, but the name has a sequence number that is appended to the end.
Note: The SUNIQUE option setting controls what server subcommand is used
when a PUT or MPUT client subcommand is entered. The subcommands are
sent from the client host to the server host and are run on the server. The
server subcommands are STOR and STOU:
v The STOR subcommand causes the remote file (member) to be overwritten if the
file already exists. STOR is sent to the server by the client when the
subcommands PUT of MPUT are run and SUNIQUE is set off.
246
OS/400 TCP/IP Configuration and Reference V4R4
v The STOU subcommand causes a new file (member) to be created on the
remote host if the specified one already exists. The name of the new member is
the specified one with a sequence number that is appended to it. For example, if
MBR were specified as the member name, MBR1 would be created. The name
of the new member is returned to the user. The STOU subcommand is sent to
the server when the SUNIQUE is set on.
File Transfer Protocol
Previous FTP subcommands and messages:
> SUNIQUE
Store unique is on.
> SUNIQUE
Store unique is off.
Enter an FTP subcommand.
===> SUNIQUE
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 153. FTP Setting SUNIQUE On and Off
Get Several File Members: The GET subcommand is used to copy one file
member from a remote host into a file at the local host. To do this, read authority is
required for the remote library from which the file is copied. The syntax of the GET
subcommand is as follows:
GET remotefile [localfile] [(Replace]
It is conceptually very similar to the PUT command in reverse.
The MGET subcommand is used to copy multiple file members or multiple files from
a remote host. As with the GET subcommand, read authority at the remote host is
required.
An example of the MGET command is shown in Figure 155 on page 248.
Chapter 7. File Transfer Protocol (FTP) Client
247
File Transfer Protocol
Previous FTP subcommands and messages:
> mget ITSOLIB1/qclsrc.*
200 PORT subcommand request successful.
125 List started.
250 List completed successfully.
250 Now using naming format "0".
257 "QGPL" is current library.
200 PORT subcommand request successful.
150 Retrieving member MEMB1 in file QCLSRC in library ITSOLIB1.
250 File transfer completed successfully.
13 bytes transferred in 1.297 seconds. Transfer rate 0.010 KB/sec.
200 PORT subcommand request successful.
150 Retrieving member MEMB2 in file QCLSRC in library ITSOLIB1.
250 File transfer completed successfully.
Enter an FTP subcommand.
===> mget ITSOLIB1/qclsrc.*
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 154. MGET Subcommand—Display 1
File Transfer Protocol
Previous FTP subcommands and messages:
257 "QGPL" is current library.
200 PORT subcommand request successful.
150 Retrieving member MEMB1 in file QCLSRC in library ITSOLIB1.
250 File transfer completed successfully.
13 bytes transferred in 1.297 seconds. Transfer rate 0.010 KB/sec.
200 PORT subcommand request successful.
150 Retrieving member MEMB2 in file QCLSRC in library ITSOLIB1.
250 File transfer completed successfully.
49 bytes transferred in 1.304 seconds. Transfer rate 0.038 KB/sec.
200 PORT subcommand request successful.
150 Retrieving member MEMB3 in file QCLSRC in library ITSOLIB1.
250 File transfer completed successfully.
49 bytes transferred in 1.239 seconds. Transfer rate 0.040 KB/sec.
Enter an FTP subcommand.
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 155. MGET Subcommand—Display 2
The MGET command copies all the file members (MEMB1,MEMB2,MEMB3) in file
QCLSRC in library ITSOLIB1 at the remote host. These file members are copied to
identically named members in file QCLSRC in the current library at the local host.
Figure 154 and Figure 155 show an example of an MGET display session.
The remote file name is required, but the library name may be omitted. If the library
name is not specified, the remote user’s current library is used.
248
OS/400 TCP/IP Configuration and Reference V4R4
Note that it is not possible to specify the library name at the local host on the
MGET subcommand itself. The local user’s working directory is used. This is set
automatically at sign-on time. You can use the LCD subcommand to change it for
the duration of the FTP Session. See Figure 156.
Note: The FTP Client Local Working Directory and the current library on the FTP
client system may be different libraries. The LCD subcommand does not
change the current library, but the Change Current Library (CHGCURLIB) CL
command changes both the working directory and the current library.
For example, examine the results of this series of commands:
SYSCMD CHGCURLIB XYZLIB
After this command is issued, the working directory and the current library are both
XYZLIB.
LCD
GHSLIB
After this command is issued, the working directory is changed to GHSLIB, but the
current library remains as XYZLIB.
SYSCMD CHGCURLIB ABCLIB
After this command is issued, both the working directory and the current library are
changed to ABCLIB.
Also note that the CD subcommand changes the current library on the server
system when the server is an AS/400.
File Transfer Protocol
Previous FTP subcommands and messages:
Connecting to host name SYSNAM02 at address 9.4.73.250 using port 21.
220-QTCP at SYSNAM02.
220 Connection will close if idle more than 5 minutes.
>
331 Enter password.
230 GWIL logged on.
OS/400 is the remote operating system. The TCP/IP version is "V4R2M0".
250 Now using naming format "0".
257 "QGPL" is current library.
> lcd gerrylib
Local working directory is GERRYLIB.
Enter an FTP subcommand.
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 156. LCD Subcommand
If the local member name exists and REPLACE is specified, the old member is
replaced with the new one. If REPLACE is not specified, an error message is
displayed and the MGET operation does not run for any members that already
exist.
Chapter 7. File Transfer Protocol (FTP) Client
249
If errors occur during a file transfer to the AS/400, look in the job logs of the remote
AS/400 FTP servers for more information.
Get Several Files from a Folder: Figure 157 and Figure 158 on page 251 show
the commands involved in doing an FTP MGET subcommand using NAMEFMT 1 to
transfer files between folders. In the example, the connection has already been
established between the two AS/400 systems. The example does the following:
v Changes the name format to 1 (NAMEFMT 1).
v Changes the transfer type to IMAGE with the BINARY subcommand.
v Changes the directory on the server to folder WS3FLR with the CD
subcommand.
v Changes the directory on the client to folder GWIL with the LCD subcommand.
v Uses the MGET *.* subcommand to transfer all files in the specified server
system folder (WS3FLR) to the specified client system folder (GWIL).
File Transfer Protocol
Previous FTP subcommands and messages:
> NAMEFMT 1
250 Now using naming format "1".
Server NAMEFMT is 1.
Client NAMEFMT is 1.
> BINARY
200 Representation type is IMAGE.
> CD /QDLS/WS3FLR
250 Current directory changed to /QDLS/WS3FLR.
> LCD /QDLS/GWIL
Local working directory is /QDLS/GWIL.
> MGET *.* (REPLACE
Enter an FTP subcommand.
===> MGET *.* (REPLACE
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 157. FTP MGET Subcommand using NAMEFMT 1 between Folders—Display 1
250
OS/400 TCP/IP Configuration and Reference V4R4
File Transfer Protocol
Previous FTP subcommands and messages:
200 Representation type is ASCII nonprint.
200 PORT subcommand request successful.
125 List started.
250 List completed successfully.
200 Representation type is IMAGE.
200 PORT subcommand request successful.
150 Retrieving file /QDLS/WS3FLR/DOC1.
250 File transfer completed successfully.
663 bytes transferred in 0.507 seconds. Transfer rate 1.308 KB/sec.
200 PORT subcommand request successful.
150 Retrieving file /QDLS/WS3FLR/DOC2.
250 File transfer completed successfully.
663 bytes transferred in 0.318 seconds. Transfer rate 2.083 KB/sec.
200 PORT subcommand request successful.
150 Retrieving file /QDLS/WS3FLR/DOC3.
250 File transfer completed successfully.
663 bytes transferred in 0.317 seconds. Transfer rate 2.089 KB/sec.
Enter an FTP subcommand.
===> MGET *.* (REPLACE
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 158. FTP MGET Subcommand using NAMEFMT 1 between Folders—Display 2
AS/400-to-VAX/Wollongong
This topic shows how to log on FTP to the VAX and how to use the PUT and GET
subcommands.
Process for Logging On: Figure 159 on page 252 shows the FTP logon process
to the VAX. Issue the command FTP MVAX. When prompted for the user ID, enter
TESTER. When prompted for the password, enter your password.
Chapter 7. File Transfer Protocol (FTP) Client
251
File Transfer Protocol
Previous FTP subcommands and messages:
Connecting to host name MVAX at address 9.4.6.252 using port 21.
220 FTP Service Ready
> TESTER
331 User name TESTER received, please send password
230 TESTER logged in, directory $DISK1:[TESTER]
Enter password:
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 159. VAX FTP Logon Process
This logon is very similar to the FTP logon to an AS/400. It is necessary to have a
valid user ID and password for the VAX.
Figure 160 shows the results of the QUOTE HELP subcommand (entered on the
AS/400), which lists the subcommands supported by the Wollongong server
software.
File Transfer Protocol
Previous FTP subcommands and messages:
220 FTP Service Ready
> TESTER
331 User name TESTER received, please send password
230 TESTER logged in, directory $DISK1:[TESTER]
> quote help
211-The following commands are accepted:
USER PASS ACCT MAIL MLFL PORT ABOR QUIT NOOP HELP
STRU BYTE ALLO XSEN XSEM XVRB XTER SYST REIN SITE
STOR APPE DELE RNFR RNTO LIST NLST REST CWD
XCWD
XPWD MKD
XMKD RMD
All file specifications must be in VMS** or Unix format.
211 Problems to [email protected]
Enter an FTP subcommand.
===> quote help
F3=Exit
F17=Top
F6=Print
F18=Bottom
TYPE
STAT
CDUP
MODE
RETR
PWD
F9=Retrieve
F21=CL command line
Figure 160. VAX FTP Server Subcommand Help Display
Help is not available for individual subcommands. For example, the QUOTE HELP
APPE subcommand returns a message that indicates that no information is
available.
252
OS/400 TCP/IP Configuration and Reference V4R4
To determine the functions of some of these remote commands, refer to the
appropriate Wollongong reference manuals.
PUT and GET Subcommands: The put and get operations are performed the
same way as the AS/400-to-AS/400 put and get operations, but with the following
differences.
Figure 161 and Figure 162 show examples of the put operation to the VAX and the
get operation from the VAX.
File Transfer Protocol
Previous FTP subcommands and messages:
> put GERRYLIB/SCREEN1.screen1 screen1.file
200 PORT Command OK.
125 ASCII transfer started for $DISK1:[TESTER]SCREEN1.FILE;
226 File transfer completed ok
265037 bytes transferred in 6.649 seconds. Transfer rate 39.859 KB/sec.
Enter an FTP subcommand.
===> put GERRYLIB/SCREEN1.screen1 screen1.file
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 161. Put Operation from AS/400 to VAX
File Transfer Protocol
Previous FTP subcommands and messages:
> get SCREEN1.FILE GERRYLIB/SCREEN1.SCREEN2
200 PORT Command OK.
125 ASCII transfer started for $DISK1:[TESTER]SCREEN1.FILE;1 (266586 bytes)
226 File transfer completed ok
265037 bytes transferred in 8.496 seconds. Transfer rate 31.195 KB/sec.
Enter an FTP subcommand.
===> get SCREEN1.FILE GERRYLIB/SCREEN1.SCREEN2
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 162. Get Operation to AS/400 from VAX
The specification of files on the VAX is as follows:
NODE::DEVICE:[DIRECTORY]FILENAME.TYPE;VERSION
where directory can be expressed as a subdirectory structure such as
[AAA.BBB.CCC.DDD...].
Chapter 7. File Transfer Protocol (FTP) Client
253
This is the full specification possible. Certain parts can be omitted and defaults can
be taken for them. In this example, $DISK1:[TESTER] uses the default node,
$DISK1 for the device, and TESTER for the directory. Use the CD subcommand to
change this directory.
Different versions of files can exist—files with the same name but different version
number. This occurs when multiple put operations are done to the same file name.
Note: Because the VAX has this version number inherent in the file name,
Wollongong TCP/IP does not support the STOU server subcommand. If
SUNIQUE is turned on at the AS/400, the STOU subcommand is sent when
PUT and MPUT are run, and Wollongong TCP/IP returns an error message
from the VAX.
It is possible to put a logical file from the IBM AS/400 to the VAX. This creates a
normal file on the VAX that contains data according to the view of the logical file.
AS/400-to-AIX (UNIX)
This topic shows how to log on FTP to the RISC System/6000 (RS/6000) system
and how to use the PUT and GET subcommands.
Logon Process for the RISC System/6000 System: When starting FTP, the user
has to log on to the remote host.
Figure 163 shows the logon process to the RS/6000 system.
File Transfer Protocol
Previous FTP subcommands and messages:
Connecting to host name SYSNAMRS.SYSNAM123.IBM.COM at address 9.4.73.198 using
port 21.
220 sysnamrs.sysnam123.ibm.com FTP server (Version 4.9 Thu Sep 2 20:35:07 CDT
1993) ready.
> root
331 Password required for root.
230 User root logged in.
UNIX Type: L8 Version: BSD-44
Enter an FTP subcommand.
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 163. AIX FTP Logon Process
This logon is very similar to the FTP logon on an IBM AS/400 business computing
system. It is necessary to have a valid user ID and password for the AIX.
Figure 164 on page 255 shows the results of a QUOTE HELP subcommand, which
lists the subcommands supported by the AIX server software.
254
OS/400 TCP/IP Configuration and Reference V4R4
File Transfer Protocol
Previous FTP subcommands and messages:
> Quote HELP
214- The following commands are recognized (* =>'s unimplemented).
USER
PORT
STOR
MSAM*
RNTO
NLST
MKD
CDUP
PASS
PASV
APPE
MRSQ*
ABOR
SITE
XMKD
XCUP
ACCT*
TYPE
MLFL*
MRCP*
DELE
SYST
RMD
STOU
SMNT*
STRU
MAIL*
ALLO
CWD
STAT
XRMD
SIZE
REIN
MODE
MSND*
REST
XCWD
HELP
PWD
MDTM
QUIT
RETR
MSOM*
RNFR
LIST
NOOP
XPWD
214 Direct comments to [email protected]
Enter an FTP subcommand.
===> Quote HELP
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 164. AIX FTP Server Subcommand Help Display
Additional help information may be available for each server subcommand. For
example, the following:
QUOTE HELP APPE
returns information on the parameters for the APPE subcommand.
PUT and GET Subcommands: The put and get operations are performed the
same way as the AS/400-to-AS/400 put and get operations, but with the following
differences.
The specification of files on AIX is as follows:
/DIRECTORY/FILENAME.TYPE
where directory can be expressed as a subdirectory structure such as
/AAA/BBB/CCC/DDD/...
It is possible to put a logical file from the AS/400 to AIX. This creates a normal file
on AIX that contains data according to the view of the logical file.
Figure 165 on page 256 and Figure 166 on page 256 show examples of put and get
operations between an AS/400 and AIX.
Chapter 7. File Transfer Protocol (FTP) Client
255
File Transfer Protocol
Previous FTP subcommands and messages:
Connecting to host name SYSNAMRS.SYSNAM123.IBM.COM at address 9.4.73.198 using
port 21.
220 sysnamrs.sysnam123.ibm.com FTP server (Version 4.9 Thu Sep 2 20:35:07 CDT
1993) ready.
> root
331 Password required for root.
230 User root logged in.
UNIX Type: L8 Version: BSD-44
> put ITSOLIB1/QCLSRC.memb1 /tmp/MEMB.TXT
200 PORT command successful.
150 Opening data connection for /tmp/MEMB.TXT.
226 Transfer complete.
13 bytes transferred in 0.214 seconds. Transfer rate 0.061 KB/sec.
Enter an FTP subcommand.
===> put ITSOLIB1/QCLSRC.memb1 /tmp/MEMB.TXT
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 165. AIX Put Operation
File Transfer Protocol
Previous FTP subcommands and messages:
> get /tmp/MEMB.TXT ITSOLIB1/QCLSRC.MEMB7
Member MEMB7 in file QCLSRC in library ITSOLIB1 already exists.
Specify REPLACE as a subcommand option.
> get /tmp/MEMB.TXT GERRYLIB/QCLSRC.MEMB7 (REPLACE
200 PORT command successful.
150 Opening data connection for /tmp/MEMB.TXT (11 bytes).
226 Transfer complete.
13 bytes transferred in 0.536 seconds. Transfer rate 0.024 KB/sec.
Enter an FTP subcommand.
===>
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 166. AIX Get Operation
AS/400-to-OS/2
In this topic we see how to log on FTP to a PS/2 running OS/2 and how to use the
PUT subcommand with NAMEFMT 1.
It is only meaningful to transfer certain types of files to a PS/2. In this case, we
have transferred a batch file from one of the OS/2 system folders.
Logon: When starting FTP, the user has to log on to the remote host. With OS/2,
this is no exception. The process is similar to other FTP server systems.
256
OS/400 TCP/IP Configuration and Reference V4R4
OS/2 Server Considerations: To use OS/2 as an FTP server, you need to set up
a file called TRUSERS in the ETC subdirectory or the directory specified by the
ETC environment variable. This file contains access authorization for users from
client systems. The user IDs and passwords it contains are case sensitive.
Full details are in the IBM TCP/IP V2.0 for OS/2 manual, SC31-6076. A sample
TRUSERS file is shown in Figure 167.
[C:\]type c:\tcpip\etc\trusers
user: GWIL XXXX
rd:
c:\
wr:
c:\
Figure 167. OS2 TRUSERS Sample File
The FTPD command starts the server on OS/2. As users log on to OS/2 FTP from
client systems, the OS/2 FTP server session displays messages as shown in
Figure 168.
FTPDC: spawned with socket 55
connection from 9.4.73.212 at Tue May 10 10:10:05 1994
FTP LOGIN FROM 9.4.73.212, GWIL
Figure 168. OS2 FTP Server Messages
FTP Put Process: Figure 169 on page 258 shows the PUT subcommand to OS/2
FTP and the associated subcommands that are required. The key points to note are
that the transfer must be done with binary images and that name format 1 is
required to use the QDLS file system. The section of this name following QDLS is
the folder name, in this case QIWSFL2.
Chapter 7. File Transfer Protocol (FTP) Client
257
File Transfer Protocol
Previous FTP subcommands and messages:
220 SCOTLAND FTP server (IBM OS/2 TCP/IP FTP Version 1.2) ready.
> GWIL
331 Password required for GWIL.
230 User GWIL logged in.
OS/2 operating system
> BINARY
200 Type set to I.
> NAMEFMT 1
202 SITE not necessary; you may proceed.
Client NAMEFMT is 1.
> put /QDLS/QIWSFL2/COPYWSFA.BAT C:\TEST\COPYWSFA.BAT
200 PORT command successful.
150 Opening BINARY mode data connection for C:\TEST\COPYWSFA.BAT.
226 Transfer complete.
159 bytes transferred in 0.984 seconds. Transfer rate 0.162 KB/sec.
Enter an FTP subcommand.
===> put /QDLS/QIWSFL2/COPYWSFA.BAT C:\TEST\COPYWSFA.BAT
F3=Exit
F17=Top
F6=Print
F18=Bottom
F9=Retrieve
F21=CL command line
Figure 169. OS2 FTP FTP/PUT Process
FTP Considerations (for Both Client and Server)
This section contains additional detailed information that is pertinent to both the
AS/400 FTP client and FTP server, including:
v
v
v
v
v
Data transfer methods
Transferring files that contain packed decimal data
Transferring AS/400 save files
Transferring HFS files
Transferring QDLS documents
v Transferring “root,” QOpenSys and QLANSrv files
v Transferring files using QFileSvr.400
v
v
v
v
v
v
v
Receiving text files
Transferring QSYS.LIB files
AS/400 file pre-creation
Automatic sequencing of source files
CCSID code page tagging for files on AS/400
NLS considerations
Effects of job wait time
Data Transfer Methods
The appropriate transmission attributes must be used to transfer files between two
systems to preserve the content and structure of the files. A text file contains
standard, displayable characters only. It does not include the end-of-record
characters (EBCDIC '1E' and ASCII '0D'). A binary file may contain any characters.
258
OS/400 TCP/IP Configuration and Reference V4R4
Table 22. Recommended Methods for Data Transfer
Transfer between System Types
Data type
Transfer Type 1, Mode2
AS/400 to AS/400
AS/400 to ASCII
ASCII to AS/400
ASCII to AS/400 to ASCII
AS/400 to AS/400
AS/400 to AS/400
EBCDIC, Stream
ASCII, Stream
ASCII, Stream
Binary, Stream
Binary, Stream
EBCDIC, Block
Text
Text
Text
All data
Mixed data3
Mixed data3
Notes:
1. The TYPE subcommand defines the way in which the data is to be represented.
2. The MODE subcommand specifies how the bits of data are to be transmitted.
3. See “Transferring Files that Contain Packed Decimal Data between AS/400 Systems”.
Transferring Files that Contain Packed Decimal Data between
AS/400 Systems
There is no support in FTP for converting special numeric formats like packed
decimal or zoned decimal.
The transfer of packed decimal or zoned decimal data is supported between AS/400
systems when you use either a transfer type of TYPE I (BINARY) or TYPE E
(EBCDIC) with a transmission mode of BLOCK; these transfer types send the data
as is without any conversion. The results of any other transfer type are
unpredictable.
When transferring packed or zoned data in an externally-described QSYS.LIB file,
the target file should be pre-created in the same manner as the source file. This
restriction applies to data containing any special numeric format or when keyed
access is required.
When transferring data with a transfer type of binary, the record length of the target
file must be the same as the record length of the source file.
Before packed decimal or zoned decimal data can be transferred to or from other
system architectures (such as S/390 or UNIX), you must convert the data to
printable form.
Transferring Save Files
Save files must be sent as images and, therefore, require the FTP BINARY
subcommand to be run before the GET or PUT subcommands.
When transferring a save file using name format 0, the save file on the receiving
system must be pre-created. It is recommended that files are pre-created in other
situations as well for reasons of performance and integrity.
The transfer of a save file—because it is a file format peculiar to AS/400—can only
be made usable if the sending and receiving systems are both AS/400 systems.
However, a save file could be sent to a non-AS/400 system and stored there for
backup purposes. The save file could be transferred later to the AS/400 with FTP.
Transferring save files from VM to AS/400—Example: The following example
shows how to transfer a save file from VM to an AS/400 for both NAMEFMT 0 and
1. The FTP session has already been initiated, the BINARY subcommand has been
issued, and NAMEFMT 0 has been specified.
Chapter 7. File Transfer Protocol (FTP) Client
259
First, we transfer the file P162484 SAVF310L from our VM A disk to the AS/400. VM
FTP requires that we insert a period between its file name and file type. We give it
the file name P162484 in library P162484 on the AS/400, and specify REPLACE as
it has been pre-created even if it has not been used before. You will recall that
pre-creation is mandatory with NAMEFMT 0.
We then change the NAMEFMT to 1, and repeat the file transfer using the new
name format. Once again we specify REPLACE as the file exists from the previous
step.
Notes about transferring save files:
1. If we had not pre-created the file on the AS/400 before performing the transfer
with NAMEFMT 0, the transfer would have appeared to have completed
satisfactorily. However, on inspection of the file on the AS/400, it would be seen
that a physical file (PF) has been created and not a save file (SAVF).
2. Some preprocessing may be necessary on the VM system depending on how
the save file was sent to VM:
v If FTP was used to send the save file to VM, you can just issue a GET
subcommand to transfer it back to the AS/400.
v If the Send Network File (SNDNETF) command was used to send the save
file to VM, it is first necessary to convert the file on the VM system from a
record format (RECFM) of variable to a RECFM of fixed before using FTP to
transfer it back to the AS/400. To do this, use the COPYFILE command on
VM. For example:
COPYFILE P162484 SAVF310L A = = = (RECFM F REPLACE
> GET P162484.SAVF310L P162484/P162484 (REPLACE
200 Port request OK.
150 Sending file 'P162484.SAVF310L'
250 Transfer completed successfully.
384912 bytes transferred in 3.625 seconds. Transfer rate 106.183 KB/sec
> namefmt 1
202 SITE not necessary; you may proceed
Client NAMEFMT is 1.
> GET P162484.SAVF310L/QSYS.LIB/P162484.LIB/P162484.savf (REPLACE
200 Port request OK.
150 Sending file 'P162484.SAVF310L'
250 Transfer completed successfully.
384912 bytes transferred in 3.569 seconds. Transfer rate 107.839 KB/sec
Enter an FTP subcommand.
===>
Figure 170. Transferring a save file from VM to AS/400 using NAMEFMT 0 and NAMEFMT 1
.
Transferring HFS Files
The transfer type must be set to IMAGE (using the TYPE I or BINARY
subcommand) when transferring HFS files.
The directory entry attributes of HFS files are not transferred. Default attributes are
assigned by the particular HFS file system (for example, QDLS file system) when
the file is written at the receiving AS/400 system. These defaulted attributes may
not be the same as those on the sending AS/400 system.
260
OS/400 TCP/IP Configuration and Reference V4R4
Depending on the particular file system (for example, /QDLS), attributes may affect
file processing. For example, transferred final-form text (FFTDCA) documents are
assigned the default document type PCFILE instead of FFTDCA. This prevents
editing and viewing the document content using the Work with Documents
(WRKDOC) CL command.
Transferring QDLS Documents
When a QDLS document is transferred, The QDLS directory entry attribute that
indicates the type of document is defaulted to the document type PCFILE on the
receiving AS/400 system for all document types except revisable-form text (RFT)
documents. RFT documents are defaulted to the document type RFTDCA. RFTDCA
type documents can be viewed and edited using the WRKDOC CL command.
PCFILE type documents cannot be viewed or edited using the WRKDOC CL
command.
Notes:
1. SMTP can be used to transfer final-form text (FFTDCA) documents.
2. For further information about document library services, refer to the Office
Services Concepts and Programmer’s Guide.
Transferring “root,” QOpenSys and QLANSrv Files
You must use stream mode (MODE S) and file structure (STRUCT F) when
transferring files in the “root,” QOpenSys, and QLANSrv file systems.
“root” and QOpenSys files can exist in any valid code page. Files transferred to the
QLANSrv file system are tagged with the code page defined for the network server
description corresponding to the directory containing that file.
Data conversion and CCSID assignments vary depending on the transfer TYPE
used (see “CCSID Code Page Tagging for New Files on the AS/400” on page 264).
TYPE E is not supported for the QLANSrv file system.
When appending data to an existing file, the CCSID tag of that file is not changed.
When appending data to an existing file using TYPE A, the data is converted to the
code page of that file.
Transferring Files Using QFileSvr.400
The QFileSvr.400 file system provides access to other file systems on remote
AS/400 systems. The transfer of files in the “root,” QOpenSys and QLANSrv file
systems is supported. The transfer of files in the QSYS.LIB, QDLS and QOPT file
systems is not supported.
You must use stream mode (MODE S) and file structure (STRUCT F).
For example, in Figure 171 on page 262, FILE.ABC is transferred to and from three
different files systems on system AS012 using the QFileSvr.400 file system on
system AS009.
After connecting to system AS009, the FTP client subcommands shown in
Figure 172 on page 262 perform the data transfers.
Note: The userid and password on systems AS009 and AS012 must be the same.
Chapter 7. File Transfer Protocol (FTP) Client
261
Figure 171. QFileSvr.400 File System Example
NAMEFMT 1
LCD /CLIENTDIR1
CD /QFileSvr.400/AS012/FLSDIR
PUT FILE.ABC
GET FILE.ABC /CLIENTDIR2/FILE.ABC
CD /QFileSvr.400/AS012/QOpenSys/FLSDIR
PUT FILE.ABCÍ GET FILE.ABC
/CLIENTDIR2/FILE.ABC (REPLACE
CD /QFileSvr.400/AS012/QLANSrv/NWS/LANSRV/DSK/K/FLSDIR
PUT FILE.ABC
GET FILE.ABC /CLIENTDIR2/FILE.ABC (REPLACE
SYSCMD RMVLNK '/CLIENTDIR2/FILE.ABC'
DELETE /QFileSvr.400/AS012/FLSDIR/FILE.ABC
DELETE /QFileSvr.400/AS012/QOpenSys/FLSDIR/FILE.ABC
DELETE /QFileSvr.400/AS012/QLANSrv/NWS/LANSRV/DSK/K/FLSDIR/FILE.ABC
QUIT
Figure 172. Subcommands to Transfer Files Using QFileSvr.400
Receiving Text Files on the AS/400 System to the QSYS.LIB File
System
Because the AS/400 QSYS.LIB file system internally supports a record structure,
the AS/400 FTP converts files received on the AS/400 system into a record
structure and converts files sent from the AS/400 system into the FTP file structure.
Text files received on the AS/400 system by FTP are converted into a record
structure in the following manner:
v When AS/400 FTP receives a file and that file already exists on the AS/400
system, the record length of the existing file is used.
v When AS/400 FTP creates a new file on the AS/400 system, it uses the length
(excluding trailing spaces) of the longest line or record in the file as the record
length of the file.
Text files sent from the AS/400 system by FTP are converted into a file structure by
removing the trailing blanks from each line or record and sending the truncated
record.
262
OS/400 TCP/IP Configuration and Reference V4R4
Transferring QSYS.LIB Files
Table 23 and Table 24 on page 264 summarize FTP operations in stream transfer
mode and in image transfer type for the QSYS.LIB file system. Keep the following
in mind when using these tables:
v Compatible record length and file size
When you send data to a file that already exists, the record and file size of the
receiving file must be compatible with the file being sent or a transfer error will
occur. Both the record and file size of the receiving file must be greater than or
equal to the source file record and file size. To determine if the existing file size
is compatible you need to consider the current number of records, the number of
extensions allowed, and the maximum record size allowed. You can view this
information by entering the AS/400 Display File Description (DSPFD) command.
v Automatic file creation on the AS/400 system
When receiving a file, the AS/400 system automatically creates a physical file, if
one does not already exist.
However, it is recommended that you pre-create the file on the AS/400. This is
discussed in “AS/400 File Pre-Creation” on page 264.
v When transferring data using TYPE I, the data is not converted. If the file does
not exist, it is tagged with CCSID 65535 when it is created.
Note: File pre-creation is advised when using the MGET and MPUT subcommands
to transfer files with multiple members. When a file is not pre-created, FTP
creates a file with a maximum record length equal to the longest record of
the first member processed. If the record length of any other file member is
longer, a data truncation error will occur when transferring that member.
Pre-creating a file with a record size to accommodate all members will
prevent this error.
Table 23. Stream Transfer Mode for QSYS.LIB File System
Compatible
Library
Exists
File
Exists
Member
Exists
Replace
Selected
Record
Length
File Size
Result
Yes
Yes
Yes
Yes
Yes
Yes
Data written to member
Yes
Yes
Yes
No
N/A
N/A
Transfer rejected and message sent.
Yes
Yes
No
N/A
No
Yes
File transfer completed, records truncated,
and message returned.
Yes
Yes
No
Yes
No
Yes
File transfer completed, records truncated,
and message returned.
Yes
Yes
No
N/A
Yes
Yes
Member created and data written to it
Yes
Yes
No
No
N/A
No
Transfer rejected and message sent
Yes
No
N/A
N/A
N/A
N/A
File created with record length equal to
the maximum record length of the
incoming file. Member created and data
written to member.
No
N/A
N/A
N/A
N/A
N/A
Transfer rejected and message sent. Use
the CRTLIB CL command to create a
library on the remote AS/400 system.
Chapter 7. File Transfer Protocol (FTP) Client
263
Table 24. Image Transfer Type for QSYS.LIB File System
Library
Exists
File Exists
Member
Exists
Replace
Selected
Result
Yes
Yes
Yes
Yes
Data written to member
Yes
Yes
Yes
No
Transfer rejected and message sent
Yes
Yes
No
N/A
Member created and data written to it
Yes
No
N/A
N/A
Data file created with record length equal to
512. Member created and data written to it.
No
N/A
N/A
N/A
Transfer rejected and message sent. Use the
QUOTE CRTL subcommand to create a library
on the remote AS/400 system.
AS/400 File Pre-Creation
We strongly recommend that you pre-create any files that are to be transferred to
the AS/400. This is the best method of ensuring that your data is transferred reliably
and effectively with optimal performance and integrity.
Be sure to allocate enough records to accommodate the entire file. On the AS/400
this is done in the SIZE parameter of the Create Physical File (CRTPF) command.
Ensure that the RCDLEN parameter of the Create Physical File (CRTPF) command
is adequate to accommodate the maximum record length expected.
In addition, if the user profile doing the transfer does not have *NOMAX specified
on the MAXSTG parameter, then the result of the calculation (MAXSTG - storage
allocated) must be a value at least twice the size of the file being transferred.
Note: You can pre-create files on the FTP server system using the QUOTE
subcommand. You can pre-create files on the FTP client system using the
SYSCMD subcommand.
Source Files: Sequencing, Timestamp, Level
When you use FTP to transfer data into a source physical file member, the member
is automatically resequenced. This automatic resequencing is the same as if you
specified Y to the resequencing prompt when exiting from the Start Source Entry
Utility display.
In addition, the date and time of the update operation, and the level identifier of the
member, but not the file, are updated. This happens automatically and cannot be
overridden.
In addition, the member type field is left blank, even if the transfer is from another
AS/400.
CCSID Code Page Tagging for New Files on the AS/400
When FTP creates a new file on an AS/400 system, the file is tagged with a CCSID
or the code page of that CCSID to identify the character data in that file. For “root,”
QOpenSys and QLANSrv, the file is always created new except when an append is
done. When appending data to an existing file, the tag of the file is not changed.
Table 25 on page 265 summarizes how FTP assigns these values for different file
systems and transfer types.
264
OS/400 TCP/IP Configuration and Reference V4R4
Table 25. CCSID Code Page Tagging for New AS/400 Files
Receiving File
System
QSYS.LIB
FTP Transfer Type
TYPE A (ASCII)
TYPE C (‘ccsid’)
TYPE E (EBCDIC)
TYPE I (Image/Binary)
Related default
EBCDIC CCSID of
FTP default ASCII
CCSID.
‘ccsid’ if EBCDIC
CCSID. If ccsid is
ASCII, then related
default EBCDIC
CCSID.
65535
65535
Not supported
Not assigned by FTP
If conversion table,
then 65535.
QDLS, QOPT, and
other HFS file
systems
Not supported
Not supported
“root,” QOpenSys
Code page of default
ASCII CCSID
‘ccsid’ value specified Code page of Job
Code page of default
in TYPE C ccsid#
CCSID if it is not
ASCII CCSID.
subcommand.
65535. If Job CCSID
is 65535, assign code
page of Default Job
CCSID.
QLanSrv
ASCII code page of
the network server
description for file
directory.
ASCII code page of
the network server
description for file
directory.
Not supported
ASCII code page of
the network server
description for file
directory.
Note:
The default ASCII CCSID is defined when the FTP job is started: For the client, the CCSID parameter of the
STRTCPFTP (and FTP) command. For the server, the CCSID parameter of the FTP Configuration attributes which
can be changed using the CHGFTPA command.
QFileSvr.400 file assignments depend on the file system receiving the file.
See Character Data Representation Architecture, SC41-1390 for additional information
When using TYPE C ccsid#, the data transferred must be in the ccsid# specified. No data conversion occurs when
transferring data using TYPE C transfer option.
National Language Support Considerations for FTP
Be aware of the following when using FTP in an environment with different primary
languages.
v When data is transferred using TYPE E (or EBCDIC) the data is stored as is and
therefore will be in the EBCDIC code page of the file that it came from. This can
result in the stored file being tagged with an inappropriate CCSID value when the
primary language of the two AS/400 systems is different.
For example, when data in code page 273 is sent using TYPE E to the
QSYS.LIB file system on a machine where the file does not exist, the data is
stored as is in a new file tagged with CCSID 65535. If the receiving file already
exists, then the data will be received as is and tagged with the existing file
CCSID which may not be 273.
To avoid incorrect CCSID tagging, you can use the TYPE C CCSID subcommand
(for example, TYPE C 273) to specify the CCSID of the data being transferred.
When a CCSID is specified on a transfer and the data is written to an existing
file, the data is converted to the CCSID of the existing file. If no target file exists
before the transfer, a file is created and tagged with the specified CCSID.
Chapter 7. File Transfer Protocol (FTP) Client
265
In the preceding example, if the target file does not exist, a file with a CCSID of
273 is created on the receiving system. When the target file already exists, the
data is converted from CCSID 273 to the CCSID of the target file.
v
When starting the FTP client, message TCP3C14: Unable to convert data from
CCSID &1; to CCSID &2, may be displayed. This occurs if no character
conversion is available between the EBCDIC CCSID specified by your job and
the ASCII CCSID specified for the this FTP session. You can change the ASCII
CCSID by specifying a value for the coded character set identifier parameter of
the STRTCPFTP CL command. CCSID 850, which contains the IBM Personal
Computer Latin-1 coded character set, is an ASCII CCSID for which character
conversions are available to all valid job CCSID values.
v When using FTP in ASCII mode between two EBCDIC systems, the data on the
system sending the file is converted from its stored EBCDIC code page to ASCII,
and then from ASCII to the EBCDIC code page of the receiving system. Usually
this does not present a problem because the 7-bit ASCII code page used by the
two systems is the same unless the EBCDIC characters on the sending system
are not defined in the ASCII code page. Also, some characters in the ASCII code
page may be mapped differently between the two different EBCDIC code pages.
This might occur if some of the ASCII characters are variant (the character
occupies a different hexadecimal code point in an EBCDIC code page). The
variant character may be interpreted differently on the receiving system if the
EBCDIC code page is different from that of the system sending the file.
Effects of Job Wait Time on FTP
FTP is dependent on the wait time of the job issuing an FTP request. Use option 3
(Display job run attributes, if active) from the Work with Job (WRKJOB) menu to
view the value of the job wait time. To increase the value of the job wait time, use
the Change Job (CHGJOB) command.
FTP Client Considerations
This section contains additional detailed information that is pertinent to the AS/400
FTP client including:
v
v
v
v
v
File client naming considerations
File structure and path name
Mapping tables
Server time-out
Using server subcommands
FTP Client File Naming
When using the PUT and GET subcommands without specifying both the local and
remote file name, a name is chosen for you. This name may not be the name you
expect or want.
For example, you could type the following subcommand to get your PROFILE
EXEC (file name, file type) from an IBM VM (Virtual Machine) system:
GET PROFILE.EXEC
VM sends the file to your AS/400 system and gives the file a name of PROFILE
and a member name of EXEC. However, you may prefer that the file name be
EXEC and the member name be PROFILE so that you could later add more
members to this “exec” file.
266
OS/400 TCP/IP Configuration and Reference V4R4
To ensure that the desired name is assigned, you should specifically state the name
as follows:
GET PROFILE.EXEC EXEC.PROFILE
In this example, member EXEC of remote file PROFILE is copied to your local system
as member PROFILE of local file EXEC.
File Structure and Path Name
File system structure and file path name specifications differ from one system to
another. For example, the AS/400 QSYS.LIB file system using NAMEFMT 0 has the
format:
Libname/Filename.Mbrname
and using NAMEFMT 1 has the format:
/QSYS.LIB/Libname.LIB/Filename.FILE/Mbrname.MBR
and UNIX-based systems allow specifications such as:
/etc/hosts
/usr/jack/test.c
/usr/*
Not all systems use the same keyboards or character sets. This can cause difficulty
when specifying path names. For example, some systems use the [ character and
the ] character in the path name to indicate the directory portion of a file name. If
you are using an IBM 52xx style keyboard or an IBM Personal Computer emulating
a 52xx, these characters are displayed as a ↑ character and as a .. character. You
also cannot type the [ character and the ] character on your keyboard. Instead, you
must type the < character and the > character.
Specifying Mapping Tables
For FTP client, the ASCII mapping tables are specified in the FTP command. For
FTP server this is done in the Change FTP Attributes (CHGFTPA) command. To
specify the FTP client mapping tables:
1. Enter the command FTP.
2. Press PF4. The Start TCP/IP FTP display is shown.
3. Press F10. The prompts for outgoing and incoming ASCII/EBCDIC tables are
displayed.
Chapter 7. File Transfer Protocol (FTP) Client
267
Start TCP/IP File Transfer (FTP)
Type choices, press Enter.
Remote system . . . . . . . . .
Internet address . . . . . . . .
Coded character set identifier
*DFT
1-65533, *DFT
Additional Parameters
Outgoing EBCDIC/ASCII table
Library . . . . . . . . .
Incoming ASCII/EBCDIC table
Library . . . . . . . . .
F3=Exit
F4=Prompt
F24=More keys
.
.
.
.
.
.
.
.
F5=Refresh
*CCSID
*CCSID
F12=Cancel
Name,
Name,
Name,
Name,
*CCSID, *DFT
*LIBL, *CURLIB
*CCSID, *DFT
*LIBL, *CURLIB
Bottom
F13=How to use this display
Figure 173. Specifying ASCII Mapping Tables with the *CCSID Value
Specify the CCSID (and hence the mapping tables) to be used for the FTP client.
When the *DFT value is not changed, the CCSID value 00819 (ISO 8859-1 8 bit
ASCII) is used. You may also specify a specific CCSID for both inbound and
outbound transfers. The use of CCSIDs is discussed in the International Application
Development book.
Notes:
1. Double-byte character set (DBCS) CCSID values are not permitted for the
CCSID parameter on the CHGFTPA command. The DBCS CCSID values can
be specified using the TYPE subcommand.
2. IBM includes mapping support in FTP to ensure compatibility with releases prior
to V3R1. Use of mapping tables for incoming TYPE A file transfers results in the
loss of CCSID tagging if the target file must be created. IBM strongly
recommends that you use CCSID support for normal operations.
Server Time-out Considerations
The inactivity time-out value requires some consideration. This is the time in
seconds without FTP server activity that will cause the server to close the session.
Certain remote servers allow the client to change this value. For example, the
AS/400 supports the FTP server TIME subcommand, which can be sent to the
server with the FTP client QUOTE subcommand. UNIX servers often support the
SITE IDLE subcommand.
When using local AS/400 subcommands with either the SYSCMD subcommand or
F21, there is no interaction between the client and the server. Therefore, if the
running of these local AS/400 commands exceeds the server inactivity time-out
period, the server will close the connection. If you lose your connection, you must
log on to the server again using the OPEN command (OPEN <remote system
name>) and the USER command as described in the note to “Logon to the Remote
System (Server)” on page 239.
268
OS/400 TCP/IP Configuration and Reference V4R4
Using Server Subcommands
The subcommands that are sent to the server can be created in two ways:
v By a client subcommand
v Explicitly typed in by the user (with the QUOTE subcommand)
In the first case, the user enters a client subcommand (other than QUOTE) that is
read and converted into one or more appropriate server subcommands by the client
program. In the second case, the user enters an explicit server subcommand
prefaced by the QUOTE subcommand.
QUOTE
server_subcommand_and_parameters
Whatever follows QUOTE is sent verbatim to the server; no conversion or
interpretation is done by the client program.
FTP as Batch Job
In addition to running the FTP client interactively, you can run the FTP client in an
unattended mode. Two examples of this method are included in this section: a
simple example and a complex example.
Batch FTP: A Simple Example
The following is a simple example of a batch file transfer that involves the
successful transfer of one file from a remote system.
The components are as follows:
v A CL program
v An input file of FTP commands
v An output file of FTP messages
The CL Program
************************************************************
ITSOLIB2/QCLSRC BATCHFTP:
---------------------PGM
OVRDBF FILE(INPUT) TOFILE(ITSOLIB2/QCLSRC) MBR(FTPCMDS)
OVRDBF FILE(OUTPUT) TOFILE(ITSOLIB2/QCLSRC) MBR(OUT)
FTP
RMTSYS(SYSxxx)
ENDPGM
************************************************************
The BATCHFTP program overrides the INPUT parameter to the source physical file
ITSOLIB1/QCLSRC MBR(FTPCMDS). The output is sent to MBR(OUT).
The Input Commands File
************************************************************
RLDICK/QCLSRC FTPCMDS:
--------------------ITSO ITSO
CD ITSOLIB1
SYSCMD CHGCURLIB ITSOLIB2
GET QCLSRC.BATCHFTP QCLSRC.BATCHFTP (REPLACE
QUIT
************************************************************
The FTP subcommands required are shown in the FTPCMDS file.
Chapter 7. File Transfer Protocol (FTP) Client
269
The Output Messages File
************************************************************
FTP Output Redirected to a File
FTP Input from Overridden File
Connecting to host name SYSxxx
at address x.xxx.xx.xxx using port 21.
220-QTCP at SYSxxx.sysnam123.ibm.com.
220 Connection will close if idle more than 5 minutes.
Enter login ID (itso):
> ITSO ITSO
331 Enter password.
230 ITSO logged on.
OS/400 is the remote operating system. The TCP/IP version is "V3R1M0".
250 Now using naming format "0".
257 "QGPL" is current library.
Enter an FTP subcommand.
> CD ITSOLIB1
Enter an FTP subcommand.
250 Current library changed to ITSOLIB1.
> SYSCMD CHGCURLIB ITSOLIB2
Enter an FTP subcommand.
> GET QCLSRC.BATCHFTP QCLSRC.BATCHFTP (REPLACE
200 PORT subcommand request successful.
150 Retrieving member BATCHFTP in file QCLSRC in library ITSOLIB1.
250 File transfer completed successfully.
147 bytes transferred in 0.487 seconds. Transfer rate 0.302 KB/sec.
Enter an FTP subcommand.
> QUIT
221 QUIT subcommand received.
************************************************************
The output file is shown. It is a straightforward matter to write a program to process
this file and display an error message on QSYSOPR if there are any error
messages. FTP error messages have numbers that start with a 4 or 5.
Batch FTP: A Complex Example
The following example shows how to retrieve files from several remote hosts to a
central AS/400 in batch mode:
270
OS/400 TCP/IP Configuration and Reference V4R4
Figure 174. Network Example for Batch FTP
User GWIL on AS/400 SYSNAM03 wants to:
1. Retrieve files from hosts SYSNAMRS (RS/6000) and MVAX (VAX).
2. After retrieving the file from SYSNAMRS, the file should be transferred to
SYSNAM02 (another AS/400) using FTP.
3. From there the file is to be sent using SNA to AS/400 SYSNAM14.
Create a CL Program to Start FTP
1. As we have seen in the previous example, FTP uses the display station for
command INPUT and message OUTPUT, and this needs to be overridden for
use in batch mode. We use the OVRDBF command to overwrite these files with
the ones to be used in batch:
OVRDBF FILE(INPUT) TOFILE(GERRYLIB/QCLSRC) MBR(FTPCMDS)
OVRDBF FILE(OUTPUT) TOFILE(GERRYLIB/QCLSRC) MBR(FTPLOG)
2. A host name or an internet address is a required parameter for the STRTCPFTP
command that is included in the CL program file. However, if one wants to
specify the remote systems in the input commands file instead of the CL
program file, then a dummy host name must be specified for the STRTCPFTP
command to satisfy the required syntax. This dummy name may be a fictitious
host name or a real host name. If it is a real name, then the first entry in the
input commands file must be a user ID and a password, and the second entry
must be the CLOSE subcommand. If it is not a real host name, then these
entries are not required, and the first entry should be an OPEN subcommand to
connect to the desired server system.
Chapter 7. File Transfer Protocol (FTP) Client
271
FTP RMTSYS(LOOPBACK)
FTP processes the input file and writes messages to the output file (FTPLOG).
3. After the FTP application ends, delete the overrides:
DLTOVR
FILE(INPUT OUTPUT)
The CL program for batch FTP will look like the following example on system
SYSNAM01:
Columns . . . :
1 71
Browse
GERRYLIB/QCLSRC
SEU==>
FTPBATCH
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
*************** Beginning of data *************************************
0001.00 PGM
0002.00
OVRDBF
FILE(INPUT) TOFILE(GERRYLIB/QCLSRC) +
0003.00
MBR(FTPCMDS)
0004.00
OVRDBF
FILE(OUTPUT) TOFILE(GERRYLIB/QCLSRC) +
0005.00
MBR(FTPLOG)
0006.00
FTP
RMTSYS(LOOPBACK) /* (FTP CL Program) */
0007.00
DLTOVR
FILE(INPUT OUTPUT)
0008.00 ENDPGM
****************** End of data ****************************************
F3=Exit
F5=Refresh
F16=Repeat find
F9=Retrieve
F10=Cursor
F12=Cancel
F24=More keys
(C) COPYRIGHT IBM CORP. 1981, 1994.
Figure 175. CL Program FTPBATCH for Batch FTP
Create the FTP Input File (FTCPDMS)
This file has to contain all the FTP client subcommands necessary to connect and
log on to the server, set up for and do the file transfers, close the server
connection, and end the client session. The example in Figure 176 on page 273
shows the subcommands used for transferring files to two different remote systems.
272
OS/400 TCP/IP Configuration and Reference V4R4
Columns . . . :
1 71
Browse
GERRYLIB/QCLSRC
SEU==>
FTPCMDS
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
*************** Beginning of data *************************************
0001.00 gwil ****
0002.00 close
0003.00 open sysnamrs
0004.00 user root root
0005.00 ascii
0006.00 syscmd dltf file(gerrylib/rs6)
0007.00 get /Itsotest gerrylib/rs6.rs6
0008.00 close
0009.00 open mvax
0010.00 user tester tester
0011.00 get screen1.file gerrylib/vax.vax (replace
0012.00 close
0013.00 open sysnam02
0014.00 user gwil ****
0015.00 ebcdic
0016.00 put gerrylib/rs6.rs6 gerrylib/rs6.rs6
0017.00 quote rcmd sndnetf file(gerrylib/rs6) tousrid((gwil sysnam14))
0018.00 close
0019.00 quit
****************** End of data ****************************************
F3=Exit
F5=Refresh
F9=Retrieve
F10=Cursor
F12=Cancel
F16=Repeat find
F24=More keys
Figure 176. FTP Client Subcommands (File Member FTPCMDS)
The explanation for the FTP client subcommands as shown in Figure 176 follows.
The line numbers on the display correspond to the numbers that follow.
0001
User ID and password for dummy connection within client AS/400
SYSNAM03.
0002
Close dummy connection in AS/400 SYSNAM03.
0003
Open control connection to RISC System/6000 SYSNAMRS.
0004
USER subcommand with user ID and password for SYSNAMRS.
Note: When running FTP in batch mode, the USER subcommand must
follow an OPEN subcommand. Both the logon user ID and password
parameters for the USER subcommand should be provided. This is
different when operating FTP interactively online. When FTP is run
interactively online, then the client will automatically initiate a USER
subcommand and prompt you for a logon ID. There is no automatic
USER subcommand when running FTP in batch mode.
0005
Transfer ASCII data (will be converted on AS/400 to/from EBCDIC).
0006
CL command to be run on client AS/400: delete file. Instead parameter
(REPLACE could be used with the next statement.
0007
Retrieve file from RISC System/6000 system
0008
Close control connection to RISC System/6000 SYSNAMRS.
0009
Open connection to VAX MVAX.
0010
USER subcommand with user ID and password for MVAX.
0011
Retrieve file from VAX replacing existing AS/400 file.
0012
Close control connection to VAX MVAX.
0013
Open control connection to remote AS/400 SYSNAM02.
Chapter 7. File Transfer Protocol (FTP) Client
273
0014
USER subcommand with user ID and password for SYSNAM02.
0015
Transfer EBCDIC data (as it is from AS/400 to AS/400).
0016
Send AS/400 file to AS/400 SYSNAM02 with TCP/IP.
0017
Send this file from server AS/400 SYSNAM03 to remote AS/400
SYSNAM14 through SNA network.
0018
Close control connection to AS/400 SYSNAM02.
0019
End FTP application.
Create CL Program for Submitting the FTPBATCH Job
To schedule the file transfers and run them unattended, create a CL program that
submits the FTPBATCH job. In Figure 177, the file transfers are supposed to run
the next Friday, 17:00 hour, in unattended mode.
Columns . . . :
1 71
Browse
GERRYLIB/QCLSRC
SEU==>
FTPSUBMIT
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7
*************** Beginning of data *************************************
0001.00 PGM
0002.00
SBMJOB
CMD(CALL PGM(GERRYLIB/FTPBATCH)) +
0003.00
JOB(FTPFRIDAY) OUTQ(QUSRSYS/GERRYQ)
+
0004.00
SCDDATE(*FRI) SCDTIME(170000) /* FTP for +
0005.00
Friday, 5:00 in the afternoon */
0006.00 ENDPGM
****************** End of data ****************************************
F3=Exit
F5=Refresh
F16=Repeat find
F9=Retrieve
F10=Cursor
F12=Cancel
F24=More keys
(C) COPYRIGHT IBM CORP. 1981, 1994.
Figure 177. CL Program for Submitting Batch FTP Job.
Check the FTP Output File for Errors
While running at the scheduled time, FTP creates the data in file member FTPLOG
shown in Figure 178 on page 275. The data in file member FTPLOG corresponds to
original statements found in Figure 175 on page 272 and in Figure 176 on page 273.
274
OS/400 TCP/IP Configuration and Reference V4R4
Connecting to host name LOOPBACK at address 127.0.0.1 using port 21.
220-QTCP at localhost.
220 Connection will close if idle more than 5 minutes.
Enter login ID (gwil):
>>>GWIL ****
331 Enter password.
230 GWIL logged on.
OS/400 is the remote operating system.
250 Now using naming format "0".
257 "QGPL" is current library.
Enter an FTP subcommand.
The TCP/IP version is "V4R2M0".
> CLOSE
221 QUIT subcommand received.
Enter an FTP subcommand.
> OPEN SYSNAMRS
Connecting to host name SYSNAMRS at address 9.4.73.198 using port 21.
220 sysnamrs.sysnam123.ibm.com FTP server (Version 4.9 Thu Sep 2 20:35:07 CDT
1993) ready.
Enter an FTP subcommand.
Figure 178. FTP Output (FTPLOG) After Running FTPBATCH Program (Part 1)
> USER root ****
331 Password required for root.
230 User root logged in.
UNIX Type: L8 Version: BSD-44
Enter an FTP subcommand.
> ASCII
200 Type set to A; form set to N.
Enter an FTP subcommand.
> SYSCMD DLTF FILE(GERRYLIB/RS6)
Enter an FTP subcommand.
> GET /Itsotest GERRYLIB/RS6/RS7
200 PORT command successful.
150 Opening data connection for /Itsotest (467 bytes).
226 Transfer complete.
467 bytes transferred in 2.845 seconds. Transfer rate 0.167 KB/sec.
Enter an FTP subcommand.
Figure 179. FTP Output (FTPLOG) after Running FTPBATCH Program (Part 2)
Chapter 7. File Transfer Protocol (FTP) Client
275
> CLOSE
221 Goodbye.
Enter an FTP subcommand.
> OPEN MVAX
Connecting to host system mvax at address 9.4.6.252 using port 21.
220 FTP Service Ready
Enter an FTP subcommand.
> USER TESTER ******
331 User name TESTER received, please send password
230 TESTER logged in, directory $DISK1:|TESTER¦
Enter an FTP subcommand.
GET SCREEN1.FILE GERRYLIB/VAX.VAX (REPLACE
200 PORT Command OK.
125 ASCII transfer started for $DISK1:|TESTER¦SCREEN1.FILE;1(266586 bytes)
226 File transfer completed ok.
265037 bytes transferred in 8.635 seconds. Transfer rate 30.694 KB/sec.
Enter an FTP subcommand.
> CLOSE
221 Goodbye.
Enter an FTP subcommand.
OPEN SYSNAM02
Connecting to host system SYSNAM02 at address 9.4.73.250 using port 21.
220-QTCP at SYSNAM02.sysnam123.ibm.com.
220 Connection will close if idle more than 5 minutes.
Enter an FTP subcommand.
Figure 180. FTP Output (FTPLOG) after Running FTPBATCH Program (Part 3)
> USER GWIL ****
331 Enter password.
230 GWIL logged on.
OS/400 is the remote operating system.
250 Now using naming format "0".
257 "QGPL" is current library.
Enter an FTP subcommand.
The TCP/IP version is "V4R2M0".
> EBCDIC
200 Representation type is EBCDIC nonprint.
Enter an FTP subcommand.
> PUT GERRYLIB/RS6.RS6 GERRYLIB/RS6.RS6
200 PORT subcommand request successful.
150 Sending file to member RS6 in file RS6 in library GERRYLIB.
250 File transfer completed successfully.
467 bytes transferred in 0.148 seconds. Transfer rate 3.146 KB/sec.
Enter an FTP subcommand.
> RCMD SNDNETF FILE(GERRYLIB/RS6) TOUSRID((GERRYLIB SYSNAM14))
250 Command SNDNETF FILE(GERRYLIB/RS6) TOUSRID((GWIL SYSNAM14))
successful.
Enter an FTP subcommand.
Figure 181. FTP Output (FTPLOG) after Running FTPBATCH Program (Part 4)
276
OS/400 TCP/IP Configuration and Reference V4R4
> CLOSE
221 QUIT subcommand received.
Enter an FTP subcommand.
> QUIT
(This ends the FTP application)
Figure 182. FTP Output (FTPLOG) after Running FTPBATCH Program (Part 5)
|
|
|
|
You should check this output for errors that might have occurred during FTP
processing. You can either check visually or run a program that tests for error reply
codes. Three-digit FTP error reply codes start with 4 or 5. Be careful to avoid
messages such as ’467 bytes transferred...’.
Sample Procedure: A sample REXX procedure and a sample physical file
member are shipped as part of the TCP/IP product. File QATMPINC in library
QTCP includes the following two members:
v BATCHFTP that contains REXX source code to specify the input and output
batch files, and start FTP.
v BFTPFILE that contains the subcommands and data required for logon and
running FTP.
Exit Points for FTP
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
Chapter 7. File Transfer Protocol (FTP) Client
277
278
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 8. File Transfer Protocol (FTP) Server
The File Transfer Protocol (FTP) server function allows you to send or receive
copies of files to or from server systems across a TCP/IP network. In addition, the
FTP server provides functions for renaming, adding, and deleting files.
You can access FTP server functions via a command line interface or the
Operations Navigator (graphical user interface). Not all FTP functions are available
on both interfaces.
This chapter discusses how you start and stop the FTP server via the command
line interface and through Operations Navigator. This chapter does not document
any of the other Operations Navigator functions. This chapter deals primarily with
command line interface functions. See the on-line Help for Operations Navigator for
information about using the Operations Navigator for FTP functions.
Also, note that even though some of the functionality of the command line interface
and the Operations Navigator is the same, the actual menu commands and
parameters are not necessarily the same.
More File Transfer Protocol (FTP) Server documentation material is covered in the
AS/400e Information Center under the TCP/IP topic. For more information see
“TCP/IP Topics in the Information Center” on page xv.
FTP Server-What It Does and Does Not Support
The following sections provide a brief description of the functions of the FTP server,
and some details of its limitations.
Functions Supported by AS/400 FTP Server
v Exit points to enable “Anonymous” FTP and FTP security controls (see “File
Transfer Protocol (FTP) Exit Points” on page 553).
v Transferring files in the “root,” QOpenSys, QLANSrv file, and QFileSvr.400
systems.
v Transferring folders and documents in the document library services (QDLS) file
system.
v Coded character set identifier (CCSID) support
v Creating and deleting libraries, files, and members using the AS/400 FTP server
subcommands.
v Creating and deleting folders using the AS/400 FTP server subcommands.
v Sending or receiving save files and members in physical files, logical files,
Distributed Data Management (DDM) files, and source physical files.
v Sending text files in EBCDIC format or converting them to ASCII (the default
format).
v Transferring binary files as is.
v Using the current library. The TCP/IP FTP server uses the current library
specified in the AS/400 user profile. If no library is specified in the user profile, or
if an error occurs, the QGPL library is used as the current library.
© Copyright IBM Corp. 1997, 1999
279
v Using the home directory. The TCP/IP FTP server uses the home directory
specified in the AS/400 user profile. If the specified directory cannot be accessed,
the root directory (/) is used as the home directory.
v Selecting the initial working directory. The initial working directory may be set to
either the user’s current library or the user’s home directory.
Functions Not Supported by FTP Server
v Logging on the AS/400 FTP server is not the same as signing on the AS/400
system. The initial program to call (INLPGM) parameter does not run.
v Transferring selected records within files.
v Selection or omission of fields within records when transferring files. You must
transfer an entire physical or logical record.
Configuring FTP Servers
The TCP/IP Connectivity Utilities for AS/400 licensed program comes with TCP/IP
FTP servers configured. You can configure more servers with the Change FTP
Attributes (CHGFTPA) command. The display is shown in Figure 183 on page 281.
The CHGFTPA command updates a database file called
QUSRSYS/QATMFTP.CONFIG, which is used by the FTP servers.
Starting FTP Servers
To use the command line interface to start the FTP server(s):
|
|
|
|
|
|
The server job for a TCP/IP application must be started in the QSYSWRK
subsystem. If no FTP server jobs are running, the Start TCP/IP Server
(STRTCPSVR) command starts the number of FTP servers that have been
configured and specified to start automatically in the FTP server configuration. If
you have not configured any FTP servers, the FTP servers that have been shipped
with the TCP/IP Utilities licensed program will be started.
|
|
|
|
Typically, the STRTCP command will start the FTP server job. The only time that is
not true is if you specify *NO for the AUTOSTART parameter in the FTP server
configuration. In this case, the FTP server job is started when STRTCPSVR *FTP is
issued. The STRTCPSVR command overrides the AUTOSTART parameter.
To manually start further FTP server jobs, use the command STRTCPSVR *FTP to
start one additional FTP server.
FTP server jobs remain active for use by subsequent users after a client session
has been ended.
Note: The FTP server cannot start if character conversion is not available between
the system’s default job CCSID and the ASCII CCSID specified by the FTP
attributes. In this case, message TCP3C14, Unable to convert data from
CCSID &1; to CCSID &2,; appears in the FTP server job log. If this situation
occurs, you must specify a different ASCII CCSID for which character
conversion is available by using the CHGFTPA command. CCSID 850, which
contains the IBM PC Latin-1 coded character set, is an ASCII CCSID for
which character conversions are available to all valid job CCSID values.
280
OS/400 TCP/IP Configuration and Reference V4R4
Available FTP Servers
|
|
|
|
|
|
|
|
The minimum number of available FTP servers to be kept ready for future client
connections is the number of initial servers specified in the NBRSVR parameter in
the FTP server configuration. When a client connects to an AS/400 FTP server, the
server examines the number of active servers that are not connected to a client and
the value specified in the NBRSVR parameter. If the NBRSVR parameter is greater
than the number of available servers, additional servers are started so that the two
numbers are equal. If the NBRSVR parameter is less than the number of available
servers, no action is taken.
For example, if there are five FTP client sessions established at the same time and
the NBRSVR parameter is set at 10, there will be 15 FTP servers running. The 15
servers include five servers for the five active client sessions and ten available
servers. The number of available servers can be larger than the NBRSVR
parameter. In this same example, if the five clients end their sessions and no other
sessions are started, there will be 15 available servers.
Changes to the NBRSVR parameter take effect at the time of the next client
connection, when the above process is activated.
Change FTP Attributes (CHGFTPA)
Type choices, press Enter.
Autostart servers . . . . . .
Number of initial servers . .
Inactivity timeout . . . . . .
Coded character set identifier
Server mapping tables:
Outgoing EBCDIC/ASCII table
Library . . . . . . . . .
. *YES
. 3
. 300
00819
*YES, *NO, *SAME
1-20, *SAME, *DFT
0-2147483647, *SAME, *DFT
1-65533, *SAME, *DFT
. *CCSID
.
Name, *SAME, *CCSID, *DFT
Name, *LIBL, *CURLIB
Incoming ASCII/EBCDIC table
Library . . . . . . . . .
Initial name format . . . . .
Initial directory . . . . . .
Initial list format . . . . .
New file CCSID . . . . . . . .
.
.
.
.
.
.
Name, *SAME, *CCSID, *DFT
Name, *LIBL, *CURLIB
*LIB, *SAME, *PATH
*CURLIB, *SAME, *HOMEDIR
*DFT, *SAME, *UNIX
*1-65533, *SAME, *CALC
F3=Exit
F4=Prompt
F24=More keys
F5=Refresh
*CCSID
*LIB
*CURLIB
*DFT
*CALC
F12=Cancel
Bottom
F13=How to use this display
Figure 183. Change FTP Attributes (CHGFTPA) Display
Ending FTP Servers
To end all AS/400 FTP servers, type the following AS/400CL command:
ENDTCPSVR *FTP
It is not possible, using the ENDTCPSVR command, to selectively end only some
servers of a given type. To do this, you need to use the End Job (ENDJOB)
command against each server job.
Chapter 8. File Transfer Protocol (FTP) Server
281
Ending and Restarting FTP Server Jobs
To use the command line interface to end the FTP server:
1. Enter the following command to verify that FTP servers are currently running:
WRKACTJOB SBS(QSYSWRK)
If no jobs are listed with a name of the form QTFTPxxxxx (where xxxxx is a
5-digit number), no further action is required. (Make sure to page down to the
bottom of the list, as the jobs may not be listed on the first page of the display.)
If one or more jobs are listed with this name, continue with the steps that follow.
2. Enter the following command to verify that no users are logged on to the FTP
server:
NETSTAT OPTION(*CNN)
Check that no connections are listed with a local port of ftp-con and a state of
Established. If FTP connections are established, wait a few minutes and check
again. (If you perform the following steps when there are established FTP
connections, users on your system may lose data.) Again, make sure to page
down to the bottom of the list.
3. Stop and restart the FTP servers by entering the following commands:
ENDTCPSVR SERVER(*FTP)
STRTCPSVR SERVER(*FTP)
To use the Operations Navigator to stop the FTP server:
v Follow the path Network\Servers\TCP/IP
v Right-mouse click the FTP server
v Select Stop
FTP Server Subcommands
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
FTP Server Considerations
This section contains additional detailed information about the FTP server,
including:
v FTP from non-AS/400 to AS/400
v FTP server jobs and job names
v Creating FTP server spooled job logs
v FTP server NAMEFMT
FTP Server Considerations for Non-AS/400 Clients
This topic covers the considerations for non-AS/400 clients. Two specific systems
have been evaluated and the following points apply in both systems.
v VAX/Wollongong
v AIX (UNIX)
282
OS/400 TCP/IP Configuration and Reference V4R4
|
|
|
When using FTP from or to the AS/400, both VAX and AIX users should be aware
of the AS/400 library/file.member structure and naming conventions when using
naming format 0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Points to Note:
1. When starting FTP from the VAX or AIX, the user is prompted for a name. This
is actually the user ID for the AS/400.
2. The CD subcommand is used to change the current library on the AS/400. (This
is the equivalent to the AS/400 CHGCURLIB command.)
3. The DIR subcommand is used to display the contents of the current library.
This command may take some time to run if the current library contains a large
number of objects.
4. Some of the error messages returned may not be very clear. For example, if
you try to delete the current library, the message returned is “Unable to delete
library.”
5. If a file with a name but no type is put to the AS/400, a file and member of that
name will be created or replaced. For example:
|
|
|
will create or replace a file named TEST with a member named TEST in the
current library.
|
|
|
|
PUT TEST
6. The AIX operating system is case sensitive.
FTP Server NAMEFMT
When an FTP server session is started, NAMEFMT is set to the value specified by
the INLNAMFMT setting in the FTP configuration. You can change the NAMEFMT
value by using the SITE subcommand.
The server automatically switches from the default of NAMEFMT 0 to NAMEFMT 1
when the ‘first’ file or pathname parameter received in a subcommand either:
v Starts with a slash (/) or a tilde () character
or
v Is blank (except for the LIST and NLST subcommands).
Any subsequent server subcommands with a file or path name parameter will not
affect the NAMEFMT value. In addition to changing the NAMEFMT, the server reply
for the subcommand will include a statement saying that the NAMEFMT value has
been changed.
For example, the server NAMEFMT value will be changed to “1” if the first server
subcommand with a file or path name is:
CWD
/DIR1/DIR2A
The server reply will be:
250-NAMEFMT set to 1.
250 Current directory changed to /DIR1/DIR2A.
Note: This capability enables the typical Web browser, which requires NAMEFMT
1, to interact with AS/400 FTP servers without issuing a SITE NAMEFMT 1
subcommand.
Chapter 8. File Transfer Protocol (FTP) Server
283
Exit Points for FTP Server Security and Anonymous FTP
This material is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
284
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 9. Post Office Protocol (POP) Mail Server
Note:
You can access POP server functions via a command line interface or the
Operations Navigator (graphical user interface). Not all POP functions are
available on both interfaces.
This chapter discusses how you start and stop the POP server via the
command line interface and through Operations Navigator. This chapter does
not document any of the other Operations Navigator functions. This chapter
deals primarily with command line interface functions. See the online Help for
Operations Navigator for information about using the Operations Navigator for
POP functions.
Also, note that even though some of the functionality of the command line
interface and the Operations Navigator is the same, the actual menu
commands and parameters are not necessarily the same.
The Post Office Protocol (POP) server is the AS/400 implementation of the Post
Office Protocol Version 3 mail interface. This server allows AS/400 systems to act
as POP servers for any clients that support the POP mail interface. This includes
clients running on Windows, OS/2, AIX and Macintosh.
Multipurpose Internet Mail Extensions (MIME) is the Internet standard for
sending mail with headers that describe the contents of the mail messages to the
receiving client. These messages can be video, image, audio, or binary files, or text
messages. The POP server allows users to exchange mail (including MIME mail)
between OfficeVision/400 and POP clients by using the AnyMail/400 mail server
framework. This support is provided by user exits or snap-ins that are provided by
the POP server to run in the AnyMail/400 mail server framework.
POP mail clients use verbs to communicate with the POP server. Verbs supported
by the AS/400 POP server are described in “Supported POP Verbs” on page 296.
The POP Version 3 mail interface is defined in RFC 1725. RFC stands for Request
for Comments. RFCs are the vehicles that are used to define evolving Internet
standards.
How the POP Server Works
The POP server is a simple store-and-forward mail system. It provides electronic
mailboxes on AS/400 from which clients can retrieve mail. It uses the AnyMail/400
mail server framework and the system distribution directory to process and
distribute E-mail. It uses simple mail transfer protocol (SMTP) to forward mail.
The system distribution directory is an IBM-supplied function that allows you to
create entries for user IDs or system addresses specific to your network.
Figure 184 on page 286 provides an overview of the standard POP server
components. If you are using AS/400 Client Access with a MAPI mail client instead
of a standard POP client, the processing is slightly different. Figure 185 on
page 287
© Copyright IBM Corp. 1997, 1999
285
page 287 provides an overview of the Client Access-based POP server
components.
Figure 184. Overview of POP Server Components. Shows “standard” POP clients such as
Netscape** and Eudora**.
All incoming mail from SMTP for local users (users with mail accounts on this
AS/400) is processed by the AnyMail/400 framework. The mail server framework is
a mail distribution structure that allows the distribution of E-mail. The mail server
framework calls exit programs or snap-ins to handle specific mail types.
For the client/server interface to work, SMTP must be running for the following
reasons:
v Both Internet mail and mail that is sent to clients on the same system go through
SMTP.
v Any mail that goes through the mail server framework needs to go through SMTP
(through a snap-in) to be delivered to external users.
The POP server serves as a temporary holding area for mail until it is retrieved by
the mail client — it does not provide a “mail store” function. When the mail client
connects to the server, it queries the contents of its mailbox to see if there is any
mail to retrieve. If there is, it retrieves the mail one message at a time. Once a
message has been retrieved, the client normally instructs the server to mark that
message for deletion when the client session is complete. The client retrieves all of
286
OS/400 TCP/IP Configuration and Reference V4R4
the messages in the mailbox and then issues a command (in the form of a QUIT
verb) that tells the server to delete all of the messages that are marked for deletion
and to disconnect from the client.
The POP Server and Client Access-based Mail
The AS/400 POP server can act as a messaging and address book server for
MAPI-based Client Access for Windows 95/NT clients. With this support, all mail is
sent to the POP server on the AS/400 by way of extensions to the standard POP
client/server interface. No SMTP connection on the client is required. This is shown
in Figure 185.
Figure 185. Overview of POP Server Components (with MAPI Service Providers). Shows
additional function provided with the Client Access for Windows 95/NT product.
Client Access-based clients can send and receive mail through the POP server with
any of these address types:
v INTERNET (the standard Internet format, sometimes referred to as an SMTP
address)
v OFFICEVISION (the SNADS address itself, not an SMTP address that is
converted to SNADS. This type also includes AS/400 distribution lists.)
v AS400FAX (the dialing sequence as defined by the Facsimile Support for OS/400
LPP).
Chapter 9. Post Office Protocol (POP) Mail Server
287
This support also includes an address book function that provides high-performance
client/server access to an address book that is periodically refreshed from the
AS/400 system distribution directory.
Finally, the following connection types are supported between the Client
Access-based client and the POP server:
v TCP/IP protocol
v IPX/SPX protocol
v SNA protocol.
When you connect to the POP server using Client Access, you gain the benefit of
secure logon - the password encryption that Client Access provides.
See “AS/400 Address Book” on page 311 for more information on the supported
address types, and for information about how data is mapped from the system
distribution directory to the address book cache. See “Configuring POP for Client
Access-Based Mail Users” on page 294 for information on how to configure this
support.
How to Get the POP Server Up and Running
To get the POP server up and running, you must do the following:
1. Install TCP/IP Connectivity Utilities for AS/400.
v Use option 12 of the Configure TCP/IP (CFGTCP) command to display the
local domain and host names used to identify the local system.
If local domain and host names are present, record them for later use. If
they are not present, fill this information in, and record it. You will need this
information when you set up clients.
2. Use the Work with Active Jobs (WRKACTJOB) command to determine if the
QSNADS subsystem is running. If not, use the Start Subsystem (STRSBS)
command to start the QSNADS subsystem:
STRSBS QSNADS
3. With QSNADS running, use the WRKACTJOB command to determine if the
mail server framework is running (look in subsystem QSYSWRK for jobs
named QMSF). If the framework is not running, use the Start Mail Server
Framework (STRMSF) command to start it.
4. If you are using a Client Access connection, install the following products on
your system:
v SS1 product, Host Servers
v XA1 product, Client Access/400 Base Family
v XD1 product, Client Access/400 for Windows 95/NT
5. If you are using Client Access for Windows 95/NT to connect to the POP
server with the IPX protocol, define and start IPX. See Internetwork Packet
Exchange (IPX) Support for information on how to do this.
6. If you are using Client Access connections (of any type), run the Start Host
Server (STRHOSTSVR) command, as follows:
STRHOSTSVR *ALL
288
OS/400 TCP/IP Configuration and Reference V4R4
For more information on setting up your Client Access client, see the online
User’s Guide, the online information for Windows 95, and the information
shipped with Lotus** :Mail**.
7. If SMTP is not set up, you must do the following:
v Get SMTP up and running with entries in the System Distribution Directory
for local users and users of other systems in the network that you might
want to send E-mail to.
8. Set up some system distribution directory entries:
You need a user profile and a directory entry for each local POP user.
The Mail service level must be set to 2 (System message store) and the
Preferred address should usually be set to 3 (SMTP name). See “Adding POP
Mail Users to the System Distribution Directory” for directions on how to do
this. (If you are using SNADS and not TCP/IP, you can set the Preferred
address to 1 (User ID/address).)
For security reasons, you may want to set up these user profiles as *SIGNOFF
profiles, since POP mail users do not need to actually sign on to the AS/400
system.
Note: If you use *SIGNOFF profiles, the system administrator will need to
manage password expiration, since *SIGNOFF users will not know
when their passwords expire.
9. Set up your clients.
10. Know what kind of client you are connecting. Make sure that the right
connection type is configured for the server (using the CHGPOPA command).
11. Start the POP Server (see “Starting the POP Server” on page 296).
The remainder of this chapter provides more detailed information about setup,
configuration, exit programs, and ASCII/EBCDIC conversion.
Setting Up Your System and Users
The system distribution directory (SDD) contains entries for users who are
authorized to send and receive messages, data, or objects on the network. These
users are on both the local system and remote systems. Entries in the SDD are for
individual users or groups of users. Entries determine where mail is delivered
(allowing users to send and receive mail from OfficeVision/400, SNADS, and SMTP
mail systems). For more detailed information on the SDD, see the SNA Distribution
Services book.
Adding POP Mail Users to the System Distribution Directory
Before you can add users to the system distribution directory (SDD), they must
have a user profile. Once they have a user profile, you can use the Work with
Directory Entries (WRKDIRE) command to add them to the directory.
1. Type WRKDIRE to display the Work with Directory Entries menu.
Chapter 9. Post Office Protocol (POP) Mail Server
289
Work with Directory Entries
Type options, press Enter.
1=Add
2=Change
4=Remove
5=Display details
6=Print details
7=Rename
8=Assign different ID to description
9=Add another description
Opt
1
User ID
_______
*ANY
*ANY
BILANSKY
CHUBALA
COOKE
CRAIG
CT1
DAVEHALL
DOWNER
FINGARJM
FINGARJM
FINGARJM
F3=Exit
F12=Cancel
Address
________
SYSNAM6
SYSNAM123
SYSNAM123
SYSNAM456
SYSNAM456
SYSNAM456
MUTT
SYSNAM456
SYSNAM456
SYSNAM456
SYSNAM07
SYSNAM09
Description
SMTP to sysnam6
sna to rochester
Mark Bilansky
Chubala Rao
Tom Cooke
craig fowler
dec station 3100 ct1
dave hall
Rob downer
Jeff Fingar CT
JEFF FINGAR
Fingar for CT
More...
F5=Refresh
F9=Work with nicknames
F11=Sort by description
F13=Work with departments
F17=Position to
F24=More keys
Figure 186. Work with Directory Entries (WRKDIRE) — Display 1
2. Type option 1 (Add) on the first line of the display.
3. Press the Enter key to see the Add Directory Entry display.
Add Directory Entry
Type choices, press Enter.
User ID/Address .
Description . . .
System name/Group
User profile . .
Network user ID .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
USER1 SYS1
Fred
SYS1 ________
F4 for list
USER1.
F4 for list
___________________________________________________
Name:
Last . .
First . .
Middle .
Preferred
Full . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
____________________________________________
______________________
______________________
______________________
___________________________________________________
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Figure 187. Add Directory Entry (ADDDIRE) — Display 1
4. Type the directory entry information. For POP mail users, pay particular
attention to these fields (which are further down on the entry display):
v Mail service level. Set this to 2 (System message store)
v Preferred address. Set this to 3 (SMTP name). If you are using SNADS and
not TCP/IP, set the Preferred address to 1 (User ID/Address).
290
OS/400 TCP/IP Configuration and Reference V4R4
Type choices, press Enter
Mail service level
. .
2
For choice 3=Other mail service:
Field name . . . . __________
1=User index
2=System message store
3=Other mail service
______
Preferred address: . . . 3
Address type . . . . . ________
For choice 4=Other preferred address:
Field name . . . . __________ ______
F3=Exit
F4=Prompt
F5=Refresh
F19=Add name for SMTP
F12=Cancel
F4 for list
1=User ID/Address
2=O/R Name
3=SMTP Name
4=Other preferred address
F4 for list
F4 for list
More...
F18=Display location details
Figure 188. Add Directory Entry (ADDDIRE) — Display 2
5. If you specified 3 (SMTP) for Preferred address, follow the remaining steps for
SMTP. If you specified 1 (User ID/Address) for Preferred address:, skip to the
end of this section.
6. Press F19 (Add name for SMTP). Fill in the SMTP user ID and SMTP domain
fields. Press Enter.
Add Name for SMTP
Type choices, press Enter.
User ID . . . . . . . . : USER1
Address . . . . . . . . : SYS1
SMTP user ID . . . . . . : USER1___________
SMTP domain . . . . . . . : SYS1.MyTown.MyCompany.COM________________________
_________________________________________________________________________________
_________________________________________________________________________________
_____________________________________________
SMTP route . . . . . . . : __________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_____________________________________________
Figure 189. Add Name for SMTP Display
Important!:
IBM recommends that you use the same name for your user profile
and your SMTP user ID. IBM also recommends that this name be
the same as your ID in the system distribution directory.
The SMTP domain field must be in the format:
hostname.domain
Chapter 9. Post Office Protocol (POP) Mail Server
291
where hostname is the AS/400 local host name and domain is the local domain
name, both from the TCP/IP configuration. In the example Figure 189 on
page 291, the host name is SYS1 and the TCP/IP domain name is
MYTOWN.MYCOMPANY.COM.
7. When you see the message SMTP Table Updates Pending - Press Enter to
Update, press Enter. This creates the directory entry and adds the TCP/IP
address to the system alias table (which the POP server needs).
Changes to the system distribution directory take effect immediately; you do not
need to restart either SMTP or the POP server.
There is a delay between the time when entries are changed in the system
distribution directory and when they are reflected in the address book provided with
Client Access for Windows 95/NT clients. This delay (or refresh interval) is set with
the ADRBOOK parameter of the CHGPOPA command. See “Configuring POP for
Client Access-Based Mail Users” on page 294.
POP Mailboxes
Once there is an entry in the system distribution directory for a POP mail user, the
mailbox for that user is created automatically either the first time the client logs on
successfully or when mail is received for the client.
The POP server uses a directory structure for mailboxes. These mailboxes are used
as transient locations for storing the mail. The directory structure is set up by the
system when the TCP/IP Connectivity Utilities for AS/400 LP is installed (at the
same time the POP server is installed).
Setting Up Standard POP Mail Clients
Although each client product is different, you will normally need to provide the
following information to set up standard (non-Client Access) POP mail clients:
v User ID and host name. This is typically in the form:
<user ID>@<Host name>
For example, user ID and host name might be:
[email protected]
In this example, the AS/400 host name is sysnam and the domain is
mytown.company.com. jsmith is the AS/400 profile name for the user on the
AS/400 system.
This is the user’s E-mail address for receiving mail and should match the SMTP
address that is entered for the system distribution directory SMTP address.
On some clients, the host IP address may have to be entered several times;
once to specify the POP server’s host for receiving mail, once to specify SMTP’s
host for sending mail, and once (sometimes more) as a way to identify the
sender of mail to the recipients.
v POP user or account name. For the AS/400 POP mail server, this is the same
as the AS/400 user profile name.
v The password to use. This must be the AS/400 user profile password.
292
OS/400 TCP/IP Configuration and Reference V4R4
Setting Up Client Access-Based Mail Clients
Set up for Client Access-based clients is minimal. When you install Client Access,
click on the mail client and follow the directions for configuration. You will need to
provide an AS/400 system name for your mail server.
Configuring the POP Server
The Change POP Attributes (CHGPOPA) command allows you to configure the
POP server. You can get to the CHGPOPA command prompt display in either of the
following ways:
v Enter the Configure TCP/IP command (CFGTCP) and select option 20 (Configure
TCP/IP applications) and then select Option 16, Change POP server attributes
v Enter the Configure TCP/IP Applications (CFGTCPAPP) command from the
command line, and select Option 16, Change POP server attributes
v Enter the Change POP Mail Server Attributes (CHGPOPA) command directly
from the command line.
The following screen is displayed:
Change POP Server Attributes (CHGPOPA)
Type choices, press Enter.
Autostart servers. . . . . . . .
Number of initial servers. . . .
Inactivity time out. . . . . . .
Message split size . . . . . . .
MIME CCSID:
Coded character set identifier
When to use . . . . . . . . .
Allow standard POP connection .
Host server connection
.
+ for more values
Address book:
Enabled: . . . . . . . . . . .
Refresh interval . . . . . . .
F3=Exit
F4=Prompt
F24=More keys
F5=Refresh
*YES
3
600
32
*YES, *NO, *SAME
1-20, *SAME, *DFT
10-65535 seconds, *SAME, *DFT
32-2048 kilobytes, *SAME, *DFT
00819
*SAME,
*BESTFIT*SAME,
*YES
*SAME,
*NONE
*SAME,
________
*NO
______
*DFT, 00819, 00912...
*BESTFIT, *ALWAYS
*YES, *NO
*NONE, *ALL, *IP...
*SAME, *NO, *YES
1-65535 minutes, *NONE
F12=Cancel
F13=How to use this display
If you are going to use standard POP (TCP/IP) connections, specify *YES for the
Allow standard POP connection (ALWSTDCNN) parameter. This is the normal
socket interface used by standard POP clients, and is the default. Specify *NO if
you will only be using the Client Access for Windows 95/NT clients.
To activate changes made in the configuration of the POP server, you must end and
restart the following:
v The POP server
v The mail server framework
Chapter 9. Post Office Protocol (POP) Mail Server
293
For more information on starting and stopping the mail server framework using the
Start Mail Server Framework (STRMSF) and End Mail Server Framework
(ENDMSF) commands, see AnyMail/400 Mail Server Framework Support.
Configuring POP for Client Access-Based Mail Users
There are two parameters on the CHGPOPA command that configure the POP
server for MAPI-based clients:
HOSTSVRCNN
This parameter identifies the types of connection protocols to be supported for
Client Access for Windows 95/NT clients connecting to the POP server. Use this
parameter if you are using Client Access to connect to the POP server. You can
specify any combination of the following protocols:
*IP
Support TCP/IP protocol for Client Access for OS/400 clients.
*IPX
Support IPX/SPX protocol for Client Access for OS/400 clients.
*SNA
Support SNA protocol for AS/400 Client Access clients. If you are using the
SNA protocol, see “Setting the Number of SNA Servers” on page 295.
You can also specify *ALL (for all three protocols) or *NONE. The default is
*NONE.
ADRBOOK
This parameter enables address book support for the client-based IBM
AS/400 MAPI address book service provider, which is part of Client Access
for Windows 95/NT. There are two elements: Enable Address Book
Support and Refresh interval.
Set Enable Address Book Support to *YES. If you set this parameter
element to *NO, clients will still be able to use POP server mail support, but
they will not be able to access address book data.
When you set ADRBOOK to *YES, the POP server builds and maintains an
address book cache. This is described in “AS/400 Address Book” on
page 311.
For performance reasons, do not enable address book support unless you
plan to use it.
The Refresh interval parameter element specifies, in minutes, how often
you want the POP server to check to see if the address book cache is
current, and if not, to refresh it from the AS/400 system distribution
directory. If you want the POP address book to be refreshed only when the
POP server starts or is restarted, specify *NONE for this parameter
element. The default is 60 minutes.
The refresh interval is a trade-off between timely availability of changes to
the system distribution directory, and processor utilization. You may want to
refresh large address books less frequently because of the processor time
required to do a refresh. Small address books can be refreshed more
294
OS/400 TCP/IP Configuration and Reference V4R4
frequently without greatly affecting processor utilization. The interval you
choose should be based on your own situation, and the size of your
address books.
Regardless of what the refresh interval is set to, if there have been no
changes to the system distribution directory since the last time the address
book cache was refreshed, a refresh is not performed. The refresh interval
specifies how often the POP server checks to see if the cache is still
current; if it is not current, it is refreshed.
If you plan to use only the Client Access MAPI-based clients, consider setting
the Allow standard connection (ALWSTDCNN) parameter of CHGPOPA to *NO
in order to save resources. This parameter defaults to *YES, which specifies the
normal socket interface used by standard clients.
Removing POP Mail Users from the System
If you sign on to the client, the best way to remove users is to:
1. Sign on
2. Remove the user from the system distribution directory (this prevents any more
mail from being delivered)
3. Connect a mail client as the user to be removed and receive any mail left in the
mailbox
4. Delete the user’s profile from the AS/400 system
Setting the Number of SNA Servers
The number of servers (NBRSVR) parameter of the CHGPOPA command
determines how many POP server jobs to start when the POP server is started. The
number of SNA servers is not affected by this parameter.
The number of SNA servers is determined by prestart job configuration, and set on
the Change Prestart Job Entry (CHGPJE) command. You can accept the defaults
on this command, or change the number of SNA servers. To change the number of
SNA servers, use these parameter values:
v For the qualified subsystem name (SBSD), specify QSYSWRK.
v For the program name (PGM), specify library QTCP and program name
QTMMSRVR.
Use these parameters to set the number of SNA servers:
v INLJOBS — the initial number of prestart jobs to start for the subsystem
v THRESHOLD — the minimum number of prestart jobs that must be available
before additional prestart jobs are started
v ADLJOBS — the additional number of prestart jobs to start when the number of
prestart jobs drops below the value of the THRESHOLD parameter
v MAXJOBS — the maximum number of prestart jobs that can be active at the
same time for this prestart entry.
Stop and restart the POP servers for any changes to take effect.
Chapter 9. Post Office Protocol (POP) Mail Server
295
Starting the POP Server
To use the command line interface: you can start the POP server in several
ways:
v Use the STRTCPSVR command with the SERVER attribute set to *POP:
STRTCPSVR SERVER(*POP)
v Use the Change POP Mail Server Attributes (CHGPOPA) command to restart the
POP server whenever the Start TCP/IP Servers (STRTCPSVR) command is run.
v Use the AUTOSTART option of the Start TCP/IP (STRTCP) command.
To use the Operations Navigator to start the POP server:
v Follow the path Network\Servers\TCP/IP
v Right-mouse click the POP server
v Select Start
Ending the POP Server
To use the command line interface to end the POP server: enter the TCP/IP
Server (ENDTCPSVR) command with the server attribute set to *POP:
ENDTCPSVR SERVER(*POP)
You can also end the POP server in the following ways:
v Enter the ENDTCPSVR command without parameters (and all servers are
stopped)
v Run the End TCP/IP (ENDTCP) command.
To use the Operations Navigator to stop the POP server:
v Follow the path Network\Servers\TCP/IP
v Right-mouse click the POP server
v Select Stop
Supported POP Verbs
The client software uses commands called verbs to communicate with the POP
server. These commands are defined in RFC 1725. The AS/400 POP server
supports the following verbs:
296
Verb and parameters
Description
USER <id>
PASS <password>
STAT
LIST <opt msg #>
RETR <msg #>
DELE <msg #>
RSET
TOP <msg #> <lines>
UIDL <opt msg #>
NOOP
QUIT
Pass user ID
Password
Query mailbox
Query message statistics
Retrieve message
Delete message
Reset message delete status
Retrieve message header and data
Get message unique ID listing
No operation
Quit client session
OS/400 TCP/IP Configuration and Reference V4R4
How the POP Server Uses the Mail Server Framework
The POP server uses snap-ins to perform POP server mail functions. Snap-ins are
user exit programs that are called by the mail server framework. For more
information about snap-ins and mail server framework processing, see AnyMail/400
Mail Server Framework Support.
The POP mail server uses the following snap-ins:
v
v
v
v
v
v
v
Address Resolution
Envelope Processing
Attachment Conversion
Local Delivery
Non-Delivery
Message Forwarding
Attachment Management
Exchanging Mail with OfficeVision
Configuring Both POP and SMTP
For TCP/IP mail to be received correctly by OfficeVision or processed by SNADS,
both SMTP and the POP server must be correctly configured. This allows SMTP to
process simple SMTP mail and the POP server to process MIME-formatted mail.
For mail sent to or from OfficeVision you may want to alter the following SMTP
attributes (using the CHGSMTPA command):
v User ID delimiter (USRIDDELIM)
v Coded character set identifier (CCSID)
v Outgoing and incoming mapping tables (TBLSMTPOUT, TBLSMTPIN)
POP attributes that could affect mail to or from OfficeVision (which you can change
with the CHGPOPA command) include:
v Message split size (MSGSPLIT)
v MIME CCSID conversion parameters (MIMECCSID).
Using *ANY Support with the POP Server
You can use *ANY support when sending mail between two systems to avoid
entering information about every mail recipient.
A POP client using SMTP can send mail to any remote SMTP user without having a
directory entry (directory entries are only required on systems where you receive
the mail). However, an OfficeVision (SNADS) user must have a directory entry on
the sending system for every person he wants to send to (local or remote).
To make this easier, and to reduce the number of entries on the sending system, a
SNADS user can enter an *ANY for the entire remote system. An entry where the
User ID is *ANY and the Address is SYSTEMA allows OfficeVision users to send mail
to anyone with an address of SYSTEMA, for example:
CAROL
SYSTEMA
Chapter 9. Post Office Protocol (POP) Mail Server
297
If the recommended connection between two systems is actually an SMTP
connection instead of a SNADS connection, you can still use the *ANY entry by
adding an SMTP address to it. The SMTP user ID is left blank and the SMTP
domain is filled in with the host.domain information for SYSTEMA, for example:
SYSTEMA.MYTOWN.MYCOMPANY.COM
To tell OS/400 to use SMTP instead of SNADS to deliver mail between the two
systems, set the Mail service level to 2 (System message store) and set Preferred
address to 3 (SMTP name).
For more information on *ANY support, see SNA Distribution Services,
SC41-5410-01 .
A Client Access-based POP mail user can also send mail to an OS/400 distribution
list.
MIME Mail Sent To OfficeVision
When a POP client sends mail to another POP client, the note is delivered without
any conversions or transformations. The content of a POP-to-POP message is not
affected by the POP server.
When mail is sent from POP to OfficeVision clients, the MIME parser snap-in
converts MIME notes to OfficeVision/400 notes and documents. The snap-in
converts any MIME text attachments into a single OfficeVision note and converts
any binary attachments into documents with a type of IBM Personal Computer file.
References to the binary attachments are noted in the OfficeVision Text Note in the
same order in which they were encountered in the original MIME note.
While OfficeVision/400 is not MIME-compliant, the MIME conversion that occurs in
the mail server framework allows users to view the text portions of MIME notes. To
control the size and margins of lines so that lines do not appear truncated when
viewed in OfficeVision/400, see “Long Line Conversion” on page 299, later in this
section. OfficeVision users may also be able to view the binary portions of the
MIME notes if they are using a graphical user interface such as IBM
Current-OfficeVision/400. With this interface you can download the documents and
start a handler to process the file. The extension of the file name determines which
handler is called.
The POP server also preserves the original MIME type and subtype of the binary
attachment. It tries to derive the file name of the original document. This is useful
because many mail clients use the extension of the document as a means of
“typing” the file and starting the proper handler for that attachment when the icon for
the attachment is clicked. This derived file name is also used as the Subject after it
has been enclosed by parentheses. The graphical OfficeVision interface called
Current-OfficeVision/400 uses the file name to name downloaded files for
processing at the workstation level.
Because OfficeVision is not MIME-compliant, no attachment icons are displayed
and OfficeVision does not attempt to process the binary documents. If you try to
view these documents from the mail menu of OfficeVision, OfficeVision displays a
message saying that the document cannot be viewed. The binary attachments can
be forwarded to MIME-compliant mail users who can display them. They can also
be copied to local folders and accessed by using AS/400 Client Access network
drives.
298
OS/400 TCP/IP Configuration and Reference V4R4
Long Line Conversion
In order to make ASCII client mail more readable in OfficeVision environments, the
AS/400 Mail Server Framework is able to modify messages as they are converted
from ASCII/MIME to EBCDIC/FFT, in Version 4 Release 2. The two modifications
allow you to do the following:
1. Split long lines into two or more shorter lines.
2. Add FFT commands to messages, overriding parameters in the OfficeVision text
profile active for the recipient of the new mail. With these FFT commands, wide
messages can be viewed without changing OfficeVision text profiles.
The steps that are outlined below will enable either of the two modifications to
occur:
1. Create a character data area that is named QUSRSYS/QMAILFMT. For
example:
CRTDTAARA DTAARA(QUSRSYS/QMAILFMT) TYPE(*CHAR) LEN(100) VALUE('73/55/0')
In this example, length of 100 on the CRTDTAARA (Create Data Area) is
arbitrary, but it should be sufficient for any combination of values to be put in the
data area. All other parameters, except for the value, should be typed exactly as
shown.
2. Change the object owner to QSYS. For example:
CHGOBJOWN OBJ(QUSRSYS/QMAILFMT) OBJTYPE(*DTAARA) NEWOWN(QSYS)
3. Grant the proper authority to the data area. For example:
GRTOBJAUT OBJ(QUSRSYS/QMAILFMT) OBJTYPE(*DTAARA) USER(PUBLIC) AUT(*ALL)
4. Stop and restart the Mail Server Framework by using the ENDMSF and
STRMSF commands.
If you choose to make changes to the original modifications that you created, for
subsequent uses, follow these steps:
1. change the value in the QUSRSYS/QMAILFMT data area. For example:
CHGDTAARA DTAARA(QUSRSYS/QMAILFMT) VALUE('80/55/1')
2. stop and restart the Mail Server Framework by using the ENDMSF and
STRMSF commands.
Data Area Values
The value in the QMAILFMT data area can contain up to eight numbers that are
defined as follows:
LL/PL/FFF/LM/RM/GFID/FWD/FA
Note: A forward slash, /, separates each field. A double forward slash, //, is an
empty field, and defaults will be used. A space in any position ends the
parameter string. Any numbers or characters after a space will be ignored.
LL
Line Length, from 1 to 255, default is 255.
The maximum number of characters in a line. A long line
will be split at a space character preceding this count or
at this count for lines without a space. Tab characters
count 1 character.
PL
Page Length, from 1 to 32752, default is 32752.
The maximum number of lines on each page. If more than
this number of lines are received without a form feed, one
will be inserted at this point.
Chapter 9. Post Office Protocol (POP) Mail Server
299
FFF
Further Formatting Flag, 1 for yes, 0 for no, default is 0.
If this flag is set to 1 (one), two FFT commands, SHM (Set
Horizontal Margins) and SFG (Set FID through GFID) will be
inserted in all messages converted from ASCII to EBCDIC.
If this flag is set to 0 (zero), SHM and SFG will not be
inserted and the remaining parameters are ignored.
NOTE: The SHM command is used to set two values:
LM (Left Margin) and RM (Right Margin). The
SFG command is used to set three values: global
font identification (GFID), font width (FWD),
and font attributes (FA)
LM
Left Margin, from 0 to 32767, default is 1.
Left margin value to be inserted in the SHM FFT command,
in units of 1/1440 of an inch. A value of 0 will cause
the left margin in the users text profile to be used.
A value of 0 will cause the left margin in the users
text profile to be used. A value of 1 represents the
left edge of the screen. Ignored if FF is 0.
RM
Right margin, from 0 to 32767, default 30480.
Right margin value to be inserted in the SHM FFT command,
in units of 1/1440 of an inch. A value of 0 will cause
the right margin in the users text profile to be used.
Ignored if FFF is 0.
GFID
Global font ID, from 1 to 65534, default is 85.
Font ID to be inserted into the SFG FFT command.
85 is a Courier 12-pitch font. Ignored if FFF is 0.
FWD
Font width, from 1 to 1440, default is 120.
Font width to be inserted into the SFG FFT command.
120 represents 120/1440, or 1/12 of an inch. Ignored
if FFF is 0.
FA
Font attributes, 1 for fixed or 2 for proportional,
default is 1.
Font attributes to be inserted into the SFG FFF command.
Ignored if FF is 0.
The following examples include some values to consider for the QMAILFMT data
area:
'73/55/0'
Lines over 73 characters long will be split into multiple
lines so that all text can be viewed with the default
OfficeVision text profile. Page breaks will be added every
55 lines, and the users OV/400 text profile will not be
overridden.
'80/55/1'
Lines over 80 characters long will be split into multiple
lines. This is a good choice if cc:Mail for the Internet or
Lotus Mail is widely used, since those clients send lines
whose maximum length are 80 characters. The right-most few
characters of 80-character lines would not be visible with
the default OfficeVision text profile. But the default FFT
commands inserted in the message override the users text
profile and the message can be scrolled to the right to view
all data.
'//1'
All default values are used, but insert FFT commands in the
300
OS/400 TCP/IP Configuration and Reference V4R4
message. This is useful if some application on your system
needs long lines to be kept intact. OfficeVision users will be
able to scroll to the right to see parts of a message which
would otherwise be hidden.
'255/32752/0/1/30480/85/120/1'
These are the default values.
'//////' or '//' or ' '
No number means use all default values.
Note: Note that the MAILFMT settings will affect all mail that comes from ASCII
into EBCDIC.
Calculating FFT Values
For many mail environments, it will be necessary to calculate values for LM, RM,
GFID, FWD, and FA. The default values allow mail of the maximum width (255
characters) to be viewed.
If you choose to set the margins to specific columns, you will need the following
information:
v left column number
v right column number
v pitch of the font (in characters per inch)
You can calculate values for the margins, LM and RM, using this formula:
LM = (left column number - 1) / (characters per inch) * 1440
RM = (right column number - 1) / (characters per inch) * 1440
Exception:
use a margin of 1, not 0, for column 1.
For more examples of calculating values for margins, refer to the three examples
below:
Example 1:
Left column number = 1
Right column number = 255
GFID = 85, Courier 12
Font pitch = 12 characters per inch
LM = 1
RM = ((255-1)/12*1440 = 30480
FWD = 1440/12 = 120
Assuming 55 lines /page, the QMAILFMT value would be:
'255/55/1/1/30480/85/120/1'
Example 2:
The default OV/400 Systems text profile has margins set at
columns 19 and 91 for a line length of 73 characters.
To set up the equivalent mail formatting using the Courier 10
font below, do the following:
Left column number = 19
Right column number = 91
GFID = 11, Courier 10
Font pitch = 10 characters per inch
Chapter 9. Post Office Protocol (POP) Mail Server
301
LM = ((10-1)/10)*1440 = 1.8*1440 = 2592
RM = ((91-1)/10)*1440 = 9.0*1440 = 12960
FWD = 1440/10 = 144
Assuming 55 lines /page, the QMAILFMT value would be:
'73/55/1/2592/12960/11/144/1'
Example 3:
Left column number = 1
Right column number = 132
GFID = 223, Courier 15
Font pitch = 15 characters per inch
LM = 1
RM = ((132-1)/15)*1440 = 12576
FWD = 1440/15 = 96
Assuming 55 lines/page, the QMAILFMT value would be:
'132/55/1/1/12576/223/96/1'
The next three examples show Set FID through GFID (SFG) parameters:
FONT STYLE
a). Courier 10
b). Courier 12
c). Courier 15
GFID
FWD
FA
COMMENTS
11
85
223
144
120
96
1
1
1
Alias Courier 72.
10 ch/in.
12 ch/in.
15 ch/in.
For FWD = 10 ch/in set it to 144.
12 ch/in set it to 120.
15 ch/in set it to 96.
MIME Content Types
Standard Internet text notes consist of a general header and a text body. MIME
notes, however, can contain multiple parts, which allows multimedia attachments to
be included with the text.
If the general header contains a content type of Multipart/Mixed, one or more
attachments follow. There are beginning and ending boundaries for each
attachment. The boundary identifier is set on the boundary= parameter that follows
the “Content-Type” header tag. See Figure 190 on page 303 for an example of a
multipart MIME note. In this example, each part has a content type, and that each
text content type can optionally have a character set (charset) defined.
302
OS/400 TCP/IP Configuration and Reference V4R4
From @SYSNAM6.CITY.COMPANY.COM:[email protected] Wed Jan 10
11:33:18 1996
Return-Path: <@SYSNAM6.CITY.COMPANY.COM:[email protected]>
Received: from SYSNAM6.city.company.com by fakeps2.city.company.com (COMPANY OS/2 SENDMAIL
VERSION 1.3.2)/1.0)
id AA0329; Wed, 10 Jan 96 11:33:18 -0500
Date: Wed, 10 Jan 96 11:33:18 -0500
Message-Id: <[email protected]>
Received: from endmail9 by SYSNAM6.CITY.COMPANY.
(IBM OS/400 SMTP V03R02M00) with TCP; Wed, 10 Jan 1996
10:23:42 +0000.
X-Sender: [email protected] (Unverified)
X-Mailer: Windows Eudora Pro Version 2.1.2
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_821301929==_"
To: [email protected]
From: endmail9 <[email protected]>
Subject: eudora attachments
X-Attachments: C:\EUDORA\ARGYLE.BMP;
--=====================_821301929==_
Content-Type: text/plain; charset="us-ascii"
An example of using Eudora to send a text and bitmap.
--=====================_821301929==_
Content-Type: application/octet-stream; name="ARGYLE.BMP";
x-mac-type="424D5070"; x-mac-creator="4A565752"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ARGYLE.BMP"
Qk12AgAAAAAAAHYAAAAoAAAAIAAAACAAAAABAAQAAAAAAAACAAAAAAAAAAAAAAAAAAAQAAAAAAAA
AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA
////AE1EREREREREZERERERERE1E1ERERERERsZERERERETURE1ERERERGxsZERERERNRERE1ERE
REbGxsZERERE1ERERE1ERERsbGxsZERETURERERE1ERGxsbGxsZERNRERERERE1EbGxsbGxsZE1E
RERERERE1sbGxsbGxsbURERERERERG1sbGxsbGxtZEREREREREbG1sbGxsbG1sZERERERERsbG1s
bGxsbWxsZERERERGxsbG1sbGxtbGxsZEREREbGxsbG1sbG1sbGxsZERERsbGxsbG1sbWxsbGxsZE
RGxsbGxsbG1tbGxsbGxsZEbGxsbGxsbG1sbGxsbGxsZEbGxsbGxsbW1sbGxsbGxkREbGxsbGxtbG
1sbGxsbGREREbGxsbG1sbG1sbGxsZEREREbGxsbWxsbG1sbGxkREREREbGxtbGxsbG1sbGRERERE
REbG1sbGxsbG1sZEREREREREbWxsbGxsbG1kRERERERERNbGxsbGxsbG1ERERERERE1EbGxsbGxs
ZE1ERERERETUREbGxsbGxkRE1ERERERNREREbGxsbGRERE1ERERE1EREREbGxsZERERE1ERETURE
REREbGxkRERERE1ERNREREREREbGRERERERE1E1EREREREREZERERERERE3URERERERERERERERE
RERE
--=====================_821301929==_--
Figure 190. Example of a Multipart MIME Note
Supported Content Types of the POP Server
The POP server can handle almost any type. If the part does not have a type of
Text with a subtype of plain or enriched or a type of Message with a subtype of
RFC822, the part is stored as a binary PC file. A notation is made in the OfficeVision
text note that is generated when a MIME note is converted.
What about the Type/Subtype of Message/RFC822? This is a commonly-used method
of embedding a note within a note that is often used when forwarding a note. The
POP server handles this type by prefixing any text and binary file notations within
the OfficeVision note with the greater-than (>) character. The number of prefixed
greater-than characters indicates the embed level of the RFC822 message.
Chapter 9. Post Office Protocol (POP) Mail Server
303
The Type/Subtype of Message/RFC822 handles up to 10 levels of embeds. After the
tenth embed, the note content is copied verbatim to the text OfficeVision note. The
following shows a message with three levels of embeds:
Message-Id:<[email protected]>
Date: Fri, 12 Jan 1996 16:51:06 -0500
From: Bob Smith <[email protected]>
Mime-Version: 1.0
To: [email protected]
Subject: [Fwd: [Fwd: [Fwd: Text and Image]]]
-----------------------------------------------------------------------3 level imbed
-Bob Smith
Dept 250
>
>
>-----------------------------------------------------------------------> Sender: [email protected]
> Message-Id:<[email protected]>
> Date: Fri, 12 Jan 1996 16:48:55 -0500
> From: Ed Bailey <[email protected]>
> Mime-Version: 1.0
> To: [email protected] > Subject: [Fwd: [Fwd: Text and Image]]
>
>
>----------------------------------------------------------------------->Next level 1
>->Ed Bailey
>Dept 129
>>
>>
>>---------------------------------------------------------------------->> Sender: [email protected]
>> Message-Id:<[email protected]>
>> Date: Fri, 12 Jan 1996 16:36:49 -0500
>> From: C. Kent <[email protected]>
>> Mime-Version: 1.0
>> To: [email protected]
>> Subject: [Fwd: Text and Image]
>>
>>
>>---------------------------------------------------------------------->>Next level 2
>>->>Clark Kent
>>Dailey Times
>>
>>>
>>>--------------------------------------------------------------------->>> From: [email protected]
>>> Message-Id:<[email protected]>
>>> Mime-Version: 1.0
>>> Date: Fri, 12 Jan 96 09:16:24 +0600
>>> To: [email protected]
>>> Subject: Text and Image
>>>
>>>
>>>--------------------------------------------------------------------->>>Next level 3
>>> Some text and an embedded image.
>>>//--------------------------------------------------------->>>// J. D. Hall
>>>// Dept 360
>>>
>>>
304
OS/400 TCP/IP Configuration and Reference V4R4
>>>--------------------------------------------------------------------->>Type/Subtype: image/GIF
>>>Description: (BRICK.BMP)
>>>
How the File Name is Derived
During the POP (MIME)-note-to-OfficeVision-note conversion process, multimedia
subparts are converted to OfficeVision/400 document PC files. These OfficeVision
document PC files are binary representations of the particular multimedia subpart
that they represent. When these OfficeVision document PC files are generated, a
file name is derived to store in the Document Interchange Architecture (DIA) portion
of the OfficeVision document. When the document is sent to a POP mail user, the
file name is used for the content description and also as the name= parameter
content for the content type. This allows MIME-compliant clients to use the file
name to determine what type of object the attachment is and which handler to run
against it.
A MIME-compliant POP client can set the file name in the following ways:
v Include the file name as the filename= parameter of the Content-Disposition
header.
v Specify the file name on the name= parameter of the Content-Type header.
v Place the filename.ext in the Content-Description header.
The POP server tries to determine the file name by successively looking in these
places. When a header is found, the MIME parser attempts to parse the file name.
If a blank string is returned, the internal file name that is used in the conversion
process is used. If a file name is parsed, then the filename portion of the
filename.ext is limited to 8 characters and the ext is limited to 3 characters. This
allows all file allocation table (FAT) file systems to process these files.
MIME Content Types
Table 26 on page 306 shows how each type and subtype of the primary header are
handled. These are defined in the content-type header. These tables are for
reference only, and show which MIME Content-Type headers the POP server
supports.
Table 27 on page 306 shows how each type and subtype of the individual part
headers are handled. These are defined in the Content-type header.
What Happens When You Send OfficeVision Mail to POP Clients
When you send an OfficeVision note to a POP user, the POP server sends the
entire contents of the OfficeVision note and includes any headers that OfficeVision
may have inserted. The character set that is used for the charset= parameter is
determined by the value of the MIMECCSID When_to_Use parameter element of
the Change POP Attributes (CHGPOPA) command. If this parameter is set to
*ALWAYS, the EBCDIC Coded Character Set Identifier (CCSID) is forced to the
ASCII CCSID that is defined in the CHGPOPA menu. If the parameter is set to
*BESTFIT, the appropriate ASCII CCSID that produces the best fit based on the
EBCDIC CCSID is used. The ASCII CCSID value is then used to look up the
equivalent ISO-8859-x character set for the charset parameter.
Chapter 9. Post Office Protocol (POP) Mail Server
305
See Figure 191 on page 307 for an example of a note generated by the
AnyMail/400 framework to a POP user. In this example, the memo slips will always
be in the default MIME charset US-ASCII. The contents of the note will be in the
best fit or forced fit character set as determined by the POP3 Server’s configuration.
The text tags that are generated by OfficeVision in the content of the note will not
be removed, hence you may see the subject and other tags twice.
Binary attachments are converted into a MIME part of a multipart/mixed note and
the stored type and subtype are placed in the Content-Type header. A name=
parameter is added to the Content-Type header with the stored filename.ext. This
name is also used as the Content-Description.
Table 26. MIME Primary Heading Content Types
Type
Subtype
OfficeVision
Counterpart
None
None
Note
This is a simple SMTP note that uses only RFC822
headings.
Text
Plain
Note
This is treated the same as SMTP simple note;
however, a character set can be used.
Multipart
Mix
Note and possibly
Document
Each part’s type and subtype determines how it is
handled. See Table 27.
Multipart
Parallel or Digest or Note and Document
Alternative or
Extension- token
This combination cannot be parsed, its contents are
spooled to an OfficeVision Document, PC file.
Message
RFC822
Note and possibly
Document
This is usually an embedded note and could be a
MIME with a content type of MultiPart Mixed. See
the multipart explanation in this table.
Message
Partial
Note and possibly
Document
This combination cannot be parsed. Its contents are
spooled to an OfficeVision Document, PC file.
Message
External- body
Note and Document
This combination cannot be parsed. Its contents are
spooled to an OfficeVision Document, PC file.
Notes
Table 27. Mapping MIME Note’s Part Type and Subtypes to OfficeVision
OfficeVision
Counterpart
Notes
None
Note or part of the
OfficeVision note
Treated as simple note; assumes the character
set is US-ASCII
Text
Plain
Note or part of the
OfficeVision note
Same as a simple note, but the character set is
honored if it is present as an attribute to the
Content-type header.
Text
Enhanced
Note or part of the
OfficeVision note
Same as Simple note, but the character set is
honored if it is present as an attribute to the
Content-type header. The text is passed as is.
Enhanced tags will be present in text.
Image
Any subtype
honored
OfficeVision Document
PC file
Type and subtype are preserved along with the
derived file name.
Audio
Any subtype
honored
OfficeVision Document
PC file
Type and subtype are preserved along with the
derived file name.
Video
Any subtype
honored
OfficeVision Document
PC file
Type and subtype are preserved along with the
derived file name.
Application
Any subtype
honored
OfficeVision Document
PC file
Type and subtype are preserved along with the
derived file name.
Type
Subtype
None
306
OS/400 TCP/IP Configuration and Reference V4R4
Table 27. Mapping MIME Note’s Part Type and Subtypes to OfficeVision (continued)
OfficeVision
Counterpart
Type
Subtype
Message
RFC822
Not defined in this
table
Not defined in this
table
Notes
Appends to existing note and may add
documents
OfficeVision Document
PC file
MIME Parser does not handle these
combinations and spools them to a PC file.
From [email protected] Thu Feb 01 07:54:03 1996
Return-Path: &lt;[email protected]>
Received: from SYSNAM7.city.company.com by fakeps2.city.company.com (COMPANY OS/2 SENDMAIL VERSION 1.3.2)/1.0)
id AA0202; Thu, 01 Feb 96 07:54:03 -0500
Message-Id: &lt;[email protected]>
Mime-Version: 1.0
Date: Thu, 1 Feb 1996 07:55:16 +0000
Subject: This is the Subject Line
Reference: This is the Reference Line
Sensitivity: none
Priority: normal
Importance: high
From: [email protected]
To: [email protected]
Content-Type: multipart/mixed;
boundary="PART.BOUNDARY.1"
> THIS IS A MESSAGE IN 'MIME' FORMAT. Your mail reader does not support MIME.
> You may not be able to read some parts of this message.
--PART.BOUNDARY.1
Content-ID: &lt;1_1>
Content-Type: text/plain
For your information
Here's a Memo Slip which I've attached.
--PART.BOUNDARY.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
TO:
FROM:
FAKE
FAKEPS2
FAKEOV
Fakes ps2
SYSNAM7
FAKEOV
DATE:
February 1, 1996
SUBJECT:
This is the Subject Line
REFERENCE: This is the Reference Line
This is the main body of the note.
--PART.BOUNDARY.1--
Figure 191. Example of a MIME Note Going from OfficeVision/400 to a POP Mail User
Setting Up MIME Headers to Differentiate between Recipients
The Change Distribution Attributes (CHGDSTA) command changes the content of
message services attributes (X.400 support) for mail distributions and
OfficeVision/400. The Keep Recipient (KEEPRCP) parameter specifies which
recipient information is stored and sent within each mail distribution. The setting of
this parameter affects how the MIME headers get created for a note from
OfficeVision.
Chapter 9. Post Office Protocol (POP) Mail Server
307
In order for CC and BCC tags to show up in MIME headers (and client screens),
you must set the KEEPRCP parameter to *ALL. BCC recipients are not shown
regardless of the setting of this parameter because they are not intended to be. The
TO and CC recipients will show up in the text of the OfficeVision note.
Sending MIME (POP Server) Mail across a SNADS Network
This section applies only to those situations where:
v You have AS/400 systems connected to each other across a SNADS network
v You are adding (or have added) POP mail clients
v You want these POP mail clients to be able to send MIME mail to each other
between these systems without the mail being handled as OfficeVision mail.
When MIME mail is sent over AS/400 systems connected with SNADS, MIME text
attachments are parsed and converted, and video, audio and image files are
decoded and reformatted as PC files. Because of this processing, a single MIME
message can be converted to many SNADS messages, and some information can
be lost in the conversion. This happens even if a POP mail user is sending mail to
another POP mail user across a network; SNADS assumes that the mail is
OfficeVision mail and handles it accordingly.
SNADS tunneling provides an alternative; it allows POP users to send MIME mail
between AS/400 systems across a SNADS network without the mail being
converted to OfficeVision mail.
How SNADS Tunneling Works
Tunneling refers to a technique in which you send protocol traffic across another
protocol or send data across a protocol that the data was not intended to be sent
across. With SNADS tunneling, a MIME message is encapsulated as a SNADS
object distribution data file. Because object distribution files are treated as binary or
unformatted data, they are passed along as is; no parsing or transformation takes
place.
How to Configure System Distribution Directory Entries for SNADS
Tunneling
Configuring SNADS mail clients to use SNADS tunneling is very simple. All you
need to do is set the Address type field in the system distribution directory entry for
the mail clients or system receiving the mail to TNDENDGN. Since you will normally
be using *ANY entries to transport mail to another system, changing this one field
ensures that all MIME mail sent to users on that system (who do not have different
instructions associated with their own individual entries in the system distribution
directory) will be tunneled.
Although mail clients still need to be configured to receive mail, you do not need to
do anything differently for these clients to receive mail that is tunneled through
SNADS (SNA distribution services). Tunneling is determined by the directory entry
for the system to which you are sending mail and only affects the way the mail is
transported (not delivered). Mail recipients, as long as they are using V3R2 or V3R7
and later versions of the TCP/IP Connectivity Utilities for AS/400, are able to receive
both OfficeVision and MIME mail (regardless of whether it is tunneled).
308
OS/400 TCP/IP Configuration and Reference V4R4
Example
You have two systems, SYSTEM1 and SYSTEM2, both with POP mail users. They
are connected with SNADS. You want the MIME mail that POP users on SYSTEM1
are sending to POP mail users on SYSTEM2 to be tunneled.
Figure 192. SNADS Network with OfficeVision and POP Mail Users
Assuming that you have a *ANY entry for all mail going to SYSTEM2, you need to
change the Address type field in this entry.
1. Type WRKDIRE to display the Work with Directory Entries menu.
Work with Directory Entries
Type options, press Enter.
1=Add
2=Change
4=Remove
5=Display details
6=Print details
7=Rename
8=Assign different ID to description
9=Add another description
Opt
_
_
2
_
_
_
_
_
_
_
_
_
_
User ID
________
AABOND
*ANY
ACER
ADAMSJA
ALBERT
APPLETN
BONNER
BRIGHT
BYERS
CARLTON
CHUCK
DAVIS
F3=Exit
Address
________
SYSNAM3
SYSTEM2
SYSNAM3
SYSNAM1
SYSNAM1
SYSNAM1
SYSNAM3
SYSNAM1
SYSNAM1
SYSNAM3
SYSNAM2
SYSNAM1
F5=Refresh
Description
Bond, Alan
System2 Mail Users
Acer, Rodney G. (Rod)
Adams, Jane
Schweitzer, Albert
Appleton, John
Bonner, Heinz
Bright, Jeremiah (Jerry)
Byers, Andrea
Lewis, Carlton
Mortimer, Charles (Chuck)
Davis, Martin
F9=Work with nicknames
TE
More...
F11=Sort by description
Figure 193. Work with Directory Entries (WRKDIRE) Display — Display 2
2. Type option 2 (Change) next to the SYSTEM2 entry
3. Press the Enter key to see the Change Directory Entry display.
Chapter 9. Post Office Protocol (POP) Mail Server
309
Change Directory Entry User ID/Address
Type changes, press Enter.
Description . . .
System name/Group
User profile . .
Network user ID .
.
.
.
.
.
.
.
.
.
.
.
.
SYSTEM2 Mail Users
SYSTEM2
_______
__________
*ANY
SYSTEM2
Name:
Last . .
First . .
Middle .
Preferred
Full . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
________________________________________
____________________
____________________
____________________
_________________________________________________
F3=Exit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F4=Prompt
F5=Refresh
F12=Cancel
F4 for list
F4 for list
:ROCHESTE
More...
F18=Display location details
Figure 194. Change Directory Entry Display — Display 1
4. Page down to the display that shows the Preferred address and Address type
fields
Change Directory Entry
User ID/Address . . . . :
*ANY
SYSTEM2
Type changes, press Enter.
Mail service level
. .
1
For choice 3=Other mail service:
Field name . . . .
Preferred address . . .
1
Address type . . . . TNDENDGN
For choice 4=Other preferred address:
Field name . . . .
F3=Exit
F4=Prompt
F5=Refresh
F12=Cancel
1=User index
2=System message store
3=Other mail service
F4 for list
1=User ID/Address
2=O/R name
3=SMTP name
4=Other preferred address
F4 for list
F4 for list
More...
F18=Display location details
Figure 195. Change Directory Entry Display — Display 2
5. Since this is a SNADS system, the Preferred address for this entry should
already be set to 1 (User ID/Address).
6. Set Address type to TNDENDGN.
7. Press Enter to save your changes.
Address Types
Standard POP implementations can address mail only with Internet addresses. If an
Internet address needs to be converted to a different type of address, the
conversion is performed by a gateway somewhere in the network. (The gateway
may be the AS/400 Mail Server Framework). Client Access-based mail clients, in
310
OS/400 TCP/IP Configuration and Reference V4R4
conjunction with the AS/400 POP server, have another option. They can address
mail with several different types of addresses.
Table 28 shows each type of address supported by Client Access-based mail. The
MAPI interface, implemented by Client Access-based mail service providers, allows
any mail-enabled application to address mail with any of these types of addresses.
The type names shown in the table are the actual MAPI address-type strings that
Client Access-based mail registers with MAPI. The table simply shows the valid
address types and their corresponding formats.
AS/400 Address Book
The POP Server and the Client Access-based MAPI address book provider also
provide a public address book. Mail-enabled applications on the client can view
entries in the address book or send mail to users listed in the address book. For
example, the Microsoft Exchange client talks to a MAPI interface. Therefore, a
Client Access user running Microsoft Exchange can select an entry from the
address book and send mail to the user represented by that entry.
The addresses in the AS/400 address book are from the system distribution
directory and distribution Lists on the AS/400. Table 29 on page 313 shows where
data in the address book comes from. The address type of an AS/400 address book
entry is determined by the preferred address in the system distribution directory.
Distribution lists always have an address type of OFFICEVISION. The Preferred
address in Table 28 gives the preferred address of each type of address in the
AS/400 address book.
Table 28. MAPI Address Type Definitions
MAPI Address Type
Preferred Address
Format and Description
INTERNET
SMTP name
Format: <userid>@<domain>
This is the standard internet format. From the system distribution
directory, <userid> is the SMTP user ID field and <domain> is the
SMTP domain field. For example:
system5.endicott.ibm.com
aol.com
gdlvm6
<userid> and <domain> must be separated by a single ‘@’
character, and blanks are not allowed within or between the parts.
Leading and trailing blanks to the whole address should be tolerated
and ignored.
Examples:
[email protected]
[email protected]
[email protected]
Chapter 9. Post Office Protocol (POP) Mail Server
311
Table 28. MAPI Address Type Definitions (continued)
MAPI Address Type
Preferred Address
Format and Description
OFFICEVISION
User ID/Address (for
individual directory
entries), or List ID and
List ID qualifier (for
distribution lists)
Format: <UUUUUUUU> <AAAAAAAA>
This type is also called the “SNADS address” or “DEN/DGN” by
some. From the system distribution directory, <UUUUUU> is the
User field, and <AAAAAA> is the Address field. Both values can be
a maximum of eight characters long (and can be shorter than eight
characters). Neither <UUUUUU> nor <AAAAAA> can contain the
blank character. They must be separated by at least one blank
character. Leading and trailing blanks to the whole address should
be tolerated and ignored.
Examples:
MANDY SYSTEM1
LISA
SYSTEM5
JAMIE
GRADE5
ELYSE GRADE1
CALDWELJ SYSTEM2
AS400FAX
Other preferred
address
(FAXTELNBR)
Format: <facsimile-telephone-number>
Within the system distribution directory, this is considered one of the
“Other” address types. (Set Preferred address to 4 (Other preferred
address).) The actual<facsimile-telephone-number> used as the
address is found in the system distribution directory FAX telephone
number. The address is a “dialing sequence”, including access code
sequences. It is expected to follow the rules for the Facsimile
Support for OS/400 LPP telephone-number.1 Leading and trailing
blanks to the whole address should be tolerated or ignored.
Examples:
7525421
9=16077525421
8+8525421
*70/18005551212
Notes:
1. The telephone number, made up of dialing and control codes, is described in the Facsimile Support for the
OS/400 Programmer’s Guide and Reference, SC41-0572. See the detailed description of the SNDFAX command.
Also see the Facsimile Support for OS/400 Installation Guide, SC41-0570 for more information on creating FAX
entries in the system distribution directory.
The entries described in Table 28 on page 311 are built into an address book
cache that includes these address types and E-mail addresses as well as other
information from the system distribution directory.
The Address Book Cache
The POP server does not read the system distribution directory every time a client
requests something from it. Instead, a cache is built from the system distribution
directory entries and distribution lists. The POP server uses this cache to retrieve
address book data for clients.
The address book cache is built and maintained by the POP server when the
ADRBOOK parameter is set to *YES. The Refresh interval element of the
ADRBOOK parameter determines how often the address book is updated from the
system distribution directory. (See “Configuring POP for Client Access-Based Mail
Users” on page 294 for a description of the ADRBOOK parameter.)
312
OS/400 TCP/IP Configuration and Reference V4R4
Table 29. Data mapping from System Distribution Directory to POP Server Address Book Cache
Field in Address Book Cache
Fields in the System Distribution Directory
<display-name>
Full name or Description
If Full name is not blank, it is used. If Full name is blank, Description is used.
For Distribution Lists, the Description field is always used (Distribution List
entries do not have a Full name field).
<address-type>
For individual system distribution directory entries, use Preferred address to
determine the type.
The cache <address-type> field is filled in using the following rules:
v If Preferred address is “*USRID” (User ID/Address), use MAPI address type
OFFICEVISION
v If Preferred address is “*SMTP” (SMTP), use MAPI address type INTERNET
v If Preferred address is “FAXTELNB” (considered an “Other” address type),
use MAPI address type AS400FAX
v If Preferred address is not one of the values above, the address type is not
supported by AS/400 MAPI service providers and the entry is not put into the
address book cache.
For AS/400 Distribution lists, <address-type> is OFFICEVISION.
<email-address>
(User ID -and- Address) or (SMTP user ID -and- SMTP domain) or FAX
telephone number
The cache <email-address> field is filled using the following rules:
v If the address book cache <address-type> is now “OFFICEVISION”,
concatenate the following:
1. The 8-character system distribution directory User ID (including trailing
blanks) for individual SDD entries, or List ID for AS/400 Distribution Lists.
2. A single blank
3. The Address (trailing blanks not required) for individual system distribution
directory entries, and List ID qualifier for AS/400 Distribution Lists.
v If the address book cache <address-type> is now “INTERNET”, concatenate
the following:
1. SMTP user ID (without trailing blanks)
2. A single “@” character
3. The SMTP domain (trailing blanks not required).
v If the address book cache <address-type> is now “AS400FAX”, use system
distribution directory FAX telephone number (trailing blanks not required).
<comment>
No system distribution directory data is currently being extracted for this field.
ASCII-EBCDIC Conversion and National Language Support
This topic describes how the POP server handles the conversion of mail from ASCII
to EBCDIC and from EBCDIC to ASCII. This conversion is part of national language
support (NLS).
Chapter 9. Post Office Protocol (POP) Mail Server
313
EBCDIC-to-ASCII Conversion
Figure 196 shows how the POP server handles mail going from EBCDIC (such as
OfficeVision mail or control language interface) to ASCII (such as Internet or POP
mail).
Figure 196. EBCDIC-to-ASCII Conversion
There are two paths by which text is converted from OfficeVision format (EBCDIC)
to Internet format (ASCII); the SMTP bridge and the Mail Server Framework. Before
the introduction of MIME support and the POP server in V3R2 and V3R7, all mail
which needed conversion went through the SMTP bridge. Mail is converted in the
SMTP bridge using the SMTP configuration information (CHGSMTPA). Mail is
converted in the framework using the POP configuration information (CHGPOPA).
To configure your outbound mail to go through the SMTP bridge, set the following
fields on the Add Directory Entry (ADDDIRE) command of the recipient of the mail:
1. Set System name to TCPIP as shown in Figure 197 on page 315:
314
OS/400 TCP/IP Configuration and Reference V4R4
Add Directory Entry
Type choices, press Enter.
User ID/Address .
Description . . .
System name/Group
User profile . .
Network user ID .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
USER1 SYS1
Fred
TCPIP ________
F4 for list
USER1.
F4 for list
___________________________________________________
Name:
Last . .
First . .
Middle .
Preferred
Full . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
____________________________________________
______________________
______________________
______________________
___________________________________________________
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Figure 197. Add Directory Entry (ADDDIRE) — Display 3
2. Set Mail service level to 1 (User index) and Preferred address to 1 (User
ID/Address) as shown.
Type choices, press Enter
Mail service level
. .
1
For choice 3=Other mail service:
Field name . . . . __________
1=User index
2=System message store
3=Other mail service
______
Preferred address: . . . 1
Address type . . . . . ________
For choice 4=Other preferred address:
Field name . . . . __________ ______
F3=Exit
F4=Prompt
F5=Refresh
F19=Add name for SMTP
F12=Cancel
F4 for list
1=User ID/Address
2=O/R Name
3=SMTP Name
4=Other preferred address
F4 for list
F4 for list
More...
F18=Display location details
Figure 198. Add Directory Entry (ADDDIRE) — Display 4
If the text is converted to a code page other than US_ASCII or Latin_1
(ISO-8859-1), the OfficeVision/400 non-convert option for FFT must be set.
Otherwise the results are unpredictable.
ASCII-to-EBCDIC Conversion
Figure 199 on page 316 shows how the POP server handles mail going from ASCII
to POP mail or EBCDIC.
Chapter 9. Post Office Protocol (POP) Mail Server
315
Figure 199. ASCII-to-EBCDIC Conversion
No conversion is done on incoming mail from SMTP if it is delivered to a POP
mailbox.
The path to SNADS does ASCII-to-EBCDIC conversion and DIA/FFT formatting.
Simple SMTP is converted using the SMTP configuration information (CHGSMTPA).
MIME mail is converted using the POP configuration information (CHGPOPA).
All TCP/IP mail sent to OfficeVision/400, both MIME and non-MIME, must be
converted from ASCII to EBCDIC. For this conversion to work in any country both
SMTP and the POP server must be configured.
What are CCSIDs
ISO standards and Internet RFCs define a list of graphic symbols or characters
used to represent the written language of one or more countries. This list is called a
character set and is identified by a number (the Coded Character Set Identifier, or
CCSID). OS/400 supports a large number of character sets.
Character sets, when given binary values for each character, are called code
pages. Each language supported by OS/400 has a character set and code page.
316
OS/400 TCP/IP Configuration and Reference V4R4
For the United States, the character set is 697 and the code page is 37 (CCSID
37). This character set and code page combination can be converted into any other
code page that uses the same character set. The ISO language standard 8859-1
uses or defines the same characters as character set 697, so United States English
can be converted into ISO-8859-1 and back again without the loss of information. If
a character set for a country is the same as, or is a subset of the MIME-standard
character set, data can be converted to the MIME code page without the loss of
information.
For more information on national language support and what is supported by
OS/400, see National Language Support book.
CCSIDs Supported by the POP Server
The MIME coded character set identifier configuration parameter (MIMECCSID) on
the Change POP Attributes (CHGPOPA) command determines which CCSID to use
for translation, and under what conditions to use it. Once you specify a CCSID, you
can choose to use it all the time (*ALWAYS) , or only if a better fit cannot be found
(*BESTFIT).
The CCSIDs supported for conversion are MIME- or Internet-defined standard
character sets:
Table 30. Supported MIME Standard Code Pages
MIME Standard
Name
ASCII CCSID
Character Set
EBCDIC CCSID
US-ASCII
US English
00367
103
00500
ISO-8859-1
Latin-1
00819
697
00500
ISO-8859-2
Latin-2
00912
959
00870
ISO-8859-5
Cyrillic
00915
1150
01025
ISO-8859-6
Arabic
1089
1271
420
ISO-8859-7
Greek
00813
925
00875
ISO-8859-8
Hebrew
00916
941
00424
ISO-8859-9
Latin-5
00920
1152
01026
ISO-2022-JP
Japan MBCS
05052
1064,1062,1121,1120
05026
Chapter 9. Post Office Protocol (POP) Mail Server
317
318
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 10. Workstation Gateway Server
The workstation gateway server (WSG) is a TCP/IP application that transforms
AS/400 5250 data streams to Hypertext Markup Language (HTML) for dynamic
display on Web browsers. This allows you to run AS/400 applications from any
workstation that has a Web browser.
The workstation gateway server provides capabilities that are similar to those when
you use the character interface to an AS/400 system or when you use the Graphical
Access function of Client Access.
To access an AS/400 system from a Web browser, specify the URL of the
workstation gateway server.
Without a workstation gateway server, your applications send out 5250 data
streams that an emulator converts to text for display on a workstation. With a
workstation gateway server, your applications send out the same 5250 data
streams, but the AS/400 system converts the data stream for display by Web
browsers. The AS/400 system converts the 5250 data to HTML, which the Web
browsers use for their displays. Figure 200 shows you how the AS/400 system does
this.
Figure 200. AS/400 Support of workstation gateway server
Your applications continue to work, unchanged, but you can add graphics to them if
you use the workstation gateway server to access them. The book DDS Reference
provides more information about adding graphics to applications.
Accessing Workstation Gateway Functions through Operations
Navigator
You can access workstation gateway server functions from a command line
interface or from Operations Navigator. Not all of the workstation gateway server
functions are available on both interfaces. However, most workstation gateway
server functions are available only through Operations Navigator.
This chapter discusses how to start, stop, and configure the workstation gateway
server from the command line interface. It does not document any of the Operations
© Copyright IBM Corp. 1997, 1999
319
Navigator functions. See the online Help in Operations Navigator for information
about using Operations Navigator for workstation gateway server functions.
To access workstation gateway server server functions through Operations
Navigator, perform the following steps:
1. Double-click your AS/400 server in the main tree view of Operations Navigator.
2. Double-click Network.
3. Double-click Servers.
4. Double-click TCP/IP.
5. Double-click Workstation gateway.
Note: Although some of the functionality of the command line interface and the
Operations Navigator is the same, the actual menu commands and
parameters are not necessarily the same.
The online help in Operations Navigator assists you with the following:
v Starting the workstation gateway server.
v Automatically starting the workstation gateway server whenever TCP/IP is
started.
v Ending the workstation gateway server.
v Configuring the workstation gateway server.
Starting the Workstation Gateway Server
To start the workstation gateway server, specify the following STRTCPSVR
command with the SERVER attribute set to *WSG:
STRTCPSVR SERVER(*WSG)
Specify the Change WSG Attributes (CHGWSGA) command to restart the server
whenever you run the Start TCP/IP Servers (STRTCPSVR) command:
CHGWSGA
AUTOSTART(*YES)
Automatically Starting the Workstation Gateway Server
The AUTOSTART parameter controls when the AS/400 system starts the
workstation gateway server. Specify *YES if you want the workstation gateway
server to start whenever TCP/IP is started. If you use the STRTCPSVR command,
this parameter is ignored, and the system starts the workstation gateway server. If
the workstation gateway server is active, the system ignores any subsequent
STRTCPSVR requests for workstation gateway.
Ending the Workstation Gateway Server
To end the workstation gateway server, specify the TCP/IP Server (ENDTCPSVR)
command with the server attribute set to *WSG:
ENDTCPSVR SERVER(*WSG)
Specify the ENDTCPSVR command without parameters. This stops all TCP/IP
servers.
320
OS/400 TCP/IP Configuration and Reference V4R4
Configuring the Workstation Gateway Server
You do not need to configure much to begin using the workstation gateway server.
Most configuration options have default settings.
To configure the workstation gateway server, use the Configure TCP/IP Workstation
Gateway (CFGTCPWSG) command.
Before you start the workstation gateway server for the first time, perform the
following steps:
1. Change the Display Sign-on Panel option to *YES.
For information on making this change, see Figure 202 on page 324. Look for
the option marked „5…, explained in “Display Sign-on Panel (DSPSGN)” on
page 325.
2. Configure and use the user exit.
For information about configuring and using the user exit for the workstation
gateway server, see “Using a WSG exit progam to bypass the AS/400 Sign-on
Display” on page 571.
The changes take effect the next time you start the workstation gateway server. For
information on starting the workstation gateway server, see “Starting the
Workstation Gateway Server” on page 320.
Note: The workstation gateway server might not recognize some customized
sign-on panels. This is because the workstation gateway server expects
input fields in certain locations. If the input fields differ greatly from the
default sign-on panel shipped with the AS/400 system, a possibility exists
that the system might fail to recognize the display as a sign-on panel. If, for
example, a user exit returns a bad user profile, password, or other field, then
the sign-on attempt fails. However, the workstation gateway server does not
recognize the display as a sign-on panel, so the workstation gateway server
continues processing and sends the sign-on panel to the Web browser. This
is why you need to test your customized sign-on panel with the workstation
gateway server and ensure that the workstation gateway server recognizes it
before you start using the workstation gateway server.
To test your customized sign-on panel, start with the default sign-on panel. Make
small changes and test each change. When the workstation gateway server no
longer sends out the AS/400 sign-on panel, this means it now recognizes your
customized display.
If you use *NO for the Display Sign-on Panel parameter, the workstation gateway
server only serves sign-on panels through a user exit. If no user exit is configured,
the workstation gateway server does nothing. If you have configured a user exit,
then the workstation gateway server attempts to identify any sign-on attempt that
was not successful. An unsuccessful sign-on attempt occurs, for example, when the
user exit provides a bad user profile or password. In these cases, the workstation
gateway server does not send a sign-on panel to the requester.
Chapter 10. Workstation Gateway Server
321
Managing Virtual Devices for the Client
The workstation gateway server uses virtual devices to direct output to client
devices. The AS/400 workstation gateway server support automatically selects (and
creates, if necessary) these devices for you.
You must allow the workstation gateway server to configure virtual controllers and
devices automatically. The QAUTOVRT system value specifies the maximum
number of devices that the system automatically configures. Use the Change
System Value (CHGSYSVAL) command to change the value of the QAUTOVRT
system value. For example, specifying the following command string changes the
number of virtual devices that you can allocate on a system to 50:
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(50)
Note: QAUTOVRT has been changed for Version 4 Release 1 to support numeric
values of 0 through 32500 and a special value of *NOMAX.
To determine and set the maximum number of users you want signed on to the
AS/400 system at any time, perform the following steps:
1. Set the QAUTOVRT value to the maximum value of 32500 or use the *NOMAX
value.
2. Let your users use pass-through, TELNET, the workstation gateway server, and
the virtual terminal application program interface until you decide that the
number of virtual devices created is sufficient for normal system operation.
3. Change the QAUTOVRT value from 32500 to the number of virtual devices you
require for normal system operation.
If you have never allowed automatic configuration of virtual devices on your system,
the QAUTOVRT value is 0. A workstation gateway server connection attempt then
fails because the workstation gateway server does not create more than the
specified QAUTOVRT devices (zero). If you try to sign on, you receive a message
(TCP2504) indicating that the Web browser session has ended and the connection
is closed. In addition, the QTGTELNETS job in the QSYSWRK subsystem on the
AS/400 TELNET server sends a message (CPF8940) indicating that a virtual device
cannot be automatically selected.
If you change the QAUTOVRT value to 10, the next Web browser connection
attempt causes the workstation gateway server to create a virtual device. The
server creates this virtual device because the number of virtual devices on the
controller (0) is less than the number specified in the QAUTOVRT (10). Even if you
change the specified number to 0 again, the next user attempting a Web connection
succeeds. When a Web connection attempt fails because the AS/400 server cannot
create a virtual device, the system sends the CPF87D7 message the system
operator message queue.
The workstation gateway server uses the following conventions for naming virtual
controllers and devices:
v Virtual controllers are named QPACTLnn.
v Virtual device descriptions are named QPADEVxxxx.
When automatically configuring virtual devices with the workstation gateway server,
the workstation gateway server does not delete virtual devices, even if the number
of devices attached to the virtual controllers that are automatically configured
exceeds the QAUTOVRT limit.
322
OS/400 TCP/IP Configuration and Reference V4R4
If you specify a value less than the number of virtual devices attached to
QPACTLnn controllers and you want the extra devices deleted, you must manually
delete any virtual devices that exceed the QAUTOVRT limit. If you delete devices to
enforce a smaller QAUTOVRT value, begin by deleting the devices from the
controller with the highest QPACTLnn value.
Note: The workstation gateway server does not manage the QAUTOVRT values
directly. The Telnet application does the managing on behalf of the
workstation gateway server.
Changing the Workstation Gateway Configuration
This topic explains each of the parameters that you control to manage the
workstation gateway server configuration. Specify CFGTCPWSG to display the
configuration (shown in Figure 201).
Configure TCP/IP Workstation Gateway
Select one of the following:
System:
SYSxxx
1. Change workstation gateway attributes
Related options:
10. Configure HTTP
11. Work with autoconfigure virtual devices
12. Work with limit security officer device access
Selection or command
===> 1
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
Figure 201. Configure TCP/IP Workstation Gateway (CFGTCPWSG) Panel
Select option 1, Change Workstation Gateway Attributes. The Change Workstation
Gateway Attributes (CHGWSGA) command displays the configuration settings you
can adjust. Figure 202 on page 324 and Figure 203 on page 324 show you the
prompts, which are explained in this topic.
Chapter 10. Workstation Gateway Server
323
Change WSG Attributes (CHGWSGA)
Type choices, press Enter.
Autostart . . . . . . . . .
Number of clients per server
Inactivity timeout . . . . .
Data request timeout . . . .
Display sign on panel . . .
Access logging . . . . . . .
Top banner URL . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
*NO
3
10
10
*NO
*YES
*NONE
„1…
„2…
„3…
„4…
„5…
„6…
„7…
Bottom banner URL . . . . . . .
„8…
F3=Exit
F4=Prompt
F24=More keys
F12=Cancel
F5=Refresh
*YES, *NO, *SAME
1-50, *SAME, *DFT
0-60 minutes, *SAME, *DFT
1-1200 seconds, *SAME, *DFT
*SAME, *NO, *YES
*SAME, *NO, *YES
More...
F13=How to use this display
Figure 202. Change Workstation Gateway Attributes — Display 1
Page down to display the remaining prompts:
Change WSG Attributes (CHGWSGA)
Type choices, press Enter.
Help panel URL . . . . . . . . .
„9…
Coded character set identifier
Server mapping tables:
Outgoing EBCDIC/ASCII table .
Library . . . . . . . . . .
00819
„10…
*CCSID
„11…
Name, *SAME, *CCSID, *DFT
Name, *LIBL, *CURLIB
*CCSID
„12…
Name, *SAME, *CCSID, *DFT
Name, *LIBL, *CURLIB
Incoming ASCII/EBCDIC table .
Library . . . . . . . . . .
F3=Exit
F4=Prompt
F24=More keys
F5=Refresh
F12=Cancel
1-65533, *SAME, *DFT
Bottom
F13=How to use this display
Figure 203. Change Workstation Gateway Attributes — Display 2
Number of Clients per Server (NBRCLT)
„2…
The AS/400 system manages the number of workstation gateway server jobs to
ensure that at least 20 client sessions are always available for use. This
number of server jobs either increases or decreases depending on the activity
for the workstation gateway server at a given time.
By default, each workstation gateway server job handles 20 client sessions. You
can change this value to anything from 1 through 50 clients per server job.
324
OS/400 TCP/IP Configuration and Reference V4R4
Number of Workstation Gateway Clients Per Server — Example
For example, assume you configured 5 client sessions per server job. The
workstation gateway server ensures that four jobs are available for work. The 4 jobs
allow 20 clients to use the workstation gateway server concurrently with this
configuration (4 server jobs times 5 client sessions per server job allows 20 client
sessions). There is also one additional job running for a total of 5 jobs. This
additional job monitors the configured or default well-known port and distributes
connection requests from clients to the other jobs. If your multiplexing value is
lower, less bottlenecking occurs through a server. However, the AS/400 system
requires more jobs and resources to support the same number of sessions.
Inactivity Timeout (INACTTIMO)
„3…
The inactivity timeout specifies how long a workstation gateway server session
can be idle before the AS/400 system ends the session. By default, the system
allows a workstation gateway server session to remain inactive for 10 minutes.
After this time, it ends the session. Possible values are from 0 through 60
minutes. A value of 0 means that there is no timeout.
Note: It can take the system an additional 1 to 300 seconds to end the inactive
session (jobs wake up at 5-minute intervals).
Data Request Timeout (DTARQSTIMO)
„4…
The data request timeout specifies how long the workstation gateway server
waits from the time a client initially connects until the workstation gateway
server receives all the request data.
Possible values are from 1 through 1200 seconds.
Network Timeout — Hint
Make the timeout value longer if you experience network delays. Make the value
shorter to minimize resource usage caused by running more workstation gateway
server jobs. If the timeout value becomes too long, too many jobs end up waiting to
run. This happens particularly on small AS/400 systems.
Display Sign-on Panel (DSPSGN)
„5…
Specifies whether to display the AS/400 sign-on panel when a Workstation
Gateway request comes in from a World Wide Web (WWW) browser.
Note: The workstation gateway server recognizes only generic, default AS/400
sign-on panels. If you have customized your AS/400 sign-on panel, the
workstation gateway server might not recognize the panel. If the
workstation gateway server cannot send your sign-on panel, start with
the default sign-on panel and try making small changes to adjust your
customized sign-on panel to a form that the workstation gateway server
recognizes. The default for DSPSGN is *NO. For most everyone, leaving
DSPSGN at *NO means that no one can use the workstation gateway
server server unless the AS/400 system cannot recognize the sign-on
Chapter 10. Workstation Gateway Server
325
panel. The DSPSGN parameter is not strictly for user exits only, but if
you leave DSPSGN at the default, *NO, then only user exits let your
users sign on.
To use an exit program, register your user exit program for exit point
QIBM_QTMT_WSG, format QAPP0100. Use the Work with Registration
Information (WRKREGINF) command to determine if the exit point is registered.
If you do not use the exit point (meaning you set DSPSGN to *YES), the
AS/400 system sends a sign-on panel to any browser that accesses the
workstation gateway server. If you do not register an exit program at this exit
point, no one can sign on. For more information about registering applications,
see “Appendix E. TCP/IP Application Exit Points and Programs” on page 535.
Changing the Sign-on Panel File
To change the format of the sign-on panel, perform the following steps:
1. Create a changed sign-on panel file. You can change a hidden field in the
display file named UBUFFER to manage smaller fields. UBUFFER is 128 bytes
long and is stated as the last field in the display file. This field can be changed
to function as an input/output buffer so the data specified in this field of the
display will be available to application programs when the interactive job is
started.
You can change the UBUFFER field to contain as many smaller fields as you
need if the following requirements are met:
v The new fields must follow all other fields in the display file. The location of
the fields on the display does not matter as long as the order in which they
are put in the data description specifications (DDS) meets this requirement.
v The length must total 128. If the length of the fields is more than 128, some
of the data is not passed.
v All fields must be hidden fields (type H in DDS source) or input or output
fields (type B in DDS source).
Notes:
a. Do not change the order in which the fields in the sign-on panel file are
declared. However, you can change the position in which they appear on the
display.
b. Do not change the total size of the input or output buffers. Serious problems
can occur if you change the order or size of the buffers.
c. Do not use the data descriptions specifications (DDS) help function in the
sign-on panel file.
2. Change a subsystem description to use the changed display file instead of the
system default of QSYS/QDSIGNON. You can change the subsystem
descriptions for subsystems that you want to use the new display.
To change the subsystem description, perform the following steps:
a. Use the Change Subsystem Description (CHGSBSD) command.
b. Specify the new display file on the SGNDSPF parameter.
c. Use a test version of a subsystem to verify that the display is valid before
attempting to change the controlling subsystem.
3. Test the change.
4. Change other subsystem descriptions.
326
OS/400 TCP/IP Configuration and Reference V4R4
Notes:
1. The buffer length for the display file must be 318. If it is less than 318, the
subsystem uses the default sign-on panel, which is QDSIGNON in library QSYS.
2. You cannot delete the copyright line.
Access Logging (ACCLOG)
„6…
This parameter tells the AS/400 system to create a table that logs all accesses
to the workstation gateway server. When you specify *YES to log all accesses
to the workstation gateway server, the system places access log records in the
physical file QATMTLOG in library QUSRSYS.
For more information about the access log, see “Managing the Access Log” on
page 330.
Top Banner URL (TOPBNRURL)
„7…
Specifies a Universal Resource Locator (URL) for displaying information on the
World Wide Web (WWW) browser display, if desired. Unless specified, no
banner URLs are displayed.
If you want to send a banner, you must create one. To create a banner, use an
editor on a workstation that can create .GIF files. Next, store the file in an
integrated file system library, such as in QDLS, QLANSrv, or QOpenSys.
Figure 204 shows an example of a banner that workstation gateway server can
send with the AS/400 sign-on panel.
Figure 204. Example of a Banner
Bottom Banner URL (BOTBNRURL)
„8…
Specifies a banner at the bottom of the panel that you want to send. For more
information, see “Top Banner URL (TOPBNRURL)”.
Help Panel URL (HLPPNLURL)
„9…
Specifies the Universal Resource Locater (URL) to display the online help
information for the workstation gateway server. The user accesses the help
information by clicking TIPS at the top of the display.
For more information about customizing the online help information for the Web
browser clients, see “Granting Access to the Web Browser Online Help
Information” on page 329.
Chapter 10. Workstation Gateway Server
327
Coded Character Set Identifier (CCSID)
„10…
The HTML specification requires browsers to indicate the content types that
they can handle. The browser passes this information by including an ISO
(international standard organization) identifier in a MIME header. The
workstation gateway server converts this content type identifier into
coded-character set identifier (CCSID) information. The AS/400 system uses the
CCSID information to interpret the input data and to provide the output data in
the proper format for the browser to use for its display. The input can be ASCII
or EBCDIC.
If your Web browser has a MIME header, then the system uses the CCSID
value from the MIME header to perform ASCII-to-EBCDIC conversion.
The AS/400 system uses the value specified in this parameter in the following
cases:
v When your Web browser does not have a MIME header.
v When the MIME header values do not match any values in the CCSID table
on the AS/400 system.
The workstation gateway server ignores ISO-xxxx-xx-style MIME headers,
starting with the following PTFs:
v SF47241 WSG_41
v SF47242 WSG_32
v SF47243 WSG_37
v SF47244 WSG_42
The CCSID is the ASCII CCSID to which you must convert the EBCDIC data, if
possible.
Server Mapping Tables (TBLWSGOUT) and (TBLWSGIN)
„11… and „12…
You can use outgoing and incoming mapping tables to manage character
conversion. Specify the tables that you want to use and the library in which the
tables reside.
Workstation Gateway Server Mapping Tables — Hint
You can use the same conversion tables for workstation gateway server that you
use for Telnet or another application. If you decide to do this, ensure that:
v The outgoing table maps from the EBCDIC of the interactive job to any of your
ASCII tables.
v The incoming mapping table maps from any ASCII table to the EBCDIC of the
interactive job.
For Korea, China, and Taiwan, the AS/400 system does not support MIME standard
code pages. This is because of missing MIME standards or CCSIDs for those
countries at this time. The system supports the CCSID parameter for each country,
as contained in Table 31 on page 329.
For detailed information about CCSIDs, see National Language Support,
SC41-5101, or International Application Development. Table 31 on page 329
contains conversion information.
328
OS/400 TCP/IP Configuration and Reference V4R4
Table 31. Supported MIME Standard Code Pages
MIME Standard
Name
ASCII CCSID
Character Set
EBCDIC CCSID
US-ASCII
US English
00367
103
00500
ISO-8859-1
Latin-1
00819
697
00500
ISO-8859-2
Latin-2
00912
959
00870
ISO-8859-5
Cyrillic
00915
1150
01025
ISO-8859-7
Greek
00813
925
00875
ISO-8859-8
Hebrew
00916
941
00424
ISO-8859-9
Latin-5
00920
1152
01026
ISO-2022-JP
Japan MBCS
05052
1064,1062,1121,1120
05026
Taiwan
00950
00937
China
01381
00935
Korea
00949
00933
For a list of supported CCSID values that the initial URL can request, see the NLS
keyboard (KBD) values, in Appendix C in the National Language Support book.
Workstation Gateway Exit Point for Accessing a User Profile Directly
The WSG Application Logon Exit Point (QAPP0100) allows you to bypass the
AS/400 sign-on panel and start an application without the client browser sending a
user profile or password. This allows you to provide any application to client
browsers without requiring a sign-on. To do this, your exit program must
authenticate the client request and provide sign-on information to the workstation
gateway server. The workstation gateway server then uses the output of your exit
program as input to the Virtual Terminal APIs and signs on for the client browser.
For information about how to create an exit program, see “Using a WSG exit
progam to bypass the AS/400 Sign-on Display” on page 571. For a list of supported
CCSID values that the initial URL can request, see the NLS keyboard (KBD) values,
in Appendix C in the National Language Support book.
Granting Access to the Web Browser Online Help Information
To enable the Tips push button on your web browser, perform the following steps:
1. Create a directory for the help information.
2. Copy QTCP/QATMHELP.WSGHELP to the directory.
3.
4.
5.
6.
7.
You can use the WRKMBRPDM command to do this.
Change the member type of the help information to HTML.
You can use the WRKMBRPDM command to do this.
Enable the new directory to the HTTP server.
Use the HTTP server configuration directives to do this.
Grant authority to the HTTP server (default QTMHHTTP user profile) to access
the directory and file.
Ensure that you have started or restarted the HTTP server.
Change the help URL by using the CHGWSGA command.
Chapter 10. Workstation Gateway Server
329
8. Stop, then restart the workstation gateway server to enable the change.
If you want to serve the Tips push button from a different server, use the
instructions provided with that server to enable the online help information. If you
serve the help information from another server, then must move the file off the
AS/400 system and rename it to the UNIX, DOS, OS/2, or other convention for help
(such as wsghelp.html or wsghelp.htm).
The online help information is also available on the Internet at this URL:
http://www.as400.ibm.com/htmlgate
Customizing Web Browser Online Help Information
If desired, you can customize the information that your workstation gateway server
sends to Web browsers. To do this, first enable the online help information. Next,
use a browser editor to change the HTML content in the help file.
Managing the Access Log
The QATMTLOG file is shipped with MAXMBRS(*NOMAX) and SIZE(*NOMAX).
Therefore, if you plan to use logging, you can change these file attributes to set
limits. If you set limits and the file becomes full for the second time on the same
day, the AS/400 system renames the file to a new member sends a message
indicating that it has done so. The job log and the QSYSOPR message queues
both receive the message. The member name has the format Qcyymmdd, where
c=0 means 19xx and where c=1 means 20xx. The scheme is based on the date,
meaning that the rename works only once a day.
If you find that you receive such messages more than once a day, consider
enlarging the limit so that the system can record a day’s worth of log records in a
file. When the system is renaming the log file, it does not log any access records or
affect the workstation gateway server function.
The AS/400 system renames this log file only once on any one day. When the log
file is full, the system sends a message to the job log and to QSYSOPR stating that
the file is full. Logging suspends when the file is full. You must delete or rename the
file member yourself to activate logging again.
The QATMTLOG File
QATMTLOG *MBR on AS/400
Figure 205 on page 331 shows a partial display that results when you display the
QATMTLOG member using the STRPDM command.
330
OS/400 TCP/IP Configuration and Reference V4R4
Specify Members to Work With
Type choices, press Enter.
File . . . . . . . . . .
Library . . . . . . . .
Member:
Name . . . . . . . . .
Type . . . . . . . . .
F3=Exit
F4=Prompt
QATMTLOG
QTCP
*ALL
*ALL
F5=Refresh
Name, F4 for list
*LIBL, *CURLIB, name
*ALL, name, *generic*
*ALL, type, *generic*, *BLANK
F12=Cancel
Figure 205. Using STRPDM to Display the QATMTLOG Member — Display 1
Work with Members Using PDM
File . . . . . .
Library . . . .
QATMTLOG
QTCP
AS007
Position to . . . . .
Type options, press Enter.
3=Copy
4=Delete
9=Save
13=Change text
5=Display
7=Rename
18=Change using DFU
Opt Member
5
QATMTLOG
Text
Access log file for CHGWSGA command
Date
04/16/96
Parameters or command
===>
F3=Exit
F4=Prompt
F9=Retrieve
F10=Command entry
8=Display description
25=Find string ...
Bottom
F5=Refresh
F23=More options
F6=Create
F24=More keys
Figure 206. Using STRPDM to Display the QATMTLOG Member — Display 2
Type a 5 to display the log file member. The AS/400 system displays the contents
of the log file as shown in Figure 207 on page 332.
The log contains the following information:
v The date and time the record was logged.
v The IP address of the local system.
v The IP address of the remote system.
Chapter 10. Workstation Gateway Server
331
v
v
v
v
The number of minutes until the connection ended.
The number of seconds until the connection ended.
The identifier of the AS/400 display that was sent to the remote system.
A device type identifier.
The AS/400 system might not always recognize the display identifier
(QPADEVnnnnnn) on the sign-on panel. For example, the system not recognize
some custom displays. If it does not recognize the display, the device columns
are blank.
v A log key.
The log key is a variable hexadecimal string that is dynamically generated for
each client. It uses timestamp as a seed. 4C4E6F7E in Figure 207 is an example
of a log key.
v A description of the activity that was logged.
Display Physical File Member
File . . . . . . : QATMTLOG
Library . . . . :
QUSRSYS
Member . . . . . : QATMTLOG
Record . . . . . : 1
Control . . . . .
Column . . . . . : 1
Find . . . . . . .
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+....0....+....1....+....2....+....3
04/29/96 8:32:13 AM
9.130.42.106 9.130.69.47 0
0
QPADEV0042 4C4E6F7E: 3179-2 Session started.
04/29/96 8:32:37 AM
9.130.42.106 9.130.69.47 0
29
QPADEV0042 4C4E6F7E: 3179-2 Session ended.
04/29/96 8:35:51 AM
9.130.42.106 9.130.69.47 0
0
00000000: Client tried to access active session owned
by another client.
04/29/96 10:05:02 AM
9.130.42.106 9.130.69.47 0
0
00000000: 3179-2 Request for WSG session has been
refused.
04/29/96 10:06:45 AM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 B82608E2: 3179-2 Sign-on panels disabled.
04/29/96 11:33:59 AM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 E9213AFA: 3179-2 Sign-on panels disabled.
04/29/96 11:34:46 AM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 0A24B605: 3179-2 Sign-on panels disabled.
04/29/96 11:35:47 AM
9.130.42.106 9.130.69.47 0
0
00000000: 3179-2 Request for WSG session has been
refused.
04/29/96 11:37:49 AM
9.130.42.106 9.130.69.48 0
0
QPADEV0027 DFBF88BE: 3179-2 Session started.
04/29/96 11:38:28 AM
9.130.42.106 9.130.69.48 0
39
QPADEV0027 DFBF88BE: 3179-2 Session ended.
04/29/96 11:45:04 AM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 C280FC9B: 3179-2 Session started.
04/29/96 11:46:53 AM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 C280FC9B: 3179-2 Session ended.
04/29/96 12:03:23 PM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 F1082E61: 3179-2 Session started.
04/29/96 12:04:02 PM
9.130.42.106 9.130.69.47 0
42
QPADEV0027 F1082E61: 3179-2 Session ended.
04/29/96 12:26:06 PM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 82CAF856: 3179-2 Sign-on panels disabled.
04/29/96 12:26:32 PM
9.130.42.106 9.130.69.48 0
0
QPADEV0027 33709128: 3179-2 Sign-on restricted through exit point
QIBM_QTMT_WSG format QAPP0100.
04/29/96 1:12:20 PM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 0D8A0DF6: 3179-2 Session started.
04/29/96 1:12:23 PM
9.130.42.106 9.130.69.47 0
5
QPADEV0027 0D8A0DF6: 3179-2 Session ended.
04/29/96 1:15:30 PM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 F2F0B75A: 3179-2 Session started.
04/29/96 1:17:33 PM
9.130.42.106 9.130.69.47 2
3
QPADEV0027 F2F0B75A: 3179-2 Session ended.
04/29/96 1:34:25 PM
9.130.42.106 9.130.69.47 0
0
QPADEV0027 7E6AB936: 3179-2 Session started.
04/29/96 1:35:15 PM
9.130.42.106 9.130.69.47 0
51
QPADEV0027 7E6AB936: 3179-2 Session ended.
04/29/96 2:05:46 PM
9.130.42.106 9.130.69.47 0
0
QPADEV0028 A69EBE2B: 3179-2 Session started.
04/29/96 2:05:51 PM
9.130.42.106 9.130.69.47 0
6
QPADEV0028 A69EBE2B: 3179-2 Session ended.
04/29/96 2:19:00 PM
9.130.42.106 9.130.69.47 0
0
00000000: Exit point QIBM_QTMT_WSG format QAPP0100
not active.
****** END OF DATA ******
Bottom
F3=Exit
F12=Cancel
F19=Left
F20=Right
F24=More keys
Figure 207. The QATMTLOG Member — Example
Accessing the Workstation Gateway from a Web Browser
To access the workstation gateway server from your Web browser, you must specify
the Universal Resource Locator (URL). The URL identifies the following attributes:
v The protocol that your browser uses when contacting the server.
v The location of the server and of the requested object.
To start a session from a Web browser to the workstation gateway server, specify
the URL of your host AS/400 system, as in the following example:
http://hostname:port/WSG
For other supported URL formats, see “Other Supported URL Formats” on
page 334.
If the workstation gateway server has an exit program that requires information to
be passed to it, use the following form:
332
OS/400 TCP/IP Configuration and Reference V4R4
http://hostname:port
/WSG/QAPP0100?op_specific_parm
http:
Identifies the protocol. The workstation gateway server uses the HTTP protocol.
hostname
Identifies the system to which you are sending a request, such as
xxx.xxx.xxx.xxx.
Note: To use the host name, you must have either a domain name server or a
local host table.
To reach a host for which you do not have a name server or a host table, use
the dotted decimal address of the host.
:port
Port 5061 is the default port for the workstation gateway server. You can
change this port by using the WRKSVRTBLE command. Keep the following in
mind if you choose a different port:
v Use wsg for the name of the service.
v Use tcp for the protocol.
v Use the dotted decimal or the alias form for the host name.
Either is accepted. Therefore, you can use the workstation gateway server
whether or not you have configured a host table.
If you do not specify a port on the URL, the request goes to the AS/400 HTTP
server at well-known port 80. Because you specified WSG, HTTP redirects your
request to the workstation gateway server.
Note: You must configure the HTTP server to allow it to redirect traffic. To do
this, specify the redirect directive:
Redirect /WSG http://--address--:5061/WSG
WSG
The WSG request keyword.
Note: Specify WSG in upper case.
/QAPP0100?
The prefix that indicates the exit point information follows. (The ‘?’ is just a
separator character between QAPP0100 and any arguments that the system
passes.)
op_specific_parm
Information about what operations the workstation gateway server must
perform.
A signature for a workstation gateway server session is added to your address after
your initial connection. This signature identifies your session to the AS/400 system.
Notes:
1. The workstation gateway server port is different from the HTTP server port. This
is because workstation gateway server is a new type of server for which no
well-known port exists.
2. When using the workstation gateway, you might find that the view of the AS/400
display varies between browsers. If there are alignment problems with the fields
Chapter 10. Workstation Gateway Server
333
on the display with the browser you are using, try another browser. The
workstation gateway server does not cause this problem.
URL Request Form for NLS
Translation is usually from the EBCDIC CCSID of your AS/400 system to the ASCII
CCSID specified on the CCSID parameter of the CHGWSGA command. When the
value of this parameter changes, the EBCDIC CCSID default also changes because
the workstation gateway server uses the best fit EBCDIC CCSID for the ASCII
CCSID.
Individual users can override this default by using the URL request form for NLS.
The format of the URL request for NLS is as follows:
http://hostname:port/WSG-XXX
where XXX is any three-character keyboard string listed in Appendix C of the
National Language Support book.
This URL allows you to specify a keyboard, code page, and character set for the
client display session.
To request the keyboard for the Belgian Multinational Character Set (BLI), for
example, use the following URL request:
http://hostname:port/WSG-BLI
With the Workstation Gateway User Exit, the format is as follows:
http://hostname:port/WSG-BLI
See National Language Support for a table of supported keyboard strings that you
can use.
Other Supported URL Formats
In addition to the URL formats shown in “Accessing the Workstation Gateway from
a Web Browser” on page 332 and in “URL Request Form for NLS”, the following are
also supported:
http://hostname:port/WSG
/QAPP0100?any_QAPP0100_info
http://hostname:port/WSG-XXX
/QAPP0100?any_QAPP0100_info
For information about how to create an exit program, see “Using a WSG exit
progam to bypass the AS/400 Sign-on Display” on page 571.
Security
The following topics consist of tips for how to control the security of your AS/400
system.
Taking Steps to Ensure Workstation Gateway Security
Stop the Server: The easiest way to secure your AS/400 system from Web
browsers is to stop the workstation gateway server.
334
OS/400 TCP/IP Configuration and Reference V4R4
Control User Profiles That Can Access AS/400: To run the server while
controlling which user profile gets sent to a Web browser, you can write an exit
program. For more information on writing exit programs, see “Adding Your Exit
Program to the Registration Facility” on page 537.
Things to Avoid to Ensure Workstation Gateway Security
Do Not Store Passwords in HTML Documents: Secured Sockets Layer (SSL),
or Secure HTTP, has been put into effect on AS/400 systems beginning with
Version 4 Release 1. This helps to ensure that data being sent from a secure
server to a secure browser is encrypted. In general, however, do not store
passwords in HTML documents.
Workstation Gateway — Requirements
Some applications continually display panel after panel without requiring keyboard
interaction or intervention. Because the workstation gateway server processes one
panel at a time, the workstation gateway server cancels applications like this similar
to a SYSREQ panel, Option 2. Do not use screen refresh applications or features
with workstation gateway server.
How the 5250 Display is Formatted for the Workstation Gateway
The workstation gateway server formats the 5250 display as follows:
1. The display is presented as 80-column, pre-formatted text.
2. Blank lines are omitted to reduce the vertical size of the display image in the
browser window.
3. 5250 input fields are translated into HTML INPUT tags with the same length as
the 5250 field.
v If an input field is longer than 160 characters, the field is translated into an
HTML text area that is 80 columns long and has enough lines to contain all
the needed input text.
v If an input field is between 60 and 160 characters long, it is presented as an
input field with 60 visible characters and a maximum length of the 5250 field
size.
4. Function key tags recognized in the function key area of the display are added
to the menu items at the top of the document.
For example, Figure 208 on page 336 shows a 5250 display without workstation
gateway.
Chapter 10. Workstation Gateway Server
335
MAIN
AS/400 Main Menu
System:
Select one of the following:
AS
1. User tasks
2. Office tasks
4. Files, libraries, and folders
6. Communications
8.
9.
10.
11.
Problem handling
Display a menu
Information Assistant options
Client Access tasks
90. Sign off
Selection or command
===> _________________________________________________________________
______________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F23=Set initial menu
(C) COPYRIGHT IBM CORP. 1980, 1998.
F13=Information Assista
Figure 208. AS/400 Main Menu Display Without Workstation Gateway
Figure 209 shows the same display using workstation gateway (with IBM
WebExplorer for Windows 95).
Figure 209. AS/400 Main Menu Display With Workstation Gateway
Converting DDS Applications to HTML
You can change your application display programs to enable them for the Internet
by inserting HTML to take advantage of the graphics capabilities of Web browsers.
For more information and examples, see Application Display Programming,
SC41-5715-00.
Note: The DDS keyword HTML is currently not supported in a sub-file record.
336
OS/400 TCP/IP Configuration and Reference V4R4
Configuration Examples
This topic contains several examples for changing the workstation gateway server
configuration.
Starting the Server Automatically when TCP/IP Starts — Example
To automatically start the workstation gateway server when the Start TCP/IP
(STRTCP) CL command runs, change the Workstation Gateway attributes as
follows:
CHGWSGA
AUTOSTART(*YES)
The next time the STRTCP command runs, the WSG server is also started.
Changing the Number of Client Sessions per Server Job —
Example
This command indicates that the next time you start the workstation gateway server,
it handles up to 30 client sessions. If you have a small system, specify a larger
number to reduce the amount of resource dedicated to the server. To reduce
bottlenecking of workstation gateway server sessions through a server, specify a
smaller number. Bottlenecking is more likely to occur if your AS/400 system is a
smaller model.
CHGWSGA NBRCLT(30)
Using Server Mapping Tables — Example
You can use any tables that you already created for Telnet. However, the AS/400
system supports only SBCS tables and not DBCS tables this way. For more
information about mapping tables, see Appendix C. Mapping Tables Associated with
TCP/IP Function.
This command indicates that the next time you start the workstation gateway server,
it has the following characteristics:
v The ASCII-to-EBCDIC and EBCDIC-to-ASCII conversion is not done with a
CCSID value, but instead the outgoing and incoming mapping tables are used.
v A copy of the information found in the table object named TSTWSGO is used for
mapping outgoing data in workstation gateway server. The table object is found
in one of the libraries in the library list.
v A copy of the information found in the table object named TSTWSGI is used for
mapping incoming data in workstation gateway server. The table object is found
in one of the libraries in the library list.
CHGWSGA TBLWSGOUT(*LIBL/TSTWSGO)
TBLWSGIN(*LIBL/TSTWSGI)
Using a CCSID When MIME Code Page Not Available—Example
The following example specifies the ASCII CCSID for China, taken from Table 31 on
page 329. Because a MIME standard does not yet support China, Korea, and
Taiwan, the AS/400 system does not automatically recognize the CCSID values for
those countries. Therefore, these countries must specify their CCSID to run the
workstation gateway server.
CHGWSGA CCSID(01381)
Chapter 10. Workstation Gateway Server
337
Resolving Network Delays — Example
If you have a slower modem or a small model AS/400 system, you might
experience delays on the network. In this case, you can change the data request
timeout value to a higher number. Choose a number somewhat higher than the
default, and experiment with that value for a while. You must balance network
delays with resource usage that can cause bottlenecks on the system. The
following command changes the data request timeout value to 60 seconds:
CHGWSGA DTARQSTIMO(60)
Online Help Information
The following information is what you see when you select the Tips button when
using the workstation gateway server:
v A Word About Browsers...
v Signing on to the AS/400 workstation gateway server
v Quick Tips for a Fast Start
v Using the Buttons
v Using the Menu Boxes
v FAQs (Frequently Asked Questions)
v Working with AS/400 Menus
v AS/400 Menu Parts
A Word About Browsers...
As you read through this document, remember that Web browsers interpret HTML
differently. Your Web browser affects the way that the AS/400 menu and list
windows look on your display. For example, the General menu might look like a
spin box in the IBM WebExplorer, but in Netscape or Mosaic, it might look like a
drop-down menu.
It is impractical to provide information for every interface variation caused by a
browser. As a result, the information in this document might not accurately describe
the interface that you are using.
Also, because of the nature of today’s browsers, you might be unable to view this
help document and the AS/400 window in which you are working at the same time.
You can print this document for your convenience now and in the future.
Signing on to the AS/400 Workstation Gateway Server
All of the parts you are used to seeing on a typical AS/400 sign-on panel are on the
AS/400 workstation gateway server display, too, like the following:
v Menu title.
v System and subsystem name.
v Sign-on area for specifying your user ID and password.
To sign on to your AS/400 system:
1. Type your user ID in the User box.
2. Type your password in the Password box.
3. If you want to call a specific program or procedure, go to a specific menu (or
specify a library), and type the name in the appropriate box.
338
OS/400 TCP/IP Configuration and Reference V4R4
4. Click Enter.
Quick Tips for a Fast Start
The AS/400 workstation gateway server provides the same capabilities that you find
on a typical AS/400 system. How you access those capabilities, however, is
different from what you are used to doing. This section provides some quick tips to
help you get started.
Using the buttons: Along the top of most AS/400 windows, you find a series of
buttons. These include the following:
Enter button
Clicking Enter is the same as pressing the Enter key.
Page Up
Clicking Page Up moves you up (back) one display.
Page Down
Clicking Page Down moves you down (forward) one display.
Reset button
Clicking Reset returns all fields back to their default state. This button might
look different from the other buttons in the action bar because it is a
browser function and not a server function.
Close button
Clicking Close disconnects from the workstation gateway server.
Remember that you can sign off from the AS/400 system and still be
running a workstation gateway serversession. After clicking Close, you
must start a new session to get to a sign-on panel again.
Refresh button
Clicking Refresh updates your AS/400 workstation gateway
serverconnection. This button is useful in the following three different ways:
v It helps you find the active AS/400 panel. If you get lost in the history list
on your WWW browser and lose track of which panel is active, clicking
Refresh on any recently used panel brings up the active panel again.
This saves you from having to hunt through old, inactive panels.
v It is the mechanism for returning to the active panel from the Time
button.
v It is essential to anyone attempting to Telnet to a 370 system, as 3270
data streams (VM systems) differ significantly from 5250 data streams
(AS/400 systems). An AS/400 system gives the workstation gateway
server browser a clear indication when it receives all the data, while VM
systems have no such indicator. This means that the AS/400 must
estimate when it has all the display information from a VM system.
Sometimes this estimate is inaccurate, which means you need the
Refresh button to receive the additional display information.
Time button
Clicking Time shows you how long your session has been connected to the
AS/400 workstation gateway server. It also shows you how long your
session can remain idle before it is disconnected.
Style button
Clicking the Style changes the general format of the display in terms of
function key placement and usability. Specifically, by default, a selection of
function keys (F1-F24) is available across the lower area of all displays.
Chapter 10. Workstation Gateway Server
339
Clicking Style displays a Function pull-down menu instead of the function
keys array. This mode of operation continues through the remainder of your
session or until you click Style again.
Notes:
1. An exception is the sign-on panel. The function keys are not available
on this panel, and you must use the General pull-down menu and the
keys that are supplied there.
2. On the other panels, all of the function keys are posted, although some
of them do not have actions associated with them.
Help
General Help and Field Context-Sensitive Help are the two types of help
that are available to the user.
v You can request General Help through the Help pull-down menu or
button. To do this, select the Help option or click the Help button,
respectively. This has the effect of first moving the cursor to row 1 and
column 1 on the display before displaying the help. Since row 1 and
column 1 are likely to be context insensitive, the General Help panel
should appear.
v To access the Field Context-Sensitive help, place a ? character in
position 1 of the input field. Only in the first position is the ? character
interpreted as a command to move the cursor to this input field. Because
the ? is an escape command, this means the ? is not left in the input
field on return from the function key button action. In essence, the ?
means to move the cursor here, then whatever other button action you
request acts after the move occurs.
Along the bottom of most windows is another series of buttons. These include the
following:
Enter button
Clicking Enter is the same as pressing the Enter key.
Page Up button
Clicking Page Up scrolls up (back) one display.
Page Down button
Clicking Page Down scrolls down (forward) one display.
Function key buttons (F1-F24)
Depending on which style you are currently using, function key buttons
might not be displayed at the bottom of the display. The default for a
session is to display the function key buttons at the bottom of the display. If
you press the Style button, however, these buttons are moved to a
Functions menu pull-down instead of being shown at the bottom of the
display. This saves display space in addition to being displayed faster.
Using the menu boxes: A series of menu boxes is located along the top of most
AS/400 windows. The type of boxes available varies with the type of AS/400
window you are displaying. The sign-on panel displays the General and Help
menus but not the Functions menu. If a menu box has only one selectable item in
it, it is shown as a button instead of as a menu box. You might see menu boxes like
those in Figure 210 on page 341.
340
OS/400 TCP/IP Configuration and Reference V4R4
Figure 210. Bottom Action Bar Buttons
There is also a chance that you might see meny boxes like those in Figure 211 .
Figure 211. Function Key Buttons
Also, depending on your browser, these menu boxes might look like spin dials or
drop-down menus. You can activate them by clicking an arrow or just a shadowed
area in the box, depending on your browser.
A spin dial has both an up and a down arrow in the box. A drop-down menu has
just a down arrow, or a shadowed area, in the box.
v To
1.
2.
v To
1.
use a spin dial, follow these instructions:
Click the arrows to rotate (or spin) through the choices in the box.
When the choice you want appears in the box, click Enter.
use a drop-down menu, follow these instructions:
Click the down arrow to display a menu of choices.
2. Select the choice you want.
3. Click Enter.
Here are the possible menu boxes and their associated choices:
v General box
v Functions box
v Help box or button
General Box: The General box displays various actions you can perform to exit or
to go to other windows. These include the following actions:
v Page Up
v Page Down
v Clear
v Record Back
v PA1
v PA2
v PA3
v Print Screen
v Test Request
v Host print screen to print the information currently shown in the window.
v Attention program to call a user-defined attention-key-handling program.
v System requests to go to the System Request menu.
v Sign off to sign off the AS/400 system.
v F12
v F3
Chapter 10. Workstation Gateway Server
341
Functions Box: All of the function keys are still available, although you cannot
press a function key on your keyboard to access them. Instead, look for them in the
Functions box. Please note that the Functions box is available only if the function
key buttons are not displayed at the bottom of the browser window (as controlled by
the Style button). The specific functions include the following:
v
v
v
v
v
v
F1
F2
F3
F4
F5
F6
v
v
v
v
v
v
F7
F8
F9
F10
F11
F12
v
v
v
v
v
v
F13
F14
F15
F16
F17
F18
v
v
v
v
v
v
F19
F20
F21
F22
F23
F24
Help Box (or button): The Help box calls general help for the current AS/400
window. This might be shown as a button instead of a menu box if there is only one
selectable item.
Frequently Asked Questions
If you accustomed to using your AS/400 in a green screen environment, the
following questions explain how to perform a green screen task in the gateway
environment.
1. Where are my function keys?
Those familiar functions keys found at the bottom of a typical AS/400 display
are available through the Functions box near the top of the window.
Function keys are accessible in two different ways. As controlled by the Style
button, the 5250 function keys are represented by buttons either at the bottom
of the screen or under the functions box. If they are shown at the bottom, then
the Functions box is not present.
Instead of pressing a function key, perform the following steps:
a. Click the Functions box near the top of the window.
b. Select the function you want.
c. Click Enter.
2. How do I use my mouse to make a selection?
Use your mouse to move the cursor to the area in which you want to work and
then click the left mouse button to make your selections.
3. How do I use my keyboard to make a selection?
v To select a push button using your keyboard, use the Tab key to move the
cursor to the first push button in a group of push buttons. Next, use the arrow
keys to put the cursor focus on the desired push button. Once the cursor
focus is on the push button you want to select, press Enter. This is the same
as clicking on the push button with your mouse.
v To select a menu box item using your keyboard, use the Tab key to move to
the menu box in which you want to work. Next, use the arrow keys to select
your choice. When the desired choice appears in the menu box, press Enter.
Note: If you select multiple menu box items, the results are unpredictable.
Normally, only the last (farthest to the right) selection is used. Thus, if
you select PA1 from the General menu and then F4 from the
Functions menu, then F4 is more likely to be done over PA1.
4. Why can’t I type into an input field?
342
OS/400 TCP/IP Configuration and Reference V4R4
5.
6.
7.
8.
9.
If the input field has any characters in it, it is probably filled up with data
already. You must delete these characters to make room to type in new
characters. Unfortunately, browsers do not provide overtyping capability in input
fields.
What do I do when my Web Browser refers to 5250 keys?
You can either press a button that is marked with the key name or use the
General or Function boxes to select a key.
How do I press Enter on a AS/400 Workstation Gateway screen?
Click Enter. It performs the same function as the Enter key on a Telnet 5250
screen.
How do I get AS/400-specific help?
Use the Help box or button at the top of the display. Click the arrow, select the
type of help you want, and then click Enter.
Can I surf to other places on the Web while I am signed on to the AS/400
Workstation Gateway ?
Yes, you can. But remember, if your gateway connection remains idle for too
long, your session is disconnected. To determine how long your connection can
remain idle, click Time.
Is it safe to store my AS/400 password in an HTML document?
No, it is not. It is possible for other Web users to read your document as it is
transmitted over the Web.
Working with AS/400 Menus
AS/400 menus provide easy access to a variety of AS/400 functions. To select an
option on an AS/400 menu, specify the menu choice number on the command line
and click Enter.
List windows (also called Work with screens) display a list of objects with which you
can work by using a variety of options. List windows usually have a command line
below the list, in which you can perform the same action on multiple objects at the
same time. To do this, select one or more items in the list, enter command
parameters on the command line, and click Enter.
AS/400 Menu Parts
This section describes the parts of an AS/400 menu.
Top Banner: If configured, this displays the contents of the top banner.
Top Action Bar: The menu bar is described in the section “Using the buttons” on
page 339.
Title: The title shows the name of the window. This is what is saved in your
browser’s history list.
Menu Boxes: The menu boxes for a list window provide access to a variety of
actions you can perform on list items. The menu boxes for a list window include the
following:
v General
v Functions
v Help
Chapter 10. Workstation Gateway Server
343
For a definition of these boxes, see “Using the menu boxes” on page 340.
Window Area: This is the actual AS/400 window and any command line area.
Large input fields are displayed as text areas so that you can see all the input being
typed. This area also includes any description of function key actions and AS/400
messages.
Bottom Action Bar: The bottom menu bar is a subset of the top menu bar. It
consists of the following buttons:
Function Key Area: Use the Style button to make the following function key
buttons toggle between being displayed or hidden in the Functions menu pull-down:
Bottom Banner: If configured, this displays the contents of the bottom banner.
344
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 11. Line Printer Requester (LPR)
You can request to have your spooled files sent to any system in your TCP/IP
network. The term that UNIX TCP/IP software uses to describe this support is line
printer requester (LPR). LPR is the sending, or client, portion of a spooled file
transfer. On the AS/400 system, the Send TCP/IP Spooled File (SNDTCPSPLF)
command provides this function by allowing you to specify on which system you
want the spooled file printed. It also allows you to specify how you want it printed.
The printing facilities of the destination system handle the printing of the file. On the
AS/400 system, the line printer daemon (LPD) is the process on the destination
system that receives the file sent by the SNDTCPSPLF command. For more
information on LPD, see “Chapter 12. Line Printer Daemon (LPD)” on page 363.
LPR Command
The LPR command provides the same parameters and function as the
SNDTCPSPLF command.
The LPR command sends a control file to the LPD server. This control file contains
attributes and options that the LPR/LPD protocol recognizes. These attributes and
options are not like the attributes that an AS/400 holds for a spooled file. Instead,
they refer to information such as the names of the sending system, the sending
user, and the name for the request. Some limited information about how the you
need to print the file, such as the number of copies and information about the
separator page, is included.
The LPR command sends these attributes and options to the destination system in
a control file, which is always in ASCII format. This control file is separate from the
file containing the data stream that it prints.
Client (LPR) and Server (LPD) Relationship
Figure 212 shows the client and server relationship between LPR and LPD.
┌───┐
┌────────────┐
┌───┐
│ ├────┤control file├───────────────────Ê│
│
│ │
└────────────┘
│
│
│ L │
┌─────────────────┐
│ L │
│ P ├────┤data files
├──────────────Ê│ P │
│ R │
└─────────────────┘
│ D │
│ │
┌───────────┐
│
│
│ │Í────────────────────┤return code├────┤
│
└───┘
└───────────┘
└───┘
Figure 212. The Client (LPR) and Server (LPD) Relationship
© Copyright IBM Corp. 1997, 1999
345
Configuration Requirements for LPR
LPR puts a host name in the control file that it sends in addition to the data file. The
receiving system uses this information to determine if the print request came from
an authorized host. LPR uses the local domain and host name if you have
configured them (Option 12 on the CFGTCP menu). Otherwise, it looks for the host
name in the local host table or the name server that you have set up with Options
10 and 12, respectively, on the CFGTCP menu. If LPR does not find a name, it
uses IP followed by the dotted Internet address of the AS/400 system.
To configure the Local Domain and Host Name, use Option 12 (Change TCP/IP
Domain Information) from the CFGTCP menu.
Sending a Spooled File (LPR)
The Send TCP/IP Spooled File (SNDTCPSPLF) command provides support for the
remote printing of spooled files on a specified host and print queue using TCP/IP.
You can send files to other AS/400 systems and non-AS/400 systems. Regardless
of the type of destination system (AS/400 system or non-AS/400 system), you need
to specify a remote system name or an Internet address. You must also specify the
name of the spooled file that you are sending (FILE parameter). The values for the
other parameters depend on the destination system. For some common parameter
settings, see Table 32 on page 351.
When sending spooled files with the SNDTCPSPLF command from the client (local)
AS/400 to an LPD server (remote) AS/400, perform the following steps:
1. Locate the spooled file that you want to send.
2. Start the spooled file transfer with the SNDTCPSPLF command.
Step 1 — Locate the Spooled File that you Want to Send
1. Specify the WRKSPLF command to see your spooled files:
Work with All Spooled Files
Type options, press Enter.
1=Send
2=Change
3=Hold
4=Delete
5=Display
8=Attributes
9=Work with printing status
Opt
File
QPJOBLOG
QPJOBLOG
QPCSMPRT
QPDCLINE
QPJOBLOG
QPJOBLOG
QPCSMPRT
QPCSMPRT
QPCSMPRT
QPCSMPRT
User
HANS
HANS
HANS
HANS
HANS
HANS
HANS
HANS
HANS
HANS
Device or
Queue
QEZJOBLOG
QEZJOBLOG
PFEIFFER
PFEIFFER
QEZJOBLOG
QEZJOBLOG
PFEIFFER
PFEIFFER
PFEIFFER
PFEIFFER
User Data
QPADEV0004
P23XYG41F
P23XYG41
P23XYG41F
Parameters for options 1, 2, 3 or command
===>
F3=Exit
F10=View 3
F11=View 2
F12=Cancel
Figure 213. Work with Spooled Files Display
346
OS/400 TCP/IP Configuration and Reference V4R4
6=Release
Sts
RDY
RDY
RDY
RDY
RDY
RDY
RDY
RDY
RDY
RDY
7=Messages
Total
Pages
10
3
4
1
1
7
4
4
4
4
F22=Printers
Cur
Page
Copy
1
1
1
1
1
1
1
1
1
1
Bottom
F24=More keys
2. Press F10 to display the job information for the spooled file.
Work with All Spooled Files
Type options, press Enter.
1=Send
2=Change
3=Hold
4=Delete
5=Display
8=Attributes
9=Work with printing status
Opt
File
QPJOBLOG
QPJOBLOG
QPCSMPRT
QPDCLINE
QPJOBLOG
QPJOBLOG
QPCSMPRT
QPCSMPRT
QPCSMPRT
QPCSMPRT
File
Nbr
Job
1 QPADEV0004
1 P23XYG41F
3 P23XYG41F
4 P23XYG41F
1 P23XYG41
5 P23XYG41F
1 P23XYG41F
2 P23XYG41F
3 P23XYG41F
4 P23XYG41F
User
HANS
HANS
HANS
HANS
HANS
HANS
HANS
HANS
HANS
HANS
Parameters for options 1, 2, 3 or command
===>
F3=Exit
F10=View 2
F11=View 1
F12=Cancel
Number
058135
058220
058406
058406
058405
058406
058480
058480
058480
058480
6=Release
7=Messages
Queue
QEZJOBLOG
QEZJOBLOG
PFEIFFER
PFEIFFER
QEZJOBLOG
QEZJOBLOG
PFEIFFER
PFEIFFER
PFEIFFER
PFEIFFER
F22=Printers
Library
QUSRSYS
QUSRSYS
PFEIFFER
PFEIFFER
QUSRSYS
QUSRSYS
PFEIFFER
PFEIFFER
PFEIFFER
PFEIFFER
Bottom
F24=More keys
Figure 214. Spooled Files Job Information
3. Locate the spooled file that you want to send to another AS/400 system and
make note of the file, job, user name, and job number.
Note: Option 1 (Send) on the Work with Spooled Files display applies to sending
spooled files in an SNA network (using the SNDNETSPLF command). This
option does not apply to sending spooled files in a TCP/IP network.
Step 2 — Start the Spooled File Transfer
Specify SNDTCPSPLF and press F4 (Prompt). Complete the highlighted fields of
Figure 215 on page 348.
Specify the host name or the special value *INTNETADR to prompt for the Internet
address to which the spooled file is transferred. In the printer queue parameter,
specify the qualified output queue (library/outqueue) of the remote system to
receive that file.
In addition, specify the information from Figure 214 for the specific spooled file that
you want to send.
When transferring spooled files from an AS/400 to an AS/400, transformation of the
data stream is not necessary.
Chapter 11. Line Printer Requester (LPR)
347
Send TCP/IP Spooled File (LPR)
Type choices, press Enter.
Remote system . . . . . . . . . > sysnam123
Printer queue . . . . . . . . . > pfeiffer/pfeiffer
Spooled file . . . . .
Job name . . . . . . .
User . . . . . . . .
Number . . . . . . .
Spooled file number .
Destination type . . .
Transform SCS to ASCII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. > qpcsmprt
. > p23xyg41f
. > hans
. > 058480
. 2
.> *as400
.> *no
F3=Exit
F4=Prompt
F5=Refresh
F13=How to use this display
Name
Name, *
Name
000000-999999
1-9999, *ONLY, *LAST
*AS400, *PSF2, *OTHER
*YES, *NO
F10=Additional parameters
F24=More keys
Bottom
F12=Cancel
Figure 215. Spooled File Job Information in LPR Display
Note: If you create the spooled file with the current interactive job, specify an
asterisk (*) for the job name parameter. Leave the user and job number
blank.
Note: Use the command line at the bottom of Figure 214 on page 347 to enter the
SNDTCPSPLF or LPR command. Specify the spooled file job information as
follows:
LPR FILE(File) Job(Number/User/Job) SPLNBR(FileNbr)
Press F4 (Prompt). The system fills in the job information in the matching
fields of Figure 215.
Sending Spooled Files to an AS/400 at V2R3 or V3R0M5
Using LPR to send spooled files to a V2R3 system or a V3R0M5 system requires
that you apply the following PTFs:
v
v
V2R3 – PTF SF16482 or higher
V3R0M5 – PTF SF16483 or higher
The phrase or higher means any PTFs that take the place of these PTFs.
How the System Sends a Spooled File from an AS/400 System to
Another AS/400 System
When you use TCP/IP to send a spooled file to another AS/400 system and the file
is not transformed to ASCII, implementation-specific extensions to LPR are
available to retain the spooled file attributes. LPR still sends the control file because
it is part of the protocol, and the receiving AS/400 checks for the control file
extended print attribute. From the extended print attribute, the receiving AS/400
determines that another AS/400 system sent the spooled file.
In this case, the system sends all of the spooled file attributes in the data file. It
does not use the option and attribute information in the control file. Except for Job
ID and output queue, all of the attributes of the spooled file are the same on both
the sending and receiving systems. The system sends the job user ID that ran the
348
OS/400 TCP/IP Configuration and Reference V4R4
SNDTCPSPLF command in the control file. The receiving system creates the
spooled file under this user profile with a job name of QPRTJOB. If the user profile
does not exist, the system uses the default user profile QTMPLPD. You can prevent
user IDs that do not exist on the receiving system from sending with LPR by setting
the *PUBLIC access of QTMPLPD to *EXCLUDE.
When the destination is an AS/400 system, the specified print queue value (PRTQ
parameter) can be the name of any defined output queue on the destination AS/400
system. You need to specify the full library name and output queue name when
sending to another AS/400 system. If you do not specify a library name, the system
searches the library list that is associated with the user ID. If it does not find the
output queue or if the user ID is not authorized to it, the system uses the default
output queue of QPRINT in library QGPL.
If the file is transformed to ASCII, the extended print attribute is not sent in the
control file. The transform program uses the spooled file attributes to produce an
ASCII print data stream that is specific to the specified printer model parameter.
The spooled file is created on the receiving AS/400 as type *USERASCII with
default attributes. Also, the spooled file name is changed to LPDxxxx where x
represents any valid hex character. This forms a unique signature that identifies the
LPR client that sent the file.
How the System Sends a Spooled File from an AS/400 System to a
Non-AS/400 System
When using SNDTCPSPLF or LPR to send a spooled file to a non-AS/400 system,
it is sometimes necessary to refer to the LPD documentation for that
implementation to determine the print queue value (PRTQ parameter). For example,
the print queue value for the OS/2 licensed program is the physical name of the
destination printer object on the desktop.
Note: On some systems, the name of the destination printer queue is case
sensitive. If the name of the destination printer queue is lowercase or mixed
case, enclose the name in apostrophes (‘ ’) to prevent the AS/400 system
from making the name uppercase. This also applies to the
destination-dependent options.
When sending to non-AS/400 systems, the LPD server reads the control file that
contains a number of printing options and attributes, such as width of output and
number of copies. Only attributes that the LPR/LPD protocol supports are sent. In
particular, the page range-to-print attribute is not supported. The LPD server
determines the implementation of the control file attributes. This control file is part of
the LPR/LPD protocol, and LPR builds it automatically.
Number of copies
For the number-of-copies attribute to function properly, you must send it in a way
that the LPD server recognizes. The default method puts a print command in the
control file for each copy requested. A single copy of the data and control files are
sent. Some print server LPDs require this method, but most LAN-attached printers
ignore the multiple print commands.
The alternate method puts a single print command in the control file. The data and
control files are then sent multiple times. To select this method, press F10 to display
Chapter 11. Line Printer Requester (LPR)
349
additional parameters and specify the destination-dependent option
DESTOPT(XAIX) on the SNDTCPSPLF command. Note that the option is
capitalized.
Verify that multiple copies are sent correctly by using the SNDTCPSPLF command
with a test spooled file that has the COPIES attribute set to two or more. Sending
with the default method when LPD requires the XAIX option prints only a single copy
with no error messages. Sending with DESTOPT(XAIX) specified when LPD
requires the default method results in the following error message:
TCP3701 Send request failed for spooled file ...
You can still print a copy after receiving this error message.
Destination-dependent options
You also use this field for specifying attributes of the LPR/LPD protocol. The AS/400
LPR command supports filters, which indicate how to print the file (for example,
whether the first column is carriage control characters). You can change the default
jobname for the separator page by specifying J immediately followed by the desired
job name. For a list of the attributes that are sent in the control file, see “LPR
Command” on page 345.
The SEPPAGE parameter specifies whether a separator page is requested when
the spooled file is printed on the remote system. The default value is *YES. The LPD
implementation determines the printing of the separator page. Some LPD
implementations ignore this request and print (or do not print) a separator page by
default.
Some LPD systems understand additional implementation-specific control file lines.
When sending to one of these systems, you can append additional lines to the
control file by specifying them on the (DESTOPT) parameter. Separate the options
with spaces to send them in the control file exactly as typed. The options must be
described in the LPD documentation for that system.
Because other systems might not support the attributes that are associated with a
spooled file, the spooled file that is created on the destination system might not be
identical to the one that you sent.
Transformation of Spooled Files
If the spooled file has a printer device type of Systems Network Architecture
character string (*SCS) or Advanced Function Printing Data Stream (*AFPDS), you
can convert the data stream to ASCII using the host print transform (HPT) on the
AS/400 prior to sending. Use the TRANSFORM parameter on the SNDTCPSPLF
command to convert the data stream to ASCII. For information on host print
transform, see the Printer Device Programming book. You cannot transform an
Intelligent Printer Data Stream (*IPDS). If the printer device type is *IPDS, no
conversion takes place, the file is not sent, and an error message is issued.
You also cannot convert files of device type *SCS that contain IPDS* to ASCII. If
you attempt to send a spooled file containing IPDS data using the SNDTCPSPLF
command, the send request is canceled. An example is some spooled files that you
create with the OfficeVision licensed program. These spooled files are intended to
print to an IPDS printer and contain IPDS data. Therefore, you cannot convert the
spooled files to ASCII.
350
OS/400 TCP/IP Configuration and Reference V4R4
Although you can send transformed files to another AS/400 (as type *USERASCII),
this is more used when the destination system is a non-AS/400 system, using the
options DESTTYP(*OTHER) and TRANSFORM(*YES) (assuming that the printer
device type of the spooled file is *SCS or *AFPDS).
Most non-AS/400 LPD receivers expect the data in ASCII format. Unless the printer
device type attribute is already *USERASCII, you need to transform the file.
If you know that the destination system supports the printer device type of the
spooled file, send it without transforming it. For example, you can send spooled files
with a printer device type of AFPDS to Print Services Facility/2 (DESTTYP(*PSF2)).
When sending *AFPDS files, you must consider any external resources of that file.
These resources, such as fonts and overlays, must also reside on the destination
system to allow the file to print correctly.
In addition to AFPDS data, you can send *SCS data to PSF/2. When you send
*SCS data, you must specify TRANSFORM(*YES) and MFRTYPMDL(*IBM5202).
These values result in the best print fidelity.
When specifying that a file must be transformed from *SCS or *AFPDS to *ASCII,
you need to specify the type of ASCII printer (MFRTYPMDL parameter). You can
also specify a workstation customizing object that affects how the transform is done
(MFRTYPMDL(*WSCST)). For more information about the relationship between the
host print transform function and the workstation customizing object, see
Workstation Customization Programming.
You can also use your own program to handle transformation of the data. User data
transform programs must be written to the Writer Transform Exit Program interface.
For more information on this interface, see Writer Transform Exit Program in the
System API Reference . The name and library of this program are entered in the
USRDTATFM parameter. This parameter is prompted only when you select
TRANSFORM(*NO) to not use the AS/400 host print transform.
Table 32. Common Parameter Settings When Using SNDTCPSPLF
Destination System
Type
Data Stream Type
Transform Value
Manufacturer Type and Model
*AS400
*SCS or *AFPDS
*YES
Specify type of ASCII printer
*AS400
Any
*NO
Leave blank
*PSF2
*AFPDS
*NO
Leave blank
*PSF2
*SCS
*YES
*IBM52021
*PSF2
*USERASCII2
*NO
Leave blank
*OTHER
*SCS or *AFPDS
*YES
Specify type of ASCII printer
*NO
Leave blank
*OTHER
2
*USERASCII
Notes:
1. Choose the highest function printer supported by PSF/2.
2. *USERASCII does not necessarily mean that the data stream for the spooled file is ASCII. It means that the data
was spooled without being examined or validated by an AS/400 business computing system.
LPR Support of PostScript Printers
The HPT on the AS/400 converts an SCS or AFPDS spooled file to ASCII format.
The Image Print Transform added in Version 4 Release 2 converts image or
PostScript *USERASCII spooled files into various ASCII formats and non-ASCII
Chapter 11. Line Printer Requester (LPR)
351
formats. Setting TRANSFORM(*YES) enables either the Image or Host Print
Transform, depending on the spooled file type.
When you convert PostScript spooled files, text data is converted into a bit-mapped
image. Conversely, only image spooled files are converted into PostScript. Image or
PostScript spooled files are also converted into Printer Control Language (PCL) for
Hewlett-Packard compatible printers and Advanced Function Printing (AFP) data
stream.
Image transformation requires additional image configuration information beyond
that of the manufacturing type and model parameter, or workstation customizing
object. When using the LPR or SNDTCPSPLF command, you must ensure that this
information is in the user-defined data attribute of the spooled file. When using
printer pass-through, you can specify this with an image configuration object in the
IMGCFG parameter of the remote output queue. For detailed information on
specifying Image and Host Print Transform parameters, see Printer Device
Programming, SC41-5713-03.
Determining the Printer Device Type
To determine the printer device type of a spooled file, display the spooled file
attributes. The printer device type (DEVTYPE) parameter on the printer file sets this
attribute when the spooled file is created. For more information, see Printer Device
Programming.
Printer Requirements when Sending with Host Print Transform
Function
You need to know the printer, the manufacturer, type, and model (MFRTYPMDL
parameter) of the destination printer if you are using the host print transform
function. Many printers sold by the following companies are supported:
v Epson America Incorporated
v Hewlett-Packard Company
v
v
v
v
v
IBM Corporation
NEC Corporation
Okidata Corporation
Panasonic Corporation
Xerox Corporation
Authority for Sending Spooled Files
To send a spooled file, you must have one of the following authorities to the file or
to the output queue that the file is on.
v Be the owner of the spooled file.
v Have spool control authority (*SPLCTL).
v Have job control (*JOBCTL) special authority on an operator-controlled
(OPRCTL(*YES)) output queue.
v Be the owner of the output queue.
v Have add, delete, and read authority to an output queue created with
AUTCHK(*DTAAUT).
v Have read authority to output queue created with DSPDTA(*YES).
352
OS/400 TCP/IP Configuration and Reference V4R4
If you are using LPR through the Remote Writer, then the Remote Writer changes
its job attributes to run under the user profile that created the spooled file. The
writer does not change its job attributes to those of a system profile. Instead, it uses
the default user profile of QSPLJOB. In any case, the Remote Writer always passes
the authority test.
Sending Spooled File — Tips
You can send only printer spooled files. You cannot send diskette spooled files.
You cannot send a spooled file that is in an open status.
Successful sending of a spooled file only acknowledges a successful transmission.
At that point, the TCP/IP connection is closed. If any errors occur while the LPD
server processes the file, messages cannot be sent back. You must not delete any
files without verifying that the spooled file was created or printed successfully.
Sending Large Spooled Files
Depending on system load, how your printer is configured, and other variables, you
might need to disable or increase the idle timeout value on the printer to print large
spooled files. This value is set differently, depending on what kind of printer you are
using. The procedure for changing the timeout and range of settings is device
dependent. For more information, see the documentation provided with the printer.
On some printers, this is set on the control panel. On others, it is set using a Telnet
command. You need a large timeout value because the printer connection is
opened before the file transforms to ASCII. Otherwise, the system resources used
in transforming are wasted if the printer is in use by another job when the transform
completes. You cannot send the file until the transform is complete because the
LPR/LPD protocol requires the system to send the total byte count before any data.
You can also transform the spooled file to ASCII before sending to the printer by
sending it to the AS/400 LPD server. Specify DESTTYP(*AS400)
TRANSFORM(*YES) on the SNDTCPSPLF command along with the desired ASCII
printer model and options. Specify the local host name for the remote system and
an output queue on the AS/400. Use a second SNDTCPSPLF command to send
the transformed spooled file to the desired printer. This significantly reduces the
wait time seen by the printer. You can also use this with printer pass-through
(below) by creating two output queues.
You can accomplish this more efficiently with printer pass-through (below) by adding
the destination option XAUTOQ with the CHGOUTQ or CRTOUTQ commands.
Note the option must be capitalized. The file is transformed and sent to the remote
system as specified by the other remote output queue parameters unless the idle
timeout value is exceeded during transformation. In this case, the transformed
spooled file is routed instead to the AS/400 LPD server and sent back to the same
output queue. From there it is automatically sent again to the remote system. The
Host Print Transform recognizes that the spooled file is already transformed and
sends the spooled file without that delay.
Printer Pass-Through
Printer pass-through enables you to route printer files automatically to another
system that supports TCP/IP LPD.
Chapter 11. Line Printer Requester (LPR)
353
It is possible to do printer pass-through over both SNA and TCP/IP. This section
deals purely with TCP/IP considerations.
Setup
To enable printer pass-through, you need to create an output queue with CRTOUTQ
and specify a RMTSYS parameter other than *NONE. Specify either the remote
system (host) name or *INTNETADR, in which case the system prompts you for the
Internet address of the remote system.
The following parameters on the CRTOUTQ command are relevant to using printer
pass-through with LPR.
v To use printer pass-through with TCP/IP, you need to specify CNNTYPE of *IP.
v Using the RMTPRTQ parameter, specify a specific print queue other than *USER
or *SYSTEM on the remote system. If you send to another AS/400, specify only
a print queue name or libname/outqname. In this case, the system expects to
find the remote output queue in QUSRSYS.
v Specify a DESTTYPE of *OS400 (for OS/400 V3 or V2R3 with TCP/IP), *PSF2
(for a PC with PSF/2), or *OTHER. OS/400 TCP/IP prior to V2R3 does not
support LPD.
v Check the TRANSFORM parameter. By default, this is *YES, to use Host Print
Transform. If you want the system to prompt you for the user transform program
parameters, specify *NO. For sending to another AS/400, use *NO with user
transfer program *NONE.
v You can send additional control file options to the remote system by specifying
them on the DESTOPT parameter. CRTOUTQ (Create Output Queue) also
supports the special value *USRDFNTXT. This takes the value of the DESTOPT
parameter from the user-defined text of the user profile when the system creates
that spooled file. The separator page parameter of the SNDTCPSPLF command
is also supported.
354
OS/400 TCP/IP Configuration and Reference V4R4
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Output queue . . . .
Library . . . . . .
Maximum spooled file
Number of pages .
Starting time . .
Ending time . . .
. . . . . . OUTQ
. . . . .
size:
MAXPAGES
. . . . . .
. . . . . .
. . . . . .
+ for more values
Order of files on queue . . . . SEQ
Remote system . . . . . . . . . RMTSYS
> SYSNAM123
*CURLIB
*NONE
*FIFO
> SYSNAM123
Remote printer queue . . . . . . RMTPRTQ
SYSNAM456
Writers to autostart . . . . . . AUTOSTRWTR
*NONE
F3=Exit
F4=Prompt
F5=Refresh
F13=How to use this display
F10=Additional parameters
F24=More keys
More...
F12=Cancel
Figure 216. Create Remote Output Queue—Display 1 of 2
Create Output Queue (CRTOUTQ)
Type choices, press Enter.
Queue for writer
Library . . .
Connection type
Destination type
Transform SCS to
messages
. . . . .
. . . . .
. . . . .
ASCII . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
MSGQ
CNNTYPE
DESTTYPE
TRANSFORM
QSYSOPR
*LIBL
> *IP
*OS400
*NO
Figure 217. Create Remote Output Queue—Display 2 of 2
You now need to ensure that the remote system’s print queue exists before starting
the pass-through process.
This completes the setup processing.
Starting Printer Pass-Through
To start printer pass-through, perform the following steps:
1. Use the Start Remote Writer (STRRMTWTR) command.
2. Specify the queue name on the local (LPR) system that you created in the
previous section. This starts a writer in the QSPL subsystem that, when using
TCP/IP, uses LPR to send printer files to the remote (LPD) system.
3. Ensure that LPD is operational on the remote system and, in the case of the
AS/400, that the remote printer writer is active.
In the event of problems with this processing, the writer’s job log is often a useful
source of problem analysis material. To access this while the job is running, specify
the WRKACTJOB SBS(QSPL) command and select Option 5 against the writer job.
Chapter 11. Line Printer Requester (LPR)
355
This shows the Work with Writers display, from which it is necessary to press F17
to see the job log. This sequence is different from the usual one for viewing batch
and interactive job logs while the jobs are running.
Configuring for a RISC System/6000 System — Scenario
This section describes the following topics:
v How to configure LPD on the RS/6000 system to allow an AS/400 to send a
spooled file with LPR.
v How to configure device and virtual printers for AIX print output.
v How to configure a PSF/6000 printer for PSF/6000 print output.
Setting Up for LPD on the RISC System/6000 System — Scenario
Use the following series of commands to follow through the SMIT menus on the
RS/6000 system.
At the AIX command line prompt, specify the following:
smit
Spooler (Print Jobs)
Manage Remote Printer Subsystem
Server Services
Host Access for Printing
Add a Remote Host
Specify the host name of the remote host that you want to send spooled files to the
local LPD as shown in Figure 218. In this case, it is SYSNAM890. This name must
also be in the local host table of the RS/6000 system (/etc/hosts).
Add a Remote Host
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
sysnam890
* Name of Remote HOST
F1=Help
Esc+5=Reset
F9=Shell
F2=Refresh
F6=Command
F10=Exit
F3=Cancel
F7=Edit
Enter=Do
F4=List
F8=Image
Figure 218. Add a Remote Host
Configuring Device and Virtual Printer for AIX Printing
Two steps are necessary for the following configurations on the RS/6000 system.
Configuring the AIX Printer Device
To configure a non-IPDS printer so that the system recognizes it as an AIX printer,
specify the following at the AIX command line prompt (in this case, an IBM 4029
printer is attached in parallel):
smit printer
Printer/Plotter Devices
Add a Printer/Plotter
356
OS/400 TCP/IP Configuration and Reference V4R4
4029
IBM 4029 LaserPrinter (select printer, press Enter)
parallel
(select Interface, press Enter)
ppa0 Available 00-00-0P Standard I/O Parallel Port Adapter
p
(select PORT number)
Figure 219 shows the final display. Make any changes if necessary. If all the fields
are correct, press the Enter key.
Add a Printer/Plotter
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[TOP]
Printer/Plotter type
Printer/Plotter interface
Description
Parent adapter
* PORT number
Type of PARALLEL INTERFACE
Printer TIME OUT period
STATE to be configured at boot time
The following attributes have meaning only
when the Printer/Plotter is not used with
a Print Queue:
[MORE...13]
Es=Help
F9=Shell
F2=Refresh
F2=Refresh
F10=Exit
[Entry Fields]
4029
parallel
IBM 4029 LaserPrinter
ppa0
[p]
[standard]
[600]
+
+
+#
[available]
+
F3=Cancel
ext F3=Cancel
Enter=Do
F4=List
Figure 219. Printer Specifications
Configuring a Virtual Printer
To configure a virtual printer, specify the following at the AIX command line prompt:
smit printer
Manage Local Printer Subsystem
Virtual Printers
Add a Virtual Printer
No.
1
2
3
4
Description
Printer or Plotter Attached to Host
Printer or Plotter Attached to Xstation
Printer or Plotter Attached to ASCII Terminal
Network Printer (Hewlett-Packard JetDirect)
Enter number from list above (press Enter to terminate):
-> 1
Figure 220. Configuring a Virtual Printer
1. Select Option 1 (Printer or plotter attached to host).
Chapter 11. Line Printer Requester (LPR)
357
Name
lp0
Description
IBM 4029 LaserPrinter
Enter device name (or, ! to exit):
-> lp0
Figure 221. Enter the Printer Device Name Used and Press Enter
2. Specify the printer device name used and press the Enter key.
For the next series of displays, answer the questions. When in doubt, take the
defaults.
Specify the print queue name to use for printing with AIX. In this case, the name is
asc.
IBM 4029 LaserPrinter
Header pages wanted? (n=none; a=each file; g=each job): -> (n)
Trailer pages wanted? (n=none; a=each file; g=each job): -> (n)
NOTE:
The 4029 printer supports multiple print data streams.
Each of the data streams will now be configured individually.
-------------------- PostScript -------------------Enter print queue name (or, ! to bypass configuration):
-> (ps)
!
-------------------- HP LaserJet II Emulation -------------------Enter print queue name (or, ! to bypass configuration):
-> (pcl)
!
-------------------- Plotter Emulation -------------------Enter print queue name (or, ! to bypass configuration):
-> (gl)
!
-------------------- IBM ASCII -------------------Enter print queue name (or, ! to bypass configuration):
-> (asc)
asc
Should this queue be the default queue? -> (y) n
4029 (IBM ASCII) configured for print queue asc
Press Enter to continue
Figure 222. Virtual Printer Queue Configuration
Verifying LPD Started on the RISC System/6000 System
Verify that LPD is started on the RS/6000 system. Check its status by issuing the
following command:
'lssrc -s lpd'
If LPD is inactive, you need to start the daemon. If you restart the system itself,
ensure that LPD starts again.
To use SMIT to start LPD either now or at system restart time, specify the following
at the AIX command line prompt:
smit
Communications Applications and Services
TCP/IP
Further Configuration
Remote Printer Subsystem
Server Services
lpd Remote Printer Subsystem
Start Using lpd Subsystem
Start BOTH Now and at System Restart
358
OS/400 TCP/IP Configuration and Reference V4R4
Verifying Your Configuration on the RISC System/6000 System
1. Verify the printer configuration by printing an RS/6000 file directly to the
attached printer. Specify the following:
cat /etc/qconfig > /dev/lp0
2. Test that the virtual printer works correctly by specifying the following:
enq -P asc /etc/qconfig
3. Use LPR on the AS/400 system to send a spooled file to the RS/6000 system to
be printed using the AIX print queue asc. Find a spooled file that you want to
send and write down the file, job, and spool number information. Next, complete
the LPR command as shown in the following example, using the file, job, and
spool number of your spooled file.
Note: It is important to enclose the PRTQ parameter asc within apostrophes.
This is because the RS/6000 system is case sensitive. Send the print
queue name asc as it appears in lowercase.
LPR RMTSYS(RCHRS001) PRTQ('asc')
FILE(FTPBATCHT)
JOB(059016/HANS/FTPBATCHT)
SPLNBR(1) DESTTYP(*OTHER)
TRANSFORM(*YES) MFRTYPMDL(*IBM42011)
Printer not Active — Symptom
When you specify enq -A at the RS/6000 system to display the status of the print
queue, the printouts to be printed are queuing in that print queue. If the printer has
been offline for some time, the status of that queue could become DOWN.
The following are possible causes for the DOWN status:
Printer is offline.
Printer status is DOWN.
Printer paper jam.
To correct the possible causes, perform the following steps:
1. Press the online button at the printer.
2. If the print queue status shows DOWN, specify the following RS/6000 command to
get the print queue to READY status again:
qadm -U asc
where asc is the print queue name.
3. To clear the paper jam and get the printer ready for printing again, perform the
following steps:
a. Clear the paper in the printer.
b. Display the status of the print queue using the following command:
enq -A
c. To clear any outstanding print jobs in the print queue, if necessary, specify
the following command:
qcan -xnn
where nn is the job number in the status screen.
d. If the status of the printer is DOWN, specify the following command:
qadm -U asc
Chapter 11. Line Printer Requester (LPR)
359
where asc is the print queue name.
e. Check the status of the print queue to ensure that the status is READY and
that the printer is online.
Print Services Facility/6000 Function
The PSF/6000 licensed program provides an intelligent print driver that accepts
input data stream files, including Advanced Function Printing data stream (AFPDS)
and ASCII. The program also produces different output data streams like Intelligent
Printer Data Stream (IPDS), IBM personal printer data stream (PPDS), or
Hewlett-Packard printer control language (PCL).
The PSF/6000 function allows you to perform the following tasks:
v Integrate workstation and host printing under a common architecture.
v Enable LAN print serving capability supporting multiple workstations, operating
systems, data streams, and print types.
v Improve systems management of printing by using Network File System (NFS).
Configuring PSF/6000 Function
This scenario configures for PPDS. To configure for other scenarios, refer to the
IBM AIX PSF/6000: Print Services for Users of AIX, G544-3814-01.
To use the PSF/6000 function, configure a PPDS printer (or an IPDS printer or a
PCL printer). Specify the following:
smit psfcfg
Add a Printer or PSF/6000 Queue
AIX-Defined (Parallel, Serial, or LAN)
The system prompts you to choose a data stream type (PPDS, PCL4, PCL5, or
PCL5C).
Following this, specify the information as shown in Figure 223.
Add a PSF/6000 Queue for AIX-Defined Printer
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
* Data stream type
* Printer NAME
* COMMAND to execute for printer output
Description
To specify other characteristics after you add
a printer, select Change Characteristics of
a Printer from the
PSF/6000 Printer Definition panel.
F1=Help
Esc+5=Reset
F9=Shell
F2=Refresh
F6=Command
F10=Exit
F3=Cancel
F7=Edit
Enter=Do
Figure 223. PPDS Printer and Queue Definition
360
OS/400 TCP/IP Configuration and Reference V4R4
[Entry Fields]
PPDS
psf6k
[qprt -P asc -dp -Z!]
F4=List
F8=Image
+
/
Specify the name of the PPDS printer. This name is equal to the PPDS queue that
you want to create.
For the COMMAND to run for the printer output field, specify the name of the AIX
output queue asc, not the name of the PSF queue.
Verifying Your Configuration of PSF/6000
To test that the path between the RS/6000 system, PSF/6000 queue, and the
PSF/6000 printer is correct, specify the following:
enq -P psf6k /etc/qconfig
where psf6k is the name of the PSF/6000 queue.
If the file prints correctly, you can send and print AS/400 spooled files with AFP and
SCS data stream on the RS/6000 printer.
When sending spooled files to PSF/6000, always specify *OTHER for the LPR
destination type parameter.
For AFPDS, specify *NO for the transform SCS to ASCII parameter. We used the
AFP Utilities licensed program with the Start AFP Utilities (STRAFPU) command on
the AS/400 system to create an overlay that is named OVERLAY. It is this AFPDS
spooled file that you sent to the RS/6000 RCHRS001 in Figure 224. PSF/6000
converts the AFPDS data stream into PPDS automatically. For more information
about the AFP Utilities licensed program, see AFP Utilities/400 User’s Guide and
Reference, SH18-2416.
Send TCP/IP Spooled File (LPR)
Type choices, press Enter.
Remote system . . . . . . . . .
rchrs001
Printer queue . . . . . . . . .
'psf6k'
Spooled file . . . . .
Job name . . . . . . .
User . . . . . . . .
Number . . . . . . .
Spooled file number .
Destination type . . .
Transform SCS to ASCII
overlay
p23xyg41f
hans
060045
*ONLY
*OTHER
*no
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F3=Exit
F4=Prompt
F5=Refresh
F13=How to use this display
Name
Name, *
Name
000000-999999
1-9999, *ONLY, *LAST
*AS400, *PSF2, *OTHER
*YES, *NO
F10=Additional parameters
F24=More keys
Bottom
F12=Cancel
Figure 224. Sending AFPDS to PSF/6000
For the SCS data stream, you must specify *YES for the Transform SCS to ASCII
parameter. The AS/400 converts the SCS data stream from EBCDIC to ASCII (by
Chapter 11. Line Printer Requester (LPR)
361
host print transform), which is then sent to PSF/6000 and properly printed. See
Figure 225 for an example.
Send TCP/IP Spooled File (LPR)
Type choices, press Enter.
Remote system . . . . . . . . . > RCHRS001
Printer queue . . . . . . . . . > 'psf6k'
Spooled file . . . . .
Job name . . . . . . .
User . . . . . . . .
Number . . . . . . .
Spooled file number .
Destination type . . .
Transform SCS to ASCII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F3=Exit
F4=Prompt
F5=Refresh
F13=How to use this display
> ftpbatcht
> ftpbatcht
> HANS
> 059016
*ONLY
*OTHER
> *yes
F10=Additional parameters
F24=More keys
Figure 225. Sending SCS to PSF/6000
362
OS/400 TCP/IP Configuration and Reference V4R4
Name
Name, *
Name
000000-999999
1-9999, *ONLY, *LAST
*AS400, *PSF2, *OTHER
*YES, *NO
Bottom
F12=Cancel
Chapter 12. Line Printer Daemon (LPD)
You can request to have your spooled files printed on any system in your TCP/IP
network.
The printing facilities of the destination system handle the printing of the file. The
destination system must be running TCP/IP. On the AS/400 system, the line printer
daemon (LPD) is the process on the destination system that receives the file that
the SNDTCPSPLF command sends. The LPD process places the spooled file on a
local printer queue. To print the spooled file, place it on a printer queue that is
already started to an active printer writer. Another method of printing a spooled file
is to start a writer to that printer queue.
Configuring for Line Printer Daemon (LPD)
LPD does not require any special setup when receiving printer files from another
AS/400 system. However, with the Change LPD Attributes (CHGLPDA) command,
you can specify the number of LPD servers that you want initially started. You can
also specify whether you want these servers to start whenever you issue the Start
TCP/IP (STRTCP) command (Figure 226). Access the LPD attributes with either the
Configure TCP/IP LPD (CFGTCPLPD) command or the CHGLPDA command.
Change LPD Attributes (CHGLPDA)
Type choices, press Enter.
Autostart servers . . . . . . .
Number of initial servers . . .
*YES
2
F3=Exit
F4=Prompt
F24=More keys
F12=Cancel
F5=Refresh
*YES, *NO, *SAME
1-20, *SAME, *DFT
Bottom
F13=How to use this display
Figure 226. Change LPD Attributes (CHGLPDA) Display
How the Destination System Receives a Spooled File
The LPD server jobs run in subsystem QSYSWRK. Display these jobs using the
Work with Active Jobs (WRKACTJOB) command. Identify them by their job names
in the format QTLPDnnnnn.
© Copyright IBM Corp. 1997, 1999
363
Work with Active Jobs
CPU %:
4.5
Elapsed time:
Type options, press Enter.
2=Change
3=Hold
4=End
8=Work with spooled files
Opt Subsystem/Job
Status
QTGTELNETS
QTMSBRCL
QTMSBRSR
QTMSNMP
QTMSNMPRCV
QTLPD66887
QTLPD67093
00:02:02
05/11/94
Active jobs:
51
5=Work with
6=Release
13=Disconnect ...
User
Type
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
BCH
BCH
BCH
BCH
BCH
BCH
BCH
CPU %
ENDAS011
07:26:02
7=Display message
Function
.0
.0 PGM-QTMSBRDG
.0 PGM-QTMSBRSR
.0 PGM-QTOSMAIN
.0 PGM-QTOSRCVR
.0
.0
Parameters or command
===>
F3=Exit
F5=Refresh
F10=Restart statistics
F12=Cancel
F23=More options
F24=More keys
DEQW
DEQW
TIMW
DEQW
TIMW
TIMW
DEQW
More...
F11=Display elapsed data
Figure 227. Viewing the LPD Servers from the Work with Active Jobs Display
Only one LPD server job at a time listens for a valid LPR request from a remote
system. When an LPR request comes in, that job handles the request, and attempts
to pass the listening socket to another waiting LPD server job.
If LPD passes the socket successfully, it submits a replacement LPD server job
using the SBMJOB command and ends when the current job is complete. If LPD
cannot pass the listening socket (if only one server is running, for example), it runs
in single server mode.
In single server mode, additional LPR requesters must wait for any currently
running requests to reach a checkpoint stage or complete processing before their
request is handled. Because the system cannot pass the listening socket to a
waiting LPD server, the current LPD server continues to run instead of ending, and
no replacement job is submitted.
To avoid LPR request failures while a job is running, start LPD with a minimum of
two servers configured. The wait for a checkpoint stage or processing to complete
is often significant, especially if you are receiving a large print job.
How an AS/400 System Receives a Spooled File from Another AS/400
System
If another AS/400 system sends the spooled file, the first file to arrive is the control
file. This is because AS/400 LPD uses the newer RCFF (Receive Control File First)
and RDFUL (Receive Data File of Unspecified Length) protocols that RFC 1179
describes. If you send the spooled file without transformation from SCS to ASCII,
the control file contains the extended print attributes. The AS/400 LPD process
checks the extended print option flag and determines that the spooled file attributes
are being sent with the data.
364
OS/400 TCP/IP Configuration and Reference V4R4
In this case, the control file printing command flags are ignored, and the spooled file
is created on the destination AS/400 using the spooled APIs. For information on
spooled file and print APIs, see System API Reference.
If the original spooled file is in SCS format and the TRANSFORM parameter on the
SNDTCPSPLF command is set to *YES, the system transforms the file to ASCII. It
accomplishes this by using the host print transform function on the client (LPR)
system before it sends the file. The system uses the manufacturer, type, and model
information given on the MFRTYPMDL parameter to determine which printer
attributes to use in the ASCII data stream. The destination system receives the
ASCII data stream without change. Because the file is received in *USERASCII
format, the destination AS/400 cannot read it. You need to print the spooled file to
see the contents.
Spooled file APIs are used to receive files from remote AS/400s. When these APIs
create copies of a spooled file, they require access to the original printer file, which
might not exist on the target system.
If the access to the printer file is restricted from the user or the default user
QTMPLPD, then errors might occur. Because this is an API limitation, it is currently
considered an LPD restriction.
In addition, this also makes Send TCP/IP Spooled File (SNDTCPSPLF) work
consistently in the same manner as SENDNETSPLF, which also requires the
original printer file.
How an AS/400 System Receives a Spooled File from a Non-AS/400
System
If the spooled file is being sent from any system other than an AS/400, AS/400 LPD
accepts the request using either the newer RCFF and RDFUL protocol, or the older
RDF (Receive Data File) and RCF (Receive Control File) protocol. Some LPR
clients do not support the new protocol, but the AS/400 LPD server accepts either
format. From the control file information, the AS/400 can establish that the file is not
being sent from another AS/400. In this case, the AS/400 assumes that no spooled
file attributes are being sent with the data.
Because the AS/400 requires that each spooled file have attributes associated with
it, default attributes are given to the file using a default printer file, QPTMPLPD, in
the library QTCP. The printer file QPTMPLPD in the library QTCP contains the
default installation values. There is another version of the printer file in library
QUSRSYS that should be used if you want to customize the printer file. Using the
version that exists in QUSRSYS preserves the default installation values.
For non-AS/400 LPR requesters, you obtain best print results by understanding that
minimal formatting of the data file occurs, other than what is provided by the
destination printing system. The AS/400 LPD server does provide support for the
print filters v, l, and f, as described in RFC 1179. If the f filter is received, line feeds
(LF) are replaced with carriage return/line feeds (CRLF). With the f filter, all printer
control characters are deleted from the data stream, with the exception of HT, CR,
FF, LF, BS, and ESC characters. Printer control characters are any characters
below hexadecimal 20. Since a parameter usually follows the ESC character, the
system also keeps the character immediately following the ESC.
Chapter 12. Line Printer Daemon (LPD)
365
The default filter is l. There is no difference between the l and v filters. The system
treats them both the same.
LPD does not support control file support for banner pages because the AS/400 has
its own separator page function.
If the non-AS/400 LPR requests multiple copies, the system changes the attributes
of one spooled file to show multiple copies.
How Spooled Files are Named on the Destination AS/400
Prior to V3R1M0, if someone used AS/400 LPR with the DESTTYP(*OTHER) and
TRANSFORM(*YES) parameters, the name of the created spooled file became that
of the PRTF file, QPTMPLPD. The original spooled file name was placed into the
user data field of the created file. Likewise, for non-AS/400 LPR clients, the system
names the newly created file QPTMPLPD. The original file name was placed into
the user data field.
Beginning with V3R1M0, spooled files that LPD receives have file names in the
form LPDxxxx. The x represents any valid hex character. These hex characters are
the result of cyclic redundancy checking that is performed on client information to
identify the LPR client for LPRM support. Spooled files that are named in this
manner are unique to each client. The system uses the name as a signature. All
files from a single client have the same signature. A client must generate a
matching signature to use LPRM to delete any LPR spooled file.
Clients can use LPQ (line printer queue) and LPRM (line printer removal)
commands to query and remove LPR spooled files, as AS/400 LPD supports both
functions. However, the AS/400 system that acts as a client cannot issue these
commands.
If the LPR client is another AS/400 using DESTTYP(*AS400) and
TRANSFORM(*NO) parameters, the spooled file has exactly the same attributes on
the receiving queue that it had on the sending queue. The spooled file name is not
converted to LPDxxxx form and is left unchanged.
The LPQ command sent to an AS/400 system requires a job list parameter, or,
more specifically, a user profile under which the query is performed. The following is
an example on OS/2:
lpq -pmylib/myoutq -sas400.endicott.ibm.com
ProfileName
Starting an LPD Server Job
You must start the server job for the LPD application in the QSYSWRK subsystem.
The Start TCP/IP Server (STRTCPSVR) command starts the LPD server that is
shipped with the TCP/IP Utilities licensed program. You can also start the LPD
server job with the AUTOSTART parameter of the Change LPD Attributes
(CHGLPDA) command. However, the STRTCPSVR command overrides or ignores
the AUTOSTART parameter on the CHGLPDA command.
The Start TCP/IP (STRTCP) command starts all of the servers that you specify in
the CHGLPDA command. The STRTCPSVR command starts the number of servers
configured in the CHGLPDA command. After you start the minimum number of LPD
servers, the STRTCPSVR command starts only one additional server at a time.
366
OS/400 TCP/IP Configuration and Reference V4R4
LPD works most efficiently when two or more servers are running. It is possible to
run only one server, but LPD cannot receive any jobs while a current job is running.
If a large print job is running, LPR clients have to wait until LPD is ready to accept
any new LPR requests.
You can use the Configure TCP/IP LPD (CFGTCPLPD) command or the CHGLPDA
command to work with the LPD attributes.
Ending an LPD Server Job
To end server jobs, use the End TCP/IP Server (ENDTCPSVR SERVER(*LPD))
command. This command also ends any active LPD jobs that are still processing an
LPR request.
Attributes of the Received Spooled File
On the AS/400 system all files that are printed have spooled file attributes
associated with the file. These attributes specify such things as lines per inch, page
widths, number of copies, and which fonts to use. If any file is received that does
not have attributes associated with it, default attributes are given to the file. Set
these attributes by using the first QPTMPLPD printer file that you find in the library
list (*LIBL). Files sent from non-AS/400 systems or files sent using the
SNDTCPSPLF command and that were transformed do not have attributes
associated with them.
The QPTMPLPD printer file can have copies in the QUSRSYS library or other
libraries. The copy of the printer file in QTCP is the default if there are no others in
the library list (*LIBL). This is the case even if the QTCP library is not in the library
list (*LIBL). The LPD processing adds the QTCP library to the library list if it is not
already in the list. An exception exists where a user has 25 libraries in the user
portion of the library list. In this situation, the system replaces the twenty-fifth library
with the QTCP library to ensure that it finds a copy of the QPTMPLPD file.
The QPTMPLPD printer file has a printer device type of *USERASCII because LPD
expects that data from non-AS/400 systems is ASCII data. If LPD receives data that
is not ASCII data from a non-AS/400 system, LPD spools the data as *USERASCII.
However, the data might not print correctly.
For the control file options and attributes that the AS/400 LPD function supports,
see Table 36 on page 369.
User Profile Library Lists
All user profiles have a library list associated with them. When LPD creates a
spooled file on behalf of a user profile, it searches for the output queue requested
using the library list for that profile. Therefore, if the requested output queue does
not have a library qualifier (library/queuename), the library list is searched for in the
queue. If LPD does not find the queue in the library list, it uses the default output
queue QPRINT in library QGPL.
Important!:
Chapter 12. Line Printer Daemon (LPD)
367
The library list of a user profile is the library list that is in effect at
sign-on time. Any libraries added by initialization programs or other
methods are not considered in the library list or associated with that
user profile.
Changing the QPTMPLPD Printer File Default Values
To change the default values in the QPTMPLPD printer file, use the Change Printer
File (CHGPRTF) command. For example, to change the number of lines per page
for all files received from non-AS/400 systems, specify the following:
CHGPRTF FILE(QUSRSYS/QPTMPLPD) PAGESIZE(60)
The change takes effect immediately and remains in effect until other changes are
made or until the printer file is created again. LPD overrides the following
CHGPRTF parameters, which you cannot change with the CHGPRTF command:
v
v
v
v
v
v
v
FILE
TOFILE
PAGESIZE(*N n) (width option only is overridden)
SPLFNAME
OUTQ
COPIES
USRDTA
Note: The installation programs copy the QPTMPLPD printer file from the QTCP
library into the QUSRSYS library. That means two versions of this printer file
exist, with one in the QTCP library and one in the QUSRSYS library. To
preserve the installation values, change the QUSRSYS version.
LPD-Supported Commands on the AS/400
Table 33 identifies what LPD commands that the AS/400 system supports.
Table 33. LPD Commands on the AS/400
Command
LPD
Hex Code
Print Any Waiting Jobs
X
X'01'
Receive a Printer Job
X
X'02'
Send Queue State (Short)
X
X'03'
Send Queue State (Long)
X
X'04'
Remove Jobs
X
X'05'
If the system receives any other commands, LPD ignores them and sends a return
code of 1, meaning failure, to the requesting system. The connection is closed
immediately. LPD logs an error that indicates unsupported function.
Table 34 identifies which LPD subcommands the AS/400 system supports.
Table 34. LPD Subcommands
Subcommand
LPD
Abort Job
368
Hex Code
X'01'
Receive Control File
X
X'02'
Receive Data File
X
X'03'
OS/400 TCP/IP Configuration and Reference V4R4
Table 34. LPD Subcommands (continued)
Subcommand
LPD
Hex Code
Receive Control File First
X
X'04'
Receive Data File with Unspecified Length
X
X'05'
LPD-Supported Commands for Control File Printing
Table 35 identifies the LPD control file printing commands that the AS/400 system
supports. A control file is used to pass all of the printing options and attributes that
were selected on the SNDTCPSPLF command to the LPD process on the
destination system. You cannot update the control file.
Table 35. Control File Printing Commands
Command
LPD
Letter Code
Plot CIF (CalTech Intermediate file) File
c
Print DVI (device-independent) File
d
Print Formatted File
X
f
Print Plot File
g
Reserved
k
Print File Leaving Control Characters
X
l
Print ditroff (device-independent troff) Output
File
n
Print File with PR Command Format
p
Print File with FORTRAN Carriage Control
r
Print troff Output File
t
Print Verbatim File
X
v
Extended Print Command
x
LPD-Supported Control File Options and Attributes
Table 36 identifies the LPD control file options and attributes that the AS/400 system
supports. The attributes that the AS/400 implementation of LPD does not support
are ignored if sent with the spooled file.
The control file and attribute information are not used when sending files from one
AS/400 system to another if the file was not transformed before sending. In this
case, all the attributes of the spooled file on the receiving system are the same as
they were on the sending system.
Table 36. Control File Options and Attributes
Option or Attribute
LPD
Class for banner page
Host name
Letter Code
C
X
H
Indent printing
I
Job name for banner page
J
Print banner page
L
Mail when printed
M
1
Name of source file
X
N
Chapter 12. Line Printer Daemon (LPD)
369
Table 36. Control File Options and Attributes (continued)
Option or Attribute
LPD
Letter Code
User identification
X
P
Symbolic link data
S
Title for pr command
T
Unlink data file
U
2
X
Extended print option
Width of output
X
W
troff R font (Times Roman type style)
1
troff I font (Times Roman type style)
2
troff B font (Times Roman type style)
3
troff S font (Times Roman type style)
4
Notes:
1. Only used to fill the user data (USRDATA) field of the spooled file created.
2. This command is only used when the destination system is an AS/400 system.
How the Ownership of Spooled Files Is Determined
If the user ID on the sending system exists on a destination AS/400 system, the
spooled file is created under that user profile. However, if the user profile does not
exist on the destination system, then the spooled file is created under the
QTMPLPD user profile.
When sending from a non-AS/400 system to an AS/400 system, the file is always
created using the QPTMPLPD printer file. This is also true when sending from an
AS/400 to an AS/400 with the TRANSFORM(*YES) parameter. In these cases,
spooled files received by the LPD server are placed under special jobs.
For example, if user ID JOHN exists, the file is placed under job
999999/JOHN/QPRTJOB. If user ID JOHN does not exist, the file is placed under
999999/QTMPLPD/QPRTJOB. For more information on QPRTJOB, see the Printer
Device Programming, SC41-5713.
How an LPD Server Selects an Output Queue for a File
Figure 228 on page 371 shows how the AS/400 LPD server selects on which output
queue a file is placed.
370
OS/400 TCP/IP Configuration and Reference V4R4
┌──────┐
│ LPR │
└──┬───┘
ø
┌──────────────────┐
│ Data and control │
│ file received on │
│
AS/400
│
└────────┬─────────┘
ø
┌────────────────────┐
│ Check control file │
│ for sending
│
│ user ID JOHN
│
└─────────┬──────────┘
┌────────────────────┐
ø
│Is *PUBLIC access
│
┌──────────────────────┐
│authority to
│
│ Does user JOHN exist │No
│QTMPLPD profile
│ Yes
│
on the AS/400?
├──────Ê │*EXCLUDE
│ ────────┐
└──────────┬───────────┘
└─────────┬──────────┘
│
│Yes
│
│
ø
│No
│
┌─────────────────────┐
┌──────────────────────┐
│
│ Receive file under │
│ Receive file under
│
│
│ user profile JOHN
│
│ user profile QTMPLPD │
│
└──────────┬──────────┘
└──────────┬───────────┘
│
│
│
│
│
│
│
ø
│
│
┌───────────────────────┐
│
│
│ Check the Receive
│ Í───────────────┘
│
│ Printer Job command
│
│
│ for OUTQ value
│
│
│ (AS/400 LPR PRTQ
│
│
│ value)
│
│
└───────────────────────┘
│
│
│
ø
│
┌──────────────────────────┐
│
│
│ No
│
│ Does OUTQ exist?
├─────┐
│
│(If no library specified, │
│
│
│then *LIBL is used)
│
│
│
└──────────┬───────────────┘
│
│
│ Yes
│
│
ø
ø
ø
┌──────────────────┐
┌─────────────────────┐ ┌──────────────────┐
│ Send spooled file│
│Send spooled file to │ │ LPR denied; file │
│
to OUTQ
│
│OUTQ QGPL/QPRINT
│ │
not accepted
│
└────────┬─────────┘
└───────┬─────────────┘ └────────────┬─────┘
│
│
│
ø
ø
ø
┌────────────────────────────┐ ┌────────────────────────────┐
│ Successful return code
│ │ Failing return code
│
│ sent to requesting system │ │ sent to requesting system │
└────────────────────────────┘ └────────────────────────────┘
Figure 228. Flow for Determining Output Queue for a Spooled File
v If the user ID on the sending system exists on the destination system, an attempt
is made to create the spooled file on the output queue that is defined on the
Receive a Printer Job command under that user ID.
– If the requested output queue exists, the spooled file is placed in that output
queue. The user ID must have access to that output queue, or the OUTQ
Chapter 12. Line Printer Daemon (LPD)
371
must have the OPRCTL parameter set to *YES. This means that anyone with
*JOBCTL authority, like LPD, can access the OUTQ.
– If the output queue name does not contain a library name, the *LIBL library is
searched.
– If the specified output queue cannot be found, the spooled file is sent to the
output queue QPRINT in the library QGPL.
v If the specified user does not exist on the destination AS/400 system, the
*PUBLIC access authority for the user QTMPLPD is checked. The *LIBL library
associated with the profile QTMPLPD is searched for the requested output
queue.
– If the authority is not *EXCLUDE, the Receive Printer Job command is
checked for the name of the requested output queue.
– If the output queue is found, the file is sent to that output queue, provided the
user profile QTMPLPD has access to that output queue or the OUTQ has the
OPRCTL parameter set to *YES. This means that anyone with *JOBCTL
authority, like LPD, can access the OUTQ.
– If the specified output queue cannot be found, the spooled file is sent to the
output queue QPRINT in the library QGPL.
In all of the previous situations, the file is considered successfully sent and
received.
If the QTMPLPD profile has public access set to *EXCLUDE, access to the output
queue is denied, and the file is rejected by the AS/400 destination system. The
error message is sent to the message queue for the QTMPLPD default user profile.
Important!:
There is no process to notify the requesting system that an authority
error was detected because the TCP connection is usually closed by
the time this is determined. Any success messages posted by the LPR
client application mean the file was temporarily received but not
necessarily kept. Do not delete any files until you have verified that
you have proper authority and that your files were received
successfully on the destination system.
How Authority for Putting Spooled Files on Output Queue is
Determined
When LPD creates spooled files, it checks to ensure that the requester has the
proper authority to place spooled files on the output queue. It checks to ensure that
the following are true:
1. The user has *READ authority to the output queue.
2. The user has *SPLCTL special authority.
3. The user has *JOBCTL special authority.
4. The output queue is OPRCTL(*YES).
If any of these conditions are true, then the user has authority to place the file on
the requested output queue. If none of these conditions are true, the file goes to the
default output queue QPRINT in library QGPL.
372
OS/400 TCP/IP Configuration and Reference V4R4
Using LPD to Print ASCII Files
A possible use of LPD is to print ASCII files received from systems running
LPR-to-ASCII workstation printers that are attached to the AS/400 in one of the
following ways:
v ASCII workstation controllers.
v NWS (Nonprogrammable workstation) printer ports.
v PWS (Programmable Workstation) serial ports.
This is useful for situations where a programmable workstation does not have its
own printer attached. You can also use it from any ASCII system that is running
LPR.
OS/2 TCP/IP—Example
The following is the syntax of the LPR command on OS/2 TCP/IP that prints file
CONFIG.SYS directly to printer WSPRT9 on AS/400 RCHASM03:
lpr config.sys -p WSPRT9 -s RCHASM03
Additionally, an LPD server must be started on RCHASM03, and WSPRT9 must be
a printer of the type described previously. The file arrives with a sending user ID of
PC-USER and is processed according to Figure 228 on page 371.
Note: Because the spooled file is still an ASCII file, you cannot display the file on
the AS/400 system while it is on the print queue.
Using LPD to Print ASCII Files Converted to EBCDIC
Another use of LPD is to receive printer files from ASCII hosts running LPR and
print them in EBCDIC. There are some limitations on character conversion,
however. The ASCII hosts must be able to convert the printer data stream to
EBCDIC before sending it using LPR.
To do this, you need to customize the LPD printer file on the AS/400. Full details
are given in the commentary to the code in the example shown in Figure 229 on
page 375.
Do not change the original printer file in QTCP. Instead, make a copy of it, change
the copy, and include it higher up the user library list portion of the *LIBL for the
user profile receiving the file.
There are two options for changing the LPD printer file:
1. Change the QUSRSYS/QPTMPLPD working copy from *USERASCII to *SCS. This
affects all LPR clients because it resides in the *SYSLIBL path and is found first
by all user profiles. This means that all LPR clients must send EBCDIC data
streams (or at least only send EBCDIC streams until the
QUSRSYS/QPTMPLPD printer file is restored to *USERASCII type).
2. Change the QUSRSYS/QPTMPLPD working copy from *USERASCII to *SCS, and
move it to another library that is your *CURLIB or somewhere in your *USRLIBL
path. Ensure that your target library is found ahead of library QTCP, which has
the installation copy of the printer file. You must also ensure that the target
library is unique to your user profile, *LIBL, in order to avoid affecting other
users.
Chapter 12. Line Printer Daemon (LPD)
373
Your *LIBL is considered to be one that exists when your user profile is signed on.
You cannot run any programs when you sign on to set the library list. Change to
your current interactive session has no effect upon the *LIBL used. This is because
the user profile *LIBL is checking occurs in an LPD server batch job and not your
interactive job.
To receive EBCDIC files, the LPR client must be any user with an AS/400 user
profile that has the *SCS working copy in its *LIBL path. For example, if
someone moves the printer file to library JOHNDOE, any user profile with
JOHNDOE as its *CURLIB or in its *USRLIBL uses the *SCS printer file.
Attention
Removing the working copy from library QUSRSYS forces every user profile that
does not have library JOHNDOE in its *LIBL to find the installation copy in QTCP. If
library QTCP is not already in the *LIBL, then the system adds it as the last library
in the *LIBL for all user profiles. This insures that the system finds a printer file. Do
not change the installation copy in QTCP. This insures that other user profiles,
including the default profile QTMPLPD, still receive ASCII data streams as usual.
System/370 Example
For System/370 systems, source files already exist in EBCDIC form. Therefore,
when you send System/370 files to an AS/400 using LPR, specify the binary option
to keep the system from translating the files from EBCDIC into ASCII.
The following example shows the LPR command to send to an AS/400 that has
DEVTYPE(*SCS) for the QPTMPLPD printer file:
LPR fname ftype fmode (HOST AS400.ENDICOTT.IBM.COM
PRINTER somelib/someoutq COPIES 1 NOHEADER
WIDTH 132 FILTER f LINECOUNT 66 BINARY
This example explicitly specifies the width of the source file. It is best if the source
file uses fixed-width records instead of variable-length records to ensure that it pads
all records to this width.
The BINARY flag indicates that the LPR platform must not do any EBCDIC to ASCII
conversion. This means that the LPD server receives an EBCDIC data stream into
an *SCS spooled file. However, this spooled file prints only on EBCDIC printers.
RISC System/6000 Example
This example uses the AIX C shell. It has not been tested on other UNIX systems.
In this example, you automatically pipe any program arguments passed into the dd
command and then pipe the output of the dd command to the lpr program.
In this example, as400 is the name of the AS/400 printer to which you are sending
the file.
374
OS/400 TCP/IP Configuration and Reference V4R4
#!/bin/csh -f
## Convert ASCII file to EBCDIC and send it to AS/400
# to be received as *SCS file
# the AS/400, it is required that the "working" LPD
# PRTF located in QUSRSYS be changed with the following
# command:
#
#
CHGPRTF FILE(QUSRSYS/QPTMPLPD) DEVTYPE(*SCS)
#
# When you are finished, restore the original settings
# with:
#
#
CHGPRTF FILE(QUSRSYS/QPTMPLPD) DEVTYPE(*USERASCII)
#
# Caveats:
#
# - Square brackets will not convert properly. Other
#
special characters may not convert properly.
#
# - If you customize the QUSRSYS/QPTMPLPD, you will
#
affect all users of LPD services who may not want
#
*SCS files.
#
# - It is strongly recommended that QTCP/QPTMPLPD be
#
left alone. This is the working installation
#
default version.
Copy or customize it to another
#
library that will be found ahead of QTCP.
#
# - If you erase the copy of QPTMPLPD in QUSRSYS, your
#
*LIBL is searched, and if no QPTMPLPD is found, the
#
version in QTCP is used. Therefore, you may copy
#
the QPTMPLPD printer file to a private library in
#
your *USRLIBL or *CURLIB and change it to be *SCS
#
without affecting other users, provided your copy
#
is found ahead of any other versions (namely, the
#
one in QTCP).
#------------------------------------------------------set nm=$0
if ("$1" == "-h" || "$1" == "") then
echo " "
echo "Usage:" "$nm:t" "[-h] file(s)"
echo " "
echo "Will convert file to EBCDIC and LPR to AS/400 printer queue"
echo "using the following string:"
echo " "
echo "
dd conv=ebcdic cbs=132 < $* | lpr -P as400 -l"
echo " "
exit
endif
echo "dd conv=ebcdic cbs=132 < $* | lpr -P as400 -l"
dd conv=ebcdic cbs=132 < $* | lpr -P as400 -l
exit;
Figure 229. Sample AIX C Shell for Printing AIX File on AS/400
Authority Required to Receive Spooled Files
The destination system administrator restricts output queue access for users without
user IDs on the destination system. This is done by restricting the access
authorities of the QTMPLPD user ID, which is the default profile used for any user
ID that is not found. However, this restriction does not affect user IDs that are found
on the destination system.
Chapter 12. Line Printer Daemon (LPD)
375
If you set the *PUBLIC authority of the user profile QTMPLPD to *EXCLUDE, only
users with user IDs that are the same on both the sending and receiving AS/400
systems receive spooled files on the destination system. The QTMPLPD user
profile ships with an authority of *OBJOPR. If you do not have a user ID on the
destination AS/400 system, you are still able to send spooled files to the destination
system under the QTMPLPD user profile.
Receiving Spooled Files — Benefits
There are advantages to having a user ID defined on the receiving AS/400 system.
If you have the same user ID on both systems, you are the owner of the spooled
file on the receiving system. It is then easier to find and access the spooled file on
the destination system. You can find the spooled file with the Work with Spooled
Files (WRKSPLF) command.
If you do not have a user ID on the receiving system, then QTMPLPD owns the file.
Because you do not own the spooled file, you might have limited access to the
spooled file. Your authority to the output queue on which the spooled file is located
determines your access to the spooled file.
If you are using a security level of 50, the system value QALWUSRDMN (allow user
domain objects in libraries) must contain the library name QTEMP to enable LPR
service. It must also contain the library name QUSRSYS to enable LPD service.
Creating a Default User Profile
A user profile, QTMPLPD, is necessary to allow remote LPR requests that do not
have an AS/400 user ID to access printer files on an AS/400 system running LPD.
The QTMPLPD user profile ships with the TCP/IP licensed program. If you damage
or delete the QTMPLPD user profile, specify the following to create the user profile:
CRTUSRPRF USRPRF(QTMPLPD)
PASSWORD(*NONE)
USRCLS(*USER)
MSGQ(QTCP/QTMPLPD)
AUT(*EXCLUDE)
PWDEXP(*NO)
PWDEXPITV(*NOMAX)
RVKOBJAUT OBJ(QTMPLPD)
OBJTYPE(*USRPRF)
USER(*PUBLIC)
AUT(*ALL)
GRTOBJAUT OBJ(QTMPLPD)
OBJTYPE(*USRPRF)
USER(*PUBLIC)
AUT(*OBJOPR)
376
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 13. BOOTP Server
Bootstrap Protocol, or BOOTP, provides a dynamic method for associating
workstations with servers. It also provides a dynamic method for assigning
workstation IP addresses and initial program load (IPL) sources. Together, BOOTP
and Trivial File Transfer Protocol, or TFTP, provide support for the IBM Network
Station for the AS/400 system. They also provide support for other clients that use
the BOOTP and TFTP protocols. For more information on TFTP, see “Chapter 14.
TFTP Server” on page 383.
BOOTP is a TCP/IP protocol. It allows a client to find its IP address and the name
of a load file from a server on the network. A client uses BOOTP to find this
information without intervention from the user of the client.
The BOOTP server listens on the well-known BOOTP server port 67, which DHCP
also uses. Because of this, BOOTP and DHCP cannot operate at the same time on
the same system. When the server receives a client request, it looks up the IP
address that is defined for the client and returns a reply to that client. This reply
contains both the client’s IP address and the name of the load file. The client then
initiates a TFTP request to the server for the load file.
The mapping between the client hardware address and IP address is kept in the
BOOTP table, which the AS/400 system administrator maintains. For information
about working with the BOOTP table, see “Working with the BOOTP Table” on
page 379.
Accessing BOOTP Functions through Operations Navigator
You can access BOOTP server functions from a command line interface or from
Operations Navigator. Not all BOOTP functions are available on both interfaces.
This chapter discusses how to start, stop, and configure the BOOTP server from
the command line interface. The only Operations Navigator function that this
chapter documents is how to add Network Stations to existings BOOTP
environments. For more information, see “Adding IBM Network Stations to an
Existing BOOTP Environment” on page 379.
To access BOOTP server functions through Operations Navigator, perform the
following steps:
1. Double-click your AS/400 server in the main tree view of Operations Navigator.
2. Double-click Network.
3. Double-click Servers.
4. Double-click TCP/IP.
5. Right-click BOOTP to open a context menu of BOOTP server functions.
Note: Although some of the functionality of the command line interface and the
Operations Navigator is the same, the actual menu commands and
parameters are not necessarily the same.
© Copyright IBM Corp. 1997, 1999
377
Starting the BOOTP Server
Specify the following Start TCP/IP Server (STRTCPSVR) command with the
SERVER parameter set to *BOOTP:
STRTCPSVR SERVER(*BOOTP)
Automatically Starting the BOOTP Server
Set the AUTOSTART parameter to *YES on the CHGBPA command. It has no effect
on the STRTCPSVR command because the STRTCPSVR command ignores the
AUTOSTART parameter value. If you run the STRTCPSVR SERVER (*BOOTP)
command while the BOOTP server is running, you receive a diagnostic message.
Ending the BOOTP Server
Specify the following End TCP/IP Server (ENDTCPSVR) command with the
SERVER parameter set to *BOOTP:
ENDTCPSVR SERVER(*BOOTP)
Configuring the BOOTP Server
Use the Configure TCP/IP BOOTP (CFGTCPBP) command to configure the
BOOTP server. The following are two different ways to get to this command prompt:
v Specify the Configure TCP/IP BOOTP (CFGTCPBP) command.
v Specify the Configure TCP/IP Applications (CFGTCPAPP) command from the
command line and select option 4, Configure BOOTP.
After you specify the command, the following display appears:
Figure 230. Configure TCP/IP BOOTP
Configure TCP/IP BOOTP
System:
SYSNAM01
Select one of the following:
1. Change BOOTP attributes
2. Work with BOOTP table
The following two AS/400 commands control the BOOTP server:
v The Change BOOTP Attributes (CHGBPA) command allows an administrator to
set the configurable attributes for the BOOTP server.
v The Work with BOOTP Table (WRKBPTBL) command allows an administrator to
work with the BOOTP table.
378
OS/400 TCP/IP Configuration and Reference V4R4
Changing BOOTP Attributes
Select option 1, Change BOOTP Attributes, of the Configure TCP/IP BOOTP display
(or simply type CHGBPA and press F4) to display the Change BOOTP Attributes
display. The AUTOSTART parameter controls if the BOOTP server is to start
automatically when TCP/IP is started with the STRTCP command.
Note: You must have *IOSYSCFG special authority to make changes to the
BOOTP attributes with the CHGBPA command.
Change BOOTP Attributes (CHGBPA)
Type choices, press Enter.
Autostart server . . . . . . . .
*YES
*YES, *NO, *SAME
Figure 231. Change BOOTP Attributes (CHGBPA)
Working with the BOOTP Table
Select option 2, Work with BOOTP Table, of the Configure TCP/IP BOOTP display
(or simply specify WRKBPTBL) to display the Work with BOOTP Table display.
The administrator uses the Work with BOOTP Table display to add, change,
remove, or display an entry in the BOOTP table.
For information about working with the BOOTP table, see IBM Network Station
Manager for AS/400, SC41-0632.
Work with BOOTP Table
Type options, press Enter.
1=Add
2=Change
4=Remove
Opt
System:
SYSNAM01
5=Display
Client
Host
Name
MAC
Address
IP
Address
act01.ibm.com
02.01.8C.06.34.98
9.130.42.1
Figure 232. Work with BOOTP Table (WRKBPTBL)
Adding IBM Network Stations to an Existing BOOTP Environment
This section describes how to add Network Stations to an existing BOOTP
environment. You can use either the command line interface or Operations
Navigator to add Network Stations.
Chapter 13. BOOTP Server
379
Note: You might have BOOTP clients that are on a subnet that is different from the
one on which the Bootstrap server is located. If this is the case, you need to
have a router that shows the server to those clients. For more information,
see Network Station Manager Installation and Use, SC41-0664-00.
Adding Network Stations with the Command Line Interface
This procedure describes how to use the command line interface to add Network
Stations to an existing BOOTP environment.
1. At an AS/400 command prompt, specify the following:
WRKBPTBL
2. In the Options field, specify 1 to add a Network Station.
3. Specify the following information:
v Client host name – The host name identifies the Network Station as a unique
destination within a TCP/IP environment. An example of a valid host name is
ns1.mycompany.com.
v MAC address – The Media Access Control (MAC) address is a unique,
hardware-specific identifier for each Network Station. The address is located
on the box of the Network Station. To find the MAC address without the box,
perform the following steps:
a. Power on the Network Station.
b. After the keyboard controller test, press Enter.
c. In the Setup Utility, press F4.
d. Record the MAC address.
v IP address – Each Network Station requires a unique IP address. Therefore,
you must assign a specific address to each Network Station. You must
ensure that the IP address is valid for your organization and that no other
device in the network uses it. An example of a valid IP address is
192.168.1.2.
4. Press Enter to exit the Configure TCP/IP BOOTP display.
Adding Network Stations with Operations Navigator
This procedure describes how to use Operations Navigator to add Network Stations
to an existing BOOTP environment. Operations Navigator requires OS/400 V4R2 or
later.
1. Use Operations Navigator to locate the BOOTP server with the following path:
Network object/Servers/OS/400
2. Double-click BOOTP.
3. Click Add.
4. Specify the following Network Device information:
v Client host name – The host name identifies the Network Station as a
unique destination within a TCP/IP environment. An example of a valid host
name is ns1.mycompany.com.
v MAC address – The MAC address is a unique, hardware-specific identifier
for each Network Station. The address is located on the box of the Network
Station. To find the MAC address without the box, perform the following
steps:
a. Power on the Network Station.
b. After the keyboard controller test, press Enter.
380
OS/400 TCP/IP Configuration and Reference V4R4
c. In the Setup Utility, press F4.
d. Record the MAC address.
v IP address – Each Network Station requires a unique IP address. Therefore,
you must assign a specific address to each Network Station. You must
ensure that the IP address is valid for your organization and that no other
device in the network uses it. An example of a valid IP address is
192.168.1.2.
v Hardware type – Your Network Stations can attach to either a Token-ring or
Ethernet LAN.
– Specify a value of 6 for Token-ring or IEEE (802.3) Ethernet networks.
– Specify a value of 1 for a Version 2 (802.2) Ethernet network.
5. If you do not use Gateway IP addresses for remote LANs, leave this field blank.
Otherwise, specify the IP address of the IP router or gateway that your Network
Station uses to reach the server.
6. If you do not use a subnet mask for remote LANs, leave this field blank.
7. Verify that the following default values are correct:
v Type is IBM Network Station Manager.
v File name and directory is /QIBM/ProdData/NetworkStation/kernel.
8. Click OK.
9. Repeat steps 3 through 8 for each additional Network Station.
10. Click OK to update the BOOTP server.
Chapter 13. BOOTP Server
381
382
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 14. TFTP Server
Trivial File Transfer Protocol, or TFTP, is a simple protocol that provides basic file
transfer function with no user authentication. Together, TFTP and Bootstrap
Protocol, or BOOTP, provide support for the IBM Network Station for an AS/400
system. They also provide support for other clients that use the TFTP and BOOTP
protocols. For more information on BOOTP, see “Chapter 13. BOOTP Server” on
page 377.
TFTP is a generic implementation that allows you to use clients other than IBM
Network Stations. For more information, see “Configuring TFTP for Clients other
than IBM Network Station” on page 389.
Accessing TFTP Functions through Operations Navigator
You can access TFTP server functions from either a command line interface or
Operations Navigator. Not all TFTP functions are available on both interfaces.
This chapter discusses how you start, stop, and configure the TFTP server from the
command line interface. This chapter does not document any of the Operations
Navigator functions. See the online Help for Operations Navigator for information
about using the Operations Navigator for TFTP functions.
To access TFTP server functions through Operations Navigator, perform the
following steps:
1. Double-click your AS/400 server in the main tree view of Operations Navigator.
2. Double-click Network.
3. Double-click Servers.
4. Double-click TCP/IP.
5. Right-click TFTP to open a context menu of TFTP server functions.
Note: Although some of the functionality of the command line interface and the
Operations Navigator is the same, the actual menu commands and
parameters are not necessarily the same.
Starting the TFTP Server
Specify the following Start TCP/IP Server (STRTCPSVR) command with the
SERVER parameter set to *TFTP:
STRTCPSVR SERVER(*TFTP)
The STRTCPSVR command ignores the AUTOSTART parameter value. If you run
the STRTCPSVR SERVER (*TFTP) command when the TFTP server is running,
you receive a diagnostic message.
Automatically Starting the TFTP Server
Set the AUTOSTART parameter to *YES on the CHGTFTPA command. The
AUTOSTART parameter of the CHGTFTPA command affects only the operation of
the STRTCP command. It has no effect on the STRTCPSVR command.
© Copyright IBM Corp. 1997, 1999
383
Ending the TFTP Server
Specify the following End TCP/IP Server (ENDTCPSVR) command with the Server
parameter set to *TFTP:
ENDTCPSVR SERVER(*TFTP)
Changing TFTP Attributes
The Change TCP/IP TFTP Attributes (CHGTFTPA) command is used to change the
TFTP server attributes. The following are two different ways to get to this command
prompt:
v Specify the Change TCP/IP TFTP Attributes (CHGTFTPA) command.
v Select option 3 on the Configure TCP/IP Applications (CFGTCPAPP) display.
Note: You must have *IOSYSCFG special authority to make changes to the TFTP
attributes with the CHGTFTPA command.
Change TFTP Attributes (CHGTFTPA)
Type choices, press Enter.
Autostart server . . . . . . . .
Enable subnet broadcast . . . .
Number of server jobs:
Minimum . . . . . . . . . . .
Maximum . . . . . . . . . . .
Server inactivity timer . . . .
ASCII single byte CCSID:
Coded character set identifier
Maximum block size . . . . . . .
Connection response timeout . .
Allow file writes . . . . . . .
Alternate source directory . . .
*NO
*YES
*YES, *NO, *SAME
*YES, *NO, *SAME
2
6
30
1-20, *SAME, *DFT
1-250, *SAME, *DFT
1-1440, *SAME, *DFT
00819
1024
60
*NONE
'*NONE'
1-65532, *SAME, *DFT
512-65464, *SAME, *DFT
1-600, *SAME, *DFT
*DFT, *NONE, *CREATE...
F3=Exit
F4=Prompt
F24=More keys
F12=Cancel
F5=Refresh
More...
F13=How to use this display
Figure 233. Change TFTP Attributes (CHGTFTPA) – Display 1
Change TFTP Attributes (CHGTFTPA)
Type choices, press Enter.
Alternate target directory . . .
'*NONE'
Figure 234. Change TFTP Attributes (CHGTFTPA) – Display 2
384
OS/400 TCP/IP Configuration and Reference V4R4
Server and Client Ports
The TFTP server uses a subnet-directed broadcast address as the destination
address. It also uses a well-known port as the port of datagrams sent to clients that
have requested the subnet broadcast option. The clients listen for and receive
datagrams on the well-known port. The keyword for the well-known port is
subntbcst_tftp, and its decimal value is 247.
The TFTP server sends subnet-directed broadcast datagrams to clients that request
the subnet broadcast option. The source ports from which the TFTP server sends
these datagrams do not have to be unique. They can be arbitrarily allocated.
Some routers filter or block subnet-directed broadcast datagrams. In support of
router filters, you can define restricted ports for the QTFTP profile. If you define
restricted ports for the QTFTP profile, the TFTP server uses only the defined
restricted ports as the source ports for the subnet-directed broadcast datagrams.
Network administrators define router filtering rules to allow subnet-directed
broadcast datagrams to pass through router filters based on the source port of
subnet-directed datagrams being one of the restricted ports defined for the QTFTP
profile.
TFTP Extensions
The following sections include information on the TFTP Transfer Size Option and
the Subnet Broadcast TFTP.
TFTP Transfer Size Option
The Transfer Size option allows the client to determine how much data is
transferred on a read request (RRQ). This is useful for requesting a subnet
broadcast of a file. The client finds the size of the buffer it needs in order to store
the file in memory. Drawing from this block size, the client determines the number
of blocks for the transfer. The number of blocks is helpful information for tracking
the blocks that have been received. You can also use it for the last block
acknowledgment (ACK), which must be sent to terminate a transfer normally.
Without the Transfer Size option, determining the size and the last block of the
transfer requires the client to wait for a block to be received that is smaller than the
block size of the transfer.
Note: For files transferred in netascii mode, this option might not be as useful if
you are converting the data during the transfer in a way that changes its
size. Also, the server might require additional processing time to determine
the transfer size due to conversion of the file to the appropriate CCSID.
TFTP Subnet Broadcast Option
With the increasing popularity of the Network Station, the possibility for boot storms
also increases. These storms occur when large numbers of clients request their
boot code at the same time. When hundreds of stations are involved in booting, the
same data must be routed through each hop in the network between each Network
Station and the server.
The TFTP Subnet Broadcast option provides a solution to this problem. It allows the
server to broadcast the boot code to the Network Stations on a subnet basis. Using
Chapter 14. TFTP Server
385
subnet-directed broadcast, Subnet Broadcast data packets are unicast between
routers until they reach the subnet on which the Network Stations reside. At this
point, the router at the destination subnet broadcasts the data packets to the
Network Stations on the subnet. Disinterested hosts on the subnet throw the data
packets away. The packets are usually thrown away by the host’s IP layer after it
determines that no applications are interested in receiving data on the port to which
the broadcast was directed. See Figure 235 on page 387 for an illustration of a
subnet-directed broadcast. This solution can drastically reduce the network traffic as
well as the time that it takes many Network Stations to boot when booting
simultaneously.
The TFTP Subnet Broadcast option enables clients to join a broadcasting filegroup.
It also allows clients to receive all subsequent blocks for a file until the client
becomes the master client. A client becomes the master client when it receives an
Option Acknowledge (OACK) packet from the TFTP server that indicates that it is
the master client. A client must keep track of blocks that it receives. After a client
becomes the master client, it can request the blocks that it has not received. The
master client requests blocks by sending ACK packets that include the block
number of the block prior to the block that the master client requires. For example,
if the client wants block 5, it sends an ACK with a block number of 4.
When a client receives an OACK packet that indicates that it is the master client,
the client must send an ACK that requests the first block it requires. From then on,
the client must request blocks in ascending but not necessarily consecutive order. A
master client continues to send ACK packets to the server to indicate the next block
that it requires. When the master client receives all of the blocks it requires, it sends
an ACK with the number of the last block on the file being transferred. Once the
server receives an ACK with the last block number of the file being transferred, the
transfer to the client sending the ACK is considered complete. A client can terminate
its transfer at any time by sending an ACK for the last block or by sending an Error
(ERR) packet. A client can terminate this transfer regardless of whether it is the
master client or not.
Note: This TFTP Subnet Broadcast option is designed to improve simultaneous
transfer of large files to multiple clients on a common subnet. This option
does not help with files that require only a few blocks to transfer or single
client transfers.
386
OS/400 TCP/IP Configuration and Reference V4R4
Figure 235. Example of Broadcasting over Subnets
Client to Server TFTP Read Request (RRQ) Options
The information that follows includes the additional TFTP options that are supported
and a description of their use. To view the standard TFTP request parameters and
their meanings, refer to Internet Request for Comments (RFC) 1350. For more
information related to the TFTP options that are described here, see RFCs 1782,
1783, and 1784. Internet RFC 2090 describes the TFTP multicast option, which has
some similarities to the Subnet Broadcast option. However, the TFTP Multicast
option it is not supported at this time. The TFTP Multicast option RFC is mentioned
here as a reference to help understand the Subnet Broadcast option.
The following is a list of supported options and their descriptions:
blksize
Null (0h) terminated keyword blksize that is followed by the requested block
size and represented as a null-terminated ASCII string. This option requests a
block size for the requested file transfer instead of using the default of 512.
sbroadcast
Null-terminated keyword sbroadcast that is followed by the subnet mask of the
subnet to which the client is connected. This option indicates that the client
wants to participate in a subnet-directed broadcast group. The subnet mask that
is included with this option is used with the client’s IP address to determine the
client’s subnet address.
Chapter 14. TFTP Server
387
tsize
Null-terminated keyword tsize that is followed by a null-terminated ASCII
representation of 0 (30h). This option is a request for the server to return the
file size in an Option Acknowledgment (OACK).
Server to Client TFTP Option Acknowledgment (OACK)
The TFTP server sends an Option Acknowledgment (OACK) to a client in response
to either a read request or a write request that includes additional TFTP options as
described in “Client to Server TFTP Read Request (RRQ) Options” on page 387. An
OACK that the servers sends in response to a transfer request includes only
responses to requested options that the server supports. The server can also send
an OACK to a client subsequently to the start of a subnet broadcast transfer. This is
done to indicate to the client whether it is the master client in a subnet broadcast
file group. An OACK packet that the server sends subsequently to the start of a
subnet broadcast transfer includes the sbroadcast option.
The following is a list of supported options and their descriptions:
blksize
Null (0h) terminated blksize keyword that is followed by the block size that is
used for this file transfer. It is represented as a null-terminated ASCII string.
This is the response to a requested block size, and the value returned here can
be less than the requested block size. The server determines the block size for
the transfer based on the requested block size, the maximum configured block
size, and possibly the subnet broadcast transfers that are already in progress.
sbroadcast
Null-terminated sbroadcast keyword that is followed by a null-terminated ASCII
string that includes the following fields separated by commas:
port
The ASCII representation of the port to which the subnet-directed broadcast
datagrams are broadcast. This is the well-known port that is registered with
the Internet Assigned Number Authority (IANA) with the keyword of
subntbcst_tftp and a decimal value of 247. This field might be empty in
OACK packets that the server sends subsequently to the start of a subnet
broadcast transfer.
sbid
The ASCII representation of a decimal number that is called the subnet
broadcast identifier. Possible values are 0 through 4,294,967,295
(FFFFFFFFh). This is used along with the server source port to determine if
a subnet-directed broadcast datagram is part of a requested transfer. This
field can be empty in OACK packets that the server sends subsequently to
the start of a subnet-based broadcast transfer.
mc
This is either an ASCII (31h) 1 or ASCII 0 (32h) to indicate to the client
whether it is currently the master client. A value of 1 indicates that the client
is the master client, and a value of 0 indicates that the client is not the
master client.
In response to an OACK, the master client must send an ACK to the server.
The master client sets the block number in this ACK to the number of the
block prior to the first block that is required by the master client.
388
OS/400 TCP/IP Configuration and Reference V4R4
The master client acknowledges subnet broadcast data (BDATA) packets by
sending an ACK to the server. The master client sets the block number in
this ACK to the block prior to the current block that the master client
requires.
Clients that are not indicated as being the master client respond to an
OACK packet with an ACK that has the block number set to zero.
Note: The block number in ACK packets is the 2-byte binary representation
of the number in network byte order.
tsize
The null-terminated tsize keyword that is followed by the null-terminated ASCII
representation of the decimal number that represents the file size of the
requested file. The client uses this information to ensure that it has enough
space to store the file and to determine the last block number of the file.
Note: The client can also determine the file size and last block of a transfer
when it receives a block that contains less data than the block size.
Server to Client Broadcast Data (BDATA) Packets
The following is a list of the fields in a Broadcast Data Packet and their
descriptions:
block#
2–byte binary number in the network byte order that indicates the number of a
particular block of data.
sbid
4–byte binary number in the network byte order that is called the subnet
broadcast identification. This must be compared with the sbid that was returned
in the OACK response to a read request (RRQ) with the Subnet Broadcast
option. Along with the source port, this uniquely identifies a Subnet Broadcast
File Transfer. The source port of the BDATA packet must be compared with the
source port of the initial OACK packet that was received for this transfer. Only
BDATA packets that match on both the SBID and source ports are considered
part of the requested transfer. All other BDATA packets must be ignored.
data
This is the data for this block of the file transfer. With the exception of the last
block of the file, the size of the data is equal to the block size for the transfer.
The last block of the file must be less than the block size, even if it means that
the length of the data in the last block is zero. However, the server might not be
done broadcasting blocks after the last block of the file is broadcast. Control
can be transferred to another client in the subnet broadcast file group that has
not yet received all the blocks in the file.
Configuring TFTP for Clients other than IBM Network Station
To allow other clients to use the TFTP server, you must ensure that the QTFTP
profile has authority to access the directories and files that the clients access
through the TFTP server. You also need to set the TFTP server attributes to allow
the desired client requests.
When configuring TFTP for use by clients other than the IBM Network Station, first
determine the directories and files that the clients are using. For this example, the
clients use the TFTP server to read files from the directory /netpc/bin/system.
Chapter 14. TFTP Server
389
1. Use the MKDIR command with an argument of /netpc to create the directory
/netpc, as follows:
MKDIR (netpc)
2. Specify the WRKLNK command with an argument of /netpc, as follows:
WRKLNK (netpc)
3. Specify option 9 to display the current authorities.
4. For the *PUBLIC user, specify option 2, Change user authority, and specify
*NONE for New data authorities. This ensures that the file is not open to the
public.
5. To add a user on the Work with Authority menu, specify the following on the first
line: 1 for Opt, QTFTP for User, and *RX for Data Authority. Press Enter.
6. Press the PF5 key to refresh the menu. You see the userid *PUBLIC with a data
authority of *EXCLUDE, the userid QTFTP with a data authority of *RX, and your
own userid with a data authority of *RWX.
Use the MKDIR command to create the following directories:
/netpc/bin
/netpc/bin/system
Each directory inherits the authority of the parent directory and has the owner
added implicitly as a user with *RWX authority. Copy any files that the client
requests to the netpc/bin/system subdirectory. You can copy the files in various
ways, such as using the COPY command, FTP, or Client Access/400. You must
ensure that the QTFTP profile has *R authority to each file that the client
requests. To set the authorities for the files, use the WRKLNK command and
option 9, Work with Authority.
7. Specify the CHGTFTPA command and press the PF4 key.
8. Change the Alternate source directory to /netpc/bin/system and press Enter.
This allows the TFTP server to request any file with the appropriate authority
settings, including the directory /netpc/bin/system in its path.
9. To have the changes take effect, stop the TFTP server with ENDTCPSVR *TFTP
and restart it by using STRTCPSVR *TFTP.
390
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 15. RouteD Server
The Route Daemon, or RouteD, provides support for the Routing Information
Protocol, or RIP, on an AS/400 system. RIP is the most widely used routing protocol
today. It is an Interior Gateway Protocol, or IGP, that assists TCP/IP in the routing of
IP data packets within an autonomous domain. Dynamic routing protocols allow you
to handle networks with multiple routers or automatic switching to redundant routes.
RIP Version 2 is available for Version 4 Release 2 and above. If you have migrated
from a previous release, the system automatically migrates your routing
configuration files as part of the Version 4 Release 2 installation process. For more
information, see “Working with RouteD Configuration” on page 393 and
“RIP_INTERFACE Statement” on page 394.
Accessing RouteD Functions through Operations Navigator
You can access RouteD server functions from a command line interface or from
Operations Navigator. Not all of the RouteD functions are available on both
interfaces. However, most RouteD functions are available only through Operations
Navigator.
This chapter discusses how to start, stop, and configure the RouteD server from the
command line interface. It does not document any of the Operations Navigator
functions. See the online Help in Operations Navigator for information about using
Operations Navigator for RouteD functions.
To access RouteD server functions through Operations Navigator, perform the
following steps:
1. Double-click your AS/400 server in the main tree view of Operations Navigator.
2. Double-click Network.
3. Double-click Servers.
4. Double-click TCP/IP.
5. Double-click RouteD.
Note: Although some of the functionality of the command line interface and the
Operations Navigator is the same, the actual menu commands and
parameters are not necessarily the same.
The online help in Operations Navigator assists you with the following:
v Starting the RouteD server.
v Automatically starting the RouteD server whenever TCP/IP is started.
v Ending the RouteD server.
v Configuring the RouteD server.
Starting the RouteD Server
To start the RouteD server, specify the following Start TCP/IP Server (STRTCPSVR)
command with the SERVER parameter set to *ROUTED:
STRTCPSVR SERVER(*ROUTED)
© Copyright IBM Corp. 1997, 1999
391
Automatically Starting the RouteD Server
The AUTOSTART parameter of the CHGRTDA command affects the operation of
the STRTCP command. It has no effect on the STRTCPSVR command, which
ignores the AUTOSTART parameter value. If you run the STRTCPSVR SERVER
(*ROUTED) command when the RouteD server is running, you receive a diagnostic
message.
You can use the STRTCPSVR command to restart the RouteD server when the
RouteD server is not running. However, the system ignores the restart instruction
and simply starts the server.
Ending the RouteD Server
To end the RouteD server, specify the following End TCP/IP Server (ENDTCPSVR)
command with the server attribute set to *ROUTED:
ENDTCPSVR SERVER(*ROUTED)
Another way to end the RouteD server (and all other servers) is to specify the
ENDTCPSVR command without parameters. If you use the ENDTCPSVR command
to end a server that is not active, you receive a diagnostic message.
Configuring the RouteD Server
Use the Configure TCP/IP RouteD (CFGTCPRTD) command to configure the
RouteD server. The following are two different ways to get to this command prompt:
v Specify the Configure TCP/IP RouteD command, CFGTCPRTD, from the command
line.
v Specify the Configure TCP/IP Applications command, CFGTCPAPP, from the
command line. Select option 2 (Configure RouteD).
After you specify the command, you see the following display:
Configure TCP/IP RouteD
System:
SYSNAM01
Select one of the following:
1. Change RouteD attributes
2. Work with RouteD configuration
Figure 236. Configure TCP/IP RouteD
The following two AS/400 commands control the RouteD server:
v The Change RouteD Attributes (CHGRTDA) command allows an administrator to
set the configurable attributes for the RouteD server.
v The Work with RouteD Configuration (WRKRTDCFG) command allows an
administrator to work with the RouteD configuration.
392
OS/400 TCP/IP Configuration and Reference V4R4
Working with RouteD Configuration
Use the Work with RouteD Configuration (WRKRTDCFG) command to change the
RouteD server configuration. The following are two different ways to get to this
command prompt:
v Specify the Work with RouteD Configuration command, WRKRTDCFG.
v Select option 2 on the Configure TCP/IP RouteD (CFGTCPRTD) display.
Note: You must have *IOSYSCFG special authority to make changes to the
RouteD configuration with the WRKRTDCFG command.
Work with RouteD Configuration
Type options, press Enter.
1=Add
2=Change
3=Copy
Opt
Sequence
Number
_____
_____
_____
_____
_____
_____
_____
_____
_____
_____
_____
_____
_____
F3=Exit
00010
00020
00030
00040
00050
00060
00070
00080
00090
00100
00110
00120
00130
4=Remove
5=Display
System:
SYSNAM01
13=Insert
Entry
#
#
#
#
#
#
#
#
#
#
#
#
#
* * * * * * * * * * * * * * * * * * * * * * * * * * *
RTD DEFAULT CONFIGURATION
* * * * * * * * * * * * * * * * * * * * * * * * * * *
RouteD Interface Definitions
---------------------------TCP/IP will learn about a route to network 9.0.0.0 th
means external to RouteD, therefore do not allow Rout
route to this network.
RIP_INTERFACE * SUPPLY RIP1 METRIC 1 BLOCK 9.0.0.0 MA
F5=Refresh
F6=Print List
F12=Cancel
F17=Top
>
>
>
>
>
>
>
More...
F18=Bottom
Figure 237. Work with RouteD Configuration
RouteD Configuration Scenario
Figure 238 on page 394 shows how the RouteD configuration entries work in a
sample network. The routers know every route within every network, including
networks X, Y, Z, A, and W.
Chapter 15. RouteD Server
393
Figure 238. RouteD Configuration Scenario
v Case 1 – If router AY has an interface of 192.10.2.1, a metric of 1, and a
NOFORWARD parameter of 192.50.21.0, then none of the hosts in the networks
reach network A.
v Case 2 – If router WZ has an interface of 192.10.3.1, a metric of 1, and a
NOFORWARD parameter of 192.10.4.0, then none of the IP packets go through
router WZ to get to network W. IP packets can still reach network W, however,
because router WY provides a route to that network.
Note: If you set the parameter option of any interface to Passive, then no routing
takes place across the interface.
RIP_INTERFACE Statement
Use the RIP_INTERFACE statement to specify all of the routing options that you
configure on a per-interface basis. The RIP_INTERFACE statement now contains
the functionality for defining routes and creating static routes. Prior to Version 4
Release 2, this functionality existed in the NET statement and HOST statement.
You can specify multiple interface options on a single entry in the configuration file.
You can accomplish this only if one of those options that requires a destination
address appears on a given statement. Options include the following: block,
forward, forward.cond, and noforward. For example, a statement can use the
forward and metric options on a single line. However, the forward and noforward
options cannot appear on the same line. It is recommended that only one option
appear on a given line. It is also recommended that you use multiple lines to
specify multiple options for a given interface.
You can specify interfaces on the AS/400 system in the following methods:
Network
Specified as an IP address and either a mask or an IP address and bit number.
The bit number n indicates which bit in the 0 – n bits of the IP address
(counting left to right) is the last bit of the IP address’ network portion. If the
MASK and bit number are missing, the system calculates a network by using
the subnet mask of the interface specified through the ADDTCPIFC command.
Interface name
Logical Interface name that identifies a PPP interface with an IP address that is
assigned dynamically when the PPP connection becomes active.
Hostname
The Host name of the AS/400 system, which is resolvable through DNS.
394
OS/400 TCP/IP Configuration and Reference V4R4
*
Refers to all of the interfaces on the AS/400 system and is useful for setting
default values that apply to all interfaces. You can override these defaults by
providing a RIP_INTERFACE statement for a specific interface with different
values for selected parameters.
Supply Values
The following is a list of possible values for a RIP_INTERFACE supply value:
PASSIVE
The system does not receive or generate any RIP traffic on the specified
interface.
SUPPLY RIP1
Indicates which version of the RIP protocol the system uses to send and
receive routing information to and from neighboring routers. For SUPPLY RIP1,
the system processes only RIPv1 packets.
SUPPLY RIP2
Indicates which version of the RIP protocol the system uses to send and
receive routing information to and from neighboring routers. For SUPPLY RIP2,
the system uses the multicast address 224.0.0.9 to process only RIPv2
packets, as specified in the RFC1723 sect.3.5.
SUPPLY OFF
Indicates that the system receives both RIPv1 and RIPv2 on the specified
interface. However, the system does not send RIP packets.
Note: The default supply value for interfaces that you do not specify is SUPPLY
RIP1. The system does not support RIP Version 1 Compatibility mode.
DIST_ROUTES_IN
DIST_ROUTES_IN controls how RouteD redistributes routes that it receives from
this RIP_INTERFACE network to Wide Area Networks, or WANs. This parameter
does not affect redistribution of routes to Local Area Networks, or LANs. The
following is a list of values and their definitions:
*CALC
RouteD determines a value of FULL or LIMITED by whether the RIP_INTERFACE
network is a LAN or a WAN. If the specified interface is broadcast-capable, it is
assumed local, and a value of FULL is given. Otherwise, the system uses a
value of LIMITED.
FULL
Indicates that RouteD redistributes routes that it receives from the specified
interface to all of the other interfaces using normal RIP algorithm. Specify this
value only for local networks.
LIMITED
Indicates that the server is not to redistribute routes that it receives from the
RIP_INTERFACE network to other LIMITED interfaces. Specify this value only
for some type of WAN. You cannot set this value for a LAN.
Metric
This parameter specifies the metric that the system adds to routes that it receives
through the specified interface. Possible values are 1 through 15.
Chapter 15. RouteD Server
395
Community
This parameter specifies the community name used by this interface for
authentication purposes as specified in RFC 1723 section 3.1. It is valid for
interfaces with a SUPPLY value of RIP2. The rip_community_name is a character
string of 1 to 16 characters in length.
If you specify the community option, then the system indicates that authentication is
needed for this interface. The community name that is specified with the community
option must match the community name sent in all RIP2 message blocks for this
interface. If you do not specify the community option, then the system does not
indicate any authentication for this interface.
Additional Parameters
You can also encounter the following RIP_INTERFACE parameters:
v BLOCK
v FORWARD
v FORWARD.COND
v NOFORWARD
BLOCK
The BLOCK parameter prevents the network route received on the specified
interface from being included in the RouteD routes table. Consequently, the network
is unknown and not forwarded to any other routers. Specify networks that you want
to block by one of the following methods:
Network
A network that is specified as an IP address and a mask or as an IP address
and a bit number. The bit number n indicates which bit in the 0 – n bits of the
IP address (counting left to right) is the last bit of the network portion of the IP
address. If the MASK and bit number are missing, the system calculates a
network by using the subnet mask of the interface specified through the
ADDTCPIFC CL command.
PRIVATE
The PRIVATE keyword refers to the sets of IP addresses that are designated
for use by the Internet Assigned Number Authority (IANA) only within private
internets. For more information, see RFC 1918, section 3.
v 10.0.0.0 to 10.255.255.255 (10/8 prefix) – 1 class A network.
v 172.16.0.0 to 172.31.255.255 (172.16/12 prefix) – 16 contiguous class B
networks.
v 192.168.0.0 to 192.168.255.255 (192.168/16 prefix) – 256 contiguous class C
networks.
When the RouteD server tries to send a route, it processes multiple forward
parameters in the supplied order. The first forward parameter that allows the system
to send the route over the specified interface ends the processing. The default is
not to forward.
396
OS/400 TCP/IP Configuration and Reference V4R4
FORWARD
Use of the FORWARD keyword forwards the specified network route exclusively
over the specified interface. If the specified interface is inactive, RouteD takes no
special action to forward this network.
Specify a network as both an IP address and a mask or as both an IP address and
a bit number. The bit number n indicates which bit in the 0 – n bits of the IP
address (counting left to right) is the last bit of the network portion of the IP
address. If the MASK and bit number are missing, the system calculates a network
by using the subnet mask of the interface specified through the ADDTCPIFC CL
command.
FORWARD.COND
Use of the FORWARD.COND keyword forwards the specified network route
exclusively over the specified interface. If the specified interface is inactive, RouteD
forwards the network over all of the other interfaces.
Specify a network as both an IP address and a mask or as both an IP address and
a bit number. The bit number n indicates which bit in the 0 – n bits of the IP
address (counting left to right) is the last bit of the network portion of the IP
address. If the MASK and bit number are missing, the system calculates a network
by using the subnet mask of the interface specified through the ADDTCPIFC CL
command.
NOFORWARD
When you use the NOFORWARD parameter, the system does not send out RIP
information about the specified network to the specified interface. Specify networks
in one of the following two methods:
Network
Specify a network as both an IP address and a mask or as both an IP address
and a bit number. The bit number n indicates which bit in the 0 – n bits of the
IP address (counting left to right) is the last bit of the network portion of the IP
address. If the MASK and bit number are missing, the system calculates a
network by using the subnet mask of the interface specified through the
ADDTCPIFC CL command.
PRIVATE
The PRIVATE keyword refers to the sets of IP addresses designated for use by
the IANA within private internets. For more information, see RFC 1918, section
3.
v 10.0.0.0 to 10.255.255.255 (10/8 prefix) – 1 class A network.
v 172.16.0.0 to 172.31.255.255 (172.16/12 prefix) – 16 contiguous class B
networks.
v 192.168.0.0 to 192.168.255.255 (192.168/16 prefix) – 256 contiguous class C
networks.
Changing RouteD Attributes
Use the Change RouteD Attributes (CHGRTDA) command to change the RouteD
server attributes. The following are two different ways to get to this command
prompt:
v Specify the Change RouteD Attributes command, CHGRTDA.
Chapter 15. RouteD Server
397
v Select option 1 on the Configure TCP/IP RouteD (CFGTCPRTD) display.
Note: You must have *IOSYSCFG special authority to make changes to the
RouteD attributes with the CHGRTDA command.
Change RouteD Attributes (CHGRTDA)
Type choices, press type.
Autostart . . . . . . . . . . .
Supply . . . . . . . . . . . . .
*No
*No
Figure 239. Change RouteD Attributes (CHGRTDA)
398
OS/400 TCP/IP Configuration and Reference V4R4
*SAME, *YES, *NO
*SAME, *YES, *NO
Chapter 16. REXEC Server
|
|
|
|
|
The Remote Execution (REXEC) server is a TCP/IP application that allows a client
user to submit system commands to a remote server system. The user identifier,
password, and command to be performed are sent from the user’s client program to
the server. The server validates the user, runs the requested command, and returns
the results of the command to the client.
|
Commands submitted to the AS/400 host fall into three categories:
|
|
|
AS/400 command processor
You run AS/400 command processor commands by specifying QCAPCMD as
the target of the client REXEC.
|
|
|
Qshell command interpreter (OS/400 option 30)
You can use the Qshell interpreter by specifying qsh as the target of client
REXEC.
|
|
|
|
″Spawned paths″
You can run any AS/400 program in a ″child″ (spawned) job by specifying
the complete path to the program or shell script as the target of the REXEC
command.
|
Accessing REXEC Functions through Operations Navigator
|
|
Although, most REXEC functions are available only from a command line interface,
you can also access configuration options from Operations Navigator.
|
|
|
|
To access REXEC server functions through Operations Navigator, perform these
steps:
1. Double-click your AS/400 server in the main tree view of Operations Navigator.
2. Double-click Network.
3. Double-click Servers.
|
|
|
4. Double-click TCP/IP.
5. Double-click REXEC.
|
|
See the online Help in Operations Navigator for information about using Operations
Navigator for REXEC functions.
|
|
The remainder of this chapter discusses how to start, stop, and configure the
REXEC server from the command line interface.
|
|
|
Note: Although the command line interface and Operations Navigator provide much
of the same function, the actual menu commands and parameters are not
necessarily the same.
|
Starting the REXEC Server from the Command Line Interface
Specify the Start TCP/IP Server (STRTCPSVR) command with the SERVER
parameter set to *REXEC, as follows:
STRTCPSVR SERVER(*REXEC)
© Copyright IBM Corp. 1997, 1999
399
Automatically Starting the REXEC Server
The AUTOSTART setting in the REXEC configuration affects the operation of the
STRTCP command. It has no effect on the STRTCPSVR command. The
STRTCPSVR command ignores the AUTOSTART parameter value. If you run the
STRTCPSVR SERVER (*REXEC) command when the REXEC server is running,
the system starts one additional REXEC server.
|
|
|
|
|
Ending the REXEC Server
Specify the End TCP/IP Server (ENDTCPSVR) command with the server attribute
set to *REXEC, as follows:
ENDTCPSVR SERVER(*REXEC)
Changing Attributes
The Change REXEC Attributes (CHGRXCA) command changes the REXEC server
attributes. The following are two ways to get to this command prompt:
v Specify the Change REXEC Attributes (CHGRXCA) command.
v Select Option 17 on the Configure TCP/IP Applications (CFGTCPAPP) display.
Note: You must have *IOSYSCFG special authority to make changes to the
REXEC attributes with the CHGRXCA command.
Figure 240. Change REXEC Attributes (CHGRXCA)
Change REXEC Attributes (CHGRXCA)
Type choices, press Enter.
Autostart server . . . . . . . . *YES
Number of initial servers
. . .
2
Inactivity timeout . . . . . . .
300
Coded character set identifier
00437
*YES, *NO, *SAME
1-20, *SAME, *DFT
1-2147483647, *SAME, *DFT
1-65533, *SAME, *DFT
REXEC Command Considerations
The REXEC server is restricted to running commands that are allowed in batch
jobs. The command must have *BATCH as one of the Where allowed to run values.
The maximum length of a command that the REXEC server can process is 4000
bytes. Some REXEC clients limit the command to a smaller length.
|
|
|
|
For spawned paths, the program that runs in the child process must be either a
program object in the QSYS.LIB file system (*PGM object) or a shell script. You
must specify the path with the proper syntax for the file system in which the file
resides.
|
|
For Qshell commands, you can put the same commands that you would enter at an
interactive command line into a non-interactive shell script.
400
OS/400 TCP/IP Configuration and Reference V4R4
|
|
Selecting a Command Processor
|
|
|
|
|
|
|
|
You can use the REXEC server command processing selection exit program
(QIBM_QTMX_SVR_SELECT) to select which command processor the REXEC
server uses to run the submitted command. (If you do not use an exit program, the
REXEC server uses the AS/400 Control Language (QCAPCMD) processor.) The
allowed command processors are:
v AS/400 Control Language (QCAPCMD)
v Qshell interpreter
v Spawned path (a shell script or program object)
|
|
|
Because data conversion is optional for the Qshell and spawn options, the exit
program also selects whether the REXEC server performs ASCII-EBCDIC
conversions on the stdin, stdout, and stderr streams.
REXEC Connection Usage
The REXEC protocol allows a REXEC client to specify whether to use one or two
connections for returning data.
For AS/400 CL command processing
|
|
|
|
|
|
If you choose AS/400 CL command processing and two connections, normal output
returns on the first connection, and error output returns on the second connection.
The REXEC server returns all spooled data that is written to the default printer file
(*PRTF). This includes data that is written to the screen if the command is run in an
interactive job. Any messages written to the job log return to the client on the
second connection.
|
If the client specifies that all data is returned on a single connection, the job log
messages are returned first, followed by any spooled output.
|
For Qshell and spawned path command processing
|
|
|
|
|
|
For Qshell or spawned path command processing, the REXEC server by default
returns normal output on the first connection and error output on the second
connection. (The REXEC stdin, stdout, and stderr streams are mapped to file
descriptors 0, 1, and 2 respectively, and the QIBM_USE_DESCRIPTOR_STDIO
environment variable is set to Y.) These options allow you to redirect input and
output.
|
Choosing the Qshell command processor sets these environment variables:
v TERMINAL_TYPE=REMOTE
v PATH=/usr/bin
v LOGNAME= user, where user is the user profile
|
|
|
|
v HOME=homedir, where homedir is the user’s home directory
|
The child job inherits any other environment variables that the exit program sets.
|
|
|
Spawned child processes are batch jobs or prestart jobs. They cannot do interactive
I/O. See ILE C for AS/400 Programmer’s Guide, SC09-2712-01 for complete details
on this support.
Chapter 16. REXEC Server
401
Spooled Output Considerations
Note: This section applies only to AS/400 CL commands.
The REXEC server overrides the default printer file (*PRTF) to capture spooled
output. Any resulting spool files are tagged with the user data field set to REXECSVR.
After the REXEC server runs the specified command, each spooled file with this
user data tag is retrieved, returned to the client, and then deleted. If more than one
spool file is created, the files are processed in the order created, as determined by
the spool file number.
|
|
If the command or program run through REXEC performs its own print file override
and changes the user data, the REXEC server is unable to capture and return the
resulting spooled data.
Client Considerations
The AS/400 REXEC client (RUNRMTCMD) uses a single connection for returned
data, which is written to a spooled file on the client system. The RUNRMTCMD
command is documented in CL Reference (Abridged), SC41-5722.
The UNIX, OS/2, Windows 95, and Windows NT REXEC clients all use two
connections, returning the normal output to the stdout stream and the error output
to the stderr stream.
The VM REXEC client uses a single connection for the returned data, which is
written to the console of the user.
REXEC Server Jobs and Job Names
REXEC server jobs start when you run the STRTCP command and setthe REXEC
AUTOSTART parameter to *YES. You can also start REXEC server jobs by running
the STRTCPSVR command with a SERVER parameter of *REXEC or *ALL. These
jobs run in the QSYSWRK subsystem. Their purpose is monitoring and processing
requests from REXEC client users. The format for the names of these jobs is
QTRXCnnnnn, where nnnn is a 5-digit decimal number.
|
|
|
|
|
|
To work with jobs in the QSYSWRK subsystem, including REXEC server jobs,
specify the following command:
WRKSBSJOB SBS(QSYSWRK)
|
|
|
If you choose to have commands processed by the Qshell command interpreter,
you start Qshell is by using the spawn() application program interface (API) to
create a child job.
|
|
|
|
|
|
If you choose to have commands interpreted as spawn path names, the REXEC
server treats command strings as path names and passes them to the spawn() API.
Spawned child processes are batch jobs or prestart jobs. Shell scripts are allowed
for the child process. If you specify a shell script, the appropriate shell interpreter
program is called. The shell script must be a text file and must contain this format
on the first line of the file:#!interpreter_path <options>.
402
OS/400 TCP/IP Configuration and Reference V4R4
Creating REXEC Server Spooled Job Logs
The REXEC server automatically writes a server job log to a spooled file when it
ends with an error.
To have a spooled job log produced at the end of each REXEC session and each
time the REXEC server ends, use the CHGJOBD command, as follows:
CHGJOBD JOBD(QTCP/QTMXRXCS) LOG(4 00 *SECLVL)
To obtain a spooled job log only when a server ends, use the CHGJOBD command,
as follows:
CHGJOBD JOBD(QTCP/QTMXRXCS) LOG(4 00 *NOLIST)
Exit Points for Controlling REXEC Server
|
|
|
|
|
|
|
|
|
|
|
Available exit points give you additional control over the REXEC server. The TCP/IP
request validation exit point (QIBM_QTMX_SERVER_REQ) provides additional
control for restricting an operation. The REXEC server command processing
selection exit point (QIBM_QTMX_SVR_SELECT) allows you to specify which
command processor the REXEC server uses for interpreting and running your
commands. If you add exit programs to both of these exit points, REXEC server
first calls the program that you add to QIBM_QTMX_SERVER_REQ. The TCP/IP
server logon exit point (QIBM_QTMX_SVR_LOGON) provides additional control
over authenticating a user and setting up the user’s environment for the REXEC
server. For a detailed description of these exit points and how to use them, see
“Appendix E. TCP/IP Application Exit Points and Programs” on page 535.
Chapter 16. REXEC Server
403
404
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 17. DHCP Server
Dynamic Host Configuration Protocol, or DHCP, provides a framework for passing
configuration information to hosts on a TCP/IP network. DHCP functions either as a
DHCP server or as a BOOTP/DHCP Relay Agent. If DHCP functions as a DHCP
server, it processes DHCP packets on the local system. If DHCP functions as a
BOOTP/DHCP Relay Agent, it relays DHCP and BOOTP packets on the local
system but does not process them. The Relay Agent forwards the packets to one or
more different server IP addresses. The Relay Agent uses port 67, the same port
that the BOOTP or DHCP server uses.
During configuration, you must specify the IP addresses that the Relay Agent uses
for forwarding. When the Relay Agent forwards a packet, it inserts its address into
the packet. It does this so the DHCP or BOOTP server can return a response to
that Relay Agent. For more information on DHCP Relay Agents, see “DHCP Relay
Agent” on page 420.
DHCP Overview
DHCP enables client machines to get network configuration information, including
an Internet Protocol (IP) address, from a central DHCP server. The administrator
sets the DHCP server to assign the network information to each client, which
makes the process transparent to the user. DHCP saves time, reduces errors, and
insures the consistency of the configurations for mobile and non-mobile users.
What is DHCP?
DHCP is a client/server protocol that enables you to centrally locate and
dynamically distribute configuration information, including IP addresses.
DHCP is based on the Bootstrap Protocol, or BOOTP, and adds the capability for
automatically allocating reusable network addresses. It also adds the capability for
distributing additional host configuration options. DHCP clients and servers use
existing BOOTP/DHCP Relay agents.
DHCP defines IP address allocation policies, including the following:
Dynamic
A DHCP server assigns an IP address to a requesting BOOTP or DHCP client
from a range of available addresses.
Static
A DHCP server administrator assigns a static, pre-defined address that is
reserved for a specific BOOTP or DHCP client.
DHCP provides the following lease policies for IP addresses:
Temporary
An IP address is temporarily leased to a DHCP client. To continue using the
address, a DHCP client that does not have a permanent lease must periodically
request the renewal of its lease on its current IP address. The process of
renewing leased IP addresses occurs dynamically as part of the DHCP
protocols. It is not generally visible to end users.
© Copyright IBM Corp. 1997, 1999
405
Permanent
A BOOTP or DHCP client leases an IP address for an infinite period of time. No
process of lease renewal is required.
Planning for DHCP
Before you put DHCP into effect in your network, you need to make the following
decisions:
v How many DHCP servers do you need?
v Do you already have BOOTP servers in your network?
v Do you have hosts with special requirements?
v What is a reasonable lease time?
How Many DHCP Servers do you Need?
The number of servers that you need depends largely on the number of subnets
you have and the number of DHCP clients that you plan to support. It also depends
on the lease time that you choose and whether your routers (or individual
computers on the subnets) are enabled with BOOTP Relay. Keep in mind that the
DHCP protocols do not currently define server-to-server communication. Therefore,
they cannot share information, and one DHCP server cannot perform as a hot
backup if the other one fails.
DHCP clients send broadcast messages. By design, broadcast messages do not
cross subnets. To allow the client’s messages to be forwarded outside its subnet,
you must configure a BOOTP/DHCP Relay Agent. Otherwise, you must configure a
DHCP server on each subnet.
Note: Many routers available today can act as a BOOTP/DHCP Relay Agent.
Software is also available for some operating system platforms that enable a
regular computer on the network to act as a BOOTP/DHCP Relay Agent. On
the AS/400 system, BOOTP/DHCP Relay capability comes standard as part
of the DHCP server.
Using a Single DHCP Server: If you choose to use a single DHCP server to
serve hosts on a subnet, you must consider the effects if the single server fails.
Generally, the failure of a server affects only those DHCP clients that attempt to join
the network. DHCP clients already on the network typically continue operating
unaffected until their lease expires. However, clients with a short lease time might
lose their network access before you can restart the server.
Using Multiple DHCP Servers: To avoid a single point of failure, you can
configure two or more DHCP servers to serve the same subnet. If one server fails,
the other continues to serve the subnet. Each of the DHCP servers must be
accessible either by direct attachment to the subnet or by using a BOOTP/DHCP
Relay Agent. Remember that you cannot run more than one DHCP server on any
individual system. Multiple DHCP servers require multiple systems.
Because two DHCP servers cannot serve the same addresses, address pools that
you define for a subnet must be unique across DHCP servers. Therefore, when
using two or more DHCP servers to serve a particular subnet, you must divide the
complete list of addresses for that subnet among the servers. Configure one server
with an address pool that consists of 70% of the available addresses for the subnet.
Configure the other server with an address pool that consists of the remaining 30%
of the available addresses.
406
OS/400 TCP/IP Configuration and Reference V4R4
Using multiple DHCP servers decreases the probability of having a DHCP-related
network access failure, but it does not guarantee against it. If a DHCP server for a
particular subnet fails, the other DHCP server might be unable to service all of the
requests from new clients. This can use every available address in the server’s
limited pool.
You can bias which DHCP server uses all of its addresses first. DHCP clients tend
to select the DHCP server that is offering more options. To bias service toward the
DHCP server with 70% of the available addresses, offer fewer DHCP options from
the server that holds 30% of the available addresses for the subnet.
Do you Already have BOOTP Servers in your Network?
If you already have BOOTP clients and servers in your network, consider replacing
your BOOTP servers with DHCP servers. DHCP servers can optionally serve
BOOTP clients the same IP configuration information as current BOOTP servers.
If you cannot replace your BOOTP servers with DHCP servers or want both to
serve your network, perform the following steps:
1. Turn off BOOTP support in your DHCP server.
2. Make sure that your BOOTP servers and DHCP servers do not give out the
same IP addresses.
3. Configure any BOOTP/DHCP Relay Agents to forward the BOOTP/DHCP
broadcasts to both the appropriate BOOTP and DHCP servers.
You also need to consider that BOOTP and DHCP servers cannot both run on any
individual system. To continue running your BOOTP servers in addition to your
DHCP servers, you need to run them on separate systems.
A DHCP server allocates a permanent IP address to a BOOTP client. If subnets are
renumbered in such a way that a BOOTP-assigned address is unusable, you must
restart the BOOTP client and obtain a new IP address.
Do you have Hosts with Special Requirements?
You might have hosts with individual or special administrative needs, such as the
following:
Permanent lease
Assign permanent leases to designated hosts by specifying an infinite lease
time. Additionally, the DHCP server allocates a permanent lease to BOOTP
clients that explicitly request it, as long as support for BOOTP clients is
enabled. The DHCP server also allocates a permanent lease to DHCP hosts
that explicitly request it.
Specific IP address
Reserve a specific address and configuration parameters for a specific DHCP
(or BOOTP) client host on a particular subnet.
Specific configuration parameters
Allocate specific configuration information to a client regardless of its subnet.
Manually defined workstations
Explicitly exclude addresses from DHCP subnets for existing hosts that do not
use DHCP or BOOTP for configuring their IP network access.
DHCP servers and clients automatically check to see if an IP address is in use
before allocating or using it. However, they are unable to detect addresses of
Chapter 17. DHCP Server
407
manually defined hosts that are either turned off or temporarily off the network.
In that case, duplicate address problems might occur when a manually defined
host re-accesses the network and its IP address is not explicitly excluded.
What is a Reasonable Lease Time?
The default lease time is 24 hours. The lease time that you choose depends largely
on your needs, including the following:
v The number of hosts to support compared to the number of available addresses.
If you have more hosts than addresses, choose a short lease time of one to two
hours. This ensures that unused addresses are returned to the pool as soon as
possible. Keep in mind that the DHCP lease time affects your network operation
and performance.
– Shorter lease times increase the amount of network traffic due to DHCP lease
renewal requests. For example, if you set a lease time of 5 minutes, each
client sends a renewal request about every 2.5 minutes.
– Longer lease times limit your ability to reuse IP addresses. Extremely long
lease times also delay configuration changes that occur when a client restarts
or renews a lease.
v The time available to make network changes.
Hosts receive changes to configuration information when they are restarted or
when they renew their lease. Allow a timely and adequate window to make these
changes. For example, if you usually make changes overnight, you might assign
a lease time of 12 hours.
v The number of available DHCP servers.
If you have only a few DHCP servers for a large network, choose a longer lease
time to minimize the impact of server downtime.
Setting Up a DHCP Network
The IBM DHCP server provides configuration information to clients. This information
is based both on statements contained within the server’s configuration file and on
information provided by the client. The server’s configuration file defines the policy
for allocating IP addresses and other configuration parameters. The file is a map
that the server uses to determine what information to provide to the requesting
client.
Before you start the DHCP server, use Operations Navigator to create or change
the DHCP server configuration file. Figure 241 on page 409 represents the DHCP
Server Configuration window.
408
OS/400 TCP/IP Configuration and Reference V4R4
Figure 241. DHCP Server Configuration
Once the DHCP server is running, you can also make dynamic changes to the
configuration by using Operations Navigator to modify the configuration file and
re-initialize the DHCP server.
Creating a Scoped Network
Create a hierarchy of configuration parameters for a DHCP network. Specify some
configuration values to serve globally to all clients, and specify other configuration
values to serve only to certain clients. Serving different configuration information to
clients is often based on network location, equipment vendor, or user
characteristics.
Depending on your configuration, specify subnets, classes, vendors, and clients to
provide configuration information to different groups of clients, as follows:
v When defined globally, client, vendor, or class options are available to DHCP
clients regardless of their network location.
Parameters specified for a subnet, class, or client are considered local to the
subnet, class, or client. A client defined within a subnet inherits both the global
options and the options defined for that subnet. If a parameter is specified in
more than one level in the network hierarchy, the lowest level (which is the most
specific) is used.
v Use the subnet to specify configuration parameters for one subnet for a specific
location in your network or enterprise.
v Use the class to configure DHCP classes to provide unique configuration
information from the server to clients that identify themselves as belonging to that
class. For example, a group of clients can all use a shared printer.
v Use a vendor to provide unique configuration information to clients that identify
themselves as using a specific vendor’s equipment or software. Specially defined
options are served to these clients.
v Use a client in the DHCP server configuration file to serve specified options to a
specific client or to exclude that client from service. You can also use a client to
exclude IP addresses from service.
Chapter 17. DHCP Server
409
Defining Scoped Statements
The concept of scoped statements in a DHCP server configuration file is shown in
Figure 242.
Figure 242. DHCP Hierarchy
In this example, you see the following:
v Options A, B, and C are global. They are inherited by all clients in the network
unless overridden by a value for the same option at a lower level in the network.
v DHCP options that you define at a global level are overridden by options defined
in a globally defined client for that client only.
v DHCP options that you define at the subnet level override options defined at the
global level for clients falling in that subnet.
v Clients that you have not specifically defined automatically fall into a specific
location in the hierarchy based on their current network location.
v A client that requests a class must fall within a subnet in which the class is
defined, or you must globally define the class, before the client receives options
from the class.
v Options defined for a client override options in a class requested by the client,
provided the class is legal for that client.
v Vendor options are always defined globally so that every client that requests a
vendor is served the same options.
410
OS/400 TCP/IP Configuration and Reference V4R4
The following examples show requesting clients and the options and values that
they are served:
v Client K, if located on subnet Y and requesting class R, is served the following
options and values:
A
3
B
2
C
8
E
7
F 7
v Client K, if located on subnet X, is served the following options and values:
A
3
B
2
C
6
E 5
v Client J, if located in subnet X and requesting class P and vendor V, is served
the following options and values:
A
1
B
2
C
6
D
7
E
11
F
Not served
H
10
Vendor option A
6
Vendor option E
3
Vendor option G
4
v Client J, if located in subnet X and requesting class Q and vendor V, is served
the following options and values:
A
1
B
2
C
6
D
7
E
11
F
9
G
8
H
10
Vendor option A
6
Chapter 17. DHCP Server
411
Vendor option E
3
Vendor option G
4
v Client J, if located in subnet X and requesting class R, is served the following
options and values:
A
1
B
2
C
6
D
7
E
11
H
10
v Any client other than J or K that is not located in either subnet X or subnet Y is
not served any options or values.
v Any client other than J or K that is located in subnet X and requesting class Q
and Vendor V receives the following options or values:
A
B
C
E
F
G
Vendor option A
Vendor option E
Vendor option G
Specifying DHCP Options
DHCP allows you to specify options, also known as BOOTP vendor extensions, to
provide additional configuration information to the client. Internet Engineering Task
Force (IETF) Request for Comment (RFC) 2132 defines the options that you can
use.
Each option is identified by a numeric code. Examples of options that DHCP
servers pass to DHCP (and in many cases to BOOTP) clients are as follows:
1
Subnet Mask
3
Gateway/Router Address
6
Domain Name Server Addresses
12 Host Name
15 Domain Name
Note: You cannot find a list of all the possible DHCP options and their descriptions
in this document. Reference the actual IETF RFC documentation for a more
thorough explanation of how DHCP options work and for descriptions of the
412
OS/400 TCP/IP Configuration and Reference V4R4
actual DHCP option numbers themselves. See “Request for Comment and
Internet Draft Documents” for information on what IETF RFCs are and how
to view them yourself.
Architected DHCP Options
Architected options 0 though 127 and option 255 are reserved for definition by
RFCs. The DHCP server, the DHCP client, or both the server and client use options
in this set. The administrator can change most architected options, but some
options are reserved for the exclusive use of the client and server programs
themselves.
Examples of architected options that the administrator must not configure at the
DHCP server include the following:
52 Option overload
53 DHCP message type
54 Server identifier
55 Parameter request list
56 Message
57 Maximum DHCP message size
60 Class identifier
77 User class
User-defined DHCP Options
Options 128 through 254 represent user-defined options that administrators define
to pass information to the DHCP client to accomplish site-specific configuration
parameters.
The format of user-defined options is always a string of hexadecimal bytes, and the
server passes the specified value to the client. In order for it to be of any use,
however, the client must have some special, application-specific program or
command file to process the value.
Request for Comment and Internet Draft Documents
The Internet is governed by protocols that are defined in Internet Engineering Task
Force (IETF) Request for Comment (RFC) documents. RFCs outline existing
protocols, suggest new protocols, and establish standards for the Internet protocol
suite. Internet drafts are proposals, techniques, and mechanisms that document
IETF work in progress. Online copies of RFCs and Internet Drafts are available
from IETF.
To access RFCs or Internet Drafts, point your Web browser at the following URL,
which links to the Internet Documentation and IETF Information home page:
http://www.ietf.org
For a better understanding of DHCP, see the following RFC documents:
RFC 2131
Dynamic Host Configuration Protocol
Chapter 17. DHCP Server
413
RFC 2132
DHCP Options and BOOTP Vendor Extensions
RFC 951
Bootstrap Protocol
RFC 1542
Clarifications and Extensions to the Bootstrap Protocol
Internet Draft titled
The User Class Option for DHCP
Accessing DHCP Functions through Operations Navigator
You can access DHCP server functions from either a command line interface or
Operations Navigator. Not all DHCP functions are available on both interfaces.
However, most DHCP functions are available only through Operations Navigator.
This chapter discusses how you start, stop, and configure the DHCP server from
the command line interface. This chapter does not document any of the Operations
Navigator functions. See the online help for Operations Navigator for information
about using the Operations Navigator for DHCP functions.
To access DHCP server functions through Operations Navigator, perform the
following steps:
1.
2.
3.
4.
Double-click
Double-click
Double-click
Double-click
your AS/400 server in the main tree view of Operations Navigator.
Network.
Servers.
TCP/IP.
5. Double-click DHCP. Figure 243 represents the DHCP Server Configuration
window.
Figure 243. DHCP Server Configuration
The online help in Operations Navigator assists you with the following:
v Adding a new subnet to an existing DHCP configuration.
v Changing an existing subnet.
v Configuring a DHCP Relay Agent.
v Configuring DHCP to assign a permanent IP address.
414
OS/400 TCP/IP Configuration and Reference V4R4
v
v
v
v
v
Creating a new DHCP configuration.
Ending the DHCP server.
Getting authority to configure the DHCP server.
Making IP addresses available for IP address management.
Migrating BOOTP to a new DHCP configuration.
v
v
v
v
Migrating BOOTP to an existing DHCP configuration.
Setting options with DHCP configuration.
Starting the DHCP server.
Starting the DHCP server automatically when TCP/IP starts.
Note: Although some of the functionality of the command line interface and the
Operations Navigator is the same, the actual menu commands and
parameters are not necessarily the same.
Starting and Ending the DHCP Server from the Command Line
Interface
The instructions in this section apply only to the command line interface. For
information on starting and ending the DHCP server with Operations Navigator, see
the online help in Operations Navigator.
Starting the DHCP Server
To start the DHCP server, specify the Start TCP Server (STRTCP) command. This
command has no parameters, and it attempts to start all of the TCP/IP servers that
have been designated for autostart, as follows:
STRTCP
The DHCP server starts with this command if the AUTOSTART parameter in the
DHCP Server attributes is set to *YES.
Note: The AUTOSTART parameter is a part of the CHGDHCPA command.
You can use the STRTCPSVR command to start the DHCP server outside of the
full-TCP start. STRTCPSVR has a SERVER parameter where you can specify
which TCP servers you want to start, as follows:
STRTCPSVR SERVER(*DHCP)
STRTCPSVR also has the following RESTART parameter:
RESTART(*DHCP)
Automatically Starting the DHCP Server
The AUTOSTART parameter of the CHGDHCPA command affects the operation of
the STRTCP command. It does not have an effect on how the STRTCPSVR
command works if DHCP is explicitly requested with SERVER(*DHCP). However, it
does have an effect if STRTCPSVR SERVER (*ALL) is issued. If you run the
STRTCPSVR SERVER (*DHCP) command when the DHCP server is running, you
receive a diagnostic message. In this case, the STRTCPSVR command ignores the
AUTOSTART parameter value.
Chapter 17. DHCP Server
415
If you use the STRTCPSVR command to restart the DHCP server when the DHCP
server is not running, the server ignores the restart instruction and simply starts.
Notes:
1. If you have installed both DHCP and BOOTP servers, only one of the servers
can run. Therefore, an AUTOSTART parameter value of *YES is not allowed for
both BOOTP and DHCP. Because of this, STRTCP never attempts to start them
both.
2. Use the Change DHCP Attributes (CHGDHCPA) command to change the
startup attributes of the DHCP server. The changes take effect the next time you
start the DHCP server by either the Start TCP/IP (STRTCP) command or the
Start TCP/IP Server (STRTCPSVR) command. You must have *IOSYSCFG
special authority to use this command.
The AUTOSTART parameter specifies whether to start the DHCP server
automatically when TCP/IP is started by the STRTCP command. When the
DHCP server is started by the STRTCPSVR command, the DHCP server
ignores the AUTOSTART parameter and starts regardless of the value of this
parameter.
There is an exception. If the STRTCPSVR *ALL command is issued, all TCP/IP
servers that have been configured are started. However, a BOOTP and DHCP
server cannot both run on the same machine at the same time. If you issue the
STRTCPSVR *ALL command, the system first checks to see if both a BOOTP
and DHCP server job are configured. If both are configured, the system checks
the AUTOSTART attribute for each server.
If the AUTOSTART attribute for one of the servers is set to *YES and the other is
set to *NO, the system starts the server with the AUTOSTART attribute set to
*YES. If both the BOOTP and DHCP AUTOSTART attributes are set to *NO, the
DHCP server starts.
3. If you want the BOOTP server to function as the default, specify that change in
the Change BOOTP Attributes (CHGBPA) command, not in the DHCP
configurations.
Ending the DHCP Server
To end the DHCP server, specify the following End TCP/IP Server (ENDTCPSVR)
command with the server attribute set to *DHCP:
ENDTCPSVR SERVER(*DHCP)
Changing DHCP Attributes
The Change DHCP Attributes (CHGDHCPA) command changes the startup
attributes of the DHCP server. The change takes effect the next time you start the
DHCP server from either the Start TCP/IP (STRTCP) command or the Start TCP/IP
Server (STRTCPSVR) command.
Note: You must have *IOSYSCFG special authority to make changes to the DHCP
attributes with the CHGDHCPA command.
416
OS/400 TCP/IP Configuration and Reference V4R4
Exit Points for a DHCP Server
The DHCP processing server (not the BOOTP/Relay Agent) provides three exit
points. These exit points are as follows:
v QIBM_QTOD_DHCP_REQ - DHCP Request Packet Validation
v QIBM_QTOD_DHCP_ABND - DHCP Address Binding Notification
v QIBM_QTOD_DHCP_ARLS - DHCP Address Release Notification
See the System API Reference, SC41-5801-03 for a detailed description of these
exit points and how to use them.
Examples of DHCP Configurations
Configuring DHCP for a Local Area Network
Figure 244 illustrates a Local Area Network (LAN) with a server and two of the
network’s client machines. In a network using DHCP, the server automatically
assigns configuration information to each client that includes IP address information.
Using DHCP in even a simple LAN, such as the one in the illustration, saves
administrative time and trouble. The automatic configuration assignment is
transparent to the user.
Figure 244. LAN with Server and Two Clients
Address Range
In order for the server to automatically assign IP addresses, you must define an
address pool from which the server chooses the IP addresses. The starting address
for this example is 192.168.1.2, and the ending address is 192.168.1.4. Both the
starting address and the ending address fall within the range, and the server
considers them candidates for assignment to a client machine.
Configuring DHCP for a Local Area Network with a Router
Figure 245 on page 418 illustrates a LAN with a server, a router, and five of the
network’s client machines. In a network that uses DHCP, the server automatically
assigns configuration information that includes IP address information. The DHCP
Chapter 17. DHCP Server
417
server automatically assigns the network information to each client, which makes
the process transparent to the user.
Figure 245. LAN with Server, Router and Five Clients
Subnet Options
The example shows two subnets. The starting address for the address range for
one subnet is 192.168.1.1, and the ending address is 192.168.1.4. The starting
address for the address range in the second subnet is 10.1.1.1, and the ending
address is 10.1.1.3.
Using DHCP to Configure Clients Attached to a Twinax Workstation
Controller
Figure 246 on page 419 illustrates a twinaxial network with a server, three of the
network’s client machines, and a workstation controller. In a network that uses
DHCP, the server automatically assigns configuration information that includes IP
address information.
418
OS/400 TCP/IP Configuration and Reference V4R4
Figure 246. Twinax Network with Server, Three Clients and Workstation Controller
For more information on Twinax networks, see Network Station Manager Installation
and Use, SC41–0664–00.
Migrating an Existing BOOTP Configuration
Migrating to DHCP means that BOOTP client data on the server becomes available
to the DHCP server, and DHCP can then service those clients. BOOTP and DHCP
cannot operate at the same time on the same system. You can disable the BOOTP
server at any time.
Unless your system is new, it might have an existing BOOTP configuration. In this
instance, you can choose to migrate client data now and disable the BOOTP server
at a later time. Be aware, however, that a client data migration to DHCP represents
a point-in-time. This means that the client data as migrated to DHCP might not
necessarily match the client data as it is known by BOOTP at the time you disable
it. Consider migrating BOOTP client data and then turning off the BOOTP server at
a time when clients are not on the system.
In Operations Navigator, you can migrate a BOOTP configuration to DHCP by using
either the New DHCP Configuration wizard or the Migrate BOOTP dialog.
Whenever you use the New DHCP Configuration wizard to create a new
configuration, the wizard checks for an existing BOOTP configuration. If one is
detected, the wizard asks if you want to migrate the configuration to the DHCP
server configuration.
For instructions on migrating BOOTP to a new or existing DHCP configuration, see
the online help in Operations Navigator.
Chapter 17. DHCP Server
419
DHCP Relay Agent
The DHCP server functions as either a DHCP server or a BOOTP/DHCP Relay
Agent. If the server functions as a DHCP server, it processes DHCP packets on the
local system. If the DHCP server functions as a BOOTP/DHCP Relay Agent, it
relays DHCP and BOOTP packets on the local system but does not process them.
The Relay Agent forwards the packets to one or more different server IP addresses.
The BOOTP/DHCP Relay Agent handles both BOOTP and DHCP client requests
for IP addresses and forwards those requests to remote destination addresses.
The BOOTP/DHCP Relay Agent runs on the local subnet. The Relay Agent
intercepts client BOOTP or DHCP packet broadcasts. It then forwards them on to
the non-local DHCP server, which sends the response back to the Relay Agent. The
Relay Agent then forwards the response to the client on the local subnet. It uses
the port 67, the same port that the BOOTP or DHCP server uses.
Specify during configuration the IP addresses that the Relay Agent uses for
forwarding.
When the Relay Agent forwards a packet, it inserts its address into the packet so
the DHCP server can return a response to that Relay Agent.
For instructions on configuring a BOOTP/DHCP Relay Agent, see the online help in
Operations Navigator.
Adding Network Stations
To add Network Stations to your DHCP environment, run the Network Station Setup
Assistant. For more information on the Network Station Setup Assistant, see
Network Station Manager Installation and Use, SC41–0664–00.
420
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 18. AS/400 Domain Name System (DNS)
The Domain Name System (DNS) is an advanced system for managing the host
names that are associated with Internet Protocol (IP) addresses on TCP/IP
networks.
Material on DNS is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv.
On AS/400, DNS configuration is only available through AS/400 Operations
Navigator. Operations Navigator is a graphical user interface, and a part of Client
Access for Windows 95/NT.
For a list of recommended DNS publications, see “Additional DNS documentation”
on page 422.
How DNS works
|
|
|
|
Material on DNS is covered in the AS/400e Information Center under the TCP/IP
topic. For more information see “TCP/IP Topics in the Information Center” on
page xv. See “Additional DNS documentation” on page 422 for a list of DNS
publications that contain more detailed information.
|
|
|
|
|
|
The Domain Name System (DNS) was developed to eliminate the problems and
limitations of using host tables only to resolve host names on large TCP/IP
networks. DNS is the naming service of intranets and the Internet. Virtually all
TCP/IP software, including electronic mail, now uses DNS. Applications such as
Telnet, File Transfer Protocol (FTP), and HyperText Transfer Protocol (HTTP)
browsers use DNS as well.
What does DNS do?
The primary job of DNS is to translate TCP/IP host names to Internet Protocol (IP)
addresses. Host names are easy for people to remember, but IP addresses are
what TCP/IP uses to make connections between hosts across the network.
Name resolution and mapping
DNS translates or resolves host names to IP addresses. It can also resolve an IP
address to a host name. When DNS associates an IP address to a host name, the
IP address is said to be mapped to the host name.
What is DNS?
DNS is a system; not one thing, but many. It is a method of logically dividing
TCP/IP networks into manageable units that are called domains. It organizes these
units or domains into a hierarchy whose structure is similar to the roots of a tree. It
is a method for naming both the domains in the hierarchy and the hosts in the
domains, so that no two names are identical.
DNS is a distributed database
© Copyright IBM Corp. 1997, 1999
421
DNS is designed so that the host name and IP address information of a network
can be stored in many different locations around the network. This helps to
distribute the name resolution workload, and makes host name management easier.
Usually, only the host names and IP addresses of the hosts within a domain are
stored in that domain’s database. However, DNS servers have the ability to share
their domain information with other DNS servers.
DNS servers
DNS servers do most of the DNS work. It is their job to receive requests (called
queries) for network information, and return answers. If the answer to a query is
not in a DNS server’s domain, the DNS server has the ability to search out into the
DNS hierarchy.
DNS resolvers
If there is a server, there must be a client. In DNS, the client is called a resolver.
Sometimes DNS resolvers are built into each TCP/IP application. Sometimes a
central resolver does all of the client work for all of the TCP/IP applications on a
host. In either case, the resolver works invisibly and automatically each time a
TCP/IP application is used to communicate with another host.
Additional DNS documentation
You can find additional documentation for the Domain Name System in these
sources:
|
|
v DNS and BIND third edition by Paul Albitz and Cricket Liu. Published by O’Reilly
& Associates, Inc., 1998. ISBN number: 1-56592-512-2. This is the most
definitive source on DNS.
v AS/400 TCP/IP Autoconfiguration: DNS and DHCP Support. This is an IBM
Redbook, order number: SG24-5147. It is available on the World Wide Web at
the following site: http://www.redbooks.ibm.com/
v AS/400 Tips and Tools for Securing Your AS/400. This is an IBM White book,
order number: SC41-5300. It has important DNS security information. It is
available on the World Wide Web at the following URL:
http://as400bks.rochester.ibm.com/cgibin/bookmgr/bookmgr.cmd/DOCNUM/SC41-5300
v RFC 1034 Domain names concepts and functions.
v RFC 1035 Domain names implementations and specifications.
RFCs on the World Wide Web
RFCs are posted in many places on the Web. DNS-related RFCs are available at
the following address: http://www.dns.net/dnsrd/docs/rfc.html
422
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 19. Client SOCKS Support
AS/400 client SOCKS support enables programs that use (AF_INET
SOCK_STREAM) sockets to communicate with server programs that run on
systems outside a firewall. In addition, by using client SOCKS support, both AS/400
FTP and AS/400 TELNET client connections can be directed through a firewall. The
key advantage to AS/400 client SOCKS support is that it enables client applications
to access a SOCKS server transparently without changing any client code. AS/400
client SOCKS support operates with any SOCKS server that supports Version 4
SOCKS protocols.
For information on AS/400 client SOCKS support and SOCKS server concepts, see
the Sockets Programming, SC41-5422-03 book. For instructions on how to
configure your SOCKS server on the AS/400 firewall or for information on firewall
concepts, see the Getting Started with IBM Firewall for AS/400, SC41-5424-02 book
or go to http://www.as400.ibm.com/firewall.
Accessing SOCKS Functions through Operations Navigator
For information on how to configure an AS/400 host to use a SOCKS server, use
the AS/400 Operations Navigator. Define the client SOCKS configuration entries
that you need by using the SOCKS tab found under the Operations Navigator
function of Client Access/400 for Windows 95/NT. The SOCKS tab has substantial
help for configuring the client system for AS/400 client SOCKS support.
To access SOCKS server functions through Operations Navigator, perform the
following steps:
1. Double-click your AS/400 server in the main tree view of Operations Navigator.
2. Double-click Network.
3. Double-click Protocols.
4. Double-click TCP/IP.
5. Click the SOCKS tab.
For a complete description of the sockets APIs, see System API Reference,
SC41-5801-03.
© Copyright IBM Corp. 1997, 1999
423
424
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 20. TCP/IP Performance
The following are performance items that should be considered when using TCP/IP.
*BASE Pool Size
The TCP/IP protocol and application code always runs in the *BASE pool on the
AS/400 system. If the *BASE pool is not given enough storage, TCP/IP
performance, especially SMTP performance, can be adversely affected.
Although it is possible to run in less than 4000 KB of storage to perform well when
running both FTP and SMTP sessions, it is suggested that the *BASE pool be
configured to use at least 4000 KB of storage. You can use the WRKSYSSTS to
view and change pool sizes on the AS/400 system. Pool 2 is the base pool. Another
alternative is to change the pool in which the TCP/IP jobs run.
TCP/IP Jobs
TCP/IP jobs, like other jobs on your system, are created from job descriptions and
associated classes. The job descriptions and classes should be adequate in most
cases; however, they may be changed to fit your configuration. The TCP/IP job
descriptions, classes, and subsystem descriptions can be found in the QTCP or the
QSYS library that was loaded in your system when TCP/IP was installed.
Each application has a job description associated with it. This job description has a
number of items associated with it that define how the application runs on the
AS/400. One of these pieces of information is the routing entry compare value. This
value identifies which routing entry in a subsystem description is used when this job
is submitted. By changing that routing entry, you can select in which storage pool to
run the jobs for a particular application. For information on compare values, see
Work Management.
Other items that can be changed or selected on a job description include the job
priority, the logging level for messages, and the initial library list.
If the storage pool that you select to run the TCP/IP application jobs in is not large
enough, excessive paging can occur. This directly affects performance on the
AS/400 and the performance of the applications.
TCP/IP Protocol Support Provided by IOP
AS/400 TCP/IP protocol support runs down in the AS/400 System Licensed Internal
Code, at the same level as LU 6.2 and APPN*. One of the goals of integrating
TCP/IP into the AS/400 System Licensed Internal Code is to provide performance
and capacity comparable to APPC.
|
|
|
|
|
|
Further, moving some functions that are normally done by the TCP/IP software into
the IOP reduces interactions between the system and the input/output processor
(input-output processor (IOP)). These functions may include:
v Checksum calculation of outgoing TCP and UPD datagrams (prior to V4R4)
v Checksum verification of incoming TCP and UPD datagrams (prior to V4R4)
v Outbound batching of TCP and UDP datagrams.
© Copyright IBM Corp. 1997, 1999
425
|
|
|
|
|
|
|
|
|
|
v Fragmentation of TCP and UDP datagrams into segments that match the MTU
size.
v Starting with V4R2, AS/400 collects all TCP datagrams in one batch and UDP
datagrams in a second batch. Ports and IP addresses are ignored. Releases
prior to V4R2 batch together datagrams at the IOP when these conditions are
true:
– The protocol (TCP or UDP) matches
– The source and destination ports match
– The source IP address and destination IP address match
– They arrive consecutively into the IOP
|
|
|
|
The IOP then passes the datagram batch to IP.
v Handling of IP and ICMP datagrams in error (unless IP NAT, which disables this
function, is active)
v Resolving physical addresses using ARP protocol
|
|
|
|
|
|
|
These functions are called TCP/IP-assist functions. Whether these functions are
done by the IOP or the System Licensed Internal Code (SLIC), depends on the IOP
type, the OS/400 release, and the TCP/IP configuration. For details about specific
functions, contact your local service representative. TCP/IP-assist functions are
available on these IOPs:
v #2617 Ethernet/IEEE 802.3 adapter/HP
v #2619 16/4 Mbps Token-Ring Network adapter/HP
v #2618 Fiber distributed data interface adapter (FDDI)
|
|
v #2665 Shielded distributed data interface adapter (SDDI)
v #2666 High-speed communication adapter that is running frame relay only
|
|
v #2668 AS/400 wireless LAN adapter
|
|
|
Note: You can get the same function without using one of the above IOP adapters
(done instead at a higher level in the system (SLIC)). When you use the
X.25 protocol, you do not gain the advantage of the TCP/IP-assist function.
|
The TCP/IP-assist functions are also available on the following LAN IOAs and ATM
IOAs:
v #2723 PCI Ethernet IOA
v #2724 PCI Token-Ring IOA
v
v
v
v
v
v
v
#2838 PCI 100/10 Mbps Ethernet IOA
#6149 16/4 Mbps Token-Ring IOA
#2811 PCI 25 Mbps UTP ATM IOA
#2812 PCI 45 Mbps Coax T3/DS3 ATM IOA
#2813 PCI 155 Mbps MMF ATM IOA
#2814 PCI 100 Mbps MMF ATM IOA
#2815 PCI 155 Mbps UTP 0C3 ATM IOA
v #2816 PCI 155 Mbps MMF ATM IOA
v #2818 PCI 155 Mbps SMF 0C3 IOA
v #2819 PCI 34 Mbps Coax E3 ATM IOA
Note: If you configure your 100 Mbps ethernet line for TCPONLY, all IOP assist
functions are disabled.
|
|
426
OS/400 TCP/IP Configuration and Reference V4R4
|
TCP/IP-assist functions that are available on frame relay IOAs are:
v #2699 Two-Line WAN IOA
v #2720 PCI WAN/Twinaxial IOA
v #2721 PCI Two-Line WAN IOA
Communications restrictions apply if any of the following communication functions
are required when using the frame relay IOAs, as listed above:
v X.25, Frame Relay, or IPX Protocol
v SDLC protocol, if used to connect to more than 64 remote sites
v Communications line speeds greater than 64 Kbps and up to 2.048 Mbps for the
synchronous data link control (SDLC) or frame relay protocols (bisync is always
limited to a maximum of 64 Kbps)
v Communications line speeds greater than 64 Kbps and up to 640Kbps for X.25
Merge Host Table Performance
|
|
|
You can use the following data to help you plan for and anticipate performance
when merging host tables. The data represents averages of measurements that are
taken. The actual time required on your AS/400 system will be different.
Three cases were measured:
v Small merge—merge a 250-record file into the local host table that currently has
50 entries
v Medium merge—merge a 2000-record file into the local host table that currently
has 50 entries
v Large merge—merge a 5000-record file into the local host table that currently
has 50 entries.
The results of this test are shown in Table 37.
|
|
|
Table 37. Merge Host Table Performance
Number of records
merged
Record format
Elapsed time
(min:sec)
CPU percent
250
2000
5000
0:42
5:38
13:54
43.7
49.4
48.6
*AIX
*NIC
*NIC
This data equates to about 6 records per second and about .07-.08 processing unit
seconds per record.
Running TCP/IP Only: Performance Considerations
|
|
Certain configurations of 2838 - 10/100 Mbps Ethernet cards allow you to run the
IOP with only TCP/IP instead of all protocols for better performance. You need a
2838 Ethernet card with either:
v 2810 IOP
v 2809 IOP (the 2838 must be the only input/output adapter (IOA)IOA on the IOP)
|
|
|
If you have one of these configurations, you can use the TCPONLY parameter
when you create or change your Ethernet line descriptions. Setting TCPONLY to
*YES in other hardware configurations has no effect on the line.
|
|
|
Chapter 20. TCP/IP Performance
427
428
OS/400 TCP/IP Configuration and Reference V4R4
Chapter 21. TCP/IP Problem Analysis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This chapter is intended to be used for determining solutions to problems
encountered while using TCP/IP. This chapter contains:
v General information for determining problems regardless of what application you
are using. You are given the following information:
– A chart of potential problems.
– A cause list for each potential problem in the chart.
v Information for determining problems with PING, SLIP, TELNET, FTP, SMTP, the
POP server, the HTTP server, the workstation gateway server, LPR, and LPD.
The debugging information for sockets is available in Sockets Programming,
SC41-5422-03. The debugging information for the SNMP agent is available in
Simple Network Management Protocol (SNMP) Support, SC41-5412-00. For
TELNET, FTP, SMTP, the POP server, LPR, and LPD, you are given one or more
of the following:
|
The following steps should be followed when finding causes and solutions for
TCP/IP problems:
1. Follow the flow chart in Figure 247 on page 431 to verify the connectivity
between the local and remote systems.
– A chart of potential problems.
– A cause list for each potential problem in the chart.
– A description for tracing the TCP/IP application.
– A description of the materials required for reporting TCP/IP problems.
2. Once you verify connectivity, determine which section of this document to go to
based on what area the problem is occurring in. For example, if the problem is
in SMTP, go to the section “Determining Problems for SMTP” on page 457.
3. Read the section associated with the function where the problem is occurring.
4. Use the flow chart provided to isolate the problem, if possible.
5. Find the cause list for that potential problem.
6. Follow the cause list instructions for correcting the problem.
7. Obtain the debugging materials required for reporting the problem if none of the
actions in the cause list corrects the problem. This might include a trace of the
function when the problem occurs. Instructions for collecting a communications
trace are provided in “Collecting a Communications Trace” on page 493.
Note: All reported TCP/IP problems should include a copy of the configuration files
used for TCP/IP processing.
To obtain a copy of the TCP/IP configuration files do the following:
1. If you have not created the library IBMLIB or output queue IBMOUTQ, enter the
following commands:
CRTLIB LIB(IBMLIB)
CRTOUTQ OUTQ(IBMLIB/IBMOUTQ)
2. Enter the following commands to add the library IBMLIB to your library list and
to change the output queue for your job to output queue IBMOUTQ:
ADDLIBLE IBMLIB
CHGJOB * OUTQ(IBMLIB/IBMOUTQ)
© Copyright IBM Corp. 1997, 1999
429
Enter the following commands to obtain a list of all physical files used for
TCP/IP configuration:
WRKF FILE(QUSRSYS/QATOC*) FILEATR(PF)
WRKF FILE(QUSRSYS/QATM*) FILEATR(PF)
To copy the contents of each of the files, you can use option 3 (Copy from the
work with files) or you can enter the following command on the command line
for each listed file to copy the contents of each file to a separate spooled file in
the IBMOUTQ output queue.
CPYF FROMFILE(QUSRSYS/QATOCHOST) TOFILE(*PRINT)
FROMMBR(*ALL) TOMBR(*FROMMBR)
MBROPT(*ADD) CRTFILE(*NO) OUTFMT(*HEX)
General TCP/IP Problems
This section discusses information that you need to verify regardless of which
application you are using.
If you are unable to use your application, you should use the following flow chart to
identify the cause. The cause lists that follow identify potential problems.
430
OS/400 TCP/IP Configuration and Reference V4R4
Figure 247. Initial TCP/IP Problem Analysis
Cause List A
1. Verify TCP/IP has been activated on your system.
Chapter 21. TCP/IP Problem Analysis
431
Enter the STRTCP command to ensure that your TCP/IP stack is active. If it is
active, you should receive message TCP1A04, TCP/IP currently active. If
TCP/IP is not active, entering the STRTCP command will activate TCP/IP on your
AS/400. Verify that no errors occurred while starting TCP/IP on your AS/400.
2. Verify your AS/400 TCP/IP software.
On the AS/400 system, the host name LOOPBACK and the interface with a line
description value of *LOOPBACK, are reserved for verifying the AS/400 TCP/IP
software. If you specify the LOOPBACK host name, no data is sent out on any
of the physical lines. This allows you to quickly determine if TCP/IP software is
working correctly on your AS/400 system.
To verify your TCP/IP software:
a. Ensure the local host table has an entry for a LOOPBACK host name and
internet address of 127.0.0.1.
b. Ensure that the interface associated with the LOOPBACK host is active. The
internet address usually associated with the LOOPBACK interface is
127.0.0.1. Ensure that there is an interface with the LOOPBACK host
name’s IP address configured with a line description of *LOOPBACK. Use
the command:
NETSTAT OPTION(*IFC)
to view the LOOPBACK interface’s status. If it is not active, use option 9 to
activate it.
c. After verifying that the LOOPBACK host’s interface is active, type:
PING RMTSYS(LOOPBACK)
The loopback host allows the user to:
v Test FTP, TELNET, LPR or user-written application programs without
being attached to a physical line or network.
v Verify that the TCP/IP software is installed and operating correctly.
Note: A similar test can be performed by using the PING command to verify
connection with one of your other locally defined IP addresses.
d. To test the software and hardware (adapter and network connection), specify
the internet address of an external host on your network:
|
|
|
|
|
PING RMTSYS('nnn.nnn.nnn.nnn')
|
|
|
Depending on the line type of the local adapter, this command sends data
out to the local adapter and is received again by the adapter and then
responded to in the same way as the previous command.
|
|
Note: Ethernet does not send the data out on the Ethernet backbone if the
internet address is for the local adapter.
e. If you cannot successfully verify your system’s connection to the network by
specifying your system name or its internet address, check the source
service access point (SSAP) of the line description associated with the
interface. X'AA' must be specified as an entry in the SSAP (source service
access point) list. This occurs by default when a new line description is
created if the SSAP parameter is left at its default value of *SYSGEN. If you
have an existing line description, use the Change Line Description command
to add these values to the list.
|
432
OS/400 TCP/IP Configuration and Reference V4R4
Not all line description types must have a SSAP for TCP/IP so please check
the source service access point (SSAP) list in the line description associated
with the interface as described in Appendix A. Configuring a Physical Line
for TCP/IP Communication.
f. Verify all line description items, particularly the frame size which should be
greater than the maximum transmission unit (MTU) of the interface.
g. If a remote system fails to respond, it may mean that the system, network,
gateway, router, or bridge in the network is unavailable or not working.
Failure to respond can also mean that the remote system does not put into
effect the ICMP echo request protocol. Try verifying the connection to other
systems and between those other systems to determine where the failure is
most likely located.
h. Verify that the local interface configuration and the routing configuration,
described in “Step 2—Configuring a TCP/IP Interface” on page 30 and “Step
3—Configuring TCP/IP Routes” on page 32, is correct.
i. Ensure the following two routing entries are configured in the QSYSWRK
subsystem description if the TCP/IP interfaces, including LOOPBACK, do not
activate or you cannot end or start TCP/IP. If they do not exist, or if they are
not correct, then add or correct them and try the request again.
ADDRTGE
SBSD(QSYS/QSYSWRK) +
SEQNBR(2505) +
CMPVAL(TCPIP) +
PGM(QSYS/QTOCTCPI) +
CLS(QSYS/QSYSCLS20) +
MAXACT(*NOMAX) +
POOLID(1)
ADDRTGE
SBSD(QSYS/QSYSWRK) +
SEQNBR(2506) +
CMPVAL(TCPEND) +
PGM(QSYS/QTOCETCT) +
CLS(QSYS/QSYSCLS20) +
MAXACT(*NOMAX) +
POOLID(1)
Cause List B
If your VFYTCPCNN or PING commands were successful to the local system, you
should verify the possibility of connecting between your system and the other
system you want to communicate with. Run the PING command as you did
previously, but this time specify the internet address of the remote host. See
“Common Error Messages” on page 438.
1. If you can verify the connection using the remote internet address but not the
remote system name, then the name or address is not correct in your host
table, or the remote name servers may not be available.
2. If your system uses remote name servers, verify that you can reach each
remote name server by using the PING command and specifying the internet
address of the remote name server.
3. When a remote system appears not to respond, it is possible that the system
has responded but the packet was dropped due to a maximum frame size
limitation. For example, if a TCP/IP communications line on the AS/400 system
was configured with a maximum frame size of 576 bytes, an ICMP echo request
sent on that line might preclude receiving an echo reply if the reply exceeded
576 bytes. It may appear to the AS/400 user that the remote host was not
responding even though it had responded properly. Use the additional
parameters of the PING command to decrease the packet length of the PING.
Chapter 21. TCP/IP Problem Analysis
433
Almost all IP hosts assume that other IP hosts accept datagrams that are at
least 576 bytes long (see RFC 791 for more information on length of
datagrams). If any line used by AS/400 TCP/IP is configured to allow less than
576 bytes, any hosts that transmit to the AS/400 system using that line should
be configured to send datagrams that are less than or equal to 576 bytes;
otherwise, data may be lost.
4. There are additional parameters on the PING command that allow you to
specify the packet length, the number of packets to be sent, and the wait time
for a response. The default wait time of 1 second allows the remote system
enough time to respond in most networks. However, if the remote system is far
away or if the network is busy, increasing the wait time parameter can give a
successful result.
It is recommended that the parameter values be left at their default values. Be
aware that if you do change them, a combination of large packet length and
short wait time may not give the network enough time to transmit and receive
the response, and time-outs can occur. If the network is not given enough time
to transmit and receive the response, it can appear that you do not have
connectivity to a system when, in fact, you actually do.
5. If a remote system fails to respond, it may mean that the system, network,
gateway, router, or bridge in the network is unavailable or not working. Failure to
respond can also mean that the remote system does not put into effect the
ICMP echo request protocol. Try verifying the connection to other systems and
between those other systems to determine where the failure is most likely
located.
6. If a remote system fails to respond when you are using the PING command to
verify an interface, which is configured to a line description of Ethernet type,
make sure the correct Ethernet standard or *ALL is specified in the Ethernet line
description.
7. Failure to get responses from all systems in a network indicates the trouble is
somewhere along the path. Verify the connection to the gateway leading into the
network in question. If this fails, work back from the remote system you cannot
reach until you find the point of failure.
8. Packets are sent using a low-level protocol that does not guarantee delivery.
Because an echo request may be lost, do not assume that a network or
gateway has failed until several commands fail to get beyond a point in the
path.
Cause List C
1. Check the AS/400 QSYSWRK subsystem for all necessary jobs (local or
remote). There should be at least the QTCPIP job. It is a control job. There
should also be at least one job for each of the applications you are attempting
to use as shown in Figure 248 on page 435. It is possible that these jobs may
not be named identically to your subsystem jobs for the FTP, LPD, and TELNET
jobs. All FTP jobs begin with QTFTP. All LPD jobs begin with QTLPD. All TELNET
jobs will be named QTVTELNET and QTVDEVICE. It is possible to have more than
one FTP, LPD, or TELNET server jobs. All SMTP jobs begin with QTSMTP. SMTP
has up to four jobs active in the QSYSWRK subsystem and two jobs active in
the QSNADS subsystem. All SNMP jobs begin with QTMSNMP. SNMP can have
three jobs active in the QSYSWRK subsystem, QTMSNMP, QTMSNMPRCV,
and QSNMPSA.
Use the Work with Active Jobs (WRKACTJOB) command to display these jobs.
Type WRKACTJOB SBS(QSYSWRK).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
434
OS/400 TCP/IP Configuration and Reference V4R4
2. End TCP/IP processing using the ENDTCP OPTION(*IMMED) command if all the
jobs are not there. Look for all the job logs associated with the jobs.
3. Change the job description message logging level for all the job description
objects to 4 0 *SECLVL. See “Working with the Job Log and Message Queues”
on page 438 for detailed information on the message logging levels.
4. Start TCP/IP processing again using the STRTCP command
5. Verify that all jobs are active.
6. Check the job logs if the appropriate jobs are not active.
Work with Active Jobs
CPU %:
.8
Elapsed time:
Type options, press Enter.
2=Change
3=Hold
4=End
8=Work with spooled files
Opt
Subsystem/Job
QSYSWRK
QMSF
QNEOSOEM
QNEOSOEM
QNEOSOEM
QNPSERVD
QPASVRP
QPASVRS
QPASVRS
User
QSYS
QMSF
QUSER
QUSER
QUSER
QUSER
QSYS
QSYS
QSYS
Parameters or command
===>
F3=Exit
F5=Refresh
F11=Display elapsed data
SYSNAM03
02/03/99
02:21:32
18:06:32
Active jobs:
5=Work with
6=Release
13=Disconnect ...
Type
SBS
BCH
ASJ
BCH
BCH
BCH
BCH
BCH
BCH
F7=Find
F12=Cancel
CPU %
.0
.0
.0
.0
.0
.0
.0
.0
.0
93
7=Display message
Function
PGM-QNEOSOEM
PGM-QNEOSOEM
PGM-QNEOSOEM
PGM-QPASVRP
PGM-QPASVRS
PGM-QPASVRS
Status
DEQW
DEQW
TIMW
TIMW
TIMW
SELW
DEQW
TIMW
TIMW
More...
F10=Restart statistics
F23=More options
F24=More keys
Figure 248. Work with Active Jobs Display—Display 1
Chapter 21. TCP/IP Problem Analysis
435
CPU %:
.8
Work with Active Jobs
02/03/99
Elapsed time:
02:21:32
Type options, press Enter.
2=Change
3=Hold 4=End
8=Work with spooled files
Opt
Subsystem/Job
QTLPD03516
QTLPD03580
QTMSNMP
QTMSNMPRCV
QTVDEVICE
QTVTELNET
QZBSEVTM
QZHQSRVD
QZRCSRVSD
User
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
QUSER
QUSER
QUSER
Parameters or command
===>
F3=Exit
F5=Refresh
F11=Display elapsed data
SYSNAM03
18:06:32
Active jobs:
93
5=Work with
6=Release
13=Disconnect ...
Type
BCH
BCH
BCH
BCH
BCH
BCH
ASJ
BCH
BCH
F7=Find
F12=Cancel
CPU %
.0
.0
.0
.0
.0
.0
.0
.0
.0
7=Display message
Function
PGM-QTOSMAIN
PGM-QTOSRCVR
PGM-QTVDEVMG
PGM-QZBSEVTM
Status
DEQW
TIMW
DEQW
TIMW
TIMW
TIMW
EVTW
SELW
SELW
More...
F10=Restart statistics
F23=More options
F24=More keys
Figure 249. Work with Active Jobs Display—Display 2
Cause List D
The network status (NETSTAT) function on the AS/400 system allows you to view
the TCP/IP interface status, the TCP/IP route configuration information, and the
TCP/IP connection status on your local system. You can use either the
WRKTCPSTS command or the NETSTAT command.
1. Start TCP/IP using the STRTCP command before using the network status
function. The Work with TCP/IP Network Status menu is displayed but the
options are not functional until TCP/IP has been started.
On the Work with TCP/IP interface status display, if you attempt to start an
active interface or end an inactive interface, an appropriate error message is
sent. If an inactive interface does not reach the active state after taking the start
interface option, there may be a problem with the interface, the line, or the line
configuration. See the job log of the QTCPIP job in the QSYSWRK subsystem
to see what errors might have occurred when activating the interface. You can
also look in the QSYSOPR and the QHST message queues to help determine
the status.
Type WRKCFGSTS *LIN to determine if the line description has a problem. See
Appendix A. Configuring a Physical Line for TCP/IP Communication for
information on line descriptions.
2. Verify that at least one passive listening connection is shown for each of the
servers on the Work with TCP/IP Connection Status display, option 3 from the
Work with TCP/IP Network Status display.
SNMP
TELNET
Version 4 Release 4 supports SSL Telnet in addition to Telnet. SSL Telnet
reflects a listening port of 992 by default and traditional Telnet uses port 23.
Restricting Telnet listening ports is the recommended approach to disabling
the traditional Telnet server, while allowing the SSL Telnet to be enabled.
FTP
|
|
|
|
436
OS/400 TCP/IP Configuration and Reference V4R4
SMTP, if configured
POP
WSG
LPD
REXEC
HTTP
Passive listening connections have an asterisk in the Remote Address and
Remote Port fields. Ending these connections is not recommended. Remote
systems cannot use SNMP, FTP or TELNET, send SMTP mail to the local
system, or send spooled files using LPR to the local system if the associated
passive listening connections have been ended. They can be restarted by
ending and starting the servers using the ENDTCPSVR and STRTCPSVR commands
and then specifying the server you want ended and started.
3. Ensure that the ports associated with the application you are attempting to use
are not restricted. Use option 4 (Work with TCP/IP port restrictions) from the
Configure TCP/IP menu to view the current port restrictions.
Cause List E
Verify the configuration data. If everything checks out, go to the flow chart for the
particular application that you are using.
PING Command Considerations
The following sections discuss how the AS/400 system concatenates the domain
name to the host name and examples are given for some of the most common
PING error conditions.
Concatenating the Domain Name to the Host Name
This example illustrates how the AS/400 system concatenates the domain name to
the host name if a period is not used at the end of the domain name.
Your AS/400 system name is SYSNAM01.A400SSC.DFW.COMPANY.COM, and you
want to verify the connection to a system whose full name is
SYSNAM02.DFW.COMPANY.COM. Your remote name server is configured to return
the address for SYSNAM02.DFW.COMPANY.COM if you send the name server
either the full name (SYSNAM02.DFW.COMPANY.COM) or just the short name
(SYSNAM02). You do not have a SYSNAM02 host name in your local host table.
If you type:
PING SYSNAM02.DFW.COMPANY.COM
the AS/400 system sends SYSNAM02.DFW.COMPANY.COM to the remote name
server. If you type:
PING SYSNAM02
the remote name server reports that the host is unknown. The reason that the
remote name server does not recognize SYSNAM02 is because the AS/400 system
sends the SYSNAM02.A400SSC.DFW.COMPANY.COM name to the remote name
server for resolution. In other words, AS/400 TCP/IP concatenates the local domain
name to the host name.
Chapter 21. TCP/IP Problem Analysis
437
If you type:
PING SYSNAM02.
then just SYSNAM02 is sent to the remote name server, and the remote name
server resolves the name, similar to when the full host name and domain name are
specified. The only difference between this name and the previous name is the use
of the period at the end of the name.
Common Error Messages
When you use the PING command to verify the connection to another host in the
network, TCP/IP could give you an error message. The following are some of the
most common error conditions:
v No TCP/IP service available
TCP/IP has not been started yet or has not completed starting. All jobs may not
be started in the QSYSWRK subsystem.
Note: Use the NETSTAT command to see if TCP/IP is active. Use the Work with
Active Jobs (WRKACTJOB) command to verify that the QSYSWRK
subsystem and related jobs are active. If they are not active, look in the
job log or system default output queue for any messages.
v Not able to establish connection with remote host system
Check your configured interfaces, their related line descriptions and the TCP/IP
routes.
v Remote host did not respond to VFYTCPCNN within 10 seconds for connection
verification 1.
Your configuration is probably correct, but you do not get an answer back from
the remote system. Ensure that the remote host is able to reach your system.
Call the remote system operator and ask them to verify the connection to your
system.
Check the host tables or remote name server (if you are using a name server)
for both systems, and the TCP/IP interfaces and routes. The remote name server
may not be able to serve you for some reason.
If you are using an Ethernet line, make sure you specified the correct Ethernet
standard or *ALL.
v VFYTCPCNN: Unknown host, xxxxxx where xxxxxx is the host name.
Check the local host table or the remote name servers (if you are using a name
server) for the remote host’s entry.
Working with the Job Log and Message Queues
TCP/IP is shipped with several job descriptions.
|
The job descriptions are stored in the QSYS or QTCP library. They are shipped with
a message logging level of 4, a message logging severity of 0, and a message
logging text value of *NOLIST. They are shipped with these values to prevent job
logs from being created with only job started and job ended messages in them.
If you are having problems with the operation of TCP/IP, one of the first things to do
is to change the message logging level on the job description for the application
you are having problems with to a message logging text value of *SECLVL.
Changing the message logging level generates a job log for that application. You
|
|
|
|
438
OS/400 TCP/IP Configuration and Reference V4R4
|
|
|
must end then restart the server for the change to take effect. If you want to change
the job immediately, you must use the CHGJOB command to change the message
logging level of the active job.
For example, if the problem is with the FTP server, change the QTMFTPS job
description by typing the following CL command:
CHGJOBD
JOBD(QTCP/QTMFTPS)
LOG(4 0 *SECLVL)
If the problem is with SMTP, change the QTMSMTPS job description by typing the
following CL command:
CHGJOBD
JOBD(QTCP/QTMSMTPS)
LOG(4 0 *SECLVL)
In addition to the QTMSMTPS job description, you might consider changing the
logging level of the QSNADS subsystem job description:
CHGJOBD
JOBD(QGPL/QSNADS)
LOG(4 0 *SECLVL)
Determining Problems for SNMP
For information on debugging SNMP, see Simple Network Management Protocol
(SNMP) Support.
Determining Problems for Serial Line Internet Protocol (SLIP)
To debug SLIP problems, use the following:
v The SLIP session job log
v The SLIP connection script spooled file
v A communications trace of the ASC line.
When a SLIP problem occurs, it is important to determine at what stage of SLIP
processing the error occurred. The normal sequence of stages for establishing a
SLIP connection are:
1. Point-to-Point configuration profile validation
2. SLIP session job startup
a. Validation of ASC line values
b. Possible creation of device and controller descriptions
c. Varying on of the ASC line, controller and device
3. Modem reset and initialization (unless null modem)
4. Call establishment and modem synchronization
5. Connection script dialog
6. TCP/IP interface and route activation
7. TCP/IP SLIP processing begins.
When a problem occurs, the three sources of debugging information listed
previously should indicate at what point the connection failed, and why.
Problem: SLIP Connection Is Failing
If your SLIP connection is failing, there are several places to look for error
indications:
Chapter 21. TCP/IP Problem Analysis
439
1. Look in the job log of the user that issued the STRTCPPTP command for errors.
Errors found during point-to-point configuration profile validation will be logged in
this job log. Press F1 on the error message issued and follow the recovery
section.
2. Look in the SLIP session job log. Use the Work with Point-to-Point TCP/IP
(WRKTCPPTP) command to display a list of profiles. Find the point-to-point
profile, and select option 14. When you select option 14, the Work with Job
(WRKJOB) display is shown. If the job is still active, you can select option 10 to
display the current job log. If the job is no longer active, select option 4 to work
with spooled files for this job. Display the QPJOBLOG spooled file and look for
any error messages that have occurred. Refer to “Working With Point-to-Point
Jobs” on page 136 for more information on working with point-to-point jobs and
session job logs.
3. When the STRTCPPTP command is issued, the default for the OUTPUT
parameter is *ERROR. When OUTPUT is set to *ERROR, a script dialog is
printed if any errors occur during the modem initialization, call establishment,
modem synchronization or connection script dialog phases. This spooled file
contains information about any errors that have occurred during this process.
To see if a spooled file was created, use option 14 of the WRKTCPPTP
command for the point-to-point profile that failed to complete.
Select option 4 on the Work with Job display to show the Work with Job
Spooled Files display. On this display look for the spooled file with the USER
DATA field set to STRTCPPTP. Display the spooled file and look for any errors.
Examples of typical errors include:
v Rejected modem commands (examples are shown in Figure 250).
v Connection rejected by remote system due to incorrect userid or password
sent (examples are shown in Figure 251 on page 441).
v Mismatches in connection scripts with missing data or out of sequence data
(shown in Figure 252 on page 441). In Figure 252, the remote system
prompted for the password but the connection script on the local system was
not set up properly to look for this prompt. Therefore the remote system
timed out and closed the connection.
Refer to “Working With Point-to-Point Jobs” on page 136 for more information
on working with the connection script dialog spooled file.
1
2
3
4
5
6
7
8
9
10
Wed May 1 11:46:30 1996 ==> Attempting modem reset.
Wed May 1 11:46:30 1996 ==> AT&FS0=0
Wed May 1 11:46:30 1996 ==> Reading modem response.
Wed May 1 11:46:33 1996 ==> Reading modem response.
Wed May 1 11:46:33 1996 ==> AT&FS0=0 OK
Wed May 1 11:46:37 1996 ==> Attempting modem initialization.
Wed May 1 11:46:37 1996 ==> AT&D2&C1X4V1Q0S7=70W2\N3&K3&S1
Wed May 1 11:46:37 1996 ==> Reading modem response.
Wed May 1 11:46:40 1996 ==> Reading modem response.
Wed May 1 11:46:40 1996 ==> AT&D2&C1X4V1Q0S7=70W2\N3&K3&S1
ERROR
Figure 250. Rejected modem commands — Examples
440
OS/400 TCP/IP Configuration and Reference V4R4
16
17
18
19
20
21
22
23
Wed
Wed
Wed
Wed
Wed
Wed
Wed
Wed
May
May
May
May
May
May
May
May
1
1
1
1
1
1
1
1
13:37:48
13:37:48
13:37:51
13:37:51
13:37:56
13:37:56
13:38:00
13:38:01
1996
1996
1996
1996
1996
1996
1996
1996
==>
==>
==>
==>
==>
==>
==>
==>
CONNECT 19200 LAPM COMPRESSED
login:
sliptest8
password:
********
Access not authorized for user SLIPTEST8
Remote host connection ended.
Figure 251. Connection rejection — Examples
16
17
18
19
20
21
Wed
Wed
Wed
Wed
Wed
Wed
May
May
May
May
May
May
1
1
1
1
1
1
14:00:22
14:00:22
14:00:26
14:00:26
14:00:31
14:02:36
1996
1996
1996
1996
1996
1996
==>
==>
==>
==>
==>
==>
CONNECT 19200 LAPM COMPRESSED
login:
sliptest8
password:
Remote host connection ended.
Figure 252. Mismatches in Connection Scripts — Examples
4. If both of the following are true:
v A problem occurs with your communications to the modem, or with
communications to or from the remote system (including connection script
problems)
v The spooled file(s) for the point-to-point job does not contain enough
information to isolate the error
you may need to run a communications trace on the ASC line while attempting
the SLIP connection. When printing the trace data, be sure to specify *CALC for
the format of the data you are printing to allow the system to format both
EBCDIC and ASCII data properly. The communications trace could contain data
to help isolate the error that is occurring.
If you are not familiar with the procedure for collecting a communications trace,
refer to “Collecting a Communications Trace” on page 493 and “Formatting and
Saving the Communications Trace” on page 499.
5. If you are trying to connect to an Internet Service Provider (ISP) but are unable
to complete the connection, verify that no errors occurred up to the point the call
is made to the ISP. You can verify this through the Connection Dialog script
spooled output. You should see an entry for ‘Attempting modem dial/answer’
followed by an ‘ATDT’ (tone) or ‘ATDP’ (pulse) entry that contains the number
you are dialing.
If no errors occurred up to point when you dial your ISP, you may need to
contact your ISP to verify the following:
v If you do not receive a ‘CONNECT’ indication after the call is made, verify
that the telephone number you are using for the ISP is correct.
v If you need to dial another number to get to an outside line prior to dialing the
ISP, make sure that you use enough comma (“,”) special characters to allow
enough time for the outside line to become available. For example:
‘9,,,,7771234’ can be defined for the Remote service phone number in the
‘Remote system access information’ section of your point-to-point
configuration profile, where “9” is the number required to get an outside line.
The time delay for each comma is defined by your modem.
Chapter 21. TCP/IP Problem Analysis
441
v If your user ID or password information is being rejected, verify that the
correct user ID and password are configured in your point-to-point
configuration profile and that this information is correct for your ISP account.
v Verify that the connection script you are using matches what the ISP is
expecting. The connection dialog script spooled file output and a
communications trace of the failed connection attempt may help with this
verification.
Problem: SLIP Job ’Hung’ with STRSSN Status
If you start a point-to-point profile and the status on the WRKTCPPTP display for
the profile appears to be hung at a STRSSN status, this could be an indication that
an inquiry message has been sent to the system operator (QSYSOPR message
queue) and the job is waiting for a reply. Go to a command line and enter the
following command:
DSPMSG MSGQ(QSYSOPR)
Look for inquiry messages involving the ASC line in use. If you find messages, look
for information on the problem that is occurring. Typical problems include:
v The modem is powered off
v The modem cable is not connected properly.
Before continuing, either answer the inquiry message or end the SLIP session by
issuing the ENDTCPPTP command. After ending the session, correct the problem
and try to start the session again.
Problem: SLIP Connection Complete but Unable to PING
If you cannot PING REMOTE IP address:
v Try setting the WAITTIME parameter on the PING command to a value greater
than the one second default.
Dial-up connections are much slower than direct connections through LANs and
some other types of connections. The default wait time for the PING command is
one second, which may be too short a time period for the PING to complete over
the dial-up line.
If you cannot PING LOCAL IP address:
v If you can PING the remote IP address (showing connectivity to the remote
system) but cannot PING the LOCAL IP address, then it is unlikely that there is a
problem. It depends on how the remote system is configured. If the remote
system is capable of forwarding IP datagrams and has its routing set up correctly
to send the IP datagrams back to your local address, the PING should work. But,
if the remote system cannot forward IP datagrams or its routing is not set up to
send the IP datagrams back to your local address, the PING request will not
work. This is because of the way PING works on point-to-point links.
v Refer to “Allow IP Datagram Forwarding” on page 145 for more information on
why the remote system must forward IP datagrams to be able to PING your local
IP address.
Materials Required for Reporting SLIP Problems
Include the following with any SLIP problem reported to IBM:
1. The type of remote host, operating system, and operating system level.
442
OS/400 TCP/IP Configuration and Reference V4R4
2.
3.
4.
5.
6.
The failing point-to-point session job log.
The type and model of the modem used and the modem strings selected.
A copy of the options used in the failing point-to-point profile.
A copy of the parameter values used in the line description.
The connection dialog script being used (if one is being used)
7. The connection dialog script spooled file output (if it exists)
8. A copy of any QSYSOPR messages that may have been logged concerning the
SLIP connection
9. A communications trace of the failing SLIP connection (if possible).
Determining Problems with TELNET
If a problem is detected when using the AS/400 TELNET server, use the following
flow chart to identify the cause after using the flow chart for general TCP/IP
problems. (Figure 247 on page 431). The cause lists that follow identify potential
problems.
Figure 253. TELNET Server Problem Analysis
Cause List A
|
|
|
|
|
|
1. Verify that the Telnet server jobs are active and that Telnet service is assigned
to a valid non-restricted port. Use the WRKACTJOB command to verify that
QTVTELNET and QTVDEVICE jobs are active in QSYSWRK subsystem. If
these jobs are not active, use the STRTCPSVR *TELNET command to start
these jobs. Use NETSTAT *CNN to verify that Telnet service is assigned to a
valid port.
2. Verify that the QAUTOVRT system value on the AS/400 server system is
properly set to allow the TELNET server to automatically create virtual devices.
For example, to allow the creation of 50 virtual devices enter the command:
Chapter 21. TCP/IP Problem Analysis
443
CHGSYSVAL SYSVAL(QAUTOVRT) VALUE(50)
Note: Since Version 4 Release 2, QAUTOVRT supports numeric values of 0
through 32500, and a special value of *NOMAX.
3. Verify that the network connection between the AS/400 server and the Telnet
client is active by using an application such as PING(VFYTCPCNN). If not
active, see your network administrator.
4. Verify that the virtual devices on the AS/400 server system that are used by
TELNET are defined to a subsystem under which the interactive TELNET jobs
should run. Use the Display Subsystem Description (DSPSBSD) command to
see which work station entries are defined to a subsystem. Use the Add Work
Station Entry (ADDWSE) command to define work stations to a subsystem.
For example, you could use the following command to allow all work station
types to run under the QINTER subsystem:
|
|
|
|
|
ADDWSE SBSD(QINTER) WRKSTNTYPE(*ALL)
5. Verify that the interactive subsystem (QINTER) is Active. TELNET connections
fail if the interactive subsystem is not active. In this situation, the system does
not write error messages to the QTVTELNET job log to show you the problem.
Use the DSPSBSD SBSD (subsystem name) command to verify that the
subsystem is active. Messages are not written to either QTVTELNET or
QTVDEVICE job log.
6. Verify that your local VTxxx client is configured to automatically wrap lines at
column 80 if you are operating in VTxxx full-screen mode.
|
|
|
|
|
|
7. Check for a TELNET user exit program registered to exit point
QIBM_QTG_DEVINIT format INIT0100, using the WRKREGINF CL command.
If there is a registered user exit program, check the TELNET server job log for
any errors related to that program. If errors exist, correct the errors in the exit
program or remove the exit program with the RMVEXITPGM CL command.
8. Ensure that your client is attempting to use the correct port to connect to
Telnet. Use CFGTCP or NETSTAT *CNN to determine what port Telnet service
is assigned to.
9. Use the CFGTCP command to verify that the port your client is attempting to
connect on is not restricted. Also look in the QTVTELNET job log for
messages indicating that the port that you are trying to use is restricted.
10. If you are attempting to connect using SSL Telnet, then in addition to the
above items, ensure that the Digital Certificate Manager (DCM), and one of the
IBM Cryptographic Provider products, are installed. Also, ensure that a valid,
non-expired certificate is assigned to the Telnet server
(QIBM_QTV_TELNET_SERVER).
|
|
|
|
|
|
|
|
|
|
|
Cause List B
1. Verify your authority to the virtual display device. If you receive message
CPF1110 when attempting to sign on the AS/400 system, you are not authorized
to the virtual display device. When the AS/400 TELNET server creates virtual
devices, the QCRTAUT system value is used to determine the authority granted
to user *PUBLIC. This system value should be *CHANGE to allow any user to sign
on using TELNET.
2. Verify that the QLMTSECOFR system value is correctly set if you are the
security officer or have *SECOFR authority.
Cause List C
1. Verify your word processing choice. If you experience problems when using
OfficeVision or the Work with Folders (WRKFLR) command, you may need to
444
OS/400 TCP/IP Configuration and Reference V4R4
change your configuration so that the Office Adapted Editor is used instead of
the Standard Editor. To do this, have your system administrator change your
word processing choice in your Environment Information associated with your
office user ID.
2. Verify that your local VTxxx client is configured to automatically wrap lines at
column 80 if you are operating in VTxxx full-screen mode.
3. If characters are not displayed properly for your VTxxx session, verify that the
correct mapping tables are in use for your session.
4. If your VTxxx client beeps every time you press a key, your keyboard may be
locked. See “Error Conditions on 5250 Keyboard” on page 207 for more
information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5. Check the QTVTELNET job log and the QTVDEVICE job log for error messages
on the AS/400 server system.
Materials Needed when Reporting TELNET Problems
Problems reported to IBM may include one or more of the following as determined
by your service representative:
v Telnet Server job logs:
– QTVTELNET job log(s)
– QTVDEVICE job log(s)
v Some details on the problem scenario. For example:
– The type of remote host you were using to Telnet from or to, such as AS/400,
S/390, or RS6000. This is particularly useful if you are doing cascaded Telnet
scenarios.
– The type of client attempting to connect to the Telnet server, such as IBM
Personal Communications, and AS/400 Client Access.
– Job log of interactive job running Telnet client (when Telnet client is under
investigation).
– TRCJOB of the failing interactive job (especially important if running Telnet
client).
|
|
|
|
|
|
|
|
|
|
|
Note: Use TRCJOB *ON to start this trace. The result will be a QPSRVTRC
spool file in the interactive job.
– A communications trace of the failure, which contains TCP/IP data only, and is
formatted for both ASCII and EBCDIC. If you are not familiar with the
procedure for collecting a communications trace, refer to “Collecting a
Communications Trace” on page 493 and “Formatting and Saving the
Communications Trace” on page 499. You may be directed by your service
representative to include broadcast messages in this trace. In addition, you
may need to filter this trace on a specific IP address if you have a large
amount of traffic on your network, and know the IP address of the failing
client.
|
|
|
|
|
|
|
|
– Any VLIC logs with major code 0700 and minor code 005x from the time of
failure. In addition, there may be some major code 0701 and minor code 005x
informational VLIC logs that may be useful but not necessarily critical.
– A Virtual Terminal Manager (VTM) VLIC component trace. This trace can be
gathered via the TRCTCPAPP command or via STRSST. For full details on
using the TRCTCPAPP command, see the OS/400 CL Reference located in
the AS/400 Online Library at the following URL address:
http://www.as400.ibm.com/infocenter.
Chapter 21. TCP/IP Problem Analysis
445
|
|
|
|
|
|
|
|
|
|
|
It is important to note that running the VTM VLIC trace will have performance
impacts. Some examples of using this command are:
- To trace all VTM activity:
|
|
|
|
Note: Specific details of which trace parameters to use for your problem
should be received from your service representative prior to running
this command. This will ensure that the correct information is
gathered for your problem.
TRCTCPAPP APP(*TELNET) SET(*ON)
- To trace the activity on a specific device, when you know the device name:
TRCTCPAPP APP(*TELNET) SET(*ON) DEVD(devicename)
- To trace the activity on a specific device, when you know the IP address of
the client:
TRCTCPAPP APP(*TELNET) SET(*ON)
RMTNETADR(*INET'www.xxx.yyy.zzz')
- To turn the trace off and spool output:
TRCTCPAPP APP(*TELNET) SET(*OFF)
|
TRCTCPAPP Service Program Outputs
|
|
|
|
|
For TRCTCPAPP, the listing of the VTM component trace will show up as a spooled
file called, VTMTRACE, with the user data field set to TELNET. This will be placed into
the default output queue of the profile executing the TRCTCPAPP *TELNET *OFF
call. At the same time, all server job flight recorders - rs - will be dumped to
spooled files called QTOCTTRC with user data set to QTVnnnnnn.
|
|
Here is an example of what you can expect to see in your interactive job log when
you perform a TRCTCPAPP *OFF call:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Command Entry
All previous commands and messages:
> trctcpapp *telnet *off
Spooled printer file 1 opened for
Trace data for application TELNET
Trace data for application TELNET
Trace data for application TELNET
Trace data for application TELNET
Trace data for application TELNET
Trace data for application TELNET
Trace data for application TELNET
output.
formatted:
formatted:
formatted:
formatted:
formatted:
formatted:
formatted:
SYSNAM03
Request level: 1
Spooled
Spooled
Spooled
Spooled
Spooled
Spooled
Spooled
VTMTRACE
QTOCTTRC
QTOCTTRC
QTOCTTRC
QTOCTTRC
QTOCTTRC
QTOCTTRC
user data 'TELNET'.
user data 'TV017231'.
user data 'TV017230'.
user data 'TV017229'.
user data 'TV017232'.
user data 'TV017233'.
user data 'TV017234'.
More...
Type command, press Enter.
===> __________________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve F10=Exclude detailed messages
F11=Display full
F12=Cancel
F13=Information Assistant F24=More keys
Here is an example of what you can expect to see in your default output queue:
|
|
446
OS/400 TCP/IP Configuration and Reference V4R4
Work with All Spooled Files
Type options, press Enter.
1=Send
2=Change
3=Hold
4=Delete
5=Display
8=Attributes
9=Work with printing status
Opt
File
VTMTRACE
QTOCTTRC
QTOCTTRC
QTOCTTRC
QTOCTTRC
QTOCTTRC
User
JEFF
JEFF
JEFF
JEFF
JEFF
JEFF
Device or
Queue
JEFFSOUTQ
JEFFSOUTQ
JEFFSOUTQ
JEFFSOUTQ
JEFFSOUTQ
JEFFSOUTQ
User Data
TELNET
TV017231
TV017231
TV017231
TV017231
TV017231
6=Release
Sts
HLD
HLD
HLD
HLD
HLD
HLD
Total
Pages
46
4
2
2
2
2
7=Messages
Cur
Page
Copy
1
1
1
1
1
1
Bottom
Parameters for options 1, 2, 3 or command
===> __________________________________________________________________________
F3=Exit
F10=View 4
F11=View 2
F12=Cancel
F22=Printers
F24=More keys
|
|
There is only one file called VTMTRACE that will be created. There can be one or
more QTOCTTRC files, if SSL Telnet mode is operational on the server.
|
|
|
Here is an example of one of the QTOCTTRC files. This spooled file is a Telnet
server job (QTVTELNET) as opposed to a QTVDEVICE job:
Chapter 21. TCP/IP Problem Analysis
447
Display Spooled File
File . . . . . :
TV017231
Page/Line
1/6
Control . . . . .
Columns
1 - 78
Find . . . . . .
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
5769TC1 V4R4M0 990521 TRCTCPAPP Output SysName Date-12/11/98 Time-14:08:32 PageTRCTCPAPP Attributes
Application.................: Telnet Server
Buffer size (KB)............: 0
(Default of 0 means 16MB buffer)
Trace full action...........: *WRAP
Job id......................: 017231/QTCP
/QTVTELNET
Start date/time.............: Fri Dec 11 13:50:33 1998
End date/time...............: Fri Dec 11 14:08:34 1998
Trace buffer wrapped........: No
Telnet Server Attributes
AutoStart server............: 'Y'
Number servers..............: 2
Session keep alive timeout..: 0
Default NVT type............: >*VT100<
Outgoing EBCDIC/ASCII table.: >*CCSID
<
Incoming ASCII/EBCDIC table.: >*CCSID
<
Coded character set id......: 84542
Attributes version id.......: >V4R4M0
<
Trace_common buffer structure:
80000000 00000000 161A8753 14001074 |..........g.....| Byte 16
80000000 00000000 161A8753 14FFFFE4 |..........g....U| Byte 48
80000000 00000000 161A8753 14005820 |..........g.....| Byte 80
00FFF000 00000084 F0F1F7F2 F3F1D8E3 |..0....d017231QT| Byte 112
C3D74040 40404040 D8E3E5E3 C5D3D5C5 |CP
QTVTELNE| Byte 144
E340C699 8940C485 8340F1F1 40F1F37A |T Fri Dec 11 13:| Byte 176
F5F07AF3 F340F1F9 F9F8D8E3 E5F0F1F7 |50:33 1998QTV017| Byte 208
F2F3F140
|231
| Byte 228
Flight Records:
qtvtelnet: Job: QTVTELNET/QTCP/017231
(C) Copyright IBM Corporation, 1999
Licensed Material - Program Property of IBM.
Refer to Copyright Instructions Form No. G120-2083
ProdId: 5769-SS1 Rel: V4R4M0 Vers: V4R4M0 PTR: P3684767
qtvtelnet: Program QTVTELNET dated 04 December 1998 running
qtvtelnet: Source file: qtvtelnet.plC
qtvtelnet: Last modified: Wed Dec 9 11:57:40 1998
qtvtelnet: Last compiled at 12:00:10 on Dec 9 1998
qtvtelnet: Arguments passed: 1
qtvtelnet: Time Started: Fri Dec 11 13:50:34 1998
qtvtelnet: sigaction() for SIGUSR1 is EndClientSession()
qtvtelnet: Set Telnet Server job identity for OpNav
qtvtelnet: Need to setup SSL_Init_Application()
qtvtelnet: SSL_Init_Application() successful
qtvtelnet: Find Telnet Server control block
qtvtelnet: Lock Telnet Server control block
qtvtelnet: Open driver to stream
qtvtelnet: First Telnet Server Job...
More...
F3=Exit
F12=Cancel
F19=Left
F20=Right
F24=More keys
Here is an example of another QTOCTTRC file. This is a device manager spooled
file, as opposed to the QTVTELNET server job:
|
|
|
448
OS/400 TCP/IP Configuration and Reference V4R4
Display Spooled File
File . . . . . :
TV017230
Page/Line
1/6
Control . . . . .
Columns
1 - 78
Find . . . . . .
*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+...
TRCTCPAPP Attributes
Application.................: Telnet Server
Buffer size (KB)............: 0
(Default of 0 means 16MB buffer)
Trace full action...........: *WRAP
Job id......................: 017230/QTCP
/QTVDEVICE
Start date/time.............: Fri Dec 11 13:50:33 1998
End date/time...............: Fri Dec 11 14:08:39 1998
Trace buffer wrapped........: No
Telnet Server Attributes
AutoStart server............: 'Y'
Number servers..............: 2
Session keep alive timeout..: 0
Default NVT type............: >*VT100<
Outgoing EBCDIC/ASCII table.: >*CCSID
<
5769TC1 V4R4M0 990521 TRCTCPAPP Output SysName Date-12/11/98 Time-14:08:32 Page*...+....1....+....2....+....3....+....4....+....5....+....6....+....7...
Incoming ASCII/EBCDIC table.: >*CCSID
<
Coded character set id......: 84542
Attributes version id.......: >V4R4M0
<
Trace_common buffer structure:
80000000 00000000 3DA86C25 5F001074 |.........y...| Byte 16
80000000 00000000 3DA86C25 5FFFFFE4 |.........y..U| Byte 48
80000000 00000000 3DA86C25 5F002F64 |.........y...| Byte 80
00FFF000 00000084 F0F1F7F2 F3F0D8E3 |..0....d017230QT| Byte 112
C3D74040 40404040 D8E3E5C4 C5E5C9C3 |CP
QTVDEVIC| Byte 144
C540C699 8940C485 8340F1F1 40F1F37A |E Fri Dec 11 13:| Byte 176
F5F07AF3 F340F1F9 F9F8D8E3 E5F0F1F7 |50:33 1998QTV017| Byte 208
F2F3F040
|230
| Byte 228
Flight Records:
qtvtncsh: >>>>> entry
(C) Copyright IBM Corporation, 1999.
Licensed Material - Program Property of IBM.
Refer to Copyright Instructions Form No. G120-2083
ProdId: 5769-SS1 Release: V4R4M0 Version: V4R4M0 PTR: P3684767
qtvtncsh: Program QTVTNCSH dated 04 December 1998 running
qtvtncsh: iActiveLogLevel: 0
qtvtncsh: Source file: qtvtncsh.c
qtvtncsh: Last modified: Wed Dec 9 11:48:33 1998
qtvtncsh: Last compiled at 11:59:42 on Dec 9 1998
qtvtncsh: SignalHandler() registered with signal()
qtvtncsh: Arguments passed: 4
qtvtncsh: argc: 4
qtvtncsh: argv[0]: >QSYS/QTVTNCSH<
qtvtncsh: argv[1]: ><
qtvtncsh: argv[2]: >1p<
qtvtncsh: argv[3]: >s<
SignalHandler: >>>>> entry
SignalHandler: Caught signal SIGSEGV
F3=Exit
F12=Cancel
F19=Left
F20=Right
F24=More keys
More...
|
Automatically Generated Diagnostic Information (FFDC Errors)
|
|
|
|
When certain errors occur within the Telnet server, some automatically generated
diagnostic information is also generated. There will be times when your service
representative will require this diagnostic information to properly analyze a Telnet
server problem.
|
|
|
|
If any Telnet or device manager job fails with an FFDC error, you will see the
spooled files under the WRKSPLF QTCP profile. When a job fails with an FFDC
error, each failing job will automatically have two dumps. One is a dump made by
calling DSPJOB *PRINT, and the other is made by DSPJOBLOG *PRINT. This way,
Chapter 21. TCP/IP Problem Analysis
449
|
|
|
you get both the job log and job run attributes dumped and have the user data
group output together with a job number identifier. This will let you match up with
any VTM Component Trace output.
|
|
|
|
You will see a total of four spooled files; two for the QTVTELNET job and two for
the QTVDEVICE job. These spooled files are automatically generated when an
FFDC error is encountered. For an example, see Figure 254:
Work with All Spooled Files
Type options, press Enter.
1=Send
2=Change
3=Hold
4=Delete
5=Display
8=Attributes
9=Work with printing status
Opt
File
QPJOBLOG
QPDSPJOB
QPJOBLOG
QPDSPJOB
QPJOBLOG
QPJOBLOG
QPDSPJOB
QPDSPJOB
User
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
QTCP
Device or
Queue
QEZJOBLOG
QPRINT
QEZJOBLOG
QPRINT
QEZJOBLOG
QEZJOBLOG
QPRINT
QPRINT
User Data
TV016868
TV016868
TV016955
TV016955
TV017231
TV017232
TV017232
TV017231
Parameters for options 1, 2, 3 or command
===>
F3=Exit
F10=View 4
F11=View 2
F12=Cancel
6=Release
Sts
HLD
HLD
HLD
HLD
HLD
HLD
HLD
HLD
7=Messages
Total
Pages
4
7
3
7
3
3
7
7
F22=Printers
Cur
Page
Copy
1
1
1
1
1
1
1
1
Bottom
F24=More keys
Figure 254. Work with All Spooled Files Display
|
Determining Problems with FTP
If you detect a problem when using FTP, use the following flow chart to identify the
cause after using the flow chart for general TCP/IP problems. (Figure 247 on
page 431). The cause lists that follow list steps to help you identify the cause of the
problem.
|
|
|
|
450
OS/400 TCP/IP Configuration and Reference V4R4
Figure 255. FTP Problem Analysis
Cause List A
|
|
|
|
|
|
|
|
|
|
|
1. Is there is a long delay between connecting to the AS/400 FTP server and
receiving a prompt for a user id? If so, check the configuration of the domain
name server on your AS/400. The FTP server performs a DNS query as soon
as a new connection is received. DNS problems may cause the server to hang
for several minutes before a response is received.
2. Check to see if an exit program has been added to the FTP Server Logon Exit
Point. If yes, then check if the logon that is unsuccessful is allowed by the exit
program.
3. Check to see if the remote logon requires a password if a password was
requested. Some systems request a password, but the connection can fail
because it is not required.
4. Set up a password on the remote system if required. You may have to IPL if you
change the security information on the system.
5. Check your user ID and password by attempting to sign on to your remote
system. If you are unable to do so, contact the system owner to verify that your
user ID and password are correct.
Cause List B
1. Make sure binary mode is in effect if you are transferring binary files.
|
|
2. Check to be sure the mapping tables on both the client and server systems are
compatible. You need only do this if you are using your own mapping tables.
3. Check to see that the correct CCSID has been specified for the transfer. If not,
use the TYPE or LTYPE subcommand to set the correct CCSID value before
the transfer is performed.
Chapter 21. TCP/IP Problem Analysis
451
4. Create a file on the system that you are planning to store data into. Set the
proper record length, number of members, and number of increments. Try the
data transfer again and verify that it was successful.
5. Make sure that you are authorized to use the file and the file members.
6. Check to see if the transfer file contains packed decimal or soned decimal data.
If yes, then make sure that the transfer is done as described in ″Transferring
Files that Contain Packed Decimal Data″.
7. If you are transferring a Save file, verify that the appropriate method was used
as described in ″Transferring Save Files″.
|
|
|
|
|
Cause List C
1. Check file size limits on the remote system.
2. Check to see if the FTP server timer ended. The AS/400 server time-out value
can be set using the QUOTE TIME command.
3. Use the NETSTAT command to verify that the *LOOPBACK interface is active.
Then re-create the problem doing FTP LOOPBACK (AS/400-to-AS/400
internally).
v If the problem cannot be recreated, it is probably a remote system problem.
v If you can re-create the problem, do the following:
a. If the problem is an FTP server problem, then start the FTP server trace
using the TRCTCPAPP command.
b. Create the problem again.
c. End the FTP connection.
|
|
|
|
|
|
d. End the FTP server trace using the TRCTCPAPP command.
e. Find a spooled file with a file name of QTMFFTRC and the user name set
to the name of the user issuing the TRCTCPAPP command which
stopped and formatted the trace. The trace is a spooled file in the default
output queue of the system associated with the FTP server job.
f. Send in that spooled file.
|
|
|
|
|
|
|
|
g. If the problem was on the AS/400 FTP client, a trace can be obtained
using the DEBUG 100 client subcommand.
h. When running the FTP client interactively, use the F6 (Print) key to create
a spool file that contains a history of the FTP client subcommands
entered, and the associated FTP server replies. When the FTP client is
run in batch unattended mode, then this history of subcommands and
server replies is written to the specified OUTPUT file. For more details,
see ″FTP as Batch Job″.
|
Materials Required for Reporting FTP Problems
Any FTP problem reported to IBM should include the following:
v A communications trace from the time of the failure (Request TCP/IP data only)
formatted twice: once for ASCII and once for EBCDIC. If you are not familiar with
the procedure for collecting a communications trace, refer to “Collecting a
Communications Trace” on page 493 and “Formatting and Saving the
Communications Trace” on page 499.
v If the FTP client or server has logged software error data, submit the data.
|
Note: The system value QSFWERRLOG must be set to *LOG for software error
logging to take place. If an error occurs while QSFWERRLOG is set to
*NOLOG, change the value to *LOG, try to re-create the error, and submit
|
|
|
452
OS/400 TCP/IP Configuration and Reference V4R4
|
|
|
|
|
|
|
|
|
v
v
v
v
the logged software error data. If logged software error data is submitted,
there is no need to perform a trace of FTP.
The QTCPIP and any FTP server or FTP client job logs.
The FTP client and FTP server debug traces.
For FTP client problems, a spool file containing the FTP client session (which
may be obtained by hitting the print (F6) key in the FTP session).
If data integrity is the problem, then the file, member, or library causing the
problem should be sent in along with a copy of the description of the file,
member, or library.
Tracing FTP Se