Chapter 3
How to design a CICS program
Objectives 1. Explain Explain why why event-dri event-driven ven program program desig design n is appropri appropriate ate for for pseudopseudoconversational CICS programs. 2. Given Given specific specificati ations ons for a CICS CICS program program,, create create a list list of each user user input event that can trigger execution of the program, identify the various contexts the program must manage, and create a summary of the program’s response to each event. 3. Working Working from from an event/ event/resp response onse chart chart such such as the the one in in figure figure 3-4, 3-4, create a program structure chart that indicates the major event processing modules module s and the major functional modules mod ules subordinate to each event-processing module.
The program overview for the customer maintenance program Program
CUSTMNT1: Customer maintenance
Trans-id
MNT1
Overview
Maintain customer information in the customer master file by allowing the user to enter new customers, change existing customers, or delete existing customers.
Input/output specifications
CUSTMAS MNTMAP1 MNTMAP2
Processing specifications
1. Control is transferred to this program via XCTL from the menu program INVMENU with no communication area. The user can also start the program by entering the trans-id MNT1. In either case, the program should respond by displaying the key map.
Customer master file Customer maintenance key map Customer maintenance data map
The program overview for the customer maintenance program (continued) Processing specifications
2. On the key map, the user enters a customer number and selects a processing action. If the user selects Add, the customer number entered must not exist in the file. For Change or Delete, the customer number must exist in the file. If a valid combination isn’t entered, an error message should be displayed. 3. If the user enters a valid combination of action and customer number, the program displays the data map. For an add operation, the user can then enter the customer information. For a change operation, the user can change any of the existing information. For a delete operation, all fields should be set to protected so the user can’t enter changes. To complete any of these operations, the user must press the Enter key. 4. If the user presses PF3 from either map, return to the menu program INVMENU by issuing an XCTL command. If the user presses PF12 from the key map, return to the menu program. However, if the user presses PF12 from the data map, redisplay the key map without completing the current operation.
The copy member for the customer master record (CUSTMAS) 01 *
*
CUSTOMER-MASTER-RECORD. 05 05 05 05 05 05 05
CM-CUSTOMER-NUMBER CM-FIRST-NAME CM-LAST-NAME CM-ADDRESS CM-CITY CM-STATE CM-ZIP-CODE
PIC PIC PIC PIC PIC PIC PIC
X(6). X(20). X(30). X(30). X(20). X(2). X(10).
The screen layout for the key map
The screen layout for the data map
CICS, C3
© 2001, Mike Murach & Associates, Inc.
Slide 7
How to create an event/response chart
Identify the events that can cause the program to be started, and identify in general terms how the program should respond to each of those events. Be sure to include a response to the user action that causes the program to be started for the first time. A program typically responds to this event by displaying the first map and then ending. If the final step in a response is to return control to CICS, you can omit this step from the event/response chart and it will be assumed. Identify the context of each event (if any), then add the contexts to the event/response chart and expand the response processing. If the response to an event causes a change in the context, indicate the new context in the event/response chart.
A beginning event/response chart for the customer maintenance program Event
Response
Start the program
Display the key map.
PF3
Transfer control to the menu program.
PF12
If the key map is displayed transfer control to the menu program. If the data map is displayed cancel the operation and display the key map.
Enter
If the key map is displayed prepare the data map according to the requested action and display it. If the data map is displayed add, change, or delete the customer as appropriate.
Clear
Redisplay the current map without any data.
PA1, PA2, or PA3
Ignore the key.
Any other key
Display an appropriate error message.
Event contexts for the customer maintenance program Context
Explanation
Get key
The key map is displayed, awaiting input of a valid combination of action code and customer number.
Add customer
The data map is displayed in response to a request to add a customer.
Change customer The data map is displayed in response to a request to change a customer. Delete customer
The data map is displayed in response to a request to delete a customer.
The final event/response chart for the customer maintenance program Event
Context
Response
New context
Start the program
n/a
Display the key map.
Get key
PF3
All
Transfer control to the menu program.
n/a
PF12
Get key
Transfer control to the menu program.
n/a
Add customer Change customer Delete customer
Cancel the operation and display the key map.
Get key
Get key
Edit input data. If valid display data map
Enter
Add customer, Change customer, or Delete customer
else display an error message.
Get key
The final event/response chart for the customer maintenance program (continued) Event
Context
Response
Enter
Add customer
Add the customer record. If not duplicate record display the key map with a completion message else display the key map with an error message.
Change customer
Change the customer record. If record found display the key map with a completion message else display the key map with an error message.
New context
Get key Get key
Get key Get key
The final event/response chart for the customer maintenance program (continued) Event
Context
Response
New context
Enter
Delete customer
Delete the customer record. If record found display the key map with a completion message else display the key map with an error message.
Get key
Get key
Redisplay the key map.
Unchanged
Add, Change, or Delete customer
Redisplay the data map with unprotected data erased.
Unchanged
PA1, PA2, or PA3
All
Ignore the key.
Unchanged
Any other key
All
Display an appropriate error message.
Unchanged
Clear
Get key
A general procedure for designing the first two levels of a structure chart 1. Draw the top-level module and give it a name that represents the entire program. 2. Decide what event processing should be implemented as separate modules, and draw a box subordinate to the top-level module for each one.
How to determine what modules should make up the second level of a structure chart
If the program’s response to an event includes receiving data from the terminal, processing it, and sending data back to the terminal, create a separate module for the event. If the program’s response to an event doesn’t include receiving data from the terminal, consider creating a separate module only if the response requires more than a few COBOL statements to implement. If the COBOL statements for implementing the top-level module require more than a page or two, consider creating additional second-level modules to simplify the coding in the top-level module.
The first two levels of the structure chart for the customer maintenance program Process customer maintenance
Process key map
Process add customer
Process change customer
Process delete customer
An alternative design for the customer maintenance program Process customer maintenance
Process key map
Process data map
Process add customer
Process change customer
Process delete customer
A general procedure for designing one leg of a structure chart 1. Draw one subordinate module for each function that the control module at the top of the leg needs to do. 2. Use the same thought process for the next level of modules. If any of them require more than one function, draw one subordinate module for each function. 3. If necessary, continue this process until each of the lowest-level modules consists of just one function.
Guidelines for designing the legs of a structure chart
Each module should represent one and only one function. The function of a called module must be logically contained in the function of its calling module. The code in each module should be manageable. Use a generalized send module for each map. Each module will contain one or more SEND MAP commands with various options. Include a separate module for each file I/O statement so the statements are easy to locate and modify.
The process-key-map leg of the customer maintenance program Process key map
Receive key map
Edit key data
Read customer record
Send data map
Send key map
The final structure chart for the customer maintenance 0000 program Process customer maintenance
1000
2000
Process key map
1100 Receive key map
1200 Edit key data
Process add customer
1400 Send data map
3000 Process change customer
1500
Read customer for update
1300
2100
Read customer record
Receive data map
Receive data map
Process delete customer
3100
Send key map
2100
4000
2300 Write customer record
1500 Send key map
3100 Read customer for update
1400 Send data map
1500 Send key map
4100 Delete customer record
1500 Send key map
3200 Rewrite customer record
1500 Send key map
How to identify common modules
To identify a common module (a module that appears more than once in a structure chart), shade its upper right corner. If a common module has subordinate modules, you need to include them only once on the chart.
How to identify linked or called programs
To identify a linked program (a program that’s executed using the LINK command), add a module to the structure chart. Include a stripe at the top of the module that gives the program name. Use the same technique to identify a called program (a program that’s executed using the COBOL Call statement).
How to number the modules in a structure chart
Use 000 or 0000 for the top-level module. Number the modules in the second level from left to right leaving large enough gaps for subordinate modules. After the first two levels, number the modules down each leg in appropriate increments. When you code the COBOL paragraph for each module later on, the paragraph name will be the module number followed by the module name.
How to create a structure listing
A structure listing is an outline that uses indentation to show the levels of the modules. The letter C in parentheses can be used to identify common modules. When you’re designing a program, use the outline feature of any modern word processor to prepare a structure listing. This feature makes it easy to analyze the structure and reorganize the listing. When a program is finished, you can use a structure listing program to generate a structure listing from the COBOL code for the finished program.
A structure listing for the customer maintenance program 0000-PROCESS-CUSTOMER-MAINT 1000-PROCESS-KEY-MAP 1100-RECEIVE-KEY-MAP 1200-EDIT-KEY-MAP 1300-READ-CUSTOMER-RECORD 1400-SEND-DATA-MAP (C) 1500-SEND-KEY-MAP (C) 2000-PROCESS-ADD-CUSTOMER 2100-RECEIVE-DATA-MAP (C) 2300-WRITE-CUSTOMER-RECORD 1500-SEND-KEY-MAP (C) 3000-PROCESS-CHANGE-CUSTOMER 2100-RECEIVE-DATA-MAP (C) 3100-READ-CUSTOMER-FOR-UPDATE (C) 3200-REWRITE-CUSTOMER-RECORD 1500-SEND-KEY-MAP (C) 4000-PROCESS-DELETE-CUSTOMER 3100-READ-CUSTOMER-FOR-UPDATE (C) 4100-DELETE-CUSTOMER-RECORD 1500-SEND-KEY-MAP (C)
