5RMC CodeBridge UG
5RMC CodeBridge UG
RM/COBOL
The only warranties for products and services of Micro Focus and its affiliates and licensors (“Micro Focus”) are as
may be set forth in the express warranty statements accompanying such products and services. Nothing herein
should be construed as constituting an additional warranty. Micro Focus shall not be liable for technical or editorial
errors or omissions contained herein. The information contained herein is subject to change without notice.
Preface ...................................................................................................... 1
Welcome to CodeBridge ............................................................................................................ 1
Who Should Use CodeBridge .................................................................................................... 1
Organization of Information ...................................................................................................... 2
Related Publications................................................................................................................... 3
Symbols and Conventions.......................................................................................................... 3
Technical Support ...................................................................................................................... 4
Support Guidelines ............................................................................................................. 5
Test Cases ........................................................................................................................... 5
List of Figures
Figure 1: Library Error Message Box ..................................................................................... 50
List of Tables
Table 1: CodeBridge Builder Error Messages ........................................................................ 47
Table 2: CodeBridge Builder Exit Codes................................................................................ 49
Table 3: CodeBridge Library Errors ....................................................................................... 50
Table 4: Type Attribute Codes .............................................................................................. 102
Table 5: Parameter Attributes Summary ............................................................................... 106
Table 6: Parameter Attribute Combinations ......................................................................... 112
Table 7: CodeBridge Library Functions ............................................................................... 117
Table 8: CodeBridge Library Flag Definitions ..................................................................... 120
Table 9: RM/COBOL Data Types as Numbers .................................................................... 171
Table 10: RM/COBOL Data Types as Numbers .................................................................. 190
Welcome to CodeBridge
This document describes CodeBridge, RM/COBOL’s cross-language call system that is
designed to simplify communication between RM/COBOL programs and
non-COBOL subprogram libraries that are written in C.
CodeBridge for Windows and UNIX allows RM/COBOL programs to call non-COBOL
subprograms built from external Application Programming Interfaces (APIs) or custom-
developed C libraries without introducing “foreign” language data dependencies into either
the COBOL program or the called C functions. This means that developers can write
COBOL-callable C functions using C data types as usual, without worrying about the
complexities of COBOL calling conventions or data types.
CodeBridge runs on Microsoft Windows and UNIX-based operating systems.
The new features for the most recent release of CodeBridge, as well as significant
enhancements in previous releases, are described in Appendix J: Summary of Enhancements
(on page 215).
Related Publications
For additional information, refer to the following publications:
RM/COBOL User’s Guide
RM/COBOL Language Reference Manual
RM/COBOL Syntax Summary Help File
CodeWatch User’s Guide
WOW Extensions Designer Help File and WOW Extensions Functions and
Messages Help File
Xcentrisity Business Information Server (BIS) User’s Guide
XML Extensions User’s Guide
Technical Support
Micro Focus is dedicated to helping you achieve the highest possible performance from the
RM/COBOL family of products. The Micro Focus Customer Care team is committed to
providing you prompt and professional service when you have problems or questions about
your Micro Focus products.
These technical support services are subject to Micro Focus’ prices, terms, and conditions in
place at the time the service is requested.
While it is not possible to maintain and support specific releases of all software indefinitely,
we offer priority support for the most current release of each product. For customers who
elect not to upgrade to the most current release of the products, support is provided on a
limited basis, as time and resources allow.
Test Cases
You may be asked for an example (test case) that demonstrates the problem. Please
remember the following guidelines when submitting a test case:
• The smaller the test case is, the faster we will be able to isolate the cause of the problem.
• Do not send full applications.
• Reduce the test case to one or two programs and as few data files as possible.
• If you have very large data files, write a small program to read in your current data files
and to create new data files with as few records as necessary to reproduce the problem.
• Test the test case before sending it to us to ensure that you have included all the
necessary components to recompile and run the test case. You may need to include an
RM/COBOL configuration file.
When submitting your test case, please include the following items:
1. README text file that explains the problems. This file must include information
regarding the hardware, operating system, and versions of all relevant software (including
the operating system and all Micro Focus products). It must also include step-by-step
instructions to reproduce the behavior.
2. Program source files. We require source for any program that is called during the
course of the test case. Be sure to include any copy files necessary for recompilation.
3. Data files required by the programs. These files should be as small as possible to
reproduce the problem described in the test case.
What is CodeBridge?
CodeBridge allows RM/COBOL applications to call C functions without being concerned
about the conversion between COBOL arguments and C parameters.
CodeBridge allows RM/COBOL programs to call non-COBOL subprograms built from
external Application Programming Interfaces (APIs) or custom-developed C libraries without
introducing “foreign” language data dependencies into either the COBOL program or the
called C functions. This means that developers can write COBOL-callable C functions using
C data types as usual, without worrying about the complexities of COBOL calling
conventions or data types.
The developer augments C function prototypes with global and parameter attributes described
in this manual to produce a template file. The developer uses the CodeBridge Builder utility
to generate a C source file from the template file. This generated C source file contains the
interface logic that, with the help from the CodeBridge Library, connects the calling COBOL
program to the C function. The developer compiles this C source file, along with the C
functions to be called, and links the generated object files together to form the completed non-
COBOL subprogram library. In many cases, existing C library functions may be used to
generate a non-COBOL subprogram library without writing any C code.
Note For Windows platforms, the generated non-COBOL subprogram library is a dynamic-
link library (DLL). For UNIX platforms, the generated non-COBOL subprogram library is a
“shared object” (normally referred to as an optional support module).
For additional information, see Preparing C Subprograms for UNIX (on page 193). For a
general discussion of support modules and how RM/COBOL uses them, see Appendix D:
Support Modules (Non-COBOL Add-Ons) of the RM/COBOL User’s Guide.
#include <math.h>
cbridge src\trig.tpl
This command reads the input file from src\trig.tpl and writes its output file to src\trig.c.
Any errors would be written to the file src\trig.err.
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice, using commands similar to the following:
For UNIX
A makefile is provided with the RM/COBOL development and runtime systems that can
be used or modified to build a shared object to be used as a support module with the
RM/COBOL runtime system. For additional information, see Preparing C Subprograms
for UNIX (on page 193).
To compile:
cc -c src/trig.c
Note Some compilers may require that the ELF (Executable and Linking Format) object
file be specified, as follows:
cc -b elf -c src/trig.c
To link:
cc -G -o trig.so trig.o
Note Some linkers may require that you explicitly specify the math (or other) libraries,
as follows:
5. Create a COBOL program in a file called trig.cbl that contains the following source
fragments:
rmcobol trig
7. Run the application, specifying the name of the COBOL program and the name of the
non-COBOL subprogram library.
You may specify the name of the non-COBOL subprogram with the appropriate file
extension. The following two commands illustrate how to specify a Windows DLL or a
For Windows
For UNIX
Attribute Lists
Two kinds of attribute lists, parameter and global, are used in a template file.
A parameter attribute list (described in the next section) is formed by enclosing one or more
attributes in double brackets. For example:
[[integer in occurs(3)]]
A global attribute list (on page 20) is formed by enclosing one or more attributes between the
characters [# and #]. For example:
Zero or more parameter attribute lists may immediately precede the type information for each
C parameter or function return value.
Attribute lists for a parameter or function return value may be omitted if the parameter or
function return value is to be ignored.
Within a parameter attribute list, the parameter attributes need not be presented in any
particular order. For example, [[integer in]] is the same as [[in integer]].
When a parameter is used for both input and output, specify both the in and out direction
attributes in either order.
The attributes in a parameter attribute list belong to one of the following categories:
• Base. Base attributes indicate the general classification of a parameter (numeric, string,
string length, pointer, descriptor, or error). Each parameter attribute list must contain
exactly one base attribute, except that the alias(name) base modifier attribute may be
used by itself if the return value is to be ignored. Therefore, within this document, a
parameter attribute list is sometimes identified by its base attribute. For example, the
phrase “an integer attribute list” refers to an attribute list that contains the integer base
attribute. For more information, see Base and Base Modifier Attributes (on page 90).
For an alphabetized summary of the parameter attributes, see the table in Parameter Attributes
Summary (on page 106).
For each usage of a data item in the C function prototype (either for the function return value
or for a parameter), a parameter attribute list has been added.
Since the C function returns an int, the integer base attribute and the out direction attribute
are used.
For the Name parameter, the string base attribute and the in direction attribute are used to
specify that the C function expects a string (array of char) as input.
The buffer_length base attribute is used to specify the size (in bytes) of the buffer used to
contain the converted COBOL argument. By default, the buffer_length base attribute refers
#include "sqltypes.h"
[# replace_type(SQLPOINTER; void *) #]
[# convention(SQL_API) #]
[[integer out]] SQLRETURN SQL_API SQLParamData(
[[integer in]] SQLHSTMT StatementHandle,
[[address]] SQLPOINTER *ValuePtrPtr);
The replace_type global attribute is used to expand the definition of SQLPOINTER to void
*. The convention global attribute is used to identify function calling conventions.
Note 1 This example is based on the ODBC API, which is provided by Microsoft
on Windows platforms. Other companies provide ODBC API implementations for some
UNIX platforms.
Note 2 The header file, sqltypes.h, is included so that the C source code generated by
CodeBridge will be able to resolve the data types, SQLRETURN and SQLHSTMT.
The default values for buffer_length may be overridden by using the size(value) base
modifier attribute in the attribute list that contains the string, numeric_string, or
general_string base attribute that is associated with the same argument as buffer_length.
If an argument is omitted for a parameter described with the optional out attributes, the
parameter result value is ignored. However, the CodeBridge Builder does not currently allow
this combination of attributes. That is, output arguments are required in the current
implementation of CodeBridge.
errno = 0;
__RETURN__open = open(filename, oflag);
__save_errno = errno;
Similarly, for those Windows API functions that set a value to be returned by the function
GetLastError, it is also considered correct behavior not to modify the last error value if no
error occurs. In other words, if no error is detected by the C function, the call to GetLastError
will return the same value it would have if it were called just prior to the C function. The
code sequence that is generated by the CodeBridge Builder guarantees that the value returned
by GetLastError will be zero if no error is detected by the C function call. The generated code
sequence is as follows:
SetLastError(0);
errno = 0;
__RETURN__CreateDirectory = CreateDirectory(DirName, SecAttr);
__save_errno = errno;
__save_lastError = GetLastError();
Explicit Association
CodeBridge is designed to handle most C-parameter-to-COBOL-argument association
situations without requiring you to explicitly specify the associations in the attribute lists of
your template file. For those situations where the CodeBridge automatic association method
does not produce the desired result, you must use the explicit association method. Even when
the automatic association method produces the correct result, you may use the explicit
association method. For instance, you might elect to use the explicit association method to
clearly document the association of parameters with arguments.
To explicitly specify the association of the C function return value or a C parameter to a
particular COBOL argument, you include either the ret_val or the arg_num(value) argument
number attribute in the attribute list for the return value or parameter. For more information,
see Argument Number Attributes (on page 89). If you explicitly specify an argument number
attribute in any attribute list for an individual C function, you must do so for every attribute
list for that function—except for those attribute lists containing a base attribute that does not
refer to an argument.
CodeBridge has limited support for C functions with a variable number of parameters. The
following sections describe that support for numeric and string C parameters.
general_string
For C string parameters that use the general_string base attribute, the last listed parameter
and all additional parameters must be strings. The general_string base attribute allows some
of the additional string parameters to be passed as numeric arguments while others are passed
as non-numeric arguments. The default size of the repeating parameters is based on the
maximum default size determined from all of the COBOL arguments passed as repeating
arguments. For parameters with the general_string base attribute, the default size is the
greater of one more than the length and four more than the digit length of the passed COBOL
argument. The size(value) base modifier attribute (on page 98) may be used to modify the
default size as necessary.
string
For C string parameters that use the string base attribute, the last listed parameter and all
additional parameters must be non-numeric strings. The default size of the repeating
parameters is based on the maximum default size determined from all of the COBOL
arguments passed as repeating arguments. For parameters with the string base attribute, the
default size is one more than the length of the passed COBOL argument. The size(value) base
modifier attribute (on page 98) may be used to modify the default size as necessary.
There are several reasons that the C function will fail to change the value of the COBOL
argument:
• The first is that if step 3 passes the temporary C data item “by value” to the C function,
the function cannot change the value of the temporary C data item, which will, therefore,
be unchanged even if it is stored in step 5.
• The second is that if the parameter does not have the out direction attribute specified,
step 5 is skipped and any change to the temporary C data item is discarded.
• The third is that if the COBOL program passed the COBOL argument using the BY
CONTENT phrase (analogous to a C call “by value”), then step 5 will modify the
contents of the temporary COBOL data area for the argument, which will then be
discarded, leaving the original COBOL argument value unchanged.
• The fourth is that if the CALL statement omits the argument (either by specifying the
OMITTED reserved word or specifying fewer arguments than expected) or if the
COBOL argument is a null-valued pointer passed to a numeric or string parameter, step 5
has no place to store the modified value. (However, the CodeBridge Builder does not
currently allow the optional base modifier attribute with the out direction attribute.)
In summary, you must do all of the following to modify a COBOL argument with the
C function:
1. In the COBOL CALL statement, pass the COBOL argument BY REFERENCE rather
than BY CONTENT. Since the BY REFERENCE phrase is the default for RM/COBOL,
it does not have to be explicitly specified unless a preceding BY CONTENT phrase has
overridden the default. RM/COBOL always passes the argument in the GIVING
(RETURNING) phrase BY REFERENCE. Also, do not pass a
null-valued pointer (on page 26) or omit the argument (on page 29).
2. In the CodeBridge template file, specify the out direction attribute for the C parameter.
For the function return value, out is assumed.
3. In the C function, specify the parameter as called “by reference” so that the address of the
temporary C data item is passed in step 3. In the following example, the first parameter
is passed “by value” (as the value of an integer), while the second is passed “by
reference” (as a pointer to an integer):
Note The C function may save in static storage the address obtained by using any of the three
base attributes described above. The saved address may then be used in subsequent calls. It
is the developer’s responsibility to avoid use of a saved address that points to a data item in a
COBOL program that has been canceled or to a dynamically allocated memory block that the
COBOL program has subsequently deallocated.
Using P-Scaling
In COBOL, P-scaling is used when working with large integers that have several trailing zero
digits before the decimal point or with small fractions that have several leading zero digits
after the decimal point. It is commonly used to store values representing thousands, millions,
or billions. For example, the PICTURE clause “PIC 9(4)P(3)” is used to represent all integers
from 0 to 9,999,000 in units of 1000. The value 1,234,000 would be stored as 1,234, but
would continue to mean 1,234,000.
For input conversions of P-scaled numbers, CodeBridge supplies the missing zero digits.
For output conversions, the extra digits are eliminated by truncation or rounding. Continuing
with the example in the preceding paragraph and using the attribute list [[float in out
Numeric Arrays
For simple numeric types, such as integer or floating-point, the implementation is
straightforward. Examples of valid C numeric array parameters are as follows:
fn(char P1[10],
char *P2,
int P3[40],
float *P4,
float P5[]);
The first two parameters, which use the char data type, are normally used to represent
character strings. However, you can have a numeric array of characters. The difference is
how the called function interprets the data.
To specify the template file for the preceding C function prototype, you might start with the
following, for example:
String Arrays
The implementation of these types of arrays is more complex because strings are already
arrays of characters. One-dimensional arrays of C parameters with a string base attribute are
allowed (this means that, as a special case, two-dimensional arrays of characters are allowed).
Examples of valid C string array parameters are as follows:
fn(char *P1[10],
char *P2[],
char **P3);
To specify the template file for the preceding C function prototype, you might start with the
following, for example:
char *P1[10];
char *P2[10];
char *P3[10];
Each element of the array is initialized to point to the correct offset within the
allocated block.
The number of elements in the array and the size of each element determine the size of the
allocated block. For a numeric_string, the size of each element is equal to four more than
the digit length of the COBOL argument. For a string, the size of each element is equal to
one more than the length of the COBOL argument. For a general_string, the size of each
element is equal to the greater of four more than the digit length and one more than the length
of the COBOL argument.
You may override these default element sizes by using the size(value) base modifier attribute
as follows:
CodeBridge Builder
This section describes the CodeBridge Builder, which reads a template file as input and
generates C source as output. This generated source provides the interface between the
COBOL program and the C function by calling functions in the CodeBridge Library to
convert between COBOL arguments and C parameters, as needed, before and after calling the
target C function.
For each C function prototype in the template file, a corresponding function is generated in
the dynamic-link library (DLL) interface code. Each function contains all of the logic needed
to do the following:
• Produce an exportable dynamic-link library (DLL) function
• Optionally perform input argument validation
• Convert input arguments from COBOL to C
• Call the C function
• Optionally perform output parameter validation
• Convert output parameters from C to COBOL
Note The generated C source contains a #include C preprocessor directive that refers to the
additional header files: rmc85cal.h, rmport.h, rtarg.h, rtcallbk.h, and standdef.h. All of
these files are installed with CodeBridge.
If errors are encountered, an error file is generated. For more details, see CodeBridge Builder
Error Messages (on page 47). The error file uses the same pathname as <output file> with the
extension changed to .err.
cbridge src\myfile.tpl
reads src\myfile.tpl, writes the generated source to src\myfile.c, and writes any error
messages to src\myfile.err.
The command:
This appendix lists and describes the messages that can be generated during the use of either
the CodeBridge Builder or the CodeBridge Library. These messages also include the
CodeBridge Builder exit codes.
The CodeBridge Builder uses the following data files: dllgen.in, dllgen.out, dllgen.p01, and
dllgen.sym. Occasionally, if these files are write-protected, the CodeBridge Builder may not
be able to open them, and an error message similar to the following will be displayed:
C:\TOOLS\SCANNER.EXE: FAILURE
- Unable to open file 'C:\TOOLS\DLLGEN.xxx'.
If this occurs, modify the attributes of these four files so that they are not write-protected.
Code Description
where,
<calling function name> is the Name parameter from the last call to ConversionStartup
(on page 147).
<number> is the one-based argument number of the argument in the USING phrase.
When the alternative, Return Value, is shown, it indicates the argument in the GIVING
(RETURNING) phrase.
<library function name> is the conversion or validation operation specified as one of the
names listed in the “Function Name” column of the table in the section Library Functions
Overview (on page 117). For example, CobolToInteger (on page 137), would be
specified if the error occurred during conversion of a COBOL numeric argument to a C
integer parameter.
<Error number> is the “Error Code” and <message text> is the “Error Text” listed in
Table 3 on page 50.
For UNIX platforms, the message is written to stderr. The following shows an example of a
CodeBridge Library error message on UNIX:
501 Digits count too large One of the base modifier attributes (assert_digits,
assert_digits_left, or assert_digits_right) was
specified and the corresponding number of digits in the
passed COBOL argument was greater than the indicated
maximum.
502 Digits count too small One of the base modifier attributes (assert_digits,
assert_digits_left, or assert_digits_right) was
specified and the corresponding number of digits in the
passed COBOL argument was less than the indicated
minimum.
503 Initialization needed A call was made to a CodeBridge Library function prior
to calling the ConversionStartup function. This error
should never occur when using the CodeBridge Builder.
504 Integer data expected The integer_only base modifier attribute was specified
and the COBOL argument contains digits to the right of
the decimal point.
505 Internal logic – Argument This indicates an incompatibility between the
setup RM/COBOL compiler and runtime. The descriptor of
the COBOL argument contained unexpected values.
506 Internal logic – Data type This indicates an incompatibility between the
RM/COBOL compiler and runtime. The type of the
COBOL argument contained an unexpected value.
507 Internal logic – Parameter This indicates a logic error in the CodeBridge Library.
setup While setting up a description of the C parameter, an
unexpected condition was encountered.
508 Invalid argument number The argument number supplied was not valid. This
could indicate an internal error with the CodeBridge
Builder or that the developer used a bad value when
calling a CodeBridge Library function directly.
509 Invalid C numeric string [[numeric_string out]] was specified and the C
string is not numeric.
510 Invalid data type The COBOL argument contains an unsupported
data type.
511 Invalid sign specification The COBOL argument contains an invalid sign.
512 Length too large The assert_length base modifier attribute was specified
and the corresponding length of the passed COBOL
argument was greater than the indicated maximum.
513 Length too small The assert_length base modifier attribute was specified
and the corresponding length of the passed COBOL
argument was less than the indicated minimum.
514 Memory allocation error The CodeBridge Library attempted to allocate memory
and encountered an error.
Error
Code Error Text Description
515 Non-numeric data A numeric COBOL argument was used with the string
expected base attribute.
This appendix contains examples that use the typical CodeBridge development procedure
outlined in Chapter 1: Introduction (on page 7). The examples build from simple to complex,
as a means of introducing CodeBridge concepts, which are discussed in Chapter 2: Concepts
(on page 17).
In addition to these examples, there are several CodeBridge sample programs that are
included with the development system in the CodeBridge samples subdirectory (cbridge on
Windows and cbsample on UNIX). See the appropriate README file (and the samples.txt
file on Windows) for additional information about the CodeBridge sample programs that
are included.
Note 1 In the following example template files, bold type is used to indicate the first instance
of a CodeBridge attribute that is being introduced. Detailed information about attributes and
attribute lists is provided in Appendix D: Global Attributes (on page 85) and Appendix E:
Parameter Attributes (on page 89).
Note 2 Unlike COBOL, C is a case-sensitive programming language. Thus, the case is
significant for words in these example template files.
#include <windows.h>
#include <winuser.h>
[# replace_type(LPCSTR; char *)
convention(WINUSERAPI)
convention(WINAPI) #]
cbridge src\mbox.tpl
This command reads the input file from src\mbox.tpl and writes its output file to
src\mbox.c. Any errors would be written to file src\mbox.err
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice, using commands similar to the following:
5. Create a COBOL program in a file named mbox.cbl that contains the following source
fragments:
rmcobol mbox
7. Run the application with the following command line:
#include <windows.h>
#include <winuser.h>
strcpy(MessageText, Text);
va_start(Marker, Text);
for (i = 4; i <= ArgCount; i++)
strcat(MessageText, va_arg(Marker, char*));
va_end(Marker);
2. Create a template file named mbox2.tpl in the src directory that consists of the following
lines:
cbridge src\mbox2.tpl
This command reads the input file from src\mbox2.tpl and writes its output file to
src\mbox2.c. Any errors would be written to file src\mbox2.err.
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice. There are now two C files to compile:
• The message_box function (created in step 1) in the file named mbox2fn.c.
• The file named mbox2.c (created in step 3 by the CodeBridge Builder when it
processed the file named mbox2.tpl, created in step 2).
rmcobol mbox2
7. Run the application with the following command line:
#include <stdlib.h>
#include <malloc.h>
void free(
[[pointer_base in]] void *memblock);
[[pointer_base out
pointer_reset_offset
ret_val]] void *malloc(
[[integer in arg_num(1)]]
[[pointer_size out ret_val]] size_t size);
cbridge src\mem.tpl
This command reads the input file from src\mem.tpl and writes its output file to
src\mem.c. Any errors would be written to file src\mem.err.
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice, using commands similar to the following:
For Windows
For UNIX
A makefile is provided with the RM/COBOL development and runtime systems that can
be used or modified to build a shared object to be used as a support module with the
RM/COBOL runtime system. For additional information, see Preparing C Subprograms
for UNIX (on page 193).
To compile:
cc -c src/mem.c
Note Some compilers may require that the ELF (Executable and Linking Format)
object file be specified, as follows:
cc -G -o mem.so mem.o
5. Create a COBOL program in a file named mem.cbl that contains the following source
fragments:
rmcobol mem
7. Run the application, specifying the name of the COBOL program and the name of the
non-COBOL subprogram library.
You may specify the name of the non-COBOL subprogram with the appropriate file
extension. The following two commands illustrate how to specify a Windows dynamic-
link library (DLL) or a UNIX shared object (generally referred to as optional support
modules). Since the COBOL program and the non-COBOL subprogram have the same
root name (mem), it is necessary to specify the correct file extension.
For Windows
For UNIX
#include <time.h>
time_of_day = time(NULL);
tmbuf = localtime(&time_of_day);
time_function(
[[integer out]] short *sec,
[[integer out]] short *min,
[[integer out]] short *hour);
cbridge src\mytime.tpl
This command reads the input file from src\mytime.tpl and writes its output file to
src\mytime.c. Any errors would be written to file src\mytime.err.
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice. There are two C files to compile:
• The time_function function (created in step 1) in the file named timefn.c.
• The file named mytime.c (created in step 3 by the CodeBridge Builder when it
processed the file named mytime.tpl, created in step 2).
Use commands similar to the following:
For Windows
For UNIX
A makefile is provided with the RM/COBOL development and runtime systems that can
be used or modified to build a shared object to be used as a support module with the
RM/COBOL runtime system. For additional information, see Preparing C Subprograms
for UNIX (on page 193).
To compile:
cc -c src/mytime.c
cc -c src/timefn.c
Note Some compilers may require that the ELF (Executable and Linking Format)
object file be specified, as follows:
5. Create a COBOL program in a file named mytime.cbl that contains the following source
fragments:
01 GROUP-1.
02 TM-SEC PIC 9(2).
02 TM-MIN PIC 9(2).
02 TM-HOUR PIC 9(2).
rmcobol mytime
7. Run the application, specifying the name of the COBOL program and the name of the
non-COBOL subprogram library.
You may specify the name of the non-COBOL subprogram with the appropriate file
extension. The following two commands illustrate how to specify a Windows dynamic-
link library (DLL) or a UNIX shared object (generally referred to as optional support
modules). Since the COBOL program and the non-COBOL subprogram have the same
root name (mytime), it is necessary to specify the correct file extension.
For Windows
For UNIX
#include <string.h>
void cstring2text(
[[address]] char *pInput,
[[string out trailing_spaces]] char *pOutput);
3. Invoke the CodeBridge Builder by using the following command line:
cbridge src\strcvt.tpl
This command reads the input file from src\strcvt.tpl and writes its output file to
src\strcvt.c. Any errors would be written to file src\strcvt.err.
The CodeBridge Builder generates a C function from the template file. The generated C
function will add trailing space characters to the output string argument because of the
trailing_spaces base modifier attribute specified in the template file. All the work of the
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice, using commands similar to the following:
rmcobol strcvt
7. Run the application with the following command line:
1. In this example, the following C++ source files represent the C++ library. The files
named libfunc.cpp and libfunc.h represent components of the C++ library. The C++
library contains functions named LibFunction1 and LibFunction2.
int LibFunction1()
{
return(1);
}
int LibFunction2()
{
return(2);
}
The file libfunc.h makes function definitions available externally and contains the
following lines:
int LibFunction1();
int LibFunction2();
Create a C++ source file that will map the function from C++ names to C names. The
file maplib.cpp contains the following lines:
#include "libfunc.h"
extern "C" int MapFunction1()
{
return(LibFunction1());
}
extern "C" int MapFunction2()
{
return(LibFunction2());
}
2. Create a template file named maplibcb.tpl that consists of the following lines:
cbridge maplibcb.tpl
5. Compile and link the non-COBOL subprogram library with the C and C++ compilers,
using commands similar to the following:
For Windows
For UNIX
A makefile is provided with the RM/COBOL development and runtime systems that can
be used or modified to build a shared object to be used as a support module with the
RM/COBOL runtime system. For additional information, see Preparing C Subprograms
for UNIX (on page 193).
To compile:
cc -c src/maplibcb.c
CC -c src/maplib.cpp
CC -c src/libfunc.cpp
Note Some compilers may require that the ELF (Executable and Linking Format)
object file be specified, as follows:
cc -b elf -c src/maplibcb.c
CC -b elf -c src/maplib.cpp
CC -b elf -c src/libfunc.cpp
To link:
rmcobol myprog
7. Run the application, specifying the name of the COBOL program and the name of the
non-COBOL subprogram library, with the following command line:
For Windows
For UNIX
For Windows
For UNIX
cbridge src\mkdir.tpl
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice, using commands similar to the following:
For Windows
For UNIX
cc –c src/mkdir.c
cc –G –o mkdir.so makdir.o
5. Create a COBOL program in a file named mkdir.cbl that contains the following source
fragments:
CALL "_mkdir"
USING File-Name Err-No
GIVING Return-Status.
For UNIX
CALL "mkdir"
USING File-Name Mode Err-No
GIVING Return-Status.
6. Compile the COBOL program with the RM/COBOL compiler by using the following
command line:
rmcobol src\mkdir
7. Run the application, specifying the name of the COBOL program and the name of the
non-COBOL subprogram library.
You may specify the name of the non-COBOL subprogram with the appropriate file
extension. The following two commands illustrate how to specify a Windows dynamic-
link library (DLL) or a UNIX shared object (generally referred to as optional support
modules). Since the COBOL program and the non-COBOL subprogram have the same
root name (mkdir), it is necessary to specify the correct file extension.
For Windows
For UNIX
#include <windows.h>
[# replace_type(LPCTSTR; char *)
replace_type(LPSECURITY_ATTRIBUTES; void *)
convention(WINBASEAPI)
convention(WINAPI) #]
cbridge src\Dir.tpl
4. Compile and link the non-COBOL subprogram library with the C compiler of your
choice, using commands similar to the following:
CALL "CreateDirectory"
USING File-Name Last-Error
GIVING Return-Status.
6. Compile the COBOL program with the RM/COBOL compiler by using the following
command line:
rmcobol src\Dir
7. Run the application with the following command line:
Data Types
C includes predefined data types that may be categorized as integer, floating-point, pointer,
and void.
Integer data types include char, short, int and long. These data types may be prefixed with
the keywords signed or unsigned. Normally, integer types default to signed. As a shorthand
notation, when signed or unsigned appear without the corresponding integer data type, then
int is implied (that is, unsigned is the same as unsigned int).
C also includes the floating-point data types float and double. Floating-point is the computer
representation of scientific notation. It allows numbers with a large scale or small scale to be
represented with an approximate value. For the IEEE representation of floating-point, the
float type is normally limited to about 6 or 7 digits of precision with an exponent (scale) of –
38 to +38. Also, the double type is normally limited to about 15 or 16 digits of precision with
an exponent (scale) of –308 to +308.
A pointer data type contains the address of a typed data item and is represented by the asterisk
character (*) in the data declaration or type definition (these terms are described in the
following sections).
The void data type, void, is used to represent untyped or sometimes omitted data.
Note that other keywords, such as far and near also exist, although their meaning is mostly
historical. Depending on the compiler, one or two underscore characters may precede some
keywords (_far or __far instead of far).
Data Declarations
A data declaration associates data type information with the name of a variable.
For example:
When an array is passed to a C function, the address of (pointer to) the array is used. In a
C function prototype, a pointer reference and an array reference are equivalent. That is, char
P5[30] is treated the same as char *P5 (with the exception that the compiler can do some
compile time range checking if the number of elements in the array is explicitly declared).
Calling Conventions
A calling convention defines additional type information. It directs how the compiler
generates function-calling sequences and is an optional part of a function prototype.
Examples include __cdecl (or RM_CDECL when writing code for both Windows and UNIX),
__stdcall, and __pascal. Often a calling convention is hidden with a type definition or a
macro. For example, the following macro definition defines the macro, SQL_API to be the
__stdcall calling convention:
Function Prototypes
A function prototype may contain or refer to any of the concepts that have been previously
presented (data types, data declarations, type definitions and macros, and calling
conventions).
A function prototype consists of the function name and a list of parameter names. The name
of the function and the name of each parameter are prefaced with type information to form a
data declaration. For example:
Compiling on Windows
The following illustrates an example of invoking Microsoft’s Visual C++ compiler to
generate Windows object files:
where,
cl indicates the name of the compiler.
-c suppresses the implicit call to LINK that normally occurs.
-MD selects the Multithread and DLL options. The developer may choose -MDd in
order to select the debugging option also.
-Zp1 specifies structure member alignment of 1 byte.
Note A structure is the C equivalent of a COBOL group. The -Zp1 option is
recommended because the ARGUMENT_ENTRY structure passed from the
RM/COBOL runtime system is built using the -Zp1 option.
src\trig.c indicates the name of the C source program to be compiled.
Note This example uses the hyphen (-) character to denote compiler options.
Microsoft’s Visual C++ compiler also allows a forward slash (/) character to be used (for
example, /c instead of –c).
Compiling on UNIX
The following illustrates an example of producing object files on UNIX:
cc -c src/trig.c
where,
cc indicates the name of the compiler/linker.
-c suppresses the linking stage and does not produce an executable file.
src/trig.c indicates the name of the C source program to be compiled.
• kernel32.lib • shell32.lib
• user32.lib • ole32.lib
• gdi32.lib • oleaut32.lib
• winspool.lib • uuid.lib
• comdlg32.lib • odbc32.lib
• advapi32.lib • odbccp32.lib
Note This example uses the hyphen (-)character to denote compiler options. Microsoft’s
linker also allows a forward slash (/) character to be used.
Linking on UNIX
The following illustrates an example of linking a shared object on UNIX:
This appendix provides detailed descriptions of the attributes used in a global attribute list in a
template file. For more information about the basic components of a template file, see
Chapter 2: Concepts (on page 17). The attributes used in a parameter attribute list are
discussed in Appendix E: Parameter Attributes (on page 89). More information about C
language concepts and terms may be found in Appendix C: Useful C Information (on page
77).
Note As you read through this manual, keep in mind that the term “parameter attribute” is a
shorthand notation for an attribute that occurs in a parameter attribute list. Likewise, “global
attribute” indicates that the attribute can be found in a global attribute list.
banner Attribute
Use the banner global attribute to display a text string when a non-COBOL subprogram built
with CodeBridge is loaded by the RM/COBOL runtime system.
The format of the banner global attribute is as follows:
convention Attribute
Use the convention attribute to declare C calling conventions (for example, SQL_API).
Calling conventions cannot be placed in the CodeBridge-generated declarations of variables;
however, they must be preserved in the external function prototype that is used to call the
C function.
The format of the convention global attribute is as follows:
[# convention(name) #]
where, name is the name of a call convention.
SQL_API can be resolved as follows:
[# convention(SQL_API) #]
SQL_API is removed from variable declarations, but is preserved as part of the external
function prototype.
diagnostic Attribute
Use the diagnostic attribute to control error reporting.
The format of the diagnostic global attribute is as follows:
[# diagnostic(value) #]
where, value may be one of the following:
• silent. Use the silent value to instruct CodeBridge not to display diagnostic messages.
• verbose. Use the verbose value to instruct CodeBridge to display diagnostic messages
even if the silent base modifier attribute is set for an individual parameter attribute list.
For more information about the silent base modifier, see Base Modifiers Common to Base
Attributes (on page 91).
load_message Attribute
Use the load_message attribute to display a text string when a non-COBOL subprogram built
with CodeBridge is loaded by the RM/COBOL runtime system.
The format of the load_message global attribute is as follows:
[# load_message(value) #]
where, value is a character string. For example:
replace_type Attribute
The CodeBridge Builder program does not resolve C data types. Frequently, necessary data
type information may be hidden in a macro or a type definition construct (as shown in the
definitions above). Specifically, CodeBridge must know whether a data item is a pointer data
type. It is necessary, therefore, for the template file to resolve some type definitions for
CodeBridge.
Use the replace_type global attribute to allow CodeBridge to resolve pointer data
declarations that hide the C unary pointer operator (*) within the data type name (for example,
SQLPOINTER).
You may choose to use the replace_type attribute as a form of self-documentation to expand
any defined data type, even if the expansion does not reveal any levels of indirection.
The format of the replace_type global attribute is as follows:
[# replace_type(name;value) #]
where, value is the character string that replaces the data type specified by name.
The SQLPOINTER data type can be resolved as follows:
[# replace_type(SQLPOINTER;void*) #]
[# replace_type(SQLPOINTER;void *) #]
[# replace_type(SQLPOINTER; void * ) #]
This appendix provides detailed descriptions of the attributes used in a parameter attribute list
in a template file. See Chapter 2: Concepts (on page 17) for more information about the
basic components of a template file. The attributes used in a global attribute list are discussed
in Appendix D: Global Attributes (on page 85). More information about C language
concepts and terms may be found in Appendix C: Useful C Information (on page 77).
Note As you read through this manual, keep in mind that the term “parameter attribute” is a
shorthand notation for an attribute that occurs in a parameter attribute list. Likewise, “global
attribute” indicates that the attribute can be found in a global attribute list.
Each group is described in the following sections. An alphabetical summary of all available
parameter attributes is shown in Table 5 beginning on page 106.
Attributes are case-sensitive and must be entered as shown.
Direction Attributes
The direction attributes are in and out. The in direction attribute specifies an input parameter
to the C function. The out direction attribute specifies an output parameter from the C
function.
Both the in and out direction attributes may be specified in a parameter attribute list. Within
a parameter attribute list, you may present the attributes in any order. For example,
[[integer in]] is the same as [[in integer]]. When a parameter is used for both
input and output, both the in and out direction attributes are specified in either order.
The direction attributes may be used to protect the calling COBOL program from unintended
modification of data. For example, when the out direction attribute is not used, then the data
in the C parameter is not converted to COBOL format, and the data is not placed in the
address space of the COBOL program.
For a given parameter, if none of its attribute lists contain the in direction attribute, an
uninitialized value may be passed to the function. No more than one attribute list (for any
given parameter) should be used for input; however, several output attribute lists may be
assigned to the same parameter.
Some base attributes imply a direction and thus do not allow either of the direction attributes.
The error base attributes (on page 103), errno and get_last_error, imply the out direction
attribute. The descriptor base attributes (on page 101), two of the pointer base attributes (on
page 100), pointer_address and pointer_length, and the string length base attributes (on
page 99) imply the in direction attribute.
Use the following template file to return only the integer part:
double modf(
[[float in arg_num(1)]] double A,
[[float out ret_val]] double *IntPart);
A similar function, called fraction_part, uses the return value of the modf function, as
follows:
[[alias(fraction_part)
float out]] double modf(
[[float in]] double A,
double *IntPart);
Note Numeric base attributes may be used with arrays. For more information, see Numeric
Arrays (on page 41).
" 1 "
" - 1 "
" 2.34 CR"
"0"
In addition to the base modifier attributes that apply to all numeric base attributes, the
following modifiers are specific to the integer base attribute:
• integer_only. Use this base modifier attribute to verify that the passed COBOL
argument represents an integer value (that is, no digits are allowed to the right of the
decimal point). This attribute is equivalent to the assert_digits_right(0;0) base modifier
attribute specification.
• scaled(value). Use this base modifier attribute to scale integer values during the
conversion process. On input, the COBOL argument is multiplied by 10value. On
output, the C parameter is divided by 10value.
For example, if the attribute list is [[integer in out scaled(2)]] and the
COBOL program supplied a value of 1.53, the C function would receive a value of 153.
If the C function changed the value to 4, the COBOL program would receive .04 back.
• unsigned. Use this base modifier attribute to force CodeBridge to treat the C parameter
as unsigned. The default is to treat C parameters as signed.
In addition to the modifiers that apply to all numeric base attributes, the following modifiers
are specific to the numeric_string base attribute:
Note To obtain the length of the COBOL argument, use the length base attribute (on page
102).
Note A COBOL pointer data item with a zero base address component is always a null
pointer, regardless of the offset and size values. If the base address of a pointer is set to a zero
value or remains a zero value, the pointer offset and size components cannot be set to non-
zero values. When a COBOL pointer data item with a zero base address component is stored,
the pointer offset and size components will be set to zero.
• windows_handle. Use the windows_handle base attribute to pass the Windows handle
associated with the run unit to the C function. This attribute, which is available only for
Windows systems, is useful when calling some Windows APIs. For example, when
opening a new window, it may be necessary to supply the handle of the parent’s window.
The windows_handle base attribute does not refer to a COBOL argument.
Note 1 The windows_handle base attribute is not available on UNIX platforms as it can
cause compilation errors.
Note 2 When using the explicit argument association method, it is an error to specify the
argument number attribute, arg_num(value), with the windows_handle base attribute
since this base attribute does not refer to a COBOL argument.
Error base attributes refer to an argument in the COBOL CALL statement, but do not refer to
any C function return value or parameter. These attributes cause the CodeBridge Builder to
generate separate code sequences to return the value of the external variable errno or the
return value of the Windows GetLastError function. For additional information, see
Returning C Error Values (on page 30).
Error base attributes are, in a certain sense, the opposite of descriptor base attributes (these
include arg_count, initial_state, and windows_handle). The error base attributes describe a
COBOL argument for which there is no corresponding C parameter, because the source item
for these attributes is not described in the C function prototype, and are output (to the COBOL
argument) only. The descriptor base attributes are used to develop input values for C
parameters from a source other than a COBOL argument or from the description of a COBOL
argument.
The error base attributes can be supplemented with additional information by the base
modifier attributes listed below:
• alias(name). See the description of the alias base modifier (on page 91). Note that the
alias base modifier attribute is only allowed when the parameter attribute list precedes
the function name.
• assert_digits(min;max). Use this base modifier attribute to verify that the digit length of
the passed COBOL argument is within the range specified by min and max. For example,
[[errno assert_digits(9;18)]] indicates that the COBOL data item must
contain from 9 to 18 digits.
The use of P-scaling in the COBOL program will increase the digit length by the number
of P symbols specified in the PICTURE character-string. For example, all of the
PICTURE character-strings 9(8), 9(5)P(3), and VP(3)9(5) describe a data item with a
digit length of eight for CodeBridge.
• assert_digits_left(min;max). Use this base modifier attribute to verify that the number of
digits to the left of the decimal point in the passed COBOL argument is within the range
specified by min and max. For example, [[get_last_error
assert_digits_left(5;~0)]] indicates that the COBOL data item must
Argument
Base Direction Number Modifiers
Argument
Base Direction Number Modifiers
Argument
Base Direction Number Modifiers
Argument
Base Direction Number Modifiers
The CodeBridge Library is a collection of functions that are included in the RM/COBOL
runtime system. These functions are used to convert input data from COBOL arguments to C
parameters on entry and from C parameters to COBOL arguments just prior to exit. The
CodeBridge Library also contains functions that perform data range and integrity checks.
This appendix describes each function in the CodeBridge Library. These descriptions will
help you understand the C code generated by the CodeBridge Builder. Information on
specifying the Flags parameter is also covered. The information in this appendix will also
prove useful if you are debugging applications developed using CodeBridge.
Note The information presented here assumes a working knowledge of the C programming
language. The material in Appendix C: Useful C Information (on page 77), is not
comprehensive enough to provide this necessary background.
The series of functions that begin with “Assert” are designated as “Either” in the Input or
Output column. It is recommended that these functions be called prior to the execution of the
C function.
The ConversionStartup, ConversionCleanup, and GetCallerInfo functions are designated as
“Neither” in the Input or Output column. The ConversionStartup function should be called
once just after entry from COBOL. The ConversionCleanup function should be called once
AssertDigits
AssertDigits returns TRUE if the number of digits for the COBOL argument is in the range
specified by MinValue and MaxValue; otherwise, the function returns FALSE. This function
also returns FALSE if the argument is not numeric.
If the COBOL CALL statement omits an argument, the value that is substituted for the
omitted argument is not checked by this function. See the discussion on managing omitted
arguments (on page 29).
The use of P-scaling in the COBOL program will increase the digit length by the number of P
symbols specified in the PICTURE character-string. For example, all of the PICTURE
character-strings 9(8), 9(5)P(3), and VP(3)9(5) describe a data item with a digit length of
eight for CodeBridge.
Calling Sequence
Error! Not a valid filename.
AssertDigitsLeft
AssertDigitsLeft returns TRUE if the number of digits to the left of the decimal point for the
COBOL argument is in the range specified by MinValue and MaxValue; otherwise, the
function returns FALSE. This function also returns FALSE if the argument is not numeric.
If the COBOL CALL statement omits an argument, the value that is substituted for the
omitted argument is not checked by this function. See the discussion on managing omitted
arguments (on page 29).
The use of P-scaling in the COBOL program will increase the number of digits to the left of
the decimal point by the number of P symbols specified in the PICTURE character-string that
occur to the left of the decimal point. For example, both of the PICTURE character-strings
9(8) and 9(5)P(3) describe a data item with eight digits to the left of the decimal point for
CodeBridge.
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
AssertLength
AssertLength returns TRUE if the length of the COBOL argument (in bytes) is in the range
specified by MinValue and MaxValue; otherwise, the function returns FALSE.
Calling Sequence
Error! Not a valid filename.
AssertSigned
AssertSigned returns TRUE if the COBOL argument is signed; otherwise, the function returns
FALSE.
If the COBOL CALL statement omits an argument, the value that is substituted for the
omitted argument is not checked by this function. See the discussion on managing omitted
arguments (on page 29).
Calling Sequence
Error! Not a valid filename.
AssertUnsigned
AssertUnsigned returns TRUE if the COBOL argument is unsigned; otherwise, the function
returns FALSE.
If the COBOL CALL statement omits an argument, the value that is substituted for the
omitted argument is not checked by this function. See the discussion on managing omitted
arguments (on page 29).
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
CobolArgCount
CobolArgCount obtains that actual number of arguments passed from the calling COBOL
program. This function returns TRUE if it is successful and FALSE if there is an error.
Note The CobolArgCount function is one of the trivial conversion functions. See the
discussion on trivial conversions (on page 206).
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
CobolDescriptorDigits
CobolDescriptorDigits obtains the digit count for the COBOL argument. This function
returns TRUE if it is successful and FALSE if there is an error.
Calling Sequence
Error! Not a valid filename.
CobolDescriptorLength
CobolDescriptorLength obtains the length (in bytes) of the COBOL argument. This function
returns TRUE if it is successful and FALSE if there is an error.
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
Flags modify the behavior of the conversion. The only valid flag value for CobolInitialState
is PF_SILENT. See Table 8 on page 120.
Parameter is the address of the C parameter where the initial state flag will be stored. It may
also be the address of an array of floating-point values if the PF_OCCURS flag is set.
Size is the size of the C parameter.
State is the initial state flag for the current COBOL CALL.
CobolToFloat
CobolToFloat converts the COBOL numeric argument to a C floating-point value. This
function returns TRUE if it is successful and FALSE if there is an error.
By convention, this function should be called prior to the FloatToCobol (on page 150)
function for the same argument number. Do not set the PF_IN flag for output-only
conversions. Because the call to this function may perform memory management operations
that are not needed for output-only conversions, this call may be omitted.
• PF_ASSERT_SIGNED • PF_OPTIONAL
• PF_ASSERT_UNSIGNED • PF_REPEAT
• PF_IN • PF_ROUNDED
• PF_NO_NULL_POINTER • PF_SILENT
• PF_NO_SIZE_ERROR • PF_VALUE_IF_OMITTED
• PF_OCCURS
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Omitted is the default value for omitted arguments if either of the PF_OPTIONAL or
PF_VALUE_IF_OMITTED flags is set.
Parameter is a pointer to the address of the C parameter where the floating-point value will be
stored.
Repeat is the repeat count if PF_REPEAT is set.
Size is the size of the C parameter.
Calling Sequence
Error! Not a valid filename.
• PF_ASSERT_SIGNED • PF_OPTIONAL
• PF_ASSERT_UNSIGNED • PF_REPEAT
• PF_C_DATA_IS_ANSI • PF_ROUNDED
• PF_C_DATA_IS_OEM • PF_SILENT
• PF_IN • PF_SIZE
• PF_LEADING_MINUS • PF_TRAILING_CREDIT
• PF_LEADING_SIGN • PF_TRAILING_DEBIT
• PF_LEADING_SPACES • PF_TRAILING_MINUS
• PF_LEADING_VALUE • PF_TRAILING_SIGN
• PF_NO_NULL_POINTER • PF_TRAILING_SPACES
• PF_NO_SIZE_ERROR • PF_TRAILING_VALUE
• PF_OCCURS • PF_VALUE_IF_OMITTED
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Omitted is the default value for omitted arguments if either of the PF_OPTIONAL or
PF_VALUE_IF_OMITTED flags is set.
Parameter is the address of the C pointer where the address of the string will be stored. It
may also be the address of an array of string values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Size is the conversion buffer length override when the PF_SIZE flag is set. If the PF_SIZE
flag is not set, the default conversion buffer length is the greater of one more than the length
of the COBOL argument and four more than the digit length of the COBOL argument. The
digit length of a COBOL argument is the sum of the number of 9 and P symbols used in its
PICTURE character-string.
Value1 is the strip/fill character value if the PF_LEADING_VALUE flag is set.
Value2 is the strip/fill character value if the PF_TRAILING_VALUE flag is set.
Calling Sequence
Error! Not a valid filename.
• PF_ASSERT_SIGNED • PF_OPTIONAL
• PF_ASSERT_UNSIGNED • PF_REPEAT
• PF_IN • PF_ROUNDED
• PF_INTEGER_ONLY • PF_SCALED
• PF_NO_NULL_POINTER • PF_SILENT
• PF_NO_SIZE_ERROR • PF_UNSIGNED
• PF_OCCURS • PF_VALUE_IF_OMITTED
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Omitted is the default value for omitted arguments if either of the PF_OPTIONAL or
PF_VALUE_IF_OMITTED flags is set.
Parameter is a pointer to the address of the C parameter where the integer value will be
stored. It may also be the address of an array of integer values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
CobolToNumericString
CobolToNumericString converts the COBOL numeric argument to a null-terminated C string.
This function returns TRUE if it is successful and FALSE if there is an error.
By convention, this function should be called prior to the NumericStringToCobol (on page
157) function for the same argument number. Do not set the PF_IN flag for output-only
conversions. Because the call to this function may perform memory management operations
that are not needed for output-only conversions, this call may be omitted.
• PF_ASSERT_SIGNED • PF_REPEAT
• PF_ASSERT_UNSIGNED • PF_ROUNDED
• PF_IN • PF_SILENT
• PF_LEADING_MINUS • PF_SIZE
• PF_LEADING_SIGN • PF_TRAILING_CREDIT
• PF_NO_NULL_POINTER • PF_TRAILING_DEBIT
• PF_NO_SIZE_ERROR • PF_TRAILING_MINUS
• PF_OCCURS • PF_TRAILING_SIGN
• PF_OPTIONAL • PF_VALUE_IF_OMITTED
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Omitted is the default value for omitted arguments if either of the PF_OPTIONAL or
PF_VALUE_IF_OMITTED flags is set.
Parameter is the address of the C pointer where the address of the string will be stored. It
may also be the address of an array of string values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Size is the conversion buffer length override when the PF_SIZE flag is set. If the PF_SIZE
flag is not set, the default conversion buffer length is the greater of one more than the length
of the COBOL argument and four more than the digit length of the COBOL argument. The
digit length of a COBOL argument is the sum of the number of 9 and P symbols used in its
PICTURE character-string.
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
Calling Sequence
Error! Not a valid filename.
CobolToPointerOffset
CobolToPointerOffset obtains the offset component of the COBOL pointer argument. This
function returns TRUE if it is successful and FALSE if there is an error.
CobolToPointerSize
CobolToPointerSize obtains the size component of the COBOL pointer argument. This
function returns TRUE if it is successful and FALSE if there is an error.
Calling Sequence
Error! Not a valid filename.
CobolToString
CobolToString converts the COBOL non-numeric argument to a null-terminated C string.
This function returns TRUE if it is successful and FALSE if there is an error.
By convention, this function should be called prior to the StringToCobol (on page 161)
function for the same argument number. Do not set the PF_IN flag for output-only
conversions. Because the call to this function may perform memory management operations
that are not needed for output-only conversions, this call may be omitted.
Calling Sequence
Error! Not a valid filename.
• PF_C_DATA_IS_ANSI • PF_OPTIONAL
• PF_C_DATA_IS_OEM • PF_REPEAT
• PF_IN • PF_SILENT
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Omitted is the default value for omitted arguments if either of the PF_OPTIONAL or
PF_VALUE_IF_OMITTED flags is set.
Parameter is the address of the C pointer where the address of the string will be stored. It
may also be the address of an array of string values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Size is the conversion buffer length override when the PF_SIZE flag is set. If the PF_SIZE
flag is not set, the default conversion buffer length is one more than the length of the COBOL
argument.
Value1 is the strip/fill character value if the PF_LEADING_VALUE flag is set.
Value2 is the strip/fill character value if the PF_TRAILING_VALUE flag is set.
Calling Sequence
Error! Not a valid filename.
Flags modify the behavior of the conversion. The only valid flag value for
CobolWindowsHandle is PF_SILENT. see Table 8 on page 120.
Parameter is the address of the C parameter where the Windows handle will be stored.
Size is the size of the C parameter.
WindowsHandle is the Windows handle for the current COBOL CALL. This attribute is not
available on UNIX platforms as it can cause compilation errors.
ConversionCleanup
ConversionCleanup must be called just prior to returning to the calling COBOL program. It
releases all memory that has been allocated by other conversion functions.
Calling Sequence
Error! Not a valid filename.
ConversionStartup
ConversionStartup must be called once at the beginning of the C function called from
COBOL and should precede all calls to other conversion functions. It allocates a block of
memory for each COBOL argument (based on the value of ArgCount). This block contains
information that must be preserved between calls to other conversion functions. This function
returns TRUE if it is successful and FALSE if there is an error.
Calling Sequence
Error! Not a valid filename.
DiagnosticMode
DiagnosticMode controls the display of error messages during execution. If Flag contains the
value, DF_SILENT, no error messages will be displayed. If Flag contains the value,
DF_VERBOSE, error messages will always be displayed. If Flag contains the value,
DF_NORMAL, the display of error messages is governed by the PF_SILENT flag in each call
to the CodeBridge Library.
Note DiagnosticMode has global scope. It affects all conversion and validation calls until
another DiagnosticMode call is made. Before the first call to DiagnosticMode, the display of
error messages is governed by the PF_SILENT flag in each call to the CodeBridge Library as
if DiagnosticMode had been called with the DF_NORMAL flag value.
Calling Sequence
Error! Not a valid filename.
Flag modifies the display of the error message. Valid flag values for DiagnosticMode are the
following:
Name Value Description
EffectiveLength
EffectiveLength obtains the length of the C string after conversion from the COBOL
argument. This includes removal of leading and/or trailing characters. The value is the same
as the value that would be returned by the C library function, strlen. This function returns
TRUE if it is successful and FALSE if there is an error.
Note The EffectiveLength function may be used only in combination with one of the input
string functions: CobolToGeneralString (on page 135), CobolToNumericString (on page
138), or CobolToString (on page 144). ArgNumber must have the same value in the
EffectiveLength function call and the corresponding input string function call. The call to
EffectiveLength may precede or follow the call to the corresponding input string function.
Calling Sequence
Error! Not a valid filename.
FloatToCobol
FloatToCobol converts from a C floating-point value to the COBOL numeric argument. This
function returns TRUE if it is successful and FALSE if there is an error.
By convention, the CobolToFloat (on page 133) function should be called prior to this
function for the same argument number. Do not set the PF_IN flag for output-only
conversions. Because the call to the CobolToFloat function may perform memory
management operations that are not needed for output-only conversions, this call may be
omitted.
Calling Sequence
Error! Not a valid filename.
• PF_ASSERT_SIGNED • PF_REPEAT
• PF_ASSERT_UNSIGNED • PF_RETURN_VALUE
• PF_NO_SIZE_ERROR • PF_ROUNDED
• PF_OCCURS • PF_SILENT
• PF_OUT
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Parameter is the address of the C parameter. It may also be the address of an array of
floating-point values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Size is the size of the C parameter.
Calling Sequence
Error! Not a valid filename.
Flags modify the behavior of the conversion. The flags available for GeneralStringToCobol
are the union of the flags for NumericStringToCobol and StringToCobol. Some flags, such as
PF_LEADING_MINUS, are ignored for non-numeric strings. Other flags, such as
PF_LEADING_SPACES are ignored for numeric strings. Valid flag values (see Table 8 on
page 120) for GeneralStringToCobol are:
• PF_ASSERT_SIGNED • PF_OUT
• PF_ASSERT_UNSIGNED • PF_REPEAT
• PF_C_DATA_IS_ANSI • PF_RETURN_VALUE
• PF_C_DATA_IS_OEM • PF_ROUNDED
• PF_IN • PF_SILENT
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Parameter is the address of the C parameter. It may also be the address of an array of string
values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Size is the conversion buffer length override when the PF_SIZE flag is set. If the PF_SIZE
flag is not set, the default conversion buffer length is the greater of one more than the length
of the COBOL argument and four more than the digit length of the COBOL argument. The
digit length of a COBOL argument is the sum of the number of 9 and P symbols used in its
PICTURE character-string. The setting of the PF_SIZE flag and the value of the Size
parameter must be the same as specified in the call to CobolToGeneralString (on page 135)
for the same argument.
Value1 is the strip/fill character value if the PF_LEADING_VALUE flag is set.
Value2 is the strip/fill character value if the PF_TRAILING_VALUE flag is set.
GetCallerInfo
GetCallerInfo obtains information about the calling COBOL program. Such information is
particularly useful in error messages because it helps identify the offending CALL statement.
This function returns a pointer to a structure that contains the information about the calling
program.
Calling Sequence
Error! Not a valid filename.
} CALLER_INFO;
Calling Sequence
Error! Not a valid filename.The function has no arguments.
The structure pointed to by the return value is described by a type definition in the supplied
header file rtcallbk.h, which is included by the supplied header file cbridge.h. For reference,
the structure is as follows:
The values in the State field of the TERMINATION_INFO structure have the following
meanings (as defined in rtcallbk.h):
#define TIS_UNKNOWN 0
#define TIS_INITIALIZING 1
#define TIS_RUNNING 2
#define TIS_TERMINATING 3
The ErrorCode and TermMsgs string pointers should never be NULL, but they may point to
empty strings (first character is zero). If the runtime is terminating normally due to executing
a STOP RUN statement in the COBOL program, the ReturnCode will be zero,
the ErrorCode string will be empty, and the normal "COBOL STOP RUN … " message will
be in TermMsgs. If the runtime is terminating due to an error, the ReturnCode will be
non-zero, the ErrorCode string will contain an error code, and the TermMsgs string will
contain as much of the runtime error and traceback messages as will fit in about 1000 bytes.
Multiple messages in the TermMsgs string are separated with a newline character.
IntegerToCobol
IntegerToCobol converts from a C integer value to the COBOL numeric argument. This
function returns TRUE if it is successful and FALSE if there is an error.
By convention, the CobolToInteger (on page 137) function should be called prior to this
function for the same argument number. Do not set the PF_IN flag for output-only
conversions. Because the call to the CobolToInteger function may perform memory
management operations that are not needed for output-only conversions, this call may be
omitted.
Calling Sequence
Error! Not a valid filename.
• PF_ASSERT_SIGNED • PF_RETURN_VALUE
• PF_ASSERT_UNSIGNED • PF_ROUNDED
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Parameter is the address of the C parameter. It may also be the address of an array of integer
values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Scale is the scale value if the PF_SCALED flag is set. It represents the power of ten by which
to divide the C parameter.
Size is the size of the C parameter.
Calling Sequence
Error! Not a valid filename.
• PF_ASSERT_SIGNED • PF_REPEAT
• PF_ASSERT_UNSIGNED • PF_RETURN_VALUE
• PF_NO_SIZE_ERROR • PF_ROUNDED
• PF_OCCURS • PF_SILENT
• PF_OPTIONAL • PF_SIZE
• PF_OUT
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
as equivalent to zero. If the value is greater than 1, we recommend the PF_OCCURS flag be
set, although it is for documentation purposes only.
Parameter is the address of the C parameter. It may also be the address of an array of string
values if the PF_OCCURS flag is set.
Calling Sequence
Error! Not a valid filename.
• PF_OUT • PF_RETURN_VALUE
• PF_POINTER_MAX_SIZE • PF_SILENT
• PF_POINTER_RESET_OFFSET
PointerOffsetToCobol
PointerOffsetToCobol modifies the COBOL pointer argument. The contents of the C
parameter are moved to the offset component. If the PF_POINTER_MAX_SIZE flag is set,
binary ones are moved to the size component. This function returns TRUE if it is successful
and FALSE if there is an error.
Calling Sequence
Error! Not a valid filename.
• PF_OUT • PF_RETURN_VALUE
• PF_POINTER_MAX_SIZE • PF_SILENT
PointerSizeToCobol
PointerSizeToCobol modifies the COBOL pointer argument. The contents of the C parameter
are moved to the size component. If the PF_POINTER_RESET_OFFSET flag
is set, a value of zero is moved to the offset component. This function returns TRUE if it is
successful and FALSE if there is an error.
Calling Sequence
Error! Not a valid filename.
• PF_OUT • PF_RETURN_VALUE
• PF_POINTER_RESET_OFFSET • PF_SILENT
StringToCobol
StringToCobol converts a C null-terminated string to the COBOL non-numeric argument.
This function returns TRUE if it is successful and FALSE if there is an error.
By convention, the CobolToString (on page 144) function should be called prior to this
function for the same argument number. Do not set the PF_IN flag for output-only
conversions. Because the call to the CobolToString function may perform memory
management operations that are not needed for output-only conversions, this call may be
omitted.
Calling Sequence
Error! Not a valid filename.
• PF_C_DATA_IS_ANSI • PF_REPEAT
• PF_C_DATA_IS_OEM • PF_RETURN_VALUE
• PF_LEADING_SPACES • PF_SILENT
• PF_LEADING_VALUE • PF_SIZE
• PF_OCCURS • PF_TRAILING_SPACES
• PF_OUT • PF_TRAILING_VALUE
Occurs is the array size if the C parameter is an array. A value of zero may be specified if the
C parameter is a scalar; negative values for the Occurs parameter are allowed, but are treated
Parameter is the address of the C parameter. It may also be the address of an array of string
values if the PF_OCCURS flag is set.
Repeat is the repeat count if the PF_REPEAT flag is set.
Size is the conversion buffer length override when the PF_SIZE flag is set. If the PF_SIZE
flag is not set, the default conversion buffer length is one more than the length of the COBOL
argument. The setting of the PF_SIZE flag and the value of the Size parameter must be the
same as specified in the call to CobolToString (on page 144) for the same argument.
Value1 is the strip/fill character value if the PF_LEADING_VALUE flag is set.
Value2 is the strip/fill character value if the PF_TRAILING_VALUE flag is set.
This appendix describes the internal details of how a non-COBOL subprogram is called from
an RM/COBOL program running under Windows. While it is possible to write non-COBOL
subprograms that directly use this information to handle COBOL argument conversions, it is
highly recommended that CodeBridge be used for this purpose instead. This appendix also
provides information on preparing a non-COBOL subprogram for use by an RM/COBOL
program on Windows. (For additional information, see the “CALL Statement” section of
Chapter 6: Procedure Division Statements in the RM/COBOL Language Reference Manual.)
Note The information presented here assumes a working knowledge of the C programming
language. The material in Appendix C: Useful C Information (on page 77) is not
comprehensive enough to provide this necessary background.
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 165
1. A single subprogram can be dynamically loaded by the Runtime Command (runcobol)
when that subprogram is called from the RM/COBOL program. The subprogram
remains resident until canceled by the RM/COBOL program or until the end of the run
unit. This method is sometimes referred to as the “call-by-filename” method since the
program is loaded because its file name matches the called program name.
2. One or more subprograms can be linked into a non-COBOL subprogram library (DLL)
and loaded by the Runtime Command upon run unit initialization. The library is loaded
either because it is referenced in an L Runtime Command Option or because it is present
in the rmautold subdirectory of the execution directory. The library remains resident
until the end of the run unit.
The value of the contents of the data item specified by identifier-1 or the value of literal-1 is
the program-name of the subprogram to be called.
166 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
identifier-2 or literal-2 are one or more actual arguments to be passed to the called program.
If the BY CONTENT phrase applies to an argument, a temporary copy of the item is passed,
thus preventing the subprogram from modifying the original item.
identifier-3 is an actual argument to be passed to the called program for the purposes of
returning a result to the calling program.
The RM/COBOL runtime system locates the subprogram with the program-name specified by
literal-1 or the value of the data item referenced by identifier-1. See the discussion of
“Subprogram Loading” in Chapter 8: RM/COBOL Features of the RM/COBOL User’s
Guide, for additional information on locating subprograms.
The subprogram also must be a dynamic-link library file (.dll) and is loaded with the
Windows LoadLibrary function.
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 167
RM_EntryPoints is one of the predefined symbols in an optional support module. For
complete information about all of the predefined symbols, see Special Entry Points for
Support Modules on Windows (on page 178).
Note The ENTRYTABLE typedef is defined in rmc85cal.h, which is provided with
RM/COBOL systems. This header file should be included (with a preprocessor #include
statement) in the C source that defines COBOL-callable subprograms. Inclusion of this
header file will also cause RM_EntryPoints symbol to be exported. Other header files
(rtarg.h, standdef.h, and rmport.h) are referenced by rmc85cal.h. These files are also
provided with RM/COBOL systems. When using CodeBridge Library functions, it is
generally sufficient to include cbridge.h, which includes these other header files.
168 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
name is always uppercase-only, regardless of the case of the name in the calling COBOL
program.
2. Argument count, which is the number of arguments, including arguments explicitly
specified with the OMITTED keyword, specified in the USING phrase of the CALL
statement. The argument in the GIVING (RETURNING) phrase, if specified, is not
included in the count.
3. Pointer to the argument array, which is an array of structures describing each of the actual
arguments passed in the GIVING (RETURNING) and USING phrases of the CALL
statement. The structure of an argument description entry is described in COBOL
Argument Entry Structure for C on Windows (on page 170) and is defined in the
rmc85cal.h header file, which is provided with RM/COBOL systems.
4. Initial state flag, which contains a zero to indicate that the subprogram is being called for
the first time in the run unit or the first time since a CANCEL statement has been
executed for the subprogram name. A nonzero value indicates that the subprogram
should remain in its last used state. It is the responsibility of the called subprogram
(rather than the runtime system) to examine the initial state flag and decide which
variables need to be reinitialized. In any case, on each call, all C automatic variables
are reallocated on the stack without being initialized to any particular value (that is,
C automatic variables have arbitrary values).
5. Windows handle of the calling program window (runtime window), which is needed for
some calls to the Windows Application Programming Interface (API).
6. Pointer to the runtime call-back table, which is a structure that contains the size of the
table, the version number of the table, and a list of subprogram addresses in the runtime.
The CodeBridge Builder uses the call-back table to obtain access to some utility
subprograms in the runtime system. The description of this table is available in
cbridge.h, a header file provided with CodeBridge. The table is named
RUNTIME_CALLS_TABLE.
Note The fifth and sixth parameters are optional. Although the runtime system will always
pass these values, the called subprogram does not have to declare them. The prototype for the
called function may omit the sixth or both the fifth and sixth parameters. The runtime call-
back table is required if the subprogram uses any of the CodeBridge Library functions.
The called subprogram must set an integer return value before returning control to the runtime
system. A value of RM_FND (defined as 0 in rmc85cal.h) indicates that the subprogram was
found and that the runtime should continue executing the COBOL program. A value of
RM_STOP (defined as 1 in rmc85cal.h) indicates that the subprogram terminated because of
a fatal error, such as incorrect parameters, and that the runtime should terminate the run unit.
An explicit return statement should be used to set the return value since otherwise the run unit
might be unintentionally terminated. The subprogram must not terminate with the system
function exit(), since the runtime could not do an orderly shutdown of the run unit in this case.
The argument entry table (arg_vector) contains descriptions of the actual arguments specified
in the CALL statement. The arg_vector[0] entry describes the first actual argument in the
USING phrase of the CALL statement. The arg_vector[arg_count - 1] entry describes the last
actual argument in the USING phrase of the CALL statement. The arg_vector[-1] entry
describes the argument specified in the GIVING (RETURNING) phrase of the CALL
statement. If the GIVING (RETURNING) phrase is omitted from the CALL statement, or
if any actual argument is specified as OMITTED in the USING phrase of the CALL
statement, the corresponding arg_vector entry contains a type value 32 (OMITTED, as shown
in Table 9 on page 171) and the remaining fields are zero.
C subprograms that access the GIVING argument in arg_vector[-1] will function correctly
only for RM/COBOL version 7 (or later) runtimes because prior runtimes did not make a
GIVING argument entry available in arg_vector[-1]. A subprogram that uses the GIVING
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 169
argument should verify that it is available by use of the version number in the runtime call-
back table, the address of which is provided by the sixth parameter to the subprogram. The
version number must be 0x0700 or greater for a GIVING argument to be available.
170 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
Table 9: RM/COBOL Data Types as Numbers
Type Number RM/COBOL Data Type Type Number RM/COBOL Data Type
0 NSE 16 ANS
1 NSU 17 ANS (justified right)
2 NTS 18 ABS
3 NTC 19 ABS (justified right)
4 NLS 20 ANSE
5 NLC 21 ABSE
6 NCS 22 GRP (fixed length)
7 NCU 23 GRPV (variable length)
8 NPP 25 PTR
9 NPS 26 NBSN
10 NPU 27 NBUN
11 NBS 32 OMITTED
12 NBU
Note The data type GRPV (23) does not occur when C$CARG is called with the formal
argument name or when C$DARG is called with an actual argument number that corresponds
to an argument that is a variable-length group. In all other cases, RM/COBOL passes
variable-length group actual arguments as if they were a fixed-length group of the maximum
length. (See Appendix F: Subprogram Library of the RM/COBOL User's Guide.)
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 171
Preparing C Subprograms for Windows
One or more dynamic-link libraries (DLLs) may be loaded and called by the RM/COBOL
runtime system. The DLL may be specified on the command line by using the L Runtime
Command Option, described in the section “Runtime Command Options” in Chapter 7:
Running of the RM/COBOL User's Guide. DLL files may also be placed in the rmautold
subdirectory of the execution directory for automatic loading when the runtime system is
started. The runtime system reads the DLL, locates the entry points, and makes each entry
point available to be called as a subprogram.
If a program-name used in a CALL statement cannot be resolved as a COBOL routine and is
not found in any already loaded non-COBOL library, a search is made for a file with that
name and an extension of .dll. If such a file is found, it is loaded and one of the following
occurs:
• If the DLL exports either of the symbols RM_EnumEntryPoints or RM_EntryPoints,
then the first specified entry point is called. For a definition of these symbols, see Special
Entry Points for Support Modules on Windows (on page 178). Any additional entry
points that these symbols may define are ignored when the DLL is loaded by this method.
Note If the DLL contains an .EDATA section that specifies an entry point exported as
nonresident ordinal one, then that entry point is called. Any other exported entry points
are ignored when the DLL is loaded by this method.
• Otherwise, a procedure error 204 occurs.
3. Create the dynamic-link library using the linker in your C development system.
Use linker options to assign an ordinal value of one to an entry point. The RM/COBOL
172 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
runtime system will associate the DLL filename with entry point one. The procedures in
the DLL are now ready to be called as a subprogram from RM/COBOL.
Note While some C compilers produce case-insensitive entry point names, others
produce case-sensitive entry point names. In addition, some C compilers may pre-pend
or append an underscore character to the entry point name.
Parameters are passed to the DLL, as described in Parameters Passed to the C Subprogram on
Windows (on page 168).
The following code sequences illustrate how a COBOL-callable DLL may be written in C.
Include the standdef.h header file (provided by Micro Focus RM/COBOL) to access
RM/COBOL standard definitions. On Windows systems, inclusion of standdef.h will cause
inclusion of the Microsoft windows.h file, which provides access to Windows operating
system functions such as MessageBox(). Define RMLittleEndian with a value of 1 for the
Intel 80x86 architecture. Include the rmc85cal.h header file to obtain ARGUMENT_ENTRY
structure definition, various type definitions, and LDLONG, LDSHORT, STLONG,
STSHORT macros. Include the cbridge.h header file if the CodeBridge Library is used by
the subprogram. Since cbridge.h includes standdef.h and rmc85cal.h, it is not necessary to
include these header files when cbridge.h is included.
The following is a sample RM/COBOL-callable DLL file written in C, named msgbox.c.
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 173
*
* This source program demonstrates the old (non-CodeBridge)
* method of preparing C subprograms under Windows
* described in Appendix G, "Non-COBOL Subprogram Internals
* for Windows" of the CodeBridge Manual.
*
* The COBOL statement
*
* CALL "MsgBox" USING Message-V, Button-V
*
* may be used to call the C subprogram "MsgBox"
* defined by this source.
*
* The MsgBox source program also demonstrates use of the v7.50
* and later runtime call back GetCallerInfo(), which may
* be used to obtain information about the calling program.
*
* The MsgBox source program also demonstrates the various
* RM_AddOn... entry points that may be specified in a non-COBOL
* subprogram.
*
* Copyright (c) 2017 Micro Focus.
*
* You have a royalty-free right to use, modify, reproduce, and
* distribute this C source file (and/or any modified version)
* in any way you find useful, provided that you retain this notice
* and agree that Micro Focus has no warranty, obligations, or liability
* for any such use of the source file.
*
* Version = @(#) $Revision: 6380 $ $Date: 2008-02-18 13:32:29 -0600 (Mon, 18 Feb 2008) $
*
*******************************************************************************/
#define _MSGBOX_C_ "@(#) msgbox.c $Rev: 6380 $ $Date: 2008-02-18 13:32:29 -0600 (Mon, 18 Feb
2008) $"
#pragma PRAGMA_WHAT_C(_MSGBOX_C_)
WHAT_C(_MSGBOX_C_)
174 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
#define MAX_MESSAGE_LENGTH 100
if ( (l == 2) || (l == 4) )
break;
/* -- else fall through to default */
p = ArgEntry[AN_MSG_V].a_address;
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 175
l = ArgEntry[AN_MSG_V].a_length;
if ( ArgEntry[AN_BTN_V].a_length == 4)
ST_BIT32(lButton, p); /* macro defined in standdef.h */
else
{
sButton = (short) lButton;
ST_BIT16(sButton, p); /* macro defined in standdef.h */
}
176 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
return "MSGBOX. RM/COBOL Message Box Sample DLL.";
}
return Msg;
}
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 177
{
{"MSGBOX", (int (RM_CDECL *)(void))MsgBox, "MsgBox" },
{NULL, NULL, NULL }
};
The MSGBOX.DLL sample can be built in the samples subdirectory using the Microsoft
Visual C++ compiler with the following command line:
DATA DIVISION.
WORKING-STORAGE SECTION.
01 RETURN-BINARY PIC 9(4) Binary(2) Value Zero.
01 DISPLAY-TEXT PIC X(24) Value "Do you wish to continue?".
PROCEDURE DIVISION.
CALL "MSGBOX" USING DISPLAY-TEXT RETURN-BINARY.
178 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
• RM_AddOnTerminate (on page 180)
• RM_AddOnVersionCheck (on page 181)
• RM_EntryPoints and RM_EnumEntryPoints (on page 181)
The following sections describe these entry points and special variables.
RM_AddOnBanner
This entry point, if present, should return a pointer to a character string. This character string
will be displayed along with the runtime system banner message. The support module banner
may be used to display any required copyright notice. The support module banner is
displayed only if the K Option of the Runtime Command is not present.
Note The Windows runtime supports the “call-by-filename” loading of DLLs, as described in
Methods of Using Non-COBOL Subprograms (on page 165). For DLLs loaded in this
manner, the RM_AddOnBanner entry point is not called and no banner is produced. The
entry point is called and a banner is produced if the DLL is loaded because of the L Runtime
Command Option or because the DLL is present in the rmautold subdirectory of the
execution directory.
Function declaration for RM_AddOnBanner:
char* RM_AddOnBanner(void);
RM_AddOnCancelNonCOBOLProgram
This entry point, if present, is called by the runtime system when a CANCEL verb is executed
for a program-name that is defined in the optional support module. It allows the support
module to do any cleanup actions that may be necessary. For example, this entry point might
be specified to allow the support module to close any open files when the COBOL program
cancels the associated non-COBOL subprogram. The program-name of the non-COBOL
subprogram for which a CANCEL has been performed is passed as a parameter to the entry
point.
Function declaration for RM_AddOnCancelNonCOBOLProgram:
RM_AddOnInit
This entry point, if present, is called to initialize the optional support module. All support
modules will be initialized (if initialization is requested) before the runtime system begins
executing the first COBOL program, except that DLLs loaded by the “call-by-filename”
method will be initialized when they are loaded at the time they are referenced by a CALL
statement. For more information, see Methods of Using Non-COBOL Subprograms (on page
165).
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 179
The entry point should return zero to indicate successful initialization or a non-zero value to
indicate that the support module initialization failed. If the initialization fails, the runtime
system will display an appropriate message and then terminate.
Note If the support module determines that successful initialization is not possible, the
support module should produce appropriate messages to allow the user to correct the problem.
The support module is passed the Runtime Command line arguments in the arguments Argc
(the argument count) and Argv (the argument vector). The support module is also passed a
pointer to the runtime call back table.
Function declaration for RM_AddOnInit:
RM_AddOnLoadMessage
This entry point, if present, should return a pointer to a character string that is displayed along
with the load messages of other optional support modules. These load messages allow the
user to verify which support modules the runtime system has loaded. The message may
contain text to identify the support module and, if desired, the version number or the build
date. Load messages are displayed only if the V Runtime Command Option is present, the
V=DISPLAY keyword-value pair is specified in the RUN-OPTION configuration record, or
the RM_DYNAMIC_LIBRARY_TRACE environment variable is defined.
If load messages are being displayed, the runtime system generates a load message consisting
of the complete pathname for the support module regardless of whether the
RM_AddOnLoadMessage entry point is defined or not defined in the support module. If the
RM_AddOnLoadMessage entry point is defined, the returned string is appended to the
pathname in this load message.
Note The Windows runtime supports the “call-by-filename” loading of DLLs, as described in
Methods of Using Non-COBOL Subprograms (on page 165). For DLLs loaded in this
manner, the RM_AddOnLoadMessage entry point is not called and no load message is
produced. The entry point is called and a load message is produced if the DLL is loaded
because of the L Runtime Command Option or because the DLL is present in the rmautold
subdirectory of the execution directory.
Function declaration for RM_AddOnLoadMessage:
char* RM_AddOnLoadMessage(void);
RM_AddOnTerminate
This entry point, if present, is called by the runtime system during termination. Execution of
all COBOL programs is complete when the runtime system calls this entry point. It allows
the optional support module to perform any cleanup actions that may be necessary.
Note The Windows runtime supports the “call-by-filename” loading of DLLs, as described in
Methods of Using Non-COBOL Subprograms (on page 165). DLLs loaded with this method
will be unloaded when a CANCEL statement references them. In this case, the
RM_AddOnTerminate entry point is called just prior to unloading the DLL, after having
called RM_AddOnCancelNonCOBOLProgram, and the runtime system is not necessarily
about to terminate.
180 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
The RM_AddOnTerminate function is called when the module is unloaded, even if the
RM_AddOnInit function (on page 179) for the module did not succeed. Thus, the code for
this function must not depend on the success of the RM_AddOnInit function.
Function declaration for RM_AddOnTerminate:
void RM_AddOnTerminate(void);
RM_AddOnVersionCheck
This entry point, if present, provides a method of verifying that the runtime system and the
optional support module are compatible.
If RM_AddOnVersionCheck is not present, the support module is assumed to support the
current interface version of the runtime system that calls the support module.
If RM_AddOnVersionCheck is present, it will be passed a version string, two support
module interface versions, and a pointer for the support module to store a desired interface
version. The version string (for example, 9.0n.nn) is defined by the VERSION macro in the
header file version.h (provided with the RM/COBOL system). The runtime support module
interface versions indicate the minimum and maximum versions that the runtime system can
support. The RM/COBOL runtime system (version 7.50 or later) supports support module
interface versions 1 and 2. For Windows, these two interface versions are identical. In the
future, the runtime system may support other, partially or completely incompatible, interface
versions.
It is the responsibility of the support module to verify that it supports one of the interface
versions supported by the runtime system and to return the interface version it supports. If the
support module does not support any of the interfaces supported by the runtime system, the
support module should return FALSE (0). In this case, or if the support module returns an
invalid interface version, the runtime system will display an appropriate message and then
terminate. Returning TRUE (1) and an interface version in the range supported by the
runtime system allows the runtime system to continue. The support module may use the
current interface version by returning the value
CURRENT_SUPPORT_MODULE_INTERFACE_VERSION (defined in the supplied
header file, rmc85cal.h).
The support module may also use the value of the version string to verify compatibility with
the runtime system. If the support module determines that it is not compatible with the
runtime system, it should return FALSE. In this case, the support module might display a
meaningful message before the runtime system displays its message and terminates.
Function declaration for RM_AddOnVersionCheck:
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 181
in the DLL. If the .EDATA section is found, the exported names listed in the .EDATA
section are considered to be COBOL-callable functions; otherwise, the DLL is considered not
to contain any COBOL-callable functions.
The use of the subprogram name table RM_EntryPoints is described in the section
C Subprogram Name Table Structure on Windows (on page 167).
If the entry point RM_EnumEntryPoints is found, it is called repeatedly to obtain the
COBOL-callable names, function addresses, and function names of the COBOL-callable
functions in the support module. This function should return a pointer to a structure that is
equivalent to one entry in the RM_EntryPoints table. The end of the entry points is
indicated by returning a null pointer or a structure whose first pointer is NULL. The index
parameter starts at zero for the first call and is incremented for each subsequent call.
If both symbols are present, RM_EnumEntryPoints takes precedence.
See the example RM_EntryPoints for Windows (on page 168) for the symbol declaration for
RM_EntryPoints.
Function declaration for RM_EnumEntryPoints:
182 • Appendix G: Non-COBOL Subprogram Internals for Windows CodeBridge User's Guide
The Watcom debugger allows you to set a breakpoint that is triggered when the module
containing the DLL is loaded. Once it has been loaded, the source for the module can be
viewed and additional breakpoints can be set. For more information, see the documentation
supplied with the debugger you are using.
CodeBridge User's Guide Appendix G: Non-COBOL Subprogram Internals for Windows • 183
Appendix H: Non-COBOL
Subprogram Internals for UNIX
This appendix describes the internal details of how a non-COBOL subprogram is called
from an RM/COBOL program running under UNIX. While it is possible to write non-
COBOL subprograms that directly use this information to handle COBOL argument
conversions, it is highly recommended that CodeBridge be used for this purpose instead. This
appendix also provides information on preparing a non-COBOL subprogram for use by an
RM/COBOL program on UNIX. (For additional information, see the “CALL Statement”
section of Chapter 6: Procedure Division Statements in the RM/COBOL Language Reference
Manual.)
Note The information presented here assumes a working knowledge of the C programming
language. The material in Appendix C: Useful C Information (on page 77) is not
comprehensive enough to provide this necessary background.
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 185
Calling C Subprograms from COBOL for UNIX
This section describes the COBOL CALL syntax and explains how a C programmer
can write a subprogram that can be called from RM/COBOL. The COBOL CALL
statement explains the use of the non-COBOL subprogram from the COBOL programmer’s
perspective while the other topics describe the structures and the function prototype that the C
programmer needs to understand.
The value of the contents of the data item specified by identifier-1 or the value of literal-1 is
the program-name of the subprogram to be called.
identifier-2 or literal-2 are one or more actual arguments to be passed to the called program.
If the BY CONTENT phrase applies to an argument, a temporary copy of the item is passed,
thus preventing the subprogram from modifying the original item.
identifier-3 is an actual argument to be passed to the called program for the purposes of
returning a result to the calling program.
The RM/COBOL runtime system locates the subprogram with the program-name specified by
literal-1 or the value of the data item referenced by identifier-1. See the discussion of
“Subprogram Loading” in Chapter 8: RM/COBOL Features of the RM/COBOL User's Guide,
for additional information on locating subprograms.
186 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
RM_EntryPoints is one of the predefined symbols in an optional support module. For
complete information about all of the predefined symbols, see Special Entry Points for
Support Modules on UNIX (on page 195).
Note The ENTRYTABLE typedef is defined in rmc85cal.h, which is provided with
RM/COBOL systems. This header file should be included (with a preprocessor #include
statement) in C source that defines COBOL-callable subprograms. Other header files
(rtarg.h, standdef.h, and rmport.h) are referenced by rmc85cal.h. These files are also
provided with RM/COBOL systems.
int sub1
(
char *name, /* param1 */
unsigned short arg_count, /* param2 */
ARGUMENT_ENTRY arg_vector[], /* param3 */
unsigned short initial_state, /* param4 */
void *reserved, /* param5 */
RUNTIME_CALLS_TABLE callbacktable /* param6 */
);
Note The above function prototype does not work on Windows. See Declaring the C
Function Return Value and Parameters (on page 202) for a function that does work for either
Windows
or UNIX.
The six parameters are described as follows:
1. Pointer to the called program-name, which is a null-terminated ASCII string
containing the name used by the run unit to identify the called subprogram. The called
program-name is always uppercase-only, regardless of the case of the name in the calling
COBOL program.
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 187
2. Argument count, which is the number of arguments, including arguments explicitly
specified with the OMITTED keyword, specified in the USING phrase of the CALL
statement. The argument in the GIVING (RETURNING) phrase, if specified, is not
included in the count.
3. Pointer to the argument array, which is an array of structures describing each of the actual
arguments passed in the GIVING (RETURNING) and USING phrases of the CALL
statement. The structure of an argument description entry is described in COBOL
Argument Entry Structure for C on UNIX (on page 189) and is defined in the rtarg.h
header file, which is provided with RM/COBOL systems.
4. Initial state flag, which contains a zero to indicate that the subprogram is being called for
the first time in the run unit or the first time since a CANCEL statement has been
executed for the subprogram name. A nonzero value indicates that the subprogram
should remain in its last used state. It is the responsibility of the called subprogram
(rather than the runtime system) to examine the initial state flag and decide which
variables need to be reinitialized. In any case, on each call, all C automatic variables
are reallocated on the stack without being initialized to any particular value (that is,
C automatic variables have arbitrary values).
5. Pointer value NULL (for compatibility with Windows non-COBOL subprograms).
6. Pointer to the runtime call-back table, which is a structure that contains the size of the
table, the version number of the table, and a list of subprogram addresses in the runtime
system. The CodeBridge Builder uses the call-back table to obtain access to some utility
subprograms in the runtime system. The description of this table is available in
rtcallbk.h, a header file provided with RM/COBOL systems. The table is named
RUNTIME_CALLS_TABLE.
Note The fifth and sixth parameters are optional. Although the runtime system will always
pass these values, the called subprogram does not have to declare them. The prototype for the
called function may omit the sixth or both the fifth and sixth parameters. The runtime call-
back table is required if the subprogram uses any of the CodeBridge Library functions.
The called subprogram must set an integer return value before returning control to the runtime
system. A value of RM_FND (defined as 0 in rtarg.h) indicates that the subprogram was
found and that the runtime system should continue executing the COBOL program. A value
of RM_STOP (defined as 1 in rtarg.h) indicates that the subprogram terminated because of a
fatal error, such as incorrect parameters, and that the runtime system should terminate the run
unit. An explicit return statement should be used to set the return value since otherwise the
run unit might be unintentionally terminated. The subprogram must not terminate with the
system function exit(), since the runtime system could not do an orderly shutdown of the run
unit in this case.
Once an optional support module is loaded, it remains loaded until the runtime system
terminates. Use of the CANCEL statement to cancel a C subprogram sets the initial flag to
zero on the next entry into the subprogram, but has no effect on the values of the external and
static variables used in the C subprogram.
The argument entry table (arg_vector) contains descriptions of the actual arguments specified
in the CALL statement. The arg_vector[0] entry describes the first actual argument in the
USING phrase of the CALL statement. The arg_vector[arg_count - 1] entry describes the last
actual argument in the USING phrase of the CALL statement. The arg_vector[-1] entry
describes the argument specified in the GIVING (RETURNING) phrase of the CALL
statement. If the GIVING (RETURNING) phrase is omitted from the CALL statement, or
if any actual argument is specified as OMITTED in the USING phrase of the CALL
statement, the corresponding arg_vector entry contains a type value 32 (OMITTED, as shown
in Table 10 on page 190) and the remaining fields are zero.
188 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
C subprograms that access the GIVING argument in arg_vector[-1] will function correctly
only for RM/COBOL version 7 (or later) runtimes because prior runtimes did not make a
GIVING argument entry available in arg_vector[-1]. A subprogram that uses the GIVING
argument should verify that it is available by use of the version number in the runtime call-
back table, the address of which is provided by the sixth parameter to the subprogram. The
version number must be 0x0700 or greater for a GIVING argument to be available.
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 189
a_picture specifies the lowest addressed byte of the encoded picture for edited items (type of
argument equals 0, 20 or 21). It is set to zero for all other types.
Type Number RM/COBOL Data Type Type Number RM/COBOL Data Type
0 NSE 16 ANS
1 NSU 17 ANS (justified right)
2 NTS 18 ABS
3 NTC 19 ABS (justified right)
4 NLS 20 ANSE
5 NLC 21 ABSE
6 NCS 22 GRP (fixed length)
7 NCU 23 GRPV (variable length)
8 NPP 25 PTR
9 NPS 26 NBSN
10 NPU 27 NBUN
11 NBS 32 OMITTED
12 NBU
Note The data type GRPV (23) does not occur when C$CARG is called with the formal
argument name or when C$DARG is called with an actual argument number that corresponds
to an argument that is a variable-length group. In all other cases, RM/COBOL passes
variable-length group actual arguments as if they were a fixed-length group of the maximum
length. (See Appendix F: Subprogram Library of the RM/COBOL User's Guide.)
190 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
For example, suppose a CALL statement specifies one argument in its USING list and this
argument refers to a three-byte numeric unsigned (NSU) data item with a PICTURE
character-string of 99V9. The following is a diagram of the structure in C.
pointer to char
argument address
argument [3]
argument length 3
type 1
digit count 3
implied decimal -1
In the second case, it is necessary to determine which C subprogram has been called. The
following example illustrates one way this might be accomplished.
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 191
#include "rmc85cal.h"
int library
(
char *name,
unsigned short arg_count,
ARGUMENT_ENTRY arg_vector[],
unsigned short initial_state
);
ENTRYTABLE RM_EntryPoints[] =
{
{"SUBA", (int (*)())library, "library" },
{"SUBB", (int (*)())library, "library" },
{NULL, (int (*)())NULL, NULL }
};
int library
(
char *name,
unsigned short arg_count,
ARGUMENT_ENTRY arg_vector[],
unsigned short initial_state
)
{
int entry_no;
const int MAX_ENTRIES =
(sizeof(RM_EntryPoints)/sizeof(RM_EntryPoints[0])) - 1;
192 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
)
break; /* matching name found */
}
switch ( entry_no )
{
case 0: /* "SUBA" called */
/*
* "SUBA" code goes here
*/
return RM_FND;
default:
return RM_STOP; /* logic error, stop run unit */
}
}
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 193
Linking a support module for IBM AIX requires both an “import” file, runcobol.imp, to
make RM/COBOL runtime system symbols available and an “export” file to make support
module symbols available. The runcobol.imp file is supplied with the RM/COBOL
development and runtime systems for IBM AIX. The “export” file must be provided by the
user. A sample export file, libusr.exp, is also provided with the RM/COBOL release as an
example of what the user must provide. The makefile includes appropriate loader options to
use the import and export files when building support modules on IBM AIX.
A separate “samples” makefile is provided with the RM/COBOL development system in the
cbsample subdirectory. This makefile has targets that are called by the various script files
used to demonstrate CodeBridge. Additional information about the CodeBridge samples may
be found in the README.txt file in the CodeBridge samples directory. For the remainder of
this section, makefile refers to the makefile that is present in the main installation directory
(normally, /usr/rmcobol) rather than the special CodeBridge “samples” makefile.
Assuming a C source file named usrsub.c, the following command generates the subprogram
object file and links a shared object to be used as an optional support module with the runtime
system:
Note Filenames of optional support modules must be unique even if the modules are located
in different directories. The runtime system assumes that support modules with the same
name are the same and, therefore, ignores all subsequent support modules with the same name
as one already loaded.
If your optional support module uses functions from the C library that are not also used by the
runtime system, you will see a message similar to the following when the runtime system tries
to load the support module:
194 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
Creating a Support Module from a C Object (No Source)
If you have old C subprograms that you have been linking into the runtime system, but no
longer have the source (to be able to build a shared object), it may still be possible to build a
shared object from the old object (.o) file. You will need to write a C wrapper module. You
can use usrsub.c as a starting point, which is the method used in the remainder of this topic.
Modify the entry points table to include the COBOL-callable name(s) of the C functions you
wish to access in the old object. Then modify the entry points table to reference the proper
C function(s) name(s) (the UNIX command nm may help you determine the function names).
Finally, include an extern declaration for the C function names in the usrsub.c source as
follows:
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 195
Note On UNIX, only the RM_EntryPoints symbol declaration (or the
RM_EnumEntryPoints entry point) is required for an optional support module. All other
entry points are optional.
The following sections describe these entry points and special variables.
RM_AddOnBanner
This entry point, if present, should return a pointer to a character string that will be displayed
along with the runtime system banner message. The support module banner may be used to
display any required copyright notice. The support module banner is displayed only if the K
Option of the Runtime Command is not present.
Function declaration for RM_AddOnBanner:
RM_AddOnCancelNonCOBOLProgram
This entry point, if present, is called by the runtime system when a CANCEL verb is executed
for a program-name that is defined in the optional support module. It allows the support
module to do any cleanup actions that may be necessary. For example, this entry point might
be specified to allow the support module to close any open files when the COBOL program
cancels the associated non-COBOL subprogram. The program-name of the non-COBOL
subprogram for which a CANCEL has been performed is passed as a parameter to the entry
point.
Function declaration for RM_AddOnCancelNonCOBOLProgram:
RM_AddOnInit
This entry point, if present, is called to initialize the optional support module. All support
modules will be initialized (if initialization is requested) before the runtime system begins
executing the first COBOL program. The entry point should return zero to indicate successful
initialization or a non-zero value to indicate that the support module initialization failed. If
the initialization fails, the runtime system will display an appropriate message and then
terminate.
Note If the support module determines that successful initialization is not possible, the
support module should produce appropriate messages to allow the user to correct the problem.
The support module is passed the shell command line arguments in the arguments Argc (the
argument count) and Argv (the argument vector). The support module is also passed a pointer
to the runtime call back table if the support module interface version is set to 2.
Function declaration for RM_AddOnInit for interface version 1:
196 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
RM_AddOnLoadMessage
This entry point, if present, should return a pointer to a character string that is displayed along
with the load messages of other optional support modules. These load messages allow the
user to verify which support modules the runtime system has loaded. The message may
contain text to identify the support module and, if desired, the version number or the build
date. Load messages are displayed only if the V Runtime Command Option is present, the
V=DISPLAY keyword-value pair is specified in the RUN-OPTION configuration record, or
the RM_DYNAMIC_LIBRARY_TRACE environment variable is defined.
If load messages are being displayed, the runtime system generates a load message consisting
of the complete pathname for the support module regardless of whether the
RM_AddOnLoadMessage entry point is defined or not defined in the support module. If the
RM_AddOnLoadMessage entry point is defined, the returned string is appended to the
pathname in this load message.
Function declaration for RM_AddOnLoadMessage:
RM_AddOnTerminate
This entry point, if present, is called by the runtime system during termination. Execution of
all COBOL programs is complete when the runtime system calls this entry point. It allows
the optional support module to perform any cleanup actions that may be necessary.
The RM_AddOnTerminate function is called when the module is unloaded, even if the
RM_AddOnInit (on page 196) for the module did not succeed. Thus, the code for this
function must not depend on the success of RM_AddOnInit function.
Function declaration for RM_AddOnTerminate:
RM_AddOnVersionCheck
This entry point, if present, provides a method of verifying that the runtime system and the
optional support module are compatible.
If RM_AddOnVersionCheck is not present, the support module is assumed to support the
current interface version of the runtime system that calls the support module.
If RM_AddOnVersionCheck is present, it will be passed a version string, two support
module interface versions, and a pointer for the support module to store a desired interface
version. The version string (for example, 8.0n.nn) is defined by the VERSION macro in the
header file version.h (provided with the RM/COBOL system). The runtime support module
interface versions indicate the minimum and maximum versions that the runtime system can
support. The RM/COBOL runtime system (version 7.50 or later) supports support module
interface versions 1 and 2. For UNIX, these two interface versions differ only in the
arguments passed to RM_AddOnInit, as documented in the description of that special entry
point (on page 196). Interface version 1 was the support module interface version supported
by the version 7.10 runtime system. Interface version 2 is the new current support module
interface version supported by version 7.50 or later runtime systems. In the future, the
runtime system may support other, partially or completely incompatible, interface versions.
It is the responsibility of the support module to verify that it supports one of the interface
versions supported by the runtime system and to return the interface version it supports. If the
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 197
support module does not support any of the interfaces supported by the runtime system, the
support module should return FALSE (0). In this case, or if the support module returns an
invalid interface version, the runtime system will display an appropriate message and then
terminate. Returning TRUE (1) and an interface version in the range supported by the
runtime system allows the runtime system to continue. The support module may use the
current interface version by returning the value
CURRENT_SUPPORT_MODULE_INTERFACE_VERSION (defined in the supplied
header file, rmc85cal.h).
The support module may also use the value of the version string to verify compatibility with
the runtime system. If the support module determines that it is not compatible with the
runtime system, it should return FALSE. In this case, the support module might display a
meaningful message before the runtime system displays its message and terminates.
Function declaration for RM_AddOnVersionCheck:
198 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
added to it. For example, if the name of the C function is MessageBox, the name of the
generated function is RMDLLMessageBox.
It is possible for a C function that calls the CodeBridge Library functions directly also to call
functions that were built by the CodeBridge Builder. A C function could call
RMDLLMessageBox directly either by using the ARGUMENT_ENTRY structure that was
passed from RM/COBOL or by constructing one that suited the needs of the C function.
One use of this capability would be to hide conversions of C data items to COBOL data items.
Example 6: Converting Buffered C Data (on page 67) describes a case in which such
conversions are necessary even though CodeBridge is being used. In that example, the
function cstring2text is called from COBOL to convert data stored in a buffer by a C function
call. This conversion could be hidden from the RM/COBOL program by embedding the
conversion in a C function that first calls the C function to store the data in the buffer and then
also calls the generated C function, RMDLLcstring2text.
C Subprogram Example
The C subprogram usrsub.c has been provided with your distribution media as an example of
the predefined symbols and entry points used in creating optional support modules (shared
objects). As distributed, usrsub.c does nothing of interest, but does serve as a template for
developing an optional support module of your own. Remember, only the RM_EntryPoints
symbol declaration (or the RM_EnumEntryPoints entry point) is required. All other entry
points are optional.
Note The special entry points, SYSTEM, DELETE, and RENAME, which were included in
the C source sub.c on previous releases of RM/COBOL, are not present in usrsub.c. These
COBOL-callable functions are now part of the runtime system and are fully documented in
Appendix F: Subprogram Library of the RM/COBOL User’s Guide.
CodeBridge User's Guide Appendix H: Non-COBOL Subprogram Internals for UNIX • 199
Runtime Functions for Support Modules
RM/COBOL provides user-supplied C subprograms with entry points to some COBOL
functions. The following routines use the standard C calling and parameter passing
conventions:
• RmForget (int y1, int x1, int y2, int x2). This function marks the indicated area of
screen memory as unknown. By doing so, the next COBOL display to that area will not
be optimized based on the screen contents. This allows COBOL output to be correctly
displayed over C subprogram output, which is not stored in the in-memory screen image.
This routine requires four int parameters (two line and position pairs), which specify the
upper-left (y1,x1) and lower-right (y2,x2) coordinates of the area of the screen to be
marked as unknown. Valid values range from 0 to the line or position limit of the screen.
Passing zero values mark the entire screen as being unknown. See C$Forget in Appendix
F of the RM/COBOL User's Guide for more information. The function returns an int
value of 0 for success.
• RmRepaintScreen(). This function causes the RM/COBOL runtime system to redraw
the entire current screen from an in-memory image. C routine output is erased. This
function requires no parameters and does not return a value. See the REPAINT-
SCREEN keyword of the CONTROL phrase in Chapter 8: RM/COBOL Features of the
RM/COBOL User's Guide for more information.
• RmRefreshCwd(). This function causes the RM/COBOL runtime system to refresh its
internal copy of the current working directory. This internal copy is used to construct
complete filenames from any filename that is not fully qualified. This function should be
called before returning to the COBOL program if a non-COBOL subprogram changes the
current working directory with the chdir() C library routine. The RmRefreshCwd()
routine has no parameters and does not return a value.
• setunit(). This function restores the terminal to the state the RM/COBOL runtime system
requires for terminal I/O. If the resetunit() function is called, the setunit() function must
be called before returning to the runtime system. This function requires no parameters
and does not return a value.
• resetunit(). This function places the terminal in a “normal state” (that is, the state before
the RM/COBOL runtime system was executed). This function should be used if any
terminal I/O is going to be performed, including operating system commands that use the
terminal. This function requires no parameters and does not return a value.
200 • Appendix H: Non-COBOL Subprogram Internals for UNIX CodeBridge User's Guide
Appendix I: Calling the
CodeBridge Library Directly
This appendix provides guidelines for calling the CodeBridge Library directly rather than
having the CodeBridge Builder generate the interface code from a template file. In order to
call the CodeBridge Library directly, you must use an alternate method for preparing non-
COBOL subprograms, as described either in Appendix G: Non-COBOL Subprogram
Internals for Windows (on page 165) or Appendix H: Non-COBOL Subprogram Internals for
UNIX (on page 185).
Note The information presented here assumes a working knowledge of the C programming
language. The material in Appendix C: Useful C Information (on page 77) is not
comprehensive enough to provide this necessary background.
Overview
In describing direct calls to the CodeBridge Library, the following topics are covered:
• Including cbridge.h (on page 202)
• Declaring the C function return value and parameters (on page 202)
• Specifying the COBOL argument number (on page 203)
• Declaring C data items used in the conversion process (on page 203)
• Initializing and terminating the conversion process (on page 206)
• Converting COBOL arguments to C data items (on page 207)
• Converting C data items to COBOL arguments (on page 209)
• Validating properties of COBOL arguments (on page 211)
Following these discussions, see the example (on page 212) of calling the CodeBridge Library
directly.
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 201
Including cbridge.h
Instead of including rmc85cal.h, include cbridge.h (which includes rmc85cal.h). cbridge.h
defines the following:
• Values for the Flags parameter used for most CodeBridge Library functions
• CodeBridge internal conversion table (CONV_TABLE)
• Runtime entry point table (RUNTIME_CALLS_TABLE)
• Function prototype of each CodeBridge Library function
• Initialization and termination logic for the generated interface DLL (for Windows)
{
/* function implementation goes here */
return RM_FND;
}
FunctionName is the name of the C function. The function return value must be declared as
an int. The value returned to the calling COBOL program must be either RM_FND or
RM_STOP, as described in the parameters passed to the C subprogram on Windows (on page
169) and UNIX (on page 188).
pCalledName is the Name parameter used for the ConversionStartup (on page 147)
CodeBridge Library function.
ArgCount is the ArgCount parameter used for most CodeBridge Library functions.
Arguments is the Arguments parameter used for most CodeBridge Library functions.
InitialState could be used as the Flags parameter for the CobolInitialState (on page 133)
CodeBridge Library function, but normally would be used directly by the code.
hRtWindow is the window handle for the runtime on Windows and could be used as the
WindowsHandle parameter for the CobolWindowsHandle (on page 146) CodeBridge Library
function, but normally would be used directly by the code. On UNIX, hRtWindow is a
placeholder that should not be used since there is no window handle on UNIX.
202 • Appendix I: Calling the CodeBridge Library Directly CodeBridge User's Guide
pRtCall points to the runtime entry point table and is used to locate CodeBridge Library
functions. For example, you could call DiagnosticMode (on page 148) as follows:
pRtCall->pDiagnosticMode(DF_SILENT);
The C subprogram table structure, which defines the COBOL-callable entry points, references
the function name as follows:
ProgramName is the name used in the COBOL program to call the C function. For more
information on the C subprogram name table, see C Subprogram Name Table Structure on
Windows (on page 167) or C Subprogram Name Table Structure on UNIX (on page 186).
Note The macros RM_DLLEXPORT, RM_CDECL, and RM_HWND, are defined in
rmc85cal.h (which is included by cbridge.h) to aid in writing code that will compile on both
Windows and UNIX.
Numeric Conversions
C numeric data items can receive and supply values for Numeric conversions. See the
CobolToFloat (on page 133), CobolToInteger (on page 137), FloatToCobol (on page 150),
and IntegerToCobol (on page 155) CodeBridge Library functions. For C numeric data items,
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 203
you must define both the data item and a pointer to the data item. The pointer must be
initialized with the address of the data item as follows:
The pointer is required so that null-valued COBOL pointers can be passed to the C function
and converted properly.
Note Because of the way numeric data items are declared (to handle null-valued pointers),
you must adjust the way you pass C numeric data items by reference to other C functions.
Normally you would pass &Name, but when using CodeBridge you must pass pName instead.
If an array of numbers is to be passed, you must define a numeric array. To pass an array of
five long integers, use the following definition:
String Conversions
C strings can receive and supply values for String conversions. See the
CobolToGeneralString (on page 135), CobolToNumericString (on page 138), CobolToString
(on page 144), GeneralStringToCobol (on page 151), NumericStringToCobol (on page 157),
and StringToCobol (on page 161) CodeBridge Library functions. To use C strings in the
conversion process, define an uninitialized string pointer as follows:
type *pString;
where,
type is a C string type (such as char, signed char, or unsigned char).
pString is the name of the string pointer.
Because the actual storage for each C string is allocated dynamically by the CodeBridge
Library, it is not necessary to define storage for the string.
If an array of strings is to be passed, you must define an array of string pointers. To pass an
array of five strings, use the following definition:
char *pMyStringArray[5];
Address Conversions
C pointers can receive and supply values for Address conversions. See the
CobolDescriptorAddress (on page 129), CobolToPointerAddress (on page 140),
CobolToPointerBase (on page 141), and PointerBaseToCobol (on page 159) CodeBridge
Library functions. For Address conversions, define a
C pointer as follows:
204 • Appendix I: Calling the CodeBridge Library Directly CodeBridge User's Guide
type *pCobolData;
where,
type is the C data type used for references to the COBOL data.
pCobolData is the name of the pointer to the COBOL data.
Note Be careful when using Address conversions. The address returned in pCobolData may
be used to directly manipulate COBOL data. It is better to use Numeric and String
conversions, which require less knowledge of COBOL data formats to accomplish the same
purpose.
Other Conversions
Other conversions, such as the BufferLength (on page 127), CobolDescriptorDigits (on page
129), CobolDescriptorLength (on page 130), CobolDescriptorScale (on page 131),
CobolDescriptorType (on page 132), CobolToPointerLength (on page 142), and
EffectiveLength (on page 149) CodeBridge Library functions, do not convert to and from
COBOL arguments. Instead, they obtain (or set) auxiliary information about COBOL
arguments or components of RM/COBOL pointer arguments. They are handled in the same
manner as Numeric conversions without requiring the additional pointer definition.
type Name;
where,
type is a C numeric type (such as int, unsigned short, or double).
Name is the name of the C numeric data item.
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 205
BufferLength and EffectiveLength conversions allow arrays to be passed.
Trivial Conversions
You can call the CodeBridge Library conversion functions, CobolArgCount (on page 128),
CobolInitialState (on page 133), or CobolWindowsHandle (on page 146), to convert
ArgCount, InitialState, or hRtWindow to a C data item. However, this is a trivial conversion
because you must pass the value to the corresponding CodeBridge Library function so that the
function can store it in the C data item you provide. For example:
short WindowsHandle2;
if (!RtCall->pCobolWindowsHandle (0,
(void *)WindowsHandle2,
sizeof (WindowsHandle2),
WindowsHandle))
{ RtCall->pConversionCleanup(ArgCount, pConvTable);
return(RM_STOP);
}
is equivalent to (though slower and more difficult to understand than):
CONV_TABLE *pConvTable;
Initialization
Before calling any other CodeBridge Library functions, the C function must initialize the
conversion process by calling ConversionStartup as follows:
if(!RtCall->pConversionStartup(ArgCount, &pConvTable,
pCalledName, Version))
return(RM_STOP);
Note Version is the CodeBridge Library version (for example, for version 9, use 0x900).
The ConversionStartup call illustrates two general properties of calling CodeBridge Library
functions. First, CodeBridge Library functions are called indirectly through pointers in the
RUNTIME_CALLS_TABLE, RtCall. Adding the prefix “p” to the CodeBridge Library
function name forms the name of the pointer. In the code above, the full reference is:
206 • Appendix I: Calling the CodeBridge Library Directly CodeBridge User's Guide
RtCall->pConversionStartup(…)
Second, most CodeBridge Library functions return TRUE to indicate success or FALSE to
indicate failure. A failure condition indicates that processing should not continue. Hence, the
previously listed sequence:
if(!RtCall->pConversionStartup(…))
return(RM_STOP);
Termination
Just before returning to the calling COBOL program, the C function must terminate the
conversion process by calling ConversionCleanup as follows:
RtCall->pConversionCleanup(ArgCount, pConvTable);
Note Because a program may have many exits, be sure that ConversionCleanup is called
prior to each exit.
For example, the code will typically contain sequences such as:
if(!RtCall->pCodeBridgeLibraryFunction(…))
{ RtCall->pConversionCleanup(ArgCount, pConvTable);
return(RM_STOP);
}
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 207
Specifying the ArgCount, ArgNumber, and Arguments
Parameters
The ArgCount and Arguments parameters are presented and described in Declaring the C
Function Return Value and Parameters (on page 202). The ArgNumber parameter is
explained in Specifying the COBOL Argument Number (on page 203).
For all other input conversions, the Parameter parameter must be:
208 • Appendix I: Calling the CodeBridge Library Directly CodeBridge User's Guide
Specifying Other Parameters
Input String conversion functions, as well as BufferLength and EffectiveLength, require that
pConvTable, the pointer to the CodeBridge conversion table be passed in the ConvTable
parameter. For more information, see Initializing and Terminating the Conversion Process
(on page 206).
For a discussion of the Flags parameter, see Specifying the Flags Parameter (on page 120).
For conversion functions that support passing arrays, the Occurs parameter is the array size.
The PF_OCCURS flag should be set if the value of this parameter is greater than one.
For Numeric and String conversions, the Omitted parameter is the default value for omitted
COBOL arguments when the PF_VALUE_IF_OMITTED flag is set. Otherwise, if the
PF_OPTIONAL flag is set, the default value for Numeric conversions is zero and the default
value for String conversions is the empty string(""). If neither the
PF_VALUE_IF_OMITTED flag nor the PF_OPTIONAL flag is set, an error occurs for an
omitted argument.
For Numeric and String conversions, the Repeat parameter specifies the repeat count when
the PF_REPEAT flag is set.
See the CobolToInteger (on page 137) CodeBridge Library function for a discussion of the
Scale parameter.
For non-numeric String conversions, the Value1 parameter specifies the strip/fill character
when the PF_LEADING_VALUE flag is set. Likewise, the Value2 parameter specifies the
strip/fill character when the PF_TRAILING_VALUE flag is set.
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 209
Specifying the Parameter Parameter
For FloatToCobol and IntegerToCobol conversions, the Parameter parameter must be:
210 • Appendix I: Calling the CodeBridge Library Directly CodeBridge User's Guide
For conversion functions that support passing arrays, the Occurs parameter is the array size.
The PF_OCCURS flag should be set if the value of this parameter is greater than one.
For Numeric and String conversions, the Repeat parameter specifies the repeat count when
the PF_REPEAT flag is set.
See the IntegerToCobol (on page 155) CodeBridge Library function for a discussion of the
Scale parameter.
For non-numeric String conversions, the Value1 parameter specifies the strip/fill character
when the PF_LEADING_VALUE flag is set. Likewise, the Value2 parameter specifies the
strip/fill character when the PF_TRAILING_VALUE flag is set.
These functions may be used with either input or output arguments. The functions can be
called anytime after the call to ConversionStartup (on page 147) and before
ConversionCleanup (on page 146).
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 211
Follow the guidelines for conversion functions when specifying parameters for validation
functions, as described in Converting COBOL Arguments to C Data Items (on page 207) and
Converting C Data Items to COBOL Arguments (on page 209).
Note Instead of calling AssertSigned or AssertUnsigned, the following functions may set the
PF_ASSERT_SIGNED or PF_ASSERT_UNSIGNED flags to verify that the COBOL
argument is signed or unsigned: CobolToFloat, CobolToGeneralString, CobolToInteger,
CobolToNumericString, FloatToCobol, GeneralStringToCobol, IntegerToCobol, and
NumericStringToCobol.
Example
The following example illustrates calling the CodeBridge Library directly.
#include "cbridge.h"
#define CLEANUP pRtCall->pConversionCleanup(ArgCount, pConvTable)
extern void DoTest01(int *OutInteger, char *InOutString);
RM_DLLEXPORT int RM_CDECL Test01(char *pCalledName,
unsigned short ArgCount,
ARGUMENT_ENTRY Arguments[],
unsigned short InitialState,
RM_HWND hRtWindow,
RUNTIME_CALLS_TABLE *pRtCall)
{ int OutInteger; int *pOutInteger = &OutInteger;
char *InOutString;
CONV_TABLE *pConvTable;
212 • Appendix I: Calling the CodeBridge Library Directly CodeBridge User's Guide
if(!pRtCall->pConversionStartup(ArgCount, &pConvTable,
pCalledName, 0x900))
return RM_STOP;
DoTest01(pOutInteger, InOutString);
if(!pRtCall->pStringToCobol(ArgCount, 1, Arguments,
(PF_OUT | PF_TRAILING_SPACES), 0,
InOutString, 0, 0, '\0', '\0'))
{ CLEANUP; return RM_STOP; }
CodeBridge User's Guide Appendix I: Calling the CodeBridge Library Directly • 213
Appendix J: Summary of
Enhancements
This appendix provides a summary of the new features and changes in the various releases of
CodeBridge. The enhancements and changes for the most recent release described by this
document are listed first.
Note The information in this appendix is historical. It was accurate at the time written for the
specific version being described. Various features may have changed in later releases, and,
possibly, some features may have been removed.
Version 12 Enhancements
Version 12 of CodeBridge provides the CodeBridge User’s Guide, Second Edition as the base
document for the CodeBridge component in RM/COBOL version 12, and it covers the
CodeBridge cross-language calling features at the time of the version 12 release.
This release also includes several defect corrections, and the product complies with the
RM/COBOL 12 release level.
Version 11 Enhancements
Version 11 of CodeBridge includes several defect corrections, and the product complies with
the RM/COBOL 11 release level. It also includes support for Microsoft Windows Vista.
Version 10 Enhancements
In version 10, the CodeBridge Library was enhanced to eliminate some 16-bit limits inherent
in its coding. The CodeBridge Library is built into the version 10 RM/COBOL runtime
system and these limits are relaxed in the version 10 runtime. The limits were not discussed
in the CodeBridge User’s Guide, First Edition. The limits were, for the most part, closely
correlated with existing limits for the OCCURS clause in versions 9 and earlier of
RM/COBOL. The CodeBridge Library needed to conform to the removal of such limits in
the version 10 runtime system.
The rtcallbk.h file, used with CodeBridge during support module compilation, was enhanced
in version 10 to properly export the entry points of a module built with CodeBridge Builder
Version 9 Enhancements
Version 9 of CodeBridge includes several defect corrections, and the product complies with
the RM/COBOL 9 release level.
In addition, two new parameter attributes, the base modifier attributes c_data_is_ansi and
c_data_is_oem, have been added to CodeBridge to support conversion of C string data
to/from the COBOL native character set on Windows. In RM/COBOL version 9, the COBOL
native character set for a run unit on Windows can be based on the OEM or ANSI system
codepage. (Prior to version 9, the native character set for a run unit on Windows was
assumed to be based on the OEM system codepage.) Frequently, C strings are based on the
ANSI codepage for Windows, particularly when used with Windows system functions. Thus
COBOL character data passed as an argument to a C routine parameter may need conversion
from OEM to ANSI and C string data returned to the COBOL program argument may need
conversion from ANSI to OEM.
Prior to the addition of the new base modifier attributes, these conversions, if necessary, were
the responsibility of the COBOL program. If the new base modifier attributes are specified in
the template, CodeBridge will now perform the conversions automatically when transferring
argument and parameter values. CodeBridge uses the native character set of the COBOL run
unit to decide if a conversion is necessary when one of these base modifier attributes is
specified. If neither of the new base modifier attributes is specified, no conversion is done,
regardless of the character set for the COBOL run unit, thus matching the prior behavior of
CodeBridge. The new attributes are ignored on UNIX so that a common template can be
shared between Windows and UNIX development environments. For a more detailed
discussion of these attributes, refer to Appendix E: Parameter Attributes (on page 89).
Version 8 Enhancements
Version 8 of CodeBridge included several defect corrections, and the product complies with
the RM/COBOL version 8 release level.
Argument
In CodeBridge documentation, the term “argument” refers to the COBOL data item specified
in the USING or GIVING phrase of a CALL statement. Contrast with parameter (on page
223).
Attribute
The individual descriptors used to construct an attribute list in a template file for the
CodeBridge Builder.
Attribute list
A block of information in a template file that provides information to the CodeBridge builder
regarding the relationship between a COBOL CALL statement and a C function prototype.
There are two kinds of attribute list, global and parameter.
Call convention
A specification of how a C function is called. Call conventions for C functions called from
RM/COBOL require the use of the convention global attribute in a template file.
CodeBridge Builder
The component of CodeBridge that takes a template file as input and produces the C code that
can be compiled and linked to produce a support module for the RM/COBOL runtime.
CodeBridge Library
The set of functions in the RM/COBOL runtime that implement data conversion for a support
module. Calls to these functions can be generated using a template file as input to the
CodeBridge Builder or can be written manually by the user.
Data type
The declaration of the form a particular data item takes in computer storage and how the value
is to be interpreted. CodeBridge supports basic COBOL data types such as numeric, non-
numeric, and pointer data items and C data types such as integer (int, char, short, long),
floating-point (float, double), and null-terminated strings (char *). Because of information
available to the CodeBridge Library at execution time, the specific data type modifiers of a
numeric COBOL argument, such as its usage (BINARY, PACKED-DECIMAL, DISPLAY,
and so forth), and any accompanying precision and scale are not needed by the CodeBridge
Builder.
Direction attribute
An attribute that specifies the conversion direction for a parameter attribute list: in or out.
Both can be specified in the case of an input-output parameter. The in attribute means the
COBOL argument is an input to the C parameter. The out attribute means the COBOL
argument receives an output from the C parameter. In some cases, such as certain base
attributes, a direction attribute is implied and cannot be specified.
DLL
Dynamic-Link Library, the Microsoft Windows form of a dynamically-loadable support
module.
Omitted argument
A COBOL argument that is not supplied in the CALL statement, either because it is specified
as OMITTED or is omitted from the end of the list of possible arguments that could be
specified in the USING phrase of the CALL statement.
Parameter
In CodeBridge documentation, the term “parameter” refers to the C data item specified in the
C function header and prototype. The return value is also considered a parameter. Contrast
with argument (on page 221).
Parameter attribute
An attribute used in a parameter attribute list. There are four categories of parameter
attribute: argument number, base, base modifier, and direction,
P-scaling
The effect of using the P symbol in the PICTURE character-string of a COBOL data item.
Prototype
The C definition of the manner in which a function is called, including the return data type,
name, and parameter data types for the function. A calling convention may also be included.
Shared object
The UNIX form of a dynamically-loadable support module (on page 224). Shared object files
usually have the extension .so.
Template file
The source file created by a developer to specify to the CodeBridge Builder how to call a C
function from COBOL. Attribute lists are specified within modified C function prototypes in
the template file.
Index
All caps, as a document convention 3
arg_count base attribute
allowed combinations (table) 112
associating an implied argument 33
defined 101
passing information to a C function 29
arg_num(value) argument number attribute
allowed combinations (table) 112
associating C parameters with COBOL arguments
19, 32
defined 89
Argument number attributes 19, 112
- (hyphen), use of arg_num(value) 89
in C compiler options 81 associating C parameters with COBOL arguments
optional, in RM/COBOL compilation and runtime 19, 32
options 4 ret_val 89
Arguments, COBOL
argument number attributes 19, 89, 112
# argument properties, passing to a C function
# (pound sign), use of, in global attribute lists 18 COBOL descriptor data 27
#include C preprocessor directives 11, 44, 47, 77 string length information 28, 102
C parameters, associating with 19, 89
automatic 33
/
examples of 34
/ (forward slash), use of, in C compiler options 81 explicit 32
defined 11
digit length 28, 38, 43
[
group
[ ] (brackets), use of fixed-length 25
in COBOL syntax 3 variable-length 25
in global attribute lists 18 miscellaneous information, passing to a C function
in parameter attribute lists 18 29
omitted arguments, managing 29
… passing to a C function
non-numeric arguments 24
… (ellipsis), use of, in variable number of C null-valued pointer arguments 26
parameters 37, 95, 98 numeric arguments 21
pointer arguments 25, 100
A Arrays
converting C
ACCEPT statement (Terminal I-O), CONTROL floating-point parameters 22
phrase, REPAINT-SCREEN keyword 200 integer parameters 22
address base attribute numeric string parameters 23
allowed combinations (table) 112 string parameters 24
defined 101 working with
managing omitted arguments 29 COBOL array references 43
passing COBOL descriptor data 27 numeric 41, 92
passing the address of the COBOL data 40 string 42, 96
Address component, COBOL pointer argument 21, assert_digits(min,max) base modifier
25, 40, 100 defined 93
alias(name) base modifier assert_digits_left(min,max) base modifier
defined 91 defined 94
U
Unions or structures, as parameters 21
example of 64
unsigned base modifier, defined, for integer numeric
only 95
USING phrase, CALL statement 12, 90
OMITTED keyword 169, 188
Using this manual 9