NS3000/iX Error Messages Reference Manual (36923-90041)

376 Chapter19
Logging Location Codes
Control Process Logging Location Codes
ACTION: The new request message has probably been lost, and
depending on the purpose of message, whatever module sent it may be
expecting a reply which will never come, so that module or session may
now be hung. For debugging purposes the message content was logged
in the NM logfile along with this error, which may aid in debugging any
hung modules. Check for other errors, and also check for Path Verify
storms by first enabling Class-5 Transport console logging in
NMCONFIG, then restarting Transport and retrying the operations.
Depending on the meaning of the error status PARM, the NETCP port
may have run out of message frames, in which case a system failure
may occur soon, though stopping and restarting Transport may be
possible, and may clear the problem until next time. See Appendix A,
“Submitting an SR,” of this manual.
MESSAGE: INTERNAL ERROR; Bad/unknown port message
678 CLAS0002 CAUSE: While awaiting Path Verify replies from all general protocols in
response to multiple requests it sent previously, NETCP received a new
message on the reply subqueue of its port that either was not a reply or
whose length was not right for a reply (PARM.(0:16) = function code and
PARM.(16:16) = interface code of received message).
ACTION: This error may be followed by a timeout of up to 15 seconds,
which is normal. Possibly some module on the system sent a message to
the wrong place, and because whatever module sent it could be
expecting a reply which will never come, that module may now be hung.
Possibly one of NETCP’s previous reply waits timed out, but the
offending module has now decided to reply. For debugging purposes the
message content was logged in the NM logfile along with this error,
which may aid in debugging any hung modules. If the received message
looks like a Path Verify reply, there is a message length bug in the
general protocol module which sent it; this is not serious though it may
result in error 629 later. If the problem occurs repeatedly or a general
protocol bug is suspected, update to the latest Transport patches, and if
this does not solve the problem either, see Appendix A, “Submitting an
SR,” of this manual.
MESSAGE: INTERNAL ERROR; Bad/unknown port message
679 CLAS0002 CAUSE: While awaiting Path Verify replies from all general protocols in
response to multiple requests it sent previously, NETCP received a
message that was indeed a reply, but the function code in the message
was not the expected value (PARM.(0:16) = the function code that was
expected and PARM.(16:16) = interface code of received message).
ACTION: This error may be followed by a timeout of up to 15 seconds,
which is normal. Possibly some other module on the system sent a
message to the wrong place, and because whatever module sent it could
be expecting a reply which will never come, that module may now be
hung. Possibly one of NETCP’s previous reply waits timed out, but the
offending module has now decided to reply. For debugging purposes the
message content was logged in the NM logfile along with this error,