z/VM: TCP/IP User's Guide - z/VM - IBM

z/VM 

 

TCP/IP Level 430 

User’s Guide 

Version4Release3.0 

SC24-6020-01


 



Version4Release3.0 

SC24-6020-01

Note: 

Before using this information and the product it supports, read the information under “Notices” on page 347. 

| 

| 

| 

| 

Second Edition (May 2002) 

This edition applies to Version 4, Release 3, Modification 0 of IBM ® z/VM, (product number 5739-A03) and to all 

subsequent releases and modifications until otherwise indicated in new editions. 

This edition replaces SC24-6020–00. 

© Copyright International Business Machines Corporation 1987, 2002. All rights reserved. 

US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract 

with IBM Corp.

Contents 

| 

| 

| 

Preface . . . . . . . . . . . . . . vii 

Who Should Read This Book . . . . . . . . vii 

What You Should Know before Reading This Book vii 

What This Book Contains . . . . . . . . . vii 

How to Use This Book . . . . . . . . . . . ix 

How the Term “internet” Is Used in This Book. . ix 

Where to Find More Information . . . . . . . ix 

PDF Links to Other Books . . . . . . . . ix 

Understanding Syntax Diagrams. . . . . . . . x 

How Numbers Are Used in This Book . . . . . xii 

How to Send Your Comments to IBM . . . . . xii 

Summary of Changes . . . . . . . . xiii 

Second Edition for z/VM Version 4 (May 2002) . . xiii 

PASV FTP client support . . . . . . . . xiii 

TCP/IP Stack Vulnerability Reduction . . . . xiii 

First Edition for z/VM Version 4 (October 2001) xiii 

TCP/IP Stack Performance and Reliability 

Improvements . . . . . . . . . . . . xiii 

IMAP Support . . . . . . . . . . . . xiv 

First Edition for z/VM Version 3 (February 2001) xiv 

FTP Web Browser Support . . . . . . . . xiv 

VM Network File System (NFS) Client . . . . xiv 

IP Multicasting . . . . . . . . . . . . xiv 

Secure Socket Layer (SSL) Support . . . . . xiv 

Chapter 1. Introducing Computer 

Networks and Protocols . . . . . . . . 1 

Computer Networks . . . . . . . . . . . . 1 

Internet Environment . . . . . . . . . . . 1 

TCP/IP Protocols and Functions . . . . . . . . 3 

Link Protocols . . . . . . . . . . . . . 4 

Network Protocols . . . . . . . . . . . 4 

Transport Protocols . . . . . . . . . . . 6 

Applications and Protocols . . . . . . . . 6 

Routing. . . . . . . . . . . . . . . . 10 

Internet Addressing. . . . . . . . . . . . 11 

Network Address Format . . . . . . . . . 11 

Broadcast Address Format . . . . . . . . 12 

Multicast Address Format . . . . . . . . 13 

Subnetwork Address Format . . . . . . . 13 

Chapter 2. Transferring Files Using FTP 15 

FTP Command . . . . . . . . . . . . . 16 

The NETRC DATA File . . . . . . . . . . 19 

The FTP DATA File . . . . . . . . . . . . 19 

Statement Syntax . . . . . . . . . . . 19 

FTP DATA File Statements . . . . . . . . . 19 

CCONNTIME Statement . . . . . . . . . 20 

DATACTTIME Statement . . . . . . . . . 21 

DCONNTIME Statement . . . . . . . . . 22 

INACTTIME Statement . . . . . . . . . 23 

LOADDBCSTABLE Statement . . . . . . . 24 

MYOPENTIME Statement . . . . . . . . 25 

FTP Subcommands . . . . . . . . . . . . 26 

Continuing Subcommand Input Strings . . . . 29 

File Name Formats . . . . . . . . . . . 30 

Fully-Qualified Pathnames . . . . . . . . 33 

Storage Space Requirements for Transferred Files 33 

File Transfer Methods . . . . . . . . . . 34 

File List Formats. . . . . . . . . . . . 35 

Transferring Files Using a Web Browser . . . . 39 

ACCT . . . . . . . . . . . . . . . . 40 

APPEND . . . . . . . . . . . . . . . 41 

ASCII . . . . . . . . . . . . . . . . 41 

BINARY . . . . . . . . . . . . . . . 42 

CD or CWD . . . . . . . . . . . . . . 42 

CDUP . . . . . . . . . . . . . . . . 46 

CLOSE . . . . . . . . . . . . . . . . 46 

CMS. . . . . . . . . . . . . . . . . 46 

DEBUG. . . . . . . . . . . . . . . . 47 

DELETE . . . . . . . . . . . . . . . 47 

DELIMIT . . . . . . . . . . . . . . . 47 

DIR . . . . . . . . . . . . . . . . . 48 

EBCDIC . . . . . . . . . . . . . . . 49 

EUCKANJI . . . . . . . . . . . . . . 50 

GET . . . . . . . . . . . . . . . . . 50 

HANGEUL . . . . . . . . . . . . . . 51 

HELP . . . . . . . . . . . . . . . . 51 

IBMKANJI. . . . . . . . . . . . . . . 52 

JIS78KJ . . . . . . . . . . . . . . . . 52 

JIS83KJ . . . . . . . . . . . . . . . . 53 

KSC5601 . . . . . . . . . . . . . . . 53 

LCD. . . . . . . . . . . . . . . . . 53 

LOCSITE . . . . . . . . . . . . . . . 54 

LOCSTAT . . . . . . . . . . . . . . . 54 

LPWD . . . . . . . . . . . . . . . . 55 

LS . . . . . . . . . . . . . . . . . 55 

MDELETE . . . . . . . . . . . . . . . 57 

MGET . . . . . . . . . . . . . . . . 58 

MKDIR . . . . . . . . . . . . . . . . 58 

MODE . . . . . . . . . . . . . . . . 59 

MPUT . . . . . . . . . . . . . . . . 59 

NETRC . . . . . . . . . . . . . . . . 60 

NOOP . . . . . . . . . . . . . . . . 60 

OPEN . . . . . . . . . . . . . . . . 61 

PASS . . . . . . . . . . . . . . . . 62 

PASSIVE . . . . . . . . . . . . . . . 62 

PUT . . . . . . . . . . . . . . . . . 63 

PWD . . . . . . . . . . . . . . . . 64 

QUIT . . . . . . . . . . . . . . . . 65 

QUOTE. . . . . . . . . . . . . . . . 65 

RENAME . . . . . . . . . . . . . . . 65 

RMDIR . . . . . . . . . . . . . . . . 66 

SENDPORT . . . . . . . . . . . . . . 67 

SENDSITE. . . . . . . . . . . . . . . 67 

SITE . . . . . . . . . . . . . . . . . 68 

SIZE. . . . . . . . . . . . . . . . . 70 

SJISKANJI . . . . . . . . . . . . . . . 70 

STATUS . . . . . . . . . . . . . . . 71 

STRUCT . . . . . . . . . . . . . . . 71 

© Copyright IBM Corp. 1987, 2002 iii

SUNIQUE . . . . . . . . . . . . . . . 71 

SYSTEM . . . . . . . . . . . . . . . 73 

TCHINESE . . . . . . . . . . . . . . 73 

TYPE . . . . . . . . . . . . . . . . 74 

USER . . . . . . . . . . . . . . . . 75 

Using FTP Within an EXEC . . . . . . . . . 75 

Providing FTP Subcommand Input . . . . . 76 

Managing FTP Command Output . . . . . . 76 

Examples . . . . . . . . . . . . . . 76 

FTP Return Codes . . . . . . . . . . . . 78 

Examples . . . . . . . . . . . . . . 80 

FTP Reply Codes . . . . . . . . . . . . 80 

Internal Error Codes . . . . . . . . . . . 82 

Using FTP with RACF ® . . . . . . . . . . 83 

Chapter 3. Transferring Files Using 

TFTP . . . . . . . . . . . . . . . 85 

TFTP Command . . . . . . . . . . . . . 85 

Creating Translation Tables . . . . . . . . . 86 

TFTP Subcommands . . . . . . . . . . . 86 

GET . . . . . . . . . . . . . . . . 86 

HELP . . . . . . . . . . . . . . . 86 

LOCSTAT . . . . . . . . . . . . . . 87 

MAXPKT . . . . . . . . . . . . . . 87 

MODE . . . . . . . . . . . . . . . 88 

OPEN . . . . . . . . . . . . . . . 88 

PUT . . . . . . . . . . . . . . . . 89 

QUIT . . . . . . . . . . . . . . . 89 

REXMIT . . . . . . . . . . . . . . 89 

TRACE . . . . . . . . . . . . . . . 90 

Chapter 4. Sending and Receiving 

Electronic Mail . . . . . . . . . . . 91 

NOTE and SENDFILE Commands. . . . . . . 91 

Electronic Mail Gateway . . . . . . . . . . 91 

Note and File Delivery . . . . . . . . . 92 

SMTPQUEU . . . . . . . . . . . . . 92 

Undelivered Notes . . . . . . . . . . . 92 

Nondelivery Note . . . . . . . . . . . 92 

Unknown Recipient Note. . . . . . . . . 93 

Using OfficeVision Without OfficeVision Extended 

Mail Installed. . . . . . . . . . . . . . 94 

Specifying TCP/IP Recipients . . . . . . . 94 

Example of Sending a Note Copy to SMTP . . . 95 

Note Delivery . . . . . . . . . . . . 95 

Using IMAP to Access Electronic Mail . . . . . 95 

Using the SMSG Interface to SMTP . . . . . . 96 

SMSG Commands . . . . . . . . . . . . 96 

Receiving Electronic Mail on VM . . . . . . . 97 

Chapter 5. Logging On to a Foreign 

Host . . . . . . . . . . . . . . . 101 

TELNET Command . . . . . . . . . . . 101 

TELNET Function Keys . . . . . . . . . . 102 

In Transparent (TN3270) Mode . . . . . . 102 

In Line Mode . . . . . . . . . . . . 102 

TELNET Subcommands . . . . . . . . . . 103 

AO. . . . . . . . . . . . . . . . 103 

AYT . . . . . . . . . . . . . . . 103 

BRK . . . . . . . . . . . . . . . 103 

HELP . . . . . . . . . . . . . . . 104 

IP . . . . . . . . . . . . . . . . 104 

PA1 . . . . . . . . . . . . . . . 104 

QUIT . . . . . . . . . . . . . . . 104 

SYNCH . . . . . . . . . . . . . . 105 

Sending ASCII Control Characters to a Host in 

Line Mode . . . . . . . . . . . . . 105 

Chapter 6. Monitoring the TCP/IP 

Network. . . . . . . . . . . . . . 107 

NETSTAT—Displaying Local Host Information . . 107 

NETSTAT Command Address Interpretation . . 107 

RPCINFO Command . . . . . . . . . . 128 

PING Command . . . . . . . . . . . 129 

TRACERTE Command . . . . . . . . . 130 

Chapter 7. Authenticating Network 

Users with Kerberos . . . . . . . . 133 

Understanding Kerberos Name Structures . . . . 133 

Kerberos Commands . . . . . . . . . . . 133 

KINIT Command . . . . . . . . . . . . 134 

KLIST Command . . . . . . . . . . . . 135 

KDESTROY Command . . . . . . . . . . 136 

KPASSWD Command . . . . . . . . . . 136 

Chapter 8. Using the Network File 

System Commands . . . . . . . . . 139 

VM’s NFS Server Support . . . . . . . . . 139 

NFS Client Commands . . . . . . . . . . 140 

MOUNT Command . . . . . . . . . . . 140 

MOUNTPW Command . . . . . . . . . . 150 

UMOUNT Command . . . . . . . . . . 151 

Diagnosing Mount Problems . . . . . . . . 152 

Errors Using Mounted Systems . . . . . . . 153 

Notes for BFS Files and Directories . . . . . . 155 

Notes for SFS Files and Directories . . . . . . 156 

Notes for Minidisk Files . . . . . . . . . . 158 

SMSG Interface to VMNFS . . . . . . . . . 160 

Name Translation File . . . . . . . . . . 165 

Special File Names for VM NFS . . . . . . 165 

Special File Name Considerations . . . . . 165 

NFS Client Problems . . . . . . . . . . . 166 

Deleting CMS Record-Length Fields . . . . . . 166 

Using NFS with RACF . . . . . . . . . . 166 

VM NFS Server Link Support . . . . . . . . 167 

SFS and Minidisk Links . . . . . . . . . 167 

BFS Links . . . . . . . . . . . . . 167 

Chapter 9. Using the Remote 

Execution Protocol . . . . . . . . . 169 

REXEC Command. . . . . . . . . . . . 169 

The NETRC DATA File . . . . . . . . . . 170 

Anonymous Remote Command Execution. . . . 171 

Command Execution Using Your Own Virtual 

Machine . . . . . . . . . . . . . . 171 

Notes and Restrictions . . . . . . . . . 172 

Using RSH commands with REXECD . . . . . 172 

Chapter 10. Using Remote Printing 175 

iv 

z/VM: TCP/IP User’s Guide

LPRSET Command . . . . . . . . . . . 175 

LPR Command . . . . . . . . . . . . . 178 

Controlling LPSERVE from other Systems . . . . 190 

LPQ Command. . . . . . . . . . . . . 191 

LPRM Command . . . . . . . . . . . . 193 

Chapter 11. Using GDDMXD/VM with 

the X Window System. . . . . . . . 195 

Overview of GDDMXD/VM . . . . . . . . 195 

GDDM Application Limitations . . . . . . 195 

GDDM Display Limitations . . . . . . . 195 

z/VM Considerations . . . . . . . . . 196 

Using GDDMXD/VM . . . . . . . . . . 196 

Configuring the GDDMXD/VM Environment . . 197 

Identifying the Target Display . . . . . . . . 197 

User-Specified Options . . . . . . . . . . 198 

Resizing the GDDMXD Graphics Window. . . 198 

Geometry . . . . . . . . . . . . . 199 

GColornn. . . . . . . . . . . . . . 199 

GMCPnn . . . . . . . . . . . . . . 200 

ZWL . . . . . . . . . . . . . . . 201 

XSync . . . . . . . . . . . . . . . 201 

CMap . . . . . . . . . . . . . . . 202 

HostRast . . . . . . . . . . . . . . 202 

XClConn . . . . . . . . . . . . . . 203 

Compr . . . . . . . . . . . . . . 204 

PDTrace . . . . . . . . . . . . . . 204 

ANFontn . . . . . . . . . . . . . . 204 

Remapping the Enter and Newline Keys . . . 205 

Enter . . . . . . . . . . . . . . . 205 

Newline . . . . . . . . . . . . . . 206 

GDDMXD/VM Keyboard Functions. . . . . . 206 

GDDMXD/VM to X Window System Keyboard 

Functions. . . . . . . . . . . . . . . 206 

APL2 Character Set Keyboard . . . . . . . . 207 

Setting Up GDXAPLCS MAP . . . . . . . . 207 

Collecting Problem Determination Information . . 208 

GDDMXD/VM—X Window System Server 

Environment . . . . . . . . . . . . 208 

Obtaining the GDDM Trace . . . . . . . 208 

Obtaining the GDDMXD Problem 

Determination Trace . . . . . . . . . . 208 

GDDMXD/VM Problem Determination Examples 209 

Demonstration Programs . . . . . . . . . 209 

GXDEMO1 . . . . . . . . . . . . . 209 

GXDEMO2 . . . . . . . . . . . . . 210 

GXDEMO3 . . . . . . . . . . . . . 210 

GXDEMO4 . . . . . . . . . . . . . 210 

GXDEMO4A . . . . . . . . . . . . 210 

GXDEMO5 . . . . . . . . . . . . . 210 

GXDEMO6 . . . . . . . . . . . . . 210 

Chapter 12. Managing TCP/IP Network 

Resources with SNMP . . . . . . . 213 

Sample Command Lists . . . . . . . . . . 213 

SNMP/NetView Overview . . . . . . . . . 214 

SNMP Commands. . . . . . . . . . . . 215 

SNMP Commands Overview . . . . . . . 215 

Return Codes . . . . . . . . . . . . 215 

SNMP GET Command . . . . . . . . . . 216 

SNMP GETNEXT Command . . . . . . . . 218 

SNMP SET Command . . . . . . . . . . 220 

SNMP TRAPSON Command . . . . . . . . 222 

SNMP TRAPSOFF Command . . . . . . . . 224 

SNMP MIBVNAME Command . . . . . . . 225 

SNMP PING Command . . . . . . . . . . 226 

Major and Minor Error Codes and SNMP Value 

Types . . . . . . . . . . . . . . . . 227 

gethostbyname() . . . . . . . . . . . 228 

IBM 3172 Enterprise-Specific MIB Variables . . . 228 

Chapter 13. Using the Network 

Database System (NDB) . . . . . . . 231 

The Client Machine . . . . . . . . . . . 232 

Components of the Client Machine . . . . . 232 

The Server Machine . . . . . . . . . . . 233 

Components of the Portmap Manager Server 233 

Components of the NDB Server . . . . . . 234 

Connecting to a Database . . . . . . . . 235 

NDBCLNT Command . . . . . . . . . 236 

Format of Output Displayed on the Client. . . 238 

SQL Commands from a Remote Machine . . . 238 

SQL Commands from an Application . . . . 239 

Security . . . . . . . . . . . . . . 240 

Limitations . . . . . . . . . . . . . 240 

Additional information on the NDB Client code 241 

Chapter 14. Using the Domain Name 

System . . . . . . . . . . . . . . 243 

Overview of the Domain Name System . . . . 243 

Domain Names. . . . . . . . . . . . 243 

Domain Name Servers . . . . . . . . . 244 

Resolvers . . . . . . . . . . . . . . 245 

Resource Records . . . . . . . . . . . 246 

NSLOOKUP—Querying Name Servers . . . . . 249 

NSLOOKUP Internal State Information . . . . 249 

NSLOOKUP Command . . . . . . . . . . 249 

NSLOOKUP Options (SET Subcommand) . . . . 254 

NSLOOKUP Examples . . . . . . . . . . 256 

DIG—Querying Name Servers. . . . . . . . 259 

DIG Internal State Information . . . . . . 259 

DIG Command . . . . . . . . . . . . . 260 

CMSRESOL—Resolver and Name Server . . . . 270 

RESOLV Command—Interface to the CMSRESOL 

MODULE . . . . . . . . . . . . . . 270 

CMSRESOL Command—Interface to the Resolver 271 

Types of Queries . . . . . . . . . . . . 272 

The Standard Query . . . . . . . . . . 272 

The Inverse Query . . . . . . . . . . 273 

Querying the in-addr.arpa Domain . . . . . 273 

The Database Query and Update . . . . . . 273 

Querying Outside Your Domain . . . . . . 274 

Chapter 15. Using Translation Tables 277 

Character Sets and Code Pages . . . . . . . 277 

TCP/IP Translation Table Files . . . . . . . 278 

Translation Table Search Order . . . . . . . 278 

Special Telnet Requirements . . . . . . . 279 

IBM-Supplied Translation Tables . . . . . . . 280 

Customizing SBCS Translation Tables . . . . . 282 

Contents 

v

Syntax Rules for SBCS Translation Tables . . . 283 

Customizing DBCS Translation Tables . . . . . 283 

DBCS Translation Table . . . . . . . . . 283 

Syntax Rules for DBCS Translation Tables . . . 284 

Sample DBCS Translation Tables . . . . . . 284 

Converting Translation Tables to Binary . . . . 286 

The CONVXLAT Command . . . . . . . 286 

Appendix A. Specifying Files and Data 

Sets . . . . . . . . . . . . . . . 289 

AIX Files . . . . . . . . . . . . . . . 289 

OS/390 Data Sets . . . . . . . . . . . . 290 

Sequential Data Sets . . . . . . . . . . 290 

Partitioned Data Sets . . . . . . . . . . 290 

DOS, OS/2, and Windows 98 Files . . . . . . 291 

AS/400 Operating System . . . . . . . . . 292 

Appendix B. Using the NETRC DATA 

File . . . . . . . . . . . . . . . . 293 

Using The NETRC DATA File with FTP . . . . 293 

Using The NETRC DATA File with REXEC . . . 293 

Using the NETRC DATA File with the OPEN 

MOUNT CMS Command . . . . . . . . . 294 

Appendix C. Mapping Values for the 

APL2 Character Set. . . . . . . . . 295 

Appendix D. Using DBCS with FTP 

and Mail . . . . . . . . . . . . . 301 

Using DBCS with FTP . . . . . . . . . . 301 

DBCS Translation Tables. . . . . . . . . 301 

DBCS Subcommands . . . . . . . . . . 301 

Defining FTP with Kanji Support . . . . . . 304 

Using FTP with Kanji Support. . . . . . . 304 

Using DBCS with Mail . . . . . . . . . . 305 

SMTP Server DBCS Support . . . . . . . 305 

SMTP Protocol for 8-bit characters . . . . . 305 

Conversion of DBCS Mail . . . . . . . . 305 

Conversion of DBCS Files . . . . . . . . 306 

Appendix E. Management Information 

Base Objects . . . . . . . . . . . 307 

Structure and Identification of Management 

Information (SMI) . . . . . . . . . . . . 307 

Names . . . . . . . . . . . . . . 308 

The Management Subtree . . . . . . . . 308 

MIB/Network Elements . . . . . . . . . . 310 

System Group . . . . . . . . . . . . . 311 

Interfaces Group . . . . . . . . . . . . 312 

Address Translation Group . . . . . . . . . 316 

IP Group . . . . . . . . . . . . . . . 317 

IP Address Translation Table . . . . . . . . 322 

ICMP Group . . . . . . . . . . . . . 323 

TCP Group . . . . . . . . . . . . . . 324 

UDP Group . . . . . . . . . . . . . . 327 

IBM 3172 Enterprise-Specific MIB Variables . . . 327 

ibm3172SystemTable . . . . . . . . . . 327 

ibm3172ifTrapTable . . . . . . . . . . 328 

ibm3172ifChanCounters Table . . . . . . . 329 

ibm3172ifLANCounters Table . . . . . . . 330 

ibm3172ifBlkCounters Table . . . . . . . 331 

ibm3172ifDblkCounters Table . . . . . . . 332 

ibm3172ifDeviceTable. . . . . . . . . . 333 

Appendix F. IBM 3172 Attribute Index 335 

Appendix G. SNMP Generic TRAP 

Types . . . . . . . . . . . . . . . 337 

Appendix H. Related Protocol 

Specifications . . . . . . . . . . . 339 

Appendix I. Abbreviations and 

Acronyms . . . . . . . . . . . . . 343 

Notices . . . . . . . . . . . . . . 347 

Trademarks . . . . . . . . . . . . . . 349 

Glossary . . . . . . . . . . . . . 351 

Bibliography. . . . . . . . . . . . 369 

z/VM Internet Library . . . . . . . . . . 369 

VM Collection CD-ROM. . . . . . . . . . 369 

z/VM Base Publications . . . . . . . . . . 369 

Evaluation . . . . . . . . . . . . . 369 

Installation and Service . . . . . . . . . 369 

Planning and Administration . . . . . . . 369 

Customization . . . . . . . . . . . . 369 

Operation . . . . . . . . . . . . . 369 

Application Programming . . . . . . . . 369 

End Use . . . . . . . . . . . . . . 370 

Diagnosis. . . . . . . . . . . . . . 370 

Publications for z/VM Additional Facilities . . . 370 

DFSMS/VM ® . . . . . . . . . . . . 370 

Language Environment ® . . . . . . . . 370 

OSA/SF . . . . . . . . . . . . . . 370 

TCP/IP for z/VM . . . . . . . . . . . 371 

Publications for z/VM Optional Features . . . . 371 

DirMaint . . . . . . . . . . . . . 371 

PRF . . . . . . . . . . . . . . . 371 

RTM . . . . . . . . . . . . . . . 371 

RACF ® for VM. . . . . . . . . . . . 371 

Other TCP/IP Related Publications . . . . . . 371 

Index . . . . . . . . . . . . . . . 373 

vi 


Preface 

Who Should Read This Book 

This TCP/IP User’s Guide describes the functions of TCP/IP Level 430 and explains 

how to use the applications available in TCP/IP for z/VM. These applications 

include: 

v Transferring files 

v Sending electronic mail 

v Logging on to a foreign host 

v Monitoring the network 

v Authenticating network users 

v Remote printing 

v Managing network resources 

v Using the Domain Name System 

This book also describes how to use the Network File System (NFS), REXEC 

command, and GDDMXD with the X Window System. 

For information about how to set up, initialize, and customize your TCP/IP, see 

TCP/IP Planning and Customization and TCP/IP Programmer’s Reference. For 

information about error messages that may appear while using TCP/IP, see TCP/IP 

Messages and Codes. 

This book is intended for an end-user and describes how to use TCP/IP Level 430 

after it has been installed and customized on your network. You should read this 

book when you want to use the applications that are available in TCP/IP Level 

430. 

What You Should Know before Reading This Book 

What This Book Contains 

Before using this book, you should be familiar with the CP and CMS components 

of z/VM. 

In addition, TCP/IP should already be installed and customized for your network. 

The following section briefly describes the format and organization of this book. 

This book describes all applications available with TCP/IP Level 430; however, 

your organization may install and use only some of these functions. 

Chapter 1, “Introducing Computer Networks and Protocols” on page 1, introduces 

the concepts of computer networks, the internet environment, TCP/IP protocols 

and functions, routing, and internet addressing. This chapter is optional for users 

who are familiar with computer networks and protocols. 

Chapter 2, “Transferring Files Using FTP” on page 15, describes how to use the File 

Transfer Protocol (FTP) command and its subcommands to transfer files from one 

host to another host. 

© Copyright IBM Corp. 1987, 2002 vii

Chapter 3, “Transferring Files Using TFTP” on page 85, describes how to use the 

Trivial File Transfer Protocol (TFTP) command and the subcommands that are 

associated with the TFTP command. 

Chapter 4, “Sending and Receiving Electronic Mail” on page 91, describes how to 

send electronic mail using the NOTE command, the SENDFILE command, and the 

PROFS ® interface. 

Chapter 5, “Logging On to a Foreign Host” on page 101, describes how to log on to 

a foreign host using the various types of terminal emulation that are associated 

with the Telnet protocol. 

Chapter 6, “Monitoring the TCP/IP Network” on page 107, describes how to obtain 

status information from the network using the NETSTAT command, RPCINFO 

command, and PING command. 

Chapter 7, “Authenticating Network Users with Kerberos” on page 133, describes 

how to use the authentication services of Kerberos. 

Chapter 8, “Using the Network File System Commands” on page 139, describes 

how to use the Network File System commands. 

Chapter 9, “Using the Remote Execution Protocol” on page 169, describes how to 

use the REXEC command. 

Chapter 10, “Using Remote Printing” on page 175, describes the line printer 

daemon (LPD) that provides support for remote printing. 

Chapter 11, “Using GDDMXD/VM with the X Window System” on page 195, 

describes GDDMXD/VM and the GDDMXD command. This chapter also describes 

how to use GDDMXD/VM user-specified options and keyboard functions. 

Chapter 12, “Managing TCP/IP Network Resources with SNMP” on page 213, 

describes the Simple Network Management Protocol (SNMP). 

Chapter 13, “Using the Network Database System (NDB)” on page 231, describes 

the Network Database system (NDB) used for relational database systems in a 

TCP/IP environment. 

Chapter 14, “Using the Domain Name System” on page 243, describes Domain 

Name Systems and how to query domain name servers. 

Chapter 15, “Using Translation Tables” on page 277, describes how to customize the 

translation tables supplied with TCP/IP. 

Appendix A, “Specifying Files and Data Sets” on page 289, describes the acceptable 

file formats for the AIX ® , MVS, and OS/2 ® operating systems, and AS/400’s ® 

operating system. This appendix also provides examples of each format. 

Appendix B, “Using the NETRC DATA File” on page 293, describes the NETRC 

DATA File and how it can be used with various applications. 

Appendix C, “Mapping Values for the APL2 Character Set” on page 295, describes 

the GDXAPLCS MAP file. This appendix also lists GDDMXD/VM’s default 

mapping values for the APL2 ® character set. 

viii 


How to Use This Book 

Appendix D, “Using DBCS with FTP and Mail” on page 301, describes how to use 

National Language Support to transfer Kanji files using FTP and SMTP. 

Appendix E, “Management Information Base Objects” on page 307, describes the 

Management Information Base (MIB) objects that are supported by the VM agent. 

Appendix F, “IBM 3172 Attribute Index” on page 335, lists MIB variables and 

corresponding attributes. 

Appendix G, “SNMP Generic TRAP Types” on page 337, describes the TRAP 

messages associated with SNMP. 

Appendix H, “Related Protocol Specifications” on page 339, lists the related 

protocol specifications concerning TCP/IP Level 430. 

Appendix I, “Abbreviations and Acronyms” on page 343, lists the abbreviations 

and acronyms that are used throughout this book. 

This book also includes a glossary, a bibliography, and an index. 

Use this book to understand the commands that are used to exploit the networking 

protocols. 

How the Term “internet” Is Used in This Book 

In this book, an internet is a logical collection of networks supported by routers, 

gateways, bridges, hosts, and various layers of protocols, which permit the 

network to function as a large, virtual network. 

Note: The term “internet” is used as a generic term for a TCP/IP network, and 

should not be confused with the Internet, which consists of large national 

backbone networks (such as MILNET, NSFNet, and CREN) and a myriad of 

regional and local campus networks worldwide. 

Where to Find More Information 

Appendix I, “Abbreviations and Acronyms” on page 343, lists the abbreviations 

and acronyms that are used throughout this book. 

The “Glossary” on page 351, defines terms that are used throughout this book 

associated with TCP/IP communication in an internet environment. 

For more information about related publications, see “Bibliography” on page 369. 

| 

| 

| 

| 

| 

| 

| 

| 

PDF Links to Other Books 

The PDF version of this book provides links to other IBM books by file name. The 

name of the PDF file for an IBM book is unique and identifies the book and its 

edition. The book links provided in this book are for the editions (PDF file names) 

that were current when this PDF file was generated. Newer editions of some books 

(with different file names) may exist. A PDF link from this book to another book 

works only when a PDF file with the requested file name resides in the same 

directory as this book. 

Preface 

ix

Understanding Syntax Diagrams 

This section describes how to read the syntax diagrams in this book. 

Getting Started: To read a syntax diagram, follow the path of the line. Read from 

left to right and top to bottom. 

v The ►►─── symbol indicates the beginning of a syntax diagram. 

v 

v 

v 

The ───► symbol, at the end of a line, indicates that the syntax diagram 

continues on the next line. 

The ►─── symbol, at the beginning of a line, indicates that a syntax diagram 

continues from the previous line. 

The ───►◄ symbol indicates the end of a syntax diagram. 

Syntax items (for example, a keyword or variable) may be: 

v Directly on the line (required) 

v Above the line (default) 

v Below the line (optional). 

Syntax Diagram Description 

Abbreviations: 

Uppercase letters denote the shortest acceptable 

abbreviation. If an item appears entirely in uppercase letters, 

it cannot be abbreviated. 

Example 

►► KEYWOrd ►◄ 

You can type the item in uppercase letters, lowercase letters, 

or any combination. 

In this example, you can enter KEYWO, KEYWOR, or 

KEYWORD in any combination of uppercase and lowercase 

letters. 

Symbols: 

You must code these symbols exactly as they appear in the 

syntax diagram. 

Variables: 

Highlighted lowercase items (like this) denote variables. 

* Asterisk 

: Colon 

, Comma 

= Equal Sign 

- Hyphen 

() Parentheses 

. Period 

►► KEYWOrd var_name ►◄ 

In this example, var_name represents a variable you must 

specify when you code the KEYWORD command. 

x 



Repetition: 

An arrow returning to the left means that the item can be 

repeated. 

A character within the arrow means you must separate 

repeated items with that character. 

A footnote (1) by the arrow references a limit that tells how 

many times the item can be repeated. 

Example 

►► ▼ repeat ►◄ 

, 

►► ▼ repeat 

►◄ 

►► ▼ (1) 

repeat 

►◄ 

Notes: 

1 Specify repeat up to 5 

times. 

Required Choices: 

When two or more items are in a stack and one of them is 

on the line, you must specify one item. 

►► 

A 

B 

C 

►◄ 

In this example, you must choose A, B, or C. 

Optional Choice: 

When an item is below the line, the item is optional. In this 

example, you can choose A or nothing at all. 

►► 

A 

►◄ 

When two or more items are in a stack below the line, all of 

them are optional. In this example, you can choose A, B, C, 

or nothing at all. 

►► 

A 

B 

C 

►◄ 

Defaults: 

Defaults are above the line. The system uses the default 

unless you override it. You can override the default by 

coding an option from the stack below the line. 

In this example, A is the default. You can override A by 

choosing B or C. 

►► 

A 

B 

C 

►◄ 

Preface 

xi


Repeatable Choices: 

A stack of items followed by an arrow returning to the left 

means that you can select more than one item or, in some 

cases, repeat a single item. 

In this example, you can choose any combination of A, B, or 

C. 

Example 

►► ▼ A 

B 

C 

►◄ 

Syntax Fragments: 

Some diagrams, because of their length, must fragment the 

syntax. The fragment name appears between vertical bars in 

the diagram. The expanded fragment appears in the 

diagram after a heading with the same fragment name. 

In this example, the fragment is named “A Fragment.” 

►► A Fragment ►◄ 

A Fragment: 

A 

B 

C 

How Numbers Are Used in This Book 

In this book, numbers over four digits are represented in metric style. A space is 

used rather than a comma to separate groups of three digits. For example, the 

number sixteen thousand, one hundred forty-seven is written 16 147. 

How to Send Your Comments to IBM 

Your feedback is important in helping us to provide the most accurate and 

high-quality information. If you have comments about this book or any other VM 

documentation, send your comments to us using one of the following methods. Be 

sure to include the name of the book, the publication number (including the 

suffix), and the page, section title, or topic you are commenting on. 

v Visit the z/VM web site at: 

http://www.ibm.com/eserver/zseries/zvm/ 

v 

v 

There you will find the feedback page where you can enter and submit your 

comments. 

Send your comments by electronic mail to one of the following addresses: 

Internet: vmpub@us.ibm.com 

IBMLink : GDLVME(PUBRCF) 

Fill out the Readers’ Comments form at the back of this book and return it by 

mail, by fax (1–607–752–2327), or by giving it to an IBM representative. If the 

form is missing, you can mail your comments to the following address: 

IBM Corporation 

Information Development 

Department G60G 

1701 North Street 

Endicott, New York 13760-5553 

USA 

xii 


Summary of Changes 

This section describes the technical changes made in this edition of the book and in 

previous editions. For your convenience, the changes made in this edition are 

identified in the text by a vertical bar (|) in the left margin. This edition may also 

include minor corrections and editorial changes that are not identified. 

Second Edition for z/VM Version 4 (May 2002) 

This edition contains updates for the General Availability of TCP/IP Level 430. 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

PASV FTP client support 

A new FTP PASSIVE subcommand has been added so that z/VM FTP clients 

outside of a firewall can transfer files to and from an FTP server that is inside of a 

firewall. 

TCP/IP Stack Vulnerability Reduction 

Function has been added to improve the performance and reliability of the TCP/IP 

stack by preventing more Denial-of-Service (DoS) attacks. These attacks include: 

v 

v 

v 

v 

v 

v 

Kiss-of-Death (KOD) — an IGMP based attack that depletes the stack’s large 

envelopes 

KOX — a version of the KOD attack that also has source IP address spoofing 

Stream — an attack in which TCP packets are sent to the stack with no header 

flags set 

R4P3D — an augmented version of the Stream attack 

Blat — a version of the Land attack that also has the URG flag turned on in the 

TCP header and has the ability to incrementally spoof the source IP address 

SynFlood — an attack in which the initiator floods the TCP/IP stack with SYN 

packets that have spoofed source IP addresses, resulting in the server never 

receiving the final ACKs needed to complete the three-way handshake in the 

connection process. 

The Smurf DoS attack has also been updated to address three variants of the 

attack. Smurf is a DoS attack in which an ICMP Echo Request is sent to a 

broadcast or multicast address. The three variants are: 

v 

v 

v 

Smurf-IC — where ″IC″ denotes that incoming packets are using the TCP/IP 

stack to launch an attack 

Smurf-OB — where ″OB″ denotes that an outbound ICMP Echo Request 

matched the description of a Smurf attack 

Smurf-RP — where ″RP″ denotes that ICMP Echo Reply packets being received 

by the stack do not match any Echo Requests that were sent. 

First Edition for z/VM Version 4 (October 2001) 

This edition contains updates for the General Availability of TCP/IP Level 420. 

TCP/IP Stack Performance and Reliability Improvements 

Function has been added to improve the performance and reliability of the TCP/IP 

stack by preventing some Denial of Service (DOS) attacks. These attacks include: 

© Copyright IBM Corp. 1987, 2002 xiii

ICMP Echo Request packets sent to IP broadcast or multicast addresses (Smurf), 

UDP Echo Request packets sent to IP broadcast or multicast addresses (Fraggle), 

and ICMP Echo Request packets that are too large (Ping-o-Death). When these 

attacks are detected, the packet is discarded and you receive message, 

DTCIPU086I. The NETSTAT command has two new operands, DOS and 

RESETDOS. NETSTAT DOS displays information about the Denial of Service 

attacks. NETSTAT RESETDOS resets the data displayed for Denial of Service 

attacks. 

IMAP Support 

Support has been added for the Internet Message Access Protocol (IMAP) server. 

This provides the processing that allows a client to access electronic mail that is 

kept in an IMAP Mailstore server. 

First Edition for z/VM Version 3 (February 2001) 

This edition contains updates for TCP/IP Level 3A0. 

FTP Web Browser Support 

The FTP server has been enhanced to better accommodate web browser and 

graphical FTP clients. The changes and new function include: 

v 

v 

v 

The ability to provide Unix-format list information in response to client DIR 

subcommand requests 

The ability to perform automatic EBCDIC-ASCII data translation for transferred 

files, based on file types (or, file extentions) 

A new SIZE subcommand 

VM Network File System (NFS) Client 

Allows BFS users and applications transparent access to data on remote systems 

with NFS servers. 

IP Multicasting 

IP Multicasting provides support for: 

v 

NETSTAT ALL and NETSTAT DEVLINKS to display information for IP 

multicasting 

Secure Socket Layer (SSL) Support 

SSL is a TCP/IP protocol that provides privacy between two communicating 

applications (a client and a server). The processing required for SSL is provided by 

a VM TCP/IP security server. 

An SSL session therefore consists of two connections — the connection from the 

remote client to the security server and the connection from the security server to 

the (application) server. 

v New NETSTAT Function: 

The output of the NETSTAT CONN command has been enhanced to identify 

both connections participating in an SSL session. 

xiv 


Chapter 1. Introducing Computer Networks and Protocols 

Computer Networks 

Internet Environment 

This chapter introduces the concepts of computer networks and an internet 

environment. The protocols used by TCP/IP are listed by layer and then described. 

Routing and addressing guidelines are also described. 

A computer network is a group of connected nodes that are used for data 

communication. A computer network configuration consists of data processing 

devices, software, and transmission media that are linked for information 

interchange. 

Nodes are the functional units, located at the points of connection among the data 

circuits. A node, or end point, can be a host computer, a communication controller, 

a cluster controller, a video display terminal, or another peripheral device. 

Computer networks can be local area networks (LANs), which provide direct 

communication among data stations on the user’s local premises, or wide area 

networks (WANs), which provide communication services to a geographic area 

larger than that served by a LAN. Typically, WANs operate at a slower rate of 

speed than LANs. 

Different types of networks provide different functions. Network configurations 

vary, depending on the functions required by the organization. Different 

organizations implement different types of networks. The technology used by these 

networks varies not only from organization to organization, but often varies within 

the same company. 

Networks can differ at any or all layers. At the physical layer, networks can run 

over various network interfaces, such as Token-Ring, Ethernet, PC Network, Fiber 

Distribution Data Interface (FDDI), and X.25. Networks can also vary in the 

architectures they use to implement network strategies. Some of the more common 

architectures used today are Open Systems Interconnection (OSI), Transmission 

Control Protocol/Internet Protocol (TCP/IP), Systems Network Architecture (SNA), 

and Integrated Services Digital Network (ISDN). Networks use different protocols 

to communicate over the different physical interfaces available. In addition to these 

differences, networks can use different software packages to implement various 

functions. 

To exchange information among these different networks, the concept of an 

internet emerged. 

An internet is a logical collection of networks supported by gateways, routers, 

bridges, hosts, and various layers of protocols. An internet permits different 

physical networks to function as a single, large virtual network, and permits 

dissimilar computers to communicate with each other, regardless of their physical 

connections. Processes within gateways, routers, and hosts originate and receive 

packet information. Protocols specify a set of rules and formats required to 

exchange these packets of information. 

© Copyright IBM Corp. 1987, 2002 1

Introduction 

Protocols are used to accomplish different tasks in TCP/IP software. To understand 

TCP/IP, you should be familiar with the following terms and relationships. 

A client is a computer or process that requests services on the network. A server is 

a computer or process that responds to a request for service from a client. A user 

accesses a service, which allows the use of data or some other resource. 

A datagram is a basic unit of information, consisting of one or more data packets 

that are passed across an internet at the transport level. 

A gateway is a functional unit that connects two computer networks of different 

network architectures. A router is a device that connects networks at the ISO 

Network Layer. A router is protocol-dependent and connects only networks 

operating the same protocol. Routers do more than transmit data; they also select 

the best transmission paths and optimum sizes for packets. A bridge is a router 

that connects two or more networks and forwards packets among them. The 

operations carried out by a bridge are done at the physical layer and are 

transparent to TCP/IP and TCP/IP routing. 

A host is a computer, connected to a network, that provides an access point to that 

network. A host can be a client, a server, or a client and server simultaneously. In a 

communication network, computers are both the sources and destinations of the 

packets. The local host is the computer to which a user’s terminal is directly 

connected without the use of an internet. A foreign host is any machine on a 

network that can be interconnected. A remote host is any machine on a network 

that requires a physical link to interconnect with the network. 

An internet address is a unique 32-bit address identifying each node in an internet. 

An internet address consists of a network number and a local address. Internet 

addresses are represented in dotted-decimal notation and are used to route packets 

through the network. 

Mapping relates internet addresses to physical hardware addresses in the network. 

For example, the Address Resolution Protocol (ARP) is used to map internet 

addresses to Token-Ring or Ethernet physical hardware addresses. 

A network is the combination of two or more nodes and the connecting branches 

among them. A physical network is the hardware that makes up a network. A 

logical network is the abstract organization overlaid on one or more physical 

networks. An internet is an example of a logical network. 

Packet refers to the unit or block of data of one transaction between a host and its 

network. A packet usually contains a network header, at least one high-level 

protocol header, and data blocks. Generally, the format of the data blocks does not 

affect how packets are handled. Packets are the exchange medium used at the 

internetwork layer to send and receive data through the network. 

A port is an end point for communication between applications, generally referring 

to a logical connection. A port provides queues for sending and receiving data. 

Each port has a port number for identification. When the port number is combined 

with an internet address, a socket address results. 

Protocol refers to a set of rules for achieving communication on a network. 

2 z/VM: TCP/IP User’s Guide

TCP/IP Protocols and Functions 

This section categorizes the TCP/IP protocols and functions by their functional 

group link(physical) layer, network layer, transport layer, and application layer). 

Table 1 shows the functional groups and their related protocols and functions. 

Table 1. Functional Groups 


Group Protocols and Functions Page 

Link (physical) layer Token-Ring ; Ethernet ; X.25 ; Others 4 

Network Layer Internet Protocol (IP) ; Internet Control 

4 

Message Protocol (ICMP) ; Address Resolution 

Protocol (ARP) ;Internet Group Management 

Protocol (IGMP) 

Transport Layer Transmission Control Protocol (TCP) ; User 

Datagram Protocol (UDP) 

Application Layer Telnet 

File Transfer Protocol (FTP) 

Trivial File Transfer Protocol (TFTP) 

Internet Message Access Protocol (IMAP) 

Simple Mail Transfer Protocol (SMTP) 

Domain Name System (DNS) 

Simple Network Management Protocol (SNMP) 

Kerberos Authentication System 

Remote Printing (LPR and LPD) 

RouteD 

X Window System 

X Toolkit 

GDDMXD 

Remote Procedure Call (RPC) 

Network File System (NFS) 

Remote Execution Protocol (REXEC) 

Bootstrap Protocol (BOOTP) 

Dynamic Host Configuration Protocol (DHCP) 

Network Database System (NDB) 

Socket Interfaces 

Secure Socket Layer (SSL) 

6 

6-10 

Figure 1 on page 4 shows the relationship of these protocols and functions within 

the TCP/IP layered architecture for VM. 

Chapter 1. Introducing Computer Networks and Protocols 3


Figure 1. The TCP/IP Layered Architecture 

Link Protocols 

Various network protocols compose the network layer available in TCP/IP. 

Network protocols define how data is transported over a physical network. These 

network protocols are not defined by TCP/IP. After a TCP/IP packet is created, the 

network protocol adds a transport-dependent network header before the packet is 

sent out on the network. 

X.25 

You can use an X.25 network to establish a TCP/IP connection between two hosts. 

X.25, recommended as a communication interface standard by the International 

Telegraph and Telephone Consultative Committee (CCITT), defines the interface 

between Data Terminal Equipment (DTE) and Data Circuit-Terminating Equipment 

(DCE). A DTE is a computer or workstation connected to a network. A DCE is the 

equipment at the point of the connection to the network, such as a modem. 

For more information about using TCP/IP over an X.25 network, see Request For 

Comment (RFC) 877. 

Network Protocols 

Protocols in the internetwork layer provide connection services for TCP/IP. These 

protocols connect physical networks and transport protocols. This section describes 

the internetwork protocols in TCP/IP. 

4 z/VM: TCP/IP User’s Guide 

For more information about TCP/IP in general, see RFCs 1118, 1180, 1206, 1207, 

and 1208. See Appendix H, “Related Protocol Specifications” for a list of other 

related RFCs. 

Internet Protocol (IP) 

The Internet Protocol (IP) provides the interface from the transport layer 

(host-to-host, TCP, or UDP) protocols to the physical-level protocols. IP is the basic 

transport mechanism for routing IP packets to the next gateway, router, or 

destination host.

IP provides the means to transmit blocks of data (or packets of bits) from sources 

to destinations. Sources and destinations are hosts identified by fixed-length 

internet addresses. Outgoing packets automatically have an IP header prefixed to 

them, and incoming packets have their IP header removed before being sent to the 

higher-level protocols. This protocol provides for the universal addressing of hosts 

in an internet network. 

IP does not ensure a reliable communication, because it does not require 

acknowledgments from the sending host, receiving host, or intermediate hosts. IP 

does not provide error control for data; it provides only a header checksum. IP 

treats each packet as an independent entity unrelated to any other packet. IP does 

not perform retransmissions or flow control. A higher-level protocol that uses IP 

must implement its own reliability procedures. 

For more information about IP, see RFC 791. 

Internet Control Message Protocol (ICMP) 

The Internet Control Message Protocol (ICMP) passes control messages between 

hosts, gateways, and routers. For example, ICMP messages can be sent in any of 

the following situations: 

v When a host checks to see if another host is available (with a PING command) 

v When a packet cannot reach its destination 

v When a gateway or router can direct a host to send traffic on a shorter route 

v When a host requests a netmask or a time stamp 

v 

When a gateway or router does not have the buffering capacity to forward a 

packet 

ICMP provides feedback about problems in the communication environment; it 

does not make IP reliable. ICMP does not guarantee that an IP packet is delivered 

reliably or that an ICMP message is returned to the source host when an IP packet 

is not delivered or is incorrectly delivered. 

For more information about ICMP, see RFC 792. 

Address Resolution Protocol (ARP) 

The Address Resolution Protocol (ARP) maps internet addresses to hardware 

addresses. TCP/IP uses ARP to collect and distribute the information for mapping 

tables. 

ARP is not directly available to users or applications. When an application sends 

an internet packet, IP requests the appropriate address mapping. If the mapping is 

not in the mapping table, an ARP broadcast packet is sent to all the hosts on the 

network requesting the physical hardware address for the host. 

For more information about ARP, see RFC 826. 


Internet Group Management Protocol (IGMP) 

The Internet Group Management Protocol (IGMP) is used to communicate 

multicast group information. It lets all systems on a physical network know which 

hosts belong to which multicast groups. Multicast routers use IGMP messages to 

determine which multicast datagrams to forward onto which interfaces. 

There are two types of IGMP messages — reports and queries. IGMP report 

messages are sent out to notify others when a multicast group has been joined, and 



to respond to an IGMP query that was received. IGMP query messages are sent 

out by multicast routers to see which multicast groups still have members. 

For more information about IGMP, see RFC 1112. 

Transport Protocols 

The transport layer of TCP/IP consists of transport protocols, which allow 

communication between application programs. This section describes the transport 

protocols in TCP/IP. 

Transmission Control Protocol (TCP) 

The Transmission Control Protocol (TCP) provides a reliable vehicle for delivering 

packets between hosts on an internet. TCP takes a stream of data, breaks it into 

datagrams, sends each one individually using IP, and reassembles the datagrams at 

the destination node. If any datagrams are lost or damaged during transmission, 

TCP detects this and resends the missing datagrams. The received data stream is a 

reliable copy of the transmitted data stream. 

For more information about TCP, see RFC 793. 

User Datagram Protocol (UDP) 

The User Datagram Protocol (UDP) provides an unreliable mode of communication 

between source and destination hosts. UDP is a datagram-level protocol built 

directly on the IP layer. UDP is used for application-to-application programs 

between TCP/IP hosts. 

Like IP, UDP does not offer a guarantee of datagram delivery or duplication 

protection. UDP does provide checksums for both the header and data portions of 

a datagram. However, applications that require reliable delivery of streams of data 

should use TCP. 

For more information about UDP, see RFC 768. 

Applications and Protocols 

Applications are provided with TCP/IP that allow users to use network services. 

These applications are included in the application layer of TCP/IP. The application 

layer is built on the services of the transport layer. This section describes the 

applications, functions, and protocols in TCP/IP. 

Telnet Protocol 

The Telnet Protocol provides a standard method to interface terminal devices and 

terminal-oriented processes with each other. Telnet is built on the services of TCP 

in the transport layer. Telnet provides duplex communication and sends data either 

as ASCII characters or as binary data. 

Telnet is commonly used to establish a logon session on a foreign host. Telnet can 

also be used for terminal-to-terminal communication and interprocess 

communication. 

For more information about the Telnet Protocol, see RFCs 854, 856, 857, 885, and 

1091. 

File Transfer Protocol (FTP) 

The File Transfer Protocol (FTP) allows you to transfer data between local and 

foreign hosts or between two foreign hosts. FTP is built on the services of TCP in 


the transport layer. FTP transfers files as either ASCII characters or as binary data. 

ASCII characters are used to transfer files that contain only text characters. 

FTP provides functions, such as listing remote directories, changing the current 

remote directory, creating and removing remote directories, and transferring one or 

more files in a single request. Security is handled by passing user and account 

passwords to the foreign hosts. 

For more information about FTP, see RFC 959. 

Trivial File Transfer Protocol (TFTP) 

Trivial File Transfer Protocol (TFTP) is designed only to read and write files to and 

from a foreign host. TFTP is built on the services of UDP in the transport layer. 

TFTP allows you to limit drive and directory access. 

TFTP, like FTP, can transfer files as either ASCII characters or as binary data. 

However, unlike FTP, TFTP cannot be used to list or change directories at a foreign 

host, and it has no provisions for user authentication. 

For more information about TFTP, see RFC 783. 

Internet Message Access Protocol (IMAP) 

The Internet Message Access Protocol (IMAP) is a mail protocol with both client 

(sender) and server (receiver) functions. 

IMAP provides the processing that allows a client to access electronic mail that is 

kept in an IMAP Mailstore server. It permits a ″client″ email program to access 

remote message folders called ″mailboxes″, as if they were local. 

For more information about IMAP, see RFC 2060. 

Simple Mail Transfer Protocol (SMTP) 

The Simple Mail Transfer Protocol (SMTP) is an electronic mail protocol with both 

client (sender) and server (receiver) functions. 

SMTP is implemented with the CMS NOTE and CMS SENDFILE EXECs in a VM 

environment. You do not interface directly with SMTP. Instead, electronic mail 

software is used to create mail, which in turn uses SMTP to send the mail to its 

destination. 

For more information about SMTP, see RFCs 821, 822, 974, 1413, and 1440. 


The Domain Name System (DNS) uses a hierarchical-naming system for naming 

hosts. Each host name is composed of domain labels separated by periods. Local 

network administrators have the authority to name local domains within an 

internet. Each label represents an increasingly higher domain level within an 

internet. The fully qualified domain name of a host connected to one of the larger 

internets generally has one or more subdomains. 

For example: 

host.subdomain.subdomain.rootdomain 

or 

host.subdomain.rootdomain 


For more information about the Domain Name System, see RFCs 1034 and 1035. 



Simple Network Management Protocol (SNMP) 

The Simple Network Management Protocol (SNMP) provides a means for 

managing an internet environment. SNMP allows network management by 

elements, such as gateways, routers, and hosts. Network elements act as servers 

and contain management agents, which perform the management functions 

requested. Network management stations act as clients; they run the management 

applications, which monitor the network. SNMP provides a means of 

communicating between these elements and stations to send and receive 

information about network resources. 

For more information about Network Management, see RFCs 1155, 1157, 1187, and 

1213. 

Kerberos Authentication System 

The Kerberos Authentication System provides additional security by allowing 

authorization checking at the user level rather than at the node level. This system 

allows client and server pairs to verify that the partner is authorized to participate 

in the function being performed. 

For additional publications about Kerberos, see Bibliography. 

Remote Printing (LPR and LPD) 

TCP/IP provides both client and server support for remote printing. This 

application allows you to spool files remotely to a line printer daemon (LPD). The 

line printer client (LPR) sends the file to be printed to a specified print server host 

and to a specified printer. 

For more information about LPR and LPD, see RFC 1179. 

RouteD 

RouteD uses the Routing Information Protocol (RIP) to dynamically create and 

maintain network routing tables. RIP arranges to have gateways and routers 

periodically broadcast their routing tables to neighbors. Using this information, a 

RouteD server can update a host’s routing tables. For example, RouteD determines 

if a new route has been created, if a route is temporarily unavailable, or if a more 

efficient route exists. 

For more information about RIP, see RFCs 1058 and 1723. 

X Window System 

The X Window System Protocol is designed to support network transparent 

windowing and graphics. TCP/IP for z/VM provides client support for the X 

Window System application program interface. 

For more information about the X Window System Protocol, see RFC 1013. 

X Toolkit 

X toolkit is a collection of basic C language routines for developing a variety of 

application environments. 

Intrinsics: 

widgets. 

Intrinsics are a collection of C language routines for building and using 

Widgets: Widgets are a set of routines that create a graphic interface. 

v Athena Widgets 



v 

The widget set developed by MIT’s Project Athena is generally known as the 

Athena Widget set. It enables application programmers to include standard 

graphic elements in their applications. 

OSF/Motif 

OSF/Motif** is an X Window System toolkit defined by Open Software 

Foundation, Inc. (OSF**), which enables the application programmer to include 

standard graphic elements that have a three-dimensional appearance. 

Performance of the graphic elements is increased with gadgets and windowless 

widgets. 

GDDMXD 

GDDMXD is an interface that allows graphics from the IBM Graphical Data 

Display Manager/VM to be displayed on workstations that support the X Window 

System. 

When GDDMXD is installed and activated, the data stream created by GDDM ® is 

translated to the X Window System protocol and transmitted by TCP/IP to the 

X Window System server for the display. If GDDMXD is installed and not 

activated, or has been made inactive, GDDM transmits data to its supported 

display device as if GDDMXD was not present. 

Remote Procedure Call (RPC) 

The Remote Procedure Call Protocol (RPC) is a programming interface that calls 

subroutines to be executed on a foreign host. RPCs are high-level program calls, 

which can be used in place of the lower-level calls that are based on sockets. 

For more information about RPC, see RFC 1057. 

Network File System (NFS) 

The Network File System (NFS) allows you to manipulate files on different TCP/IP 

hosts as if they reside on your host. NFS is based on the NFS protocol, and uses 

the Remote Procedure Call (RPC) protocol to communicate between the client and 

the server. The files to be accessed reside on the server host and are made available 

to the user on the client host. 

The Network File System supports the hierarchical file structure used by the 

UNIX ® operating system. The directory and subdirectory structure can be different 

for individual client systems. 

For more information about NFS, see RFC 1094 and 1813. 

Remote Execution Protocol (REXEC) 

The Remote Execution Protocol (REXEC) allows you to execute a command on a 

foreign host and receive the results on the local host. Remote Execution Protocol 

provides automatic logon and user authentication, depending on the parameters 

set by the user. 

Bootstrap Protocol (BOOTP) 

The Bootstrap Protocol (BOOTP) allows a diskless client machine to discover its 

own IP address, the address of a server host, and the name of a file to be loaded 

into memory and executed. 

For more information about BOOTP, see RFC 0951 and TCP/IP Planning and 

Customization. 



Dynamic Host Configuration Protocol (DHCP) 

The Dynamic Host Configuration Protocol (DHCP) provides a framework for 

passing configuration information to hosts on a TCPIP network. DHCP is based on 

the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of 

reusable network addresses and additional configuration options. DHCP captures 

the behavior of BOOTP relay agents; DHCP participants can interoperate with 

BOOTP participants. 

For more information about DHCP, see RFC 2131 and TCP/IP Planning and 


Network Database System (NDB) 

The Network Database System (NDB) is used to access relational database systems 

in a TCP/IP-based internet environment. NDB uses the RPC protocol to allow 

interoperability among a variety of workstation users and the mainframe database 

management system, DB2 Server for VM NDB is used for data conversion, security, 

I/O buffer management, and transaction management. 

Socket Interfaces 

Socket interfaces allow you to write your own applications to supplement those 

supplied by TCP/IP. Most of these additional applications communicate with 

either TCP or UDP. Some applications are written to communicate directly with IP. 

To write applications that use the socket interfaces of TCP/IP for z/VM, you must 

be able to compile and link the programs. 

Sockets are duplex, which means that data can be transmitted and received 

simultaneously. Sockets allow you to send to, and receive from, the socket as if you 

are writing to and reading from any other network device. For more information 

on sockets, see TCP/IP Programmer’s Reference. 

Secure Socket Layer (SSL) 

The Secure Socket Layer (SSL) protocol provides privacy between two 

communicating applications — a client and a server. In SSL, a server is always 

authenticated and must provide a certificate to prove its identity. In addition to 

authentication, both the client and the server participate in a handshake protocol 

that produces the cryptographic parameters for the session. 

The processing required for SSL is provided by a TCP/IP security server. An 

installation identifies the ports that are secure and specifies the certificates to be 

used. Any VM TCP/IP server listening on a secure port can participate in an SSL 

session with any external client that supports SSL. The SSL session consists of two 

connections — the connection from the remote client to the security server and the 

connection from the security server to the real (application) server. 

For more information about SSL, see TCP/IP Planning and Customization. 

Routing 

The routing functions in an internet are performed at the internetwork layer. 

Routing is the process of deciding where to send a packet based on its destination 

address. Two kinds of routing are involved in communication within an internet: 

direct and indirect. 

Direct routing is used when the source and destination nodes are on the same 

logical network within an internet. The source node maps the destination internet 

address into a hardware address and sends packets to the destination node 


Internet Addressing 


through this address. This mapping is normally performed through a translation 

table. If a match cannot be found for a destination internet address, ARP is 

invoked to determine this address. 

Indirect routing is used when the source and destination nodes are on different 

networks within an internet. The source node sends packets to a gateway or router 

on the same network using direct routing. From there, the packets are forwarded 

through intermediate gateways or routers, as required, until they arrive at the 

destination network. Direct routing is then used to forward the packets to the 

destination host on that network. Each gateway, router, and host in an internet has 

a routing table that defines the address of the next gateway or router to other 

networks (as well as other nodes on other networks) in an internet. 

Each internet host is assigned at least one unique internet address. This address is 

used by the IP and other higher-level protocols. When gateway hosts are used, 

more than one address may be required. Each interface to an internet is assigned 

its own unique address. Internet addresses are used to route packets through the 

network. 

Addresses within an internet consist of a network number and a local address. The 

unique network number is assigned to each network when it connects to another 

internet. If a local network is not going to connect to other internets, any 

convenient network number is assigned. 

Hosts that exchange packets on the same physical network should have the same 

network number. Hosts on different physical networks might also have the same 

network number. If hosts have the same network number, part of the local address 

is used as a subnetwork number. All host interfaces to the same physical network 

are given the same subnetwork number. 

An internet can provide standards for assigning addresses to networks, broadcasts, 

and subnetworks. Examples of these standard formats are described in the 

following sections. 

Network Address Format 

A standard internet address uses a two-part, 32-bit address field. The first part of 

the address field contains the network address; the second part contains the local 

address. The four different types of address fields are classified as A, B, C, or D, 

depending on the bit allocation. 

Figure 2 represents a class A address. A class A address has a 7-bit network 

number and a 24-bit local address. The highest order bit is set to 0. 

0 1234567 

1 2 3 

890123456789012345678901 

0 Network 

Local Address 

Figure 2. Class A Address 



Figure 3 represents a class B address. A class B address has a 14-bit network 

number and a 16-bit local address with the highest order bits set to 10. 

1 2 3 

01 23456789012345 6789012345678901 

10 

Network 

Local Address 

Figure 3. Class B Address 

Figure 4 represents a class C address. A class C address has a 21-bit network 

number and an 8-bit local address with the three highest order bits set to 110. 

1 2 3 

012 345678901234567890123 45678901 

110 

Figure 4. Class C Address 

Network 

Local Address 

Figure 5 represents a class D address. A class D network is a multicast address that 

is sent to selected hosts on the network. The four highest order bits are set to 1110. 

Figure 5. Class D Address 

Note: Class D addresses are not supported in TCP/IP for z/VM. 

A commonly used notation for internet host addresses is the dotted-decimal, which 

divides the 32-bit address into four 8-bit fields. The value of each field is specified 

as a decimal number, and the fields are separated by periods (for example, 

010.002.000.052 or 10.2.0.52). 

Address examples in this book use dotted-decimal notation in the following forms: 

Class A nnn.lll.lll.lll 

Class B nnn.nnn.lll.lll 

Class C nnn.nnn.nnn.lll 

where: 

nnn 

lll 

Represents part or all of a network number. 

Represents part or all of a local address. 

Broadcast Address Format 

TCP/IP uses IP broadcasting to send datagrams to all the TCP/IP hosts on a 

network or subnetwork. A datagram sent to the broadcast address is received by 


all the hosts on the network and processed as if the datagram was sent directly to 

the host’s IP address. The IP broadcast address is formed by setting all the host 

bits to ones. 

For more information about IP broadcasting, see RFCs 919 and 922. 

Multicast Address Format 

TCP/IP uses IP multicasting to send datagrams to all the TCP/IP hosts on a 

network or subnetwork. The multicast datagrams are only received by those 

TCP/IP hosts that have signed up to listen for the particular IP multicast address 

(joined the multicast group). If a TCP/IP host has not joined the multicast group, 

then the datagram is discarded. 

For more information on IP multicasting, see RFC 1112. 

Subnetwork Address Format 

The subnetwork capability of TCP/IP divides a single network into multiple 

logical networks (subnets). For example, an organization can have a single internet 

network address that is known to users outside the organization, yet configure its 

internal network into different departmental subnets. Subnetwork addresses 

enhance local routing capabilities, while reducing the number of network numbers 

required. For a subnet, the local address part of an internet address is divided into 

a subnet number and a host number, for example: 

network_number subnet_number host_number 


where: 

network_number 

subnet_number 

host_number 

Is the network portion of the internet address. 

Is a field of a constant width for a given network. 

Is a field that is at least 1-bit wide. 

If the width of the subnet_number field is 0, the network is not organized into 

subnets, and addressing to the network is done with an internet network address 

(network_number). 

Figure 6 represents a class B address with a 6-bit wide subnet field. 

1 2 3 

01 23456789012345 6789012345678901 

10 

Network 

Subnet 

Host 

Figure 6. Class B Address with Subnet 

The bits that identify the subnet are specified by a bit mask. A bit mask is a 

pattern of characters used to assign subnet addresses. The subnet bits are not 

required to be adjacent in the address. However, the subnet bits generally are 

contiguous and are the most significant bits of the local address. 

For more information about subnetwork addresses, see RFC 950. 



Chapter 2. Transferring Files Using FTP 

This chapter describes how to use the File Transfer Protocol (FTP) command and 

its subcommands to transfer files between your local host and a foreign TCP/IP 

host. The FTP command and its subcommands, allow you to sequentially access 

multiple foreign hosts without leaving the FTP environment. 

When FTP commands are used with a non-z/VM foreign host, you may need to 

consult documentation specific to that host and its operating system for 

information about file naming and supported FTP commands and parameters. 

The following table lists general operations and FTP subcommands that correspond 

to these functions: 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

Table 2. FTP and Subcommand Functions 

FUNCTION 

SUBCOMMANDS 

Establish a connection and identify yourself to ACCT OPEN USER NETRC PASS 

a foreign host’s FTP server 

Obtain status information about FTP on the DEBUG NOOP STATUS 

foreign host 

SYSTEM 

List or work with directories belonging to the 

foreign host 

CD or CWD CDUP 

LS 

DIR MKDIR RMDIR 

PWD 

List or work with directories on the local host LCD LPWD 

Prepare the environment prior to transferring 

files 

Transfer Parameter Commands 

HANGEUL JIS78KJ 

KSC5601 

TCHINESE 

ASCII EBCDIC 

BINARY MODE 

PORT PASSIVE 

Perform Special Function QUOTE SITE 

Work with and transfer files to and from the 

foreign host 

APPEND GET PUT 

EUCKANJI 

IBMKANJI JIS83KJ 

LOCSITE SIZE 

SJISKANJI 

SUNIQUE TYPE 

SENDPORT 

SENDSITE STRUCT 

DELIMIT MGET 

MPUT 

Delete or rename files on the foreign host DELETE RENAME MDELETE 

Communicate with the underlying operating CMS 

systems 

Obtain help about FTP and its subcommands HELP 


Transferring Files Using FTP 

FTP Command 

Use the FTP command to establish an environment or, shell that allows you to 

transfer files between your local host and a foreign TCP/IP host. 

►► 

FTP 

foreign_host 

21 

port_number 

( Options 

►◄ 

Options: 

Exit NONetrc NOPrompt TImeout value TRACe 

► 

| 

► 

TRANslate 

filename 

WIDth 80 

WIDth 

width 

Operands 


Once an FTP connection has been established with a foreign host, the various 

subcommands listed in Table 3 on page 26 can be used to transfer files and interact 

with the remote FTP server. 

foreign_host 

The name of the foreign host to which you are connecting. Specify foreign_host 

using an internet host name or a dotted-decimal address. You are prompted for 

a host name if this operand is omitted when the FTP command is issued. 

port_number 

the port number of the FTP server on the foreign host. The default is port 21, 

which is considered to be a “well-known” port. 

Exit 

Causes FTP to terminate when an error condition is encountered. Error 

conditions associated with FTP subcommands will also cause FTP to terminate 

when this operand is used. For more information about FTP return codes, see 

“FTP Return Codes” on page 78. 

NONetrc 

Suppresses use of the NETRC DATA file. See “The NETRC DATA File” on 

page 19 for more information. 

NOPrompt 

Suppresses prompts for the logon user name and password. Use this option 

when a NETRC DATA file is used and command input is to be obtained 

through non-interactive means, such as from an exec. See “The NETRC DATA 

File” on page 19 for more information. 

TImeout seconds 

Specifies the number of seconds to be used for all of the following timing 

parameters: 

v MyopenTime 

v DconnTime 

v CconnTime


v 

v 

InactTime 

DataCtTime 

The value specified with the TIMEOUT operand is applied to each previously 

listed timing parameter. If individual timeout values are required, these can be 

specified in an FTP data file. For more information about this file and timeout 

parameters and defaults, see “The FTP DATA File” on page 19. 

Numeric values between 15 and 720 are accepted for the TIMEOUT parameter. 

Note: If the TIMEOUT operand value is not valid, FTP ignores that value and 

uses the default values established for each timeout parameter. 

TRACe 

Starts the generation of tracing output. TRACE is used to assist in debugging. 

Trace data is written to the console. 

TRANslate filename 

The file name of a translation table file other than a standard table. The file 

type is TCPXLBIN, and the file mode is an asterisk (*). If this parameter is not 

specified, the FTP command searches sequentially for FTP TCPXLBIN and 

STANDARD TCPXLBIN. If neither is found, FTP uses the compiled translation 

table. 

Note: The FTP TCPXLBIN file is not supplied, because the standard translation 

table is adequate for most uses. You can create your own FTP 

TCPXLBIN file if your installation needs a translation for FTP that 

differs from the translation supported by STANDARD TCPXLBIN. For 

more information on translation tables see Chapter 15, “Using 

Translation Tables” on page 277. 

| 

| 

| 

| 

| 

| 

If LOADDBCSTABLE is specified in FTP DATA, then filename is used to 

determine which DBCS translation table to load. See TCP/IP Planning and 

Customization for information on the loading and customizing of DBCS 

translation tables. 

WIDth width 

Specifies the maximum width to use for lines written to the console by FTP. 

Data that is longer than the specified width is wrapped to successive lines, as 

necessary. The minimum acceptable width is 1, while the maximum is 32767. 

The default for width is 80. When a FILEDEF is used to control FTP command 

output, the WIDTH option is ignored. 

Usage Notes 

v 

v 

If the specified foreign_host is not accessible, or this operand has not been 

correctly specified, the FTP subcommand environment is established, but no 

foreign host connection exists. When this occurrs, the OPEN, USER, PASS, and 

ACCT subcommands can be used to establish a connection and log in as 

desired. 

If FTP can establish a connection to the specified foreign host and a valid entry 

for that host is present in a NETRC DATA file, by default, FTP uses that host’s 

user name and password to logon to that host. Otherwise, you are prompted for 

this information, unless the NOPROMPT command option has been specified to 

suppress prompting. 

Chapter 2. Transferring Files Using FTP 17


v 

Once in the FTP environment, FTP subcommands are limited to 130 characters 

unless line continuation is used. For more information see “Continuing 

Subcommand Input Strings” on page 29. 

Examples 

The example that follows shows information that is typically displayed when an 

FTP connection is successfully established with a foreign z/VM TCP/IP host. In 

this example GDLVM7 (in the domain ENDICOTT.IBM.COM) is the foreign_host to 

which the connection is made. 

Ready; 

ftp gdlvm7 

VM TCP/IP FTP Level 420 

Connecting to GDLVM7 9.117.32.29, port 21 

220-FTPSERVE IBM VM Level 330 at GDLVM7.ENDICOTT.IBM.COM, 

10:04:05 EST THURSDAY 2001-12-01 

220 Connection will close if idle for more than 5 minutes. 

USER (identify yourself to the host): 

terix 

>>>USER terix 

331 Send password please. 

Password: 

>>>PASS ******** 

230-TERIX logged in; working directory = TERIX 191 (ReadOnly) 

230 write access currently unavailable 

Command: 



The NETRC DATA File 

The FTP DATA File 

The NETRC DATA file provides an alternative to responding to FTP prompts for 

logon information when you connect to a foreign host. When a user name and 

password for a specific host are defined in this file, FTP will use those values 

instead of prompting for this information. 

When the FTP command or the OPEN subcommand is issued, FTP will search the 

NETRC DATA file for the first valid match on the specified host. If found, that 

host’s user name and password will be used when a connection to that host is 

attempted. If no match is found for the host in question, you will be prompted for 

a user name and password, unless the NOPROMPT option has been specified. 

For more information on the NETRC DATA File and how it may be used for other 

applications, see Appendix B, “Using the NETRC DATA File” on page 293. 

The FTP DATA configuration file defines operational characteristics that affect FTP 

connections and DBCS data translation. 

A sample FTP data file is provided as FTP SDATA on the TCPMAINT 592 disk. 

Notes: 

1. If the TIMEOUT operand is specified upon invocation of the FTP command, its 

corresponding value overrides all timing values specified within the FTP DATA 

file. However, if the TIMEOUT-specified value is not valid, the default timing 

values identified in the next section are used. 

2. When DBCS file transfers are performed, both the remote FTP server and the 

local client must have the appropriate translate tables loaded. 

Statement Syntax 

Within FTP DATA, blanks and record boundaries are used to delimit tokens. All 

characters to the right of (and including) a semicolon are treated as comments. 

FTP DATA File Statements 

Configuration statements that can be specified in the FTP DATA file are described 

in this section. 



CCONNTIME Statement 

The CCONNTIME statement specifies the timeout value used when waiting for a 

response to a connection close request on a Control connection. 

►► 

CconnTime 

30 

seconds 

►◄ 

Operands 

seconds 

The number of seconds to allow before a timeout when waiting for a response 

to a connection close request on a Control connection. The minimum 

CCONNTIME value is 15 and the maximum is 720; the default is 30 seconds. 


DATACTTIME Statement 


The DATACTTIME statement specifies the timeout value used when waiting for a 

response to a TCP send or TCP receive request. 

►► 

DataCtTime 

120 

seconds 

►◄ 

Operands 

seconds 


to a TCP send or TCP receive request. The minimum DATACTTIME value is 

15 and the maximum is 720; the default is 120 seconds. 



DCONNTIME Statement 

The DCONNTIME statement specifies the timeout value used when waiting for a 

response to a connection close request on a Data connection. 

►► 

DconnTime 

120 

seconds 

►◄ 

Operands 

seconds 


to a connection close request on a Data connection. The minimum 

DCONNTIME value is 15 and the maximum is 720; the default is 120 seconds. 


INACTTIME Statement 


The INACTTIME statement specifies the timeout value used when attempting to 

establish a data connection to complete FTP subcommand operations. 

►► 

InactTime 

120 

seconds 

►◄ 

Operands 

seconds 

The number of seconds to allow before a timeout when attempting to establish 

a data connection to complete FTP subcommand operations. The minimum 

INACTTIME value is 15 and the maximum is 720; the default is 120 seconds. 



LOADDBCSTABLE Statement 

The LOADDBCSTABLE statement indicates to the FTP client which DBCS translate 

tables should be loaded at initialization time. By using multiple LOADDBCSTABLE 

parms, any number of translate tables may be selected ranging from none to all of 

the DBCS translate tables. 

►► LOADDBCSTABLE EUCKANJI 

HANGEUL 

JIS78KJ 

JIS83KJ 

KSC5601 

SJISKANJI 

TCHINESE 

►◄ 

Operands 

JIS78KJ 

Indicates that the JIS 1978 Kanji DBCS translation table should be loaded from 

the TCPKJBIN binary translate table file. 

JIS83KJ 

Indicates that the JIS 1983 Kanji DBCS translation table should be loaded from 


SJISKANJI 

Indicates that the Shift JIS Kanji DBCS translation table should be loaded from 


EUCKANJI 

Indicates that the Extended Unix Code Kanji DBCS translation table should be 

loaded from the TCPKJBIN binary translate table file. 

HANGEUL 

Indicates that the Hangeul DBCS translation table should be loaded from the 

TCPHGBIN binary translate table file. 

KSC5601 

Indicates that the Korean Standard Code KSC-5601 DBCS translation table 

should be loaded from the TCPHGBIN binary translate table file. 

TCHINESE 

Indicates that the Traditional Chinese (5550) DBCS translation table should be 

loaded from the TCPCHBIN binary translate table file. 

If the LOADDBCSTABLE parameter is not specified, specified incorrectly, or if FTP 

DATA is not accessible, then no DBCS translate tables will be loaded, and the 

corresponding FTP client DBCS transfer types will be unavailable. 

Additional virtual storage may be required by the FTP client if a large number of 

translate tables are loaded concurrently. 

Note: The IBMKANJI transfer type does not require any translate table to be 

loaded. For more information on loading and customizing DBCS translate 

tables, see the TCP/IP Planning and Customization book. 


MYOPENTIME Statement 


The MYOPENTIME statement specifies the timeout value used when attempting to 

establish a connection. 

►► 

MyopenTime 

60 

seconds 

►◄ 

Operands 

seconds 

The number of seconds to allow before a timeout when attempting to establish 

a connection. The minimum MYOPENTIME value is 15 and the maximum is 

720; the default is 60 seconds. 


FTP Subcommands 


The FTP subcommands listed in Table 3 can be used to perform file transfer 

operations between your local z/VM host and a foreign TCP/IP host, once an FTP 

connection (and thus, the FTP subcommand environment) has been established. 

For information about establishing an FTP connection, see “FTP Command” on 

page 16. 

Table 3 provides a summary of all FTP subcommands that can be used with the 

z/VM FTP server and client, and shows the shortest abbreviation, a brief 

description, and a page reference for more information for each subcommand that 

is supported. 

Table 3. FTP Subcommands 

SubcommandMinimum Description 

Abbreviation 

ACCT AC Sends host-dependent 

account information. 

APPEND AP Appends a file on your 

local host to a file on the 

foreign host. 

ASCII AS Sets the transfer type to 

ASCII. 

BINARY B Sets the transfer type to 

IMAGE. 

CD CD Changes the working 

directory. CWD is a 

synonym for CD. 

CDUP CDU Changes the working 

directory to the parent 

directory on the foreign 

host. CD is a synonym for 

CDUP. 

CLOSE CL Disconnects from the 46 

foreign host. 

CMS CM Passes a CMS command. 46 

CWD CW Changes the working 

directory. CD is a 

synonym for CWD. 

42 

DEBUG DEB Toggles internal debug 

options. 

DELETE DELE Deletes a single file on the 

foreign host. 

DELIMIT DELI Displays the delimiter 

character between the file 

name and the file type. 

DIR DI Lists the directory entries 

for files on the foreign 

host. LIST is a synonym 

for DIR. 

EBCDIC EB Sets the transfer type to 

EBCDIC. 

Page 

40 

41 

41 

42 

42 

46 

47 

47 

47 

48 

49 



Table 3. FTP Subcommands (continued) 


Abbreviation 

EUCKANJI EU Sets the transfer type to 

EUCKANJI. 

GET G Copies a file from the 

foreign host to your local 

host. RETRIEVE is a 

synonym for GET. 

HANGEUL HA Sets the transfer type to 

HANGEUL. 

HELP H Displays help information 

for FTP. 

? ? Provides information to 

use FTP. 

IBMKANJI I Sets the transfer type to 

IBMKANJI. 

JIS78KJ JIS7 Sets the transfer type to 

JIS78KJ. 

JIS83KJ JIS8 Sets the transfer type to 

JIS83KJ. 

KSC5601 K Sets the transfer type to 

KSC5601. 

LCD LC Changes the working 

directory on the local host. 

LOCSITE LOCSI Changes local site 

information. 

LOCSTAT LOCST Displays FTP status 

information for the local 

host. 

LPWD LP Displays the name of the 

active working directory 

on the local host. 

LS LS Lists the names of files on 

the foreign host. NLST is a 

synonym for LS. 

MDELETE MD Deletes multiple files on 

the foreign host. 

MGET MG Copies multiple files from 

the foreign host to your 

local host. 

MKDIR MK Creates a new directory on 


MODE MO Specifies the mode or data 

format of the transfer. 

MPUT MP Copies multiple files on 

your local host to the 

foreign host. 

Page 

50 

50 

51 

51 

51 

52 

52 

53 

53 

53 

54 

54 

55 

55 

57 

58 

58 

59 

59 


| 

| 

| 

| 




Abbreviation 

NETRC NE Enables or disables 

automatic logon capability 

through use of a NETRC 

DATA file. 

NOOP NO Checks whether the 

foreign host is still 

responding. 

OPEN O Opens a connection to a 

foreign host. CONNECT is 

a synonym for OPEN. 

PASS PA Supplies a password to the 

foreign host. 

PASSIVE PASSI Controls whether the 

client or server establishes 

connections for data 

transers. 

PUT PU Copies a file on your local 

host to the foreign host. 

PWD PW Displays the name of the 

active working directory 

on the foreign host. 

QUIT QUI Leaves the FTP command 

environment. 

QUOTE QUO Sends an uninterpreted 

string of data. 

RENAME REN Renames a file on the 

foreign host. 

RMDIR RM Remove a directory from 


SENDPORT SENDP Enables or disables 

automatic transmission of 

the FTP server PORT 

subcommand. TOGLPORT 

is a synonym for 

SENDPORT. 

SENDSITE SENDS Enables or disables 

automatic transmission of 

the SITE subcommand. 

SITE SI Sends information to the 

foreign host using 

site-specific commands. 

SIZE SIZE Retrieves the transfer size 

(in bytes) for a foreign 

host file. 

SJISKANJI SJ Sets the transfer type to 

SJISKANJI. 

STATUS STA Displays status 

information for the foreign 

host. 

Page 

60 

60 

61 

62 

62 

63 

64 

65 

65 

65 

66 

67 

67 

68 

70 

70 

71 





Abbreviation 

STRUCT STR Sets the file transfer 

structure. 

SUNIQUE SU Toggles the storage 

methods. 

SYSTEM SY Displays the name of the 

foreign host’s operating 

system. 

TCHINESE TC Sets the transfer type to 73 

TCHINESE. 

TYPE TY Specifies the transfer type. 74 

USER U Identifies you to a foreign 

host. LOGIN is a synonym 

for USER. 

75 

Page 

71 

71 

73 

Continuing Subcommand Input Strings 

Due to system limitations, FTP subcommand input lines are restricted to 130 

characters; subcommand text that is present after 130 characters is ignored. When 

FTP subcommands are supplied, a continuation operator — a plus sign (+) 

preceded by a single blank — can be used to continue a string on a subsequent 

input line. The plus sign and its preceding blank will not be present in the 

resulting final string; thus, any blanks necessary to delimit multiple tokens for 

certain FTP subcommands must be explicitly provided as part of the input string(s) 

that are continued. Delimiting blanks can be included either before the ″ +″ 

continuation operator, or at the beginning of the next line of continued text. Note 

that multiple blanks are not significant (that is, are not preserved). The limit for the 

subcommand input stream continued in this fashion is 200 bytes. 

Example of Line Continuation 

Suppose the current working directory on the foreign host is: 

GPLSRV2:DOC.LIBRARY.PROJECTX 

The following MKDIR subcommand is then issued, using two lines: 

mkdir gplsrv2:doc.library.projectx. + 

worlfiles 

The foreign host replies with: 

>>>MKD gplsrv2:doc.library.projectx.worlfiles 

257 New directory GPLSRV2:DOC.LIBRARY.PROJECTX.WORLFILES has 

been created. 

After creating several other directories, you realize the worlfiles directory should 

be workfiles. To correct this, you issue an RMDIR command of the form: 

rmdir + 

with the remainder of the command completed by retrieving and using previously 

entered commands: 

gplsrv2:doc.library.projectx. + 

worlfiles 

The foreign host replies with: 



>>>RMD gplsrv2:doc.library.projectx.worlfiles 

250 Directory GPLSRV2:DOC.LIBRARY.PROJECTX.WORLFILES has been 

removed. 

You then correct the directory name, again retrieving and using previously entered 

commands (with the last one corrected to workfiles): 

mkdir + 

gplsrv2:doc.library.projectx. + 

workfiles 

The response from the foreign host is then: 

>>>MKD gplsrv2:doc.library.projectx.workfiles 

257 New directory GPLSRV2:DOC.LIBRARY.PROJECTX.WORKFILES has 

been created. 

File Name Formats 

FTP provides a mechanism to transfer files from one host to another, in which 

different operating systems (and thus, file systems) may be in use. Therefore, the 

format used to identify a file is dependent on the host system where that file 

resides or will reside. 

In FTP subcommands used to manipulate files, it is necessary to distinguish files 

associated with the local host from those on a foreign host. In the FTP 

subcommand descriptions throughout this chapter, files that are specific to the 

local host are identified using the term localfile, whereas a file that is specific to a 

remote (foreign) host is identified using the term foreignfile. 

Working with local CMS files 

When CMS files are identified for FTP subcommands that require a local file 

(localfile), use this naming format: 

►► 

filename.filetype 

.* 

.filemode 

►◄ 

Notes: 

1. When a specific file mode is provided for a CMS local file, only the resource 

accessed at that file mode is used to obtain or create the file that has been 

identified. 

2. When a file mode is not specified, or is specified as an asterisk (*) for a CMS 

local file, the resources involved in manipulation of the referenced file may 

vary, based on the FTP subcommand in use. For certain FTP subcommands, a 

file mode specified as an asterisk signifies the local working directory only, 

whereas for others, this may imply use of the local working directory first, 

followed by the current CMS search order. 

Working with Remote Files: When z/VM is in use on the foreign host and a 

foreignfile name is required, use the naming format that follows: 



►► 

(1) 

filename . filetype 

yourid (2) 

filepoolid: . . filename . filetype 

userid . 

▼ subdir 

/ 

(3) 

▼ subdir bfs_filename 

/../VMBFS:filepoolid:filespace/ / 

▼ 

subdir 

(3) 

bfs_filename 

►◄ 

Notes: 

1 Format for minidisk and reader files. 

2 Format for SFS files. 

3 Formats for BFS files. 

To reference minidisk or reader files, the appropriate working directory must be 

established on the foreign VM host. Fully-qualified SFS and BFS foreign files can 

be referenced regardless of whether they reside in the current working directory on 


For more information about CMS file names and limitations, see the z/VM CMS 

Command Reference. For details regarding BFS file-naming conventions, refer to the 

z/VM: OpenExtensions User’s Guide. 

File Name Pattern Matching 

When subcommands are issued that affect multiple CMS files, such as MDELETE, 

MGET, and MPUT, pattern matching can be used to affect the scope of the set of 

files affected by these subcommands (as can be done with the CMS LISTFILE 

command). Pattern matching is accomplished by specifying an asterisk (*) as a 

portion of, or in place of, filename or filetype when a file name is specified for these 

commands. 

Pattern matching can also be used with the name operand that is used in DIR and 

LS subcommands. In addition to the pattern matching just described for filename 

and filetype (when name is specified using the format filename.filetype), the name 

operand itself can be used for pattern matching. Pattern matching based on the 

name operand is accomplished by specifying an asterisk (*) as a portion of, or in 

place of, the name operand. 

Notes: 

1. When the foreign host working directory is a virtual reader, pattern matching 

characters that are used as a portion of the filename, filetype or name operands 

must be specified as a leading or trailing character. An asterisk (*) can still be 

used in place of these operands. 

2. Pattern matching cannot be used for BFS files and directories. 

File Name Case Considerations 

When FTP operations are performed between hosts that are based on differing file 

system implementations, it may be necessary to account for differences that can 

arise due to case sensitive file naming conventions. 



For example, when multiple CMS files are identified for MDELETE, MGET, and 

MPUT operations, the name and type of these files are provided by the z/VM FTP 

server to a connected client in lowercase, whereas for other subcommands (such as 

DIR or LS) these same files may be identified using uppercase names. For 

subcommands that affect only a single file (such as PUT or GET), case is preserved 

for file naming information that is transmitted. 

While these response differences do not adversely affect operations between z/VM 

hosts, they may affect file-related actions performed on a connected host that is 

case-sensitive (with respect to naming conventions and the underlying file system 

implementation of that host). 

Note: For minidisks and SFS directories, CMS files are created with names in 

uppercase. FTP on z/VM does not support mixed-case file naming for these 

resources. 

Working with Non-CMS Files 

For detailed information about naming and referencing files on a non-z/VM host, 

consult the documentation specific to that host and its operating system. The 

information provided in Appendix A, “Specifying Files and Data Sets” on page 289 

may be useful as well. 

In general, the z/VM FTP client does not restrict the naming of a foreignfile when 

such information is supplied to the FTP server on a foreign host. For example, the 

slash (/) often used in naming Unix files can be used when these files are 

referenced, even though this is not a valid CMS file name character. However, 

length restrictions may at times be encountered, due to implementation 

considerations. 

Information about how certain naming conditions and problems are dealt with by 

FTP on a z/VM host follows. 

Many commonly-referenced file systems (Unix is one example) maintain files using 

a descriptive file name only, and have no underlying support for a file type, as does 

CMS. When these files are transferred to a z/VM host, and the existing foreign file 

name cannot be used to adequately produce a CMS file name and file type, that 

file is stored on CMS minidisks and SFS directories using a CMS file type of 

$DEFAULT. 

For some files, due to their naming, a specific CMS file name or file type must be 

provided when those files are retrieved from a foreign host. For example, to 

retrieve a foreignfile that begins with a period (.), the foreignfile specified with the 

GET subcommand must include an explicit filename. To retrieve a group of such 

files using an MGET subcommand, use an asterisk (*) as the foreignfile file name. 

Quoted Strings and Embedded Spaces (Blanks) 

When the need arises to specify an FTP subcommand that includes a foreign file or 

directory name that requires spacing, that name should be enclosed using either 

single (’) or double (″) quotes. 

When the z/VM FTP client encounters a subcommand operand string that is 

enclosed within quotes and that string contains embedded spaces, it discards the 

delimiting quotes before the string is passed to the FTP server on the foreign host. 



If quotes are encountered that enclose a subcommand string which does not 

contain embedded blanks, the z/VM FTP client assumes the supplied quotes are 

inherent to this string. Thus, the delimiting quotes are retained, and are passed on 

to the FTP server on the foreign host. 

Fully-Qualified Pathnames 

For certain FTP subcommands, the z/VM FTP server allows a fully-qualified 

pathname. 

For example, assume the SFS directory FPSERV1:TSTUSER.TESTCASES is the 

working directory, but that information about all TEST007 files that reside in the 

FPSERV1:TSTUSER.TESTDATA directory needs to be obtained at a given time. This 

information can be obtained using the DIR command that follows: 

dir fpserv1:tstuser.testdata.test007.* 

If these files reside on the NOTSECUR 191 minidisk (for which a read password of 

ALL is in effect), this information would be retrieved using this command: 

dir notsecur.191/test007.* 

A fully-qualified pathname can be specified for these FTP subcommands: 

v APPEND (APPE) 

v DELETE (DELE) 

v DIR (LIST) 

v LS (NLST) 

v GET, MGET (RETR) 

v SIZE (SIZE) 

v PUT, MPUT (STOR) 

v PUT, MPUT with SUNIQUE active (STOU) 

Note: When fully-qualified path names are used with FTP subcommands, the FTP 

server temporarily acquires the appropriate z/VM file system resource 

necessary to satisfy a request. This action by the FTP server does not alter 

the working directory that has been established through use of either the 

CD or CWD commands. 

Storage Space Requirements for Transferred Files 

The information that follows must be considered when files are stored on a z/VM 

host, especially when minidisk or SFS storage space is constrained, or when 

attempts are made to minimize the use of such space. 

As part of necessary overhead required by the FTP server and by CMS for 

performing file system management, a number of storage blocks must be reserved 

and used for other than data storage purposes. For instance, some blocks are used 

as control blocks to maintatin the minidisk file directory (for which additional 

block space may be required as new files are created), while others are used as 

pointer blocks to manage file structure. 

However, these various reserved blocks are not reflected in the output returned for 

the CMS QUERY DISK or QUERY LIMITS commands. This means the results 

obtained from these commands must be used only as an approximation of storage 

block usage and availability when determining whether a file can be stored on a 

z/VM host. 



File Transfer Methods 

When files are transferred between two hosts, appropriate transmission attributes 

must be used to ensure the content and structure of any transferred file are 

preserved. The nature of a file transfer is primarily controlled using two FTP 

subcommands: 

v 

v 

the MODE subcommand, which determines how the file contents are 

transmitted. For more information, see “MODE” on page 59. 

the TYPE subcommand, which establishes attributes of the file contents. For 

more information, see “TYPE” on page 74. 

Controlling File Translation 

Because z/VM maintains data in EBCDIC format, it is often necessary to be aware 

of and have control over how EBCDIC-ASCII file translation is performed when 

files are transferred to or from a remote host. 

Table 4 shows recommendations for setting transmission attributes for file transfers 

that are performed between differing host systems. In this table, IBM host systems 

(VSE/ESA, z/VM or OS/390 hosts) are referred to as “EBCDIC” hosts. By 

comparison, a Unix, Windows, or Linux host is considered to be an “ASCII” host. 

With respect to EBCDIC hosts, text data is considered to be comprised of only 

standard, displayable characters, whereas for an ASCII host, text data generally 

contains the carriage return (ASCII X'0D' and EBCDIC X'15'), the line feed (ASCII 

X'0A' and EBCDIC X'25') and displayable characters. 

Table 4. Recommended Methods of File Transfer 

Source 

Host 

Intermediate 

Host 

Target Host Data TYPE Setting Mode 

Setting 

EBCDIC (none) EBCDIC binary E (EBCDIC) B (Block) 

EBCDIC (none) EBCDIC text E (EBCDIC) S (Stream) 

EBCDIC (none) ASCII text A (ASCII) S (Stream) 

ASCII (none) EBCDIC text A (ASCII) S (Stream) 

ASCII (none) EBCDIC binary I (Image) (1*) S (Stream) 

ASCII EBCDIC (2*) ASCII binary I (Image) (1*) S (Stream) 

EBCDIC ASCII (2*) EBCDIC (3*) binary I (Image) (1*) S (Stream) 

1. The BINARY subcommand can be used to set the transfer type to Image. 

2. Used only for storage purposes. 

3. See accompanying notes for more information. 

Notes: 

1. When files are transferred between IBM EBCDIC host systems, the combined 

use of the MODE B and TYPE E subcommands is generally sufficient to 

achieve satisfactory results. 

2. When a CMS file such as a MODULE, (which has an internal format which 

must be preserved) is transferred using an intermediate ASCII host, that file 

should first be compressed using the PACK option of the CMS COPYFILE 

command. This “packed” file should then be handled as a binary file until it is 

transferred to its final destination. For the z/VM destination host, a SITE (or 

LOCSITE) FIXRECFM 1024 subcommand must be issued prior to the PUT (or 

GET) subcommand used to transfer the file — this is necessary to create a file 

that can then be uncompressed using the UNPACK option of the CMS 

COPYFILE command. 


Automatic File Translation 

The z/VM FTP server can be configured by the system administrator to 

automatically perform EBCDIC-ASCII file translation based on the value of a file 

extension, which is defined to be the last component of a file name — that is, the 

characters that follow the last period in a path name. For file extensions, up to 

eight characters are matched and mixed case is not respected. 

Automatic file translation, when enabled, is applicable to only the Image (TYPE I) 

file transfer type. Thus, if the transfer type is changed to other than Image — for 

example, ASCII — during a session for which automatic file translation is active, 

automatic translation ceases and files are transferred in accordance with the newly 

established transfer type. In such a case, automatic file translation can be reinstated 

by changing back to the Image transfer type. 

Automatic file translation is recommended when a web browser or graphical FTP 

client is used to interact with a z/VM FTP server, because these clients often 

default to using a transfer type of Image (or, binary) and do not offer a way for a 

different file transfer type to be specified. 

The associations between file extensions and file translation are configured by the 

z/VM system administrator, as is the initial automatic file translation setting for an 

FTP session. While file extension associations cannot be changed by an FTP client, 

whether automatic file translation is performed by the server can be controlled by 

using the AUTOTRANS operand of the SITE subcommand. For more information, 

see “SITE” on page 68. 

File List Formats 

After an FTP connection has been established with a z/VM foreign host, the FTP 

server can be instructed to provide DIR subcommand responses (file lists) inone 

of two different list formats: 

v 

v 

VM-format (VM), or 

Unix-format (UNIX), sometimes referred to as Unix long-list format. 

These formats are described in more detail in the following sections. 

VM-format Lists 

The VM-format list response provides file information in a format that — for the 

minidisk and Shared File System (SFS) directory file groups — closely resembles 

that produced by the CMS LISTFILE command. A sample VM-format list response 

follows: 

Command: 

dir 

>>>PORT 9,117,32,30,4,53 

200 Port request OK. 

>>>LIST 

125 List started OK 

ENDTRACE TCPIP F 80 1 1 1999-07-28 12:24:01 TCM191 

LASTING GLOBALV V 43 10 1 1999-11-16 9:05:22 TCM191 

NOTRACE TCPIP F 80 1 1 1999-12-16 13:39:21 TCM191 

OBEY EXEC V 72 153 2 1996-01-03 16:07:07 TCM191 

PACKMODL TESTFILE F 1024 468 117 1996-07-28 13:56:36 TCM191 

PROFILE EXEC V 30 10 1 1999-11-16 9:01:10 TCM191 

RECF80 TESTFILE F 80 5 1 2000-01-17 14:47:19 TCM191 

SETX XEDIT V 46 13 1 1999-11-04 9:13:53 TCM191 

TCPIP DATA V 72 99 2 1999-11-18 17:24:05 TCM191 

TCPMNT2 NETLOG V 108 48 2 2000-01-17 14:49:09 TCM191 

TCPMNT2 SYNONYM F 80 10 1 1999-11-10 8:46:12 TCM191 

TCPSLVL EXEC V 37 23 1 1999-02-05 13:20:46 TCM191 




TEST EXEC V 71 107 2 1997-07-14 10:43:17 TCM191 

TRACE2 TCPIP F 80 1 1 1999-12-30 11:15:22 TCM191 

250 List completed successfully. 

Command: 

For files and directories that are maintained using the z/VM Byte File System 

(BFS), VM-format lists are identical to z/VM OPENVM LISTFILE responses. A 

sample response for BFS directory information follows: 

Command: 

dir 

>>>PORT 9,117,32,30,4,53 


>>>LIST 


05/20/2000 13:38:19 F 1 65758 ’bfsline.cpy’ 

05/19/2000 11:02:15 F 1 65758 ’bfsline.txt’ 

06/03/2000 12:27:48 F 1 15414 ’bfstest.cpy’ 

05/20/2000 13:38:05 F 1 15414 ’bfstest.output’ 

05/20/2000 13:38:42 F 1 772902 ’bfswork.output’ 

03/31/2000 15:49:27 F 1 782444 ’bfswork.txt’ 

05/20/2000 13:39:20 F 1 13930 ’lotsonl.putdata’ 

05/19/2000 09:41:21 F 1 13930 ’lotsonl.txt’ 

06/15/2000 09:29:25 F 1 278 ’mail.maw’ 

05/20/2000 13:39:34 F 1 278 ’mail.putdata’ 

05/20/2000 15:30:45 F 1 13930 ’nls.new’ 

05/20/2000 14:02:24 F 1 13931 ’nls.txt’ 

08/21/2000 10:03:17 F 1 328 ’rock.rules’ 

05/20/2000 13:40:05 F 1 58 ’testfil2.putdata’ 

04/26/2000 14:34:42 F 1 63 ’testfil2.txt’ 

08/21/2000 05:28:40 D - - ’ALTERNATE’ 

12/28/2000 17:36:19 D - - ’FIRST’ 


Command: 

For a z/VM virtual reader (RDR), list responses are similar to that produced by 

the CP QUERY RDR ALL command, but with certain fields removed. A sample 

VM-format response for a virtual reader follows: 

Command: 

dir 

>>>PORT 9,117,32,29,10,213 


>>>LIST 


0013 SMTP 00000011 1999-11-03 12:46:10 CIBULAPR MAIL 

0154 RSCS 00002789 1999-12-29 10:12:46 FL3XSAMP TXT 

0116 TCPLVL2 00000170 1999-12-16 11:39:07 TCP-HELP LIST3820 

0115 TCPLVL2 00002874 1999-12-16 11:39:06 TCP-OVER LIST3820 

0153 RSCS 00002825 1999-06-29 10:12:45 FL32SAMP TXT 

0214 SMTP 00000015 2000-01-14 12:50:10 CIBULAMA MAIL 


Command: 

The fields in this type of response are referred to (in order) as the spoolid, origin, 

records, date, time, filename and filetype fields. 

Unix-format Lists 

When a web browser, or other graphical FTP client is used to interact with a z/VM 

FTP server, the use of Unix-format lists is recommended. This is because these 

types of clients have, in general, been implemented to work with a Unix file 

system model and expect Unix-like information to be presented as FTP transactions 

are performed. If VM-format file lists are supplied when such a client is used, 



directory and file information may not be correctly displayed or managed by the 

client; this may then cause FTP processing capabilities to become limited or 

adversely affected. 

The list format initially supplied by an FTP server is configured by the z/VM 

system administrator. However, the list format used during an FTP session can be 

controlled by using the LISTFORMAT operand of the SITE subcommand. For 

more information on the SITE subcommand, see “SITE” on page 68. 

Unix-format List Fields 

Unix-format responses returned by a z/VM FTP server contain the following 

fields, with each separated by one or more spaces: 

mode 

link count 

owner 

group 

size 

date 

time 

name 

a one byte entry type followed by three bytes each of Owner, 

Group, and Other permissions 

a count of the number of symbolic links to a file 

the login or user name that owns a file or directory 

the group name with which permissions are associated 

the size (in bytes) of a file or directory 

date of last modification (month and day, provided in the form 

mmm nn) 

time of last modification, provided in the form hh:mm (for files 

greater than six months old, hh:mm is replaced with the year in 

which the file was last modified, provided as nnnn) 

the name of a file or directory 

An example Unix-format response follows: 

dir 

>>>PORT 129,34,128,246,13,134 

200 Port request OK 

>>>LIST 


-rwx---r-x 1 MIKE TCPIPDEV 240 Mar 18 16:13 LASTING.GLOBALV 

-rwx---r-x 1 MIKE TCPIPDEV 3192 Dec 8 1991 PROFILE.EXEC 

-rwx---r-x 1 MIKE TCPIPDEV 3 Feb 4 14:57 TELL.LOCK 

-rwx---r-x 1 MIKE TCPIPDEV 432 Mar 17 10:30 TEST.EXEC 

-rwx---r-x 1 MIKE TCPIPDEV 80 Mar 17 8:57 TEST.TEST 

-rwx---r-x 1 MIKE TCPIPDEV 432 Mar 18 10:28 TEST1.EXEC 

-rwx---r-x 1 MIKE TCPIPDEV 10640 Mar 18 13:28 TEST1.INFO 

-rwx---r-x 1 MIKE TCPIPDEV 80 Mar 8 17:37 TET.TET 

-rwx---r-x 1 MIKE TCPIPDEV 80 Mar 8 17:48 TET1.TET 

-rwx---r-x 1 MIKE TCPIPDEV 80 Mar 8 17:49 TET2.TET 

-rwx---r-x 1 MIKE TCPIPDEV 10640 Feb 26 16:36 T1.INFO 

250 List completed successfully 

Command: 

Here is a sample Unix-format response for a virtual reader: 

Command: 

dir 

>>>PORT 9,117,32,29,10,213 


>>>LIST 


-rwx---rwx 1 MIKE - 0 Nov 3 12:46 0013.CIBULAPR.MAIL 

-rwx---rwx 1 MIKE - 0 Dec 29 10:12 0154.FL3XSAMP.TXT 

-rwx---rwx 1 MIKE - 0 Dec 16 11:39 0116.TCP-HELP.LIST3820 

-rwx---rwx 1 MIKE - 0 Dec 16 11:39 0115.TCP-OVER.LIST3820 



-rwx---rwx 1 MIKE - 0 Jun 29 1999 0153.FL32SAMP.TXT 

-rwx---rwx 1 MIKE - 0 Jan 1 12:50 0214.CIBULAMA.MAIL 


Command: 

Since the z/VM Byte File System (BFS) is based on a Unix file system model, all 

fields of the Unix-format file list are applicable and available when BFS files and 

directories are listed in response to a DIR subcommand. 

When a Unix-format response is returned for z/VM-specific file system groups — 

minidisks, SFS directories, or virtual readers (RDR) — some of the information 

associated with this format is not pertinent to these file system groups. Thus, the 

FTP server substitutes or modifies values for certain Unix-format fields when its 

response corresponds to one of these file system groups; this is done to allow for 

correct processing of the response by web browser and graphical FTP clients. 

Modifications to Unix-format field values for non-BFS files and directories are 

applied by the z/VM FTP server as follows: 

v An entry type of d is supplied if the response entry is associated with an SFS 

directory; otherwise, a hyphen (-) is present. 

v For SFS and minidisk, owner permissions are always rwx, but for RDR files, 

owner permissions are always hyphens (---). 

v Group permissions are supplied as hyphens (---). 

v Other permission bits will indicate the authority of the current user. Execute 

authority (x) is assumed if the login user has read authority for the file in use. 

For resources protected by an External Security Manager (ESM), Other 

permissions are always provided as rwx. Exact file authorizations for these 

resources may be determined by using the QAUTH operand of the “SITE” 

subcommand, see “SITE” on page 68. 

v A link count of 1 is always provided. 

v If the file owner is a member of an Access Control Interface group (ACIGROUP), 

that ACIGROUP name is supplied in the group field. If an ACIGROUP is not 

available, the group name is supplied as a hyphen (-). For more ACIGROUP 

information, see z/VM Planning and Administration. 

v For fixed-record (F) format minidisk and SFS files, the size field indicates the 

actual size of a file. 

For variable-record (V) format minidisk and SFS files, the size field contains an 

estimated file size, this being the lesser value determined by: 

– the number of records in the file and its maximum record length 

– the size and number of blocks required to maintain the file. 

v 

For virtual reader files, a size of 0 is always indicated. 

For a virtual reader, the spool ID precedes the file name and file type; thus, for 

these resources, this field is formatted as: spoolid.filename.filetype 

Interpretation of Relative Path Information 

When a z/VM FTP server processes a request to manipulate a file, for which the 

file or directory has not been fully qualified, the server determines where that file 

or directory exists by appending any supplied file or directory information to an 

internal base directory. Exactly what constitutes this base directory differs based on 

the file list format that is in effect for an FTP session. 

When the list format is VM, the z/VM FTP server uses the working directory (as 

established by either a CD or CWD subcommand) as the base directory for the 


supplied, but not fully qualified, file or directory name. That is, the FTP server 

determines where the file or directory exists by appending the supplied directory 

or file information to the current working directory. 

For example, assume the current list format is VM and the current working 

directory is /../VMBFS:BFS:USER1/SUBDIR. If a GET SUBDIR2/THIS.FILE 

command is supplied by a client, the FTP server will add the supplied path 

information to that associated with the current working directory in order to obtain 

a fully qualified file name. For this example, the fully qualified file for which data 

will be returned is /../VMBFS:BFS:USER1/SUBDIR/SUBDIR2/THIS.FILE. 

By comparison, when the UNIX list format is in effect, the z/VM FTP server uses 

only a portion of the current working directory - either the root directory, or the 

lowest level directory possible - as its base for any file or directory information 

supplied by a client. 

That is, the FTP server determines where a file or directory exists by adding 

client-supplied directory or file information to the root directory of the current 

working directory. The z/VM FTP server does this in order to operate effectively 

with web browser clients, because these clients always provide directory and file 

information in a manner that is relative to the root directory. 

Thus, when Unix-format lists are in use, the root directory for BFS is 

/../VMBFS:FILEPOOL:USER/, while FILEPOOL:USER. is used for SFS. For 

minidisk and reader directories, the root directory is the minidisk or reader 

directory. 

For example, assume the current list format is UNIX and the current working 

directory is /../VMBFS:BFS:USER1/SUBDIR. If a client requests file data via a GET 

SUBDIR2/THIS.FILE command, the FTP server will construct and use a fully 

qualified relative path name, based on the client-supplied path information and the 

appropriate root directory for the file system in use (/../VMBFS:BFS:USER1 in this 

case). For this example, data will be returned for the file 

/../VMBFS:BFS:USER1/SUBDIR2/THIS.FILE. 

Transferring Files Using a Web Browser 

To FTP to a z/VM host using a web browser, use the following FTP address or 

location format: 

ftp://userid:password@host.domain/directory 


If a password is not specified as part of the location information you supply (but is 

required to gain access to the host in question) a password prompt will be issued. 

If a directory is not specified as part of the location information, the web browser 

informs the z/VM FTP server to begin at the root directory that is associated with 

the userid default working directory. If the user ID in question (userid) does not 

have authorization for the root directory, either proper authorization must be 

obtained or a suitable directory must be specified as part of the FTP location 

address (that is, a directory for which access authorization exists). 

Also, be aware that the following sequence of events may produce unexpected 

results when a web browser FTP client is used in conjunction with a z/VM FTP 

server: 



1. FTP operations commence with a root directory that corresponds to a specific 

type of z/VM file system (BFS, SFS, minidisk, reader) for which no specific 

directory has been specified as part of the FTP address or location. 

2. The type of z/VM file system used is overtly changed, by having specified a 

fully-qualified directory in the FTP address or location. 

3. A browser operation is performed that requires use of the root directory (and 

z/VM file system) that was originally established in Step 1, such as backward 

paging that initiates a file retrieval, store, or delete request. 

Problems may arise after such a sequence of events because web browser 

implementations generally expect to operate with only one type of file system for a 

given user FTP session; the browsers do not expect the root directory to change for 

the life of an FTP session. Given this, a browser will not likely send a change 

directory (CD or CWD) request prior to an operation that requires a z/VM file 

system type that differs from that currently in use. Because the z/VM FTP server 

employs a different root directory for each type of z/VM file system in use, its 

responses may differ from those expected by the browser. 

Under these (and similar) circumstances, unexpected results may be a consequence 

of discrepancies between the z/VM FTP server and the browser in use, with 

respect to conventions that concern how files should be referenced using path and 

directory information, as well as perception as to what constitutes a “working 

directory”. 

ACCT 

Before you can access files on a foreign host, some hosts require account 

information. Use the ACCT subcommand to send host-dependent account 

information. 

►► ACct account_information ►◄ 

Operands 

Usage Notes 

account_information 

Specifies the account information required by the foreign host. 

v 

v 

Some TCP/IP systems require passwords to gain access to specific resources or 

for a specific kind of access, such as “read” or “write”. For such systems, you 

can use the ACCT subcommand to supply such passwords. 

If the foreign host is a VM system, the ACCT subcommand can be used to 

supply minidisk passwords. The password you supply is used by the VM FTP 

server when CP LINK commands are issued on your behalf. 

When access to a VM minidisk is requested and a LINK password is required, 

the FTP server attempts LINK commands in the following order: 

1. MR (Multiple Read) mode 

2. WR (Read/Write) mode 

3. RR (Read only) mode. 



The level of access provided is determined by the first LINK attempt that 

succeeds. Thus, the minidisk password you supply as the account_information 

parameter should provide a minidisk LINK corresponding to the highest level of 

access you desire. For many systems, a Multiple Read password is most 

appropriate. 

For more information about the CP LINK command, see the IBM z/VM: CP 

Command and Utility Reference. 

APPEND 

Use the APPEND subcommand to append a local file to a foreign file. 

►► APpend localfile foreignfile ►◄ 

Operands 

Usage Notes 

localfile 

The name of the local file to be appended to a file that resides on a foreign 

host. For information about how to specify localfile see “File Name Formats” on 

page 30. 

foreignfile 

The foreign host file to which the local file is to be appended. If a foreign file 

of this name does not already exist, the file is created. For information about 

how to specify foreignfile see “File Name Formats” on page 30. 

v 

v 

To append to a file on the foreign host, you must have a defined working 

directory, and you must have write privileges to it. For more information, see 

the subcommands “ACCT” on page 40 and “CD or CWD” on page 42. 

When the foreign file has a fixed-record format, the file format and record length 

of the foreign file are always preserved. Records from the local file can be 

truncated or padded with blanks when necessary. 

ASCII 

Use the ASCII subcommand to change the transfer type to ASCII, and at the same 

time change the record format used to store local files. 

►► AScii ►◄ 

Operands 

The ASCII subcommand has no parameters. 

Usage Notes 

v 

The ASCII subcommand is intended for use when text files are transferred to or 

from an ASCII host. When FTP sessions are established, ASCII is the default 

transfer type. 



Note: The ASCII subcommand causes files transferred to the local host to be 

stored as variable-record (V) format files. 

For more information about file transfer methods, see Table 4 on page 34. 

BINARY 

Use the BINARY subcommand to change the file transfer type to Image. 

►► 

BINARY 

Variable 

Fixed record_length 

►◄ 

Operands 

Usage Notes 

Variable 

Specifies that files are stored as variable-record (V) format files. 

Fixed record_length 

Specifies that files are stored as fixed-record format (F), with records of length 

record_length. 

v 

v 

To specify how a binary file is stored on the local host, use the BINARY 

subcommand with the VARIABLE or FIXED operand before a GET (or MGET) 

subcommand is issued to retrieve a file. Note that when the BINARY 

subcommand is used in this manner, this has the same effect as issuing separate 

TYPE IMAGE and LOCSITE subcommands. 

For a z/VM foreign host where the FTP server has been configured to perform 

automatic file translation, the BINARY subcommand has no effect on file 

translation — the server continues to determine whether EBCDIC-ASCII 

translation should occur based only on file extension. However, the VARIABLE 

and FIXED operands still affect how a transferred file is stored on the local VM 

system. 

To enable or disable automatic file translation for files transferred using the 

Image transfer type, use the AUTOTRANS operand of the SITE subcommand. 

For information, see “SITE” on page 68. 

CD or CWD 

Use the CD or CWD subcommand to change the working directory or file group 




►► 

CD 

CWD 

191 

userid 

. vaddr 

RDR 

child-subdir 

yourid 

filepoolid: . 

userid . 

►◄ 

▼ subdir 

.. 

directory 

/../VMBFS:filepoolid:filespace/ 

▼ 

/ 

subdir 

Operands 

userid 

The user ID associated with the resource that is to be accessed. 

vaddr 

A minidisk virtual address. The default virtual address is 191. 

RDR 

Indicates the virtual reader associated with userid is to be accessed. 

child-subdir 

A subdirectory that is defined under the current working directory. 

filepoolid 

The name of the Shared File System (SFS) file pool in which the directory to be 

accessed is defined. 

userid 

The user ID that owns the SFS directory that is to be accessed. If not specified, 

the user ID that corresponds to the currently active login user name (as 

specified with the USER subcommand) is used — signified here as yourid. 

subdir 

The name of a subdirectory that is defined under the top-level directory 

defined by filepoolid:userid. 

.. A special operand that changes the working directory to the parent directory 

on the foreign host. This operand performs the same function as the CDUP 

subcommand. 

directory 

The name of a file directory or other system-dependent file group designator 


/../VMBFS:filepoolid:filespace/ 

The name of the Byte File System (BFS) root. The VMBFS, filepoolid, and 

filespace tokens are all required and must be specified in uppercase. 



Examples 

CD COOK.191 

where 191 is the default minidisk address. 

cd server5:.os2tools 

where OS2TOOLS is the SFS directory within the client’s filespace in file pool 

SERVER5. 

cd /../VMBFS:SERVER5:ROOT/user/alan 

Usage Notes 

where user/alan is the directory within file space ROOT of file pool SERVER5. 

v 

v 

v 

v 

You can also use the CWD subcommand to change the current working 

directory. This subcommand is interchangeable with the CD subcommand. 

While in the FTP environment, you can issue a CD command to specify a 

subdirectory or fully-qualified directory name for access to SFS and BFS. 

To work with SFS directories, TCP/IP V2R3 for VM or later must be in use on 

the foreign host. To work with BFS directories, TCP/IP V2R4 or later must be in 

use on the foreign host. To work with VM readers, TCP/IP FL320 or later must 

be in use on the foreign host. 

When CD commands are used with a remote host running z/VM your use of 

SFS, BFS and virtual reader support can affect how the directory names you 

supply are used. When support for these resources is available, the VM FTP 

server will interpret the directory names you supply using the following 

precedence: 

1. If the current working directory is a BFS directory, the supplied directory 

name is treated as a BFS path name. 

2. If the string “/../VMBFS:” is present, the directory name is treated as a BFS 

path name. 

3. If the current working directory is an SFS directory, the supplied directory 

name is treated as an SFS directory name. 

4. If a colon (:) is present in the directory name, it is treated as an SFS directory 

name. 

5. If the supplied directory name ends with either “ RDR” or“.RDR”, an attempt 

is made to change the working directory to a virtual reader. 

6. If the previously listed attempts fail to result in a successful change of 

directory, an attempt will be made to acquire a minidisk. 

Note: Certain SFS subdirectory and BFS path names can present problems when 

it is necessary to alternate the use of SFS/BFS resources and minidisks or 

virtual readers as working directories. When SFS subdirectories or BFS 

path names exist with names that also conform to the “userid.vaddr” or 

“userid.RDR” directory format, that SFS or BFS resource may be obtained 

as a working directory instead of an intended userid minidisk or virtual 

reader. Whether this can occur is dependent upon the SFS or BFS 

directory hierarchy being referenced, as well as the SFS/BFS directory that 

is the current working directory. 



v 

v 

v 

For such an environment, to ensure a change to a minidisk occurs when 

desired, always specify a minidisk or virtual reader directory by using 

either the “userid vaddr” or“userid RDR” directory name format, with only 

spaces or blanks used as delimiters. 

The following restrictions apply to BFS files and directories: 

1. When a CD request is for a Byte File System (BFS) directory, only the VM 

user's primary GID (from the POSIXINFO statement) is used by the FTP 

server. The user's supplementary GID list (from the POSIXGLIST statement) 

is not used. 

2. When the user ID issuing a CD command has file pool administration 

authority for the target BFS file pool, that administration authority is not 

respected by the FTP server. In other words, the user ID must have explicit 

permission to the object through the UID and GID associated with the user 

ID. 

The initial working directory you obtain after you logon to a foreign host is 

dependent upon that host system. For z/VM hosts, the initial working directory 

established, as well as the type of access to that directory (with regard to “read” 

versus “write” status), can be affected by several factors, such as: 

– the logon user ID you supply 

– the configuration of the FTP server 

– the use of an External Security Manager (ESM) 

– the release of TCP/IP for VM in use on foreign host. 

In many environments, the 191 minidisk of the login user ID is established as 

the initial working directory, by default. When possible, write access to this 

resource is obtained. However, these defaults can be influenced and altered by 

one, or a combination, of the previously cited factors. 

If TCP/IP Function Level 320 or later is in use on the foreign host and native 

VM minidisk password protection is in use, access to minidisks will be achieved 

without the need to specify a minidisk password, when one of the following 

conditions is true: 

– the login user ID owns the target minidisk 

– a minidisk read, write, or multiple password of ALL is in effect for the 

minidisk 

For these conditions, write access will be obtained, whenever possible. If none of 

these conditions is applicable for this kind of environment, the ACCT 

subcommand must be used to provide a suitable minidisk password to gain 

access to the minidisk. 

v 

For this same type of environment, but with a level of VM TCP/IP prior to 

Function Level 320 in use, minidisk access without the need for a minidisk 

password will be achieved only when a minidisk read, write, or multiple 

password of “ALL” is in effect for a minidisk. Otherwise, minidisk access will 

only be provided when you use the ACCT subcommand to provide a suitable 

minidisk password. 

You can specify the *dev.null directory for testing throughput. If *dev.null is 

specified, the PUT and MPUT subcommands transfer data to the foreign host, 

but do not store the data at the foreign host. The GET and MGET subcommands 

use the working directory that was in effect before the CD *dev.null command. 



CDUP 

Use the CDUP subcommand to change the working directory to the parent 

directory on the foreign host. The CDUP command is a special case of the CD 

command. It is included to simplify the implementation of programs for 

transferring files between operating systems that use differing directory naming 

conventions. The reply codes are identical to the reply codes for the CD command. 

CDUP works for only one level at a time and is executed only if the current 

directory is an SFS or a BFS directory. 

Note: You can also use the “..” operand of the CD subcommand to change the 

working directory to the parent directory. 

►► CDUp ►◄ 

Operands 

The CDUP subcommand has no parameters. 

CLOSE 

Use the CLOSE subcommand to disconnect from the foreign host. 

►► CLose ►◄ 

Operands 

The CLOSE subcommand has no parameters. 

Usage Notes 

v 

CLOSE does not end FTP processing, therefore you can use the OPEN 

subcommand to establish a new session. 

CMS 

Use the CMS subcommand to pass a CP or CMS command to the local z/VM 

system. 

►► CMs command ►◄ 

Operands 

Usage Notes 

command 

Specifies a CMS or CP command. 

v 

The CMS subcommand can be used to perform regular VM CMS functions such 

as checking your file list. 



DEBUG 

Use the DEBUG subcommand to enable or disable the internal debugging option. 

►► DEBug ►◄ 

Operands 

The DEBUG subcommand has no parameters. 

Usage Notes 

v 

v 

DEBUG acts as a toggle that turns the debugging option on or off. The DEBUG 

subcommand is ON, initially, if the TRACE parameter was specified on the FTP 

command. The DEBUG subcommand is OFF if the TRACE parameter was not 

specified. 

The DEBUG subcommand is intended to aid in problem diagnosis. When 

DEBUG is ON, FTP displays tracing information, in addition to the commands 

sent to the foreign host and the responses received from that host. 

DELETE 

Use the DELETE subcommand to delete a file specified in the path name at the 

foreign host. 

►► DELEte foreignfile 

spoolid . filename . filetype 

►◄ 

Operands 

foreignfile 

The foreign host file to be deleted. For information about how to specify 

foreignfile see “File Name Formats” on page 30. 

spoolid 

The system-assigned number of the spool file to be deleted; spoolid is valid 

only when the working directory on the foreign host is a z/VM virtual reader 

(RDR). When a spoolid is specified, the filename and filetype associated with that 

spool file can optionally be included, though these values are not used by the 

FTP server. 

DELIMIT 

Use the DELIMIT subcommand to display the character that is used as the 

delimiter between the filename and the filetype. 

►► DELImit ►◄ 



Operands 

The DELIMIT subcommand has no parameters and should be used for 

informational purposes only. 

Examples 

v 

Response displayed after invoking the DELIMIT subcommand: 

File delimiter is ’.’ 

Command: 

DIR 

Use the DIR subcommand to get a list of directory entries or a list of files in a file 

group on the foreign host. 

►► 

DIr 

name 

. 

.. 

(─DISK 

►◄ 

Operands 

Usage Notes 

name 

The name of the directory or file group on the foreign host for which files 

should be listed. If name is omitted, all directory entries or files for the current 

working directory or file group are listed. For information about how to 

specify name, see the “Usage Notes” for this subcommand and “File Name 

Formats” on page 30. 

To select which directory or file group is current, use the CD subcommand; for 

more information about this subcommand, see “CD or CWD” on page 42. 

. Specifies that list information should be returned for the current working 

directory. For z/VM hosts, this operand is recognized in this manner only 

when SFS or BFS directories are referenced. For other z/VM resources, 

responses are returned as if no operand had been specified. 

.. Specifies that list information should be returned for the parent directory of the 

current working directory. For z/VM hosts, this operand is recognized in this 

manner only when SFS or BFS directories are referenced. For other z/VM 

resources, responses are returned as if no operand had been specified. 

DISK 

Stores the results of the DIR subcommand in file FTP DIROUTP, on the current 

local working directory. DIR subcommand results are not displayed when this 

operand is used. 

v 

For z/VM hosts that support list format selection, the response to the DIR 

subcommand can differ, based on the list format that is specified for the current 

session. If a list format of UNIX is specified, the server responds with a 

Unix-format list; otherwise, the response is a VM-format (VM) list. 

For more information about VM-format and Unix-format responses to the DIR 

subcommand, see “File List Formats” on page 23. 



v 

v 

v 

v 

v 

For more information about controlling the type of list format used for an FTP 

session, see the description of the “SITE” subcommand, refer to “SITE” on 

page 68. 

The DIR subcommand provides a complete list of directory and file entries that 

includes auxiliary information about those entries. To get a list that contains only 

the names of files present in the directory, use the LS subcommand. For more 

information, see “LS” on page 55. 

If the DIR subcommand is issued for a BFS directory that contains other than 

regular BFS files, a vm; foreign host may return an error response that indicates 

a BFS directory error has occurred. 

For z/VM foreign hosts, pattern matching can be used to specify a subset of files 

about which information is returned. For more information, see “File Name 

Pattern Matching” on page 31. 

z/VM hosts do not support pattern matching for BFS files and directories. 

If the working directory on the foreign host is a z/VM virtual reader (RDR) and 

VM-format lists are in use, pattern matching using the name operand is possible. 

When used, matching is performed against all reader-specific fields in unison 

(that is, data is returned for a reader file when a match is found for any field). 

Examples 

v 

v 

A sample VM-format (VM) list response for a minidisk working directory 

follows: 

dir 

>>>PORT 129,34,128,246,13,134 


>>>LIST 


ALTTEST EXEC V 36 12 1 2000-03-18 10:28:52 MKW191 

LASTING GLOBALV V 48 5 1 2000-03-18 16:13:45 MKW191 

PROFILE EXEC V 76 42 1 1998-12-08 13:44:42 MKW191 

TEST DATA F 80 1 1 2000-03-17 8:57:33 MKW191 

TEST EXEC V 36 12 1 2000-03-17 10:30:39 MKW191 

TEST1 INFO F 80 133 3 2000-03-18 13:28:39 MKW191 


Command: 

A sample Unix-format (UNIX) list response, for the same directory as in the 

previous example, follows: 

dir 

>>>PORT 129,34,128,246,13,134 


>>>LIST 


-rwx---r-x 1 MIKEW TCPIPDEV 432 Mar 18 10:28 ALTTEST.EXEC 

-rwx---r-x 1 MIKEW TCPIPDEV 240 Mar 18 16:13 LASTING.GLOBALV 

-rwx---r-x 1 MIKEW TCPIPDEV 3192 Dec 8 1998 PROFILE.EXEC 

-rwx---r-x 1 MIKEW TCPIPDEV 80 Mar 17 8:57 TEST.DATA 

-rwx---r-x 1 MIKEW TCPIPDEV 432 Mar 17 10:30 TEST.EXEC 

-rwx---r-x 1 MIKEW TCPIPDEV 10640 Mar 18 13:28 TEST1.INFO 


Command: 

EBCDIC 

Use the EBCDIC subcommand to change the file transfer type to EBCDIC. 



►► EBcdic ►◄ 

Operands 

The EBCDIC subcommand has no parameters. 

Usage Notes 

v 

The EBCDIC transfer type is used to transfer files to or from another EBCDIC 

host. For more information about file transfer methods, see Table 4 on page 34. 

EUCKANJI 

Use the EUCKANJI subcommand to change the file transfer type to Extended 

UNIX Code (EUC) Kanji. 

►► 

EUckanji 

(─NOTYPE 

►◄ 

Operands 

NOTYPE 

Used when connecting to an FTP server that does not support the TYPE 

command generated by this TYPE command alias. See Appendix D, “Using 

DBCS with FTP and Mail” on page 301 for more information. 

GET 

Use the GET subcommand to transfer a file from a foreign host to the local host. 

►► Get foreignfile 

localfile 

(─REPLACE 

►◄ 

Operands 

foreignfile 

The foreign host file to be retrieved. For information about how to specify 


localfile 

The name of the local file to be created. For information about how to specify 

localfile, see the “Usage Notes” for this subcommand and “File Name Formats” 

on page 30. 

REPLACE 

Causes any localfile that already exists to be overwritten with the content of the 

foreignfile that is retrieved. If localfile already exists and the REPLACE operand 


Usage Notes 

v 

v 

v 

v 

v 


is not specified, FTP does not overwrite the existing file; it instead issues an 

informational message that identifies the existing file. 

To retrieve a file from a foreign host, a working directory must be established 

for which you have at least “read” privilege. For more information, see the 

description of the subcommands “ACCT” on page 40 and “CD or CWD” on 


The localfile is created at the local working directory by default — that is, when a 

file mode is not specified or is specified as an asterisk (*). 

If localfile is not specified, FTP attempts to create a file that is named to match 

that of the retrieved foreign file (with measures taken to meet z/VM file naming 

conventions and restrictions). Thus, if foreignfile is a BFS file, localfile should be 

explicitly specified, since the default file name produced may not be as expected. 

If the foreign file is named using a Unix or Unix-like format, the localfile name 

and type are derived from that part of the foreignfile name that follows the 

right-most slash (/) that is present. 

The retrieval of a foreign file directly to a BFS directory is not supported by the 

CMS FTP client. However, this can be accomplished with a two-step process. 

First, use the FTP GET subcommand to retrieve the file to a local SFS directory 

or minidisk; then, use the CMS OPENVM PUTBFS command to copy that file to 

its final location. 

HANGEUL 

Use the HANGEUL subcommand to change the file transfer type to Hangeul. 

►► 

HAngeul 

(─NOTYPE 

►◄ 

Operands 

NOTYPE 




HELP 

Use the HELP subcommand to get help with FTP subcommands. 

►► 

Help 

? 

ALL 

subcommand 

SERVER 

subcommand 

►◄ 



Operands 

Usage Notes 

? Provides information about how to use FTP. 

ALL 

Displays a description of all subcommands. 

subcommand 

Specifies the name of the subcommand. The subcommand can be abbreviated to 

its minimum abbreviation. 

SERVER 

Displays the help offered by the foreign host for the internal FTP commands. 

v 

If you enter the HELP subcommand without a parameter, you see the HELP FTP 

MENU, which lists the subcommands and a description of the help information 

available. If you enter the ? subcommand without a parameter, you see 

information about how to use the subcommands. 

IBMKANJI 

Use the IBMKANJI subcommand to change the file transfer type to IBM Kanji. 

►► 

Ibmkanji 

(─NOTYPE 

►◄ 

Operands 

NOTYPE 




This option usually causes no conversion to be performed on the transferred file. 

This option has exactly the same effect as the EBCDIC TYPE command alias. 

JIS78KJ 

Use the JIS78KJ subcommand to change the file transfer type to JIS78KJ (1978 

edition). 

►► 

JIS78kj 

( 

ASCII 

JISROMAN 

NOTYPE 

►◄ 

Operands 

ASCII 

Use ASCII shift-in escape sequence ESC(B 



JISROMAN 

Use JISROMAN shift-in escape sequence ESC(J 

NOTYPE 




If neither ASCII nor JISROMAN is specified, then the ASCII shift-in sequence will 

be used. 

JIS83KJ 

Use the JIS83KJ subcommand to change the file transfer type to JIS83KJ (1983 

edition). 

►► 

JIS83kj 

( 

ASCII 

JISROMAN 

NOTYPE 

►◄ 

Operands 

ASCII 

Use ASCII shift-in escape sequence ESC(B 

JISROMAN 

Use JISROMAN shift-in escape sequence ESC(J 

NOTYPE 




If neither ASCII nor JISROMAN is specified, then the ASCII shift-in sequence will 

be used. 

KSC5601 

Use the KSC5601 subcommand to change the file transfer type to KSC-5601. 

►► 

Ksc5601 

(─NOTYPE 

►◄ 

Operands 

NOTYPE 




LCD 

Use the LCD subcommand to change the working directory on the local host. 



►► LCd directory ►◄ 

Operands 

Examples 

Usage Notes 

directory 

The CMS file mode of an accessed minidisk or SFS directory to be used as the 

current working directory on the local host. 

v 

v 

Response displayed after invoking the LCD subcommand: 

Local directory mode is ’Z’ 

Command: 

LCD to a BFS directory is not supported by TCP/IP. 

LOCSITE 

Use the LOCSITE subcommand to change the record format and record length 

used for files created on the local host. 

►► LOCSIte Varrecfm 

Fixrecfmrecord_length 

►◄ 

Operands 

Varrecfm 

Specifies that the variable record format is to be used. 

Fixrecfm record_length 

Specifies that the fixed-record format is to be used. The parameter record_length 

specifies the record length for fixed records. 

LOCSTAT 

Use the LOCSTAT subcommand to display local status information. 

►► LOCSTat ►◄ 

Operands 

The LOCSTAT subcommand has no parameters. 

The following status information is displayed: 

v 

Value of the TRACE flag (set using the FTP command or the DEBUG 

subcommand) 


| 

v 

v 

v 

v 

v 

v 

v 

v 

v 

v 


SENDPORT setting (true or false) 

SENDSITE setting (true or false) 

Name, port number, and logon status of the foreign host 

Port number of the local host 

FTP data type (ASCII, EBCDIC, or Image) and transfer mode (block or stream) 

Record format (fixed or variable) and record length (for fixed record format) 

Translate table used by the client 

NETRC DATA file usage setting (true or false) 

Logon prompt setting (true or false) 

Console Width setting 

| 

Examples 

v 

Information displayed after invoking the LOCSTAT subcommand: 

Trace:FALSE, Send Port:TRUE 

Use NETRC DATA File:TRUE, Logon Prompting:TRUE 

Send Site with Put command:TRUE 

Connected to:YKTVMX, Port:FTP control (21), logged in 

Local Port:3452 

Data type:a, Transfer mode:s 

Record format:V 

Translate Table: STANDARD 

User Specified Translate Table: POSIX 

Console Width: 80 

Command: 

LPWD 

Use the LPWD subcommand to display the name of the current working directory 

on the local host. 

►► LPwd ►◄ 

Operands 

The LPWD subcommand has no parameters. 

Examples 

The following is an example of the response displayed as the result of the LPWD 

command. 

Local directory is ’Z’ 

Command: 

LS 

Use the LS subcommand to list only the name(s) of a set of foreign files, file group, 

or directory. 



►► 

LS 

name 

. 

.. 

(─DISK 

►◄ 

Operands 

Usage Notes 

name 

The name of the directory or file group on the foreign host for which files 

should be listed. If name is omitted, all directory entries or files for the current 

working directory or file group are listed. For information about how to 

specify name, see the “Usage Notes” for this subcommand and “File Name 

Formats” on page 30. 

To select which directory or file group is current, use the CD subcommand. For 

more information see “CD or CWD” on page 42. 

. Specifies that list information should be returned for the current working 

directory. For z/VM hosts, this operand is recognized in this manner only 

when SFS or BFS directories are referenced. For other z/VM resources, 

responses are returned as if no operand had been specified. 

.. Specifies that list information should be returned for the parent directory of the 

current working directory. For z/VM hosts, this operand is recognized in this 

manner only when SFS or BFS directories are referenced. For other z/VM 

resources, responses are returned as if no operand had been specified. 

DISK 

Stores the results of the DIR subcommand in file FTP LSOUTPUT, on the 

current local working directory. DIR subcommand results are not displayed 

when this operand is used. 

v 

v 

v 

v 

The LS subcommand provides a list of directory and file names only. To obtain a 

list of directory and file entries that includes auxiliary information about those 

entries, use the DIR subcommand. For more information, see “DIR” on page 48. 

For a given z/VM file system group, the response returned for an LS 

subcommand, regardless of whether VM-format or Unix-format lists are in use, 

is the same. 

If the LS subcommand is issued for a BFS directory that contains other than 

regular BFS files, a z/VM foreign host may return an error response that 

indicates a BFS directory error has occurred. 


about which information is returned. For more information see “File Name 

Pattern Matching” on page 31. 

Note: z/VM hosts do not support pattern matching for BFS files and directories. 

Examples 

A sample response to an LS subcommand follows. In this example, pattern 

matching has been used to obtain a list of only those files for which the file name 

begins with a “T”: 



Command: 

ls t* 

>>>PORT 9,117,32,30,4,53 


>>>LIST 


TCPIP.DATA 

TCPMNT2.NETLOG 

TCPMNT2.SYNONYM 

TCPSLVL.EXEC 

TEST.EXEC 

TESTFTPB.EXEC 

TRACE2.TCPIP 


Command: 

A sample LS response for a z/VM virtual reader working directory is shown here: 

Command: 

ls 

>>>PORT 9,117,32,29,10,213 


>>>LIST 


0013.CIBULAPR.MAIL 

0154.FL3XSAMP.TXT 

0116.TCP-HELP.LIST3820 

0115.TCP-OVER.LIST3820 

0153.FL32SAMP.TXT 

0214.CIBULAMA.MAIL 


Command: 

MDELETE 

Use the MDELETE subcommand to delete multiple files on the foreign host. 

►► 

▼ 

MDelete foreignfile ►◄ 

Operands 

Usage Notes 

foreignfile 

A foreign host file or file group to be deleted. For information about how to 

specify foreignfile see “File Name Formats” on page 30. 

v 

v 


to be deleted. For more information, see “File Name Pattern Matching” on 

page 31. 

To delete multiple files to which pattern matching cannot be applied, repeat 

foreignfile as necessary, with each foreignfile specification separated by at least one 

space. 



MGET 

Use the MGET subcommand to transfer a file or group of files from a foreign host. 

►► 

MGet 

▼ 

foreignfile 

(─REPLACE 

►◄ 

Operands 

Usage Notes 

foreignfile 

A foreign host file or file group to be retrieved. For information about how to 


REPLACE 

Causes an existing local file of the same name as foreignfile to be overwritten 

with the content of a corresponding foreignfile that is retrieved. If the local file 

already exists and the REPLACE operand is not specified, FTP does not 

overwrite the existing file; it instead issues an informational message that 

identifies the existing file. 

v 

v 

v 

v 

To retrieve files from a foreign host, a working directory must be established for 

which you have at least “read” privilege. For more information, see the 

subcommands “ACCT” on page 40 and “CD or CWD” on page 42. 


to be retrieved. For more information, see “File Name Pattern Matching” on 

page 31. 

To retrieve multiple files to which pattern matching cannot be applied, repeat 

foreignfile as necessary, with each foreignfile specification separated by at least one 

space. 

The MGET subcommand creates local files in the same manner as those created 

(on a single-file basis) when the GET subcommand is used. For more 

information, see the GET subcommand “Usage Notes” on page 51. 

MKDIR 

Use the MKDIR subcommand to create a new directory on the foreign host. 

►► MKdir directory ►◄ 

Operands 

directory 

The name of the new directory to be created. The directory specified can be a 

fully-qualified SFS name, just an SFS directory name (without a specified 

filepool), a fully-qualified BFS name, or a BFS subdirectory name. 


Usage Notes 


v Because of the way FTP handles searches, avoid naming any SFS or BFS 

subdirectories with the same name as a CMS minidisk that you might want to 

access using FTP. 

v MKDIR is allowed for the owner of the root directory where the new directory 

is to be created, or for SFS administrators and BFS super users. The POSIX and 

SFS permissions associated with the user ID you supply with the USER 

subcommand determine what directories can be created using the MKDIR 

command. 

General SFS users can create directories only in their own filespace. For BFS 

users, the POSIX permission checking performed by native BFS support 

determines whether the MKDIR can be done. An SFS file pool administrator or 

BFS super user has authorization to create directories for anyone enrolled in a 

filepool. The FTPSERVE machine is an SFS file pool administrator and a BFS 

super user, therefore inheriting all of the privileges of the registered user ID. See 

TCP/IP Planning and Customization for more details. 

v You must CD to an existing SFS or BFS directory before you can issue MKDIR. 

v The VM FTP server initially creates an SFS file control directory. To change the 

SFS directory to Dircontrol, issue the SITE DIRATTR dirid DIRControl command. 

See the SITE command for more information. 

For more information on SFS naming conventions, see the z/VM: CMS User’s Guide 

or the z/VM: SFS and CRR Planning, Administration, and Operation book. 

MODE 

Use the MODE subcommand to define how bits of data are to be transmitted, 

setting the mode (data format for the file transfer). 

►► 

MOde 

S 

B 

►◄ 

Operands 

S 

B 

Sets stream mode. Stream mode is the default transfer mode. In stream mode, 

data is transmitted as a stream of bytes. Any representation type can be used 

with stream mode. Stream mode is more efficient, because data block 

information is not transferred. 

Sets block mode. In block mode, data is transmitted as a series of data blocks, 

preceded by one or more header bytes. Block mode allows the transfer of 

binary data and preserves the logical record boundaries of the file. 

See Table 4 on page 34 for more information about file transfer methods. 

MPUT 

Use the MPUT subcommand to transfer a file or group of files to a foreign host. 



►► 

▼ MPut localfile ►◄ 

Operands 

Usage Notes 

localfile 

A local file or file group on the local host to be transferred to the foreign host. 

For information about how to specify foreignfile see “File Name Formats” on 

page 30. 

v 

v 

v 

v 

To transfer files to a foreign host, a working directory must be established for 

which you have at least “write” privilege. For more information see the 


For z/VM foreign hosts, pattern matching can be used to specify a subset of 

local files to be transferred. For more information see “File Name Pattern 

Matching” on page 31. 

To transfer multiple files to which pattern matching cannot be applied, repeat 

localfile as necessary, with each localfile specification separated by at least one 

space or blank. 

The MPUT subcommand creates foreign files in the same manner as those 

created (on a single file basis) when the PUT subcommand is used. For more 

information see the Usage Notes for “PUT” on page 63. 

NETRC 

Use the NETRC subcommand to enable or disable automatic logon capability 

through use of a NETRC DATA file. 

►► NEtrc ►◄ 

Operands 

The NETRC subcommand has no parameters. 

Usage Notes 

v 

The NETRC subcommand acts as a toggle that enables or disables FTP’s use of a 

NETRC DATA file. This file allows you to maintain logon user name and 

password information for specific hosts; when you connect to such a host, login 

is performed automatically, using the values defined in this file. For more 

information see “The NETRC DATA File” on page 19. 

NOOP 

Use the NOOP subcommand to determine if the foreign host is still responding. 



►► NOop ►◄ 

Operands 

The NOOP subcommand has no parameters. 

Usage Notes 

v 

If the foreign host is responding, you receive one of the following responses. 

200 OK 

or 

200 NOOP command successful 

You are prompted for the next FTP subcommand after the message is displayed, 

unless the EXIT parameter of the FTP command is active. 

OPEN 

Use the OPEN subcommand to open a connection to the foreign host’s FTP server 

when: 

v 

v 

You want to open another connection after closing one without leaving the FTP 

subcommand environment 

You were unable to open a connection after specifying a foreign_host with the 

FTP command 

►► 

Open 

host_name 

21 

port_number 

►◄ 

Operands 

Usage Notes 

host_name 

The host name or internet address of the foreign host. 

port_number 

A port on the foreign host. The default is port 21, which is also known as a 

well-known port. 

v 

v 

If you are already connected to a foreign host, you must disconnect from the 

foreign host before you can connect to a different host with the OPEN 

subcommand. For more information about closing a connection, see “CLOSE” on 

page 46. 

If a NETRC DATA file is in use and a valid match is found for the specified host 

name, that host’s user name and password will be used to automatically logon 

to that host. If no match is found, or if the use of a NETRC DATA file is 

suppressed, automatic login will not occur; a subsequent USER subcommand 

must be issued in order to logon to the foreign host. 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 


PASS 

Examples 

In this example, a CLOSE subcommand is used to terminate the FTP connection 

that is currently active, and an OPEN subcommand is then used to establish a 

connection with the GDLVMK4 host. 

Command: 

close 

>>>QUIT 

221 Quit command received. Goodbye. 

Command: 

open gdlvmk4 

Connecting to gdlvmk4 9.130.48.75, port 21 

220-FTPSERVE IBM VM Level 420 at GDLVMK4.VMTEST.ENDICOTT.IBM., 

15:02:07 EST THURSDAY 2001-12-13 

220 Connection will close if idle for more than 5 minutes. 

Command: 

teri 

>>>USER teri 

331 Send password please. 

Password: 

>>>PASS ******** 

230-TERI logged in; working directory = TERI 191 (ReadOnly) 

230 write access currently unavailable 

Command: 

Use the PASS subcommand to supply a login password to a foreign host (if one is 

required by that host) in order to validate the identity of a previously supplied 

login user name. 

►► PAss password ►◄ 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

PASSIVE 

Operands 

password 

The logon password to be used on the foreign host. If you supply an incorrect 

password, you are not prompted to enter the password again. You must 

instead issue a USER subcommand and again identify yourself to the remote 

host before you can supply the correct password using another PASS 

subcommand. 

Use the PASSIVE command to control whether the client or the server establishes 

connections for data transfers. 

►► PASSIve ►◄ 

Operands 

The PASSIVE subcommand has no parameters. 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

Usage Notes 

v 

v 


By default, passive data transfers are turned off when you start FTP. Each time 

you use the PASSIVE subcommand, data transfers are turned on and off 

alternately. If PASSIVE is on, the FTP client sends the server a PASV command 

and uses the response to determine which address and port to use when 

establishing the data transfer connection with the server. If PASSIVE is off, the 

client sends the server a PORT command (if the SENDPORT subcomand is on) 

containing the address and port the server should use to establish the data 

connection with the client. 

Passive data transfer may enable the use of FTP through a firewall that does not 

allow incoming connections. 

PUT 

Use the PUT subcommand to transfer a file from the local host to a foreign host. 

►► PUt localfile 

foreignfile 

►◄ 

Operands 

Usage Notes 

localfile 

A file on the local host that is to be transferred to and created on the foreign 

host. For information about how to specify localfile see “File Name Formats” on 

page 30. 

foreignfile 

The foreign host file to be created. For information about how to specify 


v 

v 

v 

v 

v 

To transfer files to a foreign host, a working directory must be established for 

which you have at least “write” privilege. For more information, see the 


If a file mode is not specified for the localfile, the file mode of the local working 

directory is first searched for this file; if found, this localfile is sent to the foreign 

host. If the localfile is not found at the local working directory, the first such file 

present in the CMS search order is transferred. 

In general, if a foreign host file already exists that matches the name of the 

transferred localfile, the existing foreign host file is replaced; this is the case for 

z/VM foreign hosts. For non-z/VM hosts, whether a foreign file is automatically 

replaced is dependent on the storage method used by that host. 

The “SUNIQUE” subcommand can be used to avoid overwriting a file that 

already exists on a foreign host. See “SUNIQUE” on page 71 for more 

information. 

Attempts to create the same foreign host file at a given time through different 

FTP connections may produce unexpected results. Some hosts may reply with a 

message that indicates a PUT or MPUT request should be resubmitted when 

such a condition is encountered. 

For z/VM hosts, when a transfer type of Image is used and the working 

directory on the foreign host is a minidisk or SFS directory, files are stored as 



v 

v 

variable-record (V) format files by default. To have files stored as fixed-record 

(F) format files for an Image mode transfer to these file system groups, do the 

following: 

1. Issue the SENDSITE subcommand to prevent SITE subcommands from being 

automatically issued for any PUT (or MPUT) subcommands that will be 

issued. 

2. Issue the SITE FIXRECM nn command to set the record length to be used 

when files are created. 

When an image file is stored on a z/VM foreign host as a fixed-record (F) 

format file, the last record of that file can be incomplete (that is, data stored 

using the last record does not consume the entire record). In such a case, this 

last record is padded with zeros (0). 

The transfer of a local file that resides in a BFS directory is not supported by the 

CMS FTP client. However, this can be accomplished with a two-step process. 

First, use the CMS OPENVM GETBFS command to copy that file from the BFS 

directory where it resides to a local SFS directory or minidisk; then, after this 

SFS directory or minidisk is established as the current local directory, issue the 

FTP PUT subcommand to transfer the file to the foreign host. 

PWD 

Use the PWD subcommand to display the name of the current working directory 


►► PWd ►◄ 

Operands 

The PWD subcommand has no parameters. 

Examples 

v 

v 

v 

v 

The following is an example of the information displayed after invoking the 

PWD subcommand if the current working directory is a minidisk. 

257 ’KRASIK1.0191’ is working directory 

Command: 

The following is an example of the information displayed after invoking the 

PWD subcommand if the current working directory is an SFS directory. 

257 ’SERVER1:KRAS1’ is working directory 

Command: 

The following is a sample of the information displayed after invoking the PWD 

subcommand if the current working directory is a BFS directory. 

257 ’./../VMBFS:BFS:KRASIK1/’ is working directory 

Command: 

The following is a sample of the information displayed after invoking the PWD 

subcommand if the current working directory is a VM reader. 

257 "TERI.RDR" is working directory 

Command: 



QUIT 

Use the QUIT subcommand to disconnect from the foreign host and end FTP 

processing. 

►► QUIt ►◄ 

Operands 

The QUIT subcommand has no parameters. 

QUOTE 

Use the QUOTE subcommand to send an uninterpreted string of data to the server 

port on the foreign host. The QUOTE subcommand bypasses the FTP interface of 

the local user to send commands that the foreign server understands, but the local 

host does not understand. 

►► QUOte string ►◄ 

Operands 

Examples 

string 

Data to be sent verbatim to the port on the foreign host. 

v 

To send the ALLOcate subcommand to a non-VM foreign host that supports 

ALLOcate, enter: 

QUOTE ALLO bytes 

v 

Where: 

ALLO Is the FTP standard string for the ALLOcate subcommand. 

bytes Is the number of bytes to allocate. 

To send a password to the VM FTP server, enter: 

QUOTE ACCT password 

Usage Notes 

v 

In this example, the local host implements FTP in a way that does not support 

the ACCT subcommand, but the foreign host requires a password to obtain a 

write link to a minidisk. 

The QUOTE subcommand allows you to use commands that TCP/IP does not 

support, such as the FTP ALLOcate subcommand. 

RENAME 

Use the RENAME subcommand to rename a file on the foreign host. 



►► REName foreignfile newfile ►◄ 

Operands 

Usage Notes 

foreignfile 

The foreign host file that is to be renamed. For more information about how to 


newfile 

The new name to be given to foreignfile For more information about how to 

specify newfile see “File Name Formats” on page 30. 

v 

v 

For a z/VM foreign host, the RENAME subcommand cannot be used to relocate 

a file; that is, an explicit directory change is not permitted when a file is 

renamed. Only files that reside in the current foreign host working directory can 

be renamed. 

Similarly, an existing CMS file cannot be replaced using this subcommand. For 

example, if a file named newfile already exists, that file, as well as the existing 

foreignfile are maintained without change when a RENAME operation is 

attempted. In such a case, an error reply is returned that indicates the RENAME 

operation has failed. 

For a non-z/VM foreign host, the RENAME subcommand may cause an existing 

file to be deleted. That is, if the files foreignfile and newfile already exist on the 

foreign host, the content of the existing newfile file can be lost when its name is 

assigned to foreignfile. 

RMDIR 

Use the RMDIR subcommand to remove a directory you own on a foreign host. 

►► RMdir directory ►◄ 

Operands 

Usage Notes 

directory 

The name of the directory to be removed. 

v 

v 

Before issuing an RMDIR subcommand, the user ID identified in the USER 

subcommand must first be using SFS or BFS (have a working directory in some 

SFS or BFS directory). 

You cannot remove the current working directory. You must first change to a 

different directory, and then issue an RMDIR subcommand to remove the 

desired directory. Note that the usual restrictions regarding non-empty 

directories/subdirectories may prevent an RMDIR from being executed 

successfully. Refer to the CMS User’s Guide for further information. 


v 


The directory specified can be a fully-qualified SFS or BFS name or just an SFS 

or BFS directory name (without a specified file pool). 

SENDPORT 

Use the SENDPORT subcommand to toggle PORT commands. 

►► SENDPort ►◄ 

Operands 

The SENDPORT subcommand has no parameters. 

| 

| 

| 

Usage Notes 

v 

v 

v 

v 

By default, the SENDPORT subcommand is turned on when you start the 

machine. Each time you use the SENDPORT subcommand, it is turned 

alternately on and off. 

FTP uses a PORT command by default when establishing a connection for each 

data transfer. FTP does not send PORT commands for data transfer when you 

use the SENDPORT subcommand to disable PORT commands. 

SENDPORT is useful for communication with FTP implementations that ignore 

PORT commands, but show (incorrectly) that the PORT command has been 

accepted. 

The SENDPORT setting is ignored when passive data transfer mode is 

established using the PASSIVE subcommand. This is because no PORT 

command is transmitted by the client in passive mode. 

SENDSITE 

Use the SENDSITE subcommand to toggle the sending of site information. 

►► SENDSIte ►◄ 

Operands 

The SENDSITE subcommand has no parameters. 

Usage Notes 

v 

v 

v 

By default, the SENDSITE subcommand is turned on when you start FTP. Each 

time you use the SENDSITE subcommand, it is turned alternately on and off. If 

SENDSITE is on, site information is sent to the foreign host with the PUT or 

MPUT subcommands. If SENDSITE is off, no site information is sent. 

By default, FTP sends a SITE subcommand containing record format 

information, when you issue the PUT or MPUT subcommand. Record format 

information is used by VM and MVS foreign hosts. 

If the foreign host is non-VM, you can use the SENDSITE subcommand to 

prevent the record format information from being sent. 



SITE 

Use the SITE subcommand to send information to a foreign host in order to make 

use of services which are specific to that system. 

►► 

Site 

operands 

►◄ 

Notes: 

1. The recognition and validation of operands specified with the SITE subcommand 

is dependent on the foreign host. 

2. The handling of incorrect or extraneous operand information may vary from 

one host to another. Some hosts may respond with an error reply code when a 

SITE command is considered to be in error, whereas another host may simply 

ignore such a command. 

Operands 

SITE subcommand operands that are supported by the current function level z/VM 

FTP server are described in this section. Some of these operands may not be 

supported by vm; hosts on which a prior function level is in use. 

AUTOTrans ON | OFF 

Specifies whether automatic EBCDIC-ASCII file translation, based on file 

extensions, is performed by a z/VM FTP server when files are transferred 

using the Image transfer type. Specify AUTOTRANS ON if automatic file 

translation should be performed, or AUTOTRANS OFF to prevent such 

translation. For more information about factors that affect file translation, see 

“Automatic File Translation” on page 35. 

DIRATtr dirid DIRControl | FILecontrol (options 

Sets the directory attribute of the SFS directory specified. See the CMS User’s 

Guide for a further explanation of available options. 

FIXrecfm record_length 

Specifies that the fixed-record format is to be used. The parameter record_length 

specifies the record length for fixed records. 

GRAnt AUTh fn ft dirid TO userid (options 

Grants authority for a user to a directory or files. userid can be a nickname in 

the FTP server’s NAMES files. See the CMS Command Reference for details of 

the GRANT AUTHORITY command. 

LISTFormat VM | UNIX 

Specifies the format to be used for file list information that is returned in 

response to DIR (or, LIST) subcommands. Specify LISTFORMAT VM for 

VM-format lists to be supplied by the FTP server, or LISTFORMAT UNIX if 

Unix-format lists should be returned. For more information about VM-format 

and Unix-format responses, see “File List Formats” on page 35. 

PERMit pathname mode_string (REPlace | ADD | REMove 

Issues an OPENVM PERMIT command to change the permission bits used to 

control the owner access, group access, and general access to a BFS object. 

Pathname can be specified as a relative pathname or a fully-qualified pathname. 

To issue the SITE PERMIT command, you must be the owner of the BFS object 


or have the appropriate privileges. See the z/VM: OpenExtensions Command 

Reference for details of the OPENVM PERMIT command. 

QAUTH fn ft 

Queries the authority of the current working directory or files in the directory. 

The fn and ft parameters are optional. If fn or ft is omitted, QAUTH returns the 

directory authority information. See the CMS Command Reference for details of 

the QUERY AUTHORITY command. 

QDIRattr dirid 

Returns the directory attribute of the SFS directory specified. 

QDISK 

Returns the disk information for the current working directory. If the current 

working directory is an SFS subdirectory, the information returned is the result 

of the CMS QUERY DISK and CMS QUERY LIMITS commands. If the current 

working directory is a BFS directory, the information returned is the result of 

the CMS QUERY LIMITS command. See the CMS Command Reference for details 

on the QUERY DISK and QUERY LIMITS commands. 

QPERMit pathname (OBJ 

Returns the output of the OPENVM LISTFILE (OWNERS command for the 

current working directory, or for the specified pathname. Ifpathname is omitted 

the QPERMIT command returns information for the current working directory. 

The Pathname can be specified as a relative pathname or it can be fully 

qualified. OBJ is optional and if specified, will return the output of OPENVM 

LISTFILE (OWNERS OBJECT command for the current working directory or 

pathname. See the OpenEdition Command Reference for details of the OPENVM 

LISTFILE (OWNERS command. 

REVoke AUTh fn ft dirid FROM userid (options 

Revokes authority for a user to a directory or files. userid can be a nickname in 

the FTP server’s NAMES files. See the CMS Command Reference for details of 

the REVOKE AUTHORITY command. 

TRANslate filename 

XLATe filename 

Specifies the name of the translation table to use. The translation table specifies 

the name of an EBCDIC-ASCII translation table that is to be used for all 

subsequent ASCII file transfers. To use the default translation table, issue either 

a SITE XLATE or a SITE XLATE * command. The specified translation table 

must be a TCPXLBIN file available on the remote z/VM or OS/390 host. See 

TCP/IP Planning and Customization for further information on loading and 

customizing translation tables, as well as the ″Using Translation Tables″ chapter 

in this publication. 

VARrecfm 

Specifies that the variable-record format is to be used. 

Usage Notes 

v 

v 


To obtain information about site-specific operands that are supported by a 

foreign host, issue the HELP SERVER SITE command. 

By default, the z/VM PUT and MPUT subcommands automatically issue a SITE 

subcommand before a file is transferred. This is done to provide CMS file record 

format information to the foreign host (under the assumption that the foreign 

host can make use of this information, which is the case for IBM EBCDIC host 

systems). 



v 

v 

The SENDSITE subcommand can be used to prevent SITE subcommands from 

being automatically issued by the PUT or MPUT subcommands. For more 

information see “SENDSITE” on page 67. 

For the operands that follow, dirid can be specified as a single period (.) to 

signify the current foreign host working directory: 

v 

v 

v 

DIRATTR, GRANT, QDIRATTR, REVOKE 

For SITE operands that require an SFS directory (dirid), specify this directory 

using the same syntax as for other SFS-related CMS commands. For more 

information about the naming of SFS directories, see the CMS Command 

Reference. 

The operands that follow are accepted only when the foreign host working 

directory is an SFS directory: 

DIRATTR, GRANT, QUATH, QDIRATTR, REVOKE 

The operands that follow are accepted only when the foreign host working 

directory is a BFS directory: 

PERMIT, QPERMIT 

SIZE 

Use the SIZE subcommand to retrieve the transfer size (in bytes) for a foreign host 

file. 

►► SIZE foreignfile ►◄ 

Operands 

foreignfile 

Specifies the foreign host file for which size information is to be retrieved. For 

more information about how to specify foreignfile see “File Name Formats” on 

page 30. 

The returned file transfer size may account for included record delimiter or 

block header bytes, depending on the current TYPE and MODE settings. 

SJISKANJI 

Use the SJISKANJI subcommand to change the file transfer type to SJISKANJI. 

►► 

SJiskanji 

(─NOTYPE 

►◄ 

Operands 

NOTYPE 





Note: JIS is the abbreviation for the Japan Institute of Standards. 


STATUS 

Use the STATUS subcommand to retrieve status information from the foreign host. 

►► 

STAtus 

name 

►◄ 

Operands 

Usage Notes 

name 

Specifies the file or foreign directory for which status information is requested. 

The name parameter is not supported by the VM FTP server. 

v 

Examples 

v 

The retrieved status information can be a directory, a file, or general status 

information, such as a summary of activity. If name is omitted, general status 

information is retrieved. 

Information displayed after invoking the STATUS subcommand: 

211-Server FTP talking to host 129.34.128.246, port 3452 

User: KRASIK1 Working directory: KRASIK1 0191 

The control connection has transferred 399 bytes. 

There is no current data connection. 

The next data connection will be actively opened 

to host 129.34.128.246, port 3452, using 

mode Stream, structure File, type ASCII Nonprint, byte-size 8. 

record format is V, record length 65535 

List format is UNIX. Automatic file translation is ON. 

FTPSERVE Translate Table: STANDARD 

211 User Specified Translate Table: POSIX 

Command: 

STRUCT 

Use the STRUCT subcommand to set the structure of the file. 

►► STRuct F ►◄ 

Operands 

F 

Shows the file structure. The F file structure is the only structure supported. 

The file structure affects the transfer mode, and the interpretation and storage 

of the file. With a file structure of F, the file is considered to be a continuous 

sequence of data bytes. 

SUNIQUE 

Use the SUNIQUE subcommand to toggle the method of storing files. 



►► SUnique ►◄ 

Operands 

The SUNIQUE subcommand has no parameters. 

Usage Notes 

v 

v 

v 

v 

By default, SUNIQUE is toggled off, and FTP uses a store command (STOR) 

with the PUT and MPUT subcommands. If the foreign host already has a file 

with the name specified by foreignfile, the foreign host overwrites the existing 

file. 

If SUNIQUE is toggled on, FTP uses a store-unique command (STOU) with the 

PUT and MPUT subcommands, and prevents you from erasing the existing file 

on the foreign host that is specified by foreignfile. The created foreign file is 

stored with a unique file name. FTP sends the name of the created foreign file to 

the local host, where the file name is displayed on your terminal. 

To uniquely store files or copies of files when the named foreignfile already 

exists, the z/VM FTP server generates unique file names by appending a 

numeric suffix (from 1 to 999, in increments of 1) to the foreignfile name provided 

as part of a PUT or MPUT command. The foreignfile name is truncated (if 

necessary) to allow inclusion of this suffix. A maximum of 999 uniquely-named 

copies of a file can be created on a z/VM host. Note that the foreignfile name is 

modified only when necessary. 

When the ″store unique″ attribute is in effect, the FTP server identifies file names 

available for use by first searching the current working directory for the named 

file. If the file already exists, the server sequentially checks for similarly-named 

(and numbered) files until the next available suffix number for constructing a 

unique file name has been identified. 

Notes: 

1. There is no guarantee that a file with a low suffix number (with respect to 

the numbering scheme just described) is an older file (with respect to time 

and date) than a file that has a higher suffix number. 

2. When uniquely-stored files are selected for deletion, some criteria other than 

the numeric suffix value should be used. The date and time stamp associated 

with a file is usually a reasonable compromise choice. 

For example, if a foreignfile name of UNIQTEST is in use, a file might be 

stored uniquely with the name UNIQTES9, with an ensuing file stored 

uniquely as UNIQTE10. 

In rare cases, the file transfers for which the ″store unique″ attribute is in effect 

may fail because the foreign host cannot uniquely store a file. For a z/VM host, 

this would be the case when the z/VM FTP server detects that the named file 

and all 999 uniquely named copies of the file already exist in the foreign 

directory. To store a file in this event, one of the following actions may prove 

successful: 

– Turn off the ″store unique″ attribute by re-issuing the SUNIQUE subcommand 

to toggle the setting, then re-attempt the file transfer. 

– Delete one of the uniquely named copies of the file you are attempting to 

store. 



SYSTEM 

Use the SYSTEM subcommand to display information about the operating system 

that is in use on a foreign host. 

Note: Information returned in response to the SYSTEM subcommand will vary 

depending on the foreign host with which an FTP session is established. 

Other factors, such as configuration parameters or active session attributes, 

may further affect this response. Note that the SYSTEM subcommand may 

not be supported by all foreign hosts. 

►► SYstem ►◄ 

Operands 

The SYSTEM subcommand has no operands. 

Examples 

For z/VM hosts that support list format selection, the response to the SYSTEM 

subcommand can differ, based on the list format in effect for a session. 

For example, when VM-format lists are in effect, the SYSTEM subcommand 

response is: 

215-z/VM Version 3 Release 1.0, service level 0000 (nn-bit) 

CMS Level 16, Service Level 000 

215 VM is the operating system of this server. 

Command: 

However, if Unix-format lists are in use, this response is modified to indicate this 

fact, and the following response is produced: 

215-z/VM Version 3 Release 1.0, service level 0000 (nn-bit) 

CMS Level 16, Service Level 000 

215 VM is the operating system of this server. UNIX list format is active. 

Command: 

TCHINESE 

Use the TCHINESE subcommand to change the file transfer type to Traditional 

Chinese. 

►► 

TChinese 

(─NOTYPE 

►◄ 

Operands 

NOTYPE 






TYPE 

Use the TYPE subcommand to set the file transfer type (the data representation for 

the transfer). FTP supports the ASCII, EBCDIC, Image (binary), and Kanji file 

transfer types. 

►► 

TYpe 

A 

I 

B B Options 

E 

F 1 

►◄ 

B Options: 

1 

2 

3 

4 

5 

6 

7 

A 

R 

A 

R 

Operands 

A 

I 

Sets the transfer type as ASCII, which is intended for use when text files are 

transferred to or from an ASCII host. When FTP sessions are established, ASCII 

is the default transfer type. The TYPE A subcommand has a similar effect as 

the ASCII subcommand, but it does not alter the record format used to store 

local files. 

Sets the transfer type as Image (or, binary), which is intended for use when 

binary data is transferred or when the efficient storage and retrieval of files is 

desired. With the Image transfer type, data is sent as contiguous bits, packed 

into 8-bit bytes. The TYPE I subcommand has a similar effect as the BINARY 

subcommand, but it does not alter the record format used to store local files. 

B 

E 

F 

Note: A transfer type of Image must be used when automatic file translation 

(performed by a z/VM FTP sever) is desired. 

Sets the transfer type as DBCS Kanji, Hangeul, or Traditional Chinese. 

Specifying the B transfer type with the appropriate options has the same effect 

as using the EUCKANJI, HANGEUL, JIS78KJ, JIS83KJ, KSC5601, SJISKANJI or 

TCHINESE subcommands. The options provide further DBCS information. See 

Appendix D, “Using DBCS with FTP and Mail” on page 301 for more 

information about DBCS support for FTP. 

Sets the transfer type as EBCDIC. Specifying the EBCDIC transfer type has the 

same effect as using the EBCDIC subcommand. The EBCDIC transfer type is 

intended for efficient transfer between hosts that use EBCDIC for their internal 

character representation. 

Sets the transfer type as EBCDIC IBM Kanji. Specifying the IBM Kanji transfer 


Usage Notes 


type has the same effect as using the IBMKANJI subcommand. See 

Appendix D, “Using DBCS with FTP and Mail” on page 301 for more 

information about DBCS support for FTP. 

v For a z/VM foreign host where the FTP server has been configured to perform 

automatic file translation, the TYPE I subcommand has no effect on file 

translation — the server continues to determine whether EBCDIC-ASCII 

translation should occur based only on file extension. 

To enable or disable automatic file translation for files transferred using the 

Image transfer type, use the AUTOTRANS operand of the “SITE” subcommand. 

See “SITE” on page 68 for more information. 

v See Table 4 on page 34 for more information about file transfer methods. 

USER 

Use the USER subcommand to identify yourself to a foreign host after an FTP 

connection has been established. 

►► User user_id 

user_id/BY/byuser_id 

user_id.BY.byuser_id 

password 

►◄ 

Operands 

Using FTP Within an EXEC 

user_id 

The logon name to be used on the foreign host. 

byuser_id 

An alternate logon name user_id to be used by a foreign z/VM host when 

login authorization is performed. 

When the /BY/ or .BY. delimiter and byuser_id are included with user_id, the 

byuser_id logon password is used for login authorization checking, instead of 

that for user_id. To be effective, byuser_id must be included in a LOGONBY 

statement in the user_id CP directory entry. When an External Security 

Manager (ESM) such as RACF is installed, its defined authorization criteria 

may override that defined by CP for the LOGONBY statement. For example, 

RACF may perform authorization checks for attempts to log on a shared user 

ID. For further details, refer to the documentation provided by the ESM in use. 

password 

The logon password to be used on the foreign host. If a password is not 

included with the USER subcommand, you are prompted to provide a 

password, if one is required by the foreign host. If you supply an incorrect 

password, you are not prompted to enter the password again. You must 

instead reissue the USER subcommand to supply the correct password. 

When the FTP command is used within an exec, FTP subcommands can be 

supplied by either the program stack or a CMS disk file. Likewise, FTP command 

results can be directed to either the console, or to a CMS disk file. 



Notes: 

1. FTP supports only DISK and TERMINAL I/O devices when FILEDEF 

commands are used to manage subcommand input and command results. 

2. It is recommended that the EXIT option be used when FTP is used within an 

exec, so that error conditions can be detected and handled, as needed. 

Providing FTP Subcommand Input 

The program stack is used as the input source for FTP subcommands if the input 

device DISK has not been defined with a FILEDEF, or if the input device has been 

defined as TERMINAL. 

If subcommand input is to be obtained from a disk file, that file must be identified 

with the CMS FILEDEF command. When disk file input is obtained by using 

FILEDEF, the following notes apply: 

Notes: 

1. Only the ddname INPUT is recognized and used by FTP for subcommand 

input. 

2. Program stack data is ignored. 

3. If all FTP subcommands defined in the file complete without incident, and a 

QUIT was not the last subcommand executed, FTP will supply a QUIT 

subcommand to end the FTP session. 

4. When a NETRC DATA file is used to provide logon user name and password 

values, it is advised that the NOPROMPT option be used to suppress 

unanticipated prompts for this information; this will cause FTP to return a 

nonzero return code in the event no NETRC DATA file exists or no entry for 

the target host is present in this file. 

5. Because of the processing performed by FTP to obtain login passwords, you 

must provide the login password with the login name (user ID) when you use 

FTP within an exec, unless a NETRC DATA file is used to supply these values. 

(That is, for stack input, the logon password must be queued with the logon 

name. For disk file input, the password must be part of the same line as the 

logon name.) 

If a foreign host requires account information to be provided, you need to 

supply values with the ACCT subcommand in this manner as well. 

Managing FTP Command Output 

By default, FTP dialog output (messages, subcommand reply codes and text) 

generated during FTP command processing is directed to your terminal. However, 

FTP command results can be also directed to a disk file. As with subcommand 

input, the file to receive FTP dialog results must be identified with the CMS 

FILEDEF command. Only the ddname OUTPUT is recognized and used by FTP for 

handling FILEDEF command output. 

Examples 

The following example shows how FTP subcommands could be issued from within 

a REXX exec. In this example, the CMS program stack is used to supply FTP 

subcommands. This sample also illustrates a method for checking the return and 

reply codes from the FTP command. 

/* FTPSTACK EXEC */ 

/*----------------------------------------------------------*/ 

/* Setup variables to hold some commonly-used items. */ 

/*----------------------------------------------------------*/ 


emote_host = ’rdrunner.endicott.ibm.com’ 

login_id = ’coyote’ 

pass_word = ’wileyc’ 

acct_info = ’secretpw’ 

local_mode = ’A’ 

remote_dir = ’COYOTE.191’ 

remote_file = ’ACME’ || ’.’ || ’SURPLUS’ 

local_file = ’ACME-A1’ || ’.’ || ’CATALOG’ 

/*----------------------------------------------------------*/ 

/* Setup the FTP subcommands to be issued... */ 

/*----------------------------------------------------------*/ 

ftpcmd.1 = login_id pass_word /* USER and PASS responses */ 

ftpcmd.2 = ’acct’ acct_info /* Account info - this will */ 

/* supply the minidisk READ */ 

/* password in this case. */ 

ftpcmd.3 = ’cd’ remote_dir 

ftpcmd.4 = ’lcd’ local_mode 

/*----------------------------------------------------------*/ 

/* Working with another VM host, so set up the transfer */ 

/* MODE and TYPE for EBCIDIC data -- would do the same for */ 

/* an MVS host. */ 

/*----------------------------------------------------------*/ 

ftpcmd.5 = ’mode b’ 

ftpcmd.6 = ’type e’ 

/*----------------------------------------------------------*/ 

/* Get the file of interest, then quit. */ 

/*----------------------------------------------------------*/ 

ftpcmd.7 = ’get’ remote_file local_file 

ftpcmd.8 = ’quit’ 

ftpcmd.0 = 8 

/*----------------------------------------------------------*/ 

/* Display and queue the FTP subcommands that will be used. */ 

/*----------------------------------------------------------*/ 

’MAKEBUF’ 

buff_num = rc 

Say "FTP subcommands being issued are:" 

Do ii=1 to ftpcmd.0 

Say ftpcmd.ii 

Queue ftpcmd.ii 

End 

/*----------------------------------------------------------*/ 

/* Issue the FTP command, and save it’s return code. */ 

/*----------------------------------------------------------*/ 

Say "" ; Say "Issuing FTP command..." 

’FTP’ remote_host ’(EXIT’ 

ftprc = rc 

’DROPBUF’ buff_num 

/*----------------------------------------------------------*/ 

/* Interrogate the FTP command return code, and explain it */ 

/* to the extent possible. */ 

/*----------------------------------------------------------*/ 

If (ftprc 0) 

Then Do 

fterr = Right(ftprc,3) 

cmdrc = Left(ftprc,(Length(ftprc)-3)) 

Say "FTP command code:" cmdrc 

End 

Exit ftprc 

Say "FTP Server Reply code:" fterr 

Say "Possible Internal Error code:" 

fterr 


This next example shows how FTP subcommands could be maintained separately 

from an exec that makes use of those subcommands. In this example, FTP 

subcommands to be issued are contained in a CMS file (SPACELY ACCTFTP A), 

which might contain the following data: 



FTP Return Codes 

jetsong rorge 

cd c:\sprocket\accts 

lcd a 

get sprocket.txt sprocket.acctdata 

quit 

For the data illustrated above, jetsong is the user ID and rorge is the login 

password. The GET subcommand will cause the file SPROCKET.TXT A to be 

retrieved as SPROCKET ACCTDATA to the invoking user ID’s A disk. 

/* FTPFILDF EXEC */ 

/*----------------------------------------------------------*/ 

/* Setup variables for host and input/output files. */ 

/*----------------------------------------------------------*/ 

remote_host = ’sprocketman.endicott.ibm.com’ 

input_file = ’SPACELY ACCTFTP A’ 

output_file = ’SPACEFTP RESULTS A’ 

/*----------------------------------------------------------*/ 

/* Check existing FILEDEFS, and account for them as */ 

/* required. Then establish the desired FILEDEFS. */ 

/*----------------------------------------------------------*/ 

’PIPE CMS QUERY FILEDEF | Stem filedefs.’ 

If (filedefs.0 = 0) 

Then Nop 

Else Nop /* Add appropriate checking, etc. here */ 

’ESTATE’ input_file 

If (rc 0) 

Then Do 

Say input_file "does not exist..." 

Exit 8 

End 

Else ’FILEDEF INPUT DISK’ input_file 

’FILEDEF OUTPUT DISK’ output_file 

/*----------------------------------------------------------*/ 

/* Issue the FTP command, and save it’s return code. */ 

/*----------------------------------------------------------*/ 

Say "" ; Say "Issuing FTP command..." 

’FTP’ remote_host ’(EXIT’ 

ftprc = rc 

/*----------------------------------------------------------*/ 

/* Interrogate the FTP command return code, and explain it */ 

/* to the extent possible. */ 

/*----------------------------------------------------------*/ 

If (ftprc 0) 

Then Do 

fterr = Right(ftprc,3) 

cmdrc = Left(ftprc,(Length(ftprc)-3)) 

Say "FTP command code:" cmdrc 

Say "FTP Server Reply code:" fterr 

Say "Possible Internal Error code:" 

fterr 

End 

/*----------------------------------------------------------*/ 

/* Clear the FILEDEFS created for this FTP session. */ 

/*----------------------------------------------------------*/ 

’FILEDEF INPUT CLEAR’ 

’FILEDEF OUTPUT CLEAR’ 

Exit ftprc 

When the FTP command EXIT operand is used, the FTP return code is composed 

of a command code and a reply code. The following is the format of the FTP EXIT 

return code: 

YYXXX 


FTP EXIT Return Codes 

| 

| 

where: 

YY Is the command code, which is a number from 1 to 99. For a description of 

the possible FTP command codes, see Table 5. 

XXX 

Is the reply code that is sent from the foreign host FTP server. The reply 

code is a 3-digit number. For a description of the possible reply codes, see 

Table 6 on page 81. At times XXX may instead be an FTP internal error 

code. For a description of possible internal error codes, see Table 7 on 

page 82. If an FTP server reply code or an internal error code is not 

available, XXX will be zero. 

Table 5. FTP Command Codes 

Code Number Command EXIT_IF_ERROR 

1 AMBIGUOUS true 

2 ? false 

3 ACCT true 

4 APPEND true 

5 ASCII true 

6 BINARY true 

7 CD true 

8 CLOSE true 

9 CMS true 

10 OPEN (CONNECT) true 

11 DEBUG false 

12 DELIMIT false 

13 DELETE true 

14 DIR true 

15 EBCDIC true 

16 GET true 

17 HELP false 

18 LOCSTAT true 

19 USER true 

20 LS true 

21 MDELETE true 

22 MGET true 

23 MODE true 

24 MPUT true 

25 NOOP true 

26 PASS true 

27 PUT true 

28 PWD true 

29 QUIT true 

30 QUOTE true 

31 RENAME true 

32 SENDPORT true 


FTP EXIT Return Codes 

Table 5. FTP Command Codes (continued) 

Code Number Command EXIT_IF_ERROR 

33 SENDSITE false 

34 SITE false 

35 STATUS true 

36 STRUCT true 

37 SUNIQUE true 

38 SYSTEM true 

40 TYPE true 

41 LCD true 

42 LOCSITE true 

43 LPWD false 

44 MKDIR true 

46 EUCKANJI true 

47 IBMKANJI true 

48 JIS78KJ true 

49 JIS83KJ true 

50 SJISKANJI true 

51 CDUP true 

52 RMDIR true 

53 HANGEUL true 

54 KSC5601 true 

55 TCHINESE true 

56 NETRC false 

57 SIZE true 

60 PASSIVE true 

99 UNKNOWN true 

Examples 

The following are examples of FTP return codes. 

FTP Reply Codes 

The FTP return code 16550 indicates the following: 

16 The GET command failed. 

550 The reply code from the FTP server. 

The FTP return code 4532 indicates the following: 

4 The APPEND command failed. 

532 The reply code from the FTP server. 

When you enter an FTP command, TCP/IP displays the sequence of 

subcommands, if any, that are sent to the foreign host’s FTP server. In addition, the 

subcommand’s response is also displayed as a reply code. These replies ensure the 

synchronization of requests and actions during file transfer, and guarantee that you 


always know the state of the foreign host’s FTP server. The descriptions of the 

possible reply codes are listed in Table 6. 

Note: In general, the reply code descriptions below will not match the messages 

received from a foreign host, since reply message text will vary from one 

server implementation to another. The following descriptions are intended to 

provide an explanation of the reply codes themselves. 

Table 6. FTP Reply Codes 


Code 

Description 

110 Restart marker reply 

120 Service ready in nnn minutes 

125 Data connection already open; transfer starting 

150 File status okay; about to open data connection 

200 Command okay 

202 Command not implemented; not used on this host 

211 System status, or system help reply 

212 Directory status 

213 File status 

214 Help message 

215 VM is the operating system of this server 

220 Service ready for new user 

221 QUIT command received 

226 Closing data connection; requested file action successful 

230 User logged on; requested minidisk, BFS, or SFS Directory not 

available; proceed 

250 Requested file action or directory okay, completed 

255 In target directory already 

257 PATH NAME created or directory status given 

331 Send password please 

332 Supply minidisk password using account 

421 Service not available; closing Telnet connection 

425 Cannot open data connection 

426 Connection closed; transfer ended abnormally 

450 Requested action not taken; file busy, minidisks or SFS directory not 

available 

451 Requested action aborted; local error in processing 

452 Requested action not taken; insufficient storage space in system 

500 Syntax error; command unrecognized 

501 Syntax error in parameters or arguments 

502 Command not implemented 

503 Bad sequence of commands 

504 Command not implemented for that parameter 

521 Directory already exists, taking no action 

530 Not logged on 



Table 6. FTP Reply Codes (continued) 

Code 

Description 

532 Need account for storing files 

550 Requested action not taken; file not found or no access 

551 Requested action aborted; page type unknown 

552 Requested file action ended abnormally; exceeded storage allocation 

553 Requested action not taken; file name not allowed 

Internal Error Codes 

If an internal error occurs when you enter an FTP command, the reply code is an 

internal error code rather than an FTP reply code. Table 7 lists the possible internal 

error codes. 

| 

| 

Table 7. Internal Error Codes 

Code Error EXIT_IF_ERROR 

01 NOmoreSLOTS false 

02 TOOfewDOTS false 

03 WOULDclobberFILE false 

04 CMSfileERROR false 

05 CMSfileNOTfound false 

06 CMSdiskFILEid false 

07 CMSinvalidCHAR false 

08 CMSdiksNOTaccessed false 

09 CMSdiskREADonly false 

10 CMSfileNOTaccessed false 

11 BLOCKbutNOTebcdcic false 

12 INITemulationERROR true 

13 OPENwasNOTissued true 

14 NOinputFILE false 

15 CANTwriteTOoutput false 

16 USERwasNOTissued true 

17 FileNOTauthorized false 

18 InvalidRecfm false 

19 InsuffStorage false 

20 AppcVMerror false 

21 SharingConflict false 

22 SysResrcUnavail false 

23 FSOpenError false 

24 InvalidFILEDEFDev false 

25 NoPromptConflict true 

26 InvalidArgString true 

27 NoClosingQuote true 


Using FTP with RACF ® 

For example, the internal error code 13 indicates that an “OPENwasNOTissued” error 

condition has occurred. 

The Resource Access Control Facility (RACF) allows FTP servers to act as surrogates 

for other user IDs. This means that the server can access those disks available to 

that user ID. 

The command that allows FTP servers to act as surrogates is provided in a 

program called FTPPERM EXEC. To use it, enter the command: 

FTPPERM ADD 

If you get an error, contact your system administrator. 

You may delete the FTP server’s surrogate authority by issuing the command: 

FTPPERM DELETE 

FTPPERM is explained in TCP/IP Planning and Customization. 

Internal Error Codes 



Chapter 3. Transferring Files Using TFTP 

TFTP Command 

This chapter describes how to transfer files using the Trivial File Transfer Protocol 

(TFTP) command and its subcommands. The TFTP command is a simple method 

to get files from, and send files to, a foreign host. 

TFTP uses the User Datagram Protocol (UDP), and uses a simple lock-step method 

to acknowledge each packet separately. TFTP cannot list directories and has no 

provision for user authentication. VM provides a TFTP server. This server provides 

access to a BFS directory mounted on the server machine. For additional 

information on this server, see TCP/IP Planning and Customization. 

You can also use the FTP command to transfer files from a VM host. For more 

information about the FTP command, see Chapter 2, “Transferring Files Using 

FTP” on page 15. 

Use the TFTP command to transfer files from or to the foreign host. 

►► 

TFTP 

foreign_host ( TRANSLATE filename 

►◄ 

Operands 

foreign_host 

Specifies the name of the foreign host to which you are connecting. Specify the 

foreign host by its host name or its internet address. You are prompted for a 

host name if you do not specify a foreign_host with the TFTP command. If you 

specify foreign_host incorrectly, or if the foreign host is not accessible, you 

enter the TFTP command shell. To identify the desired host, use the OPEN 

subcommand. See “OPEN” on page 88 for more information. Specify the 

foreign host by its internet host name: 

internet-hostname 

or by its dotted-decimal internet address: 

nnn.nnn.nnn.nnn 

TRANSLATE filename 

Specifies the file name of a translation table file other than a standard table. 

The file type is TCPXLBIN, and the file mode is an asterisk (*). If this 

parameter is not specified, the TFTP command searches sequentially for the 

TFTP TCPXLBIN or STANDARD TCPXLBIN table files. If neither is found, 

TFTP uses the compiled translation table. TFTP TCPXLBIN is not supplied, 

because the standard translation table is adequate for most applications. You 

can create your own TCPXLBIN table file if your installation needs a different 

translation. 


Transferring Files Using TFTP 

Creating Translation Tables 

TFTP Subcommands 

You can edit and modify translation table files that have a file type of TCPXLATE. 

A translation table must be in binary format and have a file type of TCPXLBIN. To 

convert a table from modifiable form to binary form, use the CONVXLAT EXEC 

file written in the REXX programming language. 

Creating your own translation table provides the following advantages. 

v You do not require the application’s source code. 

v You do not need to recompile the application to change the translation table. 

v You can specify, as a command parameter, a translation table file that is different 

from that of your system administrator. 

For information about creating your own translation tables, see TCP/IP Planning 

and Customization. 

The TFTP subcommands and their parameters are described in detail on pages 86 

through 90. 

GET 

Use the GET subcommand to retrieve a file from the TFTP server. 

►► Get foreignfile localfile ►◄ 

Operands 

foreignfile 

Specifies the name of the file to be retrieved from the foreign host. 

localfile 

Specifies the name of the local file to be created. The localfile is specified by 

filename.filetype.filemode or filename.filetype. The default filemode is A. 

Attention: If a file with the name specified by localfile already exists, that file is 

overwritten. 

Usage Notes 

v The localfile is created or overwritten with a variable record format. The file is 

transferred using the currently selected transfer mode. If the transfer mode is 

OCTET, the file is created with a record length of 512. 

v When a file is stored in ASCII mode, each empty line is written to the file as a 

single space, because a record of zero length cannot be written to a CMS file. 

When a file is transferred to and from VM, each previously empty line contains 

a single space. See “MODE” on page 88 for more information about transfer 

modes. 

HELP 

Use the HELP subcommand to receive assistance with the TFTP subcommands. 



►► 

Help 

subcommand 

►◄ 

Operands 

subcommand 

Specifies the name of the TFTP subcommand. 

Usage Notes 

v If you enter HELP without a parameter, you see the list of TFTP subcommands 

that are supported by the client. 

LOCSTAT 

Use the LOCSTAT subcommand to display the local status information about TFTP. 

►► LOCSTat ►◄ 

Operands 

The LOCSTAT subcommand has no parameters. 

Usage Notes 

v The following local status information is displayed when the LOCSTAT 

subcommand is issued: 

– Name of connected host (or the message not connected) 

– Transfer mode 

– Packet tracing (on or off) 

– Packet retransmit interval, in seconds 

– Packet retry count, in packets 

MAXPKT 

Use the MAXPKT subcommand to set the maximum number of times a packet is 

retransmitted. 

►► 

MAXpkt 

5 

number_of_times 

►◄ 

Operands 

number_of_times 

Specifies the maximum number of times a packet is retransmitted. The default 

value is 5 times. 

Usage Notes 

v When TFTP sends a packet for which a response packet is expected from the 

foreign TFTP server, a timer is set, as specified by the REXMIT command. See 

Chapter 3. Transferring Files Using TFTP 87


v 

v 

“REXMIT” on page 89 for more information. If the time interval expires before 

the response packet is received, the original packet is retransmitted. 

When the packet has been retransmitted the maximum number of times (as 

specified by the MAXPKT command) and nothing is received from the foreign 

TFTP server, the transfer is terminated. 

If the transmission error rate is high, you can increase the number to a value 

greater than 5. 

MODE 

Use the MODE subcommand to change the transfer mode. The TFTP transfer 

mode determines how the data bits are transmitted. 

►► 

MOde 

NETASCII 

OCTET 

►◄ 

OPEN 

Operands 

NETASCII 

Sets the mode to ASCII. In NETASCII mode, data is transferred in ASCII. This 

is the default. 

OCTET 

Sets the mode to Image (binary). In OCTET mode, all data is treated as raw 

8-bit bytes. No conversion is performed on the bytes. 

If you did not connect to a foreign host when you invoked the TFTP command, 

you must open a connection to a foreign host before you can transfer files. Use the 

OPEN subcommand to connect to the desired host. 

►► Open hostname ►◄ 

Operands 

hostname 

Specifies the internet host to which you are transferring files. Specify the 

foreign host by its internet host name: 

internet-hostname 

or by its dotted-decimal internet address: 

nnn.nnn.nnn.nnn 

Usage Notes 

v If the internet host name parameter of the TFTP command is not specified, you 

enter the TFTP command shell. To identify the desired host, use the OPEN 

subcommand. See “TFTP Command” on page 85 for more information. 


PUT 

Use the PUT subcommand to send a file to the foreign TFTP server. 


►► PUt localfile foreignfile ►◄ 

Operands 

localfile 

Specifies the name of the local file to be transferred to the foreign host. The 

localfile is specified by filename.filetype.filemode or by filename.filetype. The default 

filemode is A. 

foreignfile 

Specifies the name of the file to be created on the foreign host. 

The file is transferred using the currently selected transfer mode. See “MODE” on 


QUIT 

Use the QUIT subcommand to end the TFTP command. following format. 

►► QUIt ►◄ 

Operands 

The QUIT subcommand has no parameters. 

REXMIT 

Use the REXMIT subcommand to change the time-out value for each packet. 

►► 

REXmit 

5 

number_of_seconds 

►◄ 

Operands 

number_of_seconds 

Specifies the number of seconds TFTP waits before retransmitting a packet. The 

default value is 5 seconds. 

Usage Notes 

v When TFTP sends a packet for which it expects a response packet from the 

foreign TFTP server, a timer is set, as specified by the REXMIT command. If the 

time interval expires before the response packet is received, the original packet is 

retransmitted. 

v When the packet has been retransmitted the maximum number of times (as 

specified by the MAXPKT command) and nothing is received from the foreign 

TFTP server, the transfer is terminated. See “MAXPKT” on page 87 for more 

information. 

Chapter 3. Transferring Files Using TFTP 89


v 

You can increase the number_of_seconds value for a connection with a slow 

transmission rate. 

TRACE 

Use the TRACE subcommand to toggle the tracing of TFTP packets. 

►► TRace ►◄ 

Operands 

The TRACE subcommand has no parameters. 

Usage Notes 

v When TRACE is enabled, information about each TFTP packet that is sent or 

received is displayed. The following information about each packet is displayed. 

Field Description 

direction Indicates either Sending or Received. 

(size) Specifies the number of bytes in the packet. 

kind 

Specifies the type of TFTP packet. The TFTP packet types are: 

RRQ Read request 

WRQ Write request 

Data Data packet 

ACK Acknowledgment packet 

Error Error packet 

per-packet-information 

Contains other data contained in the packet. The type of 

information displayed about each packet is: 

RRQ Foreign file name, transfer mode 

WRQ Foreign file name, transfer mode 

Data Block number 

ACK Block number 

Error Error number, error text (if any) 


Chapter 4. Sending and Receiving Electronic Mail 

This chapter describes electronic note and file delivery and also discusses how mail 

is sent to and from other hosts/users on systems connected through TCP/IP or 

Remote Spooling Communication Subsystem (RSCS). In addition, this chapter also 

describes the electronic mail gateway, delivery failures, the OfficeVision ® interface, 

IMAP, and the SMSG interface to the SMTP server. 

You can also use SMTP to transfer Kanji mail messages. For more information 

about using Kanji support with SMTP, see “Using DBCS with Mail” on page 305. 

NOTE and SENDFILE Commands 

Electronic Mail Gateway 

Note: The SENDFILE and NOTE commands are no longer supplied with TCP/IP. 

You can now use the CMS version of SENDFILE and NOTE to send notes 

and files to network recipients. Please refer to the z/VM CMS Command 

Reference for a complete description of the syntax and options for these 

commands. 

Electronic mail services are provided in conjunction with the SMTP virtual 

machine. This virtual machine can be configured by your TCP/IP administrator to 

operate as a mail gateway between TCP/IP network users and users located on an 

RSCS network that is attached to the local host. For example, PROFS users then 

can exchange mail with UNIX users through the VM TCP/IP SMTP gateway. An 

example of such an environment follows: 

B 

RSCS 

D 

A 

TCP/IP Network 

C 

RSCS 

E 

Figure 7. Example SMTP Mail Gateway Environment 

Where: 

A 

B and C 

D and E 

Is the local VM host, running both TCP/IP and RSCS. 

Are hosts attached to host A through an RSCS network. 

Are hosts attached to host A through a TCP/IP network. 

Users on hosts A, B, and C can send mail or files to users on TCP/IP hosts D and 

E using the CMS NOTE and SENDFILE commands, or PROFS interface. The users 

on hosts D and E can send mail to the users on host A using addresses in the 

following format: 

user_id@A.domain 


Sending and Receiving Electronic Mail 

Where: 

user_id Is the user ID of the VM user on host A. 

A.domain Is the TCP/IP host name of host A. 

The users on TCP/IP hosts D and E can send mail to users on RSCS hosts B and C 

using addresses in the following format: 

user_id%RSCSHost@A.domain 

Where: 

user_id Is the user ID of the user on the host. 

RSCSHost Is the name of the RSCS host (B or C). 

A.domain Is the TCP/IP host name of host A. 

Note and File Delivery 

All mail arriving from senders on foreign hosts is delivered to the virtual machine 

of the VM recipient by the SMTP virtual machine. Normal VM processing places 

the mail in the virtual reader of the addressee. This mail can be read using 

OfficeVision or traditional CMS functions such as RDRLIST and PEEK. See the 

z/VM CMS Command Referenc e for information on manipulating electronic mail 

using CMS. 

SMTPQUEU 

The following command, issued from the CMS command line, checks any mail that 

SMTP is delivering or waiting to deliver. 

Format 

►► SMTPQUEU ►◄ 

There are no operands for this command. 

SMTPQUEU causes the SMTP virtual machine to deliver a piece of mail that lists 

the mail queued for delivery at each site. The mail list is spooled to the user that 

issued the SMTPQUEU command. 

If mail cannot be delivered to the recipients, SMTP returns a copy of the mail to 

the sender with an explanation of why it cannot be delivered. SMTPQUEU queries 

the first SMTP server defined with the SMTPSERVERID statement in the TCPIP 

DATA file, or user ID SMTP on this system if none is defined in TCPIP DATA. 

Undelivered Notes 

When the SMTP virtual machine cannot deliver a piece of mail, a nondelivery note 

or an unknown recipient note is forwarded to the sender of the mail explaining the 

reason for nondelivery. Nondelivery can occur for several reasons. For example, a 

destination host may not be known, or the recipient may not have a user ID on the 

destination host. 

Nondelivery Note 

If a piece of mail cannot be delivered, the body of the original piece of mail is 

returned as part of the nondelivery notification. 


Figure 8 is an example of a nondelivery note. 

Date: Fri, 8 Jan 93 08:23:54 EST 

From: SMTP@VM1.ACME.COM 

To: DANIEL@VM1 

Subject: Undeliverable Mail 

VM1.ACME.COM unable to deliver following mail to recipient(s): 

 

VM1.ACME.COM unable to connect for 3 days to host: 

SMTP-GATEWAY.IBM.COM 

** Text of Mail follows ** 

Date: Tue, 5 Jan 93 08:22:36 EST 

From: 

To: 

Subject: ACME iron birdseed 

Matt, 

The shipment of ACME iron birdseed was shipped last Thursday. Please 

advise me if you have not received it, and I’ll try to track it down. 

Also, your ACME giant rock catapult is on back order; another customer 

bought the last one yesterday. 

Daniel 


Figure 8. Example of a Nondelivery Note 

Unknown Recipient Note 

If a recipient is unknown at the destination host, the destination host does not 

accept the mail for delivery, and a nondelivery notification is forwarded to the 

sender. 

Figure 9 is an example of an unknown recipient note. 

Date: Mon, 15 Feb 93 13:32:12 EST 

From: SMTP@VM1.ACME.COM 

To: DANIEL@VM1 

Subject: Undeliverable Mail 

VM1.ACME.COM unable to deliver following mail to recipient(s): 

 

VM1.ACME.COM received negative reply from host: 

SMTP-GATEWAY.IBM.COM 

** Text of Mail follows ** 

Date: Tue, 16 Feb 93 08:22:36 EST 

From: 

To: 

Subject: Your retirement 

George, 

I recently learned that you will soon be retiring. I just wanted to 

wish you best of luck and thanks for all the great work you have done. 

You were a great asset to your company, and I’m sure they will miss you. 

Daniel 

Figure 9. Example of an Unknown Recipient Note 

Chapter 4. Sending and Receiving Electronic Mail 93


Using OfficeVision Without OfficeVision Extended Mail Installed 

PROFS/OfficeVision is an electronic mail interface for VM users. OfficeVision can 

send and receive electronic mail from users on TCP/IP networks with OfficeVision 

Extended Mail. For more information about using OfficeVision Extended Mail, see 

PROFS Extended Mail User’s Guide and Installation Manual. 

Contact your systems administrator to see if OfficeVision Extended Mail is 

installed at your site. 

Note: Installation of OfficeVision Extended Mail is recommended. 

A limited OfficeVision to SMTP interface is provided for sites that do not have 

PROFS Extended Mail installed. OfficeVision users can prepare mail for TCP/IP 

network recipients by including the SMTP virtual machine as one of the recipients 

of the mail. TCP/IP network recipients are specified through a special command 

within the PROFS note. 

Specifying TCP/IP Recipients 

When using OfficeVision, you must specify the addresses of RSCS recipients in the 


hostname(user_id) 

Where: 

hostname 

user_id 

Is the host name of the recipient. 

Is the user ID of the recipient. 

This format conforms to the specifications of local and RSCS network addresses, 

when you are using OfficeVision directly. 

You enter the TCP/IP network address using a .ddn command. The following list 

describes how to use the .ddn command. 

v 

Specify TCP/IP network addresses using the .ddn command, as shown in the 

following examples. 

v 

v 

v 

v 

v 

Note: The host and user ID pairs may be specified in either one of the following 

two formats. 

.ddn TcpHost(TcpUserid) 

.ddn TcpUserid@TcpHost 

Host names and user IDs can have more than 8 characters. The case (upper or 

lower) of the TCP/IP network addresses is preserved. 

Code .ddn commands starting in column 1, like all other OfficeVision dot 

commands. 

Specify multiple addresses with a single .ddn command. At least one blank 

space must separate each pair of addresses, as shown in the following example. 

.ddn TcpHost1(TcpUserid1) TcpUserid2@TcpHost2 

Code as many .ddn statements as necessary. The following example shows a 

group of three .ddn statements. 

.ddn TcpHost1(TcpUserid1) TcpHost2(TcpUserid2) 

.ddn TcpUserid3@TcpHost3 TcpUserid4@TcpHost4 

.ddn TcpHost5(TcpUserid5) TcpUserid6@TcpHost6 

Do not place text from your note on the same line with a .ddn command in 

column one. This text would be mistakenly interpreted as additional addresses. 


v No embedded blanks can appear within a TCP/IP address. 

v PROFS does not convert addresses specified on the .ddn command line to 

uppercase. 

v .ddn commands are not removed from the text of the note, when the note is sent 

to other PROFS users on the local or RSCS attached systems. The .ddn 

commands are removed from copies sent to the TCP/IP network recipients. 

v If you resend a note with .ddn commands to SMTP, all of the recipients specified 

on the .ddn command receive a copy of the mail. 

v SMTP ignores .ddn commands in a forwarded note. 

Example of Sending a Note Copy to SMTP 

OfficeVision does not deliver the mail to the TCP/IP network recipient; you must 

send a copy of the PROFS note to the SMTP virtual machine. SMTP reads the 

addresses of the recipients from the OfficeVision note and delivers the note to each 

recipient. For example, 

E34 

Send A Note 

Send to: smtp user2 system3(user1) 

From: MyName 

Subject: (U) 

00001 .ddn yktvmv.watson.ibm.com(user20) user10@ytkvmv.watson.ibm.com 

00002 

00003 ...Text of note goes here... 

00004 

00005 

00006 

To verify that SMTP receives a copy of the mail that you send, specify the address 

of the SMTP virtual machine in the Send To: field of the note, or with a .cc or .ad 

command. 

The address of the SMTP virtual machine is SMTP, unless your system 

administrator tells you otherwise. 

Note Delivery 

When SMTP receives a note from a OfficeVision user, the note is rewritten with a 

SMTP mail header. The note is also placed in batch SMTP format. 

If any of the TCP/IP addresses specified are invalid, SMTP sends an error message 

to the PROFS user. This error message includes the batch SMTP version of the 

PROFS note. If the TCP/IP addresses are valid, but the mail cannot be delivered, 

the PROFS user receives an error message of the type described in “Undelivered 

Notes” on page 92. 

Using IMAP to Access Electronic Mail 


If you are authorized to access mail from an installation that is utilizing the z/VM 

IMAP server support, you as a mail user can use an IMAP client to access your 

mail that is residing in the IMAP mailstore on z/VM. This permits you, (using a 

″client″ email program) to access your mail as if it were local. For example, email 

stored on the z/VM IMAP server can be manipulated from a desktop computer at 

home, a workstation at the office, or a laptop computer while away on business 

without the need to transfer messages back and forth. 

In order to access mail from an IMAP server, the following needs to take place: 

v The user (client) must be enrolled into the IMAP Mailstore. 



v 

The client email software must be configured to recognize the IMAP server in 

order to access the message folders. 

You will need to contact your TCP/IP administrator in order to be enrolled as an 

IMAP user and can read further about IMAP in the TCP/IP Planning and 

Customization. You will also need to refer to your particular email client’s 

documentation on how to access your mail folders. 

Using the SMSG Interface to SMTP 

SMSG Commands 

The VM Special Message Facility (SMSG) command provides an interactive 

interface to the SMTP virtual machine to perform general user tasks, such as: 

v 

v 

Querying the SMTP mail delivery queues as well as the operating statistics of 

the SMTP virtual machine 

Performing privileged system administration tasks, such as rebooting or shutting 

down the SMTP virtual machine and enabling or disabling various tracing and 

debugging options. 

Note: There is a privileged user SMSG command set designed for system 

administration tasks which are located in the TCP/IP Planning and 

Customization. Responses to commands are sent back to the originator of the 

command using CP MSG commands (or CP MSGNOH commands if SMTP 

is running with CP privilege class B). 

Use the SMSG command for general user queries for the mail delivery queues and 

the operating statistics of the SMTP virtual machine. 

►► SMSG serverid HElp 

QUeues 

STats 

►◄ 

Operands 


Note: Only the uppercase letters of each command are required. 

serverid 

Specifies the user ID of the virtual machine running the VM SMTP server. 

HElp 

Provides a list of valid SMSG commands accepted by SMTP. 

QUeues 

Provides a list of mail queued on the various SMTP mail delivery queues. 

STats 

Provides operating statistics about the SMTP virtual machine. These statistics 

include: 

v The date that SMTP was last booted 

v The number of spool files in SMTP’s RDR 

v 

v 

The number of spool files in SMTP’s RDR in HOLD status (these spool files 

are too big for SMTP to process) 

The number of files on SMTP’s 191 minidisk

Examples 

v 

v 

v The percent of disk space in use on SMTP’s 191 minidisk 

v The statistics about mail handled by SMTP over the past two days. These 

statistics include: 

– The number of pieces of mail that arrived over tcp connections 

– The number of pieces of mail that arrived from spool (from local or RSCS 

senders) 

– The number of pieces of mail generated in response to requests to 

VERBose batch SMTP connections 

– The number of pieces of mail generated to return error mail to the sender 

– The number of pieces of mail delivered to local recipients 

– The number of pieces of mail delivered to recipients on the RSCS network 

– The number of pieces of mail delivered to recipients on the TCP/IP 

network 

– The number of TCP connections opened through which mail was received 

– The number of TCP connections opened through which mail was 

delivered 

To get a list of queued mail on the SMTP mail delivery queues, enter: 

smsg smtp qu 

Ready; T=0.01/0.01 10:46:13 

* From SMTP: ----- Mail Queues ----- 

* From SMTP: Spool Queue: 0 

* From SMTP: Undeliverable Queue: 0 

* From SMTP: --- Resolver Queues --- 

* From SMTP: Process Queue: 0 

* From SMTP: Send Queue: 0 

* From SMTP: Wait Queue: 1 

* From SMTP: Retry Queue: 1 

* From SMTP: Completed Queue: 0 

* From SMTP: Error Queue: 0 

Receiving Electronic Mail on VM 

To obtain statistic information about the SMTP virtual machine, enter: 

smsg smtp stat 

Ready; T=0.01/0.01 10:46:37 

* From SMTP: Last Up Time: Mon, 13 Dec 93 09:11:30 EST 

* From SMTP: Spool Files : 0 Held: 0 

* From SMTP: Disk Files : 6 Full: 01% 

* From SMTP: Statistics : 12/23 12/22 12/21 12/20 

* From SMTP: From TCP : 23 45 44 50 

* From SMTP: From Spool : 1 3 7 36 

* From SMTP: BSMTP Logs : 10 22 22 24 

* From SMTP: Error Mail : 2 4 3 8 

* From SMTP: To Local : 65 153 148 166 

* From SMTP: To RSCS : 0 0 0 4 

* From SMTP: To TCP : 0 1 6 30 

* From SMTP: Passive Opns: 22 43 45 50 

* From SMTP: Active Opens: 0 1 5 13 


When a CMS user receives electronic mail transmitted over a TCP/IP network, it is 

held for the user in their virtual reader until the user acts on it. If the TCPIP DATA 

file has been set up with SMTPSERVERID definitions for the SMTP server(s), CMS 

productivity aids that manipulate reader files will recognize the mail’s true origin 

as other than the local SMTP userid. RECEIVE and PEEK will issue messages with 

the domain name origin of the mail. For RECEIVE, this message is limited to 240 



characters and will be truncated if the domain name causes the message text to 

exceed that limit. For PEEK, this message is limited to the user’s defined screen 

width and will be truncated if the domain name causes the message text to exceed 

that limit. For electronic mail received with the LOG option, the user’s NETLOG 

file will also contain the domain name of the originator. 

The origin of TCP/IP-based e-mail is also identified in the User and Node columns 

of the RDRLIST panel. Because these fields are each limited to eight characters, this 

origin information is divided into user and host domain information. Still, 

truncation of these values is likely, and is performed as described in the next 

section. 

The most widely-used form of an origin address is: 

user@host.domain 

The RDRLIST “Node” value is obtained from the host.domain portion of the origin 

address. This information is tokenized using the periods (.) in this information as 

delimiters, and the displayed “Node” value is the most complete string of 

unaltered tokens that can be represented using eight characters. If host is itself 

greater than eight characters, its left-most eight characters of are displayed. 

The RDRLIST “User” value is obtained from the user portion of the origin address 

that precedes the “@” sign. If user is greater than eight characters long, its left-most 

eight characters are displayed in the “User” field. However, if user contains any 

periods (.), this value is instead tokenized and then displayed in the same fashion 

as is the host.domain information. 

If mail is sent using source routing, the origin address contains additional 

information, and would be similar to: 

otherhost.other.domain.:user@host.domain 

If such an address is encountered, data to the left of the last colon (:) present is 

discarded, and the RDRLIST “User” and “Node” values are obtained from the 

remaining origin address information, as previously described. 

It is also possible for the origin address to include a percent (%) sign, and be of the 

form: 

user%host@domain 

If an address of this kind is encountered, the “@” sign is effectively replaced with a 

period (.), and the resulting user and host.domain values are processed to obtain the 

RDRLIST “User” and “Node” values in the usual way. 

Here are some examples of domain name addresses and the resulting “User” and 

“Node” information that would be displayed on the RDRLIST panel: 

john.doe%system1@vnet.ibm.com 

becomes User: john.doe 

and Node: system1 

joneswk@gny1vm.vnet.ibm.com 

becomes User: joneswk 

and Node: gny1vm 

Tom_Duffington@arbitrary_host.isp.com 

becomes User: Tom_Duff 

and Node: arbitrar 



music.marist.edu:urmm@vm.marist.edu 

becomes User: urmm 

and Node: vm 

pink.floyd@darkside.moon.com 

becomes User: pink 

and Node: darkside 

p.t.barnum@big.top.circus.com 

becomes User: p.t 

and Node: big.top 




Chapter 5. Logging On to a Foreign Host 

TELNET Command 

The Telnet and TN3270 protocols provide a standardized interface that allows 

fullscreen and linemode terminal oriented processes on hosts that support TCP/IP 

to communicate with each other. 

This chapter describes the following subjects: 

v Using the TELNET Command 

v Using the TELNET Function Keys 

v Using the TELNET Subcommands 

v Sending ASCII Control Characters to a Host in Line Mode. 

Use the TELNET command to log on to a foreign host supporting TCP/IP. 

►► 

TELNET 

foreign_host 

HELP 

23 

port_number 

( Options 

►◄ 

Options: 

Linemode Firewall TRanslate filename Record 

Operands 

foreign_host 

Specifies the name or internet address of the foreign host. 

If you do not specify the name or internet address of the foreign host, you are 

prompted for the foreign_host. 

port_number 

Specifies the port number to which you want to connect on the foreign host. 

When connecting to a non-TELNET port, the data exchange must follow the 

protocol recognized by the other port. The default is well-known port 23. 

Linemode 

Indicates the logon operation. LINEMODE uses the line mode and prevents 

operation in the transparent (TN3270) mode. 

In line mode, the foreign host’s output is displayed on your screen one line at 

a time, without full-screen capabilities. In transparent (TN3270) mode, the 

foreign host’s full-screen capabilities are functional on your local terminal. 

Firewall 

Specifies that a connection is to be made to a host in transparent (TN3270) 

mode through a proxy server. TELNET establishes a line-mode connection to 



Usage Notes 

TELNET Function Keys 

the designated foreign host (the proxy server). You conduct a conversation 

with the proxy server to cause it to establish a connection to the actual 

destination host. TELNET negotiates the termnial type with that host and will 

enter 3270 mode if permitted. 

TRanslate filename 

Specifies a nonstandard translation table file. If this parameter is not specified, 

TELNET searches sequentially for TELNET TCPXLBIN and STANDARD 

TCPXLBIN. If neither is found, TELNET uses the compiled translation table. 

TELNET TCPXLBIN is supplied. The file type is always TCPXLBIN. 

A nonstandard translation table is used in line mode only. 

Record 

Creates a log of interactions with linemode hosts in FILE LOGFILE A. A 

different file can be selected by issuing a CMS FILEDEF for ddname LOGFILE. 

v 

v 

v 

The TELNET command can only be used when logged on to VM using a 

3270-type display device. It cannot be used from a linemode terminal. 

When you use the TELNET command to connect to a foreign host running 

TCP/IP, your foreign terminal session resembles a local terminal session. 

When Telnetting to a 2074 controller the Firewall option must be specified. Also, 

the TN3270E LU name and printer functions cannot be used. 

This section describes the functions that are assigned to Program Function (PF) 

keys when you invoke TELNET in transparent mode and line mode. 

In Transparent (TN3270) Mode 

In transparent (TN3270) mode, the only function key that is available is the PA1 

attention key. The PA1 key in transparent mode indicates that you want to invoke 

a TELNET subcommand. 

For information about how to send the PA1 keystroke to the foreign session, see 

“PA1” on page 104. 

In Line Mode 

Table 8 shows the functions that are assigned to PF keys when you invoke 

TELNET in line mode. 

Table 8. TELNET PF Key Functions 

Key 

PF4-PF12, PF16-PF24, 

PF1, PF13 

PF2, PF14 

PF3, PF15 

Function 

Displays the TELNET subcommand prompt. 

Retrieves the previous input line. 

Scrolls the screen forward halfway. 

Turns off the display of the user information line. Use either of 

these keys before entering your password. 

Note: When you connect to a VM host from a non-VM host, the following applies: 


TELNET Subcommands 

v 

v 

If you invoke TELNET from a non-VM host in order to connect to a VM 

host and your client cannot emulate a 3270 data stream, transparent mode 

will not be possible. Instead, you will be connected to VM as a line-mode, 

start-stop terminal. 

When connected to VM as a line-mode, start-stop terminal, two TELNET 

subcommands have a special meaning: 

– The Abort Output (AO) subcommand causes a single attention to be 

presented. A single attention displays a VM READ. 

– The Interrupting Process (IP) subcommand causes a double attention to 

be presented. A double attention displays a CP READ. 

The TELNET subcommands are described in detail on pages 103 through 105. 

To invoke a TELNET subcommand while you are logged on to the foreign host, 

press the designated PF key. For a list of the designated PF keys, see Table 8 on 

page 102. After you press the PF key, you are prompted to enter the TELNET 

subcommand. TELNET subcommands can be entered in uppercase or lowercase. 

You can use the PA1, AYT, AO, IP, and SYNCH subcommands to communicate 

with the foreign host while you are logged on with the TELNET command. The 

following sections describe these subcommands. 

None of these subcommands have parameters. 


AO 

Use the AO (Abort Output) subcommand to stop displaying output. 

►► AO ►◄ 

The AO subcommand is useful to clear any output that has already been produced 

but has not been displayed on your terminal. 

AYT 

Use the AYT (Are You There) subcommand to query the existence of the 

connection. 

►► AYt ►◄ 

If the connection exists and you are operating in transparent mode, the terminal 

makes a sound. If you are operating in line mode, you receive a message from the 

Telnet server. 

BRK 

Use the BRK subcommand to send a Break or Attention (Attn) keystroke to the 

remote session. 

Chapter 5. Logging On to a Foreign Host 103


►► Brk ►◄ 

HELP 

Use the HELP or ? subcommand to get help. 

►► 

Help 

? 

►◄ 

When you invoke the HELP or ? subcommand, a list of TELNET subcommands is 

displayed. 

IP 

Use the IP (Interrupting Process) subcommand to interrupt the current process 

running on the foreign host. 

►► Ip ►◄ 

The IP subcommand is useful when you want to stop a process that is in a loop, or 

when you want to stop a process that you inadvertently started. 

PA1 

Use the PA1 subcommand to send a PA1 keystroke to the remote session in 

transparent mode. 

►► Pa1 ►◄ 

The PA1 subcommand operates only in transparent mode. The PA1 subcommand 

replaces the PA1 attention key on the foreign host. 

QUIT 

Use the QUIT subcommand to end the TELNET session. 

►► Quit ►◄ 

If you are connected to a foreign host running TCP/IP and you use the QUIT 

subcommand, you are disconnected but not logged off the foreign host. The Virtual 

Telecommunication Access Method (VTAM ® ) application you are accessing 

determines whether you are also logged off from the foreign host. For example, the 

Time Sharing Option (TSO) application disconnects you, but does not log you off. 



When you want to end a logon session with the foreign host, use the logoff 

procedure for the host. 

SYNCH 

Use the SYNCH (Synchronize data path) subcommand to clear the data path. 

►► Synch ►◄ 

The SYNCH subcommand clears the data path to the foreign host, except for any 

TELNET subcommands in the data path. 

Sending ASCII Control Characters to a Host in Line Mode 

In line mode, use the cent sign (¢) or the grave accent (`) to indicate a control 

character. For example, to send Ctrl-p, use either ¢p or `p. 

Other control characters are shown in Table 9. 

Table 9. Control Characters 

Characters 

ASCII Output 

`2 - `6 

1B-1F 

`# FF (DEL) 

`{ 5B (left square bracket) 

`} 5D (right square bracket) 

You use either ¢ or ` before pressing the Enter key to suppress the sending of a 

carriage return and line feed. This function is useful for continuing a line without 

introducing a new line. 

The following is an example of using the ¢ to continue a line. 

PURGE RDR 45 78 99 67 69¢Enter 

56 44 

This function works if the command environment of the foreign host responds to a 

single non-Enter character, without a carriage return and line feed following it. 

Chapter 5. Logging On to a Foreign Host 105


Chapter 6. Monitoring the TCP/IP Network 

This chapter describes how to use the NETSTAT, RPCINFO, and PING commands 

to obtain information from the network. 

v The NETSTAT command displays information about the status of the local host. 

v 

v 

The RPCINFO command displays the servers that are registered and operational 

with any portmapper on your network. 

The PING command determines the accessibility of a foreign node. 

NETSTAT—Displaying Local Host Information 

The NETSTAT command displays the network status of the local host. NETSTAT 

displays information about TCP/IP connections, network clients, gateways, 

devices, and the Telnet server. NETSTAT also drops connections and executes 

commands for users in the TCPIP virtual machine’s OBEY list. For more 

information about the OBEY list, see TCP/IP Planning and Customization. 

This section describes the NETSTAT parameters and contains examples of the 

responses that are displayed as a result of issuing the NETSTAT command with a 

specified parameter. 

Note: NETSTAT commands ALLCONN, CONN, and INTERVAL use host entries 

from the host siteinfo and host addrinfo files. If you use domain name 

server, you must update the host local table and run the MAKESITE 

command for NETSTAT to execute correctly. 

NETSTAT Command Address Interpretation 

The NETSTAT command interprets and displays internet addresses symbolically, if 

possible. If an address cannot be interpreted, it is displayed in dotted decimal 

notation. Unspecified addresses are displayed as an asterisk (*). 

Known port numbers are symbolically displayed. Port numbers that are not known 

to the network are displayed numerically. A socket is displayed as an internet 

address, followed by two periods (..) and a port number. 

NETSTAT Command 

Use the NETSTAT command to display network status of the local host. 


Monitoring the TCP/IP Network 

►► 

NETSTAT 

▼ 

Option 

Command 

(1) 

(SELect 

▼ 

Filter 

►◄ 

Option: 

COnn 

(2) (3) 

(3) 

ALL 

(2) (3) 

ALLConn 

ARp ipaddress 

ALL 

CLients 

DEvlinks 

DOS 

FILTers 

(4) 

Gate 

Help 

? 

HOme 

* 

IDENTify 

ipaddress 

(2) (3) 20 

Interval 

seconds 

LEVel 

POOLsize 

SOCKets 

(2) 

TCp serverid 

(5) 

TELnet 

Up 

Notes: 

1 Only user IDs with TCP/IP OBEY command authorization can use command operands. 

2 Only ALLCON, CONN and TCP are valid with INTERVAL. 

3 The userid filter is valid with ALL, ALLCONN, CONN, and INTERVAL. 

4 The ipaddress filter is only valid with GATE. 

5 The ldev filter is only valid with TELNET. 



Command: 

| 

BLock ipaddress 

(1) 

CP cp_command 

DELarp ipaddress 

DRop conn_num 

OBEY ▼ statement 

RESETDOS 

RESETPool 

UNBlock ipaddress 

Filter: 

(2) 

ipaddress 

(3) 

ldev 

(4) 

userid 

Notes: 

1 All data that follows the CP keyword is used as CP command input. 

2 The ipaddress filter is only valid with GATE. 

3 The ldev filter is only valid with TELNET. 

4 The userid filter is valid with ALL, ALLCONN, CONN, and INTERVAL. 

Note: The minimum abbreviation for each parameter is shown in uppercase 

letters. 

Operands: 

ALL 

Displays information about all TCP/IP connections. This option is useful for 

debugging the TCPIP virtual machine. For more information about maintaining 

the TCPIP virtual machine, see TCP/IP Planning and Customization. 

Displays the following information for UDP sockets being used for: 

v Outgoing Multicast Data 

v 

– the time-to-live value 

– whether datagrams are sent to loopback 

– the IP address of the link on which the datagrams are sent 

Incoming Multicast Data 

– the multicast groups (by IP addresses) for which data is being received. 

– the IP address of the associated link 

ALLConn 

Specifies that information about connections in either the “closed” or 

“time-wait” state should be provided, in addition to that for active TCP/IP 

connections (that is, connections that are not in either of these states). 

Chapter 6. Monitoring the TCP/IP Network 109


ARp ipaddress 

Displays the ARP cache entry for the designated IP address or set of IP 

addresses. To display entries for multiple IP addresses, specify the last token of 

the IP address as an asterisk (*). For example, an ipaddress value of 9.130.48.* 

displays ARP cache entries for IP addresses from 9.130.48.0 through 

9.130.48.255, whereas 9.* displays ARP cache entries for network 9. Specifying 

all or a single asterisk * displays all ARP cache entries. 

Notes: 

1. Entries for network adapters that maintain their own ARP cache are 

displayed after those that are maintained within the TCP/IP server. The 

time at which TCP/IP last obtained adapter-maintained data precedes these 

types of entries. 

2. The TCP/IP server requests adapter-maintained ARP data upon each 

NETSTAT ARP invocation. This data is not displayed for an initial 

NETSTAT ARP command. To display current adapter-maintained ARP data, 

issue at least two NETSTAT ARP commands, in sequence. 

ARp ALL 

Displays the ARP cache entry for all IP addresses. An asterisk (*) can be used 

for this purpose as well. 

BLock ipaddress 

Ignores incoming traffic from the designated IP address or set of IP addresses. 

To block traffic from multiple IP addresses, specify the last token of the IP 

address as an asterisk (*). For example, an ipaddress value of 9.130.48.* blocks 

traffic from IP addresses from 9.130.48.0 through 9.130.48.255, whereas 9.* 

blocks traffic from network 9. 

| 

| 

| 

Note: You should exercise care when selecting IP addresses which are to be 

blocked. It is possible to block one’s own IP address, resulting in 

unpredictable behavior. 

CLients 

Displays the following information about each client: 

v Authorization, as known by the TCP/IP server; possible values are: 

Autologged 

Informed 

Monitor 

Probed 

No-garbage-collect 

Client is listed in the AUTOLOG list, so can 

be autologged by the TCP/IP server. 

Client is listed in the TCP/IP INFORM list; it 

may receive error notifications. 

Client is listed in the TCP/IP OBEY list; it 

can issue TCP/IP monitor command 

requests that should be obeyed. 

Client supports connection probe notices. 

Resources in use by this client will not be 

affected by TCP/IP “garbage collection” 

activity. 

v Notes handled by the client 

v Elapsed time since the client was last used 

v Elapsed time since the client was last forced (applies only to clients in the 

AUTOLOG list) 

v VMCF error count 

COnn 

Displays the following information about each active TCP/IP connection: 

v User ID 



v 

v 

v 

v 

Connection number 

Local socket 

Foreign socket 

Connection state 

TCP/IP considers a connection to be active if it is not in a “closed” or 

“time-wait” state. 

CONN is the default parameter. 

Note: In a Secure Socket Layer (SSL) session, there are two connections — the 

connection from the remote client to the security server and the 

connection from the security server to the application server. For each of 

these connections, the connection number for the partner connection of 

the secure session is displayed on the next line. 

CP cp_command 

Specifies a CP command to be issued by the TCP/IP server; all data that 

follows the CP parameter is construed to be part of the CP command. For 

example, to close the console of the TCPIP virtual machine and send this 

output to a specific user ID, use this NETSTAT command: 

netstat cp spool cons close to userid 

Up to 512 bytes of the CP command response are displayed by the NETSTAT 

command. 

| 

| 

| 

| 

| 

Note: CP commands can be used only by privileged TCP/IP users, as 

identified by the TCP/IP server’s OBEY statement. For more information 

about listing user IDs with the OBEY statement, see TCP/IP Planning and 


DELarp ipaddress 

Deletes the ARP cache entry for the designated IP address or set of IP 

addresses. To delete entries for multiple IP addresses, specify the last token of 

the IP address as an asterisk (*). For example, an ipaddress value of 9.130.48.* 

deletes ARP cache entries for IP addresses from 9.130.48.0 through 9.130.48.255, 

whereas 9.* deletes ARP cache entries for network 9, and * deletes all ARP 

cache entries. 

Notes: 

1. The DELARP command can be used only by privileged TCP/IP users. For 

more information about listing user IDs with the OBEY statement, see 

TCP/IP Planning and Customization. 

2. Adapter-maintained ARP entries cannot be deleted using the NETSTAT 

DELARP command. 

DEvlinks 

Displays the following information about the devices and links defined for the 

TCP/IP virtual machine: 

v Device name 

v Device type 

v Status 

v Queue size 

v Address 

v Link name 

v Link type 

v Net number 



| 

| 

| 

| 

v 

v 

v 

v 

v 

Multicast specific information 

Broadcast capability 

QDIO port name and router type 

HiperSockets port name 

CLAW interface information 

The Multicast Specific field is significant only for multicast-capable links. If a 

link is being used to receive multicast data, then all the multicast groups, and 

the counts of receivers for each multicast group are displayed. 

Some fields of the DEVLINKS display are device-dependent. These exceptions 

are described in the list that follows. 

Address 

The base address is displayed for all devices, except IBM Token-Ring 

LAN System (ILANS) and Ethernet LAN System (ELANS). For ILANS 

and ELANS devices, the control port address is displayed. 

Status 

Some device drivers do not provide device-specific status. For these 

devices, possible status values are: 

Active 

The device is started. 

Inactive 

The device is not started. 

| 

| 

| 

| 

| 

| 

| 

| 

The LAN Channel Station (LCS), ILANS, and ELANS drivers provide 

information about the progress of their initialization procedure. This 

information can be useful when TCP/IP server initialization problems 

are being addressed. For these types of devices, the status field 

displays Ready when the initialization process is complete; if these 

devices are not started, the status field displays Inactive. 

Net Number 

This is an integer that identifies the relative adapter number of a 

network adapter within an LCS device, for which a link is defined. The 

value is 0 for the first adapter in the LCS, 1 for the second adapter, and 

so on. This field is significant only for links defined for LCS devices. 

DOS 

Displays information about Denial-of- Service attacks. For each attack detected, 

it displays the following information: 

v 

v 

v 

v 

v 

v 

v 

The name of the attack 

Up to seven IP addresses from which the attack was launched. (For Fraggle, 

Smurf-IC, Smurf-OB, and Smurf-RP, the IP address is spoofed to be the 

address of the victim of the attack. Other denial-of-service attacks may also 

spoof the source IP address to be the address to be something other than the 

address of where the attack originated.) 

An IP address of * to represent any additional IP addresses that are not 

already displayed. 

The number of attacks detected per IP address. 

The elapsed time since the first attack was detected. 

The duration of the attacks. 

The maximum number of half-open connections that are allowed. See the 

″PENDINGCONNECTIONLIMIT″ configuration statement in the TCP/IP 

Planning and Customization for more information. 

DRop conn_num 

Drops the TCP/IP connection specified by conn_num. You determine the 



connection number to be dropped from the CONN column of the NETSTAT 

CONN or NETSTAT TELNET display. If you drop the “passive open” 

connection for a server, that server will immediately reissue an “open” request. 

Note: The DROP command can be used only by privileged TCP/IP users. For 



FILTers 

Displays information about blocked IP addresses. For each blocked address or 

set of addresses, it provides the following information: 

v The IP address 

v The number of packets discarded 

v How long the block has been in effect 

v How long ago the last packet from the IP address was discarded 

Gate 

Displays information about gateways (dynamic routes) known by the TCP/IP 

server. The following information is displayed for each gateway: 

v Address of the network 

v First hop address 

v flags 

U The route is up. 

G The route is to a gateway 

H The route is to a host rather than to a network. 

C The route was created dynamically by a redirect. 

M The route was modified dynamically by a redirect. 

S The route is a static route. Only routes defined using the GATEWAY 

configuration statement are flagged as static. 

v Link name used by the first hop 

v Packet size used by the first hop 

v Subnet mask and subnet value 

Help 

? 

Displays brief help information about the NETSTAT command and its 

operands and parameters. 

HOme 

Displays the HOME list known by the TCP/IP server; an internet address and 

link name are displayed for each entry of the HOME list. For more information 

about the HOME list (and the HOME statement), see TCP/IP Planning and 


IDENTify ipaddress 

Produces information identifying the connections associated with a given IP 

address or set of IP addresses. To select a set of IP addresses, specify the last 

token of the IP address as an asterisk (*). For example, to produce information 

about all IP addresses that begin with 9.148.134, use the operand 9.148.134.*. 

The output from IDENTIFY is intended for programmable use and as such is 

blank delimited rather than formatted in columns. 



Interval seconds 

Initiates a full screen display of TCP/IP connections. The screen is updated 

every seconds seconds; the default is 20 seconds. Information may be sorted by 

idle time (the default), foreign socket, user ID, bytes out, bytes in, or by 

(connection) state. 

The following information is given for each connection: 

v User ID 

v Bytes sent on the connection 

v Bytes received on the connection 

v Local port 

v Foreign socket 

v Connection State 

v Idle time (hh:mm:ss) 

The number of TCBs in use is displayed at the bottom of the screen. 

PF Key Settings for the Interval display screen are as follows: 

PF 1 Usr Sort by User ID 

PF 2 Sock Sort by Foreign Socket 

PF 3 Quit Exit 

PF 4 BOut Sort by Bytes Out (bytes sent on a connection) 

PF 5 BIn Sort by Bytes In (bytes received on a connection) 

PF 6 St Sort by Connection State 

PF 7 Up Scroll Up (Backward) — when more than one screen of 

information is available for display. 

PF 8 Dwn Scroll Down (Forward) — when more than one screen of 

information is available for display. 

PF 9 Save Save Data in a file (NETSTAT DATA) and Exit 

PF 10 T/B Scroll to Top / Bottom of Data 

PF 11 Ip@ Locate Function; the line at which the cursor is positioned 

becomes the first line of displayed information. 

PF 12 Rfsh Refresh Connection Information 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

Note: The Enter key displays exit capability identical to that displayed by the 

F3 (Exit) PF key. 

LEVel 

Displays the processor type, z/VM system level, and TCP/IP system level. 

OBEY statement 

Processes one or more TCP/IP server configuration statements as if they had 

been entered in a file and used as the object of an OBEYFILE command. All 

data that follows the OBEY parameter is processed as part of the statement 

string. The OBEY command is subject to the considerations described in 

TCP/IP Planning and Customization for use of the OBEYFILE command. In 

addition, the length of the OBEY command operand is limited to roughly 240 

characters, so not all configuration changes can be made using this command. 

Whenever you add or change a configuration statement using the OBEY 

command, be aware that the existing statement is replaced. Therefore, you 

must supply the entire statement, not just the new or changed portions. 

When there is a problem with OBEY, file PROFILE TCPERROR is sent to your 

reader containing a description of the error and the following error message is 

displayed: 

Configuration error. Details are in PROFILE TCPERROR. 



| 

| 

| 

| 

| 

| 

| 

Note: The OBEY command can be used only by privileged TCP/IP users, as 

identified by the TCP/IP server’s OBEY statement. For more information 

about this facility, see TCP/IP Planning and Customization. 

POOLsize 

Displays information about free pool control block and data buffer pools. The 

following information is displayed for each free pool element: 

v Name of the free pool element. 

v Number of elements allocated at server initialization. 

v Number of elements available for use. 

v “Low water mark” for this element pool; this is the fewest number of 

elements that have been available since TCP/IP was started. 

v Permit size calculated for this element. If the number of elements for a pool 

drops below the permit size, TCP/IP considers the pool to be running low. 

For more information about the free pool, see TCP/IP Planning and 


RESETDOS 

Resets the data displayed for the Denial-of-Service (DOS) attacks. 

Notes: 

1. The RESETDOS command can be used only by privileged TCP/IP users. 

Such users are identified with the TCP/IP OBEY statement. For more 

information about listing user IDs with the OBEY statement, see TCP/IP 

Planning and Customization. 

RESETPool 

Resets the “informed” message flags for all free pool element pools. This allows 

pool-related notification messages and mail to again be sent. 

When the number of elements for a particular pool drops below its permit size, 

the TCP/IP server sends a message and mail to all users listed in the INFORM 

list, and then sets an “informed” flag for that pool. This flag blocks further 

notifications for the pool, even its number of elements rises above, and then 

again drops below, the permit size. 

Note: The RESETPOOL command can be used only by privileged TCP/IP 

users. Such users are identified with the TCP/IP OBEY statement. For 



SELect filter 

Specifies a character string that is used to limit response information to entries 

associated with a specific: 

v client or server user ID (userid) 

v IP address (ipaddress) 

v logical device number (ldev) 

The value specified for filter can be a complete string, or a partial string 

terminated by an asterisk (*) to select information about multiple entries that 

all begin with filter. 

For example, to select information that corresponds to only the “default” 

gateway route known by TCP/IP, specify the filter value default for a 

NETSTAT GATE command, as follows: 

netstat gate (select default 



You can specify up to six unique filter values, each of which can be up to 16 

characters long. If specified, the SELECT operand and its filter value(s) must be 

the last parameters of the NETSTAT command. 

SOCKets 

Displays information about each client using the socket interface. 

Each set of one or more sockets is preceded in the response by a socket 

descriptor. The descriptor contains the following information: 

Name: The virtual machine User id of the socket set owner. 

Subtask: Identifies the client application 

Path id: The IUCV path identifier 

Pending call: The name of the active socket function, if any. 

| 

| 

The following information is displayed for each socket: 

Sock Is the socket number. 

Type Indicates the socket type, such as stream (TCP) sockets, 

datagram (UDP) sockets, raw sockets, or the special SNMP DPI 

socket type used only by SNMP agents. 

Bound to Shows the address and port to which the socket is bound. 

Unbound TCP and UDP sockets are not displayed by the 

NETSTAT CONN or NETSTAT INTERVAL commands. 

Connected to Shows the address and port to which the socket is connected. 

State Displays the TCP connection state for TCP sockets. For raw 

sockets, the IP protocol number is displayed as well. If the 

State field is blank, the Conn field is also blank. 

Flgs 

Connection flag (displayed for TCP sockets only); possible 

values are: 

A Indicates a connection on the almost accept queue. 

C Indicates a connection on the accept queue. 

L Indicates a listening socket. 

Conn Displays the internal TCP control block (TCB) number used by 

the TCP/IP server for this connection. Conn applies only to 

TCP sockets. If this field is blank, the flag for this connection 

will be an L; this indicates this is a listening socket for which 

the accept queue is full, or for which the TCP/IP server is 

temporarily unable to allocate resources to put a TCB in a 

“Listen” state. Attempts to connect to the port (displayed in 

the Bound to field) are ignored; this allows TCP to retry the 

connection. 

TCp server 

Identifies the TCP/IP Stack server for which status information is to be 

displayed, or to which commands are to be directed. 

TELnet 

Displays the status of the internal Telnet server. 

UNBlock ipaddress 

Allows incoming traffic from the designated IP address or set of IP addresses 

by removing a previously defined filter. The specification must match the 

original definition. 


Up 

Displays the date and time that TCP/IP was started. 

Examples 

This section shows sample responses for various NETSTAT commands, issued with 

a specific operand or set of operands. 

ALL 

The following is a sample of the information that is displayed, in this case for two 

clients after entering NETSTAT ALL. 

VM TCP/IP Netstat Level nnn 

Client: FTPSERVE Last Touched: 2:07:08 

Local Socket: *..FTP-C Foreign Socket: *..* 

BackoffCount: 0 

ClientRcvNxt: 0 

ClientSndNxt: 713933277 

CongestionWindow: 65535 

Local connection name: 1002 

Sender frustration level: Contented 

Incoming window number: 0 

Initial receive sequence number: 0 

Initial send sequence number: 0 

Maximum segment size: 536 

Outgoing window number: 0 

Precedence: Routine 

RcvNxt: 0 

Round-trip information: 

Smooth trip time: 0.000 

Smooth trip variance: 1.500 


More... 

BTP311S6 

SlowStartThreshold: 65535 

SndNxt: 713933276 

SndUna: 713933276 

SndWl1: 0 

SndWl2: 0 

SndWnd: 0 

MaxSndWnd: 0 

State: Listen 

No pending TCP-receive 

---- 

Client: ROUTED Last Touched: 0:00:03 

Local Socket: *..520 

Multicast: TimeToLive: 1 LoopBack: Yes OutgoingIPAddress: * 

MulticastGroup IncomingIpAddress 

-------------- ----------------- 

224.0.0.9 9.130.48.70 

224.0.0.9 9.130.176.198 

224.0.0.9 9.130.248.99 

224.0.0.9 9.130.251.26 

224.0.0.9 9.130.251.18 

Ready; 

ALLCONN 

The following is a sample of the information that is displayed after entering 

NETSTAT ALLCONN. 




Active Transmission Blocks 

User Id Conn Local Socket Foreign Socket State 

---- -- ---- ----- ------ ------- ------ ----- 

FTPSERVE 1005 *..FTP-C *..* Listen 

TCPUSER 1013 HE60..1038 HE51..TELNET Established 

NAMESRV UDP *..DNS *..* UDP 

INTCLIEN 1002 HE60..TELNET HT102..1024 Established 

Ready; 

ARP 


NETSTAT ARP 9.117.* 


Querying ARP cache for address 9.117.* 

Link TR1 : IBMTR: 08005A8B322E IP: 9.117.32.15 

Route info: 8220 

Link TR1 : IBMTR: 0004AC20521C IP: 9.117.32.29 


Link TR1 : IBMTR: 40000057FDBC IP: 9.117.32.249 


Link ETH1 : ETHERNET: 42608C2CE222 IP: 9.117.176.4 

Adapter-maintained data as of: 04/19/01 10:00:59 

LINK OSDQDIO2 : QDIOETHERNET: 10005A998C6B IP: 9.117.176.1 

LINK OSDQDIO2 : QDIOETHERNET: 0004AC7C82F5 IP: 9.117.176.245 

LINK OSDQDIO2 : QDIOETHERNET: 0004AC7C82F5 IP: 9.117.248.157 

Ready; 

BLOCK 


NETSTAT BLOCK 9.130.48.* 


Function performed 

Ready; 

CLIENTS 

The following are examples of the information that is displayed for a client after 

entering NETSTAT CLIENTS. 

For a client with notes handled: 




Current clients: 

Client: FTPSERVE 

Authorization: Autologged 

Notes Handled: Buffer space available, Connection state changed, Data delivered, 

Urgent pending, Other external interrupt received, Timer expired, 

FSend response 

FReceive erro, IUCV interrupt 

Last Touched: 2:20:07 Last Forced: 2:36:59 

Vmcf error count: 0 

Ready; 

For a client with no notes handled: 


Current clients: 

Client: OPERATOR 

Authorization: Monitor, Informed 

Notes Handled: none 

Last Touched: 2:17:43 Last Forced: 2:34:23 

Vmcf error count: 0 

Ready; 

CONN 


NETSTAT CONN. 


Active Transmission Blocks 

User Id Conn Local Socket Foreign Socket State 

---- -- ---- ----- ------ ------- ------ ----- 

FTPSERVE 1002 *..FTP-C *..* Listen 

INTCLIEN 1000 *..TELNET *..* Listen 

INTCLIEN 2102 9.4.5.6:23 9.4.5.6:999 Established 

2023 

SMTP 1001 *..SMTP *..* Listen 

SMTP UDP *..1024 *..* UDP 

PORTMAP UDP *..PMAP *..* UDP 

PORTMAP 1003 *..PMAP *..* Listen 

NAMESRV 1004 *..DNS *..* Listen 

NAMESRV UDP *..DNS *..* UDP 

SSLSERV 2023 9.4.5.6:999 9.1.2.3:1000 Established 

2102 

Ready; 

CP 


NETSTAT CP QUERY TIME. 


CP command output is: 

TIME IS 17:27:58 EST WEDNESDAY 11/18/93 

CONNECT= 00:23:25 VIRTCPU= 000:03.62 TOTCPU= 000:05.79 

CP return code= 0 

Ready; 



Note: You must be a privileged user to use the CP command. 

DELARP 


NETSTAT DELARP 9.130.3.48. 

Note: You must be a privileged user to use the DELARP command. 


1 ARP cache entries deleted for 9.130.3.48 

Ready; 

DEVLINKS 


NETSTAT DEVLINKS. 


| 

| 

| 

Device TOTCP2 Type: CTC Status: Ready 

Queue size: 0 

Address: 03F8 

Link VCTC2 Type: CTC Net number: 0 

Broadcast Capability: Yes 

Multicast Capability: Yes 

Device LCS1 Type: LCS Status: Ready 

Queue Size: 0 

Address: 09E0 

Link ETH1 Type: ETHERNET Net number: 0 



Group 

Members 

----- ------- 

224.67.113.10 3 

225.36.12.9 5 

Link TR1 


Multicast Capability: No 

Ready; 

| 

| 

| 

| 

| 

| 

In the preceding example, the first device indicated is TOTCP2, which is a device of 

type CTC (a Channel-to-Channel device) that has a base virtual address of 03F8. 

There is one link defined for this device, named VCTC2. This link has LAN 

broadcast and multicast capabilities. 

The second device indicated is LCS1, which is a device of type LCS (a LAN Channel 

Station device) that has a base virtual address of 09E0. There are two links defined 

for this device — ETH1, an Ethernet link, and TR1, an IBM Token-Ring link 

(indicated as IBMTR). The Net number (or, relative adapter number) for each device is 

0; this indicates that each of these links are the first such links, of their respective 

type, defined for this device. The first link (ETH1) has LAN broadcast and 

multicast capabilities. There are 3 members in the multicast group 224.67.113.10 

and 5 members in the multicast group 225.36.12.9. The second link (TR1) has LAN 

broadcast capabilities, but is not multicast-capable. 

The status of both of these devices is “Ready”, which indicates they are 

operational. Also, the Queue Size of zero for each indicates that no envelopes are 

queued for output. 




| 

| 

Device IUCV1 Type: SNA IUCV Status: Will retry connect 

Queue Size: 0 Vm Id: SNALNKB Pgm: SNALINK LU: SNALKAO4 

Link IUCVL1 Type: IUCV Net number: 1 



Device IUCV2 Type: SNA IUCV Status: Issued connect 

Queue Size: 0 Vm Id: SNALNKB Pgm: SNALINK LU: SNALKCO4 

Link IUCVL2 Type: IUCV Net number: 1 



Ready; 

| 

| 

| 

In this example, the first device is IUCV1. A connection attempt to the SNALNKB 

virtual machine has failed, as indicated by the “Will retry connect” status. This 

connection will be retried again in 30 seconds. The remote Logical Unit (LU) name 

for this device is SNALKA04. This link has LAN broadcast and multicast capabilities. 

For the second device, IUCV2, the TCP/IP server has issued an IUCV CONNECT. 

This connection is accepted by the SNALNKB virtual machine when the SNA sessions 

to LU SNALKC04 are established. This link has LAN broadcast and multicast 

capabilities. 

For information about the status output for the SNAIUCV and SNALU62 devices, 

see TCP/IP Planning and Customization. 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 


Device DEVHS0 Type: HIPERS Status: Ready 

Queue size: 0 Address: 0520 Port name: HSA0PORT 

Router Type: NonRouter 

Link LINKHS0 Type: QDIOIP Net number: 0 

Broadcast Capability: No 


Group 

Members 

----- ------- 

224.0.0.1 1 

Device DEVOSD0 Type: OSD Status: Ready 

Queue size: 0 Address: 0540 Port name: OSD0PORT 

Router Type: NonRouter 

Link LINKOSD0 Type: QDIOETHERNET Net number: 0 


Multicast Capability: No 

Ready; 

| 

| 

| 

| 

| 

| 

The first device in this example is DEVHS0, which is a device type of HIPERS (a 

HiperSocket device). This device has a base virtual address of 0520, a port name of 

HSA0PORT, and a router type of NonRouter. There is one link defined for this 

device, named LINKHS0, which is a device type of QDIOIP (Queued Direct I/O 

Internet Protocol) that has no LAN broadcast capabilities, but is multicast capable. 

There is one member in the multicast group 224.0.0.1. 



| 

| 

| 

| 

| 

| 

The second device indicated is DEVOSD0, which is a device type of OSD 

(indicating it is an OSA Express Adapter using the QDIO Hardware Facility) at 

base virtual address 0540 with a port name of OSD0PORT. This device is also a 

NonRouter type. One link is defined for this device, named LINKOSD0, which is a 

QDIOETHERNET device type that has LAN broadcast capabilities, but is not 

multicast capable. 

DOS 


NETSTAT DOS. 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 


Maximum Number of Half Open Connections: 2500 

Attacks Elapsed Attack 

Attack IP Address Detected Time Duration 

-------- --------------- --------- --------- --------- 

Fraggle 10.130.248.97 2450 0:08:53 0:02:25 

10.130.248.99 100 0:05:31 0:00:50 

Smurf-OB 10.130.58.253 120 0:18:21 0:00:34 

10.130.58.25 330 0:18:21 0:00:36 

10.32.232.45 165 0:16:43 0:02:32 

10.117.222.18 3 0:08:41 0:00:03 

10.130.249.43 2 0:08:15 0:00:00 

10.130.58.22 2 0:07:49 0:00:01 

10.117.32.30 5 0:06:45 0:01:41 

* 1450 0:05:47 0:04:30 

POD 10.130.58.22 23743 0:01:11 0:01:00 

DROP 


NETSTAT DROP 1002. 


Connection successfully dropped 

Ready; 

Note: You must be a privileged user to use the DROP command. 

FILTERS 


NETSTAT FILTERS. 


Blocked IP addresses: 

Packets Active Last 

IP Address Discarded For Packet 

---------- ---------- ------- ------ 

9.130.48.223 77 0:03:22 0:00:37 

9.130.48.56 9 0:03:22 0:01:21 

Ready; 

GATE 


NETSTAT GATE. 




Known gateways: 

NetAddress FirstHop Flgs Pkt Sz Subnet Mask Subnet Value Link 

---------- -------- ------- ------ ----------- ------------ ---- 

Default 9.67.58.234 UGS Default TRI 

9.0.0.0 U 2000 0.255.255.224 0.67.58.224 TR1 

9.0.0.0 US 1500 0.255.255.224 0.67.58.32 ETH1 

9.0.0.0 S 2000 0.255.255.224 0.67.58.96 SNA1 

Ready; 


NETSTAT GATE with the (SELECT 9.117.68.* option. 


Known gateways: 

NetAddress FirstHop Flgs Pkt Sz Subnet Mask Subnet Value Link 

---------- -------- ------ ------ ----------- ------------ ---- 

9.117.68.10 UHS 1500 HOST GDLVM0 

9.117.68.14 UHS 2000 HOST TCPIP1 

9.117.68.18 HS 1500 HOST TCPIP2 

Ready; 

HELP 


NETSTAT HELP or NETSTAT ?. 




Usage: netstat option/command modifier 

Current information viewable: 

ALL - Everything about a connection 

ALLCONN - With CONN or INTERVAL options, shows 

TIME-WAIT and CLOSED connections 

ARP ip adr- Query ARP entry 

CLIENTS - Current clients 

CONN - Active control blocks 

DEVLINKS - Devices and links 

DOS - Displays Denial-of-Service attacks 

FILTERS - Displays IP addresses being blocked 

GATE - Current known gateways 

HOME - Home address list 

IDENTIFY - Identifies connections with a given IP address 

INTERVAL n- Full screen, real-time, connection display 

LEVEL - TCP/IP software level information 

POOLSIZE - Free pool status 

RESETDOS - Resets data for DOS attacks 

SOCKETS - Socket interface users and their sockets 

TCP server- Displays detailed info about the specified TCP/IP server 

TELNET - Telnet connections and logical devices 

UP - Date and time VM TCP/IP was last started 

Commands available: 

BLOCK adr - Ignore packets from an IP address 

CP command- Issue a CP command 

DELARP adr- Delete ARP cache entry for an IP address 

DROP n - Drop a TCP connection 

OBEY stmt - Changes TCP/IP configuration parameters 

RESETDOS - Resets the data displayed for DOS attacks 

RESETPOOL - Reset record of pool informs sent 

UNBLOCK adr-Process packets from an IP address 

( SELECT select-value1...select-value6 

For ALL CLIENTS CONN GATE INTERVAL TELNET select specific info 

select-value may be a partial string terminated by a ’*’ 

Ready; 

HOME 


NETSTAT HOME. 


Home address list: 

Address 

Link 

------- ------ 

9.67.58.33 ETH1 

9.67.58.225 TR1 

9.67.58.97 SNA1 

IDENTIFY 


NETSTAT IDENTIFY 9.130.57.*: 




9.117.32.29 23 9.130.57.37 1081 INTCLIEN L00E6 DIALED TO YVETTE 0200 

9.117.32.29 23 9.130.57.37 1082 INTCLIEN L00D8 DIALED TO PVM 050C 

9.117.32.29 23 9.130.57.37 1081 INTCLIEN L000B ENABLED 

9.117.32.29 23 9.130.57.37 1081 INTCLIEN L0027 LOGON AS M1GR2S 0009 

9.117.32.29 1501 9.130.57.110 2538 DSOSERV 

9.117.32.29 1501 9.130.57.54 1465 DSOSERV 

9.117.32.29 1501 9.130.57.81 1764 DSOSERV 

INTERVAL 


NETSTAT INTERVAL. The INTERVAL parameter can be used on an IBM 3278 or 

3279 display station, or at a terminal or workstation that is emulating an IBM 3278 

or 3279 display station. 

Note: The Enter key provides exit capability identical to that provided by the F3 

(Quit) PF key. Also note that the INTERVAL option provides a full–screen 

interface for its output as opposed to line-mode. 

11/17/98 VM TCP/IP Real Time Network Monitor 16:13:47 

Bytes Bytes Local Idle 

User Id Out In Port Foreign Socket State Time 

-------- ------- ------- ------ ------------------ ----------- ------- 

INTCLIEN 29009 437 TELNET 9.130.58.10..1076 Established 0:00:00 

ROUTED 31220 1342528 520 *..* UDP 0:00:01 

SMTP 0 0 1038 *..* UDP 0:00:40 

VMNFS 1520212 2446060 2049 *..* UDP 0:01:14 



INTCLIEN 0 0 TELNET *..* Listen 0:07:09 




REXECD 0 0 REXEC *..* Listen 2:52:59 

PORTMAP 533124 829304 PMAP *..* UDP 2:55:50 

VMNFS 0 0 2049 *..* Listen 5:55:19 

FTPSERVE 0 0 FTP-C *..* Listen 14:55:49 

REXECD 0 0 RSH *..* Listen 14:57:32 

DSMSERV 0 0 1500 *..* Listen 20:19:35 

SMTP 0 0 SMTP *..* Listen 20:20:15 

SNMPD 0 0 161 *..* UDP 20:20:15 

SNMPD 0 0 1024 *..* Listen 20:20:16 

PORTMAP 0 0 PMAP *..* Listen 20:20:18 

TCP/IP stack: Default 

Refresh interval: 20 seconds. 

TCBs in Use:14 

1=Usr 2=Sock 3=Quit 4=BOut 5=BIn 6=St 7=Up 8=Dwn 9=Save 10=T/B 11=Ip@ 12=Rfsh 

| 

| 

| 

| 

| 

| 

| 

| 

| 

LEVEL 


NETSTAT LEVEL. 

VM TCP/IP Netstat Level 430 

IBM 9672; z/VM Version 4 Release 3.0, service level 0201, VM TCP/IP Level 430; 

RSU 0201 

Ready; 


| 


OBEY 

The following is a sample of the response to entering NETSTAT OBEY START TR1. 


OBEY command response is: OK 

OBEY return code = 0 

Ready; 

POOLSIZE 


NETSTAT POOLSIZE. 


TCPIP Free pool status: 

Object No. alloc # free Lo-water Permit size 

====== ========= ====== ======== =========== 

ACB 5000 4955 4776 500 

CCB 750 416 416 50 

Dat buf 1200 1149 1097 240 

Sm dat buf 5000 4837 4584 500 

Tiny dat buf 0 0 0 1 

Env 1250 1250 1132 125 

Lrg env 75 74 66 15 

RCB 50 50 50 3 

SCB 2000 1947 1795 133 

SKCB 256 221 210 17 

TCB 5000 4816 4540 333 

UCB 500 488 484 33 

Add Xlate 1500 1478 1 5 

IP Route 3000 2993 1 60 

Segment ACK 100000 99996 99899 5000 

FPSP 25 64 0 54000 

FPSP Total locked pages: 215, Unused locked pages: 64 

TCPIP machine size: 90M, Pools: 59267K, Avail: 8744K, Max block: 8716K 

Ready; 

RESETPOOL 


NETSTAT RESETPOOL. 

Note: You must be a privileged user to use the RESETPOOL command. 



Ready; 

SOCKET 


NETSTAT SOCKET. 




Socket interface status: 

Sock Type Bound to Connected to State Flgs Conn 

==== ==== ======== ============ ===== ==== ==== 

Name: PMAP Subtask: 002a6070 Path id: 1 Pending call: select 

3 Dgram *..PMAP Not connected 

4 Stream *..PMAP *..* Listen L 1039 

Name: SNMPD Subtask: 002254f8 Path id: 3 Pending call: select 

3 Dgram *..3162 Not connected 

4 Dgram YKTVMZ..161 Not connected 

5 Stream *..3225 *..* Listen L 1044 

7 DPI 

Name: TCPMAINT Subtask: 002f52c8 Path id: 6 

3 Stream Not bound Not connected Closed 1011 

5 Dgram Not bound Not connected 

8 Raw Not bound Not connected 1 

9 Raw Not bound Not connected 255 

Name: TCPMAINT Subtask: 002c5268 Path id: 7 

7 Stream *..10000 *..* Listen L 1016 

7 Stream Loopback..10000 Loopback..3232 Established LC 1047 

8 Stream Loopback..10000 Not Connected Closed 1007 

TELNET 


NETSTAT TELNET. 


Internal Telnet server status: 

Conn Status Foreign Host B out B in Logical device status 

---- ------ ------------ ----- ---- --------------------- 

1118 Establshd 9.130.57.67 89606 10125 L0017 DIALED TO PVM 0503 

1115 Establshd 9.82.1.118 1811 161 L00C1 ENABLED 

1067 Listen * 0 0 

1345 Establshd 9.130.58.10 881941 1016232 L00D1 LOGON AS CIBULAMA 0009 

1213 FIN-wait-2 9.185.67.151 162931 967 

A connection in the listen state is always available for an incoming open request. 

UNBLOCK 


NETSTAT UNBLOCK 9.130.48.* 



Ready; 

UP 


NETSTAT UP. 




TCP/IP started at 17:04:15 on 11/18/00 

Ready; 

RPCINFO Command 

The RPCINFO command displays the servers that are registered and operational 

with any portmapper on your network. The RPCINFO command makes a Remote 

Procedure Call (RPC) to an RPC server and displays the results. 

RPCINFO requires SCEERUN LOADLIB to be globally available. You should 

ensure the IBM Language Environment ® can be accessed. It is included in the 

z/VM base. 

►► RPCINFO -p 

host 

-u host prognum 

-t host prognum 

-b prognum versnum 

versnum -n portnum 

versnum 

►◄ 

Operands 

-p host 

Queries the portmapper on the specified host and prints a list of all registered 

RPC programs. If host is not specified, the system defaults to the local host 

name. 

-n portnum 

Specifies the port number to be used for the -t and -u options in place of the 

port number that is given by the portmapper. 

-u host prognum versnum 

Sends an RPC call to procedure 0 of prognum on the specified host using UDP, 

and reports whether a response is received. The variable prognum is the name 

or number of the RPC program. 

-t host prognum versnum 

Sends an RPC call to procedure 0 of prognum on the specified host using TCP, 

and reports whether a response is received. 

-b prognum versnum 

Sends an RPC broadcast to procedure 0 of the specified prognum and versnum 

using UDP, and reports all hosts that respond. 

If you specify versnum (the version number), RPCINFO attempts to call that 

version of the specified program. If you do not specify a version, RPCINFO prints 

error information. 

Note: The version number is required for the -b parameter. 



PING Command 

The PING command sends an echo request to a foreign node to determine if the 

node is accessible. PING uses ICMP as its underlying protocol. 

►► PING host_name 

► 

HELP 

? 

► 

( 

LENGTH 256 COUNT 1 TIMEOUT 10 

LENGTH bytes COUNT echo TIMEOUT seconds 

►◄ 

Note: More than one option can be placed on the PING command line; however, 

the HELP parameter is an exception and cannot be placed on the PING 

command line with other parameters. 

Operands 

host 

Specifies the foreign host to which you want to send the echo request. If you 

omit the host_name, the system prompts you for a host name. The host name is 

either a character-string name or the internet address in the standard format of 


LENGTH bytes 

Sets the number of bytes of the echo request. If bytes is not specified, the 

default of 256 is used. The number of bytes must be between 8 and the 

maximum value determined by large envelope size (lrg_env_size). For more 

information about large_env_size, see TCP/IP Planning and Customization. The 

minimum abbreviation is L. 

COUNT echo 

Sets the number of echo requests that are sent to the foreign host. If echo is not 

specified, the default of 1 is used. The number echo must be between 1 and 2 31 

−1 (2 147 483 647). If echo is 0, the PING command sends echo requests 

continually. The minimum abbreviation is C. 

TIMEOUT seconds 

Sets the number of seconds that the PING command waits for a response. The 

default for seconds is 10. The number for seconds must be between 1 and 100. 

The minimum abbreviation is T. 

HELP or ? 

Provides help information about the PING command. You cannot place the 

HELP parameter on the PING command line with other parameters The 

minimum abbreviation is H or ?. 

| 

| 

| 

| 

| 

| 

| 

Note: When the TCP/IP stack is configured to use equal-cost multipath support, 

and there are multiple equal-cost paths to the destination being pinged, the 

ping results may seem inconsistent because the echo requests will be sent 

out through different interfaces. In the example below, If you ping 10.2.1.3 

twice (or once with a COUNT 2 specified), the first echo request will be sent 

out through LINK1, and the second echo request will be sent out through 

LINK2. 



GATEWAY 

10.2.1.3 = LINK1 4000 HOST 

10.2.1.3 = LINK2 4000 HOST 

Examples 

v Sample of information displayed after invoking the PING command: 

PING : Pinging host HT60 (129.34.10.60). Enter #CP EXT to interrupt 

PING: Ping #1 response took 0.033 seconds. Successes so far 1. 

TRACERTE Command 

Use the TRACERTE command to debug network problems. The Traceroute 

function sends UDP requests with varying Time-to-live (TTL) and listens for 

TTL-exceeded messages from the routers between the local host and the foreign 

host. 

►► TRACERTE ? 

host_name 

Optional Parameters 

►◄ 


MAX 30 TRY 3 PORT 4096 WAIT 5 

( DEBUG 

MAX ttl TRY attempts PORT num WAIT seconds 

Operands 

domain_name 

Specifies the internet host name used to route packets. 

MAX ttl 

Specifies the maximum TTL. The range for valid values is 1 to 255. The default 

is 30. 

TRY attempts 

Specifies the number of attempts. The range for valid values is 1 to 20. The 

default is three. 

PORT num 

Specifies the starting port number. The range for valid values is 2048 to 60000. 

The default is 4096. 

WAIT seconds 

Specifies the number of seconds to wait for a response. The range for valid 

values is 1 to 255. The default is five. 

DEBUG 

Specifies that extra messages are to be printed. 

Examples 

The following are examples using the TRACERTE command: 

v The second hop does not send TTL (Time-to-live) exceeded messages. 

tracerte cyst.watson.ibm.com 

Trace route to CYST.WATSON.IBM.COM (9.2.91.34) 

1 (9.67.22.2) 67 ms 53 ms 60 ms 

2*** 

3 (9.67.1.5) 119 ms 83 ms 65 ms 


4 (9.3.8.14) 77 ms 80 ms 87 ms 

5 (9.158.1.1) 94 ms 89 ms 85 ms 

6 (9.31.3.1) 189 ms 197 ms * 

7 * * (9.31.16.2) 954 ms 

8 (129.34.31.33) 164 ms 181 ms 216 ms 

9 (9.2.95.1) 198 ms 182 ms 178 ms 

10 (9.2.91.34) 178 ms 187 ms * 

v Sometimes packets are lost (hops 6,7, and 10). 

v 

v 

tracerte 129.35.130.09 

Trace route to 129.35.130.09 (129.35.130.9) 

1 (9.67.22.2) 61 ms 62 ms 56 ms 

2*** 

3 (9.67.1.5) 74 ms 73 ms 80 ms 

4 (9.3.8.1) 182 ms 200 ms 184 ms 

5 (129.35.208.2) 170 ms 167 ms 163 ms 

6 * (129.35.208.2) 192 ms !H 157 ms !H 

The network was found, but no host was found. Could not route to that 

network. 

tracerte 129.45.45.45 

Trace route to 129.45.45.45 (129.45.45.45) 

1 (9.67.22.2) 320 ms 56 ms 71 ms 

2*** 

3 (9.67.1.5) 67 ms 64 ms 65 ms 

4 (9.67.1.5) 171 ms !N 68 ms !N 61 ms !N 

Traceroute uses the site tables for inverse name resolution rather than the 

domain name server. If a host name is found in the site table, it is printed along 

with its IP address. For more information about using the site tables, see TCP/IP 


tracerte EVANS 

Trace route to EVANS (129.45.45.45) 

1 BART (9.67.60.85) 20 ms 56 ms 71 ms 

2 BUZZ (9.67.60.84) 55 ms 56 ms 54 ms 

3 EVANS (9.67.30.25) 67 ms 64 ms 65 ms 


| 

| 

| 

| 

| 

| 

Usage Notes 

v To use the TRACERTE command (which uses rawIP functions), you must be a 

privileged TCP/IP user. Such users are identified with the TCP/IP OBEY 

statement. For more information about listing user IDs with the OBEY statement, 

see TCP/IP Planning and Customization. 

v The range of port numbers that the TRACERTE command uses are normally 

invalid; however you can change the starting port number for this range if the 

target host is using a nonstandard UPD port. 

v The TRACERTE function will give unpredictable results if the TCP/IP stack is 

configured to use equal-cost multipath support. With this support, there may be 

multiple paths to a single destination. When TRACERTE is invoked, it will send 

the UDP requests out through the different paths. Since the packets will be 

traveling different paths to the same destination, the responses returned will not 

be for a single path. 




Chapter 7. Authenticating Network Users with Kerberos 

Kerberos is a system that provides authentication service to users in a network 

environment. This chapter describes the Kerberos name structures and Kerberos 

commands. Examples of using the Kerberos commands are also provided in this 

chapter. 

Your Kerberos system administrator can provide you with your Kerberos name 

and password when you register with the Kerberos system. 

For more information about Kerberos, see TCP/IP Programmer’s Reference and 


Understanding Kerberos Name Structures 

Before you use the Kerberos commands, you should be familiar with the structure 

of a Kerberos name. A Kerberos name consists of the following three parts: 

Name Description 

principal name Specifies the unique name of a user (client) or service. 

instance 

realm 

Kerberos Commands 

Specifies a label that is used to distinguish among the variations of 

the principal name. Aninstance allows for the possibility that the 

same client or service can exist in several forms that require 

distinct authentication. 

For users, an instance can provide different identifiers for different 

privileges. For example, the admin instance provides special 

privileges to the users assigned to it. 

For services, an instance usually specifies the host name of the 

machine that provides the service. 

Specifies the domain name of an administrative entity. The realm 

identifies each independent Kerberos site. The principal name and 

instance are qualified by the realm to which they belong, and are 

unique only within that realm. The realm is commonly the domain 

name. 

Note: You must express the realm as a name rather than an address 

number. For example, use tcp.raleigh.ibm.com rather than 

9.67.32.92. 

To use the Kerberos commands, the KERBEROS server must be running on the 

same local domain or realm of one of the hosts on your network. For information 

about how to set up the KERBEROS server and how to use the Kerberos system 

administrator commands and utilities, see TCP/IP Planning and Customization. 

The Kerberos commands for users are: 

Command Function 

KINIT Initiates a session with the Kerberos Authentication System. 


Authenticating Network Users with Kerberos 

Note: The Kerberos database must be on the same realm as the 

client. 

KLIST 

KDESTROY 

KPASSWD 

Lists currently held Kerberos tickets. 

Destroys currently active Kerberos tickets. 

Modifies Kerberos passwords. 

KINIT Command 

Note: The Kerberos database must be on the same realm as the 

client. 

You enter the Kerberos commands at a VM command prompt. The following 

sections contain descriptions and examples of Kerberos commands. 

Use the KINIT command to initiate a session with the Kerberos Authentication 

System. 

►► 

KINIT 

-i -r -v -l 

►◄ 

Operands 

Examples 

-i Prompts you for a Kerberos instance. 

-r Prompts you for a Kerberos realm. 

-v Specifies verbose mode for the Kerberos response. The response contains the 

name of the Kerberos realm, and a status message indicating the success or 

failure of your logon attempt. 

-l Specifies the TTL of the ticket, if the TTL is shorter than the TTL specified in 

the client, server, or database. 

v 

Note: KINIT may not function correctly if the clock on the local host is not 

synchronized with the clock on the host running the Kerberos 

authentication server. 

Information displayed after invoking the KINIT command: 

Kerberos Initialization 

Kerberos name: 

 

password: 

 

v 

An example format for using multiple parameters: 

KINIT 

-irvl 

Note: When you use a Kerberos command with multiple parameters, do not enter 

spaces between the parameters; any entry (parameters) after a space is 

ignored. 


Usage Notes 

KLIST Command 

v 

v 

v 

v 

v 

v 

v 


You must use the KINIT command within the same realm as the database 

(PRINCIPL DAT/PRINCIPL IDX) used by the Kerberos Authentication Server 

(VMKERB). 

The KINIT command attempts to initiate a session with the Kerberos system. 

The KINIT command allows you to obtain an initial ticket to communicate with 

the ticket-granting service. 

Use the -i parameter if you are registered in the Kerberos database with a 

non-null instance. For example, you may be registered as a remote administrator 

with an admin instance. 

Use the -r parameter if you want to log on to the Kerberos system in a foreign 

realm. 

Use the KINIT command without a parameter if you are an ordinary user, 

registered with a null instance, and want to log on to the Kerberos system in 

your local realm. 

If the KINIT command is successfully processed, you are returned to a VM 

command prompt and an initial ticket file is saved in TMP TKT0. 

Use the KLIST command to verify the initial ticket. The KLIST command is 

described in “KLIST Command”. 

Using Multiple Parameters: The KINIT -irvl command requests the system to prompt 

you for an instance and a realm throughout your Kerberos session, and requests 

that Kerberos responses be displayed in verbose mode. Using the KINIT -irvl 

command has the same effect as using KINIT -i -r -v -l. 

Use the KLIST command to list the principal names of all of your current Kerberos 

tickets. 

►► 

KLIST 

TMPTKTO 

-file filename.filetype -srvtab 

►◄ 

Operands 

Examples 

-file filename.filetype 

Specifies the name of the file to be used as the ticket file. The default file name 

is TMP TKT0, which resides on the client’s 191 disk. 

-srvtab 

Lists the contents of the key file called ETC SRVTAB. The keys to all services 

provided by the same instance are in the key file. 

v 

An example of information displayed after invoking the KLIST command: 

Ticket file:TMP TKT0 

Principal:galina@univ.lab.chem 

Issued Expires Principal 

Dec 20 13:49:16 Dec 20 21:49:16 krbtgt.univ.lab.chem@univ.lab.chem 

Chapter 7. Authenticating Network Users with Kerberos 135


KDESTROY Command 

If the KLIST command is not successfully processed, an error message is 

displayed. 

Use the KDESTROY command to delete a currently active Kerberos tickets file. 

►► 

KDESTROY 

-f -q 

►◄ 

Operands 

Usage Notes 

KPASSWD Command 

-f Deletes your active Kerberos authorization tickets file without displaying a 

status message. 

-q Eliminates the beep response to your terminal if the tickets are not deleted. 

v 

v 

A status message indicating the success or failure of the operation is displayed 

on the screen. If KDESTROY cannot delete the ticket file, the system sends a 

beep response to your terminal. 

You should periodically delete your currently active Kerberos authorization 

tickets with the KDESTROY command. When you use the KDESTROY 

command, the ticket files are overwritten with zeros and removed from the 

system. 

Use the KPASSWD command to change your Kerberos password. 

►► KPASSWD -u username 

-i instance 

►◄ 

Operands 

-u username 

Specifies the full name of the user. 

-i instance 

Specifies an instance, if you are registered with the Kerberos database with a 

non-null instance. 

-n user 

Specifies the username. 

-r real m 

Specify a real m. 

-h operand usage help. 


Usage Notes 

v 


When you use the KPASSWD command, Kerberos prompts you for your current 

password. Upon verification that the current password is correct, Kerberos 

prompts you twice for the new password. After you enter the new password, a 

message is displayed indicating the success or failure of the change. 

Chapter 7. Authenticating Network Users with Kerberos 137



Chapter 8. Using the Network File System Commands 

VM’s NFS Server Support 

NFS is a TCP/IP protocol that allows heterogeneous systems to share data and 

files across networks. The NFS protocol is a client/server protocol — an NFS server 

runs on a system that has data and files to share, while an NFS client runs on a 

system where data and files are to be shared from NFS servers. 

The VM NFS client allows BFS users and applications transparent access to data on 

remote systems that have NFS servers supporting the SUN NFS Version 2 or 

Version 3 protocols, or both. These NFS protocols are described in RFCs 1094 and 

1813 respectively. OS/390, Windows 95 and NT, AIX, LINUX, UNIX systems, and 

z/VM are examples of these remote systems. 

For VM NFS client information, see the OPENVM MOUNT command in the 

z/VM: OpenExtensions Command Reference. 

The following NFS information is described in this chapter: 

v Sample remote NFS client commands and PCNFSD User ID Authentication 

v Diagnosing Mount Problems 

v Errors Using Mounted Systems 

v Notes for BFS files and directories 

v Notes for SFS files and directories 

v Notes for minidisk files 

v SMSG VM NFS server commands 

v Name translation file 

v NFS Client Problems 

v Deleting CMS record-length fields 

v Using NFS with RACF 

BFS All functions defined by the NFS protocol are supported by BFS file 

systems. For information on special considerations, see “Notes for BFS 

Files and Directories” on page 155. 

SFS Most functions defined by the NFS protocol are supported by SFS file 

systems. For information about which functions are not supported, see 

“Notes for SFS Files and Directories” on page 156. 

Minidisk 

Some functions that are defined by the NFS protocol are not supported by 

CMS minidisk file systems. Others are partially supported. For information 

about which functions are not supported, see “Notes for Minidisk Files” on 

page 158. 

Network File System (NFS) server support for z/VM is available at the Version 2 

level (RFC 1094) and at the Version 3 level (RFC 1813). Both User Datagram 

Protocol (UDP) and Transmission Control Protocol (TCP) transport protocols are 

supported. If your NFS client can be configured to use NFS Version 3 or the TCP 

transport protocol, you will be able to select these options. 


Using NFS Commands 

NFS Client Commands 

The actual format and use of NFS commands in a client system depends on the 

implementation of the NFS client. In the following descriptions, information is 

provided for data that is transmitted by the client system to the VM NFS server. 

For information about other parts of these commands or data that is interpreted by 

the client system, consult the documentation for the specific NFS client system 

used. 

You can use the following NFS commands from an NFS client machine. 

MOUNT 

MOUNTPW 

UMOUNT 

Mounts a BFS directory, SFS directory, or CMS minidisk on a local 

directory. 

Sends authentication information (user IDs and passwords) to the 

VM NFS server to obtain access to protected CMS files, directories, 

and file systems. 

Removes mounted CMS file systems in the client environment. 

MOUNT Command 

No unique error messages are associated with these commands. The error 

messages that result from a failed mount attempt depend on the client system, 

which should provide you with sufficient status information to understand why 

the failure occurred. 

The NFS commands are described in the following sections. In some environments, 

the command syntax is case-sensitive. The following syntax diagrams are examples 

only. 

To access a CMS file system, issue the MOUNT command on the NFS client 

machine in the following format. 

BFS MOUNT Command Syntax 

BFS file system protocols are similar to those of NFS. 


MOUNT Command 

►► 

(1) 

MOUNT localoptions hostname:BFS_pathname 

,RW 

,RO 

► 

► 

,Userid=requester ,By=byrequester , Password=logonpw 

► 

► 

, Account=localdata 

,Trans=No 

,Trans=Ext 

,Trans=Yes 

► 

► 

,Xlate= 

Standard 

Posix 

tablename 

pathname 

►◄ 

Notes: 

1 names=, nlvalue= and record= are not used if specified when mounting a BFS 

directory. 

Keyword options and values that are uppercased in the syntax diagram are the 

minimum abbreviation for such keyword options or values. 

SFS and Minidisk MOUNT Command Syntax 

SFS and minidisk file system protocols are very different from those of NFS in both 

structure and naming convention. SFS and minidisks files have records; the lines 

and nlvalue options allow you to tell NFS how to map records into a data stream. 

The names option tells NFS how to map a CMS file identifier (FILENAME 

FILETYPE) into the NFS file naming convention. 

Chapter 8. Using the Network File System Commands 141

MOUNT Command 

►► 

MOUNT localoptions hostname: 

SFS_directory 

User_id.vaddr 

,RW 

,RO 

,RO 

,RW 

► 

► 

,Userid=requester ,By=byrequester , Password=logonpw 

► 

► 

,Mdiskpw=mdiskpw 


,Names=Trans 

,names= 

Fold 

Mixed 

► 

► 

,Record=Binary 

Data Translation Options 

pathname 

►◄ 

Data Translation Options: 

,Trans= 

Ext 

Yes 

No 

,Xlate= 

Standard 

Posix 

tablename 

,Lines= 

Ext 

NL 

CMS 

NOne 

► 

► 

,NLvalue=0A 

,NLvalue=xx 

,NLvalue=xxxx 

,Record= 

Binary 

Text 

NL 

(1) (2) 

Notes: 

1 The use of trans= and lines= together with record= may result in overriding options. 

2 record=binary is the default only if neither lines nor trans is specified. 

Keyword options and values that are uppercased in the syntax diagram are the 

minimum abbreviation for such keyword options or values. 

MOUNT and MOUNTPW Operand Descriptions 

The specific MOUNT parameters used by an NFS client can vary for different VM 

systems, based on the access control scheme in use (for example, protecting 

minidisks using CP LINK passwords versus an external security manager (ESM), 

such as RACF). 

Ensure the appropriate authorizations are in place before issuing a mount request. 

For example, in the case where an ESM such as RACF is in place to protect 

minidisks, the owner of a minidisk to be mounted may need to issue RACFPERM 

or RACFBAT commands to authorize your user ID and/or the VM NFS server to 

obtain access to that disk. Also, ensure that both the password= and userid= 

parameters are included in the minidisk mount request. 


Operands 

MOUNT Command 

For BFS and SFS files, authorization checking is done in the file pool server 

machine when you request access to files in the mounted directory. Your requests 

for file access are authorized (or not authorized) based on how you are identified 

to the file pool server. The VM NFS server uses the verified userid= parameter to 

identify your requests. 

Optional parameters can be specified in any order. If an optional parameter is 

specified more than once, or if overriding parameters such as record= and trans= 

are used together, the last instance prevails. 

localoptions 

Specifies the MOUNT options, which vary between different client systems. 

Some common options for a UNIX client are: intr, soft, retry=n, retrans=n, and 

timeo=n. When a time-out value is specified, it usually is in units of one-tenth 

of a second; therefore timeo=20 denotes a time-out value of 2 seconds before a 

client assumes a network error occurred and retransmits a request to a server. 

hostname: 

The hostname is the name of the host on which the VM NFS server resides. 

Some NFS clients use a different syntax to specify the server location in a 

MOUNT command, rather than placing it as a prefix to the characters that 

identify the remote file system to be mounted. 

BFS_pathname 

Specifies the fully-qualified name of the BFS directory that contains the files 

and subdirectories to be accessed by the client. 

Use two consecutive commas (,,) to indicate that a BFS directory name contains 

a comma. 

Some NFS clients have difficulties with the special characters required for 

fully-qualified BFS directory names. You may use slashes (/) in place of the 

colons (:) that are required before file pool ID and file space ID in a 

fully-qualified BFS directory name. NFS clients may have other requirements 

for entering pathnames containing special characters such as blanks. 

SFS_directory 

Specifies the SFS file pool directory that contains the files and subdirectories to 

be accessed by the client. SFS_directory must be fully qualified, except that the 

file space portion of the directory name can default to requester. 

Some NFS clients have difficulties with the special characters required for 

fully-qualified SFS directory names. You may enter a slash (/) in place of the 

colon (:) that is required between file pool ID and file space ID in a 

fully-qualified SFS directory name. You may also enter a slash in place of the 

period (.) that separates subdirectories. 

user_id.vaddr 

Specifies the minidisk. The user_id.vaddr string defines the minidisk that 

contains the files to be accessed by the client. 

RW 

Specifies that the type of mount is to be read/write access. This is the default 

for the mount of a BFS or SFS directory. 

RO 

Specifies that the type of mount is to be read-only. This is the default for a 

mount of a minidisk. 


MOUNT Command 

Userid=requester 

Specifies a CP (VM) requester user ID to be associated with the mount request. 

The user ID is used as access control for SFS files, and the user ID is translated 

into UID and GID values which are used as access controls for BFS files. 

(Additional access controls may be used if an external security manager (ESM) 

is active for the file pool.) Requester should be enrolled in the file pool 

containing the BFS or SFS directory, or PUBLIC should be enrolled. 

User ID may be used by an external security manager, such as RACF, for 

deciding whether an NFS client is permitted to access an ESM-protected 

minidisk. 

userid= need not be specified on the MOUNT or MOUNTPW requests if 

PCNFSD is used. 

If by= is not specified, the combination of userid=requester and 

password=logonpw is used by the VM NFS server to validate the identity of the 

client. 

When userid= and by= are not provided by PCNFSD, MOUNTPW, or a 

MOUNT request, the mount will be successful only if anonymous mounts are 

allowed by the VM NFS server. If anonymous MOUNTs are allowed, the 

mount may be successful if a user ID of ANONYMOU has authority to use the 

SFS directory or ESM-protected minidisk. For BFS directories, the mount may 

be successful if the default user UID or GID values allow permission to use the 

directory. See TCP/IP Planning and Customization for information about allowing 

anonymous MOUNTs. 

By=byrequester 

If both userid=requester and by=byrequester are specified, the VM NFS server 

verifies that password=logonpw is the correct logon password for byrequester, 

and that byrequester has LOGON BY privileges for userid=requester. 

Password=logonpw 

Specifies the VM logon password of the user ID requesting the mount. 

password= need not be specified on the MOUNT or MOUNTPW requests if 

PCNFSD is used. 

The -v option on the OS/2 MOUNT command can be used to have the client 

prompt you for the password, unless you are mounting a BFS directory. 

Mdiskpw=mdiskpw 

When no external security manger (ESM) is in use, specifies a CP link 

password when a password is required to access the minidisk being mounted. 

If a CMS disk is public (that is, its CP LINK password is ALL), no password 

needs to be provided with the MOUNT command in order to access files on 

that disk. 

The VM NFS server will not issue a CP LINK for an MW link. If a mount 

request specifies write access for a minidisk, but a write link to that minidisk 

already exists, the VM NFS server returns a status code to the NFS client 

which indicates the CMS minidisk is a read-only file system. 

Note: If userid=, by= and mdiskpw= are not specified, the password specified 

in the password=logonpw parameter is used as a minidisk link password 

for CMS minidisks. This exception is made because earlier releases of 

VM NFS did not make a distinction between logon and minidisk link 

passwords. 


Account=local_data 

Allows additional information to be passed to software such as an ESM in the 

host. Specifies up to 64 characters of information that can be used by 

customer-supplied programming in the VM NFS server to further control or 

record access by NFS clients. The format of this data depends upon the 

supporting software. If account information is specified by a client and there is 

no supporting software in the server, the account data is ignored by the VM 

NFS server. 

Names= 

Specifies the handling of file names for minidisk, SFS files and directories. The 

names options are: 

Fold File names supplied by the client are translated to uppercase; file 

names supplied to the client are translated to lowercase. 

Mixed File names are not changed. The client must use valid CMS names. 

This mode must be used to refer to CMS files that contain lowercase 

letters in their name. 

Trans 

Use default name handling, which is described in the following 

paragraph. 

If the names parameter is omitted, the default provides translation for names 

that are too long or contain invalid characters. File names supplied by the 

client are translated to uppercase; file names supplied to the client are 

translated to lowercase. Correct CMS file names are generated by the VM NFS 

server, and these names are used rather than the actual client names. The VM 

NFS server creates the translation file ##NFS## #NAMES# on the CMS 

minidisk for minidisk files, and in the top SFS directory of the file space for 

SFS files. This translation file contains both the original client file names and 

the corresponding CMS file names. When file names are read by a client, the 

inverse translation is performed so that the client sees the original name 

specified when the file was created. 

Trans= 

defines whether translation should occur for data in files. 

Ext 

Yes 

No 

EBCDIC-ASCII translation is done based on the value of the file 

extension. See Table 10 on page 148. 

EBCDIC-ASCII translation is performed. 

No translation is performed. 

If neither record or trans is specified, trans=no is the default. 

NFS uses translation tables to convert transmitted data between EBCDIC and 

ASCII. These translation tables can be customized by your TCP/IP 

administrator. Contact your TCP/IP administrator for information about data 

translation. 

Xlate= 

Defines which translation table is to be used for file data translation. 

Standard TCP/IP’s standard translation table is to be used. 

Posix 

MOUNT Command 

This table translates ASCII (ISO 8859-1) to and from EBCDIC 

(IBM-1047). The UNIX line terminator (lf - X'0A') is translated 

to the OpenEdition VM line-end character NL - X'15'). 


MOUNT Command 

tablename 

The name of the translate table to be used. Some examples of 

tablename include "Xlate=UK," "Xlate=French," or 

"Xlate=10471252." 

If xlate is not specified, a system-defined translation table is 

used. 

tablename may not be abbreviated. 

Your TCP/IP administrator may change the list of tables provided, or 

customize the translation tables in the list. Contact your TCP/IP administrator 

for information about data translation. 

Lines= 

defines the way CMS records are converted to an NFS data stream. 

Ext 

NL 

CMS 

NOne 

The type of conversion done is based on the value of the file extension. 

See Table 10 on page 148. 

Line feed characters are inserted at CMS record boundaries. 

The CMS file format is maintained. When dealing with CMS 

variable-length record files, the binary, unsigned, two-byte length field 

is visible to the client at the beginning of CMS records read from the 

VM NFS server, and this field must be supplied by the client program 

in data written to VM. 

No linefeed characters are inserted. When dealing with CMS 

variable-length record files, the two-byte length fields are not visible. 

If neither record nor lines is specified, lines=none is the default. 

NLvalue= 

Specifies two or four hexadecimal characters to be used as the boundary 

indicating the end of a CMS record. The default is the line feed character. 

For example, you can specify nlvalue=0D0A for carriage return and line feed. 

Record= 

The record option is supported for compatibility. Use the trans and lines 

options to tell NFS how to translate file data. 

v Binary is equivalent to trans=no and lines=CMS. 

v Text is equivalent to trans=yes and lines=CMS. 

v NL is equivalent to trans=yes and lines=NL. 

pathname 

Specifies the local path name, which identifies where to mount CMS files in 

the client file name hierarchy. 

Figure 10 on page 147 illustrates the MOUNT command. 


MOUNT Command 

MOUNT 

-o ro.soft 

(The command 

continues below) 

Local (Client) Options 

NFS Command 

hostname:user_id.vaddr,ro,mdiskpw=xxxxx,record=yyyyy,names=zzzzz 

/u/merlin/m 

Information Transmitted intact 

to the VM NFS Server 

Where to mount the file system 

in the Client Machine’s 

file hierarchy 

Figure 10. NFS MOUNT Command 

NFS File Extension Defaults 

Following are the default values used when the trans=ext or lines=ext options are 

used. The system administrator for your system may change or add to these 

default values. 

File extension is defined to be the last component of a file name, that is, the 

characters following the last period in the path name. Up to eight characters are 

matched, and mixed case is not respected. 


MOUNT Command 

Table 10. File Extension Translation Table 

File Extension trans=ext lines=ext 

*BIN¹ no none 

$EXEC $REXX $XEDIT AMS AMSERV 

ANN ANNOUNCE APP APPEND ASC 

ASCII ASM ASM3705 ASSEMBLE AVL 

AVAIL A37 BASDATA BASIC BKS 

BKSHELF C C++ CAT CATALOG 

CNTRL COB COBOL COPY CPP 

yes 

NL 

DIRECT DLCS DOCUMENT ESERV EXC 

EXEC FFT FOR FORM FORTRAN 

FREEFORT GCS GROUP H HPP 

HTM HTML H++ JOB LISTING 

LOG LST MAC MACLIB MACRO 

MAK MAKE ME MEMBER MEMO 

MODULE NAM NAMES NETLOG NONE 

NOT NOTE NOTEBOOK OFS*² OPT 

OPTIONS PACKAGE PASCAL PKG PLAS 

PLI PLIOPT PLS PVT REXX 

yes 

NL 

RPG SCR SCRIPT STY STYLE 

TEXT TEXTXXXX TXT TXTXXXX UPDATE 

UPDT VMT VSBASIC VSBDATA XED 

XEDIT 

other or none no none 

Notes: 

1. *BIN represents a wildcard, that is, any file extension ending in ’BIN’. 

2. OFS* represents a wildcard, that is, any file extension starting with ’OFS’ unless it also ends in ’BIN’. 

PCNFSD User ID Authentication 

Many NFS client implementations contain calls to PCNFSD user ID Authentication 

services. The purpose of these calls is to present a user ID and password to be 

verified by the host system. Once verified, the UID and GID by which that user is 

known at the host is returned to the client. For VM, the POSIXINFO and 

POSIXGLIST CP directory entry statements define the UID and GID(s) associated 

with a user ID. 

Note that a value of -1 is returned for a user ID of ANONYMOU. 

When PCNFSD is used, there is no need to send user ID and logon password in 

the MOUNT or MOUNTPW. If user ID or password are not provided by 

MOUNTPW or MOUNT, the PCNFSD values are used by the NFS server, as long 

as the MOUNT request is received by the NFS server immediately following the 

PCNFSD request. (The NFS client typically sends the MOUNT request immediately 

following the PCNFSD information.) 


Your system administrator has the option of disabling PCNFSD for your NFS 

server. Contact your system administrator if you receive a message that PCNFSD is 

not running or is inaccessible. 

Examples 

In the following example, a MOUNT command is issued from an OS/2 command 

prompt to mount a BFS directory that resides in the root file system in file pool: 

fpcool. Note that VMBFS, FPCOOL and ROOT must be uppercased when specified 

in the pathname. 

1. Mounting a BFS directory: 

mount -u4189 -g513 x: gd3vm0:/../VMBFS:FPCOOL:ROOT/u/jake, 

userid=elwood,password=mypass 

In the previous command, the user specified his VM uid and gid via the -u and 

-v options. This indicates to OS/2 what uid and gid are being used. However, 

the VM NFS server will perform authorization checking based on the verified 

userid= parameter. 

Alternatively, Elwood’s VM logon password can be provided via a previous 

MOUNTPW command. 

In the following example, a MOUNT command is issued from an OS/2 command 

prompt to mount the mission SFS subdirectory owned by the VM user ID, JAKE 

which resides in file pool fpcool: 

1. Mounting an SFS directory: 

mount -v x: gd3vm0:fpcool:jake.mission,trans=ext,lines=ext, 

userid=elwood 

After issuing the command above, the user will be prompted for Elwood’s user 

ID password. In response to this prompt, the VM logon (or sign-on) password 

should be provided. 

Alternatively, Elwood’s VM logon password can be provided via the 

password= parameter and no password prompt is issued. 

In the following examples, MOUNT commands are issued from an OS/2 command 

prompt to mount the VM 191 minidisk owned by the VM user ID, JAKE: 

1. Accessing a VM minidisk when an External Security Manager (ESM) is in use: 

mount -v x: gd3vm0:jake.191,ro,trans=yes,lines=NL, 

userid=elwood 

After issuing the command above, the user will be prompted for Elwood’s user 

ID password. In response to this prompt, the VM logon (or sign-on) password 

should be provided. 

mount x: gd3vm0:jake.191,ro,trans=yes,lines=NL,password=harpman, 

userid=elwood 

In the above command, Elwood’s VM logon password harpman is provided via 

the password= parameter; no password prompt is issued. 

2. Accessing a VM minidisk when no External Security Manager (ESM) is in use: 

mount -v x: gd3vm0:elwood.191,ro,trans=yes,lines=NL 

MOUNT Command 

After issuing the above command, the user will be prompted for a password. 

In response to this prompt, a VM minidisk (CP LINK) password should be 


MOUNT Command 

MOUNTPW Command 

provided. In this example, read-only access was requested, so the minidisk 

″Read (R)″ password should be provided. 

mount x: gd3vm0:elwood.191,rw,trans=yes,lines=NL,mdiskpw=whtoast 

In the above example, read/write access was requested, so the minidisk ″Mult 

(M)″ password (″whtoast″) was provided via the mdisk= parameter. 

Note: If your NFS client is configured to call PCNFSD user ID Authentication 

services and PCNFSD is available on your VM NFS server, using 

MOUNTPW is not necessary, because user ID and password information is 

passed on PCNFSD requests. This applies to mounts for SFS directories, BFS 

directories, and minidisks protected by ESMs. A minidisk protected by link 

passwords must still provide the password on the MOUNT or MOUNTPW 

command. 

The MOUNT command can pose a security problem, because NFS client systems 

often store this command’s argument values to respond to a later query asking for 

information about the mounts that are currently in effect. A password supplied in 

an argument to a MOUNT command could then be revealed in the query response 

to someone other than the user who executed the MOUNT command. The 

MOUNTPW command provides an alternative path for sending passwords, 

account, and user ID information to the VM NFS server. This information can then 

be omitted from the subsequent related MOUNT command, and therefore is not 

present in a display of currently mounted file systems. 

A MOUNTPW command precedes the related MOUNT command, which must 

follow within 5 minutes. After 5 minutes, the VM NFS server discards the 

information it received in a MOUNTPW command. If a second MOUNTPW 

command is issued for the same CMS disk or directory before a MOUNT 

command for that object, the data from the first MOUNTPW command is 

discarded. 

The only MOUNT command options that are recognized on a MOUNTPW 

command are userid, by, password, mdiskpw and account. All other MOUNT 

command options are ignored. If user IDs, passwords, or account value are 

specified on both a MOUNTPW command and a related MOUNT command, the 

value from the MOUNT command is used. 

The following is the format of the MOUNTPW command. 

►► MOUNTPW hostname: BFS_pathname 

SFS_directory 

user_id.vaddr 


► 

► 

► 

, Userid=requester , By=byrequester ,Password=logonpw 

, Mdiskpw=mdiskpw 

► 

►◄ 


MOUNTPW Command 

Operands 

Refer to the “MOUNT Command” on page 140 for a description of the operands. 

Usage Note 

The MOUNTPW C source file is supplied on TCPMAINT’s 592 disk, as are the 

executable modules built for the IBM client environments listed in Table 11 

Table 11. Executables 

Operating Environment 

AIX on an IBM RISC System/6000 ® 

OS/2 

MOUNTPW Executable File 

6000@BIN MOUNTPW 

OS2@BIN MOUNTPW 

UMOUNT Command 

If none of the executable modules are appropriate, then the MOUNTPW C file 

must be copied to the client system and compiled into an executable program 

before you can execute the MOUNTPW command. 

Compile the command using a C compiler resident on the client system. The 

location of header files (.h) in the MOUNTPW source program may not be where 

your client system expects for a compile. If this is the case, modify the MOUNTPW 

source program to specify the correct location for your client system. Some 

platforms may require that you specify libraries to build the MOUNTPW 

executable. For example, DYNIX/ptx ® requires the following: –lsocket, –lnsl, and 

–lrpc. 

Binary files are supplied containing executable MOUNTPW modules for the IBM 

AIX ® environment. These can be used in the NFS client environment AIX Version 

4.2.1 and above as an alternative to building executable modules from the source 

files. Use FTP to copy the files to the AIX environment, renaming the files to the 

command name and making sure to use the FTP command binary to ensure that a 

binary copy is performed. Once the files are copied to the AIX environment, use 

the command chmod a+x mountpw to make the files executable. 

To unmount a currently mounted file system, use the UMOUNT command. 

The format of the UMOUNT command, like the MOUNT command, depends on 

the client system. 

The following is the most common format of the UMOUNT command. 

►► UMOUNT pathname ►◄ 

Operands 

pathname 

Specifies the local path name that identifies a mounted remote file system in 

the client environment. 

Figure 11 on page 152 illustrates the NFS UMOUNT command. 



UMOUNT 

u/merlin/m 

Local Pathname 

NFS Command 

Figure 11. NFS UMOUNT Command 

Diagnosing Mount Problems 

If your NFS client is having trouble performing a mount, try the following to 

verify that your VM system is running correctly: 

1. Verify that the network connections are good. Try to ″ping″ the VM system, for 

example: ping gdlvmk1.endicott.ibm.com 

2. Verify that the PORTMAPPER server is up and running by issuing the 

″RPCINFO″ command. The RPCINFO command can be issued from VM or 

from another platform that supports it. From VM the command is issued as 

follows: 

RPCINFO -p server_name 

For example: 

RPCINFO -p gdlvmk1.endicott.ibm.com 

If the portmapper is up, a list of programs, versions, protocols, and port 

numbers is printed similar to the following: 

Ready; T=0.04/0.08 16:36:32 

rpcinfo -p k32lsf01 

program vers proto port 

100000 2 udp 111 portmapper 

100000 2 tcp 111 portmapper 

100005 1 udp 2049 mountd 

100005 3 udp 2049 mountd 

100005 1 tcp 2049 mountd 

100005 3 tcp 2049 mountd 

100003 2 udp 2049 nfs 

100003 3 udp 2049 nfs 

100003 2 tcp 2049 nfs 

100003 3 tcp 2049 nfs 

150001 1 udp 2049 pcnfsd 

150001 2 udp 2049 pcnfsd 

Ready; T=0.04/0.08 16:38:21 

If a similar response is not returned, contact your system programmer or 

TCP/IP administrator to start the PORTMAPPER server on your VM system. 

3. If your mount uses the NFS Version 3 or TCP transport protocol, verify that the 

output from the RPCINFO -p command lists 3 in the vers column and tcp in 

the proto column for both the mountd and nfs programs. 

4. Verify that the mountd, pcnfsd, portmapper, and nfs services are running on 

your VM system by entering the following commands from VM: 



rpcinfo -u server_name mount 

rpcinfo -u server_name pcnfsd 

rpcinfo -u server_name portmapper 

rpcinfo -u server_name nfs 

If the services are running on the VM system, the following responses are 

returned: 

Ready; T=0.02/0.06 16:45:36 

* See if mount is running 

rpcinfo -u k32lsf01 mount 

program 100005 version 1 ready and waiting 



Ready; T=0.04/0.08 16:45:49 

* See if portmapper is running 

rpcinfo -u k32lsf01 portmapper 


Ready; T=0.04/0.08 16:46:40 

* See if nfs is running 

rpcinfo -u k32lsf01 nfs 



Ready; T=0.04/0.08 16:47:27 

* See if pcnfsd is running 

rpcinfo -u k32lsf01 pcnfsd 



Ready; T=0.04/0.08 16:47:53 

If all of the above verifications look successful, the following can also be verified: 

1. Contact your VM NFS server administrator to verify that the EXPORT and 

EXPORTONLY configuration statements in the VMNFS CONFIG file are set up 

correctly to allow your NFS client host system to perform the mount. 

Errors Using Mounted Systems 

Table 12 describes the status values that can be generated by the VM NFS server. 

Most of these status values are defined in RFC 1094 and RFC 1813. However, there 

are VM specific status values listed here also and there are status values listed that 

are defined in the RFCs but never returned. 

The actual information that is visible to a program in the client system depends on 

the specific local file system routine invoked and the design of the NFS client 

implementation. Some NFS clients may make these error codes visible to the user, 

some do not. 

Table 12. NFS System Return Codes 

Code 

NFS3ERR_PERM = 1 

NFS3ERR_NOENT = 2 

NFS3ERR_IO = 5 

NFS3ERR_NXIO = 6 

Description 

The caller does not have valid ownership, and the 

requested operation is not performed. 

The file or directory specified does not exist. 

I/O error occurred while an operation was in progress. 

Invalid device or address specified. 



Table 12. NFS System Return Codes (continued) 

Code 

NFSERR_ENOMEM = 12 

NFS3ERR_ACCES = 13 

NFS3ERR_EXIST = 17 

NFS3ERR_XDEV = 18 

NFS3ERR_NODEV = 19 

NFS3ERR_NOTDIR = 20 

NFS3ERR_ISDIR = 21 

NFS3ERR_INVAL = 22 

NFS3ERR_FBIG = 27 

NFS3ERR_NOSPC = 28 

NFS3ERR_ROFS = 30 

NFS3ERR_MLINK = 31 

NFS3ERR_NAMETOOLONG = 63 

NFS3ERR_NOTEMPTY = 66 

NFS3ERR_DQUOT = 69 

NFS3ERR_STALE = 70 

Description 

The operation caused the server’s file system to run 

out of memory. This status value is specific to the VM 

NFS server. 

The caller does not have the correct authorization to 

perform the desired operation. 

The specified file already exists. 

An attempt was made to do a cross-device hard link. 

This status value is not returned by the VM NFS 

server. 

Invalid device specified. 

A non-directory was specified in a directory operation. 

A directory was specified in a non-directory operation. 

An invalid argument or unsupported argument for an 

operation was received. An example is attempting a 

READLINK on an object other than a symbolic link. 

File too large. The operation caused a file to grow 

beyond the server’s file system limit. 

The operation caused the server’s file system to run 

out of space. 

Writing attempted on a read-only file system. 

There are too many hard links. 

The file name in an operation was too long, or invalid 

in some other way under the name translation option 

specified in the MOUNT command. 

Directory not empty. The caller attempted to remove a 

directory that was not empty. 

Disk quota exceeded. The client’s disk quota has been 

exceeded. 

Invalid file handle. The file referred to by the file 

handle no longer exists, or access has been revoked. 

This access revoked condition also occurs under the 

following sequence of events. 

1. A client mounts a CMS disk. 

2. The minidisk link password granting access to that 

disk is changed. 

3. The VM NFS server is restarted. 

4. The client requests an operation on this disk. 

After it is restarted, the VM NFS server relinks a CMS 

disk when it first receives a client request referring to 

that disk. The server restart is not visible to the client. 

If the minidisk link password has been changed, this 

link fails and “stale filehandle” status is returned to the 

client. Similarly, if SFS authorization of BFS 

permissions change for a mounted directory, and 

attempts to access the directory fail following a server 

restart, “stale filehandle” status is returned. 



Table 12. NFS System Return Codes (continued) 

Code 

NFS3ERR_REMOTE = 71 

NFSERR_WFLUSH = 99 

NFS3ERR_BADHANDLE = 10001 

NFS3ERR_NOT_SYNC = 10002 

NFS3ERR_BAD_COOKIE = 10003 

NFS3ERR_NOTSUPP = 10004 

NFS3ERR_TOOSMALL = 10005 

NFS3ERR_SERVERFAULT = 10006 

NFS3ERR_BADTYPE = 10007 

NFS3ERR_JUKEBOX = 10008 

Description 

Too many levels of remote in the path specified. The 

file handle given in the arguments referred to a file on 

a non-local file system on the server. 

Never returned by the VM NFS server. 


Update synchronization mismatch was detected during 

a SETATTR operation. 

The cookie specified on READDIR or READDIRPLUS 

is incorrect. 

The operation specified is not supported. 

A buffer or request had an incorrect length. 


An attempt was made to create an object of a type not 

supported by the server. For example, creating a socket 

using MKNOD is not supported for BFS. 


Notes for BFS Files and Directories 

All functions defined by the NFS protocol are supported by BFS file systems. 

1. By default, NFSERR_IO is returned on requests that reference file data for BFS 

files that have been placed in migrated status. 

2. The size attribute is ignored on Create Directory. 

3. All attributes are ignored on Create Link to File and Create Symbolic Link. 

Attributes for the new link match those of the linked-to file. 

4. NFSERR_IO or NFS3ERR_INVAL is returned on all requests that attempt to use 

BFS external links of type CMSEXEC or CMSDATA. This restriction is in place 

because these types use ddnames and file modes, which will not be defined 

properly for the VM NFS server. 

5. NFSERR_IO or NFS3ERR_INVAL is returned on all requests that attempt to 

read, write, or perform the set attributes set size function on a BFS FIFO. 

6. All changes are flushed and committed for a Version 3 Commit request, even 

when offset and count contain non-zero values. 

7. Both the VM user’s primary GID (from the POSIXINFO statement) and the 

user’s supplemantary GID list (from the POSIXGLIST statement) are used for 

requests. 

8. The following restrictions apply to the MKNOD procedure: 

v creation of the block special device file and socket are not supported 

v only 16-bit major and minor device numbers are supported. 

9. The file mode creation mask that is in effect for the VM NFS server machine 

will apply to the creation of BFS objects through the VM NFS server. In other 

words, the NFS client may request the permission values to be associated with 

the file or directory (based on a local client mask), but these may be overridden 

by the file mode creation mask on the VM NFS server. 

The file mode creation mask in effect can be displayed via OPENVM QUERY 

MASK. Your TCP/IP administrator can change the default by specifying the 

OPENVM SET MASK command when the VM NFS server starts. For more 



information on the file mode creation mask, see “Handling Security for Your 

Files” in the z/VM: OpenExtensions User’s Guide, SC24-6053. 

10. If the requester user ID specified on the mount (or with mountpw or pcnfsd) 

has file pool administration authority for the target file pool, that 

administration authority is not respected by VMNFS. In other words, the 

requester user ID must have explicit permission to the object through the UID 

and GID associated with the user ID. 

11. Refer to “VM NFS Server Link Support” on page 167 in this chapter for more 

notes on BFS symbolic links and external links. 

12. If you are able to perform all expected functions for an NFS-mounted Byte 

File System directory, but ACCESS DENIED or NOT OWNER is displayed 

when you attempt to create a file, then the UID and GIDs defined for your 

client may be different from the UID and GIDs defined for the VM user ID 

used on the MOUNT. For a VM user ID, UID and GIDs are defined by the 

POSIXINFO, POSIXGROUP, and POSIXGLIST statements in the CP directory 

entry. Default values of -1 are used if these statements are not used. 

The file creation problem is typically seen on systems such as AIX and UNIX. 

The file is created successfully, but the NFS client then attempts to change the 

owning UID to match the UID of the VM user ID. This part of the operation 

fails because it requires super-user capabilities. 

Other types of clients tolerate differences in UID/GID defintions more easily. 

These other NFS clients often use PC-NFS to ask the server: By what UID am I 

known here? The NFS client then uses that information by recognizing what 

the owning UID of a new file should be. 

How can you correct this problem on a system such as AIX? 

a. The best way to avoid this problem is to have global user ID definitions. 

The VM user ID is assigned the same UID and GIDs used by the NFS 

Client system. 

b. If global user ID definitions are not possible, another choice is to create a 

new user ID on the client system with a UID that matches the VM user ID. 

Use 'su' to switch to that user ID on the client before creating the file. Also 

ensure that the GID assigned to the new name is in the list of GIDs 

assigned to the VM user ID. This may be easier than forcing consistency 

across all systems, but it is practical only if there is no overlap in the UID 

definitions for the two systems. 

c. A third choice is to MOUNT using a VM user ID that has super-user 

authority. This will allow the create request to succeed. In this case, clients 

that use the mount point have full power to anything under it (because 

they are considered super-users by the VM NFS server). Access to the 

mount point must be carefully controlled from the client side. 

Notes for SFS Files and Directories 

1. Most functions defined by the NFS protocol are supported by SFS file systems. 

Those not supported include: 

v symbolic links 

Those partially supported include: 

v link 

Limited support is available for the link NFS request. The intent of this 

support is to accommodate clients that use link as a temporary step during 

a file rename or similar operation. A hard link may be created only in the 

same directory as the source file. Link information is maintained in volatile 


v 

v 


storage by the VM NFS server, and it is not used when the reply to a 

read-directory or lookup-file request is constructed. 

set-attributes 

– Both the time of last modification (mtime) and the time of last access 

(atime) can be changed. However, SFS maintains only the date, (not time) 

of last access for SFS files, so when an atime is retrieved, it will show a 

timestamp that is midnight of the given date. 

– Requests to change file permissions are ignored and success status is 

returned to the client. 

– Requests to change mode, uid, orgid are ignored and success status is 


– Attempting to increase the size of a variable file generates an error 

response. 

Only the file space owner may create (mkdir) or remove (rmdir) directories, 

unless an ESM is used and allows the operation for the requester user ID. 

v The file size attribute can be used on Create File to set the size for fixed 

record format files. The file size attribute is ignored and set to zero for 

variable record format files. 

2. Access to SFS file and directories is based on the authorities granted to the 

requester user ID specified on the MOUNT command, and not UID’s. On 

multiple user systems such as UNIX, all users have the same access to objects 

in the mounted SFS directory if they have permission to use the mount point. 

Thus the administrator (super-user) who performs the mount must make sure 

that appropriate controls are in place for the mount point. 

3. Each update operation is committed before responding to the client, including 

Version 3 Write requests. A Version 3 commit request returns a success status 

to the client. 

4. CMS users can create SFS files that do not map to NFS file types. The ftype 

value returned for aliases, erased aliases, revoked aliases, and external objects 

is NFNON (non-file). 

5. When names=Trans is specified on the Mount command, NFS provides 

translation of SFS directory names that are greater than 16 characters or 

contain invalid characters. There is one restriction: mkdir() or rename() are 

rejected if the name contains a dot. 

The mkdir() operation creates FILECONTROL directories and uses the mtime 

(modification time), if provided by the client. 

The only date used for SFS directories is mdate. 

6. A ro (read-only) mount request is similar to the RORESPECT ON setting in a 

CMS client. If an SFS directory is mounted ro, you may not write to files in 

that subdirectory structure. 

7. By default, NFSERR_IO is returned on requests that reference file data for SFS 

files that have been placed in migrated status. 

8. Files named ##NFS## #VHIST# and ##NFS## #NAMES# may reside in an SFS 

top directory when files are written using NFS. Do not modify or erase these 

files. They contain control information needed by NFS. 

9. Not all file attributes defined by the NFS protocol apply to SFS file systems. In 

the case of uid and gid, the attribute values are returned as follows: 

v The uid value returned for an SFS Dircontrol directory will be 1. All other 

SFS objects will return a uid value of 0. 

v The gid value for an SFS file with fixed record format will be returned as 1. 

The gid value for an SFS file with variable record format will be returned as 

2. All other SFS objects will return a gid value of 0. 



Notes for Minidisk Files 

v The record length of an SFS file (LRECL) will be returned in the rdev 

attribute. 

10. Creation of special files using MKNOD is not supported. Special files are 

block special device file, character special device file, socket, and named pipe. 

11. Creation of a regular file with the mode set to EXCLUSIVE is not supported. 

12. Records in CMS variable files are limited to a length of 65535. If a write 

request attempts to create a record larger than this, a message is written to the 

VM NFS server console and an I/O error is returned to the client. 

13. The NFS READDIR procedure can appear to behave inconsistently with NFS 

mounted SFS directories, due to native SFS authorization rules. SFS will allow 

non-directory file system objects to be listed in NFS READDIR output, 

provided that the NFS client has at least SFS read authorization to the 

directory containing the objects, but SFS will not allow subdirectories in that 

directory to be listed in NFS READDIR output, unless the NFS client was also 

explicitly given at least SFS read authorization to each subdirectory. 

To ensure that clients will be able to see SFS subdirectories after an NFS 

READDIR procedure, SFS read authorization should be granted for every 

directory in a file system hierarchy. Refer to the z/VM: CMS User’s Guide, 

SC24-6009, for more information on SFS authorizations. 

1. Some functions that are defined by the NFS protocol are not supported by CMS 

minidisk file systems. Others are partially supported. 

Those not supported include: 

v make-directory 

v symbolic link 

v remove-directory 

Those partially supported include: 

v set-attributes 

– Only the time of last data modification (mtime) can be changed. 

– Requests to change file permissions are ignored and success status is 


– The size of a file can be changed to zero or to its current size. The size of 

a fixed record format file can be increased. Other size change requests 

generate an error response. 

– Requests to change mode, uid, orgid, are ignored and success status is 


v link 

– Limited support is available for the link NFS request. The intent of this 

support is to accommodate clients that use link as a temporary step 

during a file rename or similar operation. Link information is maintained 

in volatile storage by the VM NFS server, and it is not used when the 

reply to a read-directory or lookup-file request is constructed. 

v Access to minidisks is based on the ability of the VM NFS server to link the 

disk. On multiple user systems such as UNIX**, all users have the same 

access to files in the mounted minidisk if they have permission to use the 

mount point. Thus the administrator (super-user) who performs the mount 

must make sure that appropriate controls are in place for the mount point. 

v A minidisk file size can be changed to zero from an NFS client. To NFS 

clients it will appear to have a file size of zero; to CMS users the file will 

appear to have one record, of length one. 


v 

v 


Not all file attributes defined by the NFS protocol apply to minidisk files. In 

the case of uid and gid, the attribute values returned are as follows: 

– The uid value returned for a minidisk file with either fixed or variable 

record format will be returned as 0. 

– The gid value for a minidisk file with fixed record format will be returned 

as 1. The gid value for a minidisk file with variable record format will be 

returned as 2. 

– The record length of a minidisk file (LRECL) will be returned in the rdev 

attribute. 

The VM NFS server updates CMS minidisk disk blocks in place, if possible. 

The advantages of this implementation include: 

– Updates to existing data in a file are immediately visible to a CMS user 

who accessed the disk before the updates were made. 

– The VM NFS server does not need to keep elaborate data structures in 

memory, record the current state of a file, or manipulate the CMS 

allocation and directory information every time a write request is 

executed. 

The disadvantage of this type of implementation is that a time window 

exists, during which a failure of the VM NFS server could cause a disk block 

on a CMS disk to be recorded as allocated, when it does not belong to any 

file. 

This time window is of short duration, because, after the block is marked as 

allocated, the directory or pointer block necessary to record ownership of the 

block is immediately updated. For this reason, troubles with lost blocks are 

infrequent. 

If a file is open when an update is made, you may not see the update, 

because CMS buffers the disk block containing the update. CMS only buffers 

one disk data block for each file, so updates in another data block can be 

seen, even if the file is open. Closing the file makes the updates visible the 

next time the file is read. 

Updated file data is immediately visible to other NFS clients, subject to the 

limitations imposed by the buffering performed in those client machines. 

Write operations performed by the VM NFS server are similar to the 

operations that CMS performs to files that have the file mode number 6. The 

VM NFS server does not distinguish the actual file mode number associated 

with a file on a CMS disk. New files are always created with the file mode 

number 1. Files of any file mode number (including zero) can be read by any 

client that performs a successful mount. 

v The file size attribute can be used on Create File to set the size for fixed 

record format files. The file size attribute is ignored and set to zero for 

variable record format files. 

2. All changes are flushed and committed for a Version 3 Write request. A Version 

3 Commit request returns a success status to the client. 

3. Creation of special files using MKNOD is not supported. Special files are block 

special device file, character special device file, socket, and named pipe. 

4. Creation of a regular file with the mode set to EXCLUSIVE is not supported. 



SMSG Interface to VMNFS 

5. Records in CMS variable files are limited to a length of 65535. If a write request 

attempts to create a record larger than this, a message is written to the VM NFS 

server console and an I/O error is returned to the client. 

The VM Special Message Facility (SMSG) command provides an interface to VM 

NFS server to: 

v 

v 

v 

v 

cause the server to detach a minidisk it has linked (usually in read-write mode) 

so other users can establish links to that minidisk. 

refresh minidisk information after changes have been made to a minidisk that 

the server has linked in read-only mode; this causes buffered disk block data to 

be discarded so that subsequent client requests make use of current disk data. 

obtain a summary of NFS server activity. 

obtain error information about client requests that pertain to a specific SFS or 

BFS directory that has been mounted. 

Note: Some of the SMSG commands described in this section may be restricted by 

the TCP/IP administrator for use by only authorized VM user IDs. 



►► SMSG server_id replytag Options ►◄ 

Options: 

Detach 

Error 

Query 

Refresh 

user_id.vaddr 

BFS_pathname 

SFS_directory 

Query Opts 

user_id.vaddr 

Query Opts: 

Config 

Link 

Mount 

Resource 

Resource Opts 

Resource Opts: 

USER 

issuing_vm_user_ID 

USER vm_user_ID 

USER ANONYMOUS DETAILS 

IP ip_address VERSIONS 

ALL 

Operands 

SMSG command operands are parsed by the NFS server as blank-delimited tokens, 

and case is not significant. Any tokens present after those recognized by the NFS 

server are considered to be comments and are ignored. 

server_id 

The user ID of the NFS server virtual machine, usually VMNFS. 

replytag 

A character string that associates the supplied SMSG command Option with a 

server response; the replytag prefaces each message issued by the NFS server in 

response to the given command. Any characters (other than blank and null 

characters) can be used to form a replytag, and case is not significant. 

The replytag also indicates how the NFS server is to deliver its response to a 

particular SMSG command. The last character of replytag has special meaning 

and is interpreted by the server as follows: 

The following describes how the last character of replytag is interpreted. 

s respond using the CP SMSG command. 

m respond using the CP MSG command. 



n send no response. 

If the replytag does not end with one of these characters, the NFS 

server chooses a response mode. 

Detach user_id.vaddr 

Directs the NFS server to detach a minidisk that it has linked, where: 

v user_id identifies the VM user ID that owns the minidisk 

v vaddr is the minidisk virtual address. 

Error object 

Requests error information about the mounted object directory to be returned. 

The NFS server maintains a limited amount of error information for a mounted 

directory in an internal ″host″ error log. This information can be useful in 

determining the underlying reason for an error (for example, NFSERR_IO) 

that is returned in response to a client request. Note that information about 

“not found” and “not authorized” error types is not maintained. 

The object directory for which error information can be retrieved may be one of 

the following: 

BFS_pathname 

The mounted BFS directory for which host error information is 

requested. Information will only be returned if the VM user ID that 

originates the error request has permission to the directory in question. 

SFS_pathname 

The mounted SFS directory for which host error information is 

requested. Information will only be returned if the VM user ID that 

originates the error request has authorization for the directory in 

question. 

Query 

Requests summary information about NFS server activity. The QUERY 

command can be further qualified with the CONFIG, LINK, MOUNT or 

RESOURCE operands to obtain specific information. 

Query CONFIG 

Requests information about how the NFS server is configured. The server 

returns the following information in its response: 

v The TCP/IP function level of the VMNFS MODULE in use. 

v The status of various configuration parameters, such as whether mounts are 

restricted to only exported file systems, whether anonymous mounts are 

allowed, whether PCNFSD is supported, and the time after which PCNFSD 

information will be discarded. 

v The maximum buffer size to be used to satisfy NFS version 3 READ 

requests. 

v The maximum buffer size to be used to satisfy NFS version 3 WRITE 

requests. 

v The maximum number of NFS clients that can concurrently use the TCP 

transport protocol. 

v The number of NFS clients that are concurrently using the TCP transport 

protocol. 

Information returned by the SMSG QUERY CONFIG command can be used to 

determine if the maximum allowable number of clients which use the TCP 

transport protocol (controlled by the MAXTCPUSERS server configuration 

statement) is acceptable. 


Query Link 

Requests information about minidisks that are linked by the NFS server. 

Support for the SMSG QUERY LINK command is provided to maintain 

compatability with prior levels of TCP/IP for VM/ESA; it is recommended 

that the SMSG QUERY RESOURCE command be used in place of the SMSG 

QUERY LINK command. 

Query Mount 

Requests information about NFS mounts that are active. Support for the SMSG 

QUERY MOUNT command is provided to maintain compatability with prior 

levels of TCP/IP for VM/ESA; it is recommended that the SMSG QUERY 

RESOURCE command be used in place of the SMSG QUERY MOUNT 

command. 

Query Resource 

Requests information about specific resources that are actively in use by the 

NFS server. SFS and BFS directories are considered to be active if they have 

been used or referenced within the 15 minute period that percedes receipt of 

an SMSG QUERY RESOURCE command. A minidisk is considered to be active 

so long as the NFS server has established a link to that minidisk. 

If additional operands are not used to qualify a RESOURCE query, information 

that corresponds to the user ID which originated the SMSG command is 

returned, as if the USER vm_user_id had been specified. 

The information returned in response to an SMSG QUERY RESOURCE 

command includes: 

v whether a mount is read-write or read-only. 

v 

v 

v 

v 

a one-character mount indicator. This indicator is typically m, meaning the 

returned resource information corresponds to an explicit client mount. An 

asterisk (*) indicates the NFS server was restarted and that an implicit 

mount was performed for a directory that is lower in the hierarchy of the 

explicitly-mounted directory. 

the IP address from which a mount was requested. 


the VM user ID under which a mount was requested, or ″anonymous″ if an 

anonymous mount was performed. 

the name of the mounted BFS directory, SFS directory, or minidisk. 

The RESOURCE operand can be further qualified with the USER, IP or ALL 

operands to obtain more specific summary information, as follows: 

USER vm_user_id 

Limits resource information for directories and minidisks mounted 

under authority of the specified VM user ID, vm_user_id. 

USER ANONYMOUS 

Limits resource information for directories and minidisks that have 

been mounted anonymously. 

IP ip_address 

Limits resource information for directories and minidisks that have 

been mounted by the host with the IP address, ip_address. 

ALL 

Provides resource information for all mounted directories and 

minidisks. Note that BFS and SFS directory mount information is 

returned only if the user ID that originates the request has permission 

(authorization) for those directories. Table 13 on page 164 shows the 

information that is displayed when the ALL operand is used. 



Table 13. Resource Information 

Mount Information 

Meaning 

* The NFS server was restarted and an implicit mount 

was done for a directory lower in the 

explicitly-mounted directory’s hierarchy. 

m 

Information displayed is for an explicit client. 

ro, rw 

Indicates whether the mount is read-write or read-only. 

name 

The name of the mounted BFS directory, SFS directory, 

or minidisk. 

IP address 

The IP address from which the mount was requested. 

user ID 

The VM user ID under which the mount was requested. 

This will contain “anonymous” if the mount was made 

anonymously. 

Examples 

The operands that follow can be used with the USER, IP or ALL operands to 

obtain additional information, as follows: 

DETAILS 

Provides counter values for various NFS requests. 

VERSIONS 

Provides separate request counter values for NFS version 2 requests 

and NFS version 3 requests. 

Refresh user_id.vaddr 

Directs the NFS server to update information it is maintaining about a 

particular minidisk, where: 

v user_id identifies the VM user ID that owns the minidisk 

v vaddr is the minidisk virtual address. 

v 

The following example instructs the NFS server to discard any disk blocks 

buffered from the TCPMAINT 592 minidisk. 

smsg vmnfs example1m refresh tcpmaint.592 

The reply from the SMSG command is sent by the CP MSG command. The 

message text returned for this command is: 

EXAMPLE1M REFRESH TCPMAINT.592 completed. 

If a busy reply is sent, the message text is: 

EXAMPLE1M REFRESH TCPMAINT.592 busy. 

v 

The busy reply is generated if the VM NFS server cannot find a moment when a 

client request is not using the referenced minidisk. The server tries for 10 

seconds before generating a busy reply. If a busy reply is received, you can try 

the command again. 

The following example asks for a display of NFS server activity. 

smsg vmnfs m q 

The reply from this QUERY command is sent by the CP MSG command. The 

message text (time and origin information added by CP is omitted) that might 

result from this example is: 


Name Translation File 

M VM NFS server start time 18Jan1999 08:50:48. 

M 238 RPC (0 duplicate XID), 11 SMSG, 5 *BLOCKIO 

M 0 null, 6 getattr, 7 setattr, 98 lookup, 12 read, 4 write 

M 4 create, 3 remove, 2 rename, 0 link, 70 readdir, 14 statfs 

M 13 mkdir, 1 rmdir, 0 symlink, 0 readlink, 0 access, 0 mknod 

M 0 readdir+, 0 fsstat, 0 fsinfo, 0 pathconf, 0 commit 

M 2 mount, 0 mountpw, 1 mountnull, 0 unmount, 0 unmount-all 

M 1 pcnfsd auth, 0 unsupported 

M End of reply. 


The VM NFS server creates the translation file ##NFS## #NAMES# on a: 

v CMS minidisk, or 

v SFS top directory 

that has been mounted read-write with default name processing when the first 

client request to create an invalid file name for CMS is received. The translation 

file contains both the original client file names and the corresponding CMS file 

names that are generated. 

The names translation files are hidden from NFS clients. That is, lookup or readdir 

requests do not return an entry for these files. Please note that these files are only 

visible to CMS users of the minidisk or directory. 

Attention 

You can destroy a name translation file by writing incorrect data to the file. 

This damages the internal structure of the file. 

You can also destroy a name translation file by erasing or renaming it using 

CMS. 

Special File Names for VM NFS 

The file names (.) and (..) are handled as special cases by the VM NFS file server. 

No name translation is performed. For minidisk, the file lookup procedure in the 

server treats each of these file names as a request for the file handle of the 

directory (the CMS minidisk itself). For SFS and BFS, a file name of (..) is treated as 

a request for a lookup of the parent directory of the current object. A file name of 

(.) is treated as a request for a lookup of the current object. This convention 

supports interpretations that are common in UNIX NFS clients. 

Special File Name Considerations 

Note for ESM-protected file pools: an NFSERR_ACCES error code may indicate 

that you do not have the correct authorization to perform the desired operation on 

the target file, or on the name translation file that resides in an SFS top directory. 

Note to UNIX users: CMS file rename semantics differ from UNIX. CMS uses file 

names to denote files, unlike the inode organization that UNIX uses for its files. 

Changing the name of a file for which some client has a file handle makes that file 

handle invalid, because there is no longer a file with the name denoted by the file 

handle. If a new file is created with the old name, or an existing file is renamed to 

the old name, the old file handle denotes the new file. 



NFS Client Problems 

UNIX systems avoid a similar problem when reusing inodes, because they 

maintain an inode generation number which, in combination with the inode 

number, uniquely identifies a file. A new file with the name that another file used 

to have is different from the old file, because the inode number and generation 

number of the new file is different from the old one. 

Some client implementations have a particular problem with deleting files from 

CMS minidisks. The problem results from a discrepancy between assumptions 

made by the client about how the VM NFS server manages a directory, and the 

actual mechanism used by CMS to manage the directory on a minidisk. The 

problem occurs when the PC-DOS client undertakes an operation such as delete 

*.c. This operation starts with the client reading a buffer of file names 

(read-directory operation) from the server, and receiving a cookie (file name) that 

references a particular position in the directory. The client then examines the 

names, finds one or more that match the specified pattern, and emits erase-file 

calls for the matching names. Because CMS maintains a compact directory, the hole 

created by deleting a file is filled by moving the data from the last file in the 

directory into the hole and shortening the length of the directory itself. 

When the client finishes erasing all appropriately named files in this first group of 

file names, it calls the server (using the previously obtained cookie) toread 

another group of file names. However, a number of file names (equal to the 

number of erased files) can no longer be seen by the client, because the directory is 

not the same as when the first group of file names was read. In this example, if 

one of the holes was filled with data for a file that matches the “*.c” pattern, one 

or more files that should have been erased are retained. 

A similar problem between the client and server, again due to a cookie-related 

discrepancy, can occur with BFS and SFS managed directories, with some NFS 

client implementations. 

You can avoid these problems by making the client application repeat the delete 

request, if it deletes any files using a wildcard pattern, until it receives a return 

value indicating that no file names were matched by the pattern. For more specific 

instructions for particular clients please refer to the VM TCP/IP homepage at: 

http://www.ibm.com/s390/vm/related/tcpip/ 

Deleting CMS Record-Length Fields 

Using NFS with RACF 


In the past, the VCMS C sample program was provided to read variable format 

(V-format) files and delete CMS record-length fields. This sample is no longer 

provided. Instead the lines option can now be specified on MOUNT requests to 

prevent CMS record-length fields from being inserted in the NFS data stream (if 

CMS record-length fields are not needed). 

The Resource Access Control Facility (RACF) allows NFS servers to act as 

surrogates for other user IDs. This means that the server can access those disks 

available to a given user ID. 

The command that allows NFS servers to act as surrogates is provided in a 

program called NFSPERM EXEC. To use it, enter the command: 

NFSPERM ADD


VM NFS Server Link Support 

If you get an error, contact your system administrator. 

You may delete the NFS server’s surrogate authority by issuing the command: 

NFSPERM DELETE 

NFSPERM is explained in the “Using TCP/IP with External Security Manager” 

section of the TCP/IP Planning and Customization publication. 

Two kinds of links are supported in the NFS protocol, hard links and symbolic 

links. Hard links are supported by the NFS LINK procedure, and symbolic links 

are supported by the NFS SYMLINK and READLINK procedures. VM does not 

natively support hard links and symbolic links for minidisk file systems and SFS, 

but there is native support for hard links and symbolic links in BFS. 

SFS and Minidisk Links 

The VM NFS server provides no additional support for symbolic links on minidisk 

or in SFS, but it does provide limited support for minidisk and SFS hard links. 

This support is minimal, and is intended to facilitate some NFS clients’ 

intermediate use of hard links during NFS operations such as RENAME. 

BFS Links 

The VM NFS server fully supports hard links and symbolic links in BFS. A 

symbolic link may appear in NFS READDIR output, and may be a component of a 

BFS pathname on an NFS MOUNT command or other NFS client commands. 

The VM NFS server provides limited support for BFS external links, even though 

these fall outside the scope of the NFS protocol. MOUNT external links may 

appear in NFS READDIR output, may be targets of NFS READLINK procedures, 

and may be components of BFS pathnames on an NFS MOUNT command or other 

NFS client commands. NFS READLINK does not support CMSDATA, CMSEXEC, 

or CODE external links, but they may appear in NFS READDIR output. Creation 

of external links, and I/O operations on external links, are not supported by the 

VM NFS server. 

Because symbolic links and MOUNT external links may be BFS pathname 

components, seemingly inconsistent behavior related to pathname parsing can 

occur during some NFS operations. NFS clients interpret the contents of symbolic 

links and MOUNT external links when they are encountered as pathname 

components, and different NFS clients may interpret them differently; this can 

affect the outcome of NFS READDIR operations and other NFS operations. 

v 

v 

v 

v 

The use of consecutive periods (..) in a BFS pathname can cause problems. 

UNIX-type implementations interpret this to mean the parent directory of the 

current directory, and it may be meaningless in non-UNIX-type implementations. 

The OpenEdition VM fully-qualified BFS prefix “/../VMBFS:” can be a problem 

if it appears other than at the beginning of a pathname. 

A slash (/) at the beginning of a BFS pathname can imply that the subsequent 

path is relative to the root of the current file system, and the absence of a slash 

at the beginning can imply that the subsequent path is relative to the current 

directory. 

A slash (/) at the end of a pathname can imply that a link should be followed, 

and the absence of a slash at the end can imply that a link should not be 

followed. 



The following recommendations should thus be observed: 

v Consider the run-time perspective of the NFS client when constructing 

pathnames for symbolic links and MOUNT external links in BFS. 

v Do not use consecutive periods (..) in a BFS pathname unless its meaning will be 

unambiguous at run time. 

v Be conscious of whether links are being specified relative to the expected current 

directory at run time, or relative to the root of the file system. 

Refer to the z/VM: OpenExtensions User’s Guide and the z/VM: OpenExtensions 

Command Reference for more information on BFS symbolic links, external links, and 

pathname syntax and resolution. 


Chapter 9. Using the Remote Execution Protocol 

REXEC Command 

The Remote Execution Protocol (REXEC) is a remote execution client that allows 

you to execute a command on a foreign host and receive the results on the local 

host. This chapter describes how to use the REXEC command, and its associated 

NETRC DATA file. 

The REXEC client passes a user name, password, and command to an REXEC 

daemon on a foreign host, which provides automatic logon and user 

authentication, depending on the parameters set by the (client) user. If the 

authentication process succeeds, the command is issued, and any results are 

returned to the client. If the authentication fails, an error message is displayed on 

the local host. 

An REXEC daemon must be running on the foreign host where your command is 

to be issued. For information about the TCP/IP REXEC daemon (REXECD), see 

TCP/IP Planning and Customization. For information about REXEC daemons on 

other platforms, see the appropriate documentation associated with the foreign 

host being used. 

Use the REXEC command to execute commands on a foreign host and receive the 

results on the local host. 

►► 

REXEC 

-? -d -t timeout 

► 

► 

-n -k -l user_id -p password 

-s 512 

-s port 

► 

► 

-w 80 

-w width 

foreign_host command ►◄ 

Operands 

-? Displays the help message. 

-d Activates debug tracing. 

-t timeout 

Sets idle time-out. This option specifies the time (in seconds) in which a 

connection closes if there is no activity. By default, the session will remain 

active until the remote system closes the connection. 

-n Suppresses use of the NETRC DATA file and hence automatic logon to the 

foreign host. 

-k Suppresses prompts for the logon user name and password. Use this option 

when a NETRC DATA file is used and command input is to be obtained 

through non-interactive means, such as from an exec. 


Using REXEC 

Examples 

-l user_id 

Specifies a user ID that is valid on the foreign host. Depending on the type of 

host, user_id may be case sensitive. 

-p password 

Specifies the password associated with user_id. The password may also be case 

sensitive. 

-sport 

Specifies the TCP port number of the REXEC daemon on the foreign host. The 

default for port is 512. 

-w width 

Specifies the maximum width to use for lines written by REXEC. The 

minimum acceptable width is 1, while the maximum is 32767. The default for 

width is 80. Note that circumstances on the remote host continue to affect or 

restrict output when the w operand is used. 

foreign_host 

Specifies the name or internet address of the foreign host to which you are 

sending your command. You can specify the foreign host by its host name or 

internet address. 

command 

Specifies the command that is sent to the foreign host. The command can be 

composed of one or more words. After checking for any prefixed parameters 

(-l, -p, and -s) and obtaining the foreign host, the remaining REXEC argument 

string is assigned to command. Depending on the type of foreign host, the 

command may be case sensitive. 

v 

The following example shows the results obtained for an REXEC command 

issued against another VM system. In this example, the CP QUERY NAMES 

command has been executed by an rexec daemon agent (RXAGENT1) on host 

ODDJOB, as a result of a user specifying a user ID and password of “GUEST”. 

rexec -l guest -p guest -s 512 oddjob cp q names 

VMNFS - DSC, SMTP -DSC, PORTMAP - DSC 

LPSERVE - DSC, FTPSERVE -DSC, REXECD - DSC 

SNMPQE - DSC, SNMPD -DSC, RSCS - DSC 

TCPIP - DSC, PVM -DSC, GCS - DSC 

OPERSYMP - DSC, DISKACNT -DSC, EREP - DSC 

TCPMAINT - DSC, RXAGENT1 -DSC, 

VSM - VTAM 

VSM - TCPIP 

Ready; 

RUNNING 

GDLVM7 

Usage Notes 

The NETRC DATA File 

v 

If you omit the user name or password, REXEC prompts you to supply them, 

unless they are defined in a NETRC DATA file, or unless the -k option has been 

specified to suppress prompting. 

The NETRC DATA file provides an alternative for specifying the REXEC user_id 

and password parameters. If these parameters are defined within this file for a 

specific host, they can be omitted when you issue an REXEC command against 

that host. 


For more information on the NETRC DATA File and how it may be used with 

other applications, see Appendix B, “Using the NETRC DATA File” on page 293. 

The following sections should be reviewed before REXEC commands are issued 

against a VM host running TCP/IP, as they provide important information about 

the REXEC support provided in the VM environment. 

Anonymous Remote Command Execution 

Using REXEC 

TCP/IP provides support for “anonymous” REXEC command execution through 

the use of one or more REXEC “agent” machines. These machines can be used by 

specifying either of the following user ID and password combinations: 

User ID Password 

ANONYMOU ANONYMOU 

GUEST GUEST 

Note: Only the first eight characters of the above values are verified. For the case 

when ANONYMOU is used, longer strings that begin with ″ANONYMOU″ 

(such as ″ANONYMOUS″) may be accepted. Also, note that these values are 

not case-sensitive. 

When an agent machine is used to execute an anonymously-supplied command, 

the command is passed on to, and executed within, an available agent machine. 

After the command completes, output is obtained by REXECD via IUCV 

communications and is passed on to the REXEC client; the agent machine is then 

made available to process other anonymous REXEC commands. Note that since 

multiple agent machines may be in use on the remote VM host, there is no 

guarantee that the same agent will be used to process successive REXEC 

commands. Also, since a given agent machine handles multiple users’ requests, the 

internal state of that machine may vary as different commands are issued. 

Command Execution Using Your Own Virtual Machine 

A CMS user’s own virtual machine can also be used to execute REXEC-supplied 

commands. When this is done, command processing is performed in much the 

same way as that done with RXAGENT machines. The main difference is that your 

virtual machine is autologged following user and password authentication, and 

then logged off after the given command has completed. 

It should be noted that if a client application sends consecutive REXEC commands 

in quick succession to the VM TCP/IP REXECD server machine, one (or more) of 

these commands may fail due to errors associated with logging on the intended 

virtual machine. For example, the message “Unable to autolog user user ID” may 

be received. Errors such as this may occur due to timing conflicts between the 

autolog processing and that of the supplied commands. This situation can be 

avoided by enlisting the use of an RXAGENT machine or by adding an 

appropriate delay between consecutive commands issued by the client. 

In addition to the items listed in the Notes and Restrictions section, the following 

considerations apply to any CMS user’s virtual machine used for REXEC command 

processing: 

1. The user machine must not be active when REXEC requests are made against 

it. If the user’s machine is logged on or disconnected, the REXEC request will 

be rejected. 

Chapter 9. Using the Remote Execution Protocol 171

Using REXEC 

2. Any machine used to process REXEC commands must access the TCP/IP client 

minidisk TCPMAINT 592, in its PROFILE EXEC. This is necessary so that the 

RXSNDIU EXEC is available, which is used to process data provided by 

REXECD after the machine has been autologged. 

3. Your PROFILE EXEC should not attempt to process data in the console input 

buffer or program stack. Such processing, if performed, may prevent REXEC 

commands from being processed. Additionally, the PROFILE EXEC must not 

require user intervention. 

Notes and Restrictions 

1. Due to the manner in which command output is obtained from agent machines, 

secondary consoles must not be defined for them. If a secondary console is 

defined, REXECD will not be able to send command results back to the REXEC 

client. 

2. When the REXECD server autologs a virtual machine, it passes several 

parameters. In doing so, the # (pound) symbol is always used as the LINEND 

character. If a different LINEND character is in effect for the agent machine(s), 

REXEC commands will not be processed successfully. In such cases, the agent 

machine’s PROFILE EXEC will need to be modified to set the LINEND 

character to #, with the CP TERMINAL command. For example, when the 

foreign host is a VM system you would enter: 

CP TERMinal LINEND # 

3. Because the REXEC protocol doesn’t allow for user interaction, commands to be 

executed remotely must complete without the need for user intervention. When 

a VM system is the foreign host involved, commands such as FILELIST should 

not be executed via REXEC. 

4. The combined length of all REXEC operands, including spaces, is limited to 255 

bytes. Therefore, the number and length of the operands that precede the 

command operand (such as -d or -l userid) will further restrict the length of a 

command that can be sent to a foreign host. 

Commands submitted to remote VM hosts are further limited, because of 

REXECD processing constraints. Commands that are processed anonymously 

by an RXAGENT maachine are limited to 227 bytes; those processed by a CMS 

user’s own virtual machine are limited to 189 bytes. 

Using RSH commands with REXECD 

TCP/IP provides limited support for rsh, remsh, and similar commands. When 

such commands are issued against a VM host, a command to be executed on the 

remote VM host must be supplied. There is no support for the processing of 

interactive commands. 

When an rsh command is received, it is processed by the VM REXECD server in 

essentially the same manner as an REXEC command. The same user ID and 

password verification mechanisms used for REXEC commands are used for 

rsh-supplied commands as well. An attempt is made to log on to the VM user ID 

that is identical to the local login id used to issue the rsh command; the value used 

is usually that which is maintained in the LOGNAME variable on Unix-based 

systems. The only exception to this is when a special password value of *guest has 

been provided. 

Because VM requires a password to be supplied when logging on to a user, a 

password must be available. The rsh and remsh commands however have no 

inherent provision for doing so. Moreover, there is no rhosts (or similar) file 


maintained by the VM host for remote user authentication purposes. To bypass 

these limitations, the -l flag of the rsh command is used to provide the VM logon 

password as part of the rsh command. For example, when the following rsh 

command is issued from an AIX system by the user wellsjr: 

rsh gd3vm0 -l blues2me q cmslevel 

the VM user ID WELLSJR will be logged on using the password BLUES2ME. The 

QUERY CMSLEVEL command is then executed on the host GD3VM0. 

On other platforms, the rsh command may need to be specified using different 

flags. For example, from an OS/2 client, the above rsh command needs to be 

specified with both the -l and the -u flags: 

rsh gd3vm0 -u welljr -l blues2me q cmslevel 

Using REXEC 

If a user has no user ID on a remote VM system, rsh commands can still be issued, 

though in an anonymous manner. In this case, the supplied command will be 

processed by an REXEC agent virtual machine. To have an rsh command processed 

in this way, you need to specify a special value of *guest via the -l flag as shown 

below: 

rsh gd3vm0 -l *guest q cmslevel 

Chapter 9. Using the Remote Execution Protocol 173

Using REXEC 


Chapter 10. Using Remote Printing 

LPRSET Command 

TCP/IP provides client and server support for remote printing. The remote 

printing application allows you to spool files remotely to a line printer daemon 

(LPD). The line printer client (LPR) sends the spooled file to a specified print 

server host and to a specified printer. 

The following commands are described in this chapter: 

v LPRSET 

v LPR 

v LPQ 

v LPRM 

Use the LPRSET command to define default printer and host values for the LPQ, 

LPR, and LPRM remote printing commands, or to set additional defaults for the 

LPR command. 

►► 

LPRSET 

printer host Optional Parameters 

►◄ 


( 

PERMANENT TRACE (1) ) 

SESSION TYPE RESET 

Options 

Options: 

QUERY VERSION NICKNAME name TAG usertag 

► 

► 

TRANSLATE 

tablename 

SYNCHRONOUS 

ASYNCHRONOUS 

Asynchronous Options 

Asynchronous Options: 

RSCS 

linkid,nodeid 

linkid@nodeid 

linkid at nodeid 

SERVER 

rscsid 

Notes: 

1 When RESET is specified, printer and host are not valid. 


Remote Printing Commands 

Operands 

Note: You can use the shortest available unique character sequence as a minimum 

abbreviation for an LPRSET parameter. 

printer 

Specifies the name of the printer to be used for the LPQ, LPR, and LPRM 

remote printing commands; printer is restricted to 255 characters. 

host 

Specifies the name or internet address (in dotted-decimal form) of the printer 

host to be used for the LPQ, LPR, and LPRM remote printing commands; host 

is restricted to 255 characters. 

ASYNCHRONOUS 

This option will send LPR requests to another server (RSCS) for later printing. 

As a result, this causes LPR operations to be deferred. When this option is in 

effect, subsequent LPR commands cause data to be queued to an intermediate 

print service machine (an RSCS server). As a result, interaction with a remote 

print daemon is handled by this service machine and ensures your file will be 

processed with no further action required by you. Messages and status 

information associated with a deferred transaction are returned to your 

console. 

NICKNAME name 

Specifies a nickname (defined in your CMS NAMES file) that identifies the 

printer and host to which files are directed for printing. Printer-specific options 

can also be defined using such an entry. See LPR Usage Note 3 on page 188 

and “Examples - Printing Using Nicknames” on page 186 for more information 

about specifying values through nickname definitions and how nicknames and 

values can be used. 

PERMANENT 

Causes values to be maintained on a permanent basis (across separate 

LOGONs). By default, values are maintained only for the duration of the 

current initialization (IPL) of CMS. All values are affected when this option is 

used. 

QUERY 

Displays the current settings. 

RESET 

Causes all values to be re-initialized to null values. When this option is used in 

conjunction with the PERMANENT option, all values are reinitialized; when 

used with the SESSION option, only session-related values are reinitialized. If 

neither PERMANENT or SESSION is specified only current, in-storage values 

are affected. 

For information about how to reset individual values, see Usage Note 2. 

RSCS linkid,nodeid 

RSCS linkid@nodeid 

RSCS linkid AT nodeid 

Identifies the RSCS link that provides a connection to a target print daemon or 

device, where: 

v 

v 

linkid is the one- to eight-character link identifier of the RSCS link that 

provides the connection to the chosen print daemon or device. 

nodeid is the one- to eight-character node name of the remote VM system 

that provides the connection to a target print daemon or device. 


Examples 

When specific link and node values are not defined, “LPR” is used as the 

default link identifier (linkid) for non-PostScript files, while “LPRP” is used for 

PostScript files; the local node (as returned by the CMS IDENTIFY command) 

is used for nodeid. 

Note: This option applies only to asynchronous LPR processing. 

SERVER rscsid 

Identifies an RSCS service virtual machine to which print data is to be spooled. 

By default, the RSCS server reported by the CMS IDENTIFY command is used. 

Note: This option applies only to asynchronous LPR processing. 

SESSION 

Causes values to be defined for a session (generally, from LOGON to 

LOGOFF). By default, values are maintained only for the duration of the 

current initialization (IPL) of CMS. All values are affected when this option is 

used. 

SYNCHRONOUS 

Causes LPR operations to be processed immediately; this is the default. When 

this option is in effect, subsequent LPR commands are processed as immediate 

operations through the TCP/IP server and the chosen print daemon. Delays in 

command execution (caused by network congestion, for example) may be 

apparent, because synchronous processing is dependent upon the interaction 

between the TCP/IP service machine and the specified print daemon. 

TAG usertag 

Identifies a specific NAMES file tag from which printer and host destination 

information is to be retrieved. If such a tag is not identified, an attempt is 

made to retrieve printer and host values from a set of default tag definitions. 

For more information about how destination information is retrieved for a 

nickname entry, see LPR Usage Note 4 on page 189. 

TRACE 

Displays detailed command progress information. 

TRANSLATE tablename 

Identifies the file name of a translation table to be used for EBCDIC to ASCII 

data translation. See TCP/IP Planning and Customization for more information 

on creating and loading translation tables, as well as the ″Using Translation 

Tables″ chapter in this publication. 

TYPE 

Displays abbreviated command progress information. 

VERSION 

Displays program version information. 

v 


To set the default printer and host as printer LPTQ1 on host prtsrv, enter the 

following command: 

lprset LPTQ1 prtsrv 

v 

The default values established with this LPRSET command will be lost if CMS is 

reinitialized (that is, re-IPL’d). To make this selection permanent, use the 


lprset LPTQ1 prtsrv (perm 

To display the version of LPRSET currently in use, enter this command: 

Chapter 10. Using Remote Printing 177


v 

v 

v 

v 

lprset (ver 

To establish a nickname default so that values defined for the NAMES file entry 

SIMPLPRT will be used when LPR commands are processed, issue the following 

command: 

lprset (nick simplprt 

To set a nickname default so that values defined in your CMS NAMES file by 

the CMPLXPRT nickname will be used when LPR commands are processed, issue 

the following command: 

lprset (nick cmplxprt 

To ensure specific printer and host values defined by the :TSTPRINT tag entry 

(associated with the CMPLXPRT nickname) are used for LPR commands, use the 

TAG option in addition to NICKNAME option, as follows: 

lprset (nick cmplxprt tag tstprint 

To reset in-storage nickname and tag values so they will not be used for 

subsequent LPR commands, but still maintain current values for other 

parameters, use the following command: 

lprset (nick . tag . 

To establish the default translation table name as MYXLATBL, enter the following 

command: 

lprset (translate myxlatbl 

Usage Notes 

LPR Command 

1. Parameters established using the LPRSET command are maintained using CMS 

global variables. This allows these values to be shared by the various TCP/IP 

remote printing commands and allows values to be retained (either temporarily 

or permanently) for subsequent use. For more information about CMS global 

variables, see the z/VM: CMS Command and Utility Reference. 

Note: The printer and host values are recognized by all of the line printer 

commands; values set using options (such as NICKNAME and TAG) are 

recognized only by the LPR command. 

2. For operands other than printer and host, values can be reinitialized on an 

individual basis. For such operands, a value specified as a single period (.) will 

cause the current value to be nullified. For the RSCS and SERVER options, this 

will cause an appropriate system default to be reinstated. 

3. Parameters established with the LPRSET command can be overridden by using 

appropriate operands when LPQ, LPR and LPRM commands are issued. 

4. Printer names may be case-sensitive, though this depends upon the host to 

which remote printing commands are directed. In many cases, the printer name 

you provide must match the printer definition used by the remote host. For 

example, on UNIX-like systems, prt1 and PRT1 can refer to different printers. 

5. In most environments, the system defaults for asynchronous processing (that is, 

the default SERVER and RSCS linkid and nodeid values) should provide 

satisfactory results. Before setting non-default values for asynchronous 

processing, consult your RSCS operations support staff. 

Use the LPR command to print files on remote printers. 



►► LPR filename filetype 

A 

* 

filemode 

SYNCHRONOUS Options 

( Syn/Asyn Options 

ASYNCHRONOUS Options ) 

►◄ 

Syn/Asyn Options: 

► 

► 

PRINTER printer HOST host 

AT host 

CLASS mode_dflt COPIES @ host1 

CLASS 

VERSION 

data 

NICKNAMEname 

TAG 

usertag 

COPIES nn FILTER code LANDSCAPE TRACE 

TYPE 

NOCC 

CC 

(1) 

TRANSLATE 

tablename 

► 

► 

Synchronous Options: 

ACK 

NOACK 

NOBINARY 

BINARY 

BURST 

NOBURST 

HEADER 

NOHEADER INDENT nn 

JOB 

JOB 


data 

► 

► 

► 

LINECOUNT 55 

JOBNUM nnn LINECOUNT nn MAIL 

JNUM nnn 

TITLE title WIDTH nn 

NAME 


NAME data NOSECURE 

POSTSCRIPT 

NOPOSTSCRIPT 

► 

Asynchronous Options: 

FORM formname PREFIX data RSCS linkid,nodeid 

linkid@nodeid 

linkid AT nodeid 

SERVER 

rscsid 

► 

► 

SUFFIX 

data 

Notes: 

1 NOCC is the default for all files except those with a file type of LISTING or LIST3820, in which case CC is 

the default. 

Note: With some exceptions, you can use the shortest available unique character 

sequence as a minimum abbreviation for an LPR parameter. The exceptions 

are: 

v P and PR are presumed to mean PRINTER 

v H is presumed to mean HOST 

Operands - Synchronous and Asynchronous 

filename 

Specifies the name of the file to print. 



filetype 

Specifies the type of the file to print. 

filemode 

Specifies the mode of the file to print. If filemode is specified as an asterisk (*), 

the first file found in the CMS search order is used. If filemode is omitted, a file 

mode of “A” is assumed. If a CMS file mode number is not specified, the 

default is 1. 

Synchronous operations cannot be used to process files that have a file mode 

number of 3 or 4. For asynchronous operations, this restriction applies to only 

file mode number 3 files. See the z/VM: CMS User’s Guide for information 

about file mode numbers and how they are used by CMS. 

ASYNCHRONOUS 

This option will send LPR requests to another server (RSCS) for later printing. 

As a result, this causes LPR operations to be deferred. When this option is in 

effect, subsequent LPR commands cause data to be queued to an intermediate 

print service machine (an RSCS server). As a result, interaction with a remote 

print daemon is handled by this service machine and ensures your file will be 

processed with no further action required by you. Messages and status 

information associated with a deferred transaction are returned to your 

console. 

CC 

Causes the remote system to interpret the first character of each data line as 

ASA carriage control; this is the default for files with a file type of either 

LISTING or LIST3800. 

NOCC 

Prevents the remote system from interpreting the first character of each data 

line as ASA carriage control; this is the default for all files except those with a 

file type of either LISTING or LIST3800. 

COPIES nn 

Specifies the number of copies to be printed; the default is 1. Note that some 

remote servers may not recognize or honor requests to produce multiple copies 

of a file. For asynchronous operations, a maximum of 255 can be specified. 

CLASS data 

Specifies the print job classification to be used by the remote system when the 

print file is processed. By default, the host name (combined with the domain 

name, if available) defined in the TCPIP DATA file is supplied as data for 

synchronous operations; “A” is the asynchronous default. 

For synchronous operations, data is restricted to 31 characters. For print 

requests directed to a UNIX-like lpd, data will be printed on the burst (or, 

banner) page. For requests directed to a VM LPD server, data may be used as a 

spool file class. 

For asynchronous operations, data specifies a spool file class. For such 

operations, data must be a single alphanumeric value (A-Z or 0-9) or an 

asterisk (*). 

FILTER code 

Specifies the type of processing to be performed against print file data by the 

remote system. The filter code value must be a single letter. Both uppercase and 

lowercase letters are accepted, but uppercase letters are converted to lowercase 

since only lowercase filter values are recognized by remote print daemons. 


Filter codes provide carriage control. When a filter code is specified, LPR 

changes several of its conventions. When a filter code of f, l, orr, is specified, 

LPR does not paginate the processed file. Instead, it sends the data within the 

file as “plain” lines. The list that follows provides a description of available 

filter codes: 

Code Description 

f Print data as a sequence of lines 

l Print, passing through all control characters 

p Print with pagination 

r 

Print, and interpret the first column as FORTRAN (ASA) carriage 

control. The following characters are interpreted as indicated: 

Character Printing Action 

Space Start a new line of output 

+ Overprint this line on the previously printed line 

− 

Produce two blank lines, then begin a new line of 

output 

0 Produce one blank line, then begin a new line of 

output 

1 Start new page, and begin printing at first line 

For filter codes c, d, g, n, t, orv, LPR transmits the data as a byte stream (as 

though the BINARY option has been specified). 

HOST host 

AT 

@ 


host 

host 

Specifies the name or internet address (in dotted-decimal form) of the printer 

host where the file is to be printed; host is restricted to 255 characters. H is 

accepted as the minimum abbreviation for the HOST keyword. 

LANDSCAPE 

For synchronous operations, this option causes PostScript information to be 

added to the print file so that it will be printed by the remote system in 

landscape (rotated) format — provided the remote printer can process 

PostScript. 

For asynchronous operations, this option causes a form name of “LA” tobe 

used when the file is processed. When used in this context, this option will 

override any FORM value specified as part of a CMS NAMES file entry. 

NICKNAME name 

Specifies a nickname (defined in your CMS NAMES file) that identifies the 

printer and host to which files are directed for printing. Printer-specific options 

can also be defined using such an entry. See Usage Note 3 on page 188 and 

“Examples - Printing Using Nicknames” on page 186 for more information 

about specifying values through nickname definitions and how nicknames and 

values can be used. 

PRINTER printer 

Specifies the name of the printer on which the file is to be printed; printer is 

restricted to 255 characters. P is accepted as the minimum abbreviation for this 

option. 

SYNCHRONOUS 

Causes LPR operations to be processed immediately; this is the default. When 

this option is in effect, subsequent LPR commands are processed as immediate 



operations through the TCP/IP server and the chosen print daemon. Delays in 

command execution (caused by network congestion, for example) may be 

apparent, because synchronous processing is dependent upon the interaction 

between the TCP/IP service machine and the specified print daemon. 

TAG usertag 

Identifies a specific NAMES file tag from which printer and host destination 

information is to be retrieved. If such a tag is not identified, an attempt is 

made to retrieve printer and host values from a set of default tag definitions. 

For more information about how destination information is retrieved for a 

nickname entry, see Usage Note 4. 

TRACE 

Displays detailed command progress information. For synchronous operations, 

information about the interaction with the remote printer is also displayed. 

TRANSLATE tablename 

Identifies the file name of a translation table file to be used for EBCDIC to 

ASCII data translation; the file type for this file must be TCPXLBIN. The first 

tablename TCPXLBIN file found in the CMS search order is used. If this 

parameter is not specified, a default translation table is used (if one exists), 

which is defined by either a CMS NAMES file nickname entry or a CMS global 

variable; if neither exist, data translation is then performed as follows: 

v 

v 

For synchronous processing, LPR searches for and uses the LPR TCPXLBIN 

file first, and then the STANDARD TCPXLBIN file. If neither is found, an 

internal translation table is used. 

For asynchronous processing, default data translation processing is 

performed by the RSCS server to which files are directed, based on the 

configuration of that server. 

See TCP/IP Planning and Customization for more information about creating and 

loading translation tables, as well as the chapter on ″Using Translation Tables″ 

in this publication if your use of LPR requires specific translations to be 

performed. 

TYPE 

Displays abbreviated command progress information. 

VERSION 

Displays program version information. 

Operands - Synchronous 

ACK 

Requests the remote printer host to send an acknowledgment to the LPR 

command when the connection to that host is closed; this is the default. 

NOACK 

Requests the remote printer host to not return a receipt acknowledgment to the 

LPR command. This option was previously required if the receiving system 

was AIX; however, its use is no longer necessary. 

BINARY 

Causes print data to be sent without translation and without any indication of 

record boundaries. For example, use this option if the file is already in ASCII. 

At times a filter may also be required to achieve appropriate results; see the 

description of the FILTER operand on page 180 for more information about 

filter use. The BINARY option implies that the file to be printed is not 

PostScript. 



NOBINARY 

Causes print data to be converted from EBCDIC to ASCII when it is sent to the 

remote system; this is the default. 

BURST 

Causes a burst page to be printed on the remote printer; this is the default. 

This option controls whether burst (or, banner) page information is sent to the 

server. If a VM LPD server does not receive burst page information, it provides 

the best information available to a spool device, as CMS does not have an 

option to omit the burst page for print files. 

NOBURST 

Prevents a burst page from being printed on the remote printer. 

HEADER 

Causes a page header to be inserted by the LPR client at the beginning of 

every printed page — if the NOCC and NOBINARY options are in effect. 

HEADER is the default. To instead cause the remote printer to insert page 

headers, use the FILTER p and NOHEADER options. 

NOHEADER 

Prevents the LPR client from inserting page headers. 

INDENT nn 

Specifies the number of columns the remote printer indents output when the 

FILTER f or FILTER l options are in effect. 

JOB data 

Specifies a print job description, name, or other job information to be used by 

the remote system; a maximum of 99 characters can be specified. By default, 

the string “filename.filetype” is used for data. 

For a UNIX-like lpd, this option causes job information to be printed on the 

banner page; for a VM LPD server, it can be used to pass additional job 

information for use by that LPD server. 

JOBNUM nnn 

JNUM nnn 

Specifies the job number used to construct the file names of protocol-specific 

files sent to the remote print server. The provided value must be a three-digit, 

numeric string. If a specific string is not specified using this option, a 

three-digit random number is used. 

This option can be used to reduce the likelihood of problems caused by 

duplicate file names when many LPR jobs are initiated. To be effective toward 

this end, the files to be printed must be processed by a single VM user ID; as 

LPR commands are issued for each file, sequential job numbers should be 

specified using the JOBNUM option. However, collisions with jobs run by 

other virtual machines are still possible; a collision occurs when one of the 

print jobs fails. 

LINECOUNT nn 

Specifies the number of lines to be printed before a new heading is printed; the 

default is 55. This parameter has meaning only for files for which the CC 

option is not in effect (either explicitly or implicitly). A value of zero (0) can be 

used to prevent page ejects and page headers from being inserted in the print 

file. 

MAIL 

Causes mail to be sent to you when the printing operation ends that informs 



you about the success or failure of the print job. This option may not 

recognized by all remote printing servers. 

NAME data 

Specifies job name information to be provided by the remote system in 

response to a remote printer query (that is, an LPQ command). The supplied 

data is restricted to 131 characters. By default, the string “filename.filetype” is 

used for data. This option is not recognized by all remote printing servers. 

NOSECURE 

Allows the LPR client to use any source port number greater than 1023 when 

print requests are processed. By default, a port number between 721 and 731 is 

used; if such a port is not available, an attempt is then made to use an 

available port below port 1024. 

Notes: 

1. Some remote printer hosts require the source port to be within either the 

721-731 port range, or the alternative 0-1023 range. 

2. Use the NOSECURE option to facilitate printing if the use of “well-known” 

ports (ports 0-1023) has been restricted on your system. 

POSTSCRIPT 

Causes header information to be added to the print file so that it will be 

recognized as PostScript by the remote printer. 

NOPOSTSCRIPT 

Prevents a file from being recognized as PostScript. 

TITLE title 

Specifies the title assigned to a file printed with the FILTER p option. A 

maximum of 79 characters can be specified for title. 

WIDTH nn 

Specifies the line width to be used for a file printed with the FILTER f or 

FILTER l option. The value you provide may be decreased by the remote 

printer host. 

Operands - Asynchronous 

FORM formname 

Specifies a spool file form name (used by RSCS) to control how data is printed 

at the destination printer. For PostScript data, formname can be specified as a 

character string of the form OrFnFsLs, to specify a default orientation, font 

name, font size, and additional leading size to be used by the destination 

printer. For OrFnFsLs the following can be specified: 

Or File Orientation 

PO Portrait (default) 

LA Landscape 

Fn Font 

CB Courier Bold 

CI Courier Oblique 

CP Courier (default) 

CX Courier BoldOblique 

HB Helvetica Bold 

HP Helvetica 

HI Helvetica Oblique 

HX Helvetica BoldOblique 

SP Symbol 

TB Times Bold 


TI Times Italic 

TP Times Roman 

TX Times BoldItalic 

Fs Font sizes, 04-99. The default is 11 for portrait (PO) and 10 for 

landscape (LA). 

Ls Additional leading size, 0.0-9.9 added to font size to give leading, 

specified as 00 thru 99. The portrait (PO) default is 09; that for 

landscape (LA) is 12. 

Notes: 

1. The font specified via OrFnFsLs must be installed and used by the 

destination printer for correct results to be achieved. 

2. For ASCII PostScript files, the default form name used is “P+ASCII”; for 

EBCDIC PostScript files, the default is “P+SCRIPT”. There is no default for 

non-PostScript files. 

3. FORM cannot be used with the LANDSCAPE option. 

4. The spool file form name (formname) is translated to uppercase prior to use. 

PREFIX data 

Specifies a data string to be passed to the remote printer device by the RSCS 

server; up to 500 characters can be specified. Prefix data is translated to 

uppercase and is inserted at the beginning of the data file by RSCS, and might 

be used to affect printer settings; for example, to select a paper tray. 

RSCS linkid,nodeid 

RSCS linkid@nodeid 

RSCS linkid AT nodeid 

Identifies the RSCS link that provides a connection to a target print daemon or 

device, where: 

v linkid is the one- to eight-character link identifier of the RSCS link that 

provides the connection to the chosen print daemon or device. 

v nodeid is the one- to eight-character node name of the remote VM system 

that provides the connection to a target chosen print daemon or device. 

When specific link and node values are not defined, “LPR” is used as the 

default link identifier (linkid) for non-PostScript files, while “LPRP” is used for 

PostScript files; the local node (as returned by the CMS IDENTIFY command) 

is used for nodeid. 

SERVER rscsid 

Identifies an RSCS service virtual machine to which print data is to be spooled. 

By default, the RSCS server reported by the CMS IDENTIFY command is used. 

SUFFIX data 

Specifies a data string to be passed to the remote printer device by the RSCS 

server; up to 500 characters can be specified. Suffix data is translated to 

uppercase and is inserted at the end of the data file by RSCS. A suffix data 

string might be used to affect printer settings; for example, to reset the printer 

state. 

Examples - General Printing 

v 


To print the file TEST LISTING on printer LPTQ1 on the host prtsrv, enter the 


lpr test listing (printer LPTQ1 host prtsrv 



v 

v 

v 

v 

Because the file type is LISTING, the first character of each line is interpreted as 

carriage control. To prevent this, use the NOCC option as shown in the 


lpr test listing (printer LPTQ1 at prtsrv nocc 

If an LPRSET command was previously issued to set the printer and host 

defaults to LPTQ1 and prtsrv (for example, LPRSET LPTQ1 prtsrv), the following 

command has the same effect as the second command shown in the previous 

LPR example: 

lpr test listing (nocc 

Because the lines in a listing file may be wider than a page, you may want to 

print the listing in “landscape” mode. The next example includes the 

LANDSCAPE option to print the TEST LISTING file in this mode: 

lpr test listing (landscape 

To print a source program (CSPROG1 FORTRAN) so that 57 lines are printed 

per page, enter the following command: 

lpr csprog1 fortran (linecount 57 

To print a file and have it processed by an RSCS server named RSCSTST, enter 


lpr demotest schedule (async server rscstst printer prt01@prtsys1 

In the above example, the file DEMOTEST SCHEDULE is processed by the 

RSCSTST server, and sent to the printer prt01 defined for the local host PRTSYS1. 

To print a file and have data translation performed based on the translation table 

named MYXLATBL, enter the following command: 

lpr trantest datafile (printer LPTQ1 host prtsrv translate myxlatbl 

In the above example, file TRANTEST DATAFILE is sent to the printer LPTQ1 

defined for the host prtsrv; the MYXLATBL TCPXLBIN table file is used to perform 

data translation. 

Examples - Printing Using Nicknames 

The examples that follow illustrate some typical NAMES file entries that might be 

constructed for use with the LPRSET or LPR commands. For detailed information 

about defining and using nicknames, see Usage Notes 2, 3 and 4. 

v 

The following example shows a simple NAMES file entry that defines only a 

printer and host name. 

:nick.SIMPLPRT :userid.lpt1 :node.oddjob.endicott.ibm.com 

The command: 

lpr profile exec (nick simplprt 

v 

will print file PROFILE EXEC on the oddjob.endicott.ibm.com host printer lpt1. 

In the next example, additional tag entries are included as part of a nickname 

entry. 

:nick.ADVPRT1 :userid.nullprt :node.nowhere.endicott.ibm.com 

:myprint.prt1@paradox.endicott.ibm.com 

:lpraddr.LPT2@monolith.endicott.ibm.com 

With the above entry, two different destinations can be used for printing, based 

on the options provided with an LPR command. 

When following command is issued: 



lpr deptg79 report (nick advprt1 

the printer and host name defined by the :LPRADDR tag are used (LPT2 and 

monolith.endicott.ibm.com). The :LPRADDR tag definition overrides the printer 

and host information defined by the :USERID and :NODE tags. This would also 

occur if LPT2 and monolith.endicott.ibm.com were defined using either a 

:TCPADDR or :CSADDR tag. For more information about how printer and host 

information is obtained for nickname entries, see Usage Note 4. 

If instead, the following command is used: 

lpr deptg79 report (nick advprt1 tag myprint 

the printer and host name defined by the :MYPRINT tag are used (prt1 and 

paradox.endicott.ibm.com). Again, any printer and host information defined by 

the :USERID and :NODE tags is ignored because the TAG option is specified. 

For asynchronous processing of the DEPTG79 REPORT file, the following 

command could be used: 

lpr deptg79 report (asynch nick advprt1 

v 

For this command, the DEPTG79 REPORT file would first be passed to the RSCS 

server of the local node (the default), and then would be sent to the prt1 printer 

of the paradox.endicott.ibm.com host. Because no RSCS link identifier was 

provided, a default link of either LPR or LPRP would be used. 

This last example illustrates how various tags might be defined and then used 

for synchronous and asynchronous remote printing requests. 

:nick.CMPLXPRT 

:tstprint.lpt0@rocketman.endicott.ibm.com 

:tcpaddr.PRTQ1@monolith.endicott.ibm.com 

:server.rscstst 

:linkid.lprtst 

:nodeid.GDLVME 

* Prefix string to turn duplexing OFF; the PostScript command 

* string is: %!PS-AdobeCRLF statusdict begin false setduplexmode 

* 

* This string should be one contiguous line; it spans multiple 

* lines here only to meet formatting requirements. 

:prefix.252150532D41646F62650D0A73746174757364696374206265676 

96E2066616C7365207365746475706C65786D6F646520656E640D0A 

* Suffix string to turn duplexing (back) ON; the PostScript command 

* string is: %!PS-AdobeCRLF statusdict begin true setduplexmode 

* 

* This string should be one contiguous line; it spans multiple 

* lines here only to meet formatting requirements. 

:suffix.252150532D41646F62650D0A737461747573646963742062 

6567696E20074727565207365746475706C65786D6F646520656E640D0A 

:translate.MYXLATBL 

If the nickname CMPLXPRT is specified in conjunction with the 

SYNCHRONOUS option on an LPR command, only values defined by the 

following tags will be used: 

– :TSTPRINT is used if TAG TSTPRINT is specified 

– :TCPADDR is used if the TAG option is not specified. 

– :TRANSLATE is used if the TRANSLATE option is not specified. 

If this same nickname is specified, but with the ASYNCHRONOUS option: 



Usage Notes 

– :TSTPRINT is used if TAG TSTPRINT is specified 

– :TCPADDR is used if the TAG option is not specified 

– :TRANSLATE is used if the TRANSLATE option is not specified. 

In addition, the values defined by all of the remaining tags shown will be used 

for processing — assuming no options are used that override them. For example, 

if the following command is issued: 

lpr weather report (asynch nick cmplxprt tag tstprint 

the WEATHER REPORT file would first be passed to the RSCSTST RSCS server, 

which then sends it to the RSCS node GDLVME. From GDLVME it is printed on 

printer lpt0 at host rocketman.endicott.ibm.com, using the RSCS link LPRTST. 

Because the :PREFIX and :SUFFIX tags define values, this data will also be 

passed to the RSCSTST server. Also, since the TRANSLATE option was not 

specified, data translation will be performed using the translation table named 

MYXLATBL, as defined by the :TRANSLATE tag. 

If the TAG tstprint option were omitted in the above command, the destination 

printer and host would instead be PRTQ1 and monolith.endicott.ibm.com. 

1. When LPR commands are issued and certain operands are omitted, LPR will 

attempt to use values defined by CMS global variables for the TCPIP group. 

Operands to which this applies are: 

v printer and host 

v RSCS linkid and nodeid 

v Mode of operation (SYNCHRONOUS or ASYNCHRONOUS) 

v NICKNAME name and TAG usertag 

v TRANSLATE tablename 

Values for these operands can be established and changed using the LPRSET 

command. 

2. LPR command operands are selected, in order, from the following sources: 

a. the LPR command itself 

b. CMS NAMES file entries 

c. CMS global variables 

Values from different sources may be combined and used for a single LPR 

command. 

3. CMS NAMES file tags recognized by the LPR command and the options to 

which they correspond follow: 

Tag 

Corresponding Option(s) 

:CSADDR PRINTER and HOST 

:FILTER FILTER 

:LPRADDR PRINTER and HOST 

:NODE HOST 

:TCPADDR PRINTER and HOST 

:USERID PRINTER 

:TRANSLATE TRANSLATE 

:LINKID 

RSCS 



:NODEID 

:PREFIX 

:SERVER 

:SUFFIX 

:FORM 

RSCS 

PREFIX 

SERVER 

SUFFIX 

FORM 

Tags listed in the first group are supported for both synchronous and 

asynchronous operations; those listed in the second group are applicable only 

to asynchronous use. For all tags, values should be specified in the same 

manner as for their corresponding options. 

4. Print destination information (that is, the combination of a printer and host 

name) is obtained for NAMES file entries, in order, from the following tags: 

a. a user-specified tag, as identified by the TAG option 

b. an “address” tag, if the TAG option is not specified. Address tags are 

checked, when present, in this order: 

1) :LPRADDR 

2) :TCPADDR 

3) :CSADDR 

c. the :USERID and :NODE tags, if no information is defined by any of the 

previously listed tags. In the context of using TCP/IP remote printing 

commands, these tags are presumed to provide printer and host names, 

respectively, instead of conventional user ID and node ID information. 

Printer and host values for user-specific tags and the address tags previously 

listed can be specified using one of these formats: 

v linkid nodeid 

v linkid,nodeid 

v linkid@nodeid 

v linkid AT nodeid 

5. Printer names may be case-sensitive, though this depends upon the host to 

which remote printing commands are directed. In many cases, the printer 

name you provide must match the printer definition used by the remote host. 

For example, on UNIX-like systems, prt1 and PRT1 can refer to different 

printers. 

6. For certain operands, values can be specified as quoted strings, so that the 

content between the string delimiters — either single (') or double (") quotes 

— is preserved. Operands for which quoted values are accepted are: 

PRINTER, HOST, CLASS, JOB, NAME, and TITLE. 

7. The LPR command can be used to print PostScript documents. When a file is 

processed by LPR, the file is checked to determine whether it is a PostScript 

file. If it is, additional checks are performed (for synchronous operations only) 

to verify that compatible options have been provided. If you want to override 

these checks when you print a PostScript file, use the NOPOSTSCRIPT option. 

Remote hosts usually examine the first few characters of a file to determine if 

that file is PostScript; this is usually indicated by the presence of the character 

string “%!” in the first line of the file. For synchronous operations, the 

POSTSCRIPT option can be used to ensure a file is recognized as PostScript. 

8. Carriage control is interpreted line by line. A file can mix ASA and machine 

carriage control. Interpretation is done by converting the controls to the 

appropriate ASCII sequences before the file is sent to the remote system. Lines 

that have invalid carriage control are not printed. 

When a file is printed without carriage control, LPR adds a heading line to 

each page of output that shows the name of the printed file, the name of the 



system on which the LPR command originated, and a page number. You can 

specify the number of lines per page (not counting the three heading lines) 

with the LINECOUNT option. 

9. The logical record length (LRECL) of files that can be processed is restricted 

for both synchronous and asynchronous operations. 

v 

For synchronous operations, LPR processes files using OS file routines. 

Thus for fixed-format files, the maximum LRECL is 32760; for 

variable-format files, the maximum LRECL is 32756. 

v For asynchronous operations, files are processed using RSCS services. For 

non-PostScript (or, “flat”) files, only those with an LRECL of 1280 or less 

can be processed in this manner; there is no restriction for PostScript files. 

10. Some LPDs require the FILTER l option — in addition to the BINARY option 

— to ensure the data file is not changed during BINARY transfers. With such 

implementations, the receiving LPD converts the incoming line-end character 

of X'0A' to two characters, X'0D0A', if the FILTER l option is omitted. (This 

situation has been observed when files are processed by an LPD on some DOS 

and OS/2 based systems; however, this behavior may not occur in all such 

environments.) 

11. Remote printer hosts determine whether sufficient space is available to receive 

a given file before it is processed. If sufficient space is not available, the file is 

discarded and the connection is terminated with a message that identifies this 

error condition. 

12. In most environments, the system defaults for asynchronous processing (that 

is, the default SERVER and RSCS linkid and nodeid values) should provide 

satisfactory results. Before setting non-default values for asynchronous 

processing, consult your RSCS operations support staff. 

13. For most operations, LPR issues messages only if errors are encountered. To 

monitor the progress of an LPR command or to obtain information for 

diagnostic purposes, use the TYPE or TRACE options. 

Controlling LPSERVE from other Systems 

When you use the LPR command to communicate with LPSERVE, you can provide 

additional information for LOCAL and RSCS services. This can be done by passing 

the desired information with the client LPR command options. 

For example, the VM LPR CLASS option or the UNIX lpr -C option is used by lpd 

in UNIX to specify a classification that is printed on the burst page. The VM 

CLASS or UNIX -C option, when sent to a VM LPD server, is used to alter the VM 

spooled file’s class. 

The VM LPR JOB option or the UNIX lpr -J option is used by lpd in UNIX to 

specify what is printed in this field of the burst page. The VM JOB or UNIX -J 

option, when used with a VM LPD server, specifies additional information to the 

VM server such as the distribution code, priority, password, or an alternative user 

ID or destination. Within the JOB or -J option, additional options can be used to 

specify these additional job parameters. 

The additional JOB options are: 

v For LOCAL services: FOR, PASS, DEST, and DIST 

v For RSCS services: FOR, PASS, DEST, IDENTIFIER, PRIORITY, and OTHERS 


LPQ Command 

If you use more than one option, separate each by a comma with no intervening 

spaces between options. If the OTHERS option is used, it must be the last option. 

You can enter keywords on the LPR command line in any combination of upper 

and lower case. 

For both LOCAL and RSCS services, you can use either of the following JOB 

options. 

Option Description 

FOR=user_id 

PASS=password 

Specifies a user ID other than the sending user ID for which the 

job is to be spooled. The default is the sender’s user ID. 

Specifies the password for user_id. The default is no password. This 

option is required only if the RACF option has been specified for 

the designated service. 

For LOCAL services, you can use the following additional JOB options. 


DEST=name Specifies the destination printer name or destination punch name 

for the job. The default is DEST=OFF. 

DIST=code Specifies the output distribution code. The default is DIST=OFF. 

For RSCS services, you can also give any of the following: the destination node ID, 

user ID, and priority. These options can also be given in any order (except the 

OTHERS keyword, which must be last) and must be separated by commas. 

Option 

Description 

DEST=destination 

IDENTIFIER=operand 

OTHERS=option_name 

PRIORITY=nn 


Specifies a RSCS destination node. The default is 

the node on which LPSERVE is running. 

Specifies the second TAG operand, which can be 

SYSTEM, JOB, a virtual machine user ID, or a 

workstation node ID. The default is SYSTEM. 

Specifies additional options for the destination 

RSCS. This option applies only if the specified 

service has the TAG option specified and is used to 

supply additional TAG information. This can, for 

example, be used to designate forms (for an MVS 

Network Job Entry (NJE) system) or controls for an 

IBM 3800 printer. The rest of the job data is used to 

tag the spooled file. The default is no additional 

options. 

Specifies the transmission priority. The default is 

50. 

Use the LPQ command to list the printer queue on a remote printer. 



►► 

LPQ 

job_id ( Options 

►◄ 

Options: 

All PRINTER name HOST host 

AT host 

TRACE 

TYPE 

VERSION 

Operands 

Examples 

Note: You can use the shortest unique sequence as the minimum abbreviation for 

an LPQ parameter. 

job_id 

Specifies either a user ID (must not start with a number), or a job number on 

the remote printer queue. If you do not specify job_id with the LPQ command, 

all jobs in the remote printer queue are listed. 

All 

Displays for all printers a report that shows print job information. 

Printer name 

Specifies the name of the printer for which printer queue information is to be 

obtained. 

Host host 

AT host 

Specifies the name or internet address of the printer host. AT is accepted as a 

synonym for HOST. 

Trace 

Displays detailed information about the interaction with the remote printer. 

Type 

Displays the progress of the command. 

Version 

Displays the version of the program. 

v 

To query the printer psnt on host system test1, enter the following command: 

LPQ (PRINTER psnt HOST test1 

v 

v 

This command displays a short listing of the jobs that are queued for the psnt 

printer. 

If the LPRSET command was previously issued, (LPRSET psnt test1), the 

following LPQ command has the same effect as issuing the command in the first 

LPQ example: 

LPQ 

To get a long listing, enter the following command: 

LPQ (PRINTER psnt HOST test1 ALL 



v 

v 

This command prints a long listing of the jobs queued, including the name of 

the host that created the jobs. 

To list the jobs for a user named smith, enter the following command: 

LPQ smith (PRINTER psnt HOST test1 

If you want only the information about job 123, enter the following command: 

LPQ 123 (PRINTER psnt HOST test1 

Usage Notes 

LPRM Command 

1. The LPQ command allows you to query the printer queues on remote systems 

that support this activity. The VM remote printing server implementation (LPD) 

does not support such client queries because, typically, the server does not hold 

print files in its internal queue. Instead, they are almost always spooled 

immediately to the operating system or, another virtual machine (such as RSCS) 

for printing. Thus, a window of time for which jobs can be queried while they 

are in the VM LPD print queue is almost nonexistent. 

2. If a printer or host name is not provided on the LPQ command, LPQ will use 

the GLOBALV variables PRINTER and PRTHOST, respectively, from the TCPIP 

group. These variables can be set by a program or by the LPRSET command in 

order to provide defaults for these values. 

3. Printer names can be case sensitive. The printer you provide must match the 

remote host’s definition for that printer. For example, on UNIX systems, psnt 

and PSNT can refer to different printers. 

4. A user name, when provided as a job_id, can be case sensitive. For example, 

smith and SMITH may refer to different users on the same host. 

5. Some systems will not respond with job information, if you use a job number 

for a job that was not produced by the querying system. 

Use the LPRM command to remove a job from the printer queue on a remote host. 

►► 

LPRM 

job_id ( Options 

►◄ 

Options: 

PRINTER name HOST host 

AT host 

TRACE 

TYPE 

VERSION 

Operands 

Note: You can use the shortest unique sequence as the minimum abbreviation for 

an LPRM parameter. 

job_id 

Specifies either a user ID (must not start with a digit, or a job number in the 

remote printer queue. If you do not specify job_id with the LPRM command, 

your currently active job is removed. 



Examples 

PRINTER name 

Specifies the name of the printer with which the job is associated. 

HOST host 

AT host 

Specifies the name or internet address of the printer’s host. AT is accepted as a 

synonym for HOST. 

TRACE 

Turns on the trace details for the interaction with the remote printer. 

TYPE 

Displays the progress of the command. 

VERSION 

Displays the version of the program. 

v 

To cancel job number 123 on the printer psnt on the local system test1, enter 


LPRM 123 (PRINTER psnt HOST test1 

v 

v 

If you printed the job, it is removed. If the job is currently active, it is stopped. 

If the LPRSET command LPRSET psnt test1 was previously issued, entering the 

following LPRM command has the same effect as issuing the command in the 

first LPRM example: 

LPRM 123 

To cancel the currently active job, enter the following command: 

LPRM (PRINTER psnt HOST test1 

Usage Notes 

1. The LPRM command allows you to remove jobs from printer queues on remote 

systems that support this capability. The VM remote printing implementation 

(LPD) does not support such client requests because the server does not hold 

print files in its internal queue. Instead, jobs are usually spooled immediately to 

the operating system or to another virtual machine (such as RSCS) for printing. 

Thus, a window of time for which jobs can be removed while they are in the 

VM LPD print queue is almost nonexistent. 

2. If a printer or host name is not provided on the LPRM command, LPRM will 

use the GLOBALV variables PRINTER and PRTHOST, respectively, from the 

TCPIP group. These variables can be set by a program or by the LPRSET 

command in order to provide defaults for these values. 

3. Removing the currently active job can be sensitive to timing. If you have two 

jobs printing, and you use the LPRM command without the job_id parameter, 

the first job may finish, and you may inadvertently remove the second job. 


Chapter 11. Using GDDMXD/VM with the X Window System 

Overview of GDDMXD/VM 

TCP/IP provides the GDDMXD/VM interface for the IBM Graphical Data Display 

Manager/VM (GDDM*), which allows graphics to be displayed on workstations 

that support the X Window System. 

This chapter describes GDDMXD/VM and the GDDMXD command. This chapter 

also describes how to use GDDMXD/VM user-specified options and keyboard 

functions. Problem determination information associated with GDDMXD/VM is 

also described in this chapter. 

When GDDMXD/VM is installed and activated, the data stream created by GDDM 

is translated to the X Window System protocol and transmitted by TCP/IP to the X 

Window System server for the display. If GDDMXD/VM is installed and not 

activated, or has been made inactive, GDDM transmits data to its supported 

display device as if GDDMXD/VM was not present. 

GDDM Application Limitations 

GDDMXD/VM does not support the following types of applications: 

v Multiple instances of GDDM/VM 

v Opening multiple display devices at one time 

v Operator windows 

GDDM Display Limitations 

GDDMXD/VM appears as an IBM 3179G Color Graphics Display Station device 

model to GDDM. When the HostRast option is active, the device model is an IBM 

3279. The IBM 3179G model is used regardless of the display device nickname 

presented by the application. 

The GDDMXD/VM IBM 3179G device model contains the following features: 

Feature 

Description 

Blink Attribute 

Ignores the blinking character attribute. 

Detectable Fields 

Ignores the selector pen detectable fields. 

Character Display 

Displays characters with an EBCDIC value of less 

than X'40' as blanks. 

Graphics Cursor 

The X Window System pointer device cursor for 

the GDDMXD window is a crosshair pattern and 

moves as the pointer device is moved. 

Alphanumeric Cursor The alphanumeric pointer device is an open arrow 

when the keyboard is unlocked, or an “X” when 

the keyboard is locked. The cursor can be 

repositioned by moving the pointer to the desired 

character location and pressing a pointing device 

button. 

Pixel Spacing 

When the HostRast option is not active, the vertical 

and horizontal pixel spacing of the actual display 


Using GDDMXD/VM 

device that is obtained from the X Window System 

is supplied to GDDM. When the HostRast option is 

active, the pixel spacing of an IBM 3279 Color 

Display Station is supplied to GDDM. 

Appearance 

Color Mixing 

For all programmed symbol and image data that is 

received from GDDM, each GDDM pixel is 

mapped to one X Window System display pixel, 

which causes a different appearance from the same 

data stream displayed on an IBM 3179G Color 

Graphics Display Station. This mapping can also 

cause display differences in the placement of 

alphanumeric field data over the graphics display 

and in the appearance of the filled areas of the 

graphic display. When the HostRast option is not 

active, aspect ratio distortion of the displayed 

graphics appears, unless the aspect ratio of the X 

Window System display is the same as the IBM 

3279. 

GDDMXD/VM supports only the overpaint 

foreground color mix mode. The initial color of the 

image area is black, and mixing with the actual 

background colors is not performed. 

An exception is made for data passed by an image 

data order. In this case, a combined foreground 

color mix mode is supported, if the series of begin 

image orders have exactly the same parameter 

values. 

When the HostRast option is active, color mixing is 

performed by GDDM, not the X Window Display 

System, so the preceding exception does not apply. 

z/VM Considerations 

Before you can use GDDM applications with GDDMXD/VM on z/VM, issue the 

following command to ensure that GETMAIN requests by GDDMXD/VM are 

processed correctly by CMS. 


SET STORECLR ENDCMD 

The SET STORECLR ENDCMD command has no parameters. 

Before you can send GDDM data to an X Window System display, activate 

GDDMXD/VM by issuing the GDDMXD command in the following format. 

Note: If you do not want to run GDDM applications through the X Window 

System, do not enable GDDMXD/VM. 



►► 

GDDMXD 

OFF 

ON 

►◄ 

Parameter 

ON 

OFF 

Description 

Enables GDDMXD/VM. GDDM output is sent to the X Window 

System display. The system responds with GDDMXD/VM active. 

Disables GDDMXD/VM. The system erases the file that was 

created when GDDMXD/VM was activated and responds with 

GDDMXD/VM inactive. This is the default. 

Configuring the GDDMXD/VM Environment 

You must set several CMS global variables before running GDDM programs 

through GDDMXD. To create the proper environment, issue the following 

commands. 

GLOBAL LOADLIB SCEERUN 

GLOBAL TXTLIB GDDMXD ADMNLIB ADMPLIB ADMGLIB ADMHLIB X11LIB COMMTXT SCEELKED 

Identifying the Target Display 

Note: If GDDM/VM Version 2 is in use, omit ADMHLIB from the above GLOBAL 

TXTLIB command. 

These statements force GDDM applications to recognize GDDMXD’s presence and 

allow GDDM output to be directed to the specified X Window System. 

The X Window System uses the C environment variable DISPLAY to identify the 

internet address of the target display. 

The CMS GLOBALV command is used to set the required environment variable. 

►► GLOBALV SELECT CENV SET 

SETP 

DISPLAY host :target_server ► 

► 

.target_screen 

►◄ 

Parameter 

SELECT CENV 

SET 

SETP 

DISPLAY 

host 

Description 

The GLOBALV group that contains C environment 

variables. 

Defines the variable for the current IPL only. 

Defines the variable permanently. 

The C environment variable to be defined. 

The name or IP address of the host machine 

running the X Window System server. 

Chapter 11. Using GDDMXD/VM with the X Window System 197


target_server 

target_screen 

Specifies the number of the display server on the 

host machine. 

Specifies the screen to be used on the same 

target_server. 

GLOBALV SELECT CENV SET DISPLAY charm.cambridg.ibm.com:0.0 

or 

User-Specified Options 

GLOBALV SELECT CENV SET DISPLAY 129.42.3.109:0.0 

Use the workstation xhost command to allow GDDMXD access to the workstation 

you have selected. To send GDDM output to your selected X Server, enter the 

following: 

xhost vm_host_name 

The user-specified options for GDDMXD/VM are entries in a file called X 

DEFAULTS. The X DEFAULTS file is searched during initialization of 

GDDMXD/VM. 

Note: The values in the X DEFAULTS file are case sensitive and must be entered 

as shown. 

The following options are supported by GDDMXD/VM: 

v Geometry 

v GColornn 

v GMCPnn 

v ZWL 

v XSync 

v CMap 

v HostRast 

v XClConn 

v Compr 

v PDTrace 

v ANFontn 

v Enter 

v NewLine 

Resizing the GDDMXD Graphics Window 

GDDMXD supports four graphics window sizes. The initial window size is 

determined by the window width specified in the Geometry option of the X 

DEFAULTS file. Subsequently, the window size used by GDDMXD is determined 

by the width of the window resulting from any resizing that you may have done. 

The relationship of graphics window size (GDDMXD Graphics Presentation Space) 

to the actual window width is shown in Table 14. 

Table 14. Window Width and Window Size 

Window Width (pixels) GDDMXD Graphics Presentation Space (pixels) 

< 650 480 horizontal by 352 vertical 

>=650 to < 850 720 horizontal by 512 vertical 

>= 850 to 1024 1200 horizontal by 864 vertical 



For sizes other than the default graphics presentation space size of 720 pixels by 

512 pixels, bitmapped data such as symbol sets and images are expanded or 

contracted to meet the scaling requirements of the specified window size. 

Expansion is accomplished by duplicating rows and columns of the data and can 

result in a slightly different appearance than when viewed at the default size. 

Contraction is implemented for single-plane data by combining certain rows and 

columns of the data with a logical OR function. Because this may not yield 

acceptable results when a black on white image is viewed, a user option, Compr, is 

provided to specify that a logical AND function be used to contract the data. 

Contraction of multiplane bitmapped data is accomplished by eliminating certain 

rows and columns. Data compression results in a different visual appearance than 

when viewed at the default size. For more information about using this option, see 

“Compr” on page 204. 

Geometry 

To specify the size and location of the initial GDDM graphics window, use the 

Geometry option in the following format. 

►► 

gddmx*Geometry: 

750 

width 

× 

650 

height 

+ 

10 

x_offset 

► 

► 

+ 

10 

y_offset 

►◄ 

Parameter 

width 

height 

x_offset 

y_offset 

Description 

Specifies the width of the X-Window in pixels. The default width is 

750 pixels. 

Specifies the height of the X-Window in pixels. The default height 

is 650 pixels. 

Specifies the location of the upper left corner of the window where 

x_offset is the horizontal offset from the upper left corner of the 

display. The default horizontal offset is +10 pixels. 

Specifies the location of the upper left corner of the window where 

y_offset is the vertical offset from the upper left corner of the 

display. The default vertical offset is +10 pixels. 

The following is an example of a Geometry option. 

gddmx*Geometry: 600x400+20+20 

In this example, the Geometry entry in the X DEFAULTS file specifies the size of 

the initial GDDM graphics window. 

GColornn 

GDDMXD/VM provides a default mapping of GDDM colors (GColors) to X 

Window System colors. If you want to override a default color name or if a default 

color name is not available by your X Window System server, add a GColornn 

entry in the X DEFAULTS file. Table 15 on page 200 lists the GDDM colors that 



GDDMXD/VM maps to the X Window System. 

Table 15. GColors 

GColornn GDDM Color X Window System Color 

GColor1 Blue Blue 

GColor2 Red Red 

GColor3 Magenta Magenta 

GColor4 Green Green 

GColor5 Turquoise Turquoise 

GColor6 Yellow Yellow 

GColor7 White White 

GColor8 Black Black 

GColor9 Dark Blue Dark Slate Blue 

GColor10 Orange Orange 

GColor11 Purple Plum 

GColor12 Dark Green Dark Green 

GColor13 Dark Turquoise Dark Turquoise 

GColor14 Mustard Wheat 

GColor15 Gray Gray 

GColor16 Brown Brown 

The following is the format of the GColornn option. 

►► gddmx*GColornn: c ►◄ 

Parameter 

nn 

c 

Description 

Specifies the GDDM color entry that is mapped. 

Specifies the X Window System color that is used as the GDDM 

color. 

The following is an example of a GColornn option. 

gddmx*GColor3: Pink 

In this example, specifying the GColor3 entry in the X DEFAULTS file maps the 

GDDM color, Magenta, to the X Window System color, Pink. 

GMCPnn 

The GMCPnn entries in the X DEFAULTS file are used to override GDDM 

multicolor patterns (GMCP) with workstation color names. 

The following is the format of the GMCPnn option. 



►► gddmx*GMCPnn: c ►◄ 

Parameter 

nn 

c 

Description 

Specifies the GDDM multicolor pattern. 

Specifies the color that is used with the defined GDDM multicolor 

pattern. 

The following is an example of a GMCPnn option. 

gddmx*GMCP126: MediumBlue 

In the preceding example, the color MediumBlue is used when multicolor pattern 

126 is specified by the GDDM application. 

ZWL 

The X Window System supports a range of line widths. Because some X Window 

System servers draw wide lines at a slow rate, you can use the Zero Width Lines 

(ZWL) option to increase the speed at which GDDMXD/VM draws lines. 

ZWL directs GDDMXD/VM to draw all lines using zero width lines. The X 

Window System server uses the fastest drawing algorithm to draw the lines even 

though the resulting line may not be exactly the same as if it had been drawn as a 

wide line. 

The following is the format of the ZWL option. 

►► 

gddmx*ZWL: N 

gddmx*ZWL: 

Y 

►◄ 

Parameter 

Y 

N 

Description 

Directs GDDMXD/VM to use zero width lines for all drawing. 

Directs GDDMXD/VM to use normal width lines for all drawing. 

This is the default. 

XSync 

The X Window System operates asynchronously. By the time an error has been 

detected, the application may have issued more requests. 

The XSync option requests that the X Window System process one request at a 

time. 

Note: When the XSync option is specified to be on (Y), system performance is 

degraded. 

The following is the format of the XSync option. 



►► 

gddmx*XSync: N 

gddmx*XSync: 

Y 

►◄ 

Parameter 

Y 

N 

Description 

Directs GDDMXD/VM to request the X Window System to operate 

synchronously. 

Allows the X Window System to operate asynchronously. This is 

the default. 

CMap 

During initialization, GDDMXD/VM issues the X Window System call, 

XInstallColormap, to load the default color map (CMap). If the CMap option is 

specified as N, the XInstallColormap call is not made. This option accommodates 

the X Window System servers that load their own color maps and do not want the 

clients to load different color maps. 

The following is the format of the CMap option. 

►► 

gddmx*CMap: Y 

gddmx*CMap: 

N 

►◄ 

Parameter 

Y 

N 

Description 

Directs GDDMXD/VM to load the default colormap. This is the 

default. 

Directs GDDMXD/VM to bypass loading the default colormap. 

HostRast 

The default device model for GDDMXD/VM is an IBM 3179G Color Graphic 

Display Station with a mouse and raster image processing is performed at the 

workstation. The HostRast option enables you to perform the raster image 

processing at the VM host. 

When the HostRast option Y is specified, GDDM performs the raster image 

processing and transmits the picture as a series of characters whose pixel 

definitions have been transmitted to Programmed Symbol Sets. The picture is 

mapped exactly as an IBM 3279 Color Display Station. 

Note: If the ratio of horizontal to vertical pixel spacing is not the same as that of 

an IBM 3279, the aspect ratio can be distorted. 

You should use the HostRast option when: 

v Multiplane character symbol sets are required by the application. 

v GDDM color mixing is important to the application. 

Note: The APL2 character set is not supported when the HostRast option is active. 



The following is the format of the HostRast option. 

►► 

gddmx*HostRast: N 

gddmx*HostRast: 

Y 

►◄ 

Parameter 

Y 

N 

Description 

Directs GDDMXD/VM to use the IBM 3279 as a device model and 

perform raster image processing on the VM host. 

Directs GDDMXD/VM to use the IBM 3179G as a device model 

and perform raster image processing on the workstation. This is 

the default. 

XClConn 

The default operation of GDDMXD/VM creates the GDDMXD/VM window when 

the GDDM application opens the display device, destroys the window, and breaks 

the connection to the X Window System display when the application closes the 

display device. 

Some applications can repeatedly close and reopen the display device, which can 

cause a delay of several seconds to reestablish the connection to the X Window 

System display. The XClConn option instructs GDDMXD/VM not to close the 

connection to the X Window System when the GDDM device is closed. It is no 

longer necessary to use this option since GDDM will only close the X Window 

environment after a GDDM FSTERM call has been issued. All GDDM applications 

should issue the FSTERM call to close the environment. The option remains for the 

sake of compatibility with existing and older applications. 

The following is the format of the XClConn option. 

►► 

gddmx*XClConn: Y 

gddmx*XClConn: 

N 

►◄ 

Parameter 

Y 

N 

Description 

Instructs GDDMXD to close the connection to the X Window 

System when the display device is closed by the GDDM 

application. This is the default. 

Instructs GDDMXD to leave the connection to the X Window 

System active when the display device is closed by the GDDM 

application. With this parameter, GDDMXD cannot destroy the 

window and close the connection to the workstation when the 

application is finished with the device. The last GDDM graphics 

window created by the application is displayed until a GDDM 

application is started on the same System/370 (S/370 ) host for 

the same workstation, or until you explicitly destroy the window 

using the workstation window manager facilities. 



Compr 

The Compr option is used to control the technique used to compress (Compr) 

bitmapped data when a graphices window size of 480 by 352 pixels is in use. 

The following is the format of the Compr option. 

►► 

gddmx*Compr: Or 

gddmx*Compr: 

And 

►◄ 

Parameter 

And 

Or 

Description 

‘A’ or ‘a’ specifies that an AND function should be used when 

compressing bitmapped data. 

‘O’ or ‘o’ specifies that an OR function should be used. This is the 

default value. 

PDTrace 

The PDTrace option in your X DEFAULTS file is used to generate a GDDM 

problem determination trace (PDTrace). 

The following is the format of the PDTrace option. 

►► 

gddmx*PDTrace: N 

gddmx*PDTrace: 

Y 

►◄ 

Parameter 

Y 

N 

Description 

Generates GDDMXD trace information. 

Does not generate the GDDMXD trace information. This is the 

default. 

ANFontn 

The ANFontn option specifies the X Window System font that GDDMXD should 

use for displaying characters in the alphanumeric presentation space of the 

GDDMXD window. Graphics mode 1 and 2 characters in the graphics presentation 

space are not affected by this option. The value of n ranges from 1 to 4 and defines 

the X Window System font for each of the four sizes of presentation space 

supported by GDDMXD. The ANFontn option can be specified for any, all, or none 

of the four values of n. 

The X Window System fonts specified should be fixed-spaced fonts whose 

characters fit into the character box size required by each of the four presentation 

space sizes shown in Table 16. 

Table 16. X Window System Fonts 

n Presentation Space Character Box Example Font 

1 480 x 352 6 x 11 Rom8 



Table 16. X Window System Fonts (continued) 

n Presentation Space Character Box Example Font 

2 720 x 512 9 x 16 Rom11 

3 960 x 682 12 x 21 Rom14 

4 1200 x 864 15 x 27 Rom17 

Selecting a font whose characters are larger than the character box size can result 

in characters overlapping when displayed. 

The following is the format of the ANFontn option. 

►► gddmx*ANFontn fontname ►◄ 

Parameter 

n 

fontname 

Description 

Specifies the size of the presentation space. 

Specifies the name of the X Window System font. 

Remapping the Enter and Newline Keys 

GDDMXD/VM provides the following options to allow remapping of the “Enter” 

and “Newline” keys by the GDDMXD/VM user. 

Enter 

The Enter option can be specified in the X DEFAULTS file to identify which X 

Window System Keysym is to be mapped to the Enter function. The use of this 

option overrides the default mapping of the Keysym XK_Execute to the Enter 

function. 

The following is the format of the Enter option: 

►► gddmx*Enter: xxx ►◄ 

Parameter 

xxx 

Description 

Specifies the X Window System Keysym representing the physical 

key. For standard Keysyms, the XK_ prefix is not included in 

specifying the option. 

The following is an example of the Enter Option: 

gddmx*Enter: Return 

In the preceding example, the X Window System Keysym, XK_Return is mapped 

to the Enter function. 



Newline 

The NewLine option can be specified in the X DEFAULTS file to identify which X 

Window System Keysym is to be mapped to the NewLine function. The use of this 

option overrides the default mapping of the Keysym XK_Return to the Newline 

function. 

The following is the format of the NewLine option: 

►► gddmx*NewLine: xxx ►◄ 

Parameter 

xxx 

Description 

Specifies the X Window System Keysym representing the physical 

key. For standard Keysyms, the XK_ prefix is not included in 

specifying the option. 

The following is an example of the NewLine option: 

gddmx*NewLine: KP_Enter 

In the preceding example, the X Window System Keysym, KP_Enter is mapped to 

the NewLine funcion. 

GDDMXD/VM Keyboard Functions 

When you enter input to GDDM by GDDMXD/VM, use the following keyboard 

functions. 

v All alphanumeric keys 

v F1—F24 

If F13—F24 are not available, use Shift + F1 to Shift + F12 

v Tab or Shift + Tab 

v Directional arrows 

v End key to erase to the end of the field 

v Insert key and Delete key 

v PA1, PA2, and PA3 

v Enter key 

v Newline key 

Note: The Backspace key is treated as a cursor left key. 

If you cannot locate these keys on your workstation, see your workstation X 

Window System documentation to determine the mapping of the X Window 

System key symbol definitions to the physical keys. 

GDDMXD/VM to X Window System Keyboard Functions 

The following are the GDDMXD/VM keyboard functions that translate to X 

Window System key symbol definitions. Key functions not listed are not 

supported. 

GDDMXD/VM 

Keyboard Function 

X Window System Key Symbol 



F1—F12 

Tab 

Up 

Down 

Left 

Right 

End 

Insert 

Delete 

PA1 

PA2 

PA3 

Clear 

Enter 

APL2 char set toggle 

Newline 

XK_F1—XK_F12 

XK_Tab 

XK_Up 

XK_Down 

XK_Left 

XK_Right 

XK_End 

XK_Insert 

XK_Delete 

XK_Prior 

XK_Next 

XK_Home 

XK_Pause 

XK_Execute 

XK_Backspace with state Mod1Mask 

XK_Return 

APL2 Character Set Keyboard 

Setting Up GDXAPLCS MAP 

The APL2 character set is activated by simultaneously pressing the X Window 

System XK_Backspace key (usually the Backspace key) and the State Mod1Mask 

key (usually the Alt key). For example, if you use the IBM 101 Enhanced 

Keyboard, the APL2 character set is toggled on and off by pressing and holding 

Alt, and then pressing Backspace. 

When the APL2 character set is active, the characters APL are displayed in the title 

bar of the GDDMXD/VM window. 

In the X Window System, a keycode is assigned to each key on the keyboard. 

GDDMXD/VM uses keycodes in combination with modifier keys. For example, the 

Shift and Alt keys determine the data that should be passed back from 

GDDMXD/VM to the X Window System application to identify the user’s 

keystroke data. 

A default mapping for the APL2 character set is provided in GDDMXD/VM, 

which corresponds to the IBM 101 Key Enhanced Keyboard. You can override this 

default mapping by creating a file called GDXAPLCS MAP to define the mapping 

for your workstation. When GDDMXD/VM is initialized, the system searches for a 

file called GDXAPLCS MAP. If the GDXAPLCS MAP file exists, the data in the 

GDXAPLCS MAP file replaces the default mapping for all keys. 

For additional information about the mapping values defined in the GDXAPLCS 

MAP file, see Appendix C, “Mapping Values for the APL2 Character Set” on 

page 295. 

The following steps describe how to set up the GDXAPLCS MAP file. 



1. Use the sample program, KEYCODE module, to determine the keycodes for the 

physical keyboard keys. 

When the KEYCODE program is executed from your workstation session to the 

host system, the keycode is displayed for each key depressed at the 

workstation. Therefore, you can establish the association between a physical 

key and the character you want to generate. 

For more information about the mapping values that are defined in the 

GDXAPLCS MAP file, see Appendix C, “Mapping Values for the APL2 

Character Set” on page 295. 

2. Copy GDXAPLCS SAMPMAP to GDXAPLCS MAP. 

3. Edit GDXAPLCS MAP to establish the association between the keycodes in 

KEYCODE and the character set and code values in Appendix C, “Mapping 

Values for the APL2 Character Set”. 

Collecting Problem Determination Information 

If you are reporting a problem to the IBM Service Representative, you should 

provide the following information: 

v Environment description 

v GDDM trace 

v GDDMXD problem determination trace 

v Spooled console output 

Note: The GDDM and GDDMXD problem determination traces must be in 

machine-readable form. To minimize the size of these traces, find the 

shortest sequence of actions that reproduce the problem before obtaining 

traces. Running with these traces activated reduces system performance. 

GDDMXD/VM—X Window System Server Environment 

You should include the following information in the environment description: 

v 

v 

Host system software name and level 

X Window System server workstation hardware and software names and levels 

Obtaining the GDDM Trace 

To generate the GDDM trace on the virtual printer, the following lines should be 

included in the PROFILE ADMDEFS file. 

*ADMMDFT TRCESTR=’FLOW’ 

*ADMMDFT TRCESTR=’PARMSF’ 

*ADMMDFT TRCESTR=’FULLTCA’ 

*ADMMDFT CMSTRCE=(,) 

To activate the trace, you should change the asterisk (*) in column 1 of each line to 

a blank. You should include the FULLTCA line to provide all the information about 

GDDMXD/VM. You should provide the GDDM trace in machine readable format 

to your IBM Service Representative. 

Obtaining the GDDMXD Problem Determination Trace 

To activate the GDDMXD problem determination trace, add the following entry to 

your X DEFAULTS file. 

gddmx*PDTrace: Y 


By default, a file called GDDMX TRACE is written on your A disk. By issuing a 

CMS FILEDEF command for the data definition name (ddname) GDXDPDT, you 

can direct the GDDMX TRACE to another device, including the virtual printer. 

If the problem you are experiencing results in an X Window System error message, 

activate the GDDMXD XSync option by including the following entry in your X 

DEFAULTS file. 

gddmx*XSync: Y 

GDDMXD/VM Problem Determination Examples 


This section describes the process used to determine the cause of the problems that 

can occur when you run a GDDM application with GDDMXD/VM. 

Problem: Messages from the X Window System or 

from GDDMXD/VM indicating the connection could 

not be established. 

Explanation: There are problems establishing the 

connection to the X Window Server. 

User Response: 

v If you received an X Window System message 

indicating that the server was not authorized to 

connect to the host, issue an XHOST command at the 

server specifying the desired host. If the problem 

persists, seek assistance to verify that the host system 

and the work station have been set up correctly. 

v Is the global variable defining the target X Window 

System server set up correctly? Issue the following 

command: GLOBALV SELECT CENV LIST DISPLAY. 

Is the response correct? If there is more than one 

display at the server, is the global variable pointing 

to the correct display? Try using the PING command 

to check the path to the server. Try an X Windows 

System application that does not use GDDMXD/VM, 

for example, XCALC. Try running the GXDEMOn 

sample GDDMXD programs. Correct any difficulties 

before trying other GDDM applications. 

Problem: Any other problem such as program check 

or ABEND. 

Explanation: There are problems establishing the 

connection to the X Window Server. 


information. 

Collect problem determination 

Problem: An X Window System message indicating 

an error or any unexpected ABEND. 

Explanation: The connection is established, but the 

GDDMXD window is not displayed. 


v Try running with a different server. 

v Try running without a window manager at the 

server. 

v If the X Window System error message is: XIO: fatal 

IO error nn (broken pipe) and the message persists, 

the problem is most likely in the X Window System 

and not in GDDMXD/VM. If the error persists, 

collect problem determination information. 

Problem: GDDMXD window is created, but picture 

drawn is incorrect or user interaction with application 

produces unexpected results. 


v Is the server at the correct level? 

v Is the ZWL option being used? If so, try turning it 

off. 

v Is a supported version of GDDM being used? 

v Is the application using GDDM functions that are not 

supported? 

v If the error persists, collect problem determination 

information. 

Demonstration Programs 

The demonstration programs display examples of the GDDM functions. Each 

program displays a series of frames. To move to the next frame, press Enter. 

GXDEMO1 

The following describes the GXDEMO1 frames. 

Frame Description 

1 GDDM line types and widths 



2 GDDM System Markers 

3 Simple picture 

4 Circular Arcs 

5 Elliptic Arcs 

6 2-Part Polyfillet 

7 5-Part Polyfillet 

GXDEMO2 



1 Solid area fill 

2 Overlapped polygon fill 

3 2-Part graphic area fill 

4 GDDM System Shading Patterns 

5 Output from GSIMG statement 

6 Output from GSIMGS statement 

GXDEMO3 



1 Three GDDM Text Modes 

2 Proportional Spacing 

3 GDDM Character Angle 

4 GDDM Character Direction 

5 GDDM Character Shear 

GXDEMO4 

The GXDEMO4 frames display the 22 standard GDDM fonts. 

GXDEMO4A 

The GXDEMO4A frames display a subset of the standard GDDM fonts. 

GXDEMO5 



1 The Four Segment Transformations 

2 Example transformation (Part 1) 

3 Example transformation (Part 2) 

4 Examples of Called Segments 

GXDEMO6 



1 PGF Line Chart 

2 PGF Surface Chart 

3 PGF Histogram 

4 PGF Bar Chart 

5 PGF Tower Chart 

6 PGF Polar Chart 

7 PGF Composite Bar Versus Multiple Pie Charts 

8 PGF Pie Charts 



9 PGF Venn Diagram 




Chapter 12. Managing TCP/IP Network Resources with SNMP 

Sample Command Lists 

Simple Network Management Protocol (SNMP) is used to monitor your TCP/IP 

network resources. 

SNMP defines an architecture that consists of network management stations 

(SNMP clients), network elements (hosts and gateways), and network management 

agents and subagents, which perform the information management functions. 

SNMP allows clients and agents to communicate network management information 

through network elements, which act as servers. 

An SNMP client is a network workstation that executes management applications 

that are used to monitor and control network elements. When you use SNMP with 

TCP/IP, you require NetView ® to provide end-user interface to the SNMP client. A 

NetView operator can use the SNMP command to communicate with SNMP 

agents. NetView acts as an SNMP client. 

Notes: 

1. VM SNMP supports IBM 3172 Management Information Base (MIB) variables 

and MIB-II variables. For more information about MIB-II variables, see RFC 

1158 and Appendix E, “Management Information Base Objects” on page 307. 

2. The VM SNMP agent does not support the SET operation. If you use the SET 

command with the variables listed in Appendix E, “Management Information 

Base Objects” for a VM Agent, you receive a read-only error. 

Two sets of sample NetView command lists with a filetype of NCCFLST are 

supplied on the Samples tape. One set is written in CLIST (SNMPRUN), and the 

other set is written in REXX (SNMPMGMT). 

You should use CLISTs if your host system does not support REXX. The REXX 

programs supply the same functionality as the CLISTs. These command lists enable 

you, through revision and modification, to develop a set of NetView/SNMP 

client/user interface pannels that are customized to your needs. 

You can issue SNMP requests with the two sets of sample command lists that are 

shipped with the TCP/IP product, with command lists that you write, or directly 

from the command line. The SNMPRUN and the SNMPMGMT commands invoke 

the main panel from which a NetView operator can execute most of the SNMP 

requests in full-screen mode. The SNMPRUN command uses a set of command 

lists written in NetView Command List language; the SNMPMGMT command uses 

a set of REXX command lists. 

For more information about these sample command lists, see the SNMPCLST 

README and SNMPREXX README files on the client common disk (TCPMAINT 

592). 


Using SNMP 

SNMP/NetView Overview 

Figure 12 illustrates how the interface between the NetView and TCP/IP virtual 

machines is set up. An additional virtual machine running a special server called 

the Query Engine(SNMPQE) actually implements the communication function. 

Userid = NETVIEW 

Userid = SNMPQE 

Userid = TCPIP 

SNMP CMD PROC 

SQESRV 

SNMPIUCV-TASK 

SOCKET I-FACE 

GCS 

CMS 

CMS 

VM 

IUCV 

VMCF 

Internet to 

SNMP agents 

Figure 12. Overview of NetView SNMP Support 

The Query Engine communicates with an optional subtask, called SNMPIUCV, 

running under NetView. It also communicates with TCP/IP. This is done through 

socket interfaces that are based on the IUCV cross-memory facility. 

The SNMP Query Engine uses three types of sockets: 

v Datagram sockets through which the SNMP requests and responses flow and 

traps are received, because the management protocol is based on UDP 

v A raw socket into ICMP for the implementation of the PING facility, which is an 

ICMP echo application 

v A stream socket for communication with NetView 

To use the interface, a NetView operator or command list issues the SNMP 

command with the appropriate parameters. This invokes the SNMP command 

processor, which validates the syntax of the input and, if no errors are found, it 

queues the request to the SNMPIUCV task. Then, the task passes the request to the 

SNMP Query Engine, which validates the request, encodes it in ASN.1 format, and 

builds the protocol data unit (PDU) that is sent to the SNMP agent. 

When the Query Engine receives a response from the agent, it decodes the PDU 

and passes it to the SNMPIUCV NetView task. The task converts the response into 

a multiline message. The messages are prefixed with SNM, so that they can be 

assigned to specific NetView operators or autotasks. 


SNMP Commands 

To issue an SNMP request, use the SNMP command. The following is a list of the 

SNMP commands you can use on NetView. 

Note: The SNMP commands can be abbreviated; the shortest acceptable form 

appears in uppercase. 

The SNMP Query Engine issues SNMP requests to the agents and processes SNMP 

responses returned by the agents. The agents can also forward unsolicited 

messages, known as traps, to NetView and other clients. 

NetView can use the following SNMP commands. 

v SNMP Get 

v SNMP GETNext 

v SNMP Set 

v SNMP TRAPson 

v SNMP TRAPSOFf 

v SNMP MIBvname 

v SNMP PING 

The following sections describe these commands. 

SNMP Commands Overview 

The following provides information about SNMP commands. 

v 

v 

v 

v 

v 

v 

v 

v 

When the SNMP command is issued from the NetView Command Facility 

command line, all input is translated to uppercase (standard NetView) before it 

is sent to the SNMP Query Engine. 

When the SNMP command is issued from a CLIST, input is passed in whatever 

case it was passed from the CLIST (for example, mixed case). 

The short names for the variables passed to the query engine are compared 

against the entries in the MIB_DESC DATA file in a case insensitive way. For 

more information about this file, see TCP/IP Planning and Customization. 

The community name is passed to the SNMP agent in the same case as it was 

received by the query engine. 

If multiple variables are specified with the GET, GETNEXT, or SET commands, 

they are all packaged in one SNMP PDU to be sent to the agent. 

For PING, you can specify only one host_name. 

The responses may not be received in the same order they are issued. 

The SNMP agent can receive SNMP requests over any interface. 

Return Codes 

The following is a list of the return codes generated by SNMP. 

Code Description 

1 Error from DSIGET, cannot continue 

2 Invalid function specified 

3 Missing SNMP function 

4 Not enough parameters 

5 Missing variable name 

Using SNMP 

Chapter 12. Managing TCP/IP Network Resources with SNMP 215

Using SNMP 

SNMP GET Command 

6 Missing variable value 

7 Missing or invalid host name 

8 Missing community name 

9 SNMPIUCV not active 

10 Error from DSIMQS 

11 Invalid net_mask/desired network 

12 Missing/Invalid trap filter_id 

1001+ All return codes above 1001 indicate that the command was successful 

The return code represents the sequence number (or filter_id) passed to SNMP 

Query engine. The asynchronous response is identified by this sequence number. 

For a TRAPSON request, this is the filter_id to be used for a subsequent 

TRAPSOFF request. 

Use the SNMP GET command to obtain one or more variables from an SNMP 

agent. 

►► 

▼ 

SNMP Get host com_name var_name ►◄ 

Operands 

host 

Specifies the name of the destination host where the SNMP request is sent. The 

host can be specified with its name or with its IP address in dotted-decimal 

notation. 

Note: The SNMP Query Engine treats numbers with leading zeros as octal 

numbers. Therefore, do not use leading zeros. 

com_name 

Specifies the community name to use when querying the SNMP agent on the 


Note: This parameter is case sensitive. 

var_name 

Specifies one or more MIB variable names to be obtained. You can specify the 

names in short form or in ASN.1 notation (for example, sysDescr.0 or 

1.3.6.1.2.1.1.1.0). Currently, a maximum of 10 variables for each request is 

implemented in the SNMP Query Engine. 

Note: This parameter is not case sensitive. 

You must specify the host name or IP address of the host where the agent is 

running, as well as the community name to be used when making the query. 


Examples 

You must specify the variable name of each variable to be obtained. All standard 

MIB, MIB-II variable names (defined in RFC 1156 and RFC 1158), and the IBM 3172 

MIB variables are supported by the VM SNMP client. In addition, you can specify 

enterprise-specific variables that are defined by the implementer of a particular 

SNMP agent. See TCP/IP Planning and Customization for information about how to 

add the enterprise-specific variables to the MIB_DESC DATA file. 

v 

If you know: 

hostname - anyhost 

IP address - 129.34.222.72 

community name - public 

variable name - sysDescr.0 

asn.1 variable name - 1.3.6.1.2.1.1.1.0 

variable name - sysObjectID.0 


variable name - sysUpTime.0 


You can issue the following SNMP GET commands: 

snmp get 129.34.222.72 public 1.3.6.1.2.1.1.1.0 

snmp get 129.34.222.72 public sysDescr.0 

snmp get anyhost public 1.3.6.1.2.1.1.1.0 

snmp get anyhost public sysDescr.0 

snmp get anyhost public sysObjectID.0 

snmp get anyhost public sysUpTime.0 

snmp get anyhost public sysDescr.0 sysObjectID.0 sysUpTime.0 

After the SNMP command is completed, you get a message similiar to the 

following: 

SNM050I SNMP Request 1001 from NETOP accepted, sent to Query Engine 

When the response arrives in NetView (asynchronously), NetView displays it as 

a multiline message in the following form. 

SNM040I SNMP Request 1001 from NETOP Returned the following response: 

SNM042I Variable name: 1.3.6.1.2.1.1.1.0 

SNM043I Variable value type: 9 

SNM044I Variable value: AIX 2.2.1 SNMP Agent Version 1.0 



SNM044I Variable value: 1.3.6.1.4.1.2.1.1 



SNM044I Variable value: 98800 

SNM049I SNMP Request 1001 end of response 

Using SNMP 

Usage Notes 

v 

v 

For a list of variables supported by the VM Agent, see Appendix E, 

“Management Information Base Objects”. 

All lines do not need to be present, but the first line is always message 

SNM040I, and the last line is always message SNM049I. 

If an error was detected, messages SNM042–SNM044 may not be present. You 

can get (in addition to other messages) error messages in the following form (all 

as part of multiline message SNM040I). 


Using SNMP 

SNM045I Major error code: n 

SNM046I Minor error code: y 

SNM047I Error index: z 

SNM048I Error text: message text 

SNMP GETNEXT Command 

v 

v 

v 

v 

v 

See “Major and Minor Error Codes and SNMP Value Types” on page 227 for 

information about value types and minor and major error codes. 

If you issue a GET for multiple variables, messages SNM042 through SNM044 

are displayed for each variable. 

If a variable value is too long, message SNM044 may not fit on an 80-character 

line. If this happens, the value is split and multiple SNM044 messages are 

displayed. 

The SNMP response always displays the variable name in ASN.1 notation. You 

can use SNMP MIBVNAME to obtain the short name for the variable. For more 

information, see “SNMP MIBVNAME Command” on page 225. 

According to RFC 1157, a message exchanged between SNMP entities (including 

version identification and community name) can be as small as 484 octets. If you 

specify up to 10 variables in a GET/GETNEXT command, the names may be 

short enough to send the GET command to the SNMP agent, but the response 

may be too long to fit in the message. As a result, you receive a tooBig error. 

When you issue a GET for multiple variables, they are returned in the same 

sequence as requested. In the example on page 217, GET was issued for 

sysDescr.0 sysObjectID.0 sysUpTime.0.. The same three variables are returned 

in the response. If one (or more) of the variables requested results in an error, all 

variables listed after the first variable in error are ignored, and data is not 

returned for them. 

v For more information about value types, minor, and major error codes, see 

“Major and Minor Error Codes and SNMP Value Types” on page 227. 

v For a description of all variables and the meaning of their values, see RFC 1156 

and RFC 1158.. 

Use the SNMP GETNEXT command in the following format to obtain the next 

variable in the MIB tree from an SNMP agent. 

►► 

▼ 

SNMP GETNext host com_name var_name ►◄ 

Operands 

host 



notation. 




Examples 

com_name 




var_name 

Specifies one or more MIB variable names to be obtained. The names can be 

specified in short form or in ASN.1 notation (for example, sysDescr.0 or 

1.3.6.1.2.1.1.1.0). Currently, a maximum of 10 variables for each request is 


v 


If you know: 



community name - public 

variable name - ifAdminStatus (in ifTable) 

asn.1 variable name - 1.3.6.1.2.1.2.2.1.7 

Using SNMP 

v 

You can issue an SNMP GETNEXT command in one of the following ways: 

snmp getnext 129.34.222.72 public 1.3.6.1.2.1.2.2.1.7.0 

snmp getnext 129.34.222.72 public ifAdminStatus.0 

snmp getnext anyhost public 1.3.6.1.2.1.2.2.1.7.0 

snmp getnext anyhost public ifAdminStatus.0 

The GETNEXT command is completed in the same manner as the GET 

command, and you receive an asynchronous response similiar to the following 

example. 

The first instance of the variable has a status of 1 or greater (ends in 7.1) in this 

example: 


SNM042I Variable name: 1.3.6.1.2.1.2.2.1.7.1 




v 

You can then issue another GETNEXT command in one of the following ways: 






command, and you receive an asynchronous response similiar to the following 

example. 

The second instance of the variable has a status of 1 or greater (ends in 7.2) in 

this example: 






You can then issue another GETNEXT command in one of the following ways: 


Using SNMP 

v 






command, and you receive an asynchronous response similiar to the following: 






Usage Notes 

SNMP SET Command 

v 

v 

The returned variable is the first entry in the next instance, which has a value of 

1 or greater (ends in 8.1 rather than 7.x). The returned variable indicates that 

the end of the table for the ifAdminStatus variable has been reached. 


running, as well as the community name to be used when making the query. 

You must specify the name of the variable preceding the desired variable. In 

addition to the standard MIBs, there may be enterprise-specific variables as 

defined by the implementer of a particular SNMP agent. 

The GETNEXT command is used to interrogate a table (for example, the 

interface table) or an array. You can issue a GETNEXT command at the start of a 

table (use instance 0.0). The first element in the table is returned. The process 

continues in a loop, performing GETNEXT requests on the previously obtained 

variable name, until the name of the variable returned no longer has the same 

prefix as the one at the start of the table. This condition occurs when the 

GETNEXT request returns a variable that is in the next group. 

Use the SNMP SET command to set or change the value of one or more variables 

in an SNMP agent. 

►► 

▼ 

SNMP Set host com_name var_namevar_value ►◄ 

Operands 

host 



notation. 



com_name 




Using SNMP 

Examples 


var_name 

Specifies one or more MIB variable names to be obtained. The names can be 

specified in short form or in ASN.1 notation (for example, sysDescr.0 or 

1.3.6.1.2.1.1.1.0). Currently, a maximum of 10 variable pairs for each request is 



var_value 

Specifies the value(s) to be stored in the variable(s). 

v 

If you know: 



community name - publicw 

variable name - ifAdminStatus 

asn.1 variable name - 1.3.6.1.2.1.2.2.1.7.1 

(instance 1) 

You can then issue an SNMP SET command in one of the following forms to set 

the administrative status of the first interface in the ifTable (first instance) to test. 

snmp set 129.34.222.72 publicw 1.3.6.1.2.1.2.2.1.7.1 3 

snmp set 129.34.222.72 publicw IfAdminStatus.1 3 

snmp set anyhost publicw 1.3.6.1.2.1.2.2.1.7.1 3 

snmp set anyhost publicw ifAdminStatus.1 3 

After the command has completed, you receive a message similiar to the 

following: 









Usage Notes 

v 


running, as well as the community name to be used. The community name used 

for a SET request is frequently different than the community name for a GET 

request. You must specify the names and values of each variable to be set. RFC 

1156 and RFC 1158 define the variables that you can set with read-write access. 

In addition, there may be enterprise-specific variables as defined by the 

implementer of a particular SNMP agent. 


Using SNMP 

SNMP TRAPSON Command 

The SNMP Query Engine can forward only those traps that it receives. Each agent 

has a trap destination table, which lists all the hosts that should receive that 

agent’s traps. The host name of your system should be in the trap destination table 

of all agents from which you want to receive traps. 

Use the SNMP TRAPSON command to request that the SNMP Query Engine 

forward SNMP traps to NetView.e 

►► SNMP TRAPson net_mask net_desired ►◄ 

Operands 

Examples 

net_mask 

Specifies, in dotted-decimal notation, the network mask to be evaluated with 

the IP address of incoming traps. The dotted decimal IP address is ANDed 

with this mask. 

net_desired 

Specifies the network from which you want to receive traps. When you request 

traps using the SNMP TRAPSON command, it returns a request number of 

filter_id, which the SNMP Query Engine associates with the TRAPSON request. 

To stop receiving traps, specify this filter_id in the TRAPSOFF request. 

This command permits the specification of a filtering condition, which enables the 

Query Engine to perform filtering. 

The SNMP TRAPSON command assigns a unique request number to each filter 

(also called a filter_id) and returns this number in a message and in the return 

code. This filter_id is the argument to an SNMP TRAPSOFF command, which is 

used to stop receiving traps that pass this filter. 

v 

If you know: 


net mask - 255.255.255.255 

You can issue the following SNMP TRAPSON commands: 

snmp trapson 

snmp trapson 255.255.255.255 129.34.222.72 

The first command receives all traps (the default is a mask of 0 and a desired 

network of 0). The second command only receives traps from a specific host 

named anyhost. 

After the command is completed, you receive a message similiar to the 

following: 



a multiline message in the following form to indicate that the TRAPSON request 

was accepted. 


Using SNMP 


SNM045I Major error code: 0 

SNM046I Minor error code: 0 

SNM047I Error index: 0 

SNM048I Error text: no error 


When traps arrive, NetView displays each trap with a multiline message in the 

following form. This multiline message is sent to the authorized receiver (AUTH 

MSGRECVR=YES); it may not show up on the console of the operator who 

issues the TRAPSON command. 

SNM030I SNMP request 1001 received following trap: 

SNM031I Agent Address: 129.34.222.34 

SNM032I Generic trap type: 4 

SNM033I Specific trap type: 0 

SNM034I Time stamp: 472600 

SNM035I Enterprise Object ID: 1.3.6.1.4.1.2.1.1 

SNM039I SNMP request 1001 End of trap data 

Usage Notes 

v 

v 

v 

v 

v 

v 

v 

v 

v 

v 

In the response to the SNMP TRAPSON request, not all lines need to be present; 

but the first line is always message SNM040I, and the last line is always 

message SNM049I. 

For the multiline trap message, not all lines need to be present; but the first line 

is always message SNM030I, and the last line is always message SNM039I. 

Additional messages (SNM036I-SNM038I) may be present if the trap has 

additional data. 

If a variable value is too long, message SNM038 may not fit on an 80-character 

line. If this happens, the value is split and multiple SNM038 messages are 

displayed. 

The SNMP trap data always displays the variable name in ASN.1 notation. You 

can use SNMP MIBVNAME to obtain the short name for the variable. 

A trap always shows the agent address in the form of an IP address in 

dotted-decimal notation. 


information about value types, minor, and major error codes. 

See Appendix G, “SNMP Generic TRAP Types” on page 337 for a description of 

the traps and the meanings of the generic trap types. 

You can issue multiple TRAPSON requests, either with the same or with a 

different filter. If a trap passes multiple filters, the trap is sent to NetView 

multiple times. However, in NetView, the header and trailer lines (messages 

SNM030I and SNM039I) of the duplicate trap are different, because they contain 

the filter_id (request number) by which the trap was forwarded. Different types 

of traps from different hosts can have the same filter_id, if these traps pass the 

same trap filter. If an SNMP request is issued with the wrong community name, 

it receives three AUTHENTICATION FAILURE traps with the same filter_id but 

different time stamps from the same host. This is because the SNMP Query 

Engine tries to send the same request three times if a response is not received 

from the host, and each attempt causes the host to generate an 

AUTHENTICATION FAILURE trap. 

Once the TRAPSON command has been issued, traps can start to arrive 

asynchronously. They can even arrive after the operator who issued the 

TRAPSON command logs off. Often, a TRAPSON command is issued by a 


Using SNMP 

SNMP TRAPSOFF Command 

CLIST, and the received trap data triggers another CLIST to handle the trap 

data. Therefore, the messages in the range SNM030 through SNM039 are sent to 

the authorized receiver. For a NetView operator to see the traps, the operator must 

have the following statement in the profile. 

AUTH MSGRECVR=YES 

However, only one operator receives the message. The messages also go to the 

log file, so you can always browse the log file to see trap data. And as a last 

resort, you can assign trap messages to go to a specific operator using the 

NetView ASSIGN operator command. 

When you have asked the SNMP Query Engine to forward traps to NetView, it 

keeps doing so until the IUCV connection breaks or until you issue an SNMP 

TRAPSOFF command. 

►► SNMP TRAPSOFf filter_id ►◄ 

Operands 

Examples 

filter_id 

Specifies the trap filter ID. 

When you request traps using the SNMP TRAPSON command, it returns a 

request number or filter_id, which the SNMP Query Engine associates with the 

TRAPSON request. To stop receiving traps, specify this filter_id in the 

TRAPSOFF request. 

The SNMP TRAPSON command assigns a unique request number to each filter 

(also called a filter_id) and returns it in a message as the return code. This filter_id 

can later be used as the argument to an SNMP TRAPSOFF command if you want 

to stop receiving traps that pass this filter. Only one filter_id for each SNMP 

TRAPSOFF command can be passed. Extraneous arguments are ignored. 

v 

If you know the filter_id is 1001, you can issue the following SNMP TRAPSOFF 

command to tell the SNMP Query Engine to quit sending traps that would pass 

filter 1001. 

snmp trapsoff 1001 

The command completes with a message similiar to the following: 



a multiline message in the following form to indicate that the TRAPSOFF 

request was accepted. 


SNM045I Major error code: 0 

SNM046I Minor error code: 0 

SNM047I Error index: 0 

SNM048I Error text: no error 



SNMP MIBVNAME Command 

When you get an ASN.1 variable name as part of a trap, use the SNMP 

MIBVNAME command to find the short name of the variable. 

Using SNMP 

►► SNMP MIBvname asn.1_name ►◄ 

Operands 

Examples 

asn.1_name 

Specifies the ASN.1 notation of one MIB variable. You can specify only one 

variable, so additional arguments are ignored. 

v 

If you have a trap that tells you: 

SNM030I SNMP request 1001 received following trap: 

SNM031I Agent Address: 129.34.222.34 

SNM032I Generic trap type: 2 

SNM033I Specific trap type: 0 

SNM034I Time stamp: 472600 

SNM035I Enterprise Object ID: 1.3.6.1.4.1.2.1.1 

SNM036I Variable name: 1.3.6.1.2.1.2.2.1.1 



SNM039I SNMP request 1001 End of trap data 

You can issue the following SNMP MIBVNAME command to find the short MIB 

variable name. 

snmp mibvname 1.3.6.1.2.1.2.2.1.1 

The command completes with a message similar to the following: 





SNM042I Variable name: 1.3.6.1.2.1.2.2.1.1 


SNM044I Variable value: ifIndex 


Usage Notes 

v 

v 

All lines do not need to be present, but the first line is always message 

SNM040I, and the last line is always message SNM049I. If an error occurs, an 

error message explains what is wrong. 

If an error is detected, messages SNM042 through SNM044 may not be 

displayed. You receive error messages (in addition to other messages) in the 

following form (all as part of multiline message SNM040I). 


Using SNMP 





v 


information about value types and minor and major error codes. 

One ASN.1 variable name only can be passed for each SNMP MIBVNAME 

command. Additional parameters are ignored. 

SNMP PING Command 

Use the SNMP PING command to obtain the minimum round trip response time 

from the Query Engine to a specific node. 

►► SNMP PING host ►◄ 

Operands 

Examples 

host 



notation. 



The Query Engine issues one PING (an ICMP echo on a raw socket) and returns 

the value in milliseconds in an IBM-defined SNMP variable minRTT. For more 

information about the SNMP PING command, see TCP/IP Planning and 

Customization. Because only one PING is issued, this is also the average and the 

maximum response time. If the PING does not respond, the Query Engine retries 

twice, once after 1 second and again after 2 seconds (Query Engine default retry 

mechanism). If a response is not received after all retries have been exhausted, a 

variable value of -1 is returned to indicate that a reply was not received. 

v 

If you know: 

nodename - anynode 


You can issue the following SNMP PING commands: 

SNMP PING ANYNODE 

SNMP PING 129.34.222.72 

The command completes with a message similiar to the following: 



a multiline message in the following form: 


Using SNMP 


SNM042I Variable name: 1.3.6.1.4.1.2.2.1.3.2.129.34.222.72 




Usage Notes 

v 

v 

All lines need to be present, but the first line is always message SNM040I, and 

the last line is always message SNM049I. 

If an error is detected, messages SNM042 through SNM044 may not be 

displayed. You get error messages (in addition to other messages) in the 

following form (all as part of multiline message SNM040I). 





v 

v 

v 

See “Major and Minor Error Codes and SNMP Value Types” for information 

about value types and minor and major error codes. 

The 129.34.222.72 in the example represents an instance of the IBM variable 

minRTT. 

One node name only can be passed for each SNMP PING command. 

The SNMP response always displays the variable name in ASN.1 notation. You 

can use SNMP MIBVNAME to obtain the short name for the variable. 

Major and Minor Error Codes and SNMP Value Types 

The following are the possible major and minor error codes and variable value 

types that can be returned in an SNMP response or trap. 

v The major error code can have one of the following values. 

Value Major Error Code 

0 No error detected 

1 SNMP agent reported error 

2 Internally detected error 

v The minor error code can have one of the following values when the major error 

code indicates that an SNMP agent detected an error. 

Value SNMP Agent Detected Minor Error Code 

0 No error 

1 Too big 

2 No such name 

3 Bad value 

4 Read only 

5 General error 

v The minor error code can have one of the following values when the major error 

code indicates that an internal error was detected. 

Value Internal Minor Error Code 

0 No error 

1 Protocol error 

2 Out of memory 

3 No response—all retries failed 

4 Some I/O error occurred 


Using SNMP 

v 

v 

5 Illegal request 

6 Unknown host specified 

7 Unknown MIB variable 

8 No such filter 

9 Too many variables specified 

If the major error code indicates that an SNMP agent detected the error, the 

error index indicates the position of the first variable in error. 

The variable value type is one of the following (as specified in RFC 1155 and 

RFC 1156). 

Value Value Type 

0 Text representation 

1 Number (integer, signed) 

2 Binary data string 

3 Object identifier 

4 Empty (no value) 

5 Internet address 

6 Counter (unsigned) 

7 Gauge (unsigned) 

8 Time ticks (1/100ths seconds) 

9 Display string 

Note: The binary data string is displayed in NetView as a contiguous string of 

hexadecimal characters (for example, X'0123' is displayed as 0123). 

gethostbyname() 

When a host name is specified with an SNMP request, the SNMP Query Engine 

looks up the IP address of that host. It uses the standard gethostbyname() function 

to perform that function. The IP address is then saved in an in-memory cache for 

future references. For more information about gethostbyname(), see TCP/IP 

Programmer’s Reference. 

The cache cannot be refreshed, and if for some reason the mapping between host 

names and IP addresses changes, the SNMP Query Engine (the SQESERV module) 

has to be restarted to rebuild its cache. This is also true for a host name that was 

found to be nonexistent at the time of the first SNMP request, but which has been 

added to the name server database. 

This gives a performance boost to subsequent requests for the same host. 

IBM 3172 Enterprise-Specific MIB Variables 

The IBM 3172 Interconnect Controller maintains a set of enterprise-specific MIB 

variables. The SNMP agent can act as a proxy agent to retrieve these variables 

from the 3172. Either a GET or GETNEXT command can be issued to retrieve the 

3172 variables. The 3172 variable names can be included in a GET/GETNEXT 

command that also contains standard MIB variable names. See Appendix E, 

“Management Information Base Objects” on page 307 for a description of the 3172 

enterprise specific MIB variables. 

The 3172 variables are referenced by a single element instance identifier: (.1, .2, .3). 

For variables that pertain to the entire 3172, the instance identifier number is 

assigned in the order that the devices are defined in the PROFILE TCPIP file or the 

equivalent file in your system. For example, the first LCS device with NETMAN 

specified would have an instance identifier of .1, the next would be .2, and so on. 


Using SNMP 

No instance identifiers are assigned for non-LCS devices or LCS devices without 

the NETMAN keyword. For variables that are interface-specific, the instance 

identifier for a link is the link’s ifIndex. If a GET command is issued for an 

interface variable using an instance identifier of a link that does not support the 

3172 variables, a response of NO SUCH NAME is returned from the SNMP agent. 

If a GETNEXT command is issued, the links that do not support the 3172 variables 

are skipped over and the NEXT link that does support 3172 variables is returned. 

If an error occurs accessing a 3172 variable from the 3172 (either a bad return code 

is received from the 3172 or no response is received from the 3172), an error code 

of GEN ERROR is returned to the client in the SNMP response PDU for that 

variable. An error message containing more specific information about the error 

that occurred is written to the TCPIP virtual machine (either to the console or to 

the trace file, depending on the specifications of the PROFILE TCPIP file). Several 

of the potential error conditions reference the 3172 MIB variable by the 3172 

attribute index. See Appendix F, “IBM 3172 Attribute Index” on page 335 for a list 

of the 3172 attribute indices and the corresponding MIB variable names. 



Chapter 13. Using the Network Database System (NDB) 

This chapter describes the Network Database System (NDB), which is used for 

relational database systems in a TCP/IP environment. NDB uses the Remote 

Procedure Call (RPC) protocol to allow inter-operability among different database 

systems. This chapter also describes how NDB is used with Data Conversion, 

Security, I/O Buffer Management, and Transaction Management. 

The Network Database System provides : 

v Interoperabilty through access to a mainframe relational database from AIX on 

RISC System/6000 or Sun Microsystem workstation. 

v Ability to issue SQL statements interactively, or to imbed SQL statements within 

an application program. 

v Client/server capabilities by providing a way for a variety of workstations users 

to take advantage of relational technology. 

The components of the Network Database System are illustrated in Figure 13. 

1 

NDBPMGR 

4 

Port 

Manager 

3 

2 

withaport 

Server 

number 

Clients 

5 

withaport 

number 

Servers 

Client1 

NDBSRV01 

2 

3 withaport 

Client2 

6 

connected 

number 

NDBSRV02 

Clientn 

NDBSRVn 

Figure 13. Components of the Network Database System 

The following is a list of steps explaining the process of connecting the client to the 

NDB server: 

1. Bring up the Port Manager NDBPMGR. 

2. NDBSRVn issues a request to NDBPMGR for a port number. 

3. NDBPMGR updates its port status and returns a port number. 

4. A client issues a request to NDBPMGR for the port number of an available 

server. 

5. NDBPMGR returns an available port number. 


Using NDB 

The Client Machine 

6. When the client issues a request from now on, it is connected to that NDB 

server, NDBSRVnn. 

The client machine provides mainframe or workstation applications on the 

Network Database system, using: 

Interactive SQL Commands 

Imbedded SQL statements 

You can type in SQL commands directly from the 

client machine to query or access data from a 

database. 

You can write application programs in C and 

imbed SQL statements in the program. SQL 

statements are processed the same way interactive 

SQL commands are processed. 

Components of the Client Machine 

The components of a client machine include end-user applications, an NDB client, 

and an RPC client. 

Applications 

NDB client 

RPC client 

End-user applications run on a workstation, and can imbed SQL 

queries. The workstation runs the requests as its own tasks. 

The NDB client receives requests from the end-user application, 

and determines which calls to issue to the server. The NDB client 

packages requests into a standard format called NDBC main control 

block, sets up an I/O buffer, and issues RPC calls to deliver the 

requests to the network. 

The RPC client delivers calls from the client machine to the server 

machine. 

The NDB Client 

The NDB client gets control from the application, parses the input arguments, and 

sets up the main control block and I/O buffers. The NDB client packages a call for 

the RPC client, passes control to the RPC Client, and waits for the results. 

The NDBCLNT command directs the client module to deliver a request to the 

remote database system. The NDBCLNT command is sent to the server as a Unit 

Of Work (UOW). UOW is a mark for the server to recognize the threads that come 

from clients. A client starts a UOW by issuing a "begin" statement. The client 

module then requests the user to enter a valid user ID and password for a virtual 

machine on the remote database system. This user ID and password pair is used 

for authorization purposes. Both the user ID and password must be typed in; 

however, the password is not shown on the screen. After establishing a UOW by 

means of a "begin" statement and the authorization checking, the client can enter 

as many SQL statements as necessary. The client issues an end statement to end the 

UOW. Only the first request in a UOW requires the user to supply the user ID and 

password for a virtual machine on the remote database system. The information is 

stored after the first request and destroyed when the last request is issued. If a 

client sends only one SQL request, a UOW does not have to be started. The client 

simply sends one request, and the server treats the request as an entire UOW. The 

user ID and password of a virtual machine on the remote database system are still 

required in this scenario. 


The Server Machine 

The RPC Client 

The NDB Client uses the RPC protocol to package the request and issue a remote 

procedure call which sends the request to the server. The RPC client is the module 

that manages RPC calls and delivers calls through TCP/IP to the destination server 

machine. Because RPC is designed for the support of network applications, and 

runs with a client/server network, the RPC client allows you to avoid interfacing 

with the network, and provides network services without requiring any underlying 

network. The RPC call is transparent and independent of transport protocols. 

NDB is running on top of TCP. When RPC runs on top of TCP/IP, most of the 

work of reliable transport is done, but the application still needs time-outs and 

reconnection to handle server crashes. When RPC runs on top of UDP, the 

application must implement its own retransmission and time-out policy. 

The caller process sends a call message to the server process and waits for a reply 

message. The procedure’s parameters are contained in the caller message. The 

procedure results are contained in the reply message. When the reply message is 

received, the results of the procedure are extracted, and the caller’s execution is 

resumed. 

RPC uses eXternal Data Representation (XDR), a data representation for 

machine-independent description and encoding of data. 

Each RPC procedure is uniquely defined by a program number and procedure 

number. Several processes can be active at any time; however, each process can 

execute only one request at a time. The requests are executed in the order they 

arrive. 

The RPC client sends an RPC call message to a server’s PORTMAP to find a 

remote program’s port, The server returns the relevant port number in an RPC 

reply message, which allows the RPC client to send the RPC message to the remote 

program’s port. 

RPC/XDR performs data conversion between different types of machines. 

RPC/XDR requires data type information when a call is made; however, the 

requester usually does not have knowledge of the data type. Therefore, RPC/XDR 

cannot perform data conversion between different machines. To resolve the 

problem, NDB makes the reply buffer a type of string. When data is received 

from the database, the NDB Server does the data conversion, and packages the 

result into the reply buffer. 

The database system must reside on the same host as the NDB server machines. 

The server machine has two parts: the Portmap Manager server and the NDB 

server. The NDB server resolves issues of security, data conversion, data buffer 

management, and transaction management. The Portmap Manager server provides 

services for clients’ requests. 

Components of the Portmap Manager Server 

The components of the Portmap Manager server machine include: 

RPC Server 

Using NDB 

The RPC server interprets an RPC call sent to the 

server machine from a client machine, verifies the 

RPC call, and distributes it to the Portmap 

Manager server. 

Chapter 13. Using the Network Database System (NDB) 233

Using NDB 

Portmap Manager Server 

The Portmap Manager server processes a request 

from either a NDB server or a NDB client. It 

creates or updates a status table of all program 

numbers used by the NDB servers. It returns an 

available program number to the requester. One 

host only needs one portmap manager server. 

The RPC Server 

A process is dormant awaiting the arrival of a call message. When a call message 

arrives, the server process extracts the procedure’s parameters, computes the 

results, sends a reply message, and awaits the next call message. Each RPC must 

communicate with a dedicated port. As part of its initialization, a server program 

calls its host’s PORTMAP to create a portmap entry for its program and version 

number. 

The server is required to handle many client connections. The TCP server keeps 

the status of the open connection for each client. The number of clients is limited 

by the machine resources. The UDP server does not keep any status regarding the 

client but can handle unlimited numbers of clients. 

The Portmap Manager Server 

The Portmap manager server provides services for clients’ requests. It has two 

types of clients: the NDB server and the NDB clients. The main routine, 

PORTMGR, maintains a table which contains the status of all the program 

numbers that NDB uses. The status is updated when activity occurs. It is necessary 

for the NDB server and the client to use the same program number so that the 

thread can be connected directly. 

Components of the NDB Server 

The components of the NDB server include: 

RPC Server 

Portmap Manager Client 

NDB Server 

DataBase Utility 

The RPC server interprets an RPC call sent to the 

server machine from a client machine, verifies the 

RPC call, and distributes it to the NDB server. 

The Portmap Manager Client issues a request to 

the Portmap Manager server to get an available 

program number, then passes the program number 

to the NDB server when it invokes the NDB server. 

The NDB server is invoked by Portmap Manager 

Client. The NDB server preprocesses a request, sets 

up buffers for the result from the database, and 

issues a real SQL call to the database. 

The Database Utility (DBU) performs SQL 

preprocess procedures. Each SQL statement goes 

through the SQL preprocess. The database 

processes the real request delivered from the NDB 

server, and returns the result to the NDB server. 

The Portmap Manager Client 

The Portmap Manager Client can be the NDB server or the NDB client. It sends a 

request to the Portmap Manager server and expects an available program number 

to be returned. The program number is used for future NDB requests. 


The NDB Server 

The NDB server provides services for client requests. The main routine, NDBSRV, 

receives the request from the client and determines the call type. The module 

performs several functions: 

v Verifying the data in the control block passed from the client 

v Setting up the Transaction Manager table, which contains different transactions 

v Issuing an SQL call to the database 

v 

Managing Multiple Threads, including Name Mapping, Verifying VM and SQL 

IDs, and Managing Unit of Work. 

The NDB server is invoked by the Portmap Manager Client. If the host wants to 

bring up more than one NDB server, start the Portmap Manager Client on multiple 

(up to 20) user ID’s: NDBSRV01, NDBSRV02,...NDBSR...V20. 

Transaction Manager:: Most databases perform a single thread transaction, 

although a few databases can perform multiple thread transactions. Multiple NDB 

client machines can send requests simultaneously to the servers. 

Unit Of Work (UOW): Unit of Work is a mark for the server to recognize the 

threads that came from clients. A client starts a UOW by issuing a "begin" 

statement. The client host machine’s user ID and password are requested. The 

client has to type in both; however, the password is not shown on the screen. After 

the "begin", the client can issue as many SQL statements as it wants. The client 

issues an end statement to end the UOW. Only the first request in a UOW is 

prompted for the database machine’s user ID and its password. The information is 

stored after the first request and destroyed when the last request is issued. If a 

client sends only one SQL request, a UOW does not have to be started. The client 

simply sends one request, and the server treats the request as an entire UOW. The 

host machine’s user ID and password are required. 

The Database Utility 

NDBFRONT is the main routine. It is a front end to the SQL preprocess program 

and performs the following functions. 

v Parsing the request that is an SQL statement 

v Packaging I/O buffers 

v Performing data conversions and managing different SQL data types. 

The Database Server: The Database Servers that NDB utilizes are relational 

database management systems that manage, store, and retrieve data. This data is 

stored in a database that is controlled by the database server. DATABASE 2 ® 

(DB2 ® ) is the IBM relational database management system for the MVS 

environment. For more information, see the DB2 Universal Database for OS/390 SQL 

Reference (SC26-9014–01).. SQL/DS is the relational database management system 

for the VM environment. For more information, see the IBM SQL/Data System 

General Information for IBM VM Systems manual (GH09-8074).. 

Connecting to a Database 

There are two ways to connect to a database system: 

Explicit connection 

Implicit connection 

Using NDB 

Explicit connection uses the preprocess calls, such 

as CONNECT, OPEN, CLOSE, DISCONNECT. 

Implicit connection does not use these functions, 

but starts making SQL calls. 


Using NDB 

If an SQL call occurs before the connection to the database has been established, 

the connection to the database is implicit, otherwise the connection is explicit. The 

explicit connection services are used to maximize flexibility and control. 

The CONNECT function allows application programs to connect to, and use a 

database. It provides a call interface to the database connection services. 

Application programs can control the exact state of their connection to the 

database. It is restricted to a single task level. The application program and the 

database system understand the connection status of multiple tasks in an address 

space. 

The explicit connection preprocess calls are: 

Function Description 

CONNECT Establishes a connection between the current address space and a 

database, and establishes the current task as a user of database 

services. 

OPEN Establishes the current task as a user of database services, and 

allocates database resources for SQL access (creates a thread). 

CLOSE Deallocates database resources (terminates the thread), and 

removes the task as a user of database services if the connection 

was established by OPEN instead of CONNECT. 

DISCONNECT 

Removes the task as a user of a database service. DISCONNECT 

also terminates the address space connection to a database if this is 

the only remaining task in the address space established as a user 

of database services. 

SQL Calls Pass through the Language Interface by branching to the entry 

point. 

NDBCLNT Command 

Use the NDBCLNT command to direct the client module to deliver requests to the 

remote database system. 

►► NDBCLNT machine_id “SQL_statement” ►◄ 

Operands 

machine_id 

Specifies the VM machine name where the NDB server is running. 

“SQL_statement” 

Specifies the SQL query statement. 

A single SQL query statement must be embedded within a pair of double quotes. 

Examples 

v A single SQL query statement is issued from a client machine. 

ndbclnt machine_id "select * from table2" 

The client machine prompts you for a VM user ID. 


Using NDB 

Please type in your Host user id ==> 

After you type in your user ID, the client machine prompts you for a password. 

The password you type is not displayed on the screen. 

Please type in your Host password ==> 

The user then waits for the result of the command issued. 

If the return code is -8, the user ID and password do not match. You must enter 

an end command to end this UOW before you can start a new UOW. 

If the return code is 25, it means that the user has accessed a table which is 

greater than 4096 characters. There is more data to be returned. If the user wants 

to have all data returned, using multiple statements in a UOW is recommended. 

v 

Multiple SQL query statements in a UOW require a "begin" and an end. The 

subsequent SQL query statements and the end do not require quotes. 

Multiple SQL query statements are issued from a client machine. 

ndbclnt machine_id "begin" 

The client machine prompts you for a VM user ID. 

Please type in your Host user id ==> 

After you type in your user id, the client machine prompts you for a password. 

The password you type is not displayed on the screen. 

Please type in your Host password ==> 

The client machine prompts you for the next command. 

Input your SQL statement without any quotes 

You enter your next command. 

select * from table2 

When the result of the command is returned, the client machine prompts you for 

your next command. 

Input your SQL statement without any quotes 

You enter your next command. 

select column1 from table2 

When the result of the command is returned, the client machine prompts you for 

your next command. 

end 

The client machine returns a message. 

You are done with your Unit of Work 

If the table is greater than 4096 characters you will get a return code of 25, 

which means there is more data. You can enter a continue command to continue 

to receive the rest of the table, or you can enter another SQL select statement if 

you do not need the rest of the table. 


Using NDB 

Format of Output Displayed on the Client 

The output can be treated as records. Each record contains three fields shown 

below: 

Field 

datatype 

datalength 

data 

Description 

char[2] 

char[5] 

char[x] where x is the content of datalength 

For this release the following data types have been implemented. 

Data Type Description 

li 

Specifies a long integer with indicator 

ln 

Specifies a long integer without indicator 

si 

Specifies a short integer with indicator 

sn 

Specifies a short integer without indicator 

ci 

Specifies a char with indicator 

cn 

Specifies a char without indicator 

vi 

Specifies a varchar with indicator 

vn 

Specifies a varchar without indicator 

fi 

Specifies a float with indicator 

fn 

Specifies a float without indicator 

For example, a record of the output might be as follows: 

Record 

Meaning 

ln 3 925 Specifies a long integer without indicator. The 

length of the data is 3. The value is 925. 

ci 10 ABCDEFGHIJ Specifies a char with indicator. The length of the 

data is 10. The data is ABCDEFGHIJ. 

In SQL/DS, with indicator means it allows NULL characters and without indicator 

means it does not allow NULL characters. 

The NDB client displays only the first 360 characters. If the user wants to see the 

entire output, look at the output file. The default output is ndb.output. All the 

results will be appended to the output file. 

SQL Commands from a Remote Machine 

You can issue an SQL command from a remote machine. The syntax is: 

ndbclnt machine_id "select tname, creator from system.syscatalog" 

You can issue a sequence of SQL commands between "begin" and end. 

In the following example, ndbclnt is the function name, machine_id is the remote 

machine where the database is located, and the SQL statement is between the 

double quotes. However, after a UOW has started, SQL commands do not require 

quotes. 

ndbclnt machine_id "begin" 

select * from table1 

select * uid.table where col = something 

. 

end 


SQL Commands from an Application 

When the SQL command is called from an application, the syntax is: 

ndbclnt ("machine_id", "select * from uid.table") 

Using NDB 

The explanation of each field is the same. 

You can write a C language program that uses NDBCLNT as C function call. To 

use NDBCLNT as a C function call, enter the command in the following format: 

ndbclnt(" machine_id ", " sql_statement "); 

where machine_id is the machine where SQL/DS is running and sql_statement is any 

SQL query statement. 

When you write a C language program using NDBCLNT as a C function call, you 

must also generate an executable module. 

There are two ways to generate an executable module. The following list describes 

one method for generating an executable module: 

v Compile your C program and NDB client source code. 

If you have NDB client source code and do not have the object files, you must 

perform the following commands: 

cc -c your_program.c 

cc -c ndbclnt.c 

cc -c ndbcancr.c 

cc -c ndb_clnt.c 

cc -c ndb_xdr.c 

The your_program variable represents the name of your C language program 

containing the ndbclnt call. 

v 

v 

If you have all the NDB client object files, you must perform the following 

command: 


Once you have the object files, you can generate an executable module. To 

generate an executable module perform the following command: 

cc -o appl application.o 

ndbclnt.o ndbcancr.o ndb_clnt.o ndb_xdr.o 

where appl is your final executable module and application is your C language 

program. 

You can run your application by issuing appl, your final executable module. 

The following list describes the second method for generating an executable 

module: 

v Compile your C language program and NDB client source code. 

If you have NDB client source code and do not have the object files, you must 

perform the following commands: 


cc -c ndbclnt.c 

cc -c ndbcancr.c 

cc -c ndb_clnt.c 

cc -c ndb_xdr.c 


Using NDB 

The your_program variable represents the name of your C language program 

containing the ndbclnt call. 

v 

v 

v 

v 

If you have all the NDB client object files, you must perform the following 

command: 


Use the following archive command to generate a library: 

ar rv libndbc.a ndbclnt.o ndbcancr.o ndb_clnt.o ndb_xdr.o 

where rv are the options and libndbc.;a is the library that is generated by the ar 

command. 

Issue a ranlib command to adjust the table of contents of libraries. 

Issue the following cc -o command to generate an executable module: 

cc -o appl application.o 

libndbc.a 

where appl is the executable module name and application.o is the object file of 

your C language program. 

You can run your application by issuing appl the executable module. 

Figure 14 is an example of a C language program that has an ndbclnt call. 

main(argc, argv) 

int argc; 

char *argv[]; 

{ 

. 

. 

. 

ndbclnt("eduvm2", "select * from willow.table1"); 

. 

. 

. 

} 

exit(0); 

Security 

There are two levels of security. 

v System security 

System security verifies that the clients are authorized to access the host system 

on which the relational database system resides. 

v Database security. 

Database security verifies that users are authorized to access the database. The 

database system administrator authorizes the different attributes to the different 

user IDs. For example, some users have read-write access, while others may 

have read-only access. 

Limitations 

You should be aware of the following limitations for the Network Database System 

on VM. 


Figure 14. An example of a C Language Program 

v 

NDB accepts query statements such as select. However, statements that change 

the content of tables are not allowed. This protects the user’s data integrity.

v 

v 

NDB supports only the following data types: 

– INT 

– SMALLINT 

– CHAR 

– VARCHAR 

– FLOAT 

Only C language is supported by NDB for client application program interface. 

Additional information on the NDB Client code 

Sample client code for a SUN workstation and for an RS/6000 running AIX V3.1 

are provided on the TCP/IP VM product tape. For the SUN version, the three files 

on the tape are named: 

v SDBCANCR C 

v SDB_CLNT C 

v SDB_XDR C 

If you are using a SUN UNIX workstation as the client, rename these 3 files back 

to NDBXXXX.C from SDBXXXX.C when downloaded to the SUN workstation and 

proceed with compiling and building the NDB client module. The files 

NDBCANCR C, NDB_CLNT C, and NDB_XDR C are specifically for the RS/6000. 

The files NDBCI C, NDBCLNT C, NDB H are for both the RS/6000 and the SUN 

versions of the NDB client code. 

The command for compiling and building the NDB client module is: 

cc -o ndbclnt ndbci.c ndbcancr.c ndb_clnt.c ndb_xdr.c 

Using NDB 


Using NDB 


Chapter 14. Using the Domain Name System 

This chapter describes the Domain Name System (DNS), domain name servers, 

resolvers, and resource records. This chapter also provides descriptions of the 

NSLOOKUP and DiG programs used to query name servers. 

Overview of the Domain Name System 

The TCP/IP for VM DNS includes a name server and a resolver API for 

application programs. For more information about these services, see “Domain 

Name Servers” on page 244 and “Resolvers” on page 245. Configuring these 

services is described in TCP/IP Planning and Customization. 

TCP/IP applications map domain names to a 32-bit internet address to identify 

network nodes. Mapping must be consistent across the network to ensure 

interoperability. The DNS provides this mapping, through network nodes called 

domain name servers. The DNS can provide additional information about nodes 

and networks, including the TCP/IP services available at a node and the location 

of name servers in a network. 

The DNS defines a special domain called in-addr.arpa to translate internet 

addresses to domain names. An in-addr.arpa name is composed of the reverse 

octet order of an IP address concatenated with the in-addr.arpa string. For 

example, a host named Host1 has 9.67.43.100 as an internet address. The 

in-addr.arpa domain translates the host1 internet address 9.67.43.100 to 

100.43.67.9.in-addr.arpa. 

For a complete description of the DNS, see RFC 1033, RFC 1034, and RFC 1035, 

which define the internet standard. 

Domain Names 

The DNS uses a hierarchical naming convention for naming hosts. Each host name 

is composed of domain labels separated by periods. Local network administrators 

have the authority to name local domains within an internet. Each label represents 

an increasingly higher domain level within an internet. The fully qualified domain 

name of a host connected to one of the larger internets generally has one or more 

subdomains. 

For example: 

host.subdomain.subdomain.rootdomain 

or 

host.subdomain.rootdomain 

Domain names often reflect the hierarchy level used by network administrators to 

assign domain names. For example, the domain name eng.mit.edu. is the fully 

qualified domain name where eng is the host, mit is the subdomain, and edu is the 

highest level domain (root domain). 

Figure 15 on page 244 is an example of the DNS used in the hierarchy naming 

structure across an internet. 


Using the Domain Name System 

* 

(root) 

GOV 

ORG 

EDU 

DIVISTION 

STATE 

REDCROSS 

SCOUTS 

USO 

MIT 

YALE 

ENG 

BUSINESS 

Figure 15. Hierarchical Tree 

You can refer to hosts in your domain by host name only; however, a name server 

requires a fully qualified domain name. The local resolver appends the domain 

name before sending the query to the domain name server for address resolution. 

Domain Name Servers 

Domain name servers are designated network nodes that maintain a database of 

information about all nodes in a zone. The complete database is not kept by any 

one name server on a network. A name server has a zone of authority that is a 

subnetwork, or a group of subnetworks, for which the name server maintains a 

database. A name server is authoritative only within its zone of authority. 

To minimize dependency on a particular node, the name server’s database for a 

zone is replicated at several nodes. At least one of the nodes is designated as the 

primary name server. The others are secondary name servers. The zone data 

updates and maintenance are reflected in the primary name server. The secondary 

name servers update their database by contacting the primary name server at 

regular intervals. Both primary and secondary name servers are authoritative for a 

zone. 

The zones of authority are arranged in a hierarchy based on the domain origin 

components. A special zone known as the root exists at the top of the domain name 

hierarchy in a network. The root zone contains a list of all the root servers. For 

example, in the internet, the root name servers store information about nodes in 

the root domain, and information about the delegated domains, such as com 

(commercial), edu (education), and mil (military). The root name servers store the 

names of name servers for each of these domains, which in turn store the names of 

name servers for their delegated subdomains. 

TCP/IP applications contact a name server whenever it is necessary to translate a 

domain name into an internet address, or when information is required about a 

domain. The name server performs the translation if it has the necessary 

information. If it does not have the necessary information, the name server can 

contact other name servers, which in turn can contact other name servers. This 


Resolvers 


process is called a recursive query. Alternatively, a name server can simply return 

the address of another name server that might hold the requested information. 

This is called a referral response to a query. Name server implementations must 

support referrals, but are not required to perform recursive queries. For more 

information about query responses, see “Resolvers”. 

Some name server implementations maintain a cache of query responses sent out 

to other name servers on behalf of clients. This improves the processing speed for 

queries about domain names outside the server’s zone of authority. However, 

responses derived from cached information are considered nonauthoritative and 

are flagged as such in the response. 

The Network Information Center (NIC) is responsible for network and user 

registration, including network number, top-level domain name assignment, and 

in-addr.arpa zone assignment. For more information contact: 

Government Systems, Inc. 

Attention: Network Information Center 

14200 Park Meadow Drive, Suite 200 

Chantilly, VA 22021 

1-(800)-235-3155 

(internet address: nic@nic.ddn.mil) 

TCP/IP provides three programs for interactively querying a name server: 

v NSLOOKUP 

v DiG 

v A CMS command interface (CMSRESOL) 

For more information about these programs, see “NSLOOKUP—Querying Name 

Servers” on page 249, “DIG—Querying Name Servers” on page 259, and 

“CMSRESOL—Resolver and Name Server” on page 270. 

Programs that query a name server are called resolvers. Because many TCP/IP 

applications need to query the name server, a set of routines is usually provided 

for application programmers to perform queries. Under VM, these routines are 

available in the TCP/IP application programming interface (API) for each 

supported language. 

Resolvers operate by sending query packets to a name server, either over the 

network or to the local name server. 

A query packet contains the following fields: 

v A domain name 

v A query type 

v A query class 

“Resource Records” on page 246 lists valid query class (network class) and query 

type (data type) records. The name server attempts to match the three fields of the 

query packet to its database. 

The name server can return the following query responses: 

Response Description 

Authoritative Returned from a primary or secondary name server. The name 

server contains all the domain data used to define the zone for the 

specified query. 

Chapter 14. Using the Domain Name System 245


Nonauthoritative 

Returned from a cache kept by a name server. The cache does not 

contain the domain data used to define the zone for the specified 

query. 

Referral 

Negative 

Name Error 

Contains the addresses of other name servers that can answer the 

query. A referral response is returned when a recursive query is not 

supported, not requested, or cannot be answered because of 

network connectivity. 

Indicates that no records of the requested type were found for the 

domain name specified, if returned from an authoritative name 

server. 

Indicates that no resource records of any type (including 

wildcards) exist for the domain name specified. 

Format Error Indicates that the name server found an error in the query packet 

sent by the resolver. 

Not-implemented 

Indicates that the name server does not support the type of query 

requested. 

Refused 

Indicates that the name server refuses to perform the specified 

operation. For example, some root name servers limit zone 

transfers to a set number of IP addresses. 

Data from a name server is stored and distributed in a format known as a resource 

record. Resource record fields are described in detail in “Resource Records”. Each 

response from a name server can contain several resource records that can contain 

a variety of information. The format of a response is defined in RFC 1035, and 

includes the following sections: 

v A question section, echoing the query for which the response is returned. 

v An answer section, containing resource records matching the query. 

v 

v 

An additional section, containing resource records that do not match the query, 

but might provide useful information for the client. For example, the response to 

a query for the host name of a name server for a specific zone includes the 

internet address of that name server in the additional section. 

An authority section, containing information specific to the type of response 

made to the query. If a referral is returned, this section contains the domain 

names of name servers that could provide an authoritative answer. If a negative 

response is returned indicating the name does not exist, this section contains a 

Start Of Authority (SOA) record defining the zone of authority of the responding 

name server. 

Resource Records 

Resource records are name server database records. These records contain the 

following fields, in order: 

Field Description 

Domain name Specifies the domain name identifying a network object. A network 

object can be a network, a specific node, a mailbox (for a network 

user’s mail), or other objects addressable by the DNS. 

TTL 

Indicates the number of seconds that a record is valid in a cache. 

Network class Specifies the network class. The allowable values are: 



CHAOS 

HESIOD 

IN 

CHAOS system (obsolete) 

Hesiod class 

The internet (most Domain Name Systems support 

only the internet (IN) class) 

The wildcard value ANY is defined to match any of these classes. 

Data type 

Indicates the type of data record. The following is a list of valid 

record types: 

SOA Start of authority record 

The SOA record is unique to a zone. This record 

contains the administrative details of the zone, 

including: 

v The domain name of the name server 

responsible for the zone 

v The mail address of the user responsible for the 

zone 

v The serial number of the zone database, which 

identifies the current revision of the data 

v The refresh interval, which indicates the length 

of time, in seconds, you must allow between the 

refreshing of a database from a remote name 

server 

v The retry interval, which indicates the length of 

time, in seconds, you must allow before retrying 

a failed refresh 

v The expiration TTL, which indicates the 

maximum time, in seconds, for records to be 

valid in the zone database 

v The minimum TTL, which indicates the 

minimum time, in seconds, for records to be 

valid in the zone database 

NS 

Name server record 

The name server record contains the domain name 

of a name server for the current zone. 

A 

Address record 

The address record contains the dotted decimal 

notation internet address for the domain name 

identifying the record. 

CNAME Canonical name record 

The canonical name record is used to provide alias 

or alternative name information for a domain 

name. The domain name specified in the first field 

of the record is an alternative to the canonical or 

real domain name specified in the data field. 

HINFO Host Information Record 

This record type contains a text string specifying 

the CPU (central processing unit) type and 

operating system of a node. 



MB 

MG 

MINFO 

MR 

MX 

NULL 

PTR 

TXT 

WKS 

The mailbox record (experimental) 

The mailbox record contains the domain name of a 

host machine to receive mail for the user specified 

in the domain name field. 

Mail group member record (experimental) 

The mail group member record specifies the mail 

address of a person belonging to the mail group 

specified in the domain name field. 

Mailbox information record (experimental) 

The mailbox information record specifies the mail 

addresses of the persons responsible for the mail 

group specified in the domain name field. 

Mail rename name record (experimental) 

The mail rename name record specifies a mailbox 

that is a rename of the mailbox specified in the 

domain name field. 

Mail exchanger record 

The mail exchanger record identifies a host able to 

act as a mail exchange for the domain specified in 

the domain name field. A mail exchange runs a 

mail agent that delivers or forwards mail for the 

domain name specified in the first field. 

Null resource record (experimental) 

The null resource record contains any information, 

providing it is less than 65 535 octets in length. 

Domain name pointer record 

The domain name pointer record is mainly used to 

store data for the in-addr.arpa domain, and 

contains the domain name referenced by an 


Text string record 

The text string record contains descriptive text. 

Well-known services record 

The well-known services record stores the protocol 

numbers of multiple services in a single record. 

Each of the defined TCP/IP services has a unique 

protocol number. For more detailed information, 

see RFC 1060. 

For flexibility, the following wildcard query data are defined: 

Type Description 

ANY Any record type for the domain name 

AXFR The query type used by secondary name servers to 

transfer all records in the zone (the query class is 

set to IN when using the AXFR query type) 



Data 

MAILB 

Any mailbox records for the domain name. 

Contains information appropriate for the data type indicated in the 

data type field, in the format defined for that specific data type. 

NSLOOKUP—Querying Name Servers 

NSLOOKUP is a program for querying name servers. The NSLOOKUP program 

allows you to: 

v Locate information about network nodes 

v Examine the contents of a name server database 

v Establish the accessibility of name servers 

NSLOOKUP Internal State Information 

The internal state information of NSLOOKUP determines the operation and results 

of your name server queries. You can configure the internal state information of 

NSLOOKUP Command 

NSLOOKUP using the following methods, listed in order of precedence: 

v TCP/IP client program configuration file, TCPIP DATA 

v NSLOOKUP startup file, NSLOOKUP ENV 

v NSLOOKUP options in command line mode 

v NSLOOKUP options in interactive session mode 

For information about the TCPIP DATA file, see TCP/IP Planning and Customization. 

After parsing the command line, NSLOOKUP attempts to read the startup file, 

NSLOOKUP ENV. This file contains only the NSLOOKUP options, which define 

the NSLOOKUP defaults. Enter each option on a separate line; blank lines are not 

accepted. For more information about the valid options available in NSLOOKUP, 

see “NSLOOKUP Options (SET Subcommand)” on page 254. 

The following is an example of the contents of the NSLOOKUP ENV file: 

set domain=powers.oz 

querytype=HINFO 

set norecurse 

vc 

Note: Specifying set before the NSLOOKUP options in the NSLOOKUP ENV file 

is optional. 

Use the NSLOOKUP command to issue multiple queries in interactive session 

mode, or specify an individual query in command line mode. 

Command Line Queries 

In command line mode, individual queries are made by specifying a domain name 

or address on the command line. 

Use the NSLOOKUP command in the following format to issue a query in 

command line mode. 



►► 

NSLOOKUP 

▼ 

−option 

domain_name 

domain_address 

server_name 

server_address 

►◄ 

Operands 

Note: Parameters and subcommands of NSLOOKUP are case sensitive and must 

be entered in lowercase. Parameter values and domain names are not case 

sensitive. 

option 

Specifies an NSLOOKUP option that tailors query output. See “NSLOOKUP 

Options (SET Subcommand)” on page 254 for the available options. 

domain_name 

Queries the name server for information about the current query type of 

domain_name. The default query type is A (address query). 

domain_address 

Reverses the components of the address, and generates a pointer type (PTR) 

query to the name server for the in-addr.arpa domain mapping of the address 

to a domain name. 

server_name 

Directs the default name server to map server_name to an internet address and 

then uses the name server at that internet address. 


Specifies the internet address of the name server to be queried other than the 

default name server. A query for the address in the in-addr.arpa domain is 

initially made to the default name server to map the internet address to a 

domain name for the server. 

When you specify NSLOOKUP options in command line mode, do not use set 

preceding the option. For example, to specify a name server (NS) type record 

lookup for the domain name fourex.oz, enter the following on the command line: 

nslookup -querytype=ns fourex.oz 

The -querytype=ns option is a SET subcommand parameter, but set is omitted 

from the command. For more information about using these options, see 

“NSLOOKUP Options (SET Subcommand)” on page 254. 

Interactive Session Queries 

Use the NSLOOKUP command in the following format to enter interactive session 

mode. 

►► 

NSLOOKUP 

▼ 

−option 

server_name 


►◄ 



Once you have entered an NSLOOKUP interactive session, you can issue multiple 

queries using the following format: 

►► 

▼ Enter 

interactive_option 

set option 

►◄ 

Operands 

Note: Parameters and subcommands of NSLOOKUP are case sensitive and must 

be entered in lowercase. Parameter values and domain names are not case 

sensitive. 

option 

Specifies an NSLOOKUP option that tailors query output. See “NSLOOKUP 

Options (SET Subcommand)” on page 254 for the available options. 

server_name 

Directs the default name server to map server_name to an internet address, then 

use the name server at that internet address. 


Specifies the internet address of the name server to be queried other than the 

default name server. A query for the address in the in-addr.arpa domain is 

initially made to the default name server to map the internet address to a 

domain name for the server. 

interactive_option 

Specifies an interactive query option. 

The following interactive query options are available for NSLOOKUP: 

{domain_name|domain_address}[server_name|server_address][{ >| >>} file_name] 

Directs NSLOOKUP to perform a query for the domain nominated. 

The query requests all information about the domain using the current 

class and query (resource record) type. You can specify a server other 

than the current server to perform the domain name resolution. 

Output can be placed in a file for later viewing by specifying file_name. 

The > file_name option places the output in file_name overwriting the 

contents, if any, of the file. The >> file_name option places the output in 

file_name appending it to the contents, if any, of the file. There must be 

at least one space before and after the > or >> symbol. 

Queries processed by NSLOOKUP that specify an address can give 

unexpected results. If the current query type is address (A) or domain 

name pointer (PTR), NSLOOKUP generates a PTR type query for the 

specified address in the in-addr.arpa domain. This returns PTR 

records, which define the host name for the specified address. If the 

current query type is neither of these two types, a query is performed 

using the current query type, with the domain name specified as the 

address given. 



Text that does not conform to the defined options and follows the 

preceding syntax is treated as a domain query. NSLOOKUP does not 

issue a query for a domain name if the name is unqualified and is the 

same as one of the defined options. 

server {name|address} 

Changes the current server. If name is specified, the internet address of 

name is determined using the current server. 

An error occurs if the domain name cannot be mapped to an internet 

address. This option does not ensure that you can contact a name 

server at the address; it simply changes a local variable storing the 

address of the default name server. 

lserver {name|address} 

Changes the current server. If name is specified, the internet address of 

name is determined using the initial server defined at command 

invocation. 

An error occurs if the domain name cannot be mapped to an internet 

address. This option does not ensure that you can contact a name 

server at the node specified, it simply changes a local variable storing 

the address of the default name server. 

root Changes the current server address to the address of the root server. 

The root server is ns.nic.ddn.mil by default, but can be changed using 

the root=name set subcommand. This command is equivalent to 

lserver name. 

An error occurs if the name of the root server cannot be mapped to an 

internet address. This option does not ensure that you can contact a 

name server at the node specified; it simply changes a local variable 

storing the address of the default name server. 

finger [loginname] [{>|>>} file_name] 

Extracts information from the finger server of the node found in the 

last address query. By default, this command returns a list of logged in 

users for the node last found. You can find information about a 

particular user by specifying the login name of the user as a parameter. 

The loginname variable is case sensitive and must be specified in the 

same case (upper or lower) as that used by the host. 

You can place output in a file for later viewing by specifying file_name. 





An error occurs if the preceding subcommand was not a successful 

address query or finger operation. If the current host is not defined, 

querying the name server defines that name server to be the current 

host for a subsequent finger operation. 

The finger option expects that the finger server is operating on the 

node found. An error occurs if the server is not operating or the node 

cannot be reached. 

ls [-{a|d|h|m|s|t [type]}] domain [{>|>>} file_name] 

Lists the information available for the domain. By default, the internet 

address of each node in the domain is listed. 



To select resource records other than the default, specify one of the 

following options: 

−a CNAME 

−d ALL 

−h HINFO 

−m MX 

−s WKS 

−t [type] 

Retrieves the resource record type specified in type. If no record 

type is specified with the −t option, the current default type is 

used. 

See the resource record field ““Data type”” on page 247 for 

information about valid query types. 

The ls command expects the domain name specified in domain to be a 

zone. If the domain name specified refers to a host, an error message is 

printed and no information is given. This command should create a 

virtual circuit (TCP connection) with the current name server to service 

the request. An error message is printed if the virtual circuit cannot be 

established. 

Output can be placed in a file for later viewing by specifying file_name. 





A number sign (#) is displayed at the terminal as every 50 lines are 

written to the file to indicate the command is still executing. 

view file_name 

Sorts and lists the contents of file_name one screen at a time. An error 

occurs if the file does not exist. 

help or ? 

Displays a brief summary of commands. 

exit Exits from NSLOOKUP interactive session mode. 

In interactive session mode, an initial query is made to the selected name server to 

verify that the server is accessible. All subsequent interactive queries are sent to 

that server, unless you specify another server using the server or lserver options. 

You can make a query by entering the domain name of the node or subnetwork for 

which information is required. Define the data type of information to be retrieved 

using the set querytype= option. You can define only one type of resource record 

for a domain name in a single query, unless the wildcard query type of ANY has 

been set. If an internet address is given rather than a domain name, a query for the 

address in the in-addr.arpa domain is made to map the internet address to a 

domain name. 

The domain name or address for the query can be followed by the domain name 

or internet address of a name server to contact for the query. If this is not 

specified, the current name server is used. For example, typing: 



toolah wurrup.fourex.oz 

queries the name server on wurrup.fourex.oz for information about the node 

toolah. When specifying domain names that include periods, the trailing period 

(indicating a fully qualified domain name) is optional. NSLOOKUP strips the 

trailing period if it is present. If you are specifying a root domain, the domain 

name must have two trailing periods. For example, specify mynode.. when the 

node mynode is in the root domain. 

The name server often requires a fully qualified domain name for queries. 

However, NSLOOKUP allows the specification of a default subnetwork domain 

using the set domain= option, with the initial default obtained from the TCPIP 

DATA file. When the defname flag is enabled using the set defname option, the 

default domain name specified by set domain= is appended to all unqualified 

domain names. For example, if the default domain name is fourex.oz and the 

defname flag is enabled, a query for the name toolah automatically generates a 

query packet containing the domain name toolah.fourex.oz. 

A time-out error occurs if the name server is not running or is unreachable. A 

Non-existent Domain error occurs if any resource record type for the specified 

domain name is not available at the name server. A Server Failed error occurs 

when the local name server cannot communicate with the remote name server. 

NSLOOKUP can interpret typing or syntax errors in subcommands as queries. This 

results in a query being sent and the name server response printed. The response 

is usually Non-existent Domain, which indicates that the server could not find a 

match for the query. 

NSLOOKUP Options (SET Subcommand) 

Internal state information affects the operation and results of your queries. You can 

change the internal state information maintained by NSLOOKUP using the 

NSLOOKUP options. Some internal state information is initially retrieved from the 

TCPIP DATA file. See TCP/IP Planning and Customization for more information 

about the TCPIP DATA file. 

The NSLOOKUP options consist of the SET subcommand and its associated 

parameters. These options can be specified in command line mode queries, 

interactive session mode queries, or in the NSLOOKUP ENV file. When 

NSLOOKUP options are specified in command line mode queries, you must omit 

the word set preceding the option. If the NSLOOKUP options are specified in 

interactive session mode queries, the word set must precede the option. In the 

NSLOOKUP ENV file, specifying the word set is optional. 

If the NSLOOKUP ENV file exists, the NSLOOKUP options are read from the file 

and executed before any queries are made. For more information about configuring 

NSLOOKUP internal state information using the NSLOOKUP ENV file, see 

“NSLOOKUP Internal State Information” on page 249. 

The following is a list of the NSLOOKUP options: 


all 

Allows you to print the current values of the internal state 

variables. This option does not alter the internal state of 

NSLOOKUP. 


class=class 

[no]brackets 

[no]d2 

[no]debug 

[no]defname 

domain=name 

[no]ignoretc 


Sets the class of information returned by queries. The class must be 

identified by its mnemonic. For more information about the classes 

recognized by NSLOOKUP, see the resource record field 

““Network class”” on page 246. The minimum abbreviation for this 

option is cl. 

Displays output using ';' for terminals that do not support 

square brackets. The default is brackets. 

Directs NSLOOKUP to enable or disable extra debugging mode. 

Using d2 also enables debug mode. The default is nod2. 

Directs NSLOOKUP whether to print debugging information for 

each query and its corresponding response. The default is nodebug 

(do not print debugging information). Specifying nodebug also 

disables d2 (extra debugging). The minimum abbreviations for 

these options are deb and nodeb. 

Specifies whether to append the default domain name to an 

unqualified domain name in a query. 

The default domain name is initially obtained from the TCPIP 

DATA file, but can be changed using the domain=name option. 

If the nodefname option is set, the domain name specified in the 

query is passed to the server without modification. The default is 

defname. The minimum abbreviations for these options are def and 

nodef. 

Sets the default domain name to name. Initially, the default domain 

name is obtained from the TCPIP DATA file. The validity of name 

is not verified. This option also updates the search list to contain 

only the domain name specified. The minimum abbreviation for 

this option is do. 

Directs NSLOOKUP on the handling of truncated responses. The 

name server indicates, in the response header, that the complete 

query response did not fit into a single UDP packet and has been 

truncated. 

Specifying ignoretc directs NSLOOKUP to ignore the truncation 

condition when it is set in the response by the name server. 

Specifying noignoretc directs NSLOOKUP to automatically retry 

the query using a TCP connection when a response is sent with the 

truncation indicator set. 

NSLOOKUP does not handle responses greater than 512 characters 

in length. Responses greater than 512 characters are truncated and 

the internal truncation flag is set. This condition is only revealed 

when the debug option is enabled. The default is ignoretc. The 

minimum abbreviations for these options are ig and noig. 

port=port Specifies the port number to use when contacting the name server. 

The DNS is a well-known service and has been allocated port 53. 

NSLOOKUP uses port 53 by default, but the port option allows 

you to specify another port to access. The minimum abbreviation 

for this option is po. 

querytype=type 

Specifies the type of information returned by queries. The initial 

query type is A (address information). See the resource record field 

““Data type”” on page 247 for the available query types. 



[no]recurse 

retry=limit 

root=name 

NSLOOKUP cannot generate queries about type NULL. However, 

it can accept responses containing resource records of type NULL. 

In this case, NSLOOKUP displays the number of bytes returned in 

the NULL record. Global queries that return all resource records 

for a specific domain name are specified by the wildcard value ANY. 

The minimum abbreviation for this option is q. 

The type=type option is accepted by NSLOOKUP as a synonym for 

the querytype=type option. 

Specifies whether to request a recursive query when querying a 

name server. The norecurse option specifies that a recursive query 

is not returned. The default is recurse. The minimum 

abbreviations for these options are rec and norec. 

Specifies the number of times a request is resent. When a request is 

sent and the time-out period expires for a response, the request is 

resent until the value specified in limit has been exceeded. The 

value specified in limit determines the number of attempts made to 

contact the name server. The default value for limit is retrieved 

from the TCPIP DATA file. 

Setting limit to zero disables NSLOOKUP from contacting the name 

server. The result is the following error message: no response from 

server. 

The retry algorithm for NSLOOKUP uses both the limit value and 

the time-out period. Each time a request is resent, the time-out 

period for the request is twice the time-out period used for the last 

attempt. The minimum abbreviation for this option is ret. 

Specifies the name of a root server. The root server is 

ns.nic.ddn.mil by default. 

[no]search Directs NSLOOKUP to enable or disable the use of a search list. 

The minimum abbreviations for these options are sea and nosea. 

srchlist=domain[/domain/...] 

Specifies one or up to three domain names to be appended to 

unqualified host names when attempting to resolve the host name. 

Each domain name specified is tried in turn until a match is found. 

This option also directs the default domain to be set to the first 

domain name specified in the search list. The minimum 

abbreviation for this option is srchl. 

timeout=interval 

Specifies the number of seconds to wait before timing out of a 

request. The default for interval is retrieved from the TCPIP DATA 

file. The minimum abbreviation for this option is t. 

[no]vc 

NSLOOKUP Examples 

Specifies whether to use a virtual circuit (TCP connection) to 

transport queries to the name server or datagrams (UDP). The 

default is retrieved from the TCPIP DATA file. If no entry is found, 

the default is novc (use datagrams). 

This section contains examples of NSLOOKUP command line mode queries, and 

interactive session mode queries using the various options available for 

NSLOOKUP commands. 



In Figure 16, the router, wurrup, has two internet addresses and there are two name 

servers, wurrup being the primary name server. This network is described by a 

single zone in the domain naming hierarchy stored in the name servers. The 

domain name is fourex.oz. 

NAMESERVER 

ES/9221: z/VM 

uluru 

101.3.104.38 

RS/6000: AIX_4.3 

canetoad 

101.3.104.40 

Desktop: WINDOWS_NT 

bandicool 

101.3.104.52 

101.3.104 

RS/6000: AIX_4.3 

wurrup 

101.3.104.12 

101.3.100.12 

NAMESERVER 

101.3.100 

RS/6000: AIX_4.3 

toolah 

101.3.100.2 

3090: z/OS 

gecko 

101.3.100.90 

Desktop: AIX_4.2 

galah 

101.3.100.20 

Figure 16. A TCP/IP Network 

The following are examples of how to use NSLOOKUP to extract information from 

a name server. The queries are executed from the VM host uluru at IP address 

101.3.104.38 on the network described in Figure 16. 

The following examples are command line mode queries. 

1. To make a simple address query: 

User: nslookup toolah.fourex.oz wurrup.fourex.oz 

System: Server: wurrup 

Address: 101.3.104.12 

Name: toolah.fourex.oz 

Address: 101.3.100.2 

2. To specify a name server (NS) type record lookup: 

User: nslookup -query=ns fourex.oz 

System: Server: canetoad 

Address: 101.3.104.40 

fourex.oz nameserver = wurrup.fourex.oz 

fourex.oz nameserver = canetoad.fourex.oz 

wurrup.fourex.oz internet address = 101.3.100.12 


canetoad.fourex.oz internet address = 101.3.104.40 

The following command places NSLOOKUP in interactive session mode with 

wurrup as the default server. 

User: nslookup - wurrup 

System: Default Server: wurrup 

Address: 101.3.104.12 



The following examples are all in the interactive session mode initiated in the 

preceding example. 

1. Show the default flag settings: 

User: set all 

System: >; Default Server: wurrup 

Address: 101.3.104.12 

Set options: 

nodebug defname nosearch recurse 

nod2 novc noignoretc port=53 

querytype=A class=IN timeout=60 retry=1 

root=ns.nic.ddn.mil 

domain=FOUREX.OZ 

srchlist=FOUREX.OZ 

2. Perform a simple address query: 

User: toolah 

System: >; Server: wurrup 

Address: 101.3.104.12 

Name: toolah.FOUREX.OZ 

Address: 101.3.100.2 

3. Set the query record type to HINFO, and perform another query: 

User: set q=HINFO 

toolah 

System: >; >; Server: wurrup 

Address: 101.3.104.12 

toolah.FOUREX.OZ CPU = RS6000 OS = AIX3.2 

4. Find out the name servers available for a domain: 

User: set q=NS 

fourex.oz 

System: >; >; Server: wurrup 

Address: 101.3.104.12 

fourex.oz nameserver = wurrup.fourex.oz 

fourex.oz nameserver = canetoad.fourex.oz 



canetoad.fourex.oz internet address = 101.3.104.40 

5. Change the current server from wurrup to canetoad and make more queries: 

User: server canetoad 

System: >; Default Server: canetoad.fourex.oz 

Address: 101.3.104.40 

User: set q=A 

gecko 

System: >; Server: canetoad.fourex.oz 

Address: 101.3.104.40 

Name: gecko.fourex.oz 

Address: 101.3.100.90 

6. Enable debugging and execute a simple query to see the result, and then 

disable debugging: 

User: set deb 

wurrup 

System: >; >; Server: canetoad.FOUREX.OZ 

Address: 101.3.104.40 

res_mkquery(0, wurrup.FOUREX.OZ, 1, 1) 

------------ 

Got answer: 


HEADER: 

opcode = QUERY, id = 7, rcode = NOERROR 

header flags: response, auth. answer, want recursion, 

recursion avail 

questions = 1, answers = 2, authority records = 0, 

additional = 0 

QUESTIONS: 

wurrup.FOUREX.OZ, type = A, class = IN 

ANSWERS: 

->; wurrup.FOUREX.OZ 

internet address = 101.3.104.12 

ttl = 9999999 (115 days 17 hours 46 mins 39 secs) 

->; wurrup.FOUREX.OZ 

internet address = 101.3.100.12 

ttl = 9999999 (115 days 17 hours 46 mins 39 secs) 

------------ 

Name: wurrup.FOUREX.OZ 

Addresses: 101.3.104.12, 101.3.100.12 

User: set nodeb 

7. Find all addresses in the fourex.oz domain using the ls option: 

User: 

System: 

DIG—Querying Name Servers 

ls fourex.oz 

>; canetoad.FOUREX.OZ 

fourex.oz 

server = wurrup.fourex.oz 

wurrup 101.3.100.12 

wurrup 101.3.104.12 

fourex.oz 

server = canetoad.fourex.oz 

canetoad 101.3.104.40 

gecko 101.3.100.90 

wurrup 101.3.100.12 

wurrup 101.3.104.12 

galah 101.3.100.20 

bandicoot 101.3.104.52 

toolah 101.3.100.2 

canetoad 101.3.104.40 

loopback 127.0.0.1 

uluru 101.3.104.38 

8. Find all aliases in the fourex.oz domain, then exit from NSLOOKUP interactive 

session mode: 

User: ls -a fourex.oz 

System: >; canetoad.FOUREX.OZ 

localhost 

loopback.fourex.oz 

infoserver 

wurrup.fourex.oz 

pabxserver 

wurrup.fourex.oz 

User: exit 

DIG is a program for querying domain name servers. The DIG program allows 

you to: 

v Exercise name servers 

v Gather large volumes of domain name information 

v Execute simple domain name queries 

DIG Internal State Information 

The internal state information of DIG determines the operation and results of your 

name server queries. You can configure the internal state information of DIG using 

the following methods, listed in order of precedence: 

v TCP/IP client program configuration file, TCPIP DATA 

v DIG startup file, DIG ENV 



DIG Command 

v 

Query options on the command line or in a batch file 

DIG Command 

The DIG ENV file contains a list of query option defaults. This list is initialized 

from the DIG ENV file when DIG is invoked. The default values in DIG ENV are 

used for all queries unless overridden by query flags on the command line. The 

defaults can be reset during a batch run by using the -envset flag on a batch file 

line. For more information about the query options available for DIG, see “Query 

Options” on page 261. 

The DIG ENV file is created and updated using the -envsav option, which writes 

the current defaults out to the file after parsing the query options on the command 

line. The -envsav option specified on the command line and the existing default 

values are saved in the DIG ENV file as the default environment for future 

invocations of DIG. The DIG ENV file is not reread when the environment is 

updated during batch queries and the -envsav flag has no effect on subsequent 

queries in a batch file. The DIG ENV file is written in nontext format and cannot 

be viewed or edited. 

You can use DIG in command line mode, where all options are specified on the 

invoking command line, or in batch mode, where a group of queries are placed in 

a file and executed by a single invocation of DIG. DIG provides a large number of 

options for controlling queries and screen output, including most of the functions 

of NSLOOKUP. 

You can create a file for batch mode queries using the -f file option. The file 

contains complete queries, one for each line, that are executed in a single 

invocation of DIG. The keyword DIG is not used when specifying queries in a batch 

file. Blank lines are ignored, and lines beginning with a number sign (#) or a 

semicolon (;) in the first column are comment lines. 

Options specified on the initial command line are in effect for all queries in the 

batch file unless explicitly overridden. Several options are provided exclusively for 

use within batch files, giving greater control over the operation of DIG. 

Some internal state information is retrieved from the TCPIP DATA file. See TCP/IP 

Planning and Customization for more information about the TCPIP DATA file. 

Use the DIG command to query a domain name server in command line mode or 

batch mode. 

►► DIG domain_name 

@server qtype qclass %comment 

► 

► 

▼ +queryoption ▼ −digoption 

►◄ 

Note: The queryoption and digoption parameters are case sensitive and must be 

entered in lowercase. Domain names, query types, query classes, and the 

values associated with queryoption and digoption parameters are not case 

sensitive. 


Operands 

server 

Specifies the domain name or internet address of the name server to contact 

for the query. The default is the name server specified in the TCPIP DATA file. 

If a domain name is specified, DIG uses the resolver library routines provided 

in the TCP/IP for VM programming interface to map the name to an internet 

address. 

domain_name 

Specifies the name of the domain for which information is requested. If the 

domain name does not exist in the default domain specified in the TCPIP 

DATA file, a fully qualified domain name must be specified. 

qtype 

Specifies the type of query to be performed. DIG does not support MAILA, 

MD, MF, and NULL query types. The wildcard query types are ANY, MAILB, 

and AXFR. For more information about valid query types, see the resource 

record field ““Data type”” on page 247. 

If the qtype option is omitted, the default query type is A (an address query). 

qclass 

Specifies which network class to request in the query. DIG recognizes only the 

IN, CHAOS, HESIOD, and ANY network classes. For descriptions of these 

classes, see the resource record field ““Network class”” on page 246. 

comment 

Enables you to include comments in a DIG command. Any characters 

following the percent (%) character up to the next space character (space or 

end-of-record) are ignored by DIG. This option is useful in batch files for 

annotating a command. 

For example, using a dotted-decimal notation internet address rather than a 

domain name removes any overhead associated with address mapping; 

however, this makes the command less readable. Therefore, in a batch file you 

can include the domain name as a comment for readability. 

queryoption 

Interprets the string following the plus sign (+) character as a query option. 

Query options have the format: 

parameter[=value] 

and are a superset of the set subcommand options for NSLOOKUP. See “Query 

Options” for the available query options. 

digoption 

Interprets the string following the minus sign (−) as a DIG option. The DIG 

options are either a parameter or a single character followed by a parameter. 

See “DiG Options” on page 264 for the available DIG options. 

Query Options 

The following list contains the query options available for the +queryoption 

parameter: 


[no]aaonly 

DIG Command 

Specifies whether to accept only authoritative responses or all 

responses to queries. The default is noaaonly (accept all responses). 


DIG Command 

[no]addit 

[no]answer 

[no]author 

[no]cl 

[no]cmd 

[no]d2 

[no]debug 

[no]defname 

domain=name 

[no]Header 

[no]header 

[no]ignore 

Specifies whether to print the additional section of the response. 

The additional section contains resource records that have not been 

explicitly requested, but could be useful. For more information 

about this option, see RFC 1035.. The default is addit (print the 

additional section). 

Specifies whether to print the answer section of the response. The 

answer section contains the set of all resource records from the 

name server database that satisfy the query. The default is answer 

(print the answer section). 

Specifies whether to print the authoritative section of the response. 

The authoritative section contains resource records that specify the 

address of an authoritative name server for the query. This section 

is used when the name server queried cannot provide an 

authoritative answer. The default is author (print the authoritative 

section). 

Specifies whether to print network class information for each of the 

resource records returned. The default is nocl (do not print 

network class information). 

Specifies whether to echo the parsed options. The default is cmd 

(echo parsed options). 

Specifies whether to print the details of each query sent out to the 

network, including send time-stamp and time-out time-stamp. 

When a server does not respond within the time-out period, DiG 

either sends the query to another server, or resends the query to 

the original server. The details of the query are visible when d2 is 

set. The default is nod2 (do not print query details). 

Directs DiG to print additional error messages. The default is debug 

(print additional error messages). 

Specifies whether to append the default domain name to all 

unqualified domain names in a query. The default domain name is 

set by specifying the +domain=name option. If the nodefname option 

is set, the domain name specified is passed to the server without 

modification. The default is defname (append the default domain 

name). 

Sets the default domain name to name. Initially, the default domain 

name is obtained from the TCPIP DATA file. The validity of name 

is not verified. If the defname option is set, the domain name 

specified in name is appended to all unqualified domain names 

before the queries are sent to the name server. 

Specifies whether to print the header line containing the operation 

code, returned status, and query identifier of each response. This 

option is distinct from the header option. The default is Header 

(print the header). 

Specifies whether to print the query flags of each response. The 

query flags are defined in RFC 1035. The default is header (print 

the query flags). 

Specifies whether to report truncation errors. Truncation errors 

occur when a response is too long for a single datagram. 

Specifying ignore directs DiG to ignore truncation errors. The 

default is noignore (report any truncation errors). 


[no]ko Specifies whether to keep the virtual circuit open for queries in 

batch mode only. This option has no effect when used on the 

command line or when datagrams are used to transport queries 

(see the novc option). The default is noko (create a new virtual 

circuit for each batch query). 

pfand=number Performs a bitwise AND of the current print flags with the value 

specified in number. The number can be octal, decimal, or 

hexadecimal. 

pfdef Sets the print flags to their default values. 

pfmin 

pfor=number 

pfset=number 

[no]primary 

[no]qr 

[no]ques 

[no]recurse 

[no]reply 

retry=limit 

[no]sort 

DIG Command 

Sets the print flags to the minimum default values. This option 

specifies that minimal information should be printed for each 

response. 

Performs a bitwise OR of the current print flags with the value 

specified in number. The number can be octal, decimal, or 

hexadecimal. 

Sets the print flags to the value specified in number. The number 

can be octal, decimal, or hexadecimal. 

Specifies whether to use only the primary name server for the 

zone, or include the secondary name servers. The default is 

noprimary (query primary or secondary name servers). 

Specifies whether to print the outgoing query. The outgoing query 

consists of a header, question section and empty answer, 

additional, and authoritative sections. See RFC 1035 for more 

information about outgoing queries. The default is noqr (do not 

print the outgoing query). 

Specifies whether to print the question section of a response. The 

question section contains the original query. The default is ques 

(print the question section). 

Specifies whether to request a recursive query when querying a 

name server. The norecurse option specifies that a recursive query 

is not requested. The default is recurse. 

Specifies whether to print the response from the name server. 

When this option is disabled, other print flags that affect printing 

of the name server response are ignored and no sections of the 

response are printed. The default is reply (print the response). 

Specifies the number of times a request is resent. When a request is 

sent and the time-out period expires for a response, the request is 

resent until the value specified in limit has been exceeded. The 

value specified in limit determines the number of attempts made to 

contact the name server. The default value for limit is retrieved 

from the TCPIP DATA file. 

Setting limit to zero disables DiG from contacting the name server. 

The result is an error message no response from server. 

The retry algorithm for DiG uses both the limit value and the 

time-out period. Each time a request is resent, the time-out period 

for the request is twice the time-out period used for the last 

attempt. 

Specifies whether to sort resource records before printing. The 

default is nosort (do not sort resource records). 


DIG Command 

[no]stats Specifies whether to print the query statistics including round trip 

time, time and date of query, size of query and response packets, 

and name of server used. The default is stats (print the query 

statistics). 

timeout=time_out_value 

Specifies the number of seconds to wait before timing out of a 

request. The default time out value is retrieved from the TCPIP 

DATA file. 

[no]ttlid 

[no]vc 

Specifies whether to print the TTL (time to live) for each resource 

record in a response. The default is ttlid (print time to live). 

Specifies whether to use a virtual circuit (TCP connection) to 

transport queries to the name server or datagrams (UDP). The 

default is retrieved from the TCPIP DATA file. If no entry is found, 

the default is novc (use datagrams) 

DiG Options 

The following list contains the available DiG options for the −digoption parameter: 

c query_class 

Specifies that the command line query or batch query retrieves resource 

records having the given network class. The qclass parameter, described on 

page 261, can also be used to specify the query class. In addition to the 

mnemonics, this option also accepts the equivalent numeric value that 

defines the class. 

envsav 

Directs DiG to save the environment specified on the current command 

line in the DIG ENV file. The DiG environment is described in “DIG 

Internal State Information” on page 259. This DIG ENV file initializes the 

default environment each time DiG is invoked. 

envset Directs DiG to set the default environment, see “DIG Internal State 

Information” on page 259, specified on the current line in the batch file. 

This default environment remains in effect for all subsequent queries in the 

batch file, or until the next line in the batch file containing the -envset 

option is reached. This option is valid for batch mode only. 

f file 

Specifies a file for DiG batch mode queries. The batch file contains a list of 

queries that are to be executed in order. The keyword DiG is not used when 

specifying queries in a batch file. Lines beginning with a number sign (#) 

or semicolon (;) in the first column are comment lines, and blank lines are 

ignored. Options that are specified on the original command line are in 

effect for all queries in the batch file unless explicitly overwritten. The 

following is an example of a batch file. 

# A comment 

; more comments 

wurrup any in +noH =noqu -c IN 

toolah +pfmin 

P 

p port 

Directs DiG to execute a ping command for response time comparison after 

receiving a query response. The last three lines of output from the 

following command are printed after the query returns: 

PING -s server_name 56 3 

Use the port number given when contacting the name server. The Domain 


Name System is a TCP/IP well-known service and has been allocated port 

53. DiG uses 53 by default, but this option allows you to override the port 

assignment. 

[no]stick 

Restores the default environment, see “DIG Internal State Information” on 

page 259, before processing each line of a batch file. This flag is valid for 

batch mode only. If you set the stick option, queries in the batch file are 

not affected by the options specified for preceding queries in the file. 

If you set the nostick option, the query option specified on the current line 

in the batch file remains in effect until the option is overridden by a 

subsequent query. The result of each query in the batch file depends on the 

preceding queries. The default is nostick. 

T seconds 

Specifies the wait time between successive queries when operating in batch 

mode. The default wait time is 0 (do not wait). 

t query_type 

Specifies that the query retrieves resource records having the given 

resource record type. The qtype parameter on page 261 can also be used to 

specify the query type. In addition to the mnemonics, this parameter also 

accepts the equivalent numeric value that defines the type. 

x dotted_decimal_notation_address 

Simplifies the specification of a query for the in-addr.arpa domain. 

Normally these queries are made by specifying a query type of PTR for 

nn.nn.nn.nn.in-addr.arpa, where the four nn components are replaced by 

the dotted-decimal notation internet address components in reverse order. 

This option allows you to make this query by simply specifying the 

dotted-decimal notation internet address. 

For example, the domain name corresponding to internet address 

101.3.100.2 is found by a query for the domain name 

2.100.3.101.in-addr.arpa. You can use DiG -x 101.3.100.2 instead of 

reversing the address and appending in-addr.arpa. 

DiG Examples 

The following section provides examples of how to use DiG to extract information 

from a name server. In Figure 16 on page 257, the router wurrup has two internet 

addresses, and there are two name servers, wurrup being the primary name server. 

This network is described by a single zone in the domain naming hierarchy stored 

in the name servers. In the examples, all queries are issued from the VM uluru 

system. 

1. Create a default environment (default options) that gives minimal output from 

subsequent DiG commands: 

System: 

User: 

Ready 

dig wurrup +noqu +noH +nohe +nost +noad +noau +nost +nocl 

+nottl -envsav 

System: ; Ques: 1, Ans: 2, Auth: 0, Addit: 0 

;; ANSWERS: 

wurrup.FOUREX.OZ. A 101.3.104.12 


DIG Command 

The following queries show which part of the response output is controlled by 

each of the output control options. Each example enables or disables query options 

for tailoring output. The wurrup.fourex.oz domain name is used for the following 

queries. 


DIG Command 


1. Set the query type to ns, the query class to in, and print the additional section 

of the output: 

System: Ready 

User: dig fourex.oz ns in +ad 


;; ANSWERS: 

fourex.oz NS wurrup.fourex.oz 

fourex.oz NS canetoad.fourex.oz 

;; ADDITIONAL RECORDS: 

wurrup.fourex.oz A 101.3.100.12 


canetoad.fourex.oz A 101.3.104.40 

2. Set the query type to ns, the query class to in, print the additional section of 

the output, but do not print the answer section: 

System: Ready 

User: dig fourex.oz ns in +addit +noanswer 


;; ADDITIONAL RECORDS: 



canetoad.fourex.oz A 101.3.104.40 

3. Query a nonexistent domain and print the authoritative section of the output: 

System: Ready 

User: dig noname +author 

System: ;; ->>HEADER

DIG Command 

;; ANSWERS: 



8. Do not print the header line: 

System: Ready 

User: dig wurrup +noH 


;; ANSWERS: 



9. Print the query flags: 

System: Ready 

User: dig wurrup +he 

System: ;; flags: qr aa rd ra ; Ques: 1, Ans: 2, Auth: 0, Addit: 

;; ANSWERS: 



10. Print the question section and the outgoing query: 

System: Ready 

User: dig wurrup +qu +qr 


;; QUESTIONS: 

;; wurrup.FOUREX.OZ, type = A, class = IN 

; Ques: 1, Ans: 2, Auth: 0, Addit: 0 

;; QUESTIONS: 

;; wurrup.FOUREX.OZ, type = A, class = IN 

;; ANSWERS: 



11. Print the query statistics including round-trip time: 

System: Ready 

User: dig fourex.oz ns in +stats 


;; ANSWERS: 

fourex.oz NS wurrup.fourex.oz 

fourex.oz NS canetoad.fourex.oz 

;; Sent 1 pkts, answer found in time: 37 msec 

;; FROM: FOUREXVM1 to SERVER: default -- 101.3.104.40 

;; WHEN: Tue Mar 16 11:06:40 1993 

;; MSG SIZE sent: 24 rcvd: 116 

12. Print the TTL for each resource record: 

System: Ready 

User: dig fourex.oz ns in +ttlid 


;; ANSWERS: 

fourex.oz 9999999 NS wurrup.fourex.oz 

fourex.oz 9999999 NS canetoad.fourex.oz 

13. Enable extra debugging mode: 

System: Ready 

User: dig wurrup +d2 

System: ;; res_mkquery(0, wurrup, 1, 1) 

;; Querying server (# 1) address = 101.3.104.40 

;;id=3-sending now: 4044656426 msec 


;; ANSWERS: 




DIG Command 

The following examples show how options control the use and value of the default 

domain. 

1. Do not append the default domain name to unqualified domain names and 

print the question section of the response: 

System: Ready 

User: dig wurrup +nodefname +qu 


;; QUESTIONS: 

;; wurrup, type = A, class = IN 

;; ANSWERS: 



2. Set the default domain name to fourexpd and print the question section of the 

response: 

System: Ready 

User: dig wurrup +do=fourexpd +qu 

System: ;; ->>HEADER

DIG Command 



wurrup.FOUREX.OZ. HINFO RS6000 AIX3.2 

The batch file, test.digbat used for this example is shown below. The default 

environment has been removed by discarding the DIG ENV file. The DiG 

command is omitted for all entries in the file. 

Note the effect of the -envset and -stick options on the output. 

wurrup any in +noH +nohe +noqu +noad +noau -envset -stick 

wurrup any in 

toolah a in +d2 

toolah a in 

toolah a in +d2 -nostick 

toolah a in 

toolah a in +nod2 

toolah a in 

1. Specify the batch file test.digbat: 

System: 

User: 

Ready 

dig -f test.digbat 

System: ; DiG 2.0 dig wurrup any in +noH +nohe +noqu +noad 

+noau -envset -st k 


;; ANSWERS: 

wurrup.FOUREX.OZ. 9999999 A 101.3.104.12 


wurrup.FOUREX.OZ. 86400 HINFO RS6000 AIX3.2 



;; WHEN: Tue Mar 16 11:15:57 1993 


System: ; DiG 2.0 dig wurrup any in 


;; ANSWERS: 



wurrup.FOUREX.OZ. 86400 HINFO RS6000 AIX3.2 



;; WHEN: Tue Mar 16 11:15:57 1993 


System: ; DiG 2.0 dig toolah a in +d2 

;; res_mkquery(0, toolah, 1, 1) 




;; ANSWERS: 

toolah.FOUREX.OZ. 9999999 A 101.3.100.2 



;; WHEN: Tue Mar 16 11:15:57 1993 


System: ; DiG 2.0 dig toolah a in 


;; ANSWERS: 




DIG Command 

System: 

System: 

System: 

System: 


;; WHEN: Tue Mar 16 11:15:57 1993 


; DiG 2.0 dig toolah a in +d2 -nostick 





;; ANSWERS: 




;; WHEN: Tue Mar 16 11:15:57 1993 


; DiG 2.0 dig toolah a in 





;; ANSWERS: 




;; WHEN: Tue Mar 16 11:15:57 1993 


; DiG 2.0 dig toolah a in +nod2 


;; ANSWERS: 




;; WHEN: Tue Mar 16 11:15:57 1993 


; DiG 2.0 dig toolah a in 


;; ANSWERS: 




;; WHEN: Tue Mar 16 11:15:58 1993 


CMSRESOL—Resolver and Name Server 

The resolver is a program or subroutine that obtains information from a name 

server or site tables to convert host names into internet addresses. 

The name server is used for cross-referencing a name to its corresponding internet 

address. The name server uses an DB2 Server for VM database, or other name 

servers as its source of information. 

RESOLV Command—Interface to the CMSRESOL MODULE 

The RESOLV EXEC provides a sample EXEC interface to the CMSRESOL 

MODULE to perform standard Name Server queries. The sample provided has 

limited capability, but can be modified as needed using a VMSES/E local 

modification. 


CMSRESOL Command 

►► RESOLV quest_name 

quest_type 

nsaddr 

►◄ 

Operands 

quest_name 

Specifies the name of the resource that is the target of the query. This is a 

required parameter. 

quest_type 

Specifies the query question type (Qtype). If omitted, the Qtype defaults to A 

(host address query type). 

The valid values for this parameter are listed in the header file CMOLVER.H. 

They are also listed in RFC 883. 

nsaddr 

Specifies the internet address of the name server from which you want a 

response. If omitted, the first NSINTERADDR value defined in the TCPIP 

DATA file is used; if no such value is found, the VM TCP/IP loopback address 

(127.0.0.1) is used. 

CMSRESOL Command—Interface to the Resolver 

The CMSRESOL program can send queries to the name server using TCP, UDP, or 

CMS IUCV. The CMSRESOL program sends the query and receives the results by 

the communication method defined on the CMSRESOL command. The results are 

placed on the program stack. 

►► CMSRESOL querytype ((question)) ( ) 

(answer) 

► 

► ( ) 

(additional) 

nsaddr howtosend timeout nsvmid ►◄ 

Operands 

querytype 

Specifies QUERY, IQUERY, or DBASE. 

QUERY Specifies the standard query 

IQUERY Specifies the inverse query 

DBASE Specifies the database query or update. 

question 

Specifies the form of Qname, Qtype,and Qclass. 

answer 

Specifies the form of Name, Type, Class, TTL, and Data. 

additional 

Used for database queries and updates. See “The Database Query and Update” 

on page 273 for the syntax of database queries and updates. 


CMSRESOL Command 

Types of Queries 

nsaddr 

Specifies the internet address of the name server. For example: 101.3.104.40. 

howtosend 

Indicates the form of the query. The form can be: 

DATAGRAM 

Specifies the use of UDP datagrams 

CONN 

Specifies the use of TCP streams 

IUCV Specifies the use of CMS IUCV. 

timeout 

Indicates the number of seconds to wait when attempting to open a connection 

to the name server. 

nsvmid 

Specifies the VM user ID of the virtual machine that is running the name 

server. This is required for IUCV processing only. 

The question, answer, authority, and additional sections are returned as separate lines 

in the program stack (system data queue). They can be extracted from the queue 

with the REXX PULL instruction. The CMSRESOL command results in one of the 

following return codes: 

Return Code Description 

0 No error condition 

1 Format error 

2 Name server failure 

3 Domain name does not exist 

4 Not implemented 

5 Refused by name server 

20 Parameter error 

21 Error in communicating with name server 

22 Software error 

Notes: 

1. The name server uses an internal buffer of 4096 bytes to transfer data. If this 

limit is exceeded, a name server failure-error condition is returned. 

2. Each line in the program stack can hold as many as 255 characters. Data in 

excess of this limit is wrapped into additional lines in the program stack. 

3. You must allow at least one space between adjacent sets of parentheses for 

these queries to work. 

This section contains examples of standard, inverse, in-addr.arpa domain, and 

database queries, as well as examples of queries outside your domain. 

Note: The figure of 86 400, which appears in the program stack, is a typical TTL 

value of 24 hours, expressed in seconds. 

The Standard Query 

A standard query provides the question, and the answer is returned. An example of 

a standard query is: 

CMSRESOL QUERY ( ( RALPH.YKT.IBM.COM A IN ) ) ( ) ( ) 127.0.0.1 

DATAGRAM 60 NAMESRV 


The results of the query are placed on the program stack. An example of the 

format of the data on the stack resulting from this standard query is: 

( ( RALPH.YKT.IBM.COM A IN ) ) 

( ( RALPH.YKT.IBM.COM A IN 86400 192.5.5.5 ) ) 

( ) 

( ) 

The Inverse Query 

An inverse query provides the answer, and the question is returned. An example of 

an inverse query using a TCP virtual circuit and the resulting stack contents is: 

CMSRESOL IQUERY ( ) ( ( X.YKT.IBM.COM A IN 0 192.5.5.5 ) ) ( ) 

127.0.0.1 CONN 60 NAMESRV 

The stack contents are: 

( ( RALPH.YKT.IBM.COM A IN ) ) 


( ) 

( ) 


Querying the in-addr.arpa Domain 

Only local, authoritative data is returned from a name server in response to an 

inverse query. Recursion is not available, because an inverse query does not supply 

the domain origin in the data field. To resolve an internet address to a domain 

name, a special domain exists called in-addr.arpa. The in-addr.arpa domain 

contains the internet address of the name field in reverse order, suffixed with 

in-addr.arpa. To resolve the internet address to a domain name, do a standard 

query supplying the internet address, in reverse order, suffixed with in-addr.arpa 

in the name field. 

An example of this type of query is: 

CMSRESOL QUERY ( ( 126.43.67.9.IN-ADDR.ARPA PTR IN ) ) ( ) ( ) 127.0.0.1 

DATAGRAM 45 NAMESRV 


format of the data on the stack resulting from this query is: 

( ( 126.43.67.9.IN-ADDR.ARPA PTR IN ) ) 

( ( 126.43.67.9.IN-ADDR.ARPA PTR IN 86400 VMX.RALEIGH.IBM.COM ) ) 

( ) 

( ) 

The Database Query and Update 

A database query and update permits a client to update the DB2 Server for VM 

database. The database query and update functions are enhancements provided by 

IBM. An authorization scheme protects the database from unauthorized updates. 

The name field of a resource record (RR) type 97 defines a domain name; the data 

field defines a list of VM user IDs that can perform a database update. The serial 

value specified on the start of authority (SOA) record is not updated to reflect a 

change in the zone data. Other locations that transfer the domain do not do so 

until the serial on the SOA record is modified, or the refresh timer expires. See 

RFC 1034 or 1035 for further information on SOA records. 

An example of a database update follows. IUCV is required for database updates. 

UDP datagrams or TCP virtual circuits are not permitted. 

CMSRESOL DBASE ( ) ( ) ( ( RALPH.YKT.IBM.COM UPDATE IN 0 #A RSRVD 

This is the NewData# ) ) 127.0.0.1 IUCV 60 NAMESRV 




( ) 

( ) 

( ) 

( ) 

Note: In a database update, no data is returned between the parentheses. 

The database functions use the additional sections to transport the request to the 

name server. Figure 17 provides the format of the data within the additional section: 

Name Type1 Class TTL Rdata 

Type2 RSRVD NewData 

Figure 17. The Database Format of an Additional Section 

Type1 can be update or select for database functions. The Rdata field is 

surrounded by the # character. Within the Rdata field, there are three subfields for 

update operations: Type2, RSRVD, and NewData. This example uses an A-type 

internet address, which for the IN (Internet system) class is a 32-bit internet 

protocol address. 

Subfield Description 

Type2 Specifies the record type to be updated 

RSRVD Is a reserve field 

NewData Is the new data 

For database updates, a TYPE97 resource record (RR) is examined for authorization 

checking. For more information, see TCP/IP Planning and Customization. 

The following is an example of a database query using UDP datagrams. For a 

query operation, TCP virtual circuits, UDP datagrams, or CMS IUCV are allowed. 

CMSRESOL DBASE ( ) ( ) ( ( RALPH.YKT.IBM.COM SELECT IN 0A) ) 

127.0.0.1 DATAGRAM 60 NAMESRV 


( ) 


( ) 

( ( RALPH.YKT.IBM.COM SELECT IN 0A)) 

The database query operation, like the update operation, uses the additional section 

to transport the request to the name server. The type in this case is SELECT, 

indicating a database query operation. The Rdata field indicates the type of RR to 

query. In this example, the type of RR to query is the internet address Type A. The 

results are returned in the answer section. 

Querying Outside Your Domain 

The following is a sample of a query outside your domain: 



CMSRESOL QUERY ( ( ALPHA.UNKNOWN.COM A IN ) ) ( ) ( ) 

127.0.0.1 DATAGRAM 30 NAMESRV 


format of the data on the stack resulting from this query is: 

( ( ALPHA.UNKNOWN.COM A IN ) ) 

( ) 

( ( UNKNOWN.COM NS IN 86400 NAMESERVER.UNKNOWN.COM ) ) 

( ( NAMESERVER.UNKNOWN.COM A IN 86400 128.1.2.3 ) ) 




Chapter 15. Using Translation Tables 

TCP/IP uses translation tables to convert transmitted data between EBCDIC and 

ASCII. Because the meanings of the terms “EBCDIC” and “ASCII” depend on the 

particular operating system and the national language (English, French, etc.) being 

used on a particular system, TCP/IP provides many different translation tables to 

meet the diverse needs of z/VM users. 

In addition to the more than 200 translations provided by IBM, you can create 

custom tables to meet your specific requirements. 

The following sections provide the information you need to understand what 

translation tables are, how they are used by TCP/IP applications, and how you can 

create your own custom translations. 

Character Sets and Code Pages 

When you display or print a document, you see a collection of characters or 

symbols. A group of characters or symbols taken together and treated as a single 

entity is called a character set. A character set may contain hundreds or even 

thousands of characters. 

In a Single-Byte Character Set (SBCS), one 8-bit byte is used to represent a single 

character. This means there are only 256 possible bit patterns or code points 

available to represent a character. All Western languages can be represented by an 

SBCS character set. 

A Double-Byte Character Set (DBCS) uses two bytes to represent a single character, 

providing a theoretical maximum of 65536 characters. In practice, DBCS character 

sets contain far fewer than 65536 characters. Eastern languages such as Japanese 

Kanji, Korean Hangeul, and traditional Chinese require a DBCS character set. 

A collection of all of 256 (for SBCS) or 65536 (for DBCS) code points and their 

corresponding individual character assignments are called a code page. 

While it is true that always using a universal DBCS character set such as Unicode 

would eliminate the need to perform EBCDIC-ASCII translation, most of the 

operating systems and standard TCP/IP application protocols in use today were 

developed before the advent of DBCS. As a consequence, every country or 

common geographic region developed its own country-specific SBCS code page, 

particularly in the EBCDIC environment. Characters were deleted, added, and their 

order changed. 

Consequently, it is necessary to understand and manage the use of code pages. To 

assist in that effort, IBM has assigned a unique number to many of the EBCDIC 

and ASCII code pages you will use. The specific code page translations provided 

with TCP/IP are listed in Table 19 on page 280. Facilities are provided so that you 

may supplement the translations provided by IBM with your own. 

The TCP/IP translation tables convert data from one code page to another, so the 

table you choose depends on the code pages being used by the systems involved 

and your knowledge of how a file was created. 


Using Translation Tables 

It is important to recognize that changing the default translation table for servers 

such as FTP and NFS can corrupt data in a file if that file is uploaded and 

downloaded using different translation tables. (This does not apply to binary 

transfers, of course.) 

TCP/IP Translation Table Files 

TCP/IP translation tables are machine-readable binary files that are usually kept 

on the TCP/IP user disk, TCPMAINT 592. 

Most of these files are provided by IBM, and others may be created by compiling 

SBCS or DBCS translation table source files using the CONVXLAT command, 

described in “Converting Translation Tables to Binary” on page 286. 

Table 17. Translation Table Files 

Character Set Language Source File Type Table File Type 

SBCS Any TCPXLATE TCPXLBIN 

DBCS Japanese Kanji TCPKJLAT TCPKJBIN 

DBCS Korean Hangeul TCPHGLAT TCPHGBIN 

DBCS Traditional Chinese TCPCHLAT TCPCHBIN 

Note that the file types for the different languages are different. There can be up to 

four translation table that have the same file name – one for all SBCS languages, 

and one for each of the three DBCS languages. 

SBCS tables contain translations for one pair of code pages. DBCS tables may 

contain multiple translations. 

To modify an IBM-provided translation table: 

1. Modify the source file as required 

2. Run the CONVXLAT program, specifying the modified source as input 

3. Copy the resulting TCPxxBIN file to the TCP/IP user disk, TCPMAINT 592. 

Translation tables made available to servers should also be made available to 

clients. 

To create a new translation table, first copy an existing source file and then follow 

the procedure outlined above. 

SBCS translation tables may be read by CMS applications using the DTCXLATE 

CSL routine. For more information on DTCXLATE, see the z/VM: CMS Callable 

Services Reference. 

Translation Table Search Order 

Most TCP/IP client and server programs provide a way for the you to change the 

translation table that is used. This is done using either client command line 

options, server initialization parameters, or configuration file statements. For 

example, the CMS FTP client provides a TRANSLATE option that you can use to 

provide the name of a translation table. 

If no such option or configuration statement is provided, the clients and servers 

will use a preferred translation table that is specific to a particular client or server. If 

the preferred table cannot be found, the common standard translation will be used. 


The standard translation is loaded from STANDARD TCPxxBIN, if it is available, 

or from an equivalent that is compiled into the program. 

Table 18 shows the option or configuration statement that may be used to provide 

the name of a translation table to be used by each client or server. Any program 

not listed can be assumed to use STANDARD. 

Table 18. Preferred Translation Tables 


Program 

Option 

Preferred 

Translation Table 

SMTP Server None¹ SMTP 

FTP Server SITE TRANSLATE table_name² SRVRFTP 

FTP Client TRANSLATE table_name² FTP 

UFT Client (SENDFILE) TRANSLATE table_name² STANDARD 

UFT Server TRANSLATE table_name² STANDARD 

LPR Client TRANSLATE table_name² LPR 

LPD Server TRANSLATETABLE table_name² LPD 

NFS Server XLATE=table_name² VMNFS 

TELNET Client TRANSLATE table_name² TELNET 

TELNET Server (line mode) None STLINMOD 

TFTP Client TRANSLATE table_name² TFTP 

Note¹: For SMTP, an additional translation table may be specified for 8-bit MIME support. 

The TCP/IP Planning and Customization contains more information in the “8BITMIME 

Statement” section. 

Note²: table_name is the file name of a TCP/IP translation table. 

If a table is explicitly referenced by a program option or configuration statement, 

the program will display an error message and stop if the translation table file 

cannot be found or loaded. 

The file type of the translation table depends on whether any DBCS features are 

used. If Kanji translation is requested, the file type is TCPKJBIN. If Korean 

translation is requested, the file type is TCPHGBIN. For traditional Chinese, the file 

type is TCPCHBIN. 

The TCP/IP User’s Guide contains information on the TRANSLATE option for the 

TCP/IP clients, and the TCP/IP Planning and Customization contains information for 

the servers. See the z/VM: CMS Command and Utility Reference for information 

about the SENDFILE command. 

Special Telnet Requirements 

Telnet Client 

The Telnet client requires a translation table that is different from the default table, 

STANDARD. The preferred translation table is provided by IBM as TELNET 

TCPXLBIN. If this file is not found, however, the default table will be used. 

Country-specific translation tables for the Telnet application are provided. These 

tables have the file type TELXLATE. You must rename the selected file to TELNET 

Chapter 15. Using Translation Tables 279


TCPXLATE before it is converted to binary using the CONVXLAT command. The 

resulting TELNET TCPXLBIN should then be copied to TCPMAINT 592, replacing 

the IBM version. 

Note: You cannot use the Telnet translation tables to change the LineFeed (X'0A') 

character. 

Telnet Server 

For line mode Telnet sessions, translation is performed by the Telnet server using 

the STANDARD translation table. If this table does not meet your needs, you can 

create an STLINMOD TCPXLATE table, convert it to binary using CONVXLAT, 

and copy the resulting STLINMOD TCPXLBIN file to the TCP/IP customization 

disk, TCPMAINT 198. 

IBM-Supplied Translation Tables 

Table 19. IBM Translation Tables 

In order to meet the translation needs of users and installations worldwide, more 

than 200 translation tables are provided with TCP/IP for your use. Some tables 

already exist in binary form; others require conversion using the CONVXLAT 

command, as described in “Converting Translation Tables to Binary” on page 286. 

Translation Table File Translation Table File Host Code Page Remote Code 

Country 

Name 

Type 

Page 

United States and Canada 0037rrrr TCPXLATE 37 rrrr 

Austria and Germany 0273rrrr TCPXLATE 273 rrrr 

Denmark and Norway 0277rrrr TCPXLATE 277 rrrr 

Finland and Sweden 0278rrrr TCPXLATE 278 rrrr 

Italy 0280rrrr TCPXLATE 280 rrrr 

Spain and Spanish-speaking 0284rrrr TCPXLATE 284 rrrr 

Latin America 

United Kingdom 0285rrrr TCPXLATE 285 rrrr 

France 0297rrrr TCPXLATE 297 rrrr 

International 0500rrrr TCPXLATE 500 rrrr 

Iceland 0871rrrr TCPXLATE 871 rrrr 

ISO 8859-15 0924rrrr TCPXLATE 924 rrrr 

OpenEdition ® (POSIX) 1047rrrr TCPXLATE 1047 rrrr 

United States and Canada (Euro) 1140rrrr TCPXLATE 1140 rrrr 

Austria and Germany (Euro) 1141rrrr TCPXLATE 1141 rrrr 

Denmark and Norway (Euro) 1142rrrr TCPXLATE 1142 rrrr 

Finland and Sweden (Euro) 1143rrrr TCPXLATE 1143 rrrr 

Italy (Euro) 1144rrrr TCPXLATE 1144 rrrr 

Spain and Spanish-speaking 1145rrrr TCPXLATE 1145 rrrr 

Latin America (Euro) 

United Kingdom (Euro) 1146rrrr TCPXLATE 1146 rrrr 

France (Euro) 1147rrrr TCPXLATE 1147 rrrr 

International (Euro) 1148rrrr TCPXLATE 1148 rrrr 

Iceland (Euro) 1149rrrr TCPXLATE 1149 rrrr 


Table 19. IBM Translation Tables (continued) 

Translation Table File Translation Table File Host Code Page Remote Code 

Country 

Name 

Type 

Page 

OpenEdition 1047rrrr TCPXLATE 1047 rrrr 

ISO 8859-15 (EBCDIC) 0924rrrr TCPXLATE 924 rrrr 

ISO 8859-15 (ASCII) hhhh0923 TCPXLATE hhhh 923 

OS/2 hhhh0850 TCPXLATE hhhh 850 

OS/2 (Euro) hhhh0858 TCPXLATE hhhh 858 

ISO 8859-1 (ASCII) hhhh0819 TCPXLATE hhhh 819 

Microsoft ® Windows ® hhhh1252 TCPXLATE hhhh 1252 

Austria and Germany AUSGER TCPXLATE 273 850 

Belgium BELGIAN TCPXLATE 500 850 

Canada CANADIAN TCPXLATE 37 850 

Denmark and Norway DANNOR TCPXLATE 277 850 

Netherlands DUTCH TCPXLATE 37 850 

Finland and Sweden FINSWED TCPXLATE 278 850 

France FRENCH TCPXLATE 297 850 

Italy ITALIAN TCPXLATE 280 850 

Japan JAPANESE TCPXLATE 281 850 

OpenEdition POSIX TCPXLATE 1047 819 

Portugal PORTUGUE TCPXLATE 37 850 

Spain and Spanish-speaking SPANISH TCPXLATE 284 850 

Latin America 

Switzerland (French) SWISFREN TCPXLATE 500 850 

Switzerland (German) SWISGERM TCPXLATE 500 850 

United Kingdom UK TCPXLATE 285 850 

United States US TCPXLATE 37 850 

Standard (SBCS) STANDARD TCPXLATE EBCDIC ASCII 

Standard Japanese Kanji 

JIS X0208 1978 

JIS X0208 1983 

Shift JIS X0208 

Extended Unix Code 

IBM 

STANDARD 

TCPKJLAT 


300 

300 

300 

300 

300 

X0208 

X0208 

X0208 

EUC 

300 

Standard Korean Hangeul 

KSC 5601 SBCS 

KSC 5601 DBCS 

Hangeul SBCS 

Hangeul DBCS 

STANDARD 

TCPHGLAT 

833 

834 

833 

834 

1088 

951 

891 

926 

Standard Traditional Chinese 

Traditional Chinese SBCS 

Traditional Chinese DBCS 

STANDARD 

TCPCHLAT 

037 

835 

904 

927 

Note: In this table hhhh and rrrr represent four-digit host and remote code page numbers, respectively. 



Notes: 

1. STANDARD TCPXLBIN is a 7-bit non-reversible translation table. For inbound 

data, all ASCII characters with values in the range X'80'-X'FF' will have the 

same translation as values X'00'-X'7F'. The high-order bit of each ASCII byte is 

ignored and is assumed to be zero. For example, ASCII X'B1' and X'31' will 

both be converted to EBCDIC X'F1'. For outbound data, EBCDIC control 

characters that do not have ASCII equivalents are converted to ASCII X'1A'. 

STANDARD should be used in situations where a client or server is known to 

treat the high-order bit in each byte as a parity bit. 

2. All other SBCS translation tables provide a unique, one-to-one mapping of all 

256 code points. 

3. All tables translate ASCII LineFeed (LF, X'0A') to and from EBCDIC LF (X'25'), 

except for POSIX and 1047rrrr, which use EBCDIC NewLine (NL, X'15') instead. 

4. Host code pages 924 and 1140-1149 include translations for the euro currency 

symbol. 

Customizing SBCS Translation Tables 

All SBCS translation table files contain two tables. The first table is used to 

translate from ASCII to EBCDIC. The second table is used to translate from 

EBCDIC to ASCII. 

To read the translation tables, find the row for the first hex digit (▌1▐) and the 

column for the second hex digit (▌2▐). The point where the row and column 

intersect is the translation value. 

For example, to find the EBCDIC translation for the ASCII character X'A7', find 

row A0 (▌3▐) and column 07 (▌4▐) in the following example. The point where row 

A0 and column 07 intersect shows a value of X'7D', so the ASCII character X'A7' 

will be translated to a X'7D' in EBCDIC. To customize the translation table, alter 

the translate value where the row and column intersect to the new value. 

; 

; ASCII-to-EBCDIC table 

; ▌4▐ ▌2▐ 

;000102030405060708090A0B0C0D0E0F 

; ▌1▐ 

00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F ; 00 ; 

10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F ; 10 ; 

40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61 ; 20 ; 

F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F ; 30 ; 

7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6 ; 40 ; 

D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D ; 50 ; 

79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96 ; 60 ; 

97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07 ; 70 ; 

00 01 02 03 37 2D 2E 2F 16 05 25 0B 0C 0D 0E 0F ; 80 ; 

10 11 12 13 3C 3D 32 26 18 19 3F 27 22 1D 35 1F ; 90 ; 

40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61 ; A0 ; ▌3▐ 

F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F ; B0 ; 

7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6 ; C0 ; 

D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D ; D0 ; 

79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96 ; E0 ; 

97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07 ; F0 ; 

; 

; EBCDIC-to-ASCII table 

;000102030405060708090A0B0C0D0E0F 

; 

00 01 02 03 1A 09 1A 7F 1A 1A 1A 0B 0C 0D 0E 0F ; 00 ; 

10 11 12 13 1A 1A 08 1A 18 19 1A 1A 1C 1D 1E 1F ; 10 ; 

1A 1A 1C 1A 1A 0A 17 1B 1A 1A 1A 1A 1A 05 06 07 ; 20 ; 


1A 1A 16 1A 1A 1E 1A 04 1A 1A 1A 1A 14 15 1A 1A ; 30 ; 

20 A6 E1 80 EB 90 9F E2 AB 8B 9B 2E 3C 28 2B 7C ; 40 ; 

26 A9 AA 9C DB A5 99 E3 A8 9E 21 24 2A 29 3B 5E ; 50 ; 

2D 2F DF DC 9A DD DE 98 9D AC BA 2C 25 5F 3E 3F ; 60 ; 

D7 88 94 B0 B1 B2 FC D6 FB 60 3A 23 40 27 3D 22 ; 70 ; 

F8 61 62 63 64 65 66 67 68 69 96 A4 F3 AF AE C5 ; 80 ; 

8C 6A 6B 6C 6D 6E 6F 70 71 72 97 87 CE 93 F1 FE ; 90 ; 

C8 7E 73 74 75 76 77 78 79 7A EF C0 DA 5B F2 F9 ; A0 ; 

B5 B6 FD B7 B8 B9 E6 BB BC BD 8D D9 BF 5D D8 C4 ; B0 ; 

7B 41 42 43 44 45 46 47 48 49 CB CA BE E8 EC ED ; C0 ; 

7D 4A 4B 4C 4D 4E 4F 50 51 52 A1 AD F5 F4 A3 8F ; D0 ; 

5C E7 53 54 55 56 57 58 59 5A A0 85 8E E9 E4 D1 ; E0 ; 

30 31 32 33 34 35 36 37 38 39 B3 F7 F0 FA A7 FF ; F0 ; 

Syntax Rules for SBCS Translation Tables 

v 

v 

Blanks are used only as delimiters for readability purposes. 

Comments may be included, either on a separate line or at the end of a line. 

Comments must start with a semicolon (;). 

Customizing DBCS Translation Tables 


Each DBCS translation table file contains more than one translation table. 

TCPHGLAT and TCPHGBIN, for example, contain EBCDIC to ASCII and ASCII to 

EBCDIC translation tables for both the KSC 5601 and Hangeul PC code pages. 

The standard DBCS binary tables are used by the FTP server, SMTP server, and 

FTP client programs. 

The figures on the following pages show examples of the standard source for the 

Kanji, Hangeul, and Traditional Chinese DBCS translation tables. 

These source files contain two column pairs for each code page. The first column 

pair specifies double-byte EBCDIC to ASCII code point mappings for the indicated 

code page. The second column pair specifies double-byte ASCII to EBCDIC code 

point mappings for the indicated code page. 

Existing code point mappings may be changed by simply overwriting the existing 

hexadecimal code. New code point mappings may be specified by adding a new 

column pair with two double-byte hexadecimal codes. Code point mappings that 

are not specified, and are within the valid range for the code page, default to the 

“undefined” character, X'FFFF'. 

The source file format allows EBCDIC to ASCII and ASCII to EBCDIC mappings to 

be specified separately. When adding or changing a code point mapping, care 

should be taken to modify both mappings for the code point. If, for example, a 

new mapping is added for EBCDIC to ASCII only, the ASCII to EBCDIC mapping 

for that code point will be the “undefined” character. 

Any new code point mappings added outside the valid range for the 

corresponding code page will not be used by the programs that load the binary 

table. 

DBCS Translation Table 

The DBCS translation tables also contain SBCS code point mappings. These are 

used for mixed-mode DBCS strings, containing both SBCS and DBCS characters. 

Shift-out (X'0E') and shift-in (X'0F') characters are used on the EBCDIC host to 

denote the beginning and end of DBCS characters within a mixed-mode string. 



The DBCS source files must contain exactly 256 SBCS code point mappings, 

situated at the end of the table. These may be modified to contain the required 

hexadecimal value. 

Syntax Rules for DBCS Translation Tables 

v 

v 

v 

v 

Comments may be included, either on a separate line or at the end of a line. 

Comments must start with a semicolon (;). 

Code point mappings in the file are position dependent. The first non-comment 

line for the DBCS and SBCS tables in the file will be used to establish the 

column position of the code point mappings, and must contain a conversion pair 

for each code page. Any conversion pairs on following lines must use the same 

column positions. 

It is permissible to leave blanks for code point mappings after the first line in 

the DBCS and SBCS areas. For example, if a line contains only one conversion 

pair, the column position will be used to determine which code page it refers to. 

The first column of each code page column pair, the “code index”, must be in 

ascending numerical order. Any gaps in the ascending order will be marked as 

“undefined” in the binary table created by CONVXLAT. 

Sample DBCS Translation Tables 

The following examples are from the STANDARD DBCS translation table source 

files. Because these files are very large, only excerpts from the tables are shown. 

Ellipses (...) are used to indicate that information has been deleted. 


Japanese Kanji DBCS Translation Tables 

; 

; STANDARD TCPKJLAT - Japanese translation tables. 

; 

; ETA = Ebcdic to Ascii Conversion (Host - PC) 

; ATE = Ascii to Ebcdic Conversion (PC - Host) 

; 

; Use CONVXLAT to generate STANDARD TCPKJBIN 

; from this source file. 

; 

;DBCS Area - SJISETA,SJISATE 

; - JDECETA,JDECATE not used for STANDARD TCPKJBIN generation. 

; 

;SJISETA SJISATE JIS78ETA JIS78ATE JIS83ETA JIS83ATE ... 

; 

4040 8140 8140 4040 4040 2121 2121 4040 4040 2121 2121 4040 ... 

4141 83BF 8141 4344 4141 2641 2122 4344 4141 2641 2122 4344 ... 

4142 83C0 8142 4341 4142 2642 2123 4341 4142 2642 2123 4341 ... 

4143 83C1 8143 426B 4143 2643 2124 426B 4143 2643 2124 426B ... 

4144 83C2 8144 424B 4144 2644 2125 424B 4144 2644 2125 424B ... 

4145 83C3 8145 4345 4145 2645 2126 4345 4145 2645 2126 4345 ... 

4146 83C4 8146 427A 4146 2646 2127 427A 4146 2646 2127 427A ... 

4147 83C5 8147 425E 4147 2647 2128 425E 4147 2647 2128 425E ... 

4148 83C6 8148 426F 4148 2648 2129 426F 4148 2648 2129 426F ... 

4149 83C7 8149 425A 4149 2649 212A 425A 4149 2649 212A 425A ... 

. 

; 

; SBCS Area 

; 

;---------TCPKJBIN generation (no codefiles)--------------| |-------------- 

;SJISETA ATE JIS78ETA ATE JIS83ETA ATE SJEUCETA ATE J7KETA J7KATE 

; 

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .. 

01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 .. 

02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 ..


03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 .. 

04 1A 04 37 04 1A 04 37 04 1A 04 37 04 1A 04 37 04 1A 04 37 .. 

05 09 05 2D 05 09 05 2D 05 09 05 2D 05 09 05 2D 05 09 05 2D .. 

06 1A 06 2E 06 1A 06 2E 06 1A 06 2E 06 1A 06 2E 06 1A 06 2E .. 

07 7F 07 2F 07 7F 07 2F 07 7F 07 2F 07 7F 07 2F 07 7F 07 2F .. 

08 1A 08 16 08 1A 08 16 08 1A 08 16 08 1A 08 16 08 1A 08 16 .. 

09 1A 09 05 09 1A 09 05 09 1A 09 05 09 1A 09 05 09 1A 09 05 .. 

. 

Hangeul DBCS Translation Tables 

; 

; STANDARD TCPHGLAT - Korean translation tables. 

; 



; 

;use CONVXLAT to generate STANDARD TCPHGBIN 


; 

; DBCS Area 

; 

; Code Page ID - 951 Code Page ID - 926 

; KSCETA KSCATE HANETA HANATE 

; 

4040 A1A1 8FA1 D541 4040 8140 8140 4040 

4141 A1A2 8FA2 D542 4141 8141 8141 4141 

4142 A1A3 8FA3 D543 4142 8142 8142 4142 

4143 A1A4 8FA4 D544 4143 8143 8143 4143 

4144 A1A5 8FA5 D545 4144 8144 8144 4144 

4145 A1A6 8FA6 D546 4145 8145 8145 4145 

4146 A1A7 8FA7 D547 4146 8146 8146 4146 

4147 A1A8 8FA8 D548 4147 8147 8147 4147 

4148 A1A9 8FA9 D549 4148 8148 8148 4148 

. 

4149 A1AA 8FAA D54A 4149 8149 8149 4149 

; 

; SBCS Area 

; 

;Code Page ID 1088 Code Page ID 891 

;SKSCETA SKSCATE SHANETA SHANATE 

; 

00 00 00 00 00 00 00 00 

01 01 01 01 01 01 01 01 

02 02 02 02 02 02 02 02 

03 03 03 03 03 03 03 03 

04 FF 04 37 04 FF 04 37 

05 09 05 2D 05 09 05 2D 

06 FF 06 2E 06 FF 06 2E 

07 1C 07 2F 07 1C 07 2F 

08 FF 08 16 08 FF 08 16 

09 FF 09 05 09 FF 09 05 

. 

Traditional Chinese DBCS Translation Tables 

; 

; STANDARD TCPCHLAT - Traditional Chinese translation tables. 

; 



; 

; Use CONVXLAT to generate STANDARD TCPCHBIN 


; 

; DBCS Area 



; 

; Code Page ID 927 

; TCHETA TCHATE 

; 

4040 8140 8140 4040 

4141 83BF 8141 4344 

4142 83C0 8142 4341 

4143 83C1 8143 426B 

4144 83C2 8144 424B 

4145 83C3 8145 4345 

4146 83C4 8146 427A 

4147 83C5 8147 425E 

4148 83C6 8148 426F 

4149 83C7 8149 425A 

. 

; 

; SBCS Area 

; 

; STCHETA STCHATE 

; 

00 00 00 00 

01 01 01 01 

02 02 02 02 

03 03 03 03 

04 cf 04 37 

05 09 05 2d 

06 d3 06 2e 

07 7f 07 2f 

08 d4 08 16 

09 d5 09 05 

. 

Converting Translation Tables to Binary 

The CONVXLAT command converts a translation table source file to a binary file 

that usable by TCP/IP client and server programs. CONVXLAT may be used to 

convert both SBCS and DBCS source file. 

The CONVXLAT Command 

The syntax of the CONVXLAT command is: 

►► 

CONVXLAT 

input_filename 

STANDARD 

output_filename ( KANJI 

HANGEUL 

TCHINESE 

►◄ 

The parameters of the CONVXLAT command are: 

Parameter Description 

input_filename Specifies the file name of the source file to be converted. The 

source file must have a file type of TCPXLATE for SBCS tables, or 

a file type of TCPKJLAT, TCPHGLAT, or TCPCHLAT for DBCS 

tables. The first file with the required file name and file type in the 

standard minidisk search order is used. 

output_filename Specifies the destination file name created by the conversion. If this 

parameter is not specified, it defaults to the name STANDARD. 



KANJI 

HANGEUL 

TCHINESE 

The destination file type will be TCPXLBIN for SBCS tables, or 

TCPKJBIN, TCPHGBIN, or TCPCHBIN for DBCS tables. The 

destination file mode is A, which must be accessed in write mode. 

Specifies that the table being converted is the Kanji DBCS/SBCS 

translation table. The file type of the source file must be 

TCPKJLAT. The file type of the destination file will be TCPKJBIN. 

Specifies that the table being converted is the Hangeul DBCS/SBCS 

translation table. The file type of the source file must be 

TCPHGLAT. The file type of the destination file will be 

TCPHGBIN. 

Specifies that the table being converted is the Traditional Chinese 

DBCS/SBCS translation table. The file type of the source file must 

be TCPCHLAT. The file type of the destination file will be 

TCPCHBIN. 

If no optional parameters are specified, then input_filename is assumed to contain 

an SBCS translation table. 



Appendix A. Specifying Files and Data Sets 

This appendix describes the file naming formats for the AIX, OS/390, DOS, OS/2 

and Windows operating systems, as well as for the AS/400 operating system. 

Examples of each format are provided to show how the files appear to a TCP/IP 

user who is logged on to the different operating systems. 

AIX Files 

For the Advanced Interactive Executive (AIX) operating system, data is stored in 

files. Related files are stored in a directory. 

The following is the format of an AIX file name. 

►► /directory_name/file_name ►◄ 

Parameter 

directory_name 

file_name 

Description 

Specifies a directory name. Directories contain the names of files, 

other directories, or both. 

Specifies a file name. It can be up to 14 characters long. 

The complete name of an AIX file contains the directory name and the file name. 

The following is an example of an AIX file. 

/mailfiles/cooks 

Where: 

mailfiles 

cooks 

Is the directory name. 

Is the file name. 

In AIX, you specify the first slash (/) only when you begin at the root directory. If 

you are specifying a file in the current directory, enter only the file name. For 

example, if you are in the current directory mailfiles and you want to access the 

cooks file, specify: 

cooks 

The directory name and file name can each be up to 14 characters. The AIX 

operating system distinguishes between uppercase and lowercase letters in file 

names. 

A directory name and file name should not include characters, such as backslash 

(\), ampersand (&), and period (.), which have a special meaning to the AIX 

operating system shell. 

For more information about AIX files, see AIX System User’s Guide. 


Specifying Files and Data Sets 

OS/390 Data Sets 

The two most common data set types used for storing user files on an OS/390 

operating system are sequential data sets and partitioned data sets. 

Sequential Data Sets 

A sequential data set is a single file that can be allocated with any record length 

specified. The naming requirements for a sequential data set on an OS/390 host are 

minimal, and most of the requirements apply to any data set name under OS/390. 

The naming requirements for a sequential data set are: 

v No part of the name can start with a numeric. 

v No part of the name can be more than eight characters in length. 

v Each part of the name is separated by a period. 

v If single quotation marks are not used when specifying the data set name, the 

OS/390 system appends the logon user ID as the first part of the name. 

A sequential data set name can have a minimum of two and a maximum of 44 

characters. 

The following examples show the naming conventions for sequential data sets on 

an OS/390 host. 

To access the sequential data set KC00852.NAMES, the user KC00852 enters one of the 

following: 

’KC00852.NAMES’ 

or 

NAMES 

Either of these formats is acceptable to access a sequential data set. 

Partitioned Data Sets 

A partitioned data set (PDS) is a group of files contained in a library. The 

individual files that make up a PDS are called members. You can access an entire 

PDS or any individual member of a PDS. 

The following restrictions apply to the naming conventions that are used with a 

partitioned data set: 

v No part of the name can start with a numeric. 

v No part of the name can be more than eight characters in length. 

v Each part of the name is separated by a period. 

v 

If single quotation marks are not used when specifying the PDS name, the 

OS/390 system appends the logon user ID as the first part of the name. 

The difference between a sequential and partitioned data set specification is that 

the partitioned data set user accesses the directory of members in the PDS, and the 

sequential data set user accesses an individual file. 

The following examples show the naming conventions for partitioned data sets on 

an OS/390 host. 

To access the partitioned data set KC00852.PDS.NAMES, the user KC00852 enters one 

of the following: 



’KC00852.PDS.NAMES’ 

or 

PDS.NAMES 

Either of these formats is acceptable to access a partitioned data set. 

To access an individual file in a PDS, the member name is entered in parentheses. 

To access the member PROPER in the PDS KC00852.PDS.NAMES, the user KC00852 

enters one of the following: 

’KC00852.NAMES(PROPER)’ 

or 

NAMES(PROPER) 

Either of these formats is acceptable to access members in a partitioned data set. 

DOS, OS/2, and Windows 98 Files 

DOS, OS/2, and Windows 98 files are stored on high-capacity storage device, 

usually fixed disks or to a lesser extent, a diskette. Files, the smallest unit of 

organization on a hard drive are organized in directories and branching 

subdirectories. A storage device is identified by a drive letter. 

The complete name of a DOS, OS/2, or Windows 98 file contains the storage 

device identifier, directory name, file name, and extension. The following is an 

example of a complete name for a DOS, OS/2, or Windows file: 

C:\WP\MAIL.LST 

In this example, the storage device identifier is C: and the directory name is WP, 

which could be a group of word processing files. The file name is MAIL, and the file 

extension is .LST. 

In DOS, OS/2, and Windows 98, the device identifier is a drive letter that is 

assigned by the file system, followed by a colon. The drive letter, such as A, B, or 

C, can represent either a physical device or a logical device. If a device identifier is 

not specified, the default is the device from which the system was booted or the 

current drive. 

You assign the directory name, preceded by a backslash. A directory name is 

optional. If a directory name is not specified, the system searches the current 

directory. 

Normally, you would also assign a file name. In DOS, file names can be eight 

characters long and have a three character extension. The file extension is a 

character string that consists of one to three characters, preceded by a period. A file 

extension is optional. 

With OS/2, you will generally use one of two file systems: File Allocation Table or 

FAT, or else the High Performance File System, known as HPFS. You can have both 

these file systems active at the same time. For example, you can have the FAT file 

system on one hard disk, and the HPFS active on another. 

The FAT format uses the familiar but limited naming convention, where a file or 

directory name can have up to eight letters, followed by a period and then the 

three-letter extension. HPFS provides support for long file names, up to 254 

characters, including path information. including path information. 

Appendix A. Specifying Files and Data Sets 291


AS/400 Operating System 

Windows 98 supports 256-character filenames as well as upper and lowercase 

characters. 

If you use an invalid file name, the system gives you an error message. 

The following are examples of different DOS OS/2, and Windows 98 file names 

that are valid. 

TEMP 

START.BAT 

A:COMMAND.COM 

C:SPF\SPFPC.HLP 

C:REPORTS\ThisISALongFilename.TXT (Windows 98) 

For the AS/400 operating system, data is stored in files. 

The following is the format of an AS/400 file. 

►► library/file.member ►◄ 

Parameter 

library 

file.member 

Description 

Is a library name. Libraries contain the names of programs, files, 

and commands. 

Is the file name. 

In AS/400, files can have one or more members. Each file can consist of data 

records, source programs, or database definitions. 

The FTP subcommand PUT is used to copy a local file member into a file at the 

remote host. The following is an example: 

PUT TCPLIBA/FILEA.MBRA TCPLIBB/FILEA.MBRA 

In this example, the PUT subcommand copies the file member MBRA in file FILEA 

into library TCPLIBA at the local host to MBRA in FILEA in library TCPLIBB at the 

remote host. If the member already exists at the remote host, it is overwritten. 


Appendix B. Using the NETRC DATA File 

This appendix describes the NETRC DATA File and how it is used by: 

v FTP Client 

v REXEC 

v OPENVM MOUNT CMS Command 

NETRC-capable commands use fully-qualified host domain names when 

attempting to match a command specified host name with those in the NETRC 

DATA file. Thus, you may specify fully-qualified host domain names on the 

command in the NETRC DATA file. Otherwise, the command will construct a 

fully-qualified host domain name for you, by concatenating the host name you 

have provided with the domain origin specified on the DOMAINORIGIN 

statement of the TCPIP DATA configuration file. 

You maintain the NETRC DATA file on your own minidisk or directory. The first 

NETRC DATA file found in the CMS search order will be used when the command 

is invoked. Since the NETRC DATA file contains logon passwords, ensure you 

restrict access to this file using security measures appropriate for your 

environment. Do not keep this file on a disk or directory to which other persons 

have access. A file mode number of 0 will not adequately protect this file. 

The format for entries in the NETRC DATA file follows: 

machine foreign_host login user_id password password 

Several sample NETRC DATA file entries follow: 

machine oddjob login anonymou password anonymou 

machine 123.45.67.89 login guest password guest 

machine oddjob.specific.domain.com login cibulama password onion1 

machine filmore.east.com login bluespwr password albertk 

machine rocketman login gordon password flash 

Using The NETRC DATA File with FTP 

The NETRC DATA file provides an alternative to responding to FTP prompts for 

logon information when you connect to a foreign host. When a user name and 

password for a specific host are defined in this file, FTP will use those values 

instead of prompting for this information. 

When the FTP command, or its OPEN subcommand is issued, FTP searches the 

NETRC DATA file for the first valid match on the specified host. If found, that 

host’s user name and password are used when a connection to that host is 

attempted. If no match is found for the host in question, you are prompted for a 

user name and password, unless the NOPROMPT option has been specified. 

Using The NETRC DATA File with REXEC 

The NETRC DATA file provides an alternative for specifying the REXEC user_id 

and password parameters. If these parameters are defined within this file for a 

specific host, they can be omitted when you issue a REXEC command against that 

host. 


NETRC DATA File 

REXEC searches the NETRC DATA file for the first valid match on the specified 

host. If found, that host's user name and password are used when a connection to 

that host is attempted. If no match is found for the host in question, you are 

prompted for a user name and password, unless the -k option has been specified. 

The following example shows a REXEC command for which the required login 

userid and password values have been supplied by a NETRC DATA file entry. In 

this example the DIR C: command has been issued against the OS/2 host 

FILMORE: 

rexec filmore dir c: 

The volume label in drive C is OS2. 

The Volume Serial Number is A6B0 11-30-93 9:56a 0 . 

11-30-93 9:56a 0 .. 

1-17-94 4:36p 374 0 AUTOEXEC.BAT 

1-05-94 4:15p 0 BITMAPS 

11-30-93 11:37a 0 CMLIB 

4-20-94 2:18p 2968 35 CONFIG.LAP 

5-01-95 4:31p 3281 0 CONFIG.SYS 

4-06-95 12:01p 3333 0 CONFIG.TCP 

11-30-93 11:00a 1567 DESKTOP 

6-08-94 11:18a 0 FTPTEMP 

11-30-93 11:21a 1607 IBMCOM 

5-01-95 8:22a 1016 0 IBMLVL.INI 

4-20-94 1:22p 0 LANLK 

6-08-94 1:01p 0 NFSTEST 

11-30-93 9:56a 4049 OS2 

11-30-93 9:56a 0 PSFONTS 

5-14-93 10:02p 40415 0 README 

11-30-93 11:00a 0 SPOOL 

4-06-95 11:52a 80 0 STARTUP.BAK 

4-06-95 12:01p 80 0 STARTUP.CMD 

4-20-94 2:37p 0 TCPIP 

1-17-94 2:18p 329 UTILS 

22 file(s) 65759 bytes used 

9502208 bytes free 

Ready; 

RUNNING 

GD3VM0 

Using the NETRC DATA File with the OPEN MOUNT CMS Command 

The NETRC DATA file provides an alternative for specifying the username and 

password parameters on the OPENVM MOUNT command. OPENVM MOUNT is a 

CMS commnd, documented in the z/VM: OpenExtensions Command Reference that 

provides NFS client support for z/VM. This allows you to NFS-mount remote file 

systems in your Byte File System (BFS) hierarchy. 

If the username and password are defined within the NETRC DATA file for a specific 

foreign host, you can omit them from an OPENVM MOUNT command issued for 

that host. 


Appendix C. Mapping Values for the APL2 Character Set 

GDDMXD/VM has default mapping values for the APL2 character set. However, if 

the GDXAPLCS MAP file exists, the default mapping values are overridden. 

Each entry in the GDXAPLCS MAP file (alternative character set) contains the 

mapping for a particular physical key that corresponds to three characters. The 

characters correspond to the physical key by: 

v Pressing the key alone 

v Pressing the key and the Shift key simultaneously 

v Pressing the key and the Alt key simultaneously 

GDXAPLCS MAP file entries must contain the following seven single byte 

hexadecimal values entered as EBCDIC characters. 

v Value 1 is the hexadecimal keycode for the physical key. 

v 

v 

Values 2, 4, and 6 identify whether the character is in the primary or alternative 

character set for the emulated 3179G. If the character is in the primary set, the 

value is 0; if the character is in the alternative set, the value is 8. 

Values 3, 5, and 7 specify the EBCDIC code of the character in the character set. 

The combination of values 2 and 3 define the bytes that describe the character 

when the key corresponding to the keycode is pressed alone. 


when the key corresponding to the keycode and the Shift key are pressed 

simultaneously. 


when the key corresponding to the keycode and the Alt key are pressed 

simultaneously. 

Table 20 lists the mapping values for the APL2 character set. 

Table 20. Mapping Values for the APL2 Character Set 

Character Name 

Character Set EBCDIC Default Keycode 

Value Value 

Quad Jot 8 73 9 + Shift 

Quad Slope 8 CE 9 + Alt 

1 0 F1 A 

Diaeresis 8 72 A + Shift 

Down Tack Up Tack 8 DA A + Alt 

2 0 F2 B 

Overbar 8 A0 B + Shift 

Del Tilde 8 FB B + Alt 

3 0 F3 C 

Mapping APL2 Character Set Values 

Table 20. Mapping Values for the APL2 Character Set (continued) 


Character Set 

Value 

EBCDIC 

Value 

Default Keycode 

Not Greater 8 8C D + Shift 

Delta Stile 8 DD D + Alt 

5 0 F5 E 

= 0 7E E + Shift 

Circle Stile 8 CD E + Alt 

6 0 F6 F 

Not Less 8 AE F + Shift 

Circle Slope 8 CF F + Alt 

7 0 F7 10 

>; 0 6E 10 + Shift 

Circle Bar 8 ED 10 + Alt 

8 0 F8 11 

Not Equal 8 BE 11 + Shift 

Circle Star 8 FD 11 + Alt 

9 0 F9 12 

Down Caret 8 78 12 + Shift 

Down Caret Tilde 8 CB 12 + Alt 

0 0 F0 13 

Up Caret 8 71 13 + Shift 

Up Caret Tilde 8 CA 13 + Alt 

+ 0 4E 14 

- 0 60 14 + Shift 

! 8 DB 14 + Alt 

Times 8 B6 15 

Divide 8 B8 15 + Shift 

Quad Divide 8 EE 15 + Alt 

Q 0 D8 19 

? 0 6F 19 + Shift 

Q Underbar 8 58 19 + Alt 

W 0 E6 1A 

Omega 8 B4 1A + Shift 

W Underbar 8 66 1A + Alt 

E 0 C5 1B 

Epsilon 8 B1 1B + Shift 

E Underbar 8 45 1B + Alt 

R 0 D9 1C 

Rho 8 B3 1C + Shift 

R Underbar 8 59 1C + Alt 

T 0 E3 1D 




Character Set 

Value 


EBCDIC 

Value 


Tilde 8 80 1D + Shift 

T Underbar 8 63 1D + Alt 

Y 0 E8 1E 

Up Arrow 8 8A 1E + Shift 

Y Underbar 8 68 1E + Alt 

U 0 E4 1F 

Down Arrow 8 8B 1F + Shift 

U Underbar 8 64 1F + Alt 

I 0 C9 20 

Iota 8 B2 20 + Shift 

I Underbar 8 49 20 + Alt 

O 0 D6 21 

Circle 8 9D 21 + Shift 

O Underbar 8 56 21 + Alt 

P 0 D7 22 

Star 0 5C 22 + Shift 

P Underbar 8 57 22 + Alt 

Left Arrow 8 9F 23 

Right Arrow 8 8F 23 + Shift 

Quad Quote 8 DE 23 + Alt 

Left Brk Right Brk 8 CC 24 

Iota Underbar 8 74 24 + Shift 

Delta Underbar 8 FC 24 + Alt 

Equal Underbar 8 E1 25 

Epsilon Underbar 8 E1 25 + Shift 

Diaeresis Dot 8 75 25 + Alt 

A 0 C1 27 

Alpha 8 B0 27 + Shift 

A Underbar 8 41 27 + Alt 

S 0 E2 28 

Up Stile 8 8D 28 + Shift 

S Underbar 8 62 28 + Alt 

D 0 C4 29 

Down Stile 8 8E 29 + Shift 

D Underbar 8 44 29 + Alt 

F 0 C6 2A 

Underbar 0 6D 2A + Shift 

F Underbar 8 46 2A + Alt 

G 0 C7 2B 

Appendix C. Mapping Values for the APL2 Character Set 297




Character Set 

Value 

EBCDIC 

Value 


Del 8 BA 2B + Shift 

G Underbar 8 47 2B + Alt 

H 0 C8 2C 

Delta 8 BB 2C + Shift 

H Underbar 8 48 2C + Alt 

J 0 D1 2D 

Jot 8 AF 2D + Shift 

J Underbar 8 51 2D + Alt 

K 0 D2 2E 

Quote 0 7D 2E + Shift 

K Underbar 8 52 2E + Alt 

L 0 D3 2F 

Quad 8 90 2F + Shift 

L Underbar 8 53 2F + Alt 

Left Bracket 8 AD 30 

( 0 4D 30 + Shift 

Down Tack Jot 8 FE 30 + Alt 

Right Bracket 8 BD 31 

) 0 5D 31 + Shift 

Up Tack Jot 8 EF 31 + Alt 

Z 0 E9 36 

Left Shoe 8 9B 36 + Shift 

Z Underbar 8 69 36 + Alt 

X 0 E7 37 

Right Shoe 8 9A 37 + Shift 

X Underbar 8 67 37 + Alt 

C 0 C3 38 

Up Shoe 8 AA 38 + Shift 

C Underbar 8 43 38 + Alt 

V 0 E5 39 

Down Shoe 8 AB 39 + Shift 

V Underbar 8 65 39 + Alt 

B 0 C2 3A 

Down Tack 8 AC 3A + Shift 

B Underbar 8 42 3A + Alt 

N 0 D5 3B 

Up Tack 8 BC 3B + Shift 

N Underbar 8 55 3B + Alt 

M 0 D4 3C 




Character Set 

Value 


EBCDIC 

Value 


Stile 0 4F 3C + Shift 

M Underbar 8 54 3C + Alt 

, 0 6B 3D 

; 0 5E 3D + Shift 

Up Shoe Jot 8 DF 3D + Alt 

period 0 4B 3E 

: 0 7A 3E + Shift 

Slope Bar 8 EB 3E + Alt 

/ 0 61 3F 

\ 0 E0 3F + Shift 

Slash Bar 8 EA 3F + Alt 

Space 0 40 45 

Appendix C. Mapping Values for the APL2 Character Set 299



Appendix D. Using DBCS with FTP and Mail 

Using DBCS with FTP 

This appendix describes how to use the DBCS facilities provided by FTP and 

SMTP. 

This section describes how to use FTP with DBCS support to exchange DBCS files 

between hosts supporting DBCS file transfer. 

DBCS Translation Tables 

The VM TCP/IP FTP server and client programs access files containing data that is 

usually in EBCDIC format. To transfer these files to or from an ASCII based host 

requires the use of a translation table. 

The FTP server and client may be configured to load a number of DBCS translation 

tables. These are used during file transfers to convert EBCDIC DBCS characters to 

and from ASCII. The LOADDBCSTABLE statement in FTP DATA is used by both 

the FTP server and client to determine which DBCS translate table files should be 

loaded at initialization time. 

Control and Data Connection Translation 

The transfer of a DBCS file by FTP actually uses three different translation tables; 

two SBCS and one DBCS. The control connection that is used to transfer FTP 

commands and replies, uses the SBCS translation table that is normally loaded 

from the STANDARD TCPXLBIN file. The data connection that is used to transfer 

the file, uses both an SBCS and DBCS translation table that are normally loaded 

from either the STANDARD TCPKJBIN, STANDARD TCPHGBIN, or STANDARD 

TCPCHBIN file. 

Both SBCS and DBCS translation tables are required for the transfer of a DBCS file, 

as the file may contain mixed-mode strings. A mixed mode string contains both 

SBCS and DBCS data, delimited by shift-out and shift-in characters. 

Although DBCS support for FTP does not include direct support for Katakana, it is 

possible to separately configure the SBCS table used for the control connection 

(user interface), and the data connection. The SBCS translation table for SJISKANJI, 

for example, could be altered to a Katakana based code page. 

DBCS Subcommands 

DBCS files are transferred using the standard FTP subcommands “put” and “get”. 

Before the transfer commences, however, the current transfer type for the session 

must be set to the required DBCS type. To set the transfer type to DBCS for an FTP 

session, requires the sending of a TYPE command from the client to the server in 

the correct format. The VM TCP/IP FTP client provides three ways of generating 

TYPE commands: 

1. TYPE subcommand 

2. TYPE subcommand aliases 

3. QUOTE subcommand 


Using DBCS with FTP and Mail 

TYPE Subcommand 

The TYPE command sets the transfer type for the client and server at the same 

time with one command. The following DBCS TYPE subcommands are supported 

by the VM TCP/IP FTP server and client. 

►► TYPE B 

B 1 

B 2 

B 3 

B 3 A 

B 3 R 

B 4 

B 4 A 

B 4 R 

B 5 

B 6 

B 7 

F 

F 1 

►◄ 

Parameter 

TYPE B 

TYPE B 1 

TYPE B 2 

TYPE B 3 

TYPEB3A 

TYPEB3R 

TYPE B 4 

TYPEB4A 

TYPEB4R 

TYPE B 5 

TYPE B 6 

Description 

Change current transfer type to Shift JIS Kanji 

Change current transfer type to Shift JIS Kanji 

Change current transfer type to Extended Unix Code Kanji 

Change current transfer type to JIS 1983 Kanji using ASCII shift-in 

escape sequence ESC(B 



Change current transfer type to JIS 1983 Kanji using JISROMAN 

shift-in escape sequence ESC(J 





Change current transfer type to JIS 1978 Kanji using JISROMAN 

shift-in escape sequence ESC(J 

Change current transfer type to Hangeul 

Change current transfer type to Korean Standard Code KSC-5601, 

1989 version 

TYPE B 7 Change current transfer type to Traditional Chinese (5550) 

TYPE F Change current transfer type to IBM (EBCDIC) Kanji 

TYPE F 1 Change current transfer type to IBM (EBCDIC) Kanji 

TYPE Subcommand Aliases 

Each DBCS TYPE subcommand may be specified using a single word alias. Each 

TYPE subcommand alias generates the same TYPE command to the client and 


Table 21. FTP TYPE commands 


server as the corresponding TYPE subcommand. The TYPE subcommand aliases 

may be abbreviated using the minimum unambiguous client subcommand 

abbreviations. 

The TYPE subcommand aliases also have an optional parameter (NOTYPE, that 

specifies that the DBCS type should only be set locally. This is used when 

connecting to an FTP server that does not support the TYPE command generated 

by the TYPE subcommand alias. For example, SJISKANJI (NOTYPE causes the FTP 

client to change its transfer type to Shift JIS Kanji, without changing the transfer 

type in the FTP server. The server in this example should be set to the ASCII 

transfer type before the (NOTYPE subcommand is issued. Table 21 indicates the 

actual server command that would be generated for each client subcommand alias: 

Client Subcommand Server Command Description 

SJISKANJI TYPE B 1 Shift JIS Kanji transfer type 

EUCKANJI TYPE B 2 Extended Unix Code Kanji transfer type 

JIS83KJ TYPE B 3 JIS 1983 Kanji using ASCII shift-in transfer type 

JIS83KJ (ASCII TYPE B 3 A JIS 1983 Kanji using ASCII shift-in transfer type 

JIS83KJ (JISROMAN TYPE B3R JIS1983 Kanji using JISROMAN shift-in transfer 

type 

JIS78KJ TYPE B 4 JIS 1978 Kanji using ASCII shift-in transfer type 

JIS78KJ (ASCII TYPE B 4 A JIS 1978 Kanji using ASCII shift-in transfer type 

JIS78KJ (JISROMAN TYPE B4R JIS1978 Kanji using JISROMAN shift-in transfer 

type 

HANGEUL TYPE B 5 Hangeul transfer type 

KSC5601 TYPE B 6 Korean Standard Code KSC-5601 transfer type 

TCHINESE TYPE B 7 Traditional Chinese (5550) transfer type 

IBMKANJI TYPE F 1 IBM (EBCDIC) Kanji transfer type 

QUOTE Subcommand 

The QUOTE subcommand may be used to send an uninterpreted string of data to 

the server. The QUOTE subcommand may be used to generate any of the DBCS 

TYPE commands supported by the server. The QUOTE subcommand would be 

used when the FTP server supports the DBCS TYPE command, but the FTP client 

does not. For example, QUOTE TYPE B 1 causes the FTP server to change its 

transfer type to Shift JIS Kanji, without changing the transfer type in the FTP 

client. The client in this example should be set to the ASCII transfer type before the 

QUOTE subcommand is issued. 

The following examples show the screen display when setting the DBCS transfer 

type to JIS78KJ, shift-in JISROMAN, using a VM TCP/IP FTP client connected to a 

VM TCP/IP FTP server. All three methods of setting the DBCS transfer type are 

demonstrated. 

Appendix D. Using DBCS with FTP and Mail 303


User: 

System: 

System: 

System: 

User: 

System: 

System: 

System: 

User: 

System: 

User: 

System: 

System: 

System: 

jis78kj (jisroman 

>;>;>;TYPE b4r 

200 Representation type is KANJI JIS 1978 shift-in JISROMAN 

Command: 

type b4r 

>;>;>;TYPE b4r 


Command: 

jis78kj (jisroman notype 

Command: 

quote type b4r 

>;>;>;type b4r 


Command: 

Defining FTP with Kanji Support 

The following FTP subcommands can set the appropriate transfer type for the 

Kanji file transfer. The translation table STANDARD TCPKJBIN converts the 

transmitted data between Kanji and ASCII. This file is installed in the user visible 

minidisk from FTPSERVE user ID. The following are the FTP Kanji transfer type 

subcommands: 

Subcommand 

SJISKANJI 

EUCKANJI 

JIS83KJ 

JIS78KJ 

IBMKANJI 

Option 

(notype 

(notype 

(notype 

(notype 

(notype 

The (notype option is used for the standard FTP server that does not have Kanji 

support. FTP sets the data type for the client and server at the same time with one 

command. If Kanji support is only in the FTP user, the FTP server cannot accept 

Kanji data types with the TYPE subcommand. The Kanji subcommands with the 

(notype option should be used, without the TYPE subcommand. 

Using FTP with Kanji Support 

The FTP TYPE subcommand supports single byte transfer for ASCII and EBCDIC 

data transfer (TYPE A or TYPE E). Kanji data types allow you to transfer text files 

with a Kanji code set. TYPE B defines the data type of the Kanji code based on the 

ASCII code set. TYPE F defines the data type of the Kanji code based on the 

EBCDIC code set. 

The following are the Kanji code set types, based on ASCII (TYPE B) AND 

EBCDIC (TYPE F): 

Command Kanji Code Set 

TYPE B 1 Shift JIS 

TYPE B 2 Extended UNIX Code 

TYPE B JIS 1983 edition 

TYPE B 4 JIS 1978 edition 

TYPE F 1 IBM Kanji 

The number associated with the data type is the argument of the TYPE command. 

For example, if JIS 1983 edition code is used in the data transfer, issue the 

command TYPE B 3. If IBM code is used in the data transfer, issue the command 

TYPE F 1. 


Using DBCS with Mail 


If the FTP user does not support the Kanji extension, you should issue the FTP 

QUOTE subcommand to change the data type in the FTP Kanji server. For 

example, QUOTE TYPE B 1 causes the FTP server to change its data type to Shift 

JIS code without changing the data type in the FTP user. In this example, you must 

set the ASCII data type before you issue the QUOTE subcommand. 

This section describes how to use SMTP with DBCS support to exchange DBCS 

mail and messages between hosts supporting DBCS mail. 

SMTP Server DBCS Support 

Mail in EBCDIC DBCS Kanji, Hangeul, or Traditional Chinese, may be sent to a 

remote host via the CMS NOTE and SENDFILE commands, if the local SMTP 

server or agent is configured with the corresponding DBCS support. For more 

information on configuring DBCS support for the SMTP server, see TCP/IP 


SMTP Protocol for 8-bit characters 

The protocol specification for SMTP describes a transport service that provides an 

8-bit byte transmission channel, with each 7-bit character transmitted right-justified 

in an octet with the high-order bit cleared to zero. JIS Kanji DBCS may be 

transmitted using this protocol, as its code consists of two bytes with 7-bit ASCII 

and three bytes of escape sequences. JUNET, which is the Japanese academic and 

research network connecting various UNIX operating systems, provides network 

services using JIS Kanji code. Other DBCS types, such as Shift-JIS Kanji, require 

transmission using 8-bit characters. To allow transmission of these other types, the 

protocol has been extended in the VM SMTP server to accept 8-bit characters. 

To successfully distribute mail with 8-bit DBCS characters, requires that other 

SMTP servers on the same network support this extension to the SMTP protocol. 

The AIX SMTP server and the MVS version 3.1 SMTP server also support the 

transmission of 8-bit characters. 

Conversion of DBCS Mail 

The transmission of DBCS mail by SMTP actually uses three different translation 

tables; two SBCS and one DBCS. Mail headers are converted to ASCII using the 

SBCS translation table that is normally loaded from the STANDARD TCPXLBIN 

file. The body of the mail is converted using both the SBCS and DBCS translation 

tables that are normally loaded from either the STANDARD TCPKJBIN, 

STANDARD TCPHGBIN, or STANDARD TCPCHBIN file. 

Both SBCS and DBCS translation tables are required for the transmission of DBCS 

mail, as the mail may contain mixed-mode strings. A mixed mode string contains 

both SBCS and DBCS data, delimited by shift-out and shift-in characters. 

Although DBCS support for SMTP does not include direct support for Katakana, it 

is possible to separately configure the SBCS table used for mail headers, and that 

used for the body of the mail. If the SMTP server was configured with SJISKANJI, 

for example, then the SBCS translation table for SJISKANJI could be altered to a 

Katakana based code page. 

Appendix D. Using DBCS with FTP and Mail 305


DBCS conversion is only performed on outgoing and incoming mail to and from 

other hosts. Mail spooled to SMTP via NOTE or SENDFILE for the local host, is 

delivered directly, without any DBCS code conversion. 

Conversion of DBCS Files 

The transmission of DBCS files by UFT uses three different translation tables; two 

SBCS and on DBCS. UFT protocol statements are converted to ASCII using the 

SBCS translation table imbedded in the UFT client (which maps to the 

STANDARD table). The file data is converted using both the SBCS and DBCS 

translation tables that are normally loaded from the filename specified on the 

SENDFILE TRANSLATE option with a filetype of either TCPKJBIN, TCPHGBIN or 

TCPCHBIN. 


Appendix E. Management Information Base Objects 

This appendix describes the objects defined by the Management Information Base 

(MIB), the MIB-II, and the IBM 3172 enterprise-specific variables supported by VM. 

The following list contains the supported variables. 

v System 

v Interfaces 

v Address Translation 

v Internet Protocol (IP) 

v Internet Control Message Protocol (ICMP) 

v Transmission Control Protocol (TCP) 

v User Datagram Protocol (UDP) 

v IBM 3172 Enterprise-Specific 

For a complete list of the MIB and MIB-II variables, see RFC 1156 (MIB) and RFC 

1158 (MIB-II). 

The object types are defined using the following fields: 

Object A textual name, called the OBJECT DESCRIPTOR, for the object 

type, along with its corresponding OBJECT IDENTIFIER. 

Syntax The syntax for the object type, using ASN.1 notation. The syntax 

indicates that the following data is to be treated as a collection of 

objects that can be repeated. For example, the collection of objects 

can be row entries in a routing table with an unspecified number 

of rows. Therefore, these descriptors are not really MIB objects that 

can be manipulated, but only the objects within the sequence. 

Definition A description of the object type. Because this MIB is intended for 

use in multivendor environments, object types must have 

consistent meanings across all machines. 

Access One of read-only, read-write, write-only, or not-accessible. 

VM Support One of yes, no, or read-only. 

Structure and Identification of Management Information (SMI) 

Managed objects are accessed through a virtual information store, known as the 

Management Information Base (MIB). Objects in the MIB are defined using 

Abstract Syntax Notation One (ASN.1). 

Each object type has a name, a syntax, and an encoding description. The name is 

represented uniquely as an object identifier, which assigned by a systems 

administrater. 

The syntax for an object type defines the abstract data structure corresponding to 

that object type. For example, the structure of a given object type might be an 

integer or an octet string. RFC 1155 restricts the ASN.1 constructs that can be used. 

These restrictions are made solely for the sake of simplicity. 


MIB Objects 

The encoding of an object type describes how instances of that object type are 

represented using the object’s type syntax. RFC 1155 specifies the use of the basic 

encoding rules of ASN.1. 

Names 

Names are used to identify managed objects and they are hierarchical in nature. 

For example, each international standard has an object identifier assigned to it for 

the purpose of identification. In short, object identifiers are a means for identifying 

some object, regardless of the semantics associated with it. 

The root node itself is unlabeled, but has at least three nodes directly under it: one 

node is administered by the International Standards Organization (ISO), with label 

iso(1); another is administered by the International Telegraph and Telephone 

Consultative Committee (CCITT), with label ccitt(2); and the third is jointly 

administered by the ISO and the CCITT, joint-iso-ccitt(3). 

Under the iso(1) node, the ISO has designated one subtree for use by other 

(inter)national organizations, org(3). Under this node, one of the subtrees has been 

allocated to the US Department of Defense (DOD), dod(6), under which only one 

node has been assigned to the Internet community, and it is administered by the 

Internet Activities Board (IAB). Therefore, the Internet subtree of object identifiers 

starts with the prefix 1.3.6.1. 

The Management Subtree 

Under the IAB node, four subtrees have been defined, namely, directory(1), 

mgmt(2), experimental(3), and private(4). The administration of the mgmt(2) 

subtree was delegated by the IAB to the Internet Assigned Numbers Authority for 

the Internet. This subtree is used to identify objects that are defined in 

IAB-approved documents. So far, the prefix of the object identifiers is: 1.3.6.1.2. 

When RFCs, which define new versions of the Internet-standard MIB, are 

approved, they are assigned an object identifier for identifying the objects defined 

by that RFC. The Internet-standard MIB has been assigned management document 

number one. Therefore, its object identifier is: 

or 

{mgmt1} 

1.3.6.1.2.1 

The private(4) subtree is used to define enterprise-specific variables in the MIB, 

which means that you can add your own objects to the MIB. The prefix of these 

variables is: 1.3.6.1.4. 

Figure 18 illustrates the hierarchical ISO tree that has been adopted to identify 

managed objects. 


MIB Objects 

Object Identifier 

ISO 

(1) 

CCITT 

(2) 

Joint-ISO- 

CCITT (3) 

Other intnl 

organiz. (3) 

US Dept. Of 

Defense (6) 

IAB 

(1) 

Assumed by IAB 

RFC 1065 

directory 

(1) 

mgmt 

(2) 

Experimental 

(3) 

Private 

(4) 

MIB 

(1) 

Figure 18. The SMI Hierarchical Tree 

The SMI is not supposed to define objects in the MIB, but it does specify a format 

to be used by the RFCs that define these objects. An object type definition consists 

of the following fields. 

Field Name Description 

Object 

Syntax 

Definition 

Access 

Status 

Specifies a textual name, termed the object descriptor, for the object 

type, along with its corresponding object identifier 

Specifies the abstract syntax for the object type, such as integer, 

octet string, counter, timeticks, and so on 

Specifies a textual description of the semantics of the object type 

Specifies read-only, read-write, write-only or not-accessible 

Specifies mandatory, optional, or obsolete 

The following is an example of an object type definition: 

Object: 

sysDescr. 

Appendix E. Management Information Base Objects 309

MIB Objects 

MIB/Network Elements 

Syntax: 

Octet string. 

Definition: 

A textual description of the entity. This value should 

include the full name and version identification of the 

system’s hardware type, software operating system, and 

networking software. It is mandatory that this only 

contain printable ASCII characters. 

Access: 

read-only. 

Status: 

mandatory. 

For more information, see RFC 1155. 

The MIB defines the information that can be obtained from SNMP agents. The MIB 

defines objects, such as packet counts and routing tables that are relevant to a 

TCP/IP environment. The objects defined by the MIB are divided into groups, with 

each group representing a set of management data. 

Currently, the following groups have been defined: 

Group Name Description 

System Contains information about the entity, such as system hardware, 

software, and the version number. 

Interfaces Contains all the interfaces through which the nodes can send and 

receive IP datagrams. It also contains counters for packets sent and 

received and errors. 

Address translation 

Contains information for mapping a network address into a 

specific subnetwork or physical address. This group is deprecated, 

meaning that it still exists but will be deleted in the future. 


Contains information about the IP layer, such as the number of 

datagrams sent, received, and forwarded. It includes two tables: 

the IP address table contains the IP addressing information for the 

entity; the IP routing table contains one entry for each route 

presently known to it. 

ICMP Contains the ICMP input and output statistics. 

TCP 

Contains information about the TCP connections, such as the 

maximum number of connections the entity can support, the total 

number of retransmitted segments, the minimum and maximum 

time-out values, and so on. 

UDP Contains information about the UDP layer, such as counters for 

datagrams sent and received. 

EGP 

Contains information about EGP peers, such as the number of 

messages sent and received, error counters, and so on. 

Transmission Contains media-specific information. This group is not currently 

implemented. 


MIB Objects 

SNMP 

Contains information about the SNMP agent, such as the number 

of SNMP packets received, the number of SNMP requests with bad 

community names, and so on. 

The system group is the first group in the MIB. Therefore, it is identified as: 

or 

{mib1} 

1.3.6.1.2.1.1 

Each group has its own subtree. For example, the first variable in the system group 

is the system description (sysDescr), so that it can be represented as: 

or 

{ system 1 } 

1.3.6.1.2.1.1.1 

System Group 

Table 22. Implementation of the System Group 

To summarize the explanation, the following describes the composition of the 

ASN.1 object identifier for sysDescr. 

iso org dod internet mgmt mib system sysDescr 

1 3 6 1 2 1 1 1 

Table 22 lists the objects in the system group. The system objects identify the type 

of system with a text description and the vendor-assigned object-ID as an 

identification to the type of SNMP server. 

Object Syntax Definition Access 

sysDescr 

{ system 1 } 

sysObjectID 

{ system 2 } 

sysUpTime 

{ system 3 } 

DisplayString 

OBJECT IDENTIFIER 

TimeTicks 

A description of the entry. This value 

should include the full name and version 

identification of the system’s hardware 

type, software operating system, and 

networking software. This description 

must only contain printable ASCII 

characters. 

The vendor’s authorization identification 

of the network management subsystem 

contained in the entry. This value is 

allocated within the Structure for 

Management Information (SMI) 

enterprise’s subtree (1.3.6.1.4.1) and 

provides an easy and clear means for 

determining what kind of box is being 

managed. For example, if vendor Stones, 

Inc. was assigned the subtree 1.3.6.1.4.1.42, 

it could assign the identifier 

1.3.6.1.4.1.42.1.1 to the router Fred Router. 

The time (in hundredths of a second) 

since the network management portion of 

the system was last started. 

read-only 

read-only 

read-only 

1. All accesses of read-write indicate a read-only access for VM. 


MIB Objects 

Table 22. Implementation of the System Group (continued) 


sysContact 

{ system 4 } 

sysName 

{ system 5 } 

sysLocation 

{ system 6 } 

sysServices 

{ system 7 } 

DisplayString 

DisplayString 

DisplayString 

INTEGER 

The textual identification of the contact 

person for this managed node, together 

with information about how to contact 

this person. 

An administratively-assigned name for 

this managed node. By convention, this is 

the node’s fully-qualified domain name 

The physical location of this node (for 

example, telephone closet, 3rd floor) 

read-write 1 

read-write 1 

read-only 

A value that indicates the set of services read-only 

that this entity potentially offers. The 

value is a sum. This sum initially takes 

the value 0, then, for each layer L in the 

range 1 through 7 for which this node 

performs transactions, 2 raised to (L - 1) is 

added to the sum. For example, a node 

that performs only routing functions 

would have a value of 4 (2^(3-1)). In 

contrast, a node that is a host offering 

application services would have a value 

of 72 (2^(4-1) + 2^ (7-1)). Note that in the 

context of the internet suite of protocols, 

values should be calculated accordingly: 

Layer Functionality 

1 Physical (for example, repeaters) 

2 Datalink/subnetwork (for example, bridges) 

3 Internet (for example, supports the IP) 

4 End-to-end (for example, supports the TCP) 

7 Applications (for example, supports the SMTP) 

For systems including OSI protocols, 

layers 5 and 6 can also be counted. 

Interfaces Group 

Table 23. Implementation of the Interfaces Group 

Table 23 lists the objects in the interfaces group. The interfaces objects are a set of 

entries for each network interface below the IP layer that can send and receive 

datagrams. 


ifNumber 

{ interfaces 1 } 

ifTable 

{ interfaces 2 } 

INTEGER 

SEQUENCE of IfEntry 

The number of network interfaces 

(regardless of their current state) present 

on this system. 

A list of interface entries. The number of 

entries is given by the value of ifNumber. 

read-only 

not applicable 


Table 23. Implementation of the Interfaces Group (continued) 


ifEntry 

{ ifTable 1 } 

ifIndex 

{ ifEntry 1 } 

ifDescr 

{ ifEntry 2 } 

IfEntry ::= SEQUENCE An interface entry that contains objects at 

ifIndex 

the subnetwork layer and below for a 

INTEGER, 

particular interface. 

ifDescr 

(DISPLAY STRING in MIB-II) 

ifType 

INTEGER, 

ifMtu 

INTEGER, 

ifSpeed 

Gauge, 

ifPhysAddress 

OCTET STRING, 

ifAdminStatus 

INTEGER, 

ifOperStatus 

INTEGER, 

ifLastChange 

TimeTicks, 

ifInOctets 

Counter, 

ifInUcastPkts 

Counter, 

ifInNUcastPkts 

Counter, 

ifInDiscards 

Counter, 

ifInErrors 

Counter, 

ifInUnkownProtos 

Counter, 

ifOutOctets 

Counter, 

ifOutUcastPkts 

Counter, 

ifOutNUcastPkts 

Counter, 

ifOutDiscards 

Counter, 

ifOutErrors 

Counter, 

ifOutQLen 

Gauge 

ifSpecific 

Object ID 

INTEGER 

DisplayString 

A unique value for each interface. Values 

range between 1 and the value of 

ifNumber. The value for each interface 

must remain constant for at least one start 

of the systems network management 

system to the next start. 

A text string containing information about 

the interface. This string should include 

the name of the manufacturer, the product 

name, and the version of the hardware 

interface. 

MIB Objects 

read-write 1 

read-only 

read-only 


MIB Objects 



ifType 

{ ifEntry 3 } 

ifMtu 

{ ifEntry 4 } 

ifSpeed 

{ ifEntry 5 } 

ifPhysAddress 

{ ifEntry 6 } 

ifAdminStatus 

{ ifEntry 7 } 

ifOperStatus 

{ ifEntry 8 } 

INTEGER 

The type of interface, distinguished 

other (1), 

according to the physical/link/network 

regular 1822 (2), protocol(s) immediately below IP in the 

hdh1822 (3), 

protocol stack. 

ddn-x25 (4), 

rfc877-x25 (5), 

ethernet-csmacd (6), 

iso88023-csmacd (7), 

iso88024-tokenBus (8), 

iso88025-tokenRing (9), 

iso88026-kman (10), 

starLan (11), 

proteon-10Mbit (12), 

proteon-80Mbit (13), 

hyperchannel (14), 

fddi (15), 

lapb (16), 

sdlc (17), 

tl-carrier (18), 

cept (19), 

basicISDN (20), 

primaryISDN (21), 

propPointToPointSerial (22), 

terminalServer-asypcPort (23), 

softwareLoopback (24), 

eon (25), 

ethernet-3Mbit (26), 

nsip (27), 

slip (28) 

INTEGER 

Gauge 

OCTET STRING 

INTEGER 

up (1), 

down (2), 

testing (3) 

INTEGER 

up (1), 

down (2), 

testing (3) 

The size of the largest datagram that can 

be sent or received on the interface, 

specified in octets. For interfaces that are 

used for transmitting IP datagrams, this is 

the size of the largest IP datagram that 

can be sent on the interface. 

An estimate of the interface’s current 

bandwidth in bits per second. For 

interfaces that do not vary in bandwidth 

or for those where no accurate estimate 

can be made, this object should contain 

the nominal bandwidth. 

The interface’s address at the protocol 

layer immediately below IP in the protocol 

stack. For interfaces that do not have such 

an address (for example, a serial line), this 

object should contain an octet string of 

length 0. 

The desired state of the interface. The 

testing (3) state indicates that operational 

packets cannot be passed. 

The current operational state of the 

interface. The testing (3) state indicates 

that operational packets cannot be passed. 

read-only 

read-only 

read-only 

read-only 

read-write 1 

read-only 




ifLastChange 

{ ifEntry 9 } 

ifInOctets 

{ ifEntry 10 } 

ifInUcastPkts 


IfInNUcastPkts 


ifInDiscards 


ifInErrors 


ifInUnknownProtos 


ifOutOctets 


ifOutUcastPkts 


ifOutNUcastPkts 


ifOutDiscards 


ifOutErrors 


ifOutQLen 


TimeTicks 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Gauge 

The value of sysUpTime at the time the 

interface entered its current operational 

state. If the current state was entered 

before the last start-up of the local 

network management subsystem, then 

this object contains a value of 0. 

The total number of octets received on the 

interface, including framing characters. 

The number of subnetwork-unicast 

packets delivered to a higher-layer 

protocol. 

The number of non-unicast (for example, 

subnetwork-broadcast or 

subnetwork-multicast) packets delivered 

to a higher-layer protocol. 

The number of inbound packets that were 

chosen to be discarded even though errors 

had not been detected to prevent their 

delivery to a higher-layer protocol. One 

possible reason for discarding such a 

packet could be to free buffer space. 

The number of inbound packets that 

contain errors that prevent delivery to a 

higher-layer protocol. 

The number of packets received through 

the interface that were discarded because 

of an unknown or unsupported protocol. 

The total number of octets transmitted out 

of the interface, including framing 

characters. 

The total number of packets that 

higher-level protocols requested be 

transmitted to a subnetwork-unicast 

address, including those that were 

discarded or not sent. 

The total number of packets that 

higher-level protocols request to be 

transmitted to a non-unicast (for example, 

a subnetwork-broadcast or 

subnetwork-multicast) address, including 

those that were discarded or not sent. 

The number of outbound packets that 

were chosen to be discarded even though 

errors had not been detected to prevent 

their being transmitted. One reason for 

discarding such a packet could be to free 

buffer space. 

The number of outbound packets that 

could not be transmitted because of 

errors. 

The length of the output packet queue (in 

packets). 

MIB Objects 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 


MIB Objects 



ifSpecific 


OBJECT IDENTIFIER 

A reference to MIB definitions specific to read-only 

the particular media being used to realize 

the interface. For example, if the interface 

is realized by an ethernet, then the value 

of this object refers to a document 

defining objects specific to Ethernet. If an 

agent is not configured to have a value 

for any of these variables, the object 

identifier: 

nullSpecific OBJECT IDENTIFIER ::= {00} 

is returned. Note that nullSpecific is a 

syntactically valid object identifier, and 

any conformant implementation of ASN.1 

and BER must be able to generate and 

recognize this value. 

Address Translation Group 

Table 24 lists the objects in the address translation group. The address translation 

objects are a set of entries for each network interface, below the IP layer, that can 

send and receive datagrams. 

Table 24. Implementation of the Address Translation Group 


atTable 

{at1} 

atEntry 

{ atTable 1 } 

atIfIndex 

{ atEntry 1 } 

atPhysAddress 

{ atEntry 2 } 

atNetAddress 

{ atEntry 3 } 

SEQUENCE OF AtEntry 

AtEntry ::= SEQUENCE 

atIfIndex 

INTEGER, 

atPhysAddress 

OCTET STRING, 

atNetAddress 

NetworkAddress 

INTEGER 

The Address Translation tables contain the 

NetworkAddress to physical address 

equivalences. Some interfaces do not use 

translation tables to determine address 

equivalences (for example, DDN-X.25 has 

an algorithmic method). If all interfaces 

are of this type, then the Address 

Translation table is empty; it has 0 entries. 

Each entry contains one NetworkAddress 

to the physical address equivalent. 

The interface on which this entry’s 

equivalence is effective. The interface 

identified by a particular value of this 

index is the same interface that is 

identified by the same value of ifIndex. 

read-write 1 

read-write 

read-write 

OCTET STRING The media-dependent physical address. read-write 

NetworkAddress 

The NetworkAddress (for example, the IP 

address) corresponding to the 

media-dependent physical address. 

read-write 


MIB Objects 

IP Group 

Table 25 lists the objects in the IP group. The IP objects are the statistics and 

gateway routing tables for the IP layer. 

Table 25. Implementation of the IP Group 


ipForwarding 

{ip1} 

ipDefaultTTL 

{ip2} 

ipInReceives 

{ip3} 

ipInHdrErrors 

{ip4} 

ipInAddrErrors 

{ip5} 

ipForwDatagrams 

{ip6} 

ipInUnkownProtos 

{ip7} 

ipInDiscards 

{ip8} 

INTEGER 

gateway (1), 

— entry forwards 

datagrams 

host (2) 

— entry does NOT 

forward datagrams 

INTEGER 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Indicates if this entry is acting as an IP 

gateway for the forwarding of datagrams 

received by, but not addressed to, this 

entry. IP gateways forward datagrams; 

hosts do not, except those source-routed 

through the host. 

When a TTL value is not supplied by the 

transport layer protocol, the default value 

inserts into the time-to-live field of the IP 

header of datagrams that originate at this 

entry. 

The number of input datagrams received 

from interfaces, including those received 

in error. 

The number of input datagrams discarded 

because of errors in their IP headers. For 

example, bad checksums, mismatched 

version number, format errors, 

time-to-live exceeded, and processing 

errors in IP options. 

The number of input datagrams discarded 

because the IP address in their IP header’s 

destination field was not a valid address 

to be received at this entry. This count 

includes invalid addresses (for example, 

0.0.0.0), addresses of unsupported classes 

(for example, Class E), and destination 

addresses that were not local addresses 

(for example, IP gateways). 

The number of input datagrams for which 

this entry is not their final IP destination. 

As a result, an attempt is made to find a 

route to their final destination. For entries 

that do not act as IP gateways, this count 

includes only those packets that are 

source-routed successfully through this 

entry. 

The number of locally-addressed 

datagrams received successfully, but 

discarded because of an unknown or 

unsupported protocol. 

The number of input IP datagrams that 

are processed without problems, but are 

discarded (for example, for lack of buffer 

space). This count does not include any 

datagrams discarded while awaiting 

reassembly. 

read-only 

read-write 1 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 


MIB Objects 

Table 25. Implementation of the IP Group (continued) 


ipInDelivers 

{ip9} 

ipOutRequests 

{ip10} 

ipOutDiscards 

{ip11} 

ipOutNoRoutes 

{ip12} 

ipReasmTimeout 

{ip13} 

ipReasmReqds 

{ip14} 

ipReasmOKs 

{ip15} 

ipReasmFails 

{ip16} 

ipFragOKs 

{ip17} 

ipFragFails 

{ip18} 

ipFragCreates 

{ip19} 

ipAddrTable 

{ip20} 

Counter 

Counter 

Counter 

Counter 

INTEGER 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

SEQUENCE OF 

IpAddrEntry 

The number of input datagrams 

successfully delivered to IP user-protocols 

including ICMP. 

The number of IP datagrams that are 

supplied to IP and ICMP in requests for 

transmission. This count does not include 

datagrams counted in ipForwDatagrams. 

The number of output IP datagrams that 

transmit without problems, but are 

discarded (for example, for lack of buffer 

space). This count includes datagrams in 

ipForwDatagrams that meet this discard 

criterion. 

The number of IP datagrams discarded 

because no route can transmit them to 

their destination. This count includes 

packets in ipForwDatagrams that meet 

this no-route criterion. 

The maximum number of seconds that 

received fragments are held while 

awaiting reassembly at this entry. 

The number of IP fragments that are 

received and need to be reassembled at 

this entry. 

The number of IP datagrams reassembled 

without problems. 

The number of failures detected by the IP 

reassembly algorithm. This is not a count 

of discarded IP fragments because some 

algorithms can lose track of the number of 

fragments by combining them as they are 

received. 

The number of IP datagrams that have 

fragmented at this entry without 

problems. 

The number of IP datagrams that should 

have been fragmented at this entry, but 

were not because their Don’t Fragment flag 

was set. 

The number of IP datagram fragments 

that have been generated, because of 

fragmentation at this entry. 

A table that contains addressing 

information relevant to this entry’s IP 

addresses. 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 




ipAddrEntry 

{ ipAddrTable 1 } 

ipAdEntAddr 

{ ipAddrEntry 1 } 

ipAdEntIfIndex 


ipAdEntNetMask 


ipAdEntBcastAddr 


ipAdEntReasmMaxSize 


ipRoutingTable 

{ip21} 

IpAddrEntry ::= 

SEQUENCE 

ipAdEntAddr 

IpAddress, 

ipAdEnt|f|ndex 

INTEGER, 

ipAdEntNetMask 

IpAddress, 

ipAdEntBcastAddr 

INTEGER 

ipAdEntReasmMaxSize 

INTEGER 

IpAddress 

INTEGER 

IpAddress 

INTEGER 

INTEGER 

SEQUENCE OF 

IpRouteEntry 

The addressing information for one of this 

entry’s IP addresses. 

The IP address pertaining to this entry’s 

addressing information. 

The index value that uniquely identifies 

the interface to which this entry is 

applicable. The interface identified by a 

particular value of this index is the same 

interface that is identified by the same 

value of ifIndex. 

The subnet mask associated with the IP 

address of this entry. The value of the 

mask is an IP address with all the 

network bits set to 1 and all the host bits 

set to 0. 

The value of the least-significant bit in the 

IP broadcast address used for sending 

datagrams on the (logical) interface 

associated with the IP address of this 

entry. For example, when the internet 

standard all-ones broadcast address is 

used, the value is 1. 

The size of the largest IP datagram that 

this entity can reassemble from incoming 

IP fragmented datagrams received on this 

interface. 

This entry’s IP routing table. 

MIB Objects 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-write 


MIB Objects 



ipRouteEntry 

{ ipRoutingTable 1 } 

ipRouteDest 

{ ipRouteEntry 1 } 

ipRouteIfIndex 


ipRouteMetric1 




IpRouteEntry ::= 

SEQUENCE 

ipRouteDest 

IpAddress, 

ipRouteIfIndex 

INTEGER, 

ipRouteMetric 1 

INTEGER, 


INTEGER, 


INTEGER, 


INTEGER, 

ipRouteNextHop 

IpAddress, 

ipRouteType 

INTEGER, 

ipRouteProto 

INTEGER, 

ipRouteAge 

INTEGER 

ipRouteMask 

INTEGER 

IpAddress 

INTEGER 

INTEGER 

INTEGER 

A route to a particular destination. 

The destination IP address of this route. 

An entry with a value of 0.0.0.0 is 

considered a default route. Multiple 

default routes can appear in the table, but 

access to these multiple entries is 

dependent on the table-access 

mechanisms defined by the network 

management protocol in use. 

The index value that uniquely identifies 

the local interface through which the next 

hop of this route should be reached. The 

interface identified by a particular value 

of this index is the same interface that is 

identified by the same value of ifIndex. 

The primary routing metric for this route. 

The semantics of this metric are 

determined by the routing protocol 

specified in the route’s ipRouteProto 

value. If this metric is not used, its value 

should be set to −1. 

An alternative routing metric for this 

route. The semantics of this metric are 





read-write 

read-write 

read-write 

read-write 1 

read-write 








ipRouteNextHop 


ipRouteType 


ipRouteProto 


ipRouteAge 


INTEGER 

INTEGER 

IpAddress 

INTEGER 

other (1), 

invalid (2), 

direct (3), 

remote (4) 

INTEGER 

other (1), 

local (2), 

netmgmt (3), 

icmp (4), 

egp (5), 

ggp (6), 

hello (7), 

rip (8), 

is-is (9), 

es-is (10), 

ciscoIgrp (11), 

bbnSpfIgp (12), 

ospf (13) 

INTEGER 













The IP address of the next hop of this 

route. 

The type of route. 

The routing mechanism by which this 

route was learned. Inclusion of values for 

gateway routing protocols is not intended 

to imply that hosts should support those 

protocols. 

The number of seconds since this route 

was last updated or otherwise determined 

to be correct. Note semantics of too old 

cannot be implied, except through 

knowledge of the routing protocol by 

which the route was learned. 

MIB Objects 

read-write 

read-write 

read-write 

read-write 

read-only 

read-write 


MIB Objects 



ipRouteMask 


ipAddress 

Indicate the mask to be logically ANDed 

with the destination address before being 

compared to the value in the ipRouteDest 

field. For those systems that do not 

support arbitrary subnet masks, an agent 

constructs the value of the ipRouteMask 

by determining whether the value of the 

correspondent ipRouteDest field belongs 

to a class–A, B, or C network. Then use 

one of the following: 

mask network 

255.0.0.0 

class-A 

255.255.0.0 

class-B 

255.255.255.0 

class-C 

If the value of the ipRouteDest is 0.0.0.0 (a 

default route), then the mask value is also 

0.0.0.0. All IP routing subsystems 

implicitly use this mechanism. 

read-write 

IP Address Translation Table 

Table 26. IP Address Translation Table 

Table 26 lists the objects in the IP Translation table. 


ipNetToMediaTable 

{ip22} 

IpNetToMediaEntry 

{ ipNetToMediaTable 1 } 

ipNetToMediaIfIndex 

{ ipNetToMediaEntry 1 } 

ipNetToMediaPhysAddress 


ipNetToMediaNetAddress 


SEQUENCE OF 



::= SEQUENCE 

ipNetToMediaIfIndex 

INTEGER, 

ipNetToMediaPhysAddress 

OCTET STRING, 

ipNetToMediaNetAddress 

IpAddress, 

ipNetToMediaType 

INTEGER 

INTEGER 

The IP Address Translation table used for 

mapping from IP addresses to physical 

addresses. 

Each entry contains one IpAddress to 

physical address equivalence. 

The interface on which this entry’s 

equivalence is effective. The interface 

identified by a particular value of this 

index is the same interface as identified 

by the same value of ifIndex. 

read-write 1 

read-write 

read-write 

OCTET STRING The media-dependent physical address. read-write 

IpAddress 

The IpAddress corresponding to the 

media-dependent physical address. 

read-write 


Table 26. IP Address Translation Table (continued) 


ipNetToMediaType 


INTEGER 

other(1), 

invalid(2), 

dynamic(3), 

static(4), 

The type of mapping. 

Setting this object to the value invalid(2) 

has the effect of invalidating the 

corresponding entry in the 

ipNetToMediaTable. That is, it effectively 

disassociates the interface identified with 

the entry from the mapping identified 

with the entry. Whether the agent 

removes an invalidated entry from the 

table is an implementation-specific matter. 

Accordingly, management stations must 

be prepared to receive tabular information 

from agents that correspond to entries not 

currently in use. Proper interpretation of 

such entries requires examination of the 

relevant ipNetToMediaType object. 

MIB Objects 

read-write 

ICMP Group 

Table 27 lists the objects in the ICMP group. The ICMP objects are the input and 

output error and control message statistics for the IP layer. 

Table 27. Implementation of the ICMP Group 


icmpInMsgs 

{icmp1} 

icmpInErrors 

{icmp2} 

icmpInDestUnreachs 

{icmp3} 

icmpInTimeExcds 

{icmp4} 

icmpInParmProbs 

{icmp5} 

icmpInSrcQuenchs 

{icmp6} 

icmpInRedirects 

{icmp7} 

icmpInEchos 

{icmp8} 

icmpInEchoReps 

{icmp9} 

icmpInTimestamps 

{ icmp 10 } 

icmpInTimestampReps 

{ icmp 11 } 

icmpInAddrMasks 

{ icmp 12 } 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

The number of ICMP messages that the entry 

receives. This counter includes all those counted 

by icmpInErrors. 

The number of ICMP messages that the entry 

receives and determines ICMP specific errors 

(bad ICMP checksums, bad length). 

The number of ICMP destination messages that 


The number of ICMP destination messages that 


The number of ICMP Parameter Problem 

messages received. 

The number of ICMP Source Quench messages 

received. 

The number of ICMP Redirect messages 

received. 

The number of ICMP Echo (request) messages 

received. 

The number of ICMP Echo Reply messages 

received. 

The number of ICMP Timestamp (request) 


The number of ICMP Timestamp Reply 


The number of ICMP Address Mask Request 


read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 


MIB Objects 

Table 27. Implementation of the ICMP Group (continued) 


icmpInAddrMaskReps 

{ icmp 13 } 

icmpOutMsgs 

{ icmp 14 } 

icmpOutErrors 

{ icmp 15 } 

icmpOutDestUnreachs 

{ icmp 16 } 

icmpOutTimeExcds 

{ icmp 17 } 

icmpOutParmProbs 

{ icmp 18 } 

icmpOutSrcQuenches 

{ icmp 19 } 

icmpOutRedirects 

{ icmp 20 } 

icmpOutEchos 

{ icmp 21 } 

icmpOutEchoReps 

{ icmp 22 } 

icmpOutTimestamps 

{ icmp 23 } 

icmpOutTimestampReps 

{ icmp 24 } 

icmpOutAddrMasks 

{ icmp 25 } 

icmpOutAddrMasksReps 

{ icmp 26 } 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

Counter 

The number of ICMP Address Mask Reply 


The number of ICMP messages sent. This 

counter includes icmpOutErrors. 

The number of ICMP messages that this entry 

did not send, because of problems within ICMP 

(for example, no buffers). This value should not 

include errors outside the ICMP layer (for 

example, the inability of IP to route the 

resulting datagram). In some implementations, 

there may not be error types that contribute to 

the counter’s value. 

The number of ICMP Destination Unreachable 

messages sent. 

The number of ICMP Time Exceeded messages 

sent. 

The number of ICMP Parameter Problem 


The number of ICMP Source Quench messages 

sent. 

The number of ICMP Redirect messages sent. 

For a host, this object is always 0, because hosts 

do not send redirects. 

The number of ICMP Echo (request) messages 

sent. 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

The number of ICMP Echo Reply messages sent. read-only 

The number of ICMP Timestamp (request) 


The number of ICMP TimeStamp Reply 


The number of ICMP Address Mask Request 


The number of ICMP Address Mask Reply 


read-only 

read-only 

read-only 

read-only 

TCP Group 

Table 28 on page 325 lists the objects in the TCP group. The TCP objects are the 

data transmission statistics and connection data for the TCP layer. 

Note: Objects that represent information about a particular TCP connection are 

transient; the objects exist only as long as the specified connection is in use. 


Table 28. Implementation of the TCP Group 


tcpRtoAlgorithm 

{tcp1} 

tcpRtoMin 

{tcp2} 

tcpRtoMax 

{tcp3} 

tcpMaxConn 

{tcp4} 

tcpActiveOpens 

{tcp5} 

tcpPassiveOpens 

{tcp6} 

tcpAttemptFails 

{tcp7} 

tcpEstabResets 

{tcp8} 

INTEGER 

other (1), 

none of the 

following 

constant (2), 

a constant rto 

rsre (3), 

MIL-STD-1778, 

Appendix B 

vanj (4) 

Van Jacobson’s 

algorithm 

INTEGER 

INTEGER 

INTEGER 

Counter 

Counter 

Counter 

Counter 

The algorithm used to determine the 

time-out value used for retransmitting 

unacknowledged octets. 

The minimum value allowed by a TCP 

implementation for the retransmission 

time-out, measured in milliseconds. 

Semantics for objects of this type depend 

upon the algorithm used to determine the 

retransmission time-out. For example, 

when the time-out algorithm is rsre (3), an 

object of this type has the semantics of the 

LBOUND quantity. 

The maximum value allowed by a TCP 

implementation for the retransmission 

time-out, measured in milliseconds. More 

refined semantics for objects of this type 

depend upon the algorithm used to 

determine the retransmission time-out. 

For example, when the time-out algorithm 

is rsre (3), an object of this type has the 

semantics of the UBOUND quantity. 

The limit on the number of TCP 

connections the entry can support. In 

entries where the maximum number of 

connections is dynamic, this object should 

be −1. 

The number of TCP connections that have 

made a direct transition to the SYN-SENT 

state from the CLOSED state. 

The number of times TCP connections 

have made a direct transition to the 

SYN-RCVD state from the LISTEN state. 


made a direct transition to the CLOSED 

state from either the SYN-SENT state or 

the SYN-RCVD state, plus the number of 

times TCP connections have made a direct 

transition to the LISTEN state from the 

SYN-RCVD state. 


made a direct transition to the CLOSED 

state from either the ESTABLISHED or 

CLOSE-WAIT state. 

MIB Objects 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 


MIB Objects 

Table 28. Implementation of the TCP Group (continued) 


tcpCurrEstab 

{tcp9} 

tcpInSegs 

{ tcp 10 } 

tcpOutSegs 

{ tcp 11 } 

tcpRetransSegs 

{ tcp 12 } 

tcpConnTable 

{ tcp 13 } 

tcpConnEntry 

tcpConnState 

{ tcpConnEntry 1 } 

tcpConnLocalAddress 


tcpConnLocalPort 


tcpConnRemAddress 


tcpConnRemPort 


tcpInErrs 

{ tcp 14 } 

tcpOutRsts 

{ tcp 15 } 

Gauge 

Counter 

Counter 

Counter 

SEQUENCE OF 

TcpConnEntry 

TcpConnEntry 

::= SEQUENCE 

tcpConnState 

INTEGER, 

tcpConnLocalAddress 

IpAddress, 

tcpConnLocalPort 

INTEGER (0..65535), 

tcpConnRemAddress 

IpAddress, 

tcpConnRemPort 

INTEGER (0..65535) 

INTEGER closed(1), 

listen(2), synSent(3), 

synReceived(4), 

established(5), finWait1(6), 

finWait2(7), closeWait(8), 

lastAck(9), closing(10), 

timeWait(11) 

IpAddress 

INTEGER 

(0..65535) 

IpAddress 

INTEGER 

(0..65535) 

Counter 

Counter 

The number of TCP connections of the 

current state that are either 

ESTABLISHED or CLOSE-WAIT. 

The number of TCP segments including 

those received in error. This count 

includes segments received on established 

connections. 

The number of TCP segments sent 

including those on established 

connections, but excluding those 

containing only retransmitted octets. 

The number of TCP segments 

retransmitted that contain one or more 

previously transmitted octets. 

A table that contains TCP 

connnection-specific information. 

Information about a certain current TCP 

connection. An object of this type is 

transient. It does not exist when (or soon 

after) the connection makes the transition 

to the CLOSED state. 

The TCP connection status. 

The local IP address of this TCP 

connection. 

The local port number of this TCP 

connection. 

The remote IP address of this TCP 

connection. 

The remote port number of this TCP 

connection. 

The total number of segments received in 

error (for example, bad TCP checksums). 

The number of TCP segments sent 

containing the RST flag. 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 


MIB Objects 

UDP Group 

Table 29 lists the objects in the UDP group. The UDP objects are the datagram 

statistics of the UDP layer. 

Table 29. Implementation of the UDP Group 


udpInDatagrams 

{udp1} 

udpNoPorts 

{udp2} 

udpInErrors 

{udp3} 

udpOutDatagrams 

{udp4} 

udpTable 

{udp5} 

udpEntry 

{ udpTable 1 } 

udpLocalAddress 

{ udp Entry 1 } 

udpLocalPort 

{ udpEntry 2 } 

Counter 

Counter 

Counter 

Counter 

SEQUENCE of UDPEntry 

UdpEntry ::= SEQUENCE 

udpLocalAddress 

IpAddress, 

udpLocalPort 

INTEGER 

IpAddress 

INTEGER 

The number of UDP datagrams delivered 

to UDP users. 

The number of UDP datagrams received 

where there was no application at the 

destination port. 

The number of UDP datagrams received 

that could not be delivered for reasons 

other than the lack of an application at 

the destination port. 

The number of UDP datagrams sent from 

this entry. 

Information about this ENTITY’s UDP 

end-points on which a local application is 

currently accepting datagrams. 

Information about a certain current UDP 

listener. 

The local IP address for this UDP listener. 

0.0.0.0 is a listener which is willing to 

accept datagrams for any IP interface 

associated with the node. 

The local port number for this UDP 

listener. 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 

IBM 3172 Enterprise-Specific MIB Variables 

The following tables list the objects in the various IBM 3172 System tables. These 

are available if NETMAIN has been specified on the DEVICE statement in the 

TCP/IP configuration file. See TCP/IP Planning and Customization for information 

about this file. 

ibm3172SystemTable 

Table 30 on page 328 lists the objects in the IBM 3172 System Table. The system 

table identifies the hardware, software, contact person, physical location and 

number of network interfaces for the 3172. 


MIB Objects 

Table 30. Implementation of the IBM 3172 System Table 


ibm3172SystemTable ibm3172SystemTable 

::= SEQUENCE 

Descriptive objects related to the entire 

3172. 

read-only 

ibm3172Descr 

DISPLAYSTRING, 

ibm3172Contact 


ibm3172Location 


ibm3172ifNumber 

INTEGER 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.1 

ibm3172Descr 

{ibm3172SystemTable 1} 

DisplayString 

(SIZE(0..253)) 

Text Description of the 3172. Contains 

information about the hardware and 

software of the 3172. The format of the 

ibm3172Descr variable is : 

ttttxMODELxmmm, 

xSERIALxNUMBERxsssssssss, 

xiiiiiiiiiixllllll, 

xPROGRAMxNUMBERxpppppp ; where 

: x represents a blank character, ; UPPER 

CASE letters are hardcoded characters, ; 

(,) represents a comma, ; and the 

remaining lower case letters represent 

variable data as follows: 

t - machine type 

m - model number 

s - serial number 

i - software program name 

l - software level numbers 

p - software program product number. 

read-only 

An example of the information sent with 

this attribute would be: 

″3172 MODEL 001, 

SERIAL NUMBER 000001234, 

3172 Interconnect Ctlr 

Program 020100, 5601433″ 

ibm3172Contact 


DisplayString 

(SIZE(0..32)) 

The textual identification of the contact 

person for this 3172, together with 

information about how to contact this 

person. This information is provided by 

the 3172 Operator Facility. 

read-only 

ibm3172Location 


DisplayString 

(SIZE(0..32)) 

The physical location of this node. This 

information is provided by the 3172 

Operator Facility. 

read-only 

ibm3172ifNumber 


Integer 

The number of network interfaces 

(regardless of their current status) on 

which this 3172 can send data. 

read-only 

ibm3172ifTrapTable 

Table 31 on page 329 lists the objects in the IBM 3172 Trap Table. The trap table 

identifies the trap settings for the interface of the 3172. 


Table 31. Implementation of the IBM 3172 Trap Table 


ibm3172ifTrapTable ibm3172ifTrapTable 

::= SEQUENCE 

Objects at the interface level pertaining to 

the trap function. 

read-only 

ibm3172ifTrapEnable 

INTEGER 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.2 

ibm3172ifTrapEnable 

{ibm3172ifTrapTable 1} 

Integer 

Flag to indicate whether the 3172 should 

send traps for this interface to the SNMP 

proxy agent. ″0″ indicates the trap 

function of the 3172 is disabled, ″1″ 

indicates that it is enabled. The VM 

SNMP proxy agent does not utilize this 

function of the 3172, so the value of this 

variable is always ″0″. 

MIB Objects 

read-only 

ibm3172ifChanCounters Table 

Table 32 lists the objects in the IBM 3172 channel counter table. The channel 

counters identify the inbound and outbound octets and blocks of the 3172. 

Table 32. Implementation of the IBM 3172 ChanCounter Table 


ibm3172ifChanCounters ibm3172ifChanCounters 

::= SEQUENCE 

ibm3172ifInChanOctets 

COUNTER, 

ibm3172ifOutChanOctets 

COUNTER, 

ibm3172ifInChanBlocks 

COUNTER, 

ibm3172ifOutChanBlocks 

COUNTER 

Objects at the subnetwork layer and 

below pertaining to a pair of subchannels 

of the 3172. The values supplied for 

ibm3172ifOutChanOctets and 

ibm3172ifOutChanBlocks apply to the 

outbound subchannel on which the 

command was received. The values 

supplied for ibm3172ifInChanOctets and 

ibm3172ifInChanBlocks apply to the 

inbound subchannel that is paired with 

the outbound subchannel on which the 

command was received. 

read-only 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.3 

ibm3172ifInChanOctets 

{ibm3172ifChanCounters 1} 

ibm3172ifOutChanOctets 


ibm3172ifInChanBlocks 


ibm3172ifOutChanBlocks 


Counter 

Counter 

Counter 

Counter 

The number of inbound octets that were 

transmitted to the host by the 3172, 

including all headers. The value applies to 

the inbound subchannel that is paired 

with the outbound subchannel on which 

the command was received. 

The number of outbound octets that were 

received from the host by the 3172, 

including all headers. The value applies to 

the outbound subchannel on which the 

command was received. 

The number of inbound blocks that were 

transmitted to the host by the 3172. The 

value applies to the inbound subchannel 

that is paired with the outbound 

subchannel on which the command was 

received. 

The number of outbound blocks that were 

received from the host by the 3172. The 

value applies to the outbound subchannel 

on which the command was received. 

read-only 

read-only 

read-only 

read-only 


MIB Objects 

ibm3172ifLANCounters Table 

Table 33 lists the objects in the IBM 3172 LAN counter table. The LAN counters 

identify the inbound and outbound octets and frames of the 3172. The LAN 

counters identify transmission errors, discarded frames, and undeliverable frames. 

Table 33. Implementation of the IBM 3172 LAN Counter Table 


ibm3172ifLANCounters ibm3172ifLANCounters 

::= SEQUENCE 

ibm3172ifInLANOctets 


below pertaining to a particular LAN of 

the 3172. 

read-only 

COUNTER, 

ibm3172ifOutLanOctets 

COUNTER, 

ibm3172ifInLANFrames 

COUNTER, 

ibm3172ifOutLANFrames 

COUNTER, 

ibm3172ifInLANErrors 

COUNTER, 

ibm3172ifOutLANErrors 

COUNTER, 

ibm3172ifInLANDiscards 

COUNTER, 

ibm3172ifOutLANDiscards 

COUNTER 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.4 

ibm3172ifInLANOctets 

{ibm3172ifLANCounters 1} 

ibm3172ifOutLanOctets 


ibm3172ifInLANFrames 

{ibm3172ifLANCounter 3} 

ibm3172ifOutLANFrames 


ibm3172ifInLANErrors 


ibm3172ifOutLANErrors 


Counter 

Counter 

Counter 

Counter 

Counter 

Counter 


received from the LAN by the 3172, 

including all headers. 


transmitted to the LAN by the 3172, 


The number of inbound frames that were 

received from the LAN by the 3172. 

The number of outbound frames that 

were transmitted to the LAN by the 3172. 

The number of inbound frames received 

from the LAN by the 3172 that contained 

errors preventing them from being 

deliverable to a higher layer protocol. This 

variable, when combined with 

ibm3172inBlkErrors, reflects the total 

number of inbound frames not forwarded 

from the LAN to the host because of 

errors. 


could not be transmitted to the LAN 

because of transmission failures. This 

variable, when combined with 

ibm3172ifOutDblkErrors, reflects the total 

number of outbound frames not 

transmitted to the LAN because of 

transmission errors. 

read-only 

read-only 

read-only 

read-only 

read-only 

read-only 


Table 33. Implementation of the IBM 3172 LAN Counter Table (continued) 


ibm3172ifInLANDiscards 


ibm3172ifOutLANDiscards 


Counter 

Counter 

The number of inbound frames received 

from the LAN that were discarded by the 

3172, even though no errors had been 

detected to prevent their being deliverable 

to a higher layer protocol. One possible 

reason for discarding such a frame could 

be because of insufficient buffer space. 

This variable, when combined with 

ibm3172ifInBlkDiscards, reflects the total 

number of inbound frames not forwarded 

from the LAN when no error was 

detected. 

The number of outbound frames that are 

discarded. 

MIB Objects 

read-only 

read-only 

ibm3172ifBlkCounters Table 

Table 34 lists the objects in the IBM 3172 Blocker counter table. The Blocker 

counters identify the transmitted and received inbound octets and frames by the 

LAN adapter. The Blocker counters also identify the tasks that contained errors 

and the tasks that were discarded. 

Table 34. Implementation of the IBM 3172 Blk Counter Table 


ibm3172ifBlkCounters ibm3172ifBlkCounters 

::= SEQUENCE 

ibm3172ifBlkRcvOctets 

Objects at the Subnetwork layer and 

below pertaining to a particular Blocker 

Task of the 3172. 

read-only 

COUNTER, 

ibm3172ifBlkXmitOctets 

COUNTER, 

ibm3172ifBlkRcvFrames 

COUNTER, 

ibm3172ifBlkXmitBlocks 

COUNTER, 

ibm3172ifInBlkErrors 

COUNTER, 

ibm3172ifInBlkDiscards 

COUNTER 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.5 

ibm3172ifBlkRcvOctets 

{ibm3172ifBlkCounters 1} 

ibm3172ifBlkXmitOctets 


ibm3172ifBlkRcvFrames 


ibm3172ifBlkXmitBlocks 


Counter 

Counter 

Counter 

Counter 


received by the Blocker from the LAN, 



transmitted to the channel adapter by the 

Blocker, including all headers. 


received from the LAN adapter by the 

Blocker Task. 


transmitted to the channel adapter by the 

blocker task. 

read-only 

read-only 

read-only 

read-only 


MIB Objects 

Table 34. Implementation of the IBM 3172 Blk Counter Table (continued) 


ibm3172ifInBlkErrors 


ibm3172ifInBlkDiscards 


Counter 

Counter 

The number of inbound frames 

transmitted by the LAN adapter to the 

Blocker Task which contained errors 

preventing them from being deliverable to 

a higher layer protocol. This variable, 

when combined with 

ibm3172ifInLANErrors, reflects the total 

number of inbound frames discarded by 

the 3172 because of errors. 

The number of inbound frames 

transmitted by the LAN adapter to the 

Blocker Task that were discarded by the 

3172, even though no errors had been 

detected to prevent their being deliverable 

to a higher layer protocol. One possible 

reason for discarding such a frame could 

be because of insufficient buffer space. 

This variable, when combined with 

ibm3172ifInLANDiscards, reflects the total 

number of ID frames discarded by the 

3172 when no error was detected. 

read-only 

read-only 

ibm3172ifDblkCounters Table 

Table 35 lists the objects in the IBM 3172 Deblocker counter table. The Deblocker 

counters identify the transmitted and received outbound octets, blocks, and frames 

by the LAN adapter. The Deblocker counters also identify the tasks that contained 

errors and the tasks which were discarded. 

Table 35. Implementation of the IBM 3172 Dblk Counter Table 


ibm3172ifDblkCounters ibm3172ifDblkCounters 

::= SEQUENCE 

ibm3172ifDblkRcvOctets 


below pertaining to a particular Deblocker 

Task of the 3172. 

read-only 

COUNTER, 

ibm3172ifDblkXmitOctets 

COUNTER, 

ibm3172ifDblkRcvBlocks 

COUNTER, 

ibm3172ifDblkXmitFrames 

COUNTER, 

ibm3172ifOutDblkErrors 

COUNTER, 

ibm3172ifOutDblkDiscards 

COUNTER 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.6 

ibm3172ifDblkRcvOctets 

{ibm3172ifDblkCounters 1} 

ibm3172ifDblkXmitOctets 


ibm3172ifDblkRcvBlocks 


Counter 

Counter 

Counter 


received by the Deblocker from the 

channel adapter, including all headers. 


transmitted to the LAN adapter by the 

Deblocker, including all headers. 

The number of outbound blocks that were 

received from the channel adapter by the 

Deblocker Task. 

read-only 

read-only 

read-only 


Table 35. Implementation of the IBM 3172 Dblk Counter Table (continued) 


ibm3172ifDblkXmitFrames 


ibm3172ifOutDblkErrors 


ibm3172ifOutDblkDiscards 


Counter 

Counter 

Counter 


were transmitted to the LAN adapter by 

the Deblocker Task. 

The number of outbound frames 

transmitted by the channel adapter to the 

Deblocker Task that contained errors 

preventing them from being deliverable to 

a higher layer protocol. This variable, 

when combined with 

ibm3172ifOutLANErrors, reflects the total 

number of outbound frames discarded by 

the 3172 because of errors. 

The number of outbound frames 

transmitted to the Deblocker Task which 

were discarded by the 3172, even though 

no errors had been detected to prevent 

their being deliverable to a higher layer 

protocol. One possible reason for 

discarding such a frame could be because 

of insufficient buffer space. This variable 

reflects the total number of outbound 

frames discarded by the 3172 when no 

error was detected. 

MIB Objects 

read-only 

read-only 

read-only 

ibm3172ifDeviceTable 

Table 36 lists the objects in the IBM 3172 device table. The device table identifies 

the devices associated with this interface. 

Table 36. Implementation of the IBM 3172 Device Table 


ibm3172ifDeviceTable ibm3172ifDeviceTable 

::= SEQUENCE 

Objects at the interface level pertaining to 

the associated device. 

read-only 

ibm3172ifDeviceNumber 

INTEGER 

ASN.1 notation: 1.3.6.1.4.1.2.6.1.7 

ibm3172ifDeviceNumber 

{ibm3172ifDeviceTable 1} 

Integer 

The instance number, which is used to 

reference the ibm3172SystemTable, for the 

device associated with this interface. 

read-only 


MIB Objects 


Appendix F. IBM 3172 Attribute Index 

This appendix lists 3172 attributes and their corresponding MIB variables. 

Table 37. MIB Variable Cross Reference Table 

3172 Attribute MIB Variable 

01 = ibm3172Descr 

02 = ibm3172Contact 

03 = ibm3172Location 

04 = ibm3172ifNumber 

10 = ibm3172ifTrapEnable 

11 = ifDescr 

12 = ifType 

13 = ifPhysAddress 

14 = ifOperStatus 

20 = ibm3172ifChanCounters 

21 = ibm3172ifInChanOctets 

22 = ibm3172ifOutChanOctets 

23 = ibm3172ifInChanBlocks 

24 = ibm3172ifOutChanBlocks 

30 = ibm3172ifLANCounters 

31 = ibm3172ifInLANOctets 

32 = ibm3172ifOutLANOctets 

33 = ibm3172ifInLANFrames 

34 = ibm3172ifOutLANFrames 

35 = ibm3172ifInLANErrors 

36 = ibm3172ifOutLANErrors 

37 = ibm3172ifInLANDiscards 

38 = ibm3172ifOutLANDiscards 

40 = ibm3172ifBlkCounters 

41 = ibm3172ifBlkRcvOctets 

42 = ibm3172ifBlkXmitOctets 

43 = ibm3172ifBlkRcvFrames 

44 = ibm3172ifBlkXmitBlocks 

45 = ibm3172ifInBlkErrors 

46 = ibm3172ifInBlkDiscards 

50 = ibm3172ifDblkCounters 

51 = ibm3172ifDblkRcvOctets 

52 = ibm3172ifDblkXmitOctets 

53 = ibm3172ifDblkRcvBlocks 

54 = ibm3172ifDblkXmitFrames 


IBM 3172 Attribute Index 

Table 37. MIB Variable Cross Reference Table (continued) 

3172 Attribute MIB Variable 

55 = ibm3172ifOutDblkErrors 

56 = ibm3172ifOutDblkDiscards 


Appendix G. SNMP Generic TRAP Types 

This appendix lists the generic trap types that can be received by SNMP. 

Value Type Description 

0 coldStart A coldStart trap signifies that the 

sending protocol entity is 

reinitializing itself so that the agent’s 

configuration or the protocol entity 

implementation can be altered. 

1 warmStart A warmStart trap signifies that the 

sending protocol entity is 

reinitializing itself so that neither the 

agent configuration nor the protocol 

entity implementation can be altered. 

2 linkDown A linkDown trap signifies that the 

sending protocol entity recognizes a 

failure in one of the communication 

links represented in the agent’s 

configuration. 

A Trap-PDU of type linkDown 

contains, as the first element of its 

variable-bindings, the name and 

value of the ifIndex instance for the 

affected interface. 

3 linkUp A linkUp trap signifies that the 

sending protocol entity recognizes 

that one of the communication links 

represented in the agent’s 

configuration has come up. 

A Trap-PDU of type linkUp contains, 

as the first element of its 

variable-bindings, the name and 

value of the ifIndex instance for the 

affected interface. 

4 authenticationFailure An authenticationFailure trap 

signifies that the sending protocol 

entity is the addressee of a protocol 

message that is not properly 

authenticated. 

5 egpNeighborLoss An egpNeighborLoss trap signifies 

that an EGP neighbor for whom the 

sending protocol entity was an EGP 

peer has been marked down and the 

peer relationship no longer exists. 

The Trap-PDU of the 

egpNeighborLoss contains, as the 

first element of its variable-bindings, 

the name and value of the 

egpNeighAddr instance for the 

affected neighbor. 


SNMP Generic TRAP Types 

Value Type Description 

6 enterpriseSpecific An enterpriseSpecific trap signifies 

that the sending protocol entity 

recognizes that some 

enterprise-specific event has 

occurred. The specific-trap field 

identifies the particular trap that 

occurred. 


Appendix H. Related Protocol Specifications 

IBM is committed to industry standards. The internet protocol suite is still evolving 

through Requests for Comments (RFC). New protocols are being designed and 

implemented by researchers, and are brought to the attention of the internet 

community in the form of RFCs. Some of these are so useful that they become a 

recommended protocol. That is, all future implementations for TCP/IP are 

recommended to implement this particular function or protocol. These become the 

de facto standards, on which the TCP/IP protocol suite is built. 

Many features of TCP/IP for z/VM are based on the following RFCs: 

RFC Title Author 

768 User Datagram Protocol J.B. Postel 

791 Internet Protocol J.B. Postel 

792 Internet Control Message Protocol J.B. Postel 

793 Transmission Control Protocol J.B. Postel 

821 Simple Mail Transfer Protocol J.B. Postel 

822 Standard for the Format of ARPA Internet Text Messages D. Crocker 

823 DARPA Internet Gateway R.M. Hinden, A. Sheltzer 

826 Ethernet Address Resolution Protocol: or Converting Network Protocol Addresses D.C. Plummer 

to 48.Bit Ethernet Address for Transmission on Ethernet Hardware 

854 Telnet Protocol Specification J.B. Postel, J.K. Reynolds 

856 Telnet Binary Transmission J.B. Postel, J.K. Reynolds 

857 Telnet Echo Option J.B. Postel, J.K. Reynolds 

877 Standard for the Transmission of IP Datagrams over Public Data Networks J.T. Korb 

885 Telnet End of Record Option J.B. Postel 

903 Reverse Address Resolution Protocol R. Finlayson, T. Mann, J.C. 

Mogul, M. Theimer 

904 Exterior Gateway Protocol Formal Specification D.L. Mills 

919 Broadcasting Internet Datagrams J.C. Mogul 

922 Broadcasting Internet Datagrams in the Presence of Subnets J.C. Mogul 

950 Internet Standard Subnetting Procedure J.C. Mogul, J.B. Postel 

952 DoD Internet Host Table Specification K. Harrenstien, M.K. Stahl, 

E.J. Feinler 

959 File Transfer Protocol J.B. Postel, J.K. Reynolds 

974 Mail Routing and the Domain Name System C. Partridge 

1009 Requirements for Internet Gateways R.T. Braden, J.B. Postel 

1013 X Window System Protocol, Version 11: Alpha Update R.W. Scheifler 

1014 XDR: External Data Representation Standard Sun Microsystems 

Incorporated 

1027 Using ARP to Implement Transparent Subnet Gateways S. Carl-Mitchell, J.S. 

Quarterman 

1032 Domain Administrators Guide M.K. Stahl 


RFCs 


1033 Domain Administrators Operations Guide M. Lottor 

1034 Domain Names—Concepts and Facilities P.V. Mockapetris 

1035 Domain Names—Implementation and Specification P.V. Mockapetris 

1042 Standard for the Transmission of IP Datagrams over IEEE 802 Networks J.B. Postel, J.K. Reynolds 

1044 Internet Protocol on Network System’s HYPERchannel: Protocol Specification K. Hardwick, J. 

Lekashman 

1055 Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP J.L. Romkey 

1057 RPC: Remote Procedure Call Protocol Version 2 Specification Sun Microsystems 

Incorporated 

1058 Routing Information Protocol C.L. Hedrick 

1091 Telnet Terminal-Type Option J. VanBokkelen 

1094 NFS: Network File System Protocol Specification Sun Microsystems 

Incorporated 

1112 Host Extensions for IP Multicasting S. Deering 

1118 Hitchhikers Guide to the Internet E. Krol 

1122 Requirements for Internet Hosts-Communication Layers R.T. Braden 

1123 Requirements for Internet Hosts-Application and Support R.T. Braden 

1155 Structure and Identification of Management Information for TCP/IP-Based M.T. Rose, K. McCloghrie 

Internets 

1156 Management Information Base for Network Management of TCP/IP-based K. McCloghrie, M.T. Rose 

Internets 

1157 Simple Network Management Protocol (SNMP), J.D. Case, M. Fedor, M.L. 

Schoffstall, C. Davin 

1179 Line Printer Daemon Protocol The Wollongong Group, L. 

McLaughlin III 

1180 TCP/IP Tutorial, T. J. Socolofsky, C.J. Kale 

1183 New DNS RR Definitions (Updates RFC 1034, RFC 1035) C.F. Everhart, L.A. 

Mamakos, R. Ullmann, P.V. 

Mockapetris, 

1187 Bulk Table Retrieval with the SNMP M.T. Rose, K. McCloghrie, 

J.R. Davin 

1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks D. Katz 

1198 FYI on the X Window System R.W. Scheifler 

1207 FYI on Questions and Answers: Answers to Commonly Asked Experienced 

Internet User Questions 

G.S. Malkin, A.N. Marine, 

J.K. Reynolds 

1208 Glossary of Networking Terms O.J. Jacobsen, D.C. Lynch 

1213 Management Information Base for Network Management of TCP/IP-Based K. McCloghrie, M.T. Rose 

Internets: MIB-II, 

1215 Convention for Defining Traps for Use with the SNMP M.T. Rose 

1228 SNMP-DPI Simple Network Management Protocol Distributed Program G.C. Carpenter, B. Wijnen 

Interface 

1229 Extensions to the Generic-Interface MIB K. McCloghrie 

1230 IEEE 802.4 Token Bus MIB IEEE 802 4 Token Bus MIB K. McCloghrie, R. Fox 

1231 IEEE 802.5 Token Ring MIB IEEE 802.5 Token Ring MIB K. McCloghrie, R. Fox, E. 

Decker 


RFCs 


1267 A Border Gateway Protocol 3 (BGP-3) K. Lougheed, Y. Rekhter 

1268 Application of the Border Gateway Protocol in the Internet Y. Rekhter, P. Gross 

1269 Definitions of Managed Objects for the Border Gateway Protocol (Version 3) S. Willis, J. Burruss 

1293 Inverse Address Resolution Protocol T. Bradley, C. Brown 

1270 SNMP Communications Services F. Kastenholz, ed. 

1323 TCP Extensions for High Performance V. Jacobson, R. Braden, D. 

Borman 

1325 FYI on Questions and Answers: Answers to Commonly Asked New Internet G.S. Malkin, A.N. Marine 

User Questions 

1350 TFTP Protocol K.R. Sollins 

1351 SNMP Administrative Model J. Davin, J. Galvin, K. 

McCloghrie 

1352 SNMP Security Protocols J. Galvin, K. McCloghrie, J. 

Davin 

1353 Definitions of Managed Objects for Administration of SNMP Parties K. McCloghrie, J. Davin, J. 

Galvin 

1354 IP Forwarding Table MIB F. Baker 

1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode A. Malis, D. Robinson, R. 

Ullmann 

1374 IP and ARP on HIPPI J. Renwick, A. Nicholson 

1381 SNMP MIB Extension for X.25 LAPB D. Throop, F. Baker 

1382 SNMP MIB Extension for the X.25 Packet Layer D. Throop 

1387 RIP Version 2 Protocol Analysis G. Malkin 

1389 RIP Version 2 MIB Extension G. Malkin 

1390 Transmission of IP and ARP over FDDI Networks D. Katz 

1393 Traceroute Using an IP Option G. Malkin 

1397 Default Route Advertisement In BGP2 And BGP3 Versions of the Border D. Haskin 

Gateway Protocol 

1398 Definitions of Managed Objects for the Ethernet-like Interface Types F. Kastenholz 

1440 SIFT/UFT:Sender-Initiated/Unsolicited File Transfer R. Troth 

1483 Multiprotocol Encapsulation over ATM Adaptation Layer 5 J. Heinanen 

1540 IAB Official Protocol Standards J.B. Postel 

1583 OSPF Version 2 J.Moy 

1647 TN3270 Enhancements B. Kelly 

1700 Assigned Numbers J.K. Reynolds, J.B. Postel 

1723 RIP Version 2 — Carrying Additional Information G. Malkin 

1813 NFS Version 3 Protocol Specification B. Callaghan, B. 

Pawlowski, P. Stauback, 

Sun Microsystems 

Incorporated 

2060 IMAP Version 4 Protocol Specification M. Crispin 

2225 Classical IP and ARP over ATM M. Laubach, J. Halpern 

These documents can be obtained from: 

Appendix H. Related Protocol Specifications 341

RFCs 

Government Systems, Inc. 

Attn: Network Information Center 

14200 Park Meadow Drive 

Suite 200 

Chantilly, VA 22021 

Many RFCs are available online. Hard copies of all RFCs are available from the 

NIC, either individually or on a subscription basis. Online copies are available 

using FTP from the NIC at nic.ddn.mil. Use FTP to download the files, using the 


RFC:RFC-INDEX.TXT 

RFC:RFCnnnn.TXT 

RFC:RFCnnnn.PS 

Where: 

nnnn 

TXT 

PS 

Is the RFC number. 

Is the text format. 

Is the PostScript format. 

You can also request RFCs through electronic mail, from the automated NIC mail 

server, by sending a message to service@nic.ddn.mil with a subject line of 

RFC nnnn for text versions or a subject line of RFC nnnn.PS for PostScript versions. 

To request a copy of the RFC index, send a message with a subject line of 

RFC INDEX. 

For more information, contact nic@nic.ddn.mil. Information is also available 

through http://www.internic.net. 


Appendix I. Abbreviations and Acronyms 

The following abbreviations and acronyms are used throughout this book. 

AIX 

Advanced Interactive Executive 

ANSI 

American National Standards Institute 

API 

Application Program Interface 

APPC 

Advanced Program-to-Program Communications 

APPN ® Advanced Peer-to-Peer Networking ® 

ARP 

Address Resolution Protocol 

ASCII 

American National Standard Code for Information Interchange 

ASN.1 

Abstract Syntax Notation One 

ATM 

Asynchronous Transfer Mode 

AUI 

Attachment Unit Interface 

BFS 

Byte File System 

BIOS 

Basic Input/Output System 

BNC 

Bayonet Neill-Concelman 

CCITT 

Comite Consultatif International Telegraphique et Telephonique. 

The International Telegraph and Telephone Consultative 

Committee 

CETI 

Continuously Executing Transfer Interface 

CLAW 

Common Link Access to Workstation 

CLIST 

Command List 

CMS 

Conversational Monitor System 

CP 

Control Program 

CPI 

Common Programming Interface 

CREN 

Corporation for Research and Education Networking 

CSD 

Corrective Service Diskette 

CTC 

Channel-to-Channel 

CU 

Control Unit 

CUA ® Common User Access ® 

DASD 

Direct Access Storage Device 

DBCS 

Double Byte Character Set 

DLL 

Dynamic Link Library 

DNS 

Domain Name System 

DOS 

Disk Operating System 

DPI 

Distributed Program Interface 

EBCDIC Extended Binary-Coded Decimal Interchange Code 

ELANS 

IBM Ethernet LAN Subsystem 

EISA 

Enhanced Industry Standard Adapter 

ESCON ® Enterprise Systems Connection Architecture ® 

FAT 

File Allocation Table 

FDDI 

Fiber Distributed Data Interface 

FTAM 

File Transfer Access Management 

FTP 

File Transfer Protocol 

FTP API File Transfer Protocol Applications Programming Interface 

GCS 

Group Control System 

GDDM ® Graphical Data Display Manager 

GDDMXD Graphics Data Display Manager Interface for X Window System 

GDF 

Graphics Data File 

HCH 

HYPERchannel device 


Abbreviations and Acronyms 

HIPPI 

High Performance Parallel Interface 

HPFS 

High Performance File System 

ICMP 

Internet Control Message Protocol 

IEEE 

Institute of Electrical and Electronic Engineers 

IETF 

Internet Engineering Task Force 

IGMP 

Internet Group Management Protocol 

ILANS 

IBM Token-Ring LAN Subsystem 


Internet Protocol 

IPL 

Initial Program Load 

ISA 

Industry Standard Adapter 

ISDN 

Integrated Services Digital Network 

ISO 

International Organization for Standardization 

IUCV 

Inter-User Communication Vehicle 

JES 

Job Entry Subsystem 

JIS 

Japanese Institute of Standards 

JCL 

Job Control Language 

LAN 

Local Area Network 

LAPS 

LAN Adapter Protocol Support 

LCS 

IBM LAN Channel Station 

LPD 

Line Printer Daemon 

LPQ 

Line Printer Query 

LPR 

Line Printer Client 

LPRM 

Line Printer Remove 

LPRMON Line Printer Monitor 

LU 

Logical Unit 

MAC 

Media Access Control 

Mbps 

Megabits per second 

MBps 

Megabytes per second 

MCA 

Micro Channel ® Adapter 

MIB 

Management Information Base 

MIH 

Missing Interrupt Handler 

MILNET Military Network 

MHS 

Message Handling System 

MTU 

Maximum Transmission Unit 

MVS 

Multiple Virtual Storage 

MX 

Mail Exchange 

NCP 

Network Control Program 

NDIS 

Network Driver Interface Specification 

NFS 

Network File System 

NIC 

Network Information Center 

NLS 

National Language Support 

NSFNET National Science Foundation Network 

OS/2 ® Operating System/2 ® 

OSA 

Open Systems Adapter 

OSF 

Open Software Foundation, Inc. 

OSI 

Open Systems Interconnection 

OSIMF/6000 Open Systems Interconnection Messaging and Filing/6000 

OV/MVS OfficeVision/MVS 

OV/VM OfficeVision/VM 

PAD 

Packet Assembly/Disassembly 

PC 

Personal Computer 

PCA 

Parallel Channel Adapter 

PDN 

Public Data Network 

PDU 

Protocol Data Units 

PING 

Packet Internet Groper 



PIOAM 

POP 

PROFS ® 

PSCA 

PSDN 

PU 

PVM 

RACF 

RARP 

REXEC 

REXX 

RFC 

RIP 

RISC 

RPC 

RSCS 

SAA 

SBCS 

SDLC 

SFS 

SLIP 

SMIL 

SMTP 

SNA 

SNMP 

SOA 

SPOOL 

SQL 

TCP 

TCP/IP 

TFTP 

TSO 

TTL 

UDP 

VGA 

VM 

VMCF 

VM/ESA 

VMSES/E 

VTAM ® 

WAN 

XDR 

Parallel I/O Access Method 

Post Office Protocol 

Professional Office Systems 

Personal System Channel Attach 

Packet Switching Data Network 

Physical Unit 

Passthrough Virtual Machine 

Resource Access Control Facility 

Reverse Address Resolution Protocol 

Remote Execution 

Restructured Extended Executor Language 

Request For Comments 

Routing Information Protocol 

Reduced Instruction Set Computer 

Remote Procedure Call 

Remote Spooling Communications Subsystem 

System Application Architecture 

Single Byte Character Set 

Synchronous Data Link Control 

Shared File System 

Serial Line Internet Protocol 

Structure for Management Information 

Simple Mail Transfer Protocol 

Systems Network Architecture 

Simple Network Management Protocol 

Start of Authority 

Simultaneous Peripheral Operations Online 

IBM Structured Query Language 

Transmission Control Protocol 

Transmission Control Protocol/Internet Protocol 

Trivial File Transfer Protocol 

Time Sharing Option 

Time-to-Live 

User Datagram Protocol 

Video Graphic Array 

Virtual Machine 

Virtual Machine Communication Facility 

Virtual Machine/Enterprise System Architecture 

Virtual Machine Serviceability Enhancements Staged/Extended 

Virtual Telecommunications Access Method 

Wide Area Network 

eXternal Data Representation 

Appendix I. Abbreviations and Acronyms 345



Notices 

IBM may not offer the products, services, or features discussed in this document in 

all countries. Consult your local IBM representative for information on the 

products and services currently available in your area. Any reference to an IBM 

product, program, or service is not intended to state or imply that only that IBM 

product, program, or service may be used. Any functionally equivalent product, 

program, or service that does not infringe any IBM intellectual property right may 

be used instead. However, it is the user’s responsibility to evaluate and verify the 

operation of any non-IBM product, program, or service. 

IBM may have patents or pending patent applications covering subject matter 

described in this document. The furnishing of this document does not give you 

any license to these patents. You can send license inquiries, in writing, to: 

IBM Director of Licensing 


North Castle Drive 

Armonk, NY 10594-1785 

U.S.A. 

For license inquiries regarding double-byte (DBCS) information, contact the IBM 

Intellectual Property Department in your country or send inquiries, in writing, to: 

IBM World Trade Asia Corporation 

Licensing 

2-31 Roppongi 3-chome, Minato-ku 

Tokyo 106, Japan 

The following paragraph does not apply to the United Kingdom or any other 

country where such provisions are inconsistent with local law: 

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS 

PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER 

EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 

WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS 

FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or 

implied warranties in certain transactions, therefore, this statement may not apply 

to you. 

This information could include technical inaccuracies or typographical errors. 

Changes are periodically made to the information herein; these changes will be 

incorporated in new editions of the publication. IBM may make improvements 

and/or changes in the product(s) and/or the program(s) described in this 

publication at any time without notice. 

Any references in this information to non-IBM Web sites are provided for 

convenience only and do not in any manner serve as an endorsement of those Web 

sites. The materials at those Web sites are not part of the materials for this IBM 

product and use of those Web sites is at your own risk. 

IBM may use or distribute any of the information you supply in any way it 

believes appropriate without incurring any obligation to you. 


Licensees of this program who wish to have information about it for the purpose 

of enabling: (i) the exchange of information between independently created 

programs and other programs (including this one) and (ii) the mutual use of the 

information which has been exchanged, should contact: 


Mail Station P300 

2455 South Road 

Poughkeepsie, NY 12601-5400 

U.S.A. 

Attention: Information Request 

Such information may be available, subject to appropriate terms and conditions, 

including in some cases, payment of a fee. 

The licensed program described in this information and all licensed material 

available for it are provided by IBM under terms of the IBM Customer Agreement, 

IBM International Program License Agreement, or any equivalent agreement 

between us. 

Any performance data contained herein was determined in a controlled 

environment. Therefore, the results obtained in other operating environments may 

vary significantly. Some measurements may have been made on development-level 

systems and there is no guarantee that these measurements will be the same on 

generally available systems. Furthermore, some measurement may have been 

estimated through extrapolation. Actual results may vary. Users of this document 

should verify the applicable data for their specific environment. 

Information concerning non-IBM products was obtained from the suppliers of 

those products, their published announcements, or other publicly available sources. 

IBM has not tested those products and cannot confirm the accuracy of 

performance, compatibility, or any other claims related to non-IBM products. 

Questions on the capabilities of non-IBM products should be addressed to the 

suppliers of those products. 

All statements regarding IBM’s future direction or intent are subject to change or 

withdrawal without notice, and represent goals and objectives only. 

This information may contain examples of data and reports used in daily business 

operations. To illustrate them as completely as possible, the examples include the 

names of individuals, companies, brands, and products. All of these names are 

fictitious and any similarity to the names and addresses used by an actual business 

enterprise is entirely coincidental. 

COPYRIGHT LICENSE: 

This information may contain sample application programs in source language, 

which illustrates programming techniques on various operating platforms. You 

may copy, modify, and distribute these sample programs in any form without 

payment to IBM, for the purposes of developing, using, marketing, or distributing 

application programs conforming to IBM’s application programming interfaces. 

These examples have not been thoroughly tested under all conditions. IBM, 

therefore, cannot guarantee or imply reliability, serviceability, or function of these 

programs. 


Trademarks 

The following terms are trademarks of the International Business Machines 

Corporation in the United States, or other countries, or both: 

AIX 

APL2 

Advanced Peer-to-Peer Networking 

APPN 

AS/400 

BookManager 

CUA 

Common User Access 

DB2 DATABASE 2 

DirMaint 

DFSMS/VM 

DYNIX/ptx 

ESCON 

GDDM 

IBM 

Language Environment 

IBMLink 

Micro Channel 

MVS 

MVS/ESA 

MVS/XA 

NetView 

OfficeVision 

OfficeVision/VM 

OpenEdition 

Operating System/2 

OpenExtensions 

OS/390 

OS/2 

PROFS 

Presentation Manager 

RISC System/6000 

RACF 

S/370 RS/6000 

SQL/DS S/390 

System/390 

System/370 

Tivoli 

VTAM 

z/VM 

z/Series 

Microsoft, Windows, Windows 95, Windows NT, and the Windows logo are 

trademarks of Microsoft Corporation in the United States or other countries. 

UNIX is a registered trademark in the United States or other countries licensed 

exclusively through X/Open Company Limited. 

Other company, product, and service names may be trademarks or service marks 

of others. 

Notices 349


Glossary 

This glossary describes the most common terms 

associated with TCP/IP communication in an 

internet environment, as used in this book. 

If you do not find the term you are looking for, 

see the IBM Dictionary of Computing, New York: 

McGraw-Hill, 1994. 

For abbreviations, the definition usually consists 

only of the words represented by the letters; for 

complete definitions, see the entries for the 

words. 

Numerics 

3172. IBM Interconnect Controller. 

3174. IBM Establishment Controller. 

3270. Refers to a series of IBM display devices; for 

example, the IBM 3275, 3276 Controller Display Station, 

3277, 3278, and 3279 Display Stations, the 3290 

Information Panel, and the 3287 and 3286 printers. A 

specific device type is used only when a distinction is 

required between device types. Information about 

display terminal usage also refers to the IBM 3138, 

3148, and 3158 Display Consoles when used in display 

mode, unless otherwise noted. 

37xx Communication Controller. A network interface 

used to connect a TCP/IP for z/VM or z/OS network 

that supports X.25 connections. NCP with X.25 NPSI 

must be running in the controller, and VTAM must be 

running on the host. 

6611. IBM Network Processor. 

8232. IBM LAN Station. 

9370. Refers to a series of processors, namely the IBM 

9373 Model 20, the IBM 9375 Models 40 and 60, and 

the IBM 9377 Model 90 and other models. 

A 

abend. 

task. 

The abnormal termination of a program or 

abstract syntax. A description of a data structure that 

is independent of machine-oriented structures and 

encodings. 

Abstract Syntax Notation One (ASN.1). 

language for describing abstract syntax. 

The OSI 

active gateway. A gateway that is treated like a 

network interface in that it is expected to exchange 

routing information, and if it does not do so for a 

period of time, the route associated with the gateway is 

deleted. 

active open. The state of a connection that is actively 

seeking a service. Contrast with passive open. 

adapter. A piece of hardware that connects a computer 

and an external device. An auxiliary device or unit 

used to extend the operation of another system. 

address. The unique code assigned to each device or 

workstation connected to a network. A standard 

internet address uses a two-part, 32-bit address field. 

The first part of the address field contains the network 

address; the second part contains the local address. 

address mask. A bit mask used to select bits from an 

Internet address for subnet addressing. The mask is 32 

bits long and selects the network portion of the Internet 

address and one or more bits of the local portion. It is 

sometimes called a subnet mask. 

address resolution. A means for mapping network 

layer addresses onto media-specific addresses. See ARP. 

Address Resolution Protocol (ARP). A protocol used 

to dynamically bind an internet address to a hardware 

address. ARP is implemented on a single physical 

network and is limited to networks that support 

broadcast addressing. 

address space. A collection of bytes that are allocated, 

and in many ways managed, as a single entity by CP. 

Each byte within an address space is identified by a 

unique address. An address space represents an extent 

of storage available to a program. Address spaces 

allocated by VM range in size from 64KB to 2GB. 

Advanced Interactive Executive (AIX). 

version of the UNIX operating system. 

IBM’s licensed 

Advanced Program-to-Program Communications 

(APPC). The interprogram communication service 

within SNA LU 6.2 on which the APPC/VM interface 

is based. 

Advanced Research Projects Agency (ARPA). Now 

called DARPA, its the U.S. Government agency that 

funded the ARPANET. 

Advanced Research Projects Agency Network 

(ARPANET). A packet switched network developed in 

the early 1970’s that is the forerunner of today’s 

Internet. It was decommissioned in June 1990. 


agent. As defined in the SNMP architecture, an agent, 

or an SNMP server is responsible for performing the 

network management functions requested by the 

network management stations. 

AIX. 

Advanced Interactive Executive. 

American National Standard Code for Information 

Interchange (ASCII). The standard code, using a 

coded character set consisting of 7-bit coded characters 

(8 bits including parity check), used for information 

interchange among data processing systems, data 

communication systems, and associated equipment. The 

ASCII set consists of control characters and graphic 

characters. The default file transfer type for FTP, used 

to transfer files that contain ASCII text characters. 

American National Standards Institute (ANSI). An 

organization consisting of producers, consumers, and 

general interest groups that establishes the procedures 

by which accredited organizations create and maintain 

voluntary industry standards in the United States. 

ANSI is sponsored by the Computer and Business 

Equipment Manufacturer Association and is responsible 

for establishing voluntary industry standards. 

ANSI. 

API. 

American National Standards Institute. 

Application Program Interface. 

APPC. Advanced Program-to-Program 

Communications. 

application. The use to which an information 

processing system is put, for example, a payroll 

application, an airline reservation application, a 

network application. 

application layer. The seventh layer of the OSI (Open 

Systems Interconnection) model for data 

communication. It defines protocols for user or 

application programs. 

Application Program Interface (API). The formally 

defined programming-language interface between an 

IBM system control program or licensed program and 

its user. APIs allow programmers to write application 

programs that use the TCP, UDP, and IP layers of the 

TCP/IP protocol suite. 

argument. A parameter passed between a calling 

program and a called program. 

ARP. 

ARPA. 

ARPANET. 

Network. 

Address Resolution Protocol. 

Advanced Research Projects Agency. 

Advanced Research Projects Agency 

ASCII. American National Standard Code for 

Information Interchange. The default file transfer type 

for FTP, used to transfer files that contain ASCII text 

characters. 

ASN.1. 

ASYNC. 

Abstract Syntax Notation One. 

Asynchronous. 

asynchronous (ASYNC). Without regular time 

relationship; unexpected or unpredictable with respect 

to the execution of program instruction. See 

synchronous. 

asynchronous communication. A method of 

communication supported by the operating system that 

allows an exchange of data with remote device, using 

either a start-stop line or an X.25 line. Asynchronous 

communications include the file transfer and the 

interactive terminal facility support. 

Athena Widgets. The X Window widget set developed 

by MIT for Project Athena. 

Attachment Unit Interface (AUI). Connector used 

with thick Ethernet that often includes a drop cable. 

AUI. 

Attachment Unit Interface. 

attention key. A function key on terminals that, when 

pressed, causes an I/O interruption in the processing 

unit. 

authentication server. The service that reads a 

Kerberos database to verify that a client making a 

request for access to an end-service is the client named 

in the request. The authentication server provides an 

authenticated client ticket as permission to access the 

ticket-granting server. 

authenticator. Information encrypted by a Kerberos 

authentication server that a client presents along with a 

ticket to an end-server as permission to access the 

service. 

authorization. The right granted to a user to 

communicate with, or to make use of, a computer 

system or service. 

B 

backbone. In a local area network multiple-bridge 

ring configuration, a high-speed link to which rings are 

connected by means of bridges. A backbone can be 

configured as a bus or as a ring. In a wide area 

network, a high-speed link to which nodes or data 

switching exchanges (DSES) are connected. 

background task. A task with which the user is not 

currently interacting, but continues to run. 

baseband. Characteristic of any network technology 

that uses a single carrier frequency and requires all 

stations attached to the network to participate in every 

transmission. See broadband. 

Basic Encoding Rules (BER). Standard rules for 

encoding data units described in ASN.1. Sometimes 


incorrectly grouped under the term ASN.1, which 

correctly refers only to the abstract description 

language, not the encoding technique. 

Basic Input/Output System (BIOS). A set of routines 

that permanently resides in read-only memory (ROM) 

in a PC. The BIOS performs the most basic tasks, such 

as sending a character to the printer, booting the 

computer, and reading the keyboard. 

batch. An accumulation of data to be processed. A 

group of records or data processing jobs brought 

together for processing or transmission. Pertaining to 

activity involving little or no user action. See interactive 

Bayonet Neill-Concelman (BNC). A standardized 

connector used with Thinnet and coaxial cable. 

Because It’s Time NETwork (BITNET). A network of 

hosts that use the Network Job Entry (NJE) protocol to 

communicate. The network is primarily composed of 

universities, nonprofit organizations, and research 

centers. BITNET has recently merged with the 

Computer and Science Network (CSNET) to form the 

Corporation for Research and Educational Networking 

(CSNET). See CSNET. 

BER. 

Basic Encoding Rules. 

Berkeley Software Distribution (BSD). Term used 

when describing different versions of the Berkeley 

UNIX software, as in “4.3BSD UNIX”. 

BFS. 

Byte File System. 

big-endian. A format for storage or transmission of 

binary data in which the most significant bit (or byte) 

comes first. The reverse convention is little-endian. 

BIOS. 

BITNET. 

Basic Input/Output System. 

Because It’s Time NETwork. 

Blat. A denial-of-service attack in which the TCP/IP 

stack is flooded with SYN packets that have spoofed 

source IP addresses and port numbers that match the 

destination IP addresses and port numbers. The Blat 

attack also has the URG flag turned on in the TCP 

header and has the ability to incrementally spoof the 

source IP address. Blat is a version of the Land attack. 

block. A string of data elements recorded, processed, 

or transmitted as a unit. The elements can be 

characters, words, or physical records. 

blocking mode. If the execution of the program 

cannot continue until some event occurs, the operating 

system suspends the program until that event occurs. 

BNC. 

BOOTPD. 

Bayonet Neill-Concelman. 

Bootstrap Protocol Daemon. 

Bootstrap Protocol Daemon (BOOTPD). The BOOTP 

daemon responds to client requests for boot 

information using information contained in a BOOTP 

machine file. 

bridge. A router that connects two or more networks 

and forwards packets among them. The operations 

carried out by a bridge are done at the physical layer 

and are transparent to TCP/IP and TCP/IP routing. A 

functional unit that connects two local area networks 

(LANs) that use the same logical link control (LLC) 

procedures but may use different medium access 

control (MAC) procedures. 

broadband. Characteristic of any network that 

multiplexes multiple, independent network carriers 

onto a single cable. This is usually done using 

frequency division multiplexing. Broadband technology 

allows several networks to coexist on one single cable; 

traffic from one network does not interfere with traffic 

from another, because the “conversations” happen on 

different frequencies in the ether, similar to a 

commercial radio system. 

broadcast. The simultaneous transmission of data 

packets to all nodes on a network or subnetwork. 

broadcast address. An address that is common to all 

nodes on a network. 

BSD. 

Berkeley Software Distribution. 

bus topology. A network configuration in which only 

one path is maintained between stations. Any data 

transmitted by a station is concurrently available to all 

other stations on the link. 

byte-ordering. The method of sorting bytes under 

specific machine architectures. Of the two common 

methods, little endian byte ordering places the least 

significant byte first. This method is used in Intel** 

microprocessors. In the second method, big endian byte 

ordering, the most significant byte is placed first. This 

method is used in Motorola microprocessors. 

Byte File System (BFS). A file system in which a file 

consists of an ordered sequence of bytes rather than 

records. BFS files can be organized into hierarchical 

directories. Byte file systems are enrolled as file spaces 

in CMS file pools. 

C 

Carrier Sense Multiple Access with Collision 

Detection (CSMA/CD). The access method used by 

local area networking technologies such as Ethernet. 

case-sensitive. A condition in which entries for an 

entry field must conform to a specific lowercase, 

uppercase, or mixed-case format to be valid. 

Glossary 353

CCITT. Comite Consultatif International 

Telegraphique et Telephonique. 

CEC.. 

Central Electronics Complex. 

channel. A path in a system that connects a processor 

and main storage with an I/O device. 

channel-attached. pertaining to attachment of devices 

directly by data channels (I/O channels)to a computer. 

Pertaining to devices attached to a controlling unit by 

cables, rather than by telecommunication lines. 

Synonymous with local, locally attached. 

checksum. The sum of a group of data associated with 

the group and used for checking purposes. 

CICS. 

Customer Information Control System. 

Class A network. An internet network in which the 

high-order bit of the address is 0. The host number 

occupies the three, low-order octets. 

Class B network. An internet network in which the 

high-order bit of the address is 1, and the next 

high-order bit is 0. The host number occupies the two 

low-order octets. 

Class C network. An internet network in which the 

two high-order bits of the address are 1 and the next 

high-order bit is 0. The host number occupies the 

low-order octet. 

CLAW. 

Common Link Access to Workstation. 

client. A function that requests services from a server, 

and makes them available to the user. In z/OS, an 

address space that is using TCP/IP services. 

client-server model. A common way to describe 

network services and the model user processes 

(programs) of those services. Examples include the 

name server and resolver paradigm of the DNS and file 

server/file client relationships such as NFS and diskless 

hosts. 

client-server relationship. Any device that provides 

resources or services to other devices on a network is a 

server. Any device that employs the resources provided 

by a server is a client. A machine can run client and 

server processes at the same time. 

CLIST. 

CLPA. 

CMS. 

Command List. 

Create Link Pack Area. 

Conversational Monitor System. 

Comite Consultatif International Telegraphicque et 

Telephonique (CCITT). The International Telegraph 

and Telephone Consultative Committee. A unit of the 

International Telecommunications Union (ITU) of the 

United Nations. CCITT produces technical standards, 

known as “recommendations,” for all internationally 

controlled aspects of analog and digital communication. 

command. The name and any parameters associated 

with an action that can be performed by a program. 

The command is entered by the user; the computer 

performs the action requested by the command name. 

Command List (CLIST). A list of commands and 

statements designed to perform a specific function for 

the user. 

command prompt. A displayed symbol, such as [C:\] 

that requests input from a user. 

Common Link Access to Workstation (CLAW). A 

continuously executing duplex channel program 

designed to minimize host interrupts while maximizing 

channel utilization. 

communications adapter. A hardware feature that 

enables a computer or device to become a part of a 

data network. 

community name. A password used by hosts running 

Simple Network Management Protocol (SNMP) agents 

to access remote network management stations. 

compile. To translate a program written in a 

high-level language into a machine language program. 

The computer actions required to transform a source 

file into an executable object file. 

compiler. A program that translates a source program 

into an executable program (an object program). 

Computer and Science Network (CSNET). A large 

computer network, mostly in the U.S. but with 

international connections. CSNET sites include 

universities, research labs, and some commercial 

companies. It is now merged with BITNET to form 

CREN. See BITNET. 

connection. An association established between 

functional units for conveying information. The path 

between two protocol modules that provides reliable 

stream delivery service. In an internet, a connection 

extends from a TCP module on one machine to a TCP 

module on the other. 

Control Program (CP). The z/VM operating system 

that manages the real processor’s resources and is 

responsible for simulating select operating systems, 

known as virtual machines for individual users. Each 

virtual machine is the functional equivalent of a real 

machine. 

conversational monitor system (CMS). A virtual 

machine operating system that provides general 

interactive time sharing, problem solving, and program 

development capabilities, and operates only under 

control of the z/VM control program. 


Corporation for Research and Educational 

Networking (CREN). A large computer network 

formed from the merging of BITNET and CSNET. See 

BITNET and CSNET. 

CP. 

Control Program. 

Create Link Pack Area (CLPA). A parameter specified 

at startup, which says to create the link pack area. 

CREN. Corporation for Research and Educational 

Networking. 

CSMA/CD. Carrier Sense Multiple Access with 

Collision Detection. 

CSNET. 

Computer and Science Network. 

Customer Information Control System (CICS). An 

IBM-licensed program that enables transactions entered 

at remote terminals to be processed concurrently by 

user written application programs. It includes facilities 

for building, using, and maintaining databases. 

DBCS. 

DDN. 

Double Byte Character Set. 

Defense Data Network. 

decryption. The unscrambling of data using an 

algorithm that works under the control of a key. The 

key allows data to be protected even when the 

algorithm is unknown. Data is unscrambled after 

transmission. 

default. A value, attribute, or option that is assumed 

when none is explicitly specified. 

Defense Advanced Research Projects Agency 

(DARPA). The U.S. government agency that funded 

the ARPANET. 

Defense Data Network (DDN). Comprises the 

MILNET and several other Department of Defense 

networks. 

destination node. 

is sent. 

The node to which a request or data 

D 

DHCPD. 

Daemon. 

Dynamic Host Configuration Protocol 

daemon. A background process usually started at 

system initialization that runs continuously and 

performs a function required by other processes. Some 

daemons are triggered automatically to perform their 

task; others operate periodically. 

DASD. 

DARPA. 

Direct Access Storage Device. 

Defense Advanced Research Projects Agency. 

DATABASE 2 (DB2). An IBM relational database 

management system for the z/OS operating system. 

database administrator (DBA). An individual or 

group responsible for the rules by which data is 

accessed and stored. The DBA is usually responsible for 

database integrity, security, performance and recovery. 

datagram. A basic unit of information that is passed 

across the internet, it consists of one or more data 

packets. 

data link layer. Layer 2 of the OSI (Open Systems 

Interconnection) model; it defines protocols governing 

data packetizing and transmission into and out of each 

node. 

data set. The major unit of data storage and retrieval 

in z/OS, consisting of a collection of data in one of 

several prescribed arrangements and described by 

control information to which the system has access. 

Synonymous with file in z/VM. 

DB2. DATABASE 2. 

Direct Access Storage Device (DASD). A device in 

which access to data is independent of where data 

resides on the device. 

directory. 

A named grouping of files in a file system. 

Disk Operating System (DOS). An operating system 

for computer systems that use disks and diskettes for 

auxiliary storage of programs and data. 

display terminal. An input/output unit by which a 

user communicates with a data-processing system or 

sub-system. Usually includes a keyboard and always 

provides a visual presentation of data; for example, an 

IBM 3179 display. 

Distributed Program Interface (DPI). A programming 

interface that provides an extension to the function 

provided by the SNMP agents. 

DLL. 

DNS. 

Dynamic Link Library. 

Domain Name System. 

domain. In an internet, a part of the naming hierarchy. 

Syntactically, a domain name consists of a sequence of 

names (labels) separated by periods (dots). 

Domain Name System (DNS). A system in which a 

resolver queries name servers for resource records 

about a host. 

domain naming. A hierarchical system for naming 

network resources. 

DBA. 

Database administrator. 

DoS. 

Denial-of-Service. 

DOS. 

Disk Operating System. 

Glossary 355

dotted-decimal notation. The syntactic representation 

for a 32-bit integer that consists of four 8-bit numbers, 

written in base 10 and separated by periods (dots). 

Many internet application programs accept dotted 

decimal notations in place of destination machine 

names. 

double-byte character set (DBCS). A set of characters 

in which each character is represented by two bytes. 

Languages such as Japanese, Chinese, Korean, which 

contain more symbols than can be represented by 256 

code points, require double-byte character sets. Because 

each character requires 2 bytes, the typing, display, and 

printing of DBCS characters requires hardware and 

programs that support DBCS. 

doubleword. A contiguous sequence of bits or 

characters that comprises two computer words and is 

capable of being addressed as a unit. 

DPI. 

Distributed Program Interface. 

Dynamic Host Configuration Protocol Daemon 

(DHCPD). The DHCP daemon (DHCPD server) 

responds to client requests for boot information using 

information contained in a DHCP machine file. This 

information includes the IP address of the client, the IP 

address of the TFTP daemon, and information about 

the files to request from the TFTP daemon. 

dynamic resource allocation. An allocation technique 

in which the resources assigned for execution of 

computer programs are determined by criteria applied 

at the moment of need. 

dynamic link library (DLL). A module containing 

dynamic link routines that is linked at load or run time. 

E 

EBCDIC. 

code. 

EGP. 

Extended binary-coded decimal interchange 

Exterior Gateway Protocol. 

encapsulation. A process used by layered protocols in 

which a lower-level protocol accepts a message from a 

higher-level protocol and places it in the data portion 

of the low-level frame. As an example, in Internet 

terminology, a packet would contain a header from the 

physical layer, followed by a header from the network 

layer (IP), followed by a header from the transport 

layer (TCP), followed by the application protocol data. 

encryption. The scrambling or encoding of data using 

an algorithm that works under the control of a key. The 

key allows data to be protected even when the 

algorithm is unknown. Data is scrambled prior to 

transmission. 

ES/9370 Integrated Adapters. An adapter you can use 

in TCP/IP for VM to connect into Token-Ring networks 

and Ethernet networks, as well as TCP/IP networks 

that support X.25 connections. 

Ethernet. The name given to a local area 

packet-switched network technology invented in the 

early 1970s by Xerox**, Incorporated. Ethernet uses a 

Carrier Sense Multiple Access/Collision Detection 

(CSMA/CD) mechanism to send packets. 

EXEC. In a VM operating system, a user-written 

command file that contains CMS commands, other 

user-written commands, and execution control 

statements, such as branches. 

extended binary-coded decimal interchange code 

(EBCDIC). A coded character set consisting of 8-bit 

coded characters. 

extended character. A character other than a 7-bit 

ASCII character. An extended character can be a 1-bit 

code point with the 8th bit set (ordinal 128-255) or a 

2-bit code point (ordinal 256 and greater). 

Exterior Gateway Protocol (EGP). A reachability 

routing protocol used by gateways in a two-level 

internet. 

eXternal Data Representation (XDR). A standard 

developed by Sun Microsystems, Incorporated for 

representing data in machine-independent format. 

F 

FAT. 

File Allocation Table. 

FDDI. Fiber Distributed Data Interface. Also used to 

abbreviate Fiber Optic Distributed Data Interface. 

Fiber Distributed Data Interface (FDDI). The ANSI 

standard for high-speed transmission over fiber optic 

cable. 

Fiber Optic Network. A network based on the 

technology and standards that define data transmission 

using cables of glass or plastic fibers carrying visible 

light. Fiber optic network advantages are: higher 

transmission speeds, greater carrying capacity, and 

lighter, more compact cable. 

file. In z/VM, a named set of records stored or 

processed as a unit. Synonymous with data set in z/OS. 

File Allocation Table (FAT). 

space on a disk for a file. 

A table used to allocate 

File Transfer Access and Management (FTAM). An 

application service element that enables user 

application processes to manage and access a file 

system, which may be distributed. 

File Transfer Protocol (FTP). A TCP/IP protocol used 

for transferring files to and from foreign hosts. FTP also 


provides the capability to access directories. Password 

protection is provided as part of the protocol. 

foreign host. Any machine on a network that can be 

interconnected. 

foreign network. In an internet, any other network 

interconnected to the local network by one or more 

intermediate gateways or routers. 

foreign node. 

See foreign host. 

Fraggle. A denial-of-service attack in which a UDP 

Echo Request is sent to a broadcast or multicast 

address. 

frame. The portion of a tape on a line perpendicular 

to the reference edge, on which binary characters can 

be written or read simultaneously. 

FTAM. 

FTP. 

fullword. 

4 bytes. 

G 

File Transfer Access and Management. 

File Transfer Protocol. 

A computer word. In System/370, 32 bits or 

gadget. A windowless graphical object that looks like 

its equivalent like-named widget but does not support 

the translations, actions, or pop-up widget children 

supplied by that widget. 

gateway. A functional unit that interconnects a local 

data network with another network having different 

protocols. A host that connects a TCP/IP network to a 

non-TCP/IP network at the application layer. See also 

router. 

gather and scatter data. Two related operations. 

During the gather operation, data is taken from 

multiple buffers and transmitted. In the scatter 

operation, data is received and stored in multiple 

buffers. 

GC. 

GContext. 

GCS. 

GDDM. 

Graphics Context. 

See Graphics Context. 

Group Control System. 

Graphical Data Display Manager. 

GDDMXD. Graphical Data Display Manager interface 

for X Window System. A graphical interface that 

formats and displays alphanumeric, data, graphics, and 

images on workstation display devices that support the 

X Window System. 

GDF. 

Graphics data file. 

Graphical Display Data Manager (GDDM). A group 

of routines that allows pictures to be defined and 

displayed procedurally through function routines that 

correspond to graphic primitives. 

Graphics Context (GC). The storage area for graphics 

output. Also known as GC and GContext. Used only 

with graphics that have the same root and depth as the 

graphics content. 

Group Control System (GCS) . A component of 

VM/ESA, consisting of a shared segment that you can 

Initial Program Load (IPL) and run in a virtual 

machine. It provides simulated z/OS or OS/390services 

and unique supervisor services to help support a native 

SNA network. 

H 

handle. A temporary data representation that 

identifies a file. 

halfword. A contiguous sequence of bits or characters 

that constitutes half a fullword and can be addressed as 

a unit. 

HASP. 

HDLC. 

Houston automatic spooling priority system. 

High-level Data Link Control. 

header file. A file that contains constant declarations, 

type declarations, and variable declarations and 

assignments. Header files are supplied with all 

programming interfaces. 

High-level Data Link Control (HDLC). An ISO 

protocol for X.25 international communication. 

High Performance File System (HPFS). An OS/2 file 

management system that supports high-speed buffer 

storage, long file names, and extended attributes. 

HiperSockets. A hardware feature that provides high 

performance internal communications between LPARs 

within the same CEC. 

hop count. The number of gateways or routers 

through which a packet passes on its way to its 

destination. 

host. A computer connected to a network, which 

provides an access method to that network. A host 

provides end-user services and can be a client, a server, 

or a client and server simultaneously. 

Houston automatic spooling priority system (HASP). 

A computer program that provides supplementary job 

management, data management, and task management 

functions such as control of job flow, ordering of tasks, 

and spooling. 

HPFS. 

High Performance File System. 

HYPERchannel Adapter. A network interface used to 

connect a TCP/IP for z/VM or z/OS host into an 

Glossary 357

existing TCP/IP HYPERchannel network, or to connect 

TCP/IP hosts together to create a TCP/IP 

HYPERchannel network. 

I 

IAB. 

ICMP. 

IEEE. 

IETF. 

IGMP. 

IGP. 

Internet Activities Board. 

Internet Control Message Protocol. 

Institute of Electrical and Electronic Engineers. 

Internet Engineering Task Force. 

Internet Group Management Protocol (IGMP). 

Interior Gateway Protocol. 

include file. A file that contains preprocessor text, 

which is called by a program, using a standard 

programming call. Synonymous with header file. 

IMAP. 

IMS. 

Internet Message Access Protocol.. 

Information Management System. 

Information Management System (IMS). A 

database/data communication (DB/DC) system that 

can manage complex databases and networks. 

initial program load (IPL). The initialization 

procedure that causes an operating system to 

commence operation. 

instance. Indicates a label that is used to distinguish 

among the variations of the principal name. An instance 

allows for the possibility that the same client or service 

can exist in several forms that require distinct 

authentication. 

Institute of Electrical and Electronic Engineers 

(IEEE). An electronics industry organization. 

Integrated Services Digital Network (ISDN). A 

digital, end-to-end telecommunication network that 

supports multiple services including, but not limited to, 

voice and data. 

interactive. Pertaining to a program or a system that 

alternately accepts input and then responds. An 

interactive system is conversational; that is, a 

continuous dialog exists between user and system. See 

batch. 

Interior Gateway Protocol (IGP). The protocol used to 

exchange routing information between collaborating 

routers in the Internet. RIP is an example of an IGP. 

Internet. The largest internet in the world consisting 

of large national backbone nets (such as MILNET, 

NSFNET, and CREN) and a myriad of regional and 

local campus networks all over the world. The Internet 

uses the Internet protocol suite. To be on the Internet, 

you must have IP connectivity (be able to TELNET to, 

or PING, other systems). Networks with only electronic 

mail connectivity are not actually classified as being on 

the Internet. 

Internet Activities Board (IAB). The technical body 

that oversees the development of the Internet suite of 

protocols (commonly referred to as TCP/IP). It has two 

task forces (the IRTF and the IETF) each charged with 

investigating a particular area. 

Internet address. A 32-bit address assigned to hosts 

using TCP/IP. An internet address consists of a 

network number and a local address. Internet addresses 

are represented in a dotted-decimal notation and are 

used to route packets through the network. 

Internet Engineering Task Force (IETF). One of the 

task forces of the IAB. The IETF is responsible for 

solving short-term engineering needs of the Internet. 

International Organization for Standardization (ISO). 

An organization of national standards bodies from 

various countries established to promote development 

of standards to facilitate international exchange of 

goods and services, and develop cooperation in 

intellectual, scientific, technological, and economic 

activity. 

internet or internetwork. A collection of packet 

switching networks interconnected by gateways, 

routers, bridges, and hosts to function as a single, 

coordinated, virtual network. 

internet address. The unique 32-bit address 

identifying each node in an internet. See also address. 

Internet Control Message Protocol (ICMP). The part 

of the Internet Protocol layer that handles error 

messages and control messages. 

Internet Group Management Protocol (IGMP). 

is used by IP hosts to report their host group 

memberships to multicast routers. 

IGMP 

Internet Protocol (IP). The TCP/IP layer between the 

higher level host-to-host protocol and the local network 

protocols. IP uses local area network protocols to carry 

packets, in the form of datagrams, to the next gateway, 

router, or destination host. 

interoperability. The capability of different hardware 

and software by different vendors to effectively 

communicate together. 

Inter-user communication vehicle (IUCV). AVM 

facility for passing data between virtual machines and 

VM components. 

intrinsics X-Toolkit. A set management mechanism 

that provides for constructing and interfacing between 

composite X Window widgets, their children, and other 


clients. Also, intrinsics provide the ability to organize a 

collection of widgets into an application. 

IP. 

Internet Protocol. 

IP datagram. The fundamental unit of information 

passed across the Internet. An IP datagram contains 

source and destination addresses along with data and a 

number of fields that define such things as the length 

of the datagram, the header checksum, and flags to say 

whether the datagram can be (or has been) fragmented. 

IPL. 

ISDN. 

ISO. 

IUCV. 

J 

JCL. 

JES. 

JIS. 

Initial Program Load. 

Integrated Services Digital Network. 

International Organization for Standardization. 

Inter-User Communication Vehicle. 

Job Control Language. 

Job Entry Subsystem. 

Japanese Institute of Standards. 

Job Control Language (JCL). A problem-oriented 

language designed to express statements in a job that 

are used to identify the job or describe its requirements 

to an operating system. 

Job Entry Subsystem (JES). An IBM System/370 

licensed program that receives jobs into the system and 

processes all output data produced by the jobs. 

JUNET. The Japanese Academic and Research 

Network that connects various UNIX operating 

systems. 

K 

Kanji. A graphic character set consisting of symbols 

used in Japanese ideographic alphabets. Each character 

is represented by 2 bytes. 

katakana. A character set of symbols used on one of 

the two common Japanese phonetic alphabets, which is 

used primarily to write foreign words phonetically. See 

also kanji. 

Kerberos. A system that provides authentication 

service to users in a network environment. 

Kerberos Authentication System. An authentication 

mechanism used to check authorization at the user 

level. 

Kiss-of-Death (KOD). An IGMP based 

denial-of-service attack that depletes the stack’s large 

envelopes. See KOX. 

KOD. 

Kiss-of-Death. 

KOX. An IGMP based denial-of-service attack that 

depletes the stack’s large envelopes and also has source 

IP address spoofing. KOX is a version of the 

Kiss-of-Death (KOD) attack. 

L 

LaMail. The client that communicates with the OS/2 

Presentation Manager to manage mail on the network. 

LAN. 

Local area network. 

Land. A denial-of-service attack in which the TCP/IP 

stack is flooded with SYN packets that have spoofed 

source IP addresses and port numbers that match the 

destination IP addresses and port numbers. See Blat. 

Line Printer Client (LPR). A client command that 

allows the local host to submit a file to be printed on a 

remote print server. 

Line Printer Daemon (LPD). The remote printer 

server that allows other hosts to print on a printer local 

to your host. 

little-endian. A format for storage or transmission of 

binary data in which the least significant bit (or byte) 

comes first. The reverse convention is big-endian. 

local area network (LAN). A data network located on 

the user’s premises in which serial transmission is used 

for direct data communication among data stations. 

local host. In an internet, the computer to which a 

user’s terminal is directly connected without using the 

internet. 

local network. The portion of a network that is 

physically connected to the host without intermediate 

gateways or routers. 

logical character delete symbol. A special editing 

symbol, usually the at (@) sign, which causes CP to 

delete it and the immediately preceding character from 

the input line. If many delete symbols are consecutively 

entered, the same number of preceding characters are 

deleted from the input line. 

Logical Unit (LU). An entity addressable within an 

SNA-defined network. LUs are categorized by the types 

of communication they support. 

LPD. 

LPR. 

LU. 

Line Printer Daemon. 

Line Printer Client. 

Logical Unit. 

Glossary 359

LU-LU session. In SNA, a session between two logical 

units (LUs). It provides communication between two 

end users, or between an end user and an LU services 

component. 

LU type. In SNA, the classification of an LU-LU 

session in terms of the specific subset of SNA protocols 

and options supported by the logical units (LUs) for 

that session. 

M 

MAC. 

Media Access Control. 

mail gateway. A machine that connects two or more 

electronic mail systems (often different mail systems on 

different networks) and transfers messages between 

them. 

Management Information Base (MIB). A standard 

used to define SNMP objects, such as packet counts 

and routing tables, that are in a TCP/IP environment. 

mapping. The process of relating internet addresses to 

physical addresses in the network. 

mask. A pattern of characters used to control retention 

or elimination of portions of another pattern of 

characters. To use a pattern of characters to control 

retention or elimination of another pattern of 

characters. A pattern of characters that controls the 

keeping, deleting, or testing of portions of another 

pattern of characters. 

Maximum Transmission Unit (MTU). The largest 

possible unit of data that can be sent on a given 

physical medium. 

media access control (MAC). The method used by 

network adapters to determine which adapter has 

access to the physical network at a given time. 

Message Handling System (MHS). The system of 

message user agents, message transfer agents, message 

stores, and access units that together provide OSI 

electronic mail. 

MHS. 

MIB. 

Message Handling System. 

Management Information Base. 

microcode. A code, representing the instructions of an 

instruction set, which is implemented in a part of 

storage that is not program-addressable. 

MILNET. 

Military Network. 

Military Network (MILNET). Originally part of the 

ARPANET, MILNET was partitioned in 1984 to make it 

possible for military installations to have reliable 

network service, while the ARPANET continued to be 

used for research. See DDN. 

minidisk. Logical divisions of a physical direct access 

storage device. 

modem (modulator/demodulator). A device that 

converts digital data from a computer to an analog 

signal that can be transmitted on a telecommunication 

line, and converts the analog signal received to data for 

the computer. 

Motif. 

see OSF/Motif. 

mouse. An input device that is used to move a pointer 

on the screen and select items. 

MPROUTE. Multiple Protocol Routing. Implements 

the OSPF protocol described in RFC 1583, 1058, and 

1723. 

MTU. 

Maximum Transmission Unit. 

multicast. The simultaneous transmission of data 

packets to a group of selected nodes on a network or 

subnetwork. 

multiconnection server. A server that is capable of 

accepting simultaneous, multiple connections. 

Multiple Virtual Storage (MVS). Implies the 

MVS/ESA, and follow-on OS/390 and z/OS products. 

multitasking. A mode of operation that provides for 

the concurrent performance execution of two or more 

tasks. 

MVS. 

N 

name server. 

about hosts. 

Multiple Virtual Storage. 

The server that stores resource records 

National Science Foundation (NSF). 

NSFNET. 

Sponsor of the 

National Science Foundation Network (NSFNET). A 

collection of local, regional, and mid-level networks in 

the U.S. tied together by a high-speed backbone. 

NSFNET provides scientists access to a number of 

supercomputers across the country. 

NCP. 

NDB. 

NDIS. 

Network Control Program. 

Network Database. 

Network Driver Interface Specification. 

Netman. This device keyword specifies that this 

device is a 3172 LAN Channel Station that supports 

IBM Enterprise-Specific SNMP Management 

Information Base (MIB) variables for 3172. TCP/IP for 

VM supports SNMP GET and SNMP GETNEXT 

operations to request and retrieve 3172 

Enterprise-Specific MIB variables. These requests are 


answered only by those 3172 devices with the 

NETMAN option in the PROFILE TCPIP file. 

NetView. A system 390-based, IBM-licensed program 

used to monitor, manage, and diagnose the problems of 

a network. 

network. An arrangement of nodes and connecting 

branches. Connections are made between data stations. 

Physical network refers to the hardware that makes up 

a network. Logical network refers to the abstract 

organization overlaid on one or more physical 

networks. An internet is an example of a logical 

network. 

network adapter. A physical device, and its associated 

software, that enables a processor or controller to be 

connected to a network. 

network administrator. The person responsible for the 

installation, management, control, and configuration of 

a network. 

Network Control Program (NCP). An IBM-licensed 

program that provides communication controller 

support for single-domain, multiple-domain, and 

interconnected network capability. 

network database (NDB). An IBM-licensed program 

that provides communication controller support for 

single-domain, multiple-domain, and interconnected 

network capability. NDB allows interoperability among 

different database systems, and uses RPC protocol with 

a client/server type of relationship. NDB is used for 

data conversion, security, I/O buffer management, and 

transaction management. 

Network Driver Interface Specification (NDIS). An 

industry-standard specification used by applications as 

an interface with network adapter device drivers. 

network elements. As defined in the SNMP 

architecture, network elements are gateways, routers, 

and hosts that contain management agents responsible 

for performing the network management functions 

requested by the network management stations. 

network file system (NFS). The NFS protocol, which 

was developed by Sun Microsystems, Incorporated, 

allows computers in a network to access each other’s 

file systems. Once accessed, the file system appears to 

reside on the local host. 

Network Information Center (NIC). Originally there 

was only one, located at SRI International and tasked to 

serve the ARPANET (and later DDN) community. 

Today, there are many NICs operated by local, regional, 

and national networks all over the world. Such centers 

provide user assistance, document service, training, and 

more. 

Network Job Entry (NJE). In object distribution, an 

entry in the network job table that specifies the system 

action required for incoming network jobs sent by a 

particular user or group of users. Each entry is 

identified by the user ID of the originating user or 

group. 

network layer. Layer 3 of the Open Systems 

Interconnection (OSI) model; it defines protocols 

governing data routing. 

network management stations. As defined in the 

SNMP architecture, network management stations, or 

SNMP clients, execute management applications that 

monitor and control network elements. 

NFS. 

NIC. 

NJE. 

Network file system. 

Network Information Center. 

Network Job Entry. 

node. In a network, a point at which one or more 

functional units connect channels or data circuits. In a 

network topology, the point at an end of a branch. 

nonblocking mode. If the execution of the program 

cannot continue until some event occurs, the operating 

system does not suspend the program until that event 

occurs. Instead, the operating system returns an error 

message to the program. 

NPSI. 

NSF. 

NSFNET. 

O 

octet. 

X.25 NCP Packet Switching Interface. 

National Science Foundation. 

National Science Foundation Network. 

A byte composed of eight binary elements. 

Offload host. Any device that is handling the TCP/IP 

processing for the z/OS host where TCP/IP for MVS is 

installed. Currently, the only supported Offload host is 

the 3172-3. 

Offload system. Represents both the z/OS host where 

TCP/IP for z/OS is installed and the Offload host that 

is handling the TCP/IP Offload processing. 

open system. A system with specified standards and 

that therefore can be readily connected to other systems 

that comply with the same standards. 

Open Systems Interconnection (OSI). The 

interconnection of open systems in accordance with 

specific ISO standards. The use of standardized 

procedures to enable the interconnection of data 

processing systems. 

Operating System/2 (OS/2). Pertaining to the IBM 

licensed program that can be used as the operating 

system for personal computers. The OS/2 licensed 

program can perform multiple tasks at the same time. 

Glossary 361

OS/2. 

Operating System/2. 

PDU. 

Protocol data unit. 

OSF/Motif. OSF/Motif is an X Window System toolkit 

defined by Open Software Foundation, Inc. (OSF), 

which enables the application programmer to include 

standard graphic elements that have a 3-D appearance. 

Performance of the graphic elements is increased with 

gadgets and windowless widgets. 

OSI. 

Open Systems Interconnection. 

OSPF. Open Shortest Path First. An Interior Gateway 

Protocol that distributes routing information within a 

single Autonomous System. 

out-of-band data. Data that is placed in a secondary 

channel for transmission. Primary and secondary 

communication channels are created physically by 

modulation on a different frequency, or logically by 

specifying a different logical channel. A primary 

channel can have a greater capacity than a secondary 

one. 

OV. 

P 

OfficeVision. 

packet. A sequence of binary digits, including data 

and control signals, that is transmitted and switched as 

a composite whole. 

Packet Switching Data Network (PSDN). A network 

that uses packet switching as a means of transmitting 

data. 

parameter. A variable that is given a constant value 

for a specified application. 

parse. To analyze the operands entered with a 

command. 

passive open. The state of a connection that is 

prepared to provide a service on demand. Contrast 

with active open. 

Partitioned data set (PDS). A data set in direct access 

storage that is divided into partitions, called members, 

each of which can contain a program, part of a 

program, or data. 

PC. 

PCA. 

Personal computer. 

Personal Channel Attach. 

PC Network. A low-cost, broadband network that 

allows attached IBM personal computers, such as IBM 

5150 Personal Computers, IBM Computer ATs, IBM 

PC/XTs, and IBM Portable Personal Computers to 

communicate and to share resources. 

peer-to-peer. In network architecture, any functional 

unit that resides in the same layer as another entity. 

Personal Channel Attach (PCA). 

Channel Attach. 

see Personal System 

Personal Computer (PC). A microcomputer primarily 

intended for stand-alone use by an individual. 

Personal System Channel Attach (PSCA). An adapter 

card to connect a micro-channel based personal 

computer (or processor) to a System/370 parallel 

channel. 

physical layer. Layer 1 of the Open Systems 

Interconnection (OSI) model; it details protocols 

governing transmission media and signals. 

physical unit (PU). In SNA, the component that 

manages and monitors the resources, such as attached 

links and adjacent link stations, associated with a node, 

as requested by an SSPC via an SSPC-PU session. An 

SSPC activates a session with the physical unit in order 

to indirectly manage, through the PU, resources of the 

node such as attached links. 

PING. The command that sends an ICMP Echo 

Request packet to a host, gateway, or router with the 

expectation of receiving a reply. 

Ping-o-Death (POD). A denial-of-service attack in 

which huge, fragmented ICMP packets are sent. 

PM. 

Presentation Manager. 

PMANT. In OS/2, the 3270 client terminal emulation 

program that is invoked by the PMANT command. 

polling. On a multipoint connection or a 

point-to-point connection, the process whereby data 

stations are invited one at a time to transmit. 

Interrogation of devices for such purposes as to avoid 

contention, to determine operational status, or to 

determine readiness to send or receive data. 

POP. 

Post Office Protocol. 

port. An endpoint for communication between 

devices, generally referring to a logical connection. A 

16-bit number identifying a particular Transmission 

Control Protocol or User Datagram Protocol resource 

within a given TCP/IP node. 

PORTMAP. 

Synonymous with Portmapper. 

Portmapper. A program that maps client programs to 

the port numbers of server programs. Portmapper is 

used with Remote Procedure Call (RPC) programs. 

PDS. 

PDN. 

Partitioned data set. 

Public Data Network. 

Post Office Protocol (POP). 

exchanging network mail. 

A protocol used for 


presentation layer. Layer 6 of the Open Systems 

Interconnections (OSI) model; it defines protocols 

governing data formats and conversions. 

Presentation Manager (PM). A component of OS/2 

that provides a complete graphics-based user interface, 

with pull-down windows, action bars, and layered 

menus. 

principal name. Specifies the unique name of a user 

(client) or service. 

PostScript. A standard that defines how text and 

graphics are presented on printers and display devices. 

process. A unique, finite course of events defined by 

its purpose or by its effect, achieved under defined 

conditions. Any operation or combination of operations 

on data. A function being performed or waiting to be 

performed. A program in operation; for example, a 

daemon is a system process that is always running on 

the system. 

Professional Office Systems (PROFS). IBM’s 

proprietary, integrated office management system used 

for sending, receiving, and filing electronic mail, and a 

variety of other office tasks. PROFS has been replaced 

by OfficeVision. See OfficeVision. 

PROFS. 

Professional Office Systems. 

protocol. A set of semantic and syntactic rules that 

determines the behavior of functional units in achieving 

communication. Protocols can determine low-level 

details of machine-to-machine interfaces, such as the 

order in which bits from a byte are sent; they can also 

determine high-level exchanges between application 

programs, such as file transfer. 

Protocol data unit (PDU). A set of commands used by 

the SNMP agent to request management station data. 

protocol suite. A set of protocols that cooperate to 

handle the transmission tasks for a data communication 

system. 

PSCA. 

PSDN. 

PU. 

Personal System Channel Attach. 

Packet Switching Data Network. 

Physical unit. 

Public Data Network (PDN). A network established 

and operated by a telecommunication administration or 

by a Recognized Private Operating Agency (RPOA) for 

the specific purpose of providing circuit-switched, 

packet-switched, and leased-circuit services to the 

public. 

Q 

QDIO. 

Queued Direct I/O. 

queue. A line or list formed by items in a system 

waiting for service; for example, tasks to be performed 

or messages to be transmitted. To arrange in, or form, a 

queue. 

R 

R4P3D. A denial-of-service attack in which TCP 

packets are sent to the stack with no header flags set. 

R4P3D is an augmented version of the Stream attack. 

RACF. 

RARP. 

Resource access control facility. 

Reverse Address Resolution Protocol. 

read-only access. An access mode associated with a 

virtual disk directory that lets a user read, but not write 

or update, any file on the disk directory. 

read/write access. An access mode associated with a 

virtual disk directory that lets a user read and write 

any file on the disk directory (if write authorized). 

realm. One of the three parts of a Kerberos name. The 

realm specifies the network address of the principal 

name or instance. This address must be expressed as a 

fully qualified domain name, not as a “dot numeric” 


recursion. A process involving numerous steps, in 

which the output of each step is used for the successive 

step. 

reduced instruction-set computer (RISC). A computer 

that uses a small, simplified set of frequently used 

instructions for rapid execution. 

reentrant. The attribute of a program or routine that 

allows the same copy of a program or routine to be 

used concurrently by two or more tasks. 

Remote Execution Protocol (REXEC). A protocol that 

allows the execution of a command or program on a 

foreign host. The local host receives the results of the 

command execution. This protocol uses the REXEC 

command. 

remote host. A machine on a network that requires a 

physical link to interconnect with the network. 

remote logon. The process by which a terminal user 

establishes a terminal session with a remote host. 

Remote Procedure Call (RPC). A facility that a client 

uses to request the execution of a procedure call from a 

server. This facility includes a library of procedures and 

an eXternal data representation. 

Remote Spooling Communications Subsystem 

(RSCS). An IBM-licensed program that transfers spool 

files, commands, and messages between VM users, 

remote stations, and remote and local batch systems, 

through HASP-compatible telecommunication facilities. 

Glossary 363

Request For Comments (RFC). A series of documents 

that covers a broad range of topics affecting 

internetwork communication. Some RFCs are 

established as internet standards. 

resolver. A program or subroutine that obtains 

information from a name server or local table for use 

by the calling program. 

resource access control facility (RACF). An 

IBM-licensed program that provides for access control 

by identifying and by verifying the users to the system, 

authorizing access to protected resources, logging the 

detected unauthorized attempts to enter the system, 

and logging the detected accesses to protected 

resources. 

resource records. Individual records of data used by 

the Domain Name System. Examples of resource 

records include the following: a host’s Internet Protocol 

addresses, preferred mail addresses, and aliases. 

response unit (RU). In SNA, a message unit that 

acknowledges a request unit. It may contain prefix 

information received in a request unit. If positive, the 

response unit may contain additional information such 

as session parameters in response to BIND SESSION. If 

negative, it contains sense data defining the exception 

condition. 

Restructured Extended Executor (REXX) language. A 

general purpose programming language, particularly 

suitable for EXEC procedures, XEDIT macros, or 

programs for personal computing. Procedures, XEDIT 

macros, and programs written in this language can be 

interpreted by the Procedures Language VM/REXX 

interpreter. 

return code. A code used to influence the execution of 

succeeding instructions. A value returned to a program 

to indicate the results of an operation requested by that 

program. 

Reverse Address Resolution Protocol (RARP). A 

protocol that maintains a database of mappings 

between physical hardware addresses and IP addresses. 

REXEC. 

REXX. 

RFC. 

RIP. 

RISC. 

ROUTED.. 

Remote Execution Protocol. 

Restructured Extended Executor language. 

Request For Comments. 

Routing Information Protocol. 

Reduced instruction-set computer. 

Routing Daemon. 

router. A device that connects networks at the ISO 

Network Layer. A router is protocol-dependent and 

connects only networks operating the same protocol. 

Routers do more than transmit data; they also select the 

best transmission paths and optimum sizes for packets. 

In TCP/IP, routers operate at the Internetwork layer. 

See also gateway. 

Routing Information Protocol (RIP). The protocol that 

maintains routing table entries for gateways, routers, 

and hosts. 

routing table. A list of network numbers and the 

information needed to route packets to each. 

RPC. 

RSCS. 

RU. 

S 

SAA. 

SBCS. 

SDLC. 

Remote Procedure Call. 

Remote Spooling Communications Subsystem. 

Response unit. 

Systems Application Architecture. 

Single Byte Character Set. 

Synchronous data link control. 

Sendmail. The OS/2 mail server that uses Simple 

Mail Transfer Protocol to route mail from one host to 

another host on the network. 

serial line. A network media that is a de facto 

standard, not an international standard, commonly 

used for point-to-point TCP/IP connections. Generally, 

a serial line consists of an RS-232 connection into a 

modem and over a telephone line. 

semantics. The relationships of characters or groups of 

characters to their meanings, independent of the 

manner of their interpretation and use. The 

relationships between symbols and their meanings. 

server. A function that provides services for users. A 

machine can run client and server processes at the 

same time. 

SFS. 

Shared File System. 

Shared File System (SFS). A part of CMS that lets 

users organize their files into groups known as 

directories and selectively share those files and 

directories with other users. 

Simple Mail Transfer Protocol (SMTP). A TCP/IP 

application protocol used to transfer mail between 

users on different systems. SMTP specifies how mail 

systems interact and the format of control messages 

they use to transfer mail. 

Simple Network Management Protocol (SNMP). A 

protocol that allows network management by elements, 

such as gateways, routers, and hosts. This protocol 

provides a means of communication between network 

elements regarding network resources. 


simultaneous peripheral operations online (SPOOL). 

(Noun) An area of auxiliary storage defined to 

temporarily hold data during its transfer between 

peripheral equipment and the processor. (Verb) To use 

auxiliary storage as a buffer storage to reduce 

processing delays when transferring data between 

peripheral equipment and the processing storage of a 

computer. 

single-byte character set (SBCS). A character set in 

which each character is represented by a one-byte code. 

Contrast with double-byte character set. 

SMI. 

Structure for Management Information. 

spoofing. An act of forging and inserting data that is 

incorrect or not valid. It is most commonly used in 

reference to IP source spoofing, where the source 

address in an IP packet header is replaced with a false 

one, effectively masking the source of the packet 

(making it difficult to trace back to the originator). 

SPOOL. 

Simultaneous peripheral operations online. 

spooling. The processing of files created by or 

intended for virtual readers, punches, and printers. The 

spool files can be sent from one virtual device to 

another, from one virtual machine to another, and to 

read devices. 

SMTP. 

Simple Mail Transfer Protocol. 

SQL. 

Structured Query Language. 

Smurf. A denial-of-service attack in which an ICMP 

Echo Request is sent to a broadcast or multicast 

address. There are three variants of the Smurf attack. 

See Smurf-IC, Smurf-OB, and Smurf-RP. 

Smurf-IC. A denial-of-service attack in which an 

ICMP Echo Request is sent to a broadcast or multicast 

address. ″IC″ denotes that incoming packets are using 

the TCP/IP stack to launch an attack. See Smurf-OB 

and Smurf-RP. 

Smurf-OB. A denial-of-service attack in which an 


address. ″OB″ denotes that an outbound ICMP Echo 

Request matched the description of a Smurf attack. See 

Smurf-IC and Smurf-RP. 

Smurf-RP. A denial-of-service attack in which an 


address. ″RP″ denotes that the ICMP Echo Reply 

packets being received by the stack do not match any 

Echo Requests that were sent. See Smurf-IC and 

Smurf-OB. 

SNA. 

SNALINK. 

Systems Network Architecture. 

SNA Network Link. 

SNA Network Link. An SNA network link function of 

TCP/IP for z/VM and OS/390 hosts running TCP/IP 

to communicate through an existing SNA backbone. 

SNMP. 

SOA. 

Simple Network Management Protocol. 

Start of authority record. 

socket. An endpoint for communication between 

processes or applications. A pair consisting of TCP port 

and IP address, or UDP port and IP address. 

socket address. An address that results when the port 

identification number is combined with an internet 

address. 

socket interface. An application interface that allows 

users to write their own applications to supplement 

those supplied by TCP/IP. 

SQL/DS. 

Structured Query Language/Data System. 

SSL. Secure Sockets Layer. Provides the secure 

(encrypted) communication between a remote client 

and a TCP/IP server. 

start of authority record (SOA). In the Domain Name 

System, the resource record that defines a zone. 

stream. A continuous sequence of data elements being 

transmitted, or intended for transmission, in character 

or binary-digit form, using a defined format. 

Stream. A denial-of-service attack in which TCP 

packets are sent to the stack with no header flags set. 

See R4P3D. 

Structured Query Language (SQL). Fourth generation 

English-like programming language used to perform 

queries on relational databases. 

Structured Query Language/Data System (SQL/DS). 

An IBM relational database management system for the 

VM and VSE operating systems. 

Structure for Management Information (SMI). The 

rules used to define the objects that can be accessed 

through a network management protocol. See also MIB. 

subagent. In the SNMP architecture, a subagent 

provides an extension to the utility provided by the 

SNMP agent. 

subdirectory. A directory contained within another 

directory in a file system hierarchy. 

subnet. A networking scheme that divides a single 

logical network into smaller physical networks to 

simplify routing. 

subnet address. The portion of the host address that 

identifies a subnetwork. 

subnet mask. A mask used in the IP protocol layer to 

separate the subnet address from the host portion of 

the address. 

Glossary 365

subnetwork. 

Synonymous with subnet. 

subsystem. A secondary or subordinate system, 

usually capable of operating independent of, or 

asynchronously with, a controlling system. 

SYNC. 

Synchronous. 

synchronous (SYNC). Pertaining to two or more 

processes that depend on the occurrences of a specific 

event such as common timing signal. Occurring with a 

regular or predictable time relationship. See 

asynchronous. 

synchronous data link control (SDLC). A data link 

over which communication is conducted using the 

synchronous data protocol. 

SynFlood. A denial-of-service attack in which the 

initiator floods the TCP/IP stack with SYN packets that 

have spoofed source IP addresses, resulting in the 

server never receiving the final ACKs needed to 

complete the three-way handshake in the connection 

process. 

Systems Application Architecture (SAA). A formal 

set of rules that enables applications to be run without 

modification in different computer environments. 

Systems Network Architecture (SNA). The 

description of the logical structure, formats, protocols, 

and operational sequences for transmitting information 

units through, and controlling the configuration and 

operation of, networks. 

T 

TALK. An interactive messaging system that sends 

messages between the local host and a foreign host. 

TCP. 

Transmission Control Protocol. 

TCP/IP. Transmission Control Protocol/Internet 

Protocol. 

Telnet. The Terminal Emulation Protocol, a TCP/IP 

application protocol for remote connection service. 

Telnet allows a user at one site to gain access to a 

foreign host as if the user’s terminal were connected 

directly to that foreign host. 

terminal emulator. A program that imitates the 

function of a particular kind of terminal. 

Terminate and Stay Resident (TSR) program. A TSR 

is a program that installs part of itself as an extension 

of DOS when it is executed. 

TFTPD. 

Trivial File Transfer Protocol Daemon. 

ticket. Encrypted information obtained from a 

Kerberos authentication server or a ticket-granting 

server. A ticket authenticates a user and, in conjunction 

with an authenticator, serves as permission to access a 

service when presented by the authenticated user. 

ticket-granting server. Grants Kerberos tickets to 

authenticated users as permission to access an 

end-service. 

Time Sharing Option (TSO). An operating system 

option; for System/370 system, the option provides 

interactive time sharing from remote terminals 

time stamp. To apply the current system time. The 

value on an object that is an indication of the system 

time at some critical point in the history of the object. 

In query, the identification of the day and time when a 

query report was created that query automatically 

provides on each report. 

TN3270. An informally defined protocol for 

transmitting 3270 data streams over Telnet. 

token. In a local network, the symbol of authority 

passed among data stations to indicate the station 

temporarily in control of the transmission medium. 

token-bus. 

See bus topology. 

token ring. As defined in IEEE 802.5, a 

communication method that uses a token to control 

access to the LAN. The difference between a token bus 

and a token ring is that a token-ring LAN does not use 

a master controller to control the token. Instead, each 

computer knows the address of the computer that 

should receive the token next. When a computer with 

the token has nothing to transmit, it passes the token to 

the next computer in line. 

token-ring network. A ring network that allows 

unidirectional data transmission between data stations 

by a token-passing procedure over one transmission 

medium, so that the transmitted data returns to the 

transmitting station. 

Transmission Control Protocol (TCP). The TCP/IP 

layer that provides reliable, process-to-process data 

stream delivery between nodes in interconnected 

computer networks. TCP assumes that IP (Internet 

Protocol) is the underlying protocol. 

Transmission Control Protocol/Internet Protocol 

(TCP/IP). A suite of protocols designed to allow 

communication between networks regardless of the 

technologies implemented in each network. 

transport layer. Layer 4 of the Open Systems 

Interconnection (OSI) model; it defines protocols 

governing message structure and some error checking. 

TRAP. An unsolicited message that is sent by an 

SNMP agent to an SNMP network management station. 

Trivial File Transfer Protocol Daemon (TFTPD). The 

TFTP daemon (TFTPD server) transfers files between 


the Byte File System (BFS) and TFTP clients. TFTPD 

supports access to files maintained in a BFS directory 

structure that is mounted. 

TSO. 

Time Sharing Option. 

TSR. Terminate and stay resident. TSR usually refers 

to a terminate-and-stay-resident program. 

U 

UDP. 

User Datagram Protocol. 

user. A function that uses the services provided by a 

server. A host can be a user and a server at the same 

time. See client. 

Virtual Telecommunications Access Method (VTAM). 

An IBM-licensed program that controls communication 

and the flow of data in an SNA network. It provides 

single-domain, multiple-domain, and interconnected 

network capability. 

VM. 

VMCF. 

Virtual Machine. 

Virtual Machine Communication Facility. 

VM/ESA. Virtual Machine/Enterprise System 

Architecture 

VMSES/E. Virtual Machine Serviceability 

Enhancements Staged/Extended. 

VTAM. 

Virtual Telecommunications Access Method. 

User Datagram Protocol (UDP). A datagram level 

protocol built directly on the IP layer. UDP is used for 

application-to-application programs between TCP/IP 

hosts. 

W 

WAN. 

Wide area network. 

user exit. A point in an IBM-supplied program at 

which a user routine may be given control. 

user profile. A description of a user, including user 

ID, user name, defaults, password, access authorization, 

and attributes. 

V 

virtual address. The address of a location in virtual 

storage. A virtual address must be translated into a real 

address to process the data in processor storage. 

Virtual Machine (VM). Licensed software whose full 

name is Virtual Machine/Enterprise Systems 

Architecture (VM/ESA) It is a software operating 

system that manages the resources of a real processor 

to provide virtual machines to end users. It includes 

time-sharing system control program (CP), the 

conversational monitor system (CMS), the group 

control system (GCS), and the dump viewing facility 

(DVF). 

Virtual Machine Communication Facility (VMCF). A 

connectionless mechanism for communication between 

address spaces. 

VM. 

Virtual machine. 

virtual storage. Storage space that can be regarded as 

addressable main storage by the user of a computer 

system in which virtual addresses are mapped into real 

addresses. The size of virtual storage is limited by the 

addressing scheme of the computing system and by the 

amount of auxiliary storage available, not by the actual 

number of main storage locations. 

well-known port. A port number that has been 

preassigned for specific use by a specific protocol or 

application. Clients and servers using the same protocol 

communicate over the same well-known port. 

wide area network (WAN). A network that provides 

communication services to a geographic area larger 

than that served by a local area network. 

widget. The basic data type of the X Window System 

Toolkit. Every widget belongs to a widget class that 

contains the allowed operations for that corresponding 

class. 

window. An area of the screen with visible boundaries 

through which a panel or portion of a panel is 

displayed. 

working directory. The directory in which an 

application program is found. The working directory 

becomes the current directory when the application is 

started. 

X 

X Client. An application program which uses the X 

protocol to communicate windowing and graphics 

requests to an X Server. 

XDR. 

eXternal Data Representation. 

XEDIT. The CMS facility, containing the XEDIT 

command and XEDIT subcommands and macros, that 

lets a user create, change, and manipulate CMS files. 

X Server. A program which interprets the X protocol 

and controls one or more screens, a pointing device, a 

keyboard, and various resources associated with the X 

Window System, such as Graphics Contexts, Pixmaps, 

and color tables. 

Glossary 367

X Window System. The X Window System is a 

protocol designed to support network transparent 

windowing and graphics. TCP/IP for z/VM and 

OS/390 provides client support for the X Window 

System application program interface. 

X Window System API. An application program 

interface designed as a distributed, 

network-transparent, device-independent, windowing 

and graphics system. 

X Window System Toolkit. 

application environments. 

Functions for developing 

X.25. A CCITT communication protocol that defines 

the interface between data terminal equipment and 

packet switching networks. 

X.25 NCP Packet Switching Interface (X.25 NPSI). An 

IBM-licensed program that allows users to 

communicate over packet switched data networks that 

have interfaces complying with Recommendation X.25 

(Geneva** 1980) of the CCITT. It allows SNA programs 

to communicate with SNA equipment or with non-SNA 

equipment over such networks. 

Z 

ZAP. To modify or dump an individual text file/data 

set using the ZAP command or the ZAPTEXT EXEC. 

zone. In the Domain Name System, a zone is a logical 

grouping of domain names that is assigned to a 

particular organization. Once an organization controls 

its own zone, it can change the data in the zone, add 

new tree sections connected to the zone, delete existing 

nodes, or delegate new subzones under its zone. 


Bibliography 

This bibliography lists the IBM publications that 

provide information about your z/VM system. 

The z/VM library includes z/VM base 

publications, publications for additional facilities 

included with z/VM, and publications for z/VM 

optional features. For abstracts of z/VM 

publications and information about current 

editions and available publication formats, see 

z/VM: General Information. 

z/VM Internet Library 

The latest editions of most z/VM publications are 

available in Adobe Portable Document Format 

(PDF) and IBM BookManager ® format from the 

z/VM Internet Library: 

http://www.ibm.com/eserver/zseries/zvm/library/ 

The z/VM Internet Library also provides other 

information about z/VM, such as: 

v Program directories 

v Data areas and control blocks 

v Monitor records 

VM Collection CD-ROM 

The Online Library Omnibus Edition: VM Collection, 

SK2T-2067, contains libraries in BookManager 

format for current IBM VM system products and 

IBM licensed programs that run on VM. It also 

contains PDF versions of many of these books. 

Note: Only unlicensed publications are included. 

z/VM Base Publications 

Evaluation 

z/VM: General Information, GC24-5991 

z/VM License Information, GC24-6033 

z/VM: Migration Guide, GC24-5996 

Installation and Service 

z/VM: Installation Guide, GC24-5992 

z/VM: Service Guide, GC24-5993 

z/VM: VMSES/E Introduction and Reference, 

GC24-5994 

Planning and Administration 

z/VM: CMS File Pool Planning, Administration, 

and Operation, SC24-5949 

z/VM: CMS Planning and Administration, 

SC24-6042 

VM/ESA: Connectivity Planning, Administration, 

and Operation, SC24-5756 

z/VM: CP Planning and Administration, 

SC24-6043 

z/VM: Dynamic I/O Configuration Planning and 

Administration, SC24-6044 

z/VM: Group Control System, SC24-5998 

z/VM: Performance, SC24-5999 

z/VM: Running Guest Operating Systems, 

SC24-5997 

z/VM: Saved Segments Planning and 


z/VM: System Administration Facility, SC24-6034 

Customization 

z/VM: CP Exit Customization, SC24-5953 

Operation 

z/VM: System Operation, SC24-6000 

z/VM: Virtual Machine Operation, SC24-6036 

Application Programming 

z/VM: CMS Application Development Guide, 

SC24-6002 

z/VM: CMS Application Development Guide for 

Assembler, SC24-6003 

z/VM: CMS Application Multitasking, SC24-5961 

z/VM: CMS Callable Services Reference, 

SC24-6004 

z/VM: CMS Macros and Functions Reference, 

SC24-6005 

z/VM: CP Programming Services, SC24-6001 

VM/ESA: CPI Communications User’s Guide, 

SC24-5595 

z/VM: Enterprise Systems Architecture/Extended 

Configuration Principles of Operation, SC24-5965 

z/VM: OpenExtensions Advanced Application 

Programming Tools, SC24-5979 


z/VM: OpenExtensions Callable Services Reference, 

SC24-6007 

z/VM: OpenExtensions Command Reference, 

SC24-6006 

z/VM: OpenExtensions POSIX Conformance 

Document, GC24-5976 

z/VM: OpenExtensions User’s Guide, SC24-6053 

z/VM: Program Management Binder for CMS, 

SC24-6057 

VM/ESA: Programmer’s Guide to the 

Server-Requester Programming Interface for VM, 

SC24-5455 

z/VM: Reusable Server Kernel Programmer’s 

Guide and Reference, SC24-5964 

VM/ESA: REXX/VM Primer, SC24-5598 

z/VM: REXX/VM Reference, SC24-6035 

z/VM: REXX/VM User’s Guide, SC24-5962 

Common Programming Interface Communications 

Reference, SC26-4399 

Common Programming Interface Resource 

Recovery Reference, SC31-6821 

Debug Tool User’s Guide and Reference, 

SC09-2137 

OS/390: DFSMS Program Management, 

SC27-0806 

End Use 

z/VM: CMS Command and Utility Reference, 

SC24-6010 

z/VM: CMS Pipelines Reference, SC24-5971 

z/VM: CMS Pipelines User’s Guide, SC24-5970 

VM/ESA: CMS Primer, SC24-5458 

z/VM: CMS User’s Guide, SC24-6009 

z/VM: CP Command and Utility Reference, 

SC24-6008 

z/VM: Quick Reference, SC24-6011 

z/VM: XEDIT Command and Macro Reference, 

SC24-5973 

z/VM: XEDIT User’s Guide, SC24-5972 

CMS/TSO Pipelines: Author’s Edition, SL26-0018 

Diagnosis 

z/VM: Diagnosis Guide, GC24-6039 

z/VM: Dump Viewing Facility, GC24-5966 

z/VM: System Messages and Codes - CMS, 

GC24-6031 

z/VM: System Messages and Codes - CP, 

GC24-6030 

z/VM: System Messages and Codes - Other 

Components, GC24-6032 

z/VM: VM Dump Tool, GC24-6037 

Publications for z/VM Additional 

Facilities 

DFSMS/VM ® 

z/VM: DFSMS/VM Function Level 221 

Customization, SC24-6047 

z/VM: DFSMS/VM Function Level 221 Diagnosis 

Guide, GC24-6046 

z/VM: DFSMS/VM Function Level 221 Messages 

and Codes, GC24-6048 

z/VM: DFSMS/VM Function Level 221 Planning 

Guide, SC24-6049 

z/VM: DFSMS/VM Function Level 221 

Removable Media Services, SC24-6050 

z/VM: DFSMS/VM Function Level 221 Storage 


Language Environment ® 

z/VM: Language Environment 1.8 C Run-Time 

Library Reference, SC24-6038 

Language Environment for OS/390 & VM: 

Concepts Guide, GC28-1945 


Debugging Guide and Run-Time Messages, 

SC28-1942 


Programming Guide, SC28-1939 


Programming Reference, SC28-1940 


Run-Time Migration Guide, SC28-1944 


Writing Interlanguage Communication 

Applications, SC28-1943 

OSA/SF 

VM/ESA: Open Systems Adapter Support Facility 

User’s Guide for OSA-2, SC28-1992 

S/390: Open Systems Adapter-Express Customer’s 

Guide and Reference, SA22-7403 

S/390: Planning for the S/390 Open Systems 

Adapter (OSA-1, OSA-2) Feature, GC23-3870 

zSeries 900: Open Systems Adapter-Express 

Customer’s Guide and Reference, SA22-7476 


zSeries 900: Planning for the Open Systems 

Adapter-2 Feature, GA22-7477 

TCP/IP for z/VM 

z/VM: TCP/IP Level 430 Diagnosis Guide, 

GC24-6023 

z/VM: TCP/IP Level 430 Messages and Codes, 

GC24-6022 

z/VM: TCP/IP Level 430 Planning and 

Customization, SC24-6019 

z/VM: TCP/IP Level 430 Programmer’s Reference, 

SC24-6021 

z/VM: TCP/IP Level 430 User’s Guide, SC24-6020 

Publications for z/VM Optional 

Features 

DirMaint 

z/VM: Directory Maintenance Facility Function 

Level 410 Command Reference, SC24-6025 


Level 410 Messages, GC24-6026 


Level 410 Tailoring and Administration Guide, 

SC24-6024 

PRF 

z/VM: Performance Reporting Facility Function 

Level 410, SC24-6027 

RTM 

z/VM: RealTime Monitor Function Level 410, 

SC24-6028 

RACF ® for VM 

RACF: Auditor’s Guide, SC28-1342 

RACF: Command Language Reference, SC28-0733 

RACF: Command Language Reference Summary, 

SX22-0014 

RACF: Diagnosis Guide, GY28-1016 

RACF: General Information, GC28-0722 

RACF: General User’s Guide, SC28-1341 

RACF: Macros and Interfaces, SC28-1345 

RACF: Messages and Codes, SC38-1014 

RACF: Migration and Planning, GC23-3054 

RACF: Security Administrator’s Guide, 

SC28-1340 

RACF: System Programmer’s Guide, SC28-1343 

External Security Interface (RACROUTE) Macro 

Reference for MVS and VM, GC28-1366 

Other TCP/IP Related 

Publications 

This section lists other publications, outside the 

z/VM 4.3.0 library, that you may find helpful. 

v TCP/IP Tutorial and Technical Overview, 

GG24-3376 

v TCP/IP Illustrated, Volume 1: The Protocols, 

SR28-5586 

v Internetworking with TCP/IP Volume I: Principles, 

Protocols, and Architecture, SC31-6144 

v Internetworking With TCP/IP Volume II: 

Implementation and Internals, SC31-6145 

v Internetworking With TCP/IP Volume III: 

Client-Server Programming and Applications, 

SC31-6146 

v DNS and BIND in a Nutshell, SR28-4970 

v "MIB II Extends SNMP Interoperability," C. 

Vanderberg, Data Communications, October 1990. 

v "Network Management and the Design of SNMP," 

J.D. Case, J.R. Davin, M.S. Fedor, M.L. 

Schoffstall. 

v "Network Management of TCP/IP Networks: 

Present and Future," A. Ben-Artzi, A. Chandna, 

V. Warrier. 

v "Special Issue: Network Management and 

Network Security,"ConneXions-The 

Interoperability Report, Volume 4, No. 8, August 

1990. 

v The Art of Distributed Application: Programming 

Techniques for Remote Procedure Calls, John R. 

Corbin, Springer-Verlog, 1991. 

v The Simple Book: An Introduction to Management 

of TCP/IP-based Internets, Marshall T Rose, 

Prentice Hall, Englewood Cliffs, New Jersey, 

1991. 

Bibliography 371


Index 

Numerics 

3172 attributes 335 

3172 enterprise-specific MIB 

variables 327 

A 

abbreviations and acronyms 343 

ACCT (FTP subcommand) 40 

address fields 

class A 11 

class B 12 

class C 12 

class D 12 

Address Resolution Protocol (ARP) 5 

AIX files 289 

ALL (NETSTAT parameter) 109, 117 

ALLCONN (NETSTAT parameter) 109, 

117 

AO (TELNET subcommand) 103 

APL2 Character Set 295 

APPEND (FTP subcommand) 41 

application layer 3 

applications, functions and protocols 

Bootstrap Protocol (BOOTP) 9 

Domain Name System (DNS) 7, 243 

Dynamic Host Configuration 

Protocol(DHCP) 10 

File Transfer Protocol (FTP) 6, 15 

GDDMXD 9 

Kerberos Authentication System 8, 

133, 139 

Network Database System (NDB) 10, 

231 

Network File System (NFS) 9, 139 

Remote Execution Protocol 

(REXEC) 9, 169 

Remote Printing (LPD and LPR) 8, 

175 

Remote Procedure Call (RPC) 9 

RouteD 8 

Simple Mail Transfer Protocol 

(SMTP) 7 

Simple Network Management 

Protocol (SNMP) 8, 213 

Socket interfaces 10 

Telnet Protocol 6, 101 

Trivial File Transfer Protocol 

(TFTP) 7, 85 

X Toolkit 8 

X Window System 8 

ARP (NETSTAT parameter) 118 

AS 400 files 292 

ASCII (FTP subcommand) 41 

ASCII mode 

with the TFTP GET subcommand 86 

with the TFTP MODE 

subcommand 88 

ASCII-to-EBCDIC table 282 

Athena widget 8 

attacks 

Fraggle 112 

Ping-o-Death 112 

Smurf 112 

attacks, denial-of-service (DOS) 

example 122 

authentication of network users 133 

AYT (TELNET subcommand) 103 

B 

BINARY (FTP subcommand) 42 

bit mask 13 

BLOCK (NETSTAT parameter) 110 

Bootstrap Protocol (BOOTP) 9 

bridge 2 

broadcast address format 12 

C 

CD (FTP subcommand) 42 

changing the FTP file transfer type 

to ASCII 41 

to EBCDIC 49 

to Image 42 

to Kanji 52, 70 

character sets 277 

client 2 

CLIENTS (NETSTAT parameter) 110, 

118 

CLOSE (FTP subcommand) 46 

CMS (FTP subcommand) 46 

CMS command interface 271 

CMSRESOL 270 

code pages 277 

computer networks 

LAN 1 

WAN 1 

CONN (NETSTAT parameter) 110, 119 

connecting to a database 

explicit connection 235 

implicit connection 235 

Controlling File Translation (FTP) 34 

CONVXLAT command 286 

CP (NETSTAT parameter) 111, 119 

CP SMSG command 160 

customizing 

DBCS translation tables 283 

SBCS translation tables 282 

D 

data set names 289 

database query and update 273 

datagram 2 

datagram socket 214 

DBCS facilities 301 

DEBUG (FTP subcommand) 47 

DELARP (NETSTAT parameter) 111 

DELETE (FTP subcommand) 47 

deleting CMS record-length fields 166 

DELIMIT (FTP subcommand) 47 

denial-of-service (DOS) attacks 

example 122 

Fraggle 112 

Ping-o-Death 112 

Smurf 112 

DEVLINKS (NETSTAT parameter) 111, 

120 

DiG command 260 

DiG internal state information 259 

DiG options 264 

DiG program 259 

DIR (FTP subcommand) 48 

direct routing 10 

domain name servers 244 


CMS command interface to the 

resolver 271 

CMSRESOL, resolver and name 

server 270 

NSLOOKUP examples 256 

Overview of Domain Name 

System 7, 243 

query types 272 

Querying Name Servers-DiG 259 

Querying Name Servers- 

NSLOOKUP 249 

resolvers 245 

resource records 246 

Using the Domain Name System 243 

domain names 243 

DOS names 291 

dotted-decimal notation 107 

DROP (NETSTAT parameter) 112, 122 

Dynamic Host Configuration Protocol 

(DHCP) 10 

E 

EBCDIC (FTP subcommand) 49 

EBCDIC-to-ASCII table 282 

electronic mail 

delivery 92 

gateway 91 

notes 

non-delivery note 92 

unknown recipient note 93 

notes without PROFS interface 95 

PROFS interface 94 

SMTPQUEU command 92 

TCP/IP recipients 94 

EUCKANJI (FTP subcommand) 50 

Extended Mail, PROFS 94 

eXternal Data Representation (XDR) 233 

F 

file name translation (NFS) 

special names 165 


file names 289 

file naming format, FTP 30 

File Transfer Protocol (FTP) 6, 15, 83 

file transfer type 

ASCII 34, 41, 74 

EBCDIC 34, 49, 74 

Image 34, 42, 74 

Kanji 34, 74 

FILTERS (NETSTAT parameter) 113 

foreign host 2 

Fraggle attack 112 

FTP 

file transfer methods 34 

naming files 30 

FTP command format 16 

FTP DATA File 19 

Configuration Statements 20 

CCONNTIME Statement 20 

DATACTTIME Statement 21 

DCONNTIME Statement 22 

INACTTIME Statement 23 

LOADDBCSTABLE Statement 24 

MYOPENTIME Statement 25 

Statement Syntax 19 

FTP data transfer methods 34 

FTP EXEC interface 78 

FTP EXIT return codes 78 

FTP Kanji support 301 

FTP parameters 

EXIT 16 


port number 16 

TIMEOUT 16 

TRACE 17 

TRANSLATE 17 

FTP reply codes 80 

FTP servers, RACF support 83 

FTP subcommands 

ACCT 40 

APPEND 41 

ASCII 41 

BINARY 42 

CD 42, 45 

CDUP 46 

CLOSE 46 

CMS 46 

DEBUG 47 

DELETE 47 

DELIMIT 47 

DIR 48 

EBCDIC 49 

EUCKANJI 50 

GET 50 

HELP 51 

IBMKANJI 52 

JIS78KJ 52 

JIS83KJ 53 

LCD 53 

LOCSITE 54 

LOCSTAT 54 

LPWD 55 

LS 55 

MDELETE 57 

MGET 58 

MKDIR 58 

MODE 59 

MPUT 59 

FTP subcommands (continued) 

NETRC 60 

NOOP 60 

OPEN 61 

PASS 62 

PASSIVE 62 

PUT 63 

PWD 64 

QUIT 65 

QUOTE 65 

RENAME 65 

SENDPORT 67 

SENDSITE 67 

SITE 68 

SIZE 70 

SJISKANJI 70 

STATUS 71 

STRUCT 71 

SUNIQUE 71 

SYSTEM 73 

TRACE 17 

TRANSLATE 17 

TYPE 74 

USER 75 

G 

GATE (NETSTAT parameter) 113, 122 

gateway 2 

GDDMXD 9, 195, 213, 295 

GDDMXD/VM 

CMS GLOBALV command 

format 197 

command format 196 

demonstration programs 

GXDEMO1 209 

GXDEMO2 210 

GXDEMO3 210 

GXDEMO4 210 

GXDEMO5 210 

GXDEMO6 210 

GXDEMO7 210 

GDXAPLCS MAP 207 

keyboard functions 206, 207 

limitations 195 

overview 195 

problem determination 208, 209 

trace 208 

user-specified options 

CMap 202 

GColornn 199 

Geometry 199 

GMCPnn 200 

HostRast 202 

XClConn 203 

XSync 201 

ZWL 201 

VM/XA considerations 196 

X DEFAULTS 198 

GET (FTP subcommand) 50 

GET (TFTP subcommand) 86 

H 

HELP (FTP subcommand) 51 

HELP (NETSTAT subcommand) 113, 123 

HELP (TELNET subcommand) 104 

HELP (TFTP subcommand) 86 

HOME (NETSTAT parameter) 113, 124 

host 

foreign 2 

local 2 

I 

IBMKANJI (FTP subcommand) 52 

IDENTIFY (NETSTAT 

subcommand) 113, 124 

IMAP 

using 95 

indirect routing 11 

Integrated Services Digital Network 

(ISDN) 1 

internal error codes 82 

International Telegraph and Telephone 

Consultative Committee (CCITT) 4 

internet address 2 

internet addressing 

broadcast address format 12 


local address 11 

network address format 11 

network number 11 

subnetwork address format 13 

subnetwork number 11 


(ICMP) 5 

Internet Environment 

bridge 2 

client 2 

datagram 2 


gateway 2 

host 2 


local host 2 

logical network 2 

mapping 2 

network 2 

packet 2 

physical network 1 

port 2 

protocol 2 

router 2 

server 2 

user 2 

Internet Message Access Protocol 

(IMAP) 7 

Internet Protocol (IP) 4 

internetwork layer 3 

internetwork protocols 4 

Address Resolution Protocol (ARP) 5 


(ICMP) 5 

Internet Protocol (IP) 4 

INTERVAL (NETSTAT parameter) 114, 

125 

intrinsics 8 

inverse query 273 

IP (TELNET subcommand) 104 

IUCV cross-memory facility 214 


J 

JIS78KJ 52 

JIS83KJ 53 

K 

Kanji 

EUCKANJI 50 

IBMKANJI 52 

JIS78KJ 52 

JIS83KJ 53 

SJISKANJI 70 

support for FTP 301 

Kanji, using 301 

KDESTROY (Kerberos 

subcommand) 136 

Kerberos 133, 139 

Kerberos Authentication System 8 

commands 

KDESTROY 136 

KINIT 134 

KLIST 135 

KPASSWD 136 

name structures 133 

overview of Kerberos 8, 133 

KINIT (Kerberos subcommand) 134 

KLIST (Kerberos subcommand) 135 

KPASSWD (Kerberos subcommand) 136 

L 

layered architecture 



network layer 3 

transport layer 3 

LEVEL (NETSTAT parameter) 114 

licensing agreement 348 

line mode 102 

local address 11 

Local Area Network (LAN) 1 

local host 2 

LOCSTAT (FTP subcommand) 54 

LOCSTAT (TFTP subcommand) 87 

logical network 2 

LPQ 

command 191 

examples 192 

usage 193 

LPQ Command 191 

LPR 

command 178 

examples 185 

usage 188 

LPR Command 178 

LPRM 

command 193 

examples 194 

usage 194 

LPRSET 

command 175 

examples 177 

usage 178 

LPRSET Command 175 

LS (FTP subcommand) 55 

M 

mail, electronic 91, 95 

Management Information Base (MIB) 

objects 307 

mapping 2 

mapping values (APL2) 295 

MAXPKT (TFTP subcommand) 87 

MDELETE (FTP subcommand) 57 

MGET (FTP subcommand) 58 

MIB/Network elements 

Address Translation group 316 

ibm3172ifBlkCounters table 331 

ibm3172ifChanCounters table 329 

ibm3172ifDblkCounters table 332 

ibm3172ifDevice table 333 

ibm3172ifLANCounters table 330 

ibm3172ifTrap table 328 

ibm3172System table 327 

ICMP group 323 

Interfaces group 312 

IP Address Translation table 322 

IP group 317 

System group 311 

TCP group 324 

UDP group 327 

MODE (FTP subcommand) 59 

MODE (TFTP subcommand) 88 

monitoring the TCP/IP network 107, 

133 

MOUNT (NFS subcommand) 140 

MOUNTPW (NFS subcommand) 149 

MPUT (FTP subcommand) 59 

MVS data sets 290 

N 

name translation, NFS 165 

NDB client machine 232 

NDB limitations 240 

NDB server 235 

NDB server machines 234 

NDBCLNT Command 236 

NETRC (FTP subcommand) 60 

NETRC DATA File 

FTP 19 

how to use 293 

REXEC 170 

NETSTAT 107, 128 

NETSTAT address interpretation 107 

NETSTAT command format 107 

NETSTAT examples 117 

NETSTAT parameters 

ALL 109 

ALLCONN 109 

ARP 109 

BLOCK 110 

CLIENTS 110 

CONN 110 

CP 111 

DELARP 111 

DEVLINKS 111 

DROP 112 

FILTERS 113 

GATE 113 

HELP 113 

HOME 113 

NETSTAT parameters (continued) 

IDENTIFY 113 

INTERVAL 114 

POOLSIZE 115 

RESETPOOL 115 

SOCKET 116 

TELNET 116 

UNBLOCK 116 

UP 117 

NetView Command List Language 213 

network 

logical 2 

physical 2 

STATUS 107 

network address format 11 

Network Database System (NDB) 10, 

231, 243 


network management 213 

network number 11 

network protocols 4 

NFS 139, 167 

NFS CMS SMSG command 160 

NFS commands 

Error Messages 140, 153 

MOUNT 140 

MOUNTPW 140, 149 

UMOUNT 140 

NFS name translation 

special file names 165 

NFS overview 9 

NFS PC-NFS client 166 

NFS servers, RACF support 166 

NFS system return codes 153 

NOOP (FTP subcommand) 60 

NSLOOKUP command 249 

NSLOOKUP internal state 

information 249 

NSLOOKUP options 254 

NSLOOKUP program 249 

O 

OBEY (NETSTAT parameter) 114 

obtaining information from the 

network 107 

octet mode 

with the TFTP GET subcommand 86 

with the TFTP MODE 

subcommand 88 

OfficeVision 91 

OPEN (FTP subcommand) 61 

OPEN (TFTP subcommand) 88 

Open System Interconnection (OSI) 1 

OS/2 files 291 

OSF/Motif 9 

P 

PA1 (TELNET subcommand) 104 

packet 2 

partitioned data set names 290 

PASS (FTP subcommand) 62 

PASSIVE (FTP subcommand) 62 

password use with FTP 

ACCT 40 

Index 375

password use with FTP (continued) 

PASS 62 

QUOTE 65 

USER 75 

physical network 2 

PING 129 

PING command format 129 

PING options 

COUNT 129 

LENGTH 129 

TIMEOUT 129 

Ping-o-Death attack 112 

POOLSIZE (NETSTAT parameter) 115, 

126 

port 2 

Port Manager client 234 

Port Manager server 233, 234 

PROFS interface 95 

protocol data unit (PDU) 214 

protocols 

definition 2 

internetwork protocols 4 

network protocols 4 

PUT (FTP subcommand) 63 

PUT (TFTP subcommand) 89 

PWD (FTP subcommand) 64 

Q 

query engine 214 

query options 261 

query types 

inverse query 273 

standard query 272 

querying name servers 

DiG 259 

NSLOOKUP 249 

QUIT (FTP subcommand) 65 

QUIT (TELNET subcommand) 104 

QUIT (TFTP subcommand) 89 

QUOTE (FTP subcommand) 65 

R 

RACF 83, 166 

raw socket 214 

related protocols 339 

Remote Execution Protocol (REXEC) 9, 

169, 175 

remote printing 8, 175, 194 

Remote Procedure Call (RPC) 9, 231 

RENAME (FTP subcommand) 65 

RESETPOOL (NETSTAT parameter) 115, 

126 

resolvers 245 

resource records 246 

REXEC command format 169 

REXMIT (TFTP subcommand) 89 

RouteD overview 8 

router 2 

routing 

direct 10 

indirect 11 

RPC client 232, 233 

RPC server 234 

RPCINFO 128, 129 

RPCINFO command format 128 

RPCINFO parameters 128 

S 

Secure Socket Layer (SSL) 10 

security 

database 240 

system 240 

SENDPORT (FTP subcommand) 67 

SENDSITE (FTP subcommand) 67 

sequential data set names 290 

server 2 

SET subcommand 254 

Simple Mail Transfer Protocol (SMTP) 7 

Using DBCS with Mail 305 

Simple Network Management Protocol 

(SNMP) 8 

SITE (FTP subcommand) 68 

SIZE (FTP subcommand) 70 

SJISKANJI 70 

SMSG (CMS subcommand) 160 

SMSG interface to SMTP 96 

SMTPQUEU 92 

Smurf attack 112 

SNMP 

command 215 

command processor 214 

generic TRAP types 337 

IBM 3172 enterprise-specific MIB 

variables 228 

major and minor error codes 227 

managing an internet 

environment 213 

MIB/Network elements 310 

overview 8 

Protocol 213 

Query Engine Host Lookup 228 

return codes 215 

sample command lists 213 

value types 

SNMP GET 216 

SNMP GETNEXT 218 

SNMP MIBVNAME 225 

SNMP PING 226 

SNMP SET 220 

SNMP TRAPSOFF 224 

SNMP TRAPSON 222 

SNMP command processor 214 

SNMP generic TRAP types 337 

SNMP/Netview overview 214 

SNMPIUCV task 214 

SNMPMGMT command 213 

SNMPRUN command 213 

SOCKET (NETSTAT parameter) 116, 126 

socket interfaces 10 

sockets 

datagram 214 

raw 214 

stream 214 

SQL commands 

imbedded 232 

interactive 232 

SQL/DS 231 

standard query 272 

STATUS (FTP subcommand) 71 

stream socket 214 

STRUCT (FTP subcommand) 71 

Structure and Identification of 

Management Information (SMI) 307 

subnetwork address format 13 

subnetwork number 11 

SUNIQUE (FTP subcommand) 71 

SYNCH (TELNET subcommand) 105 

SYSTEM (FTP subcommand) 73 

T 

TCP/IP functional groups 





TCP/IP protocols and functions 3 

TELNET 101, 105 

TELNET (NETSTAT subcommand) 116, 

127 

TELNET command format 101 

TELNET control characters in line 

mode 105 

TELNET function keys 102 

TELNET modes 

line mode 103 

transparent mode 103 

TELNET parameters 

FIREWALL 101 

LINEMODE 101 

RECORD 102 

TRANSLATE 102 

TELNET PF key functions 102 

Telnet Protocol 6 

TELNET subcommands 

AO 103 

AYT 103 

BRK 103 

HELP 104 

IP 104 

PA1 104 

QUIT 104 

SYNCH 105 

TELNET support display stations 102 

TFTP 85, 89 

TFTP command format 85 

TFTP parameters 

ASCII 88 

OCTET 88 

TRANSLATE 85 

TFTP subcommands 

GET 86 

HELP 86 

LOCSTAT 87 

MAXPKT 87 

MODE 88 

OPEN 88 

PUT 89 

QUIT 89 

REXMIT 89 

TRACE 90 

Token-Ring 1, 2 

TRACE (TFTP subcommand) 90 

traceroute function (TRACERTE) 130 

translation tables 

Chinese DBCS 285 

converting to binary 286 


translation tables (continued) 

Hangeul DBCS 285 

IBM 280 

Japanese Kanji DBCS 284 

search order 278 

translation tables for TFTP 86 

Transmission Control Protocol (TCP) 6 

transparent mode 102 


transport protocols 

Transmission Control Protocol 

(TCP) 6 

User Datagram Protocol (UDP) 6 

Trivial File Transfer Protocol (TFTP) 7, 

85 

TYPE (FTP subcommand) 74 

U 

UNBLOCK (NETSTAT parameter) 116 

UNIX syntax 50 

UP (NETSTAT subcommand) 117, 127 

user 2 

USER (FTP subcommand) 75 

User Datagram Protocol (UDP) 6 

using translation tables 277 

V 

virtual circuitry 253 

virtual network 1 

W 

Wide Area Network (WAN) 1 

widgets 

Athena 8 

OSF/Motif 9 

Windows 95 files 291 

write logic for file mode 6 158 

X 

X-Toolkit overview 8 

X-Windows overview 8 

X.25 4 

Index 377


Readers’ Comments — We’d Like to Hear from You 




Version 4 Release 3.0 

Publication No. SC24-6020-01 

Overall, how satisfied are you with the information in this book? 

Very Satisfied Satisfied Neutral Dissatisfied Very 

Dissatisfied 

Overall satisfaction h h h h h 

How satisfied are you that the information in this book is: 

Very Satisfied Satisfied Neutral Dissatisfied Very 

Dissatisfied 

Accurate h h h h h 

Complete h h h h h 

Easy to find h h h h h 

Easy to understand h h h h h 

Well organized h h h h h 

Applicable to your tasks h h h h h 

Please tell us how we can improve this book: 

Thank you for your responses. May we contact you? h Yes h No 

When you send comments to IBM, you grant IBM a nonexclusive right to use or distribute your comments in any 

way it believes appropriate without incurring any obligation to you. 

Name 

Address 

Company or Organization 

Phone No.

Readers’ Comments — We’d Like to Hear from You 

SC24-6020-01 

SC24-6020-01 

 

_________________________________________________________________________________________ 

Fold and Tape Please do not staple Fold and Tape 

BUSINESS REPLY MAIL 

FIRST-CLASS MAIL PERMIT NO. 40 ARMONK, NEW YORK 

POSTAGE WILL BE PAID BY ADDRESSEE 


Information Development 

Department G60G 

1701 North Street 

Endicott, New York 

13760-5553 

NO POSTAGE 

NECESSARY 

IF MAILED IN THE 

UNITED STATES 

_________________________________________________________________________________________ 

Fold and Tape Please do not staple Fold and Tape 

___________________________________________________________________________________________________ 

Cut or Fold 

Along Line 

Cut or Fold 

Along Line

File Number: S370/4300/30XX-50 

Program Number: 5739-A03 

Printed in the United States of America 

on recycled paper containing 10% 

recovered post-consumer fiber. 

SC24-6020-01

Spine information: 

z/VM TCP/IP User’s Guide Version 4 Release 3.0

z/VM: TCP/IP User's Guide - z/VM - IBM

Create successful ePaper yourself

Delete template?

Save as template?