Defining CICS application requirements

One of the steps of application design is to decide how the business processes, or tasks can be best grouped into a set of programs that will efficiently perform the required processing.

Some of the considerations in analyzing processing requirements are:

• When the task must be performed
  • Will it be scheduled unpredictably (for example on terminal demand) or periodically (for example, weekly)?
• How the program that performs the task is executed
  • Will it be executed online, where response time is more important, or by batch job submission, where a slower response time is acceptable?
• The consistency of the processing components
  • Does this action the program is to perform involve more than one type of program logic? For example, does it involve mostly retrievals, and only one or two updates? If so, you should consider separating the updates into a separate program.
  • Does this action involve several large groups of data? If it does, it might be more efficient to separate the programs by the data they access.
• Any special requirements about the data or processing

  Security

  Should access to the program be restricted?

  Recovery

  Are there special recovery considerations in the program's processing?

  Integrity

  Do other departments use the same data?

Answers to questions like these can help you decide on the number of application programs that the processing will require, and on the types of programs that perform the processing most efficiently. Although rules dealing with how many programs can most efficiently do the required processing do not exist, here are some suggestions:

• As you look at each programming task, examine the data and processing that each task involves. If a task requires different types of processing and has different time limitations (for example, weekly as opposed to monthly), that task may be more efficiently performed by several programs.
• As you define each program, it is a good idea for maintenance and recovery reasons to keep programs as simple as possible. The simpler a program is—the less it does—the easier it is to maintain, and to restart after a program or system failure. The same is true with data availability—the less data that is accessed, the more likely the data is to be available; the more limited the data accessed, the more likely the data is to be available.

  Similarly, if the data that the application requires is physically in one place, it might be more efficient to have one program do more of the processing than usual. These are considerations that depend on the processing and the data of each application.

• Documenting each of the user tasks is helpful during the design process, and in the future when others will work with your application. Be sure you are aware of the standards in this area. The kind of information that is typically kept is when the task is to be executed, a functional description, and requirements for maintenance, security, and recovery.

  For example, for the Current Roster process described previously, you might record the information shown in the following form. How frequently the program is run is determined by the number of classes (20) for which the Ed Center will print current rosters each week.

                          USER TASK DESCRIPTION

NAME: Current Roster                                                    
ENVIRONMENT: Batch                   FREQUENCY: 20 per week             

INVOKING EVENT OR DOCUMENT: Time period (one week)                      
 
REQUIRED RESPONSE TIME: 24 hours                                        

FUNCTION DESCRIPTION: Print weekly, a current student roster, in student
 number sequence for each class offered at the Education Center.        

MAINTENANCE: Included in Education DB maintenance.                      

SECURITY: None.                                                         

RECOVERY: After a failure, the ability to start printing a particular   
class roster starting from a particular sequential student number.