> Our approach is very similar to George's. We access the tools disk as R > rather than P. We also have an SFS directory for local System Programmer > tools. The latter does not include things we might need in an emergency; > those go on a minidisk.
The method I've always favored is a variation of #2. We used to have a common minidisk (MAINT 31A for historical reasons) accessed as X (after S but before Y, so you get the real IBM utilities before the local stuff unless you explicitly ask for them) in SYSPROF EXEC. I then defined a target in VMLINK NAMES for each product I want to make available, which includes the location of the product (minidisk or SFS owner, directory, pre/post access setup execs, etc) and ensure the copy of VMLINK NAMES is updated on the X disk. I then supply a small "cover" exec that checks to see if the product disk has previously been accessed. If it has not been previously accessed, the cover exec does a VMLINK for the product (replacing an earlier home-grown exec called OBTAIN -- alas, OBTAIN, another lost tool with the death of RICEVM1...) and then reissues the command with the original parameter list. If it was already available, the cover exec just passed the parameters through to the real executable. This approach kept everything nice and neat, allowed a mixture of SFS and minidisk installs, and dealt nicely with the IBM stuff attempting to dump random stuff on MAINT 19E, which required a resave of the Y-STAT segment. Of course, this really matters a whole lot more if you have lots of CMS users. If all you have are a bunch of Linux guests with rare CMS sessions by well-behaved systems folks, just make 19E big and let the IBM execs dump stuff on there at will -- SES has improved enough to be able to sort stuff out properly for IBM-packaged goodies when you do your upgrades. A second minidisk accessed in either PROFILE EXEC or SYSPROF EXEC for your local goodies is still a good idea, though -- Mother's Law still applies. > And for those who say that SFS is so reliable that its being down is of > no concern, I say take off those rose colored glasses. Especially if you do not have a 3rd party backup utility and have to rely on FILESERV BACKUP as your SFS backup utility. Getting a truly clean backup of a SFS pool w/o 3rd party tooling is highly disruptive -- most CMS apps don't deal well with their disks suddenly going read-only without warning.
