CICS - CICS application development

Desenvolvido por DORNELLES Carlos Alberto - Analista de Sistemas - Brasília DF. -

CICS - CICS application development

CICS has been around for more than 50 years and has built over 25 different versions since it was first developed.
This chapter explores some of the major application enhancements that have occurred over the years and describes the sample application used throughout this paper.

2.1 Application development in CICS

When CICS was first introduced in 1969, programming was done in Assembler language and CICS resources were invoked using macro level coding techniques.
Today CICS uses modern programming interfaces while supporting traditional workloads.

2.1.1 Batch processing versus online transaction processing

To understand why CICS was created and why it has been so popular over the years, we need to understand the change in the programming models that took place in the early 1970s.

With the invention of devices that could interact directly with a user the programming model had to change to support what was back then only moderately faster machines.

Prior to the invention of the “green screen”, which today many people describe as old and outdated there were no screens.
Data was processed in a batch manner.
Whole files were fed into a program sequentially and the results were only fed back once all records were processed.
In fact, sometimes the data was fed in using “punch cards”.

Although batch programming is still used today, the world is very interactive.
We have more storage on our smart phones than we had on our mainframes 20 years ago.
So, in the 1970s when computers became faster and processing needs became more immediate, IBM built CICS as one of the first transaction processors.

The idea was simple. The user is now a person not a machine or file.
Therefore, the interaction will be shorter but access to data is completely random.
Since a user is waiting for a response, the processing time must be extremely fast and, in most cases, sub-second.
A good example of this is in our everyday life when we pay for something using a credit card by swiping or placing it into a machine.
The longer it takes for a response to come back the less customers you can transact with in a period of time.

2.1.2 Programming paradigm

In order to process data in a more immediate fashion and interact with a customer using a 3270 like screen, a new set of programming paradigms needed to be considered.
Consider the following types of transaction:

  • Non-conversational transaction
  • Conversational transaction
  • Pseudo-conversational transaction

As you can see, the word conversation appears in each of the programming styles as it assumes that you are having a conversation.
This is usually a conversation between the system and the end user.
The idea is there is a beginning and an end to these conversations, but what happens in between can be different.

Non-conversational transaction

In the case of a non-conversational transaction there is a start and an end, but they run together so the transaction is complete within one iteration.
You can think of this as an API call where the result is available immediately and there is no need to continue when the result is received.
For example, requesting the balance of your checking account, requires you provide the account number and you receive the balance back.
Any other work you want to perform is not directly tied to this request.

Conversational transaction

Conversational on the other hand, requires you provide several inputs where the path is decided based on the inputs themselves.
This interaction means the program needs to respond to an input with a request for additional input.
All of this will eventually produce a final result, but it will take an uncertain path through the program to get there.
What makes the programming style conversational is that every time a response for input is sent to the user, the system waits for the user to respond.
The program is suspended, and any resources acquired by the program remain locked until the final outcome is achieved.

A great example of this is a menu system.
The first screen will prompt a user with several options, but only when the user responds will the program determine the next processing leg.

Pseudo-conversational transaction

So why the need for the last programming style?
Well just imagine a user enters a transaction that produces a screen and gets a phone call before they respond.
They remain on the phone for an hour.
As the program is suspended holding resources until they respond, this would not allow for many users in a system as the inconsistency alone would be hard to predict.
The last programming style has the benefits of non-conversational programming but allows for the requirements of conversational.

Pseudo-conversational programming has the programmer end the task and therefore the program right after it responds to the user with a prompt for input.
This way the latency associated with user think time, is completely removed from the picture.

How does this affect the underlying program?
The answer is the program must have the ability to be restarted where it left off when the user finally responds.
In order to do this some state information must be kept in the system that allows the program to know where it left off and keep any data required to restart in the middle of a conversation.

This area is known as the COMMAREA or communication area.
Although there are newer methods to keep state information between pseudo-conversations, the COMMAREA is still heavily used not only to hold state data for CICS programs is also used to pass information between different programs.

2.1.3 Basic architecture of a CICS program

With the adoption of the pseudo-conversational programming style, CICS regions were able to host many users running the same or different applications.
However, in the mid-1970s address spaces were still only 16 megabytes, so the biggest limitation to adding more users and programs was space.

One of the solutions was to create separate CICS address spaces, known as regions, that were dedicated to individual services.
Regions that hosted terminals were labelled TORs, the ones that housed applications are known as AORs and data services were moved to FORs or DORs.
At the same time, instead of creating a single program for whole applications, development was broken down into categories (Figure 2-1).

The categories initially created closely matched the region demarcations, but soon the industry adopted a modular programming style to allow for the maximum reuse of common routines.
These developments caused applications to be split into many individual modules run over possibly multiple regions, and the modern CICS application was born.

As a result, CICS programming today is divided into three main categories.

Presentation services layer

The presentation services layer is used for all communication with the end user.
The advantage of using a separate presentation layer is the ability to swap out or add new forms of presentation without affecting the back-end business logic of the application itself.
Just imagine the transition from terminals to tablets to mobile phones for the services we use today.
Each can have different requirements for how data is presented to the display, but only require a change in one category to support the new device.

Most presentation services have all but moved from CICS as other platforms tend to be more suitable for that processing.
HTML pages that contain items such as radio buttons or selection lists can be easily processed at the local client, where CICS is simply used as the delivery mechanism to deliver the pages.

Business logic layer

Business logic is where you perform the work on the customer data and is still primarily processed by application programs in CICS.
Although customers have incorporated new languages such as Java and Node.js into these applications, the core COBOL applications remain as it would take many years to replace them all.

What’s more is that CICS along with z/OS® provides the ability to handle massive workloads with security, integrity and performance unmatched by other platforms.
Customers have attempted to rewrite whole CICS applications on other platforms and rarely have been able to match the reliability, integrity and performance.
Besides, if you take an application as a whole and rewrite it in another language for running on another platform and matched the performance in CICS what would you have in the end?
A big bill and the same thing you started with.

Data services layer

The last layer is the data services layer. Even though many customers have chosen not to separate data access from business logic, the housing and access of data can change.
One minute you are using VSAM files to house your data, the next you have the need to query that data.
With a separate data layer, the storage and retrieval of data is left to a module that can be replaced as requirements change.

Some would even argue that the module in this layer can be used to go to other platforms through web services to retrieve data, whose underlying storage methodology is unknown to the program requesting it.

Either way, over the years this separation of services has allowed CICS applications to be easily and quickly incorporated into newer applications, and in some cases with little or no changes to the underlying programs.

2.1.4 CICS resources

CICS is a resource driven system that requires most resources be defined to the system prior to its use.
Although this is not usually a function of an application programmer, it is important to understand because if it’s missing an application that may rely on that resource will not function correctly.

As you embark on the road of programming in CICS you will quickly learn that there is a partnership between the application developer and the CICS systems programmer.

CICS was designed originally as a table driven system, which means if a resource is required in a CICS region it must first be defined to the resource table for that resource.
If not, the resource will not be available in that CICS environment.

The function of defining resources was relegated to the CICS Systems programmer as he or she designs the environment and chooses where different pieces of an application runs.
He or she is also responsible for setting the attributes of that resource definition, so it best utilizes what that particular environment has to offer.

An example of this is a VSAM file.
The file may live in the same region as the application, or the systems programmer can choose to place the file in a different region.
The systems programmer can manipulate the definitions in CICS to accomplish either and as far as the application is concerned it will function the same.

In terms of attributes, the systems programmer may decide this is a critical file and set it up to be automatically backed out if a failure during application processing occurs.

Coordination between the applications developer and the systems programmer is usually required to set all attributes correctly.
However, if the programmer is simply looking to extend an existing application where the resources are already defined and require no additional CICS resources, then this can be accomplished by the application developer without any interaction with the systems programmer.

2.2 CICS sample application

In this publication, we will be using a sample application to describe some features within CICS.
Specifically we will utilize a payroll system example (Figure 2-2).

A payroll application is a good example of a service that has been hosted in CICS for years, by many large organizations.
The sample program we are using has been concentrated to some simple functions so that the complexity of the source code is reduced.

The transaction id used is PAYR. When entered on a blank CICS screen the initial program invoked is PAYPGM.
This program contains the presentation logic for the application and will determine the state.
For example, the first time through the program there will be no state data, so the program determines it is time to send the initial screen, which in CICS is known as a MAP.
Maps can be stored in something known as a MAPSET which can contain more than one map for the application. The MAP used in our application is called STUDMAP.

After the first time through, the program must query the state data to determine if it is in middle of a function such as update or if the request is simply a display of a record.

Input to this program is supplied via the 3270 screen.
It accepts a one byte department number and a five byte employee number.
Entering these values and pressing the enter key or a function key drives the re-running of the PAYPGM program.
This time to read the values entered and determine the function to run.

The only field validation done by this program is for the department and employee field.
They must be physically entered as they are required fields and they must also be numeric.
All other field validation for things such as date have been removed to simplify the logic.

Once PAYPGM has validated these fields, it will determine the function the user is requesting.
The program will build these into a communication area called the COMMAREA and will pass to PAYBUS for processing.

PAYBUS is the business logic program for this application.
It will determine the function requested, such as ADD or DELETE and invoke the necessary section of the code to process the request.
Although this may seem relatively simplistic and non-conversational, it is actually a true pseudo-conversational example due to the interaction with the 3270 screen.

Imagine you want to ADD a new employee.
You enter a department and employee number, but the rest of the screen appears to be locked.
On entry to PAYPGM the program determines this is an ADD request and calls PAYBUS to verify that this person does not already exist.
If that is the case, then it will return that information to PAYPGM which will respond to the user by sending the screen, unlocking the fields to allow the ADD to proceed.

It is only when the user enters all the data and requests the ADD a second time that is when the record is added.
Therefore, ADD is a two step process that requires a conversation.
The code used is pseudo-conversational and is a good example of how that processing takes place.

Finally, for simplicity the data is stored on a VSAM KSDS (Key Sequenced Data Set) file, so the data portion was not separated into a separate program.

2.3 CICS modernization

As the world moved from 3270 green screens to browsers, IBM provided several modernization techniques to allow CICS applications to thrive in the new world.

One of the early application modernizations in CICS was called the 3270 web bridge.
This allowed a programmer to get a HTML representation of their MAP, produced when the MAP was assembled.
This, along with a program supplied by CICS called DFHWBTTA, allowed the application to run from a browser with no changes to any of the application.
The screens were primitive, but CICS supplied utilities to try and make them look more like web screens (Figure 2-3).

As customers embarked on the path of separating presentation logic from business logic, IBM created features such as CICS Web Support and Web services, which allowed the programmer to bypass the presentation layer and simply pass data directly to the business logic.

These features, support passing the data as name value pairs for HTML pages and as XML for consumption by a client web service.
With these new features CICS allows a programmer to turn the backend business logic into an XML based service.

Today, there is even support for the creation of RESTful services using JSON with various free and for purchase utilities allowing CICS applications to be supported by mobile applications or any other application within the enterprise.

Other modernizations include the ability of CICS applications to be clients of external web services.
I was introduced to example of this recently, where a CICS application that used to pay an external service for address scrubbing, is now calling a free service on the web to provide the same functionality.

2.4 CICS built-in transactions

In order to assist with application development, CICS provides several transactions or built in functions, known as the CICS supplied transactions, that provide the ability to build and test CICS application programs.

CICS supplies over thirty transactions that provide both system and application programmers the ability to monitor, control and build applications in CICS.
Rather than try and cover them all, we have highlighted just a few that are most used by CICS applications programmers while developing applications.
Each of these provide applications programmers the ability to test, debug and modify data associated with an application.

These include:

  • CEDF/CEDX - Execution diagnostic facility transactions. Provides interactive debugging
  • CADP/DTCN - Provides access to the CICS Debug Tool, a Source Level Debugger supplied with LE370
  • CECI/CECS - Command interpreter transaction. Allow EXEC CICS statements without coding a program
  • CEBR - Allows a programmer to browse through CICS Temporary Storage or Transient Data Queues

The two most used transactions are CECI and CEDF.

2.4.1 CICS Execute Command Interpreter (CECI)

CECI, which stands for the “CICS Execute Command Interpreter”, gives you the ability to test a CICS command before coding it in an application program.
In addition, it runs the command in most cases so the changes made will be permanent in the system.

For example, if you delete a record from a file using CECI it will permanently delete the record from the file.
CECS works the same way as CECI however, it will not execute the command.
It will simply syntax check it so that a programmer knows exactly what attributes are required to properly code the command in a program.

2.4.2 CICS Execution Diagnostic Facility (CEDF)

Another one of the built-in transactions is the CICS execution diagnostic facility (CEDF).
CICS provides two such transactions that you can use for testing and following the flow of application programs, without having to supply special program testing procedures.
It too has a sister transaction called CEDX, which allows the testing of nonterminal based applications as it can be entered with an application transaction as input to test on a 3270 screen even thought the underlying transition being captured is not terminal based.

To try, simply type CEDF on a blank screen and the message returned will let you know CEDF is active.
Clear the screen and type in the application transaction which in our case is PAYR.
The following screen will be displayed.

Note that CEDX works the same way, however, it is entered as CEDX, a space, then user transaction. CEDX will capture that transaction on the users’ current screen should anyone run it in the environment run it whether on a terminal or not.

CEDF allows you to intercept your application programs at the program’s initiation, at each CICS command, and at the program termination.
CEDF helps you to isolate and focus on problems in your application programs.

This document was created or updated on December 17, 2020.

© Copyright IBM Corp.