Configuring extended function path routing

 

You configure OptiConnect extended function path routing for two-phase commit and some Lotus® Domino® applications.

The extended function path method requires the configuration of Advanced Program-to-Program Communication (APPC) controllers and devices. The controller description needs to have a link type of *OPC, which indicates to the device driver layer that the controller is attached to the optical bus (OptiConnect). The extended function path method cannot bypass some of the communication layers as the fast path method. However, this method is necessary for certain functions, such as two-phase commit, and for some Lotus Domino applications (LS:DO) that use LS:DO to access remote data.

To route data requests through OptiConnect without using the special device keyword, you create OptiConnect controllers and devices of link type *OPC. The remote system name must be the name of the target system.

To configure *OPC controllers and devices, follow these steps:

  1. Create a controller description: CRTCTLAPPC CTLD(name) LINKTYPE(*OPC) RMTSYSNAME(sysname) ROLE(*PRI or *SEC) DSAP(##). You must create a pair of *OPC controllers (one on each of the two systems that use OptiConnect to communicate). The data link role of one system must be *PRI (primary) and the data link role of the other system must be *SEC (secondary). The destination service access point (DSAP) value must match the source service access point (SSAP) value assigned to the remote controller. Valid DSAP values are 04, 08, 0C, 10, 14, ...78, 7C.

    The following job log shows an example of creating an *OPC controller on one system SYSTEMA to connect to the other system SYSTEMB: 

       > CRTCTLAPPC CTLD(SYSBCTL) LINKTYPE(*OPC) RMTSYSNAME(SYSTEMB)
                        ROLE(*PRI) DSAP(44)
      Description for controller SYSBCTL created.
  2. Create a device description for a device attached to the controller: CRTDEVAPPC DEVD(SYSBDEV) RMTLOCNAME(SYSB) ONLINE(*NO) LCLLOCNAME(SYSA) CTL(SYSBCTL) APPN(*NO).

    The *OPC controller only accepts devices that are created with APPN(*NO). The remote location (RMTLOCNAME) and local location (LCLLOCNAME) values specified for one system must match the LCLLOCNAME and RMTLOCNAME values specified for the other system in the pair. The Online at IPL (ONLINE) parameter must be set to *NO because you cannot vary on OptiConnect controllers and attached devices until the QSOC subsystem has started.

    The following job log shows an example of creating a device description on SYSTEMA for a device attached to controller SYSBCTL: 

     > CRTDEVAPPC DEVD(SYSBDEV) RMTLOCNAME(SYSB) ONLINE(*NO)
    LCLLOCNAME(SYSA) CTL(SYSBCTL) APPN(*NO) 
    Description for device SYSBDEV created.
  3. On the other system in the pair, create a controller description that points to the description created in Step 1. The following job log shows an example of creating a controller description on SYSTEMB to connect to SYSTEMA: 
     > CRTCTLAPPC CTLD(SYSACTL) LINKTYPE(*OPC)
                  RMTSYSNAME(SYSTEMA) ROLE(*SEC) DSAP(44)
      Description for controller SYSACTL created.
  4. Create a device description on SYSTEMB for a device attached to controller SYSACTL: 
     > CRTDEVAPPC DEVD(SYSADEV) RMTLOCNAME(SYSA) ONLINE(*NO)
           LCLLOCNAME(SYSB) CTL(SYSACTL) APPN(*NO) 
      Description for device SYSADEV created.

  5. Repeat steps 1 and 2 for all the system pairs in the OptiConnect network.

  6. Vary on all *OPC controllers and devices to enable requests over OptiConnect.

    When one *OPC controller in the pair is varied on, the status of the controller changes to ACTIVE/CNN PENDING or VARYON/CNN PENDING. This indicates that the OptiConnect path is not completely established. After the other *OPC controller is varied on, the status of both controllers changes to ACTIVE, and the OptiConnect connection is available for data transfer.

    You must start the QSOC subsystem on both systems before varying on the *OPC controllers and their attached devices. If the QSOC subsystem is ended on either of the systems, the controllers on that system and all connected systems change to the status ACTIVE/CNN PENDING or VARYON/CNN PENDING. After the QSOC subsystem is restarted, there cannot be any activity through these controllers until they are varied off and then back on.

    Use the Vary Configuration (VRYCFG) command to vary on controllers and devices. The following job log shows an example of varying on controller SYSBCTL on SYSTEMA: 

     > VRYCFG CFGOBJ(SYSBCTL) CFGTYPE(*CTL) STATUS(*ON)
      Vary on completed for controller SYSBCTL.
      Vary on completed for device SYSBDEV.

    The following job log shows an example of varying on controller SYSACTL on SYSTEMB: 

     > VRYCFG CFGOBJ(SYSACTL) CFGTYPE(*CTL) STATUS(*ON)
      Vary on completed for controller SYSACTL.
      Vary on completed for device SYSADEV.

  7. Set up DDM files.

    Use the same remote and local locations that are specified in the APPC device description. Use *LOC for the device description parameter. The remote and local locations that are defined for the devices attached to the *OPC controllers can also be used in Structured Query Language (SQL) relational database directories.

Although varying on the *OPC controllers and devices enables traffic over OptiConnect, varying off these devices and controllers does not necessarily block the traffic. To ensure that OptiConnect activity is stopped, use the vary option of the Work with OptiConnect Activity (WRKOPCACT) command, or end the QSOC subsystem.

The *OPC controllers can be used to provide APPC capabilities across the OptiConnect bus. An application program that uses the intersystem communications function (ICF) file interface, the Common Programming Interface for Communications (CPI-C), or the CICS® file interface can communicate with an application on a remote system through OptiConnect. Previously, only a DDM or an SQL application could use OptiConnect to communicate with a remote application.

The default QYCTSOC APPC device description has *PUBLIC authority *CHANGE, so any users can use OptiConnect. To keep the public from using OptiConnect, use the Revoke Object Authority (RVKOBJAUT) command, and then use the Grant Object Authority (GRTOBJAUT) command to grant *DEVD access to specific users.

The APPC device description does not describe a device. It is used to control authority and access to the OptiConnect path.

 

Parent topic:

Configuring OptiConnect

Related concepts
Routing SQL over OptiConnect

Related tasks
Configuring fast path routing
Related reference
Create Controller Description (APPC) (CRTCTLAPPC) command Create Device Description (APPC) (CRTDEVAPPC) command Create Distributed Data Management File (CRTDDMF) command Grant Object Authority (GRTOBJAUT) command Revoke Object Authority (RVKOBJAUT) command Vary Configuration (VRYCFG) command Work with OptiConnect Activity (WRKOPCACT) command