Since the error does explicitly complain about authorization for a "controlled program", check for existence of PROGRAM profiles of "**" or "ADDUSER" with an associated member entry with "SYS1.LINKLIB", and if they exist whether the address space getting the error runs with a userid that would have READ access to the controlling profile. Particularly with a PROGRAM "**" profile designed to cover linklist libraries, UACC(READ) would be typical. If the request is coming from a RESTRICTED userid, that could mean it wouldn't see UACC permits and would require explicit access either directly or via a connected group. If you end up altering any program profiles, don't forget to REFRESH the in-memory PROGRAM profiles before testing.
   JC Ewing

On 07/07/2012 02:36 PM, Scott Ford wrote:
Hey Joel,

We invoke via irrseq00, the permits are good for irr.radmin.adduser, etc ..so 
those permits are good. We run our product as  a STC with Special, no issue 
there

Scott ford
www.identityforge.com

On Jul 7, 2012, at 3:00 PM, "Joel C. Ewing" <jcew...@acm.org> wrote:

How is the "ADDUSER/AU" being invoked?  If in batch TSO  as a TSO command it 
should only require RACF SPECIAL authority by the invoking userid (and correct definition 
to TSO of RACF authorized commands). Unless program access is specifically disallowed by 
PROGRAM profiles, I would have thought EXECUTE dsn access would be sufficient as long as 
it is loaded via LINKLST.  If it is being invoked from some script as 
'SYS1.LINKLIB(ADDUSER)' that is a different issue, as that syntax says you are 
potentially invoking something not in LINKLST; and since ADDUSER is a TSO command 
processor, it really shouldn't be invoked that way.
    JC Ewing

On 07/07/2012 01:42 PM, Scott Ford wrote:
Craig,

Here is the problem in a nutshell. Customer has a z/os 1.11 environment. The 
term used fo the security environment was hardened. But the customer doesn't 
know their security environment, no documentation, etc. So, we are trying to 
determine what is causing the s306-30 abend. What RACF commands we can use to 
determine what is or isn't required for product installation.

I need some suggestions...any help is appreciated.

Scott ford
www.identityforge.com

On Jul 6, 2012, at 5:15 PM, craig.p...@fotlinc.com wrote:

Not always,  Here is the ABEND 306-30 documentation.


The user attempted to use a controlled program but is not
authorized by RACF to use that program. This can occur when a
user has EXECUTE access to a program library's data set profile,
even if none of the program modules involved are RACF program
protected. Have the system security administrator grant you READ
access to the data set profile instead.


Thanks,

Craig

From:   Scott Ford <scott_j_f...@yahoo.com>
To:     IBM-MAIN@LISTSERV.UA.EDU
Date:   07/06/2012 15:34
Subject:        RACF question
Sent by:        IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



All,
I have a question, I have a customer receiving a csv0025i abends306-30 on
a adduser.
Shouldn't we be seeing a ich408i message ?

Scott ford
www.identityforge.com
----------------------------------------------------------------------



--
Joel C. Ewing,    Bentonville, AR       jcew...@acm.org
...

--
Joel C. Ewing,    Bentonville, AR       jcew...@acm.org 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to