LANSA Environment System Variable

If you have a Development server and a Production server, it can be very useful to know what server your code is running on. LANSA does not have a built-in way of knowing what type of environment (development, testing or production) you are running in but there is a pretty interesting way to make it so. 

Before we get into that however, we have to understand a bit about the LANSA environment itself.

Environments and Partitions

I consider a single LANSA installation to be an environment. You can have multiple installations on a single machine. In fact at MTM, we had 4 on one iSeries that represented our Dev, Test, Production, and another one we called DBM (for reasons that are way to long to go into right now :D). 

Inside each environment, you have something called partitions. I like to think of these "partitions" as a slice of pie, cake, pizza (whatever you like to slice up in to smaller pieces). Each partition (slice) is part of the whole environment (pie). Each partition is identified by a three character identifier. When you install LANSA creates a SYS partition and it is where all the internal "System" objects live. It can also create a DEM partition where you can install all the demonstration objects. You can create other partitions such as DEV (to hold development objects), TRN (for training objects), PROD etc. 

A partition is one way to separate different applications in an environment. 

Most of the objects that you create to build an application are self contained in a partition, however some, like System Variables, cross all partition boundaries. This means that if you create a system variable in your SYS partition, it will be available in your DEM, DEV and TRN partitions as well. 

This can be problematic in some situations, but very useful in others. One way it can be useful is by developing an "Environment" System Variable.

Variables, Functions and Data Areas

The idea here is pretty simple, we have a data area on each server that stores a value that represents the environment, a Function that reads that value and a Variable that provides access to the function.

Data Area

So we create a simple data area that stores a 5 character string and we can put a value in that data area to be "DEV", "PROD", "TEST" or "LOCAL" etc. In your local development environment (not your development server) you are probably using SQL Server. You can find the LX_DTA table in your Lansa database, mine is in the LX_DTA schema.


You can add your data area in this table by inserting a new record where DTANAM is the name of the data area, DTALIB is the library where the data area lives (does not matter on windows, but does on iSeries), the DTATYPE the type of data (A for alphanumeric, N for numeric) and DTANUM is the numeric data value and DTAALP is the alphanumeric data value.


Here you can see I named this environment "LOCAL". To do this on the iSeries, look at the CRTDTAARA and CHGDTAARA commands.

Now we can move onto the "Function" to that access the data area.


A Function in LANSA is merely a chunk of code that can be invoked. I like to think of them as scripts as they execute top-down, similar to how a batch, bash or powershell script would work. A Function should not be confused with a method, procedure, routine or function (a set of instructions contained in an object).  A Function in LANSA must be contained in a Process. A Process is really nothing more then a container of Functions. I have never seen them used and it is my understanding that it is a leftover artifact of LANSA's early years. Our Function is going to be pretty simple, all its going to do is use the "Built In Function" (Yeah all the "function" stuff is confusing) and push that value into a special variable.


The #SYSVAR$NM is a special variable that gets passed into the function that contains the name of the System Variable that was passed into it. We'll get to the variable next. All we need to do is check that the variable name is the one we are interested in and then call the GET_CHAR_AREA builtin. Notice that we are passing the name of the data area (ENV) and the library in which it lives (LANSACFG). The library is optional, if not supplied it will look for the data area in the running application's Library List. We are setting the #SYSVAR$AV variable to the value that is contained in the data area. 

The #SYSVAR$NM and #SYSVAR$AV are "special" variables passed into the Function. LANSA knows to give us those values because of the *ALP_SYSTEM_VARIABLE parameter.

Now with the function in place we can create the System Variable. 

System Variable

Creating a System Variable is as easy as telling LANSA what the name is, how it gets evaluated (statically or dynamically) and what program or Function to use.


Here I made the Derivation static as it only needs to be read once when it is evaluated. So LANSA will read the value then cache it so it does not have to re-read it. The "Program Type" is Function (as we just created it) and the Program Name is what we named the function.

Technically you don't have to use a System Variable. You can just call the BuiltIn function (BIF) that the Function uses, or call the Function directly. However, I think using the System Variable is much easier and makes the code a bit cleaner.


Finally we can use are new System Variable.


Here all we are doing is outputting the Environment to the #STD_TEXTS (Standard Text Short) field and a simple check for the production environment.


Using a System Variables is a great way to determine what environment your are in. All you need is a Data Area to hold the data, a Function to retrieve it.

Use a System Variable to access it Function or call the Function directly.

Just remember the System Variable cross ALL partition boundaries.



You can follow this conversation by subscribing to the comment feed for this post.

The comments to this entry are closed.