"Generic preixes" for masking and profiles

[Robert Bridges]

I was refreshing my memory about dataset masking, and I saw in the TSS r15 User's Guide that dataset masks are treated like generic prefixes.  Not knowing what a "generic prefix" is, I went searching and found this:  "Use generic prefixing to reduce the task of assigning ownership for each resource, masking, and profile ACID."

Now, I know how to tell TSS that a department ACID owns DATASET(XXX.), for example.  If the TSS documenters means only that "XXX." is a generic prefix, I think it's a slightly confusing term but what the heck, that's what they call it.

But what could they mean by saying you use the same thing for the task of assigning ownership of a masking?  What's a "masking" in this context?

And a profile?  A profile ACID has a department, division and zone, but I don't think of that as ownership and it doesn't involve generic prefixes.  Does this mean anything, or is it just a bit of careless writing?  Anyone know?

[Joseph Porto]

Think of generic prefixing as ABCD where * is wildcard or anything that starts with ABCD.

So if you TSS PERMIT(BOB) DSN(ABCD) ACC(READ), Bob has access to all datasets that start with ABCD.

ABCD is the generic prefix.

TSS PERMIT(BOB) DSN(ABCD*) ACC(READ) is another way to code it, but the asterisk is not necessary.

Regards,
Joseph Porto - Broadcom Level 1 Support

[Robert Bridges]

I was afraid that would happen.  Joe, you answered the question I didn't ask (I said I already understand assigning ownership of datasets).  The question I asked is "what can the manual mean by talking about assigning ownership of each masking, and of each profile?".  And if you can explain why it speaks of owning a masking or a profile, how would generic profiles figure in assigning that ownership?

[Joseph Porto]

Bob,

The statement is trying to convice user's generics prefixing or masking characters in ownership. Less work, less definitions, less data on the security file.

You are right. PROFILE TYPE acids cant be owned, so I am not sure what the author was trying to convey there. It was written before my time before I started support in 1990.

Will submit a doc update.

Please let me know if there are any questions.

Regards,
Joseph Porto - Broadcom Level 1 Support

[Robert Bridges]

I wrote "how would generic profiles figure in assigning that ownership?"; I meant, of course, not generic profiles but generic prefixes.

You said profiles cannot be owned, but about the other?  That sentence also speaks of assigning ownership to each masking.  I'm not even sure what that CAN mean.

[Joe Denison]

Ha...I miss working with you Bob!  I always enjoyed your questions because you tend to interpret things literally and assume that speakers and writers do the same.

A dataset prefix must be owned before one can issue a permit it or anything prefixed with it.  This is true whether the prefix is an actual DSN prefix, or if the prefix begins with masking characters. 

So your example of DSN(XXX.) covers dsns that are prefixed with "XXX." to accommodate the placement of permissions that are prefixed with "XXX.".  

To be able to place permissions that are prefixed with masking characters, you must "own" masking characters such as DSN(**), DSN(++).  Even if there is just 1 masking character followed by actual DSN characters, it must also be owned...for example:  DSN(*.).   There can be many other combinations but these are common examples.  This is done with the TSS ADD command just the same as owning any other DSN prefix or resource.   Once owned, you can then deploy permissions that are prefixed with these masking characters.  Note that if DSN(**) isn't owned, then if you try to permit DSN(**) or DSN(**.PROCLIB), you'll get an error "DATASET/PREFIX NOT FOUND IN SECURITY FILE", just like you would if you were trying to use an actual DSN prefix that hasn't been owned.

It's important to note that unlike owning an actual DSN prefix (like the XXX. example above), the act of owning a masking character doesn't PROTECT anything ... it simply defines it to TSS, enabling you to place TSS permissions using that prefix.  I point this out because I've observed administrators who are hesitant to own DSN(**), thinking that will cause all DSNs to be protected, but, that is not the case at all...no protection occurs with ownership of a resource that begins with a masking character. 

Primary reasons for having to "own" datasets/resources is to protect them and enable permissions to be deployed.  But a secondary reason is to support more efficient processing of the TSS WHOHAS command:   For every permission of an owned resource, there is an entry made in both the ACID where the permission is TARGETED, as well as an index entry in the ACID that OWNS the resource.   This makes for a much more efficient retrieval of the information about the permissions when running the WHOHAS command, as the TSS command processor simply needs to retrieve the inventory of all permissions out of the ACID that owns the resources (vs. having to search the entire TSS SECFILE for matching permissions). 

And you are correct:  PROFILE ACIDs are not owned and don't involve generic prefixes.