ca.portal.admin

Perfmon Information (RESOLVED)

Discussion created by ca.portal.admin on Sep 30, 2005
Latest reply on Sep 30, 2005 by ca.portal.admin
Hello All:

The programming staff found the problem, it was a currency issue.

They were storing the record into the same sorted set all of the time so
the
sorted set was getting longer and longer, 16,545 members. This was a very
big area, 550,000 pages across nine files.

This accounted for the long elapsed run times, the number of pages read and
the number of record locks.

Thanks to everyone who responded.

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: Perfmon Information (RESOLVED)
"Joe is absolutely correct. This lesson I learned when we were inserting
date sequenced records into a set sorted by date with the newest last.
Knowing that the input was always going at the end of the set, the trick
was to position on the owner, grab the prior (last) in the set (prior
pointers should damned well be mandatory!) and then do the store.

Alan Fields
VF Services, Inc.
Greensboro, NC
336-424-4773
Alan_Fields@vfc.com

IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM> wrote on
09/30/2005 10:18:09 AM:
Bill,
There was one statement you made in an earlier post that I believe is in
error. You stated that an insertion into a sorted set will cause IDMS
to
read the set from the owner forward (using the NEXT pointer) until the
insertion point is found.
However, I remember from my programming days that if you insert a record
into a sorted set, IDMS will first reestablish currency in that set (if
there is a current of set) and then determine if the record to be
inserted
is further down the chain (in the NEXT direction). If so, it starts
reading
the set from the current member, not from the owner. If the record is
further back in the chain, it will start from the owner.
I once had an issue where sorted sets were getting very long and I had
to
keep inserting into them. My advantage was that the data coming in was
presorted. What I did was create a VSAM file (initialized on each run)
which kept track of the current of set for every set occurance by
keeping
the data key of the owner and the DBKEY of the current of set. When I
read
my next piece of data, I would determine which set it needed to be
inserted
into, read the VSAM file to get the DBKEY for the last time I was in
that
set, reestablish currency, and then STORE my record. This caused IDMS
to
only read from the point of last insertion to the point of the new
insertion. Once the new record was stored, I'd modify my VSAM record to
update the DBKEY for that set. It cut the run time down by hours.
Joe Lupico
IDMS System Support
""Our World is a Happy World""
>
-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]On
Behalf Of Bill Allen
Sent: Friday, September 30, 2005 9:35 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Perfmon Information (RESOLVED)
>
Hello All:
The programming staff found the problem, it was a currency issue.
They were storing the record into the same sorted set all of the time so
the
sorted set was getting longer and longer, 16,545 members. This was a
very
big area, 550,000 pages across nine files.
This accounted for the long elapsed run times, the number of pages read
and
the number of record locks.
Thanks to everyone who responded.
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: Perfmon Information (RESOLVED)
"Hello Joe:

I do not think that I am in error, since this is a sorted set how would the
DBMS know where it would put the new member? What if currency was already past
the new insertion point? Would it then get an 0307 when it hit the end of
the set? Would it go all the way around again? No, I am confident that it
starts from the owner of the set. Maybe we need someone from CA to Clarify.

However, there is a keyword CURRENT that can be added to the obtain that
would allow the DBMS to start the search from set currency, but, this was not an
OBTAIN it was a STORE that was causing the issue, the DBMS was issuing the
FIND RECORD WITHIN SET USING SORT-KEY on behalf of the run unit.


All of what you and Alan Fields are saying would absolutely be true if you
knew the input data was coming in sequence, this is an online transaction
coming from a terminal. I have used the technique described by Alan as well in
batch when I knew the input was in sequence.

Bill Allen


In a message dated 9/30/2005 10:19:56 A.M. Eastern Daylight Time,
Joe.Lupico@AIG.COM writes:

Bill,
There was one statement you made in an earlier post that I believe is in
error. You stated that an insertion into a sorted set will cause IDMS to
read the set from the owner forward (using the NEXT pointer) until the
insertion point is found.
However, I remember from my programming days that if you insert a record
into a sorted set, IDMS will first reestablish currency in that set (if
there is a current of set) and then determine if the record to be inserted
is further down the chain (in the NEXT direction). If so, it starts reading
the set from the current member, not from the owner. If the record is
further back in the chain, it will start from the owner.
I once had an issue where sorted sets were getting very long and I had to
keep inserting into them. My advantage was that the data coming in was
presorted. What I did was create a VSAM file (initialized on each run)
which kept track of the current of set for every set occurance by keeping
the data key of the owner and the DBKEY of the current of set. When I read
my next piece of data, I would determine which set it needed to be inserted
into, read the VSAM file to get the DBKEY for the last time I was in that
set, reestablish currency, and then STORE my record. This caused IDMS to
only read from the point of last insertion to the point of the new
insertion. Once the new record was stored, I'd modify my VSAM record to
update the DBKEY for that set. It cut the run time down by hours.

Joe Lupico
IDMS System Support
""Our World is a Happy World""


-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]On
Behalf Of Bill Allen
Sent: Friday, September 30, 2005 9:35 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Perfmon Information (RESOLVED)


Hello All:

The programming staff found the problem, it was a currency issue.

They were storing the record into the same sorted set all of the time so
the
sorted set was getting longer and longer, 16,545 members. This was a very
big area, 550,000 pages across nine files.

This accounted for the long elapsed run times, the number of pages read and
the number of record locks.

Thanks to everyone who responded.

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: Perfmon Information (RESOLVED)
"Hi Bill,
To answer your question about how IDMS would know...let's assume the set
is sorted ASCending.

IDMS would look at the value of the sort key in the record which is
current of set. If the new sort key is higher, it begins reading the set
from that point forward. If the new sort key is less, it starts at the
owner. A pretty simple check and one which can always be done because the
NEXT pointer is mandatory.
It could also be done with a set in DECending order.

Joe Lupico
IDMS System Support
""Our World is a Happy World""

Outcomes