A business application should incorporate the key design elements of components, transactions, and error handling. This section provides some more background to show how CICS supports the application designer to structure an application so that it meets the business requirements described in Chapter 1, and incorporates the key design elements. CICS provides the following facilities:
An environment for executing presentation logic and business logic components
Calls between components
Efficient control of concurrently running application programs serving many online users
Provision of ACID properties through management of the units of work (see the following section)
Shared error handling
System management
It’s useful at this point to look at CICS transactions, and CICS programs and linking, in more detail. We’ll also consider how CICS deals with critical activities such as error handling and security.
In a CICS application, a transaction is the processing initiated by a request, usually from an end user. A transaction starts, executes, and ends. A single business transaction (such as the enrollment of a new customer) may involve several CICS transactions.
Tip
As well as referring to a single event, transaction can also refer to the class of similar events. Thus, we speak of adding Mary Smith to the payroll file with a (single) add transaction, but we also speak of the add transaction, meaning the class of additions to that particular file.
A CICS transaction may contain one or more Units of Work (UOW) where a UOW begins with the first action to alter a protected resource and ends with either an explicit or implicit syncpoint. To summarize, a business transaction involves one or more CICS transactions that, in turn, can involve one or more units of work.
When processing transactions, CICS accumulates performance statistics and monitors the resources used. This provides the information that enables user departments in your organization to be charged accordingly. It also allows you to find out which parts of CICS are being heavily or lightly used. This helps your systems managers to tune the system to improve its performance.
A program is the smallest replaceable unit of an application. Programs are compiled, linked or bound, and turned into a single executable file which is then deployed. They can be written in many languages and run in many different environments. A component of a business application typically consists of multiple programs.
CICS provides a variety of ways for programs using CICS to invoke and be invoked by other programs running inside or outside CICS, for example on web servers or end-user workstations. Program calls can be:
- Synchronous
Control is not returned to the calling program until the call is complete.
- Asynchronous
The calling program continues executing while the call is performed. The access method informs the application program after the operation is completed.
There are two main ways in which one program can invoke another program inside CICS. These are discussed in more detail in Commands for Passing Program Control in Chapter 5. For the time being suffice it to say that the CICS API consists of a number of commands that define resources, make calls to other programs and so on. In this book you will meet a wide range of these commands particularly in Part II and Part V. Two of these commands create links from one program to another. Figure 2-2 shows the linking process and relationship of one program to the next. The commands are:
- EXEC CICS LINK
Allows one program to transfer control to another in a synchronous manner and continue execution after the called program has returned. This also occurs by means of native programming language facilities such as a COBOL CALL statement.The LINK Command in Chapter 5 gives more detail.
- EXEC CICS XCTL
Allows for one program to call another in a synchronous manner but unlike LINK will not receive control back when the called program returns. This has no equivalent high-level language facility. It is particularly useful in error processing when an unexpected error is detected that implies that the program which trapped the error cannot continue. The XCTL Command in Chapter 5 gives more details.
In both cases a COMMAREA (for “communication area”) is used to pass parameters and returned values. For more information about COMMAREAs see Saving Data: Using a Scratchpad Facility in Chapter 5.
The LINK and XCTL commands introduce the idea that different programs involved in the processing for a transaction can be executing at different logical levels. A program invoked directly by CICS is considered to be at the highest logical level of the task (level 1). If it then uses the LINK command to link to another program then the linked-to program is considered to be at a lower logical level (level 2). However, if the program detects an unexpected condition it can use XCTL to call an error handler which will be considered by CICS to be executing at the same logical level as the program issuing the XCTL request. Figure 2-2 illustrates this principle.
One CICS program can invoke another asynchronously passing data in the FROM area defined in the EXEC CICS START command. The program for which START has been issued is executed as logical level 1, independent of the level of program that issued the START. The FROM area can be accessed by executing a RETRIEVE command.
Alternatively you can use MQSeries. This is discussed in Working with MQSeries, later in this chapter.
CICS provides a number of ways in which non-CICS programs executing on a variety of hardware and software platforms can call CICS programs. In fact, there are more ways than we are able to describe in this book, but here are a few examples:
A software package known as the CICS Client provides the ECI and EPI facilities:
- ECI (External Call Interface)
Allows the calling program to call a CICS program as though it had been linked to (using the LINK command) by another CICS program. The ECI uses a COMMAREA.
- EPI (External Presentation Interface)
Allows the calling program to call a CICS program as though it had been invoked by a user at a 3270-type device.
The CICS Client is designed to run on end-user workstations and meet the needs of a single user running programs that invoke CICS programs. Our sample application makes use of the CICS Client ECI function call.
For programmers using the ECI or EPI, there are application tools that build some of the program calls automatically. One such tool is VisualAge Interspace. The sample application demonstrates the use of Interspace.
For server applications, a software package known as the CICS Transaction Gateway also supports the ECI and EPI. The CICS Transaction Gateway would be used, for example, by programs running under the control of a web server.
When the calling program is written in Java, there is a pure Java version of the ECI and EPI facilities that access the CICS Transaction Gateway using TCP/IP.
Finally, a CICS program written in Java can be invoked using the Internet Inter-ORB Protocol (IIOP); the sample program uses IIOP.
CICS has a set of resources that are grouped into categories, for example, File Control (FC), Temporary Storage (TS), and so on. These resources can be defined in batch using the DFHCSDUP utility program or online using the Resource Definition Online (RDO) transactions. A historical note: several years ago, many resources were assembled (sic) together into tables; so, for example, File Control resources were aggregated into a File Control Table (FCT).
For asynchronous processing, you can achieve the greatest flexibility by using IBM’s broad range of MQSeries products. Neither the calling program nor the called program needs to know anything at all about where or when the other program executes because MQSeries provides a common set of facilities for sending and receiving messages, takes responsibility for routing messages to the required location, and holds the message until the receiving program wants it. The sample application uses MQSeries to invoke a CICS program.
Error handling facilities are critical in any application. CICS includes several error handling facilities, including:
ABEND
Return codes in commands
DUMP
TRACE
Sending messages to system consoles where operators can respond to the problems
These are described in more detail in Handling Errors in Chapter 5.
Security is a complex subject that requires careful planning before it is implemented; as such, it is not dealt with thoroughly here. As we have already mentioned, many people, with many different roles, interact with business applications and the security, auditability, and accuracy of the application depends on these roles being kept separate and identifiable. Therefore it is natural that security of business applications should be role-based.
Once each user’s role has been understood, security can be implemented on the following basis:
- Authentication
Where the user’s identities are verified, typically using a user ID and password approach
- Authorization
Where an attempted action by a user is checked to see whether it is permitted
CICS works in co-operation with OS/390 security managers (for example, Resource Access Control Facility (RACF), Access Control Facility (CA-ACF2), or TopSecret) to implement this role-based security, with CICS calling the security manager as required to provide the authentication and authorization checks. CICS can request up to three types of authorization check: transaction security, resource security, and command security.
This is the normal sort of security applied to business applications. All CICS applications, whether started by a user at a terminal or a program connecting to CICS, run under a transaction. Consequently, using transaction security to check the authorization of an authenticated user to initiate the transaction is usually sufficient to protect the resources accessed by the transaction.
In some situations, for example where applications require varying levels of access to different users within the same transaction, a more granular approach can be required. In these cases resource security and command security may be applied, as required, to restrict access to specific resources. For example, a transaction that prints any file might use resource-level security to prevent users printing files they are not authorized to see.
Alternatively, command-level security could be used; for example, a transaction that allows the user to select CICS commands to issue could use CICS command security to prevent a user from issuing commands that set the status of a file.
CICS security is applied only to resources owned by CICS. Although a resource security check could be made against a CICS file, this would have no relevance to the underlying security on, for example, its base implementation by a VSAM data set.
CICS resource security and CICS command security are not needed for normal business applications; indeed using them in the wrong situations can give a false sense of security. They do not protect resources from what programmers might do accidentally or deliberately. For example, use of resource security would not prevent the programmer of the payroll update transaction inserting code into the transaction which when executed by others gives the programmer unauthorized pay increases. To guard against this sort of threat, it is necessary to use anonymous peer code reviews.
CICS uses operating system services on behalf of components. However, it doesn’t merely duplicate the services but adds value by providing additional services for running transactions. These services include:
Communication with devices and subsystems.
Recoverable access to shared databases and files, in conjunction with the various database products and data access methods that are available.
Communication with other CICS systems and database systems, both in the same computer and in connected computer systems.
The programming facilities CICS provides are:
- A choice of programming language
You can write your application programs in IBM Assembler, COBOL, PL/I, C, C++, REXX, or Java languages.
- An application programming interface
You need know a little about how CICS works. You request services by issuing CICS commands consistent with the programming language you are using. For example, in COBOL, the EXEC CICS command, or in Java, the JCICS classes.
- An execution diagnostic facility (EDF)
This is used for displaying and changing parameters in command-level application programs, that is, those that use the EXEC CICS command interface interactively.
- A remote edit, compile, and debug capability
This is used in conjunction with the VisualAge compilers for OS/390.