The not rusty IBM products are installed with VMSES, meaning a VMSES PARTCAT is maintained on each minidisk that received files, and this since VM/SP Rel 6. These PARTCATs have fmode 1, meaning they are invisible on 190 and 19E unless you perform your own ACCESS command (like ACCESS 190 T). You can obviously read the the PARTCAT files with XEDIT, but VMFCOPY and VMFERASE are commands you should explore, as they can perform work based on the entries in VMSES PARTCAT. If you invent your own product IDs, you can even catalog your own files when copied to 19E. With a new release, VMFCOPY can be used to copy all files of a given product ID from the old to the new 19E. That's what I did to store some customer code on the Y-disk, in a fully documented way. I wouldn't be me if I didn't create an EXEC to compare the products found in two VMSES PARTCATs (like old and new 19E), and select products to be FILELISTed of VMFCOPYed from one to the other. My SESCOMP is available on request only.
2009/8/19 David Boyes <dbo...@sinenomine.net> > > > > > 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 > > > > > > > -- Kris Buelens, IBM Belgium, VM customer support
