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 ]