[log in to unmask] wrote:
>      I am hoping that there are IBM-type people on this list who can
>      translate something for me to the MPE world.  A coworker of mine
>      who is familiar with IBM but not very familiar with MPE wants to
>      do the following (which is in IBM) speak:
>
>      Have CICS waiting for a message and when a transaction is received
>      then a certain series of actions is taken.  Since CICS is aware of
>      where these transactions is coming from it can then send a message
>      back to the transmitter of the message.

You aren't dealing with only IBM-to-HP "speak" but also the underlying
concepts of the two platforms.  CICS is (for the benefit of our HP
readers not familiar with IBM) a single process which manages multiple
terminals for online processing.  By reducing CICS to a single process,
there is no need to duplicate code and overall environment for each
terminal; you design things to perform standalone "transactions" and you
write code which handles "transactions" on a one-shot basis (not unlike
a WWW cgi-bin program - one block of input, one block of output).  This
is the IBM way (been there, done that, written self-relocating
re-entrant assembly language code, got the core dumps).  Bottom line was
you could run a boatload of terminals with only *one* copy of code in
memory.

Now enter MPE.  It has, by default, self-relocating re-entrant code.
Furthermore, it has separate address spaces for code and data, so there
is total isolation of "user data" and "code".  Now you can write a very
dumb COBOL application that interacts with only one user (note to
non-IBM readers, this is an alien concept on IBM).  Now throw it out to
users and let many users run the application.  There is only *one* copy
of the code regardless of the number of users, and each user has his own
private data storage area (unlimited save areas/working storage per
user).

So... if you want to emulate CICS on the 3000, good luck; you will have
to work really hard to get one process to serve multiple users.  But if
you simplify the ground rules so that you can write a program to deal
with a single user, MPE will do all the hard part for you.  Your CICS
person needs to set aside his CICS mindset to understand this.

>      Specifically, he would like a person to dial into our system and
>      submit a transaction (most likely a request for data) and have the
>      system automagically do the following:
>      1. Accept the transaction which contains a transaction code and the
>         selection criteria for the search.
>      2. Recognize the transaction code and the selection criteria.
>      3. Search the image database for the data and retrieve it.
>      4. Return the data back to the submitter.
>      5. Ofcourse all of this should only take a matter of seconds.

Yep, that's CICS mindset ("transaction").  Forget the constraints you
must accept for CICS (single-shot one-input one-output limited save area
and so forth) to deal with multiple users; concentrate on ONE program
that talks to ONE user and has its own data space.  You can save data
and do multiple reads, no need to pack everything into one
"transaction".  It is a piece of cake, and MPE will "automagically" do
the code sharing and data isolation you work so hard for in CICS.

>      We have a meeting with and HP engineer early next month and we
>      would like to be able to atleast know what we are asking for.
>      Also I am sure there are third party (or even HP) packages that
>      could do this easily for us I believe this is something we would
>      like to try on our own (but recommendations for third party
>      products are not unwelcome).

Your begging to spend money :-)  Depending on your application, you
should not have to worry about any of this, what you want is alreay
there and done for you by default.  CICS (and/or IMS) and MPE are two
totally different philosophies and they aren't about to change (either
way).

Jeff Kell <[log in to unmask]>