APPC, CPI-C, and SNA Sense Codes
The following return codes apply to all programs that
issue CPI-C calls.
A CPI-C call completed successfully.
- Explanation
- CPI-C executed the function that was requested.
- Programmer Action
- This is an "expected" return code. No action is required. This return
code should be handled as part of the mainline program logic for programs that
issue CPI-C calls.
- Operator Action
- None.
A session cannot be obtained for a conversation, and human intervention
will be needed to correct the problem.
- Explanation
- The local program issued an Allocate() call (CMALLC), but there was
difficulty in activating a link or a session.
CPI-C replies with this return code when it has determined that it is
impossible to allocate a session without some human intervention. For example,
the local communications software can tell when there is no adapter in the
local computer, making a conversation impossible.
If there is any hope that a conversation might be established, CPI-C
responds with the CM_ALLOCATE_FAILURE_RETRY return code. For example, CPI-C
cannot look in the remote computer and see if there is a communications
adapter there or see if it is even powered on. CPI-C retains some hope that a
conversation might still be established by simply retrying the Allocate()
call.
When you get this return code in a production environment, the problem is
frequently a transient link failure--which is recoverable. Retrying the
Allocate will generally be successful. Contrast this with a test environment,
where the conversation is being established for the first time. In a test
environment, either return code is likely, and there is probably a setup
problem with the network hardware or software.
The implication of this return code is that something is wrong at the local
computer, but this is not necessarily always true. (Experience suggests that
for any of these problems, it is likely both computers are set up wrong, as is
the connection between them!)
This conversation with the partner is over.
- Likely Causes
- There are thousands of reasons for this return code. The local computer is
unable to set up the session it needs with the remote computer. Here are some
likely causes:
- The partner LU name is not really in the network or cannot be reached.
- The partner LU name might be incorrect or the target computer is not
active or is not reachable. Partner LU names are configured as part of the
CPI-C side information, or set with a call to a Set_Partner_LU_Name().
- The mode name requested for this session is not configured or spelled
correctly at the partner.
- There is no route through the network that satisfies the requirements of
the mode name. For example, there isn't a secure route that meets the
requirements associated with #INTERSC.
- Programmer Action
- There are thousands of reasons for this return code. A specific reason for
the failure can be found in the SNA sense data associated with this
return code. To diagnose the problem, your program must provide this SNA sense
data to its user, or indicate a way it can be obtained. You should consider
directing your users to find sense data values in traces and error logs.
The local program should not try to allocate a session again until the
condition is corrected.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Examine any platform-related message logs and error logs at both locations
to find more information about this problem. Look for equipment failures or
setup problems related to the network components and the computers using them.
Fix the problem, as indicated by any SNA sense data associated with this call.
You may need to run the applications again with SNA tracing activated to get
the sense data.
After correcting the problem, try running the pair of programs again, if
appropriate.
A session cannot be obtained for a conversation; the problem may be
temporary, but human intervention will probably be needed to correct the
problem.
- Explanation
- The local program issued an Allocate() call (CMALLC), but the underlying
network software was unable to obtain or activate a session.
CPI-C replies with this return code when it has determined that it cannot
allocate a session for a conversation. If the Allocate() request is tried
again at a later time, the session might be able to be obtained, without human
intervention. For example, CPI-C cannot look in the remote computer and see if
there is a matching communications adapter there. CPI-C retains some hope that
a conversation might still be established by simply retrying the Allocate()
call.
Although this return code has the word "RETRY" in it, the allocation
request might never succeed, especially if the partner is never activated or
has been configured wrong.
This conversation with the partner is over.
- Likely Causes
- There are thousands of reasons for this return code. The local computer is
unable to set up the session it needs with the remote computer. Here are some
likely causes:
- The remote computer is not powered on or has no communications adapter.
- The underlying CPI-C or APPC software on the remote computer is stopped,
has not been started or is not yet fully active, or is abended.
- The DLC at the remote computer is not configured correctly.
- One computer, using a dependent LU 6.2, is attempting to communicate
with an independent LU 6.2.
- Programmer Action
- There are thousands of reasons for this return code. A specific reason for
the failure can be found in the SNA sense data associated with this
return code. To diagnose the problem, your program must provide this SNA sense
data to its user, or indicate a way it can be obtained.
The local program should try again (at least once) to allocate a session
for a conversation. There are some conditions that cause a failure the first
time and succeed every time after that. To avoid congesting the network with
attempted allocation requests, the local program should pause or wait for a
keystroke before repeatedly retrying the allocation, and limit the number of
retries. The implication of this return code is that something is wrong at the
partner location or with the connection between the two computers, but this is
not necessarily always true.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Examine any platform-related message logs and error logs at both locations
to find more information about this problem. Look for equipment failures or
setup problems related to the network components and the computers using them.
Fix the problem, as indicated by any SNA sense data associated with this call.
You may need to run the applications again with SNA tracing activated to get
the sense data.
After correcting the problem, try running the pair of programs again, if
appropriate.
The conversation type of the local program is not expected or supported
by the partner.
- Explanation
- The partner computer rejected the incoming Attach because it or the
partner program does not support the specified conversation type. The local
program set the conversation_type to CM_MAPPED_CONVERSATION or
CM_BASIC_CONVERSATION, and the partner configuration does not support that
type of conversation.
This conversation with the partner is over. This return code will recur
until either the local program or the partner configuration is changed. CPI-C
reports this return code on a conversation call issued after an Allocate()
call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 10086034.
- Likely Causes
- This is probably a configuration problem at the partner or a mismatched
pair of programs. The TP definition at the partner must match the conversation
type used by the local program.
- Programmer Action
- Decide what the correct conversation type should be (basic or mapped).
Change the local program so it uses the correct conversation type.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Change the TP definition at the partner to reflect the conversation type
required by the local program. To allow any conversation type at the partner,
configure the conversation type in the TP definition to allow "Either".
The install and setup procedures for your application should not allow this
return code to occur in a production environment.
The partner expected PIP data, which cannot be sent using CPI-C.
- Explanation
- The partner computer rejected the incoming Attach because the partner is
defined to expect one or more program initialization parameter (PIP)
variables. No PIP data was sent, because it cannot be sent using CPI-C. This
return code is returned only when the partner program is using a native APPC
(LU 6.2) application programming interface and is not using CPI-C.
This conversation with the partner is over. This return code will recur
until either the local program or the partner configuration is changed. CPI-C
reports this return code on a conversation call issued after an Allocate()
call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 10086032.
- Likely Causes
- This is a configuration problem at the partner. The TP definition at the
partner cannot require incoming PIP data for this conversation.
- Programmer Action
- PIP data is an obsolete APPC concept, not supported by CPI-C. The partner
program needs to be modified to receive initialization parameters as part of
its initial data exchange with its partners.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Change the partner's TP definition so that it does not expect PIP
data.
The conversation security fields sent by the local program are invalid
for the partner.
- Explanation
- The partner computer rejected the user ID or password received on an
incoming Attach.
This conversation with the partner is over. This return code will recur
until either the values supplied by the local program or the partner
configuration are changed. CPI-C reports this return code on a conversation
call issued after an Allocate() call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 080F6051.
- Likely Causes
- This is probably a configuration problem at the partner or an incorrect
user ID and password supplied to the local program. The cause differs
depending upon the local conversation_security_type of the
conversation that failed. There are three values for
conversation_security_type:
- CM_SECURITY_NONE -- the partner's TP definition has been
configured to expect conversation security on the incoming Attach, but none
was supplied by the local program.
- CM_SECURITY_SAME -- this could be an access control problem. For
example, the user ID is valid, but the local user does not have the authority
to run the partner program.
If using OS/2 Communications Manager, a likely cause is the use of
Enhanced_Security_Same. The LAN (locally-logged-on) user ID and
password were sent automatically for you. The partner was obligated to check
these, and rejected the attempt. The local program should retry the allocation
request with CM_SECURITY_NONE.
Commonly available CPI-C applications like APING, ATELL, and AREXEC default
to using conversation_security_type(CM_SECURITY_SAME). This return
code indicates that the partner does not accept the user ID and password that
was sent. You may be able to get the applications to run by starting the local
program with conversation_security_type(CM_SECURITY_NONE), by using
the "-n" command line flag.
Another possibility occurs when the local program issues an Allocate() call
with CM_SECURITY_SAME, but the local platform downgrades the security level to
CM_SECURITY_NONE and sends that to the partner. If the partner's TP
definition has been configured to require security, this return code results.
- CM_SECURITY_PROGRAM -- the combination of user ID and password were
not accepted by the partner. For example, the partner is using OS/2
Communications Manager and its TP definition specifies
conversation_security(YES). The partner's APPC attach manager searched
its list of valid user IDs and passwords, but did not find the received
combination.
User IDs and passwords are both case sensitive. Assure that the values sent
by the local program match those expected by the partner's security
configuration.
- Programmer Action
- The Allocate() call made by the local program is using the wrong user_ID
or password parameter, or the partner's configuration of allowed user IDs
and passwords needs to be changed. In the local program, look at the values
specified in the CPI-C Set_Conversation_Security_Type(),
Set_Conversation_Security_User_ID(), and Set_Conversation_Security_Password()
calls. Verify that they specify user_ID and password values acceptable to the
partner.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- If the problem is with the partner configuration, assure that the user ID
and password combination sent by the local program has been correctly defined
there. User IDs and passwords are case-sensitive. Be sure that the combination
of uppercase and lowercase letters configured at the partner matches those
specified by the local program.
Assure that if these are required (see the partner's TP definition),
they will be accepted by the partner LU (see the partner's definition of
its partner LU).
The partner's CPI-C platform does not support the sync_level used
by the local program.
- Explanation
- The local computer rejected the Allocate() call (CMALLC) because the local
program specified a sync_level of CM_SYNC_POINT, which the partner
does not support. This return code is returned only for conversations with
sync_level set to CM_SYNC_POINT (or set to CM_CONFIRM, if
activating a session with IMS using its LU 6.1 adapter).
This conversation with the partner is over. This return code will recur
until either the local program or the partner configuration is changed. CPI-C
reports this return code on an Allocate() call.
- Likely Causes
- The partner, as it is currently installed, does not support Resource
Recovery (sync point) operations. The local program, which specifies sync
point operation, may be incompatible with the current system software.
- Programmer Action
- Since sync point is not available at the partner, consider designing your
program logic to do the checkpointing it needs without using the CPI Resource
Recovery (CPI-RR) functions.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Upgrade the partner's system software, if possible, to a version that
supports sync point operations.
The sync level of the local program is not expected by the partner.
- Explanation
- The partner computer rejected the incoming Attach because the local
program specified a synchronization level (with the sync_level
parameter) that the partner program does not support.
This conversation with the partner is over. This return code will recur
until either the local program or the partner configuration is changed. CPI-C
reports this return code on a conversation call issued after an Allocate()
call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 10086041.
- Likely Causes
- This is probably a configuration problem at the partner or a mismatched
pair of programs. For example, the local transaction program issued an
Allocate() call with sync_level set to CM_CONFIRM, but at the
partner computer, the TP definition was configured as sync_level(NONE).
- Programmer Action
- Decide what the correct sync_level should be for the
conversation. Change the local program, if necessary, so it uses the correct
sync_level. The partner's TP definition should match the
sync_level chosen by the local program.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Change the TP definition at the partner to reflect the sync_level required
by the local program.
The partner computer does not recognize the TP_name sent by
the local program.
- Explanation
- The partner computer rejected the incoming Attach because the local
program specified a TP_name that the partner LU does not recognize.
This return code can also indicate that the partner LU recognized the
TP_name, but could not start the program for some reason. This can
be caused by authorization problems. Some APPC products (like VM/ESA) check
that three things match up: LU name, mode name, and TP name. These
platforms check the incoming user_ID and password of each defined TP, and
reject the incoming Attach with this return code if the Attach is not
authorized to start a corresponding program on the partner computer.
This conversation with the partner is over. This return code will recur
until either the local program or the partner configuration is changed. CPI-C
reports this return code on a conversation call issued after an Allocate()
call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 10086021.
- Likely Causes
- This is probably a configuration problem at the partner or an incorrect
TP_name supplied to the local program. The TP_name
parameter in the partner's TP definition is one of the APPC configuration
fields that is case-sensitive. Be sure that the combination of uppercase and
lowercase letters matches those specified in the program.
For example:
- Examine the TP definition at the partner. Its TP definition may have the
TP_name spelled wrong or be using the wrong combination of
uppercase and lowercase characters. The TP_name configured at the
partner must exactly match the TP_name used by the local program.
(The TP_name sent by the local program may be set up in the local
side information file.)
- If the partner is using OS/2 Communications Manager, there may be no TP
definition that corresponds to the incoming Attach. The attach manager on the
partner computer will still attempt to start the program, using the parameters
on the DEFINE_DEFAULTS statement (if present). Assure that the correct
directory_for_inbound_attaches is specified, along with the correct
default_tp_operation and default_tp_program_type.
- If the partner is using the VM operating system, this return code will be
received if the remote VM AVS is not authorized via the "*IDENT" control
statements in VM to send information to the TP Program. This return code is
saying that there is no way to get to the TP Program on VM from OS/2.
- If the partner is using the VM operating system, this return code is
returned if an attempt was made to run the partner program in a user's
virtual machine (using a non-dedicated private gateway), and the user ID and
password were not specified correctly. User ID and password are case-sensitive
fields; be sure they are specified in uppercase if that is what the partner
expects.
- Programmer Action
- The TP_name sent to the partner is either a field configured in
the local CPI-C side information, or a parameter on a Set_TP_Name() call
issued by the local program.
- Ask the program user if the correct symbolic_destination_name
was supplied, if the TP_name was configured as part of the local
CPI-C side information.
- Assure that your program constructs the TP_name and
TP_name_length parameter correctly, if it issues a Set_TP_Name()
call. The characters in the TP_name are case sensitive.
Check the designated partner LU and mode names, as well, if required by the
partner.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- At the partner, check the list of TP names to be recognized. Assure that
they match the values supplied for the TP_name values on the
Allocate() call in the local computer.
If this checks out (that is, you find the TP correctly defined at the
partner), make sure that partner TP is correctly authorized for the user_ID
and password sent on the Attach.
The partner cannot start the program that corresponds to the
TP_name that was sent.
- Explanation
- The partner computer rejected the incoming Attach because it could not
start the program that corresponds to the TP_name it received.
Without correcting the partner's configuration or operating environment,
retrying the Allocate() call will not succeed.
This conversation with the partner is over. CPI-C reports this return code
on a conversation call issued after an Allocate() call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 084C0000.
- Likely Causes
- This is probably a configuration problem at the partner. There is a valid
TP definition at the partner for the TP_name that was sent, but the
executable program named in that TP definition could not be started. For
example:
- The intended executable program does not exist at the partner location.
- The executable program exists at the partner, but not in the drive, path,
or directory specified in the partner's TP definition.
- The executable program exists at the partner, but its name is spelled
wrong in the partner's TP definition.
- The operating system, CPI-C, or APPC software at the partner has exhausted
its available resources (such as memory, processes, queues, or threads). The
partner is unable to start the program that corresponds with the incoming
TP_name.
- If the partner is using OS/2 Communications Manager, the APPC attach
manager at the partner location may have failed to start the program due to an
OS/2 error on its internal DosExecPgm() or DosStartSession() function call.
Any of the non-zero OS/2 return codes from these function calls may be causing
this situation. For example, the partner location is using OS/2 Communications
Manager and its TP definition indicates this program is to be
attach-manager-started. If there is insufficient memory for the attach manager
to start the program, the incoming Attach will be rejected with this return
code. This could similarly occur if the partner's operating system finds
that it has consumed all of its processes or screen groups.
- Programmer Action
- None. Until the partner configuration or operating environment is
corrected, it is unlikely that this conversation can be completed.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Assure that the intended program has been defined correctly at the partner
(via the TP definition), and that it has been compiled and linked correctly
for its operating system. If the partner is logging its attach manager errors,
look at its error log for more information.
The partner cannot now start the program that corresponds to the
TP_name that was sent.
- Explanation
- The partner computer rejected the incoming Attach because it could not
start the program that corresponds to the TP_name it received.
Because of timing conditions, retrying the conversation may succeed in causing
the partner program to be started.
This conversation with the partner is over. CPI-C reports this return code
on a conversation call issued after an Allocate() call.
(An Attach is the internal message that is created when an Allocate() call
is successful. It contains the TP name to be sent to the partner, as well as
the conversation type and sync level. It also contains any conversation
security information.)
You may see this return code associated with SNA sense data 084B6031.
- Likely Causes
- This is probably a problem with the operating environment or configuration
at the partner. There is a valid TP definition at the partner for the
TP_name that was sent, but the executable program named in that TP
definition could not be started. For example:
- The APPC attach manager associated with the partner LU is stopped. In OS/2
Communications Manager, this can be caused by a missing START_ATTACH_MANAGER
statement in the Communications Manager (.NDF) node definitions file.
- The incoming_allocate_timeout defined in the TP definition at the partner
LU is 0 or is too short. This only applies if the partner TP is configured as
Queued.
- The incoming_allocate_queue_depth configured in the TP definition at the
partner LU is too small. This only applies if the partner TP is configured as
Queued.
- At the partner, the incoming Attach was queued, waiting to be processed.
The intended program was remotely started, but ended before it could process
the queued incoming Attach. For example, it had not yet issued an
Accept_Conversation() call (CMACCP).
- Programmer Action
- Retry the Attach by reissuing the Initialize_Conversation() call (CMINIT)
and Allocate() call (CMALLC). However, to avoid congesting the network with
attempted allocation requests, the local program should pause or wait for a
keystroke before retrying the conversation.
Check the Accept_Conversation() calls (CMACCP) made by the partner program.
It may be failing to make these calls correctly.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Start the APPC attach manager, increase the incoming_allocate_timeout,
increase the incoming_allocate_queue_depth in the configuration at the
partner, if appropriate.
The partner has abruptly ended the conversation.
- Explanation
- This return code is returned under one of the following conditions:
- The partner program issued a Deallocate() call (CMDEAL) with
deallocate_type set to CM_DEALLOCATE_ABEND, or the partner has done
so because of a remote program abnormal-ending condition. If the conversation
at the partner program was in Receive state when the call was
issued, information sent by the local program and not yet received by the
partner program is purged.
- The partner program terminated normally but did not deallocate the session
before terminating. The CPI-C or APPC software used by the partner deallocated
the conversation on behalf of the partner program.
This conversation with the partner is over. This return code is reported to
the local program on a call the program issues for a conversation in
Send or Receive state.
You may see this return code associated with SNA sense data 08640000.
- Likely Causes
- The partner program encountered a condition that caused it to terminate
unexpectedly, or it was stopped unexpectedly by a user. For example:
- The partner program was running on OS/2. A user terminated the partner
program using Ctrl+Break or Ctrl+C, or any of the menu options for ending
programs. OS/2's ExitList processing causes the Deallocate() call to be
issued as part of cleaning up the process.
- The partner program was processing an error, and encountered another
error. Rather than loop in its error-handling code, the partner program issued
a Deallocate() call with deallocate_type set to
CM_DEALLOCATE_ABEND.
- Programmer Action
- None.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Correct the problem encountered by the partner program.
The partner program has ended the conversation.
- Explanation
- The partner program issued a Deallocate() call (CMDEAL) with
deallocate_type set to CM_DEALLOCATE_SYNC_LEVEL or
CM_DEALLOCATE_FLUSH. If deallocate_type is
CM_DEALLOCATE_SYNC_LEVEL, the sync_level is CM_NONE.
This conversation with the partner is over. This return code is reported to
the local program on a call the program issues for a conversation in
Receive state.
- Likely Causes
- This return code generally indicates the successful completion of a
conversation.
- Programmer Action
- None.
If your program sees this return code on a Receive() call (CMRCV), it
should examine the value of the data_received parameter. Although
the conversation is over, data that the partner sent, but which not yet
received, may have been returned on the Receive() call.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- None.
The local program tried to allocate a session, using invalid parameter
names.
- Explanation
- The local program issued an Allocate() call (CMALLC) that references a
parameter containing an invalid conversation characteristic. The source of the
argument can be outside the scope of the local program, such as a field in the
CPI-C side information that is referenced by the Initialize_Conversation()
call.
The state of the conversation remains unchanged.
| Note: | Contrast this return code with the CM_PROGRAM_PARAMETER_CHECK return code,
which indicates a syntax error in a parameter.
|
- Likely Causes
- This return code indicates a parameter value that is not valid on the
local platform (for example, it has not been configured), or your program
doesn't have the correct permission level to use that specific parameter
value. This is usually a problem with the partner_LU_name, mode_name, or
TP_name being used. It means that one or more fields in the local CPI-C side
information are wrong, or a CPI-C Set call--issued after the
Initialize_Conversation(), but before the Allocate() call--contained an
invalid name. For example,
- The local program specified an all-blank symbolic destination name on its
Initialize_Conversation() call, but the program failed to issue Set calls for
the partner LU name, mode name, and TP name.
- The partner_LU_name, mode_name, or TP_name contain one or more characters
that are not valid for these names on the local computer. For example, a tilde
(~) is not a valid character in these names.
- The local program attempted to use one of APPC's special modes,
CPSVCMG CPSVRMGR, or SNASVCMG, which are not for use by application programs.
- The local program is using OS/2 Communications Manager. If you specified a
partner_LU_name without a period, in the side information or on a
Set_Partner_LU_Name() call, the Communications Manager interprets that name as
a partner_LU_alias. If that partner_LU_alias is not
configured on the local computer at the time of the Allocate() call, this
return code results.
- Programmer Action
- If the local program is using CPI-C side information via a symbolic
destination name, consider overriding the partner LU name or mode name values.
If the partner LU name or mode name was set using the Set_Partner_LU_Name() or
Set_Mode_Name() calls, consider requesting different names from the user.
You may want to consider checking the validity of the characters passed to
CPI-C in the Set_Partner_LU_Name(), Set_Mode_Name(), and Set_TP_Name() calls,
since CPI-C does no validity checking of these calls.
Receiving the return code does not invalidate the conversation ID. If you
can set different names, given input from a user, you can retry the Allocate()
call without issuing Initialize_Conversation() again.
- Operator Action
- Assure that the partner LU name, mode name, and other conversation
characteristics in the local CPI-C side information are set up properly, and
correspond to the local APPC configuration.
The local program made a CPI-C call that failed because of a
platform-related condition.
- Explanation
- An operational problem has been detected which relates to the CPI-C
product that the local program is using. A description of the error has been
written to the local CPI-C product's system error log. See the product
documentation for an indication of conditions and state changes caused by this
return code.
The state of the conversation remains unchanged.
- Likely Causes
- This return code generally indicates a problem with the underlying CPI-C
software and the environment in which it is running, not the local program.
For example:
- The underlying CPI-C or APPC software is stopped, has not been started or
is not yet fully active, or is abended.
- CPI-C is unable to allocate needed memory for its internal control blocks.
For example, no more conversation IDs are available.
- If the return code is from a call to Accept_Conversation() (CMACCP), it is
likely that the program was started locally (for example, from the command
line), but the program should have been started by the attach manager because
of an incoming Attach.
- There is a CPI-C implementation bug.
Here are some other platform-specific examples of this return code.
- On the OS/2 Communications Manager:
- If the local platform is OS/2 Communications Manager, the local TP may
have been deactivated using Subsystem Management.
If the local platform is OS/2 Communications Manager, the
APPCTPN environment variable was not set before calling
Accept_Conversation().
- On CICS/ESA:
- If the local platform is CICS/ESA, this return code results in one of the
following informational error messages:
- DFHCP0742 - the session is not available for CPI-C, as it is already in
use by another process.
- DFHCP0743 - CPI-C can not be used, as the transaction was initiated by
ATI.
- DFHCP0750 - an unrecognized profile name was supplied in the partner
resource sym_dest_name.
- On MVS/ESA:
- If the local platform is MVS/ESA, the system writes a symptom record to
SYS1.LOGREC to identify the error.
- On VM/ESA:
- If the local platform is VM/ESA, the system writes a symptom record to
CPICOMM LOGDATA to identify the error.
However, depending on the platform, there are some types of problems that
are caused by an application program. For example:
- There is a multi-tasking interference problem. One way this can occur is
for a multi-threaded program to issue more than one CPI-C call for a given
conversation at the same time.
- Programmer Action
- This return code generally indicates a problem that the local program
cannot recover from without intervention. Since the state of the conversation
generally is not changed by this call, the local program should issue a
Deallocate() call (with deallocate_type set to CM_DEALLOCATE_ABEND,
if possible) to end the conversation.
- Operator Action
- First, make sure the local CPI-C software is active. If the CPI-C software
was active when this return code occurred, check the local CPI-C
product's system error log (and related message logs) for additional
details about this problem.
CPI-C may be making calls to underlying APPC software. The details of these
calls, including their control blocks and internal return codes, provide lots
of diagnostic information. If possible, get a trace of these internal calls,
to see the return codes returned by APPC.
The partner program issued a Send_Error() call while it was in
Send state.
- Explanation
- The partner program issued a Send_Error() call (CMSERR). The partner
conversation was in Send state; the Send_Error() that it issued did
not truncate a logical record. (No truncation occurs when a program issues a
Send_Error() call before sending any logical records or after sending a
complete logical record.) The local conversation is now in Receive
state.
You may see this return code associated with SNA sense data 08890000.
- Likely Causes
- The partner program issued a Send_Error() call. The partner program
encountered a problem while it had the permission to send. This could be a
problem with the data it was sending or building, or this could be a problem
discovered by the partner program's logic.
- Programmer Action
- The local program should issue a Receive() call to receive a logical
record containing a description of the error from its partner. (This presumes
that the partner program follows the recommended practice of sending a
description of the error it has just encountered after issuing a Send_Error()
call.)
The partner program may have been designed to call Send_Error() when it
finds a bug in its own logic. Examine carefully why the partner issued
Send_Error().
- Operator Action
- The partner program generally issues a Send_Error() call when it has a
problem with its logic or the data it is handling. It may be necessary to
check the validity of the data being processed by the partner.
The partner program issued a Send_Error() call while the partner was in
Receive or Confirm state.
- Explanation
- One of the following occurred:
- The partner program issued a Send_Error() call (CMSERR) while it was in
Receive or Confirm state. The call may have caused
information enroute to the partner program to be purged (discarded), but not
necessarily.
Purging occurs when the partner program issues a Send_Error() call for a
conversation in Receive state before receiving all the information
being sent by the local program. No purging occurs when the partner program
issues a Send_Error() call for a conversation in Receive state if
the partner program has already received all the information sent by the local
program. Also, no purging occurs when the partner program issues Send_Error()
for a conversation in Confirm state.
When information is purged, the purging can occur at the local system, the
partner system, or both.
- The partner program issued a Send_Error() call. The conversation for the
partner program was in Send-Pending state. No purging of data has
occurred. This return code indicates that the partner program had the
error_direction conversation characteristic set to CM_RECEIVE_ERROR
when the Send_Error() call was made.
This return code is normally reported to the local program on a call the
program issues after sending some information to the partner program. However,
the return code can be reported on a call the program issues before sending
any information, depending on the call and when it is issued. The local
conversation is now in Receive state.
You may see this return code associated with SNA sense data 08890000.
- Likely Causes
- The partner program issued a Send_Error() call. The partner program
encountered a problem while the local program had the permission to send. This
could be a problem with the data the partner was receiving or parsing, or this
could be a problem discovered by the partner program's logic.
This can also indicate a "race" condition, where both programs issued
a Send_Error() call at the same time. The local program lost the race.
- Programmer Action
- The local program should issue a Receive() call, to receive a logical
record containing a description of the error from its partner. (This presumes
that the partner program follows the recommended practice of sending a
description of the error it has just encountered after issuing a Send_Error()
call.)
The partner program may have been designed to call Send_Error() when it
finds a bug in its own logic. Examine carefully why the partner issued
Send_Error().
- Operator Action
- The partner program generally issues a Send_Error() call when it has a
problem with its logic or the data it is handling. It may be necessary to
check the validity of the data being processed by the partner.
The partner program issued a Send_Error() call for a basic
conversation, truncating a logical record it was sending.
- Explanation
- The partner program issued a Send_Error() call (CMSERR) while in
Send state, and the Send_Error() truncated a logical record.
Truncation occurs when a program begins sending a logical record and then
issues a Send_Error() call before sending the complete logical record.
CPI-C reports this return code to the local program on a Receive() call
(CMRCV), after receiving the initial portion of the truncated logical record.
The local conversation remains in Receive state.
This return code is returned for basic conversations only.
You may see this return code associated with SNA sense data 08890001.
- Likely Causes
- The partner program issued a Send_Error() call. The partner program was in
the middle of sending a logical record, and it encountered a problem. This
could be a problem with the data or a problem discovered by the partner
program's logic.
- Programmer Action
- The local program should issue a Receive() call to receive a logical
record containing a description of the error from its partner. (This presumes
that the partner program follows the recommended practice of sending a
description of the error it has just encountered after issuing a Send_Error()
call.)
The partner program may have been designed to call Send_Error() when it
finds a bug in its own logic. Examine carefully why the partner issued
Send_Error().
- Operator Action
- The partner program generally issues a Send_Error() call when it has a
problem with its logic or the data it is handling. It may be necessary to
check the validity of the data being processed by the partner.
The local program called CPI-C with an invalid parameter.
- Explanation
- The local program issued a CPI-C call with an error in one or more
parameters. ("Parameters" include not only the parameters described as
part of the call syntax, but also the CPI-C conversation characteristics
associated with the conversation_ID.)
If the return code is from a call to Initialize_Conversation() (CMINIT), it
is likely that the symbolic destination name supplied by the user was spelled
wrong, or the name has not been configured in the local CPI-C side
information.
The source of the error is considered to be under the control of the local
program. This return code may be caused by the failure of the program to pass
a valid parameter address. The program should not examine any other returned
variables associated with the call.
The state of the conversation remains unchanged.
- Likely Causes
- This can be caused by any incorrect parameter. All parameters passed to
CPI-C must be valid pointers to variable fields of the proper length. Other
examples of parameter errors are:
- Programmer Action
- If your program gets its symbolic destination name from a user or an input
file, it is likely that this return code is because of an error related to
that name. Assure the proper combination of upper and lower case letters,
numbers, and symbols (many platforms allow only uppercase letters and
numbers). Also, have the user check to see that the symbolic destination name
they provided is actually configured on the local computer in the CPI-C side
information.
For any call other than Initialize_Conversation(), this return code
indicates a bug or logic defect in the local program. Design your program so
that users only see this return code when there is a bug to be reported and
fixed. For example, do validity and range checking on length values before
making CPI-C calls to diagnose potential problems,
Find the CPI-C call that failed, and carefully check the syntax of each
parameter that is being supplied. Assure that all parameters are valid
pointers to valid fields, and that each of these fields has the proper size
and value.
- Operator Action
- Check that the symbolic destination name that was used is configured in
the local CPI-C side information. Also, assure that the symbolic destination
supplied to the local program was spelled correctly, and used the correct
combination of upper and lower case letters and numbers.
Otherwise, report this as a bug to the supplier of the program.
The local program called CPI-C with the wrong call at this time.
- Explanation
- This return code is returned under one of the following conditions:
- The local program issued a CPI-C call in a conversation state that was not
valid for that call.
- The local program issued a Wait_For_Conversation() call, and there were no
outstanding operations for any conversations known to the local program.
- For a conversation with sync_level set to CM_SYNC_POINT, the
conversation's context is in the Backout-Required condition.
The call issued is not allowed for this conversation while its context is in
this condition.
The state of the conversation remains unchanged.
- Likely Causes
- For production-level (debugged) programs, this is usually caused when the
wrong two programs are talking to one another. At the initiating side, this
may be caused because the wrong symbolic destination name is specified by the
initiating program. Similarly, the partner LU name or the TP name may be
wrong. At the target side, TP definition may specify the wrong program to be
started.
If your program has issued the Wait_For_Conversation() call, this return
code should be handled as part of the mainline program logic. There were no
conversations with outstanding calls on which to wait for completion.
Otherwise, this return code indicates a bug or logic defect in the local
program. This generally occurs when CPI-C calls are issued in the wrong order,
or when interactions with the partner program have been overlooked. For
example:
- The Set_Mode_Name() call is only valid in Initialize state,
that is, after issuing Initialize_Conversation() but before issuing
Allocate(). If it is issued after Allocate() or Accept_Conversation(), CPI-C
returns this return code.
- After receiving a return code that indicates the partner program has
issued a Send_Error() call (for example, CM_PROGRAM_ERROR_NO_TRUNC or
CM_PROGRAM_ERROR_PURGING), the local program is in Receive state.
It can only issue CPI-C calls that are valid in Receive state.
- On the OS/2 Communications Manager
- This return code is also returned on an Accept_Conversation() call for the
following reasons:
- The operator or program set a TP name in the APPCTPN
environment variable that was incorrect, that is, it did not match the TP name
on the incoming Attach.
- An operator-started program issued an Accept_Conversation() call, but the
call expired before the incoming Attach arrived. The duration that a call
waits for an incoming Attach is configured on the TP definition, using the
receive_allocate_timeout field.
- Programmer Action
- This is readily caused when the user of the initiating program specifies a
valid, but wrong, symbolic destination name, which caused this program to be
erroneously started. Convey the probable program mismatch to the
program's user, and end the program using a Deallocate() call with
deallocate_type set to CM_DEALLOCATE_ABEND.
If your program sees this on a Wait_For_Conversation() call, it should
handle it as an expected return code. It means that there were no outstanding
operations on any conversation. This can easily occur when all the
conversations are using blocking mode, that is, their
processing_mode conversation characteristic is set to the default
value of CM_BLOCKING.
Otherwise, users of your program should never see this return code; to
users, this return code indicates a bug. The program should report to its user
that a bug has been encountered, and log the bug. The program should not
examine any other returned variables associated with the call.
The conversation ID for this conversation is still valid. The local program
can find the current state of the conversation by issuing the CPI-C
Extract_Conversation_State() call. Refer to a CPI-C reference manual for a
list of calls that are allowed in each conversation state.
- Operator Action
- Assure that the TP definition at the target computer specifies the correct
program to be started for the arriving TP name. Also, assure that the program
on the initiating side has obtained the correct symbolic destination name, and
that the side information for that entry is correct.
Otherwise, report this as a bug to the supplier of the local program.
The active conversation has been unexpectedly ended, and starting it
again probably will fail.
- Explanation
- A permanent failure prematurely ended the conversation. The condition is
not temporary; operator intervention is required to correct the problem.
This conversation with the partner is over. This return code can be
reported to the local program on a call it issues for a conversation in any
state other than Reset or Initialize.
- Likely Causes
- The session or link used to get to the partner has been broken, or the
partner program was abruptly stopped. For example:
- The local and partner LUs have been disconnected from each other. The link
or session has been abruptly terminated.
- The partner program was deactivated while it was running. For example, if
the partner is using OS/2 Communications Manager, this can be done using
Communications Manager Subsystem Management.
- The partner computer may have violated internal SNA protocols.
- Programmer Action
- Without human intervention, the conversation probably cannot be
successfully restarted.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Examine any platform-related message logs and error logs at both locations
to find more information about this problem. Look for equipment failures or
setup problems related to the network components and the computers using them.
Fix the problem, as indicated by any SNA sense data associated with this call.
You may need to run the applications again with SNA tracing activated to get
the sense data.
After correcting the problem, try running the pair of programs again, if
appropriate.
The active conversation has been unexpectedly ended, and starting it
again may be successful.
- Explanation
- A temporary failure prematurely ended the conversation.
This conversation with the partner is over. This return code can be
reported to the local program on a call it issues for a conversation in any
state other than Reset or Initialize.
- Likely Causes
- Some aspect of the partner computer, needed for CPI-C communication, has
been deactivated. Here are some examples of how this return code is caused.
- The partner computer was powered off or re-booted during the conversation.
- The partner computer stopped or unloaded its APPC software during the
conversation.
- The partner computer deactivated its data link control (DLC) during the
conversation.
- The local or partner LU deactivated the session in the middle of a
conversation. In OS/2, for example, this can be done using Communications
Manager Subsystem Management or issuing the CNOS verb.
- The local LU was notified of a session outage occurring in the network.
- Programmer Action
- The local program should attempt to allocate a session again. It is
possible for some permanent failures to be initially reported as temporary,
but the allocation of subsequent conversations would also fail.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- Examine any platform-related message logs and error logs at both locations
to find more information about this problem. Look for equipment failures or
setup problems related to the network components and the computers using them.
Fix the problem, as indicated by any SNA sense data associated with this call.
You may need to run the applications again with SNA tracing activated to get
the sense data.
After correcting the problem, try running the pair of programs again, if
appropriate.
The local program made a CPI-C call that could not complete its
requested function.
- Explanation
- There are three CPI-C calls that can fail to complete their desired
function when they are issued, but may succeed if issued later. For these
three calls, this return code should be handled as part of the mainline
program logic.
The state of the conversation remains unchanged.
- Likely Causes
- This return code has different meanings, depending on whether the CPI-C
call that was issued was Allocate(), Receive(), or Test_Request_To_Send().
- For an Allocate() call (CMALLC) with return_control(CM_IMMEDIATE), CPI-C
could not obtain a contention-winner session to the partner computer, using
the requested mode name.
- For a Receive() call (CMRCV) with receive_type set to
CM_RECEIVE_IMMEDIATE, there is no data to receive, and the status_received
value hasn't changed since the last Receive().
- For a Test_Request_To_Send() call (CMTRTS), no request-to-send signal has
been received from the partner since the last time the program checked for the
signal.
- Programmer Action
- The requested call was unable to complete the function that was requested,
but no explicit action is required. Retry the call as appropriate. If you are
issuing these calls in a programmed loop, consider pausing slightly within the
loop, to avoid hard CPU usage (thus allowing other programs a chance to run).
- Operator Action
- If this return code is returned on an Allocate() call, it may indicate
that there are a large number of simultaneous sessions between this computer
and its partner using the same mode. These sessions might be spread among many
programs that are running at the same time. Consider changing the mode
definition on both computers for the mode name in question, so it has more
contention-winner sessions available concurrently.
The partner program was abnormally terminated, or it ended the
conversation abnormally by issuing a Deallocate() call.
- Explanation
- This return code is returned under one of the following conditions:
- The partner program, using a native APPC (LU 6.2) application
programming interface and not using CPI-C, issued a DEALLOCATE verb specifying
a TYPE parameter of ABEND_SVC. If the conversation for the partner program was
in Receive state when the verb was issued, information sent by the
local program and not yet received by the partner program is purged.
- The partner program either terminated abnormally or terminated normally
but did not deallocate the conversation before terminating. The CPI-C or APPC
software used by the partner deallocated the conversation on behalf of the
partner program.
This return code is returned for basic conversations only.
This conversation with the partner is over. This return code is reported to
the local program on a call the program issues for a conversation in
Send or Receive state.
You may see this return code associated with SNA sense data 08640000.
- Likely Causes
- Here are some examples of how this return code is caused.
- If the partner program is running on OS/2, this return code is seen
locally if the partner program ended unexpectedly because of a protection
fault.
- If the partner program is running on the AS/400, this return code reports
the absence of a valid routing entry in a subsystem. If no specific subsystem
device or remote location name has been entered, check to see if the subsystem
QCMN is active. If QCMN is active, be sure the routing entry for APPC programs
(PGMEVOKE) is present in the subsystem. If a subsystem other than QCMN is
being used and a specific communications entry or remote location name entry
is being used, be sure a routing entry with PGMEVOKE is specified in the same
subsystem. In both cases, the fix is to add a routing entry in a subsystem.
- Programmer Action
- None.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- None.
The partner program ended the conversation abnormally by issuing a
Deallocate() call.
- Explanation
- The remote APPC transaction program issued a DEALLOCATE verb specifying a
TYPE parameter of ABEND_TIMER. If the local conversation was in
Receive state when the verb was issued, information sent by the
local program and not yet received by the remote program is purged.
This return code is returned for basic conversations only. In addition, it
is returned only when the remote transaction program is using a native APPC
(LU 6.2) application programming interface and is not using CPI-C.
This conversation with the partner is over. This return code is reported to
the local program on a call the program issues for a conversation in
Send or Receive state.
- Likely Causes
- The partner program encountered a condition that caused it to choose to
terminate abnormally.
- Programmer Action
- None.
The conversation is now in Reset state; the
conversation_ID that was supplied in this CPI-C call is no longer
valid.
- Operator Action
- None.
The partner program issued a Send_Error() call while it was in
Send state.
- Explanation
- The partner program issued a Send_Error() call with a TYPE parameter of
SVC. The partner conversation was in Send state; the Send_Error()
that it issued did not truncate a logical record. (No truncation occurs when a
program issues a Send_Error() call before sending any logical records or after
sending a complete logical record.) The local conversation is now in
Receive state.
This return code is returned for basic conversations only. In addition, it
is returned only when the remote transaction program is using a native APPC
(LU 6.2) application programming interface and is not using CPI-C.
You may see this return code associated with SNA sense data 08890100.
- Likely Causes
- The partner program encountered a problem while it had the permission to
send. This could be a problem with the data it was sending or building, or
this could be a problem discovered by the partner program's logic.
- Programmer Action
- The local program should issue a Receive() call to receive a logical
record containing a description of the error from its partner. (This presumes
that the partner program follows the recommended practice of sending a
description of the error it has just encountered after issuing a Send_Error()
call.)
The partner program may have been designed to call Send_Error() when it
finds a bug in its own logic. Examine carefully why the partner issued
Send_Error().
- Operator Action
- The partner program generally issues a Send_Error() call when it has a
problem with its logic or the data it is handling. It may be necessary to
check the validity of the data being processed by the partner.
The partner program issued a Send_Error() call while it was in
Receive or Confirm state.
- Explanation
- One of the following occurred:
- The partner program issued a Send_Error() call with a TYPE parameter of
SVC. The conversation for the partner program was in Receive or
Confirm state. The call may have caused information enroute to the
partner program to be purged (discarded), but not necessarily.
Purging occurs when the partner program issues a Send_Error() call for a
conversation in Receive state before receiving all the information
being sent by the local program. No purging occurs when the partner program
issues a Send_Error() call for a conversation in Receive state if
the partner program has already received all the information sent by the local
program. Also, no purging occurs when the partner program issues Send_Error()
for a conversation in Confirm state.
When information is purged, the purging can occur at the local system, the
partner system, or both.
- The partner program issued a Send_Error() call with a TYPE parameter of
SVC. The conversation for the partner program was in Send-Pending
state. No purging of data has occurred. This return code indicates that the
partner program had an error_direction characteristic set to
CM_RECEIVE_ERROR when the Send_Error() call was made.
This return code is normally reported to the local program on a call the
program issues after sending some information to the partner program. However,
the return code can be reported on a call the program issues before sending
any information, depending on the call and when it is issued. The local
conversation is now in Receive state.
This return code is returned for basic conversations only. In addition, it
is returned only when the remote transaction program is using a native APPC
(LU 6.2) application programming interface and is not using CPI-C.
You may see this return code associated with SNA sense data 08890100.
- Likely Causes
- The partner program encountered a problem while the local program had the
permission to send. This could be a problem with the data it was receiving or
parsing, or this could be a problem discovered by the partner program's
logic.
- Programmer Action
- The local program should issue a Receive() call, to receive a logical
record containing a description of the error from its partner. (This presumes
that the partner program follows the recommended practice of sending a
description of the error it has just encountered after issuing a Send_Error()
call.)
The partner program may have been designed to call Send_Error() when it
finds a bug in its own logic. Examine carefully why the partner issued
Send_Error().
- Operator Action
- The partner program generally issues a Send_Error() call when it has a
problem with its logic or the data it is handling. It may be necessary to
check the validity of the data being processed by the partner.
The partner program issued a Send_Error() call for a basic
conversation, truncating a logical record it was sending.
- Explanation
- The partner program issued a Send_Error() call with a TYPE parameter of
SVC. The conversation for the partner program was in Send state.
The Send_Error() truncated a logical record. Truncation occurs when a program
begins sending a logical record and then issues a Send_Error() call before
sending the complete logical record.
CPI-C reports this return code to the local program on a Receive() call,
after receiving the initial portion of the truncated logical record. The local
conversation remains in Receive state.
This return code is returned for basic conversations only. In addition, it
is returned only when the remote transaction program is using a native APPC
(LU 6.2) application programming interface and is not using CPI-C.
You may see this return code associated with SNA sense data 08890101.
- Likely Causes
- The partner program was in the middle of sending a logical record, and it
encountered a problem. This could be a problem with the data or a problem
discovered by the partner program's logic.
- Programmer Action
- The local program should issue a Receive() call to receive a logical
record containing a description of the error from its partner. (This presumes
that the partner program follows the recommended practice of sending a
description of the error it has just encountered after issuing a Send_Error()
call.)
The partner program may have been designed to call Send_Error() when it
finds a bug in its own logic. Examine carefully why the partner issued
Send_Error().
- Operator Action
- The partner program generally issues a Send_Error() call when it has a
problem with its logic or the data it is handling. It may be necessary to
check the validity of the data being processed by the partner.
The local program issued a CPI-C call that has not yet completed.
- Explanation
- A non-blocking operation has been started on the conversation but is not
complete. This return code is returned when processing_mode is set
to CM_NON_BLOCKING for the conversation and the call is suspended waiting for
incoming data, buffers, or other resources. A program must use the
Wait_For_Conversation() call to wait for the operation to complete and to
retrieve the return code for the completed operation.
The state of the conversation remains unchanged.
- Likely Causes
- This is an "expected" return code. If your program is using
non-blocking processing mode, this return code may be returned on any CPI-C
call. Your program requested that CPI-C return immediately on each call, even
if they have not completed. This is the return code your program sees is the
call has not completed. For example:
- Your program issued a Receive() call with the receive_type set
to CM_RECEIVE_AND_WAIT, and there is nothing yet to receive.
- Your program issued a Send_Data() call and the internal buffers are full
and have not yet been sent.
- Programmer Action
- This return code should be handled as part of the mainline program logic
for programs that issue non-blocking calls. The local program was presumably
designed to use non-blocking processing mode so that it could do other work
rather than waiting on the completion of CPI-C calls. Your program should do
whatever work it has available to do, then come back to this conversation and
issue a Wait_For_Conversation() call.
- Operator Action
- None.
A platform-specific event has canceled a Wait_For_Conversation() call
issued by the local program.
- Explanation
- A CPI-C Wait_For_Conversation() call was being executed by the local
program when an event (such as a signal) occurred. This event was handled by
the local program. Wait_For_Conversation() returns this return code to allow
the program to reissue the Wait_For_Conversation() call or to perform other
processing. It is the responsibility of the event-handling portion of the
local program to capture sufficient information for the program to decide how
to proceed when it sees this return code.
The state of the conversation remains unchanged.
- Likely Causes
- The local platform or product has determined that there is an event that
your local program should handle. For example, keyboard input must be captured
before continuing with a CPI-C Receive() call.
- Programmer Action
- Handle the interrupt raised by the local platform (in a product-specific
manner), then issue a Wait_For_Conversation() call again.
- Operator Action
- All system-related events that cause this return code should be handled by
the local program. When the local program cannot handle or repair an
event-related condition, operator intervention may be required.
The local program made a CPI-C call while a previously-issued CPI-C
call had not yet completed.
- Explanation
- A previous CPI-C call on this conversation is incomplete. This return code
is returned when there is an outstanding operation on the conversation, as
indicated by the CM_OPERATION_INCOMPLETE return code to a previous call. On an
operating system that supports multiple program threads, when one thread has
started an operation that has not completed, this return code may be returned
on a call made by another thread on the same conversation.
The state of the conversation remains unchanged.
- Likely Causes
- The local program issued a CPI-C call when another had not yet completed.
This is a bug in the design or coding of the local program.
- Programmer Action
- This return code indicates a bug or logic defect in the local program.
Users of your program should not see this return code; to users, this return
code signals a bug to be reported and fixed.
- Operator Action
- Report this as a bug to the supplier of the local program.
[ Top of Page | Previous Page | Next Page | Table of Contents ]
[ DB2 List of Books |
Search the DB2 Books ]