DB2 z/OS OMVS set up

Jim Lazowski

DB2 z/OS OMVS set up
Hello,
I'm installing DB2 V8.1 on z/OS, but this also pertains to V7.1. I'm
looking for a good way to set up the OMVS DB2 environment so that Maint
can be rolled around the subsystems on an lpar. The book says to
install in /usr/lpp/db2x10 and put the paths in the omvs profile so that
the PATH, LIBPATH and CLASSPATH etc. get picked up automatically. This
being the case only one subsystem/maint level can be pointed to at a
time in the lpar. Does anyone have a slick way of setting up the
OMVS/DB2 environment to allow for rolling maint around to subsystems,
but not cause everyone to have a hard coded dot profile (.profile) with
unique subsystem specific settings?

Thanks for the input!

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

John McKown

Re: DB2 z/OS OMVS set up
(in response to Jim Lazowski)
Two thoughts:

1) Instead of putting the assignments in the individuals' .profile, put
them in the /etc/profile which is used by everybody. When you go to a
new release, put it in its own subdirectory. Update the /etc/profile to
point to this new subdirectory.

2) Use symlinks. This is a bit more involved. But suppose that you have
the actual subdirectory being "/usr/lpp/db2a10" at present. Well, in the
/usr/lpp subdirectory create a symlink of "db2prod" to "db2a10" (command
is "cd /usr/lpp; ln -sf db2a10 db2prod"). Then reference
/usr/lpp/db2prod in the profile(s). When you want to upgrade, leave the
/usr/lpp/db2a10 alone and install, for example, into /usr/lpp/db2b10.
When you want everybody to start using that subdirectory, go to /usr/lpp
and do an "ln -sf db2b10 db2prod". This will switch the "db2prod" entry
to point to db2b10 instead of db2a10.

3) an extention on the above. Suppose you want to allow people who what
to test new releases to do so. Well, you can create a symlink called
"db2new" (just an example) to point to the new release. The testers use
the name "/usr/lpp/db2new". When "db2new" is set to be the "production"
release, leave the "db2new" pointing to where it is and just, as above,
point db2prod to the new subdirectory name. At the same time, you could
possibly have another symlink, call "db2old" which you could point to
the "old" release subdirectory. When you finally don't really want
anybody to use the "old" release, point the symlink "db2old" to the
current release.

Of course, when you are first starting off, say with db2a10, then point
"db2new", "db2prod", and "db2old" to db2a10. No reason why not that I
can think of.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Lazowski, James S (Jim)
Sent: Monday, December 19, 2005 4:05 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 z/OS OMVS set up



Hello,
I'm installing DB2 V8.1 on z/OS, but this also pertains to V7.1.
I'm looking for a good way to set up the OMVS DB2 environment so that
Maint can be rolled around the subsystems on an lpar. The book says to
install in /usr/lpp/db2x10 and put the paths in the omvs profile so that
the PATH, LIBPATH and CLASSPATH etc. get picked up automatically. This
being the case only one subsystem/maint level can be pointed to at a
time in the lpar. Does anyone have a slick way of setting up the
OMVS/DB2 environment to allow for rolling maint around to subsystems,
but not cause everyone to have a hard coded dot profile (.profile) with
unique subsystem specific settings?

Thanks for the input!


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

Jim Lazowski

Re: DB2 z/OS OMVS set up
(in response to John McKown)
John,
That sounds good...When you do it this way how do you handle maint that
hits SDSNLOD2? Do you steplib to it in profile or have it in the
linklst? Either way you can only point to one copy making it not
possible to roll maint around the subsystems for this dataset. For
these events do you have to hit all subsystems at the same time?

________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of McKown, John
Sent: Monday, December 19, 2005 4:32 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 z/OS OMVS set up


Two thoughts:

1) Instead of putting the assignments in the individuals' .profile, put
them in the /etc/profile which is used by everybody. When you go to a
new release, put it in its own subdirectory. Update the /etc/profile to
point to this new subdirectory.

2) Use symlinks. This is a bit more involved. But suppose that you have
the actual subdirectory being "/usr/lpp/db2a10" at present. Well, in the
/usr/lpp subdirectory create a symlink of "db2prod" to "db2a10" (command
is "cd /usr/lpp; ln -sf db2a10 db2prod"). Then reference
/usr/lpp/db2prod in the profile(s). When you want to upgrade, leave the
/usr/lpp/db2a10 alone and install, for example, into /usr/lpp/db2b10.
When you want everybody to start using that subdirectory, go to /usr/lpp
and do an "ln -sf db2b10 db2prod". This will switch the "db2prod" entry
to point to db2b10 instead of db2a10.

3) an extention on the above. Suppose you want to allow people who what
to test new releases to do so. Well, you can create a symlink called
"db2new" (just an example) to point to the new release. The testers use
the name "/usr/lpp/db2new". When "db2new" is set to be the "production"
release, leave the "db2new" pointing to where it is and just, as above,
point db2prod to the new subdirectory name. At the same time, you could
possibly have another symlink, call "db2old" which you could point to
the "old" release subdirectory. When you finally don't really want
anybody to use the "old" release, point the symlink "db2old" to the
current release.

Of course, when you are first starting off, say with db2a10, then point
"db2new", "db2prod", and "db2old" to db2a10. No reason why not that I
can think of.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Lazowski, James S (Jim)
Sent: Monday, December 19, 2005 4:05 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 z/OS OMVS set up



Hello,
I'm installing DB2 V8.1 on z/OS, but this also pertains to V7.1.
I'm looking for a good way to set up the OMVS DB2 environment so that
Maint can be rolled around the subsystems on an lpar. The book says to
install in /usr/lpp/db2x10 and put the paths in the omvs profile so that
the PATH, LIBPATH and CLASSPATH etc. get picked up automatically. This
being the case only one subsystem/maint level can be pointed to at a
time in the lpar. Does anyone have a slick way of setting up the
OMVS/DB2 environment to allow for rolling maint around to subsystems,
but not cause everyone to have a hard coded dot profile (.profile) with
unique subsystem specific settings?

Thanks for the input!


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

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

John McKown

Re: DB2 z/OS OMVS set up
(in response to Jim Lazowski)
Hum, I had forgotten about that. Did I mention that I'm mainly a
"lurker" because we don't have DB2 here?

If you want multiple maintenance, you're forced to use STEPLIB. Just as
you would in batch, TSO, or CICS. In this case, I would likely put the
"current" SDSNLOD2 in the STEPLIB in /etc/profile. I would then also
have other environment variables set in /etc/profile which define the
name of the "old' SDSNLOD2, the "production" SDSNLOD2, and the "new"
SDSNLOD2. The user could then select exactly which DB2 they wanted by
using the appropriate environment variable.

Perhaps an example would work better. Suppose you have three maintenance
releases of DB2. I'll assume that they are DB2A10, DB2B10, and DB2C10.
These are the "old", "production", and "new" releases. The HFS
directories are: /usr/lpp/db2a10, /usr/lpp/db2b10, and /usr/lpp/db2c10.
The SDSNLOD2 libraries are DSN.DB2A10.SDSNLOD2, DSN.DB2B10.SDNSLOD2, and
DSN.DB2C10.SDSNLOD2.

In /etc/profile:

export db2old=db2a10
export db2prod=db2b10
export db2new=db2c10
# note that the lower case is OK because STEPLIB is case insensitive,
unlike UNIX directory names.
export stepDB2old=DSN.${db2old}.SDSNLOD2
export stepDB2prod=DSN.${db2prod}.SDSNLOD2
export stepDB2new=DSN${db2new}.SDNSLOD2
export dirDB2old=/usr/lpp/${db2old}
export dirDB2prod=/usr/lpp/${db2prod}
export dirDB2new=/usr/lpp/${db2new}
readonly db2old #protect from modification
readonly db2prod #protect from modification
readonly db2new #protect from modification
readonly stepDB2old #protect from modication
readonly stepDB2prod #protect from modification
readonly stepDB2new #protect from modification
readonly dirDB2old
readonly dirDB2prod
readonly dirDB2new
export STEPLIB=${stepDB2prod} #set the default to production STEPLIB

In the user's .profile, they don't need a STEPLIB unless they want to
use either the "old" or "new" DB2. If so, they could have a line like:

export STEPLIB=${stepDB2old}

Well, I hope that I'm making some sense. but I'm really getting out of
my depth, especially in how DB2 is set up (I know 0 about that).

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Lazowski, James S (Jim)
Sent: Tuesday, December 20, 2005 9:21 AM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 z/OS OMVS set up


John,
That sounds good...When you do it this way how do you handle
maint that hits SDSNLOD2? Do you steplib to it in profile or have it in
the linklst? Either way you can only point to one copy making it not
possible to roll maint around the subsystems for this dataset. For
these events do you have to hit all subsystems at the same time?



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