Path: utzoo!news-server.csri.toronto.edu!rutgers!uwvax!uwslh!lishka From: lishka@uwslh.slh.wisc.edu (a.k.a. Chri) Newsgroups: comp.sys.novell Subject: Request for suggestions on NetWare mapping schemes Message-ID: <1991Mar12.230723.6040@uwslh.slh.wisc.edu> Date: 12 Mar 91 23:07:23 GMT Reply-To: lishka@uwslh.slh.wisc.edu (a.k.a. Chri) Organization: Wisconsin State Laboratory of Hygiene Lines: 122 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. -- Q