The present invention relates generally to the field of application hosting, and more particularly to application hosting where there are multiple versions of the applications.
One conventional piece of software used in application hosting is called Customer Information Control System (CICS). CICS is a transaction server that runs primarily on certain conventional mainframe computer systems. CICS is middleware designed to support rapid, high-volume online transaction processing. A CICS transaction is a unit of processing initiated by a single request that may affect one or more objects. This processing may be interactive (screen-oriented), or may occur as background transactions. CICS provides services that extend and/or replace functions of an operating system and can be more efficient and simpler than using the generalized services in the operating system, especially in connection with communication with diverse terminal devices.
Applications developed for CICS have been written in a variety of programming languages and use CICS-supplied language extensions to: (i) interact with resources such as files, database connections and terminals, or (ii) to invoke functions such as web services. CICS is currently used by clients such as financial institutions, large commercial enterprises, smaller organizations and government entities. Customers have a huge investment in home-grown or highly customized packaged applications written in traditional languages such as COBOL (common business oriented language), PL/I (programming language one), C, and ASM (assembly language). These applications, when hosted on a middleware platform like CICS, include many, possibly thousands, of individual uniquely named program modules. Duplicate program module names are not permitted which means it is impossible to: (i) host more than one version of an application (where there are common module names which are common to both versions of the application); and/or (ii) host two different applications that have inadvertently chosen the same module names.
In some middleware transaction servers (for example, pre-5.2 versions of CICS), there is only a single directory for module names. In these conventional transaction servers, when a program issued an “EXEC CICS LINK” command (that is, a module call), the target module name was looked up and called if found. If not found in an initial look-up (that is, a look-up in an in-memory cache), then the conventional transaction server will search a “global search path” by searching the following locations in the following order: (i) LPA (link pack area); (ii) dynamic libraries; and (iii) RPL (relocatable program library). These conventional transaction servers then load the first matching module.
The role of dynamic libraries in an application server, implemented by a conventional transaction server, will now be discussed. The primary purpose of a dynamic library, in currently conventional CICS systems, is to allow new datasets to be added to those defined by a data set that is named DFHRPL in the CICS context. However, DFHRPL cannot be modified without restarting CICS. Additionally, if the datasets are defined with a higher ranking than those in DFHRPL programs already loaded can be replaced by newer versions if the SET PROGRAM NEWCOPY or PHASEIN command is used. This mechanism does not allow two or more versions of a program to be explicitly used simultaneously.