DB2 Server for VSE: System Administration

Preparing the Application Server to use TCP/IP

The following must be done to allow the application server to use TCP/IP.

  1. TCP/IP for VSE must be installed and configured.
  2. For the Online Application Requester, the ARICTCP and CEEPIPI programs must be defined to the CICS where the application requester runs. Refer to the DB2 Server for VSE Program Directory for information on how to define these programs.
  3. The LE/VSE C runtime libraries must be available. For the Batch Application Requester, this is the PRD2.SCEEBASE library. For the Online Application Requester, these are the PRD2.SCEECICS and the PRD2.SCEEBASE libraries. Minimum support level of LE/VSE is Version 1 Release 4.
  4. The TCP/IP for VSE library must be available on both Online and Batch application requesters, this is the PRD1.BASE library. If your TCP/IP product is ordered directly from CSI (Connectivity Systems) or from a distributor, the product library is PRD2.TCPIP.
  5. To ensure proper TCP/IP functionality, the C runtime library and the TCP/IP library must follow a certain search sequence. The following are sample LIBDEF statements for the possible combinations:
  6. One JCL statement //OPTION SYSPARM='xx' should be added to the CICS startup JCL or the batch JCL, where xx is to match the xx specified in the ID=xx parameter for starting up a specific TCP/IP server. This is how the application requesters can route the TCP/IP function request to the correct TCP/IP server in case there are more than one TCP/IP server running in the same VSE/ESA system. If //OPTION SYSPARM is not specified, the default is 00.
  7. The VSE partition running the TCP/IP for VSE server should always have a higher priority than the partition running the DB2 for VSE database server.

TCP/IP support is invoked at system initialization time. If TCP/IP for VSE is available, the server will make use of it. The application server must be able to determine what port number to listen on for connections. This can be accomplished in a number of ways.

  1. The DBNAME Directory of the database has a port number specified for the TCPPORT parameter in the application server's DBNAME Local entry. See Setting Up the DBNAME Directory.
  2. The new initialization parameter, TCPPORT, can be used to specify the port number to listen on. Refer to the DB2 Server for VSE & VM Operation manual for a detailed description of the TCPPORT parameter.
  3. The well-known port number 446 is used, if available.

Each method has advantages and disadvantages.

The first method of using the DBNAME Directory is the preferred method. This directory is maintained by the database administrator and resides in a VSE library. Since more than one DB2 Server for VSE can run on the same VSE system, it must be ensured that they do not use the same TCP/IP port or users will be connected to the wrong database. Identifying the port numbers in the directory makes it easier to ensure that different servers are using different ports.

The second method of port identification is the new initialization parameter, TCPPORT. This is helpful when initially testing TCP/IP support or when TCP/IP support needs to be enabled, but the DBNAME Directory cannot be updated. The disadvantage is that it is possible that another application may be using the same port. If this occurs, an error message is received during initialization showing a BIND failure with return code 1115 indicating that the port was already in use by another application.

The third method is the least desirable. If there is no port number specified in the DBNAME Directory for the application server or a TCPPORT initialization parameter was not specified, there is a well known port assignment for relational databases. It is called ddm-rdb and the port number is 446. This has the advantage of doing no extra configuration to TCP/IP for VSE and to the application server. The disadvantage is that only one application server on the VSE system can use the definition.

We will take advantage of all of the methods. The actions can be broken down into the following scenarios.

  1. If the TCPPORT initialization parameter is not specified when the application server is started, the application server will search the DBNAME Directory for its corresponding Local entry to see if the TCPPORT parameter is specified. If it is specified and the value is not zero, it will be used as the port number of the listener socket to be created. If the value is zero, no TCP/IP initialization will be performed. If the TCPPORT parameter is not specified, it will use the well known port number 446 to create the listener socket.
  2. If the TCPPORT is specified when the application server is started, the application server will use this parameter while performing TCP/IP support initialization. If the port cannot be used, no attempt is made to find another port. If any error is returned from a TCP/IP function used, it will be assumed that TCP/IP is not available and TCP/IP support on the application server will not be used.

After the TCP/IP support for the application server is initiated, a TCP/IP agent is created to handle all TCP/IP related functions. If any TCP/IP function failure was detected by the TCP/IP agent, the TCP/IP support for the application server will be disabled. It is possible to restart the TCP/IP support for the application server without recycling the application server. This can be done by using the new START TCPIP operator command. Refer to the DB2 Server for VSE & VM Operation manual for a detailed description of this command.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]