Enabling the Liberty server environment to use optimized local adapters

You must enable the Liberty server to receive inbound and outbound requests by using the optimized local adapters support. WebSphere® optimized local adapters (WOLA) for z/OS® are a set of callable services (APIs) that give native z/OS applications the ability to make inbound calls to application server enterprise beans and enable native programs to act as a server and accept requests from applications that run in the Liberty server.

1. Allocate or select a load module library to contain the optimized local adapter load modules.
   This library is used by applications that are running outside the Liberty server. The library must be a PDS-E and requires approximately 40 tracks (3390) to hold the optimized local adapter modules.
2. Copy the optimized local adapter load modules from wlp/clients/zos/* to the load module library.
   The following example shows how to copy load modules into the $DSNAME data set:

   cp -Xv wlp/clients/zos/* "//'$DSNAME'" 

3. To enable optimized local adapters support on the Liberty server, configure the zosLocalAdapters-1.0 feature in the server.xml file.
   1. To enable the feature, add the zosLocalAdapters-1.0 feature to the server.xml file as shown in the following example.

      <featureManager>
        <feature>zosLocalAdapters-1.0</feature>
      </featureManager>

   2. Create a WOLA group by configuring a zosLocalAdapters element with a three-part WOLA group name in the server.xml file.
      The three-part WOLA group name is used by clients to connect to the Liberty server. Each part of the group name must be 1 to 8 alphanumeric characters.

      Note: Do not use lowercase characters in the WOLA group name. The z/OS security subsystem converts lowercase characters to uppercase, which can cause a mismatch with your configuration.

      You must take note of an environment where WOLA is used by Liberty and by a traditional WebSphere Application Server. You must ensure that the WOLA group name for the Liberty server (the first part of the three part WOLA group name) is different than the Daemon group name configured for the traditional WebSphere Application Server.

      <zosLocalAdapters wolaGroup="LIB1" wolaName2="LIB2" wolaName3="LIB3"/>

4. Configure a connection factory by adding a connectionFactory element to the server.xml file and specifying its properties in a properties.ola element.

   <connectionFactory jndiName="eis/ola">
    <properties.ola RegisterName="OLASERVER"/>
   </connectionFactory>
   

   For information about WOLA connection factory properties, see Connection factory properties for optimized local adapters on Liberty.
5. Create SERVER profiles for z/OS.
   1. Create SERVER profiles for the optimized local adapter authorized service.
      Use the following Time Sharing Option (TSO) commands:

      RDEF SERVER BBG.AUTHMOD.BBGZSAFM.LOCALCOM UACC(NONE)
      PERMIT BBG.AUTHMOD.BBGZSAFM.LOCALCOM CLASS(SERVER) ACCESS(READ) ID(wlpuser1)
      RDEF SERVER BBG.AUTHMOD.BBGZSAFM.WOLA UACC(NONE)
      PERMIT BBG.AUTHMOD.BBGZSAFM.WOLA CLASS(SERVER)ACCESS(READ) ID(wlpuser1)

   2. Create a SERVER profile for the authorized client module BBGZSCFM and permit the Started Task user ID of the Liberty server to the profile. This action enables a Liberty server to load the z/OS Authorized client services.
      To enable a server that is running as WLPUSER1 to access the authorized client module:

      RDEF SERVER BBG.AUTHMOD.BBGZSCFM UACC(NONE)
      PERMIT BBG.AUTHMOD.BBGZSCFM CLASS(SERVER) ACCESS(READ) ID(wlpuser1)

   3. Create SERVER profiles for optimized local adapter authorized client service.
      Use the following TSO commands:

      RDEF SERVER BBG.AUTHMOD.BBGZSCFM.WOLA UACC(NONE)
      PERMIT BBG.AUTHMOD.BBGZSCFM.WOLA CLASS(SERVER) ACCESS(READ) ID(wlpuser1)

   For more information, see Enabling z/OS authorized services on Liberty for z/OS.
6. If you have CBIND enabled in System Authorization Facility (SAF), grant access to the clients that will use optimized local adapters.
   1. Define a profile for the Liberty server in the CBIND class.
      The profile name is BBG.WOLA.<WOLA1>.<WOLA2>.<WOLA3>, where WOLA1,WOLA2, and WOLA3 are the three parts of the optimized adapter group name that are specified in the <zosLocalAdapters> element in the server.xml file. You can define a profile by using the SAF RDEFINE TSO command.
      For example, the following command creates a profile in the CBIND class for a WOLA group named LIB1.LIB2.LIB3:

      RDEF CBIND BBG.WOLA.LIB1.LIB2.LIB3 UACC(NONE)

   2. Permit READ access to the profile.
      For example, the following command permits read access for the username user name on the bbg.wola.lib1.lib2.lib3 profile:

      PERMIT BBG.WOLA.LIB1.LIB2.LIB3 CLASS(CBIND) ACCESS(READ) ID(username)

      You can use asterisks to permit a user access to multiple profiles. The following example permits READ access to the username user for all profiles that start with bbg.wola in the CBIND class:

      RDEF CBIND BBG.WOLA.* UACC(NONE)
      PERMIT BBG.WOLA.* CLASS(CBIND) ACCESS(READ) ID(username)

   For more information about SAF commands and syntax, see the documentation for your version of z/OS.