Using the indep Option for Interlanguage Communication

Interlanguage Communication Considerations

This section discusses some programming conventions you need to consider when using interlanguage communication.

In a sophisticated application, you may need to do additional processing after the C execution framework has been created. For example, you may need to initialize values in one or more of the user words in the CRAB. If you do this, you need to know details of the initialization process implemented by L$UMAIN.

After L$UMAIN has created the C execution framework, it calls the initial C function (the function that invoked L$UPREP) again. That function in turn passes control to L$UPREP again. Normally, at this point L$UPREP determines that the C framework is already accessible and allows the initial function to begin execution. However, you can modify L$UPREP to detect this second call and to complete its own initialization at that time. (Inspection of the sample L$UPREP source code is recommended.)

To recognize this second call and distinguish it from other calls, compare the address of the caller's DSA (R13 on entry to L$UPREP) with the contents of CRABMDSA. If they are equal, L$UPREP was invoked from L$UMAIN. This is the most reliable test because CRABMDSA usage is not expected to change in future releases of the compiler and library.

Using the longjmp Function in a Multilanguage Program

When you have a multilanguage program compiled with the indep option, you ordinarily cannot use longjmp to transfer control from one routine to another if this would terminate a non-C routine. If you attempt this, a user ABEND 1224 results. This restriction is imposed because longjmp cannot guarantee that bypassing the normal return from the non-C routine will not cause random failures in non-C code.

If your application requires the use of longjmp in this fashion, you can modify the L$UPREP routine to remove this restriction. However, if you do so, be aware that this may cause unpredictable results later in execution, depending on the implementation of function linkage in the other language.

Reentrancy

L$UPREP uses an assembler macro named L$UCENV to locate the area where the CRAB address is saved. The L$UCENV macro sets R12 to the address where the CRAB address should be saved. As provided, the L$UCENV macro uses a CSECT named L$UCENV to store the CRAB address. For this reason, programs that use L$UPREP as provided are self-modifying and, therefore, are non-reentrant.

If your application requires reentrancy, you need to modify L$UPREP to save the CRAB address in a different manner. For example, if the language that calls C provides a user word, as PL/I does, L$UPREP can be made reentrant by modifying it to save the CRAB address in the user word. In most cases, a modification to L$UCENV is all that is required to achieve reentrancy.

Note that the version of L$UPREP provided by CICS stores the CRAB address in the first word of the Transaction Work Area (TWA) so that CICS application programs compiled when the indep option is specified will be reentrant; this is a CICS requirement. A transaction which invokes a C program compiled with the indep option must be defined with a TWA.

Note: Programs that modify external data such as FORTRAN COMMONs or PL/I STATIC EXTERNAL variables are inherently non-reentrant. There is no point in making L$UCENV reentrant in such programs. [cautionend]

main Function Considerations

Ordinarily, when you call C functions from another language, there is no C main routine because the program is composed of a main routine in the other language combined with C and other subroutines. Sometimes it is necessary to have a C main function, usually because an existing C program is being modified to be called from another language. This section describes the special considerations in such a case.

When you link code compiled with indep with a C function named main , the main function normally must also be compiled with indep . This means that L$UPREP is called to create the C execution framework if it does not exist and to save the CRAB address for later access by the L$UCENV macro. In this special case, the C execution framework is terminated when main returns. Therefore, you do not need to call L$UEXIT after a call to a main function.

When the compiler processes a function named main , the corresponding external symbol is named @MAIN. When you call a main function compiled with indep from another language, you must use this entry point name. Use of the name MAIN (without @) passes control directly to the run-time library on program entry, bypassing L$UPREP and L$UCENV for framework initialization. This means that necessary information is not stored for use by later non-C calls to C.

One difficulty that can arise when you call a main function from another language is that storage referenced by L$UCENV may not always exist at the time that main is called. This situation can occur, for example, if L$UCENV references a user word provided by another language and C code is invoked before any code in the other language. In this case, if possible, you should change the processing order so that required storage can be allocated before main is called (by calling the other language before C).

If it is not possible to change the processing order, an alternative technique can be used in which you compile the main function without indep . Then, the C execution framework is created by L$CMAIN when the C main function is invoked. The fact that storage may not be available does not matter because a main routine that is not compiled with the indep option does not invoke L$UPREP. In addition, you must store the CRAB address yourself before any C function compiled with indep is called so that it can be accessed by L$UCENV. To do this, you need to write an assembler routine and invoke it after the other storage is accessible (for example, after the other language's execution framework has been created) and before any C functions compiled with indep are called.

Note: The technique above is not directly applicable to SPE. [cautionend]

Chapter Contents
Previous
Next
Top of Page