lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (03/13/91)
My organization is running Advanced Novell Netware 2.15C on an IBM
PS/2 Model 80. This computer is connected to a small (<10 PCs) ArcNet
network and a large ethernet network (>20 PCs), with the ethernet
being connected to the entire U. of Wisc. campus and many other
servers. The PS/2 has a 300meg internal ESDI hard disk and a new
600meg external SCSI hard disk.
One problem we have is that our SYS: volume is very low on disk space
(it is configured to the 255meg limit imposed by NetWare). We are
currently in the process of moving various directories from SYS: to a
new volume (called VOLA:) on the SCSI disk drive. Thus, we need to
create MAPs to the new volumes so that users can access the data on
them. [Side note: yes, upgrading to NetWare 3.x is a good solution,
but with the slow rate that things can be ordered around here this is
not a possible short term solution, and we need to find disk space
now!]
Our biggest problem right now is finding the best way to create maps
to the new volumes. To this end, I have tried to learn as much as
possible about the ins and outs of MAPs with Novell NetWare. There
are several issues and problems involved, and it is this that I need
help on. I have chosen a solution which I consider "best" (in our
case), but I am looking for better alternatives that I have not
discovered.
We have several needs:
(a) We have four volumes that users will need to access: SYS:,
TEMP:, VOLA:, and VOLB:. Three of these volumes are configured
to the 255meg limit that Advanced NetWare 2.15c imposes.
(b) Users will eventually want to access directories and files on
all four volumes, and must be able to access at least SYS: and
VOLA: right now.
(c) Our network consists of a wide variety of PCs and clones, including
IBMs, Zeniths, Gateways, and a few others. These PCs are mostly
running 3.3 and 4.01, although some are running versions earlier
than 3.3 and a few even run buggy old 4.0.
(d) The local hard disks are varied in size, so some PCs only have a
C: drive, while others have C: through J: as local hard drives.
Any mapping scheme we come up with must allow each user to access
all of the local hard drives.
(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.
(f) We have quite a few programs that refer to directories and files
only through drive letters (e.g. WordPerfect).
(g) Currently almost all (if not all) users only use our own server.
This may change in the future.
I have tossed around several different mapping schemes. The best I
can come up with is to permanently map certain drive letters to certain
volumes. My scheme has been to add the following to the system login
script:
MAP Z: = SYS:\\
MAP Y: = TEMP:\\
MAP X: = VOLA:\\
MAP W: = VOLB:\\
I do not particularily like this scheme because it assumes that Z:
will always be SYS:\, and that other servers will NOT also make this
assumption. 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 (i.e. the user is forced to use
"X:\SOFTWARE\WP" instead of "VOLA:\SOFTWARE\WP" to reference a
directory).
Other schemes I have encountered (some which were used here in the
past) have inherent problems with them. Those that I have considered
and rejected include:
(a) Using "MAP *1: = SYS:\\". This has the unfortunate problem of
using the first free drive *after* all of the local drives. So
on some machines F: points to SYS: and on others J: points to SYS:.
This is unacceptable because programs like WordPerfect will not be able
to determine which drive refers to SYS:. This scheme is fragile
in that it depends *heavily* on what the last local hard drive is.
[Note that this scheme would be fine *IF* NetWare chose Z: and went
backwards when naming *1, *2, *etc drives (as it does with search
drives). However, Novell's stupid use of the drive *AFTER* the
last local drive makes this scheme unusable.]
(b) Using the search drives to refer to a given volume (this was actually
used at our site be a previous sysadmin). For example, the first
drive in the search path (mapped with "MAP S1: = SYS:\...") would
always end up being Z: because of the way NetWare chooses search
drive names. This scheme is unacceptable because the drive
letter that is mapped to a given volume is implicitly determined
by the order the search path is defined. This scheme is fragile
in that if the search path is changed, the drive letter referring
to a volume may change as well.
(c) NOT explicitly mapping drive letters in the login script, but rather
mapping them in batch files that first create a new search map then
call the actual program. This scheme is unacceptable because there
is no way to determine what drive letter the new search map will get,
and because programs like WordPerfect will not allow search map IDs
like S1: to be used when referencing files.
I am looking for a better scheme than the one I am using, and welcome
any suggestions you might have. I am very disappointed with Novell's
system for mapping volumes to drive letters. Being familiar with this
sort of problem in 4.3 BSD Unix (which easily solves this issue with
symbolic links, among other things) and AmigaDOS/Intuition (which
allows multi-lettered volume names to be used when referencing files)
I am very saddened that the most popular PC network operating system
has such a lousy method of referring to network volumes. Hopefully
NetWare 3.x is better, but attaining this update is a ways off and I
need to solve the problems now.
Thanks in advance for any help you can provide.
.oO Chris Oo.
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
--
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. -- Qsaddison@ca.excelan.com (Skip Addison) (03/14/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: saddison@ca.excelan.com (Skip Addison) Organization: Novell, Sunnyvale, CA References: <1991Mar12.230723.6040@uwslh.slh.wisc.edu> Date: Wed, 13 Mar 1991 17:39:01 GMT In article <1991Mar12.230723.6040@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: >... Thus, we need to >create MAPs to the new volumes so that users can access the data on >them. ... > >Our biggest problem right now is finding the best way to create maps >to the new volumes. > ... 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. >We have several needs: > ... > (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. > (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. >... 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. 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. Having drive letters refer to specific volumes is a recipe for disaster in your environment where you have to move applications around. -- Skip
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (03/16/91)
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