This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
If you’ve used WOLA with WAS traditional you might be wondering about the stubs. In TWAS we provided some WOLA stubs which you linked with your non-Java application. These stubs resolved the external references to the WOLA APIs you’d used in your application and, under the covers, could find and drive the actual WOLA code (located outside the stubs). How does this work with WOLA in Liberty?
Our goal when writing the original TWAS stubs was to have them do as little as possible. They just need to find the ‘real’ WOLA code and branch to it. This reduces the chances we’ll take an APAR on the stub code and force you to re-link all your WOLA applications. If you were to crack open the WOLA stub code you’d find that they pretty much do a series of ‘load’ instructions to run a control block chain to find where we’ve put the real WOLA code and then ‘branch’ to the address we find. That’s the address where the TWAS WOLA code lives.
Thus, in Liberty we’ve got a similar set of WOLA code that implements the WOLA APIs in order to talk to a Liberty server. That kind of suggests we have to have a different set of stubs that knows how to find the Liberty WOLA code. And so we do. Liberty ships its own set of stubs. However, we tried to be a bit clever.
It turns out that much of the control block chain we run to find the TWAS WOLA code is the same as the chain to find the Liberty WOLA code. There’s an important difference at the very end of the chain. So it isn’t a big deal for the Liberty stubs to also know how to find the TWAS code, in addition to the Liberty code. The trick is knowing which one to use.
The Liberty stubs assume if you’re using them then you’re using Liberty, or are maybe in the process of transitioning to Liberty, so it tries the Liberty WOLA code first. If doing that works (i.e. we can find the server you’re trying to talk to) then we’re all set. But if it doesn’t work then either you’ve made a mistake (wrong 3-part name maybe, or the target server isn’t up) OR…you’re trying to talk to a TWAS server. So the stub recognizes the problem using the Liberty WOLA code and tries again using the TWAS WOLA code. Basically it falls back to TWAS if Liberty doesn’t work.
Thus you can use the Liberty stubs to talk to either a Liberty server or a TWAS server using WOLA. The TWAS stubs weren’t updated and remain locked into the TWAS WOLA code only.
Bottom line – if you’re using WOLA with Liberty, you have to use the Liberty stubs. If you’re using WOLA with TWAS you can use either set of stubs. If you’re transitioning between TWAS and Liberty it might make sense to just use the Liberty stubs everywhere to avoid having to re-link your applications depending on what type of server they are talking to.
Also, if you look close at where the stubs are shipped in TWAS vs. Liberty you’ll notice the TWAS one has more stuff. Some of that is just extra TWAS stuff that doesn’t apply to Liberty, some stuff got renamed/repackaged but should still link just fine. And the 64-bit APIs aren’t available in Liberty (no WOLA support for 64-bit native clients) so those stubs aren’t present in Liberty.
TWAS also shipped some samples you might be using like BBOACPLT. In Liberty we’ve provided the source for those in github (https://github.com/WASdev/sample.wola) and don’t ship pre-built load modules for you. So you’ll need to get the source from github and build it yourself if you’re using one of those samples.
And, finally, Liberty uses a message catalog for messages it uses and your client environment (i.e. CICS) will need to set an NLSPATH environment variable to point to where the file lives (it ships as part of the Liberty runtime). If you don’t set this up, we’ll complain about it and improvise some message text to get you by until you fix it. There’s documentation about this (of course!) as part of setting up WOLA in CICS with Liberty.