IBM Support

II13495: HOW DFSORT TAKES ADVANTAGE OF 64-BIT REAL ARCHITECTURE (D/T2064)

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as canceled.

Error description

  • How DFSORT takes advantage of 64-bit real architecture
    and DFSORT migration recommendations
    .
    Following information applies to DFSORT running on D/T2064.
    
    DFSORT R14 exploits the z900's 64-bit real architecture by
    backing storage and data spaces in real storage above 2
    gigabytes, and by using central storage instead of expanded
    storage for Hipersorting. For data sets for which DFSORT can
    use the EXCP access method, DFSORT can exploit the performance
    of this environment by backing buffers above 2 gigabytes.
    DFSORT V1R5 adds additional capability for exploiting central
    storage through the use of Memory Objects above the 2GB bar.
    In a 31-bit environment, expanded storage is available, but
    can only be exploited by certain applications such as DFSORT,
    resulting in less contention for this resource and potentially
    more use of Hipersorting.   DFSORT Hiperspaces could consume
    large amounts of expanded storage while leaving central storage
    available for other address spaces.   When 64-bit real mode is
    used, all storage is central storage so DFSORT no longer has
    expanded storage to use for creating Hiperspaces and it now
    competes with all other workloads in the system for central
    storage.  To avoid shortages of this critical resource, DFSORT
    now reserves a portion of central storage that  cannot be used
    for Hipersorting (or Memory Objects in V1R5).  Level 2 or the
    change team will not discuss the algorithm used to determine
    how much is reserved.  This information APAR is only provided
    to inform DFSORT users that all of central storage will not be
    used in a 64-bit real environment.  And it is possible that
    some DFSORT jobs may not use the same amount of resources when
    comparing jobs that run in the two (31-bit and 64-bit)
    environments. Since all applications can use central storage in
    the 64-bit environment, more contention will exist for this
    resource, and DFSORT applications may potentially use less
    Hipersorting.  This is especially true in 64-bit environments
    that now have less total storage. For example, if your 31-bit
    environment had 2 gigabytes of central storage and 2 gigabytes
    of expanded storage, and your 64-bit environment now has 3
    gigabytes of central storage, you are probably going to see
    less use of Hipersorting in your 64-bit environment. This can
    also be true if your storage is the same and relatively small
    between the two environments.   For instance, if your 31-bit
    environment had 1 gigabyte of central storage and 1 gigabyte of
    expanded storage, you will see jobs using less Hipersorting in
    a 2 gigabyte 64-bit environment. This makes sense, as before,
    1 gigabyte could only be used by certain applications such as
    DFSORT.  Now that same 1 gigabyte can be used by all
    applications, giving DFSORT less of an opportunity to use that
    resource. In most cases, if DFSORT were to use the same amount
    of Hipersorting in this new 64-bit environment as it did in the
    31-bit environment, paging problems are likely to occur.
    Therefore, DFSORT must be more conservative with its use of
    central storage for Hipersorting.  For larger systems (that is,
    greater than 4 gigabytes of central storage), Hipersorting
    activity should generally be comparable between 64-bit and
    31-bit environments.  When migrating from a 31-bit to a 64-bit
    environment, consider the following:
    
    1.  Review the size of your paging subsystem and increase if
    necessary.  Even if currently there is little or no activity to
    the local page data sets, a migration to 64-bit mode should
    ensure the system has a robust paging subsystem. The auxiliary
    subsystem will now be the only resource available to support a
    workload disruption to central storage.  Chapter 2 of the z/OS
    MVS Initialization and Tuning Guide provides guidelines for
    sizing page data sets.
    
    2. DFSORT determines the amount of storage that is available for
    its use.  Included in this amount are old pages eligible to be
    stolen.  The amount of pages that can be stolen can be
    significant in an environment with a large central storage
    configuration.  When those pages are stolen from other address
    spaces, they get paged out immediately to Auxiliary Storage and
    can cause a shortage if the paging subsystem is not sized
    adequately.  Even if they don't cause an AUX storage shortage,
    they can still cause excessive paging which impacts performance.
    The following DFSORT installation defaults should be changed to
    prevent auxilary storage shortage or excessive paging:
    
    a) Set EXPOLD=0, if you do not know if your paging subsystem is
    large enough to support an increased amount of page outs from
    central storage.  In this way you can ensure that pages are not
    stolen from other address spaces to be used by DFSORT Hiperspace
    or Memory Object sorting. You can then monitor your page data
    set usage and paging activity with RMF to determine if you can
    increase EXPOLD.  Note that this option may have a negative
    impact on sort elapsed times since it will limit the resources
    DFSORT considers available for Hiperspace and Memory Object
    sorting. Note 'n' in the following recommendations is not the
    same value in all instances:
    
    b) Set EXPOLD=n or n%, if you believe your paging subsystem is
    adequately sized to allow a limited amount of pages to be
    stolen by DFSORT.
    
    3.  Set DSPSIZE=n, where the installation default of n is a
    relatively small number (128 to 256MB).  Since now Hiperspace
    and Dataspace will be using the same resources where as before
    Hiperspace was backed by expanded storage and Dataspace was
    backed by central storage, a general recommendation is to
    reduce the maximum size of dataspaces that can be created.
    Hiperspace (and Memory Object in V1R5) will be the primary
    method for placing sortwork in memory and Dataspace will
    serve as an extension of main storage for sorts too large to
    benefit from Hiperspace or Memory Object.
    
    4) Set EXPRES=n or n%, if you wish to keep a fixed amount of
    storage available for an unexpected need such as new workload
    entering the system or a large dump consuming resources.
    When DFSORT evaluates available storage, it will take in to
    consideration the EXPRES value and make the appropriate
    adjustment in its determination of available storage.
    
    5) Set EXPMAX=n or n%, to limit DFSORT's storage use for
    Hiperspace or Memory Object sorting.  Even when the system is
    not very busy, you may want to limit DFSORT's storage usage.
    This will help prevent situations where a long running sort
    holds storage resources that may be needed by new work entering
    the system later.  Note, that this recommendations only limits
    DFSORT's usage.  The sum total of storage used by DFSORT and
    other address spaces can exceed EXPMAX depending on the values
    in effect for EXPRES and EXPOLD.
    
    6) The JCL coded SORTWKs may no longer be large enough to
    complete the sort or the installation DYNSPC default may not
    be large enough for unknown file size conditions and error
    messages (for example, ICE046A and ICE083A) may occur due to
    less hiperspace being used.  Using dynamic allocaItion is
    recommended with a large enough installation default specified
    for DYNSPC.  If you have JCL coded SORTWKs and you want them
    ignored, then use the installation default of DYNAUTO=IGNWKDD.
    Other installation defaults associated with hiperspace can be
    left unchanged and use the DFSORT shipped values.
    
    After considering the above recommendations and making the
    appropriate changes, dramatic increases in paging activity,
    auxiliary storage shortages and etc. should be reported to
    IBM and investigated. Reference:
    
      DFSORT Installation and Customization (SC33-4034)
      DFSORT Tuning Guide (SC26-3111)
    
    regarding above options and recommendations.
    
    The following DFSORT PTFs are recommended for the indicated
    areas of function in DFSORT R14:
    
    Hiperspace:   64-Bit:    64-Bit and Hiperspace:
    UQ52227       UQ49424    UQ70873
    UQ54399       UQ61964
    UQ57879
    UQ61505
    
    The above service is not required in DFSORT V1R5 because it is
    already in the base. The non-DFSORT PTFs for APAR OW57718 and
    OA02117 must be applied. Without them, you may encounter central
    storage over utilization by DFSORT or any other applications
    that query the system for available storage.
    

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

  • This info apar is being closed so it is searchable
    by customers.
    

APAR Information

  • APAR number

    II13495

  • Reported component name

    PA LIB INFO ITE

  • Reported component ID

    INFOPALIB

  • Reported release

    001

  • Status

    CLOSED CAN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2003-01-06

  • Closed date

    2006-08-17

  • Last modified date

    2008-10-02

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"z\/OS Communications Server"},"Platform":[{"code":"PF054","label":"z Systems"}],"Version":"001"}]

Document Information

Modified date:
23 January 2023