This chapter tells you how to verify that CICS communications are working correctly after you have installed CICS Option and run the standard installation verification procedure described in the chapter CICS Installation Verification.
An installation verification procedure (IVP) is provided for communications. It can be run for all supported communications protocols listed in the table below, but note that it does not cover the use of the communications protocol LU 6.2 between CICS Option and an MVS mainframe CICS region.
The IVP checks that transaction routing, distributed transaction processing, distributed program linking, and function shipping are working correctly after product installation. It uses two regions, COMIVP1 and COMIVP2, and can be run standalone on a single machine in a multi-tasking environment using two instances of Mainframe Express. It can also be run on two separate machines, with one region on each machine (COMIVP1 on machine 1 and COMIVP2 on machine 2). Region COMIVP1 can be run in a single-tasking or multi-tasking environment, but region COMIVP2 must be run in a multi-tasking environment.
You must also decide if you are going to run the IVP as a multi-tasking to multi-tasking, or single-tasking to multi-tasking peer-to-peer test.
You can run only one communications IVP at any one time for any one network protocol on a network.
Depending on which communications protocol you have set up, you need one of the following System Initialization Tables (SITs) as the base SIT for your project during the running of the IVP:
| Novell IPX |
NetBIOS | TCP/IP | |
|---|---|---|---|
| Windows NT | DFHCIPX | DFHCNETB | DFHCTCP |
| Windows 95 | DFHCIPX | DFHCNETB | DFHCTCP |
Notes: If you run the IVP using two separate machines, you must use the same protocol on each machine. The two machines can be on different platforms, as long as the protocol is available on each platform.
If you are using TCP/IP, you must first start a ccitcp2 daemon if one is not already running on the network.
To start a ccitcp2 daemon, from the Mainframe Express command prompt enter the command:
ccitcp2
Diagnostic information is displayed if you start the ccitcp2 daemon with
the parameter -d.
If you are running your IVP on two separate machines, you must set the machine ID on both machines running the ccitcp2 process:
You must set the base SIT for the projects comivp1 and comivp2 according to the protocol you are using.
Open the project comivp1:
Set the base SIT for the project:
You must repeat this procedure for the project comivp2.mvp, either on the same machine if you are using only one machine, or on the second machine if you are using two.
You can run the IVP either on a single machine or on two machines.
If you need a reminder about which keys to use to emulate the action of 3270 terminal keys, see the section Use of Keys in CICS Option in the chapter CICS Installation Verification.
Run the IVP as follows:
Start Mainframe Express and open project comivp2 in the IDE. To do this:
Start a new instance of Mainframe Express and open project comivp1 in the IDE. To do this:
Start region COMIVP2. To do this:
To run a multi-tasking to multi-tasking test, start region COMIVP1, wait until the regions are connected and start a 3270 terminal emulation. To do this:
Examine the console log displayed in the output window for project comivp1 and wait for the message TXCS1109I for COMIVP2 to be displayed.
Examine the console log displayed in the output window for project comivp2 and wait for the message TXCS1110I for COMIVP1 to be displayed.
Alternatively, to run a single-tasking to multi-tasking test, start a single-tasking region COMIVP1 and wait until the regions are connected. To do this:
You are now ready to run the IVP tests.
Run the transaction routing test:
Run the distributed transaction processing test:
Run the distributed program link test:
Run the function shipping test:
You have now completed the IVP tests.
Close down the 3270 terminal emulation and region COMIVP1. To do this:
Close down region COMIVP2. To do this:
If you are using TCP/IP, you can now stop the ccitcp2 daemon.
You have now completed the communications IVP running on a single machine.
Run the IVP as follows:
| Machine 1 | Machine 2 |
|---|---|
Start Mainframe Express and open project comivp2 in
the IDE. To do this:
|
|
Start Mainframe Express and open project comivp1 in
the IDE. To do this:
|
|
Start region COMIVP2. To do this:
|
|
To run a multi-tasking to multi-tasking test, start
region COMIVP1 and wait until the regions are connected. To do this:
|
|
| Examine the console log displayed in the output window and wait for
the message TXCS1109I for COMIVP2 to be displayed. |
Examine the console log displayed in the output window and wait for
the message TXCS1110I for COMIVP1 to be displayed. |
Start a terminal for COMIVP1. To do this:
|
|
Alternatively, to run a single-tasking to
multi-tasking test, start a single-tasking region COMIVP1 and wait until
the regions are connected. To do this:
|
|
| Examine the console log displayed in the output window and wait for
the message TXCS1110I for COMIVP1 to be displayed. |
|
| You are now ready to run the IVP tests. |
|
Run the transaction routing test:
|
|
Run the distributed transaction processing test:
|
|
Run the distributed program link test:
|
|
Run the function shipping test:
|
|
| You have now completed the IVP tests. |
|
|
Close down the 3270 terminal emulation and region COMIVP1. To do this:
|
|
|
Close down region COMIVP2. To do this:
|
If you are using TCP/IP, you can now stop the ccitcp2 daemon.
You have now completed the communications IVP running on two machines.
Below is a list of problems that you might experience if you are unable to complete the communications IVP successfully:
Make sure that you have specified the correct SIT to the project.
If you are using TCP/IP, make sure that you have started the ccitcp2 daemon and that the correct machine ID is specified for CCI configuration. You will get a TXCS1101W (CCI error: No "CCITCP2" process was detected) in the console log if the ccitcp2 process cannot be found.
If you get the TXCS1114E (Load of CCI protocol module for CCITCP failed) message, check that you have configured CCI correctly.
Make sure that the COMIVP2 region is started within the timeout duration after the COMIVP1 region has started, otherwise they will fail to connect. You will get the TXCS1107W message (Activate for connection COMIVP2 failed, reason = 0001). The default timeout duration is approximately two minutes.
If COMIVP2 is started first, it will remain available for COMIVP1 to connect to unless it or the daemon is shut down.
If you are using NetBIOS, make sure that the requester is running, otherwise you will get a TXCS1113S error in the console log.
You can use the CGWY transaction to check the status of a CCI gateway to see if it has been started successfully.
It is possible for the COMIVP1 region to get message TXCS1110I instead of TXCS1109I (and for COMIVP2 to get TXCS1109I). This means that the regions connected in reverse time order and does not affect the running of the IVP.
If the two regions fail to connect (you do not receive the TXCS1109I message on your COMIVP1 console) you may get the following symptoms if you proceed with the IVP:
Make sure that you have specified the correct base SIT for the project.
The communications IVP comprises several different tests that are described here.
Transaction REG2 runs transaction CENV in region COMIVP2. When the transaction has run in COMIVP2, the second line of the screen displays TXREGN COMIVP2.
Transaction DTPF allocates a connection to COMIVP2, connects to process DTPB, defined in COMIVP2, and then issues a CONVERSE with the session. DTPF sends a buffer filled with character 'A's and receives a buffer from DTPB which should be filled with character 'B's. The sent and received buffers are displayed on the screen to ensure the data is correct.
Transaction DPLF tests links to program DPLREG2, defined to run in COMIVP2, passing a commarea containing character 'A's. DPLREG2 receives the commarea, replaces the 'A's with 'B's and returns control back to COMIVP1. The sent and received buffers are displayed on the screen to ensure that the data is correct.
Transaction ACCT is used to test function shipping. The definitions supplied ensure that the transactions run in COMIVP1 using files defined in COMIVP2. Displaying the surnames tests the shipping of STARTBR and READNEXT to COMIVP2.
The resource definitions used for the communications IVP are described here.
Which SIT you use is dependent on the communications protocol you decide to use. The following SITs are defined:
| Protocol Platform |
Novell IPX |
NetBIOS | TCP/IP |
|---|---|---|---|
| Windows NT | DFHCIPX | DFHCNETB | DFHCTCP |
| Windows 95 | DFHCIPX | DFHCNETB | DFHCTCP |
Each SIT differs in that the appropriate protocol flag for the communications gateway is set to 'Y'.
The SYSID and APPLID fields in these SITs are not used in this peer-to-peer configuration and this is the recommended method for configuring peer-to-peer communications. The SYSID and APPLID in these SITs are set to IGN1. This configuration uses the name of the TERMINAL definition as the target SYSID and the region name as the netname defined in that TERMINAL definition as the APPLID - so throughout this communications IVP the SYSID fields for remote definitions are set to REG1 or REG2 and in the autoinstall exit the ASSIGN APPLID command returns the region name as that in the TERMINAL defined netname.
Note: This technique only works when region name = netname in the TERMINAL definition.
The autoinstall exit program is also specified in the SIT. This exit program, comivpai, controls and defines the terminal ids of the connected clients and ensures that these terminal ids are unique so that as more get started no conflicts occur in the system.
The startup list name in the SIT is again protocol-dependent. The startup list name matches the SIT name.
The startup lists are also organized according to the selected protocols. The lists consist of the standard supplied groups (based on DFHLIST + DFH$IVP + communications groups) plus two others:
The only definitions contained in these groups are the CONNECTION definitions REG1 and REG2 with the difference being the defined protocol.
If the SYSID for a definition is either not specified or matches the system it is running on, the definition is treated as a local definition. Otherwise it is treated as a remote definition and requests for that resource are routed to that SYSID. This technique allows for the maintenance of only one set of resource definitions for both regions.
This group is used in both the COMIVP1 and COMIVP2 regions.
These definitions contain all details for the programs, transactions, and files that are used for the IVP. They are supplemented by the definitions in the DFH$ACCT standard IVP group. This causes duplicate entries for the ACCTFIL and ACCTIX files, the definitions in the DFHCIVP group defining the target as a remote system. As the definition loaded last is the one that is used, the precedence of the groups in the startup list is significant.
PCT - REG2 - This transaction is started on REG1 but is transaction-routed to REG2 and executes in that region routing its output back to REG1. The program that executes on REG2 is DFHZCENV. This displays the environment for REG2. Fields to note on the Remote page of the PCT Properties dialog box are:
System ID: REG2
Transaction ID: CENV.
These two fields show the destination of the transaction, REG2, and the transaction that this invokes, CENV.
PCT - DPLF - This points to the region1 local program DPLREG1 that executes and forms the front end of the Distributed Program Link test.
PCT - DTPF - This points to the region1 local program DTPREG1 that executes and forms the front end of the Distributed Transaction Programming test.
PCT - DTPB - This points to the region2 program DTPREG2 that executes and forms the back end of the Distributed Transaction Programming test. Fields to note here are:
System ID: REG2
Transaction ID: DTPB
PPT - DPLREG2 - This points to the region2 program DPLREG2 that executes and forms the back end of the Distributed Program Link test. The fields to note on the Remote page of the PPT Properties dialog box are:
System ID: REG2
Program ID: DPLREG2
These definitions act to determine local or remote execution destination and to show the program that should be executed at that destination - in this case the program name is DPLREG2. This need not match the PPT entry name.
FCT - ACCTFIL/ACCTIX - These are copies of the definitions for this file and its alternate indexes that are exactly the same as the standard ones in the DFH$ACCT standard IVP except for the following fields on the Remote page of the FCT Properties dialog box:
System ID: REG2
File: ACCTFIL or ACCTIX
These fields control the local or remote destination of the file and the file names they map to.
Each of these groups contains two definitions:
Connection - REG1
Connection - REG2
These definitions define the characteristics of the connections between the two regions.
Fields to note are:
Connection id:
Net Name:
Protocol:
Connection type: CCI
Session Maximum: greater than zero
| Connection ID: | This is the name of the definition but in the configuration as we have it defined it becomes the SYSID name for the remote region. |
| Net Name: | This must be the peer region name. It specifies the region name of the peer system this definition applies to. If the netname is the same as the region name, the connection ID overrides the local SYSID. If the netname is not the same as the region name, this region tries to communicate to the region specified by the netname using the protocol defined in the default mode parameter. If this definition is installed at system initialization and the netname is not the same as the region name, a CCI gateway is started automatically without any CCI gateway flag having to be set in the SIT. |
| Protocol: | This defines the protocol to use on this connection and is CCITCP, CCINETB, or CCIIPX, dependent on the resource definition group you are looking at. The protocol here should match that of the selected gateway in the SIT. |
If you have a valid connection ID defined in a group that is in the startup list, the gateway is automatically started.
The xxx is replaced by TCP, IPX, or NETB depending
on which protocol is used.
SIT----->Startup List----->Groups------->Definitions
DFHCxxx->DFHCxxx---------->DFHCIVP------>PCT - REG2
PCT - DPLF
PCT - DTPF
PCT - DTPB
PPT - DPLREG2
FCT - ACCTFIL
FCT - ACCTIX
DFHCxxx------>Conn - REG1
Conn - REG2
This shows the way the various names and parameters go together to
define the connections. Again, xxx is replaced by
the appropriate protocol name. These values are all set in the connection
definition.
Region Name---->Netname--->Sysid--->Protocol COMIVP1-------->COMIVP1--->REG1---->CCIxxx COMIVP2-------->COMIVP2--->REG2---->CCIxxx
Setting the region name to be the same as the netname starts the system with the appropriate connection definition when the /r parameter is used.
The autoinstall exit program, comivpai, is used by either region to determine the terminal ID to allocate for any terminals that are started to a system. This ensures that the terminal ids within a network configuration remain unique.
The most recently allocated terminal ID is maintained in the CWA.
Terminals connected to COMIVP1 have a terminal ID beginning with 'B'.
TTerminals connected to COMIVP2 have a terminal ID beginning with 'C'.
The comivpai program is the autoinstall exit for both regions and uses the ASSIGN APPLID command to determine which region it is executing in.
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.