By "heap pool" are you referring to using CEECRHP to create additional LE heaps? I am doing that upon creation of the first "dynamic table" within a program. (Just using the defaults of 0 for each of the CEECRHP parameters at the moment.) Are you thinking it might make sense to use a separate heap for each table? I have no idea what phi is (I took neither Greek nor higher mathematics), but I'll take a look at it.
I personally would like COBOL to have most of those "collection classes" you refer to. But I'm not sure how user friendly these ILCs wrappers you refer to would be. Feel free to develop them, though! :-) We don't have access to the C/C++ compiler, and thus I will not be playing around with that. Frank ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of David Crayford <[email protected]> Sent: Monday, August 8, 2016 5:49 AM To: [email protected] Subject: Re: COBOL 2014 dynamic capacity tables On 5/08/2016 11:11 PM, Frank Swarbrick wrote: > That's good to know. I searched the internet and found a page about > implementing dynamic arrays in C and he was using "double", but 1.5 also > sounds reasonable. I wonder if perhaps there should be some sort of > ratcheting down as the number of rows gets very large. The C++ runtime library on z/OS is a commercial offering from Dinkumware. Interestingly they use phi as the growth factor. A lot of the choices seem to be based on the properties of the memory allocator. Modern allocators, including z/OS LE are configurable, so if you plan to use a growth factor of 2 then you should look into using heap pools. I have to admire what you're doing. I used to be application programmer a long time ago and COBOL seriously lacks collection classes that we take for granted in modern languages. It would be trivial to write a thin ILC wrapper around the C++ STL to enable COBOL to use the C++ container classes like vectors, linked lists, heaps, stacks, queues, maps and hash maps. I'm not sure how much demand there seems to be for that on the mainframe though. > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > David Crayford <[email protected]> > Sent: Thursday, August 4, 2016 8:41 PM > To: [email protected] > Subject: Re: COBOL 2014 dynamic capacity tables > > On 4/08/2016 2:52 AM, Frank Swarbrick wrote: >> Even in the case where it does increase the actual allocated capacity, it >> does not do it "one row at a time". Rather, it doubles the current physical >> capacity and "reallocates" (using CEECZST) the storage to the new value. >> This may or may not actually cause LE storage control to reallocate out of a >> different area (copying the existing data from the old allocated area). If >> there is enough room already it does nothing except increase the amount >> reserved for your allocation. And even then, LE has already allocated a >> probably larger area prior to this from actual OS storage, depending on the >> values in the HEAP runtime option. > Almost all the dynamic array implementations that I'm aware of, C++ > std::vector, Java ArrayList, Python lists, Lua tables, use a growth > factor of 1.5. Apparently it's a golden ratio. > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
