On Thu, 19 Jun 2008 08:32:59 -0700 Schuh, Richard said: > >> >> One minor correction, PUBLIC grants access to everyone who >> has been enrolled in the filepool. If the id in question is >> not enrolled, it gains no access. They'll receive a >> DMSACCR1240E if they try to ACCESS the directory, FPLSFS733E >> reason code 30100 if they try to read a file with PIPEs, etc. >> Not helpful if it is the filepool where all users connect, >> but useful in some situations. >Not so if PUBLIC has been enrolled. >"Purpose > >Use the ENROLL PUBLIC command to give connect authority for a file pool >to all >users. File pool administration authority is required to use this >command." >I have never been in a situation where I did not want users to not see >Public data. It may be possible that there are circumstances where it is >necessary to keep only one or a few users away from data that is >accessible to everyone else. I just have not encountered any. If that is >the case, do not enroll public and only enroll those users who do need >access. In many cases, that means thousands of enrollments. That could >be cumbersome and even become unworkable if someone who is legitimately >enrolled and has data in the pool suddenly gets put on the blacklist. I >find it much easier to enroll Public and not put sensitive data in any >directory that has authorized everyone.
The use case that comes to mind is that you have a filespace that you want to restrict access to a large group of people, but not everyone and you don't want to have a large number of authorization records in the catalog. Without an ESM, every grant is an entry in the catalog, which increases its size, and slows down the process to check authorizations. I'm not saying it's a good case, but it is s case. I had forgotted about enrolling PUBLIC. It isn't something we do, and at one time was on the "not reccomended" list. We've moved a couple things to separate filepools to ease access control. > >Richard Schuh > /ahw
