An application development/testing environment is available to the CICS Development Groups to use when developing new applications or making modifications to existing production applications. This test environment is intended to look like a mirror of the production environment; however, there are additional products, tools, and aids available to application developers in the test environment. Once the CICS resources have been defined, programmers can compile new versions of their application programs and make them available in the test regions without any intervention on the part of the CICS systems staff at CNS. Moving CICS applications to production, however, is done by members of the CNS CICS systems staff.

Programming Languages Supported

The preferred progamming language for developing CICS applications at CNS is IBM's Enterprise COBOL. Assembly language as well as C/370 and C++ (via the C++ compiler) are also supported, but their use is discouraged due to the relative ease with which coding errors using these languages can lead to storage overlays and system failures. In addition, C programs tend to create very large load modules, even for programs with very little application logic. The CICS manuals also state that CICS supports PL/1; however, CNS does not accept PL/1 programs for use in CICS at this time. There is also a REXX for CICS product available, but its status with regard to support by the vendor (IBM) is questionable at the present time; therefore we do not currently accept REXX programs for installation into CICS.

Data Types Supported

All CICS File Control and Transient Data services are available. VSAM, BDAM, and BSAM datasets are supported, as well as DB2 databases. VSAM and DB2 are intended to be the file types of choice. VSAM entry-sequenced datasets are the preferred choice for sequential files (audit trails, etc) instead of transient data or journalling.

CICS Sockets feature of MVS TCP/IP

CNS also supports the use of the CICS Sockets Interface feature of TCP/IP for MVS. Documentation regarding the use of this feature is currently being developed and will be placed on the CNS CICS web site when available. For now, contact Steve Ware for information about using the CICS Sockets Interface.

Defining Resources To CICS

The first step to be taken when developing an application for CICS is to identify the resources required and define those resources to CICS, which needs to know certain information about the resources which make up an application (e.g. transactions, programs, mapsets, files, databases, etc). Definitions for these resources can be thought of as being stored in tables. Only the CICS systems staff can define these resources or make changes to the definitions. All CICS resources must have names which conform to a set of naming conventions which were designed to insure that no conflicts will arise between the names of resources belonging to different CICS Development Groups. The normal sequence of events for defining an application and its resources to CICS would go something like the following:

• Determine how many new transactions, programs, and maps are needed to perform the task in question.
• Choose a set of transaction codes, program names, and mapset names (keeping in mind the naming conventions).
• Determine if any new files need to be defined to CICS.
• Choose DDNAMEs and DSNAMEs to be associated with the files (again keeping in mind naming conventions).
• If DB2 will be used, determine what needs to be defined in the DB2 Resource Control Table (RCT).
• Request the necessary changes to RACF profiles for transactions and datasets.
• Prepare a memo to the CICS Systems Group requesting that the appropriate definitions be added to the CICS test regions.
• Send email to the CICS Systems Group notifying them of the memo.
• One of the CICS systems programmers will create the definitions and inform you of their availability.

Making The Program Available To CICS

Sample JCL for translating and compiling CICS programs and mapsets is contained in CICS.USER.SAMPLIB. An index to the contents of CICS.USER.SAMPLIB resides in member $INDEX. Each CICS Development Group should have a load library into which they compile their applications for testing using the CICS test regions.

The production CICS application program load library is also available to the test regions as the last in the list of available program libraries. We recommend that CICS Development Groups delete the programs and maps from their test load libraries after testing is completed and they have been moved to the production CICS environment. That way, should those programs be accessed from the test regions, the production copy will be referenced. This makes it easier to use the test regions to try and duplicate problems which may be encountered in production. If a program exists in both the test and production load libraries, the test version will be referenced.

Monitoring With CA-InterTest During Testing

Whenever testing is being done, CA-InterTest monitoring should be turned on for all programs and/or transactions being tested. When CA-InterTest is monitoring a program or transaction and the transaction suffers an ABEND, a breakpoint screen will be displayed rather than having the transaction end abnormally and create a transaction dump. CA-InterTest monitoring will also protect the CICS region (and others executing in it) from storage violations which may be generated by that program.

There are two very useful options which can be used when placing CA-InterTest monitoring on a program or transaction. MXR is an option which can be used to stop the transaction after a specified number of CICS commands have been executed. This is very useful in keeping a program from getting into a command loop (most commonly a READ loop). MXS is an option which stops the transaction after a specified amount of user storage has been obtained. This can keep an errant program from monopolizing all of the available storage in CICS. It is also useful in trying to determine why a program is using as much storage as it is, by stopping after it obtains what would normally be expected.

To place CA-InterTest on program USERPROG and restrict it to 300 CICS commands and 40K of user storage, for example, use the following command:

CNTL=ON,PROG=USERPROG,MXR=300,MXS=40960

CNS strongly recommends the use of CA-InterTest monitoring, as well as the use of the MXR and MXS options, during all phases of testing.

Evaluating Transaction Resource Usage

Each night a job runs to charge for the use of CICS. As part of the output of this job, datasets are created which contain performance monitoring data about the transactions which executed that day. This data should be used to evaluate the resource consumption of CICS transactions during the testing phase. A sample job is contained in CICS.USER.SAMPLIB(CICSEVAL) which can be used as a template for creating your own job to evaluate the resource consumption traits of the programs being tested and to insure that they conform to the recommended performance guidelines prior to submitting them for installation into the production CICS system. The sample CICSEVAL job can be used or you may write your own report program in the language of your choice. The sample job and the comments contained in it should provide a good guideline for what you should be reporting and where to find the data.

The CICS application performance guidelines were established by the CNS CICS Coordinator to provide for optimum performance of the CICS regions. A single CICS region supports many different applications which must all share the available resources of the region. Poorly written or consumptively designed applications, while they may actually produce the correct output to the screen, can degrade the entire region's performance for everyone else. Almost any CICS application, if well designed, should be able to conform to the suggested guidelines. Applications which greatly exceed these guidelines may be disapproved for installation into the production environment.

Back to CNS CICS Home Page Back to CNS Home Page Back to UF Home Page

Last updated: April 17, 2006 by Barry Brooks.