CICS Mainframe Solutions: A new Way of Connecting and/or Integrating with CICS

The History of CICS in IBM

CICS was introduced in 1968 as a program offering to support BTAM terminals. Featuring assembler macros that supported a limited number of functions, the program was not expected to last more than a few years.

In 1974, CICS/VS 1.0 was brought into play. It introduced management functions and support for DOS/VS, OS/VS1, and OS/VS2 (the latter both used VSAM as a file storage access method). At a macro level only, CICS/VS 1.0 was HLL supported through pre-processor standards.

1986 saw IBM also announce CICS support for the record-orientated file services defined by Distributed Data Management Architecture (DDM). Throughout the 1980s and 90s, CICS continued to run on successive versions of its mainframe operating system - from MVS in 1987 and ESA in 1989 through to VSE in 1995 and OS/390 in 1996, eventually transitioning to z/OS in 2001.

Today, CICS delivers significant capabilities to improve the developer experience, including frameworks, build tools, and various APIs. The latest z/OS iteration provides support for Java 11, Jakarta Enterprise Edition 9.1, and Eclipse MicroProfile 5 and features improved security and compliance management with support for TLS 1.3.

Through the iterations of z/OS, CICS remains the main z/OS transaction processing middleware.

OpenLegacy: Delivering Standard, Secure, Fast, Modern, Cloud-Native Services from Your Mainframe in Minutes

With OpenLegacy, you can generate new digital solutions from your legacy IBM mainframe CICS system automatically, easily, and quickly. This is especially important in a world where companies are grappling with modernization, migration, and transformation.

By connecting legacy systems directly to the modern world with standard microservices-based APIs, OpenLegacy bypasses complex ESB and SOA layers.

Easily and Safely Open Your CICS System to the Digital Innovation Team

Open your system up to a world of possibilities for partners, customers, and stakeholders. With OpenLegacy, you can leverage your existing IBM CICS investment and accelerate virtually any type of innovation.

We automate the process and create complete integrations in days or weeks, versus the months it takes for other solutions. The user picks exactly what to expose, how, and to what, and the rest of the process is automated.

Forget the ways you used to connect with CICS. OpenLegacy’s platform parses the core assets and its adapter simplifies what needs to be done. Then, its platform automatically generates interfaces that connect to the CICS adapter.

All you have to install on your CICS system is our adapter, which is a simple CICS program. The OpenLegacy adapter doesn’t require any additional resources or facades. Generate your digital assets as cloud-native microservice-based APIs or nodeJS functions.

How the CICS Adapter Works

The overall process flow is:

1. A request comes through the API gateway
2. The request is routed to the OpenLegacy API
3. The request is formatted and passed as an HTTPS payload to the CICS Adapter
4. The CICS Adapter calls a user program

Prerequisite

CICS Transaction server V4.1 and above with TCPIP enabled on the CICS SIT.

FAQs About CICS Mainframe

How do I run a COBOL-CICS program?

COBOL programs cannot recognize CICS commands, as these are coded within EXEC CICS and END–EXEC scope. To run a CICS-COBOL program, you must first pass this to the CICS Translator.

The translator will convert all the CICS commands to COBOL call statements, and this modified source can then be handed to the COBOL compiler. An integrated CICS translator is required to use the latest features of this.

For DB2 commands, the sequence of preparing load modules looks like this: DB2 Pre-compiler, CICS Translator, COBOL Compiler, and Link Editor.

In the first instance, you should work with precompilation. If the translation is completed as the first task, CICS Translation will try to recognize DB2 statements and issue diagnostic messages.

So, if you handle precompilation initially, all DB2 statements are converted into COBOL call statements in the first phase, lessening the translation time.

What are some examples of CICS transactions?

CICS provides services to enterprises to alleviate their security concerns and handle transactionality—or the exchange of data between new and existing online applications. A CICS transaction is typically interactive and is a set of operations that performs tasks together.

Used across communications, hospitality, banking, airlines, and Fortune 500 companies, CICS specializes in reliably processing large quantities of real-time, online transactions and transaction management. It can support thousands of these per second, which is why it’s commonplace in enterprise computing.

Some typical examples of CICS transactions include:

• Updating staff information on an employee program.
• A consumer settling an invoice from a supplier.
• A customer withdrawing cash from an ATM.
• Industrial production control systems.
• Insurance applications.
• Inventory request lists.
• Entering an account debit or credit.

These transactions create large datasets, which require either permanent or temporary storage. It’s imperative to keep them safe as they often contain important (and sometimes sensitive) business and customer information.

It’s possible to write Java application programs that use CICS resources but can interact with other programming languages too. This makes it so programmers can facilitate transactions in dozens of areas and for innumerable purposes.