IBM Mainframe Forum

I noticed my current shop widely uses the LE runtime storage option to set the heap_free_value to 00, so storage is re-initialized when it is freed. I'm trying to convince them that we do not need to use that here. (I don't work for the NSA.)

Is there any valid reason to initialize storage to 00's when it is freed?

Dave

In other words, your shop is using something like



It could have been worse (setting ?2 to anything other than NONE is a recipe for humongous CPU usage) , but if you regularly allocate and free large amounts of heap storage it definitely is not good.

I don't know what language you're using, but if it's PL/I, declare your data-to-be-allocated-on-the-heap with "INIT (whatever)" and you'll be much better off!

I had to go to the LE manual since I rarely gert involved with LE. I pretty much agree with prino. There is a cost to setting any of the first three parameters to something other than NONE. How much depends on both the software and hardware. The primary advantage is in debugging. If you suddenly find your storage set to the value set when freeing storage, you know something got rather too enthusiastic about freeing storage. I see less value in the other two, but there might be value. MVS will set any newly allocated storage greater than 8K to binary 0; less than 8K might not be set to 0. Some of this depends on the details of how LE manages "heap" and "stack" storage, something that is not necessarily well documented. I went back to the LE documentation, and I didn't see anything that jumped out to me, though I didn't look very hard.

Whilst there may the type of advantage pointed out by Mr Myers in a testing environment, the only reason I can think of outside of that is the one you hint at yourself, security of data. However, it would be a bit of a blundebuss to do it that way rather than clobbering sensitive fields before exiting from a program.

Best for all of those three values to be NONE unless you have a very specific local reason for something else.

However, don't just go changing the first one blindly. If it is set to other than NONE and you set it to NONE, any code which is accidentally relying on a particular initial value will become wrong. Even possible to have different behaviour going the other way (although it would be more of "regular" false behaviour in place of intermittent).

Thanks all for the quick responses. A contact of mine also sent me an answer that I thought I'd post here for future reference. Basically it is the debugging point of view that you all mentioned.

"In researching the "heap_free_value" it appears that its main purpose in debugging. From the manual, "zOS RAS Guidelines and Debug Guide for Ported Software" it says:

Detecting the storing of data into freed storage.
When using the heapchk function, the use of HEAPCHK(ON,delay,frequency) with
STORAGE(,heap_free_value) results in checking the free areas of the heap. LE sets the storage area to a repeating value of choice, like hex ‘FF’. If your program stores into a free area, an error is signaled. The intent is to ensure that the freed storage areas contain the “free value” in them and to verify that your program frees the correct storage area.

So if you have debugging issues then it is worthwhile to turn on along with HEAPCHK. Otherwise, I don't see the need unless you are paranoid about things like the NSA."

Also, I only plan on setting the Heap_free_value to NONE. We have some bad programs here that need the storage initialized to 00, so I'll leave that parm as is. (because getting the applications folks to actually fix their code is not going to happen...)