🚀 go-pugleaf

>
> >Ummmm, Peter, you are correct for the native APPC API on OS/2.  However,
> >*CPIC* should clean up the TPID for you when the last conversation to
> >use it ends.  Otherwise you will eventually exhaust all available
> >storage, not to mention the questions of which one to use when performing
>
> However, in Pure CPIC a single program cannot do two
> Accepts either concurrently or serially.  SC26-4399-6 page 67 (CMACCP) Usage
> Note 2 "Although CPI Communications allows a program to accept only one
> conversation ..." and in Related Information on the next page "VM provides
> extensions to CPI Communciations that allow an application to accept more
> than one concurrent conversation."  Architecturally the problem is that
> CMACCP has no parameters to indicated what conversation it is supposed to
> accept, so the system has to know.  In fact, in OS/2 CM the TP already
> exists before the Attach Manager loads the program.  Just configure the TP
> to be a program that does not do an Accept.  It runs, ends, and the TPID is
> still hanging around unresolved.  Several hours later you can do a
> Receive_Allocate from some other program and connect to it.  Performing
> CMACCP in a loop is ouside the scope of unextended CPIC.
>

Since the timestamp of your message is later than Peter's 'watch this space'
response, should I assume that Peter's solutions of using CPI-C extensions
is *the* solution for me to use, until changes to the CPI-C architecture?

Thanks again to you all for your very informative responses/help.

Tom Thomas
Burlington Northern Railroad