Troubleshooting
Problem
This document explains one cause of an IBM iSeries NetServer drive failure to map due to an older, incorrect version or damaged user index QUSRSYS/QYSMSVRE.
Resolving The Problem
After upgrading the IBM i5 operating system, clients attempting to use the IBM iSeries Support for Windows Network Neighborhood (IBM i NetServer) might be able to locate the IBM i NetServer but not map a drive or access the shares. Some versions of Windows can time out after a minute or two and report the following error:
Specified network name is no longer available.
NETSTAT will show that the IBM i NetServer ports (137-139, 445) are active and in listen state. No QZLSFILE jobs appear to be started even though they are available in PSRW state. No error messages appear in QSYSOPR.
Communication traces will show a timeout on the TreeConnect request:
R SessSetup and TreeConnect for a share
... <one minute>
R ECHO
S ECHO
R Disconnect (for the IPC$ logon that worked)
S Disconnect
R FIN ACK
If the trace is allowed to run long enough (5 minutes or so), a reply of error class 0x02 and an error of 0x0041 can be seen.
Currently supported IBM i versions generate VLOG VL4400000B for this error (any error involving QYSMPUT).
Problem Resolution
The problem occurs when the object QUSRSYS/QYSMSVRE is at an older, incorrect version or is damaged. The most common cause of the problem is an incorrect upgrade or restore of library QUSRSYS.
To recover, delete the user index QUSRSYS/QYSMSVRE and retry. The object will re-create on first use.
Note: Any customization of subsystem usage for any host server will be lost and must be reconfigured.
For further information about how to properly restore QUSRSYS, see the Save Restore manual.
NETSTAT will show that the IBM i NetServer ports (137-139, 445) are active and in listen state. No QZLSFILE jobs appear to be started even though they are available in PSRW state. No error messages appear in QSYSOPR.
Communication traces will show a timeout on the TreeConnect request:
R SessSetup and TreeConnect for a share
... <one minute>
R ECHO
S ECHO
R Disconnect (for the IPC$ logon that worked)
S Disconnect
R FIN ACK
If the trace is allowed to run long enough (5 minutes or so), a reply of error class 0x02 and an error of 0x0041 can be seen.
Currently supported IBM i versions generate VLOG VL4400000B for this error (any error involving QYSMPUT).
Problem Resolution
The problem occurs when the object QUSRSYS/QYSMSVRE is at an older, incorrect version or is damaged. The most common cause of the problem is an incorrect upgrade or restore of library QUSRSYS.
To recover, delete the user index QUSRSYS/QYSMSVRE and retry. The object will re-create on first use.
Note: Any customization of subsystem usage for any host server will be lost and must be reconfigured.
For further information about how to properly restore QUSRSYS, see the Save Restore manual.
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CLSAA2","label":"Integrated File System-\u003ENetServer"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
29342515
Was this topic helpful?
Document Information
Modified date:
25 October 2024
UID
nas8N1016699