This category indicates that the RU was delivered to the intended network addressable unit (NAU) component, but could not be interpreted or processed. This condition represents a mismatch of NAU Capabilities.
Explanation: Data in the request RU is not acceptable to the receiving component. For example, a character code is not in the set supported, a formatted data field is not acceptable to presentation services, or a value specified in the length field (LL) of a structured field is invalid.
Bytes 2 and 3 following the sense code contain sense-code-specific information:
No specific code applies.
Isolated Pacing Message (IPM) Format Error. An incorrectly formatted IPM was received.
A BIND request was received that was not for LU 6.2 and not in extended format. The BIND request is rejected.
Unable to Extend BIND Request. An attempt made to add control vectors to a BIND request would have exceeded the maximum BIND length. The BIND is rejected.
Explanation: The request RU was too long or too short.
Indicates that no specific code applies.
Explanation: The function requested is not supported. The function may have been specified by a formatted request code, a field in an RU, or a control character.
Bytes 2 and 3 following the sense code contain sense-code-specific information:
No specific code applies.
The function identified in the request is not supported by the processing application transaction program.
Cryptography is not supported, but a non-zero length was specified for the cryptography key.
Mismatch between the session initiation request type and the LU type (independent or dependent).
This can occur if a local LU (defined as an independent LU) attempts to connect to a partner LU that is incorrectly defined as a dependent LU in the subarea node. There are other causes, but in every case, the cause involves a "session initiation type mismatch". Your LU used dependent LU session initiation protocols (ACTLU, INIT_SELF) and the partner was expecting independent LU protocols, or your LU used independent LU session initiation protocols (BIND) and the partner expected dependent LU protocols.
Here are some examples:
Answer: In your VTAM PU definition, is the PU name the same as the control point name? Because a PU is a VTAM resource, its name cannot match other resource names, such as LU names or control point names. Versions of VTAM before V4R1 assume that a workstation PU is not an LU. If a PU tries to send a BIND, VTAM rejects it with sense data X'10030021'.
To fix your problem, make sure the PU name is different from the control point name on your VTAM PU definition. If you are not using the dynamic LU (DYNLU) feature of VTAM V3R4, add an LU definition in which the LU name matches the control point name.
Example: PU and LU definitions for a workstation attached to a token-ring:
LINK0001 PU ADDR=13,
CPNAME=CPNM0001,
PUTYPE=2,
DSCNT=NO
CPNM0001 LU LOCADDR=0, MODETAB=MODAPPN
BIND Received by an APPN end node which is not destination. A BIND was received which contained an Route Selection control vector (RSCV) specifying a destination other than this node. As this node is configured as an APPN end node, the BIND is rejected.
Explanation: A parameter modifying a control function is invalid, or outside the range allowed by the receiver.
Explanation: DFC, SC, NC, or FMD request was received by a half-session not supporting any requests in that category; or an NS request byte 0 was not set to a defined value, or byte 1 was not set to an NS category supported by the receiver.
Explanation: The FM header was not understood or translatable by the receiver, or an FM header was expected but not present. For LU 6.2, this sense code is sent in FMH-7 or UNBIND.
Bytes 2 and 3 following the sense code contain sense-code-specific information:
Invalid Concatenation Indicator. The concatenation indicator is on, but concatenation is not allowed.
FM Header and Associated Data Mismatch. The FM header indicated associated data would or would not follow (for example, FM header 7 followed by log data, or FM header 5 followed by program initialization parameters), but this indication was in error; or a previously received RU (for example, -RSP(X'0846')) implied that an FM header would follow, but none was received.
Invalid FM Header Type for this LU. The type of the FM header is other than 5, 7, or 12.
FM Header Length Not Correct. The value in the FM header Length field differs from the sum of the lengths of the subfields of the FM header.
Access Security Information Length Field Not Correct. The value in the Access Security Information Length field differs from the sum of the lengths of the Access Security Information subfields.
Invalid Parameter Length. The field that specifies the length of fixed-length parameters has an invalid setting.
Unrecognized FM Header Command Code. The partner LU received an FM header command code that it does not recognize. For LU 6.2, this sense data is sent only in FMH-7.
Invalid Logical Unit of Work (LUW). The LUW Length field (in a Compare States generalized data stream (GDS) variable or an FMH-5) is incorrect, or the length field is invalid, or an LUW ID is not present but is required by the setting of the synchronization level field.
Transaction Program Name Not Recognized. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies a transaction program name that the receiver does not recognize. This sense data is sent only in FMH-7.
The partner LU rejected the incoming Attach because the local transaction program specified a TP name that the partner LU does not recognize.
This sense data can also indicate that the partner LU recognized the TP name, but could not start the program. One reason for this may be authorization problems. Some implementations of APPC (such as VM) check that three things match up: LU name, mode name, and TP name. These computers check the incoming user_id and password of each specific TP, and reject the Attach with this sense data if your program is not authorized to start the corresponding program on the remote computer.
Examples:
The TP name field in the TP definition is one of the few APPC configuration fields that is case-sensitive. Be sure that the combination of uppercase and lowercase letters matches those specified in the program.
Programmer Response: Check the validity of the TP name, and the designated partner LU and mode names.
Operator Response: On the remote computer, check the list of TP names to be recognized. Ensure 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, the partner TP is correctly defined on the remote computer), make sure the remote TP is properly authorized for the user_id and password sent on the Attach.
PIP Not Allowed. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies program initialization parameter (PIP) data, but the receiver does not support PIP data for the specified transaction program. This sense data is sent only in FMH-7.
Explanation: The partner LU rejected the Attach because the local transaction program specified program initialization parameters (PIP data) and either the partner LU does not support PIP data or the partner transaction program has no PIP variables defined.
Programmer Response: Do not use PIP data when communicating with this remote transaction program. For example, APPC on the OS/2 Communications Manager does not accept incoming PIP data.
PIP Not Specified Correctly. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies a transaction program name that requires program initialization parameter (PIP) data, and either the FMH-5 specifies PIP data is not present or the number of PIP subfields present does not agree with the number required for the program. This sense data is sent only in FMH-7.
Explanation: The partner LU rejected the incoming Attach because the partner transaction program has one or more PIP variables defined and either the local transaction program has specified that no PIP variables are to be used, or the number of PIP variables defined by the local transaction program is different from the number specified by the remote transaction program.
Programmer Response: Specify that PIP data is to be used in the Allocate call, and make sure that the number of PIP variables agrees with the number required by the remote transaction program.
Conversation Type Mismatch. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies a conversation type that the receiver does not support for the specified transaction program. This sense data is sent only in FMH-7.
Explanation: The partner LU rejected the incoming Attach because it or the partner transaction program does not support the specified conversation type.
Programmer Response: Change the transaction program so it uses the proper conversation type (basic or mapped).
Operator Response: Alternatively, have the TP definition partner changed to reflect the conversation type used by the program.
Invalid Attach Parameter. An Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies a parameter that conflicts with the statement of LU capability previously provided in the BIND negotiation.
Synchronization Level Not Supported. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies a synchronization level that the receiver does not support for the specified transaction program. This sense data is sent only in FMH-7.
Explanation: The partner LU rejected the incoming Attach because the local transaction program specified an unacceptable sync_level parameter. For example, the local transaction program issued an Allocate call with sync_level(CONFIRM), but at the remote computer it was configured as sync_level(NONE).
Programmer Response: Change the sync_level parameter on the Allocate call.
Operator Response: Alternatively, have the TP definition at the partner changed to reflect the sync_level used by the local transaction program.
Reconnection Not Supported. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies reconnection support but the receiver does not support reconnection for the specified transaction program. This sense data is sent only in FMH-7.
Unable to Reconnect Transaction Program--No Retry. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies the conversation correlator of a transaction program to which the receiver cannot reconnect. The condition is not temporary. This sense data is sent only in FMH-7.
Unable to Reconnect Transaction Program--Retry Allowed. The Attach request (FMH-5) -- sent because of an Allocate by the local program -- specifies the conversation correlator of a transaction program to which the receiver cannot reconnect. The condition is temporary. This sense data is sent only in FMH-7.
Explanation: An error was detected during an APPN directory search or CP Capabilities exchange processing.
Bytes 2 and 3 following the sense code contain sense-code-specific information:
Unrecoverable error, such as a duplicate control vector, was detected. This can be caused when another computer is using your control point LU name (CP LU), and has registered it with your network node (NN) server.
A broadcast search resulted in two or more conflicting positive replies that differ on the control point (CP) owning the target resource. Multiple positive replies are acceptable, as long as all indicate the same owning CP.
Unrecoverable error on CP Capabilities GDS variable exchange prevented its initiation or completion on a contention-winner CP-CP session.
Length error in CP Capabilities generalized data stream (GDS) variable.
Identifier error in CP Capabilities GDS variable.
Incomplete negative or neutral reply received on a search, or reservation indicated on Broadcast, or "All" specified on a directed search.
Length error in CD-Initiate GDS variable.
No CD-Initiate (CDINIT) generalized data stream (GDS) variable returned on a search request.
Session polarity or initiate type value received in CD-Initiate (CDINIT) generalized data stream (GDS) variable not supported.
Mode name length error in CD-Initiate GDS variable.
Find generalized data stream (GDS) variable not present on Locate search request.
Command Parameters (X'80') control vector not present on Found generalized data stream (GDS) variable.
Explanation: An error was detected on one of the following generalized data stream (GDS) variables: Locate, Find, Found, CDINIT, Register, or Delete.
Bytes 2 and 3 following the sense code contain sense-code-specific information:
Missing Associated Resource Entry (X'3C') control vector.
Missing Directory Entry (X'3D') control vector.
Invalid control vector.
Conflicting APPN directory entry or invalid Associated Resource Entry (X'3C') control vector.
No Route Selection control vector (RSCV) was received from an APPN network node server.
No COS/TPF control vector received from an APPN network node server.
TG vectors not present in a CD-Initiate (CDINIT) GDS variable from an APPN end node OLU or DLU.
Missing Search Argument Directory Entry (X'82') control vector on Find.
A Found from an APPN end node indicated the directory entry for a located resource was a wildcard entry.
Explanation: The XID3 was too long or too short.
Too few bytes in XID3.
The length specified in the Length field in the XID3 is different from the number of bytes received. There is a mismatch between the number of bytes specified in the Length field of XID3 and the actual length of the received XID3.
Explanation: Data in the XID3 is not acceptable to the receiving component because the value in the received XID3 field, whose byte and bit offset is specified by the XID Negotiation Error (X'22') control vector (which also carries this sense code), is inconsistent with the corresponding field in the sent XID3.
Bytes 2 and 3 following the sense code contain sense-code-specific information:
The field in the received XID3 that specifies the Maximum number of I-frames that the sender can receive before acknowledgment is set to zero.
The adjacent node has been inconsistent in its request for ACTPU. In a nonactivation XID3 exchange, it has changed the value of the ACTPU Suppression indicator sent in the previous XID3 exchange.
The field in the received XID3 that specifies the maximum basic transmission unit (BTU) length that the sender can receive is set to less than 99 bytes, which is the minimum required.
The received XID was not XID format 3 when XID format 3 was expected.
The adjacent node does not support BIND segment generation but does support receipt of BIND segments. Any Type 2.1 node supporting receipt of BIND segments must also support generation of BIND segments.
The adjacent node is an APPN end node, does not support BIND segment receipt, and has a maximum basic transmission unit (BTU) size of less than 265, the minimum required here.
Here's an anecdote: "I ran and formatted an OS/2 Communications Manager trace at the OS/2 network node and discovered that the NN was receiving a Sense data X'10160006'. I looked it up, and found out that the Macintosh SNA*ps 5250 was using a maximum BTU size of less than 265 (the minimum) and that the XID of the partner should be the NN instead of the AS/400. I increased the size and changed the XID and everything works fine now".
The adjacent node is an APPN network node, does not support BIND segment receipt, and has a maximum basic transmission unit (BTU) size of less than 521, the minimum size required here.
The adjacent node has changed from an APPN network node to an end node, or vice versa.
The adjacent node is an APPN network node, does not provide control point (CP) services, and supports CP-CP sessions on this TG, a combination not allowed.
During a nonactivation XID exchange, the adjacent node has changed the TG number that was negotiated during the link activation exchange.
The adjacent node is the TG number negotiation winner and designates a TG number that the receiving node cannot allocate to this connection. When parallel TGs are supported between the two nodes, 0 is always such a number.
The adjacent node is an APPN network node that does not support BIND segment generation, and this node's maximum basic transmission unit (BTU) size is less than 521.
Operator response: Increase the node BTU size to at least 521.
The adjacent node is does not support the SDLC command response profile.
Operator response: The only defined value for this profile is X'0'. Make sure that the platform correctly sets that value (bits 4-7 of byte 12 of the XID).
Two different Product Set ID (X'10') control vectors have been received from the adjacent node.
Operator response: There can be only one provided on the XID. Verify that the platform specifies only one Product Set ID on the XID.
The link station roles specified in the sent and received negotiation-proceeding XID3s are not compatible. To activate a connection, one node must contain a primary link station; the other, a secondary link station.
The support of combined asynchronous balanced mode (ABM) link stations indicated in the sent and received negotiation proceeding XID3s is not in agreement.
This can occur for one of the following reasons:
(Retired)
The adjacent node has sent the Network Name (X'0E', CP name) control vector, but does not support the Exchange State indicators.
The DLC Type field in the sent and received XID3s are not the same.
The adjacent NRM link station sent an XID3, indicating that it contains a negotiable link station, after having indicated that it contained a link station with a nonnegotiable role.
The adjacent node supports adaptive BIND pacing as a sender, but not as a receiver.
The local node is attempting to activate a TG with a predefined number, but the adjacent node has attempted to use a non-zero number that is different from the one the local node used to represent the TG.
After two negotiation proceeding XID exchanges, two negotiable link stations still have equal values in the Node Identification fields of their XID3s.
The adjacent node is an APPN node but does not support adaptive BIND pacing as a sender and receiver.
On two different TGs, the adjacent node has been inconsistent in its support of parallel TGs.
The adjacent node provides or requests CP services, but does not support CP-CP sessions on this TG.
The adjacent node sent a reserved value in the XID3 field defining its link station role.
The adjacent node has only two-way alternating transmit-receive capability, but the local node supports only two-way simultaneous.
The adjacent node does not include the Network Node (X'0E', CP name) control vector in its XID3, but indicates support of CP-CP sessions.
The value sent in the Type of the XID Sending Node in XID3 indicates a node type with which the receiving node cannot activate a TG, for example, Type 2.1 nodes cannot activate TGs with Type 1 nodes.
Explanation: A control vector was found containing a key that was invalid for the position of the control vector within a Topology Database Update (TDU).