Back in the 1980s, I created a program called Partner, a productivity tool that included a calendar, a notepad, an adding machine, a command-line interceptor, and an expression analyzer. These applications popped up in different windows to provide a PC-style windowing environment. As far as I know, Partner was the first commercial 5250 application with pop-up windows.

An interesting application in that package was its expression analyzer. This component allowed users to type in a free-format mathematical expression and receive the result. You could even extend the functions by adding your own. That is, Partner did user-written procedures years before ILE was being considered by Paul Remtema and at least a decade before IBM considered adding subprocedures to RPG IV.

The types of math functions Partner was able to perform included high-level mathematical operations, such as sine, cosine, and arctangent hyperbolic. To perform these math functions in RPG, I called an MI program that used the "compute math function" and "compute math function 2" instructions.

While the Partner software continues to run and work on i5/OS more than 20 years after it was first introduced, the ability to perform high-level math continues to elude the RPG IV language even today. Or has it?

With the integration of RPG IV and ILE and the ability to call subprocedures and functions written in other programming languages, IBM has opened up RPG to extensions beyond what is officially implemented in the language.

While I've written about the C runtime library before, the math portion of the C library is intriguing. It supports a rather complete set of high-level math functions that can be utilities from within RPG IV very effectively.

By creating the prototypes for the C math runtime library and binding with the QC2LE binding directory, any high-level math function can be utilized from within RPG.

For example, to calculate the sine of a number, you could use the following:

Aside from the lack of a leading percent sign (%), these math functions, like all C runtime library functions, work much like built-in functions.

The C math functions have a more programmer-friendly parameter list than the set of CEExxxx math APIs; however, one or two more math functions are available using the APIs.

To illustrate, I've repeated the call to the sine function below, using the API convention. The API name to calculate a sine is CEESDSIN.

A few differences exist between the C runtime math library and the i5/OS math APIs.

• The binding directory QC2LE is not required for the CEExxxx APIs (it is required for the C runtime library functions).
• The C functions return their results via a return value, whereas the APIs require a second parameter to receive the result of the operation.
• The APIs accept the standardized API error data structure to trap errors; the C functions do not.

The CEExxxx APIs have more flexibility and more choices than the C math functions library, and certainly those additional features are important to compiler writers. But the C functions are much easier to use and should probably be the choice people make when selecting high-level math functions.

As with all CEExxxx APIs, the math APIs' object code is embedded directly into the generated *MODULE object. That is, although a call to the API is coded by the programmer, the compile "inlines" the object code of the API rather than inserting a subprocedure call. This occurs with any API that is prefixed with the letters "CEE" or an underscore (_) .

In my upcoming book RPG TNT: 101 Dynamite Tips and Techniques for RPG IV Programmers, the prototypes for all CEExxxx math APIs as well as the C math functions are included. For space purposes in this article, I've included only the prototypes for the C runtime library math functions below.

High-level mathematical function prototypes: