🚀 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
>work on behalf of a client (in a cascaded server scenario, perhaps).
>Programmers should *not* be *forced* to use the new extensions to make
>their code robust.

In OS/2 TPs are cleaned up at process termination unless they are REXX TPs
where they are cleaned up at session termination.  Pure CPIC has no explict
TP concept, just conversations.  You don't explicitly start or stop TPs, the
system does.  This is one of the areas where APPC/MVS, for example, added
additional function between its first version (that did not allow a single
address space to serve more than one client) to a later version.  However,
to use only Pure CPIC, the server has to end after serving one client.  It
can Allocate as many downstream conversations as it chooses before, during,
and after accepting and ending the client conversation.  All activity would
be under a single TP.  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.