From: David E. <de...@us...> - 2007-12-23 01:06:25
|
Reg wrote: > After messing around with various alternatives, > I decided that passing multiple large linkage > parameters from program to program was too flakey, > so now write them to a file and read them with > single programs each compiled with -x and running > separately. > Works fine, segmentation errors gone. I do not understand what kind of problem you have encountered, or what you mean by 'large linkage parameters' (100KB, 1MB). In any case, if you are passing the linkage parameters BY REFERENCE, which is the default, you are only passing a pointer (4 bytes on 32bit systems). I ran some tests using both the '-x' and '-m' options, but I did not encounter any problems. > Problem now is that lockserver doesn't work. > Set lockserver running in -d mode, comes up with > messages ending with "Server socket set-up" so > seems to be running fine. > Re-did Tiny Cobol config in development directory > with --enable-lockserv, make, make install. > Seems to completely ignore the option. No reference > to it in config.log, compiler chucks out error > message on encountering "unlock" (undefined reference > to tcob_unlock), no locking taking place on "read with > lock" according to lockserver debug, no lock (status 51) > encountered when expected in programs.. > What am I doing wrong? Well 'lockserver' is not currently supported by the run-time. If you run './configure --help' you will notice that it is no longer an option. I had planned to replace 'lockserver' with 'MONTSUQI'(1). It is a small transaction monitor which, according to the web site, works with OC. Except for 'lockserver', file LOCKS were badly implemented on TC, for the following reasons. 1) File LOCKS are not defined in the COBOL-85 standard. 2) Inconsistent behavior between different file types. 3) File LOCKS (flock) are not supported by the BDB 185 API. ... There are more reasons, but suffice it to say that some sort of transaction server would be the best way to ensure data integrity. In any case, I had no plans to support file LOCKS considering the above reasons. I will reconsider support for file LOCKS for indexed file types only, using either 'lockserver' or 'MONTSUQI'. But first I need to finish what I started, run-time support for SORT. So it may be a while before I can look at the code. > PS Sorry to hear that you intend to "retire" from the > TC project next year, but I guess you have done more > than your share........ I for one am grateful for your > efforts. IMHO, except for the SCREEN (ACCEPT/DISPLAY) IO code and being Win32 friendly, OC has surpassed TC. So I don't see the benefit of developing two COBOL compilers. Cheers 1) MONTSUQI (Panda) - transaction monitor http://www.nurs.or.jp/~ogochan/panda/ |