GnuCOBOL

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.

libicu is already included in the build system.

Expected outcome

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.

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.

Started: Java interoperability from/to COBOL modules

Available as either one 90 and one 175 hour, or one 350 hour task, difficulty medium to 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 finishing the implementation of the COBOL extensions to the CALL statement (as started with last GSOC2024), as well as JAVA-CALLABLE and JAVA-SHAREABLE directive to allow this interaction with using the JNI.

Expected outcome

Cleanup of addition of Java interface libraries to the build system (autoconf/automake/conditional compilation).

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 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.