Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!uwslh!lishka From: lishka@uwslh.slh.wisc.edu (a.k.a. Chri) Newsgroups: comp.sys.novell Subject: Re: Request for suggestions on NetWare mapping schemes Message-ID: <1991Mar15.184848.23449@uwslh.slh.wisc.edu> Date: 15 Mar 91 18:48:48 GMT References: <1991Mar12.230723.6040@uwslh.slh.wisc.edu> <1991Mar13.173901.17115@novell.com> Organization: Wisconsin State Laboratory of Hygiene Lines: 113 saddison@ca.excelan.com (Skip Addison) writes: >Most installations (that I'm aware of) put all or most of the application >drive mappings either in the system login script or in centrally-administered >batch files (located in SYS:PUBLIC or SYS:BATCH, for example). If you move >an application from SYS: to VOLA:, just change the drive mapping in that one >location. Users home and miscellaneous directories are often set up in the >system and user login scripts. They may need to be changed individually if >they're in the user login scripts. This is pretty much what we are doing, except that we cannot map a single drive to each application's directory in the system login script because we have more applications than the search drive limit allows. To get around this, we have batch files that evoke each major application (e.g. WP51.BAT and WP50.BAT) which first inserts a new search drive, then calls the application, and afterwards removes the search drive. This works fairly well, and does allow for the "changes in a single place", to some extent. >> (e) The users do not necessarily use the same PC all of the time; i.e. >> there is a lot of "floating" or "musical PCs" going on here. > >That's why the drive mappings should be in login scripts or elsewhere on the >file server. The drive mappings *ARE* in the system login script. The point of the above requirement was to indicate that there is no way to be sure who is using what type of hardware. This means that doing different drive mappings depending on the person logging in (which is a horrible idea anyway) would not work. I just wanted to ward off any suggestions like this. >> (f) We have quite a few programs that refer to directories and files >> only through drive letters (e.g. WordPerfect). > >That's why you HAVE drive mappings. Well, there *ARE* other ways to do it, and other operating systems utilize these other methods. I don't want to start an OS war, but other operating systems allow for more detailed volume names, host/directory specification, or other more flexible schemes. >>... However, programs like WordPerfect require that absolute >>references to directories on "drives" (or volumes) other than the >>current drive *must* be accessed through a drive letter, and will not >>work if a volume name is used ... > >You WANT it to work that way. Otherwise to change the volume for different >applications, you'd have to individually reconfigure each application, and >in some cases, each user's configuration file. OK, fair enough. However, my problem is that if I map Z: to always point to SYS: (i.e. MAP Z: = SYS:\) on our main server (call it SERVER-A), what happens when we get a second server, and users want to connect to *both* at the same time? If I use Z: to map to SYS:\ on the second server (call it SERVERB), then Z: will be mapped to whichever server the person *LAST* attached to (as far as I can see it). I could use a different letter (say, MAP Q: = SYS:\) on SERVERB, but what happens when a person attaches to a server outside our organization that already *has* a Q:? Using a specific drive letter for a map automatically ties up that virtual drive, and conflicts will arise if two servers use the same drive letter. An alternate scheme (although not a very good one) would be for the applications to recognize volume names, but this doesn't work for all programs. If volume names were used, the chance of conflict would be smaller (except for "special" volumes like SYS:). >Suggestion: >Use drive mappings to refer to the location of the application. For example, >set it up so that WordPerfect is always on drive W:. Map drive W: to the >appropriate volume:directory in the system login script or in a batch file >maintained by the supervisor. That way if you later need to move WordPerfect >you just need make the change in one location. I find this unreasonable. With Netware 2.15c there is an explictly stated limit of *16* search drives. We definitely have more than sixteen applications that people use on our server. Plus, the directories from the *local* path are also part of the sixteen search drives. Another problem is that the application directory is physically separate from the application setup-file directory. This is so that the application directory can be read-only to users, while the setup directory can be read-write. In this case either two maps are needed, or you have to make some assumption about where in the file system the setup directory is going to be located. >Having drive letters refer to specific volumes is a recipe for disaster in >your environment where you have to move applications around. Yes, I fully realize this (which is why I was asking the question ;-). However, how can a user switch around between different volumes if drive letters are not mapped to specific volumes? For example, let us say that someone wants to run FoxPro with a database file that is physically located on VOLA:, but there is no drive mapped to VOLA:. How does the user specify that file? My opinion of all of this is that the Novell Netware scheme of using drive letters for virtual drives is very limited (at least in 2.15c). I have studied operating systems in college, am familiar with Unix and AmigaDOS, and have a fair background in networks and distributed filesystems. As far as I can tell (based on the responses I have received so far via email and UseNet news), the mapping scheme employed by Netware is every bit as limited as I had thought, and that there is no really great solution to my problem (i.e. every solution has bad limitations, with some more unreasonable than others). C'est la vie. -- Christopher Lishka 608-262-4485 It is not safe out here. It is wonderous, Wisconsin State Lab. of Hygiene with treasures to satiate desires both lishka@uwslh.slh.wisc.edu subtle and gross. But it is not for the uunet!uwvax!uwslh!lishka timid. -- Q