Back to CNS CICS Home Page
Back to CNS Home Page
Back to UF Home Page
Without naming conventions, it would be practically impossible to manage the CICS environment, identify the owner of applications, or avoid conflicts in the names of the various objects which make up CICS applications. Not only are CICS regions shared by various applications and development groups, but the source code, copy code, and load modules which make up the production CICS environment are also kept in a common repository. For these reasons, it is imperative that all applications which run in CICS at CNS must conform to a set of naming rules as described on this page. There are two primary codes which are used in the derivation of most names. They are the development group code and the application code. These codes must be assigned by the CICS systems group to insure uniqueness within the CICSplex.
Development Group Code
Each CICS development group is assigned a unique two-character development group code which will be used in identifying objects belonging them. For example, all CICS programs belonging to a particular group will have names that begin with their development group code.
Application Code
Application codes are used to associate groups of transactions and are always used as the first two characters of associated transaction identifiers. Development groups may choose to identify all of the transactions they write using a single application code or they may choose to have application codes for each discrete "system" they write. In the latter case, when choosing a new application code for a system, you must first contact the CICS systems group to find out if the preferred code is available (not already reserved by someone else). Application codes must be unique within the CICSplex; therefore, two different development groups may not reserve the same application code.
NOTE: Over the years, many development groups have named things using development group code in places where the documented conventions call for application code. For this reason, it is recommended that development groups reserve the same two characters as both a development group code and an application code. This will help to avoid naming conflicts among different groups.
Transaction Names
The name given to a transaction is called a Transaction Identifier (TRANSID). It should be four characters in length and consist of the application code as its first two characters. The development group may choose the last two characters of the TRANSID to suit their own purposes. For example, if an office is in the habit of having different application codes for different systems, they may wish to design the TRANSIDs using the application code followed by digits (ie: AC00, AC01, AC02 for one system and AD00, AD01, AD02 for a different system). Others have tried to make an acronym out of the initial TRANSID, altering the last character for subordinate TRANSIDs. Whatever scheme is used, the first two characters of a TRANSID must be a valid application code that is reserved for the group writing the programs.
Program Names
All program names should be 8 characters in length with the first two characters consisting of the development group code which identifies the authoring department. The third and fourth characters of the name should be the application code. The last four characters of the name may be chosen by the developers; however, it is highly recommended that the third, fourth, fifth, and sixth characters be equivalent to the transaction identifier. Most people use digits for the seventh and eighth characters (ie: 00 if it is the initial program invoked by the transaction). If a program is associated with a particular transaction, but is invoked via LINK or XCTL and never directly as the initial program in a transaction, it would generally be named the same as the initial program for that transaction except that the last two characters would be different (ie: 01, 02, 03...).
For example, suppose development group DG has a system application code of AC consisting of two TRANSIDs. One transaction only has a single program associated with it. The other transaction has two supbrograms which are LINKed to during the life of the transaction. TRANSIDs of ACX1 and ACX2 respectively have been chosen. The program names should then be something like the following:
BMS Mapset Names
Names for BMS mapsets should be seven characters in length and begin with the development group code (as with program names). If a mapset is associated with a single application program, the name should be the same as the first six characters of the associated program, thus making it easy to figure out which maps go with which programs. The seventh character may be chosen by the development group. We suggest using an S (for map Set) if it is the only mapset associated with the transaction. If the program/transaction has multiple mapsets, using A, B, C, ... as the seventh character of the mapset names would be a good scheme to use.
For example, suppose transaction ACX2 (as shown in the above section) uses three mapsets. A good choice of names for those mapsets would be DGACX2A, DGACX2B, and DGACX2C. If transaction ACX1 uses only a single mapset, the name for its mapset might be DGACX1S.
A mapset can contain one or more maps. There is no naming convention imposed on the individual map names within a mapset, since only the mapset name is defined to CICS. The mapset name is also the load module name of the mapset.
DSECTs and Copy Code
Since all DSECTs and other copy code referenced by CICS application programs must be sent to CNS along with the application source before installation into the production system, it is necessary to impose naming standards on DSECTs and copy code members as well. The DSECTs which correspond to BMS mapsets can be named the same as the mapset, or the name could be derived by appending some character to the mapset name. Other copy code members should have names in which the first two characters consist of the development group code belonging to the owner of the application. . As with most names, beginning the names of the copy members with a the owner's development group code will insure the uniqueness necessary to keep one person's code from overlaying someone else's.
File Names
The name for all files defined in the CICS FCT should be six characters in length, except in the case of VSAM alternate index paths. VSAM alternate index paths will have a seventh character appended to the name (as described futher down). The preferred method for naming files is to use the application code as the first two characters of the file; however, some groups have chosen to use their development group code instead. Groups who choose the latter method must first reserve the two character application code which is the same as their development group code, in order to avoid conflicts with other applications. The first two characters of the file name MUST be a reserved application code belonging to the file's owner.
The file names for VSAM alternate index paths should be created by appending a "P" to the end of the six character file name of the base cluster. If additional paths exist for the same base cluster, create their names by appending Q, R, S, T, ... etc to the file name of the base cluster. Note that CICS reads via the "path"; therefore, the actual AIX need not be defined to CICS.
Examples of file names:
DB2 Objects
Like CICS names, the names for DB2 objects utilize the leading two-character development group code as assigned by the CICS systems group to ensure uniqueness. DB2 objects that come under this requirement are:
DBRM and Package names reflect program names and therefore use the full naming convention as described earlier. Database and Collection names are registered with the DB2 systems group and, along with Plan names, simply need to begin with the two-character development group code and be unique.
Temporary Storage Queues
Temporary storage queue names should be eight characters in length and begin with a valid application code. It is also a good practice to include the terminal identifier (from EIBTRMID) in the queue name. The recommended scheme would be to use the TRANSID (or the application code and 2 other characters) followed by the terminal identifier to create the queue name. Besides trying to insure uniqueness, having the terminal identifier in the name will aid in the coding of routines to clean up temporary storage queues when exiting a system or logging off of CICS. CNS provides a facility whereby an application developer can code a routine to search for and delete any temporary storage queues associated with a terminal and have it invoked at terminal session termination time. Contact the CNS CICS Systems Group for information on the use of this facility.
Transient Data Queues
Transient Data destination names are four characters in length and should begin with a valid application code.This applies to both intrapartition and extrapartition queue names.
Abend Codes
ABEND codes which are coded into applications should be four characters in length and begin with the application code of the program which issues the ABEND. One exception to this rule is that IBM has reserved to themselves all ABEND codes that begin with the letter "A". A list of user-generated ABEND codes should be maintained by the development group to insure uniqueness.
Back to CNS CICS Home Page
Back to CNS Home Page
Back to UF Home Page
Last updated: April 17, 2006 by Barry Brooks.