VCAT HLQ question

Roy Reynolds

VCAT HLQ question
I inherited several subsystems that exclusively use VCATs. The applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their DB2
VSAM Linear datasets. The differences between the enviroments are in the DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to use
a simple SMS ACS routine to group each subsystem's datasets onto a specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has a
lot more SMS assignment capability but I don't want to wait until migrating
there.
There are plans here to incorporate other applications that don't use this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Michael Ebert

Re: VCAT HLQ question
(in response to Roy Reynolds)
An application can't even know the HLQ unless they query the Catalog, and
I can't imagine any scenario in which the HLQ would even make a difference
for anything an app might want to do with a database. Ask your manager to
ask the other manager for a valid business case why they should "own" the
HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany




Roy Reynolds <[login to unmask email]>
To
[login to unmask email]
cc

bcc

Subject
[DB2-L] VCAT HLQ question





Roy Reynolds <[login to unmask email]>
Please respond to : IDUG DB2-L <[login to unmask email]>
Sent by: IDUG DB2-L <[login to unmask email]>
11-01-10 17:20


I inherited several subsystems that exclusively use VCATs. The
applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their
DB2
VSAM Linear datasets. The differences between the enviroments are in the
DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the
DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift
pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT
tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to
use
a simple SMS ACS routine to group each subsystem's datasets onto a
specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has
a
lot more SMS assignment capability but I don't want to wait until
migrating
there.
There are plans here to incorporate other applications that don't use
this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation
of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for
the use of the individual or entity shown above as addressees. It may
contain information which is privileged, confidential or otherwise
protected from disclosure under applicable laws. If the reader of this
transmission is not the intended recipient, you are hereby notified that
any dissemination, printing, distribution, copying, disclosure or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify us by reply e-mail or using the address below
and delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Kirk Hampton

Re: VCAT HLQ question
(in response to Michael Ebert)
IMHO,

The application group lost "ownership" of the dataset names when they converted from VSAM to DB2. The datasets can't really be used outside of DB2's control. Except for possibly the issue of DASD space billing, which may key off of the HLQ, there is no reason the applications team needs to be aware of the DB2 dataset names.



One point you can make that is a clear and present danger to you, is that since you are using the *same* HLQ's across multiple DB2 subsystems, it is possible for you to have two subsystems trying to access the exact same dataset name. All it takes is for someone to CREATE in the wrong subsystem with the wrong DBNAME, and you then have a collision at the z/OS level. Safety, then, as well as the separation across DASD to enhance recoverability, should be good reasons for your proposal.



Good Luck,



J Kirk Hampton

Sr. Specialist - Mainframe

HCL Technologies America

Mesquite Data Center

972-216-3119



________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Michael Ebert
Sent: Monday, January 11, 2010 10:41 AM
To: Hampton, Kirk
Subject: Re: VCAT HLQ question




An application can't even know the HLQ unless they query the Catalog, and I can't imagine any scenario in which the HLQ would even make a difference for anything an app might want to do with a database. Ask your manager to ask the other manager for a valid business case why they should "own" the HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany




Roy Reynolds <[login to unmask email]>

To

[login to unmask email]

cc



bcc



Subject

[DB2-L] VCAT HLQ question









Roy Reynolds <[login to unmask email]>

Please respond to : IDUG DB2-L <[login to unmask email]>

Sent by: IDUG DB2-L <[login to unmask email]>
11-01-10 17:20




I inherited several subsystems that exclusively use VCATs. The applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their DB2
VSAM Linear datasets. The differences between the enviroments are in the DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to use
a simple SMS ACS routine to group each subsystem's datasets onto a specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has a
lot more SMS assignment capability but I don't want to wait until migrating
there.
There are plans here to incorporate other applications that don't use this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees. It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws. If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany

________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >


Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be
advised that any reading, dissemination, forwarding, printing, copying
or other use of this message or its attachments is strictly prohibited. If
you have received this message in error, please notify the sender
immediately by reply message and delete this email message and any
attachments from your system.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Max Scarpa

Re: VCAT HLQ question
(in response to Kirk Hampton)
I knew some dept. used first qualifier for some accounting (for instance
SAL1 for salary app or ORD1 for orders etc in SAS programs) so if someone
say HLQ or first 'n' qualifiers belong to an 'application' it

could be possible they're used for space accounting or something similar.
I agree qualifiers in your post aren't so 'smart' but in a previous
company I saw this kind of accounting (using MICS and

considering first qualifier(s)).

Just an idea.

Max Scarpa
DB2 V-Visitors edition sysprog



Massimo Scarpa - Ufficio Sistemi
Cesve Servizi Informatici Bancari
v. Longhin, 1 - 35129 Padova
Tel. 049.8067111 - Fax. 049.8067300
E-Mail: [login to unmask email] - Web: http://www.cesve.it



Il presente messaggio non ha natura personale e le eventuali risposte allo
stesso potranno essere conosciute nell’ambito dell'organizzazione di
appartenenza del mittente. Esso , corredato degli eventuali relativi
allegati , contiene informazioni da considerarsi strettamente riservate ai
sensi della vigente normativa in materia di protezione di dati personali
ed è destinato esclusivamente al destinatario(i) sopra indicato. Chiunque
ricevesse questo messaggio per errore o comunque lo leggesse senza esserne
legittimato è avvertito che trattenerlo, copiarlo, divulgarlo,
distribuirlo a persone diverse dal destinatario è severamente proibito, ed
è pregato di rinviarlo immediatamente al mittente distruggendone
l’originale.

Carol Anne Sutfin

Re: VCAT HLQ question
(in response to Max Scarpa)
I agree with Kirk on this.

We have the HLQ out of the application owner control.

Granted, we do not currently have a charge back system for DASD usage, we
do keep track of usage by dataset name.
99% of the DB2 data uses a single HLQ and System Support is responsible for
backup of the ICF catalogs for this along with the DB2 catalog backups.

I have a hard enough time getting some application owners to back up their
databases, much less remembering that a User Catalog is out there also.

Also that 99% of the data is controlled by SMS routines. The only non-SMS
DB2 is the DB2 catalog.
Just call me old fashioned there. I still like being able to allocate
those myself.

Carol Sutfin
Corporate DBA
Regions Financial Corp.
(205)261-5214
[login to unmask email]



From: Kirk Hampton <[login to unmask email]>

To: [login to unmask email]

Date: 01/11/2010 12:18 PM

Subject: Re: [DB2-L] VCAT HLQ question

Sent by: IDUG DB2-L <[login to unmask email]>






IMHO,
The application group lost “ownership” of the dataset names when they
converted from VSAM to DB2. The datasets can’t really be used outside of
DB2’s control. Except for possibly the issue of DASD space billing, which
may key off of the HLQ, there is no reason the applications team needs to
be aware of the DB2 dataset names.

One point you can make that is a clear and present danger to you, is that
since you are using the *same* HLQ’s across multiple DB2 subsystems,  it is
possible for you to have two subsystems trying to access the exact same
dataset name. All it takes is for someone to CREATE in the wrong subsystem
with the wrong DBNAME, and you then have a collision at the z/OS level.
Safety, then, as well as the separation across DASD to enhance
recoverability, should be good reasons for your proposal.

Good Luck,

J Kirk Hampton
Sr. Specialist - Mainframe
HCL Technologies America
Mesquite Data Center
972-216-3119


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Michael Ebert
Sent: Monday, January 11, 2010 10:41 AM
To: Hampton, Kirk
Subject: Re: VCAT HLQ question


An application can't even know the HLQ unless they query the Catalog, and I
can't imagine any scenario in which the HLQ would even make a difference
for anything an app might want to do with a database. Ask your manager to
ask the other manager for a valid business case why they should "own" the
HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany





Roy Reynolds Roy Reynolds <[login to unmask email]>
<[login to unmask email]>

Please respond to : IDUG DB2-L
<[login to unmask email]>


To Sent by: IDUG DB2-L <[login to unmask email]>
[login to unmask email]
.ORG 11-01-10 17:20
cc

bcc

Subject
[DB2-L] VCAT HLQ
question















I inherited several subsystems that exclusively use VCATs. The
applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their
DB2
VSAM Linear datasets. The differences between the enviroments are in the
DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the
DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to
use
a simple SMS ACS routine to group each subsystem's datasets onto a specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has
a
lot more SMS assignment capability but I don't want to wait until migrating
there.
There are plans here to incorporate other applications that don't use this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation
of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for
the use of the individual or entity shown above as addressees. It may
contain information which is privileged, confidential or otherwise
protected from disclosure under applicable laws. If the reader of this
transmission is not the intended recipient, you are hereby notified that
any dissemination, printing, distribution, copying, disclosure or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify us by reply e-mail or using the address below and
delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany






The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.


Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be advised
that any reading, dissemination, forwarding, printing, copying or other use
of this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
reply message and delete this email message and any attachments from your
system.









The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.

Philip Sevetson

Re: VCAT HLQ question
(in response to Carol Anne Sutfin)
Carol,
If those databases aren't backed up, who catches the flak from management? DBA, or the application? If it's you, then you need to own the backups.

I've never heard of a line of business being responsible for backups. It's usually the case that the backups are integrated into the application business batch flows, but owned by DBA. There's also (usually) a corporate recoverability SLA that the database will be recoverable to within 24 hours of time-of-failure. Sometimes it's even "image copy with recoverysite versions every 24 hours."

--Phil

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of [login to unmask email]
Sent: Monday, January 11, 2010 2:04 PM
To: [login to unmask email]
Subject: Re: [DB2-L] VCAT HLQ question

I agree with Kirk on this.

We have the HLQ out of the application owner control.

Granted, we do not currently have a charge back system for DASD usage, we
do keep track of usage by dataset name.
99% of the DB2 data uses a single HLQ and System Support is responsible for
backup of the ICF catalogs for this along with the DB2 catalog backups.

I have a hard enough time getting some application owners to back up their
databases, much less remembering that a User Catalog is out there also.

Also that 99% of the data is controlled by SMS routines. The only non-SMS
DB2 is the DB2 catalog.
Just call me old fashioned there. I still like being able to allocate
those myself.

Carol Sutfin
Corporate DBA
Regions Financial Corp.
(205)261-5214
[login to unmask email]



From: Kirk Hampton <[login to unmask email]>

To: [login to unmask email]

Date: 01/11/2010 12:18 PM

Subject: Re: [DB2-L] VCAT HLQ question

Sent by: IDUG DB2-L <[login to unmask email]>






IMHO,
The application group lost "ownership" of the dataset names when they
converted from VSAM to DB2. The datasets can't really be used outside of
DB2's control. Except for possibly the issue of DASD space billing, which
may key off of the HLQ, there is no reason the applications team needs to
be aware of the DB2 dataset names.

One point you can make that is a clear and present danger to you, is that
since you are using the *same* HLQ's across multiple DB2 subsystems,  it is
possible for you to have two subsystems trying to access the exact same
dataset name. All it takes is for someone to CREATE in the wrong subsystem
with the wrong DBNAME, and you then have a collision at the z/OS level.
Safety, then, as well as the separation across DASD to enhance
recoverability, should be good reasons for your proposal.

Good Luck,

J Kirk Hampton
Sr. Specialist - Mainframe
HCL Technologies America
Mesquite Data Center
972-216-3119


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Michael Ebert
Sent: Monday, January 11, 2010 10:41 AM
To: Hampton, Kirk
Subject: Re: VCAT HLQ question


An application can't even know the HLQ unless they query the Catalog, and I
can't imagine any scenario in which the HLQ would even make a difference
for anything an app might want to do with a database. Ask your manager to
ask the other manager for a valid business case why they should "own" the
HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany





Roy Reynolds Roy Reynolds <[login to unmask email]>
<[login to unmask email]>

Please respond to : IDUG DB2-L
<[login to unmask email]>


To Sent by: IDUG DB2-L <[login to unmask email]>
[login to unmask email]
.ORG 11-01-10 17:20
cc

bcc

Subject
[DB2-L] VCAT HLQ
question















I inherited several subsystems that exclusively use VCATs. The
applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their
DB2
VSAM Linear datasets. The differences between the enviroments are in the
DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the
DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to
use
a simple SMS ACS routine to group each subsystem's datasets onto a specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has
a
lot more SMS assignment capability but I don't want to wait until migrating
there.
There are plans here to incorporate other applications that don't use this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation
of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for
the use of the individual or entity shown above as addressees. It may
contain information which is privileged, confidential or otherwise
protected from disclosure under applicable laws. If the reader of this
transmission is not the intended recipient, you are hereby notified that
any dissemination, printing, distribution, copying, disclosure or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify us by reply e-mail or using the address below and
delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany






The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.


Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be advised
that any reading, dissemination, forwarding, printing, copying or other use
of this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
reply message and delete this email message and any attachments from your
system.









The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are
not already an IDUG member, please register here.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Ted MacNEIL

Re: VCAT HLQ question
(in response to Philip Sevetson)
>Also that 99% of the data is controlled by SMS routines.
>The only non-SMS DB2 is the DB2 catalog.
>Just call me old fashioned there.
>I still like being able to allocate
those myself.

With SMS-control, you still can.
Ask your storage admins about "guaranteed space".
-
Too busy driving to stop for gas!

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Ted MacNEIL

Re: VCAT HLQ question
(in response to Ted MacNEIL)
>I've never heard of a line of business being responsible for backups.

Pre-SMS, a lot of shops didn't have centralised storage administration, so lots of applications did backups of their own data with inconsistent standards.
Some shops still work that way, even after implementing SMS.

-
Too busy driving to stop for gas!

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Carol Anne Sutfin

Re: VCAT HLQ question
(in response to Ted MacNEIL)
Phil,

It gets interesting Applications here are responsible for the Image
Copy/Backup of their databases because we have multiple applications
within a single DB2 subsystem.

Yes, I am the "B***H" that pokes them to make sure that they can recover
their databases.
I have been known to to my own copy of DB's with my own HLQ as a CYA until
they get their processes in place and working.

I have also been known to inform internal Auditors of Applications that do
not have backup processing in place.

Politics can be fun at times.

Carol Sutfin
Corporate DBA
Regions Financial Corp.
(205)261-5214
[login to unmask email]



From:
"Sevetson, Phil" <[login to unmask email]>
To:
[login to unmask email]
Date:
01/11/2010 02:21 PM
Subject:
Re: [DB2-L] VCAT HLQ question
Sent by:
IDUG DB2-L <[login to unmask email]>



Carol,
If those databases aren't backed up, who catches the flak from management?
DBA, or the application? If it's you, then you need to own the backups.

I've never heard of a line of business being responsible for backups. It's
usually the case that the backups are integrated into the application
business batch flows, but owned by DBA. There's also (usually) a
corporate recoverability SLA that the database will be recoverable to
within 24 hours of time-of-failure. Sometimes it's even "image copy with
recoverysite versions every 24 hours."

--Phil

-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of
[login to unmask email]
Sent: Monday, January 11, 2010 2:04 PM
To: [login to unmask email]
Subject: Re: [DB2-L] VCAT HLQ question

I agree with Kirk on this.

We have the HLQ out of the application owner control.

Granted, we do not currently have a charge back system for DASD usage, we
do keep track of usage by dataset name.
99% of the DB2 data uses a single HLQ and System Support is responsible
for
backup of the ICF catalogs for this along with the DB2 catalog backups.

I have a hard enough time getting some application owners to back up their
databases, much less remembering that a User Catalog is out there also.

Also that 99% of the data is controlled by SMS routines. The only non-SMS
DB2 is the DB2 catalog.
Just call me old fashioned there. I still like being able to allocate
those myself.

Carol Sutfin
Corporate DBA
Regions Financial Corp.
(205)261-5214
[login to unmask email]



From: Kirk Hampton <[login to unmask email]>


To: [login to unmask email]

Date: 01/11/2010 12:18 PM

Subject: Re: [DB2-L] VCAT HLQ question

Sent by: IDUG DB2-L <[login to unmask email]>






IMHO,
The application group lost "ownership" of the dataset names when they
converted from VSAM to DB2. The datasets can't really be used outside of
DB2's control. Except for possibly the issue of DASD space billing, which
may key off of the HLQ, there is no reason the applications team needs to
be aware of the DB2 dataset names.

One point you can make that is a clear and present danger to you, is that
since you are using the *same* HLQ's across multiple DB2 subsystems, it
is
possible for you to have two subsystems trying to access the exact same
dataset name. All it takes is for someone to CREATE in the wrong subsystem
with the wrong DBNAME, and you then have a collision at the z/OS level.
Safety, then, as well as the separation across DASD to enhance
recoverability, should be good reasons for your proposal.

Good Luck,

J Kirk Hampton
Sr. Specialist - Mainframe
HCL Technologies America
Mesquite Data Center
972-216-3119


From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Michael Ebert
Sent: Monday, January 11, 2010 10:41 AM
To: Hampton, Kirk
Subject: Re: VCAT HLQ question


An application can't even know the HLQ unless they query the Catalog, and
I
can't imagine any scenario in which the HLQ would even make a difference
for anything an app might want to do with a database. Ask your manager to
ask the other manager for a valid business case why they should "own" the
HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany





Roy Reynolds Roy Reynolds <[login to unmask email]>
<[login to unmask email]>

Please respond to : IDUG DB2-L
<[login to unmask email]>


To Sent by: IDUG DB2-L <[login to unmask email]>
[login to unmask email]
.ORG 11-01-10 17:20
cc

bcc

Subject
[DB2-L] VCAT HLQ
question















I inherited several subsystems that exclusively use VCATs. The
applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their
DB2
VSAM Linear datasets. The differences between the enviroments are in the
DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the
DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift
pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT
tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to
use
a simple SMS ACS routine to group each subsystem's datasets onto a
specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has
a
lot more SMS assignment capability but I don't want to wait until
migrating
there.
There are plans here to incorporate other applications that don't use
this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation
of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for
the use of the individual or entity shown above as addressees. It may
contain information which is privileged, confidential or otherwise
protected from disclosure under applicable laws. If the reader of this
transmission is not the intended recipient, you are hereby notified that
any dissemination, printing, distribution, copying, disclosure or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify us by reply e-mail or using the address below
and
delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany






The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
are
not already an IDUG member, please register here.


Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be
advised
that any reading, dissemination, forwarding, printing, copying or other
use
of this message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender immediately by
reply message and delete this email message and any attachments from your
system.









The IDUG DB2-L Listserv is only part of your membership in IDUG. If you
are
not already an IDUG member, please register here.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation
of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L


_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Carol Broyles

Re: VCAT HLQ question
(in response to Carol Anne Sutfin)
This is an excellent argument for not using the same HLQ across DB2 systems. We RACF protect the HLQ so a different DB2 system can't open them. We use the group attach name, and it's working well across more than 80 systems.





Carol L. Broyles

Infrastructure Mgt. Consultant

Commercial Solutions

Office Phone: 937-495-4003

[login to unmask email]



Affiliated Computer Services Inc.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,

is for the sole use of the intended recipient(s) and may contain confidential and

privileged information. Any unauthorized review, use, disclosure, or distribution is

prohibited. If you are not the intended recipient, please contact the sender by reply

e-mail and destroy all copies of the original message.



________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Kirk Hampton
Sent: Monday, January 11, 2010 12:49 PM
To: [login to unmask email]
Subject: Re: [DB2-L] VCAT HLQ question



IMHO,

The application group lost "ownership" of the dataset names when they converted from VSAM to DB2. The datasets can't really be used outside of DB2's control. Except for possibly the issue of DASD space billing, which may key off of the HLQ, there is no reason the applications team needs to be aware of the DB2 dataset names.



One point you can make that is a clear and present danger to you, is that since you are using the *same* HLQ's across multiple DB2 subsystems, it is possible for you to have two subsystems trying to access the exact same dataset name. All it takes is for someone to CREATE in the wrong subsystem with the wrong DBNAME, and you then have a collision at the z/OS level. Safety, then, as well as the separation across DASD to enhance recoverability, should be good reasons for your proposal.



Good Luck,



J Kirk Hampton

Sr. Specialist - Mainframe

HCL Technologies America

Mesquite Data Center

972-216-3119



________________________________

From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Michael Ebert
Sent: Monday, January 11, 2010 10:41 AM
To: Hampton, Kirk
Subject: Re: VCAT HLQ question




An application can't even know the HLQ unless they query the Catalog, and I can't imagine any scenario in which the HLQ would even make a difference for anything an app might want to do with a database. Ask your manager to ask the other manager for a valid business case why they should "own" the HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany



Roy Reynolds <[login to unmask email]>

To

[login to unmask email]

cc



bcc



Subject

[DB2-L] VCAT HLQ question









Roy Reynolds <[login to unmask email]>

Please respond to : IDUG DB2-L <[login to unmask email]>

Sent by: IDUG DB2-L <[login to unmask email]>
11-01-10 17:20




I inherited several subsystems that exclusively use VCATs. The applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their DB2
VSAM Linear datasets. The differences between the enviroments are in the DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to use
a simple SMS ACS routine to group each subsystem's datasets onto a specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has a
lot more SMS assignment capability but I don't want to wait until migrating
there.
There are plans here to incorporate other applications that don't use this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees. It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws. If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany

________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >

Confidentiality Notice: This email message, including any attachments, contains or may contain confidential information intended only for the addressee. If you are not an intended recipient of this message, be advised that any reading, dissemination, forwarding, printing, copying or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply message and delete this email message and any attachments from your system.


________________________________

IDUG - The Worldwide DB2 User Community! < http://www.idug.org/db2-north-america-conference/index.html >

The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here. < http://www.idug.org/register >


_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Jim Tonchick

Re: VCAT HLQ question
(in response to Carol Broyles)

You might want to check to see how the applications are charged for their dasd usage. I'd bet that they are billed by highlevel. This goes beyond the concept of "ownership" and adds a level of complexity to any proposed change since you'll have to get by in from management to change the IT chargeback algorithms.

OK, that being said, get the backing of management and get those highlevels changed. Time does not stand still and applications change all the time. So it's about time to change this hold over from pre-Y2K days, especially if you want to take advantage of the BACKUP SYSTEM utilities for disaster recovery.

Jim Tonchick




-----Original Message-----
From: Michael Ebert <[login to unmask email]>
To: [login to unmask email]
Sent: Mon, Jan 11, 2010 10:40 am
Subject: Re: [DB2-L] VCAT HLQ question



An application can't even know the HLQ unless they query the Catalog, and I can't imagine any scenario in which the HLQ would even make a difference for anything an app might want to do with a database. Ask your manager to ask the other manager for a valid business case why they should "own" the HLQ.

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany





Roy Reynolds <[login to unmask email]>


To

[login to unmask email]


cc



bcc



Subject

[DB2-L] VCAT HLQ question










Roy Reynolds <[login to unmask email]>
Please respond to : IDUG DB2-L <[login to unmask email]>
Sent by: IDUG DB2-L <[login to unmask email]>
11-01-10 17:20





I inherited several subsystems that exclusively use VCATs. The applications
were old VSAM apps back in the late 80s. When they were moved to DB2 the
application group person acting as DBA insisted that all the HLQs remain
unchanged. So the Dev environment still has HLQs like PR1, PR2, PR3, PR4,
etc. Likewise, the QA and Prod environments use the same HLQs for their DB2
VSAM Linear datasets. The differences between the enviroments are in the DB
name level. They use DB names like PR1XYZD for Dev, PR1XYZQ for QA, and
PR1XYZA or PR1XYZB or PR1XYZC for Prod. The leftmost three characters
always match the HLQ. I've proposed changing the HLQs to use the DataSharing
group name such as DB2D, DB2Q, or DB2P. I was amazed to get swift pushback
from an application group leader who insisted these dataset names were the
property of applications and 'current' DBA group had no right to suggest
such a change.
We are still on z/OS DB2 V8. I've been converting all the VCAT tablespaces
to STOGROUPs but keeping the existing HLQs. My direction/intention is to use
a simple SMS ACS routine to group each subsystem's datasets onto a specific
group of volumes so they could be backed up and recovered without being
intermixed with other subsystem's datasets as they are now. I know V9 has a
lot more SMS assignment capability but I don't want to wait until migrating
there.
There are plans here to incorporate other applications that don't use this
'old' naming pattern. The variety of HLQs will be confusing.
Does anyone have a really simple, really sensible document that can be
recommended as a 'best practices' outline for assigning STOGROUP HLQs?
In other shops, I've used SYSDEFLT exclusively as the STOGROUP where its
VCAT name was the subsystem name or the Group name. That has been very
satisfactory for me in the past. Can someone weigh in on this discussion
please.
Thanks in advance.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L





IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees. It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws. If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system.

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany


The IDUG DB2-L Listserv is only part of your membership in IDUG. If you are not already an IDUG member, please register here.

=

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-videos.html has hundreds of video presentations!
Did you miss out on attending an IDUG conference?
Many of the presentations were recorded and are available on our website!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Max Scarpa

Re: VCAT HLQ question
(in response to Jim Tonchick)
In the last company I worked backups were executed by application people,
not by DBAs. So you had a lot of useless backups because everyone was
scared to lose data even if tables were not updated daily or weekly......


Massimo Scarpa - Ufficio Sistemi
Cesve Servizi Informatici Bancari
v. Longhin, 1 - 35129 Padova
Tel. 049.8067111 - Fax. 049.8067300
E-Mail: [login to unmask email] - Web: http://www.cesve.it



Il presente messaggio non ha natura personale e le eventuali risposte allo
stesso potranno essere conosciute nell’ambito dell'organizzazione di
appartenenza del mittente. Esso , corredato degli eventuali relativi
allegati , contiene informazioni da considerarsi strettamente riservate ai
sensi della vigente normativa in materia di protezione di dati personali
ed è destinato esclusivamente al destinatario(i) sopra indicato. Chiunque
ricevesse questo messaggio per errore o comunque lo leggesse senza esserne
legittimato è avvertito che trattenerlo, copiarlo, divulgarlo,
distribuirlo a persone diverse dal destinatario è severamente proibito, ed
è pregato di rinviarlo immediatamente al mittente distruggendone
l’originale.



Ted MacNEIL <[login to unmask email]>
Sent by: IDUG DB2-L <[login to unmask email]>
11/01/2010 21.21
Please respond to
IDUG DB2-L <[login to unmask email]>


To
[login to unmask email]
cc

Subject
Re: [DB2-L] VCAT HLQ question






>I've never heard of a line of business being responsible for backups.

Pre-SMS, a lot of shops didn't have centralised storage administration, so
lots of applications did backups of their own data with inconsistent
standards.
Some shops still work that way, even after implementing SMS.

-
Too busy driving to stop for gas!

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.IDUG.org membership is now free.
Do you have people in your office who are not an IDUG member?
Show them how to access the information and help train the next generation
of DB2 Users!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L