[open-cobol-list] I want to create community code, not another island

[Patrick]

Hi Everyone

I've received so much help since January when I started with Cobol.

I still have lots to learn but I think I know enough now to get my main 
project under-way in Cobol(with C++ front end), in pertains to 
controlling scientific instruments.

I have been reading up and tinkering with termios on Linux and reading 
about dcb on windows. i am going to try to make a cross platform serial 
port library now. After that I am going to work on socket and winsock to 
create a cross platform socket library. After this I may be working with 
XML, OpenGL, Imagemagick, sqlite and others. I've decided that I will 
have to limp along for a year or two and use C++ and QT as a front end 
but I would really like to use a full Cobol gui binding and maybe a 
couple years from now I will try to tackle this.

I hope I won't upset anyone with an editorial, please don't get mad, 
it's motivated by the desire to help....

Cobol is so neat and there is supposed to be so much of it written but 
it seems that most Cobol people have not formed communities like ours 
and Governments and companies have used it to create codebase "islands". 
There are minimal tools to share code between unknown parties and things 
are worse with C. Sure we can use call statements but so many of them 
are required to make a binding and I don't see any standard way to 
organize them for use by unrelated parties later. It seems like Cobol 
has done very well in the business world but never really branched into 
other fields. Everything you need for business is built in but it just 
does not have "import" from python, "with" from Ada or some other 
keyword to bring in C code in a tidy way.

I know there will be user defined functions one day but we don't really 
have a lead developer right now. I want to help but it's kind of like 
the student writing the text books for the teachers right now. My C/C++ 
is really ramping up but it will still be several months before I can 
contribute anything and then, will I have time to create the mechanisms 
that I wish were there, probably not.

I have been toying with the idea of a super procedure as a module to be 
shared.

I think I have a working format but I don't have to ask anyone if they 
will like it, I know it will be totally unacceptable to the community as 
it's more like forth then cobol.

So one piece of equipment I need to control mixes four different 
solvents. It mixes them in different proportions over time, creating a 
solvent gradient.

So if I had a table that had 5 fields, time, solvent A, B, C D, I could 
send a strings to each record like:

1.00 25 35 35 15
2.00 10 10 10 70
3.00 25 25 25 25


However there are many other things that need to be controlled with this 
instrument like pumping flow rate and helium mixing.

I will need to create procedures for each of these other topics but I 
would like each to be a sub-procedure contained within a super procedure.

Right now I am playing with a scheme that would work like this:

A single string would be sent to the super procedure.  Inside the super 
procedure, a stack manager would examine the string and see if it is 
data and if so, it would push it on the stack. Later another call would 
be sent containing the name of a sub-procedure. The stack manager would 
see it it as the name of a procedure and not data and it would call it 
passing the previous value on the stack with it. The sub-procedure would 
then take the string from the stack, split it and move it into a record 
and then use it in a conventional manner.

I was thinking that the stack manager could take chunks of strings like 
this:


1.00 25 35 35 15 !!
2.00 10 10 10 70 !!
3.00 25 25 25 25 ;;
gradient ;;

and process them spiting tokens on ;; and the sub-procedures would then 
split on !!

I bet this will work but there is no way that anyone else would want to 
use this.

Can anyone help me come up with a scheme that is more cobol-like?

My idea is crazy looking but it would also allow the super procedure to 
be entirely coded in C or another language, I think this is critical. 
The library code does not need to be cobol. It would save a lot of 
trouble if the super procedure was useable from Cobol but written in C.

If there was some format that we could all(or most of us) agree on, it 
could become the basis for sharing code(at least in the interim) and not 
just cobol code but code that is or binds to C

Thanks for reading this long email-Patrick