Program Compilation, Link-Edit and Execution › Linking Multiple Modules with SQL

Linking Multiple Modules with SQL

Suppose you have the following situation:

• You have a batch COBOL main program named PGMMAIN that is not SQL.
• You have a COBOL subprogram named PGMSUB that is SQL.
• You preprocess PGMSUB, compile PGMSUB, and catalog the object to a library.
• You compile PGMMAIN (no preprocessing was necessary because it is non-SQL) and link the load module in this order:
  • INCLUDE DBSBTPR (from the library)
  • INCLUDE PGMSUB (from the library)
  • INCLUDE PGMMAIN (from the compiler output)
  • ENTRY BEGIN

Note: Use DBSU1PR instead of DBSBTPR if program is AMODE=31 and RMODE=ANY.

Given the previously described situation, the User Requirements Table gets control first, because it has an entry named BEGIN. It then passes control to the entry named DBMSCBL, because that is what the stub URT DBSBTPR (or DBSU1PR) is set up to do. In this scenario, however, the main program is never executed, because CA Datacom/DB passes control directly to the subprogram, and the program abends when (if not before) the subprogram attempts to return to the main program.

To avoid this, you need to design the link-edit so that the CA Datacom/DB User Requirements Table gets control first. The User Requirements Table that is used first then needs to point to the entry point of the main program that is to be executed next. The main program subsequently calls the subprogram, the subprogram returns to the main program, and when the main program ends it returns to the User Requirements Table. After that, the User Requirements Table program finishes and returns control to the operating system.

There are two ways to ensure that the scenario described in the previous paragraph happens:

1. Option 1: You can continue using User Requirements Table DBSBTPR (or DBSU1PR) and compiling and linking programs as before.

   The objective here is to make the entry point to which DBSBTPR (or DBSU1PR) is pointing be the entry point of the main program, not the subprogram. To accomplish this, do the following:

   1. In the main program, add ENTRY DBMSCBL at the appropriate point in the code.
   2. If the main program involved has parameters and thus has:

      PROCEDURE DIVISION USING parm1 parm2 ... parmn

      the USING clause should be copied onto the ENTRY DBMSCBL so that it becomes:

      ENTRY DBMSCBL USING parm1 parm2 ... parmn

   3. In the subroutine, remove the ENTRY DBMSCBL statement. Replace it with another entry point name. This is done with the SQL preprocessor option USRNTRY=. Specify something other than DBMSCBL. Do not let it default, since DBMSCBL is the default, and we do not want two modules going into the link-edit with the entry point DBMSCBL.
   4. Link edit the main program, including the User Requirements Table DBSBTPR (or DBSU1PR), the other modules as desired (PGMSUB and PGMMAIN), and ENTRY BEGIN.
2. Option 2: Create another stub User Requirements Table instead of using DBSBTPR (or DBSU1PR).

   The objective here is to create another stub User Requirements Table that points to an entry point (other than DBMSCBL) in the main program. To accomplish this, do the following:

   1. Create a User Requirements Table with no files specified. Choose USRNTRY= to be the appropriate entry point of the main program. See the CA Datacom/DB Database and System Administration Guide for instructions on creating User Requirements Table's.
   2. Link edit the main program, including the new User Requirements Table (using whatever name you chose), other modules as desired (PGMSUB and PGMMAIN), and ENTRY BEGIN.

   Remember, if the call to the SQL subprogram is being added to the main program at this point, and the main program does not use DATACOM, the "main" program is actually now running as a subprogram to the User Requirements Table program, and you should therefore use GOBACK instead of STOP RUN in the main program.

Note: A benefit of using option 1 for situations such as this is that you can probably use standard link-edit JCL for all programs. Option 2 requires the use of another stub User Requirements Table, either one such User Requirements Table per main non-SQL program that calls SQL subprograms, or one stub User Requirements Table for all such non-SQL main programs that call SQL subprograms. Also with option 2, the INCLUDE statements have to be different in the link-edit jobs if different stub User Requirements Table's were used.