Exposing my (monumental) SFS ignorance... Stuff here has been accumulating on the Y-disk for (literally) decades. For example, one of the oldest files is: HASMOPT COPY Y1 1 5/27/82 15:48:06
The source of many of the files can be identified by fileid naming standards. But there's a lot of accumulated garbage from "uninformed" IBM and ISV products -- and some from poorly named local applications going back to 1985 when I installed VM here. We generally migrated to new VM releases by copying everything from the old release's 19E disk to the new release's 19E disk with OLDDATE (but not replace!). Garbage continued to accumulate. Old program product placement on the Y-disk was often changed to new locations with new versions of the product - duplicating file IDs and leaving more garbage. I'd like to weed out the "garbage". We are in the process of implementing a "PPS01:MAINT.YDISK" (where "PPS" is "Program ProductS") filespace, as a "shadow copy" of the live MAINT 019E disk. The MAINT 019E disk will be maintained as the "live disk" so that it is available to XAUTOLOGed servers before the PPS01 filepool server is up, and as a fall-back (one we're really familiar) for when things "go bump in the dark". We'll probably add a test in SYSPROF to try the YDISK filespace, and fall back to the MDISK (with a warning message to the OPERATOR) if the filespace is not ready. Certainly we'll change the timing of AUTOLOG1 (actually AUTOLOG1, then VMSECURE, **then** AUTOLOG2) so that the AUTOLOG2 (which is AUTOLOGed by VMSECURE after it is running) brings up the PPS01: SFS server and waits until PPS01: is ready before continuing to AUTOLOG the rest of the usual suspects. As we work through the process, we'll test this YDISK filespace on our own sysprog ID's, and then update SYSPROF EXEC so that again, just us sysprogs will ACCESS this filespace. As we gain experience, we'll add other users to the list of folks using this technique. All that work will give us a valid Date of Last Reference (DOLR) for Y-disk files. Anything not referenced for "nnn" days can be analyzed for a good housecleaning. So, finally, the questions... a) Has anyone else done this as (1) a form of housecleaning or (2) a generally good idea for the Y-disk? Do you have any guidance for those about to trod upon the road "less traveled by"? and more-general SFS questions... b) Why is it that filemode 0 (zero) files appear in a read-only SFS filespace? OK, the "ACCESS" doc does not mention MODE0 for anything but MDISKs. But why would it even be designed to show filemode 0 in read-only mode? c) The Y-disk contains a bunch of "hidden" files (anything other than filemode Y2 is hidden by the standard "ACCESS 19E Y/S * * Y2"). That was pretty handle to reduce visible clutter for things like compilers (HLASM, COBOL2, etc.) and other installation-specific files. Did I miss something in SFS that would let us continue to "hide/reduce clutter" by filemode in an SFS filespace? Thanks! Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Mike Walter Information Technology Services Hewitt Associates [EMAIL PROTECTED] Direct: +(847) 771-9233 Main: +(847) 295-5000 http://www.hewitt.com 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.
