13.6 realloc() optimization As a string manipulation intensive application you need improved performance when using realloc() to grow the storage for the strings so that your application is not slowed down copying page after page of memory, and you need a mechanism for controlling that optimization. In z/OS V1R12, IBM provides the new environment variable _CEE_REALLOC_CONTROL that accepts two parameters: The first parameter sets a lower boundary for particular storage sizes for which a realloc() or CEECZST call may be requested. The second provides a percentage to increase the requested storage size when the lower boundary is exceeded. In this way, subsequent realloc() attempts may fit within the bounds of the previously requested storage and not require a new storage allocation and copy to occur. The syntax of the environment variable is: _CEE_REALLOC_CONTROL=bound, percentage If the variable is in effect, storage allocation is handled in the following way. For instance, if an application issues a malloc() to request storage and a subsequent realloc() to change the size of that storage allocation, this first parameter will determine whether the request will be increased with the intent that subsequent reallocations will not require that additional storage be obtained and data copied. Note: The default is indicated by a percentage of 0, which will mean the feature is not in use. Example scenario Assume in the following example that the variable is set to: _CEE_REALLOC_CONTROL=100,20. If a realloc() request is for greater than 100 bytes, increase that request by 20%, as follows: 1. A malloc() request for 100 bytes. 2. A realloc() request for 110 bytes. Greater than lower bounds, so increase request by 20%. The calculated amount of storage is now 110 + 110*0.20 = 132 bytes. Buffer is copied to a new location. 3. A realloc() request for 120 bytes. Fits in currently allocated buffer, no copy needed. 4. A realloc() request for 130 bytes. Continues to fit in the currently allocated buffer, no copy needed. With the support turned off in the above example, it would result in four separate allocations being performed and three copies of data to the new allocation. With the support turned on as above, two allocations will occur and one copy of data would result. 13.7 VSAM EA support for KSDS AIX for C/C++ Older releases of z/OS DFSMS have long supported VSAM data sets that can exceed 4 GB in size. The z/OS XL C/C++ Run-time Library has supported these data sets since z/OS V1R8, but it did not support KSDS alternate indexes. In z/OS V1R12, the z/OS XL C/C++ Chapter 13. Language Environment 255