Die Eingabe aus Prozeduren entspricht der im ungeführten Dialog. Buchstaben sind als Großbuchstaben einzugeben. Kommandos ist ein Schrägstrich voranzustellen; Anweisungen werden zwei Schrägstriche vorangestellt. Ein Kommando bzw. eine Anweisung kann aus einer oder mehreren Zeilen bestehen. Als Fortsetzungszeichen gilt der Bindestrich. Er zeigt an, dass eine Folgezeile vorhanden ist. Jede Folgezeile beginnt mit einem Schrägstrich (bzw. zwei Schrägstrichen bei Anweisungen).
Je nach Einstellung muss das Fortsetzungszeichen bei Kommandos genau in Spalte 72 (Old-Modus) oder in einer der Spalten 2 bis 72 (New-Modus) stehen. Diese Einstellung lässt sich mit dem Kommando SHOW-SDF-OPTIONS abfragen. Die Einstellung wird durch die entsprechende Angabe (*OLD-MODE oder *NEW-MODE) im Operanden CONTINUATION des Kommandos MODIFY-SDF-OPTIONS vorgenommen. In S-Prozeduren kann die Zeilenlänge mit dem Kommando SET-PROCEDURE-OPTIONS INPUT-FORMAT=*FREE-RECORD-LENGTH vereinbart werden, d.h., das Fortsetzungszeichen kann an beliebiger Stelle ab Spalte 2 stehen und die Zeilenlänge kann somit 72 Zeichen überschreiten.
Bei Anweisungen kann das Fortsetzungszeichen in jedem Fall an beliebiger Stelle ab Spalte 2 stehen, und die Zeilenlänge kann mehr als 72 Zeichen betragen.
Eingabesätze, die im Widerspruch zur SDF-Syntaxbeschreibung stehen, lösen in Nicht-S-Prozeduren Spin-Off, in S-Prozeduren die SDF-P-Fehlerbehandlung aus. Es besteht jedoch die Möglichkeit, während des Prozedurablaufs im Dialog, einen Korrekturdialog für fehlerhafte Prozedurkommandos bzw. -anweisungen zu erlauben. Dies kann durch die entsprechende Angabe im Operanden PROCEDURE-DIALOG des Kommandos MODIFY-SDF-OPTIONS eingestellt werden. Die aktuelle Einstellung kann mit dem Kommando SHOW-SDF-OPTIONS erfragt werden.
Die Definition von „Task-spezifischen Default-Werten“ ist ab "Task-spezifische Default-Werte" beschrieben.
Implementierte Prozeduren
Der Benutzer kann eigene Kommandos in einer Benutzersyntaxdatei definieren (siehe "SDF-Syntaxdateien" und "Bearbeiten von Syntaxdateien"). Er erstellt dabei für das Kommando eine Syntaxbeschreibung, die den Kommandonamen, die Operandennamen und die jeweils möglichen Operandenwerte enthält. Der Kommandoname wird bei der Definition mit dem Namen einer Prozedur verknüpft, die bei Eingabe des „neuen“ Kommandos aufgerufen wird. In der Syntaxbeschreibung ist festgelegt, wie die Prozedurparameter bei Aufruf durch SDF zu versorgen sind. Parameterwerte, die der Kommandoaufrufer bestimmen soll, werden über die angegebenen Operandenwerte bestimmt.
Der Benutzer kann somit einer Prozedur eine SDF-Oberfläche geben und damit alle Funktionen der SDF-Schnittstelle nutzen. Insbesondere sind alle Arten der Dialogführung, die Prüfung und Korrektur der angegebenen Operandenwerte, die Information über zulässige Werte mit Erläuterungen und die verdeckte Eingabe von sicherheitsrelevanten Werten möglich.
Die Definition eigener Kommandos ist mit dem Softwareprodukt SDF-A vorzunehmen (Beispiel siehe Handbuch „SDF-A“ [4]).
LOGON-Prozeduren
Bei der LOGON-Verarbeitung besteht die Möglichkeit, LOGON-Prozeduren automatisch ablaufen zu lassen. LOGON-Prozeduren können sowohl systemweit als auch benutzerspezifisch eingesetzt werden. Der Aufruf kann in beiden Fällen als Call- oder Include-Prozedur erfolgen (entspricht dem Aufruf mit dem Kommando CALL- bzw. INCLUDE-PROCEDURE; siehe auch Handbuch „SDF-P“ [5]).
LOGON-Prozeduren dürfen kein DO-Kommando enthalten und dürfen nicht mit dem Kommando ENDP-RESUME beendet werden. Außerdem sollten sie nicht unterbrechbar sein (siehe „Unterbrechungsschutz von Prozeduren“).
Der Benutzer kann für alle Aufträge, die unter seiner Benutzerkennung laufen, sowohl eine Call- als auch eine Include-Prozedur als Benutzer-LOGON-Prozeduren anlegen, wobei eine Include-Prozedur vor der entsprechenden Call-Prozedur gestartet wird.
Für den automatischen Aufruf muss die Call-Prozedur unter dem Standardnamen $userid.SYS.SDF.LOGON.USERPROC, die Include-Prozedur unter dem Standardnamen $userid.SYS.SDF.LOGON.USERINCL katalogisiert werden.
Systemweit kann die Systembetreuung durch einen entsprechenden Eintrag in der SDF-Parameterdatei System-LOGON-Prozeduren (Call- und Include-Prozedur) für alle Benutzer bereitstellen (siehe „Verwaltung systemweiter Prozedurdateien“).
Für Tasks, bei denen eine Gruppensyntaxdatei ohne Auswertung der Systemsyntaxdatei zugewiesen ist, werden keine System-LOGON-Prozeduren gestartet.
Ist der Benutzerkennung eines Benutzerauftrags eine mit HIERARCHY=*NO (Kommando MODIFY-SDF-PARAMETERS) definierte PROFILE-ID zugeordnet, so werden für diesen Benutzerauftrag keine systemweiten LOGON-Prozeduren aufgerufen; nur die benutzerspezifischen LOGON-Prozeduren, falls vorhanden, werden dann aufgerufen.
Benutzer-LOGON-Prozeduren werden erst nach Ablauf der vereinbarten System-LOGON-Prozeduren gestartet. Erst nach Ablauf der LOGON-Prozeduren können Kommandos eingegeben werden.
LOGON-Prozeduren werden in folgenden Fällen ohne Warnung ignoriert:
Die Prozedurdatei ist nur katalogisiert, belegt aber keinen Speicherplatz.
Die Task ist eine RFA-Task.
Die Task besitzt außer HARDWARE-MAINTENANCE, SECURITY-ADMINISTRATION, SAT-FILE-MANAGEMENT und SAT-FILE-EVALUATION kein anderes Privileg.
Für einige Systemtasks werden ebenfalls keine LOGON-Prozeduren gestartet (z.B. bei der Systemeinleitung).
Kann eine benutzerspezifische oder systemweite LOGON-Prozedurdatei nicht eröffnet werden, wird eine Fehlermeldung ausgegeben. Die LOGON-Verarbeitung wird dann ohne Aktivierung dieser Prozedur fortgesetzt.
LOGOFF-Prozeduren
Bei der LOGOFF-Verarbeitung besteht die Möglichkeit, LOGOFF-Prozeduren automatisch ablaufen zu lassen. LOGOFF-Prozeduren können sowohl systemweit als auch benutzerspezifisch eingesetzt werden. Der Aufruf kann in beiden Fällen als Call- oder Include-Prozedur erfolgen (entspricht dem Aufruf mit dem Kommando CALL- bzw. INCLUDE-PROCEDURE; siehe auch Handbuch „SDF-P“ [5]).
LOGOFF-Prozeduren dürfen kein DO-Kommando enthalten und dürfen nicht mit dem Kommando ENDP-RESUME beendet werden. Außerdem sollten sie nicht unterbrechbar sein.
Der Benutzer kann für alle Aufträge, die unter seiner Benutzerkennung laufen, sowohl eine Call- als auch eine Include-Prozedur als Benutzer-LOGOFF-Prozeduren anlegen, wobei eine Include-Prozedur vor der entsprechenden Call-Prozedur gestartet wird.
Für den automatischen Aufruf muss die Call-Prozedur unter dem Standardnamen $userid.SYS.SDF.LOGOFF.USERPROC, die Include-Prozedur unter dem Standardnamen $userid.SYS.SDF.LOGOFF.USERINCL katalogisiert werden.
Wird in der Prozedur ein EXIT-JOB- bzw. LOGOFF-Kommando aufgerufen, endet die Bearbeitung der Benutzer-LOGOFF-Prozeduren und es werden zunächst ggf. vereinbarte System-LOGOFF-Prozeduren gestartet.
Systemweit kann die Systembetreuung System-LOGOFF-Prozeduren (Call- und Include-Prozedur) für alle Benutzer durch einen entsprechenden Eintrag in der SDF-Parameterdatei bereitstellen (siehe „Verwaltung systemweiter Prozedurdateien“). System-LOGOFF-Prozeduren werden erst nach Ablauf der vereinbarten Benutzer-LOGOFF-Prozeduren gestartet. Benutzer- und Gruppensyntaxdateien werden vor ihrem Start deaktiviert.
Für Tasks, bei denen eine Gruppensyntaxdatei ohne Auswertung der Systemsyntaxdatei zugewiesen ist, werden keine System-LOGOFF-Prozeduren gestartet.
Ist der Benutzerkennung eines Benutzerauftrags eine mit HIERARCHY=*NO (Kommando MODIFY-SDF-PARAMETERS) definierte PROFILE-ID zugeordnet, so werden für diesen Benutzerauftrag keine systemweiten LOGOFF-Prozeduren aufgerufen; nur die benutzerspezifischen LOGOFF-Prozeduren, falls vorhanden, werden dann aufgerufen.
LOGOFF-Prozeduren werden in folgenden Fällen ohne Warnung ignoriert:
Die Prozedurdatei ist nur katalogisiert, belegt aber keinen Speicherplatz.
Die Task wurde mit CANCEL-JOB bzw. FORCE-JOB-CANCEL abgebrochen.
Die Task ist eine RFA-Task.
Die Task besitzt außer HARDWARE-MAINTENANCE, SECURITY-ADMINISTRATION, SAT-FILE-MANAGEMENT und SAT-FILE-EVALUATION kein anderes Privileg.
Für einige Systemtasks werden ebenfalls keine LOGOFF-Prozeduren gestartet (z.B. bei der Systemeinleitung).
Kann eine benutzerspezifische oder systemweite LOGOFF-Prozedurdatei nicht eröffnet werden, wird eine Fehlermeldung ausgegeben. Die LOGOFF-Verarbeitung wird dann ohne Aktivierung dieser Prozedur fortgesetzt.
Prozedurdialog
In Prozeduren kann die SDF-Dialogführung zugelassen werden, d.h. Prozedureingaben werden von SDF wie Dialogeingaben behandelt. So kann z.B. der Korrekturdialog bei syntaktisch falschen Eingaben genutzt werden. Außerdem kann in der Prozedur erzwungen werden, dass Kennwörter verdeckt eingegeben werden (Operandenwert *SECRET in der Prozedur).
Der Prozedurdialog kann genutzt werden, wenn vor Prozeduraufruf bzw. in der Prozedur die SDF-Option PROCEDURE-DIALOG auf *YES gesetzt wird.
Zur Nutzung des Korrekturdialogs ist außerdem eine entsprechende Führungsstufe einzustellen (z.B. GUIDANCE=*NO).
Unterbrechungsschutz von Prozeduren
Die Möglichkeit, Prozeduren mit der 
-Funktionstaste zu unterbrechen, kann durch entsprechende Angabe im Operanden INTERRUPT-ALLOWED im Kommando BEGIN-PROCEDURE einer Nicht-S-Prozedur bzw. SET-PROCEDURE-OPTIONS einer S-Prozedur untersagt werden. Damit können Prozeduren gegen eine unerwünschte Unterbrechung geschützt werden (z.B. innerhalb der Prozedur werden Zugriffe auf geschützte Dateien erlaubt). Die Eigenschaft „nicht unterbrechbar“ bleibt bei Prozedurschachtelung erhalten.
Unterbrechungsschutz von Programmen in Prozeduren
Ein Programm, das innerhalb einer nicht unterbrechbaren Prozedur geladen wird, ist nur in bestimmten Fällen gegen Unterbrechung (implizit) geschützt. Dabei kann eine Programmunterbrechung durch die Prozedur selbst als beabsichtigt angesehen werden. Eine Unterbrechung durch den Prozeduraufrufer ist aber nicht erwünscht.
Andererseits kann es während des Programmlaufs Verarbeitungszustände geben, in denen keinerlei Unterbrechung (auch nicht aus einer Prozedur) erwünscht ist (z.B. Verarbeitung sicherheitsrelevanter Daten). In diesem Fall muss sich das Programm explizit gegen eine Unterbrechung schützen.
Innerhalb einer Prozedur oder eines Programmes können folgende Ereignisse (Events) eine Unterbrechung anfordern:
Kontrollinstanz | Ereignis | vor Ereignis | nach Ereignis | ||
Modus | Eingabestufe | Modus | Eingabestufe | ||
Prozedur |
| proc | cmd | dia | cmd |
Programm |
| proc dia | prog prog | dia dia | cmd cmd |
BKPT-Makro | any | prog | same | cmd | |
Programm | CMD-Makro | any | prog | mclp | cmd |
//HOLD-PROGRAM | any | prog | same | cmd | |
//EXECUTE-SYSTEM-CMD | any | prog | mclp | cmd | |
/HOLD-PROGRAM | proc | prog | proc | cmd | |
| Bedeutung | proc | Prozedur |
Die Unterbrechungsanforderung für ein in einer Prozedur laufendes Programm wird dabei wie folgt behandelt:
Unterbrechung durch | Unterbrechung erlaubt | |||
Programm | nein | ja | ||
Prozedur | ja / nein | nein | ja | |
| R | R | A | |
| A,RE | A,RI | A | |
BKPT-Makro | A,RE | A,RI | A | |
CMD-Makro | A,RE | A,RI | A | |
andere Makroaufrufe | A,RE | A,RI | A | |
//HOLD-PROGRAM | R | C | C | |
//EXECUTE-SYSTEM-CMD | R | C | A | |
/HOLD-PROGRAM | R | C | C | |
| Bedeutung: | A | Die Unterbrechung wird vom System akzeptiert. |
RI | Die Unterbrechung sollte von einem Programm, das implizit nicht unterbrechbar ist, zurückgewiesen werden. | |
R | Die Unterbrechung wird vom System zurückgewiesen. |
Zurückweisen bedeutet:
wird ignoriert und die Verarbeitung wird fortgesetzt.Das Kommando bzw. die Standardanweisung HOLD-PROGRAM oder das Kommando BEGIN-BLOCK PROGRAM-INPUT=*MIXED-WITH-CMD erzeugen im Programm die EOF-Bedingung.
Die Standardanweisung EXECUTE-SYSTEM-CMD wird zurückgewiesen und aktiviert Spin-Off auf Anweisungsebene.
Die Standardanweisung HOLD-PROGRAM wird in jedem Fall zurückgewiesen, wenn sie nicht aus der Prozedurdatei gelesen wird. Anderenfalls könnte eine unterschiedliche Eingabequelle von Anweisungen und Kommandos zu Inkonsistenzen im Prozedurablauf führen.
Folgende Funktionalität wird unterstützt:
die Standardanweisungen EXECUTE-SYSTEM-CMD und HOLD-PROGRAM
der Makroaufruf CLISET, der ein Programm explizit für nicht unterbrechbar erklärt
der Makroaufruf CLIGET, mit dem abgefragt wird, ob die programmaufrufende Prozedur nichtunterbrechbar ist
Verwaltung systemweiter Prozedurdateien
Die systemweiten Prozedurdateien legt die Systembetreuung an. Sie kann dabei für die LOGON- und LOGOFF-Verarbeitung ebenfalls jeweils eine Call- und eine Include-Prozedur bereitstellen. Mit dem Kommando MODIFY-SDF-PARAMETERS werden
LOGON- und LOGOFF-Prozeduren aktiviert bzw. deaktiviert. Die Aktivierung bzw. Deaktivierung kann über den Operanden SCOPE für die aktuelle Session temporär oder permanent ab sofort bzw. ab der folgenden Session vereinbart werden. Permanente Änderungen werden auch in der SDF-Parameterdatei eingetragen. Alle Vereinbarungen können mit dem Kommando SHOW-SDF-PARAMETERS angezeigt werden. Bei der Aktivierung wird für den gewünschten Prozedurtyp (z.B. im Operanden SYSTEM-LOGON-PROC bei der Call-Prozedur für LOGON) explizit der Dateiname angegeben oder, falls die Prozedur unter einem Standardnamen abgelegt ist, der Wert *STD vereinbart. Folgende Standardnamen können verwendet werden:
$TSOS.SYS.SDF.LOGON.SYSPROC (Call-Prozedur für LOGON)
$TSOS.SYS.SDF.LOGON.SYSINCL (Include-Prozedur für LOGON)
$TSOS.SYS.SDF.LOGOFF.USERPROC (Call-Prozedur für LOGOFF)
$TSOS.SYS.SDF.LOGOFF.USERINCL (Include-Prozedur für LOGOFF)
Die systemweiten Prozeduren müssen die Schutzattribute USER-ACCESS=*ALL-USERS und ACCESS=*READ besitzen. Falls für eine Prozedurdatei eine BASIC-ACL eingerichtet ist, müssen alle Benutzer das Ausführungsrecht besitzen.
Die Namen der systemweiten Prozedurdateien können mit dem Kommando MODIFY-SDF-PARAMETERS in die SDF-Parameterdatei eingetragen werden. Mit diesem Kommando ist es auch möglich, die systemweiten LOGON-/LOGOFF-Prozeduren für alle folgenden LOGON/LOGOFF-Vorgänge der aktuellen Session zu deaktivieren, ohne dass die Einträge in der Parameterdatei geändert werden.