Pseudo-conversational Programs and DFHCOMMAREA

Q. Is there a trade-off between Conversational and Pseudo-conversational Programs?

COBOL Programs that run in Online mode on CICS Software could be Conversational or Pseudo-Conversational. How the COBOL Programmer has written and designed the COBOL Program, determines if its Conversational or Pseudo-conversational. Conversational Programs are more resource-hungry and costly in terms of Mainframe computer time as opposed to Pseudo-conversational Programs. Let’s say that you wanna book a Railway-Ticket to Varanasi. When you type the Transaction TBOOK on the Terminal, you get the MAIN MENU Input Screen. Now, you can either type options 1, 2 or 3 to book, cancel or view your ticket respectively. During the time you decide which option to choose, and stare at the screen, the COBOL Program is still alive, it is only in a Paused or Halted State, it is still living in the CICS region. The COBOL Program keeps on waiting, expecting User Input. The moment, you type Option '1' and hit ENTER, the COBOL Program resumes, receives the Input Data from MAIN MENU Screen, process the data, and sends the BOOK MENU Output Screen, and pauses, hits the breaks, and waits for you to type Input. But, it is live and Loaded into CICS Region, it has not stopped running. As the user fills in the Passenger details and train no., in the meanwhile the COBOL Program is still waiting. Once, you’ve filled in your Travel Plan details, and hit ENTER, the COBOL Program resumes, receives the Input Data from BOOK MENU Screen, processes the data, books(reserves)/marks the seat for you in the train compartment, and display the Output CONFIRMATION TICKET Screen to you. The gist of the concept, is that right from when you type TBOOK and invoke the Booking Transaction, till the time you type EXIT(or press PF3 Key on MAIN MENU Screen), the COBOL Program keeps on running, it is alive and loaded into CICS Region, for the entire Length of the User Session. Even when the User is staring at the CICS GUI Screen, thinking what input to type next, the COBOL Program is still alive and kicking, running, but waiting for your Input. The COBOL Program doesn’t get killed, terminated till your Interaction(Session) is complete. This is called a Conversationaal Program.   During the time-frame, when one CICS Output Screen is displayed on terminal, and the User is staring at the screen, thinking what Input Data Values to fill up, and then hits ENTER, the COBOL Program is alive and is kept in CICS Memory(Region), waiting for User Input. This sounds good and rosy-rosy, when it’s just a couple of users who want to Book tickets. Conversational Programs are good, when there’s just one user who needs service. Keeping the COBOL Program loaded into Memory, while the user is looking at the screen deciding what to type -  the COBOL program just sits idle on the CPU, is a sheer wastage of Mainframe Computer Time, especially when there are hundreds and thousands of People around the country who want to book tickets and need to be serviced concurrently. This is where, Pseudo-conversational Programs come into picture.

Q. How do Pseudo-conversational Programs work?

In Pseudo-Conversational Programs, every time you type Input data on a CICS Screen, and hit ENTER, the COBOL Program starts from the PROCEDURE DIVISION, validates and processes your data, and displays the next Output Screen. After displaying the Output Screen, the COBOL Program gets killed, terminated – doesn’t remain active, it is off-loaded from the CICS Region. Thus, unlike conversational programs, Pseudo-conversational programs do not remain paused, or keep waiting in the CICS Region, listening for User Input. Instead, when you type Input and hit ENTER(Press any of the Attention Identifier AID Keys), the COBOL Program re-starts all over again from the top at the PROCEDURE DIVISION. Once the processing is complete, and the Output screen is displayed to you, to COBOL Program stops running and is killed. Given below is how Pseudo-conversational Programs compare with their Conversational Counterparts.

Q. What is DFHCOMMAREA? Why is it a Linkage Section Storage Area?

When the user types Input text Data on the CICS GUI Input Screen – say he presses Option 1 on the MAIN MENU Screen, and hits ENTER, the COBOL Program starts from the top at the PROCEDURE DIVISION, processes the data, and sends the next CICS Output Screen say BOOK MENU Screen, and gets killed(terminated). This is called one Invocation of the COBOL Online Program. The User stares at the BOOK MENU screen, decides what Input to type, and then after filling in the passenger details on the BOOK MENU Input Screen, hits ENTER. The COBOL Online Program restarts all over again from the PROCEDURE DIVISION, processes the Passenger Details and reserves a ticket, and sends the next CICS Output Screen say CONFIRMATION TICKET Screen, and gets killed. This is the second invocation of the COBOL Online Program. Every time, the COBOL Program starts from the PROCEDURE DIVISION, receives data from the Input Screen, processes the data, and sends the next output screen, and finally stops running. The Start-Receive Input-Process-Send Output-Stop cycle keeps repeating till you are done with your task. Each time you type data and hit ENTER, you invoke or run the COBOL Program to process your inputs. Sometimes, you need to save(remember) data between two successive runs, or invocations of the COBOL Online Program. Such data cannot be stored in Working Storage Areas of the COBOL Program. Working Storage Areas are created when the COBOL Program starts, and deleted when the COBOL Program stops. Working Storage Areas are rough-work areas(scratch-pad) of the COBOL Program, that live only as long as the COBOL Program runs. The requirement however, is to store(save) data across multiple invocations(runs) of the COBOL Online Program. When you want to store(save) data which is globally accessible across several runs a COBOL Program, you use Linkage Section Storage Areas. Given below is a simple picture that depicts how Linkage Section Storage areas differ from Working section storage areas. You’ve got a simple Storage Area A containing the value 0. You write a COBOL Program to ADD +1 TO A. Case 1: If A were to be a Storage Area in the WORKING-STORAGE SECTION. Each time the COBOL Program starts WS-A Storage Area is created with value 0, and the COBOL Program adds +1 to WS-A, so WS-A becomes 1. After the COBOL Program stops, WS-A is deleted. So, this doesn’t offer you memory of the past feature, with working storage areas you don’t remember, what was stored in WS-A previously, the last time the COBOL Program ran. Case 2: If A were to be a Storage Area in the LINKAGE SECTION. Here WS-A Storage which  is globally accessible and shared across the 1st run, 2nd run and the 3rd run of the COBOL. WS-A is a Linkage section Area, so this Storage area is independent of the COBOL Program. It helps to remember data of the past, pass data from one invocation(run) to the next successive invocation(run). DFHCOMMAREA is a Linkage Section Storage Area that helps to store(save) data, pass data around from one invocation(run) to another invocation of a COBOL Online Program in CICS. Thus, Linkage-section storage area DFHCOMMAREA plays an important role to remember and retain data between two successive invocations.

Introduction to CICS

Q. I have been wondering, how does Online Mode of Processing work as opposed to Batch Mode?

COBOL Programs generally process Data in Batch Mode(Offline Mode). In Batch mode - you must tell all the Inputs, Outputs at the very beginning, right at outset, even before the Program actually starts. On the buzzer, once you hit SUB(Submit) and give your job(task) to the Mainframe Computer for processing, there’s no turning back. The Mainframe Computer processes your data, according to its own convenience. It can take a long time for the program to generate outputs – you don’t have any clue. During this time, there is no interaction between the COBOL Program and the user. There is no manual intervention from the time, the COBOL Program begins to run, until it completes. Once the COBOL Program completes, it alerts you – notifies you, of the results. In other words, the COBOL Program is run Offline – it wouldn’t provide immediate outputs/results to the Inputs, you supply. So, in Batch mode, don’t expect a COBOL Program to give you immediate outputs/results to your Inputs, on the spur of the moment, on the go.  Contrast this, with running a COBOL Program in Online Mode. In Online(Interactive) mode, you give some input, the COBOL Program processes your Data Input, produces some output, then you type some more input, that the COBOL Program processes and you get some more output. This Input, Process, Output cycle continues, until you arrive at the final solution. In Online mode, the Program give immediate(quick) response or output, to the Inputs you supply, on the go, on the spur of the moment. You don’t have to wait too long in Online, unlike Batch Mode(Offline).

Can you run a COBOL Program in an Online, Interactive Manner on a Mainframe Computer? What is CICS Software?

CICS Software can be used to run COBOL Programs in an Online Interactive manner, on a Mainframe Computer. CICS stands for Customer Information Control System. CICS Software is a giant, robust Transaction Server. Let’s think about Flight Reservations. Zillions of people around the globe, who want to travel send their requests for Booking Tickets. It is CICS Software that handles, manages these requests, passes them on, and gets them processed using the correct COBOL Program, immediately, on-the-fly, and sends the Output Response back to the Client. CICS Software is robust server, that can humungous volumes, huge loads of Transactions at a time. IMS-DC and TPF are examples of some other Transaction Monitors on IBM Mainframes. Role of CICS Software : Bear in mind, that when you run a COBOL Program in online-mode, it runs under the supervision of CICS Software. So, a COBOL Program in Online Mode, directly doesn’t run on its own, stand-alone. It is the CICS Software that handles all the activities on behalf of the COBOL Program.   Where does the COBOL Program come into picture : The entire Data Processing Logic(Business Rules) is written in the COBOL Program. CICS Server is just an intermediary, which delegates and passes on requests of folks to the COBOL Program for Processing. The actual data-processing is done by the COBOL Program.

Q. What are Transactions? How do you run COBOL Programs in CICS? What are CICS Tables?

In Windows, you double-click a Program, to start it in the Online-Mode. However, in CICS, a user cannot directly start a Program. Instead, you define a Transaction, which in turn will run the COBOL Program in Online Mode. Every transaction has a 4-byte Unique identification number called Transaction ID. You wanna to run COBOL Programs in Online mode on CICS, transactions are the way. How do you run a COBOL Program on CICS? On a CICS Terminal(like a Web-browser), when you type the Transaction-ID, and hit ENTER, the COBOL Program is loaded, immediately started in the online-mode. This is called invoking the Transaction. For example, if the COBOL-online Program is BOOKTKT, and the Transaction-ID is TBOOK, when you type TBOOK, and hit ENTER, CICS Software will find the the COBOL Program BOOKTKT on the Disk, and Load into the CICS Region and execute it in Online Mode. Similar to TSO, CICS Software serves many users simultaneously. CICS is a very robust Transaction Monitor (keeps listening for transactions) – it can handle trillions of transactions at a time. When you invoke a transaction, by typing say TBOOK, it starts a COBOL Program like BOOKTKT. But how does the CICS Software, which COBOL Program to start for the transaction TBOOK? Moreover, the CICS Software also needs to know the place(location) to look for your COBOL Program. What is the PDS, Folder or library on the Disk in which the COBOL Load Module BOOKTKT resides, so that CICS Software can pick up the Load, and start running it. Now, all this extra-information is stored in CICS Tables. The important CICS Tables are : PCT – For Transactions PPT – For COBOL Programs FCT – For Files RCT – For DB2 Connections When you type the Transaction ID – TBOOK, on the Terminal, the CICS Software will look-up the Transaction in the PCT. Transaction Program TBOOK BOOKTKT TABC PROGR01 TDEF PROG02 ... ... PCT Table(Program Control Table) tells the COBOL-CICS Program for any Transaction. Program Load Pointer BUA21 AGY0157.CICS.LOADS BUA22 AGY0157.CICS.LOADS BOOKTKT AGY0157.DEMO.CICS.LOADLIB BUA23 AGY0157.DEMO.CICS.LOADLIB PPT Table(Process Program Table) tells the location(Load Library) from which the COBOL Program(Load) must be picked up, and loaded into the CICS Region.

Q. How do you add entries/remove entries from PCT and PPT, for your Transaction and COBOL Program?

Just as you can write your own custom Transactions(Online COBOL Programs), IBM supplies some ready-made, pre-written transactions for doing some common day-to-day tasks. For example, you can use the Ready-made transaction CEDA, to add your Transaction’s entry into the CICS PCT Table. Such ready-made transactions supplied to you by IBM for doing routine tasks are called Utility Transactions. CEDA – CEDA is the ready-made Utility Transaction, to DEFINE(add) new entries in the CICS Tables. CEMT – CEMT is the ready-made Utility Transaction, to ENQUIRE(Search), or query the entries(rows) in CICS Tables. A second more important use of CEMT is to refresh the Load Pointer. Whenever you make changes(modifications) to a CICS Transaction(COBOL Online Program), you also need to reset(refresh) the Pointer in PCT Table, disconnect it from the Old Load, and point it to the new Load Module. CECI – CECI is the ready-made Transaction, that stands for CICS Command Level Interpreter. Essentially, when you want to execute(run) and test some CICS Instructions, outside a COBOL Program(without writing a complete COBOL Program), you can use CECI ready-made transaction. For example, after designing CICS GUI Screens, when you want to test them, display the screens and see how they look, you would use the ready-made transaction CECI.