You can mix QA Build with C in several ways. Although the techniques can be mixed, it is helpful initially to consider them separately:
You can call a QA Build program from a C program. For example, you may choose to write a high level menu program in C, because it needs to behave in ways you cannot achieve with QA Build. This technique is easy to use, but a disadvantage is that the QA Build programs cannot access the data of the calling C program. See Calling QA Build Programs from C.
You can write functions in C and add them to the QA Build function library. They are called from formulas in QA Build in the same way as DP4-provided functions. They access data from the QA Build program using value parameters and return a single value. For example, you might write a function NPV (net present value) for use in financial calculations. When you have written it and combined it into your Program Interpreter (PROGRUN), you can call NPV in the same way as you call standard DP4 functions such as SUM. See Adding Custom Functions to PROGRUN.
You can write QA Build procedure bodies in C instead of QA Build. They are called in the same way as ordinary QA Build procedure bodies. Your C code can access all the data of the QA Build program. For example, you might want to read data from an ASCII file in a QA Build program –at present QA Build does not support access to ASCII files. You could write a procedure body to open and read the file in C and then use the read data as required in the QA Build program. See Combining Procedure Bodies and Functions.
(This one applies only to Legacy Operating systems, and to 4.624) You can rebuild PROGRUN to accept a different maximum size of QA Build program. You can increase or decrease the size of the array used for storing the executing QAB program to either allow for larger programs or to save memory. See Changing the Maximum Program Size
Functions and procedure bodies written in C by users and called by PROGRUN are known as C exits.
Many QAB users build large and complex applications using only the standard QA Build facilities. The reason for this reluctance to mix C and QA Build is that each specially generated PROGRUN carries its own individual maintenance obligation.
Calling a QA Build program from a C program is easy, within the competence of any C programmer.
Altering the maximum size of QA Build programs involves only changing a constant, recompiling and linking. It requires no programming skill.
The other uses of C mentioned above entail pointers to access data; you must be competent with pointer manipulation and the use of casts. In a typical application you require only a small number of C functions or procedure bodies in comparison with the amount of work to be done in QA Build. In some organisations one skilled C programmer does this work as a service to a team of QA Build developers.