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

512 Chapter21
Logging Location Codes
Control Process Logging Location Codes
627 CLAS0002 MESSAGE: INTERNAL ERROR; Internal resource error
CAUSE: While stopping an NI because a network was being shut down,
NETCP encountered an error trying to delete a mapping table it had
previously created for the NI (PARM = 32-bit status returned by the
call to map_create_table).
ACTION: This error in itself was not fatal, and shutdown continued.
However, depending on the error, the amount of system memory used
by the table and its secondary tables be inaccessible until the next
system restart. If the problem occurs repeatedly, see Appendix A ,
“Submitting a CR,” of this manual.
628 CLAS0002 MESSAGE: Bad status
CAUSE: While attempting to stop one of the devices on an existing NI,
NETCP disconnected the device at the MAP level, then encountered an
error trying to send a device stop message to the NI (PARM = 32-bit
status returned by the call to send_msg).
ACTION: This error in itself was not fatal, and shutdown may continue.
However, some versions of Transport may hang if this problem occurs,
requiring a system restart to recover. On a non critical terminal,
attempt a :NETCONTROL STATUS command; if results are reported, then
try restarting the network. If the network restarts but the problem
returns, see Appendix A , “Submitting a CR,” of this manual.
629 CLAS0002 MESSAGE: PACKET DISCARD; Late reply
CAUSE: During processing of a Path Verify operation on behalf of some
other Transport module because of a possible problem or change in
state of a certain network, NETCP sent Path Verify request messages
to all the general protocols, but failed to receive a reply from one of
them within a 15-second timeout period (PARM = 32-bit port number of
the general protocol module which failed to reply). One of these errors
will appear for each module that fails to reply.
ACTION: This error in itself was not fatal, and NETCP processing
continued. This can mean either that a temporary Path Verify storm is
occurring because a heavily used link has failed, or it can mean there is
a problem with the general protocol module. In addition, if the reply
ever does arrive, NETCP will probably discard it, but may instead get
confused if it arrives while awaiting some other reply. If the problem
persists, first look for previous errors 678 or 679. The PARM for these
would contain the interface code from the reply, and should tell HP
what module was sending to CP. If this does not help, you can still
determine which module by restarting the network and taking note of
all port numbers printed on the console when Transport starts up, and
the modules which printed those ports. Then when the next error 629
occurs, match those port numbers with the PARM value printed for the
error. Afterward see Appendix A , “Submitting a CR,” of this manual, to
report a problem against the general protocol module which is failing to
reply.