If your scheduled programs need access to files on network devices, please make sure you understand the information presented here.
There are two approaches applications typically use for referring to network resources.
The preferred approach is to refer to the resource using its UNC designation. If your program needs to read the file data1.dat on share proddata on server prod1, it would refer to the file as \\prod1\proddata\data1.dat.
Unfortunately many applications—especially those that were not originally developed with batch execution in mind—use drive letter mappings instead. In this approach, the application relies on a particular drive letter being mapped to the network resource.
For example, using our resource from the previous example, the drive letter K: is mapped to \\prod1\proddata\. The application then refers to the file as K:\data1.dat.
Drive letters may be mapped using Windows Explorer, through batch files (using the net use command).
The most important thing to understand about drive letter mappings is the fundamental contradiction in the way they work under Windows:
Drive letter mappings are stored as part of the user profile of the user that created them. The mappings are only made when that user is logged in to the computer interactively (that is, directly logged in to the computer).
Even though the drive letter assignments "belong" to a particular user, they affect the entire computer. Two user sessions cannot be using the drive letter at the same time to point to two different network resources. And generally (but not always), while the user is logged in, the drive letter mappings are available to all users (including programs being run by adTempus under another user's account).
This leads to the following common scenario: Your application runs fine when you run it manually. You schedule it to run under adTempus and test it; it appears to work fine. You log out and go away for the evening and when the program runs at midnight it fails, because it's relying on a drive letter mapping that's part of your user profile. You're not logged in, so the drive letter does not exist.
|
|
When adTempus runs a job under your user account, it logs you in and loads your user profile. It does not however, automatically load the drive letter mappings associated with your profile (because what if another user is already sitting at the computer, with the drives mapped the way they want them, or another job is running under a different account). So when it comes to network connections, adTempus logging you in is not the same as you logging in to the computer yourself. |
We strongly recommend that, if it is at all possible, you change your applications to use UNC paths instead of drive letter mappings.
If you must use a mapped drive letter:
Do not count on drive letters that are mapped when you're sitting at the computer being valid when the job is run.
You must instead map the required drive letters as part of the job. Use Network Resources (specified on the Resources page for the job) to do this.
When you are assigning drive letters for the job, remember:
If the drive letter is already in use, adTempus will not be able to reuse it. If the drive letter K: is ordinarily mapped while you are logged in, do not use this drive letter for your job, or the job will fail if you are logged in (because the drive letter will already be in use).
Jobs running under the same user account can share drive letters (if they are mapped to the same resource).
