The nickname.sys file is an ASCII text file that can be created for the purpose of mapping resources named by the customer to named resources that LINCS can recognize. The nickname.sys file also supports the TN3270 Server feature. For specifics about its usage in conjunction with TN3270, refer to the section entitled TN3270 LU Nickname File.
User-defined names can be associated with LINCS LU resources with this file, allowing the client to be configured with meaningful resource names. For example, the named resource may be chosen to match the VTAM LU name, found in the host gen. The name is passed to LINCS as the resource name whenever the client is configured for Dedicated LUs or Pooled (Group) LUs.
The Nickname file is not required to provide specific LU assignments, but may be used to provide a means to this end.
LINCS accepts as the Nickname file, a file by the name of: nickname.sys
This file can placed on a floppy diskette residing in the floppy drive, or may be located in the SYSTEM subdirectory on the hard drive. LINCS will search the available drives for the nickname.sys file in the order of drives c, d, a, b. Although it may be useful to create the nickname.sys file and test it on a diskette, you will normally want to copy it to the hard drive using Media Management for normal operations.
The nickname.sys file is read into memory at IML time. You may also invoke changes on the fly by copying a new nickname.sys file to the hard drive, then invoking Central Control Mode utility 3/5. This will cause the new nickname file to be read into LINCS memory, and all new connections will use the new file.
Syntax for the nickname.sys file is as follows:
nickname1=host,lu1 nickname2=host,lu2 or
nickname3=class_name or
nickname4=LUnn
where each nickname must be a unique string of up to 16 characters consisting of alphanumeric characters and/or the characters space, !, “, #, $, %, &, ‘, (, ), *, +, ,, ., -, /, :, ;, <;, =, >;, ?, {, |, }, and ~. Do not use [, \, ], ^, or _.
All entries into the file should be on consecutive lines, with each line terminated with a carriage return. There is to be one entry per line, with no white space to the left of the carriage return other than as part of the nickname itself.
LINCS is not case sensitive for the nicknames. When using the format of nickname=LUnn, however, the characters “LU” must be in capitals.
Each host,lu in the nickname file should be in the form of a single letter corresponding to the host letter assigned by LINCS for the host connection, separated by a comma from a two digit LU number (in hex!). Do not use the Host ID name from configuration.
If a class_name is used, this corresponds to the LINCS Class Name for a 3270 host. LINCS is not case-sensitive for the class_name parameter.
When using the format LUnn, the letters LU must be in capital letters, and the nn is the hex value of the desired LU. The client must also send the appropriate Service Name that is LINCS-compatible to let LINCS know which PU that the LU is on.
TN3270E Server
LINCS provides TN3270 and TN3270E Clients access to all types of 3270 hosts. Clients can connect to a LINCS node to communicate with SNA, Non-SNA and Bisync hosts on a session basis. LINCS provides server capabilities for TN3270 clients as defined in RFC1576, and
TN3270E clients per RFC 1647. The TN3270E server software feature, for LINCS with the appropriate software expansion FAD, consists of an extension of the current TELNET feature to allow a TELNET client attached via Ethernet or Token Ring to receive 3270 data. LINCS acts as a TN3270E server and the terminal is the TN3270 client.
When an incoming TELNET connection is established certain TELNET options can be negotiated to cause the connection to transition to a TN3270 type 3270 session. Subsequent data from LINCS (TN3270 server) to the terminal (TN3270 client) is 3270 data to be processed by a 3270 emulator running on the client. This allows the client to connect to a 3270 host computer as a DFT type terminal without requiring an ASCII emulation/translation on the server. The TN3270 client must be a TELNET client attached to the LINCS TELNET server via Ethernet/Token Ring or be routed across a Frame Relay connection.
Client emulation must be consistent with the 3270 LU type configured on the host. The server allows you to associate a specific LU with the client, but you must make sure that the client emulator supports all functionality associated with that LU. The server passes all RU’s to the client unmodified, including Write Structured Field (WSF) commands (including queries) and orders containing a 12/14/16 bit address field. The only exception is that a non-extended type client will not receive Write Structured Field commands. If the WSF is a query, the server replies with a null query response on behalf of any non-extended type client. The following client terminal types are supported:
IBM-3179-2 IBM-3180-2
IBM-3278-2 IBM-3278-3
IBM-3278-4 IBM-3278-5
IBM-3278-2-E IBM-3278-3-E
IBM-3278-4-E IBM-3278-5-E
IBM-3279-2 IBM-3279-3
IBM-3279-2-E IBM-3279-3-E
IBM-3279-4-E IBM-3279-5-E
LINCS assumes that the TN3270 client is capable of receiving an NVT ASCII data stream, the default mode for an incoming TELNET connection. The server can be configured to send NVT data to display a user prompt panel when the client connects.
When a TELNET client connects to the server, TELNET communication parameters are negotiated to establish the client-server interface. The negotiated session parameters determine whether or not this TELNET connection is a TN3270 type connection. Specifically, the End -Of-Record and Transmit Binary TELNET options must be supported by the client and server, and the client must negotiate IBM 32XX type terminal support using the Terminal Type TELNET option. The server usually initiates negotiation of these options at connect time, although either side may negotiate any option at any time. Note that the obsolete TELNET Regime option will be refused by the server.
TN3270 and (Async) TELNET connections must use different TCP Ports on LINCS. If TN3270/
TN3270E client connections are configured and a client connects on a TCP port configured for TN3270/TN3270E client connections, the server will attempt to negotiate the client as a TN3270E client first (if configured) then as a TN3270 client if the client refuses TN3270E. To connect the client as a TN3270 device, the TELNET options mentioned above will be negotiated.
At this point it is assumed that the client is a TN3270 client. If the client refuses one or more of the options, the server closes the TCP connection. If a client attempts to connect on a TCP port not configured for TN3270 client connections, the server will not attempt to negotiate TN3270 options.