GnuCOBOL

Java interoperability from/to COBOL modules

Available as two 175 hour or one 350 hour task, difficulty hard
Skills: C is necessary
knowledge of JNI, COBOL and autotools is useful but not mandatory

Desc

COBOL calling into Java functions is often useful interfacing with external "java-only" libraries and modernization projects; calling well-tested COBOL modules from Java is often useful for modernization projects as well as new software.

This project is about implementing the COBOL extensions to the CALL statement, as well as JAVA-CALLABLE and JAVA-SHAREABLE directive to allow this interaction with using the JNI.

Expected outcome

Addition of Java interface libraries to the build system (autoconf/automake/conditional compilation) using the same approach as with other libraries, for example libxml.

Support for CALL 'Java.java-class-name.java-static-method-name' and necessary parameter mapping.

For more hours support for generation of Java wrappers and a minimal java library to provide access to COBOL fields and programs.

Implement XML PARSE in GnuCOBOL using libxml2

Aprox. 90 hours, difficulty medium
Skills: C is necessary
knowledge of COBOL, libxml2 and autotest is useful but not mandatory

Desc

XML handling is an extension to standard COBOL. The "common extension" is IBM's XML GENERATE and XML PARSE. IBM documentation can be used for a detailed explanation and some examples.
Supporting this both improves a possible migration path from environments that currently use it and provides a needed modern feature in COBOL.
Both are implemented in the compiler, but the first is missing in the runtime, which is to be added in this GSOC project.
For this libxml2 (already linked in libcob) is to be used in "stream" mode.

Expected outcome

Testsuite additions (autotest) with COBOL samples; if time permits those are to be later tweaked for coverage.
Use of libxml2 functions in libcob/mlio.c to implement the features; currently all related functions are only stubs that return an error.

Implement internal calling of EXEC preprocessors

Aprox. 90 hours, difficulty easy
Skills: basic C and bison/flex knowledge is necessary

Desc

COBOL sources often contain "foreign" embedded code. The standard way of doing this is to surround this in EXEC lang ... END-EXEC blocks. Variables may be shared by marking them within the blocks. The most common is EXEC SQL.
Those blocks are commonly handled by a preprocessor that generates COBOL code. Those preprocessors therefore need to be manually called and their output be feed into cobc, message handled separately, ...
This project is about providing "embedded" calls to the matching preprocessor from cobc, for details see FR #341.

Expected outcome

Adjustment in the preparsing/parsing steps as noted in FR #341.
Adjustment to call the external defined programs (reading configuration using existing code) and preprocess multiple times until all different EXEC LANG are handled.
If time permits: add sample definitions for EXEC SQL preprocessors ocesql, esqloc, gixsql.

add source encoding and literal conversion to the GnuCOBOL compiler using libicu

Aprox. 90 hours, difficulty medium
Skills: C is necessary
knowledge of COBOL, flex, libicu and autotools is useful but not mandatory

Desc

COBOL source files may use different encodings. Commonly these use some 8-bit character encoding like ISO-8859-15 or an EBCDIC one "transferred as binary from the Mainframe". Newer sources are often written in UTF-8, which can produce challenges for user-defined words and literals stored as single-byte characters.

This project is about adding support in the compiler for source files with different encodings and to internally convert literals between those and UTF8/UTF16/UTF32 stored as byte-arrays using libicu.

Expected outcome

Addition of libicu to the build system (autoconf/automake/conditional compilation) using the same approach as with other libraries, for example libxml2.
Adjustments as needed to handle user-defined names in UTF8 in the scanner (flex).
Internal conversion of literals, verified in the testsuite.
Testsuite additions to verify correct conversion of literals.

Implement UTF-8 Datatype in GnuCOBOL and conversion to/from UTF-16/UTF-32 via libicu

Available as either 175 hour or 350 hour task, difficulty hard
Skills: C and COBOL are necessary
knowledge of libicu and autotools is useful but not mandatory

Desc

COBOL uses fixed-length data storage, with common options "single byte" PIC X and multibyte (UTF-16 or UTF-32, so 2 or 4 byte) PIC N, where the amount of characters is specified.

PIC U for UTF-8 XML handling is relative new in COBOL and allows to specify the storage by either byte-length or character size.

Both PIC N and PIC U are only partially implemented in GnuCOBOL so far.

Expected outcome

Addition of libicu to the build system (autoconf/automake/conditional compilation) using the same approach as with other libraries, for example libxml.
Extend the testsuite to check all COBOL statements with these types. To do so duplicate the existing tests that use PIC X and replace those with PIC U and/or PIC N.
Implementation of handling those types in the runtime, at least for reference-modification (substring by character position) and the COBOL statements STRING/UNSTRING, MOVE and comparisons (doing internal conversions to UTF-8 from PIC N and PIC X).

For more hours also INSPECT, XML GENERATE, ACCEPT/DISPLAY with a high code-coverage.