MCMAHON@GRIN1.Bitnet ("McMahon,Brian D") (06/07/91)
Here's a reply I sent to Ken, posted to the list at his suggestion, plus some additional information tacked on to the end: Ken Wallewein <kenw@NOAH.ARC.AB.CA> writes: > Some one told me that, in AFP, there is a theoretical maximum number of >volumes which can be "published" by a given AppleShare server, and that >that number is actually quite low. This appears to be true. We hit this limit (and hit it HARD) when we started working with AlisaShare on VAX systems. I can't seem to find my scribbled notes, but the limit's there, and it's low enough to go splat for us past circa 20 volumes. The best my fuzzy recollection can do right now is this: The limit is a formula, based on the number of CHARACTERS in all the volumes on the server. It's not one of the "obvious" magic numbers, and if anyone could provide a coherent explanation, I'd be most grateful. > Is this true? If so, it would appear to have significant implications >for multi-user systems, such as Unix systems running CAP, which want to >make available one or more volumes for each of a large number of users. Significant, yep. :-) For us, the answer has been to go down a level, that is, to create a small number of volumes and give the users FOLDERS within. This has its good sides and its bad sides, but for many things (file protection being the most important), it makes little or no difference whether we assign folders or volumes to users -- they both map to VMS directories, anyway. > For that matter (this is a little off topic), has anyone thought of a >good way to separate -- in the Chooser -- their main AppleShare servers >from all those little servers that will pop up when everybody starts >running System 7? In our situation, we have the Macs in one zone (eventually to be subdivided, I suppose) directly plugged into the Ethernet. The VAX-based Alisa servers create virtual LocalTalk networks of their own, and appear to the Macs to be in another zone. If you can pull off something similar with your server configs, that would be one solution of sorts. Not the neatest, it's true, but for us, it's incidental... ---- New stuff starts here ---- Well, I've asked several other staffers, and they can't find THEIR scribbled notes on the matter, either. I do know that the limit is probably NOT in AFP. It sure as Hell isn't in any Apple docs I've seen. Here is what the release notes for AlisaTalk 3.3 say about AlisaShare volumes: "The number of volumes you have assigned to an AlisaShare server is limited by a formula in the AppleShare Client Software. AlisaShare ^^^^^^^^^^^^^^^^^^^^^^^^^^ checks the number of volumes in the ASVOLUME.DAT file against this formula and will display an appropriate error if the number is exceeded." (AlisaTalk V3.3 Release Notes, August, 1990, p. 13) This has been a tremendous frustration for us. For one thing, it would be really nice if Alisa would _DOCUMENT_ exactly what this formula is, so I wouldn't have to go chasing down notes written on scraps of paper during a call to Alisa tech. support. :-) I'm also puzzled by the bit about the AppleShare Client being the limiting factor. There's certainly nothing inherent in AFP that would produce a limit as restrictive as we've encountered. (And yes, we did try it out, just to be sure.) Who, what, when, where, why? And how come other systems like CAP don't seem to suffer from this problem? Could it be that Alisa are faithfully but needlessly implementing a phantom restriction? Grasping at straws, the only remotely plausible explanation I can find is that it has to do with the space available in Chooser for the list of available volumes. With AlisaShare, Chooser displays the names of all volumes defined to the server, whether the user has access to them or not. (Unaccessible volumes are grayed out.) What does CAP do when it has many volumes defined? Does it only advertise the ones a particular user can mount? Hmmm, I wonder... (Reaching for the Inside Macintosh X-Ref...) Again, any clues about what in blazes is going on here would be welcome ... and just might preserve my few remaining tattered shreds of sanity. :-) Brian McMahon <MCMAHON@GRIN1.BITNET> | VAX Kludgemeister, Macintosh Medic, Grinnell College Computer Services | Human Help Key, support for sundry Grinnell, Iowa 50112 USA | stats packages, and rookie DECUS Voice: +1 515 269 4901 | Sym_edit Grunt. Please allow two Fax: +1 515 269 4936 | to four weeks for miracles. %DCL-W-TANSTAAFL, there ain't no such thing as a free lunch