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
Dave Betten and Vicky Vezinaw ([email protected] and [email protected])
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