TN3270 Access to Mainframe SNA Applications

© IBM Corporation 2007 2007 IBM System z Expo
®
TN3270 Access to Mainframe SNA Applications
Andy Tracy - andyt@us.ibm.com

Enterprise Networking Solutions (ENS) and Transaction Processing Facility (TPF)
Trademarks and notices
The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States
or other countries or both:
ƒAdvanced Peer-to-Peer
Networking®
ƒAIX®
ƒalphaWorks®
ƒAnyNet®
ƒAS/400®
ƒBladeCenter®
ƒCandle®
ƒCICS®
ƒDB2 Connect
ƒDB2®
ƒDRDA®
ƒe-business on demand®
ƒe-business (logo)
ƒe business(logo)®
ƒESCON®
ƒFICON®
ƒGDDM®
ƒHiperSockets
ƒHPR Channel Connectivity
ƒHyperSwap
ƒi5/OS (logo)
ƒi5/OS®
ƒIBM (logo)®
ƒIBM®
ƒIMS
ƒIP PrintWay
ƒIPDS
ƒiSeries
ƒLANDP®
ƒLanguage Environment®
ƒMQSeries®
ƒMVS
ƒNetView®
ƒOMEGAMON®
ƒOpen Power
ƒOpenPower
ƒOperating System/2®
ƒOperating System/400®
ƒOS/2®
ƒOS/390®
ƒOS/400®
ƒParallel Sysplex®
ƒPR/SM
ƒpSeries®
ƒRACF®
ƒRational Suite®
ƒRational®
ƒRedbooks
ƒRedbooks (logo)
ƒSysplex Timer®
ƒSystem i5
ƒSystem p5
ƒSystem x
ƒSystem z
ƒSystem z9
ƒTivoli (logo)®
ƒTivoli®
ƒVTAM®
ƒWebSphere®
ƒxSeries®
ƒz9
ƒzSeries®
ƒz/Architecture
ƒz/OS®
ƒz/VM®
ƒz/VSE
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Intel, Intel Inside (logos), MMX and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Red Hat is a trademark of Red Hat, Inc.
SUSE® LINUX Professional 9.2 from Novell®
Other company, product, or service names may be trademarks or service marks of others.
This information is for planning purposes only. The information herein is subject to change before the products described become generally
available.
All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only.
All performance data contained in this publication was obtained in the specific operating environment and under the conditions described and is
presented as an illustration. Performance obtained in other operating environments may vary and customers should conduct their own testing.
Refer to www.ibm.com/legal/us for further legal information.
© 2007 IBM Systems IBM Corporation

TN3270 agenda
The basics of TN3270
High Availability Considerations
 TN3270 server configuration

The basics of TN3270

TN3270 is an element of your SNA modernization strategy
CICS
Preserve and re-use
ICCF RYO
IMS CMS TSO
z/OS
z/VSE
z/VM
z/TPF
SNA network infrastructure
ƒToken-ring LANs
ƒIBM 37xx Controllers
ƒChannel-attached SNA
gateways (IBM 2216,
Cisco CIP or CPA)
ƒAnyNet solutions
ƒSNA-specific data links
ƒESCON channels
3270
3270
Emulato
r
SNA/IP
Integration
Servers
3270
WebSphere
Application
Server
ATM,
POS
Real IBM
3270
devices
SNA 3270
emulators
SNA client
(LU0/LU6.2)
Frame relay, SDLC, X.25 (SNA
and non-SNA), LAN bridge
Traditional SNA clients with client SNA
stacks
(SNA nodes)
TN3270 emulator
integrated with
Web browser
SNA client
over remote
SNA API
3270
Emulato
r
TN3270
emulators
B Simplify the
SNA node
topology
ƒTN3270
ƒRemote SNA APIs
ƒRemote desktop
B
Traditional SNA client interfaces,
without distributed SNA stacks
(Thin SNA nodes)
AModernize the SNA
network
infrastructure
ƒAPPN w. EE/SNA Switch
ƒCCL with NCP and NPSI
ƒIP-TG, XOT, DLSw
Extend or build up the
IP network
infrastructure so it
integrates both SNA and
IP traffic
A
OSA
Web browser
with HTML
transformation
Web services
requester
C
CEnable new client
technologies
ƒHTML transformation
ƒWeb services integration
New client
interfaces
(Thin clients)
HATS

VT
A
M
CICS or other
SNA
Application
CICS
Trans-action
LU2
LU1/3
TN3270 and
TN3270E
telnet
server
ASCII/EBCDIC
conversion
3270
terminal
emulator
328x
printer
emulator
TN3270 basics
The 3270 data stream that is 'relayed' by
the TN3270 server between the TCP
connection and the SNA session is a
traditional 3270 data stream
ƒMix of 3270 commands, set buffer
addresses, attribute bytes, and text
data
ƒThe TN3270 client breaks the 3270
data stream up into proper elements
and converts between ASCII and
EBCDIC for text elements only
Support for extended 3270 data streams
and 3270 graphics is determined solely
by the emulator software
ƒThe TN3270 server happily relays
everything
There is a TCP connection and a matching SNA session for each TN3270 emulator window that is started on the
workstation
ƒSame client IP address may need to be able to establish many connections - one per active emulator window
Each connection is mapped to either a display terminal session (SNA LU Type 2) or a printer session (SNA LU Type
1 or 3)
ƒDetermined based on terminal type negotiations with the TN3270 server
All connections must be initiated from the TN3270 client
ƒA TN3270 server does not in general support establishing outbound connections to clients
ƒEven printer sessions must be started from the client workstation before an SNA session can send print data over the
printer session

TN3270 protocol basics
The TN3270 protocols originally grew out of the basic Telnet protocol as defined in RFC
854.
ƒThis base Telnet protocol as defined in RFC 854 and RFC 855 was first extended through RFC
1041 that introduced the concept of IBM 3270 terminal access using the basic Telnet protocol.
Since then TN3270 has been more precisely defined and extended through the following RFC
standards documents:
–RFC 1576 - TN3270 Current Practices (generally referred to as base TN3270)
–RFC 1646 - TN3270 Extensions for LUname and Printer Selection
–RFC 1647 - TN3270 Enhancements (now obsolete and replaced by RFC 2355)
–RFC 2355 - TN3270 Enhancements (generally referred to as TN3270E)
TELNET
TN3270
ƒIn addition to the above RFCs, there has over the last few years been a few draft RFCs that have
been widely implemented, but never made it into an official RFC:
–draft RFC: "TN3270E Functional Extensions" - <draft-ietf-tn3270e-extensions-04.txt>
Send Data Indicator, Keyboard Restore Indicator, BID support
Support for return of SNA sense code information to TN3270 client
–draft RFC: "TLS-based Telnet Security" - <draft-ietf-tn3270e-telnet-tls-06.txt>
SSL/TLS negotiated TN3270 connections
Almost all TN3270 servers and clients today are based on the TN3270E protocol level
(RFC2355 plus optional draft RFC extensions)
TN3270E
ƒTN3270 generally refers to the TN3270E protocol level.
ƒTo clearly distinguish, we sometimes use TN3270 to identify base TN3270 level and TN3270E to
define the TN3270E level - but that should be clear from the context.

How telnet sessions start out
All telnet connections initially start out as plain line-mode ASCII telnet connections
ƒThis is referred to as the NVT (Network Virtual Terminal) state
Telnet protocol-defined negotiations then occur to establish the precise characteristics and
capabilities of the client and the server
ƒFor TN3270 connections, this is where TN3270 or TN3270E negotiation options are exchanged
ƒIf TN3270E is negotiated, then subnegotiations will further determine the exact TN3270E options that
will be in effect for this connection
If the client chooses not to negotiate a TN3270 type of connection, most TN3270 servers are
able to continue the connection as any other plain ASCII-based line mode telnet server
ƒThis example uses the PuTTY telnet client to connect to the z/OS TN3270 server. PuTTY does not
understand TN3270 protocols at all! In this line-mode scenario, the text data is
exchanged as ASCII text between the client and
the server.
The z/OS TN3270 server performs
ASCII/EBCDIC codepage conversion for such
line-mode connections.
The codepages to use are defined on the
codepage configuration statement:
ƒCodePage ISO8859-1 IBM-1047
If the client negotiates a TN3270 type of
connection, then all codepage conversion is
done by the client and not the TN3270 server!
ƒMake sure you get the client configurations set
up correctly with the correct codepage names.

How is a TN3270E connection established?
TN3270E
Emulator
Client IP address
and port TCP Connection
TCP connect processing
IAC,DO,TN3270E
IAC,WILL,TN3270E
IAC,SB,TN3270E,SEND,DEVICE-TYPE,IAC,SE
IAC,SB,TN3270E,DEVICE-TYPE,REQUEST,"IBM-3278-4-E",IAC,SE
Server IP address
and port
IAC,SB,TN3270E,DEVICE-TYPE,IS,"IBM-3278-4-E",CONNECT,"TCPABC80",IAC,SE
IAC,SB,TN3270E,FUNCTIONS,REQUEST,BIND-IMAGE,RESPONSES,SYSREQ,IAC,SE
IAC,SB,TN3270E,FUNCTIONS,IS,BIND-IMAGE,RESPONSES,SYSREQ,IAC,SE
0000 HDR SNA bind image ACK Sequence: 0
000000 31010303 91903080 008487F8 80000280 00000000 18500000 7E000006 E3C5D3D5
000020 C5E300
0028 CMD IAC,EOR
002A HDR 3270 data stream ACK Sequence: 0
002F OUT Erase/Write 05C2 Restore
TN3270
Server
SNA Primary LU
Application
SNA SLU SNA PLU
SNA Session
SNA CINIT
SNA BIND
IBM 3270 data stream IBM 3270 data stream

What are the main differences between base TN3270 and TN3270E?
TN3270E supports the following functions in addition to the base TN3270 capabilities:
ƒSYSREQ key
ƒATTN key
ƒClient notification of BIND image
You generally want
to use TN3270E, if
your TN3270 client
supports it!
–Client cannot negotiate bind image parameters, but it can be notified of the bind image that was used
to establish the SNA session and customize its operations accordingly
ƒBoth SNA and non-SNA logmode
ƒSNA definite and exception response request and reply
ƒContention resolution (Send Data Indicator, Keyboard Restore Indicator, BID)
–Based on a draft RFC
ƒProvides SNA sense code to TN3270 client
–Based on a draft RFC
ƒClient requesting specific LU name or LU in a specific LU name pool
ƒSNA LU Type 1 (SCS) and Type 3 (DSC) printer support
–Base TN3270 had some limited printer support added through RFC 1646, but the z/OS TN3270 server
chose to implement full TN3270E support instead

There are more ways of getting to z/OS SNA 3270 applications and to
the z/OS UNIX Shell
T
C
P
/
I
P
UNIX
RloginD
UNIX
SSHD
UNIX
TelnetD
rlogin
ssh
vtxxx
ANSI
DUMB
.?.
CICS or other
SNA
Application 3270
terminal
emulator
V
T
A
M
z/OS
CICS
Trans-action
LU2
LU1/3
TN3270,
TN3270E,
and
SNA line
mode
UNIX
Shell
328x
printer
emulator
An rlogin client can connect to
the RloginD server on z/OS.
The client will be connected
directly to a UNIX shell
process.
An ssh client can connect to
the SSHD server on z/OS.
The client will be connected
directly to a UNIX shell
process.
A line-mode or raw-mode telnet
client can connect to the UNIX
Telnet server. The client will be
connected directly to a UNIX shell
process - no VTAM involvement,
no TSO.
A line-mode or
TN3270 telnet client
can connect to the
TN3270 server. The
connection will be
mapped to an SNA
LU and an SNA
session will be
created with the help
of VTAM.

a Assign an LU name at random
out of a pool of TN3270 server
LU names
b Assign an LU name based on
who the client is - client IP
address, hostname, etc.
Known as LU nailing.
aOptionally verify that the client
is allowed to use the
requested LU name
a Assign a printer LU name that
matches the previously
assigned terminal LU name
Just give me an
LU name !!
I want LU name
LUNAME3 !!
Give me a printer
LU name that
matches terminal
LU name
LUNAME4 !!
Generic LU
name
request
Specific LU
name
request
Printer
association
request
LUNAME1
LUNAME2
LUNAME3
LUNAME4
IP@1
IP@2
Select
LUNAME1
LUNAME2
LUNAME3
LUNAME4
IP@1
IP@2
Verify
LUNAME1
LUNAME2
LUNAME3
LUNAME4
LUNAMEP1
LUNAMEP2
LUNAMEP3
LUNAMEP4
How are LU names assigned by the TN3270 server?
It can be an administratively rich process to manage a TN3270 server configuration!!

What's the first thing the user should see on the terminal?
USS Message 10 screen
ƒStandard SNA USS message 10 screen
processing
ƒz/OS TN3270 server does USS message
processing (not VTAM's SSCP)
A specific SNA application's logon
screen, such as CICS or TSO
ƒAny SNA primary LU can be used
ƒFirst thing to see will be the SNA
appliation's logon screen
An SNA session manager's logon screen, such as ISM or TPX
ƒUser logon with SAF authentication and SNA application selection typically done by the SNA session
manager
ƒLU name management could be a concern if the session manager uses relay mode
The z/OS TN3270 server solicitor panel
ƒProvides user logon with SAF authentication and SNA application selection by the TN3270 server
before any SNA application is accessed
ƒCan be used to provide SNA application access authorization based on the user ID

What about security?
Most main-stream TN3270 client software supports secure TN3270 connections
ƒTCP connection between TN3270 client and TN3270 server is secured using SSL or TLS protocols
–Server authentication, data confidentiality, message integrity and authentication
ƒThe z/OS TN3270 server can use either built-in SSL/TLS logic, or it can make use of the common
SSL/TLS support on z/OS that is known as ATTLS (Application Transparent TLS)
–From z/OS V1R9, the preferred method is ATTLS
More functions and less CPU overhead
ƒTN3270 client authentication is supported by the z/OS TN3270 server, and is required if the Express
Logon Feature (ELF) is used
–ELF provides an ability to bypass selected application sign-on panels, such as a CICS or TSO sign on panel
Secure connection!!

How to monitor response times
TN3270 server performance monitoring is built into the z/OS TN3270 server
Request
Reply
+/- (DR)
RSP
Life-of-connection and life-of-SNA-session data
ƒTransaction count
ƒRound trip & IP response time totals
ƒAverages for round trip, IP, and SNA response times
Sum of squares for variance and standard deviation
ƒRound trip, IP, and SNA sum of squares
Round trip response time counts by time bucket
Response times
Bucket 1
Transaction
count
TN3270E
Client
SNA Application
z/OS TN3270 Server
A
B
C
Round-trip time = Time C - Time A
IP time = Time C - Time B
SNA time = Round trip time - IP time
Timestamps
Sliding window data for sliding window averages
ƒPeriod transaction count
ƒPeriod round trip & IP response time totals
ƒSliding window transaction count
ƒSliding window round trip & IP response time totals
0 B1 max
msec
Bucket 2
Transaction
count
Bucket 3
Transaction
count
Bucket 4
Transaction
count
Bucket 5
Transaction
count
B2 max B3 max B4 max
Response time data reporting:
ƒTN3270 end-of-SNA-session SMF
records
ƒTN3270 response MIB through a
TN3270 server SNMP subagent
ƒMVS console display commands
ƒNetwork Management Interface (NMI)
Used by Tivoli OMEGAMON XE
for Mainframe Networks

How to manage service level agreements and charge back
Response time monitor data can be used to verify if agreed-to service level agreements in
terms of end-user response time are met or not
ƒCan be run periodically for groups of users
ƒCan be enabled for individuals when response time problems are reported
ƒThe z/OS TN3270 server can measure and report response time data via MVS console command
output, SNMP queries, SMF records (z/OS V1R8), and the Network Management Interface (z/OS V1R8).
–Note: Only one out of 8 potential server address spaces on z/OS can enable the SNMP subagent that is
used to report the data via SNMP
ƒThe z/OS V1R8 response time reporting enhancements provides the response time data in the TN3270
server SNA session termination SMF records as well as real-time access over the Network Management
Interface (NMI) for network management applications, such as Omegamon.
SNA session termination SMF records can be used to generate charge-back information:
ƒClient IP address is known
ƒTelnet session type, device type, and individual telnet session options are known
ƒUse of SSL or not is known
ƒByte counts in/out are known
ƒSNA application and logmode are known
ƒSNA session duration is known
ƒResponse time data
–SNA segment
–TCP segment
–Round-trip
ƒ... more details ...

High Availability Considerations

Two general design choices for TN3270 server high availability
Single System Image pool of
servers for connections that need
no LU nailing.
Single server with stand-by server
for connections that need LU
nailing.
IP address
take-over
Availability through server replication
ƒLoad balancer sends new connections to available servers
in the pool
ƒIf n servers in pool, a server outage will affect (current
connections/n) connections.
ƒThe affected users will be able to immediately establish a
new connection with one of the n-1 remaining servers
Individual servers may be
ƒIndividual operating systems images each with one server
instance
ƒMultiple server instances running in a single operating
system image (only z/OS)
Client IP address-based timed-affinity should be used
ƒIf printer association is needed
ƒIf z/OS TN3270 're-connect' support is needed
Availability through stand-by server
ƒWhen active server goes down, the identity of that
server (IP address and port number) is taken over by
the stand-by server
ƒAll current connections are affected by an outage
ƒTime to recover (be able to establish a new connection)
depends on time to move identity to stand-by server
Primary server and stand-by server should be
implemented on separate operating system images
(and on separate hardware)

z/OS TN3270 server scenario
11 VTAM
TN3270
Server
TCP/UDP
IP/ICMP
DLC
z/OS
Local
SNA
Appl
Sessions
Network
DLC
OSA-E
QDIO
z/OS
TN3270
Server
TCP/UDP
IP/ICMP
DLC
Local
SNA
Appl
Sessions
Network
DLC
OSA-E
QDIO
z/OS
LBA
z/OS
LBA
1
12
2
3
4
11
12
10
7 6 5
10
9
8
1
2
3
4
7 6 5
8
9
Load balancing
weights
IP access network to data
centers
VTAM
VTAM
z9
VTAM
VTAM
VTAM

General considerations for high availability designs
How many parallel servers are good and how many are bad?
ƒMore than one so not all users will be impacted by a server instance outage
ƒHigh enough for remaining server instances to pick up workload from failed instance within a short
predefined period of time (seconds/minutes)
ƒBut not so high that management and operational aspects become a complicating factor
Load balancing technology characteristics:
ƒPreferably "intelligent load balancing" - load-balancing decision point able to factor in:
–Available server instance and server node capacity
–Server instances' current ability to meet predefined performance objectives
–Server instance availability
ƒOptimal traffic pattern
–No extra in-line flows for load balancer to make decision
–Direct optimal routing between clients and server instances
ƒBoth Sysplex Distributor and external load balancers (using the z/OS Load Balancing Advisor) can
do the job

TN3270 Server Configuration

Telnet Configuration statements
● Telnet has three main configuration blocks
•TelnetGlobals
•Parameters which apply to entire Telnet server
•TelnetParms
•Defines port for Telnet server
•Configures behavior of TN3270 server
•BeginVtam
•Maps objects, like LU names or USS tables, to clients based on
client identifiers, like IP address or hostname
●Multiple TelnetParms and BeginVtam blocks can be coded to
configure multiple ports.

TelnetGlobals
● One TelnetGlobals block per Telnet instance
•Defines parameters for entire Telnet server
•Some parameters can only be specified here
•TCPIPJOBNAME, TNSACONFIG, XCFGROUP
• Most TelnetParms statements can be coded here to configure
behavior for the entire server
TELNETGLOBALS
TCPIPJOBNAME TCPIP
XCFGROUP
JOIN
ENDXCFGROUP
TN3270E
SHAREACB
ENDTELNETGLOBALS

TelnetParms
● Each TelnetParms block defines a port to the Telnet server
•One of PORT/SECURPORT/TTLSPORT is a required parameter
•Additional parameters define behavior for this port. For example
•INACTIVE – how long a terminal SNA session can be inactive
before being dropped
•MAXRECEIVE – how many bytes to accept from the client
without an End or Record(EOR) before dropping connection.
• Can override a setting in TelnetGlobals for a particular port
TELNETPARMS
TTLSPORT 23
INACTIVE 3600
MAXRECEIVE 65535
NOSEQUENTIALLU
ENDTELNETPARMS

BeginVtam
● Each BeginVtam block defines objects and clients to the Telnet
server for a port
• Defines objects, such as LU groups or applications
• Defines client identifier groups, such as hostname or IP addresses
•Then maps objects to client identifiers
•Port statement connects this to a TelnetParms statement
BEGINVTAM
PORT 23
DEFAULTLUS
TCPM1000..TCPM2000
ENDDEFAULTLUS
LUGROUP lugrp_name
TCPM3000..TCPM3500
ENDLUGROUP
IPGROUP ipgrp_name
9.9.9.0/24
ENDIPGROUP
LUMAP lugrp_name ipgrp_name
ENDVTAM

ParmsGroup
● ParmsGroup allows you to map a set of Telnet parameters based
on a client identifier
• Define a ParmsGroup in a BeginVtam blockto allow a certain set
of client to have different behavior than the other users on a Telnet
port
• For example, disable TN3270E support for a specific IP address
BEGINVTAM
PORT 23
....
PARMSGROUP tn_only
NOTN3270E
ENDPARMSGROUP
IPGROUP no3270e
9.9.10.1
ENDIPGROUP
PARMSMAP tn_only no3270e
....
ENDVTAM

Response Time Monitoring
● Configure monitoring in the profile
•Create a MonitorGroup and map the group to clients using the
MonitorMap statement.
•You do not need to set up TNSACONFIG if SNMP is not being
used.
BEGINVTAM Block
MONITORMAP mongrp_name client_id
MONITORGROUP mongrp_name
AVERAGE/NOAVERAGE
AVGSAMPMULTIPLIER n
AVGSAMPPERIOD sec
BOUNDARY1,BOUNDARY2,BOUNDARY3,BOUNDARY4 msec
BUCKETS/NOBUCKETS
DYNAMICDR/NODYNAMICDR
INCLUDEIP/NOINCLUDEIP
ENDMONITORGROUP

TN3270 Access to Mainframe SNA Applications

More Related Content

What's hot

Viewers also liked

Similar to TN3270 Access to Mainframe SNA Applications

More from zOSCommserver

Recently uploaded

TN3270 Access to Mainframe SNA Applications