Applies To:
  • CitectSCADA 5.xx

Referencing UNC paths from Citect on a Windows NT LAN/WAN where Novell Netware is installed may cause repeated 30 to 60 second long hang-ups if Citect workstations are allowed to sit idle for more than 15 minutes.

During these hang-ups, Citect will appear to stop responding completely and IOservers will stop serving data. After the hang-up, everything appears to return to normal. Hardware alarms and Kernel data give no clear indication of source or cause. Furthermore, NT Task Manager / Performance Monitor will indicate lower than normal CPU utilization (perhaps as low as 1 to 3%).

Background information: See Microsoft Knowledge Base articles Q150807
and Q171386

In brief: This is a result of the way Windows NT's Multiple UNC Provider ("MUP") interacts with the two File Redirectors (Microsoft's and Novell's). The MUP will determine which File Redirector is best suited to resolve (handle) the UNC path.  This request/response cycle takes at least 30 seconds.  Once the determination is made, the status is held in a memory cache for only 15 minutes after the last access request.  After the 15 minute idle period, that memory cache is flushed, and the whole cycle is repeated the next time Citect (or any Windows application for that matter) requests something over that UNC path.

Important note: Microsoft claims that this problem has been improved or fixed in NT Service Pack 4, however this behavior was observed on a PC running NT Service Pack 5. Microsoft also outlines a registry hack that is supposed to improve performance. Unfortunately it made no visible difference on the system in this case study either.  Furthermore, the registry hack outlined in Citect Knowledge Base Q1949, though it sounds related, has no bearing on this problem. 

When implementing Citect on an NT network where Novell Netware is installed, avoid using UNC path references if at all possible.  Instead, simply map network drive letters to all necessary (shared) network resources, then hard-code those drive letters into the Citect project and CITECT.INI file (Setup Wizard).  Since the path validity of a mapped network drive is checked only at the time of creation, and assumed good thereafter, application references to that path are typically as fast as the network bandwidth will allow.

This problem is very unusual and highly situational, and your results may vary. Fortunately, the solution is very simple and quite effective.