Bill,thanks for your answer. I concur with everything you wrote. I don't know what they intended to do with this if it was available. I doubt they want to do their own storage management. I seem to remember they talked about "statistics" or "bookkeeping", but I'll have to ask for more details. Anyway, I will not suggest to learn this information by scanning undocumented control blocks. It is too dangerous for production use. They will need to keep that information, if realLy required, in their own data. They already keep all kinds of things around.
-- Peter Hunkeler Von: Bill Woodger <[email protected]> An: [email protected] Betreff: Interface to query length of storage allocated with CEEGTST LE service Datum: 23.07.16, 12:47 There is some evidence that the "control information" is stored in the heap itself (see the Usage Notes for "CEEFRST—Free heap storage") and by implication associated directly with the storage allocated. However, it is not documented, and working it out through inspection would be pointless beyond simple interest, as you know. I still can't work out *why* it is wanted. I think some detail on that would help. Generally it won't. be. Specifically it could be See if they can read through this and explain LE heaps back to you correctly. There may be assumptions being made that "storage management" of some type is needed, when probably it isn't. Note, you could ask for a very small amount of storage and if new storage has to be obtained from the OS, an entire "increment" will arrive. So what? Other heap storage requests can be served from that. If there is (genuine) concern about freeing storage (to the enclave or to the OS) it can be done, and even (using FILL) an increment which could otherwise be unavailable due to "fragmentation" can be dealt with. If necessary. For performance *don't release storage to the OS that may be needed again*. Unless you really need to. Really need to, means really need to, not just "I think it would be good to do that, because I always do that in my smartphone app". Don't apply non-z/OS concepts to z/OS. Unless they happen to work, but you have to know. You have to know your application, and how z/OS, LE, and whatever else, are doing things. If the code is all C/C++, there is the chance you write your own, presumably optimised, heap management - see Vendor Heap Management. You can't do everything there, and it is not a way to manage what LE sets up (you have to do everything yourself) so doesn't answer the original question by providing some "map", but if they really, really need to manager their own storage, it is a possibility. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
