) Why is it that filemode 0 (zero) files appear in a read-only SFS
filespace?
I asked IBM that question way back when and was told that is the way it
works.
-----Original Message-----
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
Sent: Thursday, June 14, 2007 3:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Y-disk housekeeping using SFS.
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.
--------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically indicated,
this message is not an offer to sell or a solicitation of any investment
products or other financial product or service, an official confirmation of any
transaction, or an official statement of Merrill Lynch. Subject to applicable
law, Merrill Lynch may monitor, review and retain e-communications (EC)
traveling through its networks/systems. The laws of the country of each
sender/recipient may impact the handling of EC, and EC may be archived,
supervised and produced in countries other than the country in which you are
located. This message cannot be guaranteed to be secure or error-free. This
message is subject to terms available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you
consent to the foregoing.
--------------------------------------------------------
