A valuable feature of procedure bodies written in C is that they can directly manipulate any of the tables and variables used within the QA Build program. The essential links between the data addresses in the Program Interpreter (PROGRUN) and those in the C Exit can be established either at compile time, giving a PROGRUN capable of running just one program, or at run time, giving a PROGRUN capable of running many programs. The first type is called a dedicated PROGRUN, and the second a generic PROGRUN.
It is easier to write a dedicated PROGRUN, because you do not have to write any code to assign addresses. With a dedicated PROGRUN, however, there are overheads during development, as you have to recompile and link your C code every time you change your QA Build program. For this reason we recommend that you master the generic technique first and only to use the dedicated technique as a way of producing a final program that runs faster. If you wish to have C Exits in overlaid programs you must use a generic PROGRUN, because each overlay is an independent program.
| 1 | Setup QA Build program | To call a C procedure body create a procedure body of type Link to C |
| 2 | Compile QA Build Program | Select the program you want to compile. At the end of compilation press Esc. Do not generate a .C file |
| 3 | Generate C Procedure Interface | Use the QA Build Program Compiler to generate the C procedure interface. Accept the default settings. A file called QCBODY.C will be generated |
| 4 | Create table definitions | Create a file with #pointer and #table definitions and run LIBMAKE to produce a .H file |
| 5 | Write .C file | For each C procedure body write a function to perform the required processing. Include the .H file created in step 4 |
| 6 | Compile all the source files | Use your C compiler to compile QCBODY.C and the source files containing your C functions |
| 7 | Create .LNK file | Create a file called GPROGRUN.LNK which consists of this
line: progrun qcbody <your C modules> |
| 8 | Link the modules | Link using the DP4-supplied batch file: QABLINK GPROGRUN This will create an executable program called GPROGRUN which contains all the functionality of PROGRUN plus C exits |
| 9 | Run the generic progrun | Use the following command: GPROGRUN Specify the database and any program |
| 1 | Setup QA Build program | To call a C procedure body create a procedure body of type Link to C |
| 2 | Compile QA Build Program | Select the program you want to compile. Do not generate a C function interface or a C procedure interface |
| 3 | Generate the .C file | At the end of the program compilation you will be prompted to generate a file. Accept the defaults. A file will be created with the same name as the program, and with include statements for the .H and .QAC files |
| 4 | Run LIBMAKE | LIBMAKE reads the database and sets up table declarations and
some initial processing in a file with extension .H. Use the
following command: LIBMAKE DPROGRUN.C |
| 5 | Write C functions in .QAC file | For each C procedure body write a function to perform the required processing. Give the .QAC file the same name as the QA Build program |
| 6 | Compile the C program | Use your C compiler to compile the .C file |
| 7 | Link executable program | Use the QABLINK.BAT batch file supplied with DP4: (Do not link
PROGRUN.OBJ) QABLINK DPROGRUN This will create an executable program called DPROGRUN |
| 8 | Run the dedicated PROGRUN | Use the following command: DPROGRUN |
In the instructions, the name DPROGRUN is given to the QA Build program calling the C exit
If you modify the data dictionary of a QA Build program, you will have to repeat the whole process. This is one reason for using a generic PROGRUN during development.
Because many of the processes are the same for both types of PROGRUN, the following account combines the two, highlighting the steps that are specific to one type.