How to get access to the PROC command in SDSF (using TSS)

[Robert Bridges]

I want to use the PROC command in SDSF to list the default proclibs, but when I enter "PROC" I'm told "command not authorized".  Ok, that's fine (I said to myself), I'll just look up the permissions needed, since I'm a TSS jock.  But my reading of the SDSF manual tells me I already have the permissions I need, so what am I missing?

1) The manual says I need READ authority in SDSF(ISFCMD.ODSP.PROCLIB.jesx).  When I ask TSSSIM about my access to ISFCMD.ODSP.PROCLIB, it says the access is granted.

2) The manual says that for the PROC command I also need SDSF(ISF.CONNECT.sysname), but again, TSSSIM assures me I have ISF.CONNECT already.

3) A note in TSSSIM says the RC for both permissions is 04.  But the class definition for SDSF includes DEFACC=READ, so that oughta be alright, no?

I can show the TSSSIM listings in more detail if necessary.  I'm not really experienced in SDSF permissions, so I have no difficulty believing this is just my own ignorance.

[Joe Denison]

Hi Bob,

SDSF requires that the return code for SDSF(ISFCMD.ODSP.PROCLIB.jesx) auth check to be RC=00.  Which means, the resource must be owned/protected (or, that the RDT def for this class must have DEFPROT), and, you need a permission in place to provide the access if the user doesn't have NORESCHK.   

You stated that TSSSIM reveals an RC=04, which either means that the resource is not owned, or, that the permission you have in place for it contains the ACTION(PASSWORD) keyword.  In either of those 2 cases, you'll get an RC=04 ("not defined to security") on an auth check.   To resolve this, you have several choices:  1) own the resource, and PERMIT the access.   Or 2) remove the ACTION(PASSWORD) from any permission for this resource that contains that ACTION keyword.  or 3) provide a masked permission (like, SDSF(*.ODSP.PROCLIB.jesx) ACC(READ)  somewhere that's available to the user.   NORESCHK will do it too.  

I'm running with DEFPROT on on the SDSF class, so that there will never be an RC=04.  (But, DEFPROT isn't something to just indiscriminately add without some planning and discretion to prevent an outage). 

Also note that the DEFACC attribute in the RDT for the SDSF class does not in itself provide any access or imply any access available to users.  Instead, DEFACC(READ) simply designates the default ACCESS level that will be applied to any TSS PERMIT command for the SDSF class where the ACCESS keyword is omitted.  

I hope this info is helpful!   Let us know if this resolves the issue!