Substitutable Arguments in Procedures

The variable pool is common across all procedures so one way to pass information from one procedure to the next is to put it into a variable. That is, one procedure can store values in variables that other procedures inspect or use and vice-versa.

An alternate method of passing information to a procedure is via substitutable arguments. A procedure can have up to nine arguments when invoked. The syntax is

procedure-name [arg1,...,arg9]

A procedure definition can contain up to nine dummy arguments that are replaced with real values at the time the procedure is invoked. Dummy arguments are indicated by %1, %2, ..., %9. An example is the following procedure definition which we will name REORG (short for reorganize):

FILL A {%1}
UNLOAD A {%1} * TEMP
RAZE {%1}
LOAD {%1} * TEMP
STRUCTURE/P

This definition is now a prototype definition which contains the dummy argument %1. This procedure is explained further below but for now it is sufficient to say that it is designed to operate on a Table.

The specific table name is supplied at invocation time. For example:

REORG CUSTOMERS

will execute this procedure as shown below.

FILL A CUSTOMERS
UNLOAD A CUSTOMERS * TEMP
RAZE CUSTOMERS
LOAD CUSTOMERS * TEMP
STRUCTURE/P

If you have more than one dummy argument the rule for substitution is as follows:

The first argument stated at invocation time replaces all occurrences of %1 encountered in the prototype definition, the second argument stated will replace all occurrences of %2 in the prototype definition, and so on.

The following is background information to illustrate the usefulness of the procedure shown above. Feel free to skip this if you are not interested in the subject at this time.

The technique in loading or appending records into a Table is to keep on adding them at the end as long as we can. Only when a Table "fills" will we start to reuse any "holes" left behind by record deletions.

Suppose as a result of an INFO command the Table information line displays MAX:10000 LOADED:7000 ACTIVE:5000. This means that the Table has a stated maximum of 10000 records, that 7000 records have been loaded into it, but that there are only 5000 active records because somewhere along the line 2000 of them have been deleted.

Subsequent LOADs or APPENDs will assign record numbers 7001, 7002, ..etc. to the new records as they come in.

Only after the last record number has been assigned will we start to reuse the "vacated" record numbers. When that happens, you may notice a slowdown in the speed of LOAD, APPEND, or WRITE.

Some people like to keep all their "holes" at the end rather than have them scattered around unpredictably in the data space. This also guards against slowdowns in the commands that write records into the data base. It is to these people that the REORG procedure is dedicated. There is a REORG procedure in the EXAMPLE data base that we invite you to inspect and try.