I took a slightly different approach to reach a slightly different end, rather than rely on VMSES/E (and perhaps have to refit locally developed processes if VMSES/E changes in the future). Over the years a locally written "COPY2 EXEC" was enhanced to copy local files to the Y-disk, our T-disk (local Tools disk), and (way long go) the PROFS administrator's public 199 disk. The syntax is very similar to that of COPYFILE.
That COPY2 EXEC was modified to update a new "HEWITT PARTCAT" on the target disk with info about the file just copied to the disk. For example, a few lines from an XEDIT view of that file: HEWITT PARTCAT Y2 V 83 Trunc=83 Size=2381 Line=0 Col=1 Alt=1 ====> *OutFn.. OutFt... InFn InFt CopyDate CopyTime FileSource... PIPELINE HELPLIB PIPELINE HELPLIB 2008-10-08 12:58:44 PPS01:SYSPROG.PIPELINES QDASD EXEC QDASD EXEC 2009-07-27 09:39:27 M2WALTER 0191 Having our own HEWITT PARTCAT keeps our stuff out of IBM's VMSES PARTCAT files, making upgrades to new releases easier (in particular, for Y-disk files). Mike Walter Hewitt Associates "Kris Buelens" <kris.buel...@gmail.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 08/19/2009 04:57 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Extension of MAINT 190 (S-DISK) 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 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
