Moving to RDMLX

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.

Posted on March 7, 2011, in Lansa and tagged . Bookmark the permalink. Comments Off on Moving to RDMLX.

Comments are closed.