Functions

Beginning with version 9.0.C of the Windows and Linux runtimes, a new capability has been added to the PL/B language that allows functions with a specific scope to be declared. The capability is implemented using four new instructions named FUNCTION, LFUNCTION, ENTRY, and FUNCTIONEND. The implementation provides a number of features that users have requested to enhance the PL/B language. Some of the basic FUNCTION features are as follows:

The FUNCTION/FUNCTIONEND instructions define a specific routine. The scope of the routine is all of instructions between the FUNCTION and FUNCTIONEND statements.
The FUNCTION implementation supports both input parameter variables and local variables. The ENTRY instruction is required to differentiate the parameter variables from the local variables. The variable and code label references declared in the scope of a FUNCTION will not conflict with any other label references in a program.
All input parameter variables must be declared between the FUNCTION and ENTRY instructions.
All local variables must be declared after the ENTRY instruction before any executable instructions.
The FUNCTION implementation prevents any of the local variables from being accessed by PL/B code outside the FUNCTION.
Any code labels declared within the FUNCTION cannot be accessed by PL/B code outside the FUNCTION. It is not possible to jump into the middle of a FUNCTION.
When a FUNCTION is entered, the implementation guarantees that all of the local variables are always initialized to the same state as declared by the program when it was first loaded.
A stack ensures that all variables in a FUNCTION are restored to their previous values after a CALL out of the FUNCTION and a RETURN back into the FUNCTION. The implementation allows the FUNCTION to be re-entered while preserving and restoring the variable values automatically.
Nested FUNCTIONs are not supported.
A ROLLOUT instruction cannot be compiled into a program that contains FUNCTION or LFUNCTION instructions.
The TRAP and TRAPCLR instructions can be compiled and executed within a FUNCTION. However, the destination label for the TRAP instruction cannot be a label that is local within a FUNCTION. Also, note that an EXCEPTSET event always takes precedence over a TRAP event.
The following instructions cannot be compiled into the code for a FUNCTION:

ROUTINE

LROUTINE

FUNCTION

LFUNCTION

The FUNCTIONEND instruction identifies the point where the FUNCTION scope ends. The FUNCTIONEND actually executes the same as RETURN instruction.
The FUNCTION/FUNCTIONEND logic cannot be compiled into a program within the scope of a structure logic. This means that the FUNCTION/FUNCTIONEND cannot be specified between and the 'IF/ELSE/ENDIF' constructs, 'LOOP/REPEAT', 'FOR' loops, etc.
The FUNCTION/FUNCTIONEND logic has a defined scope that does not allow execution to fall into the FUNCTION scope. There is an implied GOTO at the beginning of a FUNCTION that jumps to the code after the FUNCTIONEND instruction.
The implementation for FUNCTIONs supports the ability to return a variable to a CALL GIVING variable. Both the RETURN and FUNCTIONEND instructions support a USING option that allows a DIM, FORM, INTEGER, CONST, numeric expression, literal, or GUI Object to be returned. Please note that the USING option for the RETURN instruction is only valid within the scope of a FUNCTION.
When FILE, IFILE, AFILE local variables are declared within the scope of a FUNCTION, those file variables are automatically closed when a RETURN or FUNCTIONEND operation is executed.
When a DMAKE instruction is executed for a FUNCTION local variable pointer, a DRELEASE is executed for the local variable pointer when a RETURN or FUNCTIONEND is executed.
When GUI Object variables are created within the scope of a FUNCTION, the GUI Objects are destroyed when a RETURN or FUNCTIONEND is executed.
The FUNCTION construct executes like a ROUTINE instruction in that it is resolved in a dynamic entry label for a Load Module. The LFUNCTION construct executes like a LROUTINE instruction in that it is only allows local access from a single program.
A PLBCMP compiler error occurs when a MOVEPTR, MOVEADR, LOADADR, or STOREADR instruction attempts to move or assign a (L)Function pointer variable value to any pointer variable that is declared outside the scope of the (L)Function. This compiler restriction exists because the compiler has no knowledge about the origin of any pointer values during the compilation phase. The compiler error for this scenario reads as follows:

Can not store variable pointer outside (L)Function scope!