WebSphere Optimized Local Adapters

WOLA supports connectivity between a WAS z/OS server and one or more of the following: CICS, IMS, Batch, UNIX Systems Services and ALCS.

Other inbound solutions existed, for example: While each had its respective strengths; each also had its particular shortcomings: overhead and latency; difficulty in construction; or deficiencies in the security or transaction propagation model.

External address space programs access the OLA interface using a set of supplied APIs.

Java programs running in WAS z/OS access the OLA interface through an implementation packaged as a standard JCA resource adapter.

IBM WebSphere Optimized Adapters function support has been updated as new versions or fixpacks are released.

Application of maintenance resulted in a new directory in the product file system that provided the WOLA modules, shared objects, JCA resource adapter and development class libraries.

A shell script (olaInstall.sh) created the necessary UNIX symbolic links from the runtime environment to product install file system.

The resource failover design is present in WebSphere Application Server Version 8 across all platforms for JDBC and JCA.

Note: WAS z/OS 8.5.0.0 provides WOLA support functionally identical to 8.0.0.1 Fixpack 1 to WebSphere Application Server for z/OS Version 8 provided the following functional updates to WOLA: Prior to 8.0.0.1 the native API modules were supplied in 31-bit callable format only.

The normal WAS z/OS SMF 120 subtype 9 record (or 120.9 in shorthand notation) was used to capture the inbound call information.

InfoCenter Search: rtrb_SMFsubtype10 This functional update provides the ability to distribute outbound calls across multiple external address spaces registered into a given WAS z/OS server using the same registration name.

A common usage pattern for this would multiple CICS regions with the same stateless target program service deployed.

InfoCenter Search: cdat_olacustprop The cross-memory nature of WOLA communications implies the WAS z/OS server and the external address space must be on the same z/OS logical partition (LPAR).

This provides a mechanism by which Java applications may use the supplied WOLA JCA resource adapter to access a target address space on remote z/OS.

The proxy application on WAS z/OS receives the call and forwards it over an actual cross-memory WOLA connection to the named target service.

This topology has limitations compared to outbound WOLA calls on the same z/OS LPAR: global transactions requiring two-phase commit can not be propagated across the IIOP connection to the WOLA proxy, and the user identity on the WAS thread can not be asserted into the target service on z/OS.

This provides a mechanism by which non-Java applications in an external address space may make inbound calls to a target WOLA-enabled EJB in a remote WAS instance, either on another z/OS LPAR or a distributed WAS platform.

This requires the local and remote WAS instances to have federated names spaces or operate as a single cell for the JNDI lookup to succeed.

In 8.0.0.4 (and 8.5.0.1) support updated to include RRS transaction context assertion from IMS dependent regions into WAS over WOLA: Fixpack 8.0.0.5 / 8.5.0.2 provided two functional enhancements: (1) RRS transaction context assertion from WAS into IMS over WOLA / OTMA, and (2) enhanced support for CICS channels and containers.

A BBOC transaction is also supplied to provide a set of control commands to do things such as manually start the TRUE (if not in PLTPI), stop the TRUE, start and stop the Link Server, as well as other control and management functions.

The OLA programming interface module library data set must be concatenated to the CICS region's DFHRPL DD statement.

The external address space accesses the OLA mechanism through the supplied interface modules and documented APIs.

A Java program wishing to initiate an OLA call outbound may be implemented as either a servlet or EJB.

It is possible to design the OLA-specific programming artifacts to serve as "bridges" between the OLA interface and existing assets.

That serves to minimize impact to existing programming assets and limits the degree of "platform lock in."

In this case the BBOA1REG API is used to register into the WebSphere Application Server for z/OS Daemon group (the cell short name), and multiple invocations of BBOA1INV are used to invoke the target EJB.

With the advent of maintenance 7.0.0.12, the Optimized Local adapters also support two-phase commit outbound from WAS to CICS.

Transactional propagation is not supported inbound or outbound to batch, USS or Airlines Line Control.