Back to CNS CICS Home Page
Back to CNS Home Page
Back to UF Home Page
CNS maintains a very tightly controlled production CICS environment due to the shared use of CICS regions by different departments and development groups. This requires coordination between the CICS development groups and the CICS systems staff at CNS during the production installation phase, because only members of the CNS CICS systems staff can move applications into the production environment. The processes which have been developed to accomplish this task have proven over the years to be one of the major reasons CNS has been able to provide such a reliable CICS environment and near 100% availability to the end users, therefore justifying the extra effort required on the part of the application developers and the CNS staff.
The steps required to accomplish a production installation depend on the situation. There are three cases which can occur:
Regardless of the type of installation, a memo to the CICS systems staff must be created. This memo is the key element in making the installation go smoothly, since most of the tasks which must be performed by the CNS staff have been automated, and this automation is dependent upon a correct memo.
Routine Modifications to Existing Applications
When installing routine changes to existing applications, the memo only needs to contain information about the updated resources (programs, mapsets, DSECTs, copy code, etc). This type of installation usually has a short turnaround, normally taking two to four working days. The first step involves reviewing the memo, running jobs to pick up the source and copy code, and assembling or compiling the relevent programs and maps. Once the programs and maps have been compiled and linked into an intermediate load library belonging to CNS, the application programmers are requested to do a fairly thorough retesting of all the programs being installed. This is intended to insure that the load modules which will actually be copied into the production system still work as they did prior to being compiled by CNS personnel using the source that was sent. Linking the programs into a restricted CNS library also insures that no further code changes will be made to the application before it is moved to the production system. After final testing is complete, the CICS systems programmer will review the statistics generated to verify compliance with performance standards and to insure that none of the programs being installed suffered ABENDs during testing. Barring any problems, the programs will then be copied into the production load libraries for availability at the next reload of the production CICS region. As a rule, applications are only copied into production libraries on Monday through Thursday nights, so that there will be appropriate CNS and Development Group staff on site if any problems occur when the application is first used in the production system. Exceptions to this rule can be requested, if necessary.
Emergency Changes to Existing Applications
Emergency installations normally involve only one (or a very few) programs which are needed due to a critical application which is failing or keeping an office from being able to function. For example, if the telephone registration system is failing and students are unable to register for classes when they are scheduled, this is an emergency. However, if a routine application change or enhancement is going to fail to meet a desired deadline for whatever reason, this would not be considered an emergency.
When processing an emergency installation, the memo along with its relevent source and copy code must still be sent to CNS. However, the retesting phase will likely be very quick, the checking of statistics dispensed with, and the modules copied into production as soon as feasibly possible. If no problems are encountered with the memo, an emergency installation usually takes less than an hour from the time the memo is received.
Since emergency installations require a NEWCOPY request for the program in the running system, this type of installation is only allowed in situations that are actual emergencies. The reasoning behind this policy is that changes in the length of a storage area, commarea, or map DSECT can lead to storage violations or failure of in-flight pseudo-conversational transactions. Since most of our regions are reloaded each morning, changes to applications are normally installed on an overnight basis. Differences of opinion as to what constitutes an emergency may need to be resolved by the CNS CICS Coordinator, who has been known to operate under the motto: a lack of planning on your part does not constitute an emergency on my part.
Installing Newly Developed Applications
New applications require a little longer to process for installation into production. Resources must be defined in the CICS tables, JCL may require modification, dynamic allocation tables must be updated, etc. In addition, CNS requires the developer to do a demonstration of the application for the CICS systems staff before the application will be approved for installation into the production system. During this demonstration the application programmer shows how the application works and that it performs its intended task. The systems programmer will then try to "break" the application by feeding it unexpected data or doing other things that a typical end user might happen to do. Other than the items mentioned, the same steps which are required to install a routine change to an application apply to a new installation as well.
CA-InterTest Monitoring
CA-InterTest will be used to monitor any new or changed program after it is installed into production. This is done to protect the CICS region from storage violations or other errors which may not have been caught during testing. This monitoring will continue until one of the following occurs:
Back to CNS CICS Home Page
Back to CNS Home Page
Back to UF Home Page
Last updated: April 17, 2006 by Barry Brooks.