Chris:
This is similar in my estimation to a library sys1.maclib.
We were a 100 percent cobol shop so we used the noaccess rule. What
we found is that the only people that tried accessing it were people
from outside the company that were looking around and had no real
need for it as I said we were 100 percent cobol. To give you a fair
idea only the senior application people could even remotely look at a
dump even then they had no clue. In *OUR* shop it worked.
IMO sys1.vtamlst was similar. Every two years we had a consultant who
demanded access to it. We were nice and said NO. One consultant came
in and asked for access and we said no and he went the politic route
and they said sure. Sure enough 3 days later we get an internal memo
saying we had to change it and then the memo wars started up. One of
my VP's came down and I sat down with him and explained why we didn't
want to change it. We were short on man power in the group and could
not spare the time I had hours and dates and everything to prove we
didn't have the time. He said yes he knew but just this once. I asked
which project did he want pushed back and he pointed at one and of
course it was a really important one and I asked if he understood the
cost and everything and of course he said he did. So somewhere in my
100 hour work week I changed it and of course it did not work. This
caused a really nasty backlog to literally break. My "10 minute"
change caused an outage and we had a outage of one of our customers
got their reports 2 hours late and all hell broke loose. The VP was
called in and he tried to push it onto us. I got called up to the
presidents office and I explained our side and the president actually
told the VP to keep his people in line and not to request such items
again.
The VP eventually moved on and life went back to normal.
Ed
On Mar 9, 2012, at 12:03 PM, Chris Mason wrote:
Juan
IBM suggests UACC(NONE) for them (RACF Security Administrator
Guide, apendix D- Security for system datasets).
Why should the RACF developers be the arbiters of what is the
correct access policy for VTAMLST? I would say that they were as
likely to get such a proposal correct as any other development shop
commenting on the products of another development shop. In other
words, they are very, very likely to get it quite wrong - a
phenomenon I have observed time and again!
Indeed, I have sometimes been very pleasantly surprised when a
manual written by one development shop happened to come up with a
clear explanation of how to use products from another development
shop. Actually the only case I can remember over many years is GDDM
talking about the 3270 data stream.
(RACF Security Administrator Guide, apendix D- Security for system
datasets)
Please - and this applies to all posters - provide an URL when
referring to something state in a manual.
I suggest you post this query on the RACF-L list and challenge the
gurus I notice there are not backward in coming forward and see if
any of them can provide a reasoned argument why the following
recommendation - which I dug out! - is present:
<quote>
D.0 Appendix D. Security for system data sets
Table 48. UACC values for system data sets
Data set/UACC/Comments
...
SYS1.VTAMLST/NONE/
...
</quote>
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza7c0/
D.0
Note that the people responsible for this table couldn't even
imagine any justifying comment to add. I suspect they had wet
fingers in the air!
If the RACF-L gurus cannot provide a reasoned argument, I suggest
you treat this recommendation with the pinch of salt which in my
opinion it deserves.
Remember "There is no substitute for understanding what you are
doing.", a maxim that isn't necessarily ingrained on the conscience
of IBM developers!
-
Anyhow the "users" who need to access VTAMLST are obviously the
user of the VTAM/NET address space and any system programmer's TSO
address space where the system programmer is responsible for
maintaining the VTAMLST partitioned data set. I cannot see any
reason why a user of the VTAM API would require access to VTAMLST
for the reason that he/she was using the VTAM API.
-
Incidentally, while you are challenging the RACF-L gurus over
access to VTAMLST, you might care equally to challenge them over
the recommendation to specify universal access of READ for the
VTAMLIB partitioned data set where, again, the comment field is
completely absent in the now famous table. Again, I suspect a wet
finger!
-
Moreover, take a look at the comments where the authors bothered to
add comments and note whether there appear to have been any
guidance other than common sense and - it must be said - note the
considerable equivocation!
-
Chris Mason
On Fri, 9 Mar 2012 09:00:34 -0800, Juan Mautalen
<[email protected]> wrote:
Hi:
We currently have our VTAMLST libraries protected with UACC(READ).
IBM suggests UACC(NONE) for them (RACF Security Administrator
Guide, apendix D- Security for system datasets) . I want to make
the change, but of course i know i must be extremely carefull with
this change. I need to detect all users needing read access to
VTAMLST. Human users are not my problem, my worry is about non-
human ones (users of system tasks, started tasks, etc.).
What users need read access of VTAMLST?
Does any userid associated with a VTAM application need to read
VTAMLST?
Thanks in advance for your help,
Juan Mautalen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
