Running the TCPaccess and IBM stacks on the same LPAR

book

Article ID: 53092

calendar_today

Updated On:

Products

CA TCPaccess

Issue/Introduction

Description

System and configuration considerations to be aware of; when running both the TCPaccess and IM stacks on the same LPAR.

Solution

These are the basic rules for running a TCPaccess and IBM stack on 1 LPAR.

  1. When running only TCPaccess, many customers will have the tcpaccess.SASLINK and tcpaccess.LINK libraries in the LINKLIST.
    When running TCPaccess and IBM stacks together, we recommend STEPLIBing the libraries for both stacks instead of LINKLISTing to avoid confusion.
    Some customers LINKLIST the primary stack; and STEPLIB secondary one.


  • The TCPaccess.LOAD should never be in the LINKLST.


  • Ensure that the TSO logon procedure contains libraries needed for FTP, PING, etc if these are not in the LINKLIST.


  • Make sure the SSID's for each stack are different. There is usually no problem between TCPaccess and IBM as the defaults are different, but each TCPaccess stack must have a unique SSID.


  • If you are not running IUCV in TCPaccess, skip this step.
    If you are running IUCV, the IBM stack no longer supports the API, but is still using VMCF.
    If the TCPaccess stack is using IUCV:
    - Change the VMCFNAME to a non-default name in your TCPaccess stack.
    This is done by changing the VMCFNAME parameter in the IJTCFG to a non-default value.
    - The IUCV parameter should be coded in the APPLICATIONS statement in the IJTCFG.
    Alternately the INTERNALIUCV parameter may be used, but this is no longer the current way to do things.
    See Chapter 2 in the Configuration Guide for further explanation on both parameters.
    - Notes regarding this, along with the INTERNALIUCV parameter can be found in Chapter 18 of the Customization Guide.
    - It is possible to run IUCV as an external application but this is no longer recommended.
    - Any applications running with IUCV must have the correct VMCFNAME coded in the dataset pointed to in the SYSTCPD DD statement contained in the application JCL.
    For further information regarding IUCV configuration and requirements refer to Chapter 18 of the Customization Guide.


  • Each stack needs separate VTAM definition and configuration.


  • Open Edition (Unix Systems Services) should be set up to connect to all stacks.
    Do this by editing the BPXPRMxx member in the SYS1.PARMLIB. Stacks should be defined as SUBILESYSTYPE's under CINET. Entry point for all 6.0 TCPaccess stacks is T010PFSA.
    Please be aware that ports used by Open Edition cannot be shared between stacks with this setup.
    More information regarding this configuration can be found in Chapter 4 of the TCPaccess Planning Guide, Chapter 7 of the C Sockets Programmers Reference and Chapter 7 of the Customization Guide.
    Here is a sample BPXPRM:
  •           FILESYSTYPE TYPE(CINET)                       ENTRYPOINT(BPXTCINT)                    SUBFILESYSTYPE NAME(SNSTCP60) <---name must match STC name of TCPaccess stack                         DEFAULT                         PARM('SYSID(ACSS)')                         TYPE(CINET)                         ENTRYPOINT(T010PFSA)          SUBFILESYSTYPE NAME(TCPIP)                         TYPE(CINET)                         ENTRYPOINT(EZBPFINI)          NETWORK DOMAINNAME(AF_INET)                                                                       DOMAINNUMBER(2)                                                                           INADDRANYPORT(10000)                                                                      INADDRANYCOUNT(1000)                                                                      MAXSOCKETS(60000)                                                                         TYPE(CINET)   
  • For all TCPaccess stacks defined in the BPXPRM under CINET be sure to code a SYSUNIQ statement in your TCPCFG. Example:
     SYSUNIQ SYSNAME(USCMCVT1)
  • Where SYSNAME is a name for the stack that must be defined in the network nameserver. In, general, the hostname of the stack can be used.
    Example: If your fully qualified hostname is hostname.ca.com, you would define SYSUNIQ SYSNAME (hostname).
    If your stack does not have a hostname, any value that is defined in the network nameserver that resolves to the IP address of the stack can be used.
    If SYSUNIQ is not defined, TCPaccess will try to resolve the SMFID of the system to the IP address of the stack and some applications will not be able to connect.
    To verify that the value you have selected will work, issue a PING against it from the network (i.e. DOS prompt), and see if it resolves to the stack IP address.
    If so, it can be used as the value for SYSNAME.
    Please note that values with dotted decimal notation cannot be used.

    More information is available in Chapter 3 of the Customization Guide.

  • When running both TCPaccess and IBM FTP servers, be sure to code stack affinity in the IBM FTP server.
    Stack Affinity limits the application to connect to one stack only so prevents OE/USS from having IBM's FTP Server listen on port 21 of the TCPaccess stack.
    To implement this, code the following Stack Affinity information in your IBM FTPD started task:
        //      FTPD   EXEC PGM=&MODULE,REGION=4096K,TIME=NOLIMIT,                                //      PARM=('POSIX(ON) ALL31(ON)',                                                //      'ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP")',                                 //      '/&PARMS')                          
  • If this is not defined, the IBM FTP server will try to connect to all stacks defined in the BPXPRM under CINET.
    This is because it uses OE(USS) sockets, and that is standard processing for that socket interface.
    That means it will connect to TCPaccess as well as IBM. When it connects to the TCPaccess stack, you now have two FTP servers running, and FTPs coming in to the TCPaccess stack will load balance between the two listeners.
    Since an FTP expecting the TCPaccess server will not be able to connect correctly to the IBM FTP server, half of the FTP's will fail.
    Coding stack affinity will prevent the problem permanently.

  • If there are any other USS applications for which stack affinity should be defined, it can be done either as in the above step, or by adding;
     //STEP1  EXEC PGM=BPXTCAFF,PARM=TCPIP
  • as an extra step in front of the actual jobstep.

  • If the external TCPaccess Telnet Server (module T04STSSL in the SERVICE statement of the APPCFG) is used:
    Be aware that by default this server port will listen on all CINET stacks EVEN IF IT IS CODED IN A FULL STACK. Connectivity can by limited by


  1. Coding IPADDRESS (ip_address) in the SERVICE statement for that telnet server port.
    This allows different Telnet ports to be assigned to different interfaces, on the same or different CINET stacks.
    Problems may arise when a stack has multiple interfaces defined mixed with VIPA connections. Also, specifying TNGLOBAL PROVIDER will not allow connections to be established on IPADDRESS interfaces on a stack other than the PROVIDER'S.


  • Coding TNGLOBAL PROVIDER (stackname) in the APPCFG.
    This supplies stack affinity, allowing all Telnet ports to listen only on the specified CINET stack Coding no TNGLOBAL or IPADDRESS will cause the server to listen on all CINET stacks.


  • If the external TCPaccess FTP Server (module T051C in the SERVICE statement of the APPCFG) is used: Be aware that this server port will listen on all CINET stacks EVEN IF IT IS CODED IN A FULL STACK. Connectivity can be limited by:


  1. Coding PROVIDER(stackname) in the GLOBAL statement of the APPCFG. This supplies stack affinity, allowing FTP to listen only on the specified CINET stack Coding no PROVIDER parameter will cause the server to listen on all CINET stacks.

Environment

Release:
Component: NTCPAC