In this chapter:
The specification outline for the COBOL business logic component for the sample application is a simple one—to provide a program to perform create, read, update, delete, and browse operations on the customer account file.
The design phase for the component specifies in detail:
The interfaces to the component
Any errors the component may encounter and report
Usage constraints, such as the need to call the read operation before calling the update operation
It is important to note before starting to design and develop the component that the simple and incomplete specification above could be implemented in many ways, altering the balance of responsibilities and affecting the ease of development and debugging of the total application. In the real world, the final specification only evolves after several meetings involving the architect and the component developers, and a number of redesigns. As they work through the sample to get it right first time, consultation with the users of the application is critical to ensure the correct design decisions. During the design stage, you should include the following steps:
The first step is to ensure that you understand what your architect has said that the component must do. It is also essential to talk to the actual users of the application to find out how they do their work and how they view the functions you intend to provide.
You need to check for information or functions that nobody requested but that nevertheless may be required when real work is attempted. Inevitably the users make the same discoveries after you’ve completed your programming effort, and you’ll be left to make changes later when it may prove difficult, rather than now when it is easy. It is very important to repeat this validation step as the design process moves along from a broad outline toward a more and more detailed specifications.
As a result of these deliberations, you decide that your COBOL component will provide interfaces to do the following:
Return the contents of a customer account record, given an account number.
Add a new customer account record, given an account number and customer data.
Modify an existing account record, given an account number and modified data.
Delete an account record, given an account number.
Access customer account records by name; that is, given a last name or part of it, return a list of matching names with corresponding account numbers and addresses.
The component must be able to accept these requests from other components running inside or outside CICS.
A fundamental principle of the design is that users must always read a record before modifying or deleting it.
Once you understand the purpose of the component, you need to consider other aspects of the design. These include the structure of the data, environmental restrictions, and the estimated workload.
Naturally, the detailed design of your business logic is going to be influenced by the established form of the existing customer data. The account file is very much at the center of this application. Its records are shown in Table 4-1.
Table 4-1. Account File Records
Field | Length | Occurs | Total | Type |
|---|---|---|---|---|
Account number (Key) | 5 | 1 | 5 | Read/Write |
Surname (Last name) | 18 | 1 | 18 | Read/Write |
First name | 12 | 1 | 12 | Read/Write |
Middle initial | 1 | 1 | 1 | Read/Write |
Title (Dr., Mr. and so on) | 4 | 1 | 4 | Read/Write |
Telephone number | 10 | 1 | 10 | Read/Write |
Address line | 24 | 3 | 72 | Read/Write |
Other charge name | 32 | 4 | 128 | Read/Write |
Cards issued | 1 | 1 | 1 | Read/Write |
Date issued | 6 | 1 | 6 | Read/Write |
Reason issued | 1 | 1 | 1 | Read/Write |
Card code | 1 | 1 | 1 | Read/Write |
Approver (initials) | 3 | 1 | 3 | Read/Write |
Special codes | 1 | 3 | 3 | Read/Write |
Account status | 2 | 1 | 2 | Read-only |
Charge limit | 8 | 1 | 8 | Read-only |
Payment history: | (36) | 3 | 108 | Future Use |
Balance | 8 | Future Use | ||
Bill date | 6 | Future Use | ||
Bill amount | 8 | Future Use | ||
Date paid | 6 | Future Use | ||
Amount paid | 8 | Future Use |
The fields marked as Read/Write are the ones that are to be maintained by your online program. Those marked Read-only are updated by an existing billing and payment application.
As well as the users’ requirements, certain other requirements are imposed by the environment in which the COBOL component runs. The component must:
Maintain the integrity of the account file using CICS functions. This means that it must be protected from inconsistent or lost data, whether resulting from a failure in the application or CICS or the operating system. It must also be protected from total loss, such as a device error or other catastrophe.
Accept requests from a variety of places.
Run the program in your CICS region.
Use the existing account file, a VSAM key-sequenced data set containing about 50,000 fixed length records of 383 characters each, including the 5-digit account number key.
Using an existing file and its predefined format illustrates one of the dilemmas with which designers are faced. The file as defined has a numeric key of length five so has a maximum of 99,999 records. In order to allow for future expansion, the key should be defined as alphanumeric and with just one letter in the key can grow to 359,964 records. Obviously the simple numeric checks that are in the code would have to be modified to fit whatever scheme is adopted.
Secondly, the use of a fixed length record is not the best choice for the future. This application does not use an explicit postcode or Zip Code, but if it had, the change in length would have a major impact where the designer would have to squeeze the elongated fields in, whereas if the record was defined as variable in length with spare space on the end, the change would be no more than a simple addition.
Now is the time to find out how often the system is expected to cope with the transactions of each type, what sort of response times are expected, what times of the day the application has to be available, and so on. This allows you to design programs that are efficient for the bulk of the work, and it helps you to determine system and operational requirements.
For the sample application, you can assume that your inquiries produced the following information:
There will be about 100 additions, 500 modifications, 50 deletions, and 2,000 inquiries (by account number) per day in the accounting department.
The people in accounting are unable to estimate the number of inquiries that they would make by name, but they like the idea, and therefore may be expected to make some use of this facility.
The update and add activity is broken into separate functions, such as name and address changes, credit limit adjustments, and setting up a new account. Because these discrete activities are performed by different personnel, they could be attempted simultaneously for an individual customer. Another remote possibility is that the same account number could be erroneously assigned to two different new accounts. In order to ensure that conflicting work is not performed at the same time, the system needs to prevent more than one person operating on the same account at the same time. (This is a new requirement, not in the original specification.)
Customer services makes nearly 10,000 inquiries per day against account records, ninety percent of them by name. For most of these, the only items used from the complete account record are the name and address (to verify that it is the right record), and the credit status and limit. A management decision has been taken that payment history will be deferred to release 2.
Head office will only want to query the file, and do this on an occasional basis.
The requests from external users (customers) come in using another component that restricts access to inquiry on their account number only. The volume of these requests is unknown, but it is anticipated that this could become popular with customers, so scalability of the application is essential.
In assessing estimates of transaction frequency, you need to account for a fact of life: if you make it much easier to do something, such as an inquiry, users will almost certainly do it more often than they used to! Indeed, the eventual transaction rates experienced with online systems are almost always higher than can be predicted from the current workload—often a reliable indication of their success.
Having identified the purpose of the component, and other aspects of the design, you can now go on to design the processing programs that you’ll need. So, let’s continue now with some application design considerations. This implies that some element of scalability needs to be considered at the design stage.