IMHO, this kind of behaviour MUST have to do with some logic inside the application, which allocates storage dynamically and reacts on "short on storage" conditions from LE (aka language environment) - which is the runtime for all compiled languages today.
Storage consumption by LE is controlled by HEAP and STACK parameters, which define primary and secondary extent sizes and where the storage is taken from (BELOW/ABOVE) - very short description. See more details here: http://www-03.ibm.com/systems/resources/Stack+and+Heap.pdf I saw large CPU consumption in the past, but most of the time due to very bad LE options (small extent sizes, leading to many small storage alloc and free requests) - or, when LE is working near the short on storage condition, but then we had an error in the end, normally. FWIW: I wrote a routine that can be called on the fly and monitors the usage of dynamic storage (it does some sort of bookkeeping, based on the LE control blocks and tells, which areas have been allocated and not freed between two control points of an application). My customers used this very successfully to detect memory leaks in their applications (C, C++, even PL/1). If you are interested, contact me offline. And: I rewrote the LE storage management, based on the description above, using the Pascal language - for the use in the Hercules environment (for MVS and CMS). Look here: http://bernd-oppolzer.de/job9k14.htm Kind regards Bernd Am 25.07.2017 um 18:28 schrieb Charles Mills:
Not a huge expert but I do a certain amount of tuning of storage requirements as the developer of a vendor product, and I have the distinct impression that LE's initial program runtime storage parameters are fixed at either compile or startup time and based on supplied parameters, independent of the actual region size. That is, there is no algorithm like "get half the free storage." It is "get X bytes." Of course, region size affects the possibility of an x78 failure if the program requires more storage than initially obtained. I notice the OP, who was posting hourly or so, has gone quiet. Perhaps the problem has been located. Charles
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
