I am trying to understand the differences between pseudo conversational and conversational CICS programming. What are the advantages and disadvantages of each approach?
NealB's answer is a good one, and you should read
IBM's description
The main advantage pseudo conversational programs is reduced Computer resource usage and they can not hold Database locks.
--------------------------------------------------------------
I am going to try and express the answer in Non IBM-Mainframe Terms
In conversational programming, The program sends a screen and waits for the user to respond. The program will hold on to memory, database resources etc.
i.e.
Send Screen and wait for a users response
Evaluate user-response
when PF2
Do Something
when PF3
Do Some Thing else
Pseudo-conversational programming is basically another name for Event-Based-Programming.
A pseudo-conversational program is bit like a ActionListener in Java swing (or any other Swing, Web, SWT equivalents)
I tend to Structure CICS like
Initialise and get-screen and user-action
Evaluate
when initial-entry
Initial stuff
Send initial screen
When PF2 /* Delete Action */
Do Delete
Send Response
When PF3 /* Insert Action */
......
end-evaluate
exit program
In java-Swing you could write the above as
Class MyScreen implements ActionListener {
public MyScreen() {
Initial stuff
Add this actionlistners to various buttons
Display screen
}
public void actionPerformed(ActionEvent e) {
if (e.getSource() == deleteButton) {
Do Delete
update screen
} else if (e.getSource() == insertButton) {
.......
}
}
}
For those not from a Mainframe background, CICS is a Application-Server like any Webserver, but instead of sending Web pages and recieving HTML requests, CIC's sends and 3270-Terminal screens and recieves responses from the Terminal.
Note: CIC's can also be used as a Web server as well.
Here is a link comparing conversational and pseudo conversational CICS
The basic difference is that in conversational CICS a process (program) is "alive" and holding resources (e.g. memory, database locks) while waiting for an event (e.g. user supplied data from a screen map). In pseudo conversational CICS the process "dies" (CICS RETURN) while waiting for an event to occur. A new unit of work is started and resources are re-allocated in response to the triggering event.
Pseudo converstional CICS is frequently used to build interactive applications in CICS. This technique is resource efficient since memory and database locks are released while the user is "thinking" - which is most of the time. The net benefit is more efficient use of resources but it takes a bit more effort to manage database consistency since it is up to the programmer to ensure transaction integrity (due to loosing locks over the course of the "conversation").
This outline only covers the essence of the topic. There is a whole lot more to it than this, but it is a start.
The short answer is that Pseudoconversational code does not contain an EXEC CICS SEND MAP logically followed by an EXEC CICS RECEIVE MAP without an intervening logical EXEC CICS RETURN. Thus your program is not consuming CICS resources during user "think time."
When your program EXEC CICS RETURNs, you can save state information in either a commarea (traditional) or a channel with one or more containers (since CICS TS 3.1).
There are more details, but that's the bare bones of it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With