John Alleyn-Day writes:

>Some time ago I switched for a period to programming on an IBM mainframe
>using CICS.  Not knowing any better I adapted my experience with the
HP3000
>to write the programs.  They worked - but after I left, the company had to
>re-engineer most of my programs because CICS works in a totally different
>way from MPE and my code was very inefficient.  In essence, the CICS
>programmer has to be aware of a fundamentally different way of swapping
>programs in and out of memory, and design the programs to correspond from
>the ground up.

Uh-oh!  I've worked with CICS and DLP (Unisys) screen handlers and they 
are totally different from MPE.  Not so much the screen handler itself 
(field mapping, display attributes, etc) but the methodology used is 
psuedo-conversational as opposed to HP's conversational mode.  I've seen 
psuedo-conversational programs on the HP, but they are not pretty. 

If you're wondering what a psuedo-conversational program is and how 
it differs from a conversational one, let me tell you.  The standard 
HP VPLUS program remains active and controls the screen during the entire 
transaction (from initial screen display until the transaction is 
completed).  A pseudo-conversational scheme assumes that programs will 
be activated and then die.  For instance, in a standard MPE VPLUS 
routine that displays a screen, accepts a customer number, displays 
the customer data, and accepts changes to that data, you would normally 
use one program to do all that stuff.  The screen would be displayed and 
the program would wait for the terminal I/O to complete (the user is 
expected to type in the customer number and press the enter key).  The 
program would retrieve the customer data and display it for the user 
to review.  It would then wait for either a new customer number or 
the updated customer data.  Again, it pauses while waiting for terminal 
I/O.  When the user modified the data and presses the enter key, the 
program would edit the data and update the data base.

Now, a psuedo-conversational programming model would have a program that 
displayed the initial screen and then terminated.  While waiting for the 
user to enter a customer number, the only thing active would be the 
terminal monitor that accepts all terminal I/O.  When a user enters 
a customer number and presses the "enter" key, the terminal I/O 
monitor examines the transaction and activates the proper program 
(which usually depends on a transaction code embedded somewhere in 
the screen).  This second program would only accept the customer 
number (from the terminal I/O monitor) and then format the customer 
data for the screen, display the screen, and terminate.  While the 
user ponders the data, the only program active is the terminal 
I/O monitor.  If the user modifies the data, another, maybe different, 
program is activated to handle the data update.  

Of course, all these functions can be integrated into one program, 
but the real problem is not knowing what has happened prior to the 
program's activation. That's why psuedo-conversational programs 
have huge buffers where state information is passed.  In fact, 
psuedo-conversational programs are very like the state-less 
browser model used for web access which pass cookies back and 
forth to maintain state information.

Jim Phillips                            Manager of Information Systems
E-Mail: [log in to unmask]      Therm-O-Link, Inc.
Phone: (330) 527-2124                   P. O. Box 285
  Fax: (330) 527-2123                   Garrettsville, Ohio  44231