Reaching the IDBACK Value

Irwin Deutsch

Reaching the IDBACK Value
Hi Listers,

We reached this ZPARM value of 20 and two batch job went down with DSNE130I
(max users reached). First of all, I can't believe it doesn't generate a
'priority' message, in DB2PMSTR or something we can monitor. It's treated
like a 'low-level' problem. CICS broadcasts MAXTASK to the world.

Now that I've got that off my chest, I'm trying to understand how it
happened and ho can I monitor for future. My count of batch jobs was 12; is
there something in this count I'm not aware of? Also, Do any IFCIDS contain
any information related to the failure of connections for this reason and
can we monitor it in realtime?

I appreciate any and all help. Oh, one more thing; we did upgrade to V6 from
V5 two weeks ago, though I don't think that's a factor.


Thanks,

Irwin
DBA/Sysprog
AIG/Sunamerica


Ava Collins

Re: Reaching the IDBACK Value
(in response to Irwin Deutsch)
In a message dated 11/1/2002 4:13:12 PM Eastern Standard Time,
[login to unmask email] writes:

> We reached this ZPARM value of 20 and two batch job went down with DSNE130I
> (max users reached).

Irwin,

When this happened to us, it was because of dead threads .

Jacquie

Missy Case

Re: Reaching the IDBACK Value
(in response to Ava Collins)
We recently have pushed ours up from 50 to 100 after also receiving the
'identity thread create' error.

The background thread task spawning that the utilities do is what caused us
issues. We have some 64 partition tablespaces that we reorg & copy & they
can spawn 8 or 20 sub tasks depending on system resources. Setting it
higher doesn't allocated memory up front, it just lets the jobs run if they
want, so we didn't figure it'd break anything being set higher.

Missy Case
FDR
701-275-6358




[login to unmask email]
M To: [login to unmask email]
Sent by: DB2 Data cc:
Base Discussion bcc:
List Subject: Re: Reaching the IDBACK Value
<[login to unmask email]
LASSOC.COM>


11/01/02 03:34 PM
Please respond to
DB2 Data Base
Discussion List






In a message dated 11/1/2002 4:13:12 PM Eastern Standard Time,
[login to unmask email] writes:

We reached this ZPARM value of 20 and two batch job went down with
DSNE130I (max users reached).


Irwin,

When this happened to us, it was because of dead threads .

Jacquie



Irwin Deutsch

Re: Reaching the IDBACK Value
(in response to Missy Case)
Thanks for the info, Jacquie, but is there any way to detect these dead
threads? These job abended in the middle of the night without any realtime
monitoring capability. It's only happened one night with two jobs at around
the same time, but I want to be ready for it if it happens again. I'll
probably raise the IDBACK considerably, but we won't recycle DB2 for at
least another ten days.

-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Friday, November 01, 2002 1:35 PM
To: [login to unmask email]
Subject: Re: Reaching the IDBACK Value


In a message dated 11/1/2002 4:13:12 PM Eastern Standard Time,
[login to unmask email] writes:



We reached this ZPARM value of 20 and two batch job went down with DSNE130I
(max users reached).



Irwin,

When this happened to us, it was because of dead threads .

Jacquie

Irwin Deutsch

Re: Reaching the IDBACK Value
(in response to Irwin Deutsch)
Thanks, Missy. I'll do the same, though I have to wait around ten days for
the next recycling of DB2 - and I do want to understand this apparent
discrepancy between IDBACK and the no. of jobs.

-----Original Message-----
From: Missy Case [mailto:[login to unmask email]
Sent: Friday, November 01, 2002 2:07 PM
To: [login to unmask email]
Subject: Re: Reaching the IDBACK Value


We recently have pushed ours up from 50 to 100 after also receiving the
'identity thread create' error.

The background thread task spawning that the utilities do is what caused us
issues. We have some 64 partition tablespaces that we reorg & copy & they
can spawn 8 or 20 sub tasks depending on system resources. Setting it
higher doesn't allocated memory up front, it just lets the jobs run if they
want, so we didn't figure it'd break anything being set higher.

Missy Case
FDR
701-275-6358




[login to unmask email]
M To:
[login to unmask email]
Sent by: DB2 Data cc:
Base Discussion bcc:
List Subject: Re: Reaching the
IDBACK Value
<[login to unmask email]
LASSOC.COM>


11/01/02 03:34 PM
Please respond to
DB2 Data Base
Discussion List






In a message dated 11/1/2002 4:13:12 PM Eastern Standard Time,
[login to unmask email] writes:

We reached this ZPARM value of 20 and two batch job went down with
DSNE130I (max users reached).


Irwin,

When this happened to us, it was because of dead threads .

Jacquie





Ava Collins

Re: Reaching the IDBACK Value
(in response to Irwin Deutsch)
In a message dated 11/1/2002 7:56:55 PM Eastern Standard Time,
[login to unmask email] writes:

> is there any way to detect these dead threads?

Irwin,

Next week I'll ask my DBA what they're doing.

Jacquie

Kirk Hampton

Re: Reaching the IDBACK Value
(in response to Ava Collins)
Hello Irwin,
we also had to increase IDBACK on several of our production
subsystems after migrating to V6. The Utilities in V6 and higher spawn
subtasks, in other words they run with parallelism in many cases,
regardless
of what other ZPARM settings you have related to parallelism. So you
need IDBACK at least 2X the max number of batch utiities you have running
concurrently, i.e. with an IDBACK = 20 you can only run 10 or less
utilities
at a time depending on what other threads are being used.

Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Business Services
Dallas, Texas





Irwin Deutsch <[login to unmask email]>@LISTSERV.YLASSOC.COM> on 11/01/2002
06:52:51 PM

Please respond to DB2 Data Base Discussion List
<[login to unmask email]>

Sent by: DB2 Data Base Discussion List <[login to unmask email]>


To: [login to unmask email]
cc:
Subject: Re: Reaching the IDBACK Value


Thanks, Missy. I'll do the same, though I have to wait around ten days for
the next recycling of DB2 - and I do want to understand this apparent
discrepancy between IDBACK and the no. of jobs.

-----Original Message-----
From: Missy Case [mailto:[login to unmask email]
Sent: Friday, November 01, 2002 2:07 PM
To: [login to unmask email]
Subject: Re: Reaching the IDBACK Value


We recently have pushed ours up from 50 to 100 after also receiving the
'identity thread create' error.

The background thread task spawning that the utilities do is what caused us
issues. We have some 64 partition tablespaces that we reorg & copy & they
can spawn 8 or 20 sub tasks depending on system resources. Setting it
higher doesn't allocated memory up front, it just lets the jobs run if they
want, so we didn't figure it'd break anything being set higher.

Missy Case
FDR
701-275-6358




[login to unmask email]
M To:
[login to unmask email]
Sent by: DB2 Data cc:
Base Discussion bcc:
List Subject: Re: Reaching the
IDBACK Value
<[login to unmask email]
LASSOC.COM>


11/01/02 03:34 PM
Please respond to
DB2 Data Base
Discussion List






In a message dated 11/1/2002 4:13:12 PM Eastern Standard Time,
[login to unmask email] writes:

We reached this ZPARM value of 20 and two batch job went down with
DSNE130I (max users reached).


Irwin,

When this happened to us, it was because of dead threads .

Jacquie



the









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



Isaac Yassin

Re: Reaching the IDBACK Value
(in response to Kirk Hampton)
Hi ,

Just to emphasize - I have reorg jobs running with 6-9 threads each ...
IDBACK=60

You'll have to test with your environment :-) YMMV

Isaac Yassin
DBMS & IT Consultant
IBM Certified Solution Expert
DB2 V7.1 Database Administration for OS/390



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of [login to unmask email]
Sent: Wednesday, November 06, 2002 12:15 AM
To: [login to unmask email]
Subject: Re: Reaching the IDBACK Value


Hello Irwin,
we also had to increase IDBACK on several of our production
subsystems after migrating to V6. The Utilities in V6 and higher
spawn
subtasks, in other words they run with parallelism in many cases,
regardless
of what other ZPARM settings you have related to parallelism. So you
need IDBACK at least 2X the max number of batch utiities you have
running concurrently, i.e. with an IDBACK = 20 you can only run 10 or
less utilities at a time depending on what other threads are being used.

Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Business Services Dallas, Texas



Stephen Mallett

Re: Reaching the IDBACK Value
(in response to Isaac Yassin)
Kirk and other knowledgable Listservers,

We're OS/390 DB2 V6 and our Production SubSystem has
IDBACK=100 CTHREAD=350 MAXDBAT=100 CONDBAT=0
and Test has
IDBACK= 20 CTHREAD= 50 MAXDBAT= 20 CONDBAT=0

I'd like to run Rebuild 12 parts of an NPI with INLINE STATITICS as quickly
as possible - and avoid the "NUMBER OF PARALLEL TASKS LIMITED BY
CONNECTIONS" message. Reading through the manuals and list archives the
relation of DSNZPARMs to parallel UTILITY tasks is still a little unclear.

In Test I believe I need to increase IDBACK to say 100, to be sure, but
would I also need to increase CTHREAD and/or MAXDBAT to Production levels?
And should I also consider increasing the Production levels?

Any advice will be appreiciated
regards,
Steve



Kirk Hampton

Re: Reaching the IDBACK Value
(in response to Stephen Mallett)
Hi Stephen,
MAXDBAT and CONDBAT are for DDF threads, and so have nothing
to do with Utility jobs. But I would increase CTHREAD enough to cover your
increase in IDBACK, since CTHREAD is the max concurrent active threads
started locally (non-DDF) and includes all batch jobs, IMS, CICS, TSO, and
Call-Attach. I would probably retain the difference between your IDBACK
and CTHREAD, so if you are adding 80 to IDBACK, also add 80 to CTHREAD.


Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Business Services
Dallas, Texas




Stephen Mallett <[login to unmask email]>@LISTSERV.YLASSOC.COM> on
12/08/2002 07:42:03 PM

Please respond to DB2 Data Base Discussion List
<[login to unmask email]>

Sent by: DB2 Data Base Discussion List <[login to unmask email]>


To: [login to unmask email]
cc:
Subject: Re: Reaching the IDBACK Value


Kirk and other knowledgable Listservers,

We're OS/390 DB2 V6 and our Production SubSystem has
IDBACK=100 CTHREAD=350 MAXDBAT=100 CONDBAT=0
and Test has
IDBACK= 20 CTHREAD= 50 MAXDBAT= 20 CONDBAT=0

I'd like to run Rebuild 12 parts of an NPI with INLINE STATITICS as quickly
as possible - and avoid the "NUMBER OF PARALLEL TASKS LIMITED BY
CONNECTIONS" message. Reading through the manuals and list archives the
relation of DSNZPARMs to parallel UTILITY tasks is still a little unclear.

In Test I believe I need to increase IDBACK to say 100, to be sure, but
would I also need to increase CTHREAD and/or MAXDBAT to Production levels?
And should I also consider increasing the Production levels?

Any advice will be appreiciated
regards,
Steve



the DB2-L webpage at http://listserv.ylassoc.com. The owners of the list
can





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



Stephen Mallett

Re: Reaching the IDBACK Value
(in response to Kirk Hampton)
Thanks Kirk,

Thought that might be the case - but it never hurts to check with someone
who's actually done it.

regards,
Steve