Encryption

Smike Toppins

Encryption
I'm wondering what options other admins are using for DB2 data
encryption. The concern that an image copy tape may get "lost" from our
disaster recovery storage facility.

SMike Toppins
Great-West Life
8525 E. Orchard Road
Englewood, CO 80111
[login to unmask email]
----Statement of Confidentiality----
This e-mail, and any attachments thereto, is intended for the exclusive
use of the addressee(s) named herein and may contain information that is
privileged or confidential or otherwise legally exempt from disclosure.
If you are not a named addressee or an employee or agent responsible for
delivering this message to a named addressee, you are not authorized to
read, print, retain, copy or disseminate this message or any part of it.
If you have received this e-mail in error, please notify me immediately
by e-mail or telephone, discard any paper copies and delete all
electronic files of this e-mail.

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

Cathy Taddei

Re: Encryption
(in response to Smike Toppins)
Hi SMike. That issue has been debated here, but so far we have not made
any changes to our processes, meaning that if we lost a tape today, we
would have to determine whether any of our California customer or
employee data was on that tape, and if so, report the loss to them.
Those were the requirements for a non-financial services company last
time I checked, but legislation may have since been passed to widen our
responsibilities. We have discussed using FDR to encrypt our backups,
but at the time, I believe FDR was unable to encrypt DB2 image copies --
they may have addressed that by now. Some of our DBA's have tried to
argue that compressed tablespaces are already encrypted, and I'm curious
whether anyone else here has made that argument, and whether it has held
up. Similarly, our MVS guys argue that FDR dumps can be considered
encrypted. I don't buy that because no key is required to unlock it,
just commercially available software and a mainframe to run it on.

Personally, I am loathe to encrypt our backups, because if I am in a
position to need my backups, I would not want the additional risk and
complexity encryption adds. But each company has to weigh the risk of
something going wrong with encrypted backups against the harm from bad
publicity should a tape be lost. My favorite solution would be to
encrypt sensitive data within DB2, but that could have a high
performance impact depending on how the data is being used.

Regards,
Cathy Taddei

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Toppins, Smike
Sent: Tuesday, January 03, 2006 8:58 AM
To: [login to unmask email]
Subject: [DB2-L] Encryption

I'm wondering what options other admins are using for DB2 data
encryption. The concern that an image copy tape may get "lost" from our
disaster recovery storage facility.

SMike Toppins
Great-West Life
8525 E. Orchard Road
Englewood, CO 80111
[login to unmask email]

------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

======

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

Myron Miller

Re: Encryption
(in response to Cathy Taddei)
Cathy,
I seriously doubt any reasonably competent auditor if they required data to
be encrypted would accept compression as an acceptable substitute. It's still
readable directly for the most part and easily decoded by any competent techie
without any external keys.

From what I've been reading about DB2 V8 encryption and the hardware assists,
it doesn't seem to be that much of a performance penalty, provided (and here's
a major assumption) the programmers access the encrypted data correctly. The
actual process of encryption/decryption isn't that expensive. It only depends
on how much and when it's done. But bear in mind, this is just an assumption
that I've made from reading what Roger and others have written.

Certainly, if you have data that is critical to be protected, then encryption
is the only valid answer. SSNs, names, bank account numbers, etc. are some of
those that I can think of that should be encrypted everywhere.

Myron

--- "Taddei, Cathy" <[login to unmask email]> wrote:

> Hi SMike. That issue has been debated here, but so far we have not made
> any changes to our processes, meaning that if we lost a tape today, we
> would have to determine whether any of our California customer or
> employee data was on that tape, and if so, report the loss to them.
> Those were the requirements for a non-financial services company last
> time I checked, but legislation may have since been passed to widen our
> responsibilities. We have discussed using FDR to encrypt our backups,
> but at the time, I believe FDR was unable to encrypt DB2 image copies --
> they may have addressed that by now. Some of our DBA's have tried to
> argue that compressed tablespaces are already encrypted, and I'm curious
> whether anyone else here has made that argument, and whether it has held
> up. Similarly, our MVS guys argue that FDR dumps can be considered
> encrypted. I don't buy that because no key is required to unlock it,
> just commercially available software and a mainframe to run it on.
>
> Personally, I am loathe to encrypt our backups, because if I am in a
> position to need my backups, I would not want the additional risk and
> complexity encryption adds. But each company has to weigh the risk of
> something going wrong with encrypted backups against the harm from bad
> publicity should a tape be lost. My favorite solution would be to
> encrypt sensitive data within DB2, but that could have a high
> performance impact depending on how the data is being used.
>
> Regards,
> Cathy Taddei
>
> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
> Behalf Of Toppins, Smike
> Sent: Tuesday, January 03, 2006 8:58 AM
> To: [login to unmask email]
> Subject: [DB2-L] Encryption
>
> I'm wondering what options other admins are using for DB2 data
> encryption. The concern that an image copy tape may get "lost" from our
> disaster recovery storage facility.
>
> SMike Toppins
> Great-West Life
> 8525 E. Orchard Road
> Englewood, CO 80111
> [login to unmask email]
>
>
------------------------------------------------------------------------------
>
> This email is confidential and may be legally privileged.
>
> It is intended solely for the addressee. Access to this email by anyone else,
> unless expressly approved by the sender or an authorized addressee, is
> unauthorized.
>
> If you are not the intended recipient, any disclosure, copying, distribution
> or any action omitted or taken in reliance on it, is prohibited and may be
> unlawful. If you believe that you have received this email in error, please
> contact the sender, delete this e-mail and destroy all copies.
>
>
=====
>
>
---------------------------------------------------------------------------------
> 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

Cathy Taddei

Re: Encryption
(in response to Myron Miller)
Hi Myron. So far as backup tapes are concerned, it's not auditors we're
concerned with, it's legislators. I believe that the current hype
surrounding backup tape encryption is our nations 500th most important
problem, so naturally that's what our legislators are addressing. I
believe that virtually all identity theft is carried out by other means
besides stealing backup tapes from courier services. That said, I want
to protect my employer with as little pain and expense as possible.
What are other shops doing?

Regards,
Cathy

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Myron Miller
Sent: Tuesday, January 03, 2006 12:32 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Encryption

Cathy,
I seriously doubt any reasonably competent auditor if they required
data to
be encrypted would accept compression as an acceptable substitute. It's
still
readable directly for the most part and easily decoded by any competent
techie
without any external keys.

From what I've been reading about DB2 V8 encryption and the hardware
assists,
it doesn't seem to be that much of a performance penalty, provided (and
here's
a major assumption) the programmers access the encrypted data correctly.
The
actual process of encryption/decryption isn't that expensive. It only
depends
on how much and when it's done. But bear in mind, this is just an
assumption
that I've made from reading what Roger and others have written.

Certainly, if you have data that is critical to be protected, then
encryption
is the only valid answer. SSNs, names, bank account numbers, etc. are
some of
those that I can think of that should be encrypted everywhere.

Myron

--- "Taddei, Cathy" <[login to unmask email]> wrote:

> Hi SMike. That issue has been debated here, but so far we have not
made
> any changes to our processes, meaning that if we lost a tape today, we
> would have to determine whether any of our California customer or
> employee data was on that tape, and if so, report the loss to them.
> Those were the requirements for a non-financial services company last
> time I checked, but legislation may have since been passed to widen
our
> responsibilities. We have discussed using FDR to encrypt our backups,
> but at the time, I believe FDR was unable to encrypt DB2 image copies
--
> they may have addressed that by now. Some of our DBA's have tried to
> argue that compressed tablespaces are already encrypted, and I'm
curious
> whether anyone else here has made that argument, and whether it has
held
> up. Similarly, our MVS guys argue that FDR dumps can be considered
> encrypted. I don't buy that because no key is required to unlock it,
> just commercially available software and a mainframe to run it on.
>
> Personally, I am loathe to encrypt our backups, because if I am in a
> position to need my backups, I would not want the additional risk and
> complexity encryption adds. But each company has to weigh the risk of
> something going wrong with encrypted backups against the harm from bad
> publicity should a tape be lost. My favorite solution would be to
> encrypt sensitive data within DB2, but that could have a high
> performance impact depending on how the data is being used.
>
> Regards,
> Cathy Taddei
>
<snip>

------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.

======

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

Travis Bindenagel

Re: Encryption
(in response to Cathy Taddei)
I believe Marriott Vacation Club members would argue that backup tape
security is very important. We are currently in the process of
eliminating backup tapes and piping everything to a secure SAN where the
backups are then encrypted, even though they remain on our LAN.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Taddei, Cathy
Sent: Tuesday, January 03, 2006 3:56 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Encryption

Hi Myron. So far as backup tapes are concerned, it's not auditors we're
concerned with, it's legislators. I believe that the current hype
surrounding backup tape encryption is our nations 500th most important
problem, so naturally that's what our legislators are addressing. I
believe that virtually all identity theft is carried out by other means
besides stealing backup tapes from courier services. That said, I want
to protect my employer with as little pain and expense as possible.
What are other shops doing?

Regards,
Cathy

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Myron Miller
Sent: Tuesday, January 03, 2006 12:32 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Encryption

Cathy,
I seriously doubt any reasonably competent auditor if they required
data to be encrypted would accept compression as an acceptable
substitute. It's still readable directly for the most part and easily
decoded by any competent techie without any external keys.

From what I've been reading about DB2 V8 encryption and the hardware
assists, it doesn't seem to be that much of a performance penalty,
provided (and here's a major assumption) the programmers access the
encrypted data correctly.
The
actual process of encryption/decryption isn't that expensive. It only
depends on how much and when it's done. But bear in mind, this is just
an assumption that I've made from reading what Roger and others have
written.

Certainly, if you have data that is critical to be protected, then
encryption is the only valid answer. SSNs, names, bank account numbers,
etc. are some of those that I can think of that should be encrypted
everywhere.

Myron

--- "Taddei, Cathy" <[login to unmask email]> wrote:

> Hi SMike. That issue has been debated here, but so far we have not
made
> any changes to our processes, meaning that if we lost a tape today, we

> would have to determine whether any of our California customer or
> employee data was on that tape, and if so, report the loss to them.
> Those were the requirements for a non-financial services company last
> time I checked, but legislation may have since been passed to widen
our
> responsibilities. We have discussed using FDR to encrypt our backups,

> but at the time, I believe FDR was unable to encrypt DB2 image copies
--
> they may have addressed that by now. Some of our DBA's have tried to
> argue that compressed tablespaces are already encrypted, and I'm
curious
> whether anyone else here has made that argument, and whether it has
held
> up. Similarly, our MVS guys argue that FDR dumps can be considered
> encrypted. I don't buy that because no key is required to unlock it,
> just commercially available software and a mainframe to run it on.
>
> Personally, I am loathe to encrypt our backups, because if I am in a
> position to need my backups, I would not want the additional risk and
> complexity encryption adds. But each company has to weigh the risk of

> something going wrong with encrypted backups against the harm from bad

> publicity should a tape be lost. My favorite solution would be to
> encrypt sensitive data within DB2, but that could have a high
> performance impact depending on how the data is being used.
>
> Regards,
> Cathy Taddei
>
<snip>

------------------------------------------------------------------------
------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone
else, unless expressly approved by the sender or an authorized
addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying,
distribution or any action omitted or taken in reliance on it, is
prohibited and may be unlawful. If you believe that you have received
this email in error, please contact the sender, delete this e-mail and
destroy all copies.


======

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

Myron Miller

Re: Encryption
(in response to Travis Bindenagel)
Cathy,
I'll agree with you that identity theft from backup tapes isn't that major.
But the loss of backup tapes and the associated data from them from couriers
and other supposed secure transport mechanisms has happen to several major
companies in the last 6 months to a year. And the issues and concerns of the
customers of those companies is very real. As someone else mentioned, the
Marriot Vacation Club members were not happy about the potential exposure. And
there were literally hundreds of thousands of people exposed to these issues.
I personally had exposure due to Bank of America and Citigroup. That's extra
time and expense for me personally having to check and verify things.

So forcing some companies to pay attention to how they protect their data might
not necessarily be the legitimate highest priority for legislators, but it's
certainly received the attention of a number of people. And remember that
legislators respond to their constituent concerns. Get enough people
nationwide complaining about something and something will happen, not
necessarily the best solution or correct solution but a solution.

And actually in this country we're pretty lucky. When you consider all the
extravagant privacy laws in Europe and having to deal with them, having to deal
with some of these issues in the US is pretty simple comparatively. Try moving
customer data from England to Germany or France to italy, etc and see what's
involved there.

My client will be encrypting on DB2 the critical information and leaving it
encrypted everywhere, including backup tapes except for when it's actually
being used. That way we don't have to worry about encrypting the entire backup
tape.

Myron



--- "Taddei, Cathy" <[login to unmask email]> wrote:

> Hi Myron. So far as backup tapes are concerned, it's not auditors we're
> concerned with, it's legislators. I believe that the current hype
> surrounding backup tape encryption is our nations 500th most important
> problem, so naturally that's what our legislators are addressing. I
> believe that virtually all identity theft is carried out by other means
> besides stealing backup tapes from courier services. That said, I want
> to protect my employer with as little pain and expense as possible.
> What are other shops doing?
>
> Regards,
> Cathy
>
> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
> Behalf Of Myron Miller
> Sent: Tuesday, January 03, 2006 12:32 PM
> To: [login to unmask email]
> Subject: Re: [DB2-L] Encryption
>
> Cathy,
> I seriously doubt any reasonably competent auditor if they required
> data to
> be encrypted would accept compression as an acceptable substitute. It's
> still
> readable directly for the most part and easily decoded by any competent
> techie
> without any external keys.
>
> From what I've been reading about DB2 V8 encryption and the hardware
> assists,
> it doesn't seem to be that much of a performance penalty, provided (and
> here's
> a major assumption) the programmers access the encrypted data correctly.
> The
> actual process of encryption/decryption isn't that expensive. It only
> depends
> on how much and when it's done. But bear in mind, this is just an
> assumption
> that I've made from reading what Roger and others have written.
>
> Certainly, if you have data that is critical to be protected, then
> encryption
> is the only valid answer. SSNs, names, bank account numbers, etc. are
> some of
> those that I can think of that should be encrypted everywhere.
>
> Myron
>
> --- "Taddei, Cathy" <[login to unmask email]> wrote:
>
> > Hi SMike. That issue has been debated here, but so far we have not
> made
> > any changes to our processes, meaning that if we lost a tape today, we
> > would have to determine whether any of our California customer or
> > employee data was on that tape, and if so, report the loss to them.
> > Those were the requirements for a non-financial services company last
> > time I checked, but legislation may have since been passed to widen
> our
> > responsibilities. We have discussed using FDR to encrypt our backups,
> > but at the time, I believe FDR was unable to encrypt DB2 image copies
> --
> > they may have addressed that by now. Some of our DBA's have tried to
> > argue that compressed tablespaces are already encrypted, and I'm
> curious
> > whether anyone else here has made that argument, and whether it has
> held
> > up. Similarly, our MVS guys argue that FDR dumps can be considered
> > encrypted. I don't buy that because no key is required to unlock it,
> > just commercially available software and a mainframe to run it on.
> >
> > Personally, I am loathe to encrypt our backups, because if I am in a
> > position to need my backups, I would not want the additional risk and
> > complexity encryption adds. But each company has to weigh the risk of
> > something going wrong with encrypted backups against the harm from bad
> > publicity should a tape be lost. My favorite solution would be to
> > encrypt sensitive data within DB2, but that could have a high
> > performance impact depending on how the data is being used.
> >
> > Regards,
> > Cathy Taddei
> >
> <snip>
>
>
------------------------------------------------------------------------------
>
> This email is confidential and may be legally privileged.
>
> It is intended solely for the addressee. Access to this email by anyone else,
> unless expressly approved by the sender or an authorized addressee, is
> unauthorized.
>
> If you are not the intended recipient, any disclosure, copying, distribution
> or any action omitted or taken in reliance on it, is prohibited and may be
> unlawful. If you believe that you have received this email in error, please
> contact the sender, delete this e-mail and destroy all copies.
>
>
=====
>
>
---------------------------------------------------------------------------------
> 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

Kevin Arnold

Re: Encryption
(in response to Myron Miller)
>From what I've been reading about DB2 V8 encryption and the hardware assists,
>it doesn't seem to be that much of a performance penalty, provided (and here's >a major assumption) the programmers access the encrypted data correctly.

Myron,

What would you consider to be the "correct" means to access the data in this context? Wouldn't developers generally have access to the encryption key?

Thanks!
Kevin

CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail.


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

Andy Lankester

Re: Encryption
(in response to Kevin Arnold)
This is a much wider question. Editproc/Fieldproc based encryption is transparent to users/developers since when the row is in its page it is encrypted (i.e. in the buffer pool, DASD cache, DASD, image copy etc). The moment the row/column needs to be processed to apply predicates etc it must be decrypted and is passed across the SQL interface decrypted.

The only way to prevent developers seeing such data is to scramble the sensitive data by column when extracting subsets of production data for testing. This in turn means preserving correct referential relationships where columns are used as keys in either declared or application enforced RI.

There are products on the market that will do this - TestBase springs to mind but I am sure that there are others.

Andy Lankester

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Arnold, Kevin
Sent: Thursday, January 05, 2006 2:07 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Encryption

>From what I've been reading about DB2 V8 encryption and the hardware
>assists, it doesn't seem to be that much of a performance penalty, provided (and here's >a major assumption) the programmers access the encrypted data correctly.

Myron,

What would you consider to be the "correct" means to access the data in this context? Wouldn't developers generally have access to the encryption key?

Thanks!
Kevin

CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail.


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

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.13/221 - Release Date: 04/01/2006


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