| Command CICS | |
| Developer: | Ken Dakin APT Ltd, UK |
| Released: | 1993 |
| Latest Release Version: | n/a |
| Operating System: | MVS, MVS/XA, MVS/ESA, DOS/VSE |
| Platform: | IBM/370, IBM ES/9000 family, z/OS & compatibles |
| Genre: | Emulator |
| License: | Proprietary software |
| Website: | n/a |
Command CICS or Command-CICS is a software product that allows organizations to migrate from "Macro level" CICS to "Command level" CICS without any re-programming so that companies could migrate to later versions of CICS that did not support macro level application programs.[1] The later versions of CICS offered many advantages over previous versions yet tens of thousands of application programs were effectively locked out of the new version unless they were prepared to operate two completely different versions of CICS on the same Operating Systems, creating both operational and maintenance problems. Two different, simultaneous, CICS Licenses were also required.
When CICS was first released by IBM in the late 1960s, it used IBM Assembler macros to generate the API system calls to the CICS teleprocessing monitor kernel. This was also true even if programs were written in COBOL or PL/1. Ken Dakin an independent programmer and CEO of APT Ltd. in the U.K., realized that by creating a middleware product, the problem could be solved for almost all situations. Ken Dakin approached IBM to market his product but received no interest at the time, despite the fact that tens of thousands of their clients application programs would need to be converted or rewritten for the new versions of CICS, costing many millions of dollars.
Command-CICS intercepted macro level applications via a Link-edited (static) "stub" positioned ahead of the Load module (MVS) or Phase (DOS/VSE). On gaining control from the CICS Program Control Program (PCP), a "pseudo macro level" environment was established consisting of a pointer to a (unique) pseudo "Common System Area" (CSA), a pointer to a Transaction Control Area plus Transaction Work Area (TCA+TWA) and a pseudo Terminal Control Terminal Entry (TCTTE) and other artifacts of a macro level environment. Before passing control directly to the original program entry point, Command-CICS set up the actual general purpose registers, R13 and R12 to point to the pseudo control blocks.The CSA was the principal control block holding pointers to the CICS kernel programs (File Control Program, Storage Control Program etc.) in a real macro level CICS environment.The Command-CICS CSA had alternative pointers to Command-CICS entry points instead. It was possible to use CEDF to debug the application program calls when Command-CICS was used.
The application program proceeded to execute normal machine code instructions right up to its first macro level API call, thus adding zero overhead to the program until that point. As soon as the API call left the application program, Command-CICS code would gain control and replace the original linkage with its own, equivalent, Command-level call.In original earlier command level CICS versions (that supported both Macro and Command level programs), the CICS "Exec Interface Program" (DFHEIP) converted the Command level call to an actual macro level call. This would add a very small additional overhead only during CICS calls. Later versions of CICS, however, executed the CICS API directly, imposing no additional "backward compatibility" overhead.
Command-CICS was initially sold by APT Ltd in the U.K. and APT International in mainland Europe and the rest of the world. At the present time CommandCICS is being offered by Advanced Software Products Group, Inc. of Naples, Florida, United States
CICS/COMET for z/OS - a similar product from UNICOM Systems Inc.[2] Adds some overhead (because of the requirement to dynamically add a stub).