Uri Guttman wrote:
... DE> Yes, run-time libraries are included. They are written in C.
DE> Generally, both OC and TC generate inline code for program flow
DE> control. The RTL are used mostly for type conversions, system calls
DE> and such.
then the question is how hard would it be to retarget from c to parrot?
the code generation will be very different (c is relatively easy to
generate especially for rtl calls).
I'm not sufficiently familiar with 'parrot' to offer an opinion.
As a TC developer, my postings were intended only to offer some advice, on some the issues, and I covered only a few, specific to COBOL.
DE> For ISAM support both TC and OC use Berkeley's DB (now DE> Sleepyc*t). While functional, ISAM support has not been fully DE> tested. Nor does it meet the ISAM standard.
we wrote our own b-tree for isam as well as all the rest of the voluminous rtl for pl1. c-isam would be a commercial possibility (are they still around?). i thought sleepycat did hash indexes only and btrees are really what is needed for isam.
BDB does have a btree (btree+ I think).
The only problems are that BDB stores data and indexes in the same file, and secondary indexes create multiple files.
To complicate matters, as of version 2, BDB changed it's license from BSD to an open but proprietary license.
I think that C-IS*M is now owned by I*M.
DE> Finally, while TC has a primitive transaction processor, DE> concurrency issues have not been addressed.
hmm, pl1 didn't have transactions IIRC. i forgot (never did learn real cobol) that cobol did. that would be hard to support without major help in the isam lib. if you really want to support real cobol in parrot to handle all that legacy code, this will need to be addressed. but there is a good commercial market for this (there is so much legacy cobol out there and it can't be ported to other cpus) so maybe someone can make a biz out of this.
Concurrency is not an issue specific to COBOL.
Generally these issues are addressed by using an SQL engine, or by using a commercial transaction processor.
COBOL does support embedded SQL, so one could migrate the applications to an SQL database.
Transaction processors on the oder hand are very expensive, 10K US and up. AFAIK the are no open source TP available.
