Storing VIA records in a separate area

Discussion created by ca.portal.admin on Aug 17, 2005
What really happens when you store a record VIA a record in a different
area? The database administration manual says this: ""Advantage
CA-IDMS/DB stores the member record occurrence as close as possible to
the page (within the member record's page range) that is proportional to
the location of the owner (within the owner's page range).""

But here is what I am seeing: The owner records are stored CALC and are
seldom updated. The member records are stored in a separate area VIA a
sorted set. There is high activity for the member records, primarily
stores. The application gets a lot of ""waiting for LMGR"" abends, mostly
on page locks. It appears that everyone is trying to store records on
the same page at once. After a while, we start seeing multiple page
locks on a new page, always a higher page number than the previous one.
It has the pattern of contention caused by storing records DIRECT.

Can anyone explain this behavior? The member area is very large,
spanning multiple files. The sorted sets can also get quite large, so
that many records probably cannot be stored on their original target

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov

IDMS Public Discussion Forum


Unload/Reload of IDMS/SQL area
"Our Database Designers (DBD's) have been doing unload/reload processing of
non-SQL databases for many years and have had no problems with putting the
database areas in retrieval to take a copy upon which they do their database
maintenance. For some years now they have been using DB-EZReorg so that they
can leave the areas in update and the journal files are used for ""catch up""
processing at the end of the process in order to minimise time when the
database areas are not available at all. I think quite a few shops are doing
this without any problems.

It looks like we may be getting our first IDMS/SQL database development and
the DBD's are concerned that they have not been able to reproduce this
process for an SQL area. When they tried it the first time they found that
they could not do the unload/reload with the SQL area in retrieval. Has
anybody else experienced this?

Generally - are there any traps or pitfalls an experienced non-SQL DBA
should watch out for when performing physical maintenance activities against
IDMS/SQL databases for the first time? If anybody is aware of a CA-World or
IUA Workshop presentation on this subject perhaps you could point us in that
direction instead of typing a great long answer on the general issue? The
DBD's main concern at the moment is the unload/reload issue.

TIA - cheers - Gary

Gary Cherlet
Justice Technology Services
Telephone +61 (0)8 8226 5199
Facsimile +61 (0)8 8226 5311
Mobile +61 (0)41 333 1613

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by
reply e-mail to the sender. Please also destroy the original transmission
and its contents.
Confidentiality: This e-mail may contain confidential information which
also may be legally privileged. Only the intended recipient(s) may access,
use, distribute or copy this e-mail.
Individual Views: Unless otherwise indicated, the views expressed are those
of the sender, not Justice Technology Services.
Computer Viruses: It is the recipient's responsibility to check the e-mail
and any attached files for viruses.

IDMS Public Discussion Forum


Re: PMAM reports
"DBIO WAIT time in the DB Statistics is actual time spent waiting for an IO
to happen. When your online or batch task requires an IO to be performed -
the IO is scheduled and your task WAITs on an ECB that when posted indicates
the IO has been completed. When the ECB is posted the CV sets your dispatch
element (DCE) to READY - you now have to wait until your task can be
redispatched based on normal task priorities and what other events tasks
(including yours) may be waiting on. The IO wait time is from the time the
IO is requested until your ECB is posted and the DCE is flagged as READY.
The problem with IO Waits is that they might be journal, application
database, dictionary load, DC log and so forth - although I note from the
manual that Report 36 breaks out READ and WRITE time by DB, Journal, Log and
Scratch (although with Scratch in XA you shouldn't see too much of that ;-)
) - so you should be able to see where your IO bottlenecks are.

For my money I'd look at the Interval Monitor reports if I was trying to
identify WAIT type problems. PMIRPT11 I/O by AREA Summary or PMIRPT12 I/O by
FILE Summary might be useful for your current exercise. PMIRPT04 Summary
WAIT Detail Report might also be useful to see if there are other types of
waits that are a bottleneck as well as I/O.

HTH - cheers - Gary