Difference between DSN(**) and DSN(*****) Permissions

[Anon Anon]

Hello, can sombody explain the difference? Are they eqal? Thanks.

[Ksegreti]

Hi,

 

There is no difference in the results of the two rules. They both give access to every dataset.  You could also have *. which gives the same results.

 

Kevin

[Joseph Porto]

Kevin is correct.

 

The value you specify for the DSN resource class is a  prefix.

 

Since the masking character '*' represents upto any 8 characters, using it with DSN means upto any 8 characters as a dataset prefix. So, one asterisk, two asterisks, three asterisk, four asterisks and so on is basically the same.

 

Please let us know if there are any questions.

 

Regards,

 

Joseph Porto - CA Level 1 Support

[Anon Anon]

Thanks

 

The reason I ask was that I have found subtle differences between ** and ***** not with DSN, but with FSACCESS.

 

Manual says

"An administrator can PERMIT access to all owned resources within a NOMASK resource class by using the special resource name:

*ALL*

For resource classes with the MASK attribute, a similar PERMIT can be managed with the resource name: *****

"

So i expected ***** is something special that may differ from **

 

Although we use ** for DSN now and in the past, i have used ***** for FSACCESS to comply to the manual.

 

There are subtle issues with FSACCESS if i combine FSACESS(*****) and other FSACCESS Permissions shorter or equal 5 char. (closest match algorithm)

I have already opened a case for this, and CA recreated the problem. We agreed to not change anything.

 

But after this there was a change

 

Eg. I have in a profile

 

FSACCESS(*****) ACC(NONE) ACTION(FAIL)

FSACCESS(ABCD.) ACC(ALL)

FSACCESS(others...)

 

Before refreshing TSS the Check for FSACC(ABCD.***) was allowed

After apply last refresh behaviour changed and ***** acc(none) is used in this case. So in my sandbox some STCs failed.

 

My solution was simply to change ***** Permissions to ** and all is ok again. ** is shorter than ***** and all other FSACCESS Permissions. So it only matches if no other permission is found.

 

So ** and ***** may not always be equal (at least dealing with FSACCESS)

[Legacy User]

RVS,

 

You stated that you refreshed TSS.

 

I suggest that the length of the permit is likely NOT the issue in this case.

 

Rather, if you applied PTF RO68148, then it is likely to be the source of the operational change that you have observed.

 

RO68148 fixed a problem where an FSACCESS(...) permit specifying ACCESS(NONE) was being ignored.

 

In your case, you had two permits, each of which had a length of five (5).  The first permit, having specified ACCESS(NONE), was ignored due to the error in the code.  Thus, the second permit, specifying FSACCESS(ABCD.) ACCESS(ALL) was selected.

 

Assuming that you did apply PTF RO68148, then you would have had a situation where both permits matched, and where both permits had the same match length, so the first permit, having ACCESS(NONE) specified, was selected.

 

John P. Baker

[Eileen Becht]

RVS,

 

When two permits are the same length and one pemit has ACCESS(NONE),  the ACCESS(NONE) will take precedence.

 

Eileen K. Becht - Level 1 Support