CA IDMS IUA EIUA

Re:UNLOAD/RELOAD apars

  • 1.  Re:UNLOAD/RELOAD apars

    Posted 09-30-2008 08:11 AM
    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