SQLCODE -811 - Not expected return code

Robert Barat

SQLCODE -811 - Not expected return code
Good day to all,

We have recently experienced on rare occasions instances of an 81J
(-811) error on a query where this return code is not expected.
We are using DB2 V8 CM on z/os.

The query is similar to below :

EXEC SQL
SELECT column3
INTO :variable
FROM table1 A
,table2 B
WHERE A.column1 = :dclgen.variable1
AND A.column2 = :dclgen.variable2
AND A.column3 = B.column1
END-EXEC

Table 1 has column1, column2 as the unique index
Table 2 has column1 as the unique index (Primary key)

From these table definitions, I would expect 0 or 1 row from table1 to
be selected by specifying both columns on the unique index,
and then by joining on the unique index to Table 2, would expect either
0 or 1 row returned depending on existance.

A couple of observations from the analysis we've performed.
* if we run query in spufi using the keys from the query in error, we
receive 1 row as expected
* the row in table1 is updated by another transaction around the same
time this select is performed (the transactions appear to be running at
the same time in different CICS regions)
* I have examined the code and cannot see anything unusual or
unexpected.

My questions to the group are
* Is this at all possible due to the concurrent nature of the 2
transactions? (note the query does not specify 'WITH UR' )
* Is there a way I can gather additional diagnostics at run time when
this condition occurs? (we output the key values from working storage to
the cics log only at the moment)



Robert Barat

DB2 Database Administrator

Woolworths IT - NES Data Services

Woolworths Limited


***********************************************************
CAUTION: This email and files included in its transmission
are solely intended for the use of the addressee(s) and may
contain information that is confidential and privileged.
If you receive this email in error, please advise us
immediately and delete it without copying the contents
contained within. Woolworths Limited (including its group
of companies) do not accept liability for the views
expressed within or the consequences of any computer
viruses that may be transmitted with this email. The
contents are also subject to copyright. No part of it
should be reproduced, adapted or transmitted without the
written consent of the copyright owner.
***********************************************************

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Richard Fazio

Re: SQLCODE -811 - Not expected return code
(in response to Robert Barat)
Lock avoidance is a wonderful thing...except in cases like this. I'm
wondering if you are going in with differing access paths using data
only access in one case and index only access in another. I assume you
ran CHECK INDEX on all the tables involved just to make sure that you do
not have a broken index...yes?



As far as extra doc, I had a very illogical condition like this. When I
hit the condition I snapped a dump. I discovered my error with ease
(un-initialized storage).



However, in this case, I thing it would be more helpful to see the data.
Can you change the statement to an Open cursor/ Fetch loop? If you get
a second row back from the cursor start gathering all the data from the
cursor and abend the transaction manually. It may cause a bit of
overhead (depending upon the frequency of the transaction), but at least
you would be sure of the data being observed by the application.



Best of luck,

faz

________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Barat Robert
Sent: Wednesday, December 03, 2008 4:55 PM
To: [login to unmask email]
Subject: [DB2-L] SQLCODE -811 - Not expected return code



Good day to all,



We have recently experienced on rare occasions instances of an 81J
(-811) error on a query where this return code is not expected.

We are using DB2 V8 CM on z/os.



The query is similar to below :



EXEC SQL

SELECT column3

INTO :variable

FROM table1 A

,table2 B

WHERE A.column1 = :dclgen.variable1

AND A.column2 = :dclgen.variable2

AND A.column3 = B.column1

END-EXEC



Table 1 has column1, column2 as the unique index

Table 2 has column1 as the unique index (Primary key)



From these table definitions, I would expect 0 or 1 row from table1 to
be selected by specifying both columns on the unique index,

and then by joining on the unique index to Table 2, would expect either
0 or 1 row returned depending on existance.



A couple of observations from the analysis we've performed.

* if we run query in spufi using the keys from the query in error, we
receive 1 row as expected

* the row in table1 is updated by another transaction around the same
time this select is performed (the transactions appear to be running at
the same time in different CICS regions)

* I have examined the code and cannot see anything unusual or
unexpected.



My questions to the group are

* Is this at all possible due to the concurrent nature of the 2
transactions? (note the query does not specify 'WITH UR' )

* Is there a way I can gather additional diagnostics at run time when
this condition occurs? (we output the key values from working storage to
the cics log only at the moment)





Robert Barat

DB2 Database Administrator

Woolworths IT - NES Data Services

Woolworths Limited



***********************************************************

CAUTION: This email and files included in its transmission

are solely intended for the use of the addressee(s) and may

contain information that is confidential and privileged.

If you receive this email in error, please advise us

immediately and delete it without copying the contents

contained within. Woolworths Limited (including its group

of companies) do not accept liability for the views

expressed within or the consequences of any computer

viruses that may be transmitted with this email. The

contents are also subject to copyright. No part of it

should be reproduced, adapted or transmitted without the

written consent of the copyright owner.

***********************************************************


________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG. The
DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Roger Hecq

Re: SQLCODE -811 - Not expected return code
(in response to Richard Fazio)
Do you do Load Resume Yes loads on either of these tables and might a
failed load have been terminated and rerun, instead of restarted? That
will cause duplicate data to exist, but there will be no index entries
for the rows in the failed load..


Roger Hecq
MF IB USA DB Support
203-719-0492 / 19-337-0492



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Barat Robert
Sent: Wednesday, December 03, 2008 5:55 PM
To: [login to unmask email]
Subject: [DB2-L] SQLCODE -811 - Not expected return code


Good day to all,

We have recently experienced on rare occasions instances of an 81J
(-811) error on a query where this return code is not expected.
We are using DB2 V8 CM on z/os.

The query is similar to below :

EXEC SQL
SELECT column3
INTO :variable
FROM table1 A
,table2 B
WHERE A.column1 = :dclgen.variable1
AND A.column2 = :dclgen.variable2
AND A.column3 = B.column1
END-EXEC

Table 1 has column1, column2 as the unique index
Table 2 has column1 as the unique index (Primary key)

From these table definitions, I would expect 0 or 1 row from table1 to
be selected by specifying both columns on the unique index,
and then by joining on the unique index to Table 2, would expect either
0 or 1 row returned depending on existance.

A couple of observations from the analysis we've performed.
* if we run query in spufi using the keys from the query in error, we
receive 1 row as expected
* the row in table1 is updated by another transaction around the same
time this select is performed (the transactions appear to be running at
the same time in different CICS regions)
* I have examined the code and cannot see anything unusual or
unexpected.

My questions to the group are
* Is this at all possible due to the concurrent nature of the 2
transactions? (note the query does not specify 'WITH UR' )
* Is there a way I can gather additional diagnostics at run time when
this condition occurs? (we output the key values from working storage to
the cics log only at the moment)



Robert Barat

DB2 Database Administrator

Woolworths IT - NES Data Services

Woolworths Limited

***********************************************************

CAUTION: This email and files included in its transmission

are solely intended for the use of the addressee(s) and may

contain information that is confidential and privileged.

If you receive this email in error, please advise us

immediately and delete it without copying the contents

contained within. Woolworths Limited (including its group

of companies) do not accept liability for the views

expressed within or the consequences of any computer

viruses that may be transmitted with this email. The

contents are also subject to copyright. No part of it

should be reproduced, adapted or transmitted without the

written consent of the copyright owner.

***********************************************************


________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG. The
DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Sally Mir

Re: SQLCODE -811 - Not expected return code
(in response to Roger Hecq)
Depending upon how much data we're talking about, could you run something
like this to see if you really do have duplicate data?


SELECT column3, count(*)
FROM table1 A
,table2 B
WHERE A.column3 = B.column1
GROUP BY column3
HAVING COUNT(*) > 1.

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Robert Barat

Re: SQLCODE -811 - Not expected return code
(in response to Sally Mir)
Hello Faz,
Thank you for the reply.
I have only recently started in the DBA role so I will do some research
on the CHECK INDEX command and try that.
The table has had an online reorg recently (before the problem occured
however) as a new index was added recently for performance reasons.

The index that the 'select' query is using (index only = 'Y') is
different to the index (index only = 'Y') 'update' the other transaction
is doing. However, the index used by the select query is updated, as the
column being updated exists on this index. (i have viewed the log
records and can see the exact update performed at the time the condition
was returned)

I have noticed now the developers have included extra output in the code
where this return code occurs, which should give us a little more
information to work with. If the problem persists, I will discuss with
the developers about adding extra logic using cursors to handle the -811
and perhaps capture more information. This should show if there is an
un-initialized storage variable which i could not determine when
stepping through the logic in the code.

Cheers
-rob

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Fazio, Richard
Sent: Thursday, 4 December 2008 12:49 PM
To: [login to unmask email]
Subject: Re: [DB2-L] SQLCODE -811 - Not expected return code



Lock avoidance is a wonderful thing...except in cases like this.
I'm wondering if you are going in with differing access paths using data
only access in one case and index only access in another. I assume you
ran CHECK INDEX on all the tables involved just to make sure that you do
not have a broken index...yes?



As far as extra doc, I had a very illogical condition like this.
When I hit the condition I snapped a dump. I discovered my error with
ease (un-initialized storage).



However, in this case, I thing it would be more helpful to see
the data. Can you change the statement to an Open cursor/ Fetch loop?
If you get a second row back from the cursor start gathering all the
data from the cursor and abend the transaction manually. It may cause a
bit of overhead (depending upon the frequency of the transaction), but
at least you would be sure of the data being observed by the
application.



Best of luck,

faz


________________________________


From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Barat Robert
Sent: Wednesday, December 03, 2008 4:55 PM
To: [login to unmask email]
Subject: [DB2-L] SQLCODE -811 - Not expected return code



Good day to all,



We have recently experienced on rare occasions instances of an
81J (-811) error on a query where this return code is not expected.

We are using DB2 V8 CM on z/os.



The query is similar to below :



EXEC SQL

SELECT column3

INTO :variable

FROM table1 A

,table2 B

WHERE A.column1 = :dclgen.variable1

AND A.column2 = :dclgen.variable2

AND A.column3 = B.column1

END-EXEC



Table 1 has column1, column2 as the unique index

Table 2 has column1 as the unique index (Primary key)



From these table definitions, I would expect 0 or 1 row from
table1 to be selected by specifying both columns on the unique index,

and then by joining on the unique index to Table 2, would expect
either 0 or 1 row returned depending on existance.



A couple of observations from the analysis we've performed.

* if we run query in spufi using the keys from the query in
error, we receive 1 row as expected

* the row in table1 is updated by another transaction around the
same time this select is performed (the transactions appear to be
running at the same time in different CICS regions)

* I have examined the code and cannot see anything unusual or
unexpected.



My questions to the group are

* Is this at all possible due to the concurrent nature of the 2
transactions? (note the query does not specify 'WITH UR' )

* Is there a way I can gather additional diagnostics at run time
when this condition occurs? (we output the key values from working
storage to the cics log only at the moment)





Robert Barat

DB2 Database Administrator

Woolworths IT - NES Data Services

Woolworths Limited



***********************************************************

CAUTION: This email and files included in its transmission

are solely intended for the use of the addressee(s) and may

contain information that is confidential and privileged.

If you receive this email in error, please advise us

immediately and delete it without copying the contents

contained within. Woolworths Limited (including its group

of companies) do not accept liability for the views

expressed within or the consequences of any computer

viruses that may be transmitted with this email. The

contents are also subject to copyright. No part of it

should be reproduced, adapted or transmitted without the

written consent of the copyright owner.

***********************************************************


________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
The DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
The DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


***********************************************************
CAUTION: This email and files included in its transmission
are solely intended for the use of the addressee(s) and may
contain information that is confidential and privileged.
If you receive this email in error, please advise us
immediately and delete it without copying the contents
contained within. Woolworths Limited (including its group
of companies) do not accept liability for the views
expressed within or the consequences of any computer
viruses that may be transmitted with this email. The
contents are also subject to copyright. No part of it
should be reproduced, adapted or transmitted without the
written consent of the copyright owner.
***********************************************************

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Robert Barat

Re: SQLCODE -811 - Not expected return code
(in response to Robert Barat)
Hello Roger,
Thankyou for the reply.
Neither table has had a load of any type being performed since being
recently reorged (reorgs were done before the problem occured)
I will run a CHECK INDEX as per previous reply from Faz, to rule out a
problematic index thou..

Cheers
-rob
-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Roger Hecq
Sent: Friday, 5 December 2008 1:40 AM
To: [login to unmask email]
Subject: Re: [DB2-L] SQLCODE -811 - Not expected return code



Do you do Load Resume Yes loads on either of these tables and
might a failed load have been terminated and rerun, instead of
restarted? That will cause duplicate data to exist, but there will be
no index entries for the rows in the failed load..


Roger Hecq
MF IB USA DB Support
203-719-0492 / 19-337-0492



________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Barat Robert
Sent: Wednesday, December 03, 2008 5:55 PM
To: [login to unmask email]
Subject: [DB2-L] SQLCODE -811 - Not expected return code


Good day to all,

We have recently experienced on rare occasions instances of an
81J (-811) error on a query where this return code is not expected.
We are using DB2 V8 CM on z/os.

The query is similar to below :

EXEC SQL
SELECT column3
INTO :variable
FROM table1 A
,table2 B
WHERE A.column1 = :dclgen.variable1
AND A.column2 = :dclgen.variable2
AND A.column3 = B.column1
END-EXEC

Table 1 has column1, column2 as the unique index
Table 2 has column1 as the unique index (Primary key)

From these table definitions, I would expect 0 or 1 row from
table1 to be selected by specifying both columns on the unique index,
and then by joining on the unique index to Table 2, would expect
either 0 or 1 row returned depending on existance.

A couple of observations from the analysis we've performed.
* if we run query in spufi using the keys from the query in
error, we receive 1 row as expected
* the row in table1 is updated by another transaction around the
same time this select is performed (the transactions appear to be
running at the same time in different CICS regions)
* I have examined the code and cannot see anything unusual or
unexpected.

My questions to the group are
* Is this at all possible due to the concurrent nature of the 2
transactions? (note the query does not specify 'WITH UR' )
* Is there a way I can gather additional diagnostics at run time
when this condition occurs? (we output the key values from working
storage to the cics log only at the moment)



Robert Barat

DB2 Database Administrator

Woolworths IT - NES Data Services

Woolworths Limited



***********************************************************

CAUTION: This email and files included in its transmission

are solely intended for the use of the addressee(s) and may

contain information that is confidential and privileged.

If you receive this email in error, please advise us

immediately and delete it without copying the contents

contained within. Woolworths Limited (including its group

of companies) do not accept liability for the views

expressed within or the consequences of any computer

viruses that may be transmitted with this email. The

contents are also subject to copyright. No part of it

should be reproduced, adapted or transmitted without the

written consent of the copyright owner.

***********************************************************


________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
The DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
The DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


***********************************************************
CAUTION: This email and files included in its transmission
are solely intended for the use of the addressee(s) and may
contain information that is confidential and privileged.
If you receive this email in error, please advise us
immediately and delete it without copying the contents
contained within. Woolworths Limited (including its group
of companies) do not accept liability for the views
expressed within or the consequences of any computer
viruses that may be transmitted with this email. The
contents are also subject to copyright. No part of it
should be reproduced, adapted or transmitted without the
written consent of the copyright owner.
***********************************************************

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Robert Barat

Re: SQLCODE -811 - Not expected return code
(in response to Robert Barat)
Hello
Thankyou for replying.
I have run similar queries to this to try capture the duplicate
scenario. I dare not run the query without specifying 'WITH UR' on our
production system to prevent locks, but the returned result has failed
to return any rows which would indicate duplicates.

Cheers
-rob

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of [login to unmask email]
Sent: Friday, 5 December 2008 4:48 AM
To: [login to unmask email]
Subject: Re: [DB2-L] SQLCODE -811 - Not expected return code



Depending upon how much data we're talking about, could you run
something like this to see if you really do have duplicate data?



SELECT column3, count(*)
FROM table1 A
,table2 B
WHERE A.column3 = B.column1
GROUP BY column3
HAVING COUNT(*) > 1




________________________________

IDUG 2009 - North America * May 11-15, 2009 * Denver, CO, USA
< http://idug.org/lsNA >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
The DB2-L list archives, FAQ, and delivery preferences are at IDUG.ORG
< http://www.idug.org/lsidug > under the Listserv tab. While at the site,
you can also access the IDUG Online Learning Center, Tech Library and
Code Place, see the latest IDUG conference information
< http://www.idug.org/lsconf > , and much more. If you have not yet signed
up for Basic Membership in IDUG, available at no cost, click on Member
Services < http://www.idug.org/lsms >


***********************************************************
CAUTION: This email and files included in its transmission
are solely intended for the use of the addressee(s) and may
contain information that is confidential and privileged.
If you receive this email in error, please advise us
immediately and delete it without copying the contents
contained within. Woolworths Limited (including its group
of companies) do not accept liability for the views
expressed within or the consequences of any computer
viruses that may be transmitted with this email. The
contents are also subject to copyright. No part of it
should be reproduced, adapted or transmitted without the
written consent of the copyright owner.
***********************************************************

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms