gtpc2maa | C/C++ Language Support User's Guide |
This function deallocates the specified conversation from the transaction
program. An implied FLUSH is executed, and the resource ID becomes
unassigned when the deallocation is complete.
Format
#include <tppc.h>
void tppc_deallocate(unsigned int *resid,
struct tppc_return_codes *rcode,
enum t_deallocate_type type,
enum t_deallocate_logdata logdata);
- resid
- This is a pointer to a 4-byte field that contains the resource ID.
This resource ID must be the ID assigned on the initial ALLOCATE for this
conversation or one that was assigned by an incoming ATTACH.
- rcode
- This is a pointer to the structure tppc_return_codes, defined
in tppc.h, where the return code is to be placed.
- type
- This argument must belong to the enumeration type
t_deallocate_type, defined in tppc.h. Use
one of the following values:
- DEALLOCATE_TYPE_SYNC
- This value specifies that either the tppc_flush or the
tppc_confirm function should be performed before the conversation
is deallocated, depending on the sync level specified at ALLOCATE
time.
- DEALLOCATE_TYPE_FLUSH
- This specifies that the function of the FLUSH verb should be executed and
then the conversation should be deallocated.
- DEALLOCATE_TYPE_CONFIRM
- This specifies that the function of the CONFIRM verb should be executed
and then the conversation should be deallocated.
- DEALLOCATE_TYPE_LOCAL
- This specifies that the conversation should be deallocated locally.
This type of deallocation can be specified only if the conversation
is already in end-conversation state.
- DEALLOCATE_TYPE_ABENDP
-
- DEALLOCATE_TYPE_ABENDS
-
- DEALLOCATE_TYPE_ABENDT
- The 3 abend parameters specify that the conversation should be
unconditionally deallocated. Logical record truncation can occur when
the conversation is in send state, and data purging can occur when
the conversation is in receive state. The only difference
among the 3 abend codes is in the sense codes used to notify the remote
transaction program. ABENDP is intended to be used by the
application transaction program to indicate that it is requesting the
deallocation. ABENDS and ABENDT are intended to be
used by the TPF/APPC support routines when they request the
deallocation.
- logdata
- This specifies whether error information should be logged. This
argument must belong to the enumeration type t_deallocate_logdata,
defined in tppc.h. Use the value
DEALLOCATE_LOGDATA_NO.
- Note:
- The TPF system does not support the value YES that is defined by the
LU 6.2 architecture.
Return Codes
The following table contains a list of the primary and secondary return
codes that can be returned to the program that called the
tppc_deallocate function. A complete list of the return
codes and their definitions can be found in Table 37 and Table 38.
Symbolic Name
| Primary Code
| Secondary Code
|
LU62RC_OK
| 0000
|
|
LU62RC_PARAMETER_CHECK
| 0001
|
|
LU62RC_PK_BAD_TCBID
| ....
| 00000001
|
LU62RC_PK_BAD_CONVID
| ....
| 00000002
|
LU62RC_PKDLLOC_BADTYPE
| ....
| 00000051
|
LU62RC_PK_BAD_OPTION
| ....
| 00C62074
|
LU62RC_STATE_CHECK
| 0002
|
|
LU62RC_SKDLLOC_FLUSH
| ....
| 00000052
|
LU62RC_SKDLLOC_CONFIRM
| ....
| 00000053
|
LU62RC_SKDLLOC_ABEND
| ....
| 00000056
|
LU62RC_SKDLLOC_LOCAL
| ....
| 00000057
|
LU62RC_ALLOC_ERROR
| 0003
|
|
LU62RC_SECURITY_NOT_VALID
| ....
| 080F6051
|
LU62RC_TP_NOT_AVAIL_RETRY
| ....
| 084B6031
|
LU62RC_TP_NOT_AVAIL_NO_RETRY
| ....
| 084C0000
|
LU62RC_TPN_NOT_RECOGNIZED
| ....
| 10086021
|
LU62RC_PIP_NOT_SPECIFIED_CORRECTLY
| ....
| 10086032
|
LU62RC_CONV_TYPE_MISMATCH
| ....
| 10086034
|
LU62RC_SYNLVL_NOTSUPORT
| ....
| 10086041
|
LU62RC_DLLOC_ABEND_PGM
| 0006
|
|
LU62RC_DLLOC_ABEND_SVC
| 0007
|
|
LU62RC_DLLOC_ABEND_TMR
| 0008
|
|
LU62RC_PGMERR_PURGING
| 000E
|
|
LU62RC_CONVFAIL_RETRY
| 000F
|
|
LU62RC_CONVFAIL_NORETRY
| 0010
|
|
LU62RC_SVCERR_PURGING
| 0013
|
|
LU62RC_TPF_ABEND
| FFFF
|
|
Programming Considerations
- The conversation must be in the following state, depending on the type of
deallocation requested:
- Type
- State Required
- FLUSH
- send
- CONFIRM
- send
- LOCAL
- end-conversation
- ABEND
- send, receive, received-confirm,
received-confirm-send, or
received-confirm-deallocate.
- The value supplied in resid must be the resource ID returned by
the tppc_allocate function or one that was assigned by an incoming
ATTACH.
- When the DEALLOCATE is complete, the conversation identified by the
resource ID is completed, and no further functions can be called for that
conversation.
- If the transaction program exits without deallocating a conversation, the
TPF system does not deallocate that conversation. The program should
call this function for all conversations before exiting.
- If the type=DEALLOCATE_TYPE_CONFIRM option is specified,
TPF's EVENT and POST facility is used to suspend the ECB until the
program receives a confirmation reply. Since the ECB is suspended, all
unnecessary resources should be released before the issuance of this
verb. Failure to do so can cause serious system degradation.
- Note:
- You can avoid the problem of suspended ECBs by using the
tppc_activate_on_confirmation function instead of
tppc_deallocate. See tppc_activate_on_confirmation-Activate a Program after Confirmation Received for more information.
- If the type=DEALLOCATE_TYPE_CONFIRM option is specified, the
normal response from the remote transaction program is CONFIRMED.
However, if the remote program issues a DEALLOCATE TYPE=ABEND, the local
transaction program goes into end-conversation state. If the
remote transaction program issues a SEND_ERROR, the local program goes into
receive state, and the conversation continues.
- If the type=DEALLOCATE_TYPE_CONFIRM option is issued and the
program does not receive a confirmation reply within a certain amount of time,
TPF/APPC support issues an unbind to terminate the conversation. The
amount of time that the system waits is determined by the value you specify
for the TPRECV parameter on the SNAKEY macro. See TPF ACF/SNA Network Generation for information about the
SNAKEY macro.
- The remote transaction program receives the deallocation notification by
either a return code or the WHAT_RECEIVED indication. (See the
whatrcv parameter of the tppc_receive function; tppc_receive-Receive Information.)
- See Programming Considerations for Basic Conversation Functions for additional programming considerations relating to the
TPF/APPC basic conversation functions.
Examples
The following example deallocates a specified conversation.
#include <tppc.h>
unsigned int resource_id;
struct tppc_return_codes return_code;
·
·
·
/* set up resource_id with the value returned from the allocate verb */
·
·
·
tppc_deallocate(&resource_id,&return_code,DEALLOCATE_TYPE_SYNC, \
DEALLOCATE_LOGDATA_NO);
/* normal processing path */
·
·
·
Related Information