CA IDMS IUA EIUA

Expand all | Collapse all

UNLOAD/RELOAD apars

  • 1.  UNLOAD/RELOAD apars

    Posted 09-30-2008 06: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.

    =20

    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.) =20

    =20

    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.

    =20

    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.

    =20

    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.=20

    =20

    =20

    =20

    Dick Weiland

    =20

    CA

    Senior Sustaining Engineer

    CA-IDMS Level-II Support

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =20

    =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
    Re: UNLOAD/RELOAD apars
    "Thanks for the full description Dick. We have a couple of situations
    that could benefit from this change as we have to expand some areas that
    contain long chained sets.

    Chris


  • 2.  Re:UNLOAD/RELOAD apars

    Posted 09-30-2008 06: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 Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: UNLOAD/RELOAD apars
    "just curious - these are unpublished (test) fixes now?

    will they be published as APARs or USERMODs? are these changes universally
    desirable? or is there a significant downside that would merit optional
    application?

    thanks
    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com



    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS 3rd-party providers forum
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    IDMSVENDOR-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: [IDMSVENDOR-L] UNLOAD/RELOAD apars
    "just curious - these are unpublished (test) fixes now?

    will they be published as APARs or USERMODs? are these changes universally
    desirable? or is there a significant downside that would merit optional
    application?

    thanks
    Chris Hoelscher
    Senior IDMS & DB2 Database Administrator
    Humana Inc
    502-476-2538
    choelscher@humana.com



    The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
    "
    IDMS Public Discussion Forum
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP
    IDMS-L@LISTSERV.IUASSN.COM
    IDMS-L@LISTSERV.IUASSN.COM
    SMTP








    Normal

    Normal
    Re: UNLOAD/RELOAD apars
    "Hello Dick:

    Thank you for the clear and concise explanation.

    William M. Allen, Jr.
    ARCH Consulting Associates, Ltd.
    (704) 641-0296