In the very early days of CICS the user was required to do a "full system generation", literally assembling and link-editing all the CICS code to produce an executable system. There was no commitment on the part of CICS to provide what later became known as "source level compatibility" or "object level compatibility".
As CICS Development began to produce new versions and releases of the product, questions arose as to the compatibility of an application program, compiled and link-edited under a previous release. The first assurance users sought was that a program recompiled under a new version/release of CICS, should perform the same as the application compiled under the previous version of CICS. This was in reference to source level compatibility.
With the announcement and delivery of CICS/VS 1.3 in 1976, CICS Development made a commitment to object level compatibility. Prior to 1.3, when moving to a new release of CICS, the user may have been required to recompile and relink-edit one or more of his application programs. The new commitment on behalf of CICS was significant to users in that they could now move entire program libraries to run with a new CICS version/release and not have to recompile their programs.
At this same time, CICS/VS 1.3 delivered pregenerated systems, obviating the need for the user to perform a complete CICS system generation in order to get an executable product. All CICS code, including sample programs, were delivered in a pre-generated form such that the product was immediately usable. Service or maintenance to the product might require a given module to be recompiled but this was considered the exceptional case.
But object level compatibility should not be confused with "object code only (OCO)" or "object-oriented programming (OO). These terms became relevant to CICS in the 1990s. With the introduction of the rearchitected CICS/ESA Version 3 product, CICS began to deliver its code to the user in object form only, with no compilation (generation) and no source level documentation. There was considerable user concern about OCO, especially among customers or software vendors who felt they needed access to CICS source code for modification purposes, or to assist in debugging system and/or application problems.
One of the objectives of the rearchitected CICS product (CICS/ESA and its follow-on versions/releases) was that user programming should be performed only with supported application programming interfaces (APIs) or at supported CICS exits. In earlier years, user and/or vendor product modifications to CICS often led to software problems, and considerable IBM resource was spent doing problem diagnosis only to discover it was not a CICS code problem. By going OCO, CICS made it a requirement that user programming be done only at supported programming interfaces. If the user or vendor needed a function or access to certain CICS information, CICS Development evaluated these requirements and provided support in one form or another. A good example was the introduction of the EXEC CICS SET/INQUIRE interface which enable user code to inquire or set key system variables.
So, object level compatibility was introduced in 1976 and object code only was introduced in 1996. In 1998 CICS Transaction Server (TS) 1.3 was announced to include support for C++, an object-oriented (OO) programming language. The subject of OO was not a new one, because if only academically, the concept of OO dates back at least to the late 1960s.
If one is new to OO, depending on how the subject is introduced, it can be overwhelming. So many new terms and rules. Encapsulation, methods, persistence, classes, polymorphism, etc. To keep it simple, let's first talk about "why" OO. Whether you read a book on the subject or go to a class, the first thing you would learn is that the primary, very basic objective of OO is that reusability breeds productivity. If you have done something once, why do it again?
The OO terms aren't that difficult to learn and deal with. An object could be a small program, like a subroutine, or it might be an entire application. When you encapsulate an object (a program), you give it a name and specify some things such as its expected input and what it will deliver as output. The caller of this object need not know where the object is located or how it was written to perform its function.
Locating an object usually involves a proxy of some sort. The calling program invokes the object, as though it were local to its environment, but the proxy will determine if the called object is local or not, do what it has to do to locate the object, pass parameters to it, and when results are returned, pass those to the calling program. In many of today's software the proxy function is performed by a "name server".
In addition to the object having a name and defined input and output, the object may contain within itself multiple "methods". Imagine a program (an object) which deals with customer order entry. That is, the object can do processing for a new order, look up the status of an existing order, check on customer history, etc. Each of these functions within the object would be referred to as methods.
But more to the point, with the introduction of CICS TS 1.3, the product delivered two significant enhancements. First, there was support for C++, very definitely an object-oriented programming language. An secondly, CICS TS 1.3 delivered its intial support for something called the "Open Transaction Environment (OTE). The primary purpose of OTE, at that time, was to enable CICS applications written in Java, to execute in a CICS region.
For both C++ and Java, CICS provides "classes". Instead of coding EXEC CICS requests, the C++ or Java program can invoke an object and pass parameters to it. The invoked class would perform the CICS function and return its result to the calling program
Comparatively, Java has gained greater usage in the CICS community than C++. Popular reasons for the use of object-oriented languages, in addition to the basis premise of reusability breeds productivity, is that fact that the C++ or Java objects (programs) can easily be relocated without impacting calling or called programs (objects). Portability can be very beneficial to the user, placing application logic where it is most appropriate - and if there is a need to relocate that code at a later time, it can be easily done.
It should be mentioned at this point, that another reason for OO becoming popular is that there is an increased number of people now learning OO in colleges and universities, and this represents a large skill pool from which to hire people as the need exists.
If a CICS user begins to adopt Java as a programming language, the next logical step is to begin to conform to Enterprise Java Beans (EJB) so as to get the maximum in application portability. A bean is an object, by the way. A bean might initially be developed for one environment, such as CICS, and later moved to a WebSphere environment (which also supports EJB), or vice versa. An application developed to conform to EJB is platform independent, and the platforms that support EJB each provide a runtime environment (called a container). Thus the application is not aware of how service functions are performed on any given environment but can easily be ported among those platforms which support EJB.
This article has tried to briefly identify the context in which the term "object" might be used in conjunction with CICS. First there was "object level compatibility" obviating the need to recompile programs when moving from one CICS release to another. Then there was "object code only" where CICS no longer distributes its source code and users are obligated to use only supported interfaces. And lastly, the CICS support of "object-oriented" programming languages such as C++ and Java. What's in a name?
Copyright © 2003 - Yelavich Consulting, Sparks, NV
Click here
for other articles regarding the evolution of CICS.