I suppose that I should have started this thread by stating right away
that we have and use SAFESFS. Given it's price, ease of use, the
complexity of SFS's native ACLs, and the reduction in backup times from
hugely fewer authorizations, I can't understand why anyone using SFS would
not have purchased and installed SAFESFS. No, I do not get paid or
compensated in any way for sharing that opinion. Well... my compensation
is the same good feeling we all get from helping one another on the list
to "discover" a useful tools and product, in this case SafeSFS (or
SafeAccess, for that matter).
In response to some of the excellent replies (and all have been):
1) install tools that blindly link MAINT 19E and don't tell you or fail
reasonably when it doesn't work (or worse yet, when it succeeds and they
dump random crap on there w/o telling you)
R: I intend to the MAINT 19E disk current, and maintain the MAINT.YDISK
filespace as a "shadow copy" that is accessed by everything after the file
server comes up. Thus, products can still blindly and (cursedly) silently
install to the actual MAINT 19E disk. We'll be writing a program to
detect differences between the mdisk and filespace and report such
automatically each day. It's the "random crap", much of which is probably
obsolete, installed onto the Y-disk that inspired this effort.
2) loss of the benefit of the YDISK saved segment, although that was a
while back when storage was still a lot more constrained. It would be nice
to never see the SSTAT/YSTAT mismatch message again...
R: I did not seriously consider that. I figured that we have so few CMS
users now that everyone could have their own 19E disk accessed without
noticing all that much resource utilization. It might be true. But the
Y-STAT might be mitigated by Kris' DIRCONTROL/dataspace suggestion. I'll
have more research to do on that idea, including the ramifications of
changing their virtual machines from XA mode to XC mode.
3) The complexity of managing ACLs for large numbers of CMS users using
the built-in tools.
R: Solved. Easily. By SafeSFS. Taking a truly onerous issue and making
it a veritable "piece of cake"... one single authorization record:
ACCEPT USER * READ *:MAINT.YDISK.
4) CMS products that expect their important bits to be on the Y disk and
that rearrange their environment internally after starting up, releasing
anything but what they expect to be there.
R: Yeah, that could be an "interesting opportunity". But that's what
end-users are for -- the best testing! ;-)
Following thorough testing, updates to the SYSPROF EXEC should replace the
"ACCESS MAINT 19E Y/S * * Y2" with "ACCESS PPS01:MAINT.YDISK Y". MAINT
here also has a 019C disk, for local tools. It already has a "YDISK EXEC"
to re-LINK and ACCESS MAINT's 019E. That will be changed to access the
SFS filespace so that users have an easy way to recover a released
filemode Y -- at least without having to know that complex SFS access
syntax. ;-)~
5) (kind'a) I think you could simulate the same effect as mode 0 by using
group-based security grants for "public" files.
That could work. And I suppose we could just have a sub-directory like
"MAINT.YDISK.HIDDEN" and place all the hidden files there. But given that
we'll keep the MAINT 019E disk current, we'll probably just not place most
hidden files on SFS to begin with (except the VMSES PARTCAT Y1, HEWITT
PARTCAT Y1, and the GENDIRT'ed files). Kris pointed out on of my
concerns: "GENDIRT" for compilers (including HLASM, and COBOL2; we keep
PL/I on it's own disk). HLASM and COBOL2 need those files that were
hidden by GENDIRT. Since there's no "ACCESS dirid Y/S * * Y2" support, I
suppose we'll just have to let the users suffer through "exposure" to the
formerly hidden files (not as bad as exposure to Unix). There are not
that many, so wasted FST storage should not be much of a problem -
especially if we go the dataspace route. :-)
>From Kris:
Beware too for "special tools": my customer uses my LOOK tool to scan
files for strings. Without precautions such tools will set all DOLRs to
the date someone searched...
R: Excellent point! Long ago I wrote a "HUNTFILE EXEC" that just looks
for files with given fileid patterns, and "HUNTSCAN EXEC" that actually
reads files and searches for text strings. It already turns off MDISK
cache while it is searching. It will need additional changes to stop DOLR
updates.
Q: Any quick-tips on what you had to do? If not, I'll dig through the doc.
My LOOK has since been updated to avoid that (no, I don't think it is on
VM's download lib, but I can send it).
R: I don't suppose that one can every have enough utilities. Sure, I'd be
happy if sent a copy. You already have my e-mail address.
Similar, a simple BROWSE when one is curious will update the DOLR. So, we
have a PIEK EXEC that avoids this (in Dutch "piek" is pronounced exactly
like the English "peek").
R: Ugh. Something so simple can be so difficult :-(
SFS needs a DOLRUNJPA - Date Of Last Real Use Not Just Poking Around!
SHARE requirement? ;-)
Q: What did you do in PIEK to keep from updating the DOLR. After all, we
have the source for BROWSE. :-)
Thank you all (and future contributors) for excellent ideas and
considerations.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
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.
