The SNA architecture has a method for tracking dependent LU resources associated with an IP address. TN3270 clients and Remote API Clients using dependent LUs can display the IP address information from a Host query.
There is no similar architecture for indendent LU6.2 resources. When Remote API Clients use a local LU on the distributed server to access Host resources, no IP address is provided to show what client is using what LU6.2.
Secondly, the implementation of SNA applications usually only requires client resources to contact the host or server resources. In some scenarios, the host or server application needs to send a connection request, or ATTACH, to the clients.This could be a problem as Remote API Clients are mobile and not always associated with the same end point.
The reason for the inability to track LU6.2 resources used by IP clients is that the SNA architecture does not have any way to provide that information, currently.
Resolving the problem
The Communications Server for Data Center Deployment v7 supports this function of tracking LU6.2 resources used by the clients. The implementation documented here is also in the documented in the Communincations Server for Data Center Deployment Administration Guide. This function is also included in the distributed Communications Server for AIX v220.127.116.11, Communications Server for Linux v18.104.22.168 and the Communications Server for Linux on System z v22.214.171.124.
The distributed Communications Server for AIX, Communications Server for Linux on System z, and Communications Server for Linux ship the Remote API Client as part of the product packages. Starting with release version, v126.96.36.199, there are 2 APARs that, used together, will enable an administrator to track the use of LU6.2 resources on the server by the Remote API Client applications. This will allow upstream applications that need to contact downstream clients the ability to attach sessions, even when the clients are mobile or dynamically connecting to the servers from multiple end points in the IP network.
First, the APAR IV10996 is required on the server to enable tracking clients' DNS hostname information as LU6.2 sessions are started by the Remote API Clients. A new PTF_FLAG setting for the DEFINE_NODE record has been added. After the APAR modules are installed, the server node configuration needs to have the following parameter set to enable tracking.
Issue either of the following as needed:
"snaadmin -c define_node,ptf_flags=CLI_OVERWRITE_SYS_NAME"
or if the ptf_flags is already set to some parameter, use the plus sign, "+" , to invoke tracking:
"snaadmin -c define_node,ptf_flags=SUPPRESS_PU_NAME_ON_REQACTPU+CLI_OVERWRITE_SYS_NAME"
Second, the APAR IV11152 is needed for Windows Remote API Clients to dynamically append the client's hostname to the TP_Name field of a TP_START verb. With this APAR, if the filename "tpnamehost" exists in the Remote API Client install directory (\ibmcs\w64cli for example), then all the TP_STARTED messages from the client with append the full host name after a separator of "%" (in EBCDIC). On the server, the local LU will have its sys_name parameter changed to this client host name. This is then used for routing subsequent incoming conversations on this LU.
The APAR is not required if the following 2 environment variables are set in the application scope:
APPCLLU = set to the LU Alias for the Local LU on the server
APPCTPN = Any string followed by "%" DNS hostname
On a Windows client, the settings could be as follows:
C:\appldir\appltest> set APPCLLU=p45lu62
C:\appldir\appltest> set APPCTPN=XYZ%cs04.raleigh.ibm.com
An API trace of a CPI-C application using the default TP Name is here:
opcode = 14
opext = 0
primary_rc = 0 OK
secondary_rc = 0 OK
lu_alias = 7034356C75363220
. . . % . . . .
p 4 5 l u 6 2
tp_id = 0000000000000001
@ @ @ @ @ @ @ .
. . . . . . . .
tp_name = C3D7C9C36DC4C5C6C1E4D3E36DE3D7D5C1D4C56C83A2F0F44B998193858987884B8982944B83969440404040
C P I C _ D E F A U L T _ T P N A M E % c s 0 4 . r a l e i g h . i b m . c o m
. . . . m . . . . . . . m . . . . . . l . . . . K . . . . . . . K . . . K . . . @ @ @ @
The server will display the client's information on the query_local_lu call on the server:
[root@cs05 ~]# snaadmin -d query_local_lu,lu_alias=p45lu62
list_options = DETAIL + LIST_INCLUSIVE
lu_name = P45LU62
list_name = ""
description = Local LU for server access
lu_alias = p45lu62
nau_address = 0
syncpt_support = NO
lu_session_limit = 0
default_pool = NO
pu_name = ""
lu_attributes = NONE
allowed_sscp_id = 0
disable = NO
sys_name = cs04.raleigh.ibm.com
The APARS to implement this feature are found on Fix Central:
The Communications Server for AIX v188.8.131.52, Communications Server for Linux v184.108.40.206 and Communications Server for Linux on System z v220.127.116.11 PTF level already have these APARs. You can upgrade the v18.104.22.168 to v22.214.171.124 using the PTF packages provided on Fix Central.
|Networking||Communications Server for Linux||All||Linux xSeries||126.96.36.199, 188.8.131.52, 184.108.40.206||All Editions|
|Networking||Communications Server for AIX||All||AIX||220.127.116.11, 18.104.22.168, 22.214.171.124||All Editions|
|Networking||IBM Communications Server for Data Center Deployment||All||AIX, Linux, Linux on System z||126.96.36.199||Enterprise|