ca.portal.admin

Re: Help with PERFMON Information

Discussion created by ca.portal.admin on Sep 28, 2005
Bill,
This sure sounds like an ADS retrieval locking problem. Is it possible that
any ADS dialogs were executing at the same time the CICS program was and
they locked the records that caused the CICS program to deadlock and time
out? If the CICS program was running in shared update, it should not have
locked records.
Margaret

-----Original Message-----
From: Bill Allen [mailTo:ARCHCONB@AOL.COM]
Sent: Tuesday, September 27, 2005 09:37 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Help with PERFMON Information

Hello All:

We are having a data base performance problem that I am trying to figure
out
with an online IDMS CICS Program. Using Performance monitor PMRM PF 6
Transaction Detail I can see the last verb number, current area name and
current
record name, but, the last verb number is a 0021, here is what help says
for
the Last Verb Number field:

03 Help for Field - Last_Verb_Number
Last Verb identifies the last DML verb issued for a transaction. The
number is assigned to the verb as a major function code (see the CA-IDMS
Programmer's Quick Reference.

Here is the problem, there is no DML Major Function Code of 0021 or 21, if
this field is the IDBMSCOM field, the program does not have an IDBMSCOM
(21),
if this value is in hex, then the value would be 33, an IDBMSCOM (33) is an
obtain record name within set using sort key. One problem with that is that
the
program does not have an OBTAIN RECORD WITHIN SET USING SORT-KEY for the
record named in the Current Record name and Current Area Name. The area
name and
record name in the PMRM display only has one DML Verb for the named record
in the program and it is a STORE ORDDTL.

The ORDDTL record is getting stored VIA into a sorted chained set, the set
has NP pointers, the set connection is MA, the sort order is ASC and
duplicates
are last. I am running an IDMSDBAN now to determine set lengths but
according to the programmer there is a 1 to 25 relationship, 25 member
records to
each owner record .

The performance problem is that the program is reading approximately 16,000
records or 6,000 pages, the records requested from DB is 16,000 but the
records current of transaction is only 28. Since this program access the
area in
shared update it appears to be locking every record it reads, the lock
requests
are also 16,000, of course this is causing other tasks that access these
records to get a DB-KEY wait and some Dead Locks.

At this point I am confused by Performance Monitor, does anyone know what
this Last Verb Number Field really is? And can I believe the Current Record
Name and Current Area Name fields?

Bill Allen
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Help with PERFMON Information
"Bill,
This sure sounds like an ADS retrieval locking problem. Is it possible that any ADS dialogs were executing at the same time the CICS program was and they locked the records that caused the CICS program to deadlock and time out? If the CICS program was running in shared update, it should not have locked records.
Margaret

-----Original Message-----
From: Bill Allen [mailTo:ARCHCONB@AOL.COM]
Sent: Tuesday, September 27, 2005 09:37 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Help with PERFMON Information

Hello All:

We are having a data base performance problem that I am trying to figure out
with an online IDMS CICS Program. Using Performance monitor PMRM PF 6
Transaction Detail I can see the last verb number, current area name and current
record name, but, the last verb number is a 0021, here is what help says for
the Last Verb Number field:

03 Help for Field - Last_Verb_Number
Last Verb identifies the last DML verb issued for a transaction. The
number is assigned to the verb as a major function code (see the CA-IDMS
Programmer's Quick Reference.

Here is the problem, there is no DML Major Function Code of 0021 or 21, if
this field is the IDBMSCOM field, the program does not have an IDBMSCOM (21),
if this value is in hex, then the value would be 33, an IDBMSCOM (33) is an
obtain record name within set using sort key. One problem with that is that the
program does not have an OBTAIN RECORD WITHIN SET USING SORT-KEY for the
record named in the Current Record name and Current Area Name. The area name and
record name in the PMRM display only has one DML Verb for the named record
in the program and it is a STORE ORDDTL.

The ORDDTL record is getting stored VIA into a sorted chained set, the set
has NP pointers, the set connection is MA, the sort order is ASC and duplicates
are last. I am running an IDMSDBAN now to determine set lengths but
according to the programmer there is a 1 to 25 relationship, 25 member records to
each owner record .

The performance problem is that the program is reading approximately 16,000
records or 6,000 pages, the records requested from DB is 16,000 but the
records current of transaction is only 28. Since this program access the area in
shared update it appears to be locking every record it reads, the lock requests
are also 16,000, of course this is causing other tasks that access these
records to get a DB-KEY wait and some Dead Locks.

At this point I am confused by Performance Monitor, does anyone know what
this Last Verb Number Field really is? And can I believe the Current Record
Name and Current Area Name fields?

Bill Allen
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Help with PERFMON Information (Another Update)
"Bill:

I think that the PMRM verbs are in hex, so 21 is really 33. And
it is the last verb successfully executed by the system, so the system
could be doing a find record within a sorted set before the store (or in
support thereof). You mentioned that the run time is excessive; I have
seen STORE's into large sorted sets take an unbelievable long time to
execute. One former client who shall remain nameless had sorted sets
with 20,000 members and wondered why performance was bad (I fixed by
changing the sorted set into user-owned index). Another former client
had CALC-to-CALC sorted sets in the same area and were surprised to
learn that they had guaranteed themselves poor performance because each
record almost always was on a different page! Anyway, from the limited
symptoms you describe, I suspect that a large sorted set is your
problem.

Dan Miley
Lockheed Martin

Outcomes