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.