3.2 Lifecycle of an Application

Application deployment isn't over after the application has been successfully installed on the target system.  In fact this is just the beginning.

Your applications may receive minor or major updates, new versions of LANSA may be installed or new versions of the application may be required to be installed alongside existing applications. These and other issues determine how your software needs to be managed and evolved though the life time of the application.

The following scenario details one method for managing the development of your software:

In this scenario three different development environments are required to support development of the application at different versions.

Development of the application commences with Version 1.0.0 on a Version 13 LANSA system V13PGMLIB in partition BLD.  After releasing and distributing Version 1.0.0, minor changes to the application are released at different dates as patches 1.0.0.1 and 1.0.0.2.  These patches are to be applied to the existing software product.  It may be required for users to install both patches, or the patches maybe installable independent of each other.

When more significant enhancements to the application are planned and completed these are released as Version 1.0.1.  Following on from here any minor changes to Version 1.0.1 are released as patches starting with Patch 1.0.1.1

At this point, a major set of enhancements are planned for the application.  These will be released as Version 2.0.0.  It is envisaged that it may not be necessary / advantageous / affordable for all users of the application to upgrade to this Version 2.0.0 immediately so this will be released as a standalone application with on-going support and modifications provided for Version 1.0.1.

To facilitate this all the application objects are exported from partition BLD to partition BL2 on the same LANSA System.  Development and released of Version 1.0.1 of the product will continue in partition BLD while the branch of the application in partition BL2 can be modified without impacting Version 1.0.1.

This shared LANSA system with separate partitions means:

• The Application definition is shared between the two partitions.  Care must be taken to build the Version and Patches while logged into the correct partition.

• Any files used by the application, assuming they are recompiled, will have a different library embedded in the OAM based on the different partition Default File Library of the partition where the OAM is generated.  This will require consideration when installing and upgrading the application as the application source code will need to incorporate appropriate use of the DEFINE_OVERRIDE_FILE built-in function to direct the file to the appropriate library. For more information, refer to DEFINE_OVERRIDE_FILE in the Technical Reference Guide.

• Both versions of the Application will be based on the same Version of LANSA. This includes EPCs.

So, this raises the issue, what do you do if you need to continue support for Version 1.0.1 and Version 2.0.0 but there is a new release of LANSA available and you want to be able to take advantage of the features in the software to enhance your application.

Now you will need to install a second LANSA system ABCPGMLIB at release level V13SP1.  Export all the application objects from the most up-to-date version of your application, in this case partition BL2, and import into the new partition ABC on LANSA system ABCPGMLIB.  To finalize the setup of the new LANSA system you will also need to copy the Application definition from X_APPS into the new location and optionally the associated Version and Patch definition (for historic reference only) to a shared location.  This can be done using the Backup or Restore Applications in the Tools menu. Copying the Application is important as the GUIDs from the original Application are required if you want to be able to upgrade Version 2.0.0 to Version 3.0.0.