>>This is not a problem with the use of UNCs; it has to do with how your Novell network is set up. Novell 3.1x and 4.x in bindery emulation mode requires you to log into the server, one server at a time, either by explicit login or attachment. Attempting to map a resource (printer or drive) or examine the details of shared resources on a Netware server forces the login, but a simple UNC reference does not. A Novell server managed through an NT domain or via NDS is logged in when the domain or tree is accessed, avoiding the problem neatly. If you ATTACH the servers in your NetWare login script (as opposed to actually mapping a resource) you'll find that UNCs for the Attached servers will resolve normally.
>>
>We are using NDS here (IntraNetware 4.11) BUT I'm not sure what the other servers here are using. I *think* they are using the same. I am aware that the problem seems to be native to Novell from previous discussions with people who have had no problems with this on NT. It's just that some of my applications only display info on success of IF FILE(...) - they don't work on my PC but do work on the PCs they are intended for. (I have NO drives mapped - to ensure that my apps work without them).

When logged in via NDS, a single point of login can provide login to multiple servers through the NDS tree, in much the same way that logging into a domain server provides login authentication to other systems within the domain with NT Server. If your end-users are using an NDS tree context that validates them to the servers involved, or they aren't using NDS but have the server in question as their Preferred Server, and you do not, this would explain the difference in behavior between their systems and yours.