Authorization error after upgrade to DB2 v8 CM

Donna Domovic

Authorization error after upgrade to DB2 v8 CM
Hello,

We've started to upgrade to DB2 v8 CM and seem to be running in to a weird
situation.

We have a 2 member data sharing group both currently running DB2 v8 CM.
When we issue commands from the mvs console against the DB2R member, the
command works as expected. When we issue the same command against the
second member, DB1R, we receive authorization errors like the following that
was received from a DISPLAY THREAD command:

-DB1R DIS THREAD(*)
DSN9016I -DB1R '-DIS' COMMAND REJECTED, UNAUTHORIZED REQUEST
DSN9023I -DB1R DSN9SCND '-DIS THREAD' ABNORMAL COMPLETION

I know with DB2 v8, commands from the console are treated differently and
we should have to define the DBxx.SYSOPR resource to the DSNR class but we
checked and the SYSOPR resource isn't defined for any of our DB2 subsystems.

Does anyone have any ideas on why we may be seeing the difference between
the 2 subsystems and how to correct it? We're trying to make sure the DBAs,
System Programmers, and Data Center operators will still have the
authorization they need to issue the various DB2 commands.

Thanks in advance.

Donna Domovic

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Roger Miller

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Donna Domovic)
In every situation so far, this was caused by missing this section pasted from
the current Installation Guide:

Take one of the following actions to enable primary and secondary user IDs to
issue DB2 commands from the z/OS console or TSO SDSF:

Grant SYSOPR authority to all primary and secondary user IDs that issue DB2
commands from the z/OS console or TSO SDSF. Issue the following command:
GRANT SYSOPR TO userid

(If you are using RACF for access control) Define RACF classes to authorize
DB2 commands. Use the following statements:
SETR CLASSACT(DSNADM)
RDEFINE DSNADM DSN1.SYSOPR UACC(NONE)
SETR RACLIST(DSNADM) REFRESH
PERMIT DSN1.SYSOPR CLASS(DSNADM) ID(userid) ACCESS(READ)
SETR RACLIST(DSNADM) REFRESH

Prior to V8, SYSOPR was used as the authority running commands. With V8,
you need to have authority defined. If you are reading print, then it's time to
get the soft copy and print it, as this was in update some years ago.

Roger Miller, DB2 for z/OS

On Tue, 13 Jan 2009 20:37:25 +0000, Donna Domovic
<[login to unmask email]> wrote:

>Hello,
>
>We've started to upgrade to DB2 v8 CM and seem to be running in to a weird
>situation.
>
>We have a 2 member data sharing group both currently running DB2 v8 CM.
>When we issue commands from the mvs console against the DB2R member,
the
>command works as expected. When we issue the same command against the
>second member, DB1R, we receive authorization errors like the following that
>was received from a DISPLAY THREAD command:
>
>-DB1R DIS THREAD(*)
>DSN9016I -DB1R '-DIS' COMMAND REJECTED, UNAUTHORIZED REQUEST
>DSN9023I -DB1R DSN9SCND '-DIS THREAD' ABNORMAL COMPLETION
>
>I know with DB2 v8, commands from the console are treated differently and
>we should have to define the DBxx.SYSOPR resource to the DSNR class but
we
>checked and the SYSOPR resource isn't defined for any of our DB2
subsystems.
>
>Does anyone have any ideas on why we may be seeing the difference
between
>the 2 subsystems and how to correct it? We're trying to make sure the
DBAs,
>System Programmers, and Data Center operators will still have the
>authorization they need to issue the various DB2 commands.
>
>Thanks in advance.
>
>Donna Domovic
>

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Donna Domovic

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Roger Miller)
Thanks for the information. It looks like we will need to define a new RACF
class and then define the appropriate resources to handle SYSOPR
authorization.

Even though the RACF part isn't done, there are a few things that concern
me.

First, both subsystems in the group are running at the same level and on the
same lpar yet the commands from the console fail with the authorization error
when submtted against the DB1R member and work when submitted against
the DB2R member. (The commands work on both systems when they are
rolled back to DB2 v7.) I compared the SDSNLOAD and SDSNEXIT loadlibs and
the only member different is the zparm module. If possible, I'd like to figure
out what's causing the difference between the 2 subsystems.

Second, since we don't have the resources defined to RACF yet, I tried
granting SYSOPR to my primary id and then issuing the commands. Even after
doing that, the command still fails on the DB1R member.

We're running out of things to look at to account for the behavior difference
we're seeing between DB1R and DB2R so any suggestions would be
appreciated.

Thanks,
Donna Domovic

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Mike Bell

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Donna Domovic)
since the default userid is SYSOPR make sure both zparms have an entry like
SYSOPR2=SYSOPR

Which is what I have in all my zparms.

You can check this by building the DSNWZP stored procedure using DSNTIJSG
from new.sdsnsamp
And then running the sample program in job DSNTEJ6Z from sdsnsamp which
calls DSNWZP and produces a report.
If you do that on both subsystems, you will have a report that you can
compare the zparm sysadm and sysoper fields.

Mike
HLS Technologies

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Donna Domovic
Sent: Wednesday, January 14, 2009 12:51 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Authorization error after upgrade to DB2 v8 CM

Thanks for the information. It looks like we will need to define a new RACF
class and then define the appropriate resources to handle SYSOPR
authorization.

Even though the RACF part isn't done, there are a few things that concern
me.

First, both subsystems in the group are running at the same level and on the
same lpar yet the commands from the console fail with the authorization
error when submtted against the DB1R member and work when submitted against
the DB2R member. (The commands work on both systems when they are rolled
back to DB2 v7.) I compared the SDSNLOAD and SDSNEXIT loadlibs and the only
member different is the zparm module. If possible, I'd like to figure out
what's causing the difference between the 2 subsystems.

Second, since we don't have the resources defined to RACF yet, I tried
granting SYSOPR to my primary id and then issuing the commands. Even after
doing that, the command still fails on the DB1R member.

We're running out of things to look at to account for the behavior
difference we're seeing between DB1R and DB2R so any suggestions would be
appreciated.

Thanks,
Donna Domovic

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You
should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Dave Smith

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Mike Bell)
Hey Donna,

Check the SYSOPR1 and SYSOPR2 specifications in the DSN6SPRM section of your ZPARMs. One of those should be SYSOPRx=SYSOPR.

Dave

Hennepin County Central IT
Operations/Mainframe Services
[login to unmask email]



Donna Domovic <[login to unmask email]>
Sent by: DB2 Data Base Discussion List
<[login to unmask email]> To
[login to unmask email]
cc
01/14/2009 01:19 PM
Subject
Re: [DB2-L] Authorization error after upgrade to DB2 v8 CM
Please respond to
DB2 Database Discussion list at IDUG
<[login to unmask email]>







Thanks for the information. It looks like we will need to define a new RACF
class and then define the appropriate resources to handle SYSOPR
authorization.

Even though the RACF part isn't done, there are a few things that concern
me.

First, both subsystems in the group are running at the same level and on the
same lpar yet the commands from the console fail with the authorization error
when submtted against the DB1R member and work when submitted against
the DB2R member. (The commands work on both systems when they are
rolled back to DB2 v7.) I compared the SDSNLOAD and SDSNEXIT loadlibs and
the only member different is the zparm module. If possible, I'd like to figure
out what's causing the difference between the 2 subsystems.

Second, since we don't have the resources defined to RACF yet, I tried
granting SYSOPR to my primary id and then issuing the commands. Even after
doing that, the command still fails on the DB1R member.

We're running out of things to look at to account for the behavior difference
we're seeing between DB1R and DB2R so any suggestions would be
appreciated.

Thanks,
Donna Domovic

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html


Disclaimer: Information in this message or an attachment may be government data and thereby subject to the Minnesota Government Data Practices Act, Minnesota Statutes, Chapter 13, may be subject to attorney-client or work product privilege, may be confidential, privileged, proprietary, or otherwise protected, and the unauthorized review, copying, retransmission, or other use or disclosure of the information is strictly prohibited. If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly delete this message from your computer system.

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Ulrich Boche

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Dave Smith)


On Wednesday, 14.01.2009 at 18:51 GMT, Donna Domovic
<[login to unmask email]> wrote:
> Thanks for the information. It looks like we will need to define a new
RACF
> class and then define the appropriate resources to handle SYSOPR
> authorization.
>
> Even though the RACF part isn't done, there are a few things that concern
> me.
>
> First, both subsystems in the group are running at the same level and on
the
> same lpar yet the commands from the console fail with the authorization
error
> when submtted against the DB1R member and work when submitted against
> the DB2R member. (The commands work on both systems when they are
> rolled back to DB2 v7.) I compared the SDSNLOAD and SDSNEXIT loadlibs
and
> the only member different is the zparm module. If possible, I'd like to
figure
> out what's causing the difference between the 2 subsystems.
>
> Second, since we don't have the resources defined to RACF yet, I tried
> granting SYSOPR to my primary id and then issuing the commands. Even
after
> doing that, the command still fails on the DB1R member.
>
> We're running out of things to look at to account for the behavior
difference
> we're seeing between DB1R and DB2R so any suggestions would be
> appreciated.
>

Since you haven't any DB2 resources defined in RACF, I would assume that
you didn't activate the RACF access control module [login to unmask email] Therefore,
activating class DSNADM and defining profiles there wouldn't really help
you as no RACF checking is performed.

What you might be able to do is, if you defined SYSOPRx=SYSOPR in your
ZPARMS as suggested in other postings, to define SYSOPR as a RACF group.
Defining it as a userid wouldn't be of much use since everybody who wants
to issue DB2 commands would then need to use this userid. If you define it
as a group, you can connect the users who need to issue DB2 commands to the
group which should give them SYSOPR authority.

As an alternative to the ZPARM definition, as suggested in Roger Miller's
posting, you could also GRANT SYSOPR to the appropriate users.

Another alternative with more elegance: define a group named SYSOPR (or
SYSOPRGP or whatever), issue GRANT SYSOPR TO SYSOPRGP and then connect the
users who should have SYSOPR authority to that group. If you use the ZPARM
definition for SYSOPR, the users are install SYSOPRs which means you won't
ever see anything they're doing with that authority in a trace or, should
you ever activate RACF checking for DB2 resources, in your SMF logs.
--
Ulrich Boche
SVA GmbH, Germany

______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Ulrich Boche

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Ulrich Boche)


On Wednesday, 14.01.2009 at 18:51 GMT, Donna Domovic
<[login to unmask email]> wrote:
> Thanks for the information. It looks like we will need to define a new
RACF
> class and then define the appropriate resources to handle SYSOPR
> authorization.
>
> Even though the RACF part isn't done, there are a few things that concern
> me.
>
> First, both subsystems in the group are running at the same level and on
the
> same lpar yet the commands from the console fail with the authorization
error
> when submtted against the DB1R member and work when submitted against
> the DB2R member. (The commands work on both systems when they are
> rolled back to DB2 v7.) I compared the SDSNLOAD and SDSNEXIT loadlibs
and
> the only member different is the zparm module. If possible, I'd like to
figure
> out what's causing the difference between the 2 subsystems.
>
> Second, since we don't have the resources defined to RACF yet, I tried
> granting SYSOPR to my primary id and then issuing the commands. Even
after
> doing that, the command still fails on the DB1R member.
>
> We're running out of things to look at to account for the behavior
difference
> we're seeing between DB1R and DB2R so any suggestions would be
> appreciated.
>

Since you haven't any DB2 resources defined in RACF, I would assume that
you didn't activate the RACF access control module [login to unmask email] Therefore,
activating class DSNADM and defining profiles there wouldn't really help
you as no RACF checking is performed.

What you might be able to do is, if you defined SYSOPRx=SYSOPR in your
ZPARMS as suggested in other postings, to define SYSOPR as a RACF group.
Defining it as a userid wouldn't be of much use since everybody who wants
to issue DB2 commands would then need to use this userid. If you define it
as a group, you can connect the users who need to issue DB2 commands to the
group which should give them SYSOPR authority.

As an alternative to the ZPARM definition, as suggested in Roger Miller's
posting, you could also GRANT SYSOPR to the appropriate users.

Another alternative with more elegance: define a group named SYSOPR (or
SYSOPRGP or whatever), issue GRANT SYSOPR TO SYSOPRGP and then connect the
users who should have SYSOPR authority to that group. If you use the ZPARM
definition for SYSOPR, the users are install SYSOPRs which means you won't
ever see anything they're doing with that authority in a trace or, should
you ever activate RACF checking for DB2 resources, in your SMF logs.
--
Ulrich Boche
SVA GmbH, Germany

______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Donna Domovic

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Ulrich Boche)
Our zparm settings have [login to unmask email] and SYSOPR2=SYSOPR.

Since we don't have RACF security currently set up for DB2, I granted my
primary id SYSOPR authority. Even after doing this, commands issued from the
console work for the DB2R member of the group but fail for the DB1R member
of the group. (Within DB2I or batch, they work against both subsystems.)

Is there anything else on the z/OS or DB2 side that can be causing the
difference between the 2 systems?

We are going to try implementing the RACF authorization but we'd like to get
both subsystems working the same way first so that we have a good starting
point.

Thanks again for any help.

Donna Domovic


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Donna Domovic

Re: Authorization error after upgrade to DB2 v8 CM
(in response to Donna Domovic)
Just wanted to let everyone know we figured out what was causing this
problem. Here's a summary.

What we consider the console is actually some type of console simulator
software called SCON (not sure if this is the official name or not). Talking the
issue over with our MVS system programmer, he remembered that commands
issued from SCON actually run with the id the started task is running under.
We put that id in the zparm modules and now commands work from both
members of the group.

Still not sure why the 2 systems were acting differently but, since they seem
to be the same now, there's no further work necessary.

Thanks for everyone's help trying to figure this out.

Donna Domovic


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html