Einfuehrung in ARBEITSWEISE und BENUTZUNG von KAPROS unter UNIX von J.Braun, C.Broeders, D.Woll Ueberarbeitete Version von: Bericht: 18.01.03.P01A vom Februar 1991 PSF-Ber.: 3027 INR-Ber.: 1745 KAPROS-Ber.: 107 Ueberarbeitet am: 20.12.93 D.Woll 07.05.98 D.Woll Inhaltsangabe Einleitung Das Programmsystem KAPROS 1.Vom Benutzer gerufene KAPROS-Routinen 1.1.Systemroutinen zum Modulaufruf (KSEXEC) 1.2.Systemroutinen zum Datentransfer (KSGET(P), KSPUT(P), u.a.) 1.3.Hilfsroutinen zum Datenblockhandling (KSLEN, KSCOPY) 1.4.Initialisierungsroutine (KSINIT) 1.5.Weitere vom Modul aufgerufene KAPROS-Routinen (KSCC, KSDD) 2.KAPROS-Anweisungen 2.1.*KSIOX-Anweisung 2.2.Endanweisung *$*$ 2.3.*GO-Anweisung 2.3.Kommentarkennzeichnung durch *$ 2.5.Folgekarten 3.Angabe von KAPROS3-Parametern auf der *KSPARM-Anweisung 4.Steuerung der Protokollausgabe 4.1.Steuerung ueber *KSPARM-Anweisung oder auf *GO-Anweisung 4.2.Steuerung ueber Aufruf der Systemroutine KSTR 5.Aufteilung des zur Verfuegung stehenden Kernspeichers 5.1.Aenderung der Speicheraufteilung mit dem PL-Parameter 6.Archive 6.1.Archiv-Kennung 6.2.Verwalten von Archiven 6.3 Parameter auf der *KSIOX-Karte fuer Archiv Ein/Ausgabe 6.4.KAPROS-Routinen zur Archivierung 7.Datenblocktest 7.1.Druckausgabe von Datenbloecken 7.2.Ueberpruefung eines Datenblockes 7.3.Anwendung bei Ueberspeicherung 7.4.Aufruf von KSDB 7.5.*DBTEST-Anweisung 7.6.Die Systemroutine KSDBT zum Ausgeben der Datenblocktabelle 7.7.*DBT-Anweisung zum Ausgeben der Datenblocktabelle 8.Datenpruefung 10.Jobabbruch in KAPROS3 im Fehlerfall 10.1.Aufbau der Fehlernachricht 10.2.KAPROS-Fehlercodes 10.3.KFFORM-Fehlercodes 10.4.Umsetzung von KAPROS3- in KAPROS2-Fehlercodes 11.Verbindung von KAPROS-Kern und Moduln 11.1.Prinzipielles Vorgehen beim Aufruf von Moduln 11.2.Zentralisierung von KAPROS- und System-Routinen 12.Datenbloecke in der Lifeline 13.Datenblocktabelle 13.1.Anlegen der Datenblocktabelle 13.2.Aufbau der Datenblocktabelle 13.3.Archiv-Datenblocktabelle Referenzen Anhang Aufbau der COMMON-Bereiche KSVCOM und KSCCOM sowie des Feldes IBASE. Einleitung Das Programmsystem KAPROS KAPROS/1/ erleichtert die flexible Verknuepfung von Programmen, im weiteren als Module bezeichnet, und die Weitergabe von Daten zwischen den Modulen in Form von sogenannten Datenbloecken. KAPROS ist ein sogenanntes offenes System, in das jederzeit neue Module ohne Aenderung des System-Kerns oder anderer Module eingebracht werden koennen. Um die Vorzuege von KAPROS bezueglich Datenweitergabe ausnutzen zu koennen, muessen vorhandene stand-alone codes in dieser Hinsicht an KAPROS angepasst werden; ggf. kann eine Anpassung der Speicherverwaltung an KAPROS notwendig werden. Module koennen bei einfachen linearen Programmfolgen durch sogenannte *GO-Anweisungen aufgerufen werden, bei komplexen Modulverknuepfungen mit Hilfe der KAPROS-Routine KSEXEC durch sogenannte Steuermodule oder auch durch andere Module. Modul-Aufrufe durch KSEXEC ermoeglichen die Durchfuehrung komplexer Programmablaeufe mit z.B. iterativen oder rekursiven Programmaufrufen. Die Weitergabe von Daten in Datenbloecken erfolgt in der sogenannten Lifeline, die im Kernspeicher und bei Bedarf auf dynamisch allokierten direct-access-Dateien auf Platten angelegt wird. Die Datenbloecke werden angesprochen ueber den dazugehoerigen Datenblocknamen mit Index. Beim Zugriff wird unterschieden zwischen Uebertragungstechnik, bei der Daten aus moduleigenen Feldern in die Lifeline oder umgekehrt umgespeichert werden, und Pointertechnik, bei der KAPROS einen Pointer zur Verfuegung stellt, mit dem direkt auf Daten in der Lifeline zugegriffen werden kann. Pointer-Datenbloecke koennen in den Modulen als variable Arbeitsfelder benutzt werden. Benutzereigene Archive ermoeglichen die langfristige Speicherung von Datenbloecken, dabei koennen sowohl direct access Dateien als auch sequentielle Dateien zur Speicherung benutzt werden. Waehrend der Ausfuehrung eines KAPROS-Laufs wird nach dem Laden des KAPROS-Kerns Arbeitsspeicher fuer Tabellen und Lifeline angelegt. Die Lifeline wird unterteilt in die Internal Lifeline und die Pointer-Lifeline. Die default- Aufteilung kann ggf. durch einen Aufrufparameter den Anforderungen des jeweiligen KAPROS-Laufs angepasst werden. Bei der Uebernahme von KAPROS3 auf UNIX wurde darauf geachtet, dass vorhandene KAPROS-Jobs und Module moeglichst unveraendert laufen koennen. Daher ergibt sich, dass die wesentlichen, vom Benutzer aufgerufenen KAPROS-Routinen in ihrer Funktion unveraendert sind. Der folgende Bericht soll dem Benutzer das Arbeiten mit KAPROS in einer UNIX-Umgebung ermoeglichen. Die Kenntnis von KfK 2253 /1/ sowie KfK 2317 /2/ wird vorausgesetzt. In /3/ enthaltene Information ueber Wirkungsweise und Aufbau von KSSK hat teilweise auch Gueltigkeit fuer KAPROS3. 1.Vom Benutzer gerufene KAPROS-Routinen 1.1.Sytemroutinen zum Modulaufruf (KSEXEC) In KAPROS3 werden die Module intern durch die KAPROS-Routinen KSEXEK und KSEXEB aufgerufen, die statt einer variablen Anzahl von Argumenten (wie in der Routine KSEXEC) Felder fuer die Uebertragung von Datenblocknamen und Indexverschiebungen benutzt: CALL KSEXEK (modul,ndb,nind,dbname,iind,iq) CALL KSEXEB (modul) mit modul Name des gerufenen Moduls, CHARACTER*8 ndb Anzahl der beim Aufruf uebertragenen Datenblocknamen nind Anzahl der Indexzuordnungen dbname Datenblocknamen, CHARACTER*16 dbname(2,ndb) mit dbname(1, ) Namen der DB im gerufenen Modul dbname(2, ) Namen der DB im rufenden Modul iind Indexzuordnungen, INTEGER*4 iind(3,nind) mit iind(1, ) Anfangsindizes der DB im gerufenen Modul iind(2, ) Endindizes der DB im gerufenen Modul iind(3, ) Indexverschiebungen zum DB im rufenden Modul iq Fehlercode Um vorhandene KAPROS2-Module vertraeglich mit KAPROS3 zu machen, wurde die KAPROS3-Routine KSEXEC mit den von KAPROS2 bekannten Argumenten erstellt, die den Aufruf von KSEXEC transformiert in den internen Aufruf von KSEXEK. Gueltige KSEXEC-Aufrufe sind: CALL KSEXEC (modul,0,0,iq) CALL KSEXEC (modul,ndb,0,dbnames1,dbnamea1,..., dbnamesN,dbnameaN,iq) CALL KSEXEC (modul,ndb,nind,dbnames1,dbnamea1,..., dbnamesN, dbnameaN,iind1,...,indM,iq) mit dbnamesi Name des DB im gerufenen Modul CHARACTER*16 dbnameai Name des DB im rufenden Modul CHARACTER*16 iindj INTEGER*4 iindj(3) mit iindj(1) Anfangsindex zu dbnamesi iindj(2) Endindex zu dbnamesi iindj(3) Verschiebeindex von dbnamesi zu dbnameai iq Fehlercode. 1.2.Systemroutinen zum Datentransfer (KSGET(P), KSPUT(P), u.a.) Daten werden in KAPROS in der Form von Datenbloecken (DB) in der Lifeline (LL) gespeichert, dabei wird unterschieden zwischen Datenbloecken, auf die in Pointertechnik zugegriffen wird, und Datenbloecken, die in Uebertragungstechnik bearbeitet werden. Im folgenden wird die Funktion und der Aufruf der KAPROS-Routinen zum Datentransfer beschrieben. Die Routinen KSRES, KSPUT, KSGET, KSCH, KSPUTP, KSGETP, KSCHP und KSDLT sind in ihrer Funktion weitgehend unveraendert gegenueber KAPROS2, die Argumentliste und die Bedeutung der Argumente hat sich nicht geaendert. Lediglich die von den Routinen gelieferten Fehlercodes haben sich geaendert (siehe Fehlerbehandlung) und erfordern ggf. eine Umstellung der Module, die den Wert dieses Fehlercodes abfragen. Es bedeuten: name Name des DB CHARACTER*16 ind Index zum Namen des DB kdb Relativadresse des Teiles eines DB im DB izw Wortzahl des Teiles eines DB oder des ganzen DB. ifeld Feld der Dimension ifeld(izw), in dem die zu schreibenden Worte stehen oder in das die zu lesenden Worte uebertragen werden sollen. ifeldb Bezugs-Feld von beliebiger Dimension, auf das sich der Pointer ip beziehen soll. ip Pointer zum 1. Wort des DB, bezogen auf ifeldb (d.h. in ifeld(ip) steht das erste Wort des DB). iq Fehlercode. Mit KSRES wird fuer einen DB in Uebertragungstechnik Platz in der Lifeline reserviert. CALL KSRES (name, ind, kdb, izw, iq) Mit KSPUT werden DB oder Teile von DB aus moduleigenen Feldern in die Lifeline uebertragen, mit KSGET aus der Lifeline in moduleigene Felder uebertragen, mit KSCH in der Data-Lifeline durch Ueberspeichern aus moduleigenen Feldern geaendert (Uebertragungstechnik): CALL KSPUT (name, ind, ifeld, kdb, izw, iq) CALL KSGET (name, ind, ifeld, kdb, izw, iq) CALL KSCH (name, ind, ifeld, kdb, izw, iq) Fuer neu zu erstellende Datenbloecke sollte nach Moeglichkeit mit KSRES fuer den gesamten Datenblock Platz reserviert werden. Nach einer Platzreservierung mit KSRES wird ein Datenblock als vorhanden betrachtet, d.h. Daten muessen mit KSCH uebertragen werden. Ist eine Platzreservierung fuer den gesamten Datenblock nicht moeglich, koennen vorhandene Datenbloecke durch Aufruf von KSRES bzw. KSPUT erweitert werden. Ist nicht ohne weiteres absehbar, ob beim Uebertragen von Daten in einen reservierten Datenblock eine Erweiterung notwendig wird, kann die Routine KSTORE benutzt werden. Diese Routine entscheidet selbsttaetig, welcher Teil der Daten mit KSCH und welcher mit KSPUT uebertragen werden muss. CALL KSTORE (name, ind, ifeld, kdb, izw, iq) mit iq Fehlercode >0 Fehlercode der Routine KSCH oder KSPUT <0 -600 die Daten wurden mit KSPUT uebertragen -700 die Daten wurden mit KSCH uebertragen -3800 die Daten wurden mit KSCH und KSPUT uebertragen Mit KSPUTP wird in der Pointer-Lifeline Platz fuer einen DB reserviert, in dem er im Anschluss an den Aufruf erstellt werden kann. Derart angelegte Datenbloecke koennen in einem Modul als Arbeitsfelder benutzt werden, deren Dimensionierung dem jeweiligen Problem angepasst ist. Mit KSGETP wird ein vorhandener DB in die Pointer-Lifeline gebracht und ein Anfangsindex auf diesen Datenblock zur Verfuegung gestellt. Mit KSCHP wird ein in der Pointer-Lifeline festgehaltener DB wieder freigegeben (Pointertechnik): CALL KSPUTP (name, ind, izw, ifeldb, ip, iq) CALL KSGETP (name, ind, izw, ifeldb, ip, iq) CALL KSCHP (name, ind, iq) Mit KSDLT werden DB in der Lifeline geloescht: CALL KSDLT (name, ind, iq) Datenbloecke koennen nur auf dem Level geloescht werden, auf dem sie angelegt wurden. Mit einem KSGETP-Aufruf wird die Gesamtlaenge nzw des DB in izw angeliefert. Mit einem KSGET-Aufruf ist es moeglich, die Laenge des DB zu erfahren, wenn kdb <= 0 beim Aufruf eingesetzt wird. Wenn ein KSPUTP- oder KSGETP-Aufruf auf einen Fehlercode fuehrt, wird ip auf einen sehr grossen Wert gesetzt, so dass die irrtuemliche Benutzung von ip als Pointer auf einen Adress-Fehler und damit zum Jobabbruch fuehrt. Die Hoechstzahl nzwmax von Worten, fuer die Platz in der Pointer-Lifeline vorhanden ist, wenn alle DB, zu denen keine Pointer gesetzt sind, ausgelagert werden, ergibt sich zu: nzwmax = ip-50 000 000 1.3.Hilfsroutinen zum Datenblockhandling (KSLEN, KSCOPY) Mit der Systemroutine KSLEN kann die Laenge eines Datenblockes bestimmt werden, ohne dass auf die Daten selbst zugegriffen wird: CALL KSLEN (name, ind, izw, iq) Dabei bedeuten: name Name des DB CHARACTER*16 ind Index zum Namen des DB izw Wortzahl des DB iq Fehlercode Mit der Systemroutine KSCOPY kann von einem DB eine Kopie unter einem anderen Namen bzw. Index angelegt werden. Die Kopie wird nach Moeglichkeit in demselben Bereich der Lifeline angelegt, in dem sich das Original befindet. CALL KSCOPY (name, ind, namneu, indneu, iq) Dabei bedeuten: name Name des DB CHARACTER*16 ind Index zum Namen des DB namneu Name der Kopie des DB CHARACTER*16 indneu Index zum Namen der Kopie des DB iq Fehlercode 1.4.Initialisierungsroutine (KSINIT) Die KAPROS-Routine KSINIT sollte am Anfang jedes Moduls zur Initialisierung aufgerufen werden; sie ist in ihrer Argumentliste unveraendert gegenueber KAPROS2. CALL KSINIT (tc, dtcmax, ne, na, nd) mit tc Anfangs-CPU-Zeit des KAPROS-Jobs in Sekunden dtcmax CPU-Zeit, die fuer den KAPROS-Job zur Verfuegung steht; in Sekunden ne Dateinummer der Standardeingabe (zur Zeit gleich 5). na Dateinummer der Protokollausgabe(zur Zeit gleich 42). nd Dateinummer der Standardausgabe (zur Zeit gleich 6). 1.5.Weitere vom Modul aufgerufene KAPROS-Routinen (KSCC, KSDD) Mit der KAPROS-Routine KSCC wird der Nachrichtencode gesetzt, abgefragt oder geloescht; sie ist in ihrer Funktion und Argumentliste unveraendert gegenueber KAPROS2. Setzen des Nachrichtencodes auf den Wert iq: CALL KSCC (-1,iq) Abfragen des Nachrichtencodes (uebertragen des Wertes nach iq): CALL KSCC (0,iq) Loeschen des Nachrichtencodes oder internen Fehlercodes iq: CALL KSCC (1,iq) Der Nachrichtencode kann auf einen Wert zwischen 1 und 99 gesetzt werden. Codes zwischen 90 und 99 haben zur Folge, dass der Job abgebrochen wird. Beim Loeschen muss iq mit dem Wert des Nachrichtencodes (iq<100) oder des internen Fehlercodes (iq>=100) uebereinstimmen. Die KAPROS-Routine KSDD ist in KAPROS3 als Routine ohne wesentliche Funktion fuer den KAPROS-Kern enthalten, um die Vertraeglichkeit mit KAPROS2-Moduln zu gewaehrleisten. Zum Schliessen eines Puffers wird von KSDD ein REWIND durchgefuehrt; falls Aufrufe von KSDD entfernt werden, ist darauf zu achten, dass in solchen Faellen diese REWIND-Anweisung von dem Modul durchgefuehrt wird. 2.KAPROS-Anweisungen Im folgenden bedeutet /, dass die nachfolgenden Parameter wahlweise angegeben werden koennen, | kennzeichnet verschiedene Moeglichkeiten zur Angabe eines Anweisungsparameters. KAPROS-Anweisungen duerfen keine irrelevanten Leerzeichen enthalten. 2.1.*COMPILE und *LINK-Anweisung Der Compiler wird durch die *COMPILE-Anweisung aufgerufen, sie hat folgenden Aufbau: *COMPILE A|F7|FV/,Subparameter Dabei wird mit A der Assembler-Compiler, F7 der Siemens-Compiler, FV der IBM-Compiler (nur moeglich in der IBM-Version von KAPROS3) aufgerufen. Subparameter sind gueltige Parameter des jeweiligen Compilers. Der Linkage-Editor wird durch die *LINK-Anweisung aufgerufen, sie hat folgenden Aufbau: *LINK /Subparameter Subparameter sind gueltige Parameter des Linkage-Editors. 2.2.*KSIOX-Anweisung Mit der *KSIOX-Anweisung werden Datenbloecke spezifiziert, die als Karten-Eingabe oder aus dem Archiv in die Lifeline gebracht werden sollen oder am Stepende in ein Archiv geschrieben werden sollen. Die *KSIOX-Anweisung hat folgenden Aufbau: *KSIOX DBN= ,IND= /,TYP= /,UNIT= /,FORM= /,DBNA= /,INDA= /, DBNN= /,INDN= /,SPEC=(JOB= /,DATE= /,TIME= /,SPEC= )/, PM(PMN)= /,LM(LMN)= Dabei bedeuten: DBN = Datenblockname 1 bis 16 Zeichen (A-Z,0-9,$) IND = Index des Datenblocks 0 i1=i2=i3=i oder mit i,i1,i2,i3=0 keine Protokollausgabe ML=(i1,i2,i3) i,i1,i2,i3 1 mittlere Protokollausgabe i,i1,i2,i3 2 umfangreiche Protokollausgabe es steht i1 fuer Messages, Errors, Warnings i2 fuer Datenblocktabelle i3 fuer Trace Genauere Erklaerung in dem Kapitel 'Steuerung der Protokollausgabe' 2.5.Kommentarkennzeichnung durch *$ Durch die Zeichenkette *$ mit nachfolgendem Leerzeichen sowohl am Zeilenanfang als auch im Anschluss an eine Dateneingabe wird angezeigt, dass die nachfolgenden Zeichen als Kommentar aufzufassen sind. 2.6.Folgekarten Das Auftreten einer Folgekarte wird in der vorhergehenden Karte durch ein Komma als letztes Zeichen angezeigt; die Folgekarte beginnt mit dem naechsten Parameter in Spalte 3, die ersten beiden Zeichen muessen leer sein (sie duerfen kein *$ wie in KAPROS2 enthalten). 3.Angabe von KAPROS3-Parametern auf der *KSPARM-Anweisung In KAPROS3 koennen mit der *KSPARM-Anweisung bzw. durch Aufruf einer KAPROS3-Subroutine KAPROS-Parameter geaendert werden. Die *KSPARM-Anweisung hat folgenden Aufbau: *KSPARM /TIME/MODINF/VEROFF/SHIFTOFF/IQSK2/ML=(i1,i2,i3)) /VERON /SHIFTON /IQSK3/ML=(i) /ML=i Auf einer *KSPARM-Anweisung koennen mehrere Parameter angegeben werden, sie muessen durch Kommata voneinander getrennt werden. Die Parameter haben folgende Funktion: Parameter*Subr.*default*Funktion TIME Zeitangaben fuer KAPROS3-Subroutinen und Module MODINF KSM Ausgeben moduleigener Information TRACE KSTR KSFORM Ausgeben eines Trace fuer KSFORM VERIFY Ueberwachung der Speicherung von DB VERON Ueberwachung VEROFF x keine Ueberwachung SHIFT (KSHFT) Kontrolle der sofortigen Auslagerung von Pointer-DB nach ihrer Freigabe (KSHFT noch nicht realisiert) SHIFTON x sofortige Auslagerung SHIFTOFF keine sofortige Auslagerung IQ KSTR Setzen Fehlercode KAPROS3/KAPROS2 IQKS3 x Fehlercode von KAPROS3 IQKS2 Fehlercode von KAPROS2 ML i=0 Steuerung der Protokollausgabe ML=i bzw. ML=(i) ==> i1=i2=i3=i oder mit i,i1,i2,i3=0 keine Protokollausgabe ML=(i1,i2,i3) i,i1,i2,i3 1 mittlere Protokollausgabe i,i1,i2,i3 2 umfangreiche Protokollausgabe es steht i1 fuer Messages, Errors, Warnings i2 fuer Datenblocktabelle i3 fuer Trace Genauere Erklaerung im nachfolgenden Kapitel 4.Steuerung der Protokollausgabe 4.1.Steuerung ueber *KSPARM-Anweisung oder auf *GO-Anweisung Steuerung ueber *KSPARM-Anweisung oder auf *GO-Anweisung in der Form: ML=(i1,i2,i3) oder ML=(i) bzw. ML=i ==> i1=i2=i3=i Dabei bedeuten: i1 Kennziffer fuer Ausgabe von Messages, Warnings oder Errors 0 keine Messages, Warnings oder Errors mit Ausnahme von Messages ueber Verwendung bzw. Ausgabe von Archiv-Datenbloecken. Im Falle eines Fehlers wird der zum Abbruch fuehrende Error ausgegeben. 1 Ausgabe von Errors und Messages ueber Loeschen 2 Ausgabe von Messages, Warnings und Errors 3 Ausgabe von Messages, Warnings und Errors sowie weiterer spezieller Messages i2 Kennziffer fuer Ausgabe von Datenblocktabellen 0 keine Ausgabe einer Datenblocktabelle 1 Ausgabe der Datenblocktabelle in Kurzform fuer Rechenmodule 2 Ausgabe der vollstaendigen Datenblocktabelle fuer alle Module 3 Ausgabe der Datenblocktabelle in Kurzform fuer Pruefmodule Bei der Ausgabe der ersten und letzten Worte der Datenbloecke in den beiden nachfolgenden beiden Faellen ist zu beachten, dass das Lesen dieser Worte fuer Datenbloecke auf der EL sehr aufwendig werden kann. 4 Ausgabe der Datenblocktabelle in Kurzform mit Ausgabe der ersten und letzten Worte der Datenbloecke 5 Ausgabe der vollstaendigen Datenblocktabelle mit Ausgabe der ersten und letzten Worte der Datenbloecke auch fuer Datenbloecke auf der externen Lifeline i3 Kennziffer fuer Ausgabe eines Trace 0 keine Ausgabe eines Trace 1 Ausgabe der Aufrufe von KAPROS-Routinen durch Module auf Protokolleinheit 42 2 Ausgabe eines Trace auf Protokolleinheit 42 3 Ausgabe der Aufrufe von KAPROS-Routinen durch Module auf Ausgabeeinheit 6 4 Ausgabe der Aufrufe von KAPROS-Routinen durch Module auf Protokolleinheit 42 und Ausgabeeinheit 6 Somit bedeuten: ML=0 keine Protokollausgabe mit Ausnahme eines zum Abbruch fuehrenden Errors ML=1 Ausgabe von Errors, Aufrufen von KAPROS-Routinen durch Module und der Datenblocktabelle in Kurzform ML=2 umfassende Protokollausgabe von Messages, Warnings, Errors, der vollstaendigen Datenblocktabelle sowie eines Trace Defaultwerte fuer die Protokollausgabe sind i1=i2=i3=0, d.h. keine Protokollausgabe mit Ausnahme eines zum Abbruch fuehrenden Fehlers. Die Angabe eines ML-Parameters in einer *KSPARM-Anweisung hat Wirkung bis zum Step-Ende bzw. bis zu einer weiteren *KSPARM-Anweisung mit Angabe eines neuen ML-Parameters. Die Angabe eines ML-Parameters in einer *GO-Anweisung wirkt nur ueberschreibend fuer die Dauer der *GO-Anweisung. 4.2.Steuerung ueber Aufruf der Systemroutine KSTR Um den Ausdruck von Protokollausgabe bei grossem Umfang gezielt ein- und aus-schalten zu koennen, steht die KAPROS-Routine KSTR zur Verfuegung. Sie wird folgendermassen aufgerufen: CALL KSTR (I1,I2,I3,IQ) Dabei haben I1,I2,I3 die gleiche Bedeutung wie die Parameter i1,i2,i3 des ML-Parameters, IQ enthaelt formal den Fehlercode beim Aufruf von KSTR. Durch erneuten Aufruf von KSTR mit einer 0 fuer das entsprechende Argument kann eine eingeschaltete Option wieder ausgeschaltet werden. 5.Aufteilung des zur Verfuegung stehenden Kernspeichers Beim Compilieren oder Linken innerhalb von KAPROS wird zunaechst die gesamte verfuegbare, nicht vom KAPROS-Systemkern belegte Region dem Compiler bzw. Linkage-Editor zur Verfuegung gestellt; i.a. ist eine Region von 3072 kbytes ausreichend. Bei der Ausfuehrung eines Moduls wird in der jetzigen Version die nicht vom KAPROS-Systemkern belegte verfuegbare Region aufgeteilt in einen Bereich fuer die Module und System-Puffer fuer Dateien sowie einen Bereich fuer die Lifeline mit Pointer-Lifeline und Internal Lifeline (siehe DATENBLOECKE). Pointer-Lifeline und Internal Lifeline sind getrennte Bereiche im Kernspeicher. Die Lifeline wird in dem verfuegbaren freien Speicherplatz in der Region angelegt, der nicht vom KAPROS-Systemkern oder vom Modul belegt ist oder vom Betriebs-System z.B. fuer Puffer benoetigt wird. Ihre Groesse ergibt sich aus der Groesse der verfuegbaren Region REGION (z.Zt. max. ca 9600 kbyte auch bei Angabe einer groesseren Region auf der Job-Karte) der Laenge des KAPROS-Systemkerns mit dem Platz fuer System-Puffer der Dateien KERNEL (z.Zt. ca 800 kbytes) und dem Platz fuer Module MODBUF Die Laenge des Modul/Puffer-Bereiches und die minimale Laenge der Pointer-Lifeline sind in den Variablen MODBUF und PLLMIN in kbytes vorgeben. Fuer diese Variablen sind default-Werte festgelegt (z.Zt. MODBUF=800 kbytes, PLLMIN=150 kbytes). Die Gesamtlaenge der Lifeline LLL ergibt sich zu LLL = REGION - KERNEL - MODBUF wovon mindestens PLLMIN kbytes fuer die Pointer-Lifeline zur Verfuegung gestellt werden. Bei der Aufteilung der Lifeline in Pointer-Lifeline und Internal Lifeline erhaelt die Pointer-Lifeline die Laenge PLLMIN, wenn PLLMIN groesser als die halbe Laenge der Lifeline ist, sonst die halbe Laenge der Lifeline. Die default-Werte fuer die Regionaufteilung ermoeglichen i.a. die Ausfuehrung aller in der KAPROS-Bibliothek enthaltenen Module. Eine Vergroesserung der Pointer-Lifeline kann i.a. durch eine Vergroesserung der Region auf der Jobkarte erreicht werden, wobei zu beachten ist, dass nur maximal REGION kbytes auch bei Angabe einer groesseren Region auf der Job-Karte wirklich nutzbar sind; eine Vergroesserung der Region ueber diesen Wert hinaus bewirkt keine weitere Vergoesserung der Lifeline. Wird mit einem KSPUTP-Aufruf die Groesse des freien Speicherplatzes in der Pointer-Lifeline abgefragt, werden nur 2/3 des wirklich freien Speicherplatzes angegeben, um bei einer Reservierung des angegebenen Platzes das Anlegen weiterer Pointer-DB zu ermoeglichen. Koennen die Speicher-Anforderungen in der zur Verfuegung stehenden Region nicht erfuellt werden, wird der Step mit einer Fehlernachricht abgebrochen. 5.1.Aenderung der Speicheraufteilung mit der *REGION-Anweisung Wenn umfangreiche Module im KAPROS-Step benutzt werden, die nicht in der Modul-Bibliothek enthalten sind, oder viele Dateien mit grossem Pufferbedarf verwendet werden oder eine besonders grosse Pointer- Lifeline z.B. fuer Arbeitsfelder benoetigt wird, kann es erforderlich werden, die default-Werte von MODBUF oder PLLMIN mit der *REGION-Anweisung zu ueberschreiben: *REGION |MODBUF= |PLLMIN= |KERNEL= |REGION= | wobei die einzelnen Angaben durch Kommata getrennt werden muessen. 6.Archive KAPROS3 kennt nur benutzereigene Archive, dabei koennen zwei Arten von Archiven bearbeitet werden, direct access Archive und sequentielle Archive. Direct access Archive sollten fuer eine groessere Anzahl von Datenbloecken mit jeweils wenigen Daten, z.B. nulldimensionale Fluesse, sequentielle Archive fuer wenige Datenbloecke mit vielen Daten z.B. mehrdimensionale Fluesse benutzt werden. Werden keine besonderen Angaben ueber die Art des Archivs gemacht, nimmt KAPROS3 als default-Wert an, dass es sich um ein sequentielles Archiv handelt. Beim Zugriff auf ein sequentielles Archiv (die Angabe FORM=SEQ auf der KSIOX-Karte kann entfallen) werden die Daten in die Lifeline umgespeichert bzw. von der Lifeline auf das Archiv geschrieben. Das direct access Archiv (FORM=DA auf der KSIOX-Karte) entspricht im Aufbau der externen Lifeline. Um Ueberspeicherungen des Archiv-DB zu verhindern, werden die Daten ebenso wie beim sequentiellen Archiv umgespeichert. DB auf Archiven koennen nicht mit KSDLT geloescht oder mit KSCH veraendert werden. Ist eine Veraenderung erwuenscht, muss der DB dupliziert werden und nach der Veraenderung als neuer DB ins Archiv geschrieben werden. Benutzer koennen Datenbloecke nur auf eigene, d.h. von ihnen angelegte Archive ausgeben, die Benutzeridentifikation wird ueberprueft. Fremde Archive koennen im Rahmen des Datenschutzes durch RACF gelesen werden. Um die Verwendung von Archiven zu ermoeglichen, die mit KAPROS2 erstellt wurden, koennen auch vorhandene KAPROS2-Archive gelesen werden. Ob es sich um ein KAPROS2-Archiv handelt, wird von KAPROS3 selbsttaetig anhand der unterschiedlichen Spezifikation entschieden. KAPROS2-Archive koennen nicht von KAPROS3 beschrieben werden. 6.1.Archiv-Kennung Wort Zeichen Zeichen Inhalt Kenn. Ident. 1 1 Name des DB (CHARACTER*16) 5 17 Index des DB 6 21 1 Jobidentifikation 9 - 10 Datum (tt.mm.jj) 18 - 19 Zeit (hh:mm:ss) (i.a. Startzeit des KAPROS-Steps) 27 - 28 frei waehlbare Spezifikation 120 100 blank 31 Anfangsadresse fuer direct-access Archive Anzahl Saetze des DB fuer seq. Archive 32 Endadresse fuer direct-access Archive Anzahl Worte des DB fuer seq. Archive Angesprochen wird ein Archiv-DB durch Angabe seines Namens, seines Indexes und seiner Identifikation (Wort 6 bis 30), wobei rechtsbuendig Teile weggelassen werden koennen. Wird die Identifikation nicht angegeben, wird der neueste DB mit entsprechendem Namen und Index zur Verfuegung gestellt. 6.2.Verwalten von Archiven Zum Eroeffnen von Archiven und zum Ausdrucken von Inhaltsangaben steht der KAPROS-Modul ARCHIV zur Verfuegung. Weitere Aufgaben wie das Kopieren von Datenbloecken werden vom KAPROS3-Systemkern unterstuetzt. (ARCI und ARCO-Anweisung fuer denselben Datenblock). Der KAPROS-Modul ARCHIV kann durch Eingabe aus dem KAPROS-Eingabeblock INPUT ARCHIV oder, in vereinfachter Form, ueber den Aufrufparameter MPARM gesteuert werden. Der Eingabeblock INPUT ARCHIV hat folgenden Aufbau, ueber den Aufrufparameter MPARM kann der Index des Eingabeblocks angegeben werden: K1: NT Nummer der FORTRAN-Einheit des Archivs FORM Form des Archivs 'DA ' direct access Archiv 'SEQ' sequentielles Archiv KONTR von ARCHIV durchzufuehrende Aufgabe 'GENER' Eroeffnen eines Archivs 'PRINT' Ausdrucken einer Inhaltsangabe S1: Eingabeende fuer KONTR='PRINT', sonst K2 K2: NREC Anzahl Records des Archivs (nicht benutzt fuer sequentielles Archiv) K3: IDEN 32 Zeichen Identifikation des Archivs K4: NCOM Anzahl Worte Kommentar des Archivs (max.18) S2: Eingabeenden fuer NCOM=0, sonst K5 K5: (COM(I),I=1,NCOM) Kommentar des Archivs S3: Eingabeende Bei Steuerung ueber den Aufrufparameter hat MPARM folgenden Aufbau: MPARM=NT,FORM,KONTR mit NT Nummer der FORTRAN-Einheit des Archivs > 0 FORM Form des Archivs 'SEQ' sequentielles Archiv 'DA ' direct access Archiv KONTR von ARCHIV durchzufuehrende Aufgabe 'GENER' Eroeffnen eines Archivs 'PRINT' Ausdrucken einer Inhaltsangabe Bei Steuerung durch MPARM werden Identifikation und Kommentar des Archivs blank gesetzt. 6.3 Parameter auf der *KSIOX-Karte fuer Archiv-Ein/Ausgabe DBN = Datenblockname 1 bis 16 Zeichen (A-Z,0-9,$) IND = Index des Datenblocks 0 0 sequentielles Archiv < 0 direct access Archiv kenn = Kennzeichen des DB CHARACTER*4 spec = Spezifikation des DB 72 Zeichen ' ' falls keine Spezifikation angegeben werden soll iq = Fehlercode. 7.Datenblocktest Die in KAPROS3 neugeschaffene Moeglichkeit des Datenblocktests eroeffnet folgende Anwendungen: 1. Ausdruck von Datenbloecken auf einfache Art (entspricht der Funktion von PRINDB /6/). 2. Ueberpruefung eines Datenblockes waehrend des Programmablaufs, d.h. Untersuchen des Inhalts des Datenblocks auf Veraenderungen durch Vergleich der Daten zu zwei verschiedenen Zeitpunkten im Programmablauf. Der Datenblocktest kann gesteuert werden a. in der KAPROS-Eingabe durch die *DBTEST-Anweisung oder b. im Modul durch Aufruf der KAPROS-Systemroutine KSDB Eine *DBTEST-Anweisung bewirkt entweder den sofortigen Ausdruck eines Datenblockes oder den Beginn bzw. das Ende der Ueberpruefung des angegebenen Datenblockes. Dazu wird der Datenblock vor und nach jedem Aufruf eines Moduls ausgedruckt und/oder mit dem Datenblock zu einem frueheren Zeitpunkt verglichen. Ein Aufruf von KSDB bewirkt entweder ebenfalls den sofortigen Ausdruck eines Datenblockes oder die sofortige Ueberpruefung zum Zeitpunkt des Aufrufs. Fuer Datenbloecke, die sich in der externen Lifeline befinden, ist keine Ueberpruefung moeglich. Dies ist jedoch keine Einschraenkung, da ein Datenblock auf einer externen Lifeline nicht ueberspeichert werden kann. 7.1.Druckausgabe von Datenbloecken Die Druckausgabe der Daten eines Datenblocks kann entweder in einem vorgegeben Format (integer, real, alphanumerisch oder hexadezimal) oder, wie vom Druckmodul PRINDB /6/ bekannt, in einem in Abhaengigkeit vom jeweils vorliegenden Wert bestimmten Format erfolgen. Dabei werden Daten, - deren 1.byte hexadezimal 00 (Wert > 0) oder FF (Wert < 0) enthaelt, als Integer interpretiert; - bei denen alle 4 bytes einer alphanumerischen Darstellung entsprechen, als alphanumerisch; - alle sonstigen als Gleitkommazahlen. Eine willkuerliche Folge der Zeichen + - / * . wird als Gleitkommazahl interpretiert. Das Ausdrucken von Datenbloecken wird insbesondere bei Modulschachtelungen gegenueber der Anwendung von PRINDB durch den Aufruf von KSDB erheblich erleichtert, da nicht die von PRINDB zum Ausdrucken benoetigte Eingabe ueber die gesamte Modul-Hierarchie uebertragen werden muss. 7.2.Ueberpruefung eines Datenblockes Zur Ueberpruefung eines Datenblockes wird der zu ueberpruefende Datenblock beim erstmaligen Aufruf von KSDB an das Ende der Pointer- Lifeline geschrieben. Dabei wird vor dem Schreiben geprueft, ob ausreichend Platz vorhanden ist. Bei einem weiteren Aufruf von KSDB zur Ueberpruefung dieses Datenblockes wird zunaechst kontrolliert, ob der Platz, in dem der Datenblock gespeichert wurde, inzwischen von KAPROS zum Anlegen eines Pointer-Datenblockes benoetigt wurde; in diesem Falle ist keine Ueberpruefung mehr moeglich. Ist eine Ueberpruefung moeglich werden die Daten des gespeicherten Datenblocks mit den aktuell vorliegenden Daten des Datenblocks verglichen. Falls Veraenderungen festgestellt werden, wird der geaenderte Datenblock an das Ende der Pointer-Lifeline geschrieben. Anfangs- und End-punkt eines Teilbereiches des Datenblockes, der ueberprueft werden soll, koennen vorgegeben werden; die Anzahl der ausgegebenen Abweichungen kann begrenzt werden. 7.3.Anwendung bei Ueberspeicherung Um eine optimale Speicherbelegung durch variable, an das jeweilige Problem angepasste, Dimensionierung zu ermoeglichen, ist es ein Prinzip von KAPROS, dass Moduln keine eigenen Arbeitsfelder anlegen sollten, sondern Datenbloecke in der Pointer-Lifeline als Arbeitsfelder benutzen sollten. Die dabei verwendete Pointertechnik kann durch fehlerhaft bestimmte Pointer leicht zu Ueberspeicherungen von Daten jeder Art fuehren. Der ueberspeichernde Modul laeuft dabei haeufig fehlerfrei zu Ende, ueberspeicherte Daten in einem Datenblock koennen zu Fehlern in spaeter aufgerufenen Moduln fuehren. Beim Verdacht einer Ueberspeicherung eines Datenblockes oder auch eines mit Hilfe eines KSPUTP-Aufrufs angelegten Arbeitsfeldes kann dieser Datenblock oder das Arbeitsfeld unter dem Namen des dazugehoerigen Pointerblockes innerhalb des Moduls oder beim Aufruf und Verlassen anderer Module auf Veraenderung ueberprueft werden. Auf diese Art kann der die Ueberspeicherung verursachende Programmteil bzw. Modul gefunden werden. 7.4.Aufruf von KSDB Ueberpruefen bedeutet im folgenden Ausdrucken und/oder Vergleichen. CALL KSDB (DBN,IND,NERKL ,IQ) oder CALL KSDB (DBN,IND,NERKLF,IQ) Dabei bedeuten DBN Name des zu ueberpruefenden Datenblocks (16 Zeichen) IND Index des zu ueberpruefenden Datenblocks NERKL Kontrollwort 0 Druckausgabe des gesamten Datenblocks oder NERKLF Feld von 8 Kontrollworten mit Wort (1) 1 Konstante (2) IANF Adresse des ersten zu ueberpruefenden Wortes bezogen auf das erste Wort des Datenblocks 0 Ueberpruefung ab 1.Wort (3) IANZ Anzahl der zu ueberpruefenden Daten 0 alle Daten werden ueberprueft (4) MDIFF maximale Anzahl der zu druckenden Abweichungen 0 nur die Gesamtzahl der Abweichungen wird angegeben 999999 alle Abweichungen werden ausgedruckt (5) KTEST Kontrollwort fuer Datenblocktest 1 Beginn des Datenblocktests 0 Ende des Datenblocktests (6) KCOMP Kontrollwort fuer Datenblockvergleich 0 kein Datenblockvergleich 1 Datenblockvergleich (7) NOPRI Kontrollwort fuer Druckausgabe des Datenblocks (ermoeglicht Datenblockvergleich ohne Druckausgabe) 0 Druckausgabe des Datenblocks 1 keine Druckausgabe des Datenblocks (8) KFORM Kontrollwort IEA fuer Format der Druckausgabe 0 Bestimmung des Formats in Abhaengigkeit vom jeweils vorliegenden Wert 1 Druckausgabe im I-Format 2 Druckausgabe im E-Format 3 Druckausgabe im A-Format 4 Druckausgabe im Z-Format IQ Fehlercode (z.Zt. nicht benutzt) 7.5.*DBTEST-Anweisung Die Parameter der *DBTEST-Anweisung sind i.a. selbsterklaerend; ihre Reihenfolge ist frei waehlbar. Sie hat folgenden Aufbau: *DBTEST DBN=dbn,IND=ind(,IANF=ianf)(,IANZ=ianz)(,MDIFF=mdiff) (,TEST )(,COMPARE)(,NOPRINT)(,FORMAT=iea) (,TESTEND) Dabei bedeuten dbn Name des zu ueberpruefenden Datenblocks ind Index des zu ueberpruefenden Datenblocks ianf Adresse des ersten zu ueberpruefenden Wortes ianz Anzahl der zu ueberpruefenden Daten mdiff maximale Anzahl der zu druckenden Abweichungen 999999 alle Abweichungen werden ausgedruckt iea Kontrollwort IEA fuer Format der Druckausgabe I Druckausgabe im I-Format E Druckausgabe im E-Format A Druckausgabe im A-Format Z Druckausgabe im Z-Format In ( ) angebene Parameter koennen entfallen, fuer sie gelten folgende default-Werte: ianf = 1 ianz = Gesamtzahl aller Daten des Datenblocks mdiff = Gesamtzahl aller Abweichungen im Datenblock iea = 0 Bestimmung des Formats in Abhaengigkeit vom jeweils vorliegenden Wert 7.6.Die Systemroutine KSDBT zum Ausgeben der Datenblocktabelle Mit der Systemroutine KSDBT kann die zu Zeitpunkt des Aufrufs gueltige Datenblocktabelle ausgedruckt werden: CALL KSDBT (nout, ident) Dabei bedeuten nout Ausgabeinheit ident Identifikation des Ausdrucks 8 Zeichen 7.7.*DBT-Anweisung zum Ausgeben der Datenblocktabelle Die *DBT-Anweisung zum Ausgeben der Datenblocktabelle hat folgenden Aufbau: *DBT Ident Dabei bedeutet Ident Identifikation des Ausdrucks der Datenblocktabelle (8 Zeichen) 8.Umstellung von KAPROS2 auf KAPROS3 8.1.Umstellung von Jobs Zur Umstellung von KAPROS2-Jobs auf KAPROS3 ist erforderlich: - Die Prozeduren KSG7 bzw. KSCLG7 muessen ersetzt werden durch K3G7 bzw. K3CLG7. Fuer Rechnungen mit dem IBM-Compiler stehen die Prozeduren K3GV bzw. K3CLGV zur Verfuegung. - Falls ein Steuermodul name uebersetzt und gelinkt wird, muss - dem Steuermodul name folgendes FORTRAN-Programm vorangestellt werden: SUBROUTINE KSSKBU (MPARM) INTEGER*4 MPARM(*) CALL name (MPARM) RETURN END SUBROUTINE name (MPARM) Die Angabe von MPARM ist nur erforderlich, falls in dem Steuermodul name der Aufrufparameter MPARM benutzt wird. - folgende Linkage Editor-Eingabe enthalten sein: ENTRY KS3 NAME name - Falls im Steuermodul die Unterprogramme A8FORM, FILLC, GRB, READK0 oder WQRG oder ENTRY's dieser Programme benutzt werden, kann eine INCLUDE-Anweisung fuer diese Unterprogramme entfallen, da die Uebersetzungen dieser Programme in der Datei KAPROS.KS3.LOAD enthalten sind, die dem Linkage Editor im Rahmen der Prozedur K3CLG7 zugaenglich ist. Nach Moeglichkeit sollten diese Bibliotheksversionen benutzt werden. Fuer die Benutzung von KAPROS2-Archiven muss auf der *KSIOX-Anweisung der Parameter FORM=SEQ angegeben werden. - In seltenen Faellen muessen die default-Groessen zur Aufteilung der Region: REGION, MODBUF und PLLMIN, geaendert werden. - Der Aufruf von RENDB ueber Aufrufparameter hat sich geaendert in: *GO SM=RENDB,MPARM='alter DBname',indexalt,'neuer DBname',indexneu 8.2.Umstellung von Moduln Folgende Aenderungen gegenueber KAPROS2 koennen erforderlich werden: - Zum Compilieren und Linken von Moduln muessen die angegebenen Aenderungen in der JCL (Job Control Language) durchgefuehrt werden. - Die KAPROS-Routine KSINIT sollte weiterhin benutzt werden, um die in KAPROS3 vorgesehene Eingabe-, Ausgabe- und Protokoll-Einheit zu benutzen. - Der Aufruf der KAPROS-Routine KSDD ist nicht mehr erforderlich; es ist jedoch darauf zu achten, dass in den Faellen, in denen von KSDD ein REWIND durchgefuehrt wird, diese REWIND-Anweisung in dem KSDD rufenden Modul enthalten ist. - Falls in dem umzustellenden Modul vor dem Aufruf von KAPROS-Routinen der Fehlercode NERKS gesetzt wird, um den Ausdruck von Fehlernachrichten zu verhindern, oder nach dem Aufruf der Fehlercode NERKS zur Programmsteuerung abgefragt wird, muss entweder der KAPROS2-Fehlercode durch den entsprechenden KAPROS3-Fehlercode ersetzt werden oder in Faellen, wo eine Umstellung des Moduls wegen seltener Benutzung nicht lohnt, mit dem Parameter IQKS2 gearbeitet werden. 9.Datenpruefung Bei KSPARM VERON wird bei der Initialisierung jedes Wort des DB mit KSCNTR = Z7FFFFFFF gefuellt; dabei wird davon ausgegangen, dass dieser Wert nicht vom Anwender verwendet wird. Bei spaeteren Zugriffen auf den DB kann ueberprueft werden, ob an der jeweiligen Adresse im DB bereits ein Wert gespeichert wurde oder nicht. Bei fehlerhafter Anwendung der KAPROS-Routinen KSGET, KSPUT oder KSCH wird der Job unter Ausgabe einer Fehlernachricht abgebrochen. Durch KSPARM VEROFF wird die Datenpruefung ausgeschaltet. Datenpruefung sollte nur beim Testen neuer Module und bei der Fehlersuche durchgefuehrt werden, nicht fuer Routinerechnungen. 10.Jobabbruch in KAPROS3 im Fehlerfall KAPROS3 kennt den Fehlercode NERKS, die Fehlerklasse KERKSS (COMMON KSTBCO) und den Fehler-Flag IBASE(8) (COMMON KSEXCO) (s.Anhang). Im Fehlerfall wird in der Fehlerroutine KSERR fuer Fehler, auf die Kern oder Modul nicht reagieren koennen (Fehlerklasse 1,2,3,4), der Step durch Aufruf von KSSTOP abgebrochen. Fuer Fehler, auf die Kern oder Modul reagieren und anschliessend den Fehlercode loeschen koennen (Fehlerklasse 5), wird der Fehler-Flag IBASE(8)=-1 gesetzt. Beim naechsten Einsprung in die KAPROS-Routine KS3, die die Verbindung zwischen Modul und Routinen des KAPROS-Kerns bzw. Betriebs-Systems schafft, wird, ausser fuer die Routine zur Manipulation des Fehlercodes KSCC, vor dem Sprung in die betreffende Routine der Fehler-Flag ueberprueft und fuer IBASE(8).EQ.-1 der Step durch Aufruf von KSSTOP abgebrochen. In KSCC wird zunaechst ohne Abfrage des Fehler-Flags eingesprungen, um ein Loeschen des Fehler-Flags zu ermoeglichen; vor dem Ruecksprung in das rufende Programm wird der Fehler-Flag abgefragt, ob er weiterhin gesetzt ist, und ggf. abgebrochen. Bei Aufruf der KAPROS-Routine KSPRD wird der Fehler-Flag ebenfalls erst vor dem Ruecksprung abgefragt, um einen Ausdruck der DBT im Fehlerfalle zu ermoeglichen. Angelaufene Routinen und ihre Funktion beim Jobabbruch: KSERR Abbruch des Steps fuer einen nicht korrigierbaren Fehler oder Setzen des Fehler-Flags fuer einen korrigierbaren Fehler KS3 Aufruf von KSSTOP vor Einsprung in eine KAPROS- oder System-routine ausser fuer KSCC KSSTOP Abbruch durch STOP KSCC Loeschen des Fehler-Flags 10.1.Aufbau der Fehlernachricht Eine Fehlernachricht hat den Aufbau ==> ERROR.namsub-iikk.1==> text eine Warnung WARNING.namsub-iikk.1>>: text Dabei bedeuten: namsub Name der KAPROS-Routine, in der der Fehler festgestellt wurde iikk Fehlercode NERKS text i.a. selbsterklaerende Fehlernachricht (in Englisch) 10.2.KAPROS-Fehlercodes Der Fehlercode NERKS hat den Aufbau iikk fuer Fehler, die ohne Korrektur zum Abbruch fuehren und -iikk fuer Warnungen. Dabei kennzeichnet ii die KAPROS-Routine, in der der Fehler festgestellt wird, und kk den aufgetretenen Fehler. Im folgenden eine Liste der vom Benutzer direkt oder indirekt aufgerufenen KAPROS-Routinen: ii KAPROS-Routine 1 KSINIT 2 KSEXEC 3 KSDD 4 KSCC 5 KSGET 6 KSPUT 7 KSCH 8 KSGETP 9 KSPUTP 10 KSCHP 11 KSDAC 12 KSDLT 13 KSARC 20 KSRES 21 KSUNIT 22 KFFORM 24 KSGO 25 KSRN 27 KSARCI 28 KSARCO 16 KAPROS KAPROS-Systemkern 18 KSPIOX Steuerung Entschluesselung *KSIOX-Anweisung 23 KSIOX Entschluesselung *KSIOX-Anweisung 24 KSGO Entschluesselung *GO-Anweisung Im folgenden eine Liste der wichtigsten Fehler: kk Fehler 1 REGION zu klein 2 Eingabefehler auf angegebener Einheit 3 End of dataset auf angegebener Einheit 6 KAPROS-Eingabefehler 9 falscher Datenblockname 10 falsche Datenblockindex-Zuordnung 11 Datenblocktabelle zu kurz 21 externe Lifeline zu klein 22 Pointer-Lifeline zu klein 23 Datenblock mit Index bereits vorhanden 24 Datenblock mit Index nicht gefunden 25 Adresse im Datenblock .LE. 0 26 Versuch, leeren Datenblock zu bearbeiten 27 falsche Adresse im Datenblock 28 Anzahl Daten .LE. 0 29 Index zum Datenblock .LE. 0 .OR. .GE. 10000 30 Versuch, leeren Datenblock zu aendern 31 externe Lifeline zu klein 35 Versuch, noch nicht gespeicherte Daten zu aendern 36 Syntaxfehler in Eingabezeile 37 Syntaxfehler in Datenblockname 39 kein Datenblockname in *KSIOX-Anweisung 40 Index in *KSIOX-Anweisung .LT.0 .OR. .GT.10000 42 Angabe einer fuer KAPROS reservierten FORTRAN-Einheit zwischen 40 und 49 43 Pruefmodulname mehr als 8 Zeichen 44 Syntaxfehler in Pruefmodulname 46 Syntaxfehler im alten Datenblocknamen 49 Name des Steuermoduls mehr als 8 Zeichen 50 Syntaxfehler im ML-Parameter 51 Syntaxfehler in alphanumerischem MPARM-Parameter 56 Versuch, Datenblock in fremdes Archiv zu schreiben 58 angegebene FORTRAN-Einheit nicht deklariert 60 Versuch, noch nicht gespeicherte Daten zu uebertragen Im folgenden eine Liste der wichtigsten Warnungen: kk Warnung -3 bei Aufruf von KSEXEC mehr Indexzuordnungen als Datenblocknamen -4 interne Lifeline gefuellt -5 Datenblock nicht gefunden (KSDLT) -7 Datenblock auf hoeherem Level angelegt, kein Delete -8 Datenblock auf hoeherem Level angelegt, keine Bearbeitung -9 Datenblock im Archiv nicht gefunden -10 Datenblock wegen KAPROS-Fehler nicht archiviert -11 ueberfluessiger Aufruf von KSDD 11.3.KFFORM-Fehlercodes Die KAPROS-Routine zur Entschluesselung von Eingabedaten KFFORM hat eine eigene Fehlerroutine zur Behandlung von Eingabefehlern. Der Fehlercode hat den Aufbau iikk fuer Fehler, die zum Abbruch fuehren, -iikk fuer Warnungen. mit ii = 14 fuer KFFORM. Im folgenden eine Liste der Fehler und Warnungen: kk Fehler bzw. Warnung 1 fehlender Endapostroph bei alphanumerischer Eingabe 2 kein Leerzeichen nach Endapostroph bei alphanumerischer Eingabe 3 Fehler bei komplexer Zahl 4 fehlende rechte Klammer bei komplexer Zahl 5 fehlendes Komma bei komplexer Zahl 6 Fehler beim Lesen von Eingabedaten 7 Syntaxfehler bei Eingabedaten 8 end of record 9 zu viel Zeichen bei hexadezimaler Eingabe 10 ungueltiges Zeichen bei hexadezimaler Eingabe 11 ungueltiges Zeichen bei integer Eingabe 12 ungueltiges Zeichen bei real Eingabe im Q-Format 13 ungueltiges Zeichen bei real Eingabe im E-Format 16 ungueltiges Zeichen bei real Eingabe im D-Format 17 ungueltige real Eingabe 18 Fehler bei Wiederholung von Eingabegroessen 19 Fehler bei der Konvertierung von Eingabegroessen 20 Fehler in einem Kommentar 21 gueltiges Zeichen in Spalte 72 22 Benutzung von @ fuer Character-Eingabe nicht erlaubt -1 real Eingabe im Betrag zu gross (Maximalwert wird gesetzt) -2 integer Eingabe im Betrag zu gross (Maximalwert wird gesetzt) -3 keine Endkarte *$*$ gefunden 10.4.Umsetzung von KAPROS3- in KAPROS2-Fehlercodes Um die Umstellung von KAPROS2-Moduln zu erleichtern, die auf bestimmte Fehlercodes abfragen, wurde die Moeglichkeit geschaffen, gesteuert ueber die *KSPARM-Anweisung statt der KAPROS3-Fehlercodes die alten Fehlercodes von KAPROS2 zu setzen. Folgende Tabelle gibt, geordnet nach KAPROS2-Fehlercodes, die Umsetzungen wieder: KAPROS2 KAPROS3 Routine Bedeutung 50111 524 KSGET Datenblock nicht gefunden 50216 529 KSGET falscher Index 50440 525 KSGET Relativadresse .LE.0 50042 526 KSGET Versuch, leeren Datenblock zu bearbeiten 50544 527 KSGET falsche Adresse 60045 623 KSPUT Datenblock bereits vorhanden 70111 724 KSCH Datenblock nicht gefunden 70216 729 KSCH falscher Index 70544 727 KSCH falsche Adresse 80111 824 KSGETP Datenblock nicht gefunden 80042 826 KSGETP Versuch, leeren Datenblock zu bearbeiten 90005 922 KSPUTP Pointer-Lifeline voll 90045 923 KSPUTP Datenblock bereits vorhanden 11.Verbindung von KAPROS-Kern und Moduln 11.1.Prinzipielles Vorgehen beim Aufruf von Moduln Das prinzipielle Vorgehen beim Aufruf von Moduln ist in /4/ genauer beschrieben, im folgenden soll ein kurzer Abriss dieses Verfahrens gegeben werden. Ein Schematischer Ablauf des Vorgehens beim Aufruf von Moduln ist im folgenden Kapitel wiedergegeben. Das Betriebssystem uebergibt zunaechst dem Hauptprogramm MAIN des KAPROS-Kerns die Kontrolle. Beim Aufruf eines Steuermoduls durch den KAPROS-Kern oder beim Aufruf eines weiteren Moduls durch einen Modul mit Hilfe von KSEXEC wird durch die KAPROS-Routine KSEXEB die Assembler-Routine LINKB aufgerufen: CALL LINKB (CALMOD,MPARM,IBCADR,IBASE) Dabei bedeuten: CALMOD Name des gerufenen Moduls CHARACTER*8 MPARM Feld mit Aufrufparametern des Moduls (z.Zt.20 4-Byte-Worte) IBCADR Feld mit Adressen der KAPROS- und System-Routinen IBASE Feld mit KAPROS-Parametern Register 1 enthaelt beim Aufruf eine Adresse, die auf die Argumentliste fuer LINKB verweist. Vor Aufruf des LINK-Makros durch LINKB, das den Modul CALMOD aufruft, wird der Beginn der Argument-Liste in Register 1 auf MPARM gesetzt. Im Modul CALMOD ist als Einsprungadresse die Assembler-Routine KS3 deklariert. Durch Uebertragung der Adresse der Argument-Liste in Register 1 wird KS3 mit den Argumenten (MPARM,IBCADR,IBASE) aufgerufen. KS3 ruft die FORTRAN-Routine KS3$M$ mit denselben Argumenten auf. KS3$M$ ruft zunaechst das ENTRY IBCOB von KS3 mit dem Argument (IBCADR) auf zur Uebertragung der Adressen der zentral geladenen KAPROS- und System-Routinen, anschliessend das ENTRY KSEXEI von KSEXEC mit den Argumenten (MPARM,IBCADR,IBASE) zur Vorbereitung des evtl. Aufrufs eines weiteren Moduls durch CALMOD. Durch Aufruf der Routine KSSKBU, die ihrerseits den Modul als Subroutine aufruft, wird schliesslich der Modul angelaufen. Nach Beendigung eines Moduls wird hinter das LINK-Makro gesprungen, durch das der Modul aufgerufen wurde. Die Routinen KSEXEB und LINKB muessen sowohl im Kern als auch in jedem Modul geladen sein; die Routine KSEXEC wird nur bei Bedarf auch im Modul geladen. Dieses Vorgehen ist notwendig, um beim Aufruf eines Moduls durch einen anderen Modul die jeweils richtige Ruecksprung- Adresse in einer eigenen SAVEAREA gespeichert zu halten; bei einer Zentralisierung dieser Routinen wuerden Ruecksprung-Adressen ueberspeichert. 11.2.Zentralisierung von KAPROS- und System-Routinen Die KAPROS-Routinen sind zentral im KAPROS-Kern geladen; fuer I/O-Routinen ist es notwendig, sie nur einmal zentral zu laden. Fuer die uebrigen Routinen des Betriebssystems ist es aus Gruenden der Platzersparnis sinnvoll, sie ebenfalls nur einmal zentral zu laden und nicht in jedem Modul. Um die Verbindung zwischen Modul und den zentral geladenen Routinen herzustellen, sind im Modul ENTRYs fuer alle zentral geladenen KAPROS- und System-Routinen gespeichert, die auf die Anfangsadressen der zentral im Kern geladenen Routinen verweisen. Durch die Routine IBCENT im KAPROS-Kern werden die Anfangsadressen aller vom Modul gerufenen zentral geladenen KAPROS-und System-Routinen in dem Feld IBCADR gespeichert. Die Subroutine KS3 im Modul, die beim Aufruf eines Moduls als erste angelaufen wird, ruft die ebenfalls im Modul geladene Routine KS3$M$. Durch einen Aufruf des ENTRY's IBCOB von KS3 durch KS3$M$ werden die Adressen aller zentral geladenen System- und KAPROS-Routinen aus dem Feld IBCADR an KS3 uebertragen. Die Adresse des Feldes IBCADR wird als Argument beim Aufruf des Moduls uebergeben. Bei nachfolgenden Aufrufen dieser Routinen durch den Modul wird ueber die ENTRYs in KS3 in die Routinen im Kern gesprungen. Bei diesem Vorgehen muss die Liste der KAPROS- und System-Routinen in IBCENT und der dazugehoerigen ENTRYs in KS3 uebereinstimmen. Da die Routine KS3 in jedem Modul geladen ist, muessen bei einer Veraenderung der Liste der KAPROS- und System-Routinen z.B. durch Erstellung einer neuen KAPROS-Routine oder durch Wechsel des Compilers alle Module mit einer entsprechend veraenderten Routine KS3 neu gelinkt werden. Durch das Freihalten von Reserve-Plaetzen in IBCENT und KS3, denen bei Bedarf KAPROS- oder System-Routinen zugeordnet werden koennen, kann bei Erweiterungen der Liste erreicht werden, dass bereits fertig gelinkte Module weiterhin benutzt werden koennen. KAPROS-Kern: OS ==> MAIN CALL KSSKI (...) SUBROUTINE KSSKI (...) CALL IBCENT (IBCADR) Speichern Adressen zentral geladener ... KAPROS- und System-Routinen in KS3 CALL KSEXEB (CALMOD,MPARM,IBCADR,IBASE) SUBROUTINE KSEXEB (CALMOD,MPARM,IBCADR,IBASE) CALL LINKB (CALMOD,MPARM,IBCADR,IBASE) Aufruf LINK-MAKRO fuer CALMOD Modul CALMOD: ==> SUBROUTINE KS3 (MPARM,IBCADR,IBASE) CALL KS3$M$ (MPARM,IBCADR,IBASE) SUBROUTINE KS3$M$ (MPARM,IBCADR,IBASE) CALL IBCOB (IBCADR) ENTRY von KS3 Speichern Adressen zentral geladener KAPROS- und System-Routinen in KS3 CALL KSEXEI (MPARM,IBCADR,IBASE) ENTRY von KSEXEC uebertragen Adressen von MPARM,IBCADR,IBASE an KSEXEC fuer weitere Modul-Aufrufe CALL KSSKBU (MPARM) SUBROUTINE KSSKBU (MPARM) | der MPARM-Parameter CALL CALMOD (MPARM) Modul | kann | im Modul SUBROUTINE CALMOD (MPARM) | entfallen ... Aufruf KAPROS- oder System-Routine SYSROUT: CALL SYSROUT ==> KS3 ==> SUBROUTINE SYSROUT in Kern CALMOD <== KS3 <== ... Aufruf eines weiteren Moduls MODUL: (entspricht Aufruf von CALMOD im KAPROS-Kern) CALL KSEXEC (MODUL,...) SUBROUTINE KSEXEC (MODUL,...) CALL KSEXEB (MODUL,MPARM,IBCADR,IBASE) SUBROUTINE KSEXEB (MODUL, | Duplikat MPARM,IBCADR,IBASE) | von KSEXEC, | LINKB CALL LINKB (MODUL, | KSEXEB aus MPARM,IBCADR,IBASE) | KAPROS-Kern Aufruf LINK-MAKRO fuer MODUL ==> SUBROUTINE KS3 ... | MODUL RETURN CALMOD <== ... RETURN KAPROS-Kern <=== 12.Datenbloecke in der Lifeline Daten werden in der Form von Datenbloecken (DB) in der Lifeline (LL) gespeichert, dabei wird unterschieden zwischen Pointer-Datenbloecken (Pointer-DB), auf die in Pointertechnik zugegriffen wird, und Datenbloecken (DB), die in Uebertragungstechnik bearbeitet werden. Die Lifeline besteht aus dem freien Speicherplatz sowie bei Bedarf dynamisch allokierten Dateien mit 1000x1024 bytes Speicherkapazitaet auf den nicht durch andere Dateien belegten FORTRAN-Einheiten 89 bis 1 fuer die External Lifeline. Unter freiem Speicherplatz wird derjenige Speicherplatz in der Region verstanden, der nicht vom KAPROS- Systemkern oder Modul belegt ist oder vom Betriebs-System z.B. fuer Puffer benoetigt wird; in ihm liegen die Pointer-Lifeline und die Internal Lifeline. Die Data-Lifeline besteht aus der Internal Lifeline und der External Lifeline. DB auf direct access Archiven koennen wie normale DB auf der DL gelesen werden. LL Lifeline LL PL Pointer-Lifeline | DL Data-Lifeline ------- IL Internal Lifeline | | EL External Lifeline PL DL <- - - - SA DA direct access Archive | SA sequentielle Archive ------- - - - | | | IL EL DA Auf Pointer-DB wird mit Hilfe eines Pointers, der den Anfang des Pointer-DB in Bezug auf ein Feld im Programm kennzeichnet, direkt zugegriffen. Damit der Pointer waehrend des Progammablaufs Gueltigkeit behaelt, duerfen Pointer-DB nicht verschoben werden. Pointer-DB koennen nur freigegeben werden, wenn sie nicht von einem Modul auf hoeherem Level mit einem Pointer belegt sind. Freigegebene Pointer-DB koennen entweder sofort in die DL ausgelagert werden (default bzw. KSPARM SHIFTON) oder aber in der Datenblock-Tabelle fuer eine spaetere Auslagerung markiert werden, falls der vom freigegebenen Pointer-DB belegte Platz in der PL benoetigt wird (KSPARM SHIFTOFF). Pointer-DB koennen nicht nachtraeglich erweitert werden. Auf nicht Pointer-DB (DB) wird zugegriffen, indem Teile des DB oder der gesamte DB uebertragen werden. DB duerfen vom KAPROS-Systemkern bei Bedarf von der IL in die EL verschoben werden. Da die EL als externe Datei dynamisch allokiert wird, ist die Speicherung von grossen Datenmengen moeglich. DB koennen nachtraeglich erweitert werden, dabei wird folgendermassen vorgegangen: a1.der DB liegt in der IL und wird nicht durch einen dahinterliegenden DB blockiert: der DB kann durch Veraenderung des Eintrags fuer die End-Adresse des DB in der Datenblock-Tabelle (DBT) erweitert werden. Falls der Platz in der IL fuer die Erweiterung nicht ausreicht, wird der DB in die EL verschoben und dort erweitert. a2.der DB liegt in der IL und ist durch einen dahinterliegenden DB blockiert: der DB wird in die EL verschoben und dort erweitert. b1.der DB liegt auf der EL und wird nicht durch einen dahinterliegenden DB blockiert: der DB kann durch Veraenderung des Eintrags fuer die End-Adresse des DB in der DBT erweitert werden. Verschieben auf eine weitere Einheit der EL bei Platzueberschreitung ist z.Zt. nicht vorgesehen; eine derartige Konstellation fuehrt zum Abbruch. b2.der DB liegt auf der EL und ist durch einen dahinterliegenden DB blockiert: der DB wird auf eine weitere Einheit der EL verschoben und dort erweitert (realisiert 11.93). 13.Datenblocktabelle 13.1.Anlegen der Datenblocktabelle Die Datenblocktabelle (DBT) enthaelt fuer jeden Datenblock (DB) einen Eintrag. Die Eintraege sind nach dem Level, auf dem die DB angelegt wurden, geordnet. Innerhalb des gleichen Levels sind sie in der Reihenfolge ihres Anlegens geordnet, fuer gleiche Namen nach dem Index des DB. Die Anzahl der DB-Eintraege fuer jeden Level (einschliesslich der Anzahl der Eintraege fuer hoehere Level) wird in dem COMMON-Feld IBT gespeichert, die Gesamtzahl aller Eintraege in der COMMON-Variablen LEBT. Wenn ein Modul im *GO-Verfahren aufgerufen wird, wird eine Kopie der bereits vorhandenen DBT mit Referenzen auf die existierenden DB an die DBT angefuegt. Wenn ein Modul durch KSEXEC aufgerufen wird, werden zunaechst fuer DB, die noch nicht existieren aber uebertragen werden, Eintraege in den Bereich der DBT eingefuegt, der dem rufenden Modul zugeordnet ist. Anschliessend werden fuer die DB, die dem gerufenen Modul uebertragen werden, Eintraege mit Referenzen auf die zugehoerigen DB des rufenden Moduls angefuegt. Wenn in den rufenden Modul zurueckgesprungen wird, werden alle Eintraege auf dem Level des gerufenen Moduls, die Referenzen auf DB des rufenden Moduls enthalten, geloescht. Auf diese Art bleiben beim *GO-Verfahren neu angelegte DB fuer spaetere Zugriffe durch weitere Module erhalten. 13.2.Aufbau der Datenblocktabelle KSDBN Name des DB (CHARACTER*16) KSDBI Index des DB KSDBA >0 Start-Adresse des DB auf dem Speichermedium, auf dem der DB gespeichert ist (definiert durch KSDBS) 0 Datenblock noch nicht definiert <0 Referenz auf die Position eines vorhergehenden Eintrags in der DBT KSDBR hoechste belegte Adresse fuer Pointerbloecke gleich KSDBE nach dem Reservieren gesetzt auf KSDBA-1 KSDBE End-Adresse des DB KSDBK Kontroll-Wort, das den Zustand des DB kennzeichnet 0 Datenblock noch nicht reserviert (z.B. durch Aufruf von KSEXEC mit Uebertragung eines neuen DB) 1 Platz fuer den DB ist reserviert und initialisiert 2 der DB wurde bereits benutzt (KSCH,KSCHP) 3 Bearbeitung des DB ist abgeschlossen (RETURN in rufenden Modul bzw. KAPROS3-Kern) 4 fuer einen Pointer-DB wurde mit KSPUTP Platz in der PL reserviert 5 ein Pointerblock in der PL wurde mit KSGETP benutzt 6 Archiv-DB KSDBS Kontroll-Wort fuer die Art des DB 0 Pointer-DB auf der PL 1000 DB auf der IL 0 0 sequentielles Archiv < 0 direct acces Archiv KSSPEC Specifikation des Archivs (CHARACTER*72) Referenzen /1/ G.Buckel, W.Hoebel: Das Karlsruher Programmsystem KAPROS Teil I Uebersicht und Vereinbarungen Einfuehrung fuer Benutzer und Programmierer KFK 2253, 1976 /2/ H.Bachmann, S.Kleinheins: Das Karlsruher Programmsystem KAPROS Teil Ia Kurzes KAPROS-Benutzerhandbuch KFK 2317, 1976 /3/ J.Gutzler, S.Haas, W.Hoebel, B.Morath: KAPROS-SUBSYSTEM-KERN KSSK persoenliche Mitteilung, 1987 /4/ G.Buckel, W.Hoebel: Eine Methode zur Realisierung dynamischer Strukturen in IBM-FORTRAN KFK 1669, 1973 /5/ N.Moritz Die FORTRAN-77 Version des Karlsruher Programmsystems KAPROS KFK 3860, 1985 /6/ D.Woll Kurzbeschreibung des KAPROS-Moduls PRINDB zum Ausdruck von KAPROS-Datenbloecken in leicht lesbarer Form persoenliche Mitteilung, 1982 Aufbau der COMMON-Bereiche KSVCOM und KSCCOM sowie des Feldes IBASE KAPROS-System-Parameter werden innerhalb des KAPROS-Kerns ueber die COMMON-Bereiche KSVCOM fuer REAL, INTEGER und LOGICAL-Werte und KSCCOM fuer CHARACTER-Werte uebertragen. In der folgenden Beschreibung (Programm-Kommentar von KSTBCO) sind die Parameter in der Reihenfolge ihres Auftretens in KSVCOM und KSCCOM angeordnet. (???? deuten an, dass die aus /3/ uebernommenen Parameter in ihrer Bedeutung fuer KAPROS3 ueberprueft werden sollten.) PARAMETER VALUES (MAXIMUM VALUES) NRDBN NUMBER OF DATABLOCKS (394) NRMOD NUMBER OF MODULES (30) (LEVEL OF DEEPEST DESCEND IN CALLING HIERARCHY) N1KB NUMBER OF BYTES OF ONE PAGE (1024) COMMON /KSVCOM/ MODIN STANDARD INPUT UNIT (5) MODOUT STANDARD OUTPUT UNIT (6) KSSKUN STANDARD MESSAGE UNIT (42) NERKSS ERROR CODE KERKSS ERROR CLASS <0 WARNING 0 NO ERROR 1 ERROR IN PARAMETER-LIST 2 ERROR IN KAPROS3-SYSTEM 3 ERROR IN OPERATING-SYSTEM 4 INPUT-ERROR 5 MODUL-ERROR 6 ERROR-CODE SET BY MODUL TRACE FLAG FOR PRINTOUT OF A TRACE (0) 0 NO PRINTOUT OF A TRACE 1 PRINTOUT OF A TRACE LKSSK NOT USED ?????????????????????????????????????????? TAUM MAXIMUM LEVEL = NRMOD TAUR REACHED LEVEL KSSZT FLAG FOR TIME CONTROL (0) 0 NO TIME CONTROL 1 TIME CONTROL ZEITKS TIME USED BY KAPROS ZEITJB TIME USED BY JOB ZEITJB TIME USED BY MODULE KSCNTR CONTROL WORD FOR DATACHECK (Z7FFFFFFF) VERIFY FLAG FOR DATACHECK (1) 0 NO DATACHECK 1 DATACHECK TOZEIT REMAINING CPU TIME NRARCO NUMBER OF OUTPUT ARCHIVE FILES LTRT FLAG FOR OUTPUT OF TRACE AND TIME CONTROL (.FALSE.) TRUE OUTPUT OF TRACE AND/OR TIME CONTROL FALSE NO OUTPUT OF TRACE AND NO TIME CONTROL KTRFRM FLAG FOR PRINTOUT OF A TRACE IN KSFORM (0) 0 NO PRINTOUT OF A TRACE IN KSFORM 1 PRINTOUT OF A TRACE IN KSFORM MODINF FLAG FOR OUTPUT OF MODULE INFORMATION BY THE MODULE (0) 0 NO MODULE INFORMATION IS TO BE GIVEN 1 MODULE INFORMATION IS TO BE GIVEN DBSHFT FLAG FOR TREATING POINTER DATABLOCKS (1) 0 SHIFTING OF POINTER DATABLOCKS WHEN THE PL IS FILLED 1 IMMEDIATELY SHIFTING WHEN POINTER DATABLOCKS ARE FREED KDBT FLAG FOR PRINTING DATABLOCKTABLE (0) -1 NO PRINTOUT OF DBT 0 START VALUE, WILL BE CHANGED IN KSGO TO 1 1 PRINTOUT OF DBT 2 PRINTOUT OF LONG DBT KSDBI(NRDBN) INDEX OF THE DB KSDBA(NRDBN) ADDRESSES >0 STARTING ADDRESS OF THE DB ON THE ASSOCIATED STORAGE UNIT DEFINED BY KSDBS 0 DB NOT YET RESERVED <0 REFERENCE TO A PRECEDING POSITION OF THE DBT KSDBR(NRDBN) HIGHEST USED ADDRESS EQUAL KSDBE FOR POINTER-DB SET TO KSDBR-1 WHEN RESERVING A DB IN THE LL KSDBE(NRDBN) END ADDRESS OF THE DB KSDBK(NRDBN) CONTROL WORD 0 DB NOT YET DEFINED (BY CALL OF KSEXEC WITH A NEW DB) 1 SPACE FOR THE DB IS RESERVED AND INITIALISED 2 DB HAS ALREADY BEEN USED 3 DB CLOSED AFTER RETURN OF THE CREATING MODULE 4 SPACE FOR THE DB IS RESERVED IN THE PL BY KSPUTP 5 THE DB IN THE PL IS USED BY KSGETP KSDBS(NRDBN) CONTROL WORD FOR THE TYPE OF THE DB 0 POINTERDB LOCATED IN THE PL 1000 DB LOCATED IN THE IL 0