When you deploy a COBOL application as a Web Service or an Enterprise JavaBean, then run it using the default configuration of Enterprise Server, it can no longer open files across a network using drive mappings or UNC paths (that is, file pathnames of the form \\server\share\path\to\file). This is the result of Windows working the way it was designed to and there is no simple workaround that is satisfactory for every customer.
When a program opens a file on another computer (the file server) using a UNC path, Windows uses that program's current security information to try to authenticate it to the server and obtain authorization from the server for access to the file. If the file server does not accept the program's security credentials, the program cannot open the file. These credentials include user login information (the equivalent of a username and password) and other technical details including whether the credentials can be used for network access. If an interactive user runs a program from the desktop or command line, that process runs with the user's credentials. When the program attempts to open a file on a file server, the user's credentials are checked for access.
When a drive letter is mapped to a network share and used to open a file, Windows uses the same mechanism as for UNC paths. However, a drive letter mapping generally applies only to a specific user. A different user on the same computer can have that drive letter mapped to a different share or not mapped at all.
This means that UNC paths represent the same file for every program, no matter which user account the program is running under but that drive letter mappings can vary and are less likely to work when a program is run by different users. In general, UNC paths are more suitable for filenames that are stored in programs or saved somewhere and drive letter mappings are more suitable for interactive use. [1052982]