O'Reilly logo

Designing and Programming CICS Applications by Members of the CICS Development Team at IBM Hursley, John Horswill

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Handling Data

Having decided what you want to do, you can now determine what data is required to do it, and how to organize that data.

The Account File

In the sample application, you know that you need access to all the fields that make up records in the existing account file, because this is the data that you intend to maintain and display. You need direct access to these records by account number for several of the required operations (create, read, and so on). Happily, this file exists in a form directly usable by CICS (a VSAM key-sequenced data set (KSDS), with the exact key that you need).

This isn’t pure luck or coincidence. The account number is the natural key for this file, and a VSAM key-sequenced data set is a good choice for a mixture of sequential and direct processing, such as probably occurs now in the batch programs that already use this file. Table 4-3 shows the record format for this file.

Table 4-3. Account File Record Formats

Field

Length

Occurs

Total

Account number (Key)

5

1

5

Surname (Last name)

18

1

18

First Nname

12

1

12

Middle initial

1

1

1

Title (Dr., Mr., and so on)

4

1

4

Telephone number

10

1

10

Address line

24

3

72

Other charge name

32

4

128

Cards issued

1

1

1

Date issued

6

1

6

Reason issued

1

1

1

Card code

1

1

1

Approver (initials)

3

1

3

Special codes

1

3

3

Account status

2

1

2

Charge limit

8

1

8

Payment history:

(36)

3

108

Balance

8

  

Bill date

6

  

Bill amount

8

  

Date paid

6

  

Amount paid

8

  

The Name File

You’ll be accessing the account file records by account number, but you also need to access them by a second key—the customer’s last name. There are many ways of achieving an alternative path into a file. For example, VSAM provides a facility called an alternate index, which can be used in CICS.

CICS supports other data formats including SQL with the IBM DB2 relational database product, and hierarchical data access with the IBM IMS/DB DL/I product. These systems provide powerful cross-indexing facilities, and they have many other features that reduce the coding required in user applications. They support complex data structures, provide increased function and simplify the maintenance of file integrity. If you have data that you need to access by more than just a few different key fields, or if you have data that does not arrange itself into neat units like the account records in this application, you should use a database system. CICS also supports various non-IBM databases as well.

For this component you’ll use a simple technique, frequently used and quite appropriate to an application of this size. You’ll build an alternate index on the customer’s last name. This requires a one-time setup, and it means that every update to the base index (account number) is also accessible by both account number and last name (surname) without any extra intervention by your application.

The Locking File

One of the requests made when discussing the Accounts Department’s needs was that no conflicting work should be allowed at the same time. As considered in Maintaining File Integrity: Using Locking earlier in this chapter, you decided to use a “scratchpad” to implement the requirement of “locking” an account. The question then is how to implement this scratchpad. You have various alternatives, for example, temporary storage, but the easiest is to use a file. Table 4-4 shows the record format for this file.

Table 4-4. Scratchpad File Record Format

Field

Length

Format

Account number (Key)

5

Character

Owner:

12

Character

User

8

Character

Terminal

4

Character

Date

4

Packed decimal

Time

4

Packed decimal

Since the lock needs to be maintained by account, the account number is the field used. The logical owner of the account lock is a combination of the user field and the CICS terminal identifier since neither on its own can be guaranteed to be unique. First, CICS allows the same user to be active at multiple terminals. Second, the terminal identifier may not be relevant if entry to the system is using the CICS Client technology or Distributed Program Link (DPL). With CICS web enablement, the terminal identifier may be randomly generated.

As already discussed, the lock should have a limited lifetime. The current date and time are included when it is created. This can be tested later to see if a user has exceeded the time allowed for a lock to prevent an account from becoming unavailable.

The main drawback to this use of a file is the apparent contradiction of the resource usage guideline regarding performing unnecessary I/O operations. In fact, this can be overcome because CICS has a facility called a data table that allows the programmer to think they are accessing this use of the locking file, but in fact the data is kept in memory and no actual input/output operation takes place—the best of both worlds, simplicity and efficiency.

Recovery Requirements

As discussed already, CICS prevents loss of integrity associated with partly completed transactions. However, you must protect the account file from disasters such as a catastrophic device failure.

In some environments, you can keep an extra copy of an important file, or keep enough information to recreate it (such as backup versions and the input needed to bring it up to date). In a business application environment, this isn’t so easily done. You cannot copy the file after every update. Nor can you afford to lose all the updates since the last time you copied the file. These updates were entered at terminals by many different users, who may not remember what stage they had reached when you last secured the file, who may not have ready access to the input documents any longer, and who will certainly be very cross if they have to re-key a large number of transactions!

CICS provides facilities to address this concern. If you have a file that must be protected, you ask CICS to journal the updates. CICS then keeps a copy of every change made to the file. It logs these changes on an appropriate journal. If you lose a file, you go back to the most recent copy of it and then run a restore program that applies the changes recorded on all the journals created since that copy was made.

In your sample application, the account file is clearly a file that must be protected in this way. By way of contrast, the locking file is implemented as a data table where no I/O takes place, so changes to it are not written to a journal because no actual hardening of the data ever takes place. (In other words, no physical I/O takes place to move the data from volatile to non-volatile storage for this logical file.)

The only way this data would be destroyed is by the failure of the entire system, which would require a restart of all of the activity anyway; in this case, you would want to reconstruct the data as far as possible.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required