Input from procedures is the same as in unguided dialog. Letters must be entered in uppercase notation. Commands must be preceded by a slash, statements by two slashes. A command or statement may take up one or more lines. The continuation character used is the hyphen, which indicates that a continuation line is present. Each continuation line starts with a slash (or, in the case of statements, with two slashes).
Depending on the mode setting, the continuation character for commands either must be entered in column 72 exactly (Old mode) or may be entered in any column from 2 through 72 (New mode). The setting can be queried by means of the SHOW-SDF-OPTIONS command and is defined via the options *OLD-MODE and *NEW-MODE in the CONTINUATION operand of the MODIFY-SDF-OPTIONS command.
In S procedures, the line length can be defined by means of the command SET-PROCEDURE-OPTIONS INPUT-FORMAT=*FREE-RECORD-LENGTH. In this case, the continuation character may be entered in column 2 or any following column and the line length may exceed 72 characters.
In the case of statements, the continuation character may occupy any position as of column 2, and the line length can be more than 72 characters.
In non-S procedures, input records contradicting the SDF syntax description activate the spin-off mechanism; in S procedures, the SDF-P error recovery mechanism is activated. During an interactive procedure run, however, a correction dialog for errored procedure commands or statements can be initiated if the appropriate specification has been made in the PROCEDURE-DIALOG operand of the MODIFY-SDF-OPTIONS command. The current setting can be queried with the aid of the SHOW-SDF-OPTIONS command.
How to define task-specific default values is described on "Task-specific default values ".
Implemented procedures
Users can define their own commands in a user syntax file (see pages "SDF syntax files" and "Processing syntax files").
A user-defined command requires its own syntax description containing the command name, the operand names, and the permissible operand values. In this definition, the command name is linked to the name of a procedure, which is called as soon as the “new” command is entered. The syntax description defines the values to be supplied for the procedure parameters with the SDF procedure call. Those parameter values to be supplied by the command initiator are set according to the specified operand values.
The procedure parameters are supplied in the defined manner via the operands of the command. The user is thus able to equip a procedure with an SDF interface providing all the benefits of the SDF command language. In particular all guidance levels, checking and correction of the specified operand values, information on permissible values with additional explanations, and masked input of sensitive values are possible.
The definition of user-own commands has to be performed with the aid of the software product SDF-A (see example in the “SDF-A” manual [4]).
Logon procedures
Logon processing offers the possibility of automatic execution of logon procedures.
LOGON procedures can be used throughout the system or specifically for a certain user. The call can be made in a call or an include procedure in both cases (corresponds to a call with the command CALL-PROCEDURE or INCLUDE-PROCEDURE. See also the “SDF-P” manual [5]).
LOGON procedures may not contain any DO commands and may not be terminated using the ENDP-RESUME command. Furthermore, they should be uninterruptible.
Users can create their own logon procedure in the form of both a call and an include procedure for all jobs running under their user ID. An include procedure must be started before the corresponding call procedure when this is done.
The call procedure must be cataloged under the standard name
$userid.SYS.SDF.LOGON.USERPROC and the include procedure under the standard name $userid.SYS.SDF.LOGON.USERINCL for the automatic call.
Systems support staff can provide system-wide logon procedures (call and include procedures) that are valid for all users (see “Administration of system-wide procedure files”).
A system LOGON procedure is not started for tasks in which a group syntax file is assigned without evaluating the system syntax file.
If the user ID of a user job is assigned a PROFILE-ID defined with HIERARCHY=*NO (MODIFY-SDF-PARAMETERS command), then no system-wide LOGON procedures are called for this user job. Only the user-specific LOGON procedures, when present, are called in this case.
The user’s own logon procedures are not started until termination of the system logon procedure. Command input is not possible until termination of the logon procedure(s).
LOGON procedures are ignored without a warning in the following cases:
The procedure file is only cataloged but does not use any storage space.
The task is an RFA task.
The task has no privileges other than the HARDWARE-MAINTENANCE, SECURITY-ADMINISTRATION, SAT-FILE-MANAGEMENT and SAT-FILE-EVALUATION privileges.
In addition, no LOGON procedure is started for some system tasks (e.g. when initializing the system).
If a user-specific or system-wide LOGON procedure file cannot be opened, then an error message is output. LOGON processing is then continued without activating this procedure.
LOGOFF procedures
You can have the LOGOFF procedure run automatically. LOGOFF procedures can be set with system-wide scope or just for a certain user or users. The call can be made as a call procedure or include procedure in both cases (corresponding to a call with the command CALL-PROCEDURE or INCLUDE-PROCEDURE, see also the “SDF-P“ manual [5]). LOGOFF procedures may not contain DO commands and may not be terminated with the ENDP-RESUME command. Furthermore, they should be uninterruptible (see “Interruptibility of procedures”).
The user can create a call procedure as well as an include procedure as his user LOGOFF procedure for all jobs running under his user ID. An include procedure is started before the corresponding call procedure.
The call procedure must be cataloged under the standard name
$userid.SYS.SDF.LOGOFF.USERPROC and the include procedure under the standard name $userid.SYS.SDF.LOGOFF.USERINCL for the automatic call.
If an EXIT-JOB or LOGOFF command is called in the procedure, then processing of the user LOGOFF procedure terminates and any system LOGOFF procedures defined are then started.
Systems support can make the system LOGOFF procedure (call and include procedure) available for all users by making the appropriate entry in the SDF parameter file (see “Administration of system-wide procedure files”). System LOGOFF procedures are only started after the user LOGOFF procedures defined have run. User and group syntax files are deactivated before they are started.
A system LOGOFF procedure is not started for tasks in which a group syntax file is assigned without evaluating the system syntax file.
If the user ID of a user job is assigned a PROFILE-ID defined with HIERARCHY=*NO (MODIFY-SDF-PARAMETERS command), then no system-wide LOGOFF procedures are called for this user job. Only the user-specific LOGOFF procedures, when present, are called in this case.
LOGOFF procedures are ignored without a warning in the following cases:
The procedure file is only cataloged but does not use any storage space.
The task was canceled with CANCEL-JOB or FORCE-JOB-CANCEL
The task is an RFA task.
The task has no privileges other than the HARDWARE-MAINTENANCE, SECURITY-ADMINISTRATION, SAT-FILE-MANAGEMENT and SAT-FILE-EVALUATION privileges.
No LOGOFF procedure is started for some system tasks (e.g. when initializing the system).
If a user-specific or system-wide LOGOFF procedure file cannot be opened, then an error message is output. LOGOFF processing is then continued without activating this procedure.
Procedure dialog
SDF dialog guidance can be permitted in procedures, i.e. SDF handles procedure input like dialog input. This allows, for example, the correction dialog to be used if syntax errors are found in input. In addition the user can ensure the masked entry of passwords in a procedure (operand value *SECRET in the procedure).
The procedure dialog can be used if the SDF option PROCEDURE-DIALOG is set to *YES before the procedure is called or in the procedure. To use the correction dialog you must also set an appropriate guidance level (e.g. GUIDANCE= *NO).
Interruptibility of procedures
The possibility of procedure interruption via the 
function key can be disabled by making the appropriate specification in the INTERRUPTION-ALLOWED operand of the BEGIN-PROCEDURE command (non-S procedures) or the SET-PROCEDURE-OPTIONS command (S procedures). This protects procedures from undesired interruption (e.g. permitting access to protected files within a procedure). The uninterruptibility attribute is retained in the case of procedure nesting.
Interruptibility of programs in procedures
A program that is loaded within an uninterruptible procedure is only in certain cases protected (implicitly) against interruption. A program interruption can thus be considered by the procedure as intentional. An interruption by the user who called the procedure,
however, is undesirable.
On the other hand, during program execution processing statuses can occur in which no type of interruption (even from within a procedure) is desirable (e.g. processing of sensitive data). In this case the program must protect itself implicitly against interruption.
Within a procedure or a program, the following events can request an interrupt.
Control | Event | Before event | After event | ||
Mode | Input | Mode | Input | ||
Procedure |
| proc | cmd | dia | cmd |
Program |
| proc dia | prog prog | dia dia | cmd cmd |
BKPT macro | any | prog | same | cmd | |
CMD macro | any | prog | mclp | cmd | |
//HOLD-PROGRAM | any | prog | same | cmd | |
//EXECUTE-SYSTEM-CMD | any | prog | mclp | cmd | |
/HOLD-PROGRAM | proc | prog | proc | cmd | |
| Meaning: | proc | procedure |
The interrupt request for a program running in a procedure is thus handled as follows:
Interrupt via | Interrupt allowed | |||
Program | no | yes | ||
Procedure | yes / no | no | yes | |
|
| R | A | |
|
| A,RI | A | |
BKPT macro |
| A,RI | A | |
CMD macro |
| A,RI | A | |
Other macro calls |
| A,RI | A | |
//HOLD-PROGRAM |
| C | C | |
//EXECUTE-SYSTEM-CMD |
| C | A | |
/HOLD-PROGRAM |
| C | C | |
Meaning: | A RE
C | The interrupt is accepted by the system. The interrupt should be rejected by a program that is explicitly The interrupt should be rejected by a program that is implicitly The interrupt is rejected by the system. The interrupt is rejected by the system if the statements are |
Rejection means:
- is ignored and processing is resumed.
The command or standard statement HOLD-PROGRAM or the command BEGIN-BLOCK PROGRAM-INPUT=*MIXED-WITH-CMD generates the EOF condition in the program.
The standard statement EXECUTE-SYSTEM-CMD is rejected and activates the spinoff mechanism at statement level.
The standard statement HOLD-PROGRAM is rejected in all cases if it is not read from the procedure file. Otherwise, different input sources of statements and commands could lead to inconsistencies in the procedure execution.
The following functions are supported:
the standard statements EXECUTE-SYSTEM-CMD and HOLD-PROGRAM
the CLISET macro, which explicitly declares a program to be uninterruptible
the CLIGET macro, which is used to query whether the program-calling procedure is uninterruptible.
Administration of system-wide procedure files
The system-wide procedure files are created by systems support. Systems support can also provide one call and one include procedure each for LOGON and LOGOFF processing. LOGON and LOGOFF procedures are activated and deactivated with the MODIFY-SDF-PARAMETERS command. Activation and deactivation can be defined via the SCOPE operand temporarily or permanently for the current session and immediately or starting with the next session. Permanent changes are also entered in the SDF parameter file. All definitions can be displayed with the SHOW-SDF-PARAMETERS command. During activation, the file name can be specified explicitly for the desired procedure type (e.g. in the SYSTEM-LOGON-PROC operand for the call procedure for LOGON) or, if the procedure is stored under a standard name, using the value *STD. The following standard names can be used:
$TSOS.SYS.SDF.LOGON.SYSPROC (call procedure for LOGON)
$TSOS.SYS.SDF.LOGON.SYSINCL (include procedure for LOGON)
$TSOS.SYS.SDF.LOGOFF.USERPROC (call procedure for LOGOFF)
$TSOS.SYS.SDF.LOGOFF.USERINCL (include procedure for LOGOFF)
The system-wide procedures must have the USER-ACCESS=*ALL-USERS and ACCESS=*READ protection attributes. If a BASIC-ACL is set up for a procedure file, then all users must have execution rights.
The names of the system-wide procedure files can be entered in the SDF parameter file with the MODIFY-SDF-PARAMETERS command. It is also possible with this command to deactivate the system-wide LOGON procedures for all following LOGON processes in the current session without changing any entries in the parameter file.