Keeping CICS TS 5.3 and z/OS Connect EE 2.0 maintenance in sync

zOS Connect EE can run standalone or within a CICS Liberty (embedded). Thus, the two environments must be described uniquely. You can also run both environments concurrently, but they are not mutually exclusive which is what makes maintenance even more complex.

The primary motivation for deploying z/OS Connect EE within a CICS TS Liberty server is to BYPASS using WebSphere Optimized Local Adapters (WOLA) as you do not need cross-memory access because everything runs nicely within CICS. The only reason a site would deploy WOLA in CICS AND run an embedded z/OS Connect EE in CICS is IF the z/OS Connect EE application programming interface (API) had to invoke a service outside of CICS. For example, calling WebSphere Application Server (WAS) to invoke an Enterprise Java Bean (EJB). WOLA in CICS TS would be used for the outbound requests. In this scenario, you would want to make use of the z/OS Connect EE version of Liberty WOLA modules for CICS because they have been tested to ensure compatibility.

The native standalone environment z/OS Connect EE servers needing to access CICS will need WOLA. So now, you will need to check maintenance and compatibility between what level of z/OS Connect EE server is running (for example a 16.0.0.3 Liberty version or a newer 16.0.0.4 or higher). In this case, the site should still try to use the z/OS Connect EE supplied Liberty WOLA modules as they are typically at a higher Liberty level (by a month or so) than CICS TS and Liberty development suggests the latest WOLA modules should work best and should be downward compatible.

Reference page 11 the following link for an overview of outbound WOLA calls from CICS: WebSphere z/OS Optimized Local Adapters (WOLA) presentation