You must enable the application server to receive inbound
and outbound requests using the optimized local adapters support.
Optimized Local Adapters for z/OS® is
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 running in
the WebSphere® Applications
Server.
Before you begin
WebSphere Application
Server regions that use optimized local adapters must run in 64-bit
mode. When you create an application server, it is automatically configured
to run in 64-bit mode. If you find that your application server is
configured to run in 31-bit mode, you can convert your application
server to run in 64-bit mode. To learn how to do this conversion,
see the topic, Running servers in 31-bit mode, and the section "Converting
a migrated server to run in 64-bit mode."
Procedure
- Allocate or select a load module library to contain the
optimized local adapter load modules. This library is used
by applications running outside WebSphere Application
Server. It can be either a partitioned data set or a PDS-E, and requires
approximately 40 tracks (3390) to hold the optimized local adapter
modules. In subsequent examples, this data set is called WAS.OLA.LOADLIB.
- Switch to the node's profile_root/bin directory and
run the copyZOS.sh script
with the OLAMODS option:
cd /wasconfig/azcell/aznodea/AppServer/profiles/default/bin
copyZOS.sh OLAMODS WAS.OLA.LOADLIB
The copyZOS.sh script
writes the optimized local adapter load modules out to the data set
that you specify after the OLAMODS keyword.
- Set WebSphere environment
variables to allow the application server to use optimized local adapters.
The variables are described in the topic, Optimized local adapters
environment variables.
You need to set these variables for each
stand-alone application server or Network Deployment cell.
- Set the cell-wide variable WAS_DAEMON_ONLY_enable_adapter
to true to allow the cell daemons to process
inbound and outbound optimized local adapter calls. This variable
must be set to use the optimized local adapters.
- Use the cell-wide variables WAS_DAEMON_ONLY_adapter_max_conn,
WAS_DAEMON_ONLY_adapter_max_serv, and WAS_DAEMON_ONLY_adapter_max_shrmem
to set the maximum number of connections, maximum number of outbound
services, and maximum amount of shared memory allocated to optimized
local adapter sessions by the daemon.
- Use the ola_cicsuser_identity_propagate variable
to control propagation of security identities during registration.
This variable, which can be set at the cell or node level, must be
set to 1 to allow the optimized local adapters
samples to run.
Important: Read the information
about the ola_cicsuser_identity_propagate variable
in the topic Optimized local adapters environment variables to
understand the security implications of setting this variable on your
server.
- If you are using the CICS Link
Server, and you want to specifying multiple containers using a MappedRecord,
set the LinkTaskChanID variable to the name
of the channel which will hold the containers.
- If you are using the CICS Link
Server, and you want to specifying multiple containers using a MappedRecord,
set the LinkTaskChanType to the type of channel
which will hold the containers (CHAR=0|BIT=1). The default value for
this variable is 1.
You can use the administrative console or scripting to set these
variables. The olaRar.py script that is described in the next step
sets the WAS_DAEMON_ONLY_enable_adapter variable
to true, but does not alter any other WebSphere Application Server
environment variables.
- Install the resource adapter archive, which is the ola.rar
file, and create a connection factory. For each application
server node that uses the optimized local adapters, you must also
install the resource adapter archive, and create a connection factory.
The copyZOS.sh script creates a symbolic link to
this archive file from each application server node install_root/installableApps
directory.
You can use either the administrative console or the
olaRar.py script to install the resource adapter and create the connection
factory:
If you want to use the resource adapter high availability
feature, you must configure additional connection pool properties
on each connection factory. Refer to the topic, Enabling resource
adapter high availability support, for more information on how to
set up and use this feature.
For more information about connection
factories, see the topic, Connection factory considerations for optimized
local adapters.
- Restart the WebSphere Application
Server daemon to put these changes into effect. Restarting
the daemon causes all the cell servers on the same z/OS system to be stopped.
When the daemon
is starting, confirm that the adapter is active. A message in the
daemon log indicates if the optimized local adapter is activated or
not, as follows:
- Support is activated: BBOMOOO1I enable_adapter:1
- Support is not activated: BBOMOOO1I enable_adapter:0
Results
The optimized local adapters support is now enabled.
What to do next
You can now deploy and start applications that use WebSphere Application Server
for z/OS optimized local adapters
on the enabled application server nodes.
For all of
the external connections that use the optimized local adapters, ensure
that they are running the latest version of the OLAMODS data set for
your level of
WebSphere Application Server:
- Run the copyZOS.sh script with the OLAMODS option for the data
set to ensure that the modules are at the latest level. For example:
copyZOS.sh OLAMODS WAS.OLA.LOADLIB
- Make sure this data set is made available to all of the external
address spaces that use the optimized local adapters. For example,
make sure it is available in the STEPLIB for batch jobs, DFHRPL library
for CICS (Customer Information Control System), and DFSESL for IMS
data definitions.
You can share the same generated data set across
different clusters; you do not need to have a separate copy for each
cluster.