Configure extended function path routing

Extended function path OptiConnect requires the configuration of an APPC device and controller. The controller description will have a type of *OPC, indicating to the device driver layer to use the bus. However, you cannot bypass some of the communication layers, as with the Fastpath method. This method is necessary for certain functions like two-phase commit, and some Lotus® Domino® Applications (LS:DO) that use LS:DO to access remote data. This is known as Extended Function Path OptiConnect.

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

Use the following commands to configure the *OPC controller:

Create the 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 uses OptiConnect to communicate). The Data Link Role of one system must be *PRI (primary), and the other must be *SEC (secondary). Setting the destination service access point (DSAP) value will set both the source service access point (SSAP), and DSAP parameters. The DSAP value must be valid and identical for both controllers on both systems in the pair. Valid values are 04, 08, 0C, 10, 14, ...78, 7C.

The following is an example of creating an *OPC controller on two systems: SYSTEMA and SYSTEMB. To create a controller on SYSTEMA to connect to SYSTEMB, enter the Create Controller Description (CRTCTLAPPC) command. The joblog now shows:

   > CRTCTLAPPC CTLD(SYSBCTL) LINKTYPE(*OPC) RMTSYSNAME(SYSTEMB)
                        ROLE(*PRI) DSAP(44)
      Description for controller SYSBCTL created.

Create a device description for each controller on each system.

CRTDEVAPPC DEVD(SYSBDEV) RMTLOCNAME(SYSB) ONLINE(*NO)  LCLLOCNAME(SYSA)
CTL(SYSBCTL) APPN(*NO)

The *OPC controller will only accept devices that are created with APPN(*NO). The RMTLOCNAME and LCLLOCNAME need to be mirror images of the RMTLOCNAME and LCLLOCNAME on the other system in the 'pair.' Parameter ONLINE at IPL should be *NO since you cannot vary on OptiConnect controllers and attached devices until the QSOC subsystem has started.

The following are examples for creating an *OPC device description to attach to the controller. To create a device description on SYSTEMA to attach to controller SYSBCTL, enter the Create Device Description (CRTDEVAPPC) command.

The joblog now shows:

 > CRTDEVAPPC DEVD(SYSBDEV) RMTLOCNAME(SYSB) ONLINE(*NO)
    LCLLOCNAME(SYSA) CTL(SYSBCTL) APPN(*NO) 
    Description for device SYSBDEV created.

On the other system in the 'pair,' create a controller and device description that will point to the previously created descriptions. On SYSTEMB enter the CRTCTLAPPC command to connect to SYSTEMA.

The joblog now shows:

 > CRTCTLAPPC CTLD(SYSACTL) LINKTYPE(*OPC)
                  RMTSYSNAME(SYSTEMA) ROLE(*SEC) DSAP(44)
      Description for controller SYSACTL created.

Create a device description on SYSTEMB to attach to controller SYSACTL. Enter the CRTDEVAPPC command.

The joblog now shows:

 > CRTDEVAPPC DEVD(SYSADEV) RMTLOCNAME(SYSA) ONLINE(*NO)
           LCLLOCNAME(SYSB) CTL(SYSACTL) APPN(*NO) 
      Description for device SYSADEV created.

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

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

When the first of a pair of *OPC controllers is varied on, the status of the controller changes to ACTIVE/CNN PENDING or VARYON/CNN PENDING. That is, if the device is not varied on. This indicates that the OptiConnect path is not yet completely established. After the second of the *OPC pair is varied on, both controllers change to ACTIVE status, and the OptiConnect connection is available for data transfer.

Note:

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

The following are examples to vary on controllers and devices. Use the VRYCFG command on SYSTEMA to vary on controller SYSBCTL.

The joblog now shows:

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

Use the VRYCFG command on SYSTEMB to vary on controller SYSACTL.

The joblog now shows:

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

Setup DDM files:

Use the same locations for the Remote and Local location parameters that were previously specified in the APPC device description. Use *LOC for the device description parameter. Remote and Local Locations that are defined in the devices attached to the *OPC controllers can also be used in Structured Query Language (SQL) relational database directories. For more information, see SQL over OptiConnect.

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

The *OPC controllers can be used to provide APPC communication capability across the OptiConnect bus. An application program using the ICF file interface, the CPI communication call interface, or the CICS® file interface can communicate with an application running on a remote system using OptiConnect. It is not restricted to previous OptiConnect applications such as DDM and SQL.

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

Note:

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