sporatic dynamic alloation problems

We're having a weird problem with dynamic allocation that I'm wondering
whether anyone else is having it. Here's the thing. We've been using
dynamic allocation in all our CVs except for production for years. Last
summer, we finally converted over the production CV to include the
DSNames, and commented out all production file names in JCL INCLUDE
members so that all production jobs running in local mode are also using
dynamic allocation with the same file names. Our production CV is
cycled every night, and is down for several hours on sunday for
system-wide backups. Here's the problem.... Every once in a while,
when the production CV is brought back up, one or several files don't
get allocated due to a dynamic allocation error, and the area is flagged
as Not Available. In the log, we get message DC016922 OPENXDCB ERR=042
with the file name. If we vary the area in update, the file gets
allocated correctly, and the area is varied to update. We've determined
that it happens when there is a local mode job using the file (in
retrieval) while CV comes up. We don't seem to have any problems
when it's local mode jobs running while CV is up. I can remember a
couple of occasions where we got a dynamic allocation error, reran the
local mode job and everything was just fine.

There is an optional apar you can apply so that in local mode, if you
get the DC016922 message, it will wait and reattempt to allocate the
file. The apar is only for local mode jobs however. I've opened up a
problem with CA and have requested basically the same functionality in
the sense that if startup gets a DC016922 error, that startup continue,
but then reattempt to allocate the file. They've agreed to do
something, but I'm really curious. Am I the only one having this type
of problem with dynamic allocation????

Thanks,
Laura Rochon
Ajilon Consulting
This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipients of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed.

On the weekend I was running an unload/reload on a number of Areas in our database. I noticed that the IDMSDBL3 step was taking a long time and doing a lot of I/o's

In this job I was Unloading and Reloading a large Index area. I put a Page reserve on it, like I always do to tune the Index to allow for new records on the page and for the records to increase in size. I build the index using a ICB and then increase it by a couple to allow insertions without the index splitting and spawning. I worked out the number of full sized records that could reside on a page. It worked out to be 5 on a page size of 13680. I put a page reserve of 2540, The SR8 Record size was to be 2539 and I could get 4 records on the page and it would be over the 70% full and mark the SMP Page.

I cancelled the Reload job after it had been running for about 1 ¾ hours and restored the database. I modified the DMCL and removed the page reserve from that area, I reran the Unload and the reload and everything worked out fine. The IDMSDBL3 step took about 10 minutes. I ran a print Index on the area this morning and noticed most of the Level 0 SR8's were not full length SR8's some were as small as 760 bytes.

This Index is defined as

Duplicates are last and uncompressed.

I looked at a number of other indexes I had rebuilt on the weekend and noticed that any Index that had duplicates allowed and uncompressed that the Level 0 SR8's were not full size. Indexes that did not allow duplicates, the Level 0 SR8's were full size.

The Database Administration Manual states that there is to be full key definitions when duplicates are allowed and no compression is to take place when the Index is defined as Uncompressed.

I ran this same Unload/reload on February 24th and had the same problem. I thought I had done something wrong in my calculations so I cancelled the Job after it had done 8-9 million I/O's.

I have never had this type of problem before when I have used page reserve on indexes that I have built or rebuilt using Maintain Index or when doing and Unload/Reload. I have been doing this for almost 20 years.

We are running IDMS Rel 16 SP1 on ZOS 1.6.

Dennis Robock

IDMS DBA

Alberta Department of Energy

This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipients of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed.

The local mode jobs also use dynamic alloaction, with the dsnames in the
DMCL, and no overrides.

Laura

Petzold, Lutz wrote:

What's the jcl of the local mode jobs say? A dd statement would=0D=0Aoverr=
ide the dmcl, if overrides are allowed (default)=2E=0D=0A=0D=0A=0D=0Alutz p=
etzold=0D=0A=0D=0A=0D=0A-----------------------------------------=0D=0AThis=
e-mail may contain confidential or privileged information=2E If you=0D=0A=
think you have received this e-mail in error, please advise the sender=0D=
=0Aby=0D=0Areply e-mail and then delete this e-mail immediately=2E Thank y=
ou=2E=0D=0AAetna=0D=0A

Normal
Re: sporatic dynamic alloation problems
"What's the jcl of the local mode jobs say? A dd statement would
override the dmcl, if overrides are allowed (default).

lutz petzold

-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by
reply e-mail and then delete this e-mail immediately. Thank you.
Aetna

Normal
Re: sporatic dynamic alloation problems
"All the files in the DMCL are defined with DISP SHR, and the areas have
ON STARTUP SET STATUS TO UPDATE, ON WARMSTART MAINTAIN CURRENT STATUS.

This does not happen every time; it very sporatic, but when it does,
we've noticed there are local mode jobs running. Sometimes, it can a
DBAN report or SPACE report and sometimes, like last night, it was an
application retrieval job.

And as I said, we have no problems running local mode jobs with the same
DMCL against the same areas/files.

Thanks,
Laura

Bill Allen wrote:

Hello Laura:

Check the file statements in the segment, someone may have made a typo error
and specified DISP OLD, that would make dynamic file allocation fail for the
second program or job that attempted dynamic allocation.

We're having a weird problem with dynamic allocation that I'm wondering
whether anyone else is having it. Here's the thing. We've been using
dynamic allocation in all our CVs except for production for years. Last
summer, we finally converted over the production CV to include the
DSNames, and commented out all production file names in JCL INCLUDE
members so that all production jobs running in local mode are also using
dynamic allocation with the same file names. Our production CV is
cycled every night, and is down for several hours on sunday for
system-wide backups. Here's the problem.... Every once in a while,
when the production CV is brought back up, one or several files don't
get allocated due to a dynamic allocation error, and the area is flagged
as Not Available. In the log, we get message DC016922 OPENXDCB ERR=042
with the file name. If we vary the area in update, the file gets
allocated correctly, and the area is varied to update. We've determined
that it happens when there is a local mode job using the file (in
retrieval) while CV comes up. We don't seem to have any problems
when it's local mode jobs running while CV is up. I can remember a
couple of occasions where we got a dynamic allocation error, reran the
local mode job and everything was just fine.

There is an optional apar you can apply so that in local mode, if you
get the DC016922 message, it will wait and reattempt to allocate the
file. The apar is only for local mode jobs however. I've opened up a
problem with CA and have requested basically the same functionality in
the sense that if startup gets a DC016922 error, that startup continue,
but then reattempt to allocate the file. They've agreed to do
something, but I'm really curious. Am I the only one having this type
of problem with dynamic allocation????

Normal
Re: sporatic dynamic alloation problems
"DISP=OLD is an old trick to prevent phantom broken chain abends when
another job inserts/removes records in the file's database. It's a
tried and proven way to single thread access to files in MVS.

Lutz Petzold

-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by
reply e-mail and then delete this e-mail immediately. Thank you.
Aetna

Check the file statements in the segment, someone may have made a typo error
and specified DISP OLD, that would make dynamic file allocation fail for the
second program or job that attempted dynamic allocation.

We're having a weird problem with dynamic allocation that I'm wondering
whether anyone else is having it. Here's the thing. We've been using
dynamic allocation in all our CVs except for production for years. Last
summer, we finally converted over the production CV to include the
DSNames, and commented out all production file names in JCL INCLUDE
members so that all production jobs running in local mode are also using
dynamic allocation with the same file names. Our production CV is
cycled every night, and is down for several hours on sunday for
system-wide backups. Here's the problem.... Every once in a while,
when the production CV is brought back up, one or several files don't
get allocated due to a dynamic allocation error, and the area is flagged
as Not Available. In the log, we get message DC016922 OPENXDCB ERR=042
with the file name. If we vary the area in update, the file gets
allocated correctly, and the area is varied to update. We've determined
that it happens when there is a local mode job using the file (in
retrieval) while CV comes up. We don't seem to have any problems
when it's local mode jobs running while CV is up. I can remember a
couple of occasions where we got a dynamic allocation error, reran the
local mode job and everything was just fine.

There is an optional apar you can apply so that in local mode, if you
get the DC016922 message, it will wait and reattempt to allocate the
file. The apar is only for local mode jobs however. I've opened up a
problem with CA and have requested basically the same functionality in
the sense that if startup gets a DC016922 error, that startup continue,
but then reattempt to allocate the file. They've agreed to do
something, but I'm really curious. Am I the only one having this type
of problem with dynamic allocation????

We're having a weird problem with dynamic allocation that I'm wondering
whether anyone else is having it. Here's the thing. We've been using
dynamic allocation in all our CVs except for production for years. Last
summer, we finally converted over the production CV to include the
DSNames, and commented out all production file names in JCL INCLUDE
members so that all production jobs running in local mode are also using
dynamic allocation with the same file names. Our production CV is
cycled every night, and is down for several hours on sunday for
system-wide backups. Here's the problem.... Every once in a while,
when the production CV is brought back up, one or several files don't
get allocated due to a dynamic allocation error, and the area is flagged
as Not Available. In the log, we get message DC016922 OPENXDCB ERR=042
with the file name. If we vary the area in update, the file gets
allocated correctly, and the area is varied to update. We've determined
that it happens when there is a local mode job using the file (in
retrieval) while CV comes up. We don't seem to have any problems
when it's local mode jobs running while CV is up. I can remember a
couple of occasions where we got a dynamic allocation error, reran the
local mode job and everything was just fine.

There is an optional apar you can apply so that in local mode, if you
get the DC016922 message, it will wait and reattempt to allocate the
file. The apar is only for local mode jobs however. I've opened up a
problem with CA and have requested basically the same functionality in
the sense that if startup gets a DC016922 error, that startup continue,
but then reattempt to allocate the file. They've agreed to do
something, but I'm really curious. Am I the only one having this type
of problem with dynamic allocation????

Normal
Re: R14.1 vs. R16 ADS performance
"The QO766** series did not help our ADS performance, but it did cause a
noticeable reduction in CPU for SQL transactions. (Which are primarily
IDMS Server and batch at our shop.) Thanks, Chris.