CICS, it's been around for more than 50 years and has been over 25 different versions since it was first developed. Let's explore some of the major application enhancements that have occurred over the years. To understand why CICS was created and why it's been so popular over the years. We need to understand the change in the programming modules that took place in the early 70s. With the invention of devices that can interact directly with the user, the programming module had to change to support what was back then only moderately faster machines. Prior to the invention of the green screen, which today many people describe as old and outdated. It just simply weren't screens, data was process in a batch manner, profiles were fed into the program sequentially and the results were only fed back once all records were processed. In fact, some time the data was fed in using punch cards. Although batch programming is still used today, the world is very interactive. We have more storage on our smartphones than we had on our mainframes 20 years ago. In the 1970s, when computers became faster and processing needs became more media. IBM built CICS as one of the transaction processes, the idea was simple. The user is now a person, not a machine or a file, therefore the interaction will be shorter but access to data is completely random. Since the user is waiting for a response, the processing time must the extremely fast, and in most cases sub-second. A good example of this in our everyday life, is when we pay for something using a credit card, I swipe in or place it on a machine, the longer it takes for response to come back, the less customers you can transact with in that period of time. In order to process data in more immediate fashion, and interact with customers using the 32, 70s like screen, a new set of program paradigms have to be considered. As you can see the word conversation appears in each of the programming styles, as it assumes that you are having a conversation. This is usually a conversation between the system and the end user. The idea is you have a beginning and an end to these conversations, but what happens in between can be completely different. In the case of a non-conversation transaction, there's a stop on-demand, but they run together. The transaction is complete within one iteration. You can think of this as an API call where the result is available immediately, and there's no need to continue once the result is received. For example, request in the balance of your checking account, it requires you to provide the account number, and then you receive the bank balance back. Any other work you want to perform is not directly typed upon request. Conversation, on the other hand requires you to provide several inputs, where the path is decided based on the inputs themselves. This interaction means that the program needs to respond to an input with a request for additional input, all of this will eventually produce the final result. They will take an uncertain path through the program to get there. What makes a programming style conversational, is that every time a response for input is sent to the user, the system waits for the user to respond. The program is suspended and any results is acquired by the program will remain locked, until the final outcome is achieved. A great example of this, is a menu system, the first screen will prompt to you several options. Then when the user responds, the program would time in the next process and look. Why the need for the last programming style? Just imagine a user enters a transaction that produces a screen, and gets a phone call before they respond, they remain on the phone for an hour as the program is suspended, holding resources until they respond. This would not allow for many users in a system, as the inconsistency alone would be hard to predict. The last programming style has the benefits in non-conversation programming, allows for the requirements conversational. Pseudo conversational programming has the programmer ends the task, and therefore the program writes off the response to the user with a prompt for input. This way, the latency associated with user think time is completely removed from the picture. Sounds great, right? How does this affect the underlying program? Well, the program must have the ability to be restarted where it left off, and the user finally responds. In order to do this, some state information must be kept in the system that allows the program to know where they left off, and keep any data required to restart in the middle of that conversation. This area is known as the commarea or communication area. Although there are new methods to keep state information between pseudo-conversations, the commarea is still heavily used, not only to store state data for CICS programs. Is also used to pass information between different programs, as you'll see later on in the course. With the adoption of the pseudo-conversational programming style, CICS regions were able to host many users running the same or different applications. However, in the mid 70s address spaces were still only 16 megabytes, so the biggest limitation to adding more users and programs was space. One of the solutions was to create a separate CICS address spaces known as regions, that were dedicated to individual services. Regions that hosts the terminals were labeled TOR, the ones that house applications were known as AORs, and Data services were moved to FORS or DORs. At same time instead of creating a single program for whole applications, development was broken down into categories. The categories initially created closely match the region demarcations, but soon the industry adopted a modular programming style, set out for the maximum reuse of common routines. These developments pulls up applications to be spent in many individual modules whenever, possibly multiple regions, and the modern CICS application was born. As a result, CICS programming today is divided into three main categories. The first is the presentation layer, this layer which is used for all communication with the end user. The advantage of using a separate presentation layer is, the ability to swap out, or add new forms of presentation without affecting the backend business logic of the application itself. Just imagine the transition for terminals, to tablets, to mobile phones, with services we use today. Each can have different requirements for how data is presented to the display. The only require a change to one category to support the new device. Most presentation services have all been moved from CICS, as other platforms tend to be more suitable for that processing. Html pages that contain items such as radio buttons or selection lists, can be easily processed at the local plan. CICS is simply used as the delivery mechanism to deliver those pages. Business-logic, on the other hand, is where you perform the work on the customer data, and is still primarily processed by application programs in CICS. Well, their customers who have incorporated new languages such as Java and NodeJS into these applications. The Core COBOL applications remain as it would take many years to replaceable them all. What's more is the CICS along with SOCKS provides the ability to hanging massive workloads with security, integrity and performance unmatched by the platforms. Customers have attempted to revive whole CICS applications on other platforms, and rarely have been able to match the reliability, integrity, and performance. Besides, if you take an application as a whole, agree write in another language for running on another platform, and march the CICS performance. What would you have in the end? A big bill and the same thing that you started with. The last layer is the data services layer, even though many customers are chosen not to separate data access from business-logic. As you can imagine, the housing and access to the data can't change. For a minute you're using these some files to house your data, the next you have the need to query that data. But a separate data layer, the storage and retrieval of data is left to the module that can be replaced as requirements change. Some would even argue that the module in this layer, can be used to go to other platforms through web services to retrieve data, whose underlying storage methodology is unknown to the program in question. Either way, over the years, the separation of services has allowed CICS applications to be easily and quickly incorporated into new applications. In some cases with little or no changes to the underlying programs or tool.
