"No, definition of arbitrary objects in RACF is NOT an option" Maybe I'm misunderstanding the intent here, but why can't you define an 'arbitrary object' in the ichrrcde?
Mary Anne On Thu, Mar 26, 2009 at 12:06 PM, Rick Fochtman <[email protected]> wrote: > ---------------------------<snip>------------------------------------------ > > P S wrote: > > Well, I'm showing my RACF ignorance in a big way, obviously! That >> doesn't bother me, I can take it. >> >> The issue is code that currently generates some data objects (they're >> all small) and caches them in HFS. Someone said, "They should be in >> RACF". So a corollary question is, "Does RACF allow definition of >> arbitrary objects ([email protected] -- yes, > 8 bytes) and then >> allow access control over them? My reading suggests that it doesn't, >> but I haven't gotten very far. >> >> If it does, then the question is, "So, if these objects are accessed >> frequently, is it better performance-wise to ask RACF for access, or >> to read them from disk?" (Yes, this skips the question of whether just >> asking "Mother May I" is sufficient for this purpose, but let's assume >> it is.) >> >> On Wed, Mar 25, 2009 at 8:32 PM, George Fogg <[email protected]> wrote: >> >> >>> Make a RACF request for what? >>> RACF data can exist in lots of areas. Real or virtual storage, in a VLF >>> object, dataspace, a CF structure. If not found in any of those areas >>> then >>> RACF I/O to its database. So again, what RACF request are you after? >>> >>> >> > -------------------------------------<unsnip>------------------------------- > There seems to be a misconception here. RACF is a security mechanism, NOT a > generalized data-storage mechanism. > > No, definition of arbitrary objects in RACF is NOT an option. Storage in > HFS is fine, or some other small dataset if you like. Whoever told you "They > should be in RACF" has a faulty understanding of RACF function and usage. If > you could go into more detail about the application and its usage, perhaps > we can arrive at an acceptable solution for your issue. > > -- > Rick > -- > Remember that if you’re not the lead dog, the view never changes. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
