Using quad-FX with Aux Processors

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 123

1. Introduction¶

⎕FX is commonly used in large APL systems for overlaying code in workspaces, fixing local functions containing system specific code etc. ⎕FX is used as a form of “compiler” which allows the conversion of parameter driven systems into hard-coded systems. If any of the parameters have to be changed during the life of the system, the functions can simply be re-fixed using ⎕FX.

⎕FX can also be of use in connection with shared variable processing in an analogous way. In many functions using shared variables, the names of the shared variables are passed as an argument. The function then uses execute to assign or use the shared variables. Typical of this type of implementation are the IBM supplied functions for use in association with AP123.

2. Shared Variable Processing¶

The use of execute for processing shared variables arises as a result of the dichotomy inherent between the use of the NAME of the variable and the use of the VARIABLE itself:

• At share offer/retraction the NAME is used.
• During processing the VARIABLE is assigned/referenced.

Since the name of the shared variable may change, any function used to cover the use of shared variables must use execute to assign or use the correct variable. This is especially true if more than one set of shared variables is to be used, in which case the names of the shared variables to be used will probably be passed as an argument to the cover function, or as a global variable.

An example of this form of implementation is readily available in the IBM supplied workspace VSAMDATA, which makes use of AP123 to access VSAM clusters. Other examples of the use of execute abound in the IBM supplied workspaces which are involved in shared variable processing.

It is especially desirable to avoid execute in situations such as reading or writing files since the volumes of data input/output (and hence the number of times the executes are processed) is potentially very large. Consider also that up to 3 executes may be involved per file operation – this is certainly true for the VSAM data AP, AP123. To read data:

• Assignment of the read command to the “control” variable.
• Use of the “control” variable to check the return code.
• Use of the “data” variable to retrieve the data.

To write data:

• Assignment of the data to the “data” variable.
• Assignment of the write command to the “control” variable.
• Use of the “control” variable to check the return code.

3. Using ⎕FX¶

To avoid the use of execute, a function must be created which contains the references to the control and data shared variables explicitly. The function is created and fixed at the time the shared variables are offered to the auxiliary processor.

The following terminology is used. Each function associated with a single set of shared variables is referred to as a “PATH”. A path is created by “LINKING” to the auxiliary processor and is destroyed by “UNLINKING”. The functions listed at the end of the article, link a new path (VSAMLINK) and unlink an existing path (VSAMUNLINK) with the VSAM auxiliary processor, AP123. The right argument to both functions is the name of the path to be linked or unlinked. The result is a boolean return code, 0 if the action was successful, 1 otherwise.

The pathname is used by the LINK function to customise:

• The names of the shared variables.
• The name of the PATH function.

Both sets of names also reflect the auxiliary processor in use, so no name clashes will result if multiple auxiliary processors are used as well as multiple paths per processor. The key function in the LINK process is the VSAMGEN function, the version listed uses features of APL2, but there is no reason why it could not be recoded using VS APL.

The function created by the VSAMGEN function is also listed, essentially it simply assigns values to the control and data shared variables and returns a two item nested vector (APL2 again!). The explicit result consists of the value from the control variable as the first item, with that from the data variable as the second item.

In VS APL, one of the shared variables would have to be referenced as a global variable since nested arrays are not available. As an alternative, a second niladic function could be generated to return the value of the other variable as its explicit result. The pathname used in the example functions to link to the path is “TEST”, the function generated is called VSAMTEST, and is used for all subsequent file I/O operations. At the end of file processing, the path is unlinked by using the VSAMUNLINK function.

One result of using the PATH name to customise the shared variable names is that multiple shares with the same AP can easily be achieved. When using the VSAM AP, this allows multiple VSAM clusters to be open at the same time. Contrast this with the approach taken by the IBM supplied functions which always close a file before allowing another to be opened. Similar techniques, if applied to the QSAM and BDAM auxiliary processors would allow multiple file access using these protocols too.

4. Other Benefits¶

The command system implemented using the VSAMGEN function is identical to that for AP123 itself – there is no processing overhead interpreting the commands used. Also, using APL2, the EACH operator can be used to execute many commands without writing looping code. Allowing, for example, many read or write operations to be undertaken without the associated overheads of looping.

User written operators could be used to read or write data from/to a file until a non-zero return code, such as end-of-file, is received (problems with WS FULL may result of course).

The ability to use APL2 operators arises because the same function is used for all file based operations, with only the argument values changing. Arguments can be applied repeatedly without having to reference different functions. In contrast, the approach taken in the VSAMDATA supplied workspace is that of “keywords”, different functions being used to achieve each VSAM operation. When using the keyword approach, there is little or no opportunity to make use of the functional enhancements provided by APL2 operators.

It is worth noting that even in VS APL, the command controlled function can result in more efficient, compact code. For example, it would be relatively simple to rewrite the generated function so that it could either use a vector or array command argument. In the case of an array, each row could be used in turn until the array is exhausted. The only looping code involved in this type of implementation is inside the generated function, rather than in the application code.

A further benefit of the command approach rather than the “keyword” function approach is the reduction in the number of objects (and the volume of code) that has to be copied into the workspace. The only permanent code in the workspace when using the example functions are the LINK, UNLINK and GEN functions. During processing, the path access functions are also created. All these functions are relatively short, so the volume of code involved is small.

The largest function listed is that giving the text associated with the different error codes that may arise. Since an application will typically contain its own error checking and messaging, it may not be necessary to have this function in the workspace at all.

5. Extending the concept¶

There is no need to restrict the use of ⎕FX to the avoidance of execute for variable names, function execution is also amenable to the technique.

Mainframe APL provides no in-built mechanism for translating input data from binary, packed or other S/370 formats into APL data formats. A frequent requirement when processing files is the translation of such data, functions are provided in one of the IBM supplied workspaces for this purpose. Before the translation is performed, the record must be separated into its component fields.

A function can easily be generated, which, given a series of field names, lengths and translation requirements will take an input record, extract the fields and translate the data into APL format. The translated data can either be returned as a vector representing the data, or in a series of global variables, one per field. The reverse process can be used for writing records back to the file in S/370 data formats.

The generation of two functions (one for input and one for output) given the layout of the record as input is a relatively trivial problem. The gains in performance by avoiding use of the execute function to perform translation and assignment into the explicit result (or the global variables representing the fields within the record) will be considerable. This is all the more important since it is likely that, as with any file processing, large volumes of data will be processed.

6. Conclusions¶

The system function ⎕FX can be used to replace the use of the execute function in many situations. It acts as a form of “compiler” to hard-code the references to variables which would otherwise be referenced through execute.

Some overhead is incurred in the use of ⎕FX as the function being fixed is verified and established in the workspace. It is important therefore that ⎕FX is used in those situations where the gains from the avoidence of execute will outweigh the costs of using ⎕FX.

This technique will be of most use in situations where the execute would be invoked many times. Typical of these are file processing applications where relatively large volumes of file I/O are involved.

Other situations where execute is used, such as the conditional execution of a line of code do not lend themselves to this technique. None the less execute is probably better avoided in these cases.