Blog Archives

Part of a series devoted to RDMLX-enabling your LANSA environments.

If you have triggers that test the value of trigger return code before you default the value of trigger return code, those triggers will crash when the I/O comes from an RDMLX function.

You Really Use Triggers?

Today, general wisdom suggests putting your business logic into a callable module so that it can be accessed from a 5250 app, a web app, and a Windows/VL app without modification. Those who created the architecture for our system back in the day believed the correct place for most business logic was in triggers. Because of that decision, triggers are now business critical in our organization.

The Switch That Does Nothing Does Something

Before considering the move to an RDMLX-enabled environment, we performed due diligence to see how well our system works. Most things work so far. However, this decision to RDMLX-enable our environments, that some people have told us “is a no-brainer because it doesn’t change anything,” is not quite so straight-forward in our situation. There ARE things that break.

But You’ve Gotta

LANSA mandates that every trigger default the trigger return code. Every time we’ve asked about this, the answer has been consistent: the examples and templates from LANSA clearly show the correct way to code the trigger return code in templates.

Andersen Software Factory

Our architecture dates back to when the Andersen Software Factory from Andersen Consulting ruled the roost. Raise your hand if you remember the Andersen Software Factory! That PC-based code generator sat on top of LANSA. Yeah, good times. Fortunately, the Software Factory was destined to sleep with the fishes once the Y2K boundary was crossed. In preparation for that glorious event, I was asked to replace it with LANSA templates. The transition went smoothly and a few of the team helped to fully deprecated those PCs… by drilling holes into the hard drives. I wish I had pictures.

That history is important because the Software Factory had a specific way of coding everything. A proper structure is a good thing and the Software Factory had some good stuff. Take conversation control, for example. There were a few places, though, where the structure was broken. Like not defaulting the value of trigger return code in triggers.

RDMLX Blows (Up)

When we began testing our ERP system in an RDMLX environment, we converted some of our RDML functions into RDMLX. We didn’t get one transaction completed because our triggers crashed. It took a couple of hours to figure out the root cause.

The IOM and the OAM are distinct objects that do not communicate with each other and that behave differently. On the iSeries, an IOM is an RPG program which is executed any time an RDML function performs I/O over a file. On the iSeries, an OAM is a C program which is executed any time an RDMLX function performs I/O over a file.  (For you LANSA hackers looking for holes in the logic, I am intentionally ignoring *DBOPTIMISE in this example.)

Now let’s test. We create a trigger function that does not default trigger return code but that does test the value of trigger return code. The trigger is called for every insert, update, and delete. We have an RDML function that maintains the file by updating one particular record that already exists. We have an RDMLX function that contains code identical to the RDML function. Identical.

• When you maintain the file from the RDML function, the file’s IOM is used. The IOM defaults the trigger return code to ‘OK’ and passes it to the trigger. When the trigger tests the value of the trigger return code, the test succeeds since the value is ‘OK’.
• When you maintain the file from the RDMLX function, the file’s OAM is used. The OAM defaults the trigger return code to hex X’00′ and passes it to the trigger. When the trigger tests the value of the trigger return code, the function aborts because hex X’00′ is not an alphanumeric value and #TRIG_RETC is an alphanumeric field.

We’ve run this test dozens of times and it appears that although the IOM and the OAM both default the value of trigger return code, the default value in each is different. In the case of the OAM, it appears to be, in our opinion, an invalid value for the field.

To recap, our ERP system seemed to work fine in an RDMLX environment until we introduced RDMLX functions. As soon as they performed I/O, triggers were executed which immediately aborted. Because we have everything under commitment control, this caused the entire transaction to roll back. WAMs would have had the same result.

Resolution

It appears that our only option is to default trigger return code to OK in every trigger function and to update the templates to do that for all new triggers. Unfortunately for us, this task is not only huge, it is risky. We are in the process of automating this process of updating trigger functions in order to reduce that risk.

If you recently began using the LANSA platform, enabling RDMLX was a no-brainer.  In fact, you might not have even know there was an option.  Your LANSA environments likely supported RDMLX right out of the gate.  If this is your situation, feel free to ignore the rest of this article.  It will only serve to invoke a sense of gratitude for the minefield you avoided by showing up to the LANSA party when you did.

For the rest, you probably have LANSA systems on the iSeries that have been around for many years and you are unsure how they will be affected by enabling RDMLX.  Before we go any further, there are two similar but vastly different meanings behind the term “enabling RDMLX” and it is important to understand what we are talking about.

• RDMLX-enabling a partition.  This prepares one partition in your LANSA instance to accept RDMLX objects.  When you hear someone talk about “throwing the switch,” they are referring to making the partition RDMLX-enabled.
• RDMLX-enabling a field, a file, or a function.  Once your partition is RDMLX-enabled, you have the option of using RDMLX objects in addition to RDML objects.  You can create them new or you can convert existing.

The benefits of RDMLX are attractive: WAM development, more field types, fewer 3GL limitations, and others.  However, the decision to move to RDMLX can weigh heavy on the decision maker.  I have seen this look in the eyes of many managers.  They hear an incessant whisper from that trusted area of their brain warning them to be safe, to understand what they are about to do, and to mitigate the risk.  There are some in the LANSA community that will tell you with passion to just “Throw the switch. It does NOTHING!”  Let me warn you to do your research before making that leap.  Throwing the RDMLX switch causes some things stop working.  There are additional gotchas and if you want a seamless transition, you will need to take the time to understand what those gotchas are.

My goal is to install caution, not fear.  Moving to RDMLX is straight-forward as long as you have a road map.  In an effort to help, I am writing a series of articles on Moving to RDMLX.  I hope you find them useful.

If I had to pick the most important truth to ponder, it would be that Visual LANSA is now your only method for creating and maintaining LANSA objects.  You might consider spending a few minutes to more fully understand how this will impact your team.  If you already use Visual LANSA extensively, the impact will be small.  If some on your team primarily use the green screen interface, their transition will most likely take longer.

Here are some future topics:

• What is the impact of only maintaining LANSA objects from within Visual LANSA?
• All triggers must set the value of #TRIG_RETC since the default value coming from the OAM is different than what comes from the IOM.
• Functions that create functions (and fields and files) will no longer work on the iSeries.
• LANSA fails to create an OAM for certain files even though the IOM is created without issue.
• Debugging RDMLX objects versus RDML objects.