Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Compiled procedures

&pagelevel(3)&pagelevel

Identifying a compiled procedure

The COMPILE-PROCEDURE command writes the following identification as text in the first line of a compiled procedure:

/ ///COMPILED-PROCEDURE///

The code of the intermediate format is generated directly after this line. SDF-P-BASYS uses this identification to distinguish between compiled procedures and S procedures.

The identification also serves to signal to any other system components, utility routines or user applications that the object being read is to be considered a procedure which can be called with CALL-PROCEDURE. S procedures and compiled procedures have the following in common (see also "Internal processing of S procedures "): they must start with /<command>, and the command may not be a SET-LOGON-PARAMETERS (or LOGON) or BEGIN-PROCEDURE (or PROCEDURE) command.

Creating a compiled procedure with variable elements

Unlike source procedures, compiled procedures cannot be modified using a text editor. Therefore end users cannot tailor compiled procedures to meet their particular needs. This is why the developer of the text procedure should include independent customization mechanisms in the procedure such as:

  • use of procedure parameters

  • ways of reading in variables from the terminal (using READ-VARIABLE)

  • ways of reading in multiple variables from a text file (using READ-VARIABLE)

  • integration of variable containers with simple variables

  • integration of procedure exits for S procedures by using non-chargeable functions in the compiled procedure (e.g. with CALL-PROCEDURE or INCLUDE-PROCEDURE)

  • use of job variables, etc.

Notes

  • S procedures created by means of compiled procedures in list variables or with a text editor at runtime are not, themselves, compiled procedures. In other words, if compiled procedures are to be executed without the SDF-P subsystem, they can generate other S procedures which use chargeable SDF-P functions, but they cannot execute these procedures at runtime.
    Similarly, no chargeable SDF-P functions can be used if a compiled procedure is interrupted during execution with the key or HOLD-PROCEDURE and the SDF-P subsystem is not loaded.

  • Only errors reported to SYSOUT during the analysis of SDF-P control structures are detected. This means that only the structures in the procedure are checked, but not the input commands.

  • If the syntax files of the SDF-P flow control commands are modified after compilation but before execution, incompatible modifications may cause the compiled procedure to crash. The consequences are the same as for text procedures but the error is not reported when the procedure is called. Instead it is reported when the commands in the compiled procedure are executed.

  • The procedure compiler stores compiled procedures in containers. These procedures can also be copied into other containers, except variable containers, without affecting their execution.

  • Non-S procedures cannot be compiled.