Relocate Cross System Extended Services (XES) component trace buffers

Description

In z/OS V2R2, the Cross System Extended Services (XES) buffers for component tracing are moved from a common area data space (CADS) to a 4 GB memory object in 64-bit common high virtual (HVCOMMON) storage. During system initialization, XES obtains a 4 GB memory object and manages the virtual storage for global and connection CTRACE buffers. This change allows the GLOBAL trace buffer to be increased from 16 MB to 32 MB (fixed), which reduces the possibility of buffer wrapping. It also increases the available address range for connector trace buffers, which decreases the possibility of a connector running without component tracing.

In previous releases, the XES CTRACE buffers resided in a CADS object named IXLCTCAD, which limited the buffers to a 2 GB range of addresses. In z/OS V2R2, XES no longer creates the IXLCTCAD object.

Notes:
  1. The 4 GB memory object is a fixed size area that is obtained by XES; the size cannot be modified.
  2. The IXLCBCAD object is not affected by this migration action.

Table 1 provides more details about the migration action. Use this information to plan your changes to the system.

Table 1. Information about this migration action
Element or feature: BCP.
When change was introduced: z/OS V2R2.
Applies to migration from: z/OS V2R1 and z/OS V1R13.
Timing: Before the first IPL of z/OS V2R2.
Is the migration action required? Yes, if you use coupling facilities in your sysplex or have references to the XES CTRACE CADS ('IXLCTCAD') on the DSPNAME parameter of the DUMP and SLIP commands or in automated parse routines.
Target system hardware requirements: None.
Target system software requirements: None.
Other system (coexistence or fallback) requirements: None.
Restrictions: None.
System impacts: Eliminating the XES CADS decreases the number of common area data spaces that are created in the system.
Related IBM® Health Checker for z/OS® check: None.

Steps to take

Follow these steps:
  • Ensure that enough 64-bit common storage (HVCOMMON) storage is allocated by the system, so that the additional 4 GB request by XES does not cause shortages for other components and elements. The amount of 64-bit common storage is controlled by the HVCOMMON parameter in the IEASYSxx parmlib member. Review the value that is specified on the HVCOMMON parameter to determine whether it must be increased. You can use the MVS operator command D VIRTSTOR,HVCOMMON to display information about the current use of the HVCOMMON storage on your system.
    For example: 
    IAR019I 06.55.51 DISPLAY VIRTSTOR
SOURCE = DEFAULT
TOTAL 64-BIT COMMON = 66G
64-BIT COMMON RANGE = 1982G-2048G
64-BIT COMMON ALLOCATED = 4171M
  • To accommodate the allocation of a 4 GB XES CTRACE buffer, add 4 gigabytes (4G) to the HVCOMMON value in the IEASYSxx parmlib member.
  • Check for references to the IXLCTCAD object, which is no longer created in z/OS V2R2. Specifically, check for references to 'IXLCTCAD' on the DSPNAME parameter of the DUMP and SLIP commands (that is, DSPNAME=('XCFAS'.IXLCTCAD)) and on any automated parse routines.
  • Ensure that SDATA=XESDATA is specified on any DUMP or SLIP commands where the IXLCTCAD name was removed. This setting causes the XES CTRACE 64-bit common storage to be included in an SVC dump.

Failure to remove the IXLCTCAD references can result in an error message, such as ASA104. This error, however, does not stop the running process.

If XES cannot obtain a 4 GB memory object, message IXL017I is issued. The system continues to process XES requests normally, but SYSXES CTRACE data is not be available in dumps for analysis under IPCS.

Reference information

For more information, see the following references:
Parent topic: BCP actions to perform before the first IPL of z/OS V2R2