ASSUMING SYSADM

Brian Hirman

ASSUMING SYSADM
Our organization is looking into assuming SYSADM responsibilities for
both our development and production DB2 environments. We currently have
DBADM privileges for our application databases (a small but critical
COTS package) but would like to expand our role so to reduce cost as
well as to avoid possible risks and other issues when the two functions
are separated.

From what I can tell our existing z/OS DB2 environments have all DB2
software and subsystems installed under system-level datasets (HLQs
consisting of SYS2, SYS2A and SYS3). An issue we see is that our
service provider allows us only read, not update, capabilities to
system-level datasets (which is understandable).

Can DB2 be installed with the base software under system-level datasets
while the subsystem is under something else? If so, how difficult will
it be to move our existing subsystem out from under system-level
datasets to a different HLQ that we have R/W access? Any other concerns
we may need to deal with?

TIA,
Brian Hirman
DOD

> Privacy Act - 1974 as Amended applies--If this E-mail or attachments
> contain personal and/or assignment information, it must be protected
> IAW DoD 5400.11R and it is For Official Use Only (FOUO).
>
>

---------------------------------------------------------------------------------
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: ASSUMING SYSADM
(in response to Brian Hirman)
The issue with moving software installation and support away from systems programming to a DBA group is a challenge far greater than obtaining the required RACF or equivalent authorities.

The data set authorities are actually trivial in comparison to some of the other issues.

Almost every employed position is associated with sub-ordinates, superiors, and staff relationships. It turns out these relationships or the human and social interactions are quite different between systems programmers and DBA's. Some examples:
Direct application programmer, application design, and end user support is typically something a DBA does, not a Systems Programmer.
Vendor interfaces (to IBM for example) is something a Systems Programmer does, not typically a DBA.
It is not a question of how difficult these relationships are but if it is reasonable to assume them with ones other responsibilities. I for example know how to grow corn ... I have both formal education and practical experience for doing so. However I buy my corn not only pre grown but pre cooked as well at the local dinner. Why growing corn is simply not a good use of my time nor does it serve my customers or community.


Every position has co-lateral responsibilities. As an example the group responsible for installing and maintaining the DB2 vendor software has access to APF authorized data sets ... SDSNLOAD and SDSNEXIT for example. Authorized data sets contain authorized programs. Authorized programs can really do any thing they want, by passing security including any logging or audit trail. Is it as reasonable to move control and access for the entire mainframe environment to DBA's as it is to move software installation and service support for DB2 only? Problem is you have to do both and some one will notice especially if your Internet domain ends with ".mil"

So you may know about growing corn, but what about SMP/E, how about the software requirements for all the other lines of business at your firm besides the small but critical COTS package.

There are usually good reasons for separating responsibilities and the reason may not be "How difficult is it".

By the way if you choose to share military secrets with this list server, you might get good advice from some of the members and I for one will try not to tell.

"HIRMAN, BRIAN" <[login to unmask email]> wrote:
Our organization is looking into assuming SYSADM responsibilities for
both our development and production DB2 environments. We currently have
DBADM privileges for our application databases (a small but critical
COTS package) but would like to expand our role so to reduce cost as
well as to avoid possible risks and other issues when the two functions
are separated.

From what I can tell our existing z/OS DB2 environments have all DB2
software and subsystems installed under system-level datasets (HLQs
consisting of SYS2, SYS2A and SYS3). An issue we see is that our
service provider allows us only read, not update, capabilities to
system-level datasets (which is understandable).

Can DB2 be installed with the base software under system-level datasets
while the subsystem is under something else? If so, how difficult will
it be to move our existing subsystem out from under system-level
datasets to a different HLQ that we have R/W access? Any other concerns
we may need to deal with?

TIA,
Brian Hirman
DOD

> Privacy Act - 1974 as Amended applies--If this E-mail or attachments
> contain personal and/or assignment information, it must be protected
> IAW DoD 5400.11R and it is For Official Use Only (FOUO).
>
>

---------------------------------------------------------------------------------
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
(877)311-0480 Voice Mail
[login to unmask email]
Http://www.IBMsysProg.com




---------------------------------------------------------------------------------
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