joakim.jalap@xxxxxxxxxxxx wrote:
> Hi all!
>
> Sorry to hijack this thread, but I've been looking to get into gnu cobol
> for a while, and this seems like it might be a reasonable place to
> start. Or would it be very hard?
>
> My employer has already signed my fsf papers for emacs, so it wouldnt be
> a problem to get them to sign thlse for gnu cobol as well.
>
> Could somebody point me to a good place to start my ivestigation into
> this? :)
>
> Joakim
Will try, Joakim. Yayys.
The compiler is mainly split in cobc/ and libcob/ directories, (there
are more, but because of your introduction, I'm going to assume a few
things about your background with autotools and libtool setups).
In libcob/ there is system.def, this is the main header with string name
to C function name for the stock library. The entry points are usually
found in the libcob/*.c files. A grep (or silver-searcher ag) pass is
usually the best way to find where the sources are.
As a for instance, starting in libcob/system.def
COB_SYSTEM_GEN ("C$MAKEDIR", 1, cob_sys_mkdir)
$ ag cob_sys_mkdir
libcob/common.h
1594:COB_EXPIMP int cob_sys_mkdir (unsigned char *);
libcob/system.def
66:COB_SYSTEM_GEN ("C$MAKEDIR", 1, cob_sys_mkdir)
libcob/fileio.c
5437:cob_sys_mkdir (unsigned char *dir)
Declaration in libcob/common.h, definition in libcob/fileio.c
I'll let you look at the code instead of posting it here.
These C$... are extensions supported by other compilers, so usually you
need to bing the google with COBOL <extension> to get hints on the COBOL
version of the API documentation. Refining the search with vendor often
helps. AcuCOBOL in this case. Micro Focus or RMCOBOL for the x"91".
GnuCOBOL supports quite a few dialects, and the more the better.
Same kind of grep through the tests/ directory should get you up to
speed on the autotest set up required (and as you may have noticed,
C$MAKEDIR doesn't have a test, and that's a shortcoming). Simon prefers
accepting code that already have tests, and these tests are more
important now that development is a shared exercise.
And that's about it for entry. You'll pretty much see the coding style
when looking at source code, Roger While was a world class developer,
and very consistent. These stock library functions are aimed to
support, POSIX first, then as many other operating systems as feasible.
OS/400, System 390, (meaning big/little endian support is a must for any
features written in C), HPUX and on and on, and although we try and urge
people to the better side of life, many COBOL programmers use Windows,
so...)
Once you feel comfortable and think you'd like to continue with
GnuCOBOL, drop a note on SourceForge, in the Contributions group and
Simon will set you up with write access to the tree.
Simon is hard at work on the GnuCOBOL 2.0 rc-1 release, so he may or may
not want new code in the source tree under branches/gnu-cobol-2.0/ but
go ahead and do experiments in the 1.1x branch as it's the experimental
branch and being compatible with 1.1 is always a good thing (though
hopefully soon a less important requirement once 2.0 gets into the wild
and is elevated to trunk to we can finally focus on merging in the
reportwriter branch). This is COBOL, so we're all pretty used to things
changing slowly, while at the same time, get antsy. :-)
After that, I'll go and brag about your new entries, in the
documentation and all about the internet. :-)
Feel free to ask for more details.
Cheers, and have good, Joakim
Brian
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
open-cobol-list mailing list
open-cobol-list@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
