Legacy CICS State Management

Legacy CICS "State Management"

In a previous chapter, ^[1] I discussed the pseudo-conversational CICS model. There, I suggested that the techniques used (e.g., DFHCOMMAREA usage in the Linkage Section) to support this model were analogous to common practices used with the disconnected, stateless HTTP/ASP.NET model. With these thoughts in mind, let's look further into the details of this mainframe CICS analogy.

When you coded your legacy mainframe CICS applications, you were faced with the choice to use either the MAPONLY or DATAONLY option in your SEND BMS Screen MAP program logic. Using these CICS options, you were basically controlling what data was to be transferred between client (your 3270 screen) and server (the mainframe HOST). The concept of needing to manage "content" separately from " user data" is an important concept to resurface.

Tip  

You should find yourself being reminded of this type of content and data management when I discuss state and cache management throughout this chapter.

Another important concept that you can be reminded of from your mainframe CICS experience is queues, as in temporary storage (TS) queues and transient data (TD) queues. As you know, TS queues and TD queues were used as solutions for saving and passing data between program executions (and even between programs/ tasks ).

Although the CICS DFHCOMMAREA and the Linkage Section served this purpose as well, the CICS queues were preferred if you were working with a large quantity of data. Choosing either of the CICS queues over the CICS DFHCOMMAREA meant that you would use less of your "main memory" and more hard disk space. For application performance and resource utilization, this design choice was generally welcomed.

Note  

In comparing the two general types of CICS queues, you will recall that the TS queue had a simpler, dynamic implementation and supported sequential and random access. On the other hand, if you wanted to use the CICS Automatic Transaction Initiation (ATI) feature or you wanted to process or print your queue data, the TD queue was a better choice. However, the TD queue did not support random access.

To complete your trip down mainframe CICS memory lane (as it pertains to managing the preservation of data), you should be reminded of two additional legacy CICS techniques. The Common Work Area (CWA) and the Terminal Control Table User Area (TCTUA) advanced CICS features were known to be useful as a means for storing and passing data between CICS transactions.

Note  

In the ASP.NET arena, the practice of preserving visual content and data between program executions is referred to as state and cache management. In the CICS mainframe arena, the practice of preserving visual content and data between program executions is referred to as, well, preserving visual content and data between program executions.

There is a simple point to take away from these CICS mainframe analogies . When it came to designing your CICS program for saving and passing data (man-aging the preservation of data) between program executions, you had choices. The quantity of data being saved and how you wanted to work with the data made one design choice or the other more or less appropriate. Pulling this general point from this mainframe analogy will be helpful as you turn now to dive into ASP.NET state and cache management.

The Key/Value Pairs in the Collections Namespace

The more you program in .NET, the more you will come across classes and methods that either consume or return a key/value pair structure. In those cases, if you take a moment to dig down a bit, you will usually find that the key/value pair is tied back to a specific class (structure or interface) from the System.Collections namespace.

Therefore, having a general understanding of the Collection classes, structures, and interfaces will move you several retraining steps forward. Effectively, this would work like reusable knowledge: Learn once (with the System.Collections namespace) and reuse the knowledge repeatedly throughout .NET.

By the way, a special bonus awaits you when you learn about the System.Collections.Stack class. The Pop and Push methods of the Stack class will remind you of the READQ and WRITEQ commands you used with the CICS TD queue. For example, once you Pop an item from the Stack class, it's no longer available. Doesn't this remind you of the "read once" behavior associ-ated with the CICS (intrapartition) TD queue?

 

^[1] See the section "Application Level: Comparing CICS with ASP.NET" in Chapter 13.