Thanks to the new LANSA installer framework, the LANSA Composer install process for both the server and the client is straight-forward. (Update: added link) You answer a couple of questions, press enter, and wait. If that were the end, though, this article would be very boring and much shorter.
Where to Install Composer
There is one crucial question to answer before enter is pressed. Where will we install Composer on the server? Or more to the point, where SHOULD we install Composer on the server?
Keep in mind as we continue that a LANSA environment is the entire LANSA install, not a LANSA partition. We usually refer to the environment by the name of its’ program library: typically DC@PGMLIB or DCXPGMLIB.
There are two options. Install it into an existing LANSA environment or install it into a new LANSA environment. We wondered if there was a material difference between the two or if there was an official best practice so we asked around within the LANSA organization. Unfortunately, we received different answers from a few different people. Since we have LANSA Services in-house on a project that depends on LANSA Integrator, we asked them for a specific recommendation as a project requirement.
Best Practice Recommendations
Here are the recommendations that come directly from LANSA.
- Install Composer into its’ own LANSA instance.
- If your system calls LANSA Integrator directly, your system should have a dedicated Integrator environment in addition to the Composer Integrator environment.
LANSA says the reason for both of these recommendations is the ability to upgrade your LANSA environment and your LANSA Composer environment at different times.
Let’s dissect these recommendations in order to better understand the implications.
Dual Integrator Installs
In order to understand this recommendation, just watch the dominoes fall.
- LANSA issues Integrator EPCs separately from all other EPCs, including LANSA for iSeries.
- On occasion, Integrator EPCs contain updated JSM BIFs.
- When the JSM BIFs are updated, both the Java code in the Integrator instance and the BIF code in all LANSA environments that use that Integrator instance must be upgraded at the same.
- If the LANSA system were to use Composer’s Integrator instance then the EPC would have to be applied to Integrator, to the Composer environment, and to the primary LANSA environment all at the same time.
- LANSA does not want to require their customers to upgrade their primary LANSA environment and their LANSA Composer environment at the same time.
- So they recommend two Integrator installs. One is used by the primary LANSA environment so LANSA + LANSA’s Integrator are upgraded together. One is used by Composer so Composer + Composer’s Integrator are upgraded together.
Dual LANSA Installs
I have changed my stance on this and agree with LANSA that it is a good idea to decouple the primary LANSA environment and LANSA Composer in order to allow their upgrades to happen at different times. Since Composer and non-Composer EPCs ship separately, upgrading them separately is both attractive and easier.
It also mitigates the risk that comes from the off chance that a LANSA for iSeries EPC was not thoroughly tested in a LANSA Composer environment or that a LANSA Composer EPC was not thoroughly tested in a LANSA for iSeries environment.
Do you see that elephant in the room? His name is ‘How Do I Call Composer Processing Sequences From My Existing Lansa System In This Scenario’. It’s a good thing he’s an elephant or his name badge would never fit.
We know that calling between LANSA partitions, let alone environments, is frowned upon. The possibility exists that the LANSA environments are at different EPC levels. LANSA took these criteria and more into account when they created a new product designed specifically for this task. Many of you have probably used it already. It is the LANSA Composer Request Server.
LANSA Composer Request Server
Thanks to the LANSA Composer Request Server, there is a way to execute calls between the Composer environment and your primary LANSA environment. It appears to be a good solution but there are a couple of significant caveats.
In order to call from Composer to a different LANSA environment, the destination environment should be multilingual. There is a way to work around the monolingual problem but it leads to a maintenance nightmare. So if the destination environment is not multilingual, the call through the Request Server will fail. How did we figure this out? Yep, our primary LANSA environment is monolingual. The infamous National Language (NAT) is what our system speaks.
This is the big one. The only method for calling Composer from a different LANSA environment is to use the COMPOSER_RUN BIF. This BIF is not yet available and will be released as part of V12SP1. Once the EPC is available, you will have to upgrade your primary LANSA environment to V12SP1. There will not be an EPC for v11SP5. Just to make sure we are all on the same page, it is not possible to follow LANSA’s recommendation right now and your environment must be at V12 in order to apply the EPC. Ours is not.
Maybe you are in our situation of being caught by both of these caveats. If so, ‘Best’ practices have become ‘You Have GOT To Be Kidding Me!’ practices. Unfortunately for now there is little to be done. It is what it is. LANSA as an organization is just now coming to a consensus on this recommendation.
Because we make good use of LANSA Support, our decision is to follow LANSA recommendations even when it is difficult and frustrating. For the foreseeable future that means we can neither call Composer from our primary system nor call functions in our primary system from Composer.
Get in Touch
If you are dealing with LANSA issues and would like to discuss them, get in touch.