Can you explain some more regarding the this process and how to set it up.
Here's the high-level version: 1) Create a PRODUCTS userid and create a reasonably large minidisk at a known address (I use 31A for historical reasons - it was used in VM/IPF as the shared tools disk). You could attach this disk to MAINT, but if you create it as a separate id, it's a) easy to determine what it's for, and b) doesn't get tied up in merging the MAINT userids when you get a new release of VM. 2) Modify the SYSPROF EXEC to LINK PRODUCTS 31A 31A RR and modify the default PROFILE EXEC you give users to access the 31A as a local filemode (I use L for local). The important part is that it be BEFORE the S disk in access order so that you can intercept system commands if you choose to do so. You're also going to put a VMLINK NAMES file here to identify your products by a name. This allows you to add dependencies if a product depends on other products to work (eg, QMF needs GDDM, so you want both accessed if you access QMF). Once this is in place, then when you install a product: 1) Create a userid that is representative of the product (or use the numeric IBM nnnnnnnnn ID that most IBM products now use). 2) Copy all the user-accessible bits of the product to a single minidisk (config files, executables, and help files) attached to that userid. You want a different minidisk than VMSES uses for maintaining the product to let you stage maintenance. This does have a performance impact, but it's fairly small for reasonable numbers of CMS users. I usually start with virtual addresses above 1000, since IBM and others usually don't go that high. 3) Update VMLINK NAMES with an entry that points to the minidisk from step 2 for a name. Example: the FORTRAN entry in VMLINK NAMES might point to VSFORT2 1000 for release 10.0.0 today. I get maintenance for the compiler. I copy VSFORT2 1000 to VSFORT2 1001 and apply maintenance to the compiler. I copy the maintained files from the SES maintenance disk to VSFORT2 1002. I then update VMLINK NAMES so that FORTRAN now points to VSFORT2 1001. 4) Create a SETUP EXEC on PRODUCTS 31A that takes an argument of a name. SETUP tests for <name> EXEC in the search order. If not found, it reports "no such product". If <name> EXEC exists, you run it. <name> EXEC tests whether the product is already accessed (VMLINK name (QUERY), and if not, does a VMLINK <name> with the right parms to get it where you want it to be, and does any additional processing like adding TXTLIB or LOADLIBs to search list, etc. All the <name> EXEC files go on PRODUCTS 31A. You then teach users to issue SETUP <name> when they want a specific product (example: SETUP FORTRAN gets you the VS Fortran compiler and adds VSFORTLIB to the GLOBAL LOADLIB and VSFORT2LIB to the TXTLIB list). That way you can change anything about how the product is deployed w/o having to deal with rewriting execs or retraining users more than once. From an administrator perspective, it lets you add or update products easily (if you use the trick of renaming the existing NAMES file and exec to filemode 0 and copy the new one into place as filemode 2, you don't even have to worry about users reaccessing the disk because they get a stable version for the lifetime of a minidisk access), and you have clear update barriers for transitions. For IBM products that insist on being rude and dumping stuff on 19E, you can still copy the files from the 19E to the product minidisk and treat them in the same way, and on upgrade, they're still there if you just trash the old 19E and start with the new one from the new release of z/VM. -- db
