David, Not so easy to write as you might think. The COBOL LE environment and the C/C++ LE environment are very different. Calling C/C++ runtime routines (other than the Metal C ones resident in the system, but even some of those require some memory-allocation initialization) requires that the C/C++ RTL environment be set up, but you do not want to do that for every call, so you have to have at least a name/token pair to save the (created once) C/C++ environment.
And probably impossible for any RTL routine that requires POSIX ON, though I don't suppose the data collection routines fall into that category. I investigated this once upon a time and decided that with the amount of work required, it would probably be better to wait for IBM to provide it. Maybe COBOL V6++ will do that. :) Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of David Crayford Sent: Monday, August 08, 2016 7: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. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
