________________________________
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
