I am not sure what you mean by "secondary authorization".
Since there seems to be various players here, let me try to nail
- end user. This might be a person or a CICS, etc program. When it
makes a connection to
Db2 the authorization or signon exit will assign a primary id
(usually a user's id or something
the CICS RCT sets up). The exit might also supply one or more
secondary authids. Call
these PID, S1ID, S2ID etc
- the user executes a program, which calls a stored procedure -
"native procedure" below -
created with PACKAGE OWNER SPOID. (In this context, SPOID has no
- although it might in others.)
- "native procedure" calls SYSPROC.ADMIN_COMMAND_DB2 .
You want ADMIN_COMMAND_DB2 to use SPOID for authorisation, but it
is rejecting the
commands because PID isn't authorised.
If so, "secondary authorization permissions" means S1ID, S2ID etc -
not SPOID. I'd suggest
- make "native procedure"'s call to SYSPROC.ADMIN_COMMAND_DB2
- create "native procedure" with DYNAMICRULES DEFINEBIND
If not, and you really do want S1ID (or S2ID ...) to be used (and
are using RACF), have you
re-assembled the authorisation and sign on exits since V10? There
were changes to support
push through of secondary authids for stored procedures. It is
SYSPROC.ADMIN_COMMAND_DB2 requires them (SYSPROC.DSNUTILS certainly
If you mean a secondary authid of SPOID then you are out of luck.
It doesn't have any.
Secondary authids are created when an id goes through the sign on
or connection exit.
Since SPOID doesn't go through those exits (in this context), it
doesn't get secondary
On 31 May 2019 at 16:37, Zinderman, Troy wrote:
> Hi folks,
> Is it possible to call the SYSPROC.ADMIN_COMMAND_DB2 procedure
and have secondary
> authorization permissions push all the way down to the
Instrumentation Facility Interface?
> I am testing where we want to constrain a process to a
semi-specific set of tablespaces (via a
> native procedure). That procedure is calling the
ADMIN_COMMAND_DB2 to place the
> tablespaces in RO or RW. However, the ADMIN_COMMAND_DB2
returns a DSNT300I saying the
> auth-id is not authorized to perform that function. We
want the creator/owner of the native
> procedure to have the permissions to execute the Db2 Command,
not the calling primary
> auth-id. But it seems that when ADMIN_COMMAND_DB2 is
sending the commands down to IFI,
> it´s using the primary auth-id, not the
> I have tried some combinations of the DYNAMICRULES parameters
in the definition. However, I
> get no luck on any of them picking up the creators auth over
the caller´s. Just wondering if this is
> even possible.
> Troy Zinderman
> Division of Database Systems
> Office of Systems Architecture
> U.S. Social Security Administration
> Office: 410-965-7328
> Cell: 443-761-3655
This email has been checked for viruses by AVG.