I feel there is a need to clear up some confusion circulating about the
effect of the latest apars related to VIA clustering by the
UNLOAD/RELOAD/REORG utilities.
Prior to the apars the first three fields within the key used to sort
the intermediate file passed to the IDMSDBL2 step were the new target
page, a sequence number, and the record's old dbkey. For VIA records
not stored VIA a system-owned index, the sequence number field was not
used meaning that all VIA records targeting to a particular page were
sorted within the new target page number by their old dbkey. VIA
clusters for multiple owners targeting to the same page could be
intermixed and if all the VIA records targeting to one page do not fit
on the target page there is no guarantee that any one owner's cluster
would not experience some overflow occurrences. (A part of the sequence
number field is used to insure that CALC and DIRECT records get sorted
ahead of VIA records to increase the probability of them being stored on
their target page.)
As a result the physical sequence of the VIA records stored within the
new database did not match the set's logical sequence. This had no
effect on the overall number of pages needed to contain a page's VIA
records. However when walking a long set it could result in the need to
move between the pages containing the records multiple times. This
could increase a run-unit's PAGES REQUESTED statistic. Each count to
PAGES REQUESTED means that module IDMSDBMS needed to call module
IDMSDBIO to look for the requested page within a buffer. This overhead
is generally very small when the page resides in a buffer but it is none
the less some additional CPU cycles.
The recent apars cause the unload processing to place a sequence number
into the sort key. The sequence number is assigned for a cluster
relative to the owner of the set. For example if record A is a CALC
record which owns record B as a VIA record and record B owns record C as
a VIA record the sequence would be kept through the processing of all of
the record occurrences as the unload process walked the sets. If record
A also owned record D as a VIA record the sequence number would be
restarted for the D record occurrences. This does mean that the sorted
file passed to IDMSDBL2 could still have occurrences of record D
interspersed with occurrences of record types B and C. As prior to the
apars it is also still possible for VIA occurrences for multiple owners
targeting to a specific page to be interspersed.
It should also be noted that records stored VIA a user-owned index have
always been treated in the same manner as records stored VIA a chained
set. Prior to the apars the sequence number field was not used for
these VIA records. The apars will now insert the sequence number into
their sort key as is done for records stored VIA a chained set.
The number of pages required to contain all of the records targeting to
a particular page will not change with the implementation of the apars.
The only difference will be that the order the records will be stored
into the database will match the logical order of their VIA set. This
should allow a better physical progression through the database when
walking the set(s) and possibly reduce the number of calls from IDMSDBMS
to IDMSDBIO when a record is accessed thereby reducing a bit of CPU
overhead. I do not expect the CPU reduction to be anything particularly
significant but any possible improvement in performance is something we
will always be willing to investigate.
Dick Weiland
CA
Senior Sustaining Engineer
CA-IDMS Level-II Support
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
SOS - Release 16 sp 6
"Hi all.
We are in the midst of upgrading from 15.0 sp3 to 16.0 sp6.
On one of our test cv's I have suddenly started going SOS. We haven't
had SOS conditions in a very long time. I have checked and the storage
pool parameters are the same as before we upgraded. The storage pool
having the problem is for Terminal and Database. I have also noticed a
slight increase in the amount of storage needed at start up. =20
Anyone else experienced this? I can obviously increase my pools, but
wonder what has changed.
Here are stats.
D ALL STOR POOLS
POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX
CONTAINS =20
SOS
TYPES =20
0 0023B000 2400K 300K 156K 2400K 198 NO SY,ALL
128 164BF000 10500K 500K 36K 384K 0 NO US,UK
129 16F00000 1000K 100K 180K 772K 0 NO SH,SK
130 16FFA000 1000K 100K 196K 1000K 144 NO TR,DB
255 170F4000 6000K 0K 576K 732K 0 NO SY
Start up now:
00.31.43 JOB24800 +IDMS DC390005 V48 RHDCPARM FREESTG RELEASED...
1,200K
00.31.43 JOB24800 +IDMS DC390006 V48 REGION NEEDED TO START UP...
5,848K
00.31.43 JOB24800 +IDMS DC390020 V48 TOTAL AMOUNT OF XA STORAGE..
86,424K
00.31.43 JOB24800 +IDMS DC390007 V48 SYSTEM CONFIGURATION SIZE...
91,072K
00.31.43 JOB24800 +IDMS DC390008 V48 STORAGE RETURNED TO OPSYS...
4,020K
Before: =20
00.45.20 JOB32634 +IDMS DC390005 V48 RHDCPARM FREESTG RELEASED...
1,200K =20
00.45.20 JOB32634 +IDMS DC390006 V48 REGION NEEDED TO START UP...
5,864K =20
00.45.20 JOB32634 +IDMS DC390020 V48 TOTAL AMOUNT OF XA STORAGE..
84,900K =20
00.45.20 JOB32634 +IDMS DC390007 V48 SYSTEM CONFIGURATION SIZE...
89,560K =20
00.45.20 JOB32634 +IDMS DC390008 V48 STORAGE RETURNED TO OPSYS...
4,020K =20
Thanks in advance
Jim
Jim Rice
jlrice@southernco.com
ph (404) 506-4148
Fax (404) 506- 4870
SO Linc 2988/770.550.2988
This e-mail and any of its attachments may contain proprietary Southern
Company and/or affiliate information that is privileged, confidential,
or protected by copyright belonging to Southern Company and/or its
affiliates. This e-mail is intended solely for the use of the
individual or entity for which it is intended. If you are not the
intended recipient of this e-mail, any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is contrary to the rights of Southern Company and/or its
affiliates and is prohibited. If you are not the intended recipient of
this e-mail, please notify the sender immediately by return e-mail and
permanently delete the original and any copy or printout of this e-mail
and any attachments. Thank you. =20
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
SOS - Release 16 sp 6
"Hi all.
We are in the midst of upgrading from 15.0 sp3 to 16.0 sp6.
On one of our test cv's I have suddenly started going SOS. We haven't
had SOS conditions in a very long time. I have checked and the storage
pool parameters are the same as before we upgraded. The storage pool
having the problem is for Terminal and Database. I have also noticed a
slight increase in the amount of storage needed at start up.
Anyone else experienced this? I can obviously increase my pools, but
wonder what has changed.
Here are stats.
D ALL STOR POOLS
POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX
CONTAINS
SOS
TYPES
0 0023B000 2400K 300K 156K 2400K 198 NO SY,ALL
128 164BF000 10500K 500K 36K 384K 0 NO US,UK
129 16F00000 1000K 100K 180K 772K 0 NO SH,SK
130 16FFA000 1000K 100K 196K 1000K 144 NO TR,DB
255 170F4000 6000K 0K 576K 732K 0 NO SY
Start up now:
00.31.43 JOB24800 +IDMS DC390005 V48 RHDCPARM FREESTG RELEASED...
1,200K
00.31.43 JOB24800 +IDMS DC390006 V48 REGION NEEDED TO START UP...
5,848K
00.31.43 JOB24800 +IDMS DC390020 V48 TOTAL AMOUNT OF XA STORAGE..
86,424K
00.31.43 JOB24800 +IDMS DC390007 V48 SYSTEM CONFIGURATION SIZE...
91,072K
00.31.43 JOB24800 +IDMS DC390008 V48 STORAGE RETURNED TO OPSYS...
4,020K
Before:
00.45.20 JOB32634 +IDMS DC390005 V48 RHDCPARM FREESTG RELEASED...
1,200K
00.45.20 JOB32634 +IDMS DC390006 V48 REGION NEEDED TO START UP...
5,864K
00.45.20 JOB32634 +IDMS DC390020 V48 TOTAL AMOUNT OF XA STORAGE..
84,900K
00.45.20 JOB32634 +IDMS DC390007 V48 SYSTEM CONFIGURATION SIZE...
89,560K
00.45.20 JOB32634 +IDMS DC390008 V48 STORAGE RETURNED TO OPSYS...
4,020K
Thanks in advance
Jim
Jim Rice
jlrice@southernco.com
ph (404) 506-4148
Fax (404) 506- 4870
SO Linc 2988/770.550.2988
This e-mail and any of its attachments may contain proprietary Southern
Company and/or affiliate information that is privileged, confidential,
or protected by copyright belonging to Southern Company and/or its
affiliates. This e-mail is intended solely for the use of the
individual or entity for which it is intended. If you are not the
intended recipient of this e-mail, any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is contrary to the rights of Southern Company and/or its
affiliates and is prohibited. If you are not the intended recipient of
this e-mail, please notify the sender immediately by return e-mail and
permanently delete the original and any copy or printout of this e-mail
and any attachments. Thank you.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: SOS - Release 16 sp 6
"HPSP probably is fragmenting your storage more than you're used to . . .
Double the size of Pool 130 . ..
DCMT D AC STO POO 130 to see the map . . . to check the
fragmentation before & after