You are here: Development Standards > OSAS Standards > Program Structure > Public Programs

# Public Programs

Public programs are sections of code that have been isolated into separate programs and are CALLed into system memory to be executed. The CALLing program remains in main memory, waiting for the public program to return execution to it.

You must maintain compatibility with the OSAS initial standards, which have been well-observed by both Open Systems and independent software developers.

These routines can be accessed from any application program. These subroutines are accessed with the CALL statement instead of a RUN or a GOSUB. Programs can access these external subroutines without loading the subroutine and then reloading the main program.

Public programs allow for local variables and parameter passing. The ENTER statement is used to define which variables are call-by-value, call-by-reference or global. This allows for well-isolated routines that affect the main program in a predictable manner. Global passing (ENTER with no parameters) can be very slow, because BBx creates duplicate pointers in the public program for all data.

The public program always EXITs to the statement following the CALL statement. The EXIT may carry an error value. This should be handled by the main program.

Public programs use the SETERR and SETESC verbs. Errors must be trapped in public programs. Public programs do not nicely report errors to the user. The errors must be trapped and then acted upon or returned to the CALLing program. The user cannot escape to BASIC from a public program, but a programmer can by setting SETOPTS $08$.

Public programs have the following advantages over general routines:

- Code modification. You can change a single public program, rather than having to merge a new general routine into every program.
- Code size. Only one copy of the public program is kept on the disk, rather than each of the programs containing the general routine.
- Memory usage. The public programs are loaded outside the workspace(s) for the main program and data, allowing more code to be resident for the current task. This may help reduce the number of pauses that occur when new programs are loaded.
- Load time. Public programs can be ADDRed to resident memory, allowing them to be accessed many times with only one load.

ADDR and DROP

A nice feature of PRO/5 programs is that they can be loaded and kept in memory so that the interpreter doesn't have to load the program each time it is CALLed or RUN. This process is called ADDRing, adding to resident memory.

When a public program is going to be CALLed repeatedly, the program should be ADDRed. These programs are loaded by the ADDR verb and can be called at any time. The interpreter will know that the program has been loaded into memory and will not load it again. CALLing memory-resident procedures may save time.

When a public program is going to be CALLed only occasionally, the program may be loaded by the CALL statement. These programs are loaded at the time of CALL. It takes seconds to load and begin the routine.

At system startup, the RMSETUP program ADDRs a list of public programs. The menu program drops all public programs except those specified in an internal list. This task is executed each time an application returns to the menu. The internal list includes GENERROR.PUB, GENINPUT.PUB, GENDATE.PUB and GENOPEN.PUB. In GUI mode, GENGUINP.PUB, GENGURES.PUB, GENGUFNC.PUB, and GENGULIB.PUB are also ADDRed into memory.