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, as well as enable native
programs to act as a server and accept requests from applications
running in Version 7.0.
Before you begin
You must install
WebSphere® Application Server Version 7.0 Fix Pack 4.
Fix Pack 12 is required to support of Information
Management System (IMS) applications.
WebSphere Application Server regions that use
optimized local adapters must run in 64-bit mode. When you create
a new 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 the application server. It can be
either a partitioned data set or a PDS-E, and the library requires
approximately 40 tracks (3390) to hold the optimized local adapter
modules. In subsequent examples, this data set is called WAS.OLA.LOADLIB.
- Run the olaInstall.sh script
on each application server node that will use optimized local adapters.
- If the application server node was configured prior
to Version 7.0 Fix Pack 4,
you must start the node once at the Version 7.0 Fix Pack 4 level
or later. The post installer will create a link for the
olaInstall.sh script in the profile_root/bin directory for the application
server's node.
- Shut down all servers in the application server node.
- Run the olaInstall.sh script to install the optimized
local adapter code into the configuration directory for the application
server's node. Switch to the node's profile_root/bin
directory and run olaInstall.sh with the INIT option:
cd /wasv7config/azcell/aznodea/AppServer/profiles/default/bin
olaInstall.sh INIT WAS.OLA.LOADLIB
The olaInstall.sh
script creates the node-specific symbolic links that are required
for the optimized local adapters, and the script also writes the optimized
local adapter load modules out to the data set that you specify after
the INIT keyword.
You can also use the OLAMODS option to write
or rewrite the load modules to the data set, for example, if you apply
service to
WebSphere Application Server and
need to update the modules. For example:
cd /wasv7config/azcell/aznodea/AppServer/profiles/default/bin
olaInstall.sh OLAMODS WAS.OLA.LOADLIB
- Set WebSphere environment
variables to allow WebSphere Application Server to
use optimized local adapters. The variables are described
in the Optimized local adapters environment variables topic.
You
need to set these variables one time for each stand-alone application
server or WebSphere Application Server, Network Deployment cell:
- Set the cell-wide variable WAS_DAEMON_ONLY_enable_adapter
to true to allow the cell's daemon(s) to process inbound
and outbound optimized local adapter calls. This variable must be
set in order 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 on the
ola_cicsuser_identity_propagate variable in the Optimized local adapters
environment variables topic to understand the security implications
of setting this variable on your server.
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 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, ola.rar, and create a connection
factory. Make sure that you install the resource adapter archive
and create a connection factory on each application server node that
will handle incoming or outgoing connections for your optimized local
adapters.
You can use either the administrative console or the olaRar.py
script to install the resource adapter and create the connection factory:
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 execute applications that utilize
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 olainstall.sh script with the OLAMODS option for the data
set to ensure that the modules are at the latest level. For example:
olaInstall.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 don't need to have a separate copy for
each cluster.