Control Process Logging Location Codes

CAUSE: While initially starting NETCP, or while starting NI specific protocols on a LAN, GATEHALF, or ROUTER network, NETCP could not get node name information from the NODENAME path in the NMCONFIG file (PARM = 32-bit status returned by the call to nmconfgetdata).

ACTION: One or more network protocols were not completely started. Stop the network and use NMMGR to make sure a nodename is configured and the NMCONFIG file is validated. If the file looks good, try restarting the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While building the IP alias list, NETCP discovered there are too many network NI's configured in the NMCONFIG file (PARM = maximum networks allowed).

ACTION: Check the configuration file, and if it is not the problem see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an unexpected message that was not a reply, while waiting for a reply message having a specific function code (PARM.(0:16) = function code and PARM.(16:16) = interface code of received message).

ACTION: It is not possible to tell from NETCP logging what message it was expecting, however if disk logging was enabled, the entire received message was logged, which may aid debugging. The flow of normal NETCP operations has been interrupted, and a transport hang may be imminent, especially if new :NETCONTROL commands are issued. It may be necessary to restart the system to clear this problem. See Appendix A “Submitting an SR ” of this manual.

CAUSE: While initially starting NETCP, or while starting NI specific protocols on a LAN, GATEHALF, or ROUTER network, NETCP's attempt to get a buffer for a nodal path report failed (PARM = 32-bit status returned by the call to bmgr_get_buffer).

ACTION: One or more network protocols were not completely started. Stop transport and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While initially starting NETCP, or while starting NI specific protocols on a LAN, GATEHALF, or ROUTER network, NETCP could not get path report information from the NETXPORT.GLOBAL.REPORT path in the NMCONFIG file (PARM = 32-bit status returned by the call to nmconfgetdata).

ACTION: One or more network protocols were not completely started. Stop the network and use NMMGR to check the NMCONFIG file and validate it. If the file looks good, try restarting transport. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While initially starting up, NETCP's attempt to get the global information record from the NETXPORT.GLOBAL path in the NMCONFIG file failed (PARM = 32-bit status returned by the call to nmconfgetdata).

ACTION: Transport did not start. Verify the configuration file exists, and if this is not the problem, see Appendix A “Submitting an SR ” of this manual.

CAUSE: An attempt to create NETCP's frozen utility buffer pool failed during initial startup (PARM = 32-bit status returned by the call to bmgr_create_pool).

ACTION: Transport did not start. Depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If memory is not the cause and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: If PARM=0, during initial startup NETCP discovered the version number in the NMCONFIG file was not in the range expected by Transport.

ACTION: Transport did not start. Run program NMMGRVER to convert the configuration file to the current version, then restart the network.

CAUSE: If PARM is nonzero, during initial startup NETCP could not read the global information record from the NETXPORT.GLOBAL path in the NMCONFIG file (PARM = 32-bit status returned by the call to nmconfgetdata).

ACTION: Transport did not start. Use NMMGR to validate the NMCONFIG file, then retry the operation again. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During initial NETCP startup, an attempt to initialize the Node/Address Path cache by calling path_cache_init failed (PARM = maximum cached node names).

ACTION: Transport did not start. It is not possible to tell from NETCP logging what the result code from path_cache_init was, but PATHS may have logged additional errors. See Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message containing a negative error status, from the DCLDM controlling one of the LAPB links on the network (PARM = 32-bit status field from the message).

ACTION: NETCP stopped the device associated with the link, also stopping any attached protocols and driver. Run the PSIDAD diagnostic on the appropriate PSI card. If the PSI looks good, it may be possible to restart the device using :NETCONTROL ADDLINK=linkname; NET=niname. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While NETCP was rendezvousing a particular protocol to a driver, an attempt to connect a LAPB device failed for some reason other than a close already being in progress (PARM = 32-bit status returned by the call to xp_connect_the_driver).

ACTION: Check the appropriate PSI card and its cabling. If it looks good, another possibility is that the DCLDM or LAPB driver are hung; see Appendix A “Submitting an SR ” of this manual.

CAUSE: An attempt to physically start a device failed with a nonzero status meaning an unexpected error or warning occurred (PARM = 32-bit status returned by the call to nslopenlink). Physical startup includes all creation and startup of a link driver and its dependent modules, selftest, startup, downloading and configuration of link hardware, plus optional creation of a DCLDM, so any error along the way will be detected here by NETCP.

ACTION: Stop Transport and enable all available logging for the link subsystem corresponding to the NI type of the network reporting the error, then restart Transport and reproduce the problem, monitoring logged data for any problems. If this does not reveal the cause, link tracing can be used on the affected link to collect even more data.

Check that the physical path specified in the NMCONFIG file is correct for all link devices on the network being started, and that a card is installed in the slot for that path. You can stop the system then use IOMAP to verify physical path numbers.

For links other than X25, probably the link driver failed to obtain a resource, the link hardware was already in use by an IBM communications subsystem such as NRJE, the link hardware failed selftest or its firmware version is not supported by the driver, the download file was inaccessible, corrupt or has the wrong version, or executing the download caused the link hardware to hang and resulted in a driver or module configurator timeout or other problem. Use NMMGR to check the link configuration in NMCONFIG and use SYSDIAG to check the link hardware.

For X.25 links (and/or hardwired terminals), if a DTC link is in use the DTC and network links may have same physical path specified in NMMGR; try specifying separate physical LAN cards. Make sure the DTC configuration was validated with NMMGR. Another common cause with X25 networks is that the NMCONFIG file may have specified a DTC address or card which is inoperative or does not exist, resulting in one or more timeouts, some of which may have been accidentally sent to NETCP. Using NMMGR, compare the specified DTC configuration with the actual DTC hardware, and delete any DTC cards that are not physically present. Any DTC changes made, or re-validation of the DTC configuration, may require a system restart to take effect.

If the problem persists after investigating all these causes, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While NETCP was starting a specific network NI, an attempt to create a frozen outbound buffer pool for that NI failed (PARM = 32-bit status returned by the call to bmgr_create_pool).

ACTION: The NI did not start. Using NMMGR, check the configured packet size for the affected link. In particular, look for a packet size of 8224, which may indicate the NMCONFIG file has been corrupted, probably by an incompatible version of NMMGR. If the packet size is configured correctly, then depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If these are not the causes and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: As one of the first things it does during initial startup, NETCP logs that a new instance of Transport is starting (PIN=0, and PARM = PIN number of the NETCP system process).

ACTION: None. This is an informative message only. It does not imply successful startup, only that a startup is beginning. When starting Transport after a previous instance of it has just been stopped, it is possible for this message to appear before the other instance's Transport stop message appears.

CAUSE: As one of the last things NETCP does during shutdown, it logs that instance of Transport has stopped. After this, NETCP will close logging access, disconnect from NMMON, release its message port, then terminate (PARM = 0).

ACTION: None. This is an informative message only. It is only logged after all outstanding replies have been received from the general protocols. This message does not imply that Transport is completely down, nor does it imply successful shutdown, only that there is very little cleanup left to do. It is possible that another instance of Transport can be successfully started before this message appears.

CAUSE: An attempt to physically stop a device failed with a negative nonzero status meaning an unexpected error (not a warning) occurred (PARM = 32-bit status returned by the call to nslcloselink). Physical stop includes all shutdown and deletion of a link driver and its dependent modules and any connections to the NMS subsystem or the operating system, reset of link hardware, plus optional deletion of a DCLDM, so any error along the way will be detected here by NETCP.

ACTION: This problem in itself was not fatal, and link shutdown continued. However, there may be a problem with the link driver software or hardware.

Most shutdown problems are warnings, not errors (see error 283). Usually the link driver failed to release a resource, possibly due to a previous error, or the link hardware failed to stop in an orderly manner resulting in a driver or module configurator timeout or other problem, or an attempt to close logging resulted in a warning which was incorrectly reported as an error. If the link hardware is suspect, use SYSDIAG to check it. For X25 networks, verify the X25 switch has not failed.

If you wish to pursue the cause further, stop Transport and enable all available logging for the link subsystem corresponding to the NI type of the network reporting the error, then restart and stop the same network again to reproduce the problem, monitoring logged data for any problems. If this does not reveal the cause, link tracing may be attempted on the affected link to collect even more data, though because the device is shutting down, keep in mind the system may automatically stop the tracing before the point at which the problem is detected.

If the problem persists after investigating all these causes, see Appendix A “Submitting an SR ” of this manual.

CAUSE: At the beginning of NETCP shutdown due to a system shutdown, a :NETCONTROL STOP command, or an error during initial startup, NETCP encountered an error trying to close the NMCONFIG file it had previously opened (PARM = 32-bit status returned by the call to nmconfclose).

ACTION: This error in itself was not fatal, and shutdown continued. However, the NMCONFIG file may be inaccessible. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: A message with an unrecognized function code was received on the NETCP port while NETCP was idle and waiting for new commands (PARM = the 16-bit unknown message function code).

ACTION: The message was ignored and NETCP went back to waiting for the next new command. However, some other modules on the system are still waiting for the message exchange that mistakenly went to NETCP, and this could cause problems in those other modules. If disk logging was enabled, NETCP logged the entire received message to the current NM logfile, which may aid in diagnosis. It may not have been a transport message at all. If necessary, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that, in addition to some other error, one or more queued outbound write operations were aborted by the LAPB PSI driver (PARM = 16-bit internal ldev number of device whose writes were aborted). This error is always preceded by another asynchronous link error (for example, errors 257 and 259) indicating the original cause of the failure that resulted in the aborts.

ACTION: None; this is an informative message only, and only serves to indicate that queued outbound data was not sent when the error occurred. Additional information may be gained by enabling logging classes 10 and 12 for link subsystem 28 (LAPB) and class 0 for subsystem 4 (DCLDM), then reproducing the problem. If this does not reveal the cause, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After successfully disabling tracing for an entity at the Transport level, NETCP encountered an error trying to stop it at the NMS subsystem level (PARM = 32-bit status returned by the call to nmclosetrace).

ACTION: This error was not fatal, and NETCP continued running. However, the trace file may not have been closed, and thus would not be available for access until after the next system restart. If the problem occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to enable tracing for an entity, NETCP encountered an error attempting to get a trace ID from the NMS subsystem (PARM = 32-bit status returned by the call to nmgettraceid).

ACTION: No message to enable tracing was sent to the desired entity. Check that sufficient discspace is available on the system, and that trace filename specified in the link screen of the NMCONFIG file, or in the :NETCONTROL TRACEON command is legal and does not violate file system security rules. If this does not reveal the cause, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to rendezvous a specific protocol to the link driver, NETCP encountered an error (PARM = 32-bit status returned by the call to ns_rendezvous_to_driver).

ACTION: NETCP assumed the rendezvous failed. If this was a LAPB device, it was also not told to connect. See Appendix A “Submitting an SR ” of this manual.

CAUSE: During early initialization of NETCP during startup, validation of the NMCONFIG file failed (PARM = 16-bit result code returned by the call to validatenetxport).

ACTION: The transport did not start. Using NMMGR, open and validate the NMCONFIG configuration file to find any errors. Correct the errors and validate again. Then restart the network.

CAUSE: While starting a network NI having a nonzero number of buffers configured for IP Store/Forward, NETCP was unable to create a frozen buffer pool to provide those buffers (PARM = 32-bit status returned by the call to bmgr_create_pool).

ACTION: The NI was not started. Using NMMGR, check total Store/Forward buffers for each NI configured. Depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If memory is not the cause and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP is about to execute a Path Verify operation because of a possible path change detected by the Transport software, such as excessive retransmissions or a redirect message from a GATEWAY. NETCP logs this event, then forwards Path Verify messages to all general protocols and to the ICMP server, if any, then waits up to 15 seconds for replies to all those messages. General protocols which fail to respond will cause logging of error 629 after the timeout (PARM = number of duplicates).

Path Verify storms (a large number of Path Verify operations during a short time period) can occur if a heavily used high speed link suddenly fails. During storms, if NETCP receives new Path Verifies or any other requests while awaiting previous replies, they are queued for later execution if they are unique. If a new Path Verify is a duplicate of one already queued, the new one is counted and then discarded. Later, after all replies arrive or a timeout occurs, the oldest queued Path Verify is executed (PARM = number of duplicates of this Path Verify received and discarded while awaiting replies; nonzero indicates a storm is occurring, and larger numbers mean more severe storms). This continues until no Path Verifies arrive while awaiting replies. Other NETCP requests such as :NETCONTROL STATUS, can then be processed. If a new Path Verify arrives after that point, even if it duplicates one already processed it is treated as new and unique.

ACTION: None. This is an informative message only.

CAUSE: NETCP is about to send a GATEWAY update message to IPU for a specific IP address, because a network is starting (PARM = 32-bit IP address being updated).

ACTION: None. This is an informative message only. IPU will use information in the message to update its tables.

CAUSE: NETCP is restarted a device either because DIAL failed to make a connection (for instance due to a bad security string), or because idle device timeouts were enabled in the configuration and a timeout occurred (PARM = 16-bit NETCP device index of affected device).

ACTION: If you suspect a security problem, you may wish to address that issue. Otherwise, no action is required; this is an informative error message only. NETCP disconnected the device, then cleaned up for the next device startup.

CAUSE: While attempting to build GATEWAY update information for IPU because a network was starting, NETCP was unable to obtain a buffer from its own pool to hold the information for a specific NI (PARM = 32-bit status returned by the call to bmgr_get_buffer).

ACTION: NETCP attempted to continue with the next NI, possibly resulting in additional errors. Probably all the NETCP buffers have somehow been used up, though it should have allowed for enough to support starting any supported network configuration. Stop Transport and use NMMGR to validate the NMCONFIG file and check for obvious file corruption, then restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP is about to send a GATEWAY update message to IPU for a specific IP address, because a network is stopping (PARM = 32-bit IP address being updated).

ACTION: None. This is an informative message only. IPU will use information in the message to update its tables.

CAUSE: While attempting to collect current address configuration data from NMCONFIG because an X25 network was either starting or being updated, NETCP was unable to obtain a logical buffer from its own pool to hold all the X25 information (PARM = 32-bit status returned by the call to bmgr_get_buffer).

ACTION: Check the configuration file using NMMGR, to see that the amount of X25 configuration data seems to be within limits. Also verify your system has any and all software patches that may be needed to use the amount of X25 configuration data you are specifying, especially if you configuration contains more than 1024 X.25 paths. If the problem still cannot be isolated, the NMCONFIG file may be corrupt, or there may be a bug in NETCP or the NMS subsystem; seeAppendix A “Submitting an SR ” of this manual.

CAUSE: While configuring a GATEHALF or a ROUTER network mapping entry, NETCP was unable to find free space in a global array to hold another new phone number (PARM = maximum phone numbers per system, in hex).

ACTION: Even after attempting to eliminate duplicate phone numbers, no free cells were available for an additional number; all entries appear to be in use. If phone numbers have been changed via :NETCONTROL UPDATE, stop and restart the network, stop any started ROUTER or GATEHALF networks that are not needed, or decrease the number of unique phone numbers configured in the NETXPORT.NI.niname.MAPPING.entryname paths of your NMCONFIG file. Depending on the version of Transport you are running, the maximum number of unique phone numbers is either 1024 or 4096 for the whole system, and the per-NI limit is either 256 or 1024 respectively.

CAUSE: While attempting to build a DCN start message for IPU because of a network start, a :NETCONTROL ADDLINK command, or an X25 auto restart, NETCP was unable to obtain a buffer from its own pool to hold alias list information (PARM = 32-bit status returned by the call to bmgr_get_buffer)

ACTION: Though no DCN message was sent, network startup probably continued to completion, but connections over the affected network may not work. Probably all the NETCP buffers have somehow been used up, though it should have allowed for enough to support starting any supported network configuration. Stop Transport and use NMMGR to validate the NMCONFIG file and check for obvious file corruption, then restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During NETCP processing of a network start or update command, after an earlier successful validation of the NMCONFIG file a later validation of the file failed (PARM = 16-bit result code returned by the call to validatenetxport).

ACTION: The specified network was not started. Possibly the NMCONFIG file was being modified while networks were running, and the changes made were incomplete or incorrect. Stop Transport and use NMMGR to open and validate the NMCONFIG configuration file and find any errors. Correct the errors and validate again. Then restart the network.

CAUSE: During later phases of its initial startup, NETCP was unable to create a process port for itself (PARM = 32-bit status returned by the call to create_port).

ACTION: The transport was not started. There is a problem with the operating system or a bug in NETCP; see Appendix A “Submitting an SR ” of this manual.

CAUSE: During later phases of its initial startup, after NETCP was finished using the NMCONFIG file, it encountered an error while trying to close the file (PARM = 32-bit status returned by the call to nmconfclose).

ACTION: This error in itself was not fatal, and startup continued. However, the NMCONFIG file may be inaccessible, and to be safe NETCP assumed it still has the file open. If Transport is later stopped, NETCP will again try to close the file. Possibly an earlier run of NMMGR left the file in a bad state. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While creating and initializing a specific network NI because a :NETCONTROL START command was issued, the NI module configurator reported an error when trying to create the NI port data area or port, or when sending an initialization message to the new NI (PARM = 32-bit escape code returned by the call to ni_module_config). Always preceded by another error from the module configurator (having a different Entity number, such as 151-160), logging the reason for the original failure.

ACTION: Record the previous error and this error. See Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP tried to search the NMCONFIG file to determine if an NI having a specific name was configured or not, but was unable to open the file (PARM = 32-bit status returned by the call to nmconfopen).

ACTION: Check that the NMCONFIG file exists and is not already opened by some other user, such as a STORE process or someone running NMMGR. If this is not the problem, there may be a bug in the NMS subsystem or in NETCP; see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI link was disconnected (PARM = 32-bit NETCP device state bitmask for the device). NETCP will not attempt to reconnect the device because it appears neither level 1 nor level 2 connections were established when this event occurred. May be followed by informative error 101 if outbound data was queued when the error occurred.

ACTION: This error may follow a previous asynchronous link error, which may indicate an earlier problem. Additional information may be gained by enabling logging classes 3 for Transport subsystem 3, 10 and 12 for link subsystem 28 (LAPB) and class 0 for subsystem 4 (DCLDM), then reproducing the problem. It may be possible to manually restart the device using a :NETCONTROL ADDLINK=linkname; NET=niname command. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI link was closed (PARM = 16-bit internal ldev number of the device). NETCP will attempt to reconnect the device because it appears either level 1 or level 2 connections, or both, were established when the event occurred. May be followed by informative error 101 if outbound data was queued when the error occurred.

ACTION: None. This is an informative error message only. The link will reconnect automatically unless error 256 appears. This event may follow a previous asynchronous link error, which may indicate an earlier problem. If the situation continues, there may be a problem with the phone system; additional information may be gained by enabling logging classes 10 and 12 for link subsystem 28 (LAPB) and class 0 for subsystem 4 (DCLDM).

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI link has established a level 2 connection (PARM = 16-bit internal ldev number of the device).

ACTION: None. This is an informative message only. The LAPB link is now successfully engaged in protocol handshaking, and will stay up unless an error, disconnect, or idle timeout occurs, or the network is stopped.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI link was disconnected by its remote side (PARM = 0). May be followed by informative error 101 if outbound data was queued when the error occurred.

ACTION: None. This is an informative error message only. NETCP will now tell the driver on the local side to disconnect, so informative error 257 should follow.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB driver had some problem handling a phone number change request (PARM = 32-bit NETCP device state bitmask for the device).

ACTION: This error may be related to the syntax or length of the phone number, but could also be caused by some internal problem. Use NMMGR to check the syntax of the telephone number in the NMCONFIG file for the affected link. Then attempt a :NETCONTROL ADDLINK=linkname; NET=niname command. If the error persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that closing its LAPB PSI link failed (PARM = 16-bit internal ldev number of the device). NETCP will attempt to bring down the device and its driver. May be followed by informative error 101 if outbound data was queued when the error occurred.

ACTION: See Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating its LAPB PSI link reported some sort of miscellaneous warning (PARM = 16-bit internal ldev number of the device).

ACTION: None. This is an informative message only.

CAUSE: While creating an NI because a specific network was starting, NETCP encountered an error trying to create a message pool for the new NI port (PARM = 32-bit status returned by the call to create_pool).

ACTION: None. The network was not started. See Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP tried to search the NMCONFIG file to determine if an NI having a specific name was configured or not, but after successfully opening the file it was unable to close it (PARM = 32-bit status returned by the call to nmconfclose).

ACTION: This error in itself was not fatal, and NETCP continued. However, the NMCONFIG file may be inaccessible. Check that the NMCONFIG file exists and is not already opened by some other user, such as someone running NMMGR. If this is not the problem and the message persists, see "Appendix A “Submitting an SR ” of this manual.

CAUSE: While creating an NI because a network was starting, NETCP encountered an error trying to create a new mapping table for the NI (PARM = 32-bit status returned by the call to map_create_table).

ACTION: The network was not started. Depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If memory is not the cause and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While creating an NI because a network was starting, NETCP successfully created a new mapping table for the NI, but then encountered an error trying to add the NETCP entity into the table (PARM = 32-bit status returned by the call to map_add_entity).

ACTION: The network was not started. See Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a :NETCONTROL command to start or update a network or add a link, NETCP successfully opened the NMCONFIG file, but was unable to lock it (PARM = 32-bit status returned by the call to nmconflockfile).

ACTION: The command did not execute, and NETCP closed the open file. Check that the NMCONFIG file exists and is not already opened by some other user, such as someone running NMMGR. If this is not the problem and the message persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a :NETCONTROL command to start or update a network or add a link, NETCP was unable to open the NMCONFIG file (PARM = 32-bit status returned by the call to nmconfopen).

ACTION: The command did not execute. Check that the NMCONFIG file exists and is not already opened by some other user, such as someone running NMMGR. If this is not the problem and the message persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received a dial request message but the entity whose reply port was in the message was not one of the network specific protocols known to NETCP for this NI (PARM = 0).

ACTION: Some entity other than DIAL may be attempting dial requests. See Appendix A “Submitting an SR ” of this manual.

CAUSE: An attempt to physically start a device was successful, but returned a positive status meaning some sort of unexpected warning occurred (PARM = 32-bit status returned by the call to nslopenlink).

ACTION: None. This is an informative error message, and exists for pre-5.0 systems only. If you want more information, try enabling additional logging for the link subsystem corresponding to the type of NI for the network reporting the warning, then reproduce the message. If this still does not reveal the cause, see Appendix A “Submitting an SR ” of this manual.

CAUSE: An attempt to physically stop a device failed with a positive nonzero status meaning an unexpected warning (not an error) occurred (PARM = 32-bit status returned by the call to nslcloselink). Physical stop includes all shutdown and deletion of a link driver and its dependent modules and any connections to the NMS subsystem or the operating system, reset of link hardware, plus optional deletion of a DCLDM, so any error along the way will be detected here by NETCP.

ACTION: This problem in itself was not fatal, and link shutdown continued. However, there may be a problem with the link driver software or hardware.

Most shutdown problems are warnings, not errors (see error 54). Usually the link driver failed to release a resource, possibly due to a previous error, or the link hardware failed to stop in an orderly manner resulting in a driver or module configurator timeout or other problem, or an attempt to close logging resulted in a warning which was incorrectly reported as an error. If the link hardware is suspect, use SYSDIAG to check it. For X25 networks, verify the X25 switch has not failed.

If you wish to pursue the cause further, stop Transport and enable all available logging for the link subsystem corresponding to the NI type of the network reporting the error, then restart and stop the same network again to reproduce the problem, monitoring logged data for any problems. If this does not reveal the cause, link tracing may be attempted on the affected link to collect even more data, though because the device is shutting down, keep in mind the system may automatically stop the tracing before the point at which the problem is detected.

If the problem persists after investigating all these causes, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI link received a second SABM frame after a connection was already established, meaning the link has connected again (PARM = 0).

ACTION: None. This is an informative error message only, of interest to operators who wish to know when new connections occur. Handling a second SABM is a normal part of the LAPB protocol.

CAUSE: During NETCP's early initial startup, immediately after attempting to create the NS Registry, NETCP was unable to add Transport's subsystem number to it (PARM = 32-bit status returned by the call to reg_add_subsys).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed, in which case all subsequent calls to it will also result in errors being logged. If this message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: Near the end of NETCP's early initial startup, it was unable to put its port number into a new entity named "NetCP" in the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While creating a network NI for which IP Store and Forward was enabled, NETCP was unable to put the new Store and Forward buffer pool ID into a new entity, having the same name as the NI, in the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During NETCP's early initial startup, it was unable to put the NETCP utility buffer pool ID into a new entity named "CP POOL" in the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While creating an NI because a network was being started, NETCP was unable to put that NI outbound buffer pool ID into a new entity, having the same name as the NI, in the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While building a buffer containing all X25 configuration data for a network, NETCP successfully obtained a buffer of the supposedly correct size, but later encountered an error attempting to write a block of Network Directory address information to the buffer (PARM = 32-bit status returned by the call to bmgr_write_buffer).

ACTION: Check the configuration file using NMMGR, to see that the amount of X25 configuration data seems to be within limits. Also verify your system has any and all software patches that may be needed to use the amount of X25 configuration data you are specifying. If the problem still cannot be isolated, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI's autodial operation failed due to an internal autodialer problem (PARM = 16-bit internal ldev number of the device).

ACTION: Check the autodialer cabling and strapping or configuration, and diagnose the autodialer hardware. Then retry the operation.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI card was passed a bad autodial telephone number (PARM = 16-bit internal ldev number of the device).

ACTION: Use NMMGR to check the syntax of the telephone number in the NMCONFIG file for the affected link. Then retry the dialing operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that a LAPB PSI's autodial operation was not completed, possibly because the site being dialed is either busy or not picking up (PARM = 16-bit internal ldev number of the device).

ACTION: Attempt to dial out again at a later time, or reconfigure the remote site and the local NMCONFIG mappings to provide additional phone connections into that site.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI autodial operation was attempted while the autodialer hardware was not powered up (PARM = 16-bit internal ldev number of the device).

ACTION: Turn on the autodial unit and check for power and correct cabling. Then attempt to dial out again.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI autodial failed because the line was busy or a phone line was not available (PARM = 16-bit internal ldev number of the device). (Some pre-5.0 versions of Transport also incorrectly reported wrong autodialer cables under this location; now see error 674).

ACTION: Attempt to dial out again later when a phone line is free.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI link experienced a power failure, resulting in a disconnect of the phone line (PARM = 16-bit internal ldev number of the device). May be followed by informative error 101 if outbound data was queued when the error occurred.

ACTION: None. This is an informative error message only. NETCP will now automatically attempt to bring the device driver down and then back up.

CAUSE: During later stages of NETCP's initial startup, NETCP was unable to create a message pool for its own process port (PARM = 32-bit status returned by the call to create_pool).

ACTION: The transport was not started. There is a problem with the operating system or a bug in NETCP; see Appendix A “Submitting an SR ”A of this manual.

CAUSE: During later stages of NETCP's initial startup, NETCP was unable to add its own port message pool ID to the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While restarting a link requiring autodial, because an unexpected error occurred while connected (see error 257), NETCP instructed the local side to establish a level 2 connection. This failed because NETCP received an asynchronous DCLDM event message indicating its LAPB PSI link reported that the remote side was establishing or had already established a connection (PARM = 16-bit connect event code from LAPB).

ACTION: None. This is an informative error message only. The connection was successfully established, but through the initiative of the remote side, not the local. NETCP then disconnected the device at the local side.

CAUSE: While restarting a link requiring autodial, because an unexpected error occurred while connected (see error 257), NETCP instructed the local side to establish a level 2 connection. A connection was established, but then failed because NETCP received an asynchronous DCLDM event message indicating its LAPB PSI link reported another failure (PARM = upper 16 bits of status from the call to xp_connect_the_driver: usually the connect event code from LAPB).

ACTION: NETCP disconnected the device and notified protocols that the link went down. This is most likely a link level problem. Consult the link diagnostics and check the modems. Confirm that the link connection is working for the affected link. If the link is connection is working, then seeAppendix A “Submitting an SR ” of this manual.

CAUSE: While restarting a LAPB PSI link because an unexpected error occurred while connected (see error 257), NETCP encountered an error when it instructed the local side to reestablish a level 1 connection so that a level 2 connection can be established later (PARM = 32-bit status returned by the call to xp_connect_the_driver).

ACTION: NETCP brought the device and its driver down, and notified protocols that the link went down. This is most likely a link level problem. Another possibility is that the DCLDM or LAPB driver are hung. Consult the link diagnostics and check the modems. Confirm that the link connection is working for the affected link. If the link is connection is working, then see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a legal dial request message, NETCP found that the link appeared to already be connected, so dialing was not possible (PARM = adjusted LAPB status).

ACTION: None. This is an informative error message only. Another class-3 logging message may have preceded this, indicating that the link just connected.

CAUSE: NETCP received a legal dial request message but encountered an error while downloading the phone number to the link (PARM = 32-bit status returned by the call to xp_driver_config_dial).

ACTION: This event may follow a previous asynchronous link error, which may indicate the original problem. Another possibility is that the DCLDM or LAPB driver are hung. Also check the validity of the phone number in the configuration. If the situation continues, additional information may be gained by enabling logging classes 10 and 12 for link subsystem 28 (LAPB), and class 0 for subsystem 4 (DCLDM). If this still does not reveal the problem, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received a legal dial request message but encountered an error while trying to establish a level 2 connection at the LAPB driver, through the DCLDM (PARM = 32-bit adjusted status returned by the call to xp_connect_the_driver: add decimal 256 to get the actual status).

ACTION: Perform the same actions as above

CAUSE: While processing a legal dial request message, NETCP found that the link was already closed, due to system timing conditions (PARM = adjusted LAPB status).

ACTION: This is an informative error message only. Attempt to dial out again if necessary.

CAUSE: While collecting configuration data for startup of an X25 network, NETCP found two IP addresses mapping to the same X25 address key (PARM = 0).

ACTION: This error in itself was not fatal, and collection of the X25 data continued. The logging does not tell which address was involved. You may wish to run NMMGR and inspect the X25 configuration data for mistakes.

CAUSE: An attempt to create a frozen inbound buffer pool for a particular NI device failed (PARM = 32-bit status returned by the call to bmgr_create_pool). Always followed by another error indicating whether LAPB (see error 407) or non-LAPB (see error 619) pool creation was being attempted.

ACTION: The NI did not start. Check the packet size configured in the NMCONFIG file. For LAPB links, pool creation parameters are obtained from this file, but other link types have a more complex process for determining packet size. Depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If these are not the causes and the problem persists even if retried after a suitable waiting period, seeAppendix A “Submitting an SR ” of this manual.

CAUSE: While creating a frozen inbound buffer pool for a particular NI device because its network was being started, NETCP was unable to put that pool ID into a new entity, having a name that is the ASCII version of the decimal buffer size, in the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start a LAPB PSI device on an existing NI, NETCP was unable to create a frozen inbound buffer pool for that device's reads (PARM = 32-bit status returned by the call to cp_get_read_pool). Always preceded by another error indicating the original failure (see error 404).

ACTION: The device did not start. Check the packet size configured in the NMCONFIG file; for LAPB links, pool creation parameters are obtained from this file. Depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If these are not the causes and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down a specific protocol on a network, NETCP encountered an error attempting to unbind that protocol from a device driver (PARM = 32-bit status returned by the call to ns_separate_from_driver). NETCP did not expect any error since it supposedly bound that protocol to the driver during network startup. (Some pre-5.0 versions of Transport also reported unbind errors for shutdown of specific devices under this location; now see error 673).

ACTION: This error in itself was not failed, and protocol shutdown continued. If this error occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While collecting configuration data for startup of an X25 network, NETCP found that a user had specified an X25 address for a remote node was on a DDN Network, but had also supplied the actual address. Instead, the X25 address should be derived from the IP address by the Transport code (PARM = 0).

ACTION: Verify that the network interface started is actually for a DDN Network. If the network is DDN, no action is required, since all configured X25 addresses will be ignored. If not, reconfigure the DTC (using the DTC manager), then stop and restart the network NI on the host. This error message is only printed once per startup, even if multiple X25 addresses have this problem.

CAUSE: NETCP received an unrecognized message on port subqueue 2 or 4, which are only designed for asynchronous event messages (PARM = first 16 bits of message, which should give the message type.) NETCP was expecting either a DCLDM event message (type 340) or an SDI async event message (type 390)

ACTION: This error in itself was not fatal, and NETCP continued operating. However, some other modules on the system may still be waiting for a message exchange that mistakenly went to NETCP, and this could cause problems in those other modules. If disc logging was enabled, NETCP logged the entire received message to the current NM logfile, which may aid in diagnosis. It may not have been a Transport message at all. If necessary, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While collecting configuration data for startup of an X25 network, NETCP successfully obtained a buffer to hold the data, but later on was unable to write data into that buffer (PARM = 32-bit status returned by the call to bmgr_write_buffer).

ACTION: Not all the configuration data was collected, and startup of that network failed. Check the configuration file using NMMGR, to see that the amount of X25 configuration data seems to be within limits. Also verify your system has any and all software patches that may be needed to use the amount of X25 configuration data you are specifying. If the problem still cannot be isolated, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous DCLDM event message, but the device number in the message did not correspond to any known device in NETCP's tables (PARM = 16-bit internal ldev number from the message).

ACTION: This error in itself was not fatal, and NETCP continued operating. Some kind of timing condition may have occurred. Another possibility is NETCP or a DCLDM may be confused. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous SDI event message, but the specific type of event was something other than an exception event, the only message type NETCP was expecting (PARM = 32-bit SDI status field from the message).

ACTION: This error in itself was not fatal, and NETCP continued operating. However, some other modules on the system may still be waiting for the event message that mistakenly went to NETCP, and this could cause problems in those other modules. If disc logging was enabled, NETCP logged the entire received message to the current NM logfile, which may aid in diagnosis. If necessary, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an SDI asynchronous event message from X25 informing it that a level 3 connection has been established on a DTC for an X25 link already started by the Transport (PARM = 32-bit SDI status field from the message).

ACTION: None. This is an informational message only. NETCP has connected the device, and Transport will now begin using this link.

CAUSE: NETCP received an SDI asynchronous event message informing it that an X25 device reported an error (PARM = 32-bit SDI status field from the message).

ACTION: NETCP will bring down the X25 device and its driver, then start a 2-minute automatic restart timer. If the problem occurs repeatedly, stop the network or use the :NETCONTROL DELLINK=linkname; NET=niname command to remove the DTC link from Transport use. Verify that the DTC LAN link on the host is functioning correctly (via LANDAD) then verify that the link on the DTC is functioning correctly (via the Openview DTC Manager). Once the errors are corrected, restart the network or use a :NETCONTROL ADDLINK=linkname; NET=niname command to allow the Transport to use the DTC link again.

CAUSE: While starting an 802.3 LAN device prior to opening its driver, NETCP encountered an error attempting to add multicast addresses to the driver's KSO (PARM = 32-bit status returned by the call to ieee_multicast_add).

ACTION: The LAN network did not start. Use the LANDAD tool to verify the LAN hardware is functioning correctly. If it looks good, there may be a problem with the LAN driver software or a bug in NETCP; see Appendix A “Submitting an SR ” of this manual.

CAUSE: While stopping an 802.3 LAN device prior to closing its driver, NETCP encountered an error attempting to delete multicast addresses it supposedly added previously to the driver's KSO (PARM = 32-bit status returned by the call to ieee_multicast_delete).

ACTION: This error in itself was not fatal, and device shutdown continued. After shutdown, use the LANDAD tool to verify the LAN hardware is functioning correctly. If it looks good but the problem persists, then see Appendix A “Submitting an SR ” of this manual.

CAUSE: While stopping an X25 network, NETCP encountered an error attempting to delete the X25 Flow Control Manager (PARM = 32-bit status returned by the call to netfc_kill). The Flow Control Manager dynamically allocates the flow control buffer pools for X25.

ACTION: This error in itself was not fatal, and shutdown of the X25 NI continued. If the error occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP was about to send a level 3 restart message to the X25 protocol, but the NETCP tables showed a restart had already been sent (PARM = 0).

ACTION: No restart message was sent this time, but this situation should not have occurred. If it occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP was about to send a level 3 stop message to the X25 protocol, but the NETCP tables showed a restart had already been sent (PARM = 0).

ACTION: No stop message was sent this time, but this situation should not have occurred. If it occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an SDI async event message informing it that the X25 RLM was not ready, meaning that levels 3 and 2 have gone down on the DTC for an X25 link already started by Transport (PARM = 32-bit SDI status field from the message).

ACTION: None. This is an informative message only. In many cases the DTC will recover on its own. If this does not happen, use the DTC Manager to find the reason why levels 2/3 are not up. Once the problem is corrected on the DTC, the host will be informed and will start using the device.

CAUSE: NETCP has received a message instructing it to process one of the general :NETCONTROL commands (PARM = hex 330). Examples of these are START, ADDLINK, DELLINK, STOP, and UPDATE commands: anything except for STATUS.

ACTION: None. This is an informative message only.

CAUSE: NETCP has received a message instructing it to process a :NETCONTROL STATUS command (PARM = hex 332).

ACTION: None. This is an informative message only.

CAUSE: When NETCP attempted to send a reply message back to NETUI to complete a blocked :NETCONTROL command, or send a reply back to NMMON to complete initial creation of NETCP after either a successful or an unsuccessful startup, an error occurred on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: If user session which issued the command exists, it will now be hung. Since it also owns resources, it cannot be aborted, and a system restart will be needed to recover. However, depending on the command that hung, most other network operations should continue to work normally. If not, you may try restarting the network. If the command that hangs attempted to mix several :NETCONTROL operations in the same command, try avoiding this, issuing separate commands instead. If the separate commands are in a batch job or a UDC, try adding some :PAUSE commands between the network commands. If the problem still persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send a request message to the PROBE module to cause it to send a packet to a network, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: Other systems on the network may be unaware that this node is up. This, in itself, will not prohibit connections into or out from this node. If the desired connectivity cannot be achieved, restart the network. If the problem persists, then see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send an X25 restart request message to the X25 protocol module, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: X25 did not receive the restart request. This will cause the X25 network to enter a bad state. Stop and restart that network. If this problem continues, see Appendix A “Submitting an SR ” of this manual.

CAUSE: On an SNA network NI, while attempting to send a bind message to the L2RESOLVE module of SNA, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: This will prevent SNA from establishing any connections. Stop and restart the network. If this problem continues, see Appendix A “Submitting an SR ” of this manual.

CAUSE: On an SNA network NI, while attempting to send a device disconnect message to the L2RESOLVE module of SNA for a device which had previously established a level 1 connection, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: The device was not disconnected. Restart the network. If this problem continues, then see Appendix A “Submitting an SR ” of this manual.

CAUSE: In the last phases of stopping the last device on an NI that was being shut down, NETCP encountered an error while trying to delete that NI inbound buffer pool (PARM = 32-bit status returned by the call to bmgr_delete_pool).

ACTION: This error was not fatal, and network shutdown continued. However, the amount of system memory used by the pool may be inaccessible until the next system restart. Probably some buffers for the pool were lost, or are still outstanding in protocol modules which had previously encountered errors. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: In the last phases of stopping the last device on an NI that was being shut down, NETCP found the NI inbound buffer pool ID in its device table, but not in its read pool table (PARM = 16-bit buffer size for the missing pool ID; this number was used internally in the NS Registry to name that pool).

ACTION: This error was not fatal, and network shutdown continued. However, since pool ID's should always appear in both tables, NETCP is confused. Even if the pool ID in the device table was valid, NECP could not be sure, so to be safe the buffer pool was not deleted, and the NS Registry may still contain that pool ID. The amount of system memory used by this buffer pool may be inaccessible until the next system restart. If the problem occurs again, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to disable tracing on one of the Transport modules, in response to a system shutdown or a user's :NETCONTROL command, NETCP encountered an error trying to send a trace disable message to that module (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error was not fatal, and network operation continued. Though it is not possible to tell from console logging which module was affected, disc logging will show the entire message, including the interface code of the entity being sent to. After this error, NETCP disabled the affected module's tracing at the NMS subsystem level, closing the trace file. While this may result in additional module specific errors if the module tries writing more trace data later on, at least the file will be available for analysis. If this problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to enable tracing on one of the Transport modules, in response to a user's :NETCONTROL command, NETCP encountered an error trying to send a trace enable message to that module (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error was not fatal, and network operation continued. Even though a new trace file was created, the module will not record any trace data in it, and more errors may occur when tracing is disabled later on. The specified module may have failed or may not exist. When convenient, try restarting the network. If the problem still persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While stopping Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP was unable to delete a CM Port Dictionary entry named "NMCONFIG", into in which it had previously stored the name of the NMCONFIG file (PARM = 16-bit result code returned by the call to dict_delete). The entry was used as a way to partially lock the file, so NMMGR could tell Transport was up and running. The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport.

ACTION: This error in itself was not fatal, and shutdown continued. However, the entry should have been there. If the same error occurs again, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error trying to delete the NETIPC Socket Timers module (PARM = 32-bit status returned by the call to sk_ti_stop).

ACTION: This error in itself was not fatal, and shutdown continued. However, it may not be possible to restart Transport without first restarting the system. See Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error when trying to stop one of the general protocols (PARM = 32-bit escape code returned by the call to the module deconfigurator that failed). Always preceded by another error from another entity (having a different Entity number, such as 151-160), indicating the cause of the original failure.

ACTION: This error in itself was not fatal, and shutdown continued. However, some system resources may be lost until the next system restart. Inspect the previous error, and if necessary see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error trying to delete the NS Registry (PARM = 32-bit status returned by the call to reg_del_register).

ACTION: This error in itself was not fatal, and shutdown continued. However, it may not be possible to restart Transport without first restarting the system. If necessary, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error trying to delete its utility buffer pool (PARM = 32-bit status returned by the call to bmgr_delete_pool).

ACTION: This error was not fatal, and network shutdown continued. However, the amount of system memory used by the pool may be inaccessible until the next system restart. Probably some buffers for the pool were lost, or are still outstanding in modules which remain in the background after NETCP terminates. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error trying to delete a CM Port Dictionary entry named "NetCP", into which it had stored its own port number, for use by various CM transport modules such as PROBE (PARM = 16-bit result code returned by the call to dict_delete). The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport.).

ACTION: This error in itself was not fatal, and shutdown continued. However, it may not be possible to restart Transport without first restarting the system, since if the Dictionary entry does still exist, future :NETCONTROL commands may either hang or cause a system abort. See Appendix A “Submitting an SR ” of this manual.

CAUSE: During the later phases of initial NETCP startup, NETCP encountered an error trying to add its port ID into the NMMON port table, so that NETCP would receive a shutdown message if the system or NMMON were later shut down (PARM = 32-bit status returned by the call to nnmonaddid).

ACTION: This error was not fatal, and network startup continued. However, shutting down the system will not stop Transport, so to avoid ungraceful connection losses, you should attempt a :NETCONTROL STOP command before attempting your next system shutdown. If you wish, you can try restarting the network. If the problem still occurs, NMMON may not be running, though that would more likely cause a NETCP hang. Run NMMAINT and check for version mismatches on subsystem 0. If there is no mismatch, try restarting the system. If the problem still occurs, see Appendix A “Submitting an SR ” of this manual.

CAUSE: Dictionary error.

ACTION: This error was not fatal, and network startup continued. However, additional problems, including system aborts, may occur because other modules of Transport will not be able to find NETCP. Also, additional errors will occur later when NETCP tries to delete the Dictionary entry (see error 614). If another instance of Transport was just shut down, it is possible a collision occurred. Stop and restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During the later phases of initial NETCP startup, NETCP encountered an error trying to add its own port number into a CM Port Dictionary entry named "NetCP", for use by various CM transport modules such as PROBE (PARM = 16-bit result code returned by the call to dict_add). The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport.

ACTION: This error was not fatal, and network startup continued. However, additional problems, including system aborts, may occur because other modules of Transport will not be able to find NETCP. Also, additional errors will occur later when NETCP tries to delete the Dictionary entry (see error 614). If another instance of Transport was just shut down, it is possible a collision occurred. Stop and restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During the early phases of initial NETCP startup, after successfully opening the configuration file, NETCP encountered an error trying to add the name of the file into a CM Port Dictionary entry named "NMCONFIG" (PARM = 16-bit result code returned by the call to dict_add). The entry was used as a way to partially lock the file, so NMMGR could tell Transport was up and running. The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport.

ACTION: This error was not fatal, and network startup continued. However, additional errors will occur later when NETCP tries to delete the Dictionary entry (see error 609). In addition, assumptions made by Transport and NMMGR about the partial lock on the file will not be valid; all NMMGR access to the NMCONFIG file during the time this instance of Transport is up should be avoided. Restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While starting the X25 protocol module for an X25 network that was being started, NETCP encountered an error trying to add a linkname it created for one of the X25 devices, into a CM Port Dictionary entry (PARM = 16-bit result code returned by the call to dict_add). The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport. There should be one entry per X25 device, named "X25.linkid", where "linkid" consists of 4 unprintable bytes defining the binary SDI link ID for that link, dynamically assigned by the Link Support Services subsystem.

ACTION: This error was not fatal, and network startup continued. However, additional errors will occur later when NETCP tries to delete the linkname (see error 660). In addition, certain X25 operations may not work correctly. Restart the network. If this problem continues, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start a device on an existing NI type other than a ROUTER, NETCP encountered an error trying to create a frozen inbound buffer pool for that device's reads (PARM = 32-bit status returned by the call to cp_get_read_pool). Always preceded by another error indicating the original failure (see error 404).

ACTION: The device did not start. Check the packet size configured in the NMCONFIG file; for non LAPB links, pool creation parameters are computed from the base figures found in this file. Depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If these are not the causes and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send a device start message to an existing NI in response to a :NETCONTROL command, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: The device was started at the NETCP and MAP layers, but not at the NI layer. As a result, no packets can be successfully sent or received over that device, and other errors, especially NI errors, may occur if attempted. Restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After successfully starting an FDDI link and all its network specific protocols because a :NETCONTROL START command was issued, NETCP encountered an error trying to send a broadcast information message to the UDP protocol module (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error in itself was not fatal, and NETCP startup continued. After this failure, most of Transport, with the exception of UDP, will probably run correctly. However, certain actions, such as Path Verifies, can indirectly result in more sends to UDP, which may cause more errors. When convenient, try stopping Transport using :NETCONTROL STOP, then restart it and bring up the FDDI link again. If the same problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send a DCN start message to IPU in response to an X25 automatic restart or a user's :NETCONTROL START or :NETCONTROL ADDLINK command, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg). A DCN start message is required for a Directly Connected Network such as X25.

ACTION: IPU did not receive the message, so it does not know the network is started. As a result, path resolution for the NI will fail. Restart the network. If this problem continues, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After completing construction of a GATEWAY update buffer in response to startup or shutdown of some network, NETCP encountered an error trying to send a message referencing that buffer to the IPU module of Transport (PARM = 32-bit status returned by the call to send_msg).

ACTION: IPU did not receive the message, so path resolution information for the network will not be up to date, and attempts to establish connections with it may fail. Restart the network. If this problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send a device stop message to the DIAL module because protocols on an existing ROUTER network are being shut down, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: The error in itself was not fatal, and shutdown of this network probably continued, ending with deletion of this instance of the DIAL module. However, DIAL was not notified the device has stopped, which may have caused more errors if it happened to run again before it was deleted. In addition, 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 an SR ” of this manual.

CAUSE: While deconfiguring an NI for a network that was being shut down and which also had IP Store and Forward enabled, after first deleting that Store and Forward buffer pool ID from the NS Registry, NETCP encountered an error trying to delete the buffer pool itself (PARM = 32-bit status returned by the call to bmgr_delete_pool).

ACTION: This error was not fatal, and network shutdown continued. However, the amount of system memory used by the pool may be inaccessible until the next system restart. Probably some buffers for the pool were lost, or are still outstanding in link drivers or in Transport modules which had previously encountered errors. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While deconfiguring an NI for a network that was being shut down, after first deleting the outbound buffer pool ID from the NS Registry, NETCP encountered an error trying to delete the buffer pool itself (PARM = 32-bit status returned by the call to bmgr_delete_pool).

ACTION: This error was not fatal, and network shutdown continued. However, the amount of system memory used by the pool may be inaccessible until the next system restart. Probably some buffers for the pool were lost, or are still outstanding in link drivers or in Transport modules which had previously encountered errors. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

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 an SR ”A of this manual.

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 an SR ” of this manual.

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 an SR ” of this manual, to report a problem against the general protocol module which is failing to reply.

CAUSE: While processing a Path Verify operation because NETCP detected a possible problem or change in state of a certain network, or because of a Path Verify message received from IPU in response to a redirect packet IPU received from a GATEWAY, NETCP encountered an error trying to send a Path Verify message to one of the general protocols (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error was not fatal; messages were sent to all the other general protocols, and NETCP will not expect a reply for the send that failed. However, the affected protocol module will not be aware there may be a problem with the path, and may continue to try to use it. If NETCP tracing was active, the tracefile will show the message which could not be sent, and the interface code in that message will indicate which module was not accessible. If the problem happens frequently, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a Path Verify operation because NETCP detected a possible problem or change in state of a certain network, or because of a Path Verify message received from IPU in response to a redirect packet IPU received from a GATEWAY, NETCP encountered an error trying to send a path verify message to the ICMP Server module of Transport (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error was not fatal; messages were sent to all the general protocols, and NETCP will not expect a reply to the send that failed. However, the ICMP Server module will not be aware there may be a problem with the path, and may continue to try to use it. In addition, PING commands from NETTOOL may report errors against the affected network. If the problem persists, see Appendix A “Submitting an SR ”A of this manual.

CAUSE: While processing a :NETCONTROL STOP command or a system shutdown, NETCP encountered an error trying to send a DCN stop message to the IPU module of Transport (PARM = 32-bit status returned by the call to send_msg). A DCN stop message is required for a Directly Connected Network such as X25.

ACTION: This error in itself was not fatal, and shutdown may continue. However, some versions of Transport may hang if this problem occurs or if the IPU module initially failed to start (see error 654), 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 an SR ” of this manual.

CAUSE: While attempting to send a device stop message to notify the DIAL module that an existing ROUTER network was being shut down, because of a :NETCONTROL DELLINK command or a previous asynchronous link error, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: The error in itself was not fatal, and shutdown of this network probably continued, ending with deletion of this instance of the DIAL module. However, DIAL was not notified the device has stopped, which may have caused more errors if it happened to run again before it was deleted. In addition, 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 an SR ” of this manual.

CAUSE: While processing an asynchronous event message from the DCLDM indicating that its LAPB PSI link either experienced a problem related to autodial, or else that an autodial succeeded, NETCP encountered an error trying to send a reply message back to DIAL telling the type of event that occurred (PARM = 32-bit status returned by the call to send_msg).

ACTION: DIAL did not receive the reply message, and will be unaware of the results of the autodial operation. It may take up to 30 minutes for DIAL to time out and reset itself, and during this delay, new autodial connections cannot be established, and sessions which attempt it may hang. To clear this condition, first try a :NETCONTROL DELLINK=linkname; NET=niname command against the affected link, followed by a :NETCONTROL ADDLINK=linkname; NET=niname. If this does not help, a system restart will probably be required to clear the hang. If the problem occurs again, take a dump when the error is reported and before any attempts to recover, and see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous exception event message from a link driver, but no device having the SDI link ID in that message was found in NETCP's device tables (PARM = 32-bit SDI device ID from the message).

ACTION: Either the driver or NETCP are confused. Though NETCP may continue working, the affected network will most likely hang, possibly requiring a system restart to recover. See Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send a debug message to one of the Transport protocol modules in response to a :NETCONTROL DIAG command, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error was not fatal, and NETCP continued running. However, the desired module did not receive its debug message, and will not respond as expected. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a :NETCONTROL DELLINK command, and trying to send a DCN stop message to the IPU module of Transport because at least one network link was active, NETCP encountered an error on the send (PARM = 32-bit status returned by the call to send_msg). A DCN stop message is required for a Directly Connected Network such as X25.

ACTION: This error in itself was not fatal, and the operation may continue. However, some versions of Transport may hang if this problem occurs or if the IPU module initially failed to start (see error 654), 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 an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL START command was starting a new instance of Transport, NETCP successfully started some modules, then encountered an error trying to initialize the NETIPC Socket Timers module (PARM = 32-bit status returned by the call to sk_ti_start). May be preceded by another error from NETIPC, logging the reason for the original failure.

ACTION: Newer versions of Transport treat this as a fatal error, and Transport startup will fail. For older versions of Transport this error was not fatal, and startup will continue, but NETIPC and Sockets will not work correctly. It is possible Socket Timers encountered an unreported error during its last shutdown, and exited early without finishing. Try stopping and restarting transport. If the error still happens, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While waiting for a reply message, 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: It is not possible to tell from the console logging what function code NETCP received, however if disc logging was enabled, the entire received message was logged, which may aid debugging. The flow of normal NETCP operations has been interrupted, and a network hang may be imminent, especially if new :NETCONTROL commands are issued. It may be necessary to restart the system to clear this problem. See Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to send a reply message back to NETUI to complete the blocked :NETCONTROL START command that initially created NETCP, no entry named "NETUI" was found in the CM Port Dictionary to identify which session port number issued the command (PARM = 16-bit result code returned by the call to dict_find). Usually this means the user session which issued the command has somehow been aborted. The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport.

ACTION: If a system shutdown was being done, ignore this message. The network startup or shutdown should run to completion, and other network operations should continue to work normally. Otherwise, if it still exists, the user session which issued the command (typically the system console) may be hung. Since it also owns resources, it cannot be aborted, and a system restart will be needed to recover. You may attempt a network stop on another terminal, then restart the system and restart the network. In some versions of Transport, if this error occurs NETCP will accidentally send the reply to a random port number, and the effects of this are indeterminate. If the same problem happens again, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP detected an error or warning while attempting to stop the Net Timers module (PARM = 32-bit status returned by the call to nettmr_module_deconfig). Always preceded by other errors from Net Timers, indicating the cause of the original failure.

ACTION: This error in itself was not fatal, and shutdown continued. However, some system resources may be lost until after the next system restart. One possible cause would be if a tool has already been used to stop Net Timers, in which case NETCP cannot stop it; in this case ignore the error. Inspect the previous error, and if necessary, or if this problem occurs repeatedly, see Appendix A “Submitting an SR ”of this manual.

CAUSE: While stopping an NI due to a system shutdown or a :NETCONTROL STOP command, NETCP detected an error trying to delete the NI (PARM = 32-bit escape code returned by the call to ni_module_deconfig). Always preceded by another error from another entity (having a different Entity number, such as 151-160), indicating the cause of the original failure.

ACTION: This error in itself was not fatal, and shutdown continued. However, some system resources may be lost until after the next system restart. Inspect the previous error and if necessary, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While stopping an NI because a network was being shut down, NETCP tried to free a NIB (Network Interface Block) it had previously allocated for the NI, but was unable to locate that NIB in other NETCP tables (PARM = 32-bit address of the missing NIB).

ACTION: This error in itself was not fatal, and shutdown continued. However, NETCP may be confused. If the problem occurs repeatedly, see Appendix A “Submitting an SR ”A of this manual.

CAUSE: While initializing an NI for a network that was being started, NETCP was unable to read the global information record from the NETXPORT.NI.name path in the NMCONFIG file (PARM = 32-bit status returned by the call to nmconfgetdata).

ACTION: The NI did not start. Stop the network, run NMMGR, and check the NI configuration for the NI which did not start. Validate the file. Then restart the network. If the problem persists, the NMCONFIG file may be corrupt, or there may be a bug in the NMS subsystem, NMMGR, or NETCP; see Appendix A “Submitting an SR ” of this manual.

CAUSE: While stopping an NI because of a system shutdown or a :NETCONTROL STOP command, NETCP was unable to delete the port message pool it previously created for that NI and its attached protocols (PARM = 32-bit status returned by the call to purge_pool).

ACTION: This error in itself was not fatal, and shutdown continued. However, some amount of system memory that had been used by the message pool may be inaccessible until after the next system restart. If this problem happens repeatedly, there may be an operating system problem or a bug in NETCP; see Appendix A “Submitting an SR ” of this manual.

CAUSE: While initializing a new NI for a network that was being started, NETCP successfully created a port message pool for use by that NI and its attached protocols, but was unable to put the pool ID into a new entity named "IP-NI" in the NS Registry (PARM = 32-bit status returned by the call to reg_add_entity).

ACTION: This error was not fatal, and startup continued; use of the Registry here is not critical. However, creation of the NS Registry by NETCP may have failed (see error 285), or the Registry may be full. If the message occurs every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down an NI due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error while trying to stop one of the NI specific protocols for that network (PARM = 32-bit escape code returned by the call to the module deconfigurator that failed). Always preceded by another error from another entity (having a different Entity number, such as 151-160), indicating the cause of the original failure.

ACTION: This error in itself was not fatal, and shutdown continued. However, some system resources may be lost until the next system restart. Inspect the previous error, and if necessary see Appendix A “Submitting an SR ” of this manual.

CAUSE: While reading the home node's path report during initial NETCP startup, or while starting some network specific protocols for a LAN, GATEHALF or ROUTER network because a :NETCONTROL command was issued, NETCP successfully read local node name data from the NMCONFIG file, then encountered an error trying to write that data into a buffer it obtained a short time earlier (PARM = 32-bit status returned by the call to bmgr_write_buffer).

ACTION: NETCP was unable to write all the required data, and attempted to recover and free the buffer. The network operation that was being performed will not work correctly. Because the buffer given to NETCP by the buffer manager should have been large enough to contain all data that was to be written, there may be a problem in either NETCP, the buffer manager, the NMS subsystem, or NMMGR, or the NMCONFIG file may be corrupt. Stop the network and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After successfully building a buffer containing needed configuration data for an X25 network that was being started, NETCP encountered an error trying to send the buffer to the X25 protocol module (PARM = 32-bit status returned by the call to send_msg).

ACTION: X25 did not receive its configuration data, though the rest of network startup continued. The X25 network will not operate correctly in this condition. In addition, the buffer may have been lost, which may result in error 613 when the network is stopped. Try stopping and restarting the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During the final phases of shutdown because of a :NETCONTROL STOP command or a system shutdown, NETCP encountered and error while attempting to stop the ICMP Server module it previously started (PARM = 32-bit status returned by the call to icmp_server_module_deconfig)

ACTION: This error in itself was not fatal, and shutdown continued. However, any system resources owned by the ICMP Server may be lost until after the next system restart. If this problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP encountered an error trying to start the TCP protocol module (PARM = 32-bit status returned by the call to tcp_module_config). Always preceded by another error from another entity (having a different Entity number, such as 151-160), logging the reason for the original failure.

ACTION: None of the general protocols were started, so Transport will not work. Older versions of Transport will improperly continue the startup after this error, and may also hang when stopped. Record the previous error and this error. Stop the network. If there is no hang, then try restarting the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP encountered an error trying to start the UDP protocol module (PARM = 32-bit status returned by the call to tcp_module_config). Always preceded by another error from another entity (having a different Entity number, such as 151-160), logging the reason for the original failure.

ACTION: Some of the general protocols were started, but Transport will not work. Older versions of Transport will improperly continue the startup after this error, and may also hang when stopped. Record the previous error and this error. Stop the network. If there is no hang, then try restarting the network. If this problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP encountered an error trying to start the PXP protocol module (PARM = 32-bit status returned by the call to tcp_module_config). Always preceded by another error from a different entity (having a different Entity number, such as 151-160), the configurator, logging the reason for the original failure.

ACTION: This error in itself was not fatal, and general protocol startup continued. However, dynamic name resolution will fail. To clear the problem, stop then restart the network. If this problem persists, record the previous error and this error, then see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP encountered an error trying to start the IPU (IP Update) module (PARM = 32-bit status returned by the call to tcp_module_config). Always preceded by another error from another entity (having a different Entity number, such as 151-160), logging the reason for the original failure.

ACTION: The general protocols were started, but Transport will not work. Older versions of Transport will improperly continue the startup after this error, however path resolution will fail, and Transport may also hang when stopped. Record the previous error and this error. Stop the network. If there is no hang, then try restarting the network. If the error still occurs, a common cause is that NMMGR "Unguided Confide" mode was, at some time in the past, used to create the first NS configuration ever put into the NMCONFIG file, and that a bug in the Validation function of an earlier version of Transport then corrupted a hidden record in that file, which specifies IPU startup information.

If you suspect "Unguided Config" mode was used, you can try to repair the hidden record. First make a copy of the old NMCONFIG file. Then one way to fix it is to purge and recreate the entire file using "Guided Config" mode. If your file is complicated, you may first want to try another way, which is to create a new dummy file named, say, NMCONFGT, and using "Guided Config" mode, configure any network NI (for instance, a dummy LAN network). Then reopen the original NMCONFIG file and use the "Copy Subtree" utility function to copy the NETXPORT.GPROT.IPU path, out of the dummy NMCONFGT file and into NMCONFIG, overwriting the existing subtree. Then try restarting the network. If the error goes away, you can purge NMCONFGT. But if the same error still happens, there may be more corruption in the file than just that one record; try recreating the entire file, but using "Guided Config" mode wherever possible.

If, after recreating or attempting to repair the file, the problem still persists, there is most likely a bug in Transport; see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP successfully started some modules, then encountered an error trying to start the ICMP (PING) Server module (PARM = 32-bit escape code returned by the call to pxp_module_config). Always preceded by another error from another entity (having a different Entity number, such as 151-160), logging the reason for the original failure.

ACTION: This error in itself was not fatal, and general protocol startup continued. However, the PING service will not be available, and pings from other nodes will go unanswered. To clear the problem, stop then restart the network. If this problem persists, record the previous error and this error, then see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP successfully started some modules, then encountered an error trying to start the Net Timers module (PARM = 32-bit status returned by the call to nettmr_module_config). Always preceded by another error from Net Timers, logging the reason for the original failure.

ACTION: TCP and ARP will not work without timers. Some versions of Transport will erroneously continue the startup after this error. Record the previous error and this error. Stop the network. Then try restarting the network. If the problem still occurs, then depending on the error, it is possible too much frozen memory is being used by the system, but this can change with time. Use GLANCEXL or a similar utility to check memory usage by the system. If memory is not the cause and the problem persists even if retried after a suitable waiting period, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all the general protocols because a :NETCONTROL command was starting a new instance of Transport, NETCP successfully started some modules, then encountered an error trying to create the Socket Registry (PARM = 16-bit result code returned by the call to sock_registry_create). May be preceded by another error from NETIPC, logging the reason for the original failure.

ACTION: Newer versions of Transport treat this as a fatal error, and Transport startup will fail. For older versions of Transport this error was not fatal, and startup will continue, but NETIPC and Sockets will not work correctly. It is possible the Socket Registry encountered an unreported error during its last shutdown. Try stopping and restarting transport. If the error still happens, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While attempting to start all network specific protocols, required for a given network, such as IP, because a :NETCONTROL command was issued, NETCP encountered an error, either from a protocol's module configurator, or while trying to rendezvous a protocol to the link driver. (PARM = 32-bit status returned by the call to a module configurator, or from cp_rendezvous_protocol). May be preceded by another error from another module, logging the reason for the original failure.

ACTION: The general protocols were started, but the specified network did not start, and NETCP attempted to stop the partially started network and any network specific protocols which did start. Retry the operation. If the problem still occurs, stop and restart Transport. If the problem still persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After an error occurred while NETCP was attempting to start network specific protocols for a given network, NETCP attempted to clean up by stopping any of those protocols which did start, but then encountered another error when calling a protocol module deconfigurator (PARM = 32-bit status returned by the call to a module deconfigurator, or from cp_rendezvous_protocol). Should always be preceded by other errors, logging the reasons for the original failures.

ACTION: This secondary error is not the main concern, though it may indicate additional problems. The general protocols were started, but the specified network failed to start because of the first error. Retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While stopping an X25 network because of a system shutdown, or a :NETCONTROL STOP command for one or all networks, NETCP first stopped all devices before stopping any protocols, then encountered an error trying to delete a CM Port Dictionary entry it had previously added to keep track of one of the X25 device ports (PARM = 16-bit result code returned by the call to dict_delete). The CM Port Dictionary is an operating system lookup service used by, but not part of, Transport. There should be one entry per X25 device, named "X25.linkid", where "linkid" consists of 4 unprintable bytes defining the binary SDI link ID for that link, dynamically assigned by the Link Support Services subsystem.

ACTION: This error in itself was not fatal, and network shutdown continued. No resources were lost. If the problem happens every time, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After successfully starting a LAN 802.3 or Ethernet link and all its network specific protocols because a :NETCONTROL command was issued, NETCP encountered an error trying to send a broadcast information message to the UDP protocol module (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error in itself was not fatal, and network startup continued. After this failure, most of Transport, with the exception of UDP, will probably run correctly. However, certain actions, such as Path Verifies, can indirectly result in more sends to UDP, which may cause more errors. When convenient, try stopping Transport using :NETCONTROL STOP, then restart it and bring up the LAN link again. If the same problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While starting Transport's first active X25 NI because a :NETCONTROL command was issued, NETCP encountered an error trying to start the X25 Flow Control Manager (PARM = 32-bit status returned by the call to netfc_config). NETCP keeps track of the number of X25 networks started, and only makes this call then starting the first one. The Flow Control Manager dynamically allocates the flow control buffer pools for X25.

ACTION: This error in itself was not fatal, and network startup continued. However, X25 may not operate correctly. If X25 connections are not working, stop then restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After successfully starting a TOKEN link and all its network specific protocols because a :NETCONTROL command was issued, NETCP encountered an error trying to send a broadcast information message to the UDP protocol module (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error in itself was not fatal, and NETCP startup continued. After this failure, most of Transport, with the exception of UDP, will probably run correctly. However, certain actions, such as Path Verifies, can indirectly result in more sends to UDP, which may cause more errors. When convenient, try stopping Transport using :NETCONTROL STOP, then restart it and bring up the TOKEN link again. If the same problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a :NETCONTROL STATUS command, NETCP encountered an error trying to send a reply message back to the NETUI module (PARM = 32-bit status returned by the call to send_msg).

ACTION: This error in itself was not fatal, and Transport should continue to run. However, if the session which issued the :NETCONTROL STATUS command still exists, that session will now be hung. If the session does not exist, this also indicates a bug since supported HP commands to abort the session should have been disabled by NETUI. A system restart will be required to clear the session's hang. If the session is on the system console, a :CONSOLE command may be attempted to temporarily move the logical console to another terminal until a system restart is convenient. If the problem persists, issue a :NETCONTROL TRACEON=MHDSBN command beforehand, to enable NETCP tracing which may capture the problem. When the problem occurs, issue a :NETCONTROL TRACEOFF command from another terminal, then take a system dump and send in the dump and the resulting trace file; see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a :NETCONTROL STATUS command which reported an error because a requested module was not active, or because no buffer was available to hold excess error information, NETCP then encountered another error while trying to send a reply message about the first error, back to the NETUI module (PARM = 32-bit status returned by the call to send_msg). The cause of the first error cannot be determined, except if NETCP message tracing was enabled, the message was traced.

ACTION: The second error in itself was not fatal, and Transport should continue to run. However, if the session which issued the :NETCONTROL STATUS command still exists, that session will now be hung. If the session does not exist, this also indicates a bug since supported HP commands to abort the session should have been disabled by NETUI. A system restart will be required to clear the session's hang. If the session is on the system console, a :CONSOLE command may be attempted to temporarily move the logical console to another terminal until a system restart is convenient. If the problem persists, issue a :NETCONTROL TRACEON=MHDSBN command beforehand, to enable NETCP tracing which may capture the problem. When the problem occurs, issue a :NETCONTROL TRACEOFF command from another terminal, then take a system dump and send in the dump and the resulting trace file; see Appendix A “Submitting an SR ” of this manual.

CAUSE: While processing a request sent by the DIAL protocol module because a LAPB autodial link is being connected, NETCP encountered some kind of error (such as errors 315, 316, 322), then encountered a second error trying to send the bad reply message back to DIAL to report the first error (PARM = 32-bit status returned by the call to send_msg).

ACTION: Since DIAL never received its reply, it may take up to 30 minutes for DIAL to time out and reset itself, and during this delay, new autodial connections cannot be established, and sessions which attempt it may hang. To clear this condition, first try a :NETCONTROL DELLINK=linkname; NET=niname command against the affected link, followed by a :NETCONTROL ADDLINK=linkname; NET=niname. If this does not help, a system restart will probably be required to clear the hang. If the problem occurs again, take a dump when the first error 669 is reported and before any attempts to recover, and see "Submitting an SR" in appendix A of this manual.

CAUSE: While bringing down a device because of a serious asynchronous error, powerfail, or a :NETCONTROL DELLINK command, NETCP encountered an error trying to send a Path Verify message to the UDP protocol module (PARM = 32-bit status returned by the call to send_msg). The message was to have told UDP to discard cached paths.

ACTION: In this case UDP will continue to function, but may be unable to reach some destinations. If you cannot reach needed UDP destinations then you will need to restart Transport. This is not generally a fatal error, however some versions of Transport may accidentally hang if this error appears. If the problem occurs repeatedly, see Appendix A “Submitting an SR ” of this manual.

CAUSE: During startup of the SNMP module, the configuration file was unlocked. But afterwards, NETCP tried for up to 2 minutes to lock the file again without success (PARM = status from NMConflockfile). The 2-minute timeout is not configurable.

ACTION: Network startup was incomplete. Stop the network. Use :LISTF NMCONFIG.PUB.SYS,3 to verify the NMCONFIG file exists and is not opened. If any users are currently running NMMGR, ask them to exit. Then restart the network. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While bringing down a device because of a serious asynchronous error, powerfail, or a :NETCONTROL DELLINK command, NETCP encountered an error when attempting to separate one of the active protocols from the link driver (PARM = 32-bit status returned by the call to ns_separate_from_driver).

ACTION: This in itself was not a fatal error, and other device stop actions continued. However, either the DCLDM or the link driver may have failed, which indicates a problem. No additional NETCP logging or tracing information is available, though if problems continue, DCLDM tracing and link tracing can be used to either follow the separate request downward and locate the point where errors occur. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: NETCP received an asynchronous event message from the DCLDM indicating that its LAPB PSI's autodial operation was not completed, because the cable attached to the PSI card is not the proper cable required for autodial operations (PARM = 16-bit internal ldev number of the device). Older versions of Transport may print different messages for this error, such as "OUTBOUND; occupied" or "INTERNAL ERROR; Auto dial failure", though the actual problem is the cable.

ACTION: Install the correct cable and retry the operation. If the problem persists then see Appendix A “Submitting an SR ” of this manual.

CAUSE: While awaiting Path Verify replies from all general protocols in response to requests sent previously, NETCP received a new message on the control or reply subqueues of its port, which was not one of the expected replies. NETCP then encountered an error while trying to requeue that request for later processing, by resending it to itself (PARM = 32-bit status returned by the call to send_msg).

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.

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.

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, which may aid in debugging any hung modules. If the problem occurs repeatedly or a general protocol bug is suspected, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While reading the home node's path report during initial NETCP startup, or while starting some network specific protocols for a LAN, GATEHALF or ROUTER network because a :NETCONTROL command was issued, NETCP encountered error when trying to compute the total length of some NMCONFIG file data, prior to getting a buffer large enough to hold all that data (PARM = 32-bit status returned by the call to nmconfdatalength).

ACTION: You may have attempted to configure a larger network than is currently supported by Transport; save a copy of your current NMCONFIG file, then reduce the size of your configuration and try the operation again. If your network is small and you therefore do not suspect size as the cause, there may be some problem with the NMS subsystem, NMMGR, or NETCP, so see Appendix A “Submitting an SR ”of this manual.

CAUSE: While reading the home node's path report during initial NETCP startup, or while starting some network specific protocols for a LAN, GATEHALF or ROUTER network because a :NETCONTROL command was issued, NETCP successfully read path report data from the NMCONFIG file, then encountered an error trying to write that data into a buffer it obtained a short time earlier (PARM = 32-bit status returned by the call to bmgr_write_buffer).

ACTION: NETCP was unable to write all the required data, and attempted to recover and free the buffer. The network operation that was being performed will not work correctly. Because the buffer given to NETCP by the buffer manager should have been large enough to contain all data that was to be written, there may be a problem in either NETCP, the buffer manager, the NMS subsystem, or NMMGR, or the NMCONFIG file may be corrupt. Stop the network and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While reading X25 configuration data because a :NETCONTROL command was issued, NETCP successfully read X25 data from the NMCONFIG file, then encountered an error trying to write that data into a buffer it obtained a short time earlier (PARM = 32-bit status returned by the call to bmgr_write_buffer).

ACTION: NETCP stopped trying to load additional X25 data; some required data may not have been loaded, but startup of that network probably continued. Some or all X25 nodes may not be accessible. Because the buffer given to NETCP by the buffer manager should have been large enough to contain all data that was to be written, there may be a problem in either NETCP, the buffer manager, the NMS subsystem, NMMGR, or the NMCONFIG file may be corrupt. Use NMMGR to check the X25 configuration in the file. Stop the network and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While reading X25 configuration data because a :NETCONTROL command was issued, NETCP successfully computed the size of all applicable X25 data in the NMCONFIG file, then encountered an error trying to write a small descriptive header onto the start of a a buffer it obtained a short time earlier to hold all the X25 configuration data (PARM = 32-bit status returned by the call to bmgr_write_buffer).

ACTION: No X25 data was actually buffered, and NETCP attempted to recover and free the buffer. Though startup of that X25 network probably continued, the network will not operate correctly. Because the buffer given to NETCP by the buffer manager should have been large enough to contain all data that was to be written, there may be a problem in either NETCP, the buffer manager, the NMS subsystem, NMMGR, or the NMCONFIG file may be corrupt. Stop the network and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After NETCP successfully wrote configuration data for an X25 network into a buffer it obtained earlier, because a :NETCONTROL command was issued, while trying to crossmatch the X25 mappings NETCP encountered an error trying to read a data entry out of that same buffer (PARM = 32-bit status returned by the call to bmgr_read_buffer).

ACTION: The current matching operation stopped, then more merging of X25 mappings may have continued, possibly causing more errors, then the bad configuration data was passed to the X25 protocol module. The X25 network will probably not operate correctly now. Because NETCP already wrote to the buffer, it should have also been able to read from it; probable causes are a bug in NETCP or in the buffer manager. Stop the network and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After NETCP successfully wrote configuration data for an X25 network into a buffer it obtained earlier, because a :NETCONTROL command was issued, while trying to crossmatch the X25 mappings NETCP successfully read one data entry out of that buffer, then encountered an error trying to read other data entries to match up to the first one (PARM = 32-bit status returned by the call to bmgr_read_buffer).

ACTION: The current matching operation stopped, then more merging of X25 mappings may have continued, possibly causing more errors, then the bad configuration data was passed to the X25 protocol module. The X25 network will probably not operate correctly now. Because NETCP already wrote to the buffer, it should have also been able to read from it; since it already read once, this indicates a probable bug in NETCP. Stop the network and retry the operation. If the problem persists, see Appendix A “Submitting an SR ” of this manual.

CAUSE: After successfully opening the NSDIR network directory file, while preparing to read X25 network directory information from the file, NETCP was unable to obtain a buffer from its own buffer pool large enough to hold the maximum possible number of X25 mapping entries (PARM = 32-bit status returned by the call to bmgr_get_buffer). The size of the buffer NETCP tried to obtain was based on the size of the mapping table, a value which was obtained from a hidden field in the NI record of the NMCONFIG file.

ACTION: No network directory data was read, and NETCP attempted to recover and close the opened file. Some versions of transport may then attempt to build X25 mappings, even though no buffer was obtained, and send a restart message to X25. After the error, network startup may continue to completion, but the resulting network will probably not operate correctly. Verify you have all the required patches, especially a coherent set of patches required to support 2048 X25 SVC paths under NMMGR and NS Transport. Also verify that the number of X25 paths configured in the NMCONFIG file is within the supported limits. If the problem still cannot be found, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While starting or updating a ROUTER network, because a :NETCONTROL command was issued, NETCP successfully started a LAPB link device, then encountered an error trying to read information from the NMCONFIG file about the number of mappings in that NI, prior to actually loading the mappings (PARM = 32-bit status returned by the call to nmconf3soninfo).

ACTION: No mapping entries were read, and though network startup probably continued to completion without a command error, you will not be able to connect to any remote nodes configured in the mapping entries. Verify you have a coherent set of patches installed, especially between Transport and NMMGR, and especially if your NMCONFIG file contains a large number of ROUTER mappings. Try stopping and restarting the network. If the problem persists, you may have a software installation problem, a bug in the NMS subsystem, or a corrupt NMCONFIG file; if necessary, see Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, NETCP encountered an error trying to delete the NETIPC Socket Registry module (PARM. (0:16) = error location within SOCKREG.NET.SYS and PARM. (16:16) = error status from SOCKREG).

ACTION: This error in itself was not fatal, and shutdown continued. However, depending on the error it may not be possible to restart Transport without first restarting the system. See Appendix A “Submitting an SR ” of this manual.

CAUSE: While shutting down Transport due to a system shutdown or a :NETCONTROL STOP command, after attempting to delete the NETIPC Socket Registry module, NETCP discovered a CM Port Dictionary entry named "SOCKREGISTRY" had not been deleted (PARM = 32-bit port number of the SOCKREG.NET.SYS process which failed to delete the entry).

ACTION: This error in itself was not fatal, and shutdown continued. However, the entry should have been deleted, and now it will not be possible to restart Transport without first restarting the system. See Appendix A “Submitting an SR ” of this manual

CAUSE: While starting an X.25 network due to a :NETCONTROL START command, or while updating it due to a :NETCONTROL UPDATE command, NETCP found that none of the X.25 address keys in the Network Directory file matched any keys in the NMCONFIG file's SVC or PVC configurations for that X.25 network (PARM = 0).

ACTION: This error in itself was not fatal, and startup continued. However, outbound connections cannot be initiated using this X.25 network. Stop the network and use NMMGR to ensure the address keys in the "Additional Address" field of X.25 Network Directory entries match "X.25 Address Key" fields in the NETXPORT.NI.name.PROTOCOL.X25.SVCPATH (or PVCPATH) screens of the NMCONFIG file. If this does not solve the problem, see Appendix A “Submitting an SR ” of this manual.