The scenarios in this IBM Redbooks publication use a general insurance application available with IBM GENAPP SupportPac CB12, which can be found on the following website:

The General Insurance Application GENAPP is an IBM Customer Information Control System (CICS) Transaction Server (CICS TS) Common Business Oriented Language (COBOL) application that simulates transactions made by an insurance company to create and manage customer and insurance policy data. It provides sample data and an IBM 3270 interface for creating and inquiring on customers and insurance policy information.

This chapter introduces the components of the application and its topology. To install and set up the application, see Appendix A, “Setup and environment” on page 207.

This chapter contains the following topics:

GENAPP can be installed into a stand-alone CICS TS region System Management Single Server (SMSS) that is not managed using CICSPlex SM. However, the concepts of applications and platforms discussed in this IBM Redbooks publication require the region to be managed by IBM CICSPlex System Manager (CICSPlex SM). Therefore, all steps in the scenarios are applied to a single region, but it is still a part of a CICSPlex, and is referred to as a single managed region.

In addition, the scenarios separate the GENAPP application into a CICS TS topology consisting of three different types of CICS TS regions:

Chapter 3, “Creating a platform” on page 25 shows how to create a development platform, where all three region types are provided by a single managed region, and a test platform, where each region type has its own CICS TS region, connected using multiregion operation (MRO) or Internet Protocol interconnectivity (IPIC). One might imagine a production platform taking this a step further, and having multiple regions for each region type, with requests dynamically routed between the CICS TS regions.

Figure 2-1 shows the infrastructure of the example used in this IBM Redbooks publication, where the single managed region is used for development, the simple CICS TS topology for test, and the full CICSPlex SM topology in production.

To install GENAPP to a single managed region and a CICS TS topology, see Appendix A, “Setup and environment” on page 207.

If you follow the instructions described in Appendix A, “Setup and environment” on page 207, you will have defined some CICS TS system groups to logically group regions of the same type together in the CICSPlex, as shown in Figure 2-2:

Chapter 3, “Creating a platform” on page 25, takes you through the process of adding more CICS TS system groups to enable a single managed region to be used as a development platform with three different region types, as shown in Figure 2-1 on page 16.

This section describes the basic architecture of GENAPP as it has been used for this IBM Redbooks publication.

GENAPP can be divided into two different application parts:

The scenarios in this book use the customer application part of GENAPP.

Figure 2-3 shows the architecture of this part of the application.

The following prefixes are used:

LGSTSQ is a utility program used by most of the other programs. Figure 2-4 shows a part of a visualization from CICS Interdependency Analyzer (IBM CICS IA®) that collects information about the customer application part of GENAPP. The LGSTSQ program does not show up, because IA only collects programs that ran at run time. LGSTSQ is only called in case of
an error.

Figure 2-5 shows GENAPP deployed across a test platform consisting of three different region types (where each region type consists of a single CICS TS region), as described in Chapter 3, “Creating a platform” on page 25. This strategy separates the different layers into unique address spaces:

As outlined in Figure 2-6, the application design means that it can easily be separated into presentation, business, and data access logic.

The GENAPP artifacts is distributed among those layers in the following ways:

Figure 2-7 shows the topology in a CICSPlex SM context.

This section provides information about some limitations in the current design of the GENAPP application, and how these can be addressed using CICS TS cloud capabilities.

Strict naming conventions enable you to derive the functions of the programs, transactions, and other resources used in GENAPP. But eight characters (or even four, in the case of transactions) do not allow for much flexibility. For example, it would be much more meaningful to identify resources as part of the GeneralInsuranceCustomer application in SMF data, in addition to knowing that they ran under the SSC1 CICS TS transaction.

Chapter 4, “Creating an application” on page 51 addresses the concept of applications.

The same applies to the underlying CICS TS infrastructure, for example, it would be more meaningful to deploy part of the application onto the ApplicationServices regions rather than the CICSAAOR CPSM system group.

Chapter 3, “Creating a platform” on page 25 addresses the concept of platforms.

From a CICS TS perspective, GENAPP currently consists of a load library and some CICS TS resources (programs, transactions, files, IBM DB2 connection, and entries). Although these CICS TS resources are organized in groups and lists, it is not possible to manage them as a single entity after installation.

A connection between resources can only be concluded manually from the carefully designed naming conventions (programs starting with LGIC belong to the customer application). This makes it a challenge to perform some tasks, such as removing the application from CICS TS.

Chapter 6, “Packaging an application for multiversion deployment” on page 127 describes how to package resources and code as an entity.

CICS TS resource names have historically had to be unique within a CICS TS region. This makes it impossible to run two versions of GENAPP on the same CICS TS region if they have the same named CICS TS programs and transactions. This in turn makes it difficult to update the application without affecting its availability to users. Sometimes, if a change is to a single CICS TS program, NEWCOPY can be used to update just that module, but when changes affect more than one resource, this approach can lead to inconsistent results.

Chapter 6, “Packaging an application for multiversion deployment” on page 127 describes how to package application resources, such that multiple versions of the application can be deployed into the same CICS TS regions.

Chapter 9, “Application lifecycle management” on page 193 provides information about the value in being able to deploy multiple versions of the same application.

Currently, there is no way to make the availability of a CICS TS program dependent on a CICS TS resource, such as a file or DB2 connection. Chapter 4, “Creating an application” on page 51 describes how to declare application dependencies.

As discussed in section 2.2.2, “GENAPP in a CICS TS topology” on page 19, it is a manual process to distribute the definitions among the different regions. This topology uses one single CSD that requires that different lists be maintained to separate resources dedicated to specific types of regions. This is addressed by the introduction of application bindings in Chapter 4, “Creating an application” on page 51.

The GENAPP application makes DB2 calls, and accesses a CICS TS Virtual Storage Access Method (VSAM) file. In addition, requests into GENAPP are from a user, who expects a response within a reasonable period of time. A sysprog might want to protect the CICS TS regions from changes to GENAPP that result in it making an excessive number of DB2 or FILE access calls, or using too much processor or elapsed time. Chapter 5, “Applying a policy” on page 97, demonstrates how this can be achieved using threshold policies.