Neither here nor there, but I did not know that C++ enums could have non-numeric values! Are they limited to a single character? Just wondering...
________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of David Crayford <[email protected]> Sent: Monday, August 8, 2016 9:01 PM To: [email protected] Subject: Re: COBOL 2014 dynamic capacity tables On 9/08/2016 12:36 AM, Farley, Peter x23353 wrote: > 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. #pragma linkage(...,fetchable) takes care of the ILC linkage. LE will dynamically load the C++ module and use the same LE environment for both the COBOL and the C++ program. I've done this before for ILC calls between HLASM->C++ and it works well. It's very fast, the call overhead is just a few instructions in the FECB glue code. I wrote a test with a COBOL main that calls a C++ subroutine 10,000,000 times. It ran in 01.33 CPU seconds, roughly the same as C++ calling a statically linked C++ routine. identification division. program-id. cobilc. data division. working-storage section. 01 set-module-name pic x(08) value "PCOLSET ". procedure division. perform 10000000 times call set-module-name end-perform goback. #pragma linkage(PCOLSET,fetchable) extern "C" int PCOLSET() { return 0; } HTRT01I CPU (Total) Elapsed CPU (TCB) CPU (SRB) Service HTRT02I Jobname Stepname ProcStep RC I/O hh:mm:ss.th hh:mm:ss.th hh:mm:ss.th hh:mm:ss.th Units HTRT03I COBILC C 00 73 01.33 02.24 01.33 00.00 29549 > And probably impossible for any RTL routine that requires POSIX ON, though I > don't suppose the data collection routines fall into that category. One of my colleagues wrote a POSIX(ON) COBOL program a few weeks ago. It uses the new callable services for HTTP web services and POSIX(ON) is a requirement. No problems. > 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. :) From what I can tell it would be quite easy. It's simple to write a C++ module to wrap an STL container. I would design it to take one argument, a COBOL record (C struct) list with a request type, the set handle and a record buffer. For example, for a dictionary (std::set) NEW, TERM, INSERT, FIND, REPLACE, DELETE etc. I would store records in the set as C++ strings to simplify memory management and write a custom comparator function for comparing keys. One constraint would be that record keys must be fixed length, but this is COBOL right so that's nothing new. Excuse my COBOL, it's been a while but something like this which would have a C/C++ structure mapping in the API. 01 stl-set. 05 stl-set-token pic x(4) value low-values. 05 stl-set-method pic x. 88 stl-set-method-new value 'N'. 88 stl-set-method-insert value 'I'. 88 stl-set-method-find value 'F'. 88 stl-set-method-update value 'U'. 88 stl-set-method-delete value 'D'. 88 stl-set-method-term value 'T'. 05 stl-set-key-length pic 9(8) binary. 05 stl-set-rec-length pic 9(8) binary. 05 stl-set-rec-ptr pointer. struct stl_set { void * token; // ptr to std::set instance enum // request type { method_new = 'N', // - create a new set method_insert = 'I', // - insert a record method_find = 'F', // - find a record method_update = 'U', // - update a record method_delete = 'D', // - delete a record method_term = 'T' // - destroy the set } method; size_t keylen; // [input] the fixed key length size_t reclen; // [in/out] the record length void * rec; // [in/out] the record buffer } > 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 ---------------------------------------------------------------------- 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
