IRLM Question

Sharon Fields-SW UG Leader

IRLM Question
5 Sundays ago we were attempting to drop a 130partition tablespace with 3
indexes, normal
number of grants, 275 packages bound to it.
Process failed with following error:

DSNT501I _DSNJ DSNILMCL RESOURCE UNAVAILABLE 239
CORRELATION-ID=MYUSERID
CONNECTION-ID=DB2CALL
LUW-ID=*
REASON 00C90092
TYPE 00000905
NAME IRLM

We requested that our IRLM region be increased, which it was on 1/15.
That Sunday
night we did the required conversion using a sidecopy/rename method.
Tuesday
morning when we went to drop the object we got the same error. Ouch --
the attempted
drop was at 9:00am

Have confirmed that our region was doubled -- now at: MAXCSA=10 (M). What
might
be going on here ? Was the culprit that the second drop was poorly timed ?
Could a
very disorganized catalog have added to the problem ?


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


Sharon Fields
Consulting Analyst
ITD Database Services
Direct:     480-391-4469
Cell:         602-321-6595
Fax:         480-314-4850
[login to unmask email]

CaremarkPCS
9501 E. Shea Blvd. MC 081
Scottsdale, AZ 85260



CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may
contain confidential and/or privileged information for the use of the
designated recipients named above. If you are not the intended recipient,
you are hereby notified that you have received this communications in error
and that any review, disclosure, dissemination, distribution or copying of
it or its contents is prohibited. If you have received this communication
in error, please notify the sender immediately by telephone and destroy all
copies of this communication and any attachments.

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

Mike Bell

Re: IRLM Question
(in response to Sharon Fields-SW UG Leader)
The first question is are you running pc=NO. If so the storage you ran out
of was ECSA not IRLM private. You might as well change to PC=YES because it
is the only option for V8.
If you are running with PC=NO, you have to IPL to change the size of ECSA
talk to your MVS people.

The second suggestion is to break the work into smaller pieces.
free the packages, stop the tablespace and indexes, drop the indexes then
commit, drop all RI commit again, delete the datasets with IDCAMS then drop
the tablespace. That should work no matter how much activity there is.

Mike
HLS Technologies

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Sharon Fields-SW UG Leader
Sent: Wednesday, January 18, 2006 3:06 PM
To: [login to unmask email]
Subject: [DB2-L] IRLM Question

5 Sundays ago we were attempting to drop a 130partition tablespace with 3
indexes, normal
number of grants, 275 packages bound to it.
Process failed with following error:

DSNT501I _DSNJ DSNILMCL RESOURCE UNAVAILABLE 239
CORRELATION-ID=MYUSERID
CONNECTION-ID=DB2CALL
LUW-ID=*
REASON 00C90092
TYPE 00000905
NAME IRLM

We requested that our IRLM region be increased, which it was on 1/15.
That Sunday
night we did the required conversion using a sidecopy/rename method.
Tuesday
morning when we went to drop the object we got the same error. Ouch --
the attempted
drop was at 9:00am

Have confirmed that our region was doubled -- now at: MAXCSA=10 (M). What
might
be going on here ? Was the culprit that the second drop was poorly timed ?
Could a
very disorganized catalog have added to the problem ?


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


Sharon Fields
Consulting Analyst
ITD Database Services
Direct:     480-391-4469
Cell:         602-321-6595
Fax:         480-314-4850
[login to unmask email]

CaremarkPCS
9501 E. Shea Blvd. MC 081
Scottsdale, AZ 85260



CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may
contain confidential and/or privileged information for the use of the
designated recipients named above. If you are not the intended recipient,
you are hereby notified that you have received this communications in error
and that any review, disclosure, dissemination, distribution or copying of
it or its contents is prohibited. If you have received this communication
in error, please notify the sender immediately by telephone and destroy all
copies of this communication and any attachments.

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Avram Friedman

Re: IRLM Question
(in response to Mike Bell)
The suggested region size for the IRLM is 0M ... I think it is the only size that should be used.

One problem that you may run into is operating system limits on the size of the address space or the amount of private that may be obtained above the line. What is coded on the REGION= parameter may be an exercise in futility.

I suggest
1. Checking with your operating systems programmer about any parmlib or exit imposed limits, and have them removed with all possible haste.
2. Do a "F irlmname,STATUS,STOR" command from the console, SDSF etc to see what is really happening with IRLM storage.

IRLM will allow the storage available for locks to grow to 90% of the actual region size before giving a out of storage condition.

Once again the actual region size may have nothing to do with what is coded on the REGION= in the JCL


Sharon Fields-SW UG Leader <[login to unmask email]> wrote:
5 Sundays ago we were attempting to drop a 130partition tablespace with 3
indexes, normal
number of grants, 275 packages bound to it.
Process failed with following error:

DSNT501I _DSNJ DSNILMCL RESOURCE UNAVAILABLE 239
CORRELATION-ID=MYUSERID
CONNECTION-ID=DB2CALL
LUW-ID=*
REASON 00C90092
TYPE 00000905
NAME IRLM

We requested that our IRLM region be increased, which it was on 1/15.
That Sunday
night we did the required conversion using a sidecopy/rename method.
Tuesday
morning when we went to drop the object we got the same error. Ouch --
the attempted
drop was at 9:00am

Have confirmed that our region was doubled -- now at: MAXCSA=10 (M). What
might
be going on here ? Was the culprit that the second drop was poorly timed ?
Could a
very disorganized catalog have added to the problem ?


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


Sharon Fields
Consulting Analyst
ITD Database Services
Direct: 480-391-4469
Cell: 602-321-6595
Fax: 480-314-4850
[login to unmask email]

CaremarkPCS
9501 E. Shea Blvd. MC 081
Scottsdale, AZ 85260



CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may
contain confidential and/or privileged information for the use of the
designated recipients named above. If you are not the intended recipient,
you are hereby notified that you have received this communications in error
and that any review, disclosure, dissemination, distribution or copying of
it or its contents is prohibited. If you have received this communication
in error, please notify the sender immediately by telephone and destroy all
copies of this communication and any attachments.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm




Avram Friedman
(877)311-0480 Voice Mail
[login to unmask email]
Http://www.IBMsysProg.com




---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Jim Tonchick

Re: IRLM Question
(in response to Avram Friedman)
I suffered the same problem once.

What is going on is the IRLM is overloaded obtaining locks for objects in
the catalog related to the tablespace you are attempting to drop. All the
tables in the catalog that contain data on the tablespace and everything in it.
You have the table then indexes, statistics, any history, SYSCOPY recovery
information, authorization tables, etc. To relieve the problem, I deleted as
much "related" information as possible. I ran MODIFY RECOVERY, REVOKED
authorizations, unloaded history then deleted it. I then performed "reverse
drops", first indexes, then any tables, an finally the tablespace.

Jim Tonchick

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