cahill@dit.ie (02/02/90)
In article <213.25c4249b@acci.com>, ta2@acci.com writes: > I got tossed a Tech Support question about my client's product as > it runs on 3Com (3Plus I believe.) We have absolutely no information > about 3Com... > > I have been told that the application program does not "unlink" at > program exit. What does this mean? > > In other words - what do the terms "link" and "unlink" mean in the > context of a 3Com network? > In article <213.25c4249b@acci.com>, ta2@acci.com writes: > I have been told that the application program does not "unlink" at > program exit. What does this mean? > > In other words - what do the terms "link" and "unlink" mean in the > context of a 3Com network? > 3+File LINK (3F LINK) maps part of the server file area to a virtual drive e.g. A>3f link f: \\sys\msword will assign virtual drive f: to a server file area where MSWORD lives. where: 3f is the 3Plus program link is a 3f command f: is the virtual drive \\sys\msword is a 3+ SHARENAME that maps to a directory on the server. (format is: \\user\name in this case sys is the SERVER user (a special user). Users can set up their own SHARE names and these will be referenced by prefixing the user name to make them unique. To run an application the following cycle is usually performed: 3f link f: \\user\application f:application 3f unlink f: where f: is a virtual drive. I think your problem is that a drive is being linked for the application and not being unlinked, later somebody expects this drive to be linked to some where else. To avoid this type of problem adopt a few simple conventions to achieve consistency. 3Com recommend the following: o Avoid link "real drives" e.g. floppy A, B or hard disc C: o Link as follows: Net drive SHARENAME Purpose D: \\sys\apps the top directory under which all applications software lives in separate subdirectories. E: home directory Users private file space on the server. A few conventions I decided on area as follows: o When running an application always link drive f: to where it resides. We use 3+Menus as the user interface and there is a facility for doing this. o Use APPEND and PATH to f: so that the application can always find its own program or data files if needed. Again in 3+Menus we invoke a batch file F.BAT and pass it the application name as the first parameter. F.BAT is: APPEND f: ! APPEND before PATH or PATH will dissappear PATH f: %1 %2 %3 %4 %5 ! run application with parameters (max=4) Most applications (not all) will gladly work this way and you don't need a special startup batch file for each one, f.BAT will do for most. The net drive f: is being reassigned (LINKED) differently for each application. If you are not using 3+Menus you could simply adapt f.bat I see only one problem: 3+Menus ensures that the PATH and APPEND assignments made by f.bat are only temporary and your original settings are preserved. How it does this I don't know but would be interested to find out. Normally if you run a batch job with such commands your original settings will be overwritten. Conor Cahill Dublin Institute of Technology cahill@dit.ie
dave@westmark.UU.NET (Dave Levenson) (02/02/90)
In article <213.25c4249b@acci.com>, ta2@acci.com writes: ... > I have been told that the application program does not "unlink" at > program exit. What does this mean? I'll take a stab at your question, but first, let me say that I'm assuming something about the context in which it was asked: I'm assuming that your application is running on a MS-DOS machine that is a client, and that the application creates a link to a shared resource (a shared directory or printer) on a server. Link is the operation that re-directs a device (such as D: or E: or LPT1:) to a shared resource. Unlink breaks the association -- i.e. it disassociates the local device name from the shared resource. In many lan installations, links are created when the client is booted, and remain up until the client is shut down. But if you have an application that performs its own link, then for completeness (finish what you started...) it probably ought to unlink before it exits. -- Dave Levenson Voice: (201 | 908) 647 0900 Westmark, Inc. Internet: dave@westmark.uu.net Warren, NJ, USA UUCP: {uunet | rutgers | att}!westmark!dave [The Man in the Mooney] AT&T Mail: !westmark!dave
alawlor@dit.ie (Aengus Lawlor) (02/02/90)
In article <7158.25c887bc@dit.ie>, cahill@dit.ie writes: > If you are not using 3+Menus you could simply adapt f.bat > I see only one problem: > > 3+Menus ensures that the PATH and APPEND assignments made by > f.bat are only temporary and your original settings are preserved. > How it does this I don't know but would be interested to find out. > Normally if you run a batch job with such commands your original > settings will be overwritten. 3+Menus runs COMMAND.COM with F.BAT as a parameter. COMMAND get a copy of 3+Menus Environment table, which F then alters. When F is finished, COMMAND exits back to 3+Menus, who's environment hasn't been altered. Using 3+Menus this way chews up a LOT of memory, and many applications will choke on this. To achieve the same effect without 3+Menus, copy your path to a temporary variable with SET TPATH=%PATH% If you invoke APPEND with the /E option the first time you run it(at least under DOS 3.3), you will get an APPEND environment variable which can be saved in the same way. SET TAPPEND=%APPEND% At the end of your batch job, set PATH %TPATH% APPEND %TAPPEND% SET TPATH= SET TAPPEND= > > Conor Cahill > Dublin Institute of Technology > cahill@dit.ie > -- Aengus Lawlor Dept of Computer Science. Time flies like an arrow, ALAWLOR@DIT.IE Dublin Institute of Technology. Fruit-flies like a banana Kevin Street. Dublin 8. Ireland.