Mainframe DBA's without DBADMIN in production?

Michael Jessen

Mainframe DBA's without DBADMIN in production?
Does anyone out in DB2land have any documentation or best practices on
setting up dba authority in a production environment? I'm very interested
in hearing what companies allow dbadmin authority in production and the
reasoning behind allowing this authority. My assumption is that most
companies allow this level of authority for the dba team, but any/all
supporting documentation and/or best practices information would be nice to
hear about.

I'm putting together a proposal to justify why our dbas should have dbadmin
authority and I would appreciate any input you may have to further my cause!

In case you are wondering... Our goal state is that all production database
modifications be run thru our change control (ChangeMan) environment...
DBA's would have very limited (if any) access to production databases.

Thanks!
Mike

ps - Have I mentioned we have a job opening for a senior level mainframe
dba. If I said we have a great environment would you believe me?
Seriously, we do have a good environment... I'm just trying to keep it that
way :-)

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Dan Michaelis

Re: Mainframe DBA's without DBADMIN in production?
(in response to Michael Jessen)
Mike,

I can only offer you my personal opinions, tainted by my experiences with
both good and bad change management procedures. I've worked in a couple of
large shops (Disney and Verizon) and a couple of small shops (of whom I'm
guessing you've never heard), so I've got a variety of experiences.

With any restrictive change management system, the intent is to ensure that
changes to the production environments are as well thought out and tested as
they can possibly be, and that their implementation is practiced and
proofed, to minimize the impact of mistakes on the user community (but you
know that). It's worth repeating that, because it's easy to forget it, and
think that the reason for change management is to employ the people who
manage changes, and to annoy those who are managed by it.

It is a firm belief of mine, having been both a developer and a production
support DBA, that nobody in a development role should have write access to
ANYTHING on the production systems. I'd even argue (in some cases) that
read access isn't a good idea for developers either. Now this makes the
assumption that you've got enough people to segregate them; if you're in a
small shop, this really doesn't work, and you're stuck. The reasoning
behind this is that while the production support staff and the developers
are on the same "team"... They come at service provisioning from different
perspectives. From a developer's point of view, anything that adds new
(useful) features quickly, or resolves issues immediately is a good thing.
From the support staff perspective, anything that maintains stability, and
is repeatable (from a troubleshooting/correcting perspective) is a good
thing. Often these two approaches are at odds with each other. In the
better-run organizations, they act as a set of checks and balances, where
the production support staff provide necessary "edits" on enhancements and
fixes, and the development staff push hard on the production support staff
to implement new features as quickly as is possible. It can go bad as well,
but for the most part, the system works.

That said, whether you deny your development DBA's access to the production
system or not, the important thing is to make sure that you have COMPETENT
DBA's who can make changes to the production system. Change management
works wonderfully... Until something is so badly broken that it requires
immediate action by someone who knows what he/she is doing. I have
experience in organizations where the intent was to reduce the production
support DBA's role to that of a database operator, and I can say
unequivocally that it's a bad idea to do that. Corrective action is delayed
as communications have to go through middle-men, preventative maintenance is
often missed, because of the lack of skills in the production support
operators, and customers are almost always unhappy, because when they do
have questions or issues, it always requires a committee to answer or
resolve them.

Assuming that you have production support DBA staff separate from developer
staff, you ought to be good. Your PS DBA's still ought to follow change
management procedures for routine maintenance (adding space, altering
bufferpools, changing instance parameters, etc.), if for no other reason
than to document the work that they're doing. For emergencies, the most
effective thing that I've seen is to allow the people involved to do the
work necessary to resolve the issue, and then to document what was done in
an "after the fact" change record. That way, you don't inhibit the
corrective process, but you get documentation about how the system was
modified so that you're aware of it for the next go-round.

The last point that I'd make is to ensure that whatever change management
processes you have/put in place, you want to make sure that the person who
is driving the change (likely the business owner for the changing process)
is responsible for ensuring that the work is coordinated, rather than
shuffling that off to the lowest level individual on the team. If you do
the latter, at best, you have a rubber-stamp wielder, who doesn't know the
impacts of good or bad decisions on his/her part, and at worst, you have
someone who is vested in making the process onerous to inflate his/her ego
and sense of importance (not that I've ever run into this or anything... )
And for those who say that you need to ensure security by revoking access
from your DBA's; remind them that SOMEONE has to have the keys to the
kingdom... Do you want it to be the king, or a peasant?

Thanks.

Dan Michaelis

Database Administrator/Developer
eOriginal
351 West Camden Street
Suite 800
Baltimore, MD 21201

410.625.5187 (phone)
410.659.9799 (fax)

-----Original Message-----
From: Mike Jessen [mailto:[login to unmask email]
Sent: Friday, December 10, 2004 1:31 PM
To: [login to unmask email]
Subject: Mainframe DBA's without DBADMIN in production?

Does anyone out in DB2land have any documentation or best practices on
setting up dba authority in a production environment? I'm very interested
in hearing what companies allow dbadmin authority in production and the
reasoning behind allowing this authority. My assumption is that most
companies allow this level of authority for the dba team, but any/all
supporting documentation and/or best practices information would be nice to
hear about.

I'm putting together a proposal to justify why our dbas should have dbadmin
authority and I would appreciate any input you may have to further my cause!

In case you are wondering... Our goal state is that all production database
modifications be run thru our change control (ChangeMan) environment...
DBA's would have very limited (if any) access to production databases.

Thanks!
Mike

ps - Have I mentioned we have a job opening for a senior level mainframe
dba. If I said we have a great environment would you believe me?
Seriously, we do have a good environment... I'm just trying to keep it that
way :-)

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Doyle Mark

Re: Mainframe DBA's without DBADMIN in production?
(in response to Dan Michaelis)
Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Rohn Solecki

Re: Mainframe DBA's without DBADMIN in production?
(in response to Doyle Mark)
At a prior employer although DBA had DBADM rights but our unofficial rule was "DBA does structure changes (table changes etc), developers do data manipulation (insert/update/delete)". Basically our manager didn't want DBA doing data changes for the obvious reason that we didn't have the required depth of knowledge about what the data was supposed to look like. The developers, looking at the code and working with the business analysts would have access to knowledge required to determine if a data change was appropriate.

Rohn Solecki

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 2:32 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Avram Friedman

Re: Mainframe DBA's without DBADMIN in production?
(in response to Rohn Solecki)
DBADMIN authority is automatically granted to the creator of a data
base.
The suggestion that the DBA's not create databases seems a bit odd to
me.
DBA stands for DataBase Administration after all.

Being very stingy on DBADMIN authority outside of DBA has merit.

I guess the idea of restricting read write access has merit so why not
just give DBA SYSCTRL.
While this is possible
1. Some one still has to create the database and will therefore have
DBADMIN
2. It is easier to 'go with the flow' DB2 wants to give DBA DBADMIN
3. What about emergencies. Any one who might need DBADMIN oncall should
IMHO have it all the time

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Mike Jessen
Sent: Friday, December 10, 2004 1:31 PM
To: [login to unmask email]
Subject: Mainframe DBA's without DBADMIN in production?

Does anyone out in DB2land have any documentation or best practices on
setting up dba authority in a production environment? I'm very
interested
in hearing what companies allow dbadmin authority in production and the
reasoning behind allowing this authority. My assumption is that most
companies allow this level of authority for the dba team, but any/all
supporting documentation and/or best practices information would be nice
to hear about.

I'm putting together a proposal to justify why our dbas should have
dbadmin authority and I would appreciate any input you may have to
further my cause!

In case you are wondering... Our goal state is that all production
database modifications be run thru our change control (ChangeMan)
environment...
DBA's would have very limited (if any) access to production databases.

Thanks!
Mike

ps - Have I mentioned we have a job opening for a senior level mainframe
dba. If I said we have a great environment would you believe me?
Seriously, we do have a good environment... I'm just trying to keep it
that way :-)

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Vaughan

Re: Mainframe DBA's without DBADMIN in production?
(in response to Avram Friedman)
How would you go about making structure changes if all you had was SYSCTRL? I realize that this includes DBCTRL over every database which would allow you to drop/create/alter any objects, but you would not have the ability to unload the data prior to a drop/recreate (hence no way to re-load the data). You would also lose the ability to re-grant security lost by the drop/recreate. This might be ok if the intent was that any structure modifications would run under a restricted change-control process so the dba doesn't need this authority, but then why even have sysctrl? Also keep in mind that you can't currently run an explain without having access to the data (I think I heard that this was changing, but don't quote me on that).
Also keep in mind the following blurb from the Admin guide -- "SYSCTRL authority is intended for separation of function, not for added security..." and "...an ID with SYSCTRL authority can grant itself SYSADM authority."

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 2:32 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to [login to unmask email] and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

William Favero

Re: Mainframe DBA's without DBADMIN in production?
(in response to Mike Vaughan)
Actually, if you grant the DBA CREATEDBA then they will have the DBADM
privilege set over the database. However, if you grant them CREATEDBC
they will get DBCTRL privilege set.

SYSCTRL may give a DBA a few more system level privileges than some
customers want them to have... Chapter 10 of the DB2 Admin guide as all
of the details.

Willie

Friedman, Avram (IT) wrote:

>DBADMIN authority is automatically granted to the creator of a data
>base.
>The suggestion that the DBA's not create databases seems a bit odd to
>me.
>DBA stands for DataBase Administration after all.
>
>Being very stingy on DBADMIN authority outside of DBA has merit.
>
>I guess the idea of restricting read write access has merit so why not
>just give DBA SYSCTRL.
>While this is possible
>1. Some one still has to create the database and will therefore have
>DBADMIN
>2. It is easier to 'go with the flow' DB2 wants to give DBA DBADMIN
>3. What about emergencies. Any one who might need DBADMIN oncall should
>IMHO have it all the time
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
>Behalf Of Mike Jessen
>Sent: Friday, December 10, 2004 1:31 PM
>To: [login to unmask email]
>Subject: Mainframe DBA's without DBADMIN in production?
>
>Does anyone out in DB2land have any documentation or best practices on
>setting up dba authority in a production environment? I'm very
>interested
>in hearing what companies allow dbadmin authority in production and the
>reasoning behind allowing this authority. My assumption is that most
>companies allow this level of authority for the dba team, but any/all
>supporting documentation and/or best practices information would be nice
>to hear about.
>
>I'm putting together a proposal to justify why our dbas should have
>dbadmin authority and I would appreciate any input you may have to
>further my cause!
>
>In case you are wondering... Our goal state is that all production
>database modifications be run thru our change control (ChangeMan)
>environment...
>DBA's would have very limited (if any) access to production databases.
>
>Thanks!
>Mike
>
>ps - Have I mentioned we have a job opening for a senior level mainframe
>dba. If I said we have a great environment would you believe me?
>Seriously, we do have a good environment... I'm just trying to keep it
>that way :-)
>
>------------------------------------------------------------------------
>---------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
>home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
>page select "Join or Leave the list". The IDUG DB2-L FAQ is at
>http://www.idugdb2-l.org. The IDUG List Admins can be reached at
>[login to unmask email] Find out the latest on IDUG conferences
>at http://conferences.idug.org/index.cfm
>--------------------------------------------------------
>
>NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
>
>
>---------------------------------------------------------------------------------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>
>
>

--
Willie
http://www.Red-Corvettes.com
62 Maroon, 98 Carmine, 99 MagRed (MTI 422), 03 Anniversary
I just love dark red.. LOL

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Doyle Mark

Re: Mainframe DBA's without DBADMIN in production?
(in response to William Favero)
Mike,

If your point is that DB2 security is confusing, arcane & a little bit
illogical, you'll get no argument from me.

But if your point is that it's impossible to get the job done with only
SYSCTRL, I would respectfully disagree.
Yes, the situations you describe might require DBAs to -- heaven
forbid! -- coordinate with users or developers, and may also require
increased vigilance (to quote further from the admin guide: "The only
control over such actions is to audit the activity of IDs with high
levels of authority."), but most of your objections are, in my opinion,
just straw men.

With Sarbanes-Oxley Section 404, these kinds of checks and balances are
likely to be more common, not less.


Mark




-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Vaughan, Mike
Sent: Friday, December 10, 2004 2:48 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


How would you go about making structure changes if all you had was
SYSCTRL? I realize that this includes DBCTRL over every database which
would allow you to drop/create/alter any objects, but you would not have
the ability to unload the data prior to a drop/recreate (hence no way to
re-load the data). You would also lose the ability to re-grant security
lost by the drop/recreate. This might be ok if the intent was that any
structure modifications would run under a restricted change-control
process so the dba doesn't need this authority, but then why even have
sysctrl? Also keep in mind that you can't currently run an explain
without having access to the data (I think I heard that this was
changing, but don't quote me on that).
Also keep in mind the following blurb from the Admin guide --
"SYSCTRL authority is intended for separation of function, not for added
security..." and "...an ID with SYSCTRL authority can grant itself
SYSADM authority."

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 2:32 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable
law. If you are not the intended recipient, any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us
immediately by reply email to [login to unmask email] and delete or
destroy all copies of the original message and attachments thereto.
Email sent to or from the Principal Financial Group or any of its member
companies may be retained as required by law or regulation.

Nothing in this message is intended to constitute an Electronic
signature for purposes of the Uniform Electronic Transactions Act (UETA)
or the Electronic Signatures in Global and National Commerce Act
("E-Sign") unless a specific statement to the contrary is included in
this message.

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Vaughan

Re: Mainframe DBA's without DBADMIN in production?
(in response to Doyle Mark)
Um, ok, but how do you unload a table when all you have is sysctrl?

I actually don't find the db2 security all that confusing. It's annoying and has some goofy rules that I don't really care for, but my point really had nothing to do with confusion. The point I was trying to make is that you cannot just replace dbadmin with sysctrl and expect the dba's to do their jobs in the same way they did before -- either you need to make structure changes or you don't. If you do need to make structure changes then you need the authority to do so. If the changes are being made under another id running some type of controlled process then you also don't have a need for syscntrl (which, by the way is far more dangerous to have than dbadmin since it has authorities across the subsystem and not only on a single database - unless you really meant DBCTRL and not SYSCTRL?).

I should probably mention that I've been in the situation in the past where I was administering a database and I only had DBCTRL and not DBADM, so I realize it's possible to do. In that situation any activities that required a drop/recreate had to be run through a controlled job. With this in mind, I didn't really need DBCTRL either, and having it didn't really do me any good.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 3:23 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

If your point is that DB2 security is confusing, arcane & a little bit
illogical, you'll get no argument from me.

But if your point is that it's impossible to get the job done with only
SYSCTRL, I would respectfully disagree.
Yes, the situations you describe might require DBAs to -- heaven
forbid! -- coordinate with users or developers, and may also require
increased vigilance (to quote further from the admin guide: "The only
control over such actions is to audit the activity of IDs with high
levels of authority."), but most of your objections are, in my opinion,
just straw men.

With Sarbanes-Oxley Section 404, these kinds of checks and balances are
likely to be more common, not less.


Mark




-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Vaughan, Mike
Sent: Friday, December 10, 2004 2:48 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


How would you go about making structure changes if all you had was
SYSCTRL? I realize that this includes DBCTRL over every database which
would allow you to drop/create/alter any objects, but you would not have
the ability to unload the data prior to a drop/recreate (hence no way to
re-load the data). You would also lose the ability to re-grant security
lost by the drop/recreate. This might be ok if the intent was that any
structure modifications would run under a restricted change-control
process so the dba doesn't need this authority, but then why even have
sysctrl? Also keep in mind that you can't currently run an explain
without having access to the data (I think I heard that this was
changing, but don't quote me on that).
Also keep in mind the following blurb from the Admin guide --
"SYSCTRL authority is intended for separation of function, not for added
security..." and "...an ID with SYSCTRL authority can grant itself
SYSADM authority."

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 2:32 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable
law. If you are not the intended recipient, any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us
immediately by reply email to [login to unmask email] and delete or
destroy all copies of the original message and attachments thereto.
Email sent to or from the Principal Financial Group or any of its member
companies may be retained as required by law or regulation.

Nothing in this message is intended to constitute an Electronic
signature for purposes of the Uniform Electronic Transactions Act (UETA)
or the Electronic Signatures in Global and National Commerce Act
("E-Sign") unless a specific statement to the contrary is included in
this message.

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to [login to unmask email] and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Doyle Mark

Re: Mainframe DBA's without DBADMIN in production?
(in response to Mike Vaughan)
Mike,

Unloading a table -- Darn, you would pick up on the one functionality
point that had me say "most of" rather than "all of" your objections are
straw men.

I will agree to the annoying & goofy part, but as to the confusing part,
when was the last time you explained DB2 security to a pointy-haired
manager?

I think you hit upon it when you said "you cannot just replace dbadmin
with sysctrl and expect the dba's to do their jobs IN THE SAME WAY THEY
DID BEFORE." Truth is, the times, they are a-changing. Gone are the
free and easy days of yesteryear. We will continue to be more
integrated, less independent and have more people watching over our
shoulders than was true in the past. There are good and bad points to
these changes, but they are changes. And we have to start thinking about
the implications of our decisions and processes in this changing
environment.

I believe there is a happy medium between the DBA as independent
data-god, answerable to no-one and DBA as slave data-clerk who hasn't
the authority to blow his nose without a full-blown change management
process with 3 meetings and 15 signoffs. I think we (the profession)
are still trying to find that point.

I've worked in shops where I did it all -- ZPARMS to Databases to
programs to sending out end-user reports. I was a very fulfilling place
to work.

I've also worked in a shop that was very proud of its automated change
control processes. No one but change control had ANY DBA-type
permissions in production. Change control had all of the permissions,
but none of the knowledge; the DBA's had the knowledge but not the
permissions. Unbeknownst to almost everyone there, if you had a TSO ID
on the system, you could drop every production database in the house
(except the DB2 catalog) -- using the automated process to do it. Thank
goodness most TSO users didn't know that they had that power. So far,
that shop has dodged a lot of bullets (I think).

I believe that the CTRL-type authorities are the proper ones for DBAs.
I would argue (although not strenuously) that SYSCTRL is more
appropriate for DBAs than is a collection of individual DBCTRLs. After
all, you don't have HR / Finance / Manufacturing /etc. system
programmers, you just have system programmers, and you shouldn't have
HR / Finance / Manufacturing /etc. DBAs, just DBAs.

Thank you for a most interesting discussion. I'm leaving for the
weekend. If you like, we can pick this up next week.

Mark



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Vaughan, Mike
Sent: Friday, December 10, 2004 3:50 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Um, ok, but how do you unload a table when all you have is sysctrl?

I actually don't find the db2 security all that confusing. It's
annoying and has some goofy rules that I don't really care for, but my
point really had nothing to do with confusion. The point I was trying
to make is that you cannot just replace dbadmin with sysctrl and expect
the dba's to do their jobs in the same way they did before -- either you
need to make structure changes or you don't. If you do need to make
structure changes then you need the authority to do so. If the changes
are being made under another id running some type of controlled process
then you also don't have a need for syscntrl (which, by the way is far
more dangerous to have than dbadmin since it has authorities across the
subsystem and not only on a single database - unless you really meant
DBCTRL and not SYSCTRL?).

I should probably mention that I've been in the situation in the past
where I was administering a database and I only had DBCTRL and not
DBADM, so I realize it's possible to do. In that situation any
activities that required a drop/recreate had to be run through a
controlled job. With this in mind, I didn't really need DBCTRL either,
and having it didn't really do me any good.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 3:23 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

If your point is that DB2 security is confusing, arcane & a little bit
illogical, you'll get no argument from me.

But if your point is that it's impossible to get the job done with only
SYSCTRL, I would respectfully disagree.
Yes, the situations you describe might require DBAs to -- heaven
forbid! -- coordinate with users or developers, and may also require
increased vigilance (to quote further from the admin guide: "The only
control over such actions is to audit the activity of IDs with high
levels of authority."), but most of your objections are, in my opinion,
just straw men.

With Sarbanes-Oxley Section 404, these kinds of checks and balances are
likely to be more common, not less.


Mark




-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Vaughan, Mike
Sent: Friday, December 10, 2004 2:48 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


How would you go about making structure changes if all you had was
SYSCTRL? I realize that this includes DBCTRL over every database which
would allow you to drop/create/alter any objects, but you would not have
the ability to unload the data prior to a drop/recreate (hence no way to
re-load the data). You would also lose the ability to re-grant security
lost by the drop/recreate. This might be ok if the intent was that any
structure modifications would run under a restricted change-control
process so the dba doesn't need this authority, but then why even have
sysctrl? Also keep in mind that you can't currently run an explain
without having access to the data (I think I heard that this was
changing, but don't quote me on that).
Also keep in mind the following blurb from the Admin guide --
"SYSCTRL authority is intended for separation of function, not for added
security..." and "...an ID with SYSCTRL authority can grant itself
SYSADM authority."

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 2:32 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable
law. If you are not the intended recipient, any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us
immediately by reply email to [login to unmask email] and delete or
destroy all copies of the original message and attachments thereto.
Email sent to or from the Principal Financial Group or any of its member
companies may be retained as required by law or regulation.

Nothing in this message is intended to constitute an Electronic
signature for purposes of the Uniform Electronic Transactions Act (UETA)
or the Electronic Signatures in Global and National Commerce Act
("E-Sign") unless a specific statement to the contrary is included in
this message.

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable
law. If you are not the intended recipient, any dissemination,
distribution or copying of this communication is strictly prohibited. If
you have received this communication in error, please notify us
immediately by reply email to [login to unmask email] and delete or
destroy all copies of the original message and attachments thereto.
Email sent to or from the Principal Financial Group or any of its member
companies may be retained as required by law or regulation.

Nothing in this message is intended to constitute an Electronic
signature for purposes of the Uniform Electronic Transactions Act (UETA)
or the Electronic Signatures in Global and National Commerce Act
("E-Sign") unless a specific statement to the contrary is included in
this message.

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Bob Irving

Re: Mainframe DBA's without DBADMIN in production?
(in response to Doyle Mark)
Hi My 2 cents -

I work for a large Financial Svcs company - the practice here is to have 2
tso id's - 1 for sysadm in all development and QA environments, and that has
permissions to look at the DB2 Catalog in production, and 1 prod-access TSO id
that has SYSDADM authority in production, but only read authority in
development and QA environments. And, the prod-access id is audited by our
Information Security folks using Top-secret "foot prints" (or whatever it is called...)
. Any change /install or production touch if you will, requires a change
control meeting to explain what you are doing and formal documentation about the
change using a central repository/reporting tool. The accesses in production
by the prod-access id are logged and scrutinized by our information security
folks.

Being 24x7 and a large shop, we cannot afford to wait to fix things that go
bump in the night. It is more important here to minimize outages and fix
problems. Locking up the DBADM function (or, whatever level) into a change
control tool and bureaucracy takes away the ability to be nimble.

Only a fool here would do something unscrupulous in production as it would
cost them their job, and a whole lot more...

Bob Irving

Fidelity Investments



---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Vaughan

Re: Mainframe DBA's without DBADMIN in production?
(in response to Bob Irving)
Unfortunately, unloads are not the *one* functionality that sysctrl cannot do, it's really just one example. You could also include grants of objects that need to be dropped/recreated as well as creating views. My point was not to try to list off each of the items that sysctrl cannot do, but to point out that if the task that needs to be accomplished involves dropping and recreating a table then an authid that only has sysctrl simply does not have the horsepower to get the job done. I believe that V8 will change this for many types of changes since you will be able to use alter instead of drop/recreate for more types of changes, but there will still be occasions where a drop/recreate is required.
Yes, times are changing and believe me I'm already up to my eyeballs with SOX as well. In my opinion change management questions and "who is answerable to who" is really a side-discussion that is not neccessarily related to security - A person can have security to do their job but still be held accountable for their actions. As people start to look at their security setup they just need to keep in mind that if they replace a dbadm authority with a CTRL authority then they also need to provide a method for the dba's to do their job, because CTRL authority does not provide it.
On a side note, I also don't agree with the statement that "you shouldn't have HR / Finance / Manufacturing /etc. DBAs, just DBAs", but I'll save that one for another time (for a quick explanation - our dba's are decentralized, so we defintely are split by the applications being supported).

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 5:01 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

Unloading a table -- Darn, you would pick up on the one functionality
point that had me say "most of" rather than "all of" your objections are
straw men.

I will agree to the annoying & goofy part, but as to the confusing part,
when was the last time you explained DB2 security to a pointy-haired
manager?

I think you hit upon it when you said "you cannot just replace dbadmin
with sysctrl and expect the dba's to do their jobs IN THE SAME WAY THEY
DID BEFORE." Truth is, the times, they are a-changing. Gone are the
free and easy days of yesteryear. We will continue to be more
integrated, less independent and have more people watching over our
shoulders than was true in the past. There are good and bad points to
these changes, but they are changes. And we have to start thinking about
the implications of our decisions and processes in this changing
environment.

I believe there is a happy medium between the DBA as independent
data-god, answerable to no-one and DBA as slave data-clerk who hasn't
the authority to blow his nose without a full-blown change management
process with 3 meetings and 15 signoffs. I think we (the profession)
are still trying to find that point.

I've worked in shops where I did it all -- ZPARMS to Databases to
programs to sending out end-user reports. I was a very fulfilling place
to work.

I've also worked in a shop that was very proud of its automated change
control processes. No one but change control had ANY DBA-type
permissions in production. Change control had all of the permissions,
but none of the knowledge; the DBA's had the knowledge but not the
permissions. Unbeknownst to almost everyone there, if you had a TSO ID
on the system, you could drop every production database in the house
(except the DB2 catalog) -- using the automated process to do it. Thank
goodness most TSO users didn't know that they had that power. So far,
that shop has dodged a lot of bullets (I think).

I believe that the CTRL-type authorities are the proper ones for DBAs.
I would argue (although not strenuously) that SYSCTRL is more
appropriate for DBAs than is a collection of individual DBCTRLs. After
all, you don't have HR / Finance / Manufacturing /etc. system
programmers, you just have system programmers, and you shouldn't have
HR / Finance / Manufacturing /etc. DBAs, just DBAs.

Thank you for a most interesting discussion. I'm leaving for the
weekend. If you like, we can pick this up next week.

Mark



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Vaughan, Mike
Sent: Friday, December 10, 2004 3:50 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Um, ok, but how do you unload a table when all you have is sysctrl?

I actually don't find the db2 security all that confusing. It's
annoying and has some goofy rules that I don't really care for, but my
point really had nothing to do with confusion. The point I was trying
to make is that you cannot just replace dbadmin with sysctrl and expect
the dba's to do their jobs in the same way they did before -- either you
need to make structure changes or you don't. If you do need to make
structure changes then you need the authority to do so. If the changes
are being made under another id running some type of controlled process
then you also don't have a need for syscntrl (which, by the way is far
more dangerous to have than dbadmin since it has authorities across the
subsystem and not only on a single database - unless you really meant
DBCTRL and not SYSCTRL?).

I should probably mention that I've been in the situation in the past
where I was administering a database and I only had DBCTRL and not
DBADM, so I realize it's possible to do. In that situation any
activities that required a drop/recreate had to be run through a
controlled job. With this in mind, I didn't really need DBCTRL either,
and having it didn't really do me any good.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 3:23 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

If your point is that DB2 security is confusing, arcane & a little bit
illogical, you'll get no argument from me.

But if your point is that it's impossible to get the job done with only
SYSCTRL, I would respectfully disagree.
Yes, the situations you describe might require DBAs to -- heaven
forbid! -- coordinate with users or developers, and may also require
increased vigilance (to quote further from the admin guide: "The only
control over such actions is to audit the activity of IDs with high
levels of authority."), but most of your objections are, in my opinion,
just straw men.

With Sarbanes-Oxley Section 404, these kinds of checks and balances are
likely to be more common, not less.


Mark




-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Vaughan, Mike
Sent: Friday, December 10, 2004 2:48 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


How would you go about making structure changes if all you had was
SYSCTRL? I realize that this includes DBCTRL over every database which
would allow you to drop/create/alter any objects, but you would not have
the ability to unload the data prior to a drop/recreate (hence no way to
re-load the data). You would also lose the ability to re-grant security
lost by the drop/recreate. This might be ok if the intent was that any
structure modifications would run under a restricted change-control
process so the dba doesn't need this authority, but then why even have
sysctrl? Also keep in mind that you can't currently run an explain
without having access to the data (I think I heard that this was
changing, but don't quote me on that).
Also keep in mind the following blurb from the Admin guide --
"SYSCTRL authority is intended for separation of function, not for added
security..." and "...an ID with SYSCTRL authority can grant itself
SYSADM authority."

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Doyle Mark
Sent: Friday, December 10, 2004 2:32 PM
To: [login to unmask email]
Subject: Re: Mainframe DBA's without DBADMIN in production?


Mike,

To expand on what Dan so eloquently wrote . . .

If I were you, I wouldn't push for DBADM authority (which includes
reading & changing the data), but for SYSCTL authority (which has all of
the permissions to the structure, and no permissions the the data
itself) . See the admin guide section 3.1.2.3 for a great diagram on how
all the auths fit together.

Furthermore, I would expect that SYSCTL would be an easier sell than
DBADM (for all the reasons Dan mentioned).


HTH

Mark


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to [login to unmask email] and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm