What are the advantages of pseudo conversational vs conversational CICS programming?

Question

I am trying to understand the differences between pseudo conversational and conversational CICS programming. What are the advantages and disadvantages of each approach?

Cucullate

Hey downvoters... this is a serious question. Would you be so quick to downvote if OP was asking what characterized REST or MVC? – Endothecium

@Endothecium - The question as originally asked was a little rough, but it should now be in a much cleaner state. – Expertism

This should be re-opened. It is a perfectly clear and legitimate question. – Incoordination

This is a perfectly understandable question. Any one with CICS programming experience on the Mainframe should understand it – Chellman

Answer 1

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 responds to User Actions or Events (i.e. PF keys).
• A pseudo-conversational program is only run when
  1. Started/called by another program
  2. The user does certain actions (e.g. hits enter/pk-key). in-between tims- all resources are released

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.

Chellman

Answer 2

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.

Endothecium

Answer 3

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.

Isfahan