MVS/ESA JCL: Einführung in die Praxis [3., korr.und akt. Aufl. Reprint 2014] 9783486599008, 9783486250589

Citation preview

Herausgegeben von

Dr. Klaus Becker-Berke

MVS/ESA JCL Einführung in die Praxis von

Michael Winter Deutsche Lufthansa AG

3., korrigierte und aktualisierte Auflage

Oldenbourg Verlag München Wien

Michael Winter sammelte nach seinem Studium mehrjährige Erfahrung als Anwendungsentwickler in der IBM-Welt in den Umgebungen DOS/VSE und MVS/TSO, bevor er als EDV-Dozent zur Deutschen Lufthansa AG wechselte. Er ist dort verantwortlich für die Schulung der Programmierer in den Bereichen TSO/ISPF, MVS, JCL und REXX sowie systemnaher Software. Anschrift: Michael Winter Lufthansa Systems GmbH Am Weiher 24 65451 Kelsterbach Tel.:+49 69 696 6587 Fax: +49 69 696 6588 E-Mail: [email protected]

Die Deutsche Bibliothek CIP-Einheitsaufnahme -

Winter, Michael: MVS ESA JCL : Einfuhrung in die Praxis / von Michael Winter. [Hrsg. von Klaus Becker-Berke.]. 3., korrigierte und aktualisierte Aufl. München ; Wien : Oldenbourg, 1999 -

ISBN 3-486-25058-2 -

© 1999 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0, Internet: http://www.oldenbourg.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen.

Lektorat:

Birgit Zoglmeier Herstellung: Rainer Haiti Umschlagkonzeption: Kraxenberger Kommunikationshaus, München Gedruckt auf säure- und chlorfreiem Papier Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH, München

Inhaltsverzeichnis V

Inhaltsverzeichnis

Vorwort.XIII

Auflage.XIV Einleitung.1

Vorwort 1

zur

3.

Warum ist JCL so wichtig?.1 Wie ist dieses Buch aufgebaut?.1 Wer kann dieses Buch nutzen?.2 Was dieses Buch nicht ist.3

1.1

Grundbegriffe.3

MVS-Betriebssysteme.3

Speichermedien.4 Plattenspeicher.4 Magnetbänder und Kassetten.5 Logische versus physische Records.6 Datenverwaltung VTOC, VVDS und Katalog.6

Datenverwaltung und -Sicherung: DFHSM und RACF.11 Datenmanagement SMS.11 Zugriffsmethoden.12 -

-

VSAM.12

QSAM.12 Record-Formate.12

Datenorganisation PS oder PO.13 1.2 Der Ablauf des Jobs.13 Die 5 Jobphasen.14 Der Initiator.17 1.3 Fehlermeldungen.20 -

2

JCL.23 Aufbau der JCL-Anweisungen.23 Das Identifikationsfeld.23 Das Namefeld.24 Das Operationsfeld.24 Das Parameterfeld.24 Das Kommentarfeld.25

Fortsetzungsregeln.25

Default-Werte.26 Parameter.26

2.1 Die JOB-Anweisung.26 Der Beginn der JOB-Anweisung.27

VI Inhaltsverzeichnis

CLASS.28 MSGCLASS.28 MSGLEVEL.29 NOTIFY.30 REGION auf Job-Ebene.30 TIME auf Job-Ebene.31

TYPRUN.31 COND auf Job-Ebene.31 RESTART.33

Beispiele.33 EXEC-Anweisung.34

2.2 Die

PGM.34

PROC als Parameter der EXEC-Anweisung.35

PARM.35 COND auf EXEC-Ebene.36 TIME und REGION auf EXEC-Ebene.38 Abhängiges Ausführen von Steps mit IF/ELSE.38 2.3 Die DD-Anweisung für Datasets auf Platte.41 Existierende Datasets ansprechen.41

Verbindung zum Anwendungsprogramm.42 Beispiele für das Ansprechen existierender Datasets.42 Datasets auf Plattenspeicher anlegen.44 DSNAME.44 DISP.46

Der Subparameter status.46 Der normal-disp Subparameter.47 Der abnormal-disp Subparameter.49

Die Defaults für den DISP-Parameter.49 Beispiele zur Verwendung des DISP-Parameters.50

UNIT.51 VOLUME.52 SPACE.54

DCB.55 LRECL.57 BLKSIZE.57 Arbeiten mit dem Katalog.61 Besondere DD-Anweisungen.62 DD-Namen für Utility Output.62 DD-Namen für DISPLAY Output.63 Die STEPLIB DD-Anweisung.63 Die JOBLIB DD-Anweisung.64 Der DD DUMM Y-Parameter.65 Verketten von Datasets.66 DD SYSOUT-Anweisungen.67 Der DCB-Parameter.67 Der OUTLIM-Parameter.68

Inhaltsverzeichnis VII Der COPIES-Parameter.68 Der DEST-Parameter.68 Der SEGMENT-Parameter.69 Der SPIN-Parameter.69 Der FREE-Parameter.70 Die SYSIN DD-Anweisung.70

Output Management.73 DD-Anweisung für Datasets auf Bändern oder Kassetten.83

2.4 Die

Ansprechen von Datasets auf Band oder Kassette.83

Der Parameter UNIT=AFF.84 Schreiben von Datasets auf Band oder Kassette.85 Ein Dataset auf Band oder Kassette schreiben.86

EXPDT.86 RETPD.87

Beispiel für ein Anlegen eines Datasets auf einer Kassette.87 Arbeiten mit dem Katalog bei Bändern/Kassetten.88 Mehrere Datasets hintereinander auf Band oder Kassette schreiben.90 LABEL.91 VOLUME für Band Verarbeitung.91 Beispiele für Multi-File Technik.94 Ein großes Dataset auf mehrere Kassetten schreiben.97 Besonderheiten bei Band- bzw. Kassettenverarbeitung.98 MVDs lesen oder mit DISP=MOD erweitern.98

UNIT=(„DEFER).98

Der unit-Subparameter.98 Der Anzahl-Subparameter.98 Der DEFER-Subparameter.99 Nicht katalogisierte Datasets von Bändern/Kassetten lesen.99

Bänder exportieren.100 Standardbänder importieren.100 Kassetten/Bänder ohne Standardlabel verarbeiten.100 Die Subparameter NL, LTM und BLP.101 ASCII Daten auf Kassetten/Bändern verarbeiten.103 OPTCD für Bandverarbeitung.103 2.5 PASSen von Datasets zwischen Steps.104 Was passiert beim PASSen.104 2.6 Temporäre Datasets.108 Der DSN temporäre Datasets.108

Symbolische DSNs.108 Rückbezüge (Referbacks).109

DISP=(,PASS) für temporäre Datasets.111 UNIT und temporäre Datasets.112 Mögliche Probleme bei der Benutzung temporärer Datasets.113

Nicht-eindeutige symbolische DSNs.113 RESTART und

temporäre Datasets.114

VIII Inhaltsverzeichnis 2.7 Die OUTPUT JCL-Anweisung.117

ADDRESS.118 BUILDING.119 CLASS.119 COPIES.119 DEFAULT.119 DEPT.120 DEST.120 NAME.120 ROOM.120 TITLE.121

3

JCL-Prozeduren.123 Arten

3.1

von

Prozeduren.124

Benutzung katalogisierter Prozeduren.124

Katalogisierte Prozeduren auf privaten Bibliotheken.128 Die JCLLIB-Anweisung.129 Möglichkeiten der Anpassung.129 Ändern von EXEC-An Weisungen.130 Ändern von DD-Anweisungen.131

3.2

Hinzufügen von DD-Anweisungen.132 Gleichzeitiges Einfügen und Ändern von Anweisungen.133 Eigene Prozeduren schreiben.136 In-Stream-Prozeduren.137

Symbolische Parameter einsetzen.139 Wertzuweisungen für symbolische Parameter.140

SYSIN und Prozeduren.146 Die SYSIN DD DDNAME-Anweisung.146 Die SYSIN DD DSN-Anweisung.147 Die SET-An Weisung.151 Die INCLUDE-Anweisung.152

4

Utility-Programme.155 Allgemeine Merkmale von Utility-Programmen.155 Kontrollkommandos für

4.1

Utility-Programme.156

IDCAMS.157

Datasets löschen mit dem IDCAMS DELETE-Kommando.157

PURGE NOPURGE.158 SCRATCH NOSCRATCH.158 IDCAMS DELETE Beispiele.159 Datasets kopieren mit dem REPRO-Kommando.164 Datasets drucken mit dem PRINT-Kommando.167 -

-

-

4.2 IEBGENER.171 Datasets kopieren mit IEBGENER (SYNCGENR).171 Datasets umformatieren mit IEBGENER.175

Inhaltsverzeichnis IX Das GENERATE-Kommando.175 Das RECORD-Kommando.176 4.3 IEHPROGM.178 Bänder/Kassetten mit IEHPROGM entkatalogisieren.179 4.4 Die SORT Utility.180 JCL-Anweisungen für Sort-Programme.181 Sortieren mit dem SORT FIELDS-Kommando.183 Erhalten der ursprünglichen Reihenfolge.'..185 Beispiel für einen SORT über ein Feld.185 Verbesserungen der Performance beim SORT.187 Records auswählen mit INCLUDE oder OMIT.187 Verkürzung des zu sortierenden Records mit INREC.190 Einsatz von SUM FIELDS im SORT.192 Echtes Summieren mit SUM FIELDS.193 Unterdrücken von Duplikaten.195 Mischen von Datasets mit MERGE FIELDS.196 Kopieren von Datasets mit OPTION COPY.197 SORT Beispiele.198 4.5 Generation Data Groups.203 Erzeugen des GDG-Basiseintrags mit IDCAMS.204 Erzeugen einer neuen Generation.205 Abändern von Basisparametern.207 Ändern des LIMITS ohne SMS.208 Ändern des LIMITS mit SMS.209 Ansprechen existierender GDGs.210 Löschen einer GDG ohne SMS.210 Löschen einer GDG mit SMS.211 Besonderheiten von GDGs.212 4.6 IEBCOPY.212 Bibliotheken kompressen mit IEBCOPY.212 4.7 IEFBR14.213 Dispositions-Verarbeitung mit IEFBR14.214

5

VSAM.217 Arten von VSAM-Datasets.217 VSAM KSDS-Datasets.218

Die Datenkomponente.218 Das Kontrollintervall (CI).219 Die Control Area.223 Die Indexkomponente.223 Lesen von Records.225

DerCI-Split.228 DerCA-Split.229

KSDS-Datasets mit Alternativschlüssel.230 VSAM ESDS-Datasets.231

X Inhaltsverzeichnis

VSAM RRDS-Datasets.232 Die relative Byte Adresse (RBA).232

Übersicht VSAM-Datasets.232

5.1 Linear Data Sets.233 5.2 IDCAMS für VSAM-Datasets.234 Anlegen von VSAM-Datasets mit DEFINE CLUSTER.236

NAME.237 Platzanforderung für VSAM-Datasets.237 VOLUMES.238 Die

Datasetorganisationsparameter.239

RECORDSIZE.239 CONTROLINTERVALSIZE.239

UNIQUE.240

SUB ALLOCATION

KEYS.240 FREESPACE.241 SHAREOPTIONS.241 ERASE NOERASE.243 RECOVERY SPEED.243 IMBED NOIMBED.243 REPLICATE NOREPLICATE.244 ORDERED UNORDERED.244 KEYRANGES.245 REUSE NOREUSE.246 BUFFERSPACE.246 FOR-TO.247 SPANNED NONSPANNED.247 Anlegen eines KSDS-Dataset.247 Anlegen eines ESDS-Datasets.249 Anlegen eines RRDS-Datasets.250 Anlegen eines LDS-Datasets.251 -

-

-

-

-

-

-

-

VSAM-Datasets laden mit dem REPRO-Kommando.252 VSAM KSDS-Datasets reorganisieren.255 VSAM-Datasets mit Alternativindex anlegen.257 Das DEFINE AIX-Kommando.259

Beispiel für DEFINE AIX.262

Pfade für AIX-Datasets mit DEFINE PATH definieren.263 Beispiel für Anlegen eines Pfades.265 Alternativindex laden mit BLDINDEX.265 Beispiel für BLDINDEX.266 Erstellen und Laden des AIX.268 Ansprechen über den AIX im Batch.269 VSAM Informationen mit LISTCAT abrufen.270 Der Output des LISTCAT.272 VSAM-Datasets recovern VERIFY.278 JCL für existierende VSAM-Datasets.279 Der AMP-Parameter in der DD-Anweisung.279 -

Inhaltsverzeichnis XI VSAM-Datasets drucken mit dem PRINT-Kommando.280 VSAM-Datasets löschen mit IDCAMS DELETE.283 PURGE NOPURGE.284 ERASE NOERASE.284 IDCAMS DELETE Beispiel.284 Return Codes verändern mit IDCAMS Modal-Kommandos.287 5.3 COBOL für VSAM-Datasets.288 Die SELECT ASSIGN-Anweisung.288 SELECT ASSIGN für KSDS-Datasets.288 SELECT ASSIGN für ESDS-Datasets.289 SELECT ASSIGN für RRDS-Datasets.290 Die FD-Anweisung.,.290 Die OPEN-Anweisung.291 -

-

-

Lesezugriffe.292 Schreibzugriffe.293 Löschen von Records.293 START und READ NEXT.293

Beispiel.294 6

SMS

-

Storage Management Subsystem.303

6.1 SMS installiert, aber nicht aktiviert.304 Wegfall der Blocksize-Angaben.304 Konkatenieren von Kassettendatasets.307 Konkatenieren von ungleichen Datenträgern.308 Ändern des LIMITS eines Generationdatasets.308 Kilobytes und Megabytes beim Anlegen eines VSAM-Dataset.309 6.2 SMS installiert und aktiviert.310 Neue JCL-Anweisungen für SMS.311 AVGREC und SPACE.311

DATACLAS.311 KEYLEN.312 KEYOFF.313 LIKE.313 MGMTCLAS.314 RECORG.315 REFDD.315 SECMODEL.316 STORCLAS.316 Neue IDCAMS-Parameter für SMS.317

6.3

SMS-managed

vs.

nicht-SMS-managed.317

Anlegen von Datasets unter SMS ohne ACS.318 Sequentielle Datasets.318

VSAM-Datasets......320

Anlegen von Datasets unter SMS mit ACS.322 Sequentielle Datasets.322

XII Inhaltsverzeichnis

6.4

VSAM-Datasets.324 Mögliche Probleme beim Einsatz von SMS.324 VOL=SER in der JCL.324 DISP=(OLD,DELETE) bei VSAM-Datasets.326 Datasets auf mehreren Platten.326 Löschen und entkatalogisieren von Datasets.327 Nicht optimierte Blocksize.329 JOBCAT und STEPCAT.329 Neue Defaults beim DISP-Parameter.330

7

JCL-Schnittstellen.333

7.1 JCL aus CLISTen submitten.333 7.2 JCL aus REXX EXECs submitten.337 7.3 JCL mit File Tailoring Services generieren.339 Erzeugen eines temporären Jobs.340 Erzeugen des Jobs als Member einer Bibliothek.342 Erzeugen des Jobs aus mehreren SKEL Membern.344 7.4 TSO-Kommandos mit JCL absetzen.347

8

JCL-Fehler und ABENDs.349 Fehler in der JOB-Anweisung.349 Fortsetzungsfehler.349 Häufige Laufzeitfehler.351

Unsichtbare Fehler.352 8.1 ABEND Codes.353 ABEND Codes 001 bis 04F.353 ABEND Codes 100 bis EFF.355 ABEND Codes xFO bis xFF.357 ABEND Codes Fxx bis FFF.357

9

Anhang.359

9.1 Aufbau von Volume und Header Records.359 9.2 Nutzungsraten unterschiedlicher BLKSIZEs.363 9.3 CI-Größe und Plattennutzung.364 9.4 Glossar.366 9.5 Literatur.380 9.6 Installationsspezifische Daten.382 9.7 COBOL Return Codes für das FSl-Feld.384 9.8 Index.386

Vorwort Von einem, der auszog, JCL zu lehren Mal ganz ehrlich: Wie sind Sie

zu

Ihrer ersten JCL

gekommen?

War es nicht auch so, daß ein netter Kollege Ihnen anbot, seine JCL zu kopieren. "Da ändern Sie mal meine Userid in Ihre und dann wird das Ganze schon funktionieren". Und es funktionierte. Manchmal. Manchmal funktionierte es auch nicht und der nette Kollege hatte gerade Urlaub. Dann war man gezwungen, Änderungen an Dingen vorzunehmen, die man womöglich nicht verstand. Die Resultate sind meist dementsprechend. Erstaunlicherweise gibt es heutzutage noch viele Verantwortliche in der DV-Industrie, die der Meinung sind, man könne JCL so eben nebenbei lernen. Gerade für Anwendungsprogrammierer wird eine JCL-Ausbildung oft für überflüssig gehalten. Die Folgen dieser Haltung konnte ich am eigenen Leib erfahren. Auch ich bin in der oben beschriebenen Weise zum ersten Mal mit JCL in Berührung gekommen. Eine gezielte JCLAusbildung gab es nicht. 'Learning by doing' war angesagt, meistens war es jedoch 'Learning by surprise' oder 'Learning by ABEND'. Ich habe so ziemlich jeden JCL-Fehler und jeden ABEND mitgemacht. Doch diese Art, JCL zu lernen, ist sehr langwierig und ineffizient. Damals hätte ich ein Buch, wie es jetzt hier vorliegt, gut gebrauchen können. Dieses Buch ist aus den Erfahrungen der Praxis entstanden. Es vermittelt Ihnen die Kenntnisse, die Sie brauchen, um mit JCL sicher umgehen zu können. Es vermittelt auch wichtige Zusammenhänge. Sie sollen nicht nur Syntax beherrschen lernen, sondern Sie sollen vor allen Dingen verstehen, warum bestimmte Dinge so funktionieren, wie sie funktionieren. Das Buch ist in zweierlei Hinsicht strukturiert. Zum einen im Hinblick auf die Parameter, die Sie einsetzen müssen, zum anderen im Hinblick auf bestimmte Funktionen und Aufgabenstellungen, die Ihnen in Ihrer täglichen Arbeit begegnen können. Die Neuerungen, die sich mit der Version 4.2 (oder höher) von MVS/ESA ergeben haben, sind in diesem Buch berücksichtigt. Gleiches gilt für SMS, das Storage Management Subsystem, das in den letzten Jahren zu einem integralen Bestandteil der Datenverwaltung in der MVS-Welt wurde. Alle Neuerungen, die in Zusammenhang mit SMS stehen, werden vorgestellt. Großen Wert habe ich auf die Vollständigkeit der Beispiele gelegt. So ist nicht nur die JCL erläutert, es wird auch gezeigt, wie das entsprechende Programmcoding auszusehen hat. Ich habe mich entschlossen, dies immer an COBOL-Beispielen darzustellen, da diese Programmiersprache in der IBM-Welt noch immer große Bedeutung hat. Die im Buch verwendeten Begriffe und Abkürzungen werden bei ihrem ersten Auftauchen erläutert. Im Anhang befindet sich ein Glossar, in dem die wichtigsten Begriffe zusammengefaßt sind. Sollten Sie Dinge in diesem Buch entdecken, die bei Ihnen so nicht funktionieren, so halten Sie Rücksprache mit Ihrer Systemprogrammierung. Es ist durchaus denkbar, daß bei

XIV Vorwort

Ihnen Besonderheiten installiert worden sind. Ansonsten würde ich mich freuen, wenn Sie sich an den Verlag wenden würden. Dies gilt auch, wenn Sie bestimmte Dinge in diesem Buch erwartet und dennoch nicht gefunden haben. Ihre Anregungen können dann bei einer

Neuauflage Berücksichtigung finden.

Ich wünsche, daß Ihnen dieses Buch einige Aha-Erlebnisse vermitteln wird. Wenn es Ihnen gelingt, JCL damit zu meistern, so würde mich dies am meisten freuen. Dann hätte sich die Arbeit des Lehrenden gelohnt.

Frankfurt, im März 1996 Michael Winter

Vorwort zur 3.

Auflage

Sechs Jahre sind nunmehr seit dem Erscheinen der ersten Auflage dieses Buches vergangen. In dieser Zeit hat sich die EDV-Welt gravierend verändert. So stark sind Veränderungen, daß selbst die Prognosen der Fachleute über den Haufen geworfen wurden.

gibt Sie immer noch, entgegen aller Prognosen: Die IBM-Hosts. Auch sie haben sich angepaßt (wenngleich man das von der JCL nicht sagen kann, sie ist nun mal nicht so dynamisch). Sie werden die Jahrtausendwende erleben und, so hoffen alle, gut bewältigen.

Es

Da es die Rechner immer noch gibt, müssen die Programme weiter laufen. Der Bedarf nach JCL ist also immer noch vorhanden. Ich hoffe, daß es Ihnen mit Hilfe dieses Buches gelingen wird, praktische Probleme mit Hilfe von JCL zu bewältigen.

Frankfurt, im März 1999 Michael Winter

1

Einleitung

vorliegende Buch befaßt sich mit Job Control Language JCL. Um die Eigenheiten dieser Kontrollsprache zu verstehen, muß man wissen, daß man es bei JCL mit einem Produkt aus der Computer-Urzeit zu tun hat. JCL hat seine Ursprünge in den sechziger Jahren, als IBM die Computerserie der /360er Reihe einführte. Die JCL, die Sie heute benutzen, unterscheidet sich im Prinzip nicht von der, die es schon vor fast 30 Jahren gegeben hat. Dies ist auch einer der Gründe dafür, daß der Umgang mit JCL bisweilen schwerfällt. Das

-

JCL brauchen Sie, wann immer Sie Batch-Verarbeitung betreiben. Der Begriff BatchVerarbeitung ist ebenfalls ein Relikt aus der EDV-Urzeit, wurde damit doch der physische Lochkartenstapel bezeichnet, mit dessen Hilfe man früher Jobs in das System einlas. Heute werden die JCL-Anweisungen selbstverständlich auf elektronischem Wege erzeugt. Der

Begriff Batch-Verarbeitung ist jedoch geblieben.

Warum ist JCL

so

wichtig?

Wenn Sie auf einem IBM Großrechnersystem arbeiten, kommen Sie zwangsläufig mit JCL in Berührung. JCL wird gebraucht, um Anwendungsprogramme zu kompilieren und zu linken. Ohne JCL gibt es keine ausführbaren Programme. Anwendungsprogramme enthalten ausschließlich logische Datenbeschreibungen. Die Verbindung zu den physischen Daten erfolgt über JCL. Wenn Sie Funktionen, wie Kopieren von Datasets, nicht ständig manuell mit ISPF ausführen wollen, so brauchen Sie auch dazu JCL.

Gegensatz zu Ihrem Programm beschreibt JCL physische Daten. Zwar gibt es heute einen Trend, den Programmierer von den Zwängen der physischen Datensicht zu befreien, doch Sie sollten sich klarmachen, daß, auch wenn es wünschenswert ist, auf die physische Datensicht nicht verzichtet werden kann. Eine optimale physische Datenstruktur entscheidet letztlich über die Performance eines Programms. Sie entscheidet auch über eine optimale Nutzung der Im

Speicherressourcen. Dagegen ist die Frage, ob strukturiert oder unstrukturiert programmiert wurde, für die Performance und die

Speicherplatznutzung ohne jede Bedeutung.

Wie ist dieses Buch

aufgebaut?

In diesem einleitenden Kapitel wird auf einige wichtige Grundlagen Verständnis der Bedeutung der JCL-Parameter von Bedeutung ist.

eingegangen, die zum

MVS/ESA JCL

2

Kapitel Werden Ihnen alle wichtigen JOB-, EXEC- und DD-Anweisungen Sie lernen, existierende Datasets anzusprechen und neue Datasets im Job zu erzeugen. Die unterschiedliche Syntax für das Anlegen auf Platte bzw. Band/Kassette wird erläutert. Sie erlernen auch den Umgang mit temporären Datasets und wie Sie diese Datasets an die folgenden Steps übergeben können. Zur Vereinfachung wiederkehrender Abläufe lassen sich JCL-Prozeduren einrichten. Im Kapitel 3 lernen Sie, wie man vorhandene Prozeduren einsetzen kann und wie man eigene Prozeduren schreiben kann. Prozeduren geben Ihnen die Möglichkeit, Variable in der JCL zu definieren. Damit kann JCL sehr flexibel eingesetzt werden. Für eine ganze Reihe von wichtigen Funktionen, gibt es sogenannte Utility-Programme. Sie werden benötigt, um z.B. mit dem Katalog richtig umgehen zu können oder Datasets zu kopieren. Auf alle wichtigen Utility-Funktionen wird im Rahmen des Kapitels 4 Im zweiten

vorgestellt.

eingegangen. Umgang mit VSAM-Datasets erfordert eine umfangreiche Syntax, auf die im Kapitel 5 eingegangen wird. Sie lernen, wie die verschiedenen Arten von VSAM Datasets angelegt werden. Außerdem wird die Möglichkeit, Alternativindices zu definieren, erläutert. Dabei werden auch Performanceaspekte berücksichtigt. Wenn oben gesagt wurde, daß JCL in den letzten Jahren (Jahrzehnten) sehr statisch war, so gilt das nicht für SMS. Mit der Einführung vom SMS (System Managed Storage) ergeben Der

sich eine Reihe von Änderungen für die Benutzer von JCL. Zudem werden mit SMS 10 JCL-Parameter eingeführt. Im Kapitel 6 wird deren Benutzung ebenso erläutert wie auch Probleme, die sich beim Umstieg von einer Nicht-SMS auf eine SMS-Umgebung ergeben können. Im siebten Kapitel wird auf wichtige JCL-Schnittstellen eingegangen. Es wird gezeigt, wie Jobs auf andere Weise als durch einen SUBMIT aus einem Dataset heraus gestartet werden können. Dabei handelt es sich um die Möglichkeit, CLISTen oder REXX Execs zu nutzen. Der Dateierstellungsservice des ISPF (File Tailoring Service) stellt eine elegante Möglichkeit dar, JCL zu generieren. Auch dies wird im siebten Kapitel vorgestellt. Fehlermeldungen und ABENDs sind im Kapitel acht erläutert. Im neunten Kapitel finden Sie technische Daten, die für die Performance von Bedeutung sind. neue

Wer kann dieses Buch nutzen? Alle, die unter den Betriebssystemen MVS/XA und MVS/ESA arbeiten. Parameter, die erst mit MVS/ESA verfügbar wurden, sind mit (ESA) gekennzeichnet. Parameter, die mit der Version 4 von MVS/ESA verfügbar wurden, sind mit (ESA/4) gekennzeichnet. Ob Sie JCL-Neuling sind oder schon JCL-Erfahrung besitzen, spielt keine Rolle. Sie werden in jedem Fall

von

diesem Buch profitieren können.

Einleitung

3

Was dieses Buch nicht ist Dieses Buch will kein Ersatz für ein IBM Handbuch sein. Aus diesem Grund wird Ihnen immer nur die Syntax vorgestellt, die Sie in der Praxis brauchen. Auf eine vollständige Darstellung von in der Praxis nur sehr selten eingesetzten Parametern wird daher verzichtet.

1.1

Grundbegriffe

Wie Sie sehr bald merken werden, tauchen einige Begriffe in diesem Buch immer wieder auf. Es handelt sich dabei um zentrale Merkmale der MVS-Umgebung.

MVS-Betriebssysteme MVS/ESA ist bereits die dritte Generation der MVS-Betriebssysteme. MVS steht für ein Betriebssystem, das in der Lage ist, einen virtuellen Speicher zu benutzen. MVS ging aus einer Reihe von Vorgängersystemen hervor, deren Ursprung in das Jahr 1964 zurück reicht. Damals brachte IBM die Rechner der Reihe /360 auf den Markt und versprach seinen Kunden Aufwärtskompatibilität. Dieses Versprechen wurde bis heute immer eingehalten. Das wichtigste Betriebssystem der Nachfolgereihe /370 wurde MVS. In seiner Ursprungsversion MVS/370 bot es einen virtuellen Speicher mit 16 MB und eine 24Bit Adressierung. Schon gegen Ende der 70er Jahre konnte MVS/370 den gewachsenen Platzanforderungen nicht mehr gerecht werden. Insbesondere On-Line-Anwendungen wie IMS forderten ihren Preis. Die Antwort war das Betriebssystem MVS/XA, wobei XA für Extended Architecture steht. MVS/XA arbeitet mit einem virtuellen Speicher von 2 GB und einer auf 31 Bit erweiterten Adressierung. Das 32. Bit gibt den Adressierungsmodus an. Um die Kompatibilität zu wahren, wurde der virtuelle Speicher logisch um die 16 MB Linie gruppiert. 24-Bit Programme laufen unterhalb dieser Linie, 31-Bit Programme unterhalb und oberhalb dieser Linie. Da unter MVS/XA auch die Abwicklung von I/Os neu gestaltet wurde, brachte dieses System erhebliche Vorteile gegenüber MVS/370. Der Bedarf an virtuellem Speicher wuchs und wächst unaufhaltsam weiter. Moderne OnLine-Systeme wie DB2 oder CICS brauchen immer mehr Platz. Die zu verwaltenden Objekte nehmen an Größe zu. Das neueste Betriebssystem MVS/ESA (Enterprise System Architecture) bietet einen maximalen adressierbaren Bereich von fast unvorstellbaren 16 TB (Terabyte). Während beim Wechsel von MVS/370 auf MVS/XA die Adressierung von 24 Bit auf 31 Bit wuchs, ist bei MVS/ESA der adressierbare Bereich in die Breite gewachsen. Auch bei MVS/ESA wird mit 31 Bit adressiert. Zusätzlich zum normalen Adreßraum mit 2 GB, der schon unter XA verfügbar war, gibt es unter ESA NurDatenräume mit der Bezeichnung Data Space und HiPer Space, die ebenfalls 2 GB groß sind. Data Spaces sind byteadressierbar, in HiPer Spaces wird blockweise (4.096 Byte) adressiert. HiPer steht übrigens für High Performance.

Multiple Virtual Storage,

-

-

4

MVS/ESA JCL

Emführung von Nur-Datenräumen wird die Möglichkeit gegeben, die Daten adreßmäßig vom normalen Adreßraum zu trennen. Derzeit lassen sich die Data bzw. HiPer Spaces von höheren Programmiersprachen nur über die Data Windowing Services ansprechen, deren Benutzung derzeit noch etwas umständlich ist. Mit Assembler lassen sich beide Datenräume nutzen. Softwareprodukte wie DB 2 oder SYNCSORT nutzen diese Datenräume bereits. Dadurch ist es möglich, physische I/Os zu reduzieren. Durch die

Speichermedien Speicherung von Daten stehen Ihnen zwei verschiedene Möglichkeiten zu Verfügung: 1. Plattenspeicher mit der Möglichkeit des Direktzugriffs. 2. Kassetten und Bänder für die Speicherung von Massendaten und die Datensicherung mit der Möglichkeit des rein sequentiellen Zugriffs. Der einzelne Datenträger, egal ob Platte oder Band/Kassette, wird als Volume bezeichnet. Jedes Volume hat eine eindeutige Bezeichnung, von der häufig auch als vol-ser-no die Rede ist. Diese Volume-serial-number dient der exakten Bezeichnung. Bei Platten enthält die vol-ser-no Buchstaben, die Angaben für Bänder/Kassetten sind rein numerisch. Die Unit bezeichnet eine Gruppe gleichartiger Datenträger. Diese Bezeichnung wird Ihnen häufiger als die vol-ser-no begegnen, denn oft ist es praktischer, sich nur für einen Für die

Datenträgertyp

zu

entscheiden, als für eine ganz bestimmte Platte oder ein bestimmtes

Band.

Plattenspeicher Die am häufigsten genutzten Plattenspeicher sind die IBM Modelle 3380 und 3390. Die älteren Typen der Baureihe 3350 und 3330 sind heutzutage nur noch vereinzelt im Einsatz. Die einzelnen Baureihen unterscheiden sich hinsichtlich ihrer physischen Konfiguration. Innerhalb einer Modellreihe gibt es nur Unterschiede hinsichtlich der

Gesamtspeicherkapazität. Jeder Plattenspeicher hat

Summe der übereinander rotieren.

eine

Volume-Bezeichnung. Ein Platten-Volume besteht aus der angebrachten physischen Platten, die um eine gemeinsame Achse

Zusammenhang mit der Speicherung von Daten auf Platte gibt es zwei wichtige Begriffe: 1. Spur (Track) und 2. Cylinder Jede Platte besteht aus Magnetspuren, die in der Form von konzentrischen Kreisen auf der Plattenoberfläche abgelegt sind. Obwohl alle Spuren einen unterschiedlichen Radius besitzen, ist ihre Speicherkapazität gleich. Die Speicherdichte der einzelnen Spuren ist unterschiedlich und nimmt nach innen hin zu. Dies hat aber heute keinerlei praktische Bedeutung mehr. Im

5

Einleitung

jede Plattenoberfläche gibt es einen Lese-Schreibkopf. 15 Lese-Schreibköpfe sind an Zugriffsarm gekoppelt und werden immer gemeinsam über die Plattenoberflächen geführt. Die Summe der übereinander auf den verschiedenen Platten liegenden Spuren wird als Cylinder bezeichnet. Kontrolliert werden die Plattenspeicher von den Storage Control Units (SCU). Verbreitet sind heutzutage die Baureihen 3880 und 3990. Die SCU der Baureihe 3990 hat die Besonderheit, daß sie Platten des Typs 3380 und 3390 gemeinsam kontrollieren kann. Die Tatsache, daß diese Plattentypen hinsichtlich der Spurkapazität unterschiedlich konfiguriert sind, macht der SCU nichts aus. Allerdings kann es Ihnen Probleme bereiten, in dieser Konfiguration eine optimale physische Recordgröße zu errechnen. Die einzelnen Plattenbaureihen unterscheiden sich hinsichtlich der Spurkapazität. Diese Unterschiede sind für den Programmierer von großer Bedeutung. Ziel sollte es immer sein, den Platz auf der Platte optimal zu nutzen. Dies kann man dadurch erreichen, daß man es MVS ermöglicht, eine optimale physische Recordgröße zu errechnen. Man kann auch selber eine entsprechende Angabe mit dem BLKSIZE-Parameter machen, dann ist man aber auch selber für die Optimierung zuständig. Dies läßt sich durch Benutzung von JCL erreichen. Wer JCL falsch einsetzt, kann in diesem Punkt jedoch böse Überraschungen erleben. Im schlimmsten Fall kommt man auf Nutzungsgrade, die unter 10% des verfügbaren Platzes liegen. Die folgende Übersicht zeigt die wesentlichen physischen Merkmale verschiedener Plattenspeicher:

Für

einen

t

Baureihe

Bytes/Spur

Spur/Cyl

Kap/Vol (MB)

3380 A/B/D

47.476

15

630

2,52

3380 E/J

47.476

15

1.260

5,04

3380 K

47.476

15

1.890

7,56

3390-1

56.664

15

946

11,35

56.664

15

1.892

3390-2

Da mehrere

physische

Volumes

zu

einem

logischen

Volume

Kap/Laufwerk (GB)

22,7

zusammengefaßt

werden

können, ergeben sich maximale Speicherkapazitäten von bis zu 22,7 GB auf einer 3390-2.

Magnetbänder und Kassetten zum Zwecke der Datensicherung werden heutzutage Magnetkassetten und Magnetbänder verwendet, wobei die Magnetkassetten wegen ihrer leichteren Bedienung die

Vornehmlich

MVS/ESA JCL

6

Magnetbänder weitgehend verdrängt haben. Daten auf Band oder Kassette können nur sequentiell verarbeitet werden. Die Speicherkapazität einer Kassette vom Typ 3480 liegt bei 250 MB. Was die JCL betrifft, so macht es keinen Unterschied, ob Sie auf eine Kassette oder ein Band zugreifen. Aus diesem Grund werden in diesem Buch die Begriffe Band und Kassette synonym benutzt.

Logische versus physische Records In Ihren Anwendungsprogrammen werden immer logische Records verarbeitet. Auf den Datenträgern werden aber die logischen Records nicht einzeln abgespeichert; sie werden zu physischen Records, die aus mehrerem logischen Records bestehen, zusammengefaßt. Diese physischen Records heißen Blöcke. Ihre Größe kann mit einem bestimmtem JCLParameter beeinflußt werden.

Zwischen den Blöcken müssen Lücken, sogenannte Gaps, frei bleiben. Dies ist notwendig, um dem Lese-Schreibkopf das Aufsetzen am Beginn eines Blocks zu ermöglichen. Die Größe der Lücke ist erheblich. Sie beträgt 492 Byte bei einer 3380 und 666 Byte bei einer 3390. Auch zwischen den Blöcken von Daten, die auf Band oder Kassette gespeichert werden, müssen Lücken frei bleiben. Diese Gaps sind es, die das Abspeichern in Blöcken erforderlich machen. Würde man z.B. einen logischen Record von 80 Byte Länge in der physisch gleichen Länge abspeichern, so würde auf einen physischen Record von 80 Byte Länge eine Lücke von 492 Byte folgen. Der Effekt wäre eine miserable Platzausnutzung. Nur 1/6 der Spur wäre mit Daten belegt. Bei Bändern/Kassetten sieht diese Rechnung ähnlich aus. Während Sie früher gezwungen waren, sich eine optimale Blockgröße selbst zu errechnen, wird diese Funktion heute vom Betriebssystem übernommen. Dies bedeutet für Sie eine wesentliche Erleichterung und garantiert sowohl eine optimale Speicherplatznutzung als auch eine gute I/O-Performance.

Datenverwaltung VTOC, VVDS und Katalog -

Ebenso wie die Betriebssysteme, so ist auch die Art und Weise, wie Datenbestände verwaltet werden, evolutionär gewachsen. Dies erklärt die duale Struktur der Datasetverwaltung. Die untere Ebene ist die des Plattenverzeichnisses (VTOC) und der Bandverzeichnisse (Label), die obere Ebene ist die des Kataloges. Das Plattenverzeichnis wird als VTOC bezeichnet. Die Abkürzung bedeutet Volume Table of Content. Der VTOC enthält die Namen der auf der Platte befindlichen Datasets und gibt die Position auf der Platte an. Außerdem wird im VTOC Information über Umfang und Position von freiem Platz auf der Platte verwaltet. Als Rechenzentren nur wenige Platten zu verwalten hatten, genügte es, sich die Platte zu merken, auf der ein Dataset angelegt wurde oder aber alle Platten durchsuchen zu lassen, wenn von einem Dataset gelesen werden sollte. Mit der Zunahme der Platten wurde diese

Einleitung Form der Verwaltung immer ineffizienter. Hinzu eine sehr I/O-intensive Angelegenheit ist.

1

kommt, daß das Durchsuchen des VTOCs

Um das Auffinden von Datasets zu vereinfachen, wurde eine Katalogstruktur entwickelt. In seiner ursprünglichen Form war der Katalog ein Dataset, in dem die DSNs aller anderen Datasets und der Name der Platte verzeichnet war, auf dem die Datasets tatsächlich standen. Um ein Arbeiten mit dieser Katalogstruktur zu ermöglichen, war es jetzt notwendig geworden, beim Anlegen eines Datasets darauf zu achten, daß ein Eintrag sowohl im VTOC der Platte als auch im Katalog erfolgte. Die Einträge müssen synchron gehalten werden. In Nicht-SMS-Umgebungen gibt es immer noch die Möglichkeit, sogenannte nicht katalogisierte Datasets anzulegen. Für diese Datasets existiert zwar ein Eintrag im VTOC, aber kein Eintrag im Katalog. Ein weiteres Problem kann auftreten, wenn ein Dataset angelegt wird, dessen Namen im Katalog schon existiert. Wird der Katalogeintrag vor dem Anlegen nicht entfernt, so wird das Dataset zwar im VTOC einer Platte eingetragen, nicht aber im Katalog. Auch hier ist das Ergebnis ein nicht-katalogisiertes Dataset. Auch dieses Problem kann nur in Umgebungen auftreten, in denen SMS nicht aktiv ist. Eine Zeit lang existierten in MVS-Umgebungen verschiedene Katalogsysteme nebeneinander. Diesem Durcheinander wurde durch die Einführung der Integrated Catalog Facility (ICF) ein Ende gemacht. Mit ICF können sowohl normale (sequentielle) als auch

VSAM-Datasets verwaltet werden. Der ICF-Katalog besteht aus einem Master- und mehreren Userkatalogen. Der MasterKatalog enthält als Eintrag den ersten Teil des Datasetnamens (DSN) und den Verweis auf den Userkatalog. Im Userkatalog ist der eigentliche Datasetname (DSN), der Datenträger (UNIT) und die Plattennummer der Platte (VOLUME) verzeichnet, auf dem das gesuchte Dataset steht. Warum nun diese scheinbar komplizierte Struktur? Ein Grund ist die Datensicherheit. Wie der Name schon vermuten läßt, ist der Master-Katalog ein zentraler Teil der Datasetverwaltung. Um ihn zu schützen, haben die normalen User auf diesem Katalog nur eine Leseberechtigung. Einträge dürfen nur von der Systemprogrammierung gemacht werden. Bevor ein neuer User sich zum ersten Mal zum ISPF anmelden kann, muß seine USERID im Master-Katalog eingetragen sein, ansonsten kann das ISPF Profildataset nicht angelegt werden, wodurch das Anmelden zum ISPF mißlingt.

Im ihm zugeordneten Userkatalog hat der User Updateberechtigung. Sie ist notwendig, um z.B. ein Dataset neu eintragen zu können. Die Tatsache, daß mehrere Userkataloge eingesetzt werden können, bietet den Vorteil, daß der einzelne Userkatalog nicht zu groß wird, was wiederum für einen schnellen Zugriff sehr wichtig ist.

MVS/ESA JCL

8

Die

folgende Abbildung zeigt den grundsätzlichen Aufbau von Master- und Userkatalog:

MVS ICF

TD2104

=

Katalogstruktur Integrated Catalog Facility

TD2105

TD2106

9

Einleitung Am folgenden Beispiel soll erläutert UWIN.CLIST lokalisiert wird.

DSN

=

/

werden, wie mit Hilfe des Katalogs das Dataset

T842.CLIST —

Master Katalog

DATA SET NOT CATALOGED

Verarbeitung

DATA SET NOT FOUND

MVS/ESA JCL

10

In der JCL wird

nur

der Datasetname UWIN.CLIST mit Hilfe des DSN-Parameters UWIN auf dem Master-

angegeben. Zunächst wird mit Hilfe des ersten Teil des DSN Katalog gelesen. Eintrag im Master-Katalog für User UWIN und für HLQ T999: HLQ

UCAT

T999

UCAT.T800

UWIN

UCAT.T800

Der Master-Katalog enthält als Einträge nicht nur USERIDS sondern auch andere High Level Qualifier. High Level Qualifier sind zulässige erste Teile des DSN. Ob Sie diese HLQ benutzen dürfen, hängt von Ihrer RACF-Berechtigung ab.

Eintrag im verzeichnet ist: Der

Master-Katalog verweist auf den Userkatalog,

in dem der

komplette

DSN

Eintrag im Userkatalog für das Dataset UWIN.CLIST: DSN

UNIT

VOLUME

UWIN.CLIST

3390

DSK013

Der Eintrag besagt, daß das Dataset UWIN.CLIST auf einer Platte des die Bezeichnung DSK013 trägt.

Typs 3380 steht, die

Im VTOC der Platte DSK013 ist der DSN UWIN.CLIST und die Position dieses Datasets auf der Platte verzeichnet. Was wäre passiert, wenn ein nicht existierendes Dataset gesucht worden wäre? Nehmen wir an, Sie hätten sich verschrieben und nach dem Dataset UWfNN.CLIST gesucht. Da für UWINN kein Eintrag im

Master-Katalog existiert, käme es zu einem

DATASET NOT CATALOGED Fehler. Hätten Sie nach UWIN.CLST gesucht, und es wäre zum gleichen Fehler gekommen.

so

hätte der

Eintrag

im

Userkatalog gefehlt

Neben den Komponenten Master-Katalog, Userkatalog und VTOC gibt es noch ein weiteres wichtiges Systemdataset: das VVDS (VSAM Volume Data Set). Auf jeder Platte, auf der VSAM-Datasets stehen, gibt es ein VVDS. Mit dem VVDS wird die große Zahl von Statistikeinträgen gehandhabt, die VSAM-Datasets mit sich herumschleppen müssen. Das VVDS enthält alle Statistikeinträge für die auf der gleichen Platte stehenden VSAMDatasets. Diese Statistiken sind ein wichtiger Indikator für das Performanceverhalten von VSAM-Datasets. Vor der Einrichtung des VVDS wurden all diese Statistikeinträge im Userkatalog verwaltet. Dies führte zu einer hohen Zahl von Zugriffen auf den Userkatalog und beeinträchtigte sowohl die Performance des Katalogs, der seinerseits die Struktur eines

11

Einleitung

VSAM-Dataset hat, wie auch die der VSAM-Datasets allgemein. Durch die Einrichtung des VVDS wird die Zahl der Zugriffe auf den Katalog vermindert und das Synchronitätsverhalten verbessert, denn das VSAM-Dataset und das zugehörige VVDS liegen ja immer auf demselben Volume. Da der Master- und Userkatalog ebenfalls als VSAM-Datasets organisiert sind, gibt es auf den Platten, auf denen Master- und Userkataloge angesiedelt sind, jeweils ein VVDS.

Datenverwaltung und -Sicherung: DFHSM und RACF große Zahl der Datasets, die von einem Großsystem zu verwalten sind, zwingt zu einer optimalen Datenorganisation. So stehen auf den meisten MVS-Installationen zwei große Systemsoftwarepakete zur Verfügung, die dem Datenmanagement und dem Datenschutz (Zugriffsschutz) dienen. DFHSM (Data Facility/Hierarchical Storage Manager) ist ein System, daß die Datenverwaltung auf dem Großsystem optimieren hilft. Es besteht aus einer Migrationsund einer Backupkomponente. Die Migrationskomponente sorgt dafür, daß nicht oder selten benötigte Datasets entweder komprimiert oder auf Band/Kassette ausgelagert und erst bei Bedarf wieder geladen werden. Fragmentierte Datasets werden automatisch wieder zusammengefügt. Die Backupkomponente zieht von allen Daten in regelmäßigen Abständen Kopien (Backups). Im Falle eines Datenverlusts können diese Backups zum Recovern von Datasets Die

verwendet werden.

Access Control Facility) regelt den Zugang zum System und den Zugriff auf Daten (Lese- und Schreibvorgänge). Es stellt sicher, (Anmeldevorgang) daß nur autorisierte User Zugang zu den für sie bestimmten Datenbeständen haben. Zudem überwacht RACF die Art des Zugriffs. RACF

(Ressource

Mehr über den DFHSM und RACF erfahren Sie in dem Band: TSO Teuffei (siehe Literaturverzeichnis im Anhang).

Datenmanagement

-

von

Dr. Michael

SMS

SMS System Managed Storage oder Storage Management Subsystem ist ein Produkt, daß die Verwaltung von Datasets auf Plattenspeicher vereinfachen soll. Es kann unter MVS/ESA eingesetzt werden. Die meisten MVS-Installationen setzen SMS als selbstverständliche Ergänzung ein. -

-

Die wichtigste Neuerung unter SMS ist die Tatsache, daß es in einem von SMS kontrollierten Umfeld keine nicht-katalogisierten Datasets mehr geben kann. Außerdem lassen sich mit SMS VSAM-Datasets ohne die Benutzung der Utility IDCAMS definieren (und auch löschen!). Bei SMS unterscheidet man die Zustände installiert und aktiviert. Bereits im nicht aktivierten Zustand bringt SMS einige erhebliche Vorteile. Wegen seiner großen Bedeutung wurde SMS das gesamte Kapitel 6 in diesem Buch gewidmet.

MVS/ESA JCL

12

Zugriffsmethoden Die Zugriffsmethoden erlauben es, in Ihrem Anwendungsprogramm logische Records verarbeiten zu können, ohne sich um deren physische Struktur kümmern zu müssen. Wir werden uns mit den zwei wichtigsten Zugriffsmethoden auseinandersetzen: VSAM und

QSAM.

Die Zugriffsmethode ISAM (Indexed Sequential Access Method) ist veraltet und wurde durch VSAM abgelöst. Sie wird deshalb in diesem Buch nicht besprochen. VSAM VSAM ist die Abkürzung für Virtual Storage Access Method. Es ist eine Zugriffsmethode, die vier Datasetarten unterstützt, eine davon mit der Möglichkeit des Direktzugriffs. Das Thema VSAM ist so umfangreich, daß ihm das komplette Kapitel 5 gewidmet wurde.

VSAM-Datasets können nur auf Plattenspeichern

angelegt werden.

QSAM

QSAM steht für Queued Storage Access Method. Zugriff auf sequentielle Datasets erlaubt. Die

Es ist eine Zugriffsmethode, die den Datasets können auf Platte oder

Band/Kassette residieren.

im Hauptspeicher Platz für fünf Blöcke in einem Verfügung gestellt. Die Größe dieser Puffer entspricht der Blocksize. Setzt Ihr Programm den OPEN-Befehl für ein sequentielles Dataset ab, so werden die fünf Puffer gefüllt. Ihr Programm arbeitet dann die Records sequentiell mit READ-Anweisungen ab. Während Ihr Programm die Daten aus den Puffern verarbeitet, werden die bereits gelesenen Puffer asynchron wieder aufgefüllt. Sind die Daten aus dem fünften Puffer abgearbeitet worden, so kann unmittelbar im ersten Puffer weitergelesen werden, da QSAM die Daten schon zur Verfügung gestellt hat. Um die Tatsache, daß irgendwelche Puffer im Spiel sind, brauchen Sie sich in Ihrem Anwendungsprogramm nicht zu kümmern. Dies alles übernimmt die Zugriffsmethode QSAM. Beim Schreiben wird mit QSAM zunächst in die Puffer geschrieben und dann asynchron auf den gewünschten Datenträger übertragen. Dem

Anwendungsprogramm wird

sogenannten Puffer

zur

Record-Formate Bei

sequentiellen oder PO-Datasets werden folgende Record-Formate unterschieden: logische Recordlänge (F)

1. Fixe

2. Variable

logische Recordlänge (V) logische Recordlänge (U) Mehrere logische Records sind zu einem physischen wird durch ein auf F oder V folgendes B dargestellt.

3. Undefinierte

4.

Record

zusammengefaßt.

Dies

13

Einleitung

Das am häufigsten verwendete Format ist FB, wobei B für blocked steht. Die logischen Records werden zu einem physischen Block zusammengefaßt. Die Länge des physischen Blocks ist ein Mehrfaches der logischen Recordlänge. Die maximal zulässige Blockgröße ist 32760. Sollen variabel lange logische Records zu einem Block zusammengefaßt werden, so ist als Format VB anzugeben. Am Anfang eines jeden Blocks befindet sich ein 4 Byte langes Feld, das die tatsächliche Länge des Blocks beschreibt. Dies hat Auswirkungen auf Ihr Anwendungsprogramm. So stehen Ihnen bei einer maximalen Blockgröße von 32760 Byte nur 32756 zur Verfügung.

Beim Undefinierten Record-Format gibt es keine logischen Records. Dieses Format wird für Bibliotheken benötigt, in deren Member sich ausführbare Programme Load Modules befinden.

nur

-

-

Datenorganisation

-

PS oder PO

Wenn Sie

Batch-Verarbeitung betreiben, so haben Sie es am häufigsten mit Physisch Sequentiellen Datasets PS-Datasets zu tun. Bei dieser Datasetform werden die Records einer nach dem anderen weg geschrieben. In Jobs werden sehr häufig PS-Datasets als Ausgabedatasets erzeugt. Daneben gibt es noch eine weitere Organisationsform, die Bibliothek oder PO-Dataset. PO kommt aus dem Englischen und heißt Partitioned Organized, meint also eine Datasetform, die in sich noch einmal untergliedert ist. Der Vergleich mit der Bibliothek ist recht passend, denn wie eine Bibliothek besteht ein PO-Dataset aus einem Verzeichnis (Directory) und vielen Büchern (Member). Editiert -

-

werden die Member und nicht das gesamte Dataset. Bibliotheken werden u.a. zum Entwickeln von Programmen eingesetzt, aber auch die JCL, die einen Job steuert, wird als Member einer Bibliothek abgelegt. Das Haupteinsatzgebiet von Bibliotheken ist ISPF. In Jobs werden nur sehr selten Bibliotheken erzeugt.

1.2

Der Ablauf des Jobs

Ein Job ist eine Folge von JCL-Anweisungen. Jeder Job muß mit der JOB-Anweisung beginnen. Ein Job kann ein oder mehrere Programme ausführen. Für jedes Programm wird eine EXEC-Anweisung benötigt. Die Beziehung zu den physischen Daten wird über DDAnweisungen hergestellt. DD steht für Data Definition. Damit haben wir die drei wichtigsten Arten von JCL-Anweisungen kennengelernt. Wie sie syntaktisch aussehen, wird später erläutert. Ein Job wird als Member eines PO-Dataset abgelegt. Es ist möglich, mehrere Jobs in ein Member zu stellen. Diese Vorgehensweise ist jedoch unüblich. Ein kompletter Job kann folgendermaßen aussehen:

MVS/ESA JCL

14

edit-uwin.schulung idcams(br1401) 01.05 scroll ===> page command ===> ****** **************************** top of data ****************************** 000001 //uwin217c job (uwin,abtdg02),'m.winter1,class=x,msgclass=h 000002 //br14 exec pgm=iefbr14 000003 //delds dd dsn=uwin.test.outfile, 000004 // disp=(old,delete) .

-

******

***************************

.

bottom of data

****************************

jetzt noch nicht alles verstehen, ist das nicht schlimm. Alles wird noch ausführlich erläutert. Die grundsätzliche Folge der verschiedenen Anweisungen ist jedoch gut zu erkennen. Alles, was vom Beginn einer EXEC-Anweisung bis zum Beginn der nächsten EXECAnweisung steht, wird als Step oder Job Step bezeichnet. Ein Job muß zumindest einen Step besitzen. Er kann aus bis zu 255 Steps bestehen. Die DD-Anweisungen gehören immer zum Step. Ihre Zahl ist auf 3273 pro Step limitiert. Mit Hilfe einer DD-Anweisung wird entweder ein Dataset erzeugt oder ein existierendes Wenn Sie

Dataset angesprochen.

Um den Job zu aktivieren, geben Sie in der Kommandozeile des ISPF-Bildschirms den Befehl: SUBMIT ein. Ihr Job durchläuft dann 5 Phasen, die jetzt im einzelnen besprochen werden.

Die 5

Jobphasen

Die Abbildung auf der folgenden Seite

zeigt den Ablauf des Jobs:

SUBMIT

Ihren Job erstellen Sie in der Regel unter ISPF als Member eines PO-Dataset. Wollen Sie den Job ausführen lassen, so setzen Sie den ISPF-Befehl: SUBMIT ab. Durch den SUBMIT-Befehl übergeben Sie Ihren Job der Kontrolle des Job Entry Subsystems (JES). Von JES gibt es zwei Varianten: JES2 und JES3. Beide unterscheiden sich etwas in der Art, wie Sie Jobs abhandeln. JES2 ging aus einem Vorgängerprodukt namens HASP hervor. Dieses Houston Automatic Spooling Program wurde in den 60er Jahren für Einprozessorbetriebssysteme entwickelt. Die meisten MVS-Installationen nutzen heute JES2. JES3 wurde aus dem Vorgängerprodukt ASP (Asynchronous Multiprocessing System) entwickelt und war von Anfang an für Mehrprozessorumgebungen ausgelegt. Obwohl heute fast alle Mainframes mehrere Prozessoren haben, ist JES2 zu über 90% im Einsatz. Die Operator-Meldungen, die Sie zurückbekommen, beginnen mit $HASP. Sie stammen also noch aus der Zeit, als dieses Job Management System entwickelt wurde.

15

Einleitung

Die fünf JOB-Phasen::

SUBMIT

KONVERTIERUNG

JCL ERROR

JOB EXECUTION

OUTPUT PROCESSING JOB PURGING

Konvertierung und Syntaxprüfung Da JCL Variable enthalten kann (siehe dazu das Kapitel JCL-Prozeduren), müssen diese Variablen aufgelöst werden, bevor eine syntaktische Prüfung erfolgen kann. Zusammen mit den JCL-Anweisungen können auch Daten übergeben werden. Diese sogenannten SYSIN-Daten nehmen am Konvertierungsprozeß nicht teil. Daher ist es Unsinn, dort Variable anzugeben, auch wenn dies wünschenswert wäre. Da SYSIN-Daten nicht auf Syntax geprüft werden, können sie auch keinen JCL Syntaxfehler auslösen. Der Konvertierung folgt die Syntaxprüfung. Dort werden die JCL-Anweisungen auf formale Richtigkeit geprüft. Grob gesagt werden Fehler links vom Gleichheitszeichen fast immer erkannt. Fehler auf der rechten Seite des Gleichheitszeichens werden nur dann erkannt, wenn sogenannte Schlüsselwörter falsch angegeben wurden oder positionelle Parameter an der falschen Stelle stehen. Wenn Sie syntaktische Fehler begangenen haben, bekommen Sie eine:

MVS/ESA JCL

16

JCL ERROR-

Meldung. Ihr Job kommt dann erst gar nicht auf die Warteschlange. Noch unter HASP war dies anders. Da konnte es passieren, daß man nach dem SUBMIT 30 Minuten warten mußte, bis der Job anlief und dann wegen eines trivialen Fehlers abbrach. Das kann heute nicht mehr passieren. Fehler werden beim Syntax Check nicht erkannt. So können Sie ein Programm gar nicht existiert. Solange der Programmname syntaktisch korrekt eingegeben ist (max. 8 Zeichen, darf nicht mit einer Zahl beginnen), wird es nicht zu einem JCL-Fehler kommen. Wohl aber kommt es zu einem ABEND zur Laufzeit. Es kann aber während der Laufzeit des Programms zu einem Allokationsfehler kommen, der ebenfalls als JCL ERROR gemeldet wird. Syntaktische und Allokationsfehler sollten nicht miteinander verwechselt werden.

Logische

aufrufen, das

(Job Execution) Wenn Ihr Job syntaktisch einwandfrei ist, dann wird er auf einer Warteschlange plaziert und steht zur Ausführung an. Die Frage, wann Ihr Job ausgeführt wird, hängt zuallererst von der Job-Klasse und deren Priorität ab. Die Frage des Zeitpunkts des SUBMITs ist nur dann interessant, wenn Jobs in der gleichen Klasse laufen. Job-Klassen sind ein Instrument, um den Ablauf der Jobs zu steuern. Eine Job-Klasse kann Die Ausführung des Jobs

einen oder mehrere Initiator besitzen. Der Initiator ist ein Systemprogramm, daß einen Job ausführt. Wie dies im einzelnen geschieht, wird noch erläutert. Job-Klassen werden eingerichtet, um unterschiedlichen Bedürfnissen Rechnung zu tragen. So gibt es Job-Klassen mit einem hohen Anteil an CPU-Zeit, Job-Klassen, in denen Band/Kassettenverarbeitung zugelassen ist oder nicht oder Job-Klassen, die Jobs nur zu bestimmten Zeiten, z.B. nachts laufen lassen. Wichtig zu wissen ist, daß mit den JobKlassen auch Limitierungen einhergehen. So gibt es in den meisten MVS-Installationen nur wenige Job-Klassen mit unlimitierter CPU-Zeit. Wenn aber die Job-Klasse ein CPUZeitlimit vorgibt, so können Sie es auch durch die Angabe entsprechender JCL-Parameter nicht erhöhen. Die Ausgabeverarbeitung (Output Processing) Wenn Ihr Job Output, z.B. Druckoutput erzeugt, so wird dieser nicht unmittelbar auf den Drucker gelegt, sondern wird in einem Zwischendataset gespeichert. Diese Vorgehensweise ist notwendig, da Sie in einer Multiprogramming Umgebung arbeiten. Dieses Zwischendataset wird auf dem sogenannten Spool Volume angelegt. Dies geschieht automatisch. Diese Form des Outputs wird als SYSOUT (SYStem OUTput) bezeichnet. Erst wenn der Step beendet ist, wird mit dem Drucken begonnen. Job entfernen

(Purge Processing)

Ist der letzte Output, den der Job erzeugt hat, abgearbeitet (z.B. gedruckt), so wird der Job aus dem System entfernt. In den meisten MVS-Installationen wird der Job von einem

Einleitung

17

Output Management System übernommen. Typische Beispiele sind das BETA92 oder IOF (Input-Output Facility). Dort können Sie dann die Ergebnisse Ihres Jobs anschauen. Der Initiator

Job-Ausführung wollen wir uns noch einmal genauer ansehen. Er ist der für uns entscheidende. Der Job wird wie bereits gesagt von einem Systemprogramm mit dem Namen Initiator zur Ausführung gebracht. Einzige Aufgabe des Inititiators ist es, nach Jobs Ausschau zu halten, die ausgeführt werden können. Der Initiator ist einer oder mehreren Job-Klassen zugeordnet. Ein Job kann von einem Initiator nur dann ausgeführt werden, wenn die im Job angegebene Job-Klasse mit der übereinstimmt, für die der Initiator zuständig ist. Gibt es für eine bestimmte Job-Klasse nur einen Initiator, so kann das eine erhebliche Wartezeit bedeuten. Job-Klassen für Band- bzw. Kassettenverarbeitung besitzen meist nur einen oder wenige Initiator. Sehr aktiven JobKlassen sind viele Initiator zugeordnet. Die Wartezeiten in diesen Klassen sind daher meist Den Schritt

gering.

Job Initiation Die

wichtigste Aufgabe der Job Initiation ist sicherzustellen, daß im Job keine Datasets angefordert werden, die von anderen Jobs reserviert wurden. Sollte dies der Fall sein, so geht der Initiator in einen sogenannten 'wait state' und der Operator wird informiert. Ansonsten wird der nächste Schritt: Step Initiation ausgeführt. Step Initiation Wichtigste Aufgabe dieses Schrittes ist festzustellen, ob der Step wegen einer besonderen Bedingung unter Umständen nicht ausgeführt werden soll. Dazu wird, falls angegeben, der COND-Parameter überprüft bzw. Bedingungen geprüft, die mit IF/ELSE/ENDIF gesetzt wurden.

MVS/ESA JCL

18 Der schematische Ablauf der Jobphase

JOB-AUSFÜHRUNG sieht folgendermaßen aus:

JOB EXECUTION:

JOB INITIATION

STEP INITIATION

ALLOKATION PGM EXECUTION

DEALLOKATION

Step Allokation Durch die Allokation werden dem Step die benötigten Ressourcen zur Verfügung gestellt. Können die Ressourcen nicht zur Verfügung gestellt werden, so kommt es zum Abbruch des Steps (und damit des Jobs). Dies ist z.B. dann der Fall, wenn Sie für ein neues Dataset mehr Platz anfordern als zur Verfügung steht. In diesem Fall erhalten Sie einen JCLAllokationsfehler. Es gibt auch Fälle, in denen der Step nicht anlaufen kann. Dieser Fall ist gegeben, wenn Sie mehr Lese-Schreibstationen anfordern als zur Verfügung stehen. Die Art und Weise, wie die Allokation ausgeführt wird, unterscheidet sich je nachdem, ob bei Ihnen SMS aktiv ist oder nicht. Beim Aufsuchen vorhandener Datasets gibt es keinen Unterschied, wohl aber beim Anlegen neuer Datasets. Außerdem macht es bei der

19

Einleitung

Allokation einen Unterschied, wenn Sie Datasets auf Plattenspeicher oder Datasets auf Band/Kassette ansprechen. Werden vorhandene Datasets, die auf Plattenspeicher residieren, angesprochen, so wird der Katalog abgesucht. Wird im Userkatalog der Eintrag für den DSN gefunden, so wird sichergestellt, daß die Platte, auf der sich das Dataset befindet, für den Step verfügbar ist. Zu diesem Zeitpunkt wird aber noch nicht in den VTOC der Platte geschaut. Dies geschieht erst, wenn das Programm einen OPEN absetzt. Beim

Anlegen

von

Nicht-SMS-Datasets wird eine Platte

zugewiesen.

Danach wird das

Dataset angelegt, vorausgesetzt, der angeforderte Platz ist verfügbar. Das Dataset erhält dann einen Eintrag im VTOC. Beachten Sie, daß das Dataset zu diesem Zeitpunkt nicht katalogisiert ist. Reicht der Platz nicht, kommt es zu einem JCL-Fehler.

Werden SMS-Datasets angelegt, so wird zunächst überprüft, ob bereits ein Eintrag im Katalog für den zu vergebenden Datasetnamen existiert. Ist dies der Fall, so kommt es zu einem JCL-Fehler. Der Step bricht ab. Auf diese Weise wird verhindert, daß ein nichtkatalogisiertes Dataset angelegt wird. Sofern der Datasetname vergeben werden darf, wird eine Platte, die ebenfalls der Kontrolle von SMS unterliegt, zugewiesen. Das Dataset erhält einen VTOC-Eintrag und wird sofort katalogisiert. Dies ist der entscheidende Unterschied zu Nicht-SMS-Umgebungen. Dort wird das Katalogisieren von den Step-TerminationRoutinen übernommen. Wird anhand des Kataloges festgestellt, daß ein Dataset auf Band oder Kassette residiert oder soll ein neues Dataset auf Band/Kassette geschrieben werden, so erhält der Operator eine Meldung (Mount Message). Er muß dann eine freie oder die betreffende Kassette in eine Lese-Schreibstation einlegen. Die Lese-Schreibstation ist damit für Sie reserviert. Ein wichtiger Unterschied zwischen Plattenspeicher und Band/Kassette ist der, daß Ihnen die Lese-Schreibstation exklusiv zur Verfügung steht während sich viele User den Zugriff auf eine Platte teilen können ('shared access'). Beachten Sie auch, daß für jedes Dataset, das vom Band/von der Kassette gelesen oder geschrieben werden soll, eine Lese-Schreibstation belegt wird. Die

Ausführung des Programms Nach der Allokation folgt die Programmausführung. Dabei können sowohl vom User geschriebene Programme wie auch Utility-Programme ausgeführt werden. Erst wenn jetzt ein OPEN gemacht wird, wird beim Lesen von Plattendatasets der VTOC abgesucht. Sollte wider Erwarten das Dataset dort nicht vorhanden sein, kommt es zu einem DATASET NOT FOUND JCL Error.

Step-Ende (Step Termination) In diesem Schritt werden die bei der

Step-Allokation belegten Ressourcen wieder freigegeben. Außerdem wird versucht, die Datasets in den Zustand zu bringen, den der User mit Hilfe der JCL bestimmt hat. Dieser gewünschte Zustand kann sich unterscheiden, je

MVS/ESA JCL

20

nachdem, ob der Step normal endet (normale Disposition) oder abbricht (abnormale

Disposition). Vor Stepbeginn vorhandene

Datasets läßt man meist in dem Zustand zurück, wie man sie vorfand. Neue Datasets sollte man katalogisieren, wenn der Step normal endet. Bricht er ab, sollte man sie löschen. Wichtig ist, daß bei neuen Datasets, die nicht SMS-kontrolliert sind, erst jetzt mit dem Versuch des Katalogisierens begonnen wird. Sollte der DSN im Userkatalog schon vorhanden sein, kann nicht katalogisiert werden. Der Step endet aber trotzdem normal. Das auf der Platte angelegte Dataset bleibt bestehen. Auf diese Weise ist dann ein sogenanntes nicht-katalogisiertes Dataset entstanden. Sollten Datasets, die während des Programms geöffnet wurden, nicht geschlossen worden sein, so übernehmen die Step-Termination-Routinen diese Aufgabe. Sollte der Job aus mehreren Steps bestehen, so werden jetzt die Schritte ab Step-Initiation erneut durchlaufen. Dies geschieht solange, bis der letzte Step beendet ist. Das Ende des Jobs

(Job Termination)

Normalerweise haben die Job-Termination-Routinen nichts zu tun. Es gibt aber einige Sonderfälle, in denen sie eingreifen müssen, z.B. dann, wenn ein Dataset an Folgestep übergeben wurde, dort aber nicht angenommen wurde. In diesem Fall entscheiden die Job Termination Routinen, was mit dem Dataset geschieht. Unter Umständen können dabei überraschende Resultate produziert werden.

1.3

Fehlermeldungen

Bei der Benutzung von JCL kann es zum Auftreten unterschiedlicher Fehlerbedingungen kommen. Es handelt sich dabei um JCL-Fehler und ABnonnal ENDs (ABEND).

Bei JCL-Fehlem ist zwischen syntaktischen und Allokationsfehlern zu unterscheiden. Die syntaktischen JCL-Fehler lassen sich relativ leicht beheben. Sie werden beim Syntax Check entdeckt und gemeldet. Der Job kommt erst gar nicht zur Ausführung. Allokationsfehler treten erst während des Joblaufs auf. So kann es sein, daß der für ein neu anzulegendes Dataset angeforderte Platz nicht zur Verfügung gestellt werden kann. In diesem Fall kommt es zu einem SPACE REQUESTED NOT AVAILABALE-Fehler. Der Job Step bricht dann ab. Vorangegangene Steps sind aber bereits gelaufen. Der Job muß neu gestartet werden, und dieser Neustart kann wiederum mühsam sein. Allokationsfehler lassen sich nicht immer ausschließen. ABENDs treten auf, wenn Ihr Programm versucht eine Instruktion auszuführen, die es aus welchen Gründen auch immer nicht ausführen darf. Meist ist es nicht einmal Ihr Programm selbst, daß die Kontrolle hat, sondern ein Systemprogramm, daß von Ihrem Programm mit Hilfe eines SVC (Supervisor Call) aufgerufen wurde. MVS beendet dann die Ausführung Ihres Programms und gibt einen sogenannten System Completion Code oder ABEND Code zurück. Der Code besteht aus drei Zeichen und ist mit dem SVC verknüpft. So zeigt ein Code von xl3 ein Problem beim Öffnen eines Dataset an. Um die Ursache des -

-

Einleitung

21

ABEND herauszufinden, müssen Sie das entsprechende IBM Manual: GC28-1815 MVS/ESA Message Library: System Codes konsultieren. Dort werden Sie häufig auf die Manuals: MVS/ESA Message Library: System Messages Vol. I und II verwiesen. Hier finden sich dann genaue Informationen zum ABEND und den zu ergreifenden Maßnahmen. Im Kapitel 8 wird erläutert, wie die verschiedenen Fehlermeldungen zu interpretieren sind.

JCL

2

Bevor auf die einzelnen

JCL-Anweisungen eingegangen wird, syntaktischen Grundzüge erläutert werden.

sollen

an

dieser Stelle die

Aufbau der JCL-Anweisungen Job

Control-Anweisungen

müssen in einem ganz bestimmten Format erstellt werden. Die

Länge eines JCL-Records muß 80 Byte betragen. Diese Länge stammt noch aus der Lochkartenära, doch nur 72 Byte sind tatsächlich verfugbar. Die JCL-Anweisungen werden in der Regel als Member einer Bibliothek gespeichert. Diese Bibliothek sollte den Namen:

userid.*.CNTL tragen, wobei bei * ein beliebiger String bis zu acht Zeichen eingesetzt werden kann. CNTL

steht als Abkürzung für Control. Sie kann unter der ISPF Option 3.2 erstellt werden. Eine JCL-Anweisung kann aus bis zu vier verschiedenen Feldern bestehen. Diese Felder werden im einzelnen beschrieben.

Das Identifikationsfeld Das Identifikationsfeld beginnt auf Position 1 und hat eine Länge von 2 oder 3 Normale JCL-Anweisungen beginnen immer mit der Zeichenfolge '//'.

Byte.

Besondere Bedeutung haben die Zeichenfolgen '/*', die das Ende von Daten oder Kontrollanweisungen kennzeichnet (Standard Delimiter Anweisung), und '//*', die am Beginn einer Kommentarzeile steht. Beispiele:

ID-Feld

Bedeutung

//

Normale

//*

Kommentarzeile

P

Ende

von

JCL-Anweisung Daten

MVS/ESA JCL

24

Das Namefeld Unmittelbar auf das Identifikationsfeld folgt das Namefeld. Der Name darf maximal acht Zeichen lang sein. Er darf aus den Buchstaben A-Z, 0-9 und den Zeichen '#', '@' und '$' bestehen. Nummern an der ersten Stelle des Namens sind nicht erlaubt. Im Namefeld muß eine Angabe stehen, wenn es sich um eine JOB-Anweisung handelt. In einer EXEC-Anweisung sollte eine Angabe erfolgen. Dieser Name wird dann der sogenannte Stepname. Ein Step ist immer mit einer EXEC-Anweisung verbunden.

Bei DD-Anweisungen (Data Definition) wird mit der Angabe im Namefeld die Verbindung zwischen logischen und physischen Datasetnamen hergestellt. Der Name selbst ist weitgehend wahlfrei mit Ausnahme bestimmter Namen, auf die später eingegangen wird. Grundsätzlich sollte man bei DD-Anweisungen keine Feldnamen vergeben, die mit SYS anfangen, denn es gibt eine Reihe reservierter Feldnamen.

Beispiele: ID Namefeld -

//TJWINUEB

//STEP1 //EINGABE1 Das

Operationsfeld

Das Operationsfeld kennzeichnet die Funktion, die die JCL-Anweisung hat. Zwischen dem Namefeld und dem Operationsfeld muß mindestens ein blank stehen. Ausführlich betrachtet werden JOB, EXEC, DD und OUTPUT. IF, ELSE, ENDIF, SET und JCLLIB sind ab der Version 4.2 von MVS/ESA verfügbar. PROC und PEND haben nur für JCL-Prozeduren Bedeutung und werden im Kapitel 3: JCL-Prozeduren ausführlich vorgestellt.

Beispiele: ID Namefeld -

Operation

//UWINUEB

JOB

//STEP1

EXEC

//EINGABE 1

DD

Das Parameterfeld Das Parameterfeld ist das umfangreichste von allen. Zwischen dem Operationsfeld und dem Namefeld muß mindestens ein Leerzeichen stehen. Besteht das Parameterfeld aus mehreren Parametern, so werden diese durch Kommata abgetrennt. Besteht ein Parameter aus

JCL

25

mehreren Subparametern, so müssen diese umklammert und mit Kommata abgetrennt werden, wobei keine Leerzeichen eingefügt werden dürfen (ein Leerzeichen kennzeichnet das Ende einer JCL-Anweisung). Parameter können Schlüsselwort-Parameter oder Positionelle Parameter sein.

Beispiel 1 (ein Parameter im Parameterfeld): ID Namefeld

Op

Parameter

//EINGABE

DD

SYSOUT=*

Beispiel 2 (mehrere Parameter im Parameterfeld): ID-Namefeld Op Parameter

//EINGABE

DD

DSN=TJWIN.

TESTFILE, DISP=SHR

Beispiel 3 (ein Parameter mit mehreren Subparametern): ID-Namefeld Op Parameter

//EINGABE

DD

DCB=(RECFM=FB,LRECL=287)

Das Koninicntai leid Eine Kommentarzeile muß mit //* beginnen. Daran anschließend kann eine beliebige werden. Die Benutzung von Kommentaren ist sehr nützlich für Dokumentationszwecke. Nicht kommentierte JCL ist genauso fürchterlich wie unkommentierte Programme. Nutzen Sie deshalb die Kommentarmöglichkeit. Kommentare können auch rechts angehängt werden. Sie müssen von den Anweisungen durch mindestens ein Leerzeichen getrennt werden.

Zeichenfolge eingegeben

Fortsetzungsregeln Ein Komma muß am Ende der ersten Zeile stehen, in jeder Folgezeile muß nach dem '//' ein Leerzeichen stehen. Neue Anweisungen müssen zwischen Spalte 4 und Spalte 16 beginnen. Wird auf Spalte 17 oder später begonnen, betrachtet MVS dies als Kommentar.

Hier ein Beispiel für Fortsetzungsregeln und Kommentare. Die JCL-Anweisung auf Zeile 300 wird fortgesetzt. Auf den Zeilen 300 und 400 stehen Kommentare. Auf Zeile 600 folgt den JCL-Anweisungen ein Kommentar:

MVS/ESA JCL

26 EDIT-UWIN.SCHULUNG.CNTL(UEBUNGI)

01.00

.

-

COMMAND

===>

COLUMNS 001 072 SCROLL ===> PAGE

//UWINUEB1 JOB (998,ABTDG02),1M.WINTER1,CLASS=X,MSGCLASS=H //STEP1 EXEC PGM=IEFBR14 //* DIES IST EIN BEISPIEL FUER EINEN KOMMENTAR AUSSER//* HALB VON JCL-ANWEISUNGEN 000500 //INPUT DD DSN=UUIN.SCHULUNG.INPUT,

000100 000200 000300 000400

DISP=SHR

000600 // ******

KOMMENTARE KOENNEN AUCH HIER BEGINNEN BOTTOM OF DATA ***************************

****************************

Default-Werte

einige Parameter und Subparameter existieren systemseitige Default-Werte (Standardeinstellungen). Will man diese übernehmen, so braucht man den entsprechenden

Für

Parameter nicht

sich um einen Schlüsselwort-Parameter handelt. Bei Abwesenheit desselben durch ein Komma aber aus Dokumentationsgründen für erforderlich Default-Parameter dennoch kodieren.

zu

kodieren,

wenn es

positionellen Parametern muß die gekennzeichnet werden. Wenn man es hält, so kann man

Parameter Wie bereits erwähnt gibt es zwei Arten 1. positionelle (positional) und

von

Parametern:

(keyword) Parameter Wie der Name schon sagt, werden positionelle Parameter anhand ihrer Position erkannt. Werden sie weggelassen, so muß an ihre Stelle ein Komma treten. In diesem Fall werden Default-Werte angenommen. Gegebenenfalls sind mehrere Kommata für mehrere fehlende positionelle Parameter zu setzen. Fehlende positionelle Parameter am Schluß einer Anweisung brauchen nicht durch ein Komma ersetzt zu werden. Schlüsselwort-Parameter werden unabhängig von ihrer Position erkannt. Sie können überall 2. Schlüsselwort-

innerhalb des Parameter-Feldes stehen.

2.1

Die JOB-Anweisung

Ein Job ist eine Folge von JCL-Anweisungen, die mindestens aus einer JOB und einer oder mehreren EXEC-Anweisungen besteht. Jede EXEC-Anweisung markiert den Beginn eines Steps. Jeder Step ist mit der Ausführung eines Programmes verknüpft. Ein Job besteht also aus mindestens einem Step, er kann aber auch eine Vielzahl von Steps umfassen (bis 255).

Jeder Job muß mit einer Job-Anweisung beginnen. Aus ihm ergibt sich der Job-Name, der Abrechnungscode, die Klasse, in der der Job laufen soll, Art und Umfang der Nachrichten,

JCL

27

die man sind.

von

MVS zurückbekommen will und der

Ort,

an

den die

Ausgaben

zu

schicken

Syntax: JOB

(acct.info[,add.acct.info])[,'programmierer name'], CLASS=jobklasse, MSGCLASS=outputklasse[,] [NOTIFY=userid,] [MSGLEVEL=(anweisung,nachricht)5] [TYPRUN=SCAN,] [REGION=wertK oder wertM,] [TIME=(min,sec),] [COND=(zahl,operator),] [RESTART=stepname]

Die einzelnen Parameter werden in den

Der

folgenden Kapiteln erläutert.

Beginn der JOB-Anweisung

Syntax:

//jobname

JOB (acct.info[,add.acct.info]), ['Programmierer name',]

jobname ist ein bis zu 8 Zeichen langer String, der aus Buchstaben, Zahlen und den Zeichen '#', '@' und '$' bestehen kann. Das erste Zeichen darf keine Ziffer sein.

jeder MVS-Installation gibt es eigene Regeln für die Vergabe von Job-Namen. Erkundigen Sie sich, wie die entsprechenden Vorschriften bei Ihnen sind. In den Beispielen In

wird davon ausgegangen, daß der Job-Name aus der USERID: UWIN und vier wahlfreien Zeichen bestehen darf. Auf das JOB-Schlüsselwort folgt in Klammern die Abrechnungsinformation (account info). Auf sie kann das Feld additional account info folgen. Beide Angaben sind rein installationsabhängig. Erkundigen Sie sich, wie diese Angaben für Sie lauten müssen. Der Name desjenigen, der den Job abschickt, folgt nach den Abrechnungsinformationen. Beachten Sie, daß der Name in Hochkommata gesetzt wird. (Das ist unumgänglich, wenn z.B. Punkte im Namen verwendet werden).' Die folgenden Beispiele zeigen den Beginn von Job-Anweisungen.

MVS/ESA JCL

28

EDIT-UWIN.SCHULUNG.CNTLCUEB1) -

COMMAND

===>

01.00-. COLUMNS 001 072 SCROLL ===> PAGE

000001 //UWINUEB1 JOB (998,ABTDG02),'M.WINTER1, 000002 // MSGCLASS=Y, CLASS=A 000003 // 000004 //*_

UWIN.SCHULUNG.CNTLCUEB1)

EDIT

COMMAND 000001 //PRODP001 JOB

01.00

C OLUMNS 001 072

-

-

SCROLL

===>

===>

PAGE

(124),1M.WINTER 1,

000002 // MSGCLASS=Y, CLASS=A 000003 // 000004 //*_

CLASS Syntax:

CLASS=jobklasse Als Wert für jobklasse sind 0-9 und A-Z

zulässig.

Zuteilung von Jobs in bestimmte Job-Klassen dient der optimalen Auslastung des Systems. Es gibt daher Klassen für Produktion und Entwicklung, Klassen für Jobs mit hohem CPU-Anteil oder Klassen für Jobs, die viele I-Os durchführen. Auch die Frage, ob Band- bzw. Kassettenverarbeitung zugelassen ist, spielt bei der Wahl der Job-Klasse eine Die

Rolle.

Erkundigen Sie sich, welche Job-Klassen benutzen dürfen.

in Ihrer Installation

generiert sind und welche Sie

MSGCLASS Syntax:

MSGCLASS=outputklasse Als Wert für outputklasse sind 0-9 und A-Z zulässig. Der Parameter MSGCLASS teilt MVS mit, wo der Output hingestellt werden soll, d.h. soll er gedruckt werden oder nur ins IOF Menü laufen, wo er angeschaut werden kann. Mit jeder Output-Klasse ist ein Maximum an sogenanntem SYSOUT Output verbunden. Wird dieses Maximum überschritten, so erhält man an einen S722 ABEND. Wenn dieser

29

JCL

Fall eintreten sollte, so müssen Sie ihrem Job eine andere MSGCLASS zuordnen. Erkundigen Sie sich, welche MSGCLASSes bei Ihnen generiert sind.

MSGLEVEL Syntax:

MSGLEVEL=(anweisung,nachricht) Default:

MSGLEVEL=(1,1)_

Mit MSGLEVEL bestimmen Sie Art und Umfang der von System zurückzugebenden Meldungen. Der Parameter besteht aus zwei positionellen Subparametern: 1.

2.

Subparameter anweisung (Zahl zwischen 0 und 2) Bedeutung: Der

0

=

1

=

2

=

JOB-Anweisung drucken alle JCL-Anweisungen drucken, einschließlich solcher von Prozeduren nur JCL-Anweisungen des Eingabestroms drucken (von JCL-Prozeduren stammende Anweisungen werden nicht gedruckt) nur

Subparameter nachricht (Meldung) (Zahl zwischen 0 und 1) Bedeutung: 0 nur STEP-Ende-Meldungen drucken, keine Allokations- und Deallokations-Meldungen drucken 1 alle Meldungen drucken Der

=

=

Der Default für den MSGLEVEL Parameter ist

MSGLEVEL=(1,1) Anhand des MSGLEVEL-Parameters soll die Bedeutung positioneller Parameter erläutert werden. Will man z.B. den ersten Parameter weglassen, so kann man:

//

MSGLEVEL=(,0)

eingeben. Das Komma steht für den fehlenden ersten positionellen Subparameter. An seine Stelle tritt der Default-Wert 1. man den zweiten Subparameter (nachricht) weglassen will,

Wenn

//

MSGLEVEL=(2 ) ,

so

könnte man:

MVS/ESA JCL

30

eingeben. Da jedoch das Komma nicht erforderlich ist, Subparameter weggelassen wird, kann man statt dessen:

//

wenn

der letzte

positionelle

MSGLEVEL=(2)

Die Klammern sind jedoch nur dann erforderlich, wenn mehrere Subparameter voneinander getrennt werden sollen. Da hier nur noch ein Subparameter übrig bleibt, kann man bedenkenlos:

eingeben.

//

MSGLEVEL=2

eingeben. NOTIFY Syntax:

NOTIFY=userid Wird NOTIFY angegeben, so meldet sich MVS bei Beendigung des Jobs bei dem User, dessen USERID eingetragen ist. Die Benutzung dieses Parameters kann sehr nützlich sein. In den meisten Installationen ist als Standard NOTIFY=userid gesetzt, so daß man im Normalfall nichts angeben braucht.

REGION auf Job-Ebene Syntax: REGION=wertK oder wertM In vielen Installationen wird einem TSO User eine Region von 4096 K als 'private region' Verfügung gestellt. Dieser Platz steht dem Programm im virtuellen Speicher zur

zur

Verfügung. Sollte ein Anwendungsprogramm mehr Platz benötigen, so kann mit REGION mehr Platz angefordert werden. Die Anforderung kann in Kilobyte oder Megabyte erfolgen. Wenn MVS den angeforderten Platz nicht zur Verfügung stellen kann, kommt es zu einem

Abbruch.

Es ist auch möglich, REGION auf Step-Ebene einzusetzen.

31

JCL

TIME auf Job-Ebene Syntax:

TIME=[min,sec] TIME wird überwiegend in Testumgebungen verwandt. Der Parameter dient dazu, einen Abbruch zu erzeugen, wenn das Programm die angegebene CPU-Zeit überschreiten sollte. In diesem Fall kommt es zu einem S322 ABEND. Der TIME-Parameter ist also eine Notbremse für den Fall eines Loops. Die Zeitvorgabe, die sich durch die CLASS ergibt, kann mit dem TIME-Parameter zwar herab, nicht aber herauf gesetzt werden. Minuten und Sekundenangabe werden durch ein Komma getrennt. Steht nur eine Zahl da, so wird sie als Minuten interpretiert.

Beispiele für den Parameter TIME: TIME=2

TIME=(1,45) TIME=30

TIME=(,30)

gibt ein Limit von 2 Minuten an gibt ein Limit von 1 Minute und 45 gibt ein Limit von 30 Minuten an gibt ein Limit von 30 Sekunden an

Sekunden

an

TYPRUN

Syntax:

TYPRUN=SCAN TYPRUN=SCAN bewirkt eine Syntaxprüfung der JCL. Der Job selbst kommt nicht zur Ausführung, auch dann nicht, wenn die JCL-Anweisungen fehlerfrei sind. JCLAllokationsfehler, die sich erst zur Laufzeit bemerkbar machen, können mit dieser

Anweisung nicht aufgespürt werden. COND auf Job-Ebene Syntax:

COND=[zahl,operator] Als zahl kann ein

beliebiger Wert zwischen 0 und 9999 stehen.

MVS/ESA JCL

32

Als

Operatoren unter op sind möglich: EQUAL

EQ

GT GE LT LE NE

> >=

< 8, dann wird der Job abgebrochen. Als Zahl kann ein beliebiger Wert zwischen 0 und 9999 stehen. Will man z.B. erreichen, daß der Job abbricht, wenn ein Step einen Return Code von 12 oder mehr zurückgibt, so kann man bei der Formulierung der Bedingung wie folgt

verfahren:

33

JCL

Gewünschte Bedingung: Wenn RC >=

12, dann breche ab.

Umkehrung: Wenn 12

*****************************

TOP OF DATA

===>

PAGE

*****************************

000001 //UWIN217G JOB (998,ABTDG02),1M.WINTER',CLASS=A, MSGCLASS=Y 000002 // ****** **************************** BOTTOM OF DATA ***************************

MVS/ESA JCL

34

Dieses

Beispiel zeigt eine um mehrere Parameter ergänzte JOB-Anweisung:

edit-uwin.schulung.cntl(pgm01)

01.15 -

command ******

.

columns 001 072 ===> page

scroll

===> *****************************

000001 //uwin217g job

top of data

*****************************

(998,abtdg02),'m.winter1,class=a,notify=uwin,

msgclass=y,

000002 000003 000004 000005

// // // //*

******

****************************

time=(,10), msglevel=(1,1) msglevel=(1,1),typrun=scan BOTTOM OF DATA

***************************

Die EXEC-Anweisung

2.2

EXEC-Anweisung werden Programme oder Prozeduren aufgerufen. Sie markiert gleichzeitig den Beginn eines Steps. Mindestens ein Step muß vorhanden sein, d.h. zu jedem Job gehört zumindest eine EXEC-Anweisung. Mit der

Syntax:

PGM=pgmname | [PROC]=procname[,] [PARM=,parameter,J] [COND=(zahl,operator[,stepname]),] [TIME=(min,sec),] [REGION=wertK oder wertM]

EXEC

PGM Syntax:

PGM=pgmname Mit pgmname wird der Name des auszuführenden Programms angegeben. Es kann ein vom User geschriebenes Programm sein oder ein Utility-Programm. User-Programme müssen zuerst kompiliert und gelinkt werden.

Programme werden normalerweise in den sogenannten LINKLIBs gefunden. Als LLNKLIB wird die SYS 1 .LINKLIB und die mit ihr verketteten Bibliotheken bezeichnet. Auf diesen Bibliotheken stehen ausführbare Programme (Lademodule), die allen Usern einer MVSInstallation zugänglich sind. Es gibt jedoch auch die Möglichkeit, mit privaten

35

JCL

Ladebibliotheken werden.

zu

arbeiten. Dann muß mit der STEPLIB

PROC als Parameter der

DD-Anweisung gearbeitet

EXEC-Anweisung

Syntax:

[PROC=]procname Mit procname wird der Name der auszuführenden Prozedur PROC kann, muß aber nicht angegeben werden:

//COMPLINK

EXEC PROC=COBCL

//COMPLINK

EXEC COBCL

Beide Anweisungen bewirken, daß die Prozedur COBCL

angegeben.

Das Schlüsselwort

aufgerufen wird.

Prozeduren werden auf der SYS1.PROCLIB und den mit ihr verketteten Bibliotheken gefunden. Auf diesen Bibliotheken stehen Prozeduren, die allen Usern einer MVSInstallation zugänglich sind. Unter MVS/ESA Version 4 gibt es jedoch auch die Möglichkeit, private Prozedurbibliotheken zu definieren. Diese Möglichkeit wird im Kapitel über JCL-Prozeduren behandelt. Obwohl es syntaktisch nicht erforderlich ist, sollte bei jeder EXEC-Anweisung immer ein

Stepname angegeben werden.

PARM Über den PARM-Parameter lassen sich Informationen an Anwendungsprogramme weitergeben. Die Länge des Parameters darf 100 Zeichen nicht überschreiten. In den Anwendungsprogrammen muß ein geeignetes Feld für die Aufnahme der Parameter definiert werden. Dem eigentlichen Parameter ist ein Feld vorangestellt, dem die tatsächliche Länge des übergebenen Parameters entnommen werden kann.

Beispiel: Anweisung in der JCL:

//STEP1

EXEC

PGM=PGM01,PARM='STRING'

36

MVS/ESA JCL

Aufbereitung der LINKAGE SECTION in einem COBOL-Programm: LINKAGE SECTION. 01

PARAMETER.

05 LAENGE 05 PARM1

PIC PIC

S9(4) COMP. X(100).

Notwendige Anpassung der PROCEDURE DIVISION-Anweisung: PROCEDURE DIVISION USING PARAMETER.

COND auf EXEC-Ebene

Solange Ihnen die Version 4 von MVS/ESA noch nicht zur Verfügung steht, müssen Sie sich mit dem vorhandenen COND-Parameter abplagen. Wenn Sie die folgenden Ausführungen gelesen haben, werden Sie die Einführung der Version 4 von MVS/ESA kaum noch erwarten können. Syntax:

COND=(zahl,operator[,stepname]) Syntax ist ähnlich wie beim COND-Parameter auf Job-Ebene. Es wird immer die Bedingung formuliert, die zum Nicht-Ausfuhren des Steps führt. Nachfolgende Steps werden wieder ausgeführt. Wird der Subparameter stepname weggelassen, so bezieht sich die Abfrage auf den höchsten bisher zurückgegebenen Return Code. Ansonsten bezieht sich die Abfrage auf den Return Code des angegebenen Steps. Es ist auch möglich, die Return Codes mehrerer Steps abzufragen. Diese Abfragen sind dann mit einem logischen UND verknüpft. Der Return Code selbst ist nicht Bestandteil der Syntax. Ihn muß man sich gedanklich ergänzen (siehe COND auf JOB-Ebene). Die

37

JCL Ein Beispiel soll dies verdeutlichen:

//STEP1

EXEC PGM=PROGl

//STEP2

EXEC

PGM=PROG2,COND=(0,NE,STEP1)

//STEP3

EXEC

PGM=PROG3,COND=(12,LE,STEP1)

//STEP4

EXEC PGM=PROG4

Die Ausführung von STEP2 ist abhängig von dem Return Code, der bei Beendigung von STEP1 erzeugt wird. Ist der Return Code von STEP1 ungleich 0, dann soll STEP2 nicht ausgeführt werden. In diesem Fall springt MVS sofort zu STEP3. Dieser Step wird aber nur dann ausgeführt, wenn der RC von STEP1 kleiner 12 ist, andernfalls wird auch dieser Step nicht ausgeführt. STEP4 wird unabhängig von den Return Codes von STEP1 STEP3 -

ausgeführt. Im Gegensatz zum COND-Parameter auf Job-Ebene führt der COND-Parameter in der EXEC-Anweisung nicht zu einem Abbruch des gesamten Jobs. Lediglich der betreffende Step wird nicht ausgeführt. Nachfolgende Steps werden aber ausgeführt. Erzeugt in obigem Beispiel STEP1 einen RC von 4, so wird STEP2 übersprungen, STEP3 und STEP4 aber gelangen zur Ausführung. Es können auch die Return Codes mehrerer Steps abgefragt werden. Beachten Sie die zusätzliche Klammerung, die in diesem Fall notwendig wird:

//STEP1

EXEC PGM=PROGl

//STEP2

EXEC PGM=PROG2

//STEP3 //

EXEC

//STEP4

EXEC PGM=PROG4

PGM=PROG3,

COND=((12,LE,STEP1),(8,LE,STEP2))

STEP3 wird ausgeführt,

wenn

STEP1 einen RC




******

*****************************

000001 000002 000003 000004

//uwin217g

// //chkcat //sysprint 000005 //sysin

===>

page

*****************************

job (998,abtdg02),'m.winter1,class=a,not ify=uwin, msgclass=y,time=(,10) exec pgm=idcams dd sysout=* dd

*

(uwin-schulung.ds99)

000006

delete

000007 000008 000009 000010 000011 000012

if maxcc

//step1

8 then set maxcc exec pgm=pgm01 =

dd

=

0

dsn=uwin.schulung.load,disp=shr

000013 000014 000015 000016 000017

//steplib //sysprint //sysabout //sysout //outfile // // // //

******

****************************

Besondere

top of data

dd sysout=* dd sys0ut=* dd sys0ut=* dd

dsn=uwin.schulung.ds99,

disp=(new,catlg), recfm=fb,

space=(trk,(5,1),rlse), un it=dskprm

bottom of data

***************************

DD-Anweisungen

DD-Feldnamen sind grundsätzlich wahlfrei. Es gibt jedoch eine Reihe festgelegter Feldnamen für bestimmte DD-Anweisungen, die eine besondere Bedeutung haben.

DD-Anweisungen mit festgelegten Feldnamen gibt es eine Reihe weiterer spezieller DD-Anweisungen, auf die im folgenden Abschnitt eingegangen wird. Grundsätzlich sollte man keinesfalls DD-Feldnamen kreieren, die mit SYS beginnen, da sonst zufällige Namensgleichheiten mit festgelegten DD-Feldnamen nicht auszuschließen

Neben solchen

sind.

DD-Namen für Utility

Output

Syntax: //SYSPRINT DD SYSOUT=*

63

JCL

Über den MSGLEVEL-Parameter lassen sich Art und Umfang der gewünschten JobInformationen steuern. Diese Messages werden auf das Spool-Volume geschrieben. Dafür

sind keine besonderen Angaben nötig, sofern kein Utility-Programm ausgeführt wird. Utility-Programme wie z.B. IDCAMS erzeugen jedoch einen zusätzlichen Output, für den auf dem Spool-Volume ein Dataset angelegt werden muß. Dieses Dataset muß unter dem DD-Namen SYSPRINT angesprochen werden. Um den Output auf das Spool-Volume zu legen, genügt die Angabe SYSOUT=*. Diese Anweisung bewirkt, daß alle Messages, die sich auf den Output einer Utility beziehen, in ein Dataset namens SYSPRINT geschrieben werden. Der Stern hinter SYSOUT dient dazu, die in MSGCLASS angegebene Output-Klasse zu verwenden. Es ist jedoch auch möglich, eine bestimmte Output-Klasse zu benutzen. Diese muß dann explizit angegeben werden. Es ist auch möglich, den Output in ein sequentielles Dataset laufen zu lassen. Von dieser Möglichkeit wird aber nur selten Gebrauch gemacht. Da diese Anweisung häufig gebraucht wird, sollte immer aufzunehmen. Wird SYSPRINT nicht benötigt, DD-Namen für DISPLAY

sich angewöhnen, diese Zeile entsteht kein Schaden.

man so

Output

Syntax: //SYSOUT

DD SYSOUT=*

Dient der Ausgabe von DISPLAY-Kommandos in einem COBOL Anwendungsprogramm. Die beiden SYSOUT sollten nicht miteinander verwechselt werden. Das erste SYSOUT ist ein Feldname (DD-Name), das zweite ist ein DD-Parameter und bewirkt die Umleitung auf das Spool-Volume. Dieser DD-Name ist installationsabhängig. Es kann sein, daß er bei Ihnen SYSOUX oder ähnlich heißt. Erkundigen Sie sich, welche Bezeichnung bei Ihnen zu verwenden ist. Die STEPLIB

DD-Anweisung

Syntax:

//STEPLIB DD DSN=dsname,DISP=SHR Die STEPLIB

DD-Anweisung benötigen Sie, wenn das Programm, das durch die EXECAnweisung ausgeführt werden soll, nicht auf einer sogenannten LINKLIB, sondern auf einer privaten Ladebibliothek steht. Als LINKLIB bezeichnet man eine Verkettung von Bibliotheken, die ausführbare Programme enthalten. So stehen z.B. alle Utility-Programme auf einer LINKLIB. Wo die von Ihnen kompilierten und gelinkten Programme stehen, ist abhängig von der Compileund Link-Prozedur, die in Ihrem Unternehmen verwendet wird. Es kann, muß aber keine

64

MVS/ESA JCL

LINKLIB sein. Für den Fall, daß es sich bei der Ladebibliothek nicht handelt, müssen Sie den Bibliotheksnamen unter STEPLIB angeben.

//STEP1 //STEPLIB

um

eine LINKLIB

EXEC PGM=PGM01 DD DSN=UWIN.LOAD,DISP=SHR

UWIN.LOAD muß eine Ladebibliothek sein, d.h. sie muß das Record-Format U besitzen und die logische Record-Länge muß 0 sein. Die BLKSIZE muß von 0 verschieden sein. Ist STEPLIB angegeben, so schaut MVS nur auf die dort angegebene Bibliothek und auf keine andere. Ist das Programm dort nicht vorhanden, kommt es zu einem S806 ABEND. Sollen mehrere Bibliotheken durchsucht werden, so müssen sie verkettet (konkateniert) werden. Ein Maximum von 16 verketteten Bibliotheken ist möglich.

//STEP1 //STEPLIB //

EXEC PGM=PGM01

DSN=UWIN.LOADl,DISP=SHR DD DSN=UWIN.LOAD2,DISP=SHR

DD

Die Funktionsweise der Verkettung wird weiter unten erläutert. Die STEPLIB DD-Anweisung kann irgendwo im Step stehen. Aus Gründen der Übersichtlichkeit sollte sie jedoch unmittelbar auf die EXEC-Anweisung folgen. Die JOBLIB

DD-Anweisung

Syntax: //JOBLIB DD DSN=dsname,DISP=SHR Im

Gegensatz zur STEPLIB DD-Anweisung bezieht sich die JOBLIB DD-Anweisung auf den gesamten Job. Die JOBLIB DD-Anweisung muß zwischen der JOB-Anweisung und der ersten EXECAnweisung stehen. Steht sie an einer anderen Stelle, kommt es unweigerlich zu einem JCLFehler. IEF606I

MISPLACED DD STATEMENT

Werden STEPLIB und JOBLIB zusammen angegeben, so gilt immer die STEPLIBAnweisung im betreffenden Step. Die unter JOBLIB genannten Bibliotheken werden dann nicht abgesucht.

Sollen mehrere Bibliotheken durchsucht werden, so müssen sie verkettet (konkateniert) werden. Ein Maximum von 16 verketteten Bibliotheken ist möglich. Bei der Benutzung von JOBLIB werden im Unterschied zu STEPLIB neben den angegebenen Bibliotheken auch die LINKLIB-Bibliotheken durchsucht. Es kann daher nicht so leicht zu einem S806 ABEND kommen.

65

JCL Das

folgende Beispiel zeigt

Beachten Sie, daß im STEP1 wird.

einen JOB mit JOBLIB- und STEPLIB-Anweisungen. die Bibliothek: UWIN.SCHULUNG.LOAD abgesucht

nur

edit-uwin. schulung. cntl(pgm01)

01.15

.-.

-

command ******

columns 001 072 ===> page

scroll

===> *****************************

fop op data

*****************************

000001 //uwin217g job (998,abtdg02),1m.winter1,class=a,n0tify=uwin, 000002 // msgclass=y, 000003 // msglevel=(1,1) dd dsn=uuin.load,disp=shr 000004 //joblib 000005 // dd dsn=sys1.linklib,disp=shr dd dsn=sys1.loadlib,disp=shr 000006 // exec pgm=idcams 000007 //chkcat 000008 //sysprint dd sysout=* dd * 000009 //sysin delete (uwin.schulung.ds99) 000010 if maxcc = 8 then set maxcc = 0 000011 exec pgm=pgm01 000012 //step1 000013 //steplib dd dsn=uwin.schulung.load,disp=shr 000014 //sysprint dd sysout=* 000015 //sysabout dd sysout=* 000016 //sysout dd sysout=* 000017 //outfile dd dsn=uwin.schulung.ds99, 000018 // disp=(new,catlg), 000019 // recfm=fb, 000020 // space=(trk,(5,1),rlse), unit=dskprm 000021 // ******

****************************

bottom of data

***************************

Der DD DUMMY-Parameter

Will man in Testumgebungen das Vorhandensein eines Dataset nur simulieren, so kann dazu der DUMMY-Parameter verwendet werden. Bei Ausgabedatasets wird in die Luft geschrieben, bei Eingabedatasets wird beim ersten READ die End-of-File Bedingung

zurückgegeben.

Unter Umständen können auch

DCB-Angaben zusammen mit DUMMY eingesetzt werden.

Beispiel:

//EINGABE //AUSGABE

DD DUMMY DD

DUMMY,BLKSIZE=23440

Wie man VSAM-Datasets auf DUMMY setzt, ist im

Kapitel über VSAM erläutert.

MVS/ESA JCL

66

Verketten

von

Datasets

MVS bietet die Möglichkeit, mit Hilfe von JCL mehrere physische Datasets zu einem logischen Dataset zu verketten (Concatenation of Datasets). Voraussetzung ist, daß alle zu verkettenden Datasets die gleiche LRECL besitzen, die BLKSIZE kann, muß aber nicht identisch sein.

Verkettet werden können nur gleichartige Datasets, also sequentiell mit sequentiell, PODatasets mit PO-Datasets. Sofern SMS installiert ist, spielt der Datenträger keine Rolle, d.h. ein sequentielles Dataset auf Band kann sehr wohl mit einem sequentiellen Dataset auf Platte verkettet werden. Ohne SMS muß die Art des Datenträgers gleich sein. Bei der Verkettung erhält nur das erste Dataset einen DD-Namen, die übrigen folgen

unmittelbar, wie folgendes Beispiel zeigt:

//INPUT // //

DD DSN=UWIN.JANUAR,DISP=SHR DD DSN=UWIN.FEBRUAR,DISP=SHR DD

DSN=UWIN.MAERZ,DISP=SHR

Das Anwendungsprogramm betrachtet die so verketteten Datasets als ein logisches Dataset. Es ist also nur ein OPEN und ein CLOSE erforderlich. Sehr häufig werden Verkettungen im Zusammenhang mit STEPLIB oder JOBLIB

eingesetzt.

//STEP1 //STEPLIB // // Beachten Sie

EXEC PGM=PGM04

DSN=UWIN.LOAD,DISP=SHR DSN=UGOS.LOADLIB,DISP=SHR DD DSN=SYS1.LOADLIB,DISP=SHR DD DD

Folgendes:

Stehen in den verketteten Bibliotheken Member mit gleichem Namen, so wird immer das Member gefunden, das in der Bibliothek steht, die in der Verkettung zuerst genannt wird. Stehen also im obigen Beispiel zwei Member mit Namen PGM04 auf den Bibliotheken UWIN.LOAD und UGOS.LOADLIB, so wird immer das Member auf der UWIN.LOAD gefunden und zur Ausführung gebracht. Achten Sie beim Kompilieren und Linken darauf, daß das ausführbare Programm auf die richtige Bibliothek kommt. Wird das Programm PGM04 neu kompiliert und gelinkt und anschließend als ausführbares Modul auf die UGOS.LOADLIB gestellt, so wird beim Ausführen von STEP1 immer die alte Version des PGM04, das auf der UWIN.LOAD steht, ausgeführt. Dies kann zu erheblicher Verwirrung führen, da Sie annehmen könnten, die von Ihnen vorgenommenen Programmänderungen hätten nichts bewirkt. Überprüfen Sie die verketteten Bibliotheken auf Namensgleichheiten von Membem und versuchen Sie, diesen Zustand nach Möglichkeit zu vermeiden.

67

JCL

DD

SYSOUT-Anweisungen

Der DD-Parameter SYSOUT dient dazu, Ausgaben auf das Spool-Volume zu schreiben. Diese Ausgaben können sofort gedruckt werden oder aber zunächst gehalten und angeschaut werden. Den Output auf SYSOUT umzuleiten, kann beim Testen Vorteile bringen, da man sich unter anderem das Vergeben eines DSN und damit alle Katalogprobleme erspart. Einige Parameter, wie VOL, DISP und LABEL, dürfen nicht eingesetzt werden, andere wie UNIT oder SPACE können zwar angegeben werden, sie werden aber ignoriert. Damit vereinfacht sich unser Beispiel-Job erheblich. Er braucht jetzt auch keinen vorgeschalteten IDCAMS-Step mehr. edit-uwin schulung. cn tl (pgm01)

01.15

.

-

command

.

columns 001 072 ===> page

scroll

===>

******

*****************************

000001 000002 000003 000004 000005

//uwin217g

job

// //

msgclass=y,

top of data

*****************************

(998,abtdg02),1m.winter1,class=a,not ify=uwin,

msglevel=(1,1)

//step1

exec pgm=pgm01

dd

000006 000007 000008 000009

//steplib //sysprint //sysabout //sysout //outfile

******

****************************

dsn=uwin.schulung.load,disp=shr

dd sys0ut=*

dd sys0ut=* dd sysout=* dd sys0ut=*

Sozusagen als Ausgleich gibt auf die hier eingegangen wird:

es

für

bottom of data

***************************

SYSOUT-Anweisungen einige

besondere Parameter,

Der DCB-Parameter

Auch für SYSOUT-Datasets kann der DCB-Parameter angegeben werden. Er muß angegeben werden, wenn im Anwendungsprogramm keinerlei Angaben zur LRECL und RECFM gemacht werden. Die BLKSIZE läßt man am besten vom System errechnen. Im Gegensatz zu Datasets auf Platte oder Band haben kleine BLKSIZEs keine negativen Auswirkungen auf Platznutzung und Performance.

SYSOUT-Output häufig gedruckt wird, findet sich folgende Angabe: DD SYSOUT=*,LRECL=13 3, //DRUCK RECFM=FBA,BLKSIZE=13 3 II

Da

RECFM=FBA bewirkt, daß das erste Byte als Drucksteuerzeichen

interpretiert wird.

68

MVS/ESA JCL

Der OUTLIM-Parameter

Syntax:

OUTLIM=nnnn Der OUTLIM-Parameter dient der Begrenzung des Outputs. Er findet vor allen Dingen in Testumgebungen Verwendung. Er kann nur zusammen mit dem SYSOUT-Parameter verwendet werden. Bei normalen Datasets kann er zwar angegeben werden, ist aber unwirksam. Als Wert für nnnn kann eine beliebige Zahl zwischen 1 und 16.777.215 verwendet werden.

Wird die angegebene Zahl überschritten, so kommt es zu einem S722 ABEND. Der OUTLIM-Parameter ist somit eine Art Notbremse für den Fall eines Loops. Mit ihm läßt sich das überflüssige Drucken von Seiten im Fehlerfall zumindest begrenzen. Der COPIES-Parameter

Syntax: COPIES=nnn Mit COPIES wird die Zahl der Kopien angegeben, die erzeugt werden sollen. Die Zahl kann zwischen 1 (Default) und 254 liegen. Der DEST-Parameter

Syntax (JES2): DEST=LOCAL DEST=name DEST=Nnnnn DEST=NnnRmmmm DEST=NnnnRmmm DEST=NnnnnRmm DEST=Rnnnn DEST=RMnnnn DEST=RMTnnnn

DEST=Unnnn_ Unter dem Job Entry

Subsystem 3 weicht die Syntax geringfügig ab. Mit LOCAL wird irgendein lokaler Drucker angesprochen. name kann nur genutzt werden, wenn in Ihrer Installation entsprechende Festlegungen getroffen worden sind.

69

JCL

Mit Nnnnn wird die Nummer eines Knotens angegeben. Dies ist dann erforderlich, wenn sich Rechenzentrum und Drucker an verschiedenen Orten befinden. Mit den Angaben NnnRmmmmm, NnnnRmmmm und NnnnnRmmm wird eine Kombination von Knoten und Datenfernverarbeitungsstation angegeben. Mit Rnnnn, RMnnnn oder RMTnnnn wird ein remote angeschlossenes Terminal

angesprochen. Mit Unnnn wird ein spezielles Routing angesprochen, das wird der Output an eine bestimmte Destination geleitet.

installationsabhängig

ist. Damit

Beispiel:

//SYSPRINT

DD

SYSOUT=A,DEST=U0302

In diesem Fall wird der SYSPRINT unmittelbar auf den Drucker mit der logischen Adresse U0302 gelegt. Zum Umleiten eines Druck verwenden.

Outputs können Sie auch das /*ROUTE

JES2-Kommando

Der SEGMENT-Parameter

Syntax:

SEGMENT=pages Mit der Version 4 von MVS/ESA wurde der SEGMENT-Parameter verfügbar. Er dient dazu, bei großem Output mit dem Drucken zu beginnen, obwohl der Job-Step noch nicht beendet ist.

Beispiel:

//SYSOUT

DD

SYSOUT=A,SEGMENT=100

Sind 100 Seiten erzeugt worden, so werden sie zum Druck freigegeben. Sind unter SYSOUT=A mehrere physische Drucker zusammen definiert, so kann es passieren, daß die unterschiedlichen Segmente auf unterschiedlichen Druckern

gedruckt werden.

Der SPIN-Parameter

Syntax:

SPIN=UNALLOC

70

MVS/ESA JCL

Durch die Angabe SPIN=UNALLOC ist es möglich, ein SYSOUT-Dataset bereits bei StepEnde zu deallokieren, wonach mit dem Drucken begonnen werden kann (Normalerweise ist dies bei SYSOUT-Datasets erst nach Job-Ende möglich). Wird SEGMENT und SPIN angegeben,

so

überschreibt SEGMENT SPIN.

Der FREE-Parameter

Syntax:

FREE=CLOSE Mit FREE=CLOSE wird ein Dataset schon beim CLOSE deallokiert, also noch vor dem Step-Ende. Damit kann noch etwas früher mit dem Drucken begonnen werden als bei der Angabe SPIN=UNALLOC.

Beispiel:

//SYSOUT

DD

SYSOUT=A,SPIN=UNALLOC,FREE=CLOSE

Die SYSIN DD-Anweisung Syntax: //SYSIN

DD

*

DD

DSN=datasetname,DISP=SHR

DD

DSN=datasetname(member),DISP=SHR

oder

//SYSIN oder

//SYSIN

Mit der SYSIN DD-Anweisung wird MVS angezeigt, daß nunmehr entweder Input-Daten unmittelbar folgen oder das angesprochene Dataset den Input enthält. Alle Utility-Programme haben eine SYSIN-Anweisung. MVS erkennt das Ende von SYSIN-Anweisungen daran, daß entweder das Delimiterzeichen /* vorkommt oder eine neue JCL-Anweisung mit // beginnt. Das folgende Beispiel zeigt einen typischen Fall. Im Step CHKCAT wird das Programm IDCAMS aufgerufen, das seine Steueranweisungen über die SYSIN DD * Anweisung erhält.

71

JCL EDIT-UWIN.SCHULUNG.CNTL(PGMOI)

01.15

.

-

COMMAND ******

===>

*****************************

fop OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

000001 //UWIN217G JOB (998,ABTDG02),1M.WINTER ,CLASS=A,NOTIFY=UWIN, 000002 // MSGCLASS=Y, EXEC PGM=IDCAMS 000003 //CHKCAT 000004 //SYSPRINT DD SYSOUT=* DD * 000005 //SYSIN DELETE (UWIN.SCHULUNG.DS99) 000006 IF MAXCC = 8 THEN SET MAXCC = 0 000007 1

000008 /* _

_

Umgebungen, die den Einsatz von SYSIN DD * nicht zulassen, z.B. bei Prozeduren müssen die SYSIN-Daten in ein Dataset gestellt werden. Am besten eignet sich dazu ein Member einer Bibliothek. Das folgende Beispiel ist eine Alternative zum vorherigen In

-

-

Beispiel.

EDIT -UWIN.SCHULUNG.CNTL(PGM01) COMMAND ===>

01.15 .COLUMNS 001 072 -

SCROLL

******

*****************************

000001 000002 000003 000004 000005 000006 000007

//UWIN217G JOB (998,ABTDG02),'M.WINTER1,CLASS=A,NOTIFY=UWIN, MSGCLASS=Y, //

******

****************************

// //

//*

TOP OF DATA

===>

PAGE

*****************************

TIME=(,10), MSGLEVEL=(1,1) MSGLEVEL=(1,1),TYPRUN=SCAN

EXEC PGM=IDCAMS //CHKCAT DD SYSOUT=* //SYSPRINT DD DSN=UWIN.SCHULUNG.DATA(DELDS99),DISP=SHR 000008 //SYSIN

BOTTOM OF DATA

***************************

Das Member DELDS99 der Bibliothek UWIN.SCHULUNG.DATA muß aussehen: EDIT-UWIN.SCHULUNG.DATA(DELDS99)

01.15 -

COMMAND ******

*****************************

DELETE (UWIN.SCHULUNG.DS99) 000001 IF MAXCC = 8 THEN SET MAXCC 000002 000003 /* ******

.

===>

****************************

TOP OF DATA =

folgendermaßen

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

0

BOTTOM OF DATA

***************************

Eine Alternative zu dieser Methode bietet die SYSIN DD DDNAME-Anweisung. Sie verschiebt die inhaltliche Definition eines Feldes auf einen späteren Zeitpunkt im Job. Im Kapitel über Prozeduren ist diese Technik erläutert. Das Ende von SYSIN-Daten wird entweder am Zeichen /* oder an der nächsten folgenden JCL-Anweisung erkannt. Für den Fall, daß die SYSIN-Daten JCL-Anweisungen enthalten,

MVS/ESA JCL

72

muß verhindert werden, daß das Lesen der SYSIN-Daten vorzeitig beendet wird. Dies wird durch die Benutzung von SYSIN DD DATA anstelle von SYSIN DD * erreicht: edit-uwin.schulung.cntl(pgm01)

01.15 -

command

.

===>

columns 001 072 scroll ===> page

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016

//uwin217g job (998,abtdg02),'m.winter1,class=a,not ify=uwin, // msgclass=y, // //

//* //copy //sysprint //sysin //uwin217g // // //

//* //br14 /* //ende

top of data

*****************************

t1me=(,10), msglevel=(1,1) msglevel=(1,1),typrun=scan exec proc=test1 dd sysout=* dd data job

(998,abtdg02),1m.winter 1,class=a,not ify=uwin,

msgclass=y,

time=(,10), msglevel=(1,1) msglevel=(1,1),typrun=scan exec pgm=iefbr14 exec

proc=abschl_

Während sonst das Zeichen /* nicht unbedingt stehen muß, ist es bei der Verwendung von SYSIN DD DATA unbedingt erforderlich. Wird es weggelassen, werden auch die folgenden JCL-Anweisungen als Teil der SYSIN-Daten gelesen. Wenn auch das Zeichen /* Teil der SYSIN-Daten sein soll, so muß ein anderes Delimiterzeichen definiert werden. Dies geschieht mit dem DLM-Parameter und sieht dann

folgendermaßen aus:

73

JCL 01.15

EDIT-UWIN. SCHULUNG .CN TL (PGM01)

.

-

COMMAND ******

COLUMNS 001 072 ===> PAGE

SCROLL

===>

*****************************

top OF DATA

*****************************

000001 //UWIN217G (998,ABTDG02),'M.WINTER',CLASS=A,NOTIFY=UWIN, 000002 // MSGCLASS=Y, 000003 // TIME=(,10), 000004 // MSGLEVEL=(1,1) 000005 //* MSGLEVEL=(1,1),TYPRUN=SCAN 000006 //COPY EXEC PGM=JOBGEN DD SYSOUT=* 000007 //SYSPRINT DD 000008 //SYSIN DATA,DLM=$$ 000009 //UWIN217G JOB (998,ABTDG02),'M.WINTER1,CLASS=A,NOT IFY=UWIN, MSGCLASS=Y 000010 // EXEC PGM=IDCAMS 000011 //CHKCAT 000012 //SYSPRINT DD SYSOUT=* DD * 000013 //SYSIN DELETE (UWIN.SCHULUNG.DS99) 000014 8 THEN SET MAXCC = 0 IF MAXCC 000015 000016 /* EXEC PGM=IEFBR14 000017 //BR14 DD 000018 //OUTFILE DSN=UWIN.SCHULUNG.DS99, 000019 // DISP=(NEW,CATLG), 000020 // RECFM=FB,LRECL=80, 000021 // SPACE=(TRK,(5,1),RLSE), 000022 // UNIT=DSKPRM 000023 $$ 000024 //ENDE EXEC PROC=ABSCHL JOB

=

Die Zeilen 000009 bis 000022 werden als Daten Anweisungen bestehen.

interpretiert,

obwohl diese

aus

JCL-

Output Management Fast alle MVS Installationen haben heutzutage ein Output Management System installiert, das ähnlich dem hier vorgestellten ist. Es handelt sich dabei um die Input-Output-Facility. Nachfolgend ist das eigentliche Job List Menü abgebildet. Es zeigt immer zumindest einen RUNNING JOB, das ist der eigene User, den MVS als Job verwaltet. Sofern weitere Jobs gerade am Laufen sind, würden sie ebenfalls hier angezeigt. Fertige Jobs werden unter OUTPUT JOBS angezeigt.

Um die Jobs anzuschauen, gibt es zwei Möglichkeiten: 1. Eingabe der Jobnummer in der Kommandozeile.

2.

In die

Eingabezeile vor der Jobnummer springen und dort ein s eingeben.

MVS/ESA JCL

74 Im

folgenden Panel sind beide Möglichkeiten eingetragen.

---.---.

IOF JOB LIST MENU .

COMMAND

===>

2

SCROLL

---.-.

RUNNING JOBS

SCREEN

===>

--.

.JOBNAME--JOBID- -ACT-HELD--SYSID.CPU-I/O-STEP.PROCSTEP-SWP IN S21 :01 2.47 ISPF#AS T2731 1 UUIN OUTPUT JOBS ---.

.

.JOBNAME--JOBID--ACT-HELD-DEST.GRPS--RECORDS-BUSY DEVICE--HELDDS-2 UWIN217G

S.

J2746_FRA21_4

Summary Die wichtigsten Informationen im IOF JOB SUMMARY befinden sich in den MESSAGES und in SYSPRINT, sofern dieser nicht leer ist. Schauen Sie immer in die Messages, auch Das Job

bei Return Code 0. Ist SYSPRINT nicht leer, verlassen Sie sich auf die dort abgelegten Informationen. Die Meldungen in MESSAGES können unter Umständen denen widersprechen, die in SYSPRINT stehen. In diesem Fall ignorieren Sie die MESSAGES. =

Im IOF JOB SUMMARY finden Sie unter den DD-Namen alle die wieder, denen JCL SYSOUT=* zugeordnet haben. Unter der Rubrik RECORDS steht die ausgegebenen Records. Bei einigen DD-Namen stehen keine Records. Dies ungewöhnlich, da z.B. unter dem DD-Namen SYSABOUT nur im Falle eines

Angaben stehen würden. Sollte ein Step wegen eines gesetzten

COND-Parameters nicht

anstelle des RC ein *.

IOF JOB SUMMARY COMMAND ===> JOBNAME JOB ID- STATUS --RAN/RECEIVED-DAY--UWIN217G J05683 OUTPUT 10:43 6/13/91 TODAY --RC--STEP-PROCSTEP- PROC-.COMMENTS. 0 CHKCAT -

-

-

0

-

-

-

Sie in der Zahl der ist nicht ABENDs

gelaufen sein,

so

steht

SCROLL ===> SCREEN -DEST.--COPIES. FRA21 1

STEP1

.DDNAME

1 2 3 4 5

LOG

STEP.STAT-ACT-GRP-CLS--RECORDS--DEST9 HELD 14

*

JCL

*

HELD

9

15

MESSAGES

*

HELD SEL

9

SYSPRINT CHKCAT

HELD

9

57 9

SYSPRINT STEP1

DONE

9

SYSABOUT STEP1 SYSOUT STEP1

DONE

9 9

DONE

FORMS-

-COPIES

75

JCL

RC

Hier wird der Return Code für jeden im Job

ausgeführten

Step angezeigt. STEP

Name der

Steps hier CHKCAT und STEP1.

PROCSTEP

Name des

PROC

Name der

LOG

Hier befindet sich die Jobstatistik

Steps in einer Prozedur (ist Prozedur aufgerufen wurde).

leer weil keine

aufgerufenen Prozedur (s.o.). (meist

von nur

ge-

ringem Interesse). JCL

Hier wird die verwendete JCL angezeigt. Dies ist besonders wichtig, wenn in der JCL symbolische Parameter stehen, die zur Laufzeit substituiert werden (häufig bei

Prozeduren). MESSAGES

Hier werden die wichtig, aber auch

System-Messages abgestellt (sehr unzuverlässig, falls ein SYSPRJNT

erzeugt wird). SYSPRINT

Hier werden Meldungen von Utilities

SYSABOUT

Hier werden

SYSOUT

Hier werden

abgestellt.

abgestellt.

Kurzdumps abgestellt.

Displays,

z.B. eines

COBOL-Programms,

MVS/ESA JCL

76 Das Job LOG browse command

*

log

--

page

1-- cols

line

1 -

-

-

scroll

===>

*******************************

jes2

top of data

job

job 5683 job 5683 job 5683 job 5683 job 5683

1 80 screen

***********************************

system

log

nod

s21 --

--

10.43.56 10.43.56 10.43.57 10.43.59 10.43.59

===>

ich70001i uuin last access at 10:42:17 on thursday, june class c sys s21 init 3 $hasp373 uwin217g started 1 104356 104357 .07 s000 uwin217g chkcat .05 sooo 1 104357 104359 uuin217g step1 shasp395 uwin217g ended -

-

-

jes2 job statistics

13 jun 91 job execution date 17 cards read 95 sysout print records 0 sysout punch records 5 SYSOUT SPOOL KBYTES 0.05 minutes execution time bottom of data

*******************************

Dem oben 1. 2.

********************************

abgebildeten JOB LOG können folgende Informationen entnommen werden:

Anfangs- und Endezeit Laufzeit (nicht CPU-Zeit)

3. Der verwendete Initiator 4. Job-Klasse 5. Nummer des Initiators 6. CPU-Zeit 7. Zahl der Ein- und

Ausgabe-Records

Die Abkürzung $HASP steht für Houston Automatic Spooling Program. Es wurde eigens für die NASA in den sechziger Jahren entwickelt. Es ist der Vorläufer des heutigen JES2.

77

JCL Die JCL

Hier ist die im Job benutzte JCL abgebildet. Sie unterscheidet sich nicht von der JCL, wie sie im Member der CNTL Bibliothek steht, da es keine symbolischen Parameter gab, die hätten aufgelöst werden können. BROWSE

*

JCL

COMMAND

1-- LINE

PAGE

SCROLL

===>

********************************

1 //UWIN217G JOB

2 3

4 5 6 7 8 9 10

1-- COLS

1

80

--

-

// // //CHKCAT //SYSPRINT //SYSIN //STEP1 //STEPLIB //SYSPRINT //SYSABOUT //SYSOUT //OUTFILE // // //

tqp op DATA

===>

SCREEN

**********************************

(998.ABTDG02),'M.WINTER1,CLASS=A, NOTIFY=UWIN,MSGCLASS=Y

TIME=(,10),MSGLEVEL=(1,1),USER=UWIN EXEC PGM=IDCAMS DD SYS0UT=*

DD

*

EXEC PGM=PGM01 DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DD SYSOUT=* DD SYS0UT=* DD SYSOUT=*

DD

DSN=UWIN.SCHULUNG.DS99.DISP=(,CATLG), RECFM=FB,

SPACE=(TRK,(5,1),RLSE), UNI T=DSKPRM

*******************************

BOTTOM OF DATA

********************************

Sollten Sie JCL-Fehler bei der Syntax-Prüfung erhalten haben, so sind die fehlerhaften Anweisungen numeriert. Die Numerierung entspricht der obigen Anzeige. Beachten Sie, daß unter Umständen der Fehler in der vorhergehenden oder folgenden JCL-Anweisung stecken kann. Die unter SYSIN gemachten Angaben können Sie hier nicht sehen. Sie finden sich unter dem SYSPRINT des Steps CHKCAT wieder. Die

Messages Die Messages geben wichtige Hinweise darauf, wie es Messages für jeden Step und einmal für den Job. Die Step Messages bestehen aus:

ein Job

gelaufen

ist. Grob gesagt

Allokationsmeldungen Step-Ende-Meldung mit Return-Code des Steps 3. Deallokationsmeldungen 4. Statistikmeldungen Im folgenden Beispiel wird zunächst auf die Messages für STEP1 Bezug genommen. 1.

2.

gibt

MVS/ESA JCL

78

IEF236I 1EF237I IEF237I IEF237I IEF237I IEF237I IEF142I IEF285I IEF285I IEF285I IEF285I IEF285I IEF285I IEF285I

ALLOC. FOR UWIN217G STEP1 6F0 ALLOCATED TO STEPLIB JES2 ALLOCATED TO SYSPRINT JES2 ALLOCATED TO SYSABOUT JES2 ALLOCATED TO SYSOUT 827 ALLOCATED TO OUTFILE STEP WAS EXECUTED

UWIN217G STEP1 -

-

UWIN.SCHULUNG.LOAD

COND CODE 0000 KEPT

VOL SER NOS= PRM013.

JES2.JOB05683.SO000103 JES2.JOB05683.SO000104 JES2.JOB05683.SO000105 UWIN.SCHULUNG.DS99 VOL SER NOS= PRM004.

SYSOUT SYSOUT SYSOUT CATALOGED

Jede Message beginnt mit einer Message Codes nachgesehen werden kann. So sind

Identification, die

im Handbuch:

IEF237I

6F0 ALLOCATED TO STEPLIB

IEF23 7I

82 7 ALLOCATED TO OUTFILE

Messages and

aus, daß das Dataset unter dem DD-Namen STEPLIB auf der physischen Adresse 6F0 (die UNIT-Adresse) gefunden wurde und für den Step zur Verfügung steht. Für das unter OUTFILE angesprochene Dataset wurde die UNIT mit der physischen Bezeichnung 827 (ebenfalls eine Platte) allokiert.

sogenannte Allokationsmeldungen. Sie sagen

Auf die Allokationsmeldungen folgt die mit einem Return Code von 0 endete.

Sie sagt aus, daß der

Stepl

STEP WAS EXECUTED COND CODE 0000 Auf die Step-Ende-Meldung folgen die Deallokationsmeldungen. Hier wird die Disposition wirksam, die Sie in Ihrer JCL angegeben haben. Da die Bibliothek UWIN.SCHULUNG.LOAD mit DISP=SHR angesprochen wurde und diese Disposition auf DISP=(SHR,KEEP,KEEP) ergänzt wird, ist die folgende Deallokationsmeldung verständlich. Sie sagt aus, daß das Dataset behalten wurde und auf der Platte mit der Bezeichnung PRM013 steht. IEF142I

UWIN217G

Step-Ende-Meldung.

STEP1

-

-

IEF285I

UWIN.SCHULUNG.LOAD

IEF285I

VOL SER NOS= PRM013.

KEPT

Deallokationsmeldung für das Dataset UWIN.SCHULUNG.DS99 lautet anders. Die in JCL-angegebene DISP=(,CATLG) wurde in DISP=(NEW,CATLG,CATLG) umgesetzt. Da das Katalogisieren erfolgreich war, wird dies entsprechend gemeldet: Die der

JCL_79 UWIN.SCHULUNG.DS99

IEF285I IEF2 85I

CATALOGED

VOL SER NOS= PRM004

Die Meldung sagt aus, daß das Dataset UWIN.SCHULUNG.DS99 auf dem Volume PRM004 angelegt wurde.

katalogisiert wurde und

Alle DD-Namen, die sich auf das Spool-Volume beziehen, werden JES2 zugeordnet. Sie werden auf SYSOUT gelegt. Dabei wird die MSGCLASS wirksam, die darüber entscheidet, ob der Output gleich gedruckt oder behalten wird. Die Statistiken bestehen aus zwei Teilen: Step-Statistik (für jeden Step) und Job-Statistik (1 mal). Achten sollte man besonders auf die verbrauchte CPU-Zeit. / START 91164.1043 / STOP 91164.1043 CPU

IEF373I STEP /STEP1 IEF374I STEP /STEP1

OMIN 00.05SEC SRB

OMIN 00.OOS

*********************************************** *.

.*

STEP STATISTICS

*************************************************** *

JOBNAME

*

*

CPU

STEPNAME END TIME

*

ELAPSED TIME

UWIN217G 10:43:57 1

*

STORAGE USED

392K

*

STORAGE REO

0

*

PAGES OUT

*

START TIME

*

STEP1 10:43:59 .05 OK 0

TIME -

*

PAGES IN

*

* * * *

***************************************************

6F0= IEF375I IEF376I

2

0

000=

000=

0

000=

/UWIN217G/ START 91164.1043 JOB /UWIN217G/ STOP 91164.1043 CPU

0

827=

3

JOB

OMIN 00.12SEC SRB

OMIN 00.OOS

*************************************************** *

LH-RECHENZENTRUM

*

FRAAD2

*************************************************** *

JOBNAME

*

START TIME

*

ELAPSED TIME

UWIN217G 10:43:56 3

*

DATE

*

END

TIME

*

CPU

TIME

06/13/91

*

10:43:59 .12

* *

-

*************************************************** *******************************

Es wurde bereits gesagt, daß die MESSAGES haben. Dies wird am

bottom OF DATA

********************************

Meldungen unter SYSPRJNT Vorrang Beispiel des Steps CHKCAT illustriert:

vor

denen unter

MVS/ESA JCL

80

chkcat

sysprint

browse

scroll

===>

********************************

idcams

1— cols

1-- line

page

1

80

--

-

command

===>

screen

**********************************

top of data

time: 10:43:56

system services

(uwin.schulung.ds99)

delete

idc0550i entry (a) uwin.schulung.ds99 deleted idc0001i function completed, highest condition code was 0

if maxcc

8 then set maxcc

=

=

0

idc0002i idcams processing complete. maximum condition code was 0 rottom of data ********************************

*******************************

um den SYSPRTNT des Programms. Aus ihm UWm.SCHULUNG.DS99 gelöscht wurde. Dies bedeutet: 1. Der Eintrag im User-Katalog wurde gelöscht und

Es handelt sich

geht hervor, daß der Eintrag

2. der Eintrag im VTOC der Platte wurde

Betrachtet

man

die

gewinnen: browse command

-

gelöscht. zugehörigen Messages, so könnte *

messages

--

page

man

einen ganz anderen Eindruck 1-- cols

1-- line

scroll

===>

********************************

1 80 screen

**********************************

top of data

ief285i

kept

uwin.schulung.ds99 vol ser nos= prm021. ief285i ief142i uwin217g chkcat step was executed -

===>

cond code 0000 -

Hier steht, daß das Dataset UWIN.SCHULUNG.DS99 behalten wird. Dies ist jedoch effektiv falsch. Wenn die Meldungen unter Messages und SYSPRINT einander widersprechen, so verlassen Sie sich auf die SYSPRINT-Meldungen.

Gefahren

von

Return Code

=

0

Endet ein Step mit dem Return Code 0, so denkt man, daß alles in Ordnung ist. In der Regel ist dem auch so, aber nicht unbedingt. Folgender Job wird zweimal hintereinander abgeschickt. Beachten Sie, daß dieser Job keinen Step CHKCAT hat, also der Katalog bei Job-Beginn nicht überprüft wird.

81

JCL edit-uwin schulung. cn tl (pgh01) command ===>

01.16

.

---.

scroll

*****************************

000001 000002 000003 000004 000005 000006 000007

//uwin217g

job

//

msgclass=y

//step1

exec pgm=pgm01

//steplib //outfile // //

dd

dsn=uwin.schulung.load,disp=shr

dd

dsn=uwin.schulung.ds99,disp=(,catlg),

Was

===>

page

*****************************

******

******

columns 001 072

-

top of data

(998,abtdg02),1m.winter1,class=a,notify=uwin,

recfm=fb,

unit=dskprm,space=(trk,(5,1),rlse)

****************************

bottom of data

***************************

folgt, ist der Output des zuletzt abgeschickten Jobs. Der Return Code von STEP1

.

ist 0!

iof job summary -

command

scroll ===> screen -dest.copies.

===>

--jobname---jobid--status---ran/received-day-10:49 6/13/91 today uwin217g j05711 output

fra21

1

-rc- -step.procstep- -proc.comments. -

0 step1 .ddname-step-stat-act-grp-cls * log HELD * jcl HELD messages * HELD SEL sysprint step1 DONE sysabout step1 DONE sysout DONE step1

Schaut man jedoch in die

RECORDS--DEST-

•forms-

COPIES -

13 12 36

Messages, so erlebt man eine Überraschung:

MVS/ESA JCL

82

*

MESSAGES

BROWSE

--

1-- LINE

PAGE

1-- COLS

1

80

-

COMMAND

SCROLL

===>

********************************

top OF DATA

===>

SCREEN

**********************************

ICH700011 UWIN LAST ACCESS AT 10:43:55 ON THURSDAY, JUNE 13, 1991 IEF236I ALLOC. FOR UWIN217G STEP1 IEF237I 6F0 ALLOCATED TO STEPLIB IEF237I JES2 ALLOCATED TO SYSPRINT IEF237I JES2 ALLOCATED TO SYSABOUT IEF237I JES2 ALLOCATED TO SYSOUT IEF237I 833 ALLOCATED TO OUTFILE COND CODE 0000 STEP WAS EXECUTED IEF142I UWIN217G STEP1 UWIN.SCHULUNG.LOAD KEPT IEF285I VOL SER NOS= PRM013. IEF285I SYSOUT JES2.JOB05711 .SO000101 IEF285I SYSOUT JES2.JOB05711.SO000102 IEF285I SYSOUT IEF285I JES2.JOB05711 .SO000103 NOT CATLGD 2 IEF287I UWIN.SCHULUNG.DS99 VOL SER NOS= PRM024. IEF287I IEF373I STEP /STEP1 / START 91164.1049 OMIN 00.05SEC SRB IEF374I STEP /STEP1 OMIN 00.OOS / STOP 91164.1049 CPU -

-

Deallokationsmeldung für UWIN.SCHULUNG.DS99 sagt aus, daß das Dataset nicht katalogisiert wurde. Es exisitiert daher nach wie vor der alte Katalogeintrag, der auf das Volume PRM004 verweist. In der obigen Meldung ist allerdings auch vom Volume Die

PRM024 die Rede.

passiert? Existiert der DSN im Katalog nicht und läuft der Job ohne CHKCAT, passiert beim ersten Mal nichts Besonderes. MVS wählt ein passendes Volume der Gruppe DSKPRM aus. Der DSN wird beim Beginn des Steps (Allokation) im VTOC dieses Volumes (PRM004) eingetragen, beim Step-Ende (Deallokation) erfolgt der Eintrag im Was ist nun

so

Katalog mit Verweis auf das Volume PRM004. Beim zweiten Joblauf sucht MVS wieder ein passendes Volume der Gruppe DSKPRM. Die Wahrscheinlichkeit, daß wieder PRM004 genommen wird, ist sehr gering. In diesem Fall

wählt MVS das Volume PRM024 aus und trägt den DSN im VTOC der Platte ein. Beim Step-Ende versucht MVS, das Dataset zu katalogisieren. Dabei kommt es zu einem Fehler, da der DSN bereits im Katalog eingetragen ist. Daher die Meldung NOT CATLGD 2. Im Return Code schlägt sich das allerdings nicht nieder. Was hier passiert ist, ist Code 16 verdient hätte. Wenn

die MESSAGES nicht überprüft, dann fällt dieser Fehler nicht auf. Die Folge Zugriff auf falsche Daten, der zu Anfang aller Wahrscheinlichkeit nach unbemerkt

man

wäre der

bliebe.

streng genommen ein katastrophaler Fehler, der den Return

Außerdem wurde ein Dataset angelegt, das so ohne weiteres nicht mehr auffindbar ist, denn für das auf dem Volume PRM024 angelegte Dataset gibt es keinen Hinweis im Katalog. Nur mit Hilfe der Volume-Nummer läßt sich dieses Dataset überhaupt noch ansprechen.

83

JCL

Sofern in Ihrer Installation File-AID installiert ist, können Sie mit Hilfe der Option F.3.7. (VTOC) die VTOCs durchsuchen lassen und die nicht katalogisierten Datasets wieder entfernen. Job-Management-Systeme wie BETA92 weisen einen NOT CATLGD 2 zwar im Job Summary aus, fahren aber u.U. mit der Verarbeitung fort. Sofern bei Ihnen SMS aktiv ist, kann es zu dem oben beschriebenen Problem nicht kommen. Der zweite Job würde bereits in der Allokationsphase abbrechen, da SMS bereits in dieser Phase versucht, zu katalogisieren. Kommt es dabei zu einem Fehler, weil das Dataset schon existiert, bricht der Job mit einem JCL Error ab.

2.4

Die DD-Anweisung für Datasets auf Bändern oder Kassetten

Bisher haben wir nur Datasets betrachtet, die auf einer Platteneinheit residieren. Die Verarbeitung von Bändern oder Kassetten hat jedoch einige Besonderheiten. Während sich beim Lesen von Datasets, die auf Band oder Kassette stehen, nur wenig ändert, kommt es beim Anlegen darauf an, welche Technik Sie verwenden. Es können dann eine ganze Reihe zusätzlicher Parameter erforderlich werden. Beachten Sie bitte, daß, wie bereits erwähnt, in den folgenden Abschnitten die Begriffe Band und Kassette synonym verwendet werden. Was die JCL angeht, so unterscheidet sie sich nicht, was Bänder und Kassetten betrifft.

Ansprechen von Datasets auf Band oder Kassette Beim

Ansprechen eines Datasets, das auf Band gespeichert ist, gelten im Prinzip die gleichen Regeln wie bei solchen, die auf Platte residieren, d.h. ist das Dataset katalogisiert, so genügt die Angabe des DSN- und des DISP-Parameters.

//EINGABE

DD DSN=TJWIN.

CASSDAT1, DISP=OLD

Bei Band- bzw Kassettendatasets können Sie bedenkenlos DISP=OLD angeben, da dieser Datenträger ohnehin nicht gleichzeitig von anderen Usern angesprochen werden kann. Alle notwendigen Informationen wie UNIT (TAPE oder CASS), Nummer der Kassette sowie Position des Dataset auf der Kassette werden dem Katalogeintrag entnommen. Wenn Sie in einem Step mehrere Datasets, die auf Band oder Kassette liegen, ansprechen, so versucht MVS, Ihnen so viele Lese-Schreibstationen zur Verfügung zu stellen, wie sie Datasets allokieren.

//EINGABE1 //EINGABE2 //EINGABE3 //EINGABE4

DSN=UWIN.CASSDATl,DISP=OLD DSN=UWIN.CASSDAT2,DISP=OLD DD DSN=UWIN.CASSDAT3,DISP=OLD DD DSN=UWIN.CASSDAT4,DISP=OLD DD DD

MVS/ESA JCL

84

Für jeden DD-Namen, der auf ein auf Band oder Kassette liegendes Dataset verweist, wird pro Step eine Lese-Schreibstation benötigt und allokiert. Im obigen Beispiel wären dies 4. Die Zahl der zur Verfügung stehenden Lese-Schreibstationen ist jedoch begrenzt. Unter

Umständen kann es daher schon bei der Allokation zu Problemen kommen. Wenn mehr als ein Band- bzw. Kassettendataset pro Step verarbeitet werden soll, sollte man immer von der Möglichkeit Gebrauch machen, die Zahl der zu allokierenden Lese-Schreibstationen so gering wie möglich zu halten. Dies können Sie mit dem Parameter UNIT=AFF=ddname

tun.

Der Parameter UNIT=AFF

Syntax:

UNIT=AFF=ddname Wenn in einem

Step

Bänder nacheinander

gelesen werden,

so

läßt sich die Zahl der Lese-

Schreibstationen, die allokiert werden, durch die Benutzung des AFF-Subparameters

vermindern. Mit UNIT=AFF=ddname wird auf eine andere DD-Anweisung im gleichen Step verwiesen. Dadurch wird bewirkt, daß die gleiche Lese-Schreibstation mehrmals hintereinander verwendet wird. Ein Beispiel soll dies illustrieren:

//EINGABE1 //EINGABE2 // //EINGABE3 // //EINGABE4 //

DD DD

DSN=UWIN.CASSDAT1,DISP=OLD DSN=UWIN.CASSDAT2,DISP=OLD,

UNIT=AFF=EINGABE1 DD DSN=UWIN.CASSDAT3,DISP=OLD, UNIT=AFF=EINGABE1 DD DSN=UWIN.CASSDAT4,DISP=OLD,

UNIT=AFF=EINGABE1

Im Gegensatz zum ersten Beispiel wird jetzt nur eine Lese-Schreibstation belegt. Funktionieren wird das Ganze aber nur, wenn das Anwendungsprogramm das unter EINGABE 1 angesprochene Dataset schließt, bevor das unter EINGABE2 angesprochene Dataset geöffnet wird. Das Problem mit der Belegung vieler Lese-Schreibstationen tritt auch dann auf, wenn mehrere physische Datasets verkettet werden:

//EINGABE1 // // //

DD DD

DD DD

DSN=UWIN.CASSDAT1,DISP=OLD DSN=UWIN.CASSDAT2,DISP=OLD DSN=UWIN.CASSDAT3,DISP=OLD DSN=UWIN.CASSDAT4,DISP=OLD

JCL

85

Auch in diesem Fall werden 4 Lese-Schreibstationen angefordert. Die Lösung des Problems

geschieht analog zum ersten Beispiel:

//EINGABE1 // // // // // //

DD DD

DSN=UWIN.CASSDAT1,DISP=OLD DSN=TJWIN.CASSDAT2,DISP=0LD,

UNIT=AFF=EINGABE1 DD

DSN=UWIN.CASSDAT3,DISP=OLD,

UNIT=AFF=EINGABE1 DD

DSN=UWIN.CASSDAT4,DISP=OLD,

UNIT=AFF=EINGABE1

Bei einer Verkettung kann es nicht zu dem oben beschriebenen OPEN/CLOSE Problem kommen. Gleiches gilt bei der Benutzung eines IDCAMS REPRO.

Schreiben

von

Datasets auf Band oder Kassette

Wenn Sie Datasets auf Band oder Kassette anlegen wollen, haben Sie die Wahl zwischen drei grundsätzlichen Möglichkeiten: 1. Ein Dataset auf ein Band/eine Kassette schreiben.

Dies ist die am häufigsten genutzte Form der Speicherung. Da aber die Datasets, die auf Band gespeichert werden, meist klein sind (gemessen an der Speicherkapazität eines Bandes bzw. einer Kassette) und nur einen Bruchteil des Bandes einnehmen, kann dies zu einer Verschwendung von Bändern fuhren. Der Vorteil

ist, daß diese Datasets später mit DISP=MOD erweitert werden können.

2. Viele Datasets auf ein Band/eine Kassette schreiben.

Diese Technik wird auch Multi-File-Technik genannt. Dies ist eine effektive Form der Speicherung, weil sie die vorhandenen Ressourcen optimal nutzt. Probleme beim Ansprechen der Datasets entstehen dann nicht, wenn jedes auf dem Band befindliche Dataset katalogisiert wird. Diese Form der Speicherung empfiehlt sich besonders für Sicherungen. Bedenken Sie jedoch, daß Ihre Datasets ohnehin vom HSM gesichert werden. Nachteil dieser Technik: Die mehr verändert werden.

so

geschriebenen

Datasets können in ihrer Größe nicht

3. Ein Dataset auf viele Bänder/Kassetten schreiben.

Sehr große Datasets können unter Umständen mehrere Bänder benötigen. In diesem Fall

erzeugt MVS ein 'Multi-Volume Dataset' (MVD). Sofern nicht mehr als fünf Bänder

benötigt werden, überschritten,

erfolgen.

so

sind keine besonderen muß eine Angabe der

Angaben erforderlich. Wird diese geschätzten Anzahl der benötigten

Grenze Bänder

86

MVS/ESA JCL

Ein Dataset auf Band oder Kassette schreiben Wenn ein Dataset auf Band/Kassette geschrieben werden soll, so ist dies syntaktisch am leichtesten. Sie brauchen nur mit dem UNIT-Parameter mitteilen, daß Sie auf Band/Kassette schreiben wollen und Sie müssen eine Schutzfrist angeben.

gesehen

In den meisten MVS-Installationen sind die und UNIT=TAPE für Bänder generiert.

Gruppennamen

UNIT=CASS für Kassetten

EXPDT

Syntax:

EXPDT=yyddd

oder yyyy/ddd

Wenn Sie Datasets auf Band- bzw. Kassetten schreiben wollen, so wird Ihnen dazu eine Kassette aus einem Pool freier oder leerer Kassetten zur Verfügung gestellt. Diese Kassetten heißen Scratch-Kassetten. Es handelt sich dabei entweder um ganz neue Kassetten, die frisch initialisiert wurden, oder um Kassetten, deren Schutzfrist abgelaufen ist und die daher wieder zur allgemeinen Verfügung stehen. Um nun zu verhindern, daß Ihr Dataset vorzeitig überschrieben wird, müssen Sie eine Schutzfrist angeben. Sie können dabei ein bestimmtes Datum angeben oder den Schutz der Kassette an den Katalogeintrag der auf der Kassetten befindlichen Datasets koppeln. Beides geht mit dem EXPDT-Parameter. Bei der Benutzung des EXPDT-Parameters erfolgt die Angabe eines Auslaufdatums in der Form: yyddd oder yyyy/ddd. Soll die Kassette nicht vor dem 31.12.1992 überschrieben werden, so ist

//

EXPDT=92365

anzugeben. Für die Zeit ab dem Jahr 2000 ist die Angaben in folgender Form erfolgen:

//

Syntax bereits erweitert

EXPDT=200l/365

Wenn Sie den Schutz der Kassette an den mit einer besonderen Wertzuweisung:

//

worden. Es können dann

Katalogeintrag koppeln wollen,

so

geschieht dies

EXPDT=99000

Die Kassette ist dann

entkatalogisieren.

solange geschützt,

Wird weder EXPDT oder RETPD

Tag überschrieben werden.

bis Sie die darauf befindlichen Datasets

angegeben,

so

kann die Kassette bereits

am

folgenden

87

JCL Eine besondere

Bedeutung hat auch

die

Wertzuweisung EXPDT=98000. Sofern eine Tape

Management Utility installiert ist, bewirkt diese Angabe, daß dort keine Einträge gemacht werden. Dies hat Bedeutung im Zusammenhang mit Exportbändern. In

vorhandener

JCL

LABEL=EXPDT=yyddd.

finden Sie womöglich Sie ist gleichwertig.

noch

die

alte

Syntaxvariante

RETPD

Syntax:

RETPD=nnnn Im Gegensatz zu EXPDT, das ein Datum angibt, wird mit RETPD ein Zeitraum während dem die Kassette nicht überschrieben werden darf. Soll eine Kassette nicht vor Ablauf von 30 Tagen überschrieben werden, so ist:

//

angegeben,

RETPD=30

anzugeben. Eine Möglichkeit RETPD nicht.

der

Kopplung

mit dem

Katalogeintrag

In vorhandener JCL finden Sie womöglich LABEL=RETPD=nnnn. Sie ist gleichwertig.

noch

wie bei EXPDT die

alte

gibt

es

bei

Syntaxvariante

Beispiel für ein Anlegen eines Datasets auf einer Kassette Das folgende Beispiel zeigt ein Anlegen eines Datasets auf einer Kassette. Wie Sie sehen, unterscheidet sich die JCL nur geringfügig von der, die Sie beim Anlegen von Datasets auf Platte verwenden. Bei UNIT muß ein anderer Gruppenname angegeben werden, der Parameter SPACE fällt ganz weg, dafür müssen Sie einen der Parameter EXPDT oder RETPD verwenden.

Wenn Sie verfahren, wie hier gezeigt, dann sollten Sie sicherstellen, daß der Platz, den die Kassette bietet, gut ausgenutzt wird. Es macht keinen Sinn, ein Dataset mit 5 MB auf eine Kassette mit 250 MB Speicherkapazität zu speichern.

MVS/ESA JCL

88

edit-uwin.schulung.cntl(pgmoi)

01.16 -

command

.

===>

******

*****************************

000001 000002 000003 000004

//uwin217g

job

// // //

msgclass=y, time=(,10),

000005 000006 000007 000008 000009 000010 000011 000012 000013 000014

//* //step1

******

****************************

//steplib //sysprint //sysabout //sysout //outfile // // //

fop of data

columns 001 072 scroll ===> page

*****************************

(998,abtdg02),1m.winter1,class=t,not ify=uwin,

msglevel=(1,1) msglevel=(1,1),typrun=scan exec pgm=pgm01 dd

dsn=uwin.schulung.load,disp=shr

dd sysout=* dd sysout=* dd sysout=* dd dsn=uwin.cassdat1,disp=(new,catlg,delete),

recfm=fb, expdt=99000, unit=cass bottom of data

***************************

Einen SPACE-Parameter brauchen Sie bei Band- bzw. Kassettendatasets nicht angeben.

Meldungen sind ähnlich wie beim Anlegen auf Platte. An der Tatsache, daß bei der Deallokationsmeldung VOL SER NOS 717922 eine rein numerische Angabe erfolgt, kann man erkennen, daß es sich beim Datenträger um ein Band oder eine Kassette handelt. Die

=

ief236i alloc for uwin217g step1 ief237i 0d8 allocated to outfile step was executed ief142i uwin217g step1 ief287i uwin.cassdat1 vol ser nos= 717922. ief287i -

Wenn Sie diesen Job Fehler!

so

Arbeiten mit dem

-

cond code 0000 cataloged

ein zweites Mal abschicken, kommt es

zu

einem NOT CATLGD 2-

Katalog bei Bändern/Kassetten

Auch wenn Sie Datasets auf Band/Kassette anlegen, sollten Sie darauf nicht katalogisierten Datasets angelegt werden.

achten, daß keine

Ähnlich wie beim VTOC haben auch Bänder/Kassetten Kontrolleinträge. Diese können

jedoch von Ihnen nicht gelöscht werden. Da es ohnehin nicht möglich ist, den Eintrag auf dem Band zu löschen, reicht das Löschen des

Katalogeintrags

aus.

Dies wurde früher beim IDCAMS DELETE mit dem

Zusatzparameter NOSCRATCH erreicht. Verwenden Sie diesen Zusatzparameter

nicht mehr! IDCAMS Band/Kassettendatasets automatisch und setzt NOSCRATCH von sich aus.

erkennt

89

JCL EDIT-UWIN.SCHULUNG.CNTL(PGM01)

01.16

.

-

COMMAND ******

===>

*****************************

TOP OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

000001 //UUIN217G JOB (998,ABTDG02),1M.WINTER 1, 000002 // CLASS=T, 000003 // MSGCLASS=Y, 000004 // TIME=(,10), 000005 // MSGLEVEL=(1,1), NOTIFY=UUIN 000006 // EXEC PGM=IDCAMS 000007 //UNCAT 000008 //SYSPRINT DD SYSOUT=* DD * 000009 //SYSIN DELETE UWIN.CASSDAT1 000010 000011 IF MAXCC = 8 THEN SET MAXCC = 0 000012 000013 000014 000015

/* //STEP1 //STEPLIB //SYSPRINT //SYSABOUT //SYSDBOUT //SYSOUT //OUTFILE

000016 000017 000018 000019 000020 // 000021 // 000022 // 000023 // ******

EXEC PGM=PGM01 DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DD SYSOUT=* DD SYSOUT=* DD SYSOUT=* DD SYSOUT=* DD DSN=UWIN.CASSDAT1,

DISP=(NEW,CATLG,DELETE), RECFM=FB, EXPDT=99000, UNIT=CASS

****************************

BOTTOM OF DATA

***************************

vorhergehende Beispiel ist um einen IDCAMS Step ergänzt worden. Auch ohne die Benutzung des NOSCRATCH-Parameters wird das überflüssige Einlegen der Kassette Das

verhindert. Dies führt zu einer erheblichen

Zeitersparnis.

90

MVS/ESA JCL

Der SYSPRINT für den BROWSE

Step UNCAT hat folgendes Aussehen:

SYSPRINT

UNCAT

-

COMMAND

********************************

IDCAMS

PAGE

1-- LINE

--

===>

TOP OF DATA

1-- COLS 1 80 SCROLL ===> SCREEN

**********************************

SYSTEM SERVICES

TIME: 10:43:56

DELETE UWIN.CASSDAT1

IDC0550I ENTRY (A) UWIN.CASSDAT1 DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 IF MAXCC

=

8 THEN SET MAXCC

=

0

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 BOTTOM OF DATA ********************************

*******************************

Die Meldung sagt aus, daß der Katalogeintrag für UwTN.CASSDATl gelöscht wurde. Der wirksam gewordene Parameter NOSCRATCH ist nicht zu sehen. Da das Dataset auf der Kassette mit EXPDT=99000 angelegt wurde, ist durch das Entkatalogisieren des Datasets auch die Kassette wieder freigegeben worden. Sie ist wieder zu einer Scratch-Kassette geworden. Wenn beim Anlegen eines Dataset nicht mit EXPDT=99000 gearbeitet wurde, dann bleibt die Kassette solange gesperrt, bis die Frist, die durch die Angaben des EXPDT- oder RETPD-Parameters gesetzt wurde, abgelaufen ist. Dies gilt auch dann, wenn das auf der Kassette befindliche Dataset mit IDCAMS entkatalogisiert wurde. Die Schutzfrist bezieht sich immer auf die physische Kassette, nicht auf das Dataset. Sie sich, ob in Ihrem Unternehmen eine Tape Management Utility installiert ist. Unter Umständen kann sie dazu verwendet werden, Bänder oder Kassetten, deren

Erkundigen

Schutzfrist noch nicht abgelaufen

ist, wieder freizugeben.

Mehrere Datasets hintereinander auf Band oder Kassette schreiben Es gibt viele Gründe, die dafür sprechen, Datasets hintereinander auf Band/Kassette zu schreiben. Zum einen können dadurch viele Kassetten eingespart werden, zum anderen gibt es Verarbeitungsformen, wo die Datasets ohnehin nicht mehr erweitert werden müssen. Ein typischer Fall sind Datasets, die tagsüber on-Line und nachts im Batch verarbeitet werden. Vor dem Beginn der Batch-Verarbeitung sichert man die Datasets, damit für den Notfall ein Zurückladen erfolgen kann. Für diese Sicherung bietet sich Band/Kassette als

Datenträger an.

JCL

91

Wenn Sie die Datasets hintereinander anordnen wollen, so müssen Sie folgende Probleme lösen: 1. Sie müssen MVS mitteilen, wenn Sie auf eine andere als die erste Position schreiben wollen. Dies geschieht mit dem LABEL-Parameter. 2. Sie müssen MVS dazu bringen, die gleiche Kassette weiter zu verwenden. Dies erreichen Sie mit einer Angabe im VOL-Parameter. 3. Sie sollten ein vorzeitiges Zurückspulen der Kassette verhindern. Auch dies können Sie mit dem VOL-Parameter erreichen. 4. Sofern insgesamt mehr als 5 Kassetten beim Hintereinanderschreiben so ist dies ebenfalls mit dem VOL-Parameter mitzuteilen.

benötigt werden,

LABEL

Syntax:

LABEL=Dataset-Position Der Default-Wert ist:

LABEL=1 Mit dem LABEL-Parameter wird MVS mitgeteilt, welche Position auf der Kassette ein bestimmtes Dataset einnehmen soll. Diese Angabe ist nur dann notwendig, wenn auf eine andere als die erste Position geschrieben werden soll.

Sie können mit LABEL= aufsteigend durchnumerieren. Dabei oder mehrere Kassetten eingesetzt werden. VOLUME für

spielt es keine Rolle, ob eine

Bandverarbeitung

Syntax:

VOL=([PRIVATE][,RETAIN][,Volume-Sequenz][,Volume-Anzahl] [,SER=(vol-ser-no,vol-ser-no,...)]) [,REF=*.ddname]) [,REF=*.stepname.ddname]) [,REF=*. stepname. procstepname.ddname])

Wie Sie sehen, ist der VOLUME-Parameter recht kompliziert aufgebaut. Er besteht aus vier positioneilen und zwei Schlüsselwort-Subparametern. Alle Subparameter außer SER und REF sind positioneil.

MVS/ESA JCL

92

Der PRIVATE-Subparameter

Die Angabe von PRIVATE sollte heutzutage unterbleiben. Sie hatte früher Bedeutung als Schutz gegen unerwünschtes Lesen. Da der PRIVATE-Subparameter positioneil ist, muß seine Abwesenheit durch ein Komma gekennzeichnet werden. Die Angabe von PRIVATE bewirkt, daß ein weiterer Output auf dieses Band nur dann geschrieben werden darf, wenn ein 'Specific Volume Request' gemacht wird. Dies bedeutet, daß die Angabe der Vol-Ser-No erfolgen muß, obwohl das Dataset katalogisiert ist. Im Endeffekt handelt es sich also nur um eine weitere Sicherungsmaßnahme, die das unabsichtliche Überschreiben von Daten verhindern soll. Diese

Vorgehensweise ist nicht zu empfehlen.

Der RETAIN-Subparameter

Während die Anwendung des PRIVATE-Subparameters wenig bringt, ist die Anwendung des RETAIN-Subparameters sehr sinnvoll, da sie den Operator von überflüssiger Arbeit entlastet. RETAIN bewirkt, daß am Ende eines Steps das Band/die Kassette nicht zurückgespult wird. Wird im folgenden Step die gleiche Kassette benötigt, so steht sie sofort zur Verfügung. Dies bringt neben einer nicht unbedeutenden Zeitersparnis auch eine Entlastung für den Operator.

//

VOL=(,RETAIN)

Durch diese

Angabe wird das vorzeitige Zurückspulen unterbunden.

Der Volume-Sequenz-Subparameter

Der Volume-Sequenz-Subparameter hat nur eine geringe Bedeutung im Zusammenhang mit 'Multi-Volume Datasets (MVD)', d.h. Datasets, die mehr als ein Band beanspruchen. Wird bei Volume-Sequenz eine Zahl angegeben, so wird nicht das erste, sondern das mit der Zahl versehene Band angefordert. Wir werden diesen Subparameter hier nicht weiter betrachten. Der Volume-Anzahl-Subparameter

Mit Hilfe des Volume Anzahl-Subparameters kann man MVS mitteilen, wieviele Kassetten/Bänder ein Dataset voraussichtlich benötigt. Der Default-Wert ist 5. Wenn man also mehr Kassetten/Bänder benötigt, muß eine Angabe im Volume-Anzahl-Subparameter erfolgen. Die Angaben werden von MVS nach folgendem Schema aufgerundet:

93

JCL

Angabe

von

MVS angenommener Wert

keine 1 -5

6-20

20

>20

Mehrfaches

von

15

+

5, also 35, 50, 65 usw. bis maximal 255

Beispiel:

VOL=(,,,8)

//

Dadurch werden maximal 20 Kassetten angefordert. Die ersten drei Kommata stehen für die nicht kodierten positioneilen Parameter. Der

SER-Subparameter

SER ist ein Schlüsselwort-Subparameter in der VOLUME Anweisung. Mit ihm kann eine ganz bestimmte Kassette angefordert werden. Eine solche explizite VOLUME Angabe ist im Normalfall nicht notwendig. Ausnahme sind nicht katalogisierte Datasets, die auf Band oder Kassette stehen. Der

REF-Subparameter Der REF-Subparameter wird benötigt, wenn mehrere Datasets auf eine Kassette hintereinander geschrieben werden sollen. Mit Hilfe eines Rückbezugs (referback) wird MVS angewiesen, die vol-ser-no des vorhergehenden Datasets zu benutzen. Dadurch wird die gleiche Kassette weiterbenutzt. Außerdem wird die Übernahme der UNIT-Angabe bewirkt. Dort, wo VOL=REF eingesetzt wird, brauchen Sie also UNIT nicht mehr anzugeben. Je nachdem, ob dieses Dataset im gleichen oder einem vorhergehenden Step angesprochen wurde, unterscheidet sich die Syntax:

// wenn

// wenn

// wenn

VOL=REF=*.ddname beide Datasets im

gleichen Step angesprochen werden bzw.

VOL=REF=*.stepname.ddname auf einen vorhergehenden

Step Bezug genommen wird.

VOL=REF=*.stepname.procstepname.ddname auf einen vorhergehenden

Step in einer Prozedur Bezug genommen wird.

MVS/ESA JCL

94

gleichzeitig ein Zurückspulen der Kassette verhindert werden, Subparameter mit anzugeben: VOL=(,RETAIN,REF=*.ddname) // Soll

so

ist der RETAIN-

oder

//

VOL=(,RETAIN,REF=*.stepname.ddname)

oder

// //

VOL=(,RETAIN,

REF=*.stepname.procstepname.ddname)

Machen Sie Rückbezüge mit VOL=REF immer auf den unmittelbar vorhergehenden Step oder das unmittelbar vorhergehende Dataset. Lassen Sie niemals alle Rückbezüge auf den ersten Step des Jobs verweisen. Sonst bekommen Sie Probleme, wenn mehr als eine Kassette beschrieben wird.

Beispiele für Multi-File Technik Im folgenden Beispiel werden drei Datasets in drei Steps hintereinander weggeschrieben: 000001 //UWIN217X JOB (998,ABTDG02),'M.WINTER1, 000002 // CLASS=T,MSGCLASS=Y 000003 //CLRCAT EXEC PGM=IDCAHS 000004 //SYSPRINT DD SYS0UT=* DD * 000005 //SYSIN DELETE UWIN.CASSDAT1 000006 DELETE UWIN.CASSDAT2 000007 DELETE UWIN.CASSDAT3 000008

Das

Beispiel wird auf der folgenden Seite fortgesetzt.

95

JCL 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020

//STEP1

EXEC PGM=PGH05

//STEPLIB //SYSOUT //SYSDBOUT //SYSABOUT //OUTFILE // // // // //

DD

//STEP2

000021 //STEPLIB 000022 //SYSOUT

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

DD SYSOUT=*

DD SYSOUT=* DD SYSOUT=*

DSN=UWIN.CASSDAT1, DISP=(,CATLG,DELETE), UNIT=CASSA, VOL=(,RETAIN), DD

RECFM=FB, EXPDT=99000 EXEC PGM=PGM06 DD

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

DD SYSOUT=*

000023 //SYSDBOUT DD SYSOUT=* 000024 //SYSABOUT DD SYSOUT=* 000025 //OUTFILE DD DSN=UUIN.CASSDAT2, 000026 // DISP=(,CATLG,DELETE), 000027 // VOL=(,RETAIN,REF=*.STEP1.OUTFILE), 000028 // RECFM=VB, 000029 // LABEL=2,EXPDT=99000 EXEC PGM=PGM07 000030 //STEP3 000031 //STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DD SYS0UT=* 000032 //SYSOUT 000033 //SYSDBOUT DD SYSOUT=* 000034 //SYSABOUT DD SYSOUT=* 000035 //OUTFILE DD DSN=UWIN.CASSDAT3, 000036 // DISP=(,CATLG,DELETE), 000037 // V0L=REF=*.STEP2.0UTFILE, 000038 // RECFM=FB, 000039 //_LABEL=3,EXPDT=99000_

LABEL= muß in STEP2 und STEP3 eingesetzt werden, da nicht mehr auf die erste Position geschrieben werden kann. Die Rückbezüge im Parameter VOL=REF verweisen immer auf den unmittelbar vorhergehenden Step. Dies ist für den Fall wichtig, daß mehrere Kassetten für die Aufnahme des Datenbestandes erforderlich sind.

Beachten Sie, daß in STEP3 RETAIN weggelassen wurde. Es gibt keinen vernünftigen Grund, das Zurückspulen zu verzögern. Durch den Wegfall von RETAIN vereinfacht sich die Schreibweise des VOL-Parameters erheblich.

MVS/ESA JCL

96 Im

folgenden Beispiel werden drei Datasets in einem Step gesichert. Kopieren verwendet. IDCAMS benötigt die LRECL-Angabe!

Dazu wird IDCAMS

zum

edit command

uwin.schulung.cntl(cass)

01.00

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019

//uwin217x

job

// // //* // //clrcat //sysprint //sysin

class=t, msgclass=y, notify=uwin,typrun=scan

fop of data

(998,abtdg02),'h.winter',

notify=uwin exec pgh=idcams dd sysout=*

dd

*

delete

uwin.ksds.save

delete

uwin.esds.save

delete

uwin.rrds.save

exec pgh=idcams //save dd sys0ut=* //sysprint dd dsn=uwin.ksds,disp=shr //ini

//in2 //in3 //out1

// // 000020 // 000021 // 000022 // 000023 //out2 000024 // 000025 // 000026 // 000027 // 000028 //

Das

.

-

===>

dsn=uwin.esds,disp=shr dsn=uwin.rrds,disp=shr dd dsn=uwin.ksds.save, disp=(,catlg,delete), unit=cass, vol=(,retain), dd

dd

recfm=fb,lrecl=94, expdt=99000

dsn=uwin.ksds.save, disp=(,catlg,delete), dd

vol=(,retain,ref=*.out1), label=2, recfm=fb,lrecl=278, expdt=99000

Beispiel wird fortgesetzt:

columns 001 072 scroll ===> page

*****************************

97

JCL

000029 000030 000031 000032 000033 000034 000035 000036 000037 000038

Ein

//OUT3

DSN=UWIN.KSDS.SAVE, DISP=(,CATLG,DELETE) V0L=REF=*.0UT2, LABEL=3, DD

// // // // // //SYSIN REPRO

,

RECFM=FB,LRECL=85, EXPDT=99000 *

DD

INFILE(IN1) OUTFILE(0UT1)

REPRO INFILEUN2) OUTFILE(OUT2) REPRO INFILE(IN3) OUTFILE(OUT3)

großes Dataset auf mehrere Kassetten schreiben

Beim ersten Schreiben eines großen Datasets auf Band/Kassette ist nur darauf zu achten, ob möglicherweise mehr als 5 Kassetten benötigt werden. In diesem Fall ist der Subparameter Volume-Anzahl-einzusetzen. Datasets, die mehr als eine Kassette einnehmen, werden als Multi-Volume Datasets (MVD) bezeichnet. 000001 //UWIN217X 000002 // 000003 //CLRCAT 000004 //SYSPRINT

000005 000006 000007 000008 000009 000010 000011 000012 000013 000014

//SYSIN DELETE

//STEP1 //STEPLIB //OUTFILE // // // // //

Wieviele Kassetten IEF287I IEF287I

JOB

(998,ABTDG02),'M.WINTER',

CLASS=T,MSGCLASS=Y EXEC PGM=IDCAMS

DD SYSOUT=* DD * UWIN.BIGFILE EXEC PGM=PGM91

DSN=UUIN.SCHULUNG.LOAD,DISP=SHR DSN=UWIN.BIGFILE, DISP=(,CATLG,DELETE), UNIT=CASS, DD

DD

V0L=(,,,20), RECFM=FB, EXPDT=99000

eingesetzt wurden geht aus der Deallokationsmeldung hervor.

UWIN.BIGFILE VOL SER NQS=

Für das Dataset wurden

CATALOGED

717922, 717923, 633998, 722556, 766221, 433221.

insgesamt sechs Kassetten benötigt.

98

MVS/ESA JCL

Besonderheiten bei Band- bzw.

Kassettenverarbeitung

Bei der Verarbeitung von Bändern/Kassetten können eine Reihe von Optimierungsmöglichkeiten genutzt werden. Dies betrifft vor allem MVDs (Multi-Volume Datasets). Daneben gibt es Fälle, in denen Bänder verarbeitet werden müssen, die nicht den IBM-Standardkonventionen entsprechen. Gelegentlich müssen auch Bänder verarbeitet werden, die ASCII Daten enthalten. Auf solche Sonderfälle und die dafür notwendigen Parameter wird jetzt eingegangen. MVDs lesen oder mit DISP=MOD erweitern Soll ein MVD gelesen werden, so kann es sinnvoll sein, eine zweite Lese-Schreibstation anzufordern. Dies bringt eine Zeitersparnis, wenn das Ende der ersten Kassette erreicht wird. In diesem Fall wird die zweite Kassette in eine zweite Lese-Schreibstation eingelegt, bevor das Ende der ersten Kassette erreicht ist. Sollen MVDs mit DISP=MOD erweitert werden, so kann es zu einer vermeidbaren kommen. Sie ist dadurch bedingt, daß der Operator beim Ansprechen des Datasets immer eine 'Mount Message' für die erste Kassette bekommt, d.h. er wird aufgefordert, die erste Kassette in eine Lese-Schreibstation einzulegen. Der neue Datenbestand muß aber ans Ende der letzten Kassette angehängt werden. Erst beim OPEN wird festgestellt, welches die letzte Kassettennummer ist. Mit dem UNIT-Parameter läßt sich diese Verzögerung beseitigen.

Verzögerung

UNIT=(„DEFER) Syntax:

UNIT=(Unit[,Anzahl][,DEFER]) Der

unit-Subparameter Diesen Subparameter kennen Sie bereits, normalerweise in der Form UNIT=gruppenname. Der

Anzahl-Subparameter Anzahl-Subparameter kann

Mit dem

man für ein Dataset mehrere Lese-Schreibstationen anfordern. Dies ist nur bei Multi-Volume Datasets sinnvoll. Fordern Sie niemals mehr als 2 Lese-Schreibstationen an. Dies ist nicht nur sinnlos, sondern führt auch zu einer unnötigen Belegung von Lese-Schreibstationen. Auch für den Fall, daß es sich bei Ihrem Dataset um ein Multi-Volume Dataset handelt (d.h. das Dataset benötigt mehr als ein Band/eine Kassette), reichen zwei LeseSchreibstationen völlig aus. Wird eine Kassette auf der Lese-Schreibstation 1 bearbeitet, so hat der Operator Zeit, die andere Kassette auf der Lese-Schreibstation 2 zu wechseln.

99

JCL Der

DEFER-Subparameter

Wird in einem Job eine Kassette benötigt, so erhält der Operator zur Allokationszeit eine 'Mount Message', d.h. die Aufforderung, entweder eine Scratch-Kassette einzulegen (beim Anlegen von Datasets) oder eine bestimmte Kassette einzulegen (beim Lesen von

Datasets). Bei der Erweiterung eines MVDs mit DISP=MOD erhält der Operator zunächst die Aufforderung, die erste Kassette einzulegen. Mit der Angabe TJNIT=(„DEFER) wird aber diese Meldung solange verzögert, bis ein OPEN dann auch die richtige Kassette angefordert.

//OUTFILE //

DD

abgesetzt wird.

In diesem Moment wird

DSN=UWIN.BIGFILE,DISP=MOD,

UNIT=(,,DEFER)

Der Einsatz von UNIT=(„DEFER) ist nur dann sinnvoll, MVD handelt. Ansonsten fuhrt es zu unnützer Verzögerung.

wenn es

sich wirklich im ein

Ein weiterer Fall, bei dem UNIT=(„DEFER) eingesetzt werden kann, ist gegeben, wenn nicht sicher ist, ob ein auf der Kassette liegendes Dataset tatsächlich geöffnet wird. Diese Angabe ist nur dann sinnvoll, wenn zu erwarten ist, daß die Kassette tatsächlich nicht benötigt wird. Ansonsten führt es nur zu unnützer Verzögerung, da der Operator, wenn er erst zur Open-Zeit die Mount Message erhält, keine Möglichkeit hat, den 'wait state' des Programms zu verhindern. Zu beachten ist, daß bei der Benutzung von DEFER die Lese-Schreibstation belegt wird, und zwar unabhängig davon, ob es zu einem OPEN kommt oder nicht. Nicht

katalogisierte Datasets von Bändern/Kassetten lesen Im Zusammenhang mit Bändern/Kassetten werden häufig nicht katalogisierte Datasets eingesetzt. Beim Lesen nicht katalogisierter Datasets ist die zusätzliche Angabe von UNIT,

VOL=SER und evtl. LABEL erforderlich. Problematisch ist die Verwaltung nicht katalogisierter Datasets. In einigen Installationen sind Tape Management Systeme installiert (z.B CA1), um den Zugriff auf nicht mehr katalogisierte Datenbestände zu ermöglichen.

Will man ein nicht katalogisiertes Dataset auf Kassette ansprechen, so muß man die Kassettennummer wissen und unter Umständen auch die Position des Dataset auf der Kassette, falls es nicht auf Position 1 steht. Außerdem muß der DSN korrekt angegeben werden.

Beispiel:

//EINGABE //

DSN=UWIN.TEST.UNCAT,DISP=OLD, UNIT=CASS,VOL=SER=778201,LABEL=2 DD

Sollte einer der Parameter DSN, VOL=SER oder LABEL falsch einem 813-04 ABEND.

es zu

angegeben sein, so kommt

100

MVS/ESA JCL

Bänder exportieren

werden Bänder aus einer Installation heraus verschickt. Die darauf befindlichen Datasets sollten nicht katalogisiert werden, da ansonsten Katalogeinträge für nicht verfügbare Bänder existieren.

Häufig

Sofern eine Tape Management Utility installiert ist, sollte darauf geachtet werden, daß auch dort bei Exportbändern keinerlei Einträge gemacht werden. Dies läßt sich mit der Angabe EXPDT=98000 erreichen.

//EXDAT // // // //

DD

DSN=UWIN.EXPORT.DATEN.M9201,

DISP=(NEW,KEEP,DELETE), UNIT=TAPE, EXPDT=98000, RECFM=FB,LRECL=453

Standardbänder

importieren Standardbänder zu importieren stellt kein allzu großes Problem dar. Der neue Datenbestand sollte katalogisiert werden. Im folgenden Beispiel werden zwei Datasets auf Band importiert.

//IMPDAT1 // // //IMPDAT2 // // //

DD

DSN=UWIN.IMPORT.DATEN.M9201,

DISP=(OLD,CATLG,DELETE), UNIT=TAPE,VOL=SER=76 6 991 DD

DSN=UWIN.IMPORT.DATEN.M9202,

DISP=(OLD,CATLG,DELETE), UNIT=TAPE,VOL=SER=7669 91, LABEL=2

Sollen Datasets auf Bändern, die nicht den IBM-Standardkonventionen entsprechen, importiert werden, so sollten sie auf einen anderen Datenträger (Kassette oder Platte) kopiert werden. Wie Nicht-Standardbänder verarbeitet werden, erfahren Sie im folgenden Kapitel. Kassetten/Bänder ohne Standardlabel verarbeiten

Standardisierte Bänder und Kassetten von IBM sind nach einem ganz bestimmten Muster Sie enthalten neben den Daten Blöcke mit Steuerinformationen. Die verschiedenen Bestandteile sind mit Hilfe von Markierungen (Tape Marks) voneinander

aufgebaut. getrennt.

Am Anfang des Bandes/der Kassette steht der Volume Record gefolgt von Header 1 und Header2 Record. Anschließend folgt eine Tape Mark. Zwischen dieser und der nächsten

JCL

101

Mark stehen die Datensätze. Danach steht nochmals eine Tape Mark.

Tape

folgen

die Trailer Records 1 und 2. Am Ende

Record, der häufig auch nur als Volume Record bezeichnet wird, steht eines jeden Bandes/Kassette. In ihm ist u.a. die Volume Serial Number Anfang mit der das Band/die Kassette identifiziert wird. Diese Angabe ist für normale abgelegt, (nicht importierte) Bänder/Kassetten rein numerisch. Für jedes Dataset stehen zwei Header Records zur Verfügung (HDR1, HDR2). Im HDR1 stehen u.a. der DSN, die Vol-ser-no für das Dataset, die mit der des gesamten Volumes identisch sein kann, das Datum des Anlegens des Datasets, die Position des Datasets auf der Kassette und die Schutzfrist. Im HDR2 stehen u.a. Record-Format, Blockgröße bzw. Blockfaktor, Record-Länge und Schreibdichte. Der Initial Volume am

Der genaue Aufbau der Header ist im

Anhang erläutert.

Auf HDR1 und HDR2 können bis zu weitere acht User Labels folgen. Von dieser Möglichkeit wird im normalen DV-Alltag allerdings nur sehr selten Gebrauch gemacht. Spätestens jetzt folgt eine Tape Mark. Danach folgen die eigentlichen Datensätze, die ihrerseits mit einer Tape Mark abgeschlossen werden. Auf sie folgen zwei Trailer oder End-of-File (EOF) Records, deren Aufbau mit denen der Header Records identisch ist. Ihr Vorhandensein ermöglicht ein Rückwärtslesen der Kassetten. Auf sie folgen zum Abschluß zwei Tape Marks.

Reicht ein Band für die Aufnahme des Datenbestandes nicht aus, so können weitere Bänder für das Speichern verwendet werden. In diesem Fall wird an das Ende des ersten und jeden weiteren Bandes, auf dem das Dataset noch nicht endet, ein End-of-Volume Record (EOV)

geschrieben. Es gibt eine Reihe

von Umgebungen, in denen andere Labelarten verwendet werden. Sie unterscheiden sich hinsichtlich der Zahl und der Position der Tape Marks. Manchmal kann es auch notwendig werden, die Header Records zu lesen, um Informationen über das

Dataset

zu

erhalten.

Für die Verarbeitung von Bändern/Kassetten ohne Standardlabel wird eine LABEL-Parameters benötigt.

Erweiterung des

Die

Subparameter NL, LTM und BLP Syntax:

LABEL=(pos,labeltyp) Default:

LABEL=(1,SL)_

Der pos-Subparameter

Diesen Parameter kennen Sie bereits. Er ist Position geschrieben werden soll. Der Default-Wert ist 1.

anzugeben,

wenn

auf eine andere als die erste

102

MVS/ESA JCL

Der Label-Typ-Subparameter Der Label-Typ-Subparameter gibt an, welches Format das Tape Label hat. In der Regel wird dies die Angabe SL für Standard Label sein. Daher ist dies auch der Default-Wert. Folgende Label Angaben sind möglich:

Standard Label Standard und User Labels ISO/ANSI Labels ISO/ANSI und User Labels Non-Standard Label No Label Bypass Label Processing Leading Tape Mark

SL SUL AL AUL NSL NL BLP LTM

Von den verschiedenen Möglichkeiten haben außer SL nur NL, BLP und LTM eine praktische Bedeutung. Neben den normalen Label-Typen (SL, AL, SUL, AUL) gibt es die Möglichkeit, innerhalb einer Installation andere, nicht standardgemäße Label zu definieren. Davon wird aber nur selten Gebrauch gemacht. In diesem Fall ist NSL anzugeben. Wenn NL, LTM oder BLP benutzt wird, so ist zu beachten, daß alle Informationen, die normalerweise dem Label entnommen werden können, nicht zur Verfügung stehen. Dies bedeutet, daß Parameter wie LRECL, RECFM und BLKSIZE mit angegeben werden müssen. Der DSN spielt übrigens keine Rolle. Er wird nicht verifiziert.

NL (No Label) ist beim Fehlen von Labein Datensätze unmittelbar am Bandanfang.

//NLTAPE // // Steht

vor

beginnen

die

DSN=EGAL,DISP=OLD,UNIT=TAPE, VOL=SER=111655,LABEL=(l,NL), RECFM=FB,LRECL=8 0,BLKSIZE=24 0 0 0

den Datensätzen eine einzelne Tape kann z.B. bei

BLP steht für

In diesem Fall

DD

anzugeben. Diese Konfiguration Umgebung angelegt wurden.

//DOSTAPE // //

anzugeben.

DD

Mark, so ist LTM (Leading Tape Mark) Tapes auftreten, die in einer DOS/VSE-

DSN=EGAL,DISP=OLD,UNIT=TAPE,

VOL=SER=254221,LABEL=(,LTM), RECFM=FB,LRECL=140,BLKSIZE=28000

Bypass Label Processing. Es ist eine Option, die Sie einsetzen können, um Informationen über einen auf Band befindlichen unbekannten Datenbestand zu erhalten. So können Sie mit LABEL=(1,BLP) die Header Records 1 und 2 des ersten Datasets auf der Kassette lesen (vorausgesetzt es handelt es sich um eine SL Kassette). Mit LABEL=(4,BLP) erhalten Sie die Header Records des zweiten Datasets. Mit der Utility IEBGENER können Sie den Header z.B. drucken lassen.

JCL

103

//FINDOUT EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* DD DSN=EGAL,DISP=OLD,UNIT=TAPE, //SYSUT1 VOL=SER=111655,LABEL=(4,BLP), // RECFM=FB,LRECL=8 0,BLKSIZE=8 0 // DD SYSOUT=A //SYSUT2 DD DUMMY //SYSIN In

einigen MVS-Installationen ist der Einsatz von LTM und BLP nicht ohne weiteres Erkundigen Sie sich, welche Konventionen in Ihrer Installation einzuhalten sind.

erlaubt.

ASCII Daten auf Kassetten/Bändern verarbeiten

Alle IBM Mainframe Systeme arbeiten mit dem EBCDIC. EBCDIC steht für: Extended Binary Coded Decimal Interchange Code. Es kann jedoch auch notwendig werden, Bänder zu verarbeiten, deren Daten im ASCII Format stehen. ASCII steht für: American Standard Code for Information Interchange. Sollen Bänder/Kassetten mit ASCII Daten gelesen oder geschrieben werden, so können die Daten übersetzt werden. Denkbar ist z.B. der Einsatz eines Streamers in einem PCNetzwerk. Die dort im ASCII Format geschriebenen Daten sollen in einem MVS-System verarbeitet werden. Dies stellt eine Alternative zu einem File Transfer dar. OPTCD für

Bandverarbeitung

Syntax:

DCB=(...,OPTCD=Q) Beim Lesen von Bändern erfolgt eine Übersetzung von ASCII nach EBCDIC, beim Schreiben von Bändern wird von EBCDIC nach ASCII übersetzt. ASCII Bänder haben in der Regel keine IBM-Standardlabel. Meist folgen die Daten nach der ersten Tape Marke. Setzen Sie in diesem Fall den LABEL-Parameter auf LTM. Im folgenden Beispiel werden die Daten von einem Band gelesen, das ASCII Daten enthält. Durch die Angabe von OPTCD=Q wird eine Übersetzung von ASCII nach EBCDIC bewirkt. Der Datenbestand wird ans Ende des bestehenden Datasets UWIN.TRANSDAT

angehängt:

104

MVS/ESAJCL

//TRANSLAT EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* DD DSN=EGAL,DISP=OLD,UNIT=TAPE, //SYSUT1 VOL=SER=121771,LABEL=(,LTM), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=16000, // OPTCD=Q) // DD DSN=UWIN.TRANSDAT,DISP=MOD //SYSUT2 DD DUMMY //SYSIN

2.5

PASSen von Datasets zwischen Steps

Möglichkeit, Datasets mit DISP=(,CATLG) zu katalogisieren oder mit DISP=(,DELETE) zu löschen, gibt es die DISP=(,PASS), mit der ein Dataset an einen Folge-Step weitergegeben (gepassed) wird. In diesem Fall behält man sich vor, was mit dem Dataset bei Beendigung des Jobs geschehen soll. Notwendig ist diese Vorgehensweise bei temporären Datasets. Da temporäre Datasets nicht katalogisiert werden dürfen, ist das PASSen die einzige Möglichkeit, solche Datasets über mehrere Steps hinweg anzusprechen. Aus diesem Grund wird DISP=(,PASS) und das Arbeiten mit temporären Datasets in einem Kapitel behandelt. Neben der

Was

passiert beim PASSen

Wird ein Dataset gepassed, so erfolgt ein Eintrag in einer Tabelle, der sogenannten Passed Data Set Queue (PDSQ). Für jedes gepasste Dataset erfolgt ein Eintrag. Betrachten wir einmal,

//STEP1 //OUTPUT1 // // // // //STEP2 //INPUT

was

bei der Ausführung der folgenden JCL

geschieht:

EXEC PGM=PGM01 DD

DSN=UWIN.TESTOUT,

DISP=(NEW,PASS), UNIT=DSKPRM,

RECFM=FB,LRECL=234,

SPACE=(CYL,(1,1),RLSE) EXEC PGM=PGM02 DD

DSN=UWIN.TESTOUT,DISP=(OLD,DELETE)

JCL

105

In STEP1 wird ein Dataset mit dem DSN UWIN.TESTOUT neu angelegt. Es wird aber weder katalogisiert noch gelöscht, sondern mit der Normal-Disposition PASS an den Folge-

Step weitergegeben. Die Angabe von DISP=(,PASS) bewirkt, daß am Ende von STEP1 MVS einen Eintrag in der sogenannten Passed Data Set Queue (PDSQ) kreiert. Die PDSQ befindet sich im Hauptspeicher, im Gegensatz zu Katalogeinträgen, die auf Platte residieren. Der Eintrag für das gepasste Dataset sieht folgendermaßen aus: Eintrag in der PDSQ: DSN

Volume

Unit

UWIN.TESTOUT

DSK005

338Ö

Die Allokationsroutinen von STEP2 stellen bei dem DD-Namen INPUT fest, daß es sich ein existierendes Dataset (DISP=OLD) handelt, für die keine spezifische VOLUMEInformation angegeben wurde. Daher muß im Katalog nach den Einträgen geschaut werden. Bevor dies aber geschieht, muß die Passed Data Set Queue durchsucht werden, um festzustellen, ob dort ein Eintrag vorhanden ist. In diesem Beispiel findet MVS den Eintrag für das Dataset und entnimmt ihm die notwendigen VOLUME- und UNIT-Angaben. Anschließend wird dieser Eintrag aus der Passed Data Set Queue entfernt. Dies bedeutet, daß der Folge-Step das Dataset angenommen hat. Was passiert aber, wenn ein gepasstes Dataset nicht angenommen wird? In diesem Fall übernehmen es die Job Termination-Routinen, die übriggebliebenen Einträge in der PDSQ zu löschen. Für das Dataset ergeben sich dabei die folgenden vier Möglichkeiten: 1. Wenn das Dataset während des Jobs erstellt und weder katalogisiert noch behalten wurde (KEEP soll bei neuen Datasets nicht verwendet werden!), so wird es gelöscht. Dies trifft für temporäre Datasets immer zu. um

2. Ein Dataset wird in einem Job

Step erstellt und katalogisiert und in einem darauf Job Step gepassed, und dieser Pass wird nicht angenommen. In diesem Fall bleibt das Dataset katalogisiert. folgenden

3. Ein Dataset wird in einem Job Step erstellt, gepassed und im Folge-Step katalogisiert, ohne dabei aber angenommen zu werden (Dies ist durchaus möglich). Die Ergebnisse sind schwer vorherzusagen. Diese Form von JCL ist unter allen Umständen zu

vermeiden.

4. Ein Dataset, das vor Job-Beginn Das Dataset bleibt katalogisiert.

existiert, wird gepassed, ohne angenommen zu werden.

Zu allen vier Möglichkeiten werden im

folgenden Beispiele gegeben:

MVS/ESA JCL

106 1.

//STEP1 //OUTPUT1 // // // // //STEP2 //INPUT

EXEC PGM=PGM01 DD DSN=UWIN.TESTOUT,

DISP=(NEW,PASS), UNIT=DSKPRM, RECFM=FB,LRECL=234

,

SPACE=(CYL, (1,1) ,RLSE) EXEC PGM=PGM02,COND=(4,LT,STEP1) DD DSN=UWIN.TESTOUT,DISP=(OLD,CATLG)

Werden beide Steps ausgeführt, so wird das gepasste Dataset angenommen und Gibt STEP1 jedoch einen Return Code von 4 oder mehr zurück, so wird STEP2 nicht mehr ausgeführt. Die Job Termination-Routinen finden einen Eintrag in der Passed Data Set Queue und löschen ihn und damit das Dataset.

katalogisiert. 2.

//STEP1 //OUTPUT1 // // // // //STEP2 //INPUT //STEP3 //INPUT

EXEC PGM=PGM01 DD DSN=UWIN.TESTOUT,

DISP=(NEW,PASS), UNIT=DSKPRM, RECFM=FB,LRECL=234

,

SPACE=(CYL, (1,1) ,RLSE) EXEC PGM=PGM02 DD DSN=UWIN.TESTOUT,DISP=(OLD,CATLG)

EXEC PGM=PGM03 DD DSN=UWIN.TESTOUT,DISP=(OLD,PASS)

Dataset in STEP1 erstellt, an STEP2 gepassed und dort Auffinden des Dataset den Katalog und passed das Dataset weiter. Dieser Pass wird nicht mehr angenommen. Da das Dataset zum Zeitpunkt des Passens in STEP3 jedoch schon katalogisiert war, bleibt es katalogisiert. In diesem

Beispiel wird das katalogisiert. STEP3 benutzt

zum

JCL

107

3.

//STEP1 //OUTPUT1 // // // // //STEP2 //INPUT //

EXEC PGM=PGM01 DD DSN=UWIN.TESTOUT,

DISP=(NEW,PASS), UNIT=DSKPRM, RECFM=FB,LRECL=234,

SPACE=(CYL,(1,1),RLSE) EXEC PGM=PGM02 DD DSN=UWIN.TESTOUT,DISP=(OLD,CATLG),

VOL=REF=*.STEP1.OUTPUT1

Diese JCL ist ausgesprochen gefährlich. In ihr ist eine Anweisung enthalten, die bei Datasets auf Platte nicht zum Einsatz kommen sollte: Die Anweisung VOL=REF. Sie hat nur im Zusammenhang mit Bandverarbeitung Berechtigung, wenn mehrere Datasets hintereinander auf ein Band geschrieben werden sollen. In obigem Beispiel hat die völlig überflüssige Benutzung der Anweisung VOL=REF verheerende Folgen. STEP1 erstellt das Dataset, macht einen Eintrag in der Passed Data Set Queue (PDSQ) und übergibt es an STEP2. Da im STEP2 bei INPUT der VOL=REFSubparameter angegeben ist, wird die entsprechende VOLUME- und UNIT-Information durch den Rückbezug von STEP1 übernommen. STEP2 braucht daher nicht mehr in die PDSQ zu schauen. Die Folge: Das Dataset wird nicht angenommen. Deshalb wird der in der PDSQ befindliche Eintrag nicht gelöscht. STEP2 katalogisiert das Dataset. Die Job Termination-Routinen finden jedoch einen Eintrag in der PDSQ und starten einen Löschvorgang. In Nicht-SMS-Umgebungen löschen sie nur den Eintrag im VTOC der Platte, während der Katalogeintrag im ICF bestehen bleibt. Somit existiert nach dem Job ein Katalogeintrag für ein nicht existierendes Dataset. Unter SMS werden beide wird.

Einträge gelöscht,

Wird die Anweisung VOL=REF

was vom

User mit Sicherheit nicht

gewünscht

entfernt, so entstehen keinerlei Probleme.

4.

//STEP1 //OUTPUT1 // //STEP2 //INPUT

EXEC PGM=PGM01 DD DSN=UWIN.TESTOUT,

DISP=(OLD,PASS) EXEC PGM=PGM02 DD

DSN=UWIN.TESTOUT,DISP=(OLD,PASS)

108

MVS/ESA JCL

In diesem Fall existiert das Dataset bereits vor Job-Beginn. Der PASS bewirkt einen minimalen Performancevorteil in STEP2, da die PDSQ im Speicher gehalten wird und ein erneuter Read im ICF nicht notwendig wird. Der Pass im STEP2 wird nicht angenommen. Da das Dataset aber bereits katalogisiert war, bleibt es katalogisiert.

2.6

Temporäre Datasets

Bei der Verarbeitung umfangreicher Jobs werden häufig Datasets angelegt, die nur zur Laufzeit des Jobs benötigt werden. Ein typisches Anwendungsfeld von temporären Datasets ergibt sich in Zusammenhang mit der Benutzung der SORT-Utility. Diese wird im Kapitel über Utilities behandelt. Das Besondere an diesen Datasets ist, daß man sie in einem Step erzeugen kann und ohne sie katalogisieren zu müssen an den folgenden Step weitergeben kann.

Der DSN

temporäre Datasets

Für temporäre Datasets werden keine zu katalogisierenden Namen vergeben. Man kann entweder mit einem symbolischen DSN arbeiten oder aber den DSN ganz weglassen. Im letzteren Fall muß dann im Folge-Step mit einem Rückbezug (referback) gearbeitet werden. Wie dies geschehen muß, wird weiter unten gezeigt.

Symbolische DSNs Ein von

symbolischer DSN beginnt immer mit der Zeichenfolge &&. Darauf maximal acht Zeichen. Typische symbolische DSNs sind:

//DDI

DD DSN=5c&TEMPDAT

//DDI

DD DSN=&&SORTOUT

//DDI

DD DSN=&&LOADSET

folgt

ein

String

Diese DSNs können dann in den Folge-Steps wieder verwendet werden. Wird im Job mehr als ein symbolischer DSN verwendet, so sollte auf Eindeutigkeit geachtet werden. Diese

Eindeutigkeit ist syntaktisch nicht zwingend vorgeschrieben. Wer jedoch mit abhängiger Step-Steuerung (COND-Parameter auf Step-Ebene) arbeitet, kann böse Überraschungen erleben. Unter Umständen werden falsche Datasets angefaßt, ohne daß sich das in einer Fehlermeldung niederschlagen muß. Im folgenden Beispiel wird ein symbolischer Name vergeben:

109

JCL uwin.schulung.cntl(tempi)

edit

01 14 -

command

.

c olumns 001 072 ===> page

scroll

===>

*****************************

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009

//uwinc job (998,abtdg02),'m.winter1,class=a,notify=uwin, // msgclass=y,msglevel=(1,1) exec pgm=pgm01 //step1

//input1

dd

//

disp=shr

//output1

dd

// // // 000010 // 000011 //step2 000012 //input2 000013 //output2 000014 // 000015 // 000016 // 000017 //

Top of data

dsn=uwin.schulung.testdat.input,

dsn=&&tempdat, disp=(new,pass), unit=sysda, recfm=fb,

space=(cyl,(1,1),rlse) exec pgm=pgm02

dsn=&&tempdat,disp=(old,delete) dsn=uwin.schulung.testdat.output2, disp=(new,catlg,delete), dd dd

unit=prmdsk, recfm=fb,

space=(cyl,(1,1),rlse)_

In diesem Beispiel erhält OUTPUT1 den symbolischen DSN &&TEMPDAT. Dieses Dataset wird an STEP2 übergeben, dort als INPUT2 verwendet und anschließend gelöscht. Für den

symbolischen Namen generiert MVS einen DSN nach folgendem Muster:

SYS90 003.TO91524.RD001.UWIN.TEMPDAT

folgt auf SYS das julianische Datum. Auf T folgt die Zeit, zu der JES2 initialisiert wurde. RD001 ist die Kennung des verwendeten Readers. Darauf folgt die USERID und schließlich der symbolische Name. Wird der gleiche symbolische Name mehrfach verwendet, so wird zwar nicht der gleiche physische DSN generiert, es kann aber trotzdem zu Problemen kommen. Im ersten Level

Rückbezüge (Referbacks) Rückbezüge sind Verweise auf DD-Namen, genauer auf Parameter, die mit diesem DDBeziehung stehen. Sie werden häufig eingesetzt für den DSN-, DCB-, VOL- und PGM-Parameter. Sie können sich auf DD-Namen des gleichen Steps oder DD-Namen eines vorangehenden Steps beziehen. Syntax für Rückbezüge auf DD-Namen innerhalb desselben Steps:

Namen in

parameter=*.ddname

MVS/ESA JCL

110

Syntax fur Rückbezüge auf DD-Namen vorhergehender Steps:

parameter=*.stepname.ddname Syntax für Rückbezüge auf DD-Namen vorhergehender Steps in Prozeduren:

parameter=*.stepname.procstepname.ddname Auf der folgenden Seite werden beide Möglichkeiten eines 1. Rückbezug innerhalb eines Steps:

Rückbezugs vorgestellt.

000001 //UWINC JOB (998,ABTDG02),'M.WINTER',CLASS=A,NOTIFY=UWIN, 000002 // MSGCLASS=Y,MSGLEVEL=(1,1) EXEC PGM=PGM01 000003 //STEP1 000004 //OUTPUT 1 DD DSN=UWIN.SCHULUNG.TESTDAT.0UTPUT1, 000005 // DISP=(NEW,CATLG,DELETE), 000006 // UNIT=DSKPRM, 000007 // RECFM=FB, 000008 // SPACE=(CYL,(1,1),RLSE) 000009 //OUTPUT2 DD DSN=UWIN.SCHULUNG.TESTDAT.0UTPUT2, 000010 // DISP=(NEW,CATLG,DELETE), 000011 // UNIT=DSKPRM, 000012 // 000013 // ******

DCB=*.0UTPUT1, SPACE=(CYL,(1,1),RLSE)

****************************

BOTTOM OF DATA

***************************

In diesem Fall wurde für OUTPUT2 die DCB-Information von OUTPUT1

kopiert.

111

JCL

2.

Rückbezug auf einen vorhergehenden Step:

000001 //UWINC JOB (998,ABTDG02),1H.WINTER 1, CLASS=A,NOTIFY=UWIN, 000002 // MSGCLASS=Y,MSGLEVEL=(1,1) EXEC PGM=PGM01 000003 //STEP1 000004 //OUTPUT1 DD DISP=(NEW,PASS),

000005 000006 000007 000008 000009 000010 000011 000012

// // //

RECFM=FB,LRECL=234, SPACE=(CYL,(1,1),RLSE)

//STEP2

EXEC PGM=PGM02

//STEPLIB //INPUT2

DD

//OUTPUT2

// 000013 // 000014 // 000015 // ******

UNIT=SYSDA,

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DSN=*.STEP1.OUTPUT,DISP=(OLD,DELETE) DD DSN=UWIN.SCHULUNG.TESTDAT.OUTPUT2, DISP=(NEW,CATLG,DELETE), DD

UN IT=PRMDSK,

DCB=*.STEP1.OUTPUT1, SPACE=(CYL,(1,1),RLSE)

****************************

BOTTOM OF DATA

***************************

erfolgt ein Rückbezug auf den DSN von OUTPUT1 in Stepl. Dies scheint für diesen DD-Namen wurde der DSN-Parameter weggelassen. In diesem denn erstaunlich, Fall generiert MVS einen Namen und zwar nach folgendem Muster: In diesem Fall

SYS90 0 03.TO91524.RDOOl.UWIN.RO0 00 0 001 Im ersten Level

folgt auf SYS das julianische Datum. Auf T folgt die Zeit, zu der JES2 initialisiert wurde. RD001 ist die Kennung des verwendeten Readers. Darauf folgt die USERID und schließlich eine laufende Nummer, die eins steht für das erste im Job erzeugte temporäre Dataset. Für jedes neue wird diese Zahl um eins erhöht. Damit ist die Eindeutigkeit des Namens sichergestellt. Rückbezüge auf vorhergehende Steps funktionieren Bezug genommen wird, auch ausgeführt wurde.

nur

dann,

wenn

der

Step, auf den

DISP=(,PASS) für temporäre Datasets Für die im vorhergehenden Abschnitt verwendeten temporären Datasets wurde im DISPParameter (,PASS) angegeben. Über die Verwendung bei nicht-temporären Datasets wurde bereits gesprochen. Da die Dispositionen KEEP und CATLG für temporäre Datasets nicht zugelassen sind, kann eine Weiterverwendung in einem Folge-Step nur mit DISP=(,PASS) ermöglicht werden. Im

Folge-Step muß das gepasste Dataset angenommen werden und gelöscht oder nochmals gepassed werden. Werden temporäre Datasets gepassed und nicht angenommen, so erfolgt die Löschung durch die Job Termination-Routinen.

112

MVS/ESA JCL

Sollen temporäre Datasets annehmenden Step

am

Ende des annehmenden

Steps gelöscht werden,

so

ist im

DISP=(OLD,DELETE) anzugeben. Falls sie in einem weiteren können sie mit:

Folge-Step

weiterverarbeitet werden

sollen,

so

DISP=(OLD,PASS) nochmals weitergegeben werden. Das OLD muß in beiden Fällen annehmen würde. Das

stehen, keinesfalls ein Komma, das den Default NEW

folgende Beispiel zeigt eine typische Verwendung temporärer Datasets:

//STEP1 //OUTPUT1 // // // // //STEP2 //INPUT //STEP3 //INPUT

EXEC PGM=PGM01 DD DSN=&&TEMPDAT,

DISP=(NEW,PASS), UNIT=SYSDA, RECFM=FB,

SPACE=(CYL, (1,1) ,RLSE) EXEC PGM=PGM02 DD

DSN=&&TEMPDAT,DISP=(OLD,PASS)

EXEC PGM=PGM03 DD

DSN=&&TEMPDAT,DISP=(OLD,DELETE)

Bei dieser Art JCL können keinerlei Probleme entstehen. &&TEMPDAT wird in STEP1 erzeugt, von STEP2 angenommen und an STEP3 übergeben, wo es angenommen und wieder gelöscht wird.

UNIT und

temporäre Datasets

Temporäre Datasets existieren bloß für die Zeit des Joblaufs. Der von ihnen eingenommene spätestens zu diesem Zeitpunkt wieder frei. Daher dürfen temporäre Datasets auf Plattenpools angelegt werden, die für permanente Datasets üblicherweise nicht zugelassen Platz wird

sind. In fast jeder MVS-Installation gibt es einen Plattenpool mit dem Namen SYSDA. Mit diesem Gruppennamen wird ein Pool sogenannter Work-Datasets angesprochen. Wenn man sich angewöhnt, bei der Benutzung temporärer Datasets:

UNIT=SYSDA

113

JCL

anzugeben, so macht man mit Sicherheit nichts falsch.

Mögliche Probleme bei der Benutzung temporärer Datasets großen Vorteile des Benutzung temporärer Datasets ist die Tatsache, daß Plattenplatz bei Beendigung des Steps sofort wieder freigegeben werden kann. Der Performancevorteil, der durch das Nicht-Katalogisieren entsteht, ist dagegen unbedeutend. Probleme können entstehen, wenn sich Unachtsamkeiten im Umgang mit symbolischen Eine der

DSNs einschleichen oder der Job nach einem Abbruch mit RESTART neu laufen soll.

Nicht-eindeutige symbolische DSNs Es wurde bereits ausgeführt, daß man bei der Benutzung symbolischer DSNs auf Eindeutigkeit achten sollte. Das folgende Beispiel soll demonstrieren, was passieren kann, wenn man sich an diese Regel nicht hält.

//STEP1 //OUTPUT1 // // // // // //STEP2 //INPUT2 //OUTPUT2 // // // // //STEP3 //INPUT3

EXEC PGM=PGM01 DD DSN=&&TEMPDAT,

DISP=(NEW,PASS), UNIT=SYSDA, RECFM=FB, LRECL=234,

SPACE=(CYL,(1,1),RLSE) EXEC PGM=PGM0 2,COND=(4,LT,STEP1) DD DSN=&&TEMPDAT,DISP=(OLD,DELETE) DD DSN=&&TEMPDAT,DISP=(,PASS), UNIT=SYSDA, RECFM=FB, LRECL=234,

SPACE=(CYL,(1,1),RLSE) EXEC PGM=PGM03 DD DSN=&&TEMPDAT,DISP=(OLD,DELETE)

Die vorstehende JCL ist syntaktisch völlig korrekt. Was aber passiert, wenn STEP1 einen Return Code von 4 zurück gibt? Dann wird STEP2 nicht ausgeführt. STEP3 aber wird ausgeführt. Nur erhält er als Input nicht den Output von STEP2, sondern den von STEP1. Fehler treten wahrscheinlich keine auf, da auch der DCB von OUTPUT 1 und OUTPUT2 identisch ist. Der Job kann völlig normal durchlaufen, wenn auch mit den falschen Daten. Wären, wie im folgenden Beispiel, eindeutige symbolische Namen verwendet worden, wäre es in jedem Fall zu einem Fehler gekommen:

MVS/ESA JCL

114

//STEP1 //0UTPUT1 // // // //

EXEC PGM=PGM01 DD DSN=&&TEMP1,

DISP=(NEW,PASS), UNIT=SYSDA, RECFM=FB,LRECL=234,

SPACE=(CYL,(1,1),RLSE) PGM=PGM02,COND=(4,LT,STEP1) DSN=&&TEMP1,DISP=(OLD,DELETE) DSN=&&TEMP2,DISP=(,PASS),

//STEP2 //INPUT2 //OUTPUT2 // // // //STEP3 //INPUT3

UNIT=SYSDA, RECFM=FB,LRECL=234,

Wird STEP2 nicht

ausgeführt,

Fehlermeldung: IEF212I

EXEC DD DD

SPACE=(CYL, (1,1) ,RLSE) EXEC PGM=PGM03 DD

DSN=&&TEMP2,DISP=(OLD,DELETE) so

JOBNAME

kommt

es

bei der

STEP3

Ausführung

von

STEP3

zu

folgender

INPUT3 -

DATA SET NOT FOUND

RESTART und

temporäre Datasets

Jobs, die für die Produktion bestimmt sind, sollten grundsätzlich

so geschrieben sein, daß der Job im Falle eines Abbruchs nach der Fehlerbehebung mit RESTART neu gestartet werden kann. Mit RESTART wird normalerweise auf dem Step aufgesetzt, bei dem der Abbruch erfolgte. Wird in Jobs mit temporären Datasets gearbeitet, so ist große Vorsicht bei der Benutzung von RESTART geboten.

//STEP14 //OUTPUT1 // // // //

EXEC PGM=PGM01 DD

DSN=&&TEMPDAT,

DISP=(NEW,PASS), UNIT=SYSDA, RECFM=FB,LRECL=234

,

SPACE=(CYL, (50,5) ,RLSE)

115

JCL

//STEP15 //INPUT2 //0UTPUT2 // // // //

DD

PGM=PGM02,COND=(4,LT,STEP1) DSN=&&TEMPDAT,DISP=(OLD,DELETE)

DD

DSN=UWIN.SCHULUNG.OUTPUT,

EXEC

DISP=(,PASS), UNIT=SYSDA, RECFM=FB,LRECL=2265,

SPACE=(CYL, (500,100) ,RLSE)

vorhergehenden Beispiel wird im STEP 14 ein großes Output Dataset erzeugt, das als Input für STEP2 dient. STEP2 seinerseits erzeugt ein noch größeres Output Dataset. Kommt es jetzt bei STEP 15 zu einem Abbruch, z.B. weil der für OUTPUT2 zu allokierende Platz nicht ausreicht, so ist auch das in STEP1 erzeugte Dataset verloren, da es von den Job Termination-Routinen gelöscht wird. In diesem Fall ist ein Restart nur ab STEP 14 möglich. Dieser Step kann aber wegen des großen Outputs sehr zeitintensiv sein. Wäre das Dataset in STEP 14 katalogisiert worden, hätte der Restart ab STEP 15 erfolgen können. Grundsätzlich gilt: Wenn mit dem Parameter RESTART gearbeitet werden soll, so kann die Benutzung temporärer Datasets nicht empfohlen werden. In solchen Fällen ist es besser, die Datasets zu katalogisieren. Um zu verhindern, daß diese Datasets, die ja nach Job-Ende nicht mehr benötigt werden, Plattenplatz wegnehmen, sollte am Ende des Jobs ein Step laufen, der diese Datasets wieder löscht. Dies wird an folgendem Beispiel gezeigt: Im

//STEP14 //OUTPUT1 // // // // Das

EXEC PGM=PGM01 DD

DSN=UWIN.OUTPUTl,

DISP=(NEW,CATLG,DELETE), UNIT=SYSDA, RECFM=FB,LRECL=234,

SPACE=(CYL, (50,5) ,RLSE)

Beispiel wird auf der folgenden Seite fortgesetzt.

MVS/ESA JCL

116

11STEP15 //INPUT2 //OUTPUT2 // // // // //CLEARCAT //SYSPRINT //SYSIN DELETE DELETE

EXEC PGM=PGM02,COND=(4,LT,STEP1) DD DSN=UWIN.0UTPUT1,DISP=0LD DD

DSN=UWIN.OUTPUT2,

DISP=(,CATLG,DELETE), UNIT=SYSDA, RECFM=FB,LRECL=234,

SPACE=(CYL, (100,10) ,RLSE) EXEC PGM=IDCAMS DD SYSOUT=* DD

*

(UWIN.OUTPUT1) (UWIN.OUTPUT2)

Alternativ dazu kann auch die

//STEP14 //OUTPUT1 // // // // //STEP15 //INPUT2 // //OUTPUT2 // // // //

Disposition im STEP 15 angepaßt werden.

EXEC PGM=PGM01 DD DSN=UWIN.OUTPUT1,

DISP=(NEW,CATLG,DELETE), UNIT=SYSDA, RECFM=FB,LRECL=234

,

SPACE=(CYL, (50,5) ,RLSE) EXEC PGM=PGM02,COND=(4,LT,STEP1) DD

DSN=UWIN.OUTPUTl,

DISP=(OLD,DELETE,KEEP) DD

DSN=UWIN.OUTPUT2,

DISP=(,CATLG,DELETE), UNIT=SYSDA, RECFM=FB,LRECL=234

,

SPACE=(CYL, (100,10) ,RLSE)

Das Dataset UWIN.OUTPUT1 wird im STEP 14 katalogisiert. Sie dient nur als INPUT für STEP 15 und wird danach nicht mehr benötigt. Das heißt, im Normalfall soll dieses Dataset beim Ende vom STEP 15 gelöscht werden, im Falle eines Abbruchs von STEP 15 aber behalten werden. In diesem Fall wird INPUT 1 nur dann gelöscht, wenn STEP 15 normal endet. Bricht STEP 15 ab, so wird die abnormale Disposition KEEP wirksam und das Dataset wird behalten. Dies ist eine der wenigen Fälle, wo KEEP als abnormal-disp explizit angegeben

117

JCL

angegeben worden, so würde der Default (OLD,DELETE,DELETE) gelöscht. Die zuletzt aufgezeigte Möglichkeit hat den Vorteil, daß der Plattenplatz bereits beim StepEnde und nicht wie im Beispiel zuvor erst bei Job-Ende freigegeben wird. werden muß und auch sinnvoll ist. Wäre

es

nicht

angenommen und das Dataset würde

2.7

Die OUTPUT JCL-Anweisung

Syntax:

//feldname OUTPUT parameter.parameter,... Output JCL-Anweisung kann in Zusammenhang mit SYSOUT-Datasets (Spool Datasets) verwendet werden. Sie macht vor allen Dingen dann Sinn, wenn man sich die ständige Wiederholung von Parametern bei der Benutzung DD SYSOUT-Anweisungen

Die

ersparen will. Die OUTPUT-Anweisung kann mit einem Rückbezug (referback) angesprochen werden, es gibt jedoch auch die Möglichkeit, mit Hilfe des DEFAULT=YES-Parameters die Übernahme der dort abgelegten Angaben für alle folgenden DD SYSOUT-Anweisungen zu

erzwingen. Beispiel:

//STEP1 //FORM1 //SYSPRINT

//STEP2 //SYSPRINT

EXEC PGM=P0001 OUTPUT COPIES=3 DD

SYSOUT=*,OUTPUT=*.FORM1

EXEC PGM=P0002 DD

SYSOUT=*,OUTPUT=*.STEP1.FORM1

In diesem Beispiel nimmt der SYSPRINT in STEP1 einen Bezug auf die im gleichen Step verwendete OUTPUT-Anweisung. Im STEP2 wird für SYSPRINT ebenfalls Bezug auf die OUTPUT-Anweisung von STEP1 genommen. Da dies aber bereits ein zurückliegender Step ist, muß der Stepname im Rückbezug mit angegeben werden. Dies ist auf Dauer sehr umständlich. Daher gibt es den DEFAULT=YES-Parameter, der diese Arbeit abnimmt. Er gilt für alle SYSOUT-Datasets, solange keine neue OUTPUTAnweisung mit DEFAULT=YES gesetzt wird.

MVS/ESA JCL

118

//UWINUEB2 JOB OUTPUT COPIES=3,DEST=U03 02, //FORM1 DEFAULT=YES,CLASS=A // EXEC PGM=P0 0 01 //STEP1 //SYSPRINT DD SYSOUT=* ...

//STEP2 //SYSPRINT

EXEC PGM=P0002 DD SYSOUT=*

Da DEFAULT=YES angegeben wurde, wird der SYSPRINT Output in beiden Steps dreimal gedruckt und auf den Drucker U0302 gelegt. Sollen Parameter der OUTPUT-

Anweisung überschrieben werden, so geschieht dies Parameters in der DD SYSOUT-Anweisung.

durch die

Angabe des entsprechenden

//UWINUEB2 JOB OUTPUT COPIES=3,DEST=U0302, //FORM1 DEFAULT=YES,CLASS=A // EXEC PGM=P0001 //STEP1 //SYSPRINT DD SYSOUT=* .

//STEP2 //SYSPRINT

.

.

EXEC PGM=P0002 DD

SYSOUT=*,COPIES=2

In diesem Fall wird der SYSPRINT

von

STEP2

wichtigsten Parameter der OUTPUT wiedergegeben. Für eine vollständige Handbücher verwiesen. Die

nur

zweimal

gedruckt.

JCL-Anweisung werden auf den folgenden Seiten Übersicht wird auf die entsprechenden IBM-

ADDRESS Syntax:

ADDRESS=('Lieferadresse,..., Lieferadresse') Mit ADDRESS können 4 Zeilen zu 60 Zeichen als Lieferadresse angegeben werden. Sie erscheinen auf den Trennblättern, die am Beginn jedes Outputs gedruckt werden.

119

JCL

BUILDING Syntax:

BUILDlNG='Gebäudename' Wie auch ADDRESS, so erscheint BUILDING auf der allerersten Seite des Es steht eine Zeile mit 60 Zeichen zur Verfügung.

Druckoutputs.

CLASS Syntax:

CLASS=outputklasse Durch die Angabe von CLASS kann eine bestimmte Output-Klasse verwendet werden. Der Parameter darf nicht mit dem CLASS-Parameter der JOB-Anweisung verwechselt werden. Wird nichts oder CLASS=* angegeben, so wird der bei MSGCLASS angegebene Wert übernommen.

Erfolgt

eine

Angabe,

muß bei der SYSOUT

so

DD-Anweisung Folgendes angegeben

werden:

//SYSPRINT

DD

SYSOUT=(,),OUTPUT=*.FORM1

Es handelt sich dann um eine sogenannte Null

SYSOUT-Anweisung.

COPIES Syntax: COPIES=nnn Damit läßt sich die Zahl der Kopien

DEFAULT Syntax:

DEFAULT=YES/NO

angeben. Maximal 255

sind

zulässig.

120

MVS/ESA JCL

Wird DEFAULT=YES gesetzt, so gelten die Angaben in dieser OUTPUT-Anweisung für alle folgenden SYSOUT-Datasets. Der eingestellte Default bleibt bis zum Auftauchen einer neuen OUTPUT-Anweisung mit DEFAULT=YES gültig.

DEPT Syntax:

DEPT='Abteilungsname' Mit DEPT läßt sich der Abteilungsname auf dem Trennblättern Zeile mit 60 Zeichen zur Verfügung.

ausgeben.

Es steht eine

DEST Syntax:

DEST=RDnnnn oder Unnnn Mit DEST=Unnnn kann eine angegeben werden.

logische,

mit DEST=RDnnnn eine

physische Druckeradresse

NAME Syntax:

NAME='name* Dient der Angabe des Namens einer Zeile mit 60 Zeichen zur Verfügung.

Person, die den Output erhalten soll. Es steht eine

ROOM Syntax:

ROOM='raumbezeichnung' Dient der

Verfügung.

Angabe

einer

Raumbezeichnung.

Es steht eine Zeile mit 60 Zeichen

zur

JCL

121

TITLE Syntax: TITLE='titel' Dient der Angabe eines Titels auf den Trennblättern. Es steht eine Zeile mit 60 Zeichen

Verfugung.

zur

3

JCL-Prozeduren

Anwendungsprogrammierer müssen in fast allen MVS-Installationen JCL-Prozeduren benutzen, um Programme kompilieren und linken (evtl. auch ausführen) zu können. Um diese Prozeduren optimal nutzen zu können, müssen bestimmte Kenntnisse über die Funktionsweise

JCL-Prozeduren vorhanden sein. Darüber hinaus können auch eigene Prozeduren schreiben. Dies kann Testabläufe erheblich verkürzen und vereinfacht auch die Übernahme von Programmen in die Produktion. von

Anwendungsprogrammierer

Prozeduren sind nichts anderes als Stücke vorgefertigter JCL, die häufig benutzt werden. Anders als in 'normaler' JCL, dürfen in Prozeduren Variable benutzt werden. Sie werden hier meist als symbolische Parameter bezeichnet. Zusätzlich besteht die Möglichkeit, EXEC- und DD-Anweisungen zu ergänzen bzw. zu überschreiben. Dies geht in allen Prozeduren, auch solchen, die keine Variable enthalten. Wir werden uns im Rahmen dieses 1.

Kapitels mit folgenden Fragen befassen:

2.

Wie benutze ich vorhandene Prozeduren? Wie kann ich vorhandene Prozeduren meinen Bedürfhissen

3.

Wie kann ich vorhandene Prozeduren

4.

Wie kann ich

anpassen?

ergänzen?

eigene Prozeduren schreiben? 5. Wie kann ich mit eigenen Prozedurbibliotheken arbeiten? Solange Ihnen die Version 4 von MVS/ESA noch nicht zur Verfugung steht, können Sie nur die im System definierten Prozedurbibliotheken beim Aufruf katalogisierter Prozeduren nutzen. Das Absuchen von Ladebibliotheken, auf denen Programme stehen, läßt sich durch die STEPLIB- oder JOBLIB DD-Anweisung steuern. Bei Prozedurbibliotheken wird erst mit der Version 4 von MVS/ESA ein entsprechender Mechanismus eingeführt. Beim Aufruf einer Prozedur wird die SYS1.PROCLIB und die mit ihr verbundenen Bibliotheken abgesucht. Um andere Bibliotheken abzusuchen, muß die Initialisierung des JES entsprechend angepaßt werden. Mit der Einführung der Version 4 von MVS/ESA wird die Möglichkeit gegeben, private Prozedurbibliotheken zu benutzen. Dies stellt einen bedeutenden Fortschritt dar, weil die Testumgebung dann mit der Produktionsumgebung identisch ist. In-Stream-Prozeduren brauchen dann nicht mehr verwendet werden.

MVS/ESA JCL

124

Arten Es

von

Prozeduren

gibt zweierlei Arten von Prozeduren:

1.

In-Stream-Prozeduren

2.

Katalogisierte Prozeduren

In-Stream-Prozeduren sehen fast aus wie normale JCL, mit Ausnahme einiger zusätzlicher Parameter. Sie eignen sich besonders für Testzwecke. Der Aufruf und die Prozedur selber befinden sich innerhalb der JCL. Daher auch die Bezeichnung 'In-Stream'.

Katalogisierte Prozeduren werden als" Member einer oder mehrerer Bibliotheken gespeichert. In jeder MVS-Installation ist die SYS1.PROCLIB vorhanden. Daneben können der Systemprogrammierung weitere Prozedurbibliotheken definiert werden. von Erkundigen Sie sich, wie diese Bibliotheken bei Ihnen heißen. Katalogisierte Prozeduren können mit der EXEC PROC-Anweisung aufgerufen werden. Es ist dann nur der Name des Members anzugeben, in dem die Prozedur enthalten ist. Prozeduren werden meist als In-Stream-Prozeduren entwickelt. Fertige und ausgetestete Prozeduren werden 'katalogisiert', d.h. sie kommen als Member auf eine der oben angegebenen Bibliotheken. Prozeduren besitzen gegenüber normaler JCL einige syntaktische Besonderheiten:

3.

Prozeduren dürfen weder eine JOB-Anweisung noch eine Delimiter-Anweisung (/* ) oder Leer-Anweisung (//) enthalten. Die JOBLIB DD- und JOBCAT DD-Anweisungen dürfen nicht innerhalb von Prozeduren verwendet werden. Die Anweisung DD * sowie DD DATA dürfen nicht verwendet werden.

4.

In Prozeduren dürfen keine JES2-Konfrollkommandos verwendet werden.

5.

Bis zur Einführung von MVS/ESA Version 4 dürfen Prozeduren ihrerseits keine weiteren Prozeduren aufrufen. Aus Prozeduren heraus dürfen maximal 15 weitere Prozeduren aufgerufen werden (erst ab MVS/ESA Version 4).

1. 2.

6.

3.1

Benutzung katalogisierter Prozeduren

Katalogisierte

Prozeduren werden in mehreren Systembibliotheken, u.a. in der SYS1.PROCLIB vorgehalten. Sie können von jedem MVS-Benutzer aufgerufen werden. Der Aufruf geschieht in einer EXEC-Anweisung:

Syntax: EXEC

[PROC=]procname

125

JCL-Prozeduren Prozeduren können einfach durch die Angabe von EXEC procname aufgerufen Schlüsselwort PROC ist optional.

werden, das

Anhand einer Prozedur COBCL, die COBOL-Programme kompiliert und linkt und so oder so ähnlich auch bei Ihnen installiert sein kann, soll die Benutzung vorhandener Prozeduren erläutert werden. Ein Problem bei der Benutzung katalogisierter Prozeduren ist die Tatsache, daß man die dahinter steckende JCL nicht ohne weiteres sehen kann. Zwar kann man in das Member schauen, das die Prozedur enthält, doch können in ihm symbolische Parameter enthalten sein, die vor der Ausführung der Prozedur ersetzt werden. Zudem können beim Aufruf Veränderungen oder Hinzufügungen vorgenommen werden. Prozeduren sollte man sich daher im IOF-Menü anschauen. Wenn man verhindern will, daß die Prozedur ausgeführt wird, kann man in der JOB-Anweisung den Parameter TYPRUN=SCAN setzen. Auf diese Weise kann man zumindest den Zustand nach der Ersetzung von Variablen sehen. Leider gibt es keine Möglichkeit, die aktive JCL sichtbar zu machen, die nach Hinzufügungen oder Veränderungen wirksam wird. Bevor wir die JCL nach der Ersetzung betrachten, zunächst einmal ein typischer Aufruf der COBCL-Prozedur: edit-uwin.schulung.cntl(cl)

01.14

.

-

command

===>

columns 001 072 scroll ===> page

******

*****************************

000001 000002 000003 000004 000005 000006 000007

//uwinc job (998,abtdg02),1m.winter 1,class=a,notify=uwin, // msgclass=y,msglevel=(1,1) exec pr0c=c0bcl //step1 dd dsn=uwin.schulung.cobol(pgm05) ,disp=shr //cob.sysin //lked.syslmod dd dsn=uwin.schulung.load,disp=shr dd * //lked.sysin

******

****************************

name

Top of data

*****************************

pgm05(r)

Lassen Sie sich durch das, noch erläutert werden. Die Compile- und Aussehen:

was

bottom of data

auf den Zeilen 4-7

Link-Prozedur, die in

unserem

***************************

angegeben ist, nicht verwirren. Es wird

Beispiel aufgerufen wird,

hat

folgendes

MVS/ESA JCL

126 01.14

EDIT-USER.PROCLIB(COBCL)

.

-

COMMAND

===>

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020 000021 000022 000023 000024 000025 000026 000027 000028 000029 000030 000031 000032 000033

PROC ADV=,BUF=4K,DATA=31,DYNAM=,FDUMP=,FLAG=1 I,E1,LIB=,LN=68, //COBCL LIST=,LITCHAR=,MAP=,NUMPROC=NOPFD,OFFSET=,OPT=NOOPT,RES=, // RENT=,SEQ=NOSEQ,SSRANGE=,TEST=,TRUNC=STD,VBREF=,XREF=,ZWB=, // // OUT='*',VAL1=,VAL2= EXEC PGM=IGYCRCTL,C0ND=(8,LE), //COB PARM=(&ADV,IBUF(&BUF)',,DATA(&DATA),,&DYNAM,&FDUMP, // •F(&FLAG),,&LIB,ILC(&LN),,&LIST,&LITCHAR,&MAP, // 'NUMPROCC&NUMPROC)1,&OFFSET,&OPT,&RENT,&RES,&SEQ, // &SSRANGE.&TEST,'TRUNC(&TRUNC)',&VBREF,&XREF,&ZWB) // //STEPLIB DD DSN=SYS1.COB2COMP,DISP=SHR //SYSPRINT DD SYSOUT=&OUT

******

****************************

//SYSPUNCH //SYSUT1 //SYSUT2 //SYSUT3 //SYSUT4 //SYSUT5 //SYSUT6 //SYSUT7 //SYSLIN // //SYSIN //LKED // //SYSLIB // // // //SYSLIN //

Top OF DATA

DD

DUMMY,SYSOUT=B

DD

UNIT=SYSDA,SPACE=(CYL,(1,1))

DD UN IT=SYSDA,SPACE=(CYL,(1,1))

DD

IT=SYSDA,SPACE=(CYL,(1,1)) UNIT=SYSDA,SPACE=(CYL,(1,1)) UN IT=SYSDA,SPACE=(CYL,(1,1)) UNIT=SYSDA,SPACE=(CYL,(1,1)) UN IT=SYSDA,SPACE=(CYL,(1,1))

DD

DSN=&&LOADSET,DISP=(NEW,PASS),UNIT=SYSDA,

DD UN DD

DD DD

SPACE=(TRK,(3,3)),DCB=BLKSIZE=3200 DSN=&&LIBRA,DISP=(OLD,DELETE) EXEC PGM=IEWL,COND ((5,LT,COB),(8, LE)),

DD

=

DD

PARM=ILIST,XREF,LET,SIZE=(&VAL1,&VAL2)1 DSN=SYS1 .COB2LIB,DISP=SHR DSN=IMS.S2.PGMLINK,DISP=SHR

DD

DSN=USER.LOADLIB,DISP=SHR

DD

DSN=SYS1.ROUT874,DISP=SHR DSN=&&LOADSET,DISP=(OLD,DELETE)

DD

DD

DD DDNAME=SYSIN

//SYSLMOD DD DSN=USER.LOADLIB,DISP=SHR DD UN IT=SYSDA,SPACE = (TRK,(50,5)) //SYSUT1 //SYSPRINT DD SYSOUT=&OUT BOTTOM OF DATA

***************************

Weder die JCL, die die Prozedur aufruft, noch das Member, das die Prozedur enthält, geben wieder, was eigentlich geschieht. Aufschluß bringt erst der Zustand, der zur Laufzeit aktiv wird. Ihn kann

man

zumindest teilweise in der JCL des IOF sehen.

127

JCL-Prozeduren ****************************

xoP OF DATA

*******************************

1 //UWINC JOB (998,ABTDG02),'M.WINTER1,CLASS=A,NOT IFY=UWIN,MSGCLASS=Y MSGLEVEL=(1,1),USER=UWIN // EXEC PROC=COBCL 2 //STEP1 PROC OUT='*',VAL1=,VAL2= 3 XXCOBCL EXEC PGM=IGYCRCTL,COND=(8,LE), 4 XXCOB PARM='N00PT' XX 5 XXSTEPLIB DD DSN=SYS1.COB2COMP,DISP=SHR 6 XXSYSPRINT DD SYSOUT=&OUT SYSOUT=* IEF653I SUBSTITUTION JCL 7 XXSYSPUNCH DD DUMMY,SYSOUT=B -

8 9 10 11 12 13 14 15

XXSYSUT1 XXSYSUT2 XXSYSUT3 XXSYSUT4 XXSYSUT5 XXSYSUT6 XXSYSUT7

DD

XXSYSLIN

DD

DD DD DD DD DD

DD

UNIT=SYSDA,SPACE=(CYL, UNIT=SYSDA,SPACE=(CYL, UNIT=SYSDA,SPACE=(CYL, UNIT=SYSDA,SPACE=(CYL, UNIT=SYSDA,SPACE=(CYL, UNIT=SYSDA,SPACE=(CYL, UNIT=SYSDA,SPACE=(CYL, DSN=&&LOADSET,DISP=(NEW PASS),UNIT=SYSDA,

SPACE=(TRK,(3,3)),DCB=B

XX

KSIZE=3200

DD DSN=UWIN.SCHULUNG.COBOL(PGM05),DISP=SHR 16 //COB.SYSIN DD DSN=&&LIBRA,DISP=(OLD,DELETE) X/SYSIN EXEC PGM=IEWL,COND=((5,LT,COB),(8,LE)), 17 XXLKED

PARM='LIST,XREF,LET,SIZE=(&VAL1,&VAL2)'

XX

IEF653I SUBSTITUTION JCL

PARM=1 LI ST,XREF,LET,SIZE=(,)1 DSN=SYS1.COB2LIB,DISP=SHR DSN=IMS.S2.PGMLINK,DISP=SHR DSN=USER.LOADLIB,DISP=SHR DSN=SYS1.R0UT874,DISP=SHR DSN=&&LOADSET,DISP=(OLD,DELETE) -

18 XXSYSLIB 19 XX 20 XX 21 XX 22 XXSYSLIN

DD

DD DD DD DD

DD DDNAME=SYSIN 23 XX 24 //LKED.SYSLMOD DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR X/SYSLMOD DD DSN=USER.LOADLIB,DISP=SHR DD UNIT=SYSDA,SPACE=(TRK,(50,5)) 25 XXSYSUT1 26 XXSYSPRINT DD SYSOUT=&OUT IEF653I SUBSTITUTION JCL SYSOUT=* DD * 27 //LKED.SYSIN ******************************** BOTTOM OF DATA ******************************** -

Die Ausgabe umfaßt sowohl die JCL, mit denen die Prozedur aufgerufen wurde, als auch die der Prozedur. Die Herkunft der Anweisungen läßt sich am Identifikationsfeld erkennen. JCL-Anweisungen, mit der die Prozedur aufgerufen wurde, beginnen mit der Zeichenfolge '//'. JCL-Anweisungen der Prozedur selber beginnen mit 'XX'. Daneben gibt es noch die Zeichenfolge 'X/', die eine JCL-Anweisung der Prozedur markiert, die durch den Aufruf

128

MVS/ESA JCL

verändert wurde. Eine Übersicht über die verschiedenen Identifikationsfelder befindet sich auf der folgenden Seite. Im oben angegebenen Beispiel stammen die Anweisungen mit den Nummern 1,2, 16, 24 und 27 aus der aufrufenden JCL. Zeile 16 und 24 wurden geändert. Zeile 27 wurde

hinzugefügt.

Die Prozedur COBCL besteht aus zwei Steps: COB und LKED. Im Step COB wird das Quellprogramm kompiliert. Der Input für den Step COB, d.h. das COBOL Quellprogramm, wird unter dem DD-Namen SYSIN angesprochen. Der kompilierte Code wird in das temporäre Dataset &&LOADSET gestellt und dem Step LKED übergeben. Im Step LKED wird das Programm gelinkt und würde normalerweise auf die USER.LOADLIB gestellt. In diesem besonderen Fall wurde jedoch die SYSLMOD DDAnweisung geändert und das ausführbare Programm wird als Member auf die Bibliothek UWIN.SCHULUNG.LOAD gestellt.

Identifikationsfelder in Identifikation

katalogisierten Prozeduren: Bedeutung normale

JCL-Anweisung der aufrufenden JCL

XX

JCL-Anweisung der Prozedur bzw. fortgesetzte Anweisung

XI

beim Aufruf modifizierte

XX*

JCL-Anweisungen

JCL-Anweisung der Prozedur

der Prozedur, die in Kommentare

umgesetzt wurden (meist Hinweis auf Fehlerfall) Kommentare bzw. JES2

Kontrollanweisungen

Bis auf die Zeichenfolge XX* erkennen wir alle in der COBCL-Prozedur wieder. Werden Zeilen modifiziert, so steht die beim Aufruf übergebene Modifikation, die mit // beginnt, eine Zeile über der in der Prozedur vorhandenen Anweisung, die mit X/ beginnt (siehe

Anweisung 24).

Katalogisierte Prozeduren auf privaten Bibliotheken Mit der Einführung von MVS/ESA Vers. 4 besteht die Möglichkeit, katalogisierte Prozeduren auf private Bibliotheken zu stellen. Um diese Möglichkeit nutzen zu können, muß mit der JCLLIB-Anweisung gearbeitet werden.

129

JCL-Prozeduren

Die JCLLIB-Anweisung Syntax:

ORDER=(dsname,dsname,...,dsname)

// JCLLIB

Unter MVS/ESA Version 4 wird die

möglich, private

JCLLIB-Anweisung verfügbar werden.

Prozedurbibliotheken

zu

Mit ihr ist es definieren. Der Mechanismus ähnelt dem der

JOBLIB- und

STEPLIB-DD-Anweisungen. JCLLIB-Anweisung listet die Bibliotheken auf, die bei den EXEC PROCAnweisungen zu durchsuchen sind. Pro Job darf nur eine JCLLIB-Anweisung verwendet werden. Sie muß zwischen der JOB und der ersten EXEC-Anweisung stehen. Sie enthält Die

einen oder mehrere DSNs

von

Bibliotheken.

Beispiel: JOB (998,ABTDG02),CLASS=A,MSGCLASS=Y //UWINPROC // JCLLIB ORDER=(UWIN.SCHULUNG.PROCLIB,USER.PROCLIB)

//STEP1_EXEC TESTPROC_ Bei der obigen Angabe werden die beiden Bibliotheken in der angegebenen Reihenfolge nach einem Member namens TESTPROC durchsucht. Die SYS 1.PROCLIB wird nicht durchsucht! Falls dies geschehen soll, so muß auch ihr DSN in die Liste der DSNs aufgenommen werden.

Soll eine

JCLLIB-Anweisung fortgesetzt werden, so gilt:

1.

erste Zeile nach einem Komma beenden und

2.

auf der Fortsetzungszeile zwischen

Spalte 4 und

16

beginnen.

JOB (998,ABTDG02),CLASS=A,MSGCLASS=Y //UWINPROC // JCLLIB 0RDER=(UWIN.SCHULUNG.PROCLIB,USER.PROCLIB, // SYSUSER1.PROCLIB,SYSUSER2.PROCLIB)

//STEP1

EXEC

TESTPROC_

Möglichkeiten der Anpassung Beim Anpassen 1. 2.

3.

4.

von

Prozeduren gibt es

grundsätzlich vier Möglichkeiten:

EXEC- oder

DD-Anweisungen der Prozedur sollen abgeändert werden. Es sollen zusätzliche DD-Anweisungen aufgenommen werden. Parameter von EXEC- oder DD-Anweisungen der Prozedur sollen ungültig gemacht werden. Es sollen in einer Prozedur mit mehreren Steps sowohl Anweisungen zusätzliche Anweisungen aufgenommen werden.

geändert als auch

MVS/ESA JCL

130

Ändern von EXEC-Anweisungen In Prozeduren können EXEC- und DD-Anweisungen geändert werden (JOB-Anweisungen dürfen in Prozeduren nicht auftauchen). Das Ändern einer EXEC-Anweisung erfolgt nach

folgendem Schema: Syntax:

parameter.procstepname=wert Der

zu

ändernde Parameter wird als Teil der EXEC

Ändern einer EXEC-Anweisung soll auch

am

erläutert werden:

01.16

EDIT-UWIN.SCHULUNG.CNTL(CL)

Beispiel

Dieses des Aufrufs der COBCL-Prozedur

PROC-Anweisung kodiert.

.

-

COMMAND ******

===> *****************************

T0p OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

000001 //UWINC JOB (998,ABTDG02),'M.WINTER',CLASS=A,NOTIFY=UWIN, 000002 // MSGCLASS=Y,MSGLEVEL=(1,1) EXEC PROC=COBCL,TIME.COB=(0,5) 000003 //STEP1 000004 //COB.SYSIN DD DSN=UWIN.SCHULUNG.C0B0L(PGM05),DISP=SHR

000005 //LKED.SYSLMOD DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR 000006 //LKED.SYSIN DD * NAME PGM05(R) 000007 ****** **************************** BOTTOM OF DATA ***************************

Zeile 3 des Aufrufs wurde ergänzt:

//STEP1

EXEC

PROC=COBCL,TIME.COB=(0,5)

Durch diese Angabe wird für die EXEC-Anweisung im Step COB der TIME Parameter auf 5 Sekunden festgesetzt. Dadurch wurde diese EXEC-Anweisung abgeändert.

Prozeduren, die Programme kompilieren und linken, benötigen häufig den PARMParameter, um die Optionen für den Compiler setzen zu können:

//STEP1 //

PROC=COBCL, PARM.COB='NOOPT,LIB'

EXEC

Angabe bewirkt, daß für den Step COB die Compiler Optionen NOOPTimize und LIBrary gesetzt werden. Sollen für eine Prozedur, die aus mehreren Steps besteht, mehrere EXEC-Anweisungen überschrieben werden, so ist genau auf die Reihenfolge der Steps zu achten. Das folgende Beispiel bezieht sich auf eine fiktive Prozedur, die aus drei Steps besteht. Diese

JCL-Prozeduren In diesem

Beispiel

131

wird der TIME-Parameter für die

Steps STEP1, STEP2 und

STEP3

geändert:

//PROCSTEP EXEC TEST,TIME.STEP1=(,5), TIME.STEP2=(,15), // TIME.STEP3=1 // Wird, wie im folgenden Beispiel, die richtige Reihenfolge nicht eingehalten, kommt es bei der Ausfuhrung der Prozedur zu einem Fehler:

//PROCSTEP // //

TEST,TIME.STEP1=(,5), TIME.STEP3= (,15) EXEC

,

TIME.STEP2=1

Die Überschreibung von STEP1 und STEP3 funktioniert zwar noch, die Ersetzung bei STEP2 kann aber nicht mehr durchgeführt werden, da innerhalb der Prozedur bei der Ersetzung nicht beliebig vorwärts und rückwärts gesprungen werden kann. Die Fehlermeldung selbst klingt etwas irreführend:

IEF611I

OVERRIDDEN STEP NOT FOUND IN PROCEDURE

Dies könnte schließen lassen, daß der angesprochene aber nur die Reihenfolge im Aufruf falsch. Ein Hinzufugen von neuen Prozedur ist nicht möglich.

Steps mit Hilfe

von

Step nicht existiert.

EXEC-Anweisungen

Tatsächlich

war

beim Aufruf einer

Ändern von DD-Anweisungen Will man

DD-Anweisungen überschreiben, so gilt folgende Syntax:

//procstepname.ddname DD parameter=wert Während Änderungen von EXEC-Anweisungen als Teil der EXEC PROC-Anweisung kodiert werden, folgen die geänderten DD-Anweisungen auf die EXEC PROC-Anweisung. Es braucht nur der DD-Parameter angegeben werden, der geändert werden soll. Es ist nicht erforderlich, die komplette DD-Anweisung neu zu kodieren.

//COB.SYSUT1

DD

SPACE=(CYL, (2,1))

Durch diese Angabe wird dem Workdataset SYSUT1 im Step COB mehr Platz zugewiesen. Die Angabe im UNIT-Parameter bleibt unverändert. Während das oben angegebene Beispiel keinerlei praktische Bedeutung besitzt, wird das folgende Beispiel in der Praxis häufig eingesetzt. Es geht darum, ein gelinktes Programm auf eine private Ladebibliothek zu stellen. Dazu werden Angaben der SYSLMOD DD-

MVS/ESA JCL

132

Anweisung geändert. seinen

Unter SYSLMOD

(SYS

Load

Output ab.

//LKED.SYSLMOD

DD

MODule) stellt

das

Programm

IEWL

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

Hier wird im Step LKED die DD-Anweisung mit dem Namen SYSLMOD geändert. Es werden nur der oder die geänderten Parameter angegeben. In diesem Beispiel handelt es sich dabei um den DSN- und den DISP-Parameter. Dadurch wird das ausführbare Programm nicht auf die USER.LOADLIB, sondern auf die private Ladebibliothek UWIN.SCHULUNG.LOAD gestellt. Leider sieht der Output für diese Form der Überschreibung nicht besonders übersichtlich aus, da die geänderten und die ursprünglichen Parameter zusammen ausgegeben werden. Dies sieht dann BROWSE

JCL

folgendermaßen aus: *

PAGE 1-- LINE 24 //LKED.SYSLMOD DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR X/SYSLMOD DD DSN=USER.LOADLIB,DISP=SHR DD UNIT=SYSDA,SPACE=(TRK,(50,5)) 25 XXSYSUT1 26 XXSYSPRINT DD SYSOUT=&OUT IEF653I SUBSTITUTION JCL SYS0UT=* DD * 27 //LKED.SYSIN -

28-- COLS

1

80

--

-

*******************************

BOTTOM OF DATA

********************************

Zeile 24 zeigt die Anweisung, so wie sie beim Aufruf angegeben wurde. Daher beginnt die Zeile mit //. Auf der Folgezeile findet sich die Anweisung, auf die sich die Überschreibung bezieht. Sie beginnt mit der Zeichenfolge X/. Dadurch wird kenntlich gemacht, daß diese Anweisung überschrieben wurde. Sie wird allerdings unverändert dargestellt, also auch mit den Parametern, die eigentlich überschrieben worden sind. So steht in der Ausgabe zwar noch DSN=USER.LOADLIB, effektiv geworden ist aber der Parameter DSN=UWlN.SCHULUNG.LOAD, wie es in der Überschreibung angegeben ist. Die optische Darstellung des Outputs ist äußerst verwirrend und vielleicht mit ein Grund dafür, daß die Benutzung von Prozeduren nicht so schrecklich populär ist.

Hinzufügen von DD-Anweisungen Neben der Möglichkeit, bestehende DD-Anweisungen zu ändern, können katalogisierten Prozeduren auch zusätzliche DD-Anweisungen mitgegeben werden. Beim Einfügen von Anweisungen gelten die gleichen Syntaxregeln wie für die Änderungen von DD-Anweisungen. Beim Aufruf der Prozedur müssen erst die Änderungen von DD-Anweisungen erfolgen und dann die Hinzufügungen. Im folgenden Beispiel wird Prozedur COBCL um ein Dataset mit dem DD-Namen SYSLIB ergänzt. Dies ist von Bedeutung, wenn beim Compile mit der LIB Option gearbeitet wird.

133

JCL-Prozeduren EDIT

---

01.16

UWIN.SCHULUNG.CNTL(CL)

.

-

COMMAND

===>

fop OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

******

****************************

000001 000002 000003 000004 000005 000006 000007

//UWINC JOB (998,ABTDG02),'M.WINTER",CLASS=A,NOTIFY=UWIN, // MSGCLASS=Y,MSGLEVEL=(1,1) EXEC PROC=COBCL,PARM.COB=1NOOPT,LIB1 //STEP1 DD DSN=UWIN.SCHULUNG.COBOL(PGM05),DISP=SHR //COB.SYSIN DD DSN=UWIN.SCHULUNG.COPYLIB,DISP=SHR //COB.SYSLIB DD * //LKED.SYSIN NAME PGM05(R)

******

****************************

BOTTOM OF DATA

**************************

Gleichzeitiges Einfügen und Ändern von Anweisungen

Häufig ist es nötig, beim Aufruf von Prozeduren sowohl Anweisungen zu ändern, als auch neue Anweisungen mitzugeben. Hierbei ist genau auf die Reihenfolge der Steps innerhalb der Prozedur zu achten.

Es

gilt folgende Regel:

Zunächst werden alle Änderungen von EXEC-Anweisungen angegeben. Dabei ist auf die Reihenfolge der Steps zu achten. Dann werden Änderungen von DD-Anweisungen für den ersten Step angeben, dann zusätzliche DD-Anweisungen. Danach folgen Änderungen für den nächsten Step, dann Ergänzungen für den nächsten Step usw. In der Prozedur COBCL muß im Step COB unter dem DD-Namen SYSLIB der Name des Dataset stehen, auf dem die Copy-Member für den COBOL Compile stehen. Die Prozedur ist um diesen DD-Namen zu ergänzen. SYSLMOD soll eine

geändert werden.

private

Ladebibliothek sein. Die

DD-Anweisung

muß

entsprechend

So sieht der Aufruf aus: 01.16

EDIT-UWIN.SCHULUNG.CNTL(CL) -

COMMAND

.

===>

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

******

*****************************

000001 000002 000003 000004

//UWINC JOB (998,ABTDG02),'M.WINTER',CLASS=A,NOTIFY=UWIN, // MSGCLASS=Y,MSGLEVEL = (1,1)

******

****************************

//STEP1

EXEC

TOP OF DATA

PR0C=C0BCL,PARM.C0B= NOOPT,LIB'

DD DSN=UWIN-SCHULUNG.COBOL(PGM05),DISP=SHR //COB.SYSIN DD DSN=UWIN.SCHULUNG.COPYLIB,DISP=SHR 000005 //COB.SYSLIB 000006 //LKED.SYSLMOD DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DD * 000007 //LKED.SYSIN NAME PGM05(R) 000008 BOTTOM OF DATA

***************************

MVS/ESA JCL

134

ist, daß die Anweisungen COB.SYSIN und COB.SYSLIB in der angegeben Wird die Reihenfolge vertauscht, so wird die Anweisung COB.SYSIN der Prozedur nicht mehr überschrieben. Als Name des Input Datasets steht

Zu beachten

Reihenfolge erfolgen. dann &&LIBRA und

es

kommt zu einem JCL-Error.

Ungültigmachen von Anweisungen Bisweilen kann es erforderlich werden, Teile von JCL-Anweisungen, die sich in der Prozedur befinden, ungültig zu machen. In diesem Fall wird der Parameter beim Aufruf der Prozedur auf blank gesetzt.

Beispiel verdeutlicht werden: Die Prozedur WAHNSINN besteht aus zwei Steps, Dies soll

an

einem

STEP1 und STEP2. Jeder

Zeitlimit:

//STEP1 //.... //.... //.... //STEP2

EXEC

PGM=XY,TIME=(,30)

EXEC

PGM=ABC,TIME=(,10)

Step hat ein

Beim Aufruf der Prozedur soll nun das Zeitlimit von STEP1 ungültig gemacht werden, das Zeitlimit von STEP2 soll auf 30 Sekunden erhöht werden. Dies geschieht auf folgende Weise:

//PROCSTEP //

EXEC WAHNSINN,

TIME.STEP1=,TIME.STEP2=(,30)

Besonderheiten bei Concatenated Data Sets

Beim Ändern

Parametern innerhalb verketteter (concatenated) Datasets sind besondere Am Beispiel der SYSLIB DD-Anweisung im Step LKED der beachten. Syntaxregeln Prozedur COBCL soll die Art und Weise der Überschreibung verdeutlicht werden. SYSLIB 4 besteht aus verketteten Datasets. Bei der dritten soll nun der DSN=UWIN.SCHULUNG.COPYLIB anstelle von USER.LOADLIB stehen. von

zu

JCL-Prozeduren

135

Der Aufruf der Prozedur COBCL muß dann

so

01.16

edit-uwin.schulung.cntl(cl)

aussehen: .

-

command ******

===> *****************************

top of data

columns 001 072 scroll ===> page

*****************************

000001 //uwinc job (998,abtdg02),'m.winter1,class=a,notify=uwin, 000002 // msgclass=y,msglevel=(1,1) exec proc=cobcl,parm.cob=1noopt,lib1,time=(,10) 000003 //step1 dd dsn=uwin.schulung.cobol(pgm05),disp=shr 000004 //cob.sysin 000005 //lked.syslib dd dd 000006 // dd dsn=uwin.schulung.copylib,disp=shr 000007 // dd * 000008 //lked.sysin name pgm05(r) 000009 ******

****************************

bottom of data

***************************

Für jede nicht geänderte Zeile steht eine DD-Anweisung mit blank. Die zu ändernde Zeile wird angegeben. Nachfolgende Zeilen brauchen nicht angegeben zu werden, sofern keine weitere Änderung erfolgt.

Will

ein weiteres oder mehrere Datasets der Konkatenation hinzufügen, so verfährt ähnlich. Dies läßt sich ebenfalls am Beispiel der SYSLIB DD-Anweisung im Step LKED demonstrieren. Zusätzlich zu den bereits angegebenen soll das Dataset SYS1.ROUT875 konkateniert werden: man

man

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011

//uwinc job (998,abtdg02),'m.winter',class=a,notify=uwin, // msgclass=y,msglevel=(1,1)

******

//step1

exec

//cob.sysin //cob.syslib // // // // //lked.sysin name

top of data

*****************************

pr0c=c0bcl,parm.cob='noopt,lib',time=(,10) dsn=uwin.schulung.cobol(pgm05),disp=shr

dd dd dd

dd dd dd

dsn=sys1.r0ut875,disp=shr

dd

*

pgm05(r)

****************************

In diesem Fall folgen auf die vier leeren

bottom of data

***************************

DD-Anweisungen das zu ergänzende Dataset.

Beeinflussen der gesamten Prozedur Neben der Möglichkeit, die Anweisungen einzelner Steps abzuändern bzw. zu ergänzen, können auch Parameter, die die gesamte Prozedur beeinflussen, eingesetzt werden. In diesem Fall steht bei den zusätzlichen Parametern auf der EXEC-Ebene kein Stepname. Auf diese Art und Weise lassen sich nur EXEC-Anweisungen überschreiben.

MVS/ESA JCL

136

01.16

edit-uwin.schulung.cntl(cl)

.

-

command ******

===> *****************************

jqp of data

columns 001 072 scroll ===> page

*****************************

000001 //uwinc job (998,abtdg02),'m.winter',class=a,not ify=uwin, 000002 // msgclass=y,msglevel=(1,1) exec proc=cobcl,parm.cob=1noopt,lib',time=(,10) 000003 //step1 dd dsn=uwin.schulung.cobol(pgm05),disp=shr 000004 //cob.sysin dd unit=sysda,space=(cyl,(1,1)) 000005 //c0b.sysut8 000006 //lked.syslmod dd dsn=uwin.schulung.load,disp=shr dd * 000007 //lked.sysin name pgm05(r) 000008 ****** **************************** bottom of data ***************************

obigen Beispiel steht für die gesamte Prozedur nur noch 10 CPU Sekunden zur Verfügung. Man beachte den Unterschied zum Überschreiben einer EXEC-Anweisung für einen bestimmten Step. Eine Ausnahme bildet der PARM-Parameter. Er gilt nur für den ersten Step, auch dann, wenn er ohne Stepnamen angegeben wurde. Übersicht über Gültigkeit der Parameter auf EXEC Ebene: Im

COND

gilt für alle Steps der Prozedur

PARM

gilt

REGION

Sift ^ur a^e Steps der Prozedur

TIME

gilt für alle Steps der Prozedur

3.2 Wie

nur für den ersten Step der Prozedur sollten weitere PARM-Parameter besitzen, so werden diese ignoriert

Steps

Eigene Prozeduren schreiben man

bereits

an

der COBCL-Prozedur

gesehen hat,

ist

es

sehr

sinnvoll,

von

vielen

Benutzern häufig genutzte JCL in Form einer Prozedur auf die SYS1.PROCLIB zu stellen. Der Benutzer kann die Prozedur beim Aufruf seinen eigenen Bedürfnissen anpassen, ohne dabei den JCL-Quellcode der Prozedur selbst ändern zu müssen.

Was für das Kompilieren und Linken gilt, ist auch für Anwendungsprogramme gültig. Auch sie können in einer Prozedur zusammengefaßt werden. Der Aufruf ist recht einfach. Wer entsprechende Dialog Manager und CLIST bzw. REXX Kenntnisse besitzt, kann sogar Panels entwickeln, die wenig erfahrenen Benutzern das Submitten von Jobs/Prozeduren ermöglichen. Bei der Übernahme von Jobs in die Produktion sind häufig Änderungen notwendig. Werden Prozeduren benutzt, so muß nur der Aufruf geändert wer-

JCL-Prozeduren

137

den. Für die Datasets können in der Prozedur symbolische Namen vergeben werden. Dies hat den Vorteil, daß die Prozedur bei Übergabe an die Produktion nicht geändert werden muß. Es ändert sich lediglich der Aufruf, bei dem die symbolischen Namen belegt werden.

Solange die Version 4 von MVS/ESA noch nicht verfügbar ist, müssen

Sie Prozeduren als In-Stream-Prozeduren erstellen. Sie sehen ein wie normales Member einer aus sogenannte CNTL-Bibliothek. In-Stream-Prozeduren, die fertig und ausgetestet sind, werden als katalogisierte Prozeduren auf die entsprechende PROCLIB gestellt. Lassen Sie sich von dem Begriff 'katalogisiert' nicht verwirren. Er hat hier eine andere Bedeutung als bei einem Dataset. Selbstverständlich entwickeln Sie Ihre Prozeduren auf einer Bibliothek, die katalogisiert ist.

In-Stream-Prozeduren Um

einem normalen Job eine In-Stream-Prozedur zu machen, genügt die Angabe zusätzlicher einiger JCL-Anweisungen. Jede In-Stream-Prozedur benötigt ein ganz normale JOB-Anweisung. Auf sie folgt die Prozedur, deren Anfang und Ende markiert werden. Nach der Ende-Anweisung wird die Prozedur sofort aufgerufen. aus

Zunächst einmal muß MVS Anfang und Ende der Prozedur angezeigt werden. Außerdem benötigt die Prozedur einen Namen. Mit Hilfe der PROC- und PEND- Anweisungen wird diese Aufgabe gelöst. edit-uwin.schulung.cntl(proc01)

01.16

.

-

command

===>

columns 001 072 ===> page

scroll

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013

//uwinc job (998,abtdg02),'m.winter1,class=a,notify=uwin,msgclass=y proc //test exec pgm=pgm01 //step1 //steplib dd dsn=uwin.schulung.load,disp=shr dd dsn=uwin.schulung.testdat.januar.input,disp=shr //input dd dsn=uwin.schulung.testdat.januar.output, //output // disp=(new,catlg,delete), // unit=dskprm,space=(cyl,(5,1),rlse), // recfm=fb,lrecl=234 //sysprint dd sysout=* dd sysout=* //sysout pend // exec test //do

******

****************************

yop of data

*****************************

bottom of data

***************************

Bis auf die Zeilen 2, 12 und 13 gleicht die JCL einem normalen Job. In Zeile 2 wird der Prozedur ein Name zugewiesen, der

wiederverwendet wird.

später beim Aufruf

MVS/ESA JCL

138

Syntax:

//procname PROC Damit ist der Anfang der Prozedur markiert und ein Name zugewiesen. Das Ende eine Prozedur wird durch die PEND- (Procedure END) Anweisung in Zeile 12 angezeigt. Ein Feldname darf nicht angegeben werden.

Syntax:

// PEND Um die Prozedur ausführen zu lassen, muß sie jetzt einer EXEC-Anweisung in Zeile 13.

nur

noch aufrufen. Dies

geschieht mit

Syntax:

//stepname EXEC procname Keine Fehler vorausgesetzt, wird die Prozedur normalen Job eine In-Stream-Prozedur geworden.

In-Stream-Prozeduren verwenden die Identifikation

jetzt ausgeführt.

Somit ist

aus

einem

folgenden Identifikationsfelder:

Bedeutung normale JCL-Anweisung

++

JCL-Anweisung der Prozedur bzw. fortgesetzte Anweisung

+/

beim Aufruf modifizierte JCL-Anweisung der Prozedur

++*

JCL-Anweisungen der Prozedur, (meist Hinweis auf Fehlerfall) Kommentare bzw. JES2

die in Kommentare umgesetzt wurden

Kontrollanweisungen

139

JCL-Prozeduren Die JCL, die im IOF-Menü für eine In-Stream-Prozedur aus (Fortsetzung auf der folgenden Seite): ********************************

TOP OF DATA

ausgegeben wird,

sieht wie

folgt

**********************************

1 //UWINC JOB (998,ABTDG02),'M.WINTER', CLASS=A,NOTIFY=UWIN,MSGCLASS=Y II TIME=(,05),MSGLEVEL=(1,1),TYPRUN=SCAN,USER=UWIN PROC //TEST EXEC PGM=PGM01 //STEP1

//STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* DD SYS0UT=* //SYSOUT DD DSN=UWIN.SCHULUNG.TESTDAT,JANUAR.INPUT,DISP=SHR //INPUT DD DSN=UWIN.SCHULUNG.TESTDAT,JANUAR.OUTPUT, //OUTPUT // DISP=(,CATLG,DELETE), // UNIT=DSKPRM,SPACE=(CYL,(5,1),RLSE), // RECFM=FB,LRECL=234, // PEND 2 //DO EXEC TEST PROC 3 ++TEST EXEC PGM=PGM01 4 ++STEP1 5 ++STEPLIB 6 ++INFILE

DD DD

DISP=SHR

++

7 ++0UTPUT ++ ++ ++

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DSN=UWIN.SCHULUNG.TESTDAT,JANUAR.INPUT,

DD

DSN=UWIN.SCHULUNG.TESTDAT,JANUAR.OUTPUT, DISP=(,CATLG,DELETE), UNIT=DSKPRM,SPACE=(CYL,(5,1),RLSE), RECFM=FB,LRECL=234,

8 ++SYSPRINT DD SYSOUT=* 9 ++SYSOUT DD SYSOUT=* *******************************

BOTTOM OF DATA

*******************************

Zunächst erscheinen die JCL-Anweisungen in der Reihenfolge, in der sie eingegeben wurden. Sie werden jedoch nicht numeriert. Die JOB-Anweisung hat die Nummer 1, die zweite Anweisung ist DO EXEC TEST.

Wie katalogisierte Identifikationsfelder.

Prozeduren

haben

auch

In-Stream-Prozeduren

besondere

Symbolische Parameter einsetzen Das zuletzt gezeigte Beispiel unterscheidet sich kaum von normaler JCL, sieht man einmal von der PROC-, PEND- und der zusätzlichen EXEC-Anweisung ab. Man erkennt auch, daß der DSN Bestandteil 'JANUAR' zweimal vorkommt und kann sich unschwer vorstellen, daß dieser Parameter bei der Verarbeitung im Folgemonat geändert werden muß. Diese Änderungen lassen sich mit Hilfe symbolischer Parameter vereinfachen.

MVS/ESA JCL

140

Symbolische Parameter sind nichts anderes als Platzhalter, die vom JES bei der der Prozedur eingesetzt werden. Im oben angegebenen Beispiel würde dies folgendermaßen aussehen: Statt

//

Auflösung

DD DSN=TJWIN. SCHULUNG. TESTDAT JANUAR. INPUT .

wird

//

DD DSN=UWIN.SCHULUNG.TESTDAT.&MONAT..INPUT

angegeben. Der '&' vor MONAT zeigt an, daß es sich um einen symbolischen Parameter handelt. Der Inhalt des symbolischen Parameters wird normalerweise beim Aufruf der Prozedur mitgegeben.

Wertzuweisungen für symbolische Parameter Direkt im Anschluß an den Aufruf der Prozedur können die Variablen besetzt werden. Dabei darf dem Variablennamen kein & vorangestellt werden.

//PROCSTEP

EXEC

TEST,MONAT=JANUAR

Beim Lesen der Prozedur sucht JES nach einem Parameter mit der Bezeichnung MONAT und ersetzt in der Prozedur den symbolischen Parameter durch den zugeordneten Wert. In der JCL im IOF-Menü wird sowohl der symbolische Parameter als auch die vorgenommene Ersetzung, die durch die Meldung IEF653I erkennbar ist, ausgegeben.

141

JCL-Prozeduren BROWSE

*

JCL

PAGE

COMMAND

1-- LINE

1-- COLS

1

80

--

-

SCROLL

===>

********************************

1 //UWING JOB

// //TEST

-pop op DATA

===>

SCREEN

**********************************

(998,ABTDG02),'M.WINTER1,CLASS=A,NOTIFY=UWIN,MSGCLASS=Y TIME=(,05),MSGLEVEL=(1,1),TYPRUN=SCAN,USER=UWIN PROC

EXEC PGM=PGM2 //STEP1 DD //STEPLIB DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=*

//SYSABOUT DD SYSOUT=* DD SYSOUT=* //SYSOUT DD DSN=UWIN.TEST.&MONAT..INPUT,DISP=SHR //INFILE //OUTFILE DD DSN=UWIN.TEST.&MONAT..OUTPUT,DISP=(,CATLG,DELETE), // RECFM=FB,LRECL=80, // SPACE=(TRK,(5,1),RLSE), UNIT=3380 // // PEND 2 //DO EXEC TEST,MONAT=JANUAR PROC 3 ++TEST 4 ++STEP1 EXEC PGM=PGM2 5 ++STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR 6 ++SYSPRINT DD SYSOUT=* 7 ++SYSABOUT DD SYSOUT=* DD SYSOUT=* 8 ++SYSOUT ++INFILE DD 9 DSN=UWIN.TEST.&MONAT..INPUT,DISP=SHR IEF653I SUBSTITUTION JCL DSN=UWIN.TEST.JANUAR.INPUT,DISP=SHR 10 ++OUTFILE DD DSN=UWIN.TEST.&MONAT..OUTPUT,DISP=(,CATLG,DELETE), IEF653I SUBSTITUTION JCL DSN=UWIN.TEST.JANUAR.OUTPUT,DISP=(,CATLG -

-

++ ++ ++

RECFM=FB,LRECL=80, SPACE=(TRK,(5,1),RLSE), UNIT=3380

*******************************

BOTTOM OF DATA

********************************

MVS/ESA JCL

142

Bei der Ersetzung symbolischer Parameter sieht der Output ganz vernünftig aus. Leider gilt aber auch bei In-Stream-Prozeduren, daß bei Überschreibungen bzw. Hinzufügungen von Parametern der Output genauso schlimm aussieht wie bei katalogisierten Prozeduren. Im folgenden Beispiel wurde der SPACE-Parameter von OUTFILE geändert: 000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016

//UWING JOB (998,ABTDG02),'M.WINTER1,CLASS=A,NOTIFY=UWIN, HSGCLASS=Y // PROC //TEST EXEC PGM=PGM2 //STEP1 //STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSABOUT DD SYSOUT=* DD SYSOUT=* //SYSOUT DD DSN=UWIN.TEST.&MONAT..INPUT,DISP=SHR //INFILE //OUTFILE DD DSN=UWIN.TEST.&MONAT..OUTPUT,DISP=(,CATLG,DELETE), // RECFM=FB,LRECL=80, // SPACE=(TRK,(5,1),RLSE), UNIT=3380 // // PEND //DO EXEC TEST,M0NAT=JANUAR

******

****************************

//STEP1.OUTFILE DD SPACE=(TRK,(10,3)) BOTTOM OF DATA

***************************

143

JCL-Prozeduren Der

Output sieht folgendermaßen aus:

BROWSE COMMAND

*

JCL

1-- LINE

PAGE --

-

===>

TOP OF DATA

********************************

1 //UWING JOB

// //TEST

1 80 1-- COLS SCROLL ===> SCREEN

**********************************

(998,ABTDG02),'M.WINTER',CLASS=A,NOTIFY=UWIN,MSGCLASS=Y TIME (,05),MSGLEVEL=(1,D,TYPRUN=SCAN,USER=UWIN =

PROC

EXEC PGM=PGM2 //STEP1 //STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=*

//SYSABOUT DD SYSOUT=* DD SYSOUT=* //SYSOUT DD DSN=UWIN.TEST.&MONAT. INPUT,DISP=SHR //OUTFILE DD DSN=UWIN.TEST-&MONAT..OUTPUT,DISP=(,CATLG,DELETE), // RECFM=FB,LRECL=80, // SPACE=(TRK,(5,1),RLSE), UNIT=3380 // // PEND 2 //DO EXEC TEST,MONAT=JANUAR PROC 3 ++TEST EXEC PGM=PGM2 4 ++STEP1 5 ++STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR 6 ++SYSPRINT DD SYSOUT=* 7 ++SYSABOUT DD SYSOUT=*

//i'NFILE

8 ++SYSOUT 9 ++INFILE

.

DD SYSOUT=*

DSN=UWIN.TEST.&MONAT..INPUT,DISP=SHR DSN=UWIN.TEST.JANUAR.INPUT,DISP=SHR 10 //STEP1.OUTFILE DD SPACE=(TRK,(10,3)) +/0UTFILE DD DSN=UWIN.TEST.&MONAT..OUTPUT,DISP=(,CATLG.DELETE), IEF653I SUBSTITUTION JCL DSN=UWIN.TEST.JANUAR.OUTPUT,DISP=(,CATLG ++ RECFM=FB,LRECL=80, ++ SPACE=(TRK,(5,1),RLSE), DD

IEF653I SUBSTITUTION JCL

-

-

++

UNIT=3380

*******************************

BOTTOM OF DATA

********************************

Man kann nicht gerade behaupten, daß dieser Output übersichtlich sei. Auf Zeile 10 erkennt die beim Aufruf geänderte DD-Anweisung mit dem SPACE-Parameter. Hinzu kommt noch die Ersetzung des symbolischen Parameters &MONAT. jetzt man

sieht, ist das Problem das gleiche wie bei katalogisierten Prozeduren. Vorsicht muß man walten lassen, wenn entweder mehrere symbolische Parameter Wie man

hintereinander gehängt werden oder auf den symbolischen Parameter weitere Angaben folgen. Der erste nach einem symbolischen Parameter auftretende Punkt wird als Ende-

MVS/ESA JCL

144

Markierung für diesen

Parameter interpretiert. Man muß aufpassen, daß einem die die die verschiedenen Teile des DSNs voneinander trennen, nicht verlorengehen.

Punkte,

Würde anstelle:

//EIN1

DD DSN=UWIN.SCHULUNG.TESTDAT.&MONAT..INPUT

//EIN1

DD DSN=UWIN.SCHULUNG.TESTDAT.&MONAT.INPUT

stehen, so würde der DSN folgendermaßen aufgelöst:

//EIN1

DD DSN=UWIN.SCHULUNG.TESTDAT.JANUARINPUT

Die Folge wäre ein JCL-Fehler, da der DSN-Bestandteil JANUARINPUT mehr als 8 Zeichen lang ist.

gibt es zwei Möglichkeiten, dieses Problem zu lösen: Durch Anhängen des Punktes in der Wertzuweisung, also: Grundsätzlich

//PROCNAME

PROC MONAT='JANUAR.'

oder das Begrenzen des symbolischen Parameters mit einem Punkt. In diesem Fall stehen dann zwei Punkte hintereinander, der erste zeigt das Ende des symbolischen Parameters an, der zweite trennt die Bestandteile des DSN voneinander:

//EIN1

DD DSN=UWIN.SCHULUNG.TESTDAT.&MONAT..INPUT

Die erste Möglichkeit, den Punkt in die Wertzuweisung zu nehmen, in diesem Fall müssen Anführungsstriche stehen, da der Punkt als ein Sonderzeichen interpretiert wird -

bedingt empfohlen werden, angegebene symbolische Parameter am kann

da Probleme auftreten können, wenn der so Ende eines DSN steht. In diesem Fall darf der Punkt nicht stehen. Aus diesem Grande ist die zweite Möglichkeit, das Einfügen eines weiteren Punktes in der Prozedur, vorzuziehen. -

nur

folgende Beispiel soll erläutern, wie die Prozedur wird folgendermaßen aufgerufen: Das

//STEP

EXEC

Ersetzung von Platzhaltern funktioniert.

TEST,VAR1=COPY,VAR2=LIB

Eine

145

JCL-Prozeduren

JCL in Prozedur

Auflösung durch JES

DSN=&VAR1 DSN=&VAR2 DSN=&VAR1&VAR2 DSN=&VAR1.&VAR2 DSN=&VAR1..&VAR2 DSN=TEST&VAR2 DSN=&VAR1.DATA DSN=&VAR1..DATA DSN=&VAR1.A

DSN DSN DSN DSN DSN DSN DSN DSN DSN

Die Punkte sind ungeheuer Wäre in der Prozedur:

wichtig.

Im letzten

COPY LIB COPYLIB COPYLIB COPY.LIB TESTLIB COPYDATA COPY.DATA COPYA

Beispiel wurde der DSN=COPYA erzeugt.

DSN=&VAR1A

angegeben worden, so hätte JES nach dem Variablennamen: VARIA gesucht und ihn nicht gefunden. Das Resultat wäre ein JCL-Fehler gewesen. Bisher haben wir nur Beispiele betrachtet, in denen der DSN oder Teile von ihm als symbolische Parameter verwandt wurden. Symbolische Parameter können anstelle jedes Parameters stehen. So kann z.B. eine Output-Klasse variabel gesteuert werden. Ebenso lassen sich Zuweisungen für den SPACE-Parameter treffen. Um in unserer Beispielprozedur zu bleiben. Nicht immer soll der Output ins IOF-Menü gestellt werden. Manchmal will man ihn auch drucken lassen. Dies läßt sich erreichen, wenn anstelle des * ein symbolischer Parameter steht, wie in folgendem Beispiel gezeigt wird:

MVS/ESA JCL

146

edit-uuin.schulung.cntl(procoi)

01.16

---.

-

command ******

===>

*****************************

jqp op data

columns 001 072 scroll ===> page

*****************************

000001 //uuinc job (998,abtdg02),'m.winter',class=a,not ify=uwin, 000002 // msgclass=y,msglevel=(1,1) proc 000003 //test exec pgm=pgm01 000004 //step1 000005 //steplib dd dsn=uwin .schulung.load,disp=shr dd dsn=uwin.schulung.testdat.&monat..input,disp=shr 000006 //input dd dsn=uwin.schulung.testdat.&monat..output, 000007 //output 000008 // disp=(new,catlg,delete), 000009 // unit=dskprm, 000010 // recfm=fb,lrecl=234, 000011 // space=(cyl,(1,1),rlse) 000012 //sysprint dd sys0ut=&0ut dd sysout=&out 000013 //sysout 000014 // pend exec test,out=a,monat=januar 000015 //do ******

****************************

bottom of data

***************************

Bei SYSPRINT und SYSOUT wird der symbolische Parameter &OUT durch A ersetzt. Dadurch wird der dort erzeugte Output unmittelbar auf den Drucker gelegt.

SYSIN und Prozeduren Sie werden wahrscheinlich bemerkt haben, daß in den bisher gezeigten Beispielen kein IDCAMS-Step vorangestellt war, der den Katalog bereinigt hätte. Insofern hätte ein mehrfaches Ausfuhren der Prozedur einen NOT CATLGD 2-Fehler zur Folge, unter SMS wäre es sogar zu einem Abbruch des Jobs gekommen. Das Problem besteht darin, daß IDCAMS eine SYSIN-Anweisung braucht, über die die Steueranweisungen gegeben werden. Innerhalb von Prozeduren ist jedoch die Benutzung von DD * Anweisungen verboten. Man kann deshalb auch nicht die Anweisung SYSIN DD * einsetzen. Um das Problem zu lösen, muß die Übergabe der SYSIN-Parameter außerhalb der Prozedur erfolgen. Dazu kann die SYSIN DD DDNAME-Anweisung eingesetzt werden. Die SYSIN DD

DDNAME-Anweisung

Syntax: //SYSIN DD DDNAME=ddname DDNAME-Anweisung verschiebt die inhaltliche Beschreibung des Feldes auf einen späteren Zeitpunkt im Job. Auf diese Weise wird eine in der Prozedur unzulässige DD *

Die

147

JCL-Prozeduren vermieden. Statt dessen werden die IDCAMS außerhalb der Prozedur übergeben.

Anweisung Wie dies

für das

Programm

geschehen kann, soll am folgenden Beispiel verdeutlicht werden:

EDIT-UWIN. SCHULUNG.CNTL(PROC01) COMMAND ===> ******

Kontrollanweisungen

*****************************

01.16

.

-

yep OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

000001 //UWINC JOB (998,ABTDG02),'M.WINTER1 ,CLASS=A,NOTIFY=UWIN, 000002 // MSGCLASS=Y,MSGLEVEL=(1,1) 000003 //TEST PROC EXEC PGM=IDCAMS 000004 //CLRCAT 000005 //SYSPRINT DD SYSOUT=* 000006 //SYSIN 000007 //STEP1

DD DDNAME=LOESCH

000008 000009 000010 000011 000012 000013 000014 000015

DD

000016 000017 000018 000019 000020 000021 ******

//STEPLIB //INPUT //OUTPUT // // // // //SYSPRINT //SYSOUT // PEND //DO //LOESCH

EXEC PGM=PGM01

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

DSN=UWIN.SCHULUNG.TESTDAT.&MONAT..INPUT.DISP=SHR DSN=UWIN.SCHULUNG.TESTDAT.&MONAT..OUTPUT, DISP=(NEW,CATLG,DELETE), DD DD

UNIT=DSKPRM,

RECFM=FB,LRECL=234, SPACE=(CYL,(1,1),RLSE) DD SYSOUT=&OUT DD SYSOUT=&OUT

EXEC TEST,OUT=A,MONAT=JANUAR DD * DELETE UWIN.SCHULUNG .TESTDAT.JANUAR.OUTPUT IF MAXCC = 8 THEN SET MAXCC = 0

****************************

BOTTOM OF DATA

***************************

Da die

Anweisung //LOESCH DD * jetzt außerhalb der Prozedur steht, ist sie zulässig. Allerdings hat die Sache noch einen Haken: In der SYSIN-Anweisung darf keine Variable stehen. Man kann also nicht:

SYSIN DD * DELETE UWIN.SCHULUNG.TESTDAT.&MONAT..OUTPUT

schreiben, da bei SYSIN Daten keine Variablenersetzung erfolgt. Mit Hilfe der SYSIN DD DSN-Anweisung ergibt sich jedoch eine Möglichkeit, auch hier variabel zu arbeiten. Die SYSIN DD

DSN-Anweisung Das nächste Beispiel beruht auf folgender Technik:

MVS/ESA JCL

148

Die Steueranweisungen werden in verschiedene Member einer Bibliothek geschrieben. Die Membernamen sind so gewählt, daß sie den Variableninhalten entsprechen, die beim Aufruf der Prozedur ersetzt werden. edit-uwi n.schulung. del (januar) command ===> ******

*****************************

01.15 -

.

fop of data

columns 001 072 scroll ===> page

*****************************

delete (uwin.schulung.testdat.januar.output) 000001 if maxcc = 8 then set maxcc =0 000002 000003 /* ****** **************************** bottom of data ***************************

Auf der gleichen Bibliothek stehen die Member für Februar, März usw. In der Prozedur wird nun dafür gesorgt, daß die entsprechenden Member angezogen werden: ******

*****************************

top of data

*****************************

000001 //uwinc job (998,abtdg02),'m.winter1,class=a,notify=uwin, 000002 // msgclass=y,msglevel=(1,1) 000003 //test proc exec pgm=idcams 000004 //clrcat 000005 //sysprint dd sys0ut=* dd dsn=uwin.schulung.del(&m0nat),disp=shr 000006 //sysin exec pgm=pgm01 000007 //step1 000008 //steplib dd dsn=uwin.schulung.load,disp=shr dd dsn=uwin.schulung.testdat.&m0nat..input,disp=shr 000009 //input 000010 //output dd dsn=uwin.schulung.testdat.&monat..output, 000011 // disp=(new,catlg,delete), 000012 // unit=dskprm, 000013 // recfm=fb,lrecl=234, 000014 // space=(trk,(5,1),rlse) 000015 //sysprint dd sysout=&out dd sysout=&out 000016 //sysout 000017 // pend exec test,out=a,m0nat=januar 000018 //do ******

****************************

bottom of data

***************************

Der Membername wird als Variable abgestellt. Beim Aufruf der Prozedur wird er ersetzt und das entsprechende Member der Bibliothek UWIN.SCHULUNG.DEL gelesen. Dieses Member enthält dann die für den IDCAMS Step notwendigen Kontrollanweisungen.

Symbolische Parameter vorbesetzen Es gibt viele Situationen, in denen es sinnvoll ist, Standardwerte vorzugeben. Der Benutzer ist dann nicht mehr gezwungen, jeden symbolischen Parameter beim Aufruf zu besetzen. Die Vorbesetzung erfolgt in der Prozedur auf der PROC-Zeile.

JCL-Prozeduren

149

Im folgenden Beispiel enthält der SPACE Parameter auf Zeile 14 zwei symbolische Parameter: PRIM und SEK. Mit ihrer Hilfe kann der Umfang der Platzanforderung festgelegt werden. Werden diese symbolischen Parameter beim Aufruf der Prozedur auf Zeile 18 nicht besetzt, so treten die Werte 5 und 1 an ihre Stelle, die in der PROCAnweisung auf Zeile 3 festgelegt wurden. Werden beim Aufruf andere Werte übergeben, so werden die Standardwerte damit überschrieben. ******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008

000012 000013 000014 000015 000016 000017 000018

//uwinc // //test //clrcat //sysprint //sysin //step1 //steplib //input //output // // // // //sysprint //sysout // pend //do

******

****************************

000009 000010 000011

job

fop of data

*****************************

(998,abtdg02),'m.winter',class=a,notify=uwin, msgclass=y,msglevel=(1,1) proc prim=5,sek=1 exec pgm=idcams dd sys0ut=* dd dsn=uwin.schulung.del(&m0nat)

,di sp=shr

exec pgm=pgm01 dd dsn=uwin.schulung.load,disp=shr dd dd

dsn=uwin.schulung.testdat.&m0nat..input,disp=shr dsn=uwin.schulung.testdat.&m0nat..output,

disp=(new,catlg,delete), unit=dskprm,

recfm=fb,lrecl=234, space=(trk,(&prim,&sek),rlse) dd sysout=&out dd sysout=&out

exec

test,out=a,monat=januar bottom of data

***************************

Auslassen

symbolischer Parameter Unter Umständen kann es vorkommen,

daß man einen symbolischen Parameter überhaupt nicht mit einem Wert besetzen will. Auch in diesem Fall muß der Parameter angegeben werden, allerdings folgt auf das Gleichheitszeichen nichts. Man muß sehr genau überlegen, ob das Auslassen eines Parameters überhaupt möglich ist. Betrachten wir nochmals den symbolischen Parameter &MONAT. In der Prozedur steht:

//EIN1

DD DSN=UWIN.SCHULUNG.&MONAT..INPUT

Wird &MONAT beim Aufruf der Prozedur ausgelassen, also:

//STEP

EXEC

TEST,MONAT=,OUT=*

150

MVS/ESA JCL

angegeben, so kommt es zu einem JCL-Fehler, weil folgende Ersetzung stattfindet:

//EIN1

DD DSN=TJWIN. SCHULUNG.

.

INPUT

Im DSN

folgen zwei Punkte unmittelbar aufeinander. Dies ist aber syntaktisch falsch. Um das Auslassen des DSN zu ermöglichen, müßte man schon zu der bereits beschriebenen Möglichkeit greifen, den Punkt mit in den Parameter zu übernehmen. Die Nachteile dieser Möglichkeit sind bereits beschrieben worden. Ein Fall, bei dem das Auslassen Sinn macht, soll hier kurz beschrieben werden. Es geht um die Möglichkeit, ein Dataset auf DUMMY zu setzen, also zu verhindern, daß es einen Output erzeugt oder einen Input wirklich liest. Um nun zu erreichen, daß wahlweise auf DUMMY gesetzt werden kann, muß man zu einem kleinen Trick greifen. So muß die Anweisung lauten, wenn ein Input erfolgen soll:

//INPUT //

DD

DSN=UWIN.SCHULUNG.JANUAR.INPUT,

DISP=SHR

das Dataset auf DUMMY gesetzt ist die Lesezugriff EOF Bedingung zurückgegeben):

und so,

wenn

//INPUT // //

DD

Fall wird beim ersten

DUMMY,

DSN=UWIN.SCHULUNG.JANUAR.INPUT, DISP=SHR

In der Prozedur wird nun

//INPUT //

(In diesem

DD

angegeben:

&SUPP.DSN=UWIN.SCHULUNG.JANUAR.INPUT,

DISP=SHR

Beim Aufruf wird nun entweder:

//STEP1

EXEC

TEST,SUPP='DUMMY,1

oder

//STEP1

EXEC TEST,SUPP=

angegeben. Im ersten Fall wird der Input unterdrückt, im zweiten Fall erfolgt er. Der Trick besteht nun darin, das Komma mit in die Wertzuweisung zu nehmen. Dies ist unbedingt notwendig, denn sonst würde folgendes passieren:

151

JCL-Prozeduren

/'/INPUT

DD &SUPP

//

DISP=SHR

.

,

DSN=UWIN. SCHULUNG J7ANUAR INPUT, .

.

Ruft man mit

//STEP

EXEC TEST,SUPP=DUMMY

auf, so ist alles in Ordnung. Ruft man aber mit:

//STEP

EXEC TEST,SUPP=

auf, so erfolgt folgende Ersetzung:

//INPUT //

DD

,DSN=UWIN.SCHULUNG.JANUAR.INPUT,

DISP=SHR

und schon hat man einen wunderschönen

JCL-Fehler, da auf DD kein Komma folgen darf.

Schachteln von Prozeduren Unter MVS/ESA Version 4 ist es möglich, Prozeduren bis zu einer Tiefe von 15 Ebenen zu schachteln. Dies gilt für katalogisierte und für In-Stream-Prozeduren. Besondere Angaben

sind nicht nötig, außer daß eine Prozedur ihrerseits eine EXEC PROC-Anweisung enthält.

Problematisch ist das Schachteln von Prozeduren in zweierlei Hinsicht: 1. Alle Stepnamen sollten eindeutig sein, damit es bei Überschreibungen nicht zu Verwechslungen kommen kann. 2. Überschreibungen gelten nur für das nächst tieferliegende Level. Will man noch tiefer liegende Parameter überschreiben, so müssen die entsprechenden Angaben in die aufgerufenen Prozedur mit eingebaut werden. Ob dann noch eine Übersichtlichkeit gegeben ist, sei dahingestellt. Da bei bereits vorhandenen Prozeduren davon auszugehen eindeutig sind, sollte die Schachtelungsmöglichkeit nur bei werden.

Die

ist, daß die Stepnamen nicht

Neuentwicklungen eingesetzt

SET-Anweisung

Syntax: SET

parameter=wert[,parameter=wert,...]

Einführung von MVS/ESA Version 4 gibt es eine einfache Wertzuweisung mit einer SET-Anweisung (ähnlich wie in Clisten). Sie Wertzuweisung in der PROC-Anweisung ergänzen oder ersetzen.

Mit der

Form der kann die

MVS/ESA JCL

152

Beispiel:

//STEP1 SET // //OUTPUT

EXEC TESTPROC MONAT=JANUAR DD DSN=SCHULUNG.OUTFILE.&MONAT

ist identisch mit:

//STEP1 //OUTPUT

EXEC TESTPROC,MONAT=JANUAR DD DSN=SCHULUNG.OUTFILE.&MONAT,...

SET-Anweisung erlaubt eine größere Flexibilität. Sie kann auch innerhalb katalogisierter Prozeduren stehen. Bisher waren Wertzuweisungen nur beim Aufruf der Prozedur möglich. Die Verwendung von SET-Anweisungen ist übrigens nicht auf Prozeduren beschränkt. Sie kann auch innerhalb 'normaler' JCL eingesetzt werden und manche Prozedur überflüssig machen. Die

Die

INCLUDE-Anweisung

Syntax:

// INCLUDE MEMBER=name Mit Hilfe der INCLUDE-Anweisung ist es ab der Version 4 von MVS/ESA möglich, JCL in Prozeduren oder andere JCL hinein zu kopieren. Die INCLUDE-Anweisung kann nur zusammen mit der JCLLIB-Anweisung eingesetzt werden. Die JCLLIB-Anweisung enthält die Namen der zu durchsuchenden Bibliotheken, die INCLUDE-Anweisung den Membernamen. Für das Format der Bibliotheken gilt das gleiche wie bei JCLLIB. Die INCLUDE-Anweisung kann ihrerseits in einem Member stehen, das durch INCLUDE aufgerufen wurde. Auf diese Weise ist eine Schachtelungstiefe bis zu 15 Ebenen möglich. Das Member, das mit INCLUDE aufgerufen wird, darf keine PROC/PEND, JCLLIB, DD *, DD DATA oder JES2 Anweisungen enthalten. Zusammen mit der SET-Anweisung ergeben sich interessante Möglichkeiten:

//UWININC1 JOB (998,ABTDG02),'M.WINTER', // CLASS=A,MSGCLASS=A // JCLLIB ORDER=(UWIN.PRINTREP)

page

******************************

000001 //uwin217c job (uwin,abtdg02),'m.winter 1,n0tify=uwi n, 000002 // class=t,msgclass=y 000003 //***************************************************************

000004 000005 000006 000007 000008 000009

//* idcams zum loeschen eines dataset //* //* //***************************************************************

exec pgm=idcams //delete //sysprint dd sysout=* dd * 000010 //sysin

000011

delete uwin.schulung.ds31

******************************

bottom of data

Der SYSPRINT liefert das Ergebnis. Für den erfolgreiches Löschen gemeldet: sysprint

browse

1-- line

1-- cols

--

===>

*******************************

idcams

Fall, daß das Dataset existiert, wird ein

page

uncat

-

command

********************************

scroll

===>

1 80 screen

yop of data **********************************

system services

time: 12:06:43

delete uwin.schulung.ds31

idc0550i entry (a) uwin.schulung.ds31 deleted idc0001i function completed, highest condition code was 0

idc0002i idcams processing complete. maximum condition code was 0 ******************************

bottom of data ********************************

Sollte das Dataset bereits nicht mehr existiert 8 gemeldet.

von

haben,

so

wird dies mit einem Return Code

MVS/ESA JCL

160 ************************************

IDCAMS

TOP OF DATA

*****************************

TIME: 12:05:26

SYSTEM SERVICES

DELETE UWIN.SCHULUNG.DS31

IDC3012I ENTRY UWIN.SCHULUNG.DS31 NOT FOUND REASON CODE IS IGGOCLEG-42 IDC3009I ** VSAM CATALOG RETURN CODE IS 8 IDC0551I ** ENTRY UWIN.SCHULUNG.DS31 NOT DELETED -

IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 8 ******************************

BOTTOM OF DATA

********************************

Dieser Return Code ist (meistens) harmlos.

IDCAMS DELETE -

Beispiel 2

Soll ein Dataset auf Band/Kassette gelöscht werden, so kann heute auf den Zusatzparameter NSCR (NOSCRATCH) verzichtet werden. NSCR Angaben in existierender JCL können entfernt werden, sofern SMS im Einsatz ist: EDIT-UWIN.SCHULUNG.IDCAMS(DEL02)

01.05

.-.

-

COMMAND

SCROLL

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009

//UWIN217C JOB (UWIN.ABTDG02),1 M.WINTER 1,NOT IFY=UWIN, CLASS=T,MSGCLASS=Y //

TOP OF DATA

===>

PAGE

*****************************

//*************************************************************** //* IDCAMS ZUM LOESCHEN EINES DATASET AUF BAND/KASSETTE //* //* //*************************************************************** EXEC PGM=IDCAMS //DELETE DD SYS0UT=* //SYSPRINT

DD * 000010 //SYSIN DELETE UWIN.SCHULUNG.TESTCASS 000011 *******************************

BOTTOM OF DATA

*******************************

Util ity-Program m e

Sofern das Löschen ******

IDCAMS

161

erfolgreich war, erscheint folgende Meldung:

*****************************

TOP OF DATA

****************************

SYSTEM SERVICES

TIME: 12:05:26

DELETE UWIN.SCHULUNG.TESTCASS

IDC0550I ENTRY (A) UUIN.SCHULUNG.TESTCASS DELETED

IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 *******************************

BOTTOM OF DATA

*******************************

Beachten Sie, daß auch nach dem DELETE das Band/die Kassette unbenutzbar sofern nicht abgelaufene Schutzfristen existieren. IDCAMS DELETE

-

bleibt,

Beispiel 3

Wie schon erwähnt, ist ein RC von 8 meistens harmlos. Es gibt jedoch leider einige Situationen, wo der RC von 8 auf ein schwerwiegendes Problem hinweist. Eine dieser Situationen ist gegeben, wenn der Eintrag im User-Katalog auf ein falsches Volume verweist. Eine solche Situation ist zugegebenermaßen sehr selten. Sie kann jedoch eintreten, wenn ein neues Volume unter einer neuen logischen Bezeichnung in Betrieb genommen wird und eine alte Platte 'abgehängt' wird. Sofern die Einträge im Katalog nicht korrekt nachgeführt werden, kann der Eintrag dort auf ein altes, nicht mehr existierendes Volume verweisen. Eine ähnliche Situation tritt ein, wenn durch falsche Benutzung des VOL=REF-Parameters und des Parameters DISP=(,PASS) ein Katalogeintrag für ein nicht existierendes Dataset erzeugt wird. Im

folgenden Beispiel soll das Dataset UWIN.SCHULUNG.DS51 gelöscht werden.

MVS/ESA JCL

162

UWIN.SCHULUNG.IDCAMS(DELOI)

EDIT

01.05

---.

-

-

COMMAND

SCROLL

===>

******

*****************************

000001 000002 000003 000004

//UWIN217D

JOB

// //

MSGCLASS=Y,

//

yep OF DATA

===>

PAGE

****************************

(998,ABTDG02),'M.WINTER 1,CLASS=C,NOT IFY=UWIN,

TIME=(,05), MSGLEVEL=(1,1) MSGLEVEL=(1,1),TYPRUN=SCAN

000005 //* EXEC PGM=IDCAMS 000006 //UNCAT 000007 //SYSPRINT DD SYS0UT=* DD * 000008 //SYSIN DELETE UWIN.SCHULUNG.DS51 000009 ******************************* BOTTOM OF DATA

*******************************

Für das Dataset UWIN.SCHULUNG.DS51 gibt es zwar einen Erntrag im Katalog, aber keinen VTOC-Eintrag mehr. Da beim DELETE zunächst versucht wird, den VTOC-Eintrag zu löschen, muß es zu einem Fehler kommen, denn ein nicht vorhandener Eintrag läßt sich nicht löschen. Die

Meldungen in SYSPRINT sehen folgendermaßen aus:

******

IDCAMS

*****************************

TOP OF DATA

*****************************

SYSTEM SERVICES

TIME: 12:05:26

DELETE UWIN.SCHULUNG.DS51

IKJ56232I DATA SET UWIN.SCHULUNG.DS51 NOT ON VOLUME AS INDICATED IN THE IKJ56232I CATALOG OR VOL PARAMETER IDC0551 I ** ENTRY UWIN.SCHULUNG .DS51 NOT DELETED

IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 8 *******************************

BOTTOM OF DATA

********************************

Die Folge dieses Fehlers ist äußerst unangenehm. Durch das nicht erfolgreiche Löschen wird es beim erneuten Anlegen eines Datasets unter dem gleichen Namen zu einem NOT CATLGD 2-Fehler kommen, falls SMS aktiviert ist, kommt es sogar zu einem Abbruch des Jobs. Diese Situation läßt sich vermeiden, wenn man auf den normalen DELETE noch einen DELETE NSCR folgen läßt. Sofern der normale DELETE nicht erfolgreich ist, bereinigt

Utility-Programme

163

der DELETE NSCR den Katalog und ermöglicht so die Weiterverarbeitung. Dies geht jedoch nur in Nicht-SMS-Umgebungen, da NSCR dort für Plattendatasets benutzt werden darf. Unter SMS ist die Benutzung von NSCR nicht möglich. Allerdings kann es dort jedoch nicht zu dem oben beschriebenen Problem kommen. Da nunmehr im IDCAMS Step auf jeden Fall ein Return Code von 8 geliefert wird es kann nur eines der beiden Kommandos erfolgreich ausgeführt werden, kann es in der Folge -

des Jobs unter Umständen zu Problemen kommen. Sollte der COND-Parameter in der Weise eingesetzt sein, daß bei einem Return Code von mehr als 4 ein Abbruch erfolgt, so wäre diese Bedingung nunmehr erfüllt.

überflüssigen Abbruch zu vermeiden, wird der Return Code auf 0 geschieht mit Hilfe eines IDCAMS Modal-Kommandos. Mit ihm ist es möglich, den Return Code abzuprüfen und umzusetzen.

Um einen solchen zurückgesetzt. Dies

edit-uwin.schulung.idcams(del01)

01.05

.-.-.

-

command

===>

scroll

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011

//uwin217d job (998,abtdg02),1m.winter1,class=c,not ify=uwin, // msgclass=y, // //

//*

1. 2.

===>

page

*****************************

time=(,05), msglevel=(1,1) msglevel=(1,1),typrun=scan

exec pgm=idcams //uncat //sysprint dd sysout=* dd * //sysin delete uwin.schulung.ds51 delete uwin.schulung.ds51 noscratch 8 then set maxcc = 0 if maxcc =

*******************************

Aus den

top of data

bottom 0f data

********************************

Meldungen geht hervor:

Das erste Löschen

war nicht erfolgreich, Katalog angegebenen Volume befand. Das zweite Löschen war erfolgreich.

da das Dataset sich nicht auf dem im User-

MVS/ESA JCL

164

******************************** TOP OF DATA **********************************

IDCAMS

TIME: 12:06:43

SYSTEM SERVICES

DELETE UWIN.SCHULUNG.DS51

IKJ56232I DATA SET UWIN.SCHULUNG.DS51 NOT ON VOLUME AS INDICATED IN THE IKJ56232I CATALOG OR VOL PARAMETER IDC0551I ** ENTRY UWIN.SCHULUNG.DS51 NOT DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8

NOSCRATCH

DELETE UWIN.SCHULUNG.DS51

IDC0550I ENTRY (A) UWIN.SCHULUNG.DS51 DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

IF MAXCC

=

8 THEN SET MAXCC

=

0

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 *******************************

Datasets

BOTTOM OF DATA

********************************

kopieren mit dem REPRO-Kommando

Mit dem IDCAMS REPRO-Kommando lassen sich Datasets kopieren.

Syntax:

REPRO

INFILE(ddname) OUTFILE(ddname) SKIP(zahl) COUNT(zahl)

INDATASET(dsname) OUTDATASET(dsname) -

-

Um die INFILE-/OUTFILE-Parameter benutzen zu können, müssen die DD-Namen in der JCL enthalten sein. Wird ein nicht existierendes Dataset angesprochen, bricht der Job mit einem Fehler ab. Bei der Benutzung von INDATASET oder OUTDATASET werden keine DDAnweisungen benötigt. In diesem Fall kommt es zu einer dynamischen Allokation. Diese

Util ity-Programme

165

hat aber gegenüber der normalem Allokation mit INFILE bzw. OUTFILE einen entscheidenden Nachteil: Kann das Dataset vorübergehend nicht allokiert werden, weil z.B. ein anderer User exklusiv darauf zugreift, so wird nicht gewartet, sondern es kommt zur

Meldung:

DATASET ALLOCATED BY ANOTHER JOB OR USER

TRY LA-

TER

Die Funktion wird dann nicht ausgeführt. Aus diesem Grund sollten Sie immer mit INFILE oder OUTFILE arbeiten. Sie sind dann auf der sicheren Seite. Mit SKIP kann eine bestimmte Zahl von Records am Anfang des Datasets übersprungen werden. COUNT beschränkt die Zahl der zu kopierenden Records. SKIP und COUNT dürfen nur einmal angegeben werden.

Die

folgenden Beispiele sollen beide Möglichkeiten illustrieren:

edit-uwin.schulung.

idcams(rep01)

01.05

-.-.

-

command ******

===>

scroll

*****************************

-pop of data

===>

page

*****************************

//uwin217c job (uwin,abtdg02),'m.winter',not ify=uwin, class=t,msgclass=y //******************************* //* idcams zum kopieren sequentieller datasets //* //* //*************************************************************** exec pgm=idcams //delete //sysprint dd sysout=* dd * 000010 //sysin 000001 000002 000003 000004 000005 000006 000007 000008 000009

//

000011

delete uwin.schulung.ds99.back exec pgm=idcams 000012 //repro 000013 //sysprint dd sysout=* 000014 //ein dd dsn=uwin.schulung.ds99,disp=old

000015 //aus 000016 // 000017 //

dd dsn=uwin.schulung.ds99.back, disp=(new,catlg,delete), unit=dskprm, space=(cyl,(1,1)), lrecl=120,recfm=fb

000018 // 000019 // 000020 //sysin dd * repro infile(ein) outfile(aus) 000021

Bei der Verwendung von REPRO haben Sie die Wahl, ob Sie das komplette Dataset oder aber nur einen Teilbereich kopieren wollen. Durch die Angabe von COUNT und/oder SKIP läßt sich die Zahl der zu kopierenden Records beschränken.

MVS/ESA JCL

166 EDIT-UUIN.SCHULUNG. IDCAMS(REP01) COMMAND ===>

01.05

.--.-.

-

SCROLL

*****************************

000001 000002 000003 000005 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020 000021

//UUIN217C JOB (UWIN,ABTDG02),'M.WINTER' NOTI FY=UWI N, CLASS=T,MSGCLASS=Y //

TOP OF DATA

===>

PAGE

*****************************

******

,

//*************************************************************** //*

IDCAMS ZUM KOPIEREN SEQUENTIELLER DATASETS

//******************************** EXEC PGM=IDCAMS //DELETE //SYSPRINT DD SYSOUT=* DD * //SYSIN DELETE UWIN.SCHULUNG.DS99.BACK EXEC PGM=IDCAMS //REPRO DD SYSOUT=* //SYSPRINT DD DSN=UWIN.SCHULUNG.DS99,DISP=OLD //EIN DD DSN=UWIN.SCHULUNG.DS99.BACK, //AUS DISP=(NEU,CATLG,DELETE), // UNIT=DSKPRM, // // SPACE=(CYL,(5,1),RLSE), // LRECL=120,RECFM=FB //SYSIN DD * REPRO INFILE(EIN) OUTFILE(AUS) -

COUNTC1000)

000022

In diesem Fall werden

nur

die ersten 1000 Records

Mit den folgenden Kontrollkommandos wird ein Ende des Dataset erreicht:

//SYSIN

DD

kopiert. Kopieren

ab dem 1001. Record bis

zum

*

INFILE(EIN) OUTFILE(AUS) SKIP(1000)

REPRO

Jetzt wird alles ab dem 1001. Record bis

zum

COUNT und SKIP können auch zusammen werden nur die Kontrollkommandos gezeigt:

//SYSIN

DD

-

Ende des Dataset kopiert.

eingesetzt

werden. Auch in diesem

*

INFILE(EIN) OUTFILE(AUS) SKIP(500) COUNT(1000)

REPRO

-

Beispiel

Utility-Program m e

167

Jetzt werden die Records 501 bis 1500 kopiert. Im SYSPRINT wird die Zahl der bearbeiteten Records gemeldet. Der SYSPRINT des IDCAMS REPRO ist wesentlich aussagekräftiger als der des IEBGENER. browse

sysprint

savedisk-- page

1-- cols 1 80 scroll ===> screen

1-- line

-

command

===>

*******************************

idcams

repro

top of data

***********************************

system services

time: 09:07:08

infilecin1) outfile(0ut1) -

(5) count (15) skip

-

idc0005i number of records processed was 15 idc0001i function

completed,

highest condition code was 0

idc0002i idcams processing complete. maximum condition code was 0 bottom of data ********************************

*******************************

Ein mehrfaches Einsetzen von COUNT und SKIP ist nicht möglich. Obwohl wird folgende Kontrollanweisung zu einem Fehler führen:

//SYSIN

DD

es

schön wäre,

*

INFILE(EIN) OUTFILE(AUS) SKIP(500)

REPRO

-

COUNT(1000) SKIP(500) COUNT(1000) Ein solches alternierendes

Kopieren ist (leider) nicht möglich.

Datasets drucken mit dem PRINT-Kommando Mit Hilfe des IDCAMS PRINT-Kommandos läßt sich der Inhalt von Datasets ausdrucken. Dabei kann das Ausgabeformat gewählt werden, ebenso kann Anfang und Ende des Drucks bestimmt werden.

168

MVS/ESA JCL

Syntax: PRINT

INFILE(ddname) | INDATASET(Eintrag-Name)

CHARACTER | HEX | DUMP

-

-

SKIP(Zahl) COUNT(Zahl)

druckenden Datasets kann über INFILE dann ist die Angabe einer DDAnweisung erforderlich oder über INDATASET hier muß der Datasetname eingesetzt werden mitgeteilt werden. Bei der Benutzung von INDATASET kann das bereits beschriebene Allokations-Problem auftauchen. Der Name des

zu

-

-

-

-

Das Format der 1.

Ausgabe kann in verschiedener Form erfolgen: Schriftform (CHARacter). Gepackte numerische Felder

werden.

können nicht

dargestellt

Ausgabe nur in HEX-Zeichen (HEX). Dieser Output ist nur schwer lesbar. 3. Ausgabe im DUMP-Format. DUMP ist der Default, er braucht nicht angegeben zu werden. Bei einer Ausgabe im DUMP-Format stehen auf der linken Seite die HEXZeichen, auf der rechten Seite die entsprechenden Darstellungen im Character-Format. Mit SKIP läßt sich eine bestimmte Zahl von Records am Anfang des Datasets überspringen.

2.

Mit COUNT läßt sich eine maximale Zahl der zu druckenden Records definieren. SKIP und COUNT können einzeln oder zusammen eingesetzt werden. Wird SKIP einzeln eingesetzt, wird bis zum Ende des Datasets gedruckt.

Utility-Programme

169

Im folgenden Beispiel werden die Records 11-15 eines Form gedruckt:

uwin.schulung.idcams(prt01)

edit -

command

01.05

sequentiellen Datasets in Character

.

-

===>

scroll

******

****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012

//uwin217c job (uwin.abtdg02),'m.winter 1,notify=uwin,

yop Qp data

===>

page

******************************

//

class=t,msgclass=y //******************************* //* //* idcams zum drucken eines sequentiellen dataset //* //*************************************************************** exec pgm=idcams //print //sysprint dd sysout=*

//in //sysin

dd

dsn=uwin.schulung.ds99,disp=shr

dd

*

print inf ile(in) -

000014 000015

count(4) -

char

******************************

Die im Dataset vorhandenen werden.

bottom of data

gepackten

*********************************

Felder können in diesem Format nicht

gelesen

listing of data set -uwin.schulung.ds99

1

record sequence number -

00001mueller

sabine

record sequence number

am hang 44

5000koeln

oberweg 7

2000hamburg

waldgasse 21

1000berlin

keplerstrasse 3

5000koeln

2 -

00002schneider

werner

3

record sequence number -

00003sielder

norbert

record sequence number

4 -

00004becker

erika

folgenden Beispiel wurde der Parameter CHAR weggelassen. In diesem Fall tritt der Default DUMP in Kraft, d.h. es erfolgt eine Ausgabe in Hexadezimal- und CharacterFormat: Im

MVS/ESA JCL

170 EDIT-UWIN.SCHULUNG.IDCAMS(PRT01)

01.05

.-.

-

COMMAND

SCROLL

===>

******

****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011

//UWIN217C //

jop OF DATA

===>

PAGE

******************************

JOB (UWIN.ABTDG02),1M.WINTER 1,NOT IFY=UWIN, CLASS=T,MSGCLASS=Y

//*************************************************************** //* //* //*

IDCAMS ZUM DRUCKEN EINES SEQUENTIELLEN DATASET

//*************************************************************** EXEC PGM=IDCAMS //PRINT //SYSPRINT DD SYSOUT=* DD DSN=UWIN.SCHULUNG.DS99,DISP=SHR //IN DD * //SYSIN PRINT INFILE(IN)

000012 000014

-

COUNTC3)

******************************

Aus Gründen der

BOTTOM OF DATA

*********************************

Übersichtlichkeit ist der Hex-Teil des folgenden Outputs unvollständig

wiedergegeben. LISTING OF DATA SET -UWIN.SCHULUNG.DS99 RECORD SEQUENCE NUMBER

1 FOF0F0F0 F1D4E4C5 D3D3C5D9 40404040 4040C1D4 40C8C1D5 C740F4F4 40404040 40404040 40404040 40404000 0002076F -

000000 000020 000040

RECORD SEQUENCE NUMBER 2 000000 F0F0F0F0 F2E2C3C8 D5C5C9C4 C5D94040

*00001MUELLER * AM HANG 44 *

SABINE 5000KOELN

* * *

_?

-

000020 000040

4040D6C2 C5D9E6C5 C740F740 40404040 C7404040 40404040 40404000 0003801F

RECORD SEQUENCE NUMBER 3 000000 F0F0F0F0 F3E2C9C5 D3C4C5D9 40404040 000020 4040E6C1 D3C4C7C1 E2E2C540 F2F14040

*00002SCHNEIDER * OBERWEG 7 *G

WERNER

*00003SIELDER

NORBERT

*

2000HAMBUR* *

.

-

000040

40404040 40404040 40404000 0004721F

Der Vorteil des

gepackten

* *

WALDGASSE 21 .

1000BERLIN* *

Outputs besteht darin, daß er einerseits gut lesbar ist, andererseits die Felder im Hex-Teil entschlüsselt werden können.

Utility-Programme

4.2

171

IEBGENER

Hauptfunktion der IEBGENER-Utility besteht im Kopieren von Datasets. Dies geschieht in der Regel zum Erzeugen eines Backups. Kommt es während der Verarbeitung zu Fehlern, so können Datasets mit Hilfe der Backups wiederhergestellt werden. Die

In vielen MVS-Installationen ist das

Programm SYNCGENR von der Fa. SYNCSORT installiert. Beim Aufruf der IEBGENER Funktionen kann deshalb das Programm SYNCGENR aufgerufen werden. In den Fällen, in denen IEBGENER nicht ausgeführt werden braucht, verzweigt SYNCGENR zu SORT. Ist die SYSIN DD-Anweisung nicht DUMMY, wird immer IEBGENER ausgeführt. Erkundigen Sie sich, ob bei Ihnen IEBGENER aufgerufen werden muß oder ob Sie SYNCGENR aufrufen können. Neben der reinen Kopierfunktion bietet IEBGENER weitere Möglichkeiten. So kann beim Kopieren eine Umformatierung erfolgen, z.B. können gepackte Felder entpackt werden. Die Reihenfolge der Datenfelder im Ziel-Record kann anders gewählt werden als die Ausgangsrecord vorhandene. Diese Möglichkeit kann unter Umständen das Schreiben eines Anwendungsprogrammes ersparen. Auf weitere exotische Möglichkeiten, die IEBGENER bietet, z.B. Anlegen eines Member in einer Bibliothek, wird hier nicht eingegangen. Diese Funktionen werden heutzutage mit ISPF erledigt.

IEBGENER kann für jedes sequentielle Dataset benutzt werden, unabhängig davon, ob sie auf Band oder Platte steht. VSAM-Datasets kann IEBGENER nicht verarbeiten. Hierzu ist die IDCAMS-Utility zu verwenden.

Datasets

kopieren mit IEBGENER (SYNCGENR)

Die Kopierfunktion von IEBGENER wird am häufigsten genutzt. Größere Backups sollten auf Band bzw. Kassette gezogen werden. Ansonsten kann auch von Platte auf Platte kopiert werden. Falls Bänder oder Kassetten verwendet werden sollen, muß der Job in einer Klasse laufen, die für Bandverarbeitung zugelassen ist. Für jedes IEBGENER-Programm müssen drei DD-Anweisungen mit bestimmten Feldnamen existieren. Diese Feldnamen sind nicht wahlfrei: 1.

2. 3.

DD-Anweisung mit dem Feldnamen SYSUT1 enthält das Ausgangsdataset. Die DD-Anweisung mit dem Feldnamen SYSUT2 enthält das Zieldataset. Auf die SYSIN DD-Anweisung folgen normalerweise die Kontrollkommandos. Wenn die Kopierfunktion von IEBGENER aufgerufen wird, sind aber keine Kontrollkommandos erforderlich. Daher wird die SYSIN DD-Anweisung auf DUMMY gesetzt. Keinesfalls darf sie einfach weggelassen werden. Dies würde zu Die

einem JCL-Fehler führen.

Da das unter SYSUT2 allokierte Ausgabedataset meist neu angelegt wird, ist daran denken, daß in einem vorhergehenden Step der Katalog mit IDCAMS bereinigt wird.

zu

Welche Art von Datenträger beim Kopiervorgang gewählt wird, spielt keine Rolle. Es kann also von Platte auf Band, von Platte auf Platte, von Band auf Platte oder von Band auf Band

172

MVS/ESA JCL

kopiert werden. Auch kann die SYSUT1 DD-Anweisung auf * gesetzt werden. In diesem Fall folgen die zu kopierenden Daten unmittelbar auf die SYSUT1-Anweisung (In-StreamDaten).

Wird unter SYSUT2 ein neues Dataset angelegt, so werden die DCB-Anweisungen (RECFM, LRECL) von SYSUT1 übernommen. Die Blocksize wird selbständig bestimmt, wobei die für den Datenträger optimale BLKSIZE benutzt wird. Soll SYSUT2 ein anderes Format erhalten, so ist RECFM und meist auch LRECL anzugeben. Es gibt einen wesentlichen Unterschied zum Kopieren mit IDCAMS. IEBGENER kann pro Step nur einen Kopiervorgang durchführen. Sollen mehrere Kopiervorgänge durchgeführt werden, so müssen entsprechend vieles Steps durchlaufen werden. Die JCL wird dadurch aufgebläht. Andererseits ist in Ihrem Unternehmen möglicherweise SYNCSORT installiert. Dieser ist aller Wahrscheinlichkeit nach schneller als ein IDCAMS REPRO, mit dem ebenfalls kopiert werden kann. Prüfen Sie das einfach mal nach. Sie sollten sich dann für die Möglichkeit entscheiden, die in Ihrer Installation das beste Ergebnis liefert. Die folgenden Beispiele sollen verschiedene Kopiervorgänge illustrieren. Im ersten Beispiel wird eine Kopie eines Datasets auf Platte erstellt: EDIT-UWIN.SCHULUNG.UTIL(SYNC001)

01.05

-.-

-

COMMAND

===>

SCROLL

===>

******

*****************************

000001 000002 000003 000004

//UWIN217C JOB (UWIN,ABTDG02),'M.WINTER1,NOT IFY=UWIN, // CLASS=T,MSGCLASS=Y //*************************************************************** //* IEBGENER ZUM KOPIEREN SEQUENTIELLER DATASETS //* //* //*************************************************************** EXEC PGM=IDCAMS //DELETE

000005 000006 000007 000008

TOP OF DATA

PAGE

*****************************

000009 //SYSPRINT DD SYS0UT=* 000010 //SYSIN DD * DELETE UWI N.SCHULUNG.DS99.BACKUP 000011 EXEC PGM=IEBGENER 000012 //COPY 000013 //SYSPRINT DD SYS0UT=* DD DSN=UWIN.SCHULUNG.DS99,DISP=OLD 000014 //SYSUT1 DD DSN=UWIN.SCHULUNG.DS99.BACKUP, 000015 //SYSUT2 000016 // DISP=(,CATLG,DELETE), 000017 // SPACE=(TRK,(5,1),RLSE), 000018 // UNIT=SYSDA 000019 //SYSIN DD DUMMY

Die Meldung im SYSPRINT ist sehr knapp: Dies zeigt das erfolgreiche Kopieren an.

'Processing ended at End-Of-Dataset (EOD)'.

173

Utility-Programme sysprint

browse

page

copy

1-- line

1-- cols

--

-

command

scroll

===>

********************************

top of data

===>

1 80 screen

**********************************

generate

data set utility -

processing ended at eod *******************************

Im folgenden Beispiel wird ein Kassette gezogen:

bottom of data

Backup

eines Datasets, das auf einer Platte steht, auf

edit-jjwin.schulung.util(sync001 )

01.05 -

command ******

********************************

.

scroll

===> *****************************

top of data

===>

page

*****************************

000001 //uwin217c job (uwin,abtdg02),'m.winter1,not ify=uwin, 000002 // class=t,msgclass=y 000003 //*************************************************************** 000004 //* 000005 //* 000006 //* 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019

iebgener zum kopieren sequentieller datasets

//*************************************************************** exec pgm=idcams //delete //sysprint dd sysout=* dd * //sysin delete

//copy //sysprint //sysut1 //sysut2 // // // //sysin

uwin.schulung. testcass exec pgm=syncgenr dd sysout=* dd dd

dsn=uwin.schulung.ds99,disp=old dsn=uwin.schulung.testcass, disp=(,catlg,delete),

expdt=99000, unit=cass dd dummy

*******************************

bottom of data

********************************

In diesem Job wird ein Dataset von Platte auf Kassette kopiert. Als DISP für das Ausgangsdataset wird OLD gesetzt, um zu verhindern, daß Zugriffe auf das Dataset während der Sicherung erfolgen. Andere User, die während der Sicherung auf dieses Dataset zugreifen wollen, werden in einen Wartezustand versetzt. Der Parameter EXPDT=99000 bewirkt, daß die Kassette, solange darauf befindliche Datasets katalogisiert sind, nicht überschrieben werden kann. Wird das Dataset UWIN.SCHULUNG.TESTCASS entkatalogisiert (z.B. durch IDCAMS), wird die Kassette automatisch freigegeben, sofern sich nicht noch weitere Datasets auf der Kassette befinden.

174

MVS/ESA JCL

Im

Dies ist eine

folgenden Beispiel werden In-Stream-Daten auf Platte kopiert. Möglichkeit, ohne großen Aufwand Testdaten in ein Dataset zu schreiben: ******

*****************************

TOP OF DATA

*****************************

000001 //UWIN217C JOB (UWIN.ABTDG02),1 M.WINTER 1,NOTIFY=UWIN, 000002 // CLASS=T,MSGCLASS=Y 000003 //*************************************************************** 000004 //* 000005 //* IEBGENER ZUM KOPIEREN SEQUENTIELLER DATASETS 000006 //* 000007 //*************************************************************** 000008 //DELETE EXEC PGM=IDCAMS 000009 //SYSPRINT DD SYS0UT=* 000010 000011 000012 000013 000014 000015 000016

//SYSIN

DD

*

DELETE UWIN.SCHULUNG.TEST1 EXEC PGM=SYNCGENR //COPY //SYSPRINT DD SYSOUT=*

//SYSUT1

DD

*

0001SCHNEIDER 0002DAUBER

000017 0004SCHMID 000018 0006MUELLER 000019 /*

//SYSUT2 // // // // 000025 //SYSIN

000020 000021 000022 000023 000024

AM

KLAUS

HAUPTSTRASSE 5 IN DER AU 7 OBERGASSE 15

DIETER HANS DD

MÜHLGARTEN 22

WERNER

6000FRANKFURT 8000MUENCHEN 8500NUERNBERG 7000STUTTGART

DSN=UWIN.SCHULUNG.TEST1, DISP=(,CATLG,DELETE), RECFM=FB,LRECL=72, SPACE=(TRK,(5,1),RLSE), UNIT=SYSDA

DD DUMMY

*******************************

BOTTOM OF DATA

********************************

folgen auf die SYSUT1 DD * Anweisung die Input Daten, deren Ende durch eine Delimiter-Anweisung (/*) gekennzeichnet ist. Dieses Zeichen ist an dieser Stelle nicht unbedingt erforderlich, da das Ende der Daten auch durch die nächste auftauchende JCLAnweisung markiert wird. LRECL wurde angegeben, um zu verhindern, daß die ISPF-Standardlänge von 80 Byte zum Zuge kommt. IEBGENER kann auch zum Drucken verwendet werden. In diesem Fall wird die Ausgabe auf den Drucker gelegt: In diesem Fall

175

Utility-Programme ******

*****************************

TOP OF DATA

*****************************

000001 //UWIN217C JOB (UWIN,ABTDG02),1M.WINTER',NOT IFY=UWIN, 000002 // CLASS=A,MSGCLASS=Y 000003 //*************************************************************** 000004 //* IEBGENER ZUM DRUCKEN SEQUENTIELLER DATASETS 000005 //* 000006 000007 000008 000009 000010 000011

//*

//*************************************************************** EXEC PGM=SYNCGENR //PRINT DD SYSOUT=* //SYSPRINT

//SYSUT1 //SYSUT2

000012 //SYSIN

DD

DSN=UWIN.SCHULUNG.DS99,DISP=SHR

DD SYSOUT=A DP

DUMMY_

Datasets umformatieren mit IEBGENER Wie bereits erwähnt bietet IEBGENER neben der einfachen Kopierfunktion weitere Funktionen. Um sie nutzen zu können, werden in der SYSIN DD-Anweisung Kontrollkommandos mitgegeben. Syntax der IEBGENER Kontrollkommandos:

[label]

operation

parameter

Kommentar

Das Feld operation gibt die Art des Kontrollkommandos RECORD befrachten.

an.

Wir werden GENERATE und

Das Feld operation besteht aus einem oder mehreren Schlüsselwortparametern. Wir werden die Parameter MAXFLDS und MAXLITS betrachten. Kommentare können für notwendig hält.

angeschlossen werden,

sofern

man

das

aus

Dokumentationsgründen

Um ein IEBGENER-Kontrollkommando fortzusetzen, ist es notwendig, auf der ersten Zeile mit einem Komma abzuschließen und auf jeder Folgezeile auf Spalte 16 zu beginnen. Das GENERATE-Kommando

Das GENERATE-Kommando dient der Allokation für die auszuführende zwei Parameter: 1. 2.

Operation. Es hat

(MAXimum FieLDS) gibt die maximale Zahl der FIELD-Parameter im RECORD-Kommando an. folgenden MAXLITS (MAXimum LITeralS) gibt die maximale Zahl der Zeichen an, die in den FIELD-Parametern der folgenden RECORD-Kommandos enthalten sind. MAXFLDS

MVS/ESA JCL

176

Während die Zahl der benutzten Felder leicht zu überblicken ist, lassen sich die Literale nur schwer überblicken. Da aber immer die maximale Anzahl angegeben werden muß, behilft man sich dadurch, daß man immer eine Zahl angibt, die über der erwarteten Anzahl liegt.

Syntax:

GENERATE

MAXFLDS=wert,MAXLITS=wert

Wenn man

GENERATE MAXFLDS=10 0,MAXLITS=10 0

angibt, so dürfte dies in fast allen Fällen ausreichen. Aufpassen muß man bei der Fehlermeldung, die man erhält, wenn die Zuweisung dennoch nicht ausreicht. Sie lautet lapidar: 'INVALID SPACE ALLOCATION' und führt einen meistens in die Irre, da man annehmen könnte, daß z.B. der zugewiesene Platz für das Zieldataset nicht ausreicht. Wenn man diese Funktion benutzt und die erwähnte Fehlermeldung auftaucht, sollte man vor allem das Feld MAXLITS noch einmal überprüfen. Die gleiche Meldung erhält man, wenn man versehentlich MAXFIELDS statt MAXFLDS schreibt. Daher gilt es, sehr sorgfältig auf die Syntax zu achten. Das RECORD-Kommando Das zweite Kontrollkommando, das zum Umformatieren benötigt wird, ist das RECORDKommando. Ihm schließt sich der Parameter FIELD an. Für jedes zu formatierende Feld ist ein FIELD-Parameter anzugeben.

Die

Syntax des Parameters FIELD sieht folgendermaßen aus:

FIELD=(Länge,{lnput-Pos j 'Literal'},[Konversion],Out-Pos) Alle Parameter sind

positioneil.

Erläuterung: 1.

Länge ist die Länge in Byte des Input-Feldes oder des Literais,

das verarbeitet werden

soll. Der Default-Wert ist 80.

2.

3.

4.

Input-Pos gibt den Beginn des Feldes im Input-Record an. Der Default-Wert ist 1. Wenn ein Literal in den Output-Record eingefügt werden soll, so wird es in Anführungszeichen gesetzt. Die Länge des Literais darf 40 Byte nicht übersteigen. Konversion kann benutzt werden, um numerische Felder zu entpacken, in diesem Fall muß PZ angegeben werden, oder um numerische Felder zu packen, in diesem Fall ist ZP anzugeben. Wenn keine Konversion erfolgen soll, so steht ein Komma, um das Fehlen des positionellen Parameters zu kennzeichnen. Out-Pos gibt die Startposition des Feldes im Output-Record an. Der Default-Wert ist 1.

Utility-Programme

177

Wenn man numerische Felder entpackt, so muß man darauf achten, daß ihnen im Record genügend Platz zur Verfügung gestellt wird.

Output-

Wichtiger Hinweis ! Das

Entpacken funktioniert nur mit nicht-negativen Zahlen.

Einige Beispiele sollen die Anwendung des FIELD-Parameters illustrieren: FIELD=(4,55,,1) bewirkt, daß ein Feld mit 4 Byte Länge, das am 55. Byte des steht ohne Konversion auf das 1. Byte des Output-Records gestellt wird. Der Parameter

Input-Records

FIELD=(5,76,PZ,39) Der Parameter bewirkt, daß das Feld auf der Position 76 des Input-Records auf das 39. Byte des Output-Records gestellt wird. Dabei wird ein Entpackungsprozeß durchgeführt. Die Länge des Feldes, das im Input-Record 5 Byte einnimmt, wächst auf 9 Byte. Der folgende Job formatiert einen und Umsatz besteht.

neuen

Record, der aus den Felder: PLZ, Name, Vorname

edit-uwin.schulung.utilloes(iebgen01) -

command

===>

01.02 .columns 001 072 scroll ===> page

******

*****************************

000001 000002 000003 000004 000005 000006

//uuin217s job (998,abtdg02),'m.winter 1,

-pop of data

*****************************

// class=c,msgclass=9 exec pgm=idcams //del //sysprint dd sys0ut=* dd * //sysin delete uwin.schulung.ds991 8 then set maxcc = 0 if maxcc 000007 exec pgm=iebgener 000008 //copy 000009 //sysprint dd sysout=* 000010 //sysut1 dd dsn=uwin.schulung.ds99,disp=old 000011 //sysut2 dd dsn=uwin.schulung.ds991, 000012 // disp=(,catlg,delete), =

000013 // space=(trk,(5,1),rlse), un it=dskprm 000014 // dd * 000015 //sysin 000016 generate maxflds=4,maxlits=1 000017 record field (4,55, , 1), 000018 field=(14,6,,5), 000019 field=(20,35,,19), 000020 field=(5,76,pz,39) =

******

****************************

bottom of data

***************************

MVS/ESA JCL

178

Beachten Sie die Fortsetzung des Record-Kommandos auf Spalte 16. LRECL braucht bei SYSUT2 nicht angegeben werden. LRECL wird automatisch errechnet, ebenso die BLKSIZE.

So sieht der Beginn des Ausgangsdataset 000001 000002 000003 000004

00001MUELLER 00002SCHNEIDER 00003SIELDER 00004BECKER 000005 00005PARKER 000006 00006ZAUM 000007 00007WERNER 000008 00008MÜLLER 000009 00009WILHELM 000010 00010MUELLER

SABINE WERNER NORBERT ERIKA LASSE MICHAEL VERENA KARL NOTKER PETER

aus:

5000KOELN 2000HAMBURG WALDGASSE 21 1000BERLIN KEPLERSTRASSE 3 5000KOELN AM FLEET 65 2000HAMBURG RASSELWEG 2 1000BERLIN HALMSTRASSE 6 5000KOELN FISCHERSTRASSE 56 2000HAMBURG AM ACKER 5 1000BERLIN AN DER ROSENELLER 1 5000KOELN AM HANG 44 OBERWEG 7

So sieht der Anfang des umformatierten Dataset aus: 000001 000002 000003 000004 000005 000006

5000MUELLER 2000SCHNEIDER 1000SIELDER 5000BECKER 2000PARKER 1000ZAUM

000007 000008 000009 000010

5000WERNER

2000MÜLLER 1000WILHELM 5000MUELLER

000001156 000001271 WALDGASSE 21 000001386 KEPLERSTRASSE 3 000001501 AM FLEET 65 000001616 RASSELWEG 2 000001731 HALMSTRASSE 6 000001846 FISCHERSTRASSE 56 000001961 AM ACKER 5 000002076 AN DER ROSENELLER 1 000002191 AM HANG 44 OBERWEG 7

Bitte beachten Sie, daß das hier gezeigte Entpacken des Umsatzfeldes konnte, weil keine negativen Werte auftraten!

4.3

nur

funktionieren

IEHPROGM

Wie viele Utilities stammt IEHPROGM noch aus einer Zeit, als es noch kein ISPF gab. Von den vielen Funktionen, die IEHPROGM ausführen kann, ist heutzutage nur noch eine interessant. Unter SMS sollte IEHPROGM nicht mehr eingesetzt werden.

Utility-Programme

179

Bänder/Kassetten mit IEHPROGM Die

entkatalogisieren

Syntax der Steueranweisung lautet:

UNCATLG DSNAME=dsname Wir werden hier

nur

die Funktion UNCATLG näher betrachten. Sie kann

eingesetzt

werden, wenn man Datasets auf Bändern/Kassetten entkatalogisieren will. Dies bringt einen Zeitvorteil, da das betreffende Band nicht eingelegt werden muß. IEHPROGM sollte nur bei Bändern/Kassetten eingesetzt werden, die entweder EXPDT=99000 besitzen oder deren RETPD oder EXPDT abgelaufen ist. Die Steueranweisung UNCATLG von IEHPROGM löscht lediglich den Katalogeintrag für das Band/die Kassette. Ist das EXPDT noch nicht erreicht bzw. die RETPD noch nicht abgelaufen, so kann das Band/die Kassette nicht weiter verwendet werden. In diesem Zusammenhang kam es in manchen MVS-Installationen schon zu einer Knappheit an Bändern bzw. Kassetten. 01.05

edit-uwin.schulung.util(iehpr)

.-.

-

command ******

scroll

===> *****************************

fop of data

page

===>

*****************************

000001 //uwin217c job (uwin,abtdg02),'m.winter1,notify=uwin, 000002 // class=t,msgclass=9 000003 //*************************************************************** iehprogm zum entkatalogisieren von baendern, mit 000004 //* 000005 //* expdt=99000 oder abgelaufener retpd 000006 //*************************************************************** 000007 //copy exec pgm=iehprogm 000008 //sysprint dd sysout=* dd * 000009 //sysin uncatlg dsname=uwin.testband 000010

Beim

erfolgreichen Entkatalogisieren sieht der SYSPRINT wie folgt aus: sysprint

browse

scratch

-

command

1-- line

page

1-- cols

1

80

--

===>

scroll

********************************

top of data

===>

screen

**********************************

iehprogm

system support utilities -

uncatlg dsname=uwin.testband normal end of task returned from uncatlg utility end *******************************

bottom of data

********************************

MVS/ESA JCL

180

Wenn man Datasets auf Platte löschen will, so sollte man dies nicht mit IEHPROGM tun. Dies ist zwar möglich, aber umständlich, weil für die Vorgänge VTOC-Eintrag löschen und Eintrag im User-Katalog löschen zwei Kommandos erforderlich sind. In alter JCL können Sie gelegentlich noch diese SCRATCH- und UNCATLG-Anweisungen finden. Wesentlich einfacher ist es jedoch, IDCAMS zu verwenden, da Sie damit die beiden Vorgänge mit einer Anweisung anstoßen können.

4.4

Die SORT Utility

steht man vor dem Problem, daß man bei der Batch-Verarbeitung eines Dataset die Records in einer anderen als der ursprünglichen Reihenfolge verarbeiten will. Zur Lösung dieses Problems bieten sich mehrere Möglichkeiten an:

Häufig 1.

2.

Sofern das Dataset als VSAM KSDS- oder RRDS-Dataset existiert: Lesen über den Schlüssel bzw. Relative Record Nummer. Ein direktes Lesen hat gegenüber dem sequentiellen Lesen den Nachteil, daß wesentlich mehr physische I/Os benötigt werden. Unter Umständen werden mehrere physische I/Os benötigt, um einen logischen Record zu lesen. Beim sequentiellen Lesen werden dagegen mit einem physischen I/O viele logische Datensätze zur Verfügung gestellt, nämlich genau so viele, wie ein Block enthält.

Direkt lesen sollten Sie von einem VSAM-Dataset nur dann, wenn eine vergleichsweise geringe Zahl von Records bezogen auf die Zahl der gesamten Records des Datasets verarbeitet werden soll. Ansonsten sollten Sie versuchen, sequentiell zu verarbeiten. Umsortieren des Datasets mit Hilfe eines Anwendungsprogrammes, z.B. COBOL, unter Zuhilfenahme der COBOL SORT-Anweisung. Diese Vorgehensweise kann nur dann empfohlen werden, wenn im SORT-Teil Daten verändert werden. Ansonsten sollte auf die unter 3. genannte Möglichkeit zurückgegriffen werden. Wenn Sie den COBOL SORT benutzen, so setzen Sie nach Möglichkeit die Compiler Option FASTSRT ein.

3.

Umsortieren des Datasets mit Hilfe von JCL und des bei Ihnen installierten Programmes zum Sortieren. Das kann das Originalprogramm DFSORT von IBM oder SYNCSORT sein. Die Benutzung eines solchen Programms ist aus Performancegründen die beste Option. Die syntaktischen Unterschiede zwischen DFSORT und SYNCSORT sind marginal. Im Rahmen dieses

1.

Kapitels werden wir uns mit folgenden Funktionen befassen: Sortieren über ein oder mehrere Felder mit dem SORT FIELDS-Kommando.

2.

Unterdrücken von Records mit FIELDS=NONE.

3.

Vorauswahl der

4. 5.

gleichen

Inhalten auf den Sortierfeldern mit SUM

sortierenden Records mit INCLUDE bzw. OMIT. Umformatieren der zu sortierenden Records mit INREC bzw. OUTREC. Bilden von Summenfeldern mit SUM FIELDS. zu

Utility-Programme

181

Kopieren mit der OPTION COPY. Im Rahmen dieses Kapitels werden wir uns auf ein Beispieldataset beziehen, das auf der folgenden Seite abgebildet ist. Es besteht aus einer fünfstelligen Personalnummer, Name und Vorname, Strasse, PLZ und Ort sowie einem im COMP-3 dargestellten Feld, das einen 6.

Umsatz enthält.

JCL-Anweisungen für Sort-Programme Um das

benötigt: 1.

2.

3.

SORT-Programm laufen

lassen

zu

können, werden folgende Informationen

Die Ladebibliothek, auf der das SORT-Programm steht. In den meisten Installationen ist dies die SYS1.SORTLIB. Da diese Bibliothek eine LINKLIB ist, braucht in der JCL keine STEPLIB-Anweisung zu stehen. Zuweisungen für die Ein- und Ausgabe-Datasets.

Temporäre Datasets, die für den eigentlichen Sortiervorgang benötigt werden, falls der virtuelle Speicher nicht ausreicht.

4.

Ein Dataset für

5.

Die

Sortmeldungen. eigentlichen Sort-Kontrollkommandos. Das in diesem Kapitel verwendete Beispieldataset: 00001MUELLER 00002SCHNEIDER 00003SIELDER 00004BECKER 00005PARKER 00006ZAUM 00007WERNER 00008MÜLLER 00009WILHELM 0001OMUELLER 00011SCHNEIDER 00012TROTZ 00013KUBIK 00014ANDERSON 00015VAN DAALEN 00016ECKART 00017ANTON 00018LACROSS 00101TRAUTMANN 00102HESS 00103KAEMPFER

SABINE WERNER NORBERT ERIKA LASSE MICHAEL VERENA KARL NOTKER PETER ELLI CLAUDIA VERA JUERGEN ELMAR SABINE JUERGEN NORBERT

WALTRAUD WILHELM NORBERT

AM HANG 44 OBERWEG 7

5000KOELN 2000HAMBURG WALDGASSE 21 1000BERLIN KEPLERSTRASSE 3 5000KOELN AM FLEET 65 2000HAMBURG RASSELWEG 2 1000BERLIN HALMSTRASSE 6 5000KOELN FISCHERSTRASSE 56 2000HAMBURG AM ACKER 5 1000BERLIN AN DER ROSENELLER 1 5000KOELN CAPRISTRASSE 432 2000HAMBURG AM LANDWEHR 87 1000BERLIN VOCKSTRASSE 32 5000KOELN LAUBENGASSE 12 2000HAMBURG ULMENWEG 77 1000BERLIN ROTTALLEE 4 5000KOELN GELANWEG 65 2000HAMBURG RUE DE RIVOLI 7 0000PARIS WEBERSTRASSE 6 5000KOELN OBERWEG 7 2000HAMBURG AM HANG 44 1000BERLIN

++++? +++++

++++? +++&+

+++/? +++++

+++D? +++0+ ++++? +++++

++++? +++++

++++? +++++

++++?

+++H+ +++R? +++++

++++? +++++ ++++

MVS/ESA JCL

182

Das Eingabe-Dataset wird über die SORTIN DD-Anweisung angesprochen. Sollen mehrere Datasets mit der MERGE Funktion gemischt werden, so werden die Eingabe-Datasets mit SORTIN01, SORTIN02 angesprochen. Es sind maximal 16 SORTIN Datasets erlaubt.

Ausgabe-Dataset wird über die SORTOUT DD-Anweisung angesprochen. In der Regel wird unter SORTOUT ein neues Dataset erzeugt. Die temporären Datasets, die unter Umständen während des Sortiervorganges als Zwischenspeicher benutzt werden, werden über die SORTWKnn DD-Anweisungen angesprochen, wobei nn eine Zahl zwischen Ol und 16 ist. Es muß mindestens eine SORTWKnn angegeben werden. In der Regel werden jedoch nur eine oder zwei temporäre Datasets benötigt. Eine Erhöhung der Zahl der temporären Datasets erhöht die Performance nicht. Der eigentliche Sortiervorgang fmdet im virtuellen Speicher statt. Das

Verbesserung der Performance kann eine Vergrößerung der Region beitragen. Bei der Sortierung großer Datasets sollten Sie den REGION-Parameter des Sort Steps erhöhen. Dies gilt, wenn Sie unter MVS/XA arbeiten. Wenn bei Ihnen schon MVS/ESA installiert ist, dann kann es sein, daß das bei Ihnen verwendete Sortprogramm Data- oder Hiper Spaces nutzen kann. Wenn dem so ist, so brauchen Sie Ihre REGION nicht erhöhen. Das Dataset für Systemmeldungen wird nicht, wie bei Utilities üblich, über die SYSPRINT DD-Anweisung angesprochen. Sofern bei Ihnen SYNC-SORT installiert ist, so verwenden Sie die //SRTMSG DD-Anweisung. Ist bei Ihnen DFSORT installiert, so verwenden Sie die //SYSOUT DD-Anweisung für die Meldungen der Utility. Die grundlegende JCL für einen Sort sieht demnach folgendermaßen aus: Zur

//UWINSRT1 // // // //SORT1 //SRTMSG //SORTIN //SORTOUT // // // // //SORTWK01 //SORTWK02 //SYSIN

JOB

(998,ABTDG02),'M.WINTER',

CLASS=C, MSGCLASS=9, NOTIFY=UWIN EXEC

PGM=SORT,REGION=8M

DD SYSOUT=*

DD DD

DSN=UWIN.SCHULUNG.SORTIN,DISP=SHR DSN=UWIN.SCHULUNG.SORTOUT,

DISP=(,CATLG,DELETE), RECFM=FB,LRECL=8 0, UNIT=SYSDA,

SPACE=(CYL, (100,10) ,RLSE) DD UNIT=3 3 90,SPACE=(TRK, (10,1) ) DD UNIT 3390,SPACE=(TRK, (10,1) ) =

DD

*

SORT KONTROLL KOMMANDOS

183

Utility-Programme

Auf die Sort Kontroll-Kommandos wird im folgenden Kapitel eingegangen. Im vorliegenden Fall wird das Sortout-Dataset neu angelegt und katalogisiert. Wir werden jedoch sehen, daß es auch andere Möglichkeiten gibt, das Dataset für die Weiterverarbeitung vorzubereiten. Auch dies wird noch erläutert werden. Keinesfalls sollte der DSN für SORTIN und SORTOUT gleich sein. (Dies ist syntaktisch zulässig !) Dann würde der sortierte Output im Input-Dataset stehen. Die ursprüngliche Reihenfolge der Records ginge damit für immer verloren. Die Angabe des UNIT- und SPACE-Parameters für die SORTWKnn-Datasets reicht völlig aus (DISP nimmt den Default (NEW.DELETE) an, der DSN wird vom System generiert). Auch wenn kein SORTWKnn-Dataset beim SORT eingesetzt wird, so muß mindestens die SORTWK01 DD-Anweisung vorhanden sein.

Sortiereif mit dem SORT FIELDS-Kommando Wie alle Kontrollkommandos für Utilities, so werden auch die Sort-Kontrollkommandos über die SYSIN DD * Anweisung zugewiesen. Die Syntax der Sort-Kontrollkommandos ist ähnlich, aber nicht identisch mit der von IEBGENER und IDCAMS. Mit Hilfe von SORT FIELDS (nicht FIELD wie bei IEBGENER) wird mitgeteilt, über welche Felder sortiert werden soll und wie das Format der Felder ist. Die Syntax der SortKontrollkommandos sieht folgendermaßen aus:

SORT

FIELDS=(position,länge,format,reihenfolge...)

oder

SORT

FIELDS=(position,länge,reihenfolge),FORMAT=format

Die so definierten Felder werden im weiteren Verlauf als Sortierfelder bezeichnet. Sortiert werden kann über ein Feld oder mehrere Felder. Die oben erwähnten Parameter haben 1. 2. 3.

folgende Bedeutung: Bytes des Sortierfeldes im Eingabe-Record an

die Position des ersten

position gibt länge gibt die Länge des Sortierfeldes an format ist ein zwei Byte langer String, der das Format der Daten im Sortierfeld angibt. Möglich sind: Character (alphabetische Sortierung) CH Zoned Decimal (numerische Sortierung für Felder im DISPLAY-Format) ZD Packed Decimal (numerische Sortierung für Felder im COMP-3-Format) PD Fl Signed Fixed Point Binary (numerische Sortierung, Daten im COMPFormat mit Vorzeichen) Bl Unsigned Binary (numerische Sortierung, Daten im COMP-Format ohne

MVS/ESA JCL

184

Vorzeichen) FL

Signed normalized mit Exponent)

floating

Point

(für

Felder mit

Gleitkommadarstellung

reihenfolge gibt an, ob aufsteigend (A für Ascending) oder absteigend (D für Descending) sortiert werden soll. Beispiele für Angaben eines oder mehrerer Sortierfelder. Die Feldnamen beziehen sich auf das Beispieldataset: 1. SORT FIELDS (6,19, CH, A)

4.

=

Hier wird über ein 19 Byte langes Feld, das an der Position 6 beginnt, sortiert. Das Format ist Character. Die Sortierreihenfolge ist aufsteigend. Es wird aufsteigend nach Nachnamen sortiert. 2.

SORT

FIELDS=(55,4,ZD,A,6,19,CH,A)

Hier wird über zwei Felder sortiert. Das erste ist ein 4 Byte langes Feld, das an der Position 55 beginnt. Das zweite Sortierfeld beginnt an der Position 6 und ist 19 Byte lang. Das Format des ersten Feldes ist ZD, das des zweiten Character. Es wird aufsteigend nach Postleitzahlen und innerhalb gleicher Postleitzahlen aufsteigend nach Nachnamen sortiert.

Sortierung erfolgt in folgender Weise: Zunächst erfolgt die Sortierung nach dem ersten Sortierfeld (Major Control Field). Stehen auf dem ersten Sortierfeld gleiche Werte, so erfolgt die weitere Sortierung nach dem zweiten Sortierfeld (Minor Control Field). Stehen auf beiden Sortierfeldern gleiche Werte, so ist die Reihenfolge im Ausgabedataset nicht vorhersagbar. SORT FIELDS= (76, 5, PD,A) Die

3.

Hier wird über ein 5 Byte langes Feld, das an der Position 76 beginnt, sortiert. Das Format ist Packed Decimal. Das Format des Feldes muß also 9(9) COMP-3 oder 9(08) COMP-3 sein. Die Sortierreihenfolge ist aufsteigend. Es wird aufsteigend nach Umsatz sortiert. 4.

SORT FI ELDS

=

(55,4, ZD, A,

76 , 5 , PD,

D)

Hier wird über 2 Felder sortiert. Es wird aufsteigend nach Postleitzahlen und innerhalb gleicher Postleitzahlen absteigend nach Umsatz sortiert.

wird das Format CHaracter mißbraucht, um über Felder zu sortieren, die in anderen Formaten stehen. Tatsächlich kann man ein Feld im ZD-Format mit CH sortieren, wenn auch mit etwas schlechterer Performance. Es gibt jedoch auch 'Spezialisten', die Felder, die im COMP-3-Format stehen, mit CH sortieren. Das kann gut gehen (sofern die Werte positiv sind und mit den Zahlen nicht gerechnet wurde). Bei negativen Zahlen geht dies aber nicht. Verwenden Sie daher immer die korrekten Formate. Sie vermeiden damit unliebsame Überraschungen.

Häufig

185

Utility-Programme Erhalten der

ursprünglichen Reihenfolge

Mit Hilfe des Parameters EQUALS | NOEQUALS kann auf die Reihenfolge der Ausgabe eingewirkt werden, wenn auf dem Sortierfeld (den Sortierfeldern) gleiche Werte stehen.

EQUALS bewirkt, daß die Reihenfolge von Eingabe-Records, die gleiche Werte auf den Sortierfeldern stehen haben, erhalten bleibt. Die Benutzung der Option EQUALS verlangsamt den Sort erheblich. Deshalb ist NOEQUALS der Default. Er gibt an, daß die Reihenfolge von EingabeRecords, die gleiche Werte auf den Sortierfeldern stehen haben, nicht berücksichtigt wird. EQUALS sollte nur dann angewandt werden, wenn zwingende Gründe dafür sprechen. Beispiel für die Benutzung des EQUALS-Parameters:

//SYSIN SORT

DD

*

FIELDS=(55,4,ZD,A),EQUALS

Beispiel für einen SORT über ein Feld Im folgenden Beispiel wird das Eingabedataset UWIN.SCHULUNG.DS99 über den Der Nachnamen sortiert. Output wird in das neu erzeugte Dataset UWIN.SCHULUNG.SORTOOl gestellt. Der dem Sortstep vorangestellte IDCAMS Step bereinigt den Katalog.

186

edit

MVS/ESA JCL

-

uwin.schulung.procauf(sort01)

01.04 -

command

.

******

*****************************

000001 000002 000003 000004 000005

//uwinsrt1

job

// //

msgclass=9, time=(,05), msglevel=(1,1),typrun=scan msglevel=(1,1)

//*

columns 001 072 ===> page

scroll

===>

Top of data

*****************************

(998,abtdg02),'m.winter1,class=c,notify=uwin,

// exec pgm=idcams 000006 //clrcat 000007 //sysprint dd sysout=* 000008 //sysin dd * 000009 delete (uwin.schulung.sort001) exec pgm=sort 000010 //step1 dd dsn=uwin.schulung.ds99,disp=shr 000011 //sortin 000012 //sysprint dd sysout=* dd sysout=* 000013 //srtmsg 000014 //sortwk01 dd unit=3390,space=(cyl,(1,1)) 000015 //sortwk02 dd un it=3390,space=(cyl,(1,1)) 000016 //sortout dd dsn=uwin.schulung.sort001,disp=(,catlg,delete), 000017 // recfm=fb,lrecl=80, 000018 // space=(trk,(5,1),rlse), unit=dskprm 000019 // 000020 //********************************************************************* * 000021 //* * 000022 //* 6 sortiere ab spalte über 14 bytes absteigend alphabetisch * entspricht absteigend nach nachnamen 000023 //* * 000024 //* 000025 //********************************************************************* dd * 000026 //sysin sort fields=(6,14,ch,d) 000027 ****** **************************** bottom of data ***************************

Den den SORT Step betreffenden Output finden Sie unter SRTMSG oder unter SYSOUT. Dies ist abhängig davon, ob bei Ihnen SYNCSORT oder DFSORT installiert ist.

Im Output sind die Datasetattribute von SORTIN und SORTOUT die Zahl der gelesenen und sortierten Records angegeben.

dargestellt. Außerdem ist

Sollten Ihnen beim Schreiben der Kontrollanweisungen Fehler unterlaufen diese ebenfalls an dieser Stelle gemeldet.

sein,

so

werden

Util ity-Programme browse command

187

srtmsg

wer045c wer246i wer054i wer169i wer052i

1-- line

1-- cols

--

scroll

===>

********************************

wer108i wer110i wer177i

page

step1

-

yep of data

sortin

:

recfm=fb

lrecl=

sortout

:

recfm=fb

lrecl=

===>

1 80 screen

**********************************

80 blksize= 27920 80 blksize= 27920

turnaround sort performed end sort phase filesize 3,040 bytes

38,

rcd in tpf level 2+ end syncsort

-

out

38

uwinsrt1,step1,,diag=cc00,1d9d,337d,600c

*******************************

bottom of data

********************************

Verbesserungen der Performance beim SORT Beim Einsatz des SORT lassen sich einige Performance-Vorteile durch die Benutzung geeigneter Parameter erzielen. Dies betrifft die Zahl der zu sortierenden Records, die sich beschränken läßt, und das Record-Layout, das verkürzt werden kann. Records auswählen mit INCLUDE oder OMIT

Soll der Sort nur über einen Teilbereich des Input-Dataset erfolgen, so kann mit den INCLUDE/OMIT-Parametern die Auswahl der Records gesteuert werden. Diese Vorgehensweise wird dringend empfohlen, da dadurch die Zahl der zu sortierenden Records verringert und die Performance deutlich verbessert wird. Der INCLUDE-Parameter beschreibt die Bedingung, unter denen Records am Sort teilnehmen sollen. Der OMIT-Parameter beschreibt die Bedingung, unter denen die Records am SORT nicht teilnehmen sollen. Benutzen Sie den Parameter, mit dem Sie die Bedingung am leichtesten formulieren können. Sie dürfen nur ein INCLUDE oder ein OMIT verwenden. Verwenden Sie INCLUDE und OMIT gleichzeitig, kommt es zu einem Fehler. Auf INCLUDE bzw. OMIT folgt ein COND-Parameter, der die Auswahlbedingung beschreibt. Mehrere Bedingungen können durch ein logisches AND oder OR verknüpft werden. Es kann auch geklammert werden. Die

allgemeine Syntax sieht folgendermaßen aus:

INCLUDE

COND=(cond1,AND°OR,cond2,....)

oder

OMIT

COND=(cond1,AND°OR,cond2.)

wobei condn

folgendermaßen aufgebaut ist:

188

MVS/ESA JCL

Bedingung bei Vergleich des Feldes mit einem String:

(position,länge,format,operator,string) Bedingung bei Vergleich des Feldes mit einem anderen Feld des Records:

(position,länge,format,operator,position,iänge,format) Als operator sind zulässig:

Operator EQ

Bedeutung

NE

Equal To Not Equal To

GT

Greater Than

GE

Greater Than

LT

Less Than

LE

Less Than

or

or

Equal To

Equal To

Operator wird benutzt, um den Inhalt des ersten Feldes mit dem eines zweiten Feldes, Characterstring, einem Hexstring oder einer Dezimalzahl (Display-Format) zu vergleichen. Wenn mit einem String verglichen werden soll, so muß einem Characterstring der Buchstabe C, einem Hexstring der Buchstabe X vorangestellt werden (s. Beispiele unten). Beispiele für: 1. Vergleich mit einer Dezimalzahl INCLUDE COND=(55,4,ZD,EQ,6000) Hier wird der Inhalt des Feldes PLZ mit der Zahl 6000 verglichen. 2. Vergleich mit einem Character-String INCLUDE COND=(59,3,CH,EQ,C'FRA') Hier wird der Inhalt des Feldes mit der Zeichenfolge 'FRA' verglichen. 3. Vergleich mit einem Hexadezimal-String INCLUDE COND=(76,1,CH,EQ,X'00') Hier wird der Inhalt des Feldes mit dem Hexadezimal-String '00' verglichen (Dies ist ein etwas umständlicher Weg, den Umsatz zu vergleichen). 4. Feld-Feld Vergleich INCLUDE COND=(6,1 ,CH,GT,20,1 ,CH) Hier wird der Record nur dann sortiert, wenn auf der erste Buchstabe des Nachnamens größer als der des Vornamens ist. Der

mit einem

Utility-Programme

189

Nicht alle Feldformate können miteinander Auskunft über die zulässigen Vergleiche:

verglichen werden. Die folgende Übersicht gibt

Vergleich Feld-Feld Format

CH

BI

ZD

PD

Bl

CH ZD PD

Vergleich Feld-Konstante Format

Character-String

Hex-String

Dezimalzahl

BI

CH ZD PD

Beispiele für die Benutzung der Parameters INCLUDE bzw. OMIT: 1.

INCLUDE

COND=(55,4,ZD,EQ,6000) FIELDS=(6,29,CH,A)

SORT

Es werden nur die Records sortiert, die ab Position 55 die Zahl 6000 (PLZ) stehen haben. Anschließend werden diese Records aufsteigend nach Nachname und Vorname sortiert. Die übrigen Records nehmen am Sortiervorgang nicht teil.

2.

INCLUDE

COND=(6,7,CH,EQ,C'MUELLER',AND, SORT

55,4,ZD,EQ,6000) FIELDS=(6,2 9,CH,A)

Es werden nur die Records sortiert, deren Nachname mit dem String 'MUELLER' beginnt und die in Frankfurt wohnen. Die übrigen Records nehmen am Sortiervorgang nicht teil. Anschließend werden diese Records nach Nachname und Vorname sortiert.

Muß ein Kontrollkommando fortgesetzt werden, so beenden Sie es auf der ersten Zeile an einer Stelle, an der ein Komma steht und setzen dann auf der neuen Zeile fort.

MVS/ESA JCL

190

3.

INCLUDE

COND=(5,15,CH,EQ,C'MUELLER',AND, 55,4,CH,EQ,X'F6F0F0F0') SORT FIELDS=(5,15,CH,A)

Beschreibung ist identisch mit der unter 2, lediglich Vergleichsstring als Hexadezimalzeichen dargestellt. OMIT COND=(55,4,ZD,EQ,5000) SORT FIELDS=(6,29,CH,A)

Diese 4.

wurde der

Es werden alle Records außer denen mit PLZ 5000 sortiert. Anschließend werden diese Records nach Name und Vorname sortiert. =

Verkürzung des zu sortierenden Records mit INREC Mit Hilfe des INREC-Kommandos lassen sich aus dem Eingabe-Record gezielt die Felder auswählen, die sortiert und später weiterverarbeitet werden sollen. Diese Vorgehensweise ist dann empfehlenswert, wenn aus einem großen Record vergleichsweise wenige Felder benötigt werden. Die Benutzung von INREC kann die Performance bedeutend erhöhen. Nachteilig wirkt sich die Verkürzung der Records insofern aus, als daß die folgenden Anwendungsprogramme auf den verkürzten Record abgestimmt sein müssen.

Syntax:

INREC

FIELDS=(pos,länge,pos.länge,...)

von INREC soll am folgenden Beispiel verdeutlicht werden. Vom werden nur die Personalnummer, die PLZ und der Wohnort benötigt. Die Ausgangsrecord Sortierung soll aufsteigend nach Ortsnamen erfolgen. Die Reihenfolge der Felder im Ausgabe-Record soll PLZ, Ort, Personalnummer sein. Zu beachten ist, daß sich die nachfolgenden Sort-Kommandos auf das durch INREC erzeugte Record Layout beziehen. Der komplette Job sieht folgendermaßen aus:

Die Benutzung

Utility-Programme

191

EDIT-UWIN.SCHULUNG.UTI L(SORT09) COMMAND ===>

01.04 -

.

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

******

*****************************

000001 000002 000003 000004

//UWINSRT3 JOB (998,ABTDG02),'M.WINTER1,CLASS=C,NOTIFY=UUIN,

Tfjp OF DATA

// MSGCLASS=9, // TIME=(,05), // MSGLEVEL=(1,1) EXEC PGM=IDCAMS .000005 //CLRCAT 000006 //SYSPRINT DD SYSOUT=* DD * 000007 //SYSIN DELETE (UWIN.SCHULUNG.SORT003) 000008 EXEC PGM=SORT 000009 //STEP1 DD DSN=UWIN.SCHULUNG.DS99,DISP=SHR 000010 //SORTIN 000011 //SYSPRINT DD SYSOUT=* DD SYSOUT=* 000012 //SRTMSG 000013 //SORTWK01 DD UNIT=3390,SPACE=(CYL,(1,1)) 000014 //SORTWK02 DD UNIT=3390,SPACE=(CYL,(1,1)) 000015 //SORTOUT DD DSN=UWIN.SCHULUNG.SORT003,DISP=(,CATLG,DELETE), 000016 // RECFM=FB, 000017 // SPACE=(TRK,(5,1),RLSE), UNIT=DSKPRM 000018 // 000019 //********************************************************************* * 000020 //* * ZIEHE FELD PLZ, ORT UND PERS.NR HERAUS 000021 //* * SORTIERE SO ENTSTANDENE DATASET AUFSTEIGEND NACH ORTSNAMEN 000022 //* * 000023 //* ACHTUNG !! ANGABEN BEI SORT FIELDS BEZIEHEN SICH AUF NEUES AYOUT* 000024 //* * 000025 //* 000026 //********************************************************************* 000027 //SYSIN DD * INREC FIELDS=(55,4,59,15,1,5) 000028 SORT FIELDS=(5,15,CH,A) 000029 ******

****************************

BOTTOM OF DATA

***************************

Die SORT FIELDS-Anweisung bezieht sich bereits auf das durch INREC erzeugte neue Record Layout. Da der Ortsname jetzt auf dem fünften Byte beginnt, muß die entsprechende SORT FIELDS-Anweisung angepaßt werden. Wäre SORT FIELDS=(55,4,ZD,A) angegeben worden, so wäre es zu einem Fehler gekommen, weil das neue Ausgabedataset nur noch 24 Byte umfaßt. Die LRECL wird vom Sort selbständig errechnet, die BLKISZE automatisch optimiert. '

Wenn Sie mit INREC arbeiten, so brauchen Sie bei SORTOUT den Parameter LRECL nicht angeben. Der Wert wird vom SORT ermittelt. Wenn Sie aber selber eine Angabe für LRECL machen, so muß diese mindestens so groß sein, wie die Summe der Längenangaben unter INREC.

MVS/ESA JCL

192 Das

Ausgabe-Dataset hat folgendes Aussehen:

browse command

uwin.schulung.ds99

--.

.

--

===>

*********************************

1000berlin 1000berlin 1000berlin 1000berlin 1000berlin 1000berlin 2000hamburg 2000hamburg 2000hamburg 2000hamburg 2000hamburg 2000hamburg 2000hamburg 5000koeln 5000koeln 5000koeln 5000koeln 5000koeln 5000koeln 5000koeln 0000paris

top of data

l i ne 00000000 col 001 080 scroll ===> page

********************************

00003 00006 00009 00012 00015 00103 00002 00005 00008 00011 00014 00017 00102 00001 00004 00007 00010 00013 00016 00101 00018

Einsatz von SUM FIELDS im SORT Die

Summen zu bilden, wird im SORT auf zweierlei Weise Bilden echter Summen auf numerisch definierten Feldern.

Möglichkeit,

1.

eingesetzt:

Unterdrücken von Records, die auf den Sortierkontrollfeldern gleiche Weite stehen haben. Je nachdem, welcher Zweck erreicht werden soll, unterscheidet sich die Syntax:

2.

Für 1:

SUM

FIELDS=(pos,länge,format)

oder für 2:

SUM FIELDS=NONE

193

Utility-Programme

Die zweite Funktion wird häufig im Zusammenhang mit VSAM KSDS-Datasets eingesetzt, wenn eine beliebiges sequentielles Dataset zum Laden des VSAM-Datasets verwendet werden soll. Man verwendet dann den SORT, um aufsteigend nach dem Schlüsselfeld zu sortieren und unterdrückt etwaige Records mit identischen Schlüsselfeldem mit dem SUM

FIELDS=NONE-Kommando.

Echtes Summieren mit SUM FIELDS Da der Umgang mit dem normalen SUM-Kommando etwas schwierig sein kann, wird er hier in mehreren Schritten dargestellt. In unserem Beispieldataset sollen die Umsätze für jeden Ort summiert werden. Daher ist es zunächst einmal notwendig, den Datenbestand aufsteigend nach Postleitzahlen zu sortieren. Anschließend erfolgt das Summieren über das Umsatzfeld. Es werden nur soviele Records ausgegeben,~wie Postleitzahlen vorhanden sind. Die Felder, über die sortiert und summiert wird, dürfen nicht identisch sein. Im

folgenden Beispiel werden nur die erforderlichen SORT-Kontrollkommandos gezeigt.

SORT SUM

FIELDS=(55,4,CH,A) FIELDS=(76,5,PD)

Zunächst wird nach PLZ sortiert und dann innerhalb

Wie

man an

BROWSE

dem SRTMSG

gleicher PLZs addiert. Output erkennt, gibt es nur noch 4 Ausgabe-Records:

SRTMSG

PAGE

STEP1

-

COMMAND

1-- LINE

1-- COLS

--

SCROLL

===>

********************************

TOP OF DATA

WER108I WER110I WER177I

SORTIN

:

RECFM=FB

LRECL=

SORTOUT

:

RECFM=FB

LRECL=

WER045C WER055I WER246I

END SORT PHASE

WER054I WER169I WER052I

RCD IN

===>

1 80 SCREEN

**********************************

80 BLKSIZE= 27920 80 BLKSIZE= 27920

TURNAROUND SORT PERFORMED

0,

INSERT FILESIZE

3,040

38,

TPF LEVEL 2+ END SYNCSORT

34

DELETE

BYTES

OUT

4

UWINSRT3,STEP1,,DIAG=8200,17D1,7977,2C06 -

*******************************

Und

so

BOTTOM OF DATA

sieht das erzeugte Dataset aus:

********************************

MVS/ESA JCL

194 UWIN.SCHULUNG.SORT003

BROWSE

.-.

--

COMMAND

===>

*********************************

00018LACROSS 00103KAEMPFER 00005PARKER 00101TRAUTMANN

NORBERT NORBERT LASSE

WALTRAUD

********************************

TOP OF DATA

********************************

RUE DE RIVOLI 7 AM HANG 44 AM FLEET 65 WEBERSTRASSE 6 BOTTOM OF DATA

LINE 00000000 COL 001 080 SCROLL ===> PAGE

0000PARIS 1000BERLIN 2000HAMBURG 5000KOELN

+++++ ++++ +++++

+++++

*******************************

Die Ausgabe hat aber noch zwei Schönheitsfehler. Die Angaben, die vor der PLZ und den Summen stehen, sind völlig uninteressant und sogar verwirrend, weil man z.B annehmen könnte, daß die rechts dargestellte Umsatzzahl sich auf die zuvor genannte Person beziehen könnte. Dem ist aber nicht so. Klarheit kann man schaffen, in dem man die INRECAnweisung zusätzlich einsetzt. Außerdem lassen sich die Umsatzzahlen besser im DISPLAY-Format lesen. Durch Anhängen des aktuellen Formats in der INREC-Anweisung wird ein Entpacken der Felder bewirkt. Beachten Sie, daß sich die Angaben für SORT FIELDS und SUM FIELDS im folgenden Beispiel auf das mit INREC erzeugte Record-Layout beziehen. Das Feld, über das summiert wird, wuchs durch das Entpacken auf neun Byte an:

FIELDS=(59,15,76,5,PD) FIELDS=(1,15,CH,A) FIELDS=(16,9,ZD)

INREC

SORT SUM

Durch INREC wird ein Record erzeugt, der nur die Felder Ort und Umsatz dieses Feld wird entpackt enthält. Anschließend wird über Ort sortiert und über Umsatz die Summe -

-

gebildet. BROWSE

UWIN.SCHULUNG.SORT006

.

--

COMMAND

===>

*********************************

BERLIN KOELN

000041127 000039172 000041363

PARIS

000003111

HAMBURG

********************************

Noch ein

TOP OF DATA

BOTTOM OF DATA

LINE 00000000 COL 001 020 SCROLL ===> PAGE

********************************

*******************************

Tip:

Sollte das Umsatzfeld für die Ausgabe der Summe nicht groß genug sein, mehrere Möglichkeiten, in der INREC-Anweisung zusätzlich Platz zu schaffen.

FIELDS=(59,15,2Z,76,5) SORT FIELDS=(1,15,CH,A) SUM FIELDS=(16,7,PD) INREC

so

gibt

es

Utility-Programme

195

Durch die Angabe 2Z wurde das numerische Feld um zwei Byte erweitert. Es werden zwei Byte mit x'OO' eingefügt. Diese Erweiterung funktioniert bei allen Zahlenformaten, mit Ausnahme negativer, binär dargestellter Zahlen (S9(n) COMP). Bei Zahlen, die im Displayformat dargestellt sind, können einfach C'OO' eingefügt werden. Dadurch kann z.B. das Feld PLZ um ein Byte erweitert und links mit 0 aufgefüllt werden: INREC SORT

FIELDS=(1,54,C'0',55,4,59,15) FIELDS=(55,5,ZD,A)

In vorangehenden Beispiel wurde die PLZ um ein PLZ sortiert. Das Ergebnis sieht wie folgt aus: *********************************

00018LACROSS 00003SIELDER 00006ZAUM 00009WILHELM 00012TROTZ

CLAUDIA

00015VAN DAALEN

ELMAR

00103KAEMPFER 00002SCHNEIDER 00005PARKER

WERNER

00008MÜLLER

KARL

00011SCHNEIDER 00014ANDERSON 00017ANTON 00102HESS 00001MUELLER 00004BECKER 00007WERNER 0001OMUELLER 00013KUBIK 00016ECKART 00101TRAUTMANN

ELLI

Unterdrücken

NORBERT NORBERT MICHAEL NOTKER

von

NORBERT LASSE

JUERGEN

JUERGEN WILHELM SABINE

ERIKA VERENA PETER VERA SABINE WALTRAUD

Byte erweitert und anschließend nach

TOP OF DATA ******************************** RUE DE RIVOLI 7 00000PARIS WALDGASSE 21 01000BERLIN

RASSELWEG 2

01000BERLIN 01000BERLIN AM LANDWEHR 87 01000BERLIN ULMENWEG 77 01000BERLIN AM HANG 44 01000BERLIN OBERWEG 7 02000HAMBURG AM FLEET 65 02000HAMBURG FISCHERSTRASSE 56 02000HAMBURG CAPRISTRASSE 432 02000HAMBURG LAUBENGASSE 12 02000HAMBURG GELANWEG 65 02000HAMBURG OBERWEG 7 02000HAMBURG AM HANG 44 05000KOELN KEPLERSTRASSE 3 05000KOELN HALMSTRASSE 6 05000KOELN AN DER ROSENELLER 1 05000KOELN VOCKSTRASSE 32 05000KOELN ROTTALLEE 4 05000KOELN WEBERSTRASSE 6 05000KOELN AM ACKER 5

Duplikaten

Für das Laden von VSAM KSDS-Datasets können sequentielle Datasets verwendet werden, sofern diese auf den Schlüsselfeldern des VSAM-Datasets keine identischen Werte stehen haben. Mit SUM FIELDS=NONE läßt sich dieser Zustand auf elegante Weise erreichen. In unserem Beispiel soll unser Dataset zum Laden eines VSAM-Dataset verwendet werden. Im VSAM-Dataset soll der Schlüssel aus Name und Vorname bestehen. Zu diesem Zweck wird die Personalnummer durch den Einsatz des INREC-Kommandos abgetrennt und

MVS/ESA JCL

196

anschließende über Name und Vorname sortiert, wobei Duplikate unterdrückt werden. Die SORT-Kontrollanweisungen müssen folgendermaßen aussehen: INREC SORT

FIELDS=(6,75) FIELDS=(1,29,CH,A)

SUM FIELDS=NONE Es wird ein 75 Byte langer Ausgaberecord erzeugt. Das so erzeugte Dataset kann dann zum Laden des VSAM-Datasets verwendet werden. Dies geschieht dann mit der REPRO Funktion von IDCAMS.

Mischen von Datasets mit MERGE FIELDS Mit dem MERGE-Kommando können mehrere physische Datasets zu einem verschmolzen werden. Im Gegensatz zu einer Konkatenation, die nur ein zusammenhängendes physisches Dataset vortäuscht, wird mit MERGE aus mehreren Datasets ein neues erzeugt.

Syntax des MERGE ist ähnlich wie bei SORT. Syntax:

Die

MERGE

FIELDS=(pos,länge,format,reihenfolge)

Es können auch mehrere Felder

angegeben werden.

ACHTUNG !!! Das Kommando MERGE funktioniert nur dann, wenn die Datasets, die verschmolzen werden sollen, auf den im MERGE FIELDS angegebenen Feldern bereits sortiert sind.

Aus diesem Grund folgt der Merge Step meist auf zwei oder mehr Sort-Steps. Es können bis zu 16 Datasets verschmolzen werden. Diese Datasets werden unter den DD-Namen SORTINOT, SORTIN02 usw. angesprochen.

197

Utility-Programme

Beispiel für einen MERGE: EDIT-UWIN.SCHULUNG.UTIL(SORTOI)

01.04

.

-

COMMAND ******

COLUMNS 001 072 ===> PAGE

SCROLL

===> *****************************

fop op DATA

*****************************

000001 //UUINSRT1 JOB (998,ABTDG02),1M.WINTER1,CLASS=C,NOTIFY=UWIN, 000002 // MSGCLASS=9, 000003 // TIME=(,05), 000004 //* MSGLEVEL=(1,1),TYPRUN=SCAN 000005 // MSGLEVEL=(1,1) EXEC PGM=IDCAMS 000006 //CLRCAT 000007 //SYSPRINT DD SYSOUT=* DD * 000008 //SYSIN DELETE (UWIN.SCHULUNG.SORT001) 000009 EXEC PGM=SORT 000010 //STEP1 000011 //SORTIN01 DD DSN=UWIN.SCHULUNG.DS88,DISP=SHR 000012 //SORTIN02 DD DSN=UWIN.SCHULUNG.DS99.DISP=SHR 000013 //SYSPRINT DD SYSOUT=* DD SYSOUT=* 000014 //SRTMSG 000015 //SORTWK01 DD UN IT=3390,SPACE (CYL,(1,1)) 000016 //SORTWK02 DD UN IT=3390,SPACE (CYL,(1,1)) 000017 //SORTOUT DD DSN=UWIN.SCHULUNG.SORT001,DISP=(,CATLG,DELETE), 000018 // RECFM=FB,LRECL=80, 000019 // SPACE=(TRK,(5,1),RLSE), UN IT=DSKPRM 000020 // 000021 //******************************** 000022 //* ERZEUGE EIN NEUES DATASET AUS DEN UNTER SORTIN01 UND SORTIN02 000023 //* GENANNTEN. DIE DATASET SIND VORSORTIERT NACH NACHNAME 000024 //* 000025 //* =

=

000026 //******************************* 000027 //SYSIN DD * MERGE FIELDS=(6,15,CH,A) 000028 ******

****************************

ßOTTOM OF DATA

***************************

Kopieren von Datasets mit OPTION COPY SORT bietet eine Möglichkeit zum Kopieren von Datasets. Manche SYNCGENR rufen die SORT COPY OPTION auf.

Syntax:

SORT FIELDS=COPY

Programme wie

MVS/ESA JCL

198

oder

OPTION COPY Beide Angaben bewirken eine

SORT

Kopie von SORTIN auf SORTOUT.

Beispiele

Die folgenden werden kann.

Beispiele zeigen

verschiedene Situationen, in denen der SORT

eingesetzt

SORT Beispiel 1 Das erste Beispiel zeigt einen MERGE zweier Datasets. Das Dataset DS99 und DS88 werden gemischt. Zum besseren Verständnis ist das Dataset DS88 nochmals abgebildet: 00001MUELLER 00002SCHNEIDER 00003SIELDER

00004BECKER 00005PARKER 00006ZAUM 00007WERNER

SABINE

WERNER NORBERT SABINE WERNER NORBERT SABINE

00008MÜLLER

WERNER

00009WILHELM 0001OMUELLER 00011SCHNEIDER

NORBERT

AM HANG 44 OBERWEG 7

5000KOELN 2000HAMBURG 1000BERLIN 5000KOELN 2000HAMBURG 1000BERLIN 5000KOELN 2000HAMBURG 1000BERLIN 5000KOELN 2000HAMBURG

AM STRAUCH 77 AM HANG 44 OBERWEG 7 AM STRAUCH 77 AM HANG 44

SABINE

OBERWEG 7 AM STRAUCH 77 AM HANG 44

WERNER

OBERWEG 7

Das Ausgabe-Dataset nach dem MERGE. Die Records daß sie ab Byte 76 nochmals die PLZ besitzen:

von

DS88 sind daran

5000 2000 6000 5000 2000 6000 5000 2000 6000 5000 2000 zu

erkennen,

199

Utility-Programme SABINE

00001MUELLER 00001MUELLER 00002SCHNEIDER 00002SCHNEIDER 00003SIELDER 00003SIELDER 00004BECKER 00004BECKER 00005PARKER 00005PARKER 00006ZAUM 00006ZAUM 00007WERNER 00007WERNER

SABINE WERNER WERNER NORBERT NORBERT

KEPLERSTRASSE 3 AM HANG 44

WERNER

OBERWEG 7

LASSE

AM FLEET 65 RASSELWEG 2

SABINE VERENA KARL WERNER

NORBERT NOTKER PETER SABINE WERNER

0001OMUELLER 00010MUELLER 00011SCHNEIDER

AM STRAUCH 77 WALDGASSE 21

SABINE

NORBERT

00009WILHELM 00009WILHELM

OBERWEG 7 OBERWEG 7

ERIKA

MICHAEL

00008MÜLLER 00008MÜLLER

AM HANG 44 AM HANG 44

AM STRAUCH 77 AM HANG 44

HALMSTRASSE 6 FISCHERSTRASSE 56 OBERWEG 7 AM STRAUCH 77

5000KOELN 5000KOELN 2000HAMBURG 2000HAMBURG 1000BERLIN 1000BERLIN 5000KOELN 5000KOELN 2000HAMBURG 2000HAMBURG 1000BERLIN 1000BERLIN 5000KOELN 5000KOELN 2000HAMBURG 2000HAMBURG 1000BERLIN 1000BERLIN

AM ACKER 5 AN DER ROSENELLER 15000KOELN AM HANG 44 5000KOELN OBERWEG 7 2000HAMBURG

5000 ++++? +++++

2000 6000 ++++? +++&+ 5000 2000

+++/? +++++

6000 5000 +++D? +++0+ 2000 6000 ++++? +++++

5000 2000

Die Tatsache, daß auf den Sortierfeldern (Bytes 1-5) jetzt gleiche Werte stehen, ist unbedeutend. Entscheidend für das Funktionieren des MERGE war, daß vor dem MERGE beide Datasets aufsteigend nach Personalnummer sortiert waren.

Beispiel 2 Das zweite Beispiel zeigt ein Aufsummieren Gesamtsumme nicht geeignet ist: INREC FIELDS=(59,15,55,4) SORT

SORT SUM

Feld, welches für die Aufnahme der

FIELDS=(1,15,CH,A) FIELDS=(16,4,ZD)

Deshalb werden wäre:

über ein

so

viele Records erzeugt, wie

es zur

Gesamtdarstellung der Summe nötig

MVS/ESA JCL

200

9000 3000 8000 8000 8000

BERLIN BERLIN

HAMBURG HAMBURG HAMBURG

5000 5000 5000 5000

KOELN KOELN KOELN KOELN

5000 5000 5000

KOELN KOELN KOELN

5000 5000 5000 5000 5000 5000

KOELN KOELN KOELN KOELN KOELN

KOELN

PARIS_0000_ Lösen läßt sich das Problem, indem in der INREC-Anweisung zwei Nullen eingefügt werden. Beachten Sie, daß in diesem Fall die Records des Ausgabedataset zwei Byte sind als im vorherigen Beispiel:

länger

FIELDS=(59,15,C'00',55,4) SORT FIELDS=(1,15,CH,A) SUM FIELDS=(16,6,ZD) INREC

Die Ausgabe zeigt jetzt nur noch einen Record für eine Stadt. Sollten Sie über COMP-3Felder summieren wollen, so können Sie mit beim INREC mit der Angabe 2Z 2 binäre Nullen einfügen. BROWSE

--

UWIN.SCHULUNG.SORT008 .

COMMAND

===>

*********************************

BERLIN HAMBURG

KOELN PARIS

TOP OF DATA

L I NE 00000000 COL 001 021 SCROLL ===> PAGE

********************************

012000 024000

065000 000000

********************************

BOTTOM OF DATA

*******************************

SORT Beispiel 3

folgenden Beispiele zeigen zwei verschiedene Techniken zur Übergabe temporärer Sort Ausgabedatasets an einen Folge-Step zur Weiterverarbeitung. Die

Utility-Programme

201

Im eisten Step wird das temporäre Dataset &&SORTOUT an weitergepassed, dort verarbeitet und bei Beendigung des Steps gelöscht: edit-uwin.schulung.jcl(pass07) -

command

===>

******

*****************************

000001 000002 000003 000004 000005

//uuin217s // //

//* //

den

Folge-Step

01.01 -.-columns 001 072 scroll ===> page tqp of data *****************************

job (998,abtdg02),1m.winter1,class=c,notify=uwin, msgclass=9, time=(,05), msglevel=(1,1),typrun=scan msglevel=(1,1)

000006 //clrcat exec pgm=idcams 000007 //sysprint dd sysout=* dd * 000008 //sysin 000009 delete uwin.schulung.sortout delete uuin.schulung.ds11 000010

000011 000012 000013 000014 000015 000016 000017 000018 000019 000020 000021

//step1

exec pgm=sort

//sysprint //srtmsg //sortwk01 //sortwk02 //sortin //sortout // // // //sysin

dd sysout=* dd sysout=* dd un it=3380,space = (cyl,(1,1))

it-3380,space (cyl,(1,1)) dsn=uwin.schulung.ds99,disp=shr dsn=&&sortout,disp=(,pass) recfm=fb,lrecl=80, space=(trk,(5,1),rlse),

dd un dd dd

=

unit=sysda dd

*

sort fields=(55,4,a,6,14,d),format=ch 000022 000023 //step2 exec pgm=pgm04 000024 //steplib dd dsn=uwin.schulung.load,disp=shr 000025 //sysprint dd sysout=* 000026 //sysabout dd sysout=* 000027 //sysout dd sysout=* 000028 //infile dd dsn=&&sortout,disp=(old,delete) 000029 //outfile dd dsn=uuin.schulung.ds11,disp=(,catlg,delete), 000030 // recfm=fb,lrecl=80, 000031 // space=(trk,(5,1),rlse),

000032 // ******

un it=dskprm

****************************

bottom of data

***************************

Im zweiten Beispiel wird für das SORTOUT Dataset kein DSN vergeben. MVS generiert in diesem Fall einen Namen. Das Ansprechen des Datasets erfolgt im STEP1 mit einem Rückbezug auf die SORTOUT DD-Anweisung des Steps SORT:

MVS/ESA JCL

202 01.01

EDIT-UWIN. SCHULUNG. JCUPASS08) COMMAND ===>

.

-

yep OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

******

*****************************

000001 000002 000003 000004

//UWIN217S JOB (998,ABTDG02) 'M.WINTER1,CLASS=C,NOT IFY=UWIN, ,

MSGCLASS=9, TIME=(,05), MSGLEVEL=(1,1),TYPRUN=SCAN MSGLEVEL=(1,1)

// //

//*

000005 // EXEC PGM=IDCAMS 000006 //CLRCAT 000007 //SYSPRINT DD SYSOUT=* DD * 000008 //SYSIN 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020 000021 000022 000023 000024 000025 000026 000027 000028 000029 000030 000031 000032

DELETE UWIN.SCHULUNG.SORTOUT DELETE UWIN.SCHULUNG.DS11 EXEC PGM=SORT //SORT

******

****************************

//SYSPRINT DD SYSOUT=* DD SYSOUT=* //SRTMSG

//SORTWK01 DD UNIT=3380,SPACE=(CYL,(1,1)) //SORTWK02 DD UN IT=3380,SPACE (CYL,(1,1)) =

//SORTIN //SORTOUT // // // //SYSIN SORT

DD

DSN=UWIN.SCHULUNG.DS99,DISP=SHR

DD

DISP=(,PASS)

RECFM=FB,LRECL=80, SPACE=(TRK,(5,1),RLSE), UNIT=SYSDA DD

*

FIELDS=(6,14,CH,D,20,15,CH,A)

//STEP1

EXEC PGM=PGM04

//STEPLIB //SYSPRINT //SYSABOUT //SYSOUT //INFILE //OUTFILE // // //

DD

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

DD SYSOUT=* DD SYSOUT=* DD SYSOUT=* DD DD

DSN=*.SORT.SORTOUT,DISP=(OLD.DELETE) DSN=UWIN.SCHULUNG.DS11,DISP=(,CATLG,DELETE), RECFM=FB,LRECL=80, SPACE=(TRK,(5,1),RLSE), UNIT=DSKPRM

BOTTOM OF DATA

***************************

Ihnen wird aufgefallen sein, daß als Programm nur SORT aufgerufen wurde. In den meisten Installationen ist dieser Name über einen Alias-Namen mit dem tatsächlich auszuführenden SORT-Programm verknüpft. Erkundigen Sie sich, ob Sie in gleicher Weise verfahren können oder aber explizit DFSORT oder SYNCSORT als PGM-Name angeben müssen. Beachten Sie, daß in den eben genannten Beispielen die unter SORTOUT genannten Datasets verloren

gehen,

wenn es

im STEP1

zu

einem ABEND kommen sollte. Dies

Utility-Programme hängt mit der sicher ist.

4.5

203

Benutzung

der

PASS zusammen, die nicht RESTART-

Disposition

Generation Data Groups

Generationdatasets

(Generation

Data

Group

GDG)

eröffnen die

Möglichkeit,

Datasets

über einen relativen DSN anzusprechen. Der Vorteil von GDGs besteht darin, daß man mit der gleichen JCL immer neue Datasetnamen ansprechen kann. Folgendes Beispiel soll dies illustrieren:

//INPUT //OUTPUT // // //

-

DD

DSN=UWIN.MONTAG,DISP=SHR

DD

DSN=UWIN.DIENSTAG,

DISP=(,CATLG,DELETE), UNIT=DSKPRM,RECFM=FB, SPACE=(CYL, (5,1) ,RLSE)

Wie man sich leicht vorstellen kann, müßte diese JCL jeden Tag geändert werden oder es müßte für jeden Tag der Woche eine andere JCL vorgehalten werden. Bei GDGs sieht die Sache anders aus:

//INPUT //OUTPUT // // // //

DD DD

DSN=UWIN.TAG(0),DISP=SHR DSN=UWIN.TAG(+1),

DISP=(,CATLG,DELETE), UNIT=DSKPRM, RECFM=FB,

SPACE=(CYL,(5,1),RLSE)

Die beiden DSNs sind sogenannte 'relative' Namen. MVS erzeugt daraus absolute Namen, denn nur die können vom Katalog verarbeitet werden. Vorausgesetzt, daß bereits 10 Generationen des Datasets existieren, so wird unter dem DD-Namen OUTPUT der DSN UWIN.TAG.G0011V00 Bei der erzeugt. folgenden Generation wird UWIN.TAG.G0012V00 erzeugt. Der DD-Name INPUT spricht die 10. Generation an, da sich das TAG(O) auf die letzte existierende Generation bezieht. Bevor mit GDGs in der oben angegebenen Weise (TAG(+1)) gearbeitet werden kann, muß ein GDG-Basiseintrag erzeugt werden. Wie dies zu geschehen hat, wird im folgenden

Kapitel gezeigt. Die V00

am

Ende des absoluten DSN steht für Version 00. Sie besitzt aber keinerlei

praktische Bedeutung.

204

MVS/ESA JCL

Erzeugen des GDG-Basiseintrags mit IDCAMS Syntax: DEFINE

GENERATIONDATAGROUP

(NAME(Katalogeintrag) LIMIT(limit) [EMPTY | NOEMPTY] [SCRATCH I NOSCRATCH] [TO(Datum) | FOR(Tage)])

-

-

-

-

-

GENERATIONDATAGROUP kann mit GDG

abgekürzt werden. Mit diesem IDCAMS-Kommando wird nur der Basiseintrag erzeugt. Der Name des Basiseintrages ist mit dem NAME-Parameter zu übergeben. LIMIT gibt die maximale Zahl der Generationen an, die vorgehalten werden sollen. Mehr als 255 Generationen vorzuhalten, ist nicht möglich. Mit EMPTY/NOEMPTY wird angegeben, was passieren soll, wenn die mit LIMIT angegebene maximale Zahl der Generationen erreicht wird: EMPTY bedeutet, daß in diesem Fall alle vorherigen Generationen entkatalogisiert werden. Dies ist eine extrem merkwürdige Option, die nicht verwendet werden sollte. NOEMPTY ist der Default und entkatalogisiert werden soll.

gibt

an, daß

Mit SCRATCH/NOSCRATCH wird angegeben, ob beim auch der VTOC-Eintrag gelöscht werden soll.

nur

die letzte Generation

Entkatalogisieren eines

GDGs

SCRATCH löscht beim Entkatalogisieren auch den VTOC-Eintrag. Da SCRATCH kein Default ist, empfiehlt es sich, immer SCRATCH anzugeben. Ansonsten werden nicht katalogisierte Datasets erzeugt.

NOSCRATCH erzeugt in Nicht-SMS-Umgebungen nicht katalogisierte Datasets, die dann als Leichen auf den Platten herumstehen und sollte daher vermieden werden. Unter SMS verhindert die Angabe von NOSCRATCH das Löschen der alten Generationen. Damit wird der unter LIMIT gesetzte Wert außer Kraft gesetzt. Mit TO bzw. FOR lassen sich Schutzfristen definieren. Dies ist bei Plattendatasets wenig sinnvoll, zumal mit PURGE ein Löschen ohnehin erzwungen werden kann. Im

folgenden Beispiel wird ein GDG-Basiseintrag erzeugt.

205

Utility-Programme EDIT-UW IN.SCHULUNG. IDCAMS(GDG) COMMAND ===>

01.00

******

*****************************

000001 000002 000003 000004

//UWIN217D

******

****************************

JOB

.

-

fop op DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

(998,ABTDG02),'M.WINTER1,CLASS=K,NOT IFY=UWIN,

MSGCLASS=9 // EXEC PGM=IDCAMS //CRGDG //SYSPRINT DD SYSOUT=* DD * 000005 //SYSIN DEFINE GDG (NAME(UUIN.SCHULUNG.GDG) LIMIT(5) SCRATCH) 000006

Im IOF sollte

***************************

folgendes Ergebnis zu sehen sein:

SYSPRINT

BROWSE

BOTTOM OF DATA

CRGDG

—

1-- LINE

PAGE

1-- COLS

-

COMMAND

********************************

IDCAMS

SCROLL

===>

TOP OF DATA

===>

1 80 SCREEN

**********************************

SYSTEM SERVICES

TIME: 11:45:28

DEFINE GDG (NAME(UWIN.SCHULUNG.GDG)

LIMIT(5) SCRATCH)

IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 *******************************

BOTTOM OF DATA

********************************

Erzeugen einer neuen Generation Um eine

neue Generation zu erzeugen, wird an den relativen DSN (+1) angehängt. MVS einen absoluten DSN. In Nicht-SMS-Umgebungen muß ein sogenannter dann erzeugt Model DCB verwendet werden. Dieser Modellname kann in jeder Installation frei definiert werden. Im Beispiel wurde der Modellname MODEL genannt. In SMS-Umgebungen kann die Angabe des DCB-Parameters in der Regel entfallen. Erkundigen Sie sich, ob er bei Ihnen eingesetzt werden muß und wie er heißen muß.

MVS/ESA JCL

206 Er wird als Wert des DCB-Parameters

codiert, wie folgendes Beispiel zeigt:

edit-uwin.schulung. idcams(gdg02) command ===>

01.01

.

-

*****************************

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015

//uwin217g job (998,abtdg02),'m.winter',notify=uwin, // class=c, // msgclass=9, // time=(,10), // msglevel=(1,1) //* msglevel=(1,1),typrun=scan exec pgm=pgm01 //step1 //steplib dd dsn=uwin.schulung.load,disp=shr //sysprint //sysabout //sysout //outfile // // //

******

****************************

In den

columns 001 072 ===> page

scroll top of data

dd sys0ut=* dd sysout=* dd sysout=* dd

dsn=uwin.schulung.gdg(+1),disp=(,catlg), dcb=model,recfm=fb,

space=(trk,(5,1),rlse), un it=dskprm bottom of data

**************************

Messages des Jobs wird gezeigt, welcher absolute DSN erzeugt wurde:

browse

*

messages -

page

1-- line

1-- cols

1

80

--

********************************

jop of data

**********************************

step was executed cond code 0000 ief142i uwin217g step1 cataloged ief285i uwin.schulung.gdg.g0002voo vol ser nos= dsk021. ief285i ief373i step /step1 / start 91191.1145 step ief374i /step1 0min 00.18sec srb / stop 91191.1145 cpu -

-

0min 00.03s

Sofern SMS aktiviert ist, wird aus der Meldung CATALOGED die Meldung ROLLED IN. Der Aussagewert ist der gleiche. Da unter SMS schon beim Step-Anfang katalogisiert wird, werden GDGs, die der Kontrolle von SMS unterliegen, in einen vorläufigen Zustand gebracht. Dieser wird als 'deferred roll-in' Status bezeichnet. Dies ist notwendig, da erst bei Step-Ende die Disposition wirksam wird. Ist sie CATLG, so wird die neue Generation 'eingerollt' und damit aktiv, ist sie DELETE, so wird die neue Generation sofort wieder

gelöscht.

Wird das LIMIT erreicht, so wird die älteste Generation aus dem Katalog gelöscht. Wenn SCRATCH bei der Definition des Basiseintrages angegeben wurde, so wird auch der VTOC-Eintrag gelöscht (Diese Vorgehensweise wird empfohlen). In den Messages wird dies aber nicht dokumentiert.

Utility-Programme

207

Es stehen somit immer

so

viele Generationen

zur

wurden.

Abändern

von

Verfügung,

wie mit LIMIT

festgelegt

Basisparametern

Die Basisparameter EMPTY/NOEMPTY und SCRATCH/NOSCRATCH lassen sich mit dem IDCAMS ALTER-Kommando ändern. Das Limit einer GDG können Sie mit diesem Kommando nur ändern, wenn SMS bei Ihnen installiert ist. Ansonsten müssen Sie auf den weiter unten beschriebenen Weg

zurückgreifen. Im folgenden Beispiel wird eine GDG mit dem Attribut NOSCRATCH versehen, was unter SMS übrigens unsinnig wäre. EDIT-UWIN.SCHULUNG. IDCAMS(GDGALT) COMMAND ===>

01.00

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009

//UWIN217D

JOB

// // //

MSGCLASS=9, TIME=(,05), MSGLEVEL=(1,1) MSGLEVEL=(1,1),TYPRUN=SCAN

******

TOP OF DATA

*****************************

(998,ABTDG02),'M.WINTER1,CLASS=C,NOTIFY=UWIN,

EXEC PGM=IDCAMS //CRGDG //SYSPRINT DD SYSOUT=* DD * //SYSIN ALTER UWIN.SCHULUNG.GDG NOSCRATCH **************************** ROTTOM OF DATA

Im SYSPRINT sieht das

COLUMNS 001 072 ===> PAGE

SCROLL

******

//*

.-

-

***************************

Ergebnis folgendermaßen aus:

EDIT-UWIN.SCHULUNG. IDCAMS(GDGALT) 01.00 BROWSE SYSPRINT CRGDG PAGE 1-- LINE COMMAND ===>

COLUMNS 001 072 1-- COLS 1 80 SCROLL ===> SCREEN

-.--

-

--

-

********************************

IDCAMS

ALTER

-pop OF DATA

**********************************

SYSTEM SERVICES

TIME: 11:53:33

UWIN.SCHULUNG.GDG NOSCRATCH

IDC0531I ENTRY UWIN.SCHULUNG.GDG ALTERED IDC0001I FUNCTION

COMPLETED,

HIGHEST CONDITION CODE WAS 0

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 *******************************

BOTTOM OF DATA

********************************

MVS/ESA JCL

208

Ändern des LIMITS ohne SMS Will

man

das LIMIT einer GDG herabsetzen,

so

sind, sofern SMS nicht installiert ist,

folgende Schritte erforderlich: 1. Alle Generationen entkatalogisieren. Den GDG-Basiseintrag löschen. 2. 3. Den GDG-Basiseintrag mit dem neuen LIMIT definieren. Die entkatalogisierten Generationen wieder katalogisieren. 4. Die Schritte 1 und 2 lassen sich durch ein IDCAMS-Kommando erledigen.

//SYSIN

DD

*

DELETE UWIN.SCHULUNG.GDG FORCE

Zusatzparameter FORCE ist hier unbedingt erforderlich. Er bewirkt, daß der Basiseintrag gelöscht werden kann, obwohl noch Generationen existieren. Die vorhandenen Generationen werden bei diesem Vorgang entkatalogisiert. Notieren Sie sich die VolumeAngaben der Generationen bevor Sie diesen Schritt ausführen. Ansonsten können Sie in große Schwierigkeiten beim Wiederauffinden kommen. Nach dem Löschen des Basiseintrages definieren Sie die Basis neu, diesmal mit dem neuen Der

LIMIT.

Anschließend müssen Sie die Generationen wieder katalogisieren. Dazu können Sie ISPF oder auch das Programm IEFBR14 verwenden. In beiden Fällen brauchen Sie die Volume-

Angaben.

209

Utility-Programme 01.05

EDIT-UWIN.SCHULUNG. IDCAMS(RECAT)

-.

-

COMMAND ******

SCROLL

===>

*****************************

TOP OF DATA

===>

PAGE

*****************************

000001 //UWIN217C JOB (UWIN,ABTDG02),'M.WINTER',NOTIFY=UWIN, 000002 // CLASS=T,MSGCLASS=9 000003 //*************************************************************** 000004 //* IEFBR14 ZUM KATALOGISIEREN VON GDG DATASETS 000005 //* 000006 000007 000008 000009 000010

//*

//*************************************************************** //BR14

EXEC PGM=IEFBR14

//SYSPRINT DD SYSOUT=* DD DSN=UWIN.SCHULUNG.GDG.G0002V00, //CAT1 000011 // DISP=(OLD,CATLG),

UNIT=3390,VOL=SER=DSK003

000011 // 000010 //CAT2

DD

000011 000011 000010 000011 000011 000010

UNIT=3390,VOL=SER=DSK021 DD DSN=UWIN.SCHULUNG.GDG.G0005V00,

DSN=UWIN.SCHULUNG.GDG.G0003V00, DISP=(OLD,CATLG), UNIT=3390,VOL=SER=DSK011 DD DSN=UWIN.SCHULUNG.GDG.G0004V00, DISP=(OLD,CATLG),

// //

//CAT3 // //

//CAT4

DISP=(OLD,CATLG),

000011 // 000011 // ******

UNIT=3390,VOL=SER=DSK022

****************************

BOTTOM OF DATA

***************************

Andern des LIMITS mit SMS

Mit SMS ist das Ändern des LIMITS eine einfache Sache. Man benutzt einfach das IDCAMS ALTER-Kommando:

//SYSIN

DD

*

ALTER UWIN.SCHULUNG.GDG

LIMIT(4)

Sofern die GDG mit SCRATCH definiert wurde, erscheint folgende

IDC0196I

Meldung:

UWIN.SCHULUNG.GDG.G000IVO0 HAS BEEN ROLLED OFF AND DELETED

War die GDG mit NOSCRATCH definiert, so kann folgendes passieren. Untersteht die GDG der Kontrolle von SMS, so erscheint die gleiche Meldung. Die Generation wird entkatalogisiert und gelöscht. Ist die GDG nicht unter der Kontrolle

von

SMS, so erscheint folgende Meldung:

MVS/ESA JCL

210

IDC0196I

UWIN.SCHULUNG.GDG.GO00IVO0 HAS BEEN ROLLED OFF AND UNCATALOGED

Im letzteren Fall entsteht ein nicht katalogisiertes Dataset.

Ansprechen existierender GDGs Existierende GDGs werden normalerweise über ihren relativen DSN angesprochen. Will man die zuletzt erzeugte Generation ansprechen, so ist die Nummer 0 zu verwenden, wie

folgendes Beispiel zeigt.

//INPUT

DD

DSN=UWIN.SCHULUNG.GDG(0),DISP=SHR

Sollen frühere Generationen Zahl einzutragen. So spricht:

//INPUT

DD

die vorletzte Generation

angesprochen werden,

so

ist in der Klammer eine

negative

DSN=UWIN.SCHULUNG.GDG(-1),DISP=SHR an.

Wird eine nicht existierende Generation

angesprochen, so kommt es zu einem JCL-Fehler. anzusprechen.

Es ist auch möglich, GDGs über ihren absoluten DSN

Löschen einer GDG ohne SMS Will man eine komplette GDG löschen, so kann man dies mit dem Kommando DELETE GDG tun. Sofern die GDG mit SCRATCH definiert wurde, werden beim Löschvorgang auch alle Generationen mit gelöscht. Dazu muß der Zusatzparameter FORCE verwendet werden. War die GDG mit NOSCRATCH definiert worden, so werden zwar alle Katalogeinträge, nicht aber die VTOC-Einträge gelöscht. Deshalb sollte mit dem ALTER-Kommando die Option SCRATCH vor dem Löschen gesetzt werden.

211

Utility-Programme 01.00

edit-uwin.schulung. idcahs(gdgdel)

---.

-

command ******

===>

*****************************

top of data

columns 001 072 scroll ===> page

*****************************

000001 //uwin217d job (998,abtdg02),1m.winter1,class=c,notify=uwin, 000002 // msgclass=9, 000003 // time=(,05), 000004 // msglevel=(1,1) 000005 //* msglevel=(1,1),typrun=scan exec pgm=idcams 000006 //crgdg sysout=* dd 000007 //sysprint * dd 000008 //sysin alter uwin.schulung.gdg scratch 000009 delete uwin.schulung.gdg gdg force 000010 ******

****************************

bottom of data

***************************

Die Benutzung des FORCE-Parameters ohne den Zusatz GDG bewirkt ein sieren ohne Löschen der Generationen.

Entkatalogi-

Löschen einer GDG mit SMS Will man unter SMS eine komplette GDG löschen, so kann man dies ebenfalls mit dem Kommando DELETE GDG tun. Allerdings ist es Ihnen unter SMS nicht möglich, den Zusatzparameter FORCE einzusetzen, es sei denn, Sie besitzen eine entsprechende RACFAutorisation. Um das Löschen vorhandener Generationen sicherzustellen, wird ein normaler DELETE mit einem * im DSN-Teil dem DELETE GDG vorangestellt. Das Zeichen * darf einen

kompletten Qualifier ersetzen.

edit-uwin.schulung. idcams(gdgdel) command ===> ******

*****************************

000001 //uwin217d 000002 // 000003 // 000004 // 000005 //* 000006 //crgdg 000007 //sysprint 000008 //sysin

000009 000010 ******

columns 001 072

01.00 -

.

Top of data

scroll

===>

page

*****************************

(998,abtdg02),1m.winter1,class=c,not ify=uwin, msgclass=9, time=(,05), msglevel=(1,1) msglevel=(1,1),typrun=scan job

exec pgm=idcams dd sys0ut=*

dd

*

delete uwin.schulung.gdg.* delete uwin.schulung.gdg gdg ****************************

bottom of data

***************************

MVS/ESA JCL

212 Der erste DELETE löscht alle vorhandenen

gelöscht.

zur

GDG

usw.

z.B. leere GDG selber

zugehörenden Datasets,

Anschließend wird die Dazu ist der Zusatzparameter GDG zu verwenden.

UWIN.SCHULUNG.GDG.G0003V00

nun

Besonderheiten von GDGs GDGs haben

einige Besonderheiten,

die

man

kennen muß,

Überraschungen zu vermeiden.

um

unangenehme

Die wichtigste ist die, daß beim Anlegen einer neuen Generation der Update auf die Generationsnummern nach Job-Ende erfolgt. Es ist also nicht möglich, mit Hilfe des relativen DSN innerhalb eines Jobs auf gerade angelegte neue Generationen zuzugreifen. Wird als relative Nummer 0 oder eine negative Zahl benutzt, so ist als DISP nur OLD, SHR oder MOD zulässig. MOD darf in diesem Fall nicht den Default NEW annehmen. Ansonsten kommt es zu folgendem JCL-Fehler: IEF286I JOBNAME STEPNAME DDNAME

DISP FIELD -

INCOMPATIBLE

WITH DSNAME

Wird die Generationsnummer 9999 erreicht, so wird als nächstes die Generation G0000V00 angelegt. Nur in diesem Fall kann sie existieren, beim Erzeugen der ersten Generation wird der absolute DSN G0001V00 erzeugt.

4.6

IEBCOPY

Obwohl man aufgrund des Namens vermuten könnte, die wichtigste Funktion IEBCOPY sei das Kopieren von Datasets, ist dem nicht so. Am häufigsten wird er Compress von PO-Datasets, insbesondere von Ladebibliotheken, verwandt.

Bibliotheken

von zum

kompressen mit IEBCOPY

Bei jedem Update eines Members wird dasselbe nicht überschrieben. Statt dessen wird eine neue Version ans Ende des PO-Dataset gestellt. Die alte Version erhält eine Kennzeichnung, so daß auf sie nicht mehr zugegriffen werden kann. Irgendwann einmal wird der Punkt erreicht sein, an dem das PO-Dataset voll ist. In diesem Fall werden Sie versuchen, über die ISPF Option 3.1 die Funktion 'Compress' auszulösen. Wenn Sie hierbei ständig die Meldung 'Data Set in Use' erhalten, so bedeutet dies, daß andere User ebenfalls auf das PO-Dataset zugreifen. Für die Funktion 'Compress Dataset'

brauchen Sie aber einen exklusiven Zugriff. Sie können natürlich ständig neue Versuche starten, in der Hoffnung, irgendwann einmal den gewünschten Zugriff zu bekommen. Einfacher ist es jedoch, in dieser Situation das Programm IEBCOPY einzusetzen, um die gewünschte Funktion durchzuführen.

213

Utility-Programme

Um den Compress ausführen zu können, benötigt MVS Zwischenspeicher-Datasets. Diese werden über die SYSUT3 und SYSUT4 DD-Anweisung angesprochen.

PO-Dataset, das compressed werden soll, muß mit DISP=OLD allokiert werden. Geschieht dies nicht, besteht die Gefahr, daß die Bibliothek inkonsistent und damit unbrauchbar wird. Ist ein solcher Fall eingetreten, so hilft nur noch das Zurückladen einer

Das

Sicherungsversion. Als Kontrollkommando wird COPY angegeben. Die Parameter sind INDD für INput Data Definition und OUTDD für OUTput Data Definition. Ihnen muß ein DD-Name zugeordnet werden. Beim Compress eines PO-Datasets ist er gleich. Im

folgenden Beispiel wird ein PO-Dataset compressed:

edit-uwin. schulung. ut il (iebcopy)

01.00

.-

columns 001 072

-

command

scroll

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007

//uwin217g job (998,abtdg02),'m.winter1, // notify=uwin, // class=c,

000008 000009 000010 000011 000012

//sysut3 //sysut4

dd un it=sysda,space = (trk,(5,1))

//podat //sysin

dd

dsn=uwin.schulung.load,disp=0ld

dd

*

******

****************************

fop of data

===>

page

*****************************

// msgclass=9, // msglevel=(1,1) //compress exec pgm=iebcopy //sysprint dd sysout=*

copy

dd un it=sysda,space = (trk,(5,1))

outdd=podat,

indd=podat bottom of data

***************************

An dieser Stelle fällt Ihnen möglicherweise auf, daß die DD-Anweisungen für die Arbeitsdatasets SYSUT3 und SYSUT4 weder einen DISP- noch einen DSN-Parameter besitzen. Da er weggelassen wurde, tritt der Default DISP=(NEW,DELETE,DELETE) in Kraft, der bei temporären Datasets in Ordnung ist. Der DSN für eine solches Dataset wird von MVS generiert. Es sei nochmals darauf hingewiesen, daß die Disposition für das unter PODAT angesprochene PO-Dataset niemals auf SHR gesetzt werden darf.

4.7

IEFBR14

Das

Utility-Programm IEFBR14 läßt sich für 'Disposition Processing' verwenden. Das Programm führt lediglich eine Assembler Instruktion aus, es verzweigt (branch) zum Register 14, das die Rücksprungadresse des aufrufenden Programms enthält (in diesem Fall wird die Kontrolle an MVS zurückgegeben). Obwohl das Programm nichts tut, ist es nützlich, weil allokiert und deallokiert wird. Dies heißt, daß die im DISP-Parameter gesetzte Disposition gültig wird.

214

MVS/ESA JCL

Dispositions-Verarbeitung mit IEFBR14 Da die Disposition von Datasets, die beim Lauf von IEFBR14 angesprochen werden, wirksam wird, kann man mit diesem Programm Datasets leer anlegen. Dies gilt aber nur für Datasets auf Platte. Viele Programmierer setzen IEFBR14 gerne ganz am Anfang eines Jobs ein, um alle im Job benötigten Datasets leer anzulegen. In den Folge-Steps werden diese Datasets dann mit DISP=OLD oder DISP=SHR angesprochen. Der Vorteil dieser Vorgehensweise ist, daß es während des Jobs nicht mehr zu einem Problem mit der Allokation von Platz kommen kann. Dennoch wird diese Vorgehensweise nicht empfohlen. Sie hat zwei sehr schwerwiegende Nachteile: 1.

IEFBR14 macht keinen OPEN und braucht daher eine BLKSIZE-Angabe.

2.

Bei IEFBR14 kann nicht mit dem RLSE gearbeitet werden.

Subparameter

des SPACE-Parameters

Sofern bei Ihnen gemischte Plattengruppen bestehend aus 3380er und 3390er Platten installiert sind, ist bei der Benutzung von UNIT=gruppenname nicht sicher, ob das Dataset auf einer 3380er oder 3390er Platte angelegt wird. Es kann daher keine optimale BLKSIZE angegeben werden. Läßt man die BLKSIZE Angabe weg, so kann auch MVS keine optimale BLKSIZE erzeugen, da IEFBR14 ja keinen OPEN absetzt. Stattdessen wird ein Dataset mit BLKSIZE=0 erzeugt, das nachher nicht mehr benutzbar ist. Wird bei IEFBR14 im SPACE-Parameter RLSE eingesetzt, so wird der gesamte Primärplatz freigegeben (IEFBR14 erzeugt schließlich keinen Output). Ohne RLSE läuft man aber Gefahr, viel Platz zu verschwenden. Auch bei dem Versuch, IEFBR14 zum Bereinigen des Katalogs und zum Löschen von Datasets einzusetzen, ergeben sich Probleme: EDIT-UWIN.SCHULUNG.IDCAMS(BR1401 )

01.05

.-.-.

-

COMMAND ******

===> *****************************

SCROLL fop OF DATA

===>

PAGE

*****************************

000001 //UWIN217C JOB (UWIN,ABTDG02),'M.WINTER1,NOTIFY=UWIN, 000002 // CLASS=T,MSGCLASS=9 000003 //*************************************************************** 000004 //*

000005 000006 000007 000008

//* IEFBR14 ZUM LOESCHEN EINES DATASET //* //*************************************************************** EXEC PGM=IEFBR14 //BR14

000009 //SYSPRINT DD SYSOUT=* 000010 //DELDS DD DSN=UWIN.TEST.OUTFILE, 000011 // DISP=(0LD,DELETE) ******

****************************

BOTTOM OF DATA

***************************

Utility-Programme

215

Wenn das unter DELDS angesprochene Dataset bei Step-Beginn schon nicht mehr existiert, kommt es zu einem JCL-Allokationsfehler, weil das Dataset mit DISP=(OLD,DELETE) angefaßt wird. DISP=OLD setzt aber ein existierendes Dataset voraus. Die Folge: der Job stürzt ab. Dies ist jedoch überflüssig, weil ja nur der Katalog bereinigt werden sollte. Die Tatsache, daß das Dataset bei Step-Beginn schon nicht existiert, beeinträchtigt ein späteres Vergeben des DSN nicht.

Wenn man nur den Katalog bereinigen will, so sollte man IDCAMS verwenden. Dort kann auch der Return Code mit SET MAXCC zurückgesetzt werden.

Sinnvoll einsetzen läßt sich IEFBR14 in Nicht-SMS-Umgebungen, wenn vorhandene katalogisiert werden sollen. In SMS-Umgebungen wird sich IEFBR14 kaum noch

Datasets

behaupten können.

VSAM

5

VSAM ist eine der am häufigsten genutzten Zugriffsmethoden. Die Abkürzung VSAM steht für Virtual Storage Access Method. VSAM-Datasets müssen auf Speicherplatten mit Direktzugriff (DASD) residieren.

Arten Es

von

VSAM-Datasets

gibt vier Arten von VSAM-Datasets: (Key Sequenced Data Sets) ESDS (Entry Sequenced Data Sets) RRDS (Relative Record Data Sets) LDS (Linear Data Sets)

1. KSDS

2. 3. 4.

Sie unterscheiden sich im Aufbau und in der Art und Weise, wie auf einen logischen Record zugegriffen wird. In der praktischen Arbeit haben die KSDS-Datasets die größte Bedeutung, da auf die einzelnen Records mit Schlüsseln zugegriffen werden kann. Zusätzlich zum Primärschlüssel lassen sich bis zu 255 Sekundärschlüssel definieren. KSDS-Datasets bieten auch die Möglichkeit einer effizienten sequentiellen Verarbeitung, was für die Batch-Verarbeitung von großer Bedeutung ist.

ESDS-Datasets sind die sequentielle Variante der VSAM-Datasets. Sie besitzen keinen Schlüssel. Neue Records werden wie bei PS-Datasets ans Ende des bestehenden Datasets geschrieben. Auch über ESDS-Datasets lassen sich Alternativschlüssel legen (allerdings nur mit CICS nutzen). In der Praxis werden ESDS häufig eingesetzt, um Transaktionen weg zu schreiben. Bestimmte On-Line Umgebungen (z.B. CICS Customer Information Control System) verlangen VSAM-Datasets. Ein Einsatz von PS-Datasets ist in solchen Umgebungen nicht möglich. RRDS-Datasets besitzen einen relativen Schlüssel, d.h. es muß möglich sein, zwischen der Position des Records im Dataset und dem logischen Schlüssel eine eindeutige Beziehung herzustellen. Da dies in der Praxis nicht einfach ist, besitzen RRDS-Datasets nur eine geringe Bedeutung. Alternativschlüssel werden bei RRDS-Datasets nicht unterstützt. RRDS-Datasets besitzen eine feste Record-Länge. LDS-Datasets sind das jüngste Kind unter den VSAM-Datasets. Sie unterscheiden sich erheblich von den bisher bekannten VSAM-Datasets. Sie können nur dort eingesetzt werden, wo DFP 2.3 installiert ist (entspricht dem jüngsten MVS/XA Release oder -

MVS/ESA).

218

MVS/ESA JCL

VSAM wurde 1972 eingeführt. Die Absicht von IBM, durch VSAM-Datasets die anderen Datasetformen (insbesondere die PS-Datasets) zu ersetzen, ließ sich nicht realisieren. Dies liegt daran, daß die PS-Datasets mit der Zugriffsmethode QSAM eine sehr gute Performance haben, so daß kein Grund bestand und besteht, von QSAM-Datasets abzugehen. VSAM wurde ständig weiterentwickelt und steht heute in der Form von DFP/VSAM V 2.3 zu Verfügung. VSAM ist ein zentraler Bestandteil der Katalogverwaltung in MVS. Master- und UserKatalog sind VSAM-Datasets. VSAM stellt die Integrated Catalog Facility (ICF) zur Verfügung. Sie erlaubt eine effektive Verwaltung der Datasetbestände mit den Komponenten Master-Katalog, User-Katalog, VTOC und VVDS. Im Gegensatz zu PO- oder PS-Datasets werden VSAM-Datasets automatisch katalogisiert. Es kann daher keine Probleme mit nicht-katalogisierten VSAM-Datasets geben, unabhängig davon, ob SMS installiert ist oder nicht. Der interne Aufbau von VSAM-Datasets unterscheidet sich erheblich von nicht-VSAM Datasets. So gibt es beispielsweise keinen Blockungsfaktor. VSAM-Datasets besitzen als interne Organisationselemente Kontrollintervalle (Control Intervals CI). Bei KSDSDatasets werden mehrere CIs zu einer Control Area (CA) zusammengefaßt. =

VSAM-Datasets bestehen meist aus mehreren Komponenten. So besitzt ein KSDS-Dataset eine Daten- und eine Indexkomponente. Diese Komponenten können einzeln angesprochen werden. Will man alle Komponenten in ihrer Gesamtheit ansprechen, so verwendet man dazu den Begriff Cluster. Er umfaßt alle zu einem VSAM-Dataset gehörenden Komponenten. Dies können sein: Datenteil, Indexteil, Alternativindices oder Pfade.

VSAM KSDS-Datasets VSAM KSDS-Datasets sind für den Programmierer die interessanteste und am häufigsten benutzte VSAM-Datasetform. Auf die Sätze eines KSDS-Dataset kann direkt oder

sequentiell zugegriffen werden. KSDS-Datasets besitzen eine Daten- und eine enthält Verweise auf die Records im Datenteil.

Indexkomponente.

Die

Indexkomponente

Die

Datenkomponente Die Datenkomponente eines VSAM-Dataset besteht aus Kontrollintervallen, die ihrerseits die logischen Records beinhalten. Mehrere Kontrollintervalle werden zu einer Control Area (CA) zusammengefaßt. Diese Control Area ist wichtig für das Platzmanagement. So ist es möglich, bei einem KSDS-Dataset einen prozentualen Anteil einer CA beim Laden des

Dataset frei zu halten. Die Größe einer CA läßt sich nur indirekt bestimmen. Wird der Platz für das VSAM-Dataset in Cylindern angefordert, so nimmt eine CA einen Cylinder ein. Diese Größe bringt bestimmte Performancevorteile, die in der technischen Struktur der Platten und Zugriffsanne begründet sind.

219

VSAM Die grundsätzliche Struktur des Datenteils sieht demnach Control Area 2

Control Area 1

CI1

Das Kontrollintervall

folgendermaßen aus:

CI2

CD

CI4

(CI)

In VSAM-Datasets werden die Records in Kontrollintervallen

(Control Intervals CI) Dabei beginnen die Records von links, während auf der rechten Seite Kontrollinformationen gespeichert sind. Die Größe eines Kontrollintervalls liegt zwischen 512 Byte und 32.768 Byte. Bis 8.192 muß die Kontrollintervallgröße ein Mehrfaches von 512 sein, darüber hinaus ist nur ein Mehrfaches von 2.048 erlaubt. Wird von Ihnen eine andere CI-Größe angegeben, so rundet VSAM selbständig auf die nächst größere gültige CI-Größe auf. Die Bestimmung der Größe von Kontrollintervallen kann von VSAM übernommen werden, ist aber selten optimal. Die Errechnung optimaler Größen für die CIs ist jedoch recht kompliziert. Dabei ist zu unterscheiden, ob es sich um CI-Größen für den Daten- oder den Indexteil handelt. Zunächst sollen einige allgemeine Hinweise für die Wahl der CI-Größe des Datenteils eines KSDS-Dataset gegeben werden. Die optimale CI-Größe ist von mehreren Faktoren gespeichert.

-

abhängig: 1. Ausnutzung des Plattenplatzes Da die Platten vom Typ 3380 und 3390 unterschiedliche Spurgrößen haben, ist die CIGröße, die den Platz optimal ausnutzt, unterschiedlich. Sie beträgt 18.432 für eine 3390 (= 3 CIs pro Spur) und 22.528 für eine 3380 (= 2 CIs pro Spur). 2. Art der Verarbeitung Für die sequentielle Verarbeitung sind große CI-Größen geeignet. Für direkte Verarbeitung sind kleine CI-Größen besser geeignet. Bei gemischter Verarbeitung überwiegt der Vorteil kleiner CI-Größen.

MVS/ESA JCL

220 3.

Art des

Zugriffs

Wird auf ein KSDS-Dataset nur lesend zugegriffen, so stellen große CI-Größen keinen Nachteil dar. Wird aber schreibend zugegriffen oder werden Records eingefügt, so sollten unbedingt kleine CI-Größen verwendet werden (nicht größer als 8192 Byte). 4.

Länge der logischen Records Wenn mit großen logischen Records gearbeitet wird, die mehr als 200 Byte lang sind und eine fixe Länge haben, dann sollte darauf geachtet werden, daß durch die Wahl der CI-Größe kein zu großer Anteil unbelegbaren Platzes entsteht. Die gewählte CI-Größe stellt letztlich einen Kompromiß zwischen den verschiedenen Anforderungen dar. Für die On-Line Verarbeitung werden generell kleine CI-Größen

empfohlen, da bei Schreiboperationen immer das betreffende CI für den User reserviert wird. Andere User müssen solange warten, bis der erste User seine UPDATE- oder WRITE-Operation beendet hat. Bei großen CIs wäre der Umfang der gesperrten Daten zu umfangreich und die Performance würde beeinträchtigt. Als praktikabel hat sich 4.096 bei kleinen CI-Größen herausgestellt. Diese CI-Größe liefert neben einer akzeptablen Plattennutzung eine gute On-Line Performance. Beachten Sie die Plattennutzungsrate verschiedener CI-Größen, die im Anhang abgebildet ist. Bei rein sequentieller oder nur lesender Verarbeitung können bedenkenlos große CI-Größen verwendet werden. Die Bestimmung optimaler CI-Größen für den Indexteil einer KSDS ist noch komplizierter als die für den Datenteil. Bei Index CIs hängt die optimale CI-Größe von der Art und Weise ab, wie VSAM die Schlüsseleinträge komprimieren kann. Um dies nachzuvollziehen, benötigt man sehr gute Kenntnisse von VSAM-Interna. In der Mehrzahl der Fälle bewegt sich die optimale Index-CI-Größe im Bereich zwischen 512 und 2048 Byte. Sofern Sie eine kleine Index-CI-Größe wählen, kann es sein, daß sie von VSAM nach oben korrigiert wird, falls VSAM die gewählte Größe als unzureichend erachtet.

Aufbau eines CIs Kontrollintervalle stellen die physische Komponente von VSAM-Datasets dar. Ebenso wie in einem Block eines sequentiellen Dataset sind in ihnen die logischen Records enthalten. Zudem sind in ihnen Kontrollinformationen gespeichert, die zur Verwaltung des CIs notwendig sind. Das CI besteht aus den logischen Datensätzen, die von links beginnend abgespeichert werden. Darauf folgt der Freespace (der freie Platz), der zum Einfügen neuer logischer Records genutzt werden kann. Ihm folgen RDFs (Record Definition Field), die die Länge und Häufigkeit der einzelnen logischen Records beschreiben. Ganz rechts im CI steht das CIDF (Control Interval Definition Field), in dem Informationen über Umfang und Position von freiem Platz im CI gespeichert sind.

VSAM

221

Das Record Definition Field

(RDF)

RDFs sind drei Byte lange Felder, die ein Kontrollbyte und zwei Längenbytes umfassen. Wenn aufeinander folgende logische Records die gleiche Länge besitzen, so stehen zwei RDFs: Einer definiert die Record-Länge, der andere gibt an, wie viele dieser gleich langen Records folgen. Sind die Records variabel lang, so wird für jeden Record ein RDF geschrieben. Die Daten-Records beginnen von rechts. Zwischen Daten-Records und dem ersten RDF liegt der Freespace, der zum Einfügen von weiteren Records verwendet werden kann. Beim Löschen logischer Records kann der freie Platz wiederverwendet werden. Position von logischen Records, RDFs und CIDF in einem CI:

Log.

Log.

Record2

Record 1

Das

Log.

Record3

FREE SPACE

RDF1

RDF2

CIDF

Kontrollbyte eines RDF kann folgenden Inhalt haben:

1. 2. 3.

X'OO' Dieses RDF enthält die Länge eines einzelnen Satzes. X'40' Dieses RDF enthält die Länge mehrerer gleich langer Sätze. X'08' Dieses RDF enthält die Anzahl mehrerer gleich langer Sätze.

Die beiden

Längenbytes enthalten folgende Informationen:

Typ 1 die Länge des logischen Datensatzes. Beim Typ 2 die Länge der gleich langen logischen Datensätze. 3. Beim Typ 3 die Anzahl der gleich langen logischen Datensätze. Da RRDS-Datasets eine fixe Record-Länge besitzen, enthalten die RDFs dieser Datasets andere Informationen. Es gibt für jeden Slot ein RDF, dessen erstes Byte X'OO' ist, wenn der Slot frei und X'04' ist, wenn der Slot belegt ist. Die Längenbytes enthalten immer die Satzlänge. Record-Reihenfolge im CI eines KSDS- oder ESDS-Datasets mit gleich langen logischen 1.

Beim

2.

Records:

REC 52 Byte

1 REC 52 Byte

2 REC 52 Byte

3 FREE SPACE

Es existieren zwei RDFs. Einer beschreibt die

langen Sätze.

RDF1

Länge, der

RDF2

CIDF

andere die Anzahl der

gleich

MVS/ESA JCL

222

Record-Reihenfolge logischen Records: REC 52 Byte

im CI einer KSDS oder ESDS-Dataset mit unterschiedlich

1 REC 2 REC 67 Byte 44 B.

FREE SPACE

RDF1

RDF2

langen

CIDF

Sofern immer unterschiedlich lange Records aufeinander folgen, existiert für jeden logischen Record ein RDF. Gruppen aufeinander folgender, gleich langer logischer Records werden durch zwei aufeinander folgende RDFs beschrieben. Bei variabel langen Records geht durch die große Zahl der RDFs mehr Platz im CI verloren als bei gleich langen Records. Das Control Interval Definition Field

(CIDF)

Beim Laden eines VSAM KSDS-Dataset kann der Benutzer den prozentualen Anteil des Platzes bestimmen, der in einem CI freigehalten werden soll. Im CI wird dieser Platz mit Hilfe des CIDF verwaltet. Das CIDF ist 4 Byte lang und enthält auf den ersten beiden Bytes die Anfangsposition (Displacement) des freien Platzes und auf den beiden letzten Bytes die Länge des freien Platzes.

Logische Record-Länge und Kontrollfelder Die Kontrollinformationen haben unter Umständen sehr große Auswirkungen auf den Nutzungsgrad eines CIs. So könnte man meinen, daß bei einer logischen Record-Länge von 4096 die Kontrollintervallgröße von 8192 günstig wäre, da ja dann zwei logische Records in ein CI passen müßten. Dem ist aber nicht so, da mindestens 10 Byte Kontrollinformationen ebenfalls im CI untergebracht werden müssen. Dabei handelt es sich um zwei RDFs (6 Byte) und ein CIDF (4 Byte). Es stehen daher nur 8182 Byte für die Speicherung logischer Records zur Verfügung. Bei einer logischen Record-Länge von 4096 Byte kann aber nur ein logischer Record im CI untergebracht werden. Die verbleibenden 4086 Byte reichen nicht aus, um einen weiteren logischen Record aufzunehmen. Sie sind unbenutzbarer Platz. Dieser ist nicht mit FREESPACE zu verwechseln, der der Aufnahme weiterer logischer Records dienen soll. Bei einer CI-Größe von 8192 und einer logischen Record-Länge von 4096 können nur etwa 50% des im CI vorhandenen Platzes belegt werden. Wäre die logische Record-Länge mit 4091 nur um 5 Byte kürzer, so würde ein CI mit der Größe 8192 zu 100% genutzt. Denn dann würden zwei logische Records mit 4091 insgesamt 8182 Byte einnehmen, die restlichen 10 Byte werden durch RDF und CIDF verbraucht.

VSAM

223

Achten Sie daher bei großen logischen Record-Längen darauf, daß das CI vernünftig ausgenutzt wird. Sie können damit eine erhebliche Platzersparnis und eine wesentlich bessere Performance erzielen. Die Control Area

Die Kontrollintervalle des Datenteils werden zu Control Areas zusammengefaßt, die ihrerseits freien Platz mit einschließen können. Die Größe einer CA liegt zwischen einem Track und einem Cylinder. Man sollte immer dafür sorgen, daß die CA-Größe bei einem Cylinder liegt. Dies läßt sich durch die Anforderung des Platzes in der Einheit CYLINDER erreichen. Beim Laden eines VSAM KSDS-Dataset kann der Benutzer den prozentualen Anteil des Platzes bestimmen, der in einer CA freigehalten werden soll. Dies bedeutet, daß komplette CIs innerhalb der CA freigehalten werden. Diese freien CIs werden beim Einfügen von Records benötigt. Die

Indexkomponente Auch die Indexkomponente besteht aus CIs. Allerdings ist in jedem CI nur ein Indexrecord gespeichert. Die höchste Ebene des Index besteht aus einem CI. Unter ihm befinden sich Ebenen, die mehrere CIs enthalten können. Diese Ebenen werden als Index Set bezeichnet.

Der Index Set besitzt eine baumartige Struktur. Es kann aus einem oder mehreren CIs bestehen. Die CIs enthalten Schlüssel in komprimierter Form und die zugehörigen Pointer in der Form einer relativen Byte Adresse (RBA). Die Schlüssel enthalten den höchsten abspeicherbaren Schlüssel im adressierten CI der tiefer liegenden Ebene.

Die unterste Ebene der Index Records heißt Sequence Set. Jeder dieser Records ist genau einer Control Area des Datenteils zugeordnet. Die Pointer in einem Sequence Set Record veiweisen auf die Adresse (RBA) eines CI in der Control Area. Im Sequence Set Record ist der höchste in einem CI des Datenteils ablegbare Schlüssel gespeichert. Dieser Schlüssel wird aber nicht in seiner tatsächlichen Form, sondern in einer komprimierten Art und Weise gespeichert. Diese Komprimierung trägt zu einer erheblichen Platzersparnis bei. Unter günstigen Umständen kann ein Schlüssel auf 0 Byte komprimiert werden. Es werden Kontrollinformationen mit geführt, die angeben, wie viele Stellen am Anfang und am Ende des Schlüssels komprimiert wurden. Vor dem Lesen des Schlüssels muß dieser wieder dekomprimiert werden. Bei dieser Dekomprimierung wird aber der Schlüssel nicht in seinen ursprünglichen Zustand zurückversetzt, sondern die rechts redundanten Stellen werden mit Hex 'FF' aufgefüllt. Dies ist für den String-Vergleich, den VSAM ausführt, völlig ausreichend. Auf diese Weise können VSAM KSDS-Datasets sowohl numerische als auch alphabetische Schlüssel verwalten. (Da der gespeicherte Schlüssel ohnehin nicht zu sehen ist, wird in den folgenden Abbildungen des Indexes aus Gründen der Einfachheit der kleinste Schlüssel des folgenden Daten-CIs 1 dargestellt). -

224

MVS/ESA JCL

Die

folgende Abbildung zeigt den Aufbau des Index und des Sequence Set mit den höchstmöglichen Schlüsseln im darunter liegenden Set. Die Zahlen über den CIs geben die relative Byte Adresse (RBA) an (in diesem Beispiel wird davon ausgegangen, daß die CIGröße des Daten- und Indexteils 512 ist, eine in der Praxis eher unwahrscheinliche Voraussetzung. Meist ist die CI-Größe des Datenteils größer als die des Indexteils):

In den Pointern stehen die RBAs der CIs. Bei direkter Verarbeitung werden die vertikalen Pointer benutzt. Für die sequentielle Verarbeitung eines KSDS-Dataset hält der Indexteil neben den vertikalen auch horizontale Pointer bereit, die das Auffinden des folgenden Daten-CIs ermöglichen. Dies ist erforderlich, weil die physische Reihenfolge der CIs nicht der logischen entsprechen muß.

Jeder Record im Sequence Set ist genau einer Control Area zugeordnet. Die Pointer in den Records verweisen auf genau ein CI des Datenteils. Der schraffierte Bereich in den DatenCIs soll den durch RDF und CIDF eingenommenen Platz darstellen.

VSAM Die

225

folgende Abbildung zeigt die Beziehung von Sequence Set Record zum Daten-CI:

Lesen

von

Records

Soll ein Record direkt gelesen werden, so wird der Indexteil durchsucht. Die entsprechenden Pointer verweisen auf das gesuchte CI im Datenteil. Anhand der folgenden Abbildung soll das Auffinden (direktes Lesen) des Records mit dem Schlüssel 130 erläutert werden. Beachten Sie bitte, daß die Darstellung der Schlüssel im Indexteil grob vereinfacht ist (Es wurde einfach 1 vom niedrigsten Schlüssel des Folge-CIs abgezogen). Da die Schlüssel im Indexteil komprimiert abgespeichert sind, ist eine normale Darstellung nicht möglich. Beim Lesen steigt VSAM im höchsten CI des Indexteils ein. Der erste dort abgelegte Schlüssel ist 104, also kleiner als der des gesuchten Records. Der nächste Schlüssel ist 259. Da 259 größer ist als 130, benutzt VSAM diesen Pointer mit der RBA 1024 zum Auffinden des Index-CIs der niedrigeren Ebene. Auf die gleiche wird das Index-CI des Sequence Set mit der RBA 2560 gefunden. Dieses Index-CI verwaltet die dritte Control Area des Datenbereichs. Der zweite Schlüssel dieses Index-CIs ist größer als 130, also muß im zweiten CI

226

MVS/ESA JCL

der CA 3 der gesuchte Record mit dem Schlüssel 130 zu finden sein. VSAM durchsucht dieses CI sequentiell, bis es auf den gesuchten Record stößt. Die folgende Abbildung zeigt den Aufbau des Daten- und Indexteils, die bei der Suche nach dem Record mit dem Schlüssel 130 durchlaufen wird:

Einfügen von Records In ein KSDS-Dataset können Records eingefügt werden. Der einfachste Fall liegt dann vor, das CI, in das der Record eingefügt werden muß, entsprechend viel Platz vorrätig hat. In diesem Fall greift VSAM auf das CI zu, fugt den Record ein und schreibt das CI wieder wenn

VSAM

227

zurück. CIDF und RDFs werden auf den neuesten Stand gebracht. Während des Zugriffs bleibt das CI für andere Benutzer gesperrt. Den Zustand des KSDS-Datasets vor dem Einfügen können Sie der vorangegangenen Abbildung entnehmen. Die folgende Abbildung zeigt das Beispiel eines Einfügens. Der Record mit dem Schlüssel 35 wurde eingefügt. Da im betreffenden CI ausreichend Platz vorhanden war, kam es zu keinerlei Split-Aktivität:

MVS/ESA JCL

228

Der

Cl-Split

Der zweite Fall liegt vor, wenn im betreffenden CI zwar kein Platz mehr vorhanden ist, aber in der CA noch komplett freie CIs existieren. In diesem Fall teilt VSAM das volle CI etwa in der Mitte (nicht notwendigerweise an der Einfügesteile) und schreibt die zweite Hälfte des Ausgangs-CIs in ein freies CI. Anschließend wird der Record in das erste CI eingefügt. Die Pointer im Sequence Set Record müssen jetzt ebenfalls upgedated werden, da ein bisher freies CI belegt wurde. Dies bedeutet einen erhöhten I/O-Aufwand. Im

folgenden Beispiel wurde der Record mit dem Schlüssel entsprechenden CI kein Platz mehr frei war, wurde das CI geteilt:

93

eingefugt.

Da im

VSAM

Der

229

CA-Split

Der dritte Fall

liegt vor, wenn:

1.

im betreffenden CI kein Platz mehr ist und

2.

keine komplett freien CIs in der CA mehr vorhanden sind.

In diesem Fall wird die alte CA etwa in der Mitte geteilt und die Daten-CIs auf die alte und die neue CA verteilt. Danach kann es unter Umständen noch zu einem CI-Split kommen (wie in unserem Beispiel). Bei einem CA-Split müssen die zugehörigen Sequence Set Records auf jeden Fall neu geschrieben werden. Auch die höher liegenden Index Records müssen upgedated werden. Unter Umständen reichen diese Updates bis in hohe Indexebenen hinein. Ein CA-Split ist ein äußerst I/O-intensiver Vorgang, der nach Möglichkeit vermieden werden sollte. Eine große Zahl von CA-Splits senkt die Performance erheblich! Aus diesem Grund sollten VSAM-Datasets beobachtet werden. Bei Datasets, die eine große Zahl von CA-Splits aufweisen, sollte der Anteil des Freespace in der CA erhöht werden. Auch eine Erhöhung des CI Freespace kann sinnvoll sein. Prüfen Sie auch die Zahl der Cl-Splits. Versuchen Sie nach Möglichkeit, sowohl die Zahl der CAwie der Cl-Splits zu senken. Wenn alle diese Maßnahmen keine Verbesserung bringen, so sollte das Dataset häufig reorganisiert (neu geladen) werden. Im folgenden Beispiel wird ein Record mit dem Schlüssel 220 eingefügt. Aufgrund seines Schlüssels müßte dieser Record im CI4 der CA3 eingefügt werden. Dieses CI ist jedoch voll belegt. Ein CI-Split kann nicht durchgeführt werden, da keine freien CIs in der CA3 mehr vorhanden sind. Die Tatsache, daß in den CI1 und CI3 der betreffenden CA noch Platz frei ist, spielt übrigens keine Rolle. Es kommt daher zu einem CA-Split. Beachten Sie, daß bis in die Ebene des Index Set Record hinein Updates vorgenommen werden müssen:

230

MVS/ESA JCL

Löschen von Records Soll ein logischer Record gelöscht werden, so wird er zunächst wie beim Lesen aufgesucht. Anschließend wird der logische Record physisch gelöscht. Der dabei frei werdende Platz kann zum erneuten Einfügen von Records wiederverwendet werden. Ein VSAM-Dataset, das durch Löschungen alle seine Records verliert, gilt nicht als leer. Es unterscheidet sich insofern von einem leeren (definiert, aber nicht geladen) VSAM-Dataset. KSDS-Datasets mit Alternativschlüssel

Neben dem Primärschlüssel kann der Benutzer eines KSDS-Dataset bis zu 255 Alternativschlüssel (Alternate Index) definieren. Diese Schlüssel können eindeutig oder nicht eindeutig sein (Letzteres ist in der Praxis häufig). Man kann jedoch auch nicht eindeutige Schlüssel eindeutig machen, sofern dies beim Design des Datasets vorgesehen

VSAM

231

Eindeutige Alternativschlüssel lassen sich meist einfacher in Anwendungsprogrammen verarbeiten. Für jeden Alternativschlüssel muß ein weiterer VSAM KSDS-Cluster definiert werden (sog. AIX-Cluster). Dieser verwaltet die Sekundärschlüssel und die zugehörigen Primärschlüssel. Wird über den Alternativschlüssel zugegriffen, so wird über den AIXCluster gelesen, der Schlüssel zum Zugriff auf den zugehörigen Primärcluster entnommen und dann im Primärcluster gelesen. Die Zahl der physischen I/Os ist damit um ein Vielfaches größer als beim Lesen mit dem Primärschlüssel. Daher sollten Sie sich unbedingt an die folgenden Empfehlungen halten: wird.

L

Zugriffe

über den Alternativschlüssel sollten

nur

in On-Line

werden.

Umgebungen genutzt

2.

Definieren Sie nur die unbedingt notwendigen Alternativschlüssel.

3.

In

Batch-Umgebungen ist es besser, den Basiscluster umzusortieren und dann sequentiell zu verarbeiten (Im Batch sollte man es sich ohnehin dreimal überlegen, ob aus

4.

VSAM KSDS-Datasets direkt gelesen werden

soll).

Verarbeiten Sie niemals sequentiell über den Alternativschlüssel im Batch. Die Performance ist sehr schlecht, weil jeder Record im Basiscluster direkt gelesen werden muß. Das Verhältnis zwischen physischen und logischen I/Os ist höchst ungünstig.

Zugriff auf den Alternativschlüssel erfolgt über einen sogenannten Pfad, der durch ein bestimmtes AMS-Kommando erstellt wird. Gleiches gilt für das eigentliche Laden des Alternativschlüssels. Der

VSAM ESDS-Datasets ESDS-Datasets besitzen nur eine Datenkomponente. Die Record-Länge ist variabel. Neue Records werden in freie CIs am Ende des Datasets gestellt. Ein Einfügen oder Löschen von Records ist nicht möglich. ein ESDS ist sequentiell. Es besteht jedoch auch die Hilfe RBA anzusprechen. Dieses Verfahren ist jedoch Records mit ihrer Möglichkeit, umständlich und daher wenig gebräuchlich.

Die normale

Verarbeitungsform für

ESDS-Datasets werden

überwiegend in IMS- bzw. CICS- (Customer Information Control System) Umgebungen eingesetzt, um beispielsweise Transaktionen sequentiell weg zu schreiben. In solchen Umgebungen ist der Einsatz von VSAM-Datasets zwingend, da andere Zugriffsformen nicht unterstützt werden. In 'normalen' MVS-Umgebungen behaupten sich die 'alten' QSAM-Datasets weiterhin. Auch über ESDS-Datasets kann ein AIX erzeugt werden. Damit ist es dann möglich, Records direkt anzusprechen. Diese Variante kann aus Gründen der Performance dann interessant sein, wenn: 1. nur lesend zugegriffen werden soll und

MVS/ESA JCL

232 2.

mehrere Alternativschlüssel genutzt werden sollen.

Diese Form der Verarbeitung ist nur unter CICS

möglich.

VSAM RRDS-Datasets PvRDS-Datasets besitzen nur eine Datenkomponente und als einzige VSAM-Datasetart eine fixe Record-Länge. Die CIs sind in Slots unterteilt. Im RDF wird festgehalten, ob der Slot frei oder durch einen Record belegt ist. Die Slots besitzen eine Nummer, die relative Record Nummer (RRN), über die jeder Record direkt angesprochen werden muß. RRDS-Datasets können nur dort eingesetzt werden, wo eine eindeutige Beziehung zwischen der RRN (= Position des Records im Cluster) und dem logischen Schlüssel des Anwendungsprogramms hergestellt werden kann. So könnten z.B. Kontonummern zwischen 100.001 und 999.999 über eine RRN verwaltet werden (RRN Kontonummer 100.000). Da KSDS-Datasets jedoch ökonomischer in der Platzausnutzung sind, werden sie den RRDS-Datasets meist vorgezogen. Der Vorteil der RRDS besteht im vergleichsweise schnellen Zugriff, da es keinen Schlüssel gibt, der gesucht werden müßte. =

Die relative

-

Byte Adresse (RBA)

Zur Adressierung des Datenbestandes benutzt VSAM die relative Byte Adresse (RBA). Es werden sowohl die Kontrollintervalle im Datenteil als auch im Indexteil mit einer RBA adressiert. Theoretisch kann man jedes CI mit Hilfe seiner RBA ansprechen. In der Praxis hat diese Möglichkeit jedoch kaum Bedeutung. Diese Form der Adressierung des Datenbestandes ermöglicht es, die physischen Records unabhängig von ihrer logischen Reihenfolge zu speichern. Die höchste Relative Byte Adresse ist 2^. Der Datenbestand eines VSAM-Dataset kann daher maximal 4.294.967.296 Byte umfassen. Wird versucht, über diese Grenze hinaus zu schreiben, so erhält man einen 'Dataset full'-Fehler. Wenn man in diese Situation unvorbereitet hinein gerät, so ist dies eine Katastrophe, allerdings eine vermeidbare. Wenn ein Datenbestand so groß wird, daß diese Grenze erreicht werden könnte, so muß das VSAM-Dataset gesplittet werden. Dies hat aber erhebliche Auswirkungen auf die Programme. Unter Umständen muß eine ganze Serie von Programmen angepaßt werden. Wenn man mit der Anpassung beim ersten Auftreten des Fehlers beginnt, ist es zu spät. Das Dataset muß beobachtet und neue Programme müssen fertig und ausgetestet sein, will man ein Desaster verhindern. (Stellen Sie sich vor, daß Ihr wichtigstes Dataset für Tage oder Wochen unbenutzbar ist. Die Anwender werden sich bei Ihnen bedanken!)

Übersicht VSAM-Datasets Die folgende Übersicht faßt die ESDS und RRDS zusammen:

wichtigsten

Merkmale der VSAM-Datasetformen KSDS,

233

VSAM

ESDS

RRDS

KSDS

relative RecordNummer

Schlüsselreihenfolge

Zugriff

Reihenfolge der Eingabe sequentiell

durch relative Record-Nummer oder sequentiell

direkt (Schlüssel) oder

Record-Format

fix oder variabel

fix

fix oder variabel

in freien Slots

im

Möglich, freie

möglich, freier Platz kann

Reihenfolge der Records

Hinzufügen

am

Ende des

Datasets

nicht möglich

Löschen

Slots können wiederverwendet werden

möglich, wenn der möglich geänderte Record die gleiche Länge

Ändern

sequentiell

Freespace

wiederverwendet werden

möglich

besitzt

5.1

Linear Data Sets

(LDS) sind die jüngsten Vertreter der VSAM-Datasets. Sie stehen seit der (letzte MVS/XA Version) zur Verfügung. Einführung LDS unterscheiden sich ganz erheblich von den übrigen drei VSAM-Dataset-Formen. Das Einzige, was sie mit ihnen gemein haben, ist die Tatsache, daß sich auch LDS mit IDCAMS definieren lassen. Das Hauptcharakteristikum der VSAM-Datasets, nämlich die Zugriffsmethode VSAM, fehlt den LDS jedoch völlig. LDS werden von keiner Zugriffsmethode unterstützt. Das mag auf den ersten Blick merkwürdig erscheinen, bietet jedoch auch Vorteile. Wo keine Zugriffsmethode im Spiel ist, gibt es auch keinen dadurch erzeugten Overhead. Da es keine Zugriffsmethode gibt, brauchen LDS auch keinerlei Kontrollinformationen. Die CIs eines LDS sind immer 4.096 Byte groß und beinhalten nur Daten. Sie besitzen weder Linear Data Sets von

DFP 2.3

RDFs noch CIDF.

Ein LDS wird nicht durch VSAM verarbeitet, sondern durch DIV. DIV steht für Data-inVirtual und bezeichnet eine Möglichkeit, ein sogenanntes DIV-Objekt im virtuellen Speicher zu verarbeiten. LDS werden in diesem Zusammenhang als ein Linear Data Objekt betrachtet, für das es entsprechende DIV-Makros gibt. Direkt aufrufen kann man diese Makros mit Assembler. Diese Möglichkeit ist jedoch für Anwendungsprogrammierer, die normalerweise nicht über Assemblerkenntnisse verfügen, uninteressant. Es gibt jedoch

234

MVS/ESA JCL

zwischenzeitlich eine Schnittstelle zu höheren Programmiersprachen, die sogenannten Data Windowing Services, die es gestatten, die zum Verarbeiten eines LDS notwendigen Makros aus Sprachen wie C/370, COBOL, PASCAL, PLI oder FORTRAN abzusetzen. Die Verarbeitung eines LDS geschieht in einem sogenannten Window. Das Window ist nichts weiter als eine Oler-Stufe in der LINKAGE SECTION eines COBOL-Programms. Dieses Feld ist 4096 Byte oder ein Mehrfaches von 4096 Byte groß. In dieses Fenster werden dann ein oder mehrere CIs des LDS hineingestellt und durch die entsprechenden CALLs verarbeitet. Sollen logische Records, die es ja in einem LDS nicht gibt, verarbeitet werden, so muß die Struktur des Windows entsprechend aufbereitet werden. Das Auffinden eines bestimmten Records geschieht allein durch die Logik des Anwendungsprogramms. Besondere Bedeutung besitzen LDS bei DB2. Sie werden dort als physische Struktur im Hintergrund eingesetzt, ohne daß es dem DB2-Benutzer bewußt wird.

5.2

IDCAMS für VSAM-Datasets

Die

Endung von IDCAMS steht für 'Access Method Services'. IDCAMS ist die bei weitem wichtigste Utility, die heutzutage im MVS-Umgebungen eingesetzt wird. Sie wurde im Zusammenhang mit der Einführung von VSAM-Datasets entwickelt, enthält aber auch allgemein nutzbare Funktionen für nicht-VSAM-Datasets. Diese wurden bereits im Kapitel über Utilities vorgestellt. Wie bei den bereits erwähnten Utilities, werden die zur Ausführung des IDCAMSProgramms benötigten Kommandos und Parameter über die SYSIN DD * Anweisung gegeben. Syntax:

[label]

Kommando Parameter(wert) Auf jedes Kommando folgen ein oder mehrere Parameter, denen Werte in Klammern zugewiesen werden können. Aus Gründen der Übersichtlichkeit sollte nur ein Kommando/Parameter auf eine Zeile gesetzt werden. Zur Fortsetzung des Kommandos folgt ein Blank und anschließend ein Bindestrich. Es gibt zwei Arten von Kommandos: funktionelle Kommandos, die AMS Befehle ausführen 2. Modal-Kommandos, die die Ausführung von Befehlen überwachen. In der folgenden Übersicht werden nur die AMS-Kommandos aufgelistet, die für einen Anwendungsprogrammierer von praktischer Bedeutung sind. 1.

235

VSAM Funktionelle Kommandos

AMS-Kommando

Bedeutung

BLDINDEX

Lädt einen AIX-Cluster.

DEFINE ALTERNATEINDEX Definiert einen Alternativindex. DEFINE CLUSTER

Definiert ein VSAM-Dataset (KSDS, ESDS, RRDS oder LDS).

DEFINE GDG

Definiert den

Group.

Basiseintrag für eine Generation Data

DEFINE PATH

Definiert einen Pfad, d.h. einen Katalogeintrag für eine logische Verbindung zwischen einem Basiscluster und einem einen Alternativindex.

DELETE

Löscht einen

Katalogeintrag, einen Cluster, einen

Alternativindex, einen Pfad oder eine GDG. LISTCAT

Gibt Informationen über Katalogeinträge

PRINT

Druckt den Inhalt von VSAM-Datasets.

REPRO

Kopiert Records. Input- und Output-Datasets können

aus.

VSAM- oder nicht-VSAM-Datasets sein. Es kann auch zwischen VSAM- und nicht-VSAM-Datasets kopiert werden. Modal Kommandos AMS-Kommando

Bedeutung

IF

Prüft die bei der Ausführung von funktionellen Kommandos zurückgegebenen Return Codes ab.

SET

Ändert Return Codes, die von funktionellen Kommandos

zurückgegebenen werden.

MVS/ESA JCL

236

Anlegen von VSAM-Datasets mit DEFINE CLUSTER Syntax: DEFINE CLUSTER

(NAME(Katalog-Eintrag) CYLINDERS(primär sekundär) TRACKS(primär sekundär) VOLUMES(vol-ser-no) INDEXED NUMBERED

0 °

NONINDEXED

LINEAR

RECORDSIZE(avg max) CONTROLINTERVALSIZE(Wert) UNIQUE

°

SUBALLOCATION

KEYS(Länge Position) FREESPACE(CI CA) SHAREOPTIONS (a b)

ERASE ° NOERASE SPEED ° RECOVERY IMBED • NOIMBED REPLICATE ° NOREPLICATE) ORDERED 0 UNORDERED

KEYRANGES(lowkey highkey) REUSE

°

NOREUSE

BUFFERSPACE(Wert) FOR(Tage) TO(Datum) °

SPANNED DATA

•

NONSPANNED

)

(

NAME(Katalog-Eintrag) VOLUMES(vol-ser-no) CONTROLINTERVALSIZE(Wert) CYLINDERS(primär sekundär) TRACKS(primär sekundär) ) INDEX ( NAME(Katalog-Eintrag) VOLUMES(vol-ser-no) CONTROLINTERVALSIZE(Wert) TRACKS(primär sekundär) _CYLINDERS(primär sekundär) ) Ein VSAM-Dataset wird mit dem DEFINE CLUSTER-Kommando angelegt. Sofern bei Ihnen SMS installiert ist, können VSAM-Datasets auch mit normaler JCL (ohne IDCAMS) angelegt werden. Die notwendigen Parameter finden Sie im Kapitel über SMS.

237

VSAM

DEFINE CLUSTER ist das bei weitem umfangreichste Kommando mit 36 Parametern. Die wichtigsten Parameter des DEFINE CLUSTER-Kommandos werden in der Übersicht auf Seite 236 vorgestellt. Wie Sie sehen, gibt es 3 verschiedene Ebenen, nämlich CLUSTER-, DATA- und INDEXEbene. Einige Parameter können auf unterschiedlichen Ebenen angegeben werden. Die meisten Definitionen werden auf der CLUSTER-Ebene durchgeführt. Der CLUSTER umfaßt alle zu einem VSAM-Dataset gehörenden Komponenten, z.B. Daten- und Indexteil eines KSDS-Dataset, einen Pfad oder einen Alternativindex. In der DATA- und INDEX-Ebene einer KSDS wird meist Parameter kodiert.

nur

der NAME- und CISZ-

NAME

Syntax:

NAME(Katalogeintrag) NAME gibt den Namen des Clusters oder der Komponente an. Die Regeln folgen denen normaler DSNs. Name kann auf CLUSTER-Ebene oder den anderen Ebenen (DATA und INDEX) angegeben werden. Wird der NAME nur auf CLUSTER-Ebene angegeben, so wird für die DATA- und die bei KSDS-Datasets vorhandene INDEX-Ebene ein Name generiert. Dazu wird .DATA oder .INDEX an den CLUSTER-Namen angehängt. Wenn man den NAME-Parameter im DATA- und/oder INDEX-Teil benutzt, andere DSN-Anhängsel als DATA und INDEX vergeben.

so

kann

man

Platzanforderung für VSAM-Datasets Syntax:

CYLINDERS(primär sekundär) TRACKS(primär sekundär) RECORDS(primär sekundär)

Abkürzung: Abkürzung: Abkürzung:

CYL TRK REC

Einer der drei angeführten Parameter muß für die Allokation von Platz verwendet werden. Der Aufbau ähnelt dem SPACE-Parameter in der DD-Anweisung. Im Unterschied zu einem QSAM-Dataset können bei einem VSAM-Dataset bis zu 122 Sekundärextents angelegt werden. Die Zahl der Extents sollte immer so gering wie möglich sein. Das Optimum ist 1, also keine Sekundärextents vorhanden. Es gibt Installationen, in denen das Anfordern von Sekundärextents in Produktionsumgebebungen verboten ist! Stellt man ein Ansteigen der Zahl der Extents fest, so sollte beim Reorganisieren des Datasets mehr Platz zur Verfügung gestellt werden. Nach dem Laden des Dataset sollten Sekundärextents noch nicht belegt sein.

238

MVS/ESA JCL

Normalerweise wird SPACE auf der CLUSTER-Ebene angefordert. Für KSDS-Datasets kann SPACE auch auf unterschiedlichen Ebenen, entweder nur auf CLUSTER-, nur auf DATA- oder aber auf DATA- und INDEX-Ebene angefordert werden. Da VSAM sich den für die INDEX-Komponente erforderlichen Platz selbst errechnet, ist eine Angabe auf dieser Ebene nicht zu empfehlen. Die Platzanforderung kann in unterschiedlichen Einheiten erfolgen. Die empfehlenswerte Einheit ist CYLINDER. Wird sie benutzt, so wird die Control Area in der Größe eines Cylinders angelegt. Dies ist besonders wichtig für KSDS-Datasets, da der Indexteil relativ gut strukturiert wird, da die Zahl der Control Areas klein gehalten wird. Außerdem sind dann Multi-Track Operations möglich, d.h. mit einer I/O Operation können alle Tracks eines Cylinders gelesen werden. Wird IMBED verwendet, so wird das erste Track des Cylinders verwendet, um den Sequence Set Record (SSR) abzuspeichern. Dann stehen der SSR und die zugehörigen CIs des Datenbereichs in einem Cylinder, was die Performance verbessert. Wird RECORDS als Größeneinheit verwendet, so kalkuliert VSAM die voraussichtliche Größe des Datasets aufgrund der Angabe für den Subparameter avg im RECSZ-Parameter. Wenn mit variabel langen Records gearbeitet wird, ist diese Vorgehensweise nicht zu empfehlen, da es fast unmöglich ist, im Vorhinein eine exakte Angabe zur durchschnittlichen Record-Größe zu machen. Es kann dann schnell zu Platzproblemen kommen. Sofern bei Ihnen SMS installiert ist, kann auch eine Angabe in der Form KILOBYTES(wert) oder MEGABYTES(wert) erfolgen. VOLUMES

Syntax:

VOLUMES(voI-ser-no [vol-ser-no ...])

Abkürzung:

VOL

Mit dem VOLUMES-Parameter wird MVS mitgeteilt, auf welches Volume oder welche Volumes das Dataset zu legen ist. Erfolgt diese Angabe nur auf der CLUSTER-Ebene, so gilt diese Angabe auch auf und INDEX-Ebene. Volume-Angaben können auch auf DATAund INDEX-Ebene erfolgen. Bei sehr großen VSAM KSDS-Datasets kann es vorteilhaft sein, Daten- und Indexbereich auf unterschiedliche Volumes (Platten) zu legen. Die Angabe eines Gruppennamens wie bei dem UNIT-Parameter ist nicht möglich. Sofern SMS aktiviert ist, kann die Angabe mit dem STORAGECLASS-Parameter erfolgen. Als Angabe ist nur vol-ser-no zulässig. Es können mehrere Volumes angegeben werden. In diesem Fall wird das VSAM-Dataset auf das erste angegebene Volume gelegt. Reicht der Platz dort nicht aus, werden Extents auf dem zweiten Volume angelegt.

VSAM

239

Die Datasetorganisationsparameter

Syntax:

Abkürzung: Abkürzung: Abkürzung Abkürzung:

INDEXED NONINDEXED NUMBERED LINEAR

IXD NIXD NUMD LIN

Gibt die Art des VSAM-Datasets an. Mit INDEXED der Default werden KSDS-Datasets angelegt, NONINDEXED steht für ESDS-Datasets und NUMBERED für RRDS-Datasets. Mit LINEAR wird ein lineares VSAM-Dataset angelegt. -

-

RECORDSIZE

Syntax:

Abkürzung:

RECORDSIZEfavg max)

RECSZ

Gibt die durchschnittliche (avg) und maximale (max) logische Record-Länge an. Wird die Größe des Datasets in RECORDS angegeben was nicht empfehlenswert ist so benutzt MVS die unter avg angegebene Länge zur Berechnung des zu allokierenden Platzes. Die gleiche Angabe unter avg und max bewirkt bei KSDS- oder ESDS-Datasets nicht, daß die Records eine fixe Länge haben. Mit Ausnahme von RRDS-Datasets hier müssen die Werte von avg und max gleich sein können die Records bis zur maximalen Länge immer variabel lang sein. Der Default-Wert ist abhängig davon, ob SPANNED oder NONSPANNED angegeben wurde. Wird RECORDSIZE und SPANNED weggelassen, so wird eine Record-Länge von 4089 für avg und max angenommen. Wird nur SPANNED angegeben, so wird der Wert für avg auf 4086 und der für max auf 32600 gesetzt. Bei LDS-Datasets ist die Angabe einer RECSZ verboten! LDS haben immer eine implizite Recordgröße von 4096. -

-

-

-

CONTROLINTERVALSIZE

Syntax:

CONTROLINTERVALSIZE(byte)_Abkürzung: C1SZ

Gibt die Größe des Kontrollintervalls an, die zwischen 512 Byte und 32.768 Byte liegt. Bis 8.192 muß die Kontrollintervallgröße ein Mehrfaches von 512 sein, darüber hinaus ist nur ein Mehrfaches von 2.048 erlaubt. Wird eine CISZ angegeben, die diesen Konventionen nicht entspricht, so wird auf die nächst größere CI-Größe aufgerundet.

240

MVS/ESA JCL

Die CISZ sollte immer für den Daten- und Indexteil den Indexteil zu klein angegeben, so wird diese Größe

angegeben von

VSAM

werden. Ist die CISZ für

korrigiert.

Das Optimieren der CISZ für den Daten- und Indexteil eines KSDS-Clusters ist eine äußerst komplizierte Angelegenheit, die den Rahmen dieses Buches sprengen würde. Als

Faustregel gilt:

Bei direktem Zugriff mit Updates oder Inserts sind kleine Kontrollintervalle für den Datenteil vorteilhaft. Bei sequentieller Verarbeitung oder direktem, nur lesenden Zugriff sind große Kontrollintervalle bis zur halben Tracklänge der Platte vorteilhaft. Bei LDS-Datasets muß entweder eine CI-Größe von 4096 verwendet werden oder es

erfolgt keine Angabe. SUBALLOCATION UNIQUE -

Syntax:

UNIQUE

I

SUBALLOCATION

Abkürzung: UNQ I SUBAL

Dieser Parameter hatte Bedeutung in Vor-MVS/XA Systemen. Heute wird immer UNIQUE verwendet. Mit dem UNIQUE/SUBALLOCATION-Parameter wurde angegeben, ob der zu allokierende Platz aus VSAM Space genommen werden soll dies geht nur, wenn VSAM Space allokiert ist oder eigener Platz allokiert wird, d.h. das VSAM-Dataset kann auf jeder Platte zu liegen kommen, auf der Sie Datasets anlegen dürfen. Da SUBALLOCATION der Default ist, muß UNIQUE angegeben werden. -

-

KEYS

Syntax:

KEYS(Länge Position) Der KEYS-Parameter darf nur bei KSDS-Datasets eingesetzt werden. Gibt Länge und Position des Schlüssels an. Das erste Byte entspricht Position 0. Die Defaults sind 64 für Länge und 0 für Position. Achten Sie besonders auf die Positionsangabe, wenn der Schlüssel nicht auf dem ersten Byte des Records beginnt. Stimmen die Angaben bei der Definition und im Programm nicht überein, so bekommen Sie einen Fehler beim Absetzen der OPEN-Anweisung. Im Listcat finden sie den Beginn der Schlüsselposition im Feld RKP (Relative Key Position).

VSAM

241

FREESPACE

Syntax: r

FREESPACE(CI CA)

Abkürzung: FSPC

Gibt den Prozentsatz von Platz an, der im CI bzw. der CA beim Laden eines KSDS-Dataset freigelassen wird. Der Default ist 0, sowohl für das CI als auch für die CA. Sofern damit zu rechnen ist, daß in das Dataset Records eingefügt werden, muß mit FREESPACE freier Platz vorgesehen werden. Wenn das Dataset eine hohe Splitrate aufweist, so kann hier eingegriffen werden, indem der Anteil freien Platzes erhöht wird. Dies sollte man vor allem beim Auftreten von CA-Splits tun. Die Summe beider Parameter sollte 50 nicht überschreiten, da ansonsten zuviel Platz verschwendet wird. Wenn zu viele Splits auftreten, erhöhen Sie den Freespace und beobachten das Dataset. Wird die Splitrate nicht besser, dann sollte das Dataset häufiger reorganisiert werden. Unter Umständen sollte eine andere CI-Größe in Erwägung gezogen werden. Achten Sie bei der Angabe für FREESPACE darauf, daß soviel Platz freigelassen zumindest ein Record aufgenommen werden kann.

wird, daß

Beispiel (CISZ 4096 Byte, RECSZ 460 Byte): FSPC

(10 10)

Die erste Angabe bewirkt, daß 10% des Cl-Platzes frei gehalten werden. Dies sind 10% von 4096 409,6 Byte, abgerundet 409 Byte. Dieser Platz reicht nicht aus, um auch nur einen logischen Record neu aufzunehmen, da die logische Record-Länge 460 Byte beträgt. Es entsteht unbenutzbarer Platz. =

Wird die FSPC-Angabe auf FSPC (12 10) erhöht, so ist der frei gehaltene Platz ausreichend für die Aufnahme eines weiteren logischen Record. Denn jetzt werden pro CI ca. 480 Byte

freigehalten. Die Angabe

FREESPACE CA gibt den Prozentsatz der komplett freizuhaltenden CIs in einer CA an. Diese komplett freien CIs werden bei Cl-Splits benötigt. Eine ausreichende Zahl freier CIs hilft, CA-Splits zu vermeiden. SHAREOPTIONS

Syntax:

SHAREOPTIONS

(a b)

Abkürzung: SHR

MVS/ESA JCL

242 Der SHAREOPTIONS-Parameter besitzt zwei Subparameter, wobei Shareoption und b für die cross-system Shareoption steht.

a

für die

cross-region

Die cross-region Shareoption regelt, wie zwei oder mehr Jobs in einem System auf ein Dataset zugreifen können. Dies ist insbesondere dann von Bedeutung, wenn ein VSAMDataset in eine On-Line Umgebung (z.B. CICS) eingebunden ist und gleichzeitig im Batch verarbeitet werden soll. Da CICS und Batch-Jobs in unterschiedlichen Regionen laufen, regelt die cross-region Shareoption den Zugriff.

Shareoption regelt den Datasetzugriff von zwei oder mehr Jobs, Systemen laufen. Eine solche Konfiguration ist in einem Prozessor-Komplex möglich. Die folgenden Angaben sind möglich: Cross-region Shareoption: Die cross-system unterschiedlichen

die auf Multi-

1. Das Dataset kann von mehreren Jobs verarbeitet werden, so lange alle Jobs nur lesend auf das Dataset zugreifen. Greift ein Job schreibend auf das Dataset zu, können andere Jobs das Dataset nicht öffnen. 2. Das Dataset kann von mehreren Jobs verarbeitet werden, solange nur ein Job schreibend und alle anderen Jobs nur lesend auf das Dataset zugreifen. 3. Das Dataset kann von mehreren Jobs lesend und schreibend verarbeitet werden. VSAM ergreift keine Maßnahmen, um die Datenintegrität zu gewährleisten. 4. Das Dataset kann von mehreren Jobs lesend und schreibend verarbeitet werden. VSAM überwacht jedoch die Einhaltung folgender Beschränkungen:

bei Direktzugriffen wird immer von der Platte Daten im VSAM-Buffer befinden Daten können nicht

ans

Ende des Datasets

gelesen, auch wenn sich die gewünschten

angehängt werden

ein CA-Split ist nicht erlaubt.

Cross-system Shareoption: 1.

Das Dataset kann von mehreren Jobs mehrerer Systeme lesend und schreibend verarbeitet werden. VSAM ergreift keine Maßnahmen, um die Datenintegrität zu

gewählleisten. 2.

Das Dataset kann

mehreren Jobs mehrerer Systeme lesend und schreibend gelten die gleichen Beschränkungen wie die unter 4 bei den

von

verarbeitet werden. Es

cross-region Shareoption genannten.

größte Maß an Datensicherheit bei größtmöglicher Effizienz gewährt die cross-region Shareoption 2. Für die cross-system Shareoption sollte man 3 angeben. Die Shareoption 4 ist wegen ihrer vielen Einschränkungen wenig sinnvoll. Die Datenintegrität muß durch Reserve-Release-Makros der Anwendungsprogramme sichergestellt werden. Bei LDS-Datasets ist als cross-system Shareoption nur 3 zulässig. Das

243

VSAM ERASE NOERASE -

Syntax:

I

ERASE

Abkürzung:

NOERASE

Wird ein VSAM-Dataset DELETE.

gelöscht,

so

geschieht

I

ERAS

NERAS

dies mit dem IDCAMS-Kommando

Dieser Vorgang löscht nur den Katalogeintrag, falls beim Löschen keine besonderen Parameter gesetzt werden. Der Datenbestand auf der Platte existiert bis zu einem evtl. Überschreiben weiter!

Sollen die Daten auch physisch gelöscht (sofort überschrieben) werden, so ist die Option ERASE zu verwenden. Wird die Option ERASE im DEFINE CLUSTER-Kommando verwendet, so wird das Dataset beim Löschen überschrieben, unabhängig davon welche Parameter beim DELETE-Kommando verwendet werden. Dieser Löschvorgang ist sehr zeitintensiv, weil das ganze Dataset mit binären Nullen überschrieben wird. Von dieser Möglichkeit sollte nur dann Gebrauch gemacht werden, wenn dies unbedingt erforderlich ist, z.B. bei der Löschung eines Dataset, das personenbezogene Daten enthält.

Achtung:

RECOVERY SPEED -

Syntax:

I

SPEED

Abkürzung: SPEED |

RECOVERY

RCVY

Diese Optionen beziehen sich nur auf das Laden von VSAM-Datasets. Mit SPEED kann schneller geladen werden, weil auf ein Vorformatieren verzichtet wird. Wird RECOVERY benutzt, so kann ein abgebrochener Ladevorgang an der Stelle des Abbruchs wieder aufgenommen werden. Dies wird aber meist nicht möglich sein, da ein Abbruch auf ein schwerwiegendes Problem hindeutet, der ein einfaches Nachladen meist unmöglich macht (z.B. zu wenig Platz allokiert). Aus diesem Grund wird SPEED

empfohlen.

IMBED NOIMBED -

Syntax: IMBED

I

NOIMBED

Abkürzung:

IMBD

I

NIMBD

MVS/ESA JCL

244

Wird der IMBED-Parameter benutzt, so wird dadurch bewirkt, daß der Sequence Set Record nicht im Indexbereich, sondern auf dem ersten Track der jeweiligen Control Area gespeichert wird. Da eine CA normalerweise einen Cylinder in Anspruch nimmt, kann VSAM den Sequence Set Record und die von ihm indizierten Datenbereiche ansprechen, ohne den Zugriffsmechanismus bewegen zu müssen. Dies ergibt eine erhebliche bessere Performance, so daß die Benutzung dieses Parameters generell empfohlen werden kann. Bei der Kalkulation des Platzes ist daran zu denken, daß in diesem Fall das erste Track eines Cylinders für die Speicherung von Daten nicht zur Verfügung steht. REPLICATE NOREPLICATE -

Syntax:

REPLICATE

I

NOREPLICATE

Abkürzung:

I

REPL

NREPL

Der REPLICATE-Parameter kann zur Verringerung des sogenannten Rotational Delay' eingesetzt werden. Er bewirkt, daß jeder Index Record auf einer separaten Spur zu schreiben ist und so oft wie möglich wiederholt wird. Dadurch wird nur sehr wenig Plattenumdrehungszeit zum Auffinden eines Index Record benötigt.

Andererseits wird mehr Plattenplatz benötigt. Besteht die Indexkomponente eines KSDSDataset aus 15 Index Records und wird REPLICATE angegeben, so nimmt der Indexteil einen kompletten Cylinder in Anspruch. Sofern sich bei Ihnen Platten-Controller, die mit einem Zwischenspeicher (Cache) ausgerüstet sind, im Einsatz befinden, sollten Sie prüfen, ob Sie auf REPLICATE verzichten können. Der replizierte Index nimmt nämlich im Cache mehr Platz weg als der nicht duplizierte. Sofern eine optimale Pufferung erfolgt, kann auf REPLICATE verzichtet werden. ORDERED UNORDERED -

Syntax:

ORDERED

I

UNORDERED

Abkürzung:

ORD

I

UNORD

Dieser Parameter hat nur in Zusammenhang mit dem KEYRANGES-Parameter Bedeutung. Wird er angegeben, so werden die Schlüsselbereiche in der genauen Reihenfolge auf die angegebenen Volumes gelegt. Beachten Sie, daß UNORDERED der Default-Wert ist.

VSAM

245

KEYRANGES

Syntax:

KEYRANGES((lowkey1 highkeyl) (lowkey2 highkey2)...) Abkürzung.: KRNG Schlüsselbereiche eines KSDS-Datasets können auf unterschiedliche Platten angelegt werden. Mit dem KEYRANGES-Parameter werden die Schlüsselbereiche angegeben, die auf die verschiedenen Platten verteilt werden sollen. Bei KEYRANGES sollten so viele Bereiche angegeben werden, wie Volumes im VOLUME-Parameter angegeben worden sind. Die Verteilung von Schlüsselbereichen auf unterschiedliche Platten kann sinnvoll sein, wenn z.B. bestimmte Bereiche nur selten, andere aber sehr häufig angesprochen werden. Selten angesprochene Bereiche kann man dann z.B. auf eine 3380, häufig angesprochene Bereiche auf eine 3390 legen. Durch das Verteilen auf unterschiedliche Platten kann das Responseverhalten günstig beeinflußt werden, weil sich nicht alle User auf einer Platte tummeln. Wenn Sie KEYRANGES einsetzen, so sollten Sie unbedingt den ORDERED-Parameter setzen. Nur dann ist gewährleistet, daß die Schlüsselbereiche auf die Platten kommen, die Sie angegeben haben. (UNORDERED ist Default!)

Beispiel: VOLUMES(DSKO01 DSK002 DSK003) KEYRANGES((X'00000000001 19999) (50001 X'FFFFFFFFFF'))

-

(20000 50000) -

ORDERED

Die Schlüsselbereiche müssen nicht vollständig sein (Lücken sind erlaubt), sie dürfen sich aber nicht überlappen. Wird versucht, mit einem Schlüssel zu schreiben, der nicht im KEYRANGE-Bereich ist, so kommt es zu einem OUT OF KEYRANGE-Fehler. Im obigen Beispiel wurde der niedrigste und höchste Schlüssel in Hexadezimalform angegeben. Die Angabe eines solchen 'Catch-all'-Bereichs kann unter Umständen den Absturz eines CICS-Systems verhindern. Die Benutzung des ORDERED-Parameters stellt sicher, daß alle Records mit den Schlüsseln bis 19999 auf die Platte DSK001, die mit 20000 bis 50000 auf die Platte DSK002 und alle Records, die einen Schlüssel größer als 50000 haben auf das Volume

DSK003 kommen.

Sind weniger VOLUMES als Schlüsselbereiche angegeben, so werden die letzten Schlüsselbereiche zusammen auf das zuletzt angegebene VOLUME gelegt.

MVS/ESA JCL

246

REUSE -NOREUSE

Syntax:

REUSE

I

NOREUSE

Abkürzung: RUS I NRUS

Mit Hilfe des REUSE-Parameters läßt sich ein VSAM-Dataset wiederverwendbar machen. Dadurch kann man sich das Löschen und Definieren vor einem erneuten Beschreiben des Datasets ersparen. Reusable Datasets werden einmal angelegt. Werden sie später mit der Anweisung OPEN OUTPUT angesprochen, so wird das Dataset behandelt, als ob es leer wäre. Um dies zu erreichen, wird ein bestimmtes Feld im Katalogeintrag, das 'high-used RBA' auf 0 gesetzt. Dieses Feld markiert das letzte verwendete Byte im letzten Record. VSAM-Datasets, die mit REUSE definiert wurden, verhalten sich so wie physischsequentielle Datasets, die beim Schreiben mit der Disposition OLD angesprochen werden. Die Option REUSE ist potentiell gefährlich, weil sie ein Überschreiben eines Dataset mit Hilfe eines Anwendungsprogramms gestattet. Wird versehentlich mit OPEN OUTPUT auf ein mit REUSE definiertes Dataset zugegriffen, so ist das Dataset in seiner ursprünglichen Form nicht mehr wiederherstellbar. BUFFERSPACE

Syntax:

BUFFERSPACE(Wert (Byte))

Abkürzung: BUFSP

VSAM stellt bei der Verarbeitung von KSDS-Datasets zwei Buffer für Daten-CIs und einen Buffer für Index-CIs zur Verfügung. Will man die Zahl der Buffer erhöhen, so kann man dies mit dem BUFFERSPACE-Parameter tun. Die Buffer sind Platz im Hauptspeicher, in die die entsprechenden CIs hineingeladen werden. Daten, die im Buffer stehen, brauchen nicht gelesen werden. Durch eine optimale Pufferung läßt sich die Zahl der physischen I/Os senken.

Wählt man bei der Angabe von BUFFERSPACE den Wert so klein, daß er für die Aufnahme von 2 Daten-CIs und einem Index-CI zu klein ist, so kommt es zu einem Abbruch. Am besten läßt man den BUFFERSPACE-Parameter ganz weg. Eine optimale Angabe ist ohnehin nicht möglich, da je nachdem, wie auf das Dataset zugegriffen wird sequentiell oder direkt -, eine unterschiedliche Pufferung notwendig ist. Soll in einem Programm die Zahl der Puffer erhöht werden, so kann dies mit dem AMP JCL-Parameter gemacht werden. -

247

VSAM FOR TO -

Syntax:

FOR(nnnn) I TO([yy]yyddd) FOR(Tage) oder TO(Datum) gibt eine Schutzfrist in Tagen oder ein Datum an, bis zu dem das Dataset nicht gelöscht werden darf. Das Format für den Parameter FOR ist (nnnn), wobei nnnn eine Zahl zwischen 1 und 9999 ist. Das Format für TO ist ([yyjyyddd). Wird das Jahr zweistellig angegeben, so werden für die beiden ersten Byte 19 angenommen. Der Wert für ddd kann zwischen 001 und 366 liegen. Die Verwendung von FOR oder TO stellt keinen absoluten Schutz gegen vorzeitiges Löschen dar. Denn durch die Angabe des Zusatzparameters PURGE bei einem DELETE mit IDCAMS kann ein Löschen auch dann erzwungen TO gesetzte Frist noch nicht abgelaufen ist.

werden,

wenn

die durch FOR oder

SPANNED NONSPANNED -

Syntax: SPANNED

I

NONSPANNED

Abkürzung: SPND I NSPND

Zeigt an, daß bei variabel langen logischen Records die Record-Länge einzelner Records größer sein kann als die CI-Größe. Diese logischen Records werden auf mehrere CIs

verteilt, wobei das CI, in dem der gespannte Record endet, für die Aufnahme weiterer

Records nicht zur Verfügung steht. Das Arbeiten mit SPANNED macht nur Sinn, wenn man trotz einzeln vorkommender langer logischer Records eine optimale CI-Größe beibehalten will. Dies wird nur selten vorkommen, daher ist NONSPANNED der Default. Record Spanning hat nachteilige Auswirkungen auf die Performance und sollte nach Möglichkeit vermieden werden.

Anlegen eines KSDS-Dataset Das

folgende Beispiel zeigt das Anlegen eines VSAM KSDS-Dataset mit 80 Byte RecordLänge und 5 Byte Schlüssellänge. Der Schlüssel beginnt beim ersten Byte des Records (= Offset 0). Das Dataset soll auf dem Volume PRM001 zu liegen kommen. Für den Fall, daß der Platz auf dem Volume PRM001 nicht ausreichen Erweiterung genutzt werden.

sollte, kann das Volume PRM002 als

248

MVS/ESA JCL

Für das Dataset sollen 5 Cylinder primär und 1 Cylinder sekundär allokiert werden. 10 Prozent des Platzes innerhalb der CIs und 10 Prozent der CIs in einer CA sollen beim Laden des Datasets freigelassen werden.

Die Shareoptions sind so gesetzt, daß sie eine Einbindung des Dataset in eine On-LineUmgebung gestatten. Alle Jobs können lesend auf das Dataset zugreifen, einer darf gleichzeitig mit Update-Absicht zugreifen. Das Setzen der Optionen REPLICATE und IMBED dient der Verbesserung der Performance. Dadurch wird Such- und Rotationszeit eingespart. Der vorangehende DELETE dient dem Bereinigen des Katalogs. Da der gesamte CLUSTER gelöscht werden soll, muß der Zusatzparameter CLUSTER beim DELETE mit angegeben werden. Das Beispiel auf der folgenden Seite zeigt die für das Anlegen eines KSDS-Dataset

erforderliche JCL. Nach der Ausführung des DEFINE CLUSTER ist das Dataset zwar definiert, aber noch leer. In diesem Zustand kann es einmal von einem Anwendungsprogramm mit der Anweisung OPEN OUTPUT angesprochen werden. Dies ist erforderlich, wenn man das Dataset mit Hilfe eines Programmes laden will. Meist wird zum Laden jedoch die REPROFunktion von IDCAMS eingesetzt.

249

VSAM

Anlegen eines VSAM KSDS-Dataset: *****************************

******

*****************************

000001 000002 000003 000004 000005 000006

(UWIN,ABTDG02),'M.WINTER 1,NOTIFY=UWIN, //UWIN217C // CLASS=T,MSGCLASS=Y

TOP OF DATA

JOB

//*************************************************************** //* //* //*

IDCAMS ZUM ANLEGEN EINES VSAM KSDS-DATASET

000007 //*************************************************************** 000008 //DEFINE EXEC PGM=IDCAMS 000009 //SYSPRINT DD SYSOUT=* 000010 //SYSIN DD * 000011 DELETE UWIN.SCHULUNG.VSAM.KSDS 000012 CLUSTER 000013 000014 DEFINE CLUSTER (NAME(UWIN.SCHULUNG.VSAM.KSDS) INDEXE) 000015 RECORDSIZEC80 80) 000016 KEYS(5 0) 000017 FREESPACEC10 10) 000018 000019 VOLUMES(PRM001 PRM002) 000020 CYLINDERSC 5 1) SHAREOPTIONS (2 3) 000021 REPLICATE 000022 IMBED ) 000023 -

-

-

000024 000025 000026 000027 ******

DATA (NAME(UWIN.SCHULUNG.VSAM.KSDS.DATA) CONTROL INTERVALSIZE(4096))

-

-

INDEX (NAME(UWIN.SCHULUNG.VSAM.KSDS.INDEX) CONTROL INTERVALSIZE(1536)) ***************************

BOTTOM OF DATA

-

***************************

Anlegen eines ESDS-Datasets Im folgenden Beispiel wird ein VSAM ESDS-Dataset angelegt. ESDS sind die sequentielle Variante von VSAM-Datasets und kommen dort zum Einsatz, wo normale QSAM-Datasets nicht eingesetzt werden können, z.B. in CICS-Umgebungen. Da ein ESDS-Dataset keine Index-Komponente besitzt, wird der Indexteil beim Definieren weggelassen. Es gibt auch keine Möglichkeit, freien Platz wie auf einem KSDS-Dataset zu definieren. Der FREESPACE-Parameter darf deshalb nicht benutzt werden. Da ein Zugriff mit einem Schlüssel ebenfalls nicht möglich ist, muß der KEYS-Parameter weggelassen

250

MVS/ESA JCL

werden. Die den soll.

Angabe

NONINDEXED teilt AMS

edit-uwin.schulung. idcloes(defesds) command ===> ******

*****************************

mit, daß ein ESDS-Dataset angelegt wer01.02

.

-

columns 001 072 ===> page

scroll

fop op data

*****************************

000001 //uwin217d job (998,abtdg02),'m.winter 1, 000002 // class=c, 000003 // msgclass=y, notify=uwin 000004 // 000005 //deldef exec pgm=idcams 000006 //sysprint dd sysout=* 000007 //sysin dd * 000008 delete 000009 uwin.schulung.vsam.esds 000010 cluster 000011 8 then set maxcc = 0 if maxcc define cluster 000012 000013 (name(uwin.schulung.vsam.esds) 000014 nonindexed cylinders (11) 000015 000016 volumes ( dsk021 ) recordsize ( 80 80 ) 000017 unique 000018 shareoptions (13)) 000019 data 000020 000021 (name(uwin.schulung.vsam.esds.data) 000022 cisz ( 18432) ) -

=

-

-

-

-

-

******

****************************

bottom of data

Die CI-Größe im Datenteil wurde für eine Platte des

****************************

Typs 3390 optimiert.

Anlegen eines RRDS-Datasets RRDS-Datasets können

nur dort sinnvoll eingesetzt werden, wo eine logische Beziehung zwischen dem Schlüssel und der relativen Position des Records im Dataset hergestellt werden kann. Einen KEYS-Parameter gibt es deshalb bei RRDS-Datasets nicht. Da RRDS Daten keine Indexkomponente besitzen, ist der Zugriff auf die Records schneller als bei der

KSDS.

Da RRDS-Datasets nur Records mit fixer Länge verarbeiten können, müssen beim RECORDSIZE-Parameter und avg und max die gleichen Angaben gemacht werden. Mit der Angabe NUMBERED wird das Anlegen eines RRDS-Datasets erreicht.

251

VSAM 01.02

EDIT-UWIN.SCHULUNG. IDCLOES(DEFRRDS)

.

-

COMMAND

COLUMNS 001 072 ===> PAGE

SCROLL

===>

******

*****************************

000001

//UUIN217D

JOB

000002 000003 000004 000005

// // //

CLASS=C, MSGCLASS=Y,

jop op DATA

*****************************

(998,ABTDG02),'M.WINTER',

NOTIFY=UWIN

EXEC PGM=IDCAMS //DELDEF 000006 //SYSPRINT DD SYSOUT=* DD * 000007 //SYSIN

000008 000009

DELETE -

UWIN.SCHULUNG.VSAM.RRDS CLUSTER

000010 000011

IF MAXCC

=

8 THEN SET MAXCC

=

0

DEFINE CLUSTER

000012 000013 000014 000015 000016 000017 000018 000019 000020

-

(NAME(UWIN.SCHULUNG.VSAM.RRDS) NUMBERED CYLINDERS

(11)

VOLUMES

( DSK031 ) )

-

RECORDSIZE ( 80 80 UNIQUE

-

-

SHAREOPTIONS

(13))

.

-

DATA -

(NAME(UWIN.SCHULUNG.VSAM.RRDS.DATA) (18432) )

000021 000022 ******

CISZ

****************************

BOTTOM OF DATA

***************************

Anlegen eines LDS-Datasets Lineare VSAM-Datasets lassen sich mit Hilfe von IDCAMS definieren. Um ein LDS zu definieren, sind nur wenige Angaben erforderlich. Lineare VSAM-Datasets bestehen nur aus einem Datenteil. Sie haben eine einheitliche CI-Größe von 4096 Byte. Diese CIs sind reine Daten-CIs ohne Kontroll-Informationen. Aus diesen Gründen sind

folgende Angaben nicht erlaubt:

1.

RECSZ

LDS kennen keine Recordsize.

2.

FSPC

LDS können keinen Freespace besitzen.

Als CISZ ist ausschließlich 4096

zulässig.

Meist wird der Parameter weggelassen.

MVS/ESA JCL

252 EDIT-UWIN. SCHULUNG. IDCLOES(DEFLDS)

01.02

.

-

COMMAND

===>

******

*****************************

000001 000002 000003 000004

//UUIN217D

JOB

joP OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

(998,ABTDG02),1M.WINTER 1,

CLASS=C, // MSGCLASS=Y, // NOTIFY=UWIN // EXEC PGM=IDCAMS 000005 //DELDEF DD SYSOUT=* 000006 //SYSPRINT DD * 000007 //SYSIN DELETE 000008 UWIN.SCHULUNG.VSAM.LINEAR 000009 CLUSTER 000010 = 8 THEN SET MAXCC = 0 IF MAXCC 000011 -

000012 000013

DEFINE CLUSTER

(NAME(UWIN.SCHULUNG.VSAM.LINEAR) LINEAR

000014 000015 000016 000017 000018 000019 ******

-

CYLINDERS

(11)

VOLUMES

( DSK031 ) ( 4096 )

CISZ

-

-

UNIQUE SHAREOPTIONS (1 3) ) ****************************

BOTTOM OF DATA

****************************

Nach dem Definieren können lineare VSAM-Datasets nur mit dem Inhalt anderer linearer VSAM-Datasets oder mit Hilfe eines Anwendungsprogrammes geladen werden.

VSAM-Datasets laden mit dem REPRO-Kommando Mit dem DEFINE CLUSTER-Kommando wird ein VSAM-Dataset angelegt, allerdings befinden sich in ihm noch keine Daten. Geladen werden kann es nun mit einem Anwendungsprogramm oder aber mit dem Inhalt eines anderen Datasets. Für diesen Kopiervorgang steht das REPRO-Kommando zur Verfügung.

Syntax: REPRO

-

INFILE(ddname) | INDATASET(dsname) OUTFILE(ddname) | OUTDATASET(dsname) FROMKEY(lowkey) | FROMNUMBER(lownumber) | FROMADDRESS(lowaddress) | SKIP(zahl) TOKEY(highkey) | TONUMBER(highnumber) | TOADDRESS(highaddress) | COUNT(zahl) -

-

-

253

VSAM

Um die INFILE/OUTFILE-Parameter benutzen zu können, müssen die DD-Namen in der JCL enthalten sein. Wird ein nicht existierendes Dataset angesprochen, bricht der Job mit einem Fehler ab. Bei der Benutzung von INDATASET oder OUTDATASET werden keine DD-Anweisungen benötigt. Werden nicht existierende Datasets angesprochen, so kommt es lediglich zu einer Meldung im SYSPRINT von IDCAMS, der Job bricht nicht ab. Es kann aber auch bei existierenden Datasets zu Allokationsproblemen kommen. Es ist auch möglich, die Kombination einzusetzen und umgekehrt.

Wenn nicht vom Beginn des folgende Weise spezifizieren:

Datasets

INFILE(ddname) OUTDATA-SET(dsname)

kopiert

werden

soll,

so

läßt sich der

Beginn

auf

1.

Bei KSDS-Datasets mit FROMKEY und Angabe des Startschlüssels.

2.

Bei RRDS-Datasets mit FROMNUMBER und Angabe des relativen Schlüssels.

3.

Bei ESDS-Datasets mit FROMADDRESS und Angabe einer relativen Byte-Adresse, die von VSAM auf die nächst größere 512-Byte-Grenze aufgerundet wird.

4.

Bei allen Datasetformen

überspringenden Records.

(außer LDS)

Wenn nicht bis zum Ende des Datasets folgende Weise spezifizieren:

mit SKIP und

kopiert

werden soll,

Angabe so

der Zahl der

läßt sich das Ende auf

1.

Bei KSDS-Datasets mit TOKEY und Angabe des Endeschlüssels.

2.

Bei RRDS-Datasets mit TONUMBER und Angabe des relativen Schlüssels.

3.

Bei ESDS-Datasets mit TOADDRESS und Angabe einer relativen von VSAM auf die nächst größere 512er Grenze aufgerundet wird.

4.

Bei allen Datasetformen kopierenden Records.

(außer LDS)

mit COUNT und

zu

Angabe

Byte-Adresse,

die

der Zahl der

zu

Beim Laden eines VSAM-Dataset mit REPRO wird das Dataset in einen physisch optimalen Zustand gebracht. Das gilt auch dann, wenn von einem anderen VSAM-Dataset kopiert wird, welches sich nicht in einem optimalem Zustand befindet. Der unter FREESPACE angegebene Platz wird beim Kopieren mit REPRO freigehalten.

MVS/ESA JCL

254

folgende Beispiel zeigt sequentiellen Datasets:

Das

das Laden eines KSDS-Dataset mit dem Inhalt eines

edit-uwin.schulung.idcamscrep01)

01.05

.

-

command

scroll

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009

//uwin217c

===>

page

*****************************

(uwin,abtdg02),'m.winter1,notify=uwin,

job

class=t,msgclass=y //**************************************************** idcams zum kopieren mit infile / outfile //* //*************************************************************** //

//repro //sysprint //ein //aus 000010 //sysin dd repro 000011

******

top of data

exec pgm=idcams dd sysout=* dd dd

dsn=uwin.schulung.vsamload.seq,disp=shr dsn=uwin.schulung.vsam.ksds,disp=old

*

infile(ein) outfile(aus)

****************************

bottom of data

***************************

Voraussetzung für das Funktionieren dieses Beispiels ist, daß die Records des sequentiellen Datasets, das zum Laden verwendet wird, auf dem Schlüsselfeld aufsteigend sortiert sind und keine Records mit identischem Schlüssel vorhanden sind. Sind diese Voraussetzungen nicht erfüllt, kommt es beim REPRO zu einem Abbruch. *************************************

idcams

*****************************

system services

repro infile(seqfil)

idc3302i

top of data

time: 09:45:27

outdataset(uwin.schulung.vsam.ksds)

action error on uwin.schulung.vsam.ksds

idc3314i **record x1f0f0f2f0f11 out of sequence idc0005i number of records processed was 38 idc0001i function completed, highest condition code was 8 idc0002i idcams processing complete. maximum condition code was 8 bottom of data ***************************

************************************

Die Fehlermeldung verweist darauf, daß auf dem Ladedataset der Record mit dem Schlüssel 00201 'Out of Sequence' ist. Meist ist der Fehler auf einen doppelt vorhandenen Schlüssel zurückzuführen. Ein Tip: In Testumgebungen können Sie das sequentielle Dataset mit der SORT-Utility über das Schlüsselfeld sortieren. Wenn Sie zusätzlich SUM FIELDS=NONE angeben, so

VSAM

255

werden Duplikate auf dem Schlüsselfeld unterdrückt. Bei einem es nicht mehr zu dem oben beschriebenen Fehler kommen.

so

erstellten Dataset kann

VSAM- auf VSAM-Dataset wie im folgenden Beispiel funktioniert meist die VSAM-Datasets sind vom gleichen Typ. Ein REPRO zwischen unterschiedlichen VSAM-Datasettypen ist aber ebenfalls zulässig, mit der Ausnahme von LDS-Datasets. Ein REPRO

von

problemlos, vorausgesetzt,

01.05

EDIT-UWIN.SCHULUNG.IDCAMS(REP02)

-.-.-.

-

COMMAND

SCROLL

===>

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008

//UWIN217C JOB (ULJIN,ABTDG02), 1 M.WINTER 1 ,NOTIFY=UWIN, // CLASS=T,MSGCLASS=Y //*************************************************************** IDCAMS ZUM KOPIEREN MIT INDATASET / OUTDATASET //* //**********************************

000009 000010 ******

fop OF DATA

PAGE

*****************************

//REPRO EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * REPRO

INDATASETCUWIN.SCHULUNG.VSAM.KSDS.ALT) OUTDATASETCUWIN.SCHULUNG.VSAM.KSDS.NEU)

****************************

BOTTOM OF DATA

-

***************************

Beachten Sie, daß LDS mit REPRO nur dann geladen werden können, wenn als INFILE oder INDATASET ein anderes LDS spezifiziert wurde. Ein Laden von anderen VSAMDatasetformen ist nicht möglich.

Eine direkte Verarbeitung eines LDS ist mit Hilfe der Data Windowing Services deren komplette Darstellung den Rahmen dieses Buches jedoch sprengen würde.

VSAM KSDS-Datasets

möglich,

reorganisieren

VSAM KSDS-Datasets haben die Besonderheit, daß in das bestehende Dataset Records eingefügt werden können. Durch diese Einfügeaktivitäten kann es zu CI- bzw. CA-Splits kommen. Diese Splits beeinträchtigen die Performance. Die physische Reihenfolge der Records kann nach einiger Zeit von der logischen abweichen. Wenngleich auch dann die Verarbeitung immer gewährleistet ist, so ist die Performance besser, wenn die physische weitgehend der logischen Record-Reihenfolge entspricht. Durch die Einfügeaktivität geht freier Platz immer mehr verloren, bis irgendwann ein

Einfügen gänzlich unmöglich wird. Vorher wird VSAM versuchen, Sekundärextents anzulegen (122 sind möglich). KSDSDatasets mit einer großen Zahl von Sekundärextents haben aber ebenfalls eine sehr schlechte Performance. Über kurz oder lang muß ein KSDS-Dataset reorganisiert werden. Dieses Reorganisieren besteht aus den folgenden Schritten: 1. Sichern des KSDS-Datasets durch

Kopieren.

MVS/ESA JCL

256 2.

Löschen des KSDS-Datasets.

3.

Neudefinieren des KSDS-Datasets.

4.

Laden des KSDS-Datasets mit der unter Schritt 1

angelegten Sicherung.

Beim ersten Schritt hat man die Wahl, ob man das KSDS-Dataset in ein anderes oder auf ein sequentielles Dataset kopieren will. Das folgende Beispiel zeigt einen kompletten REORG-Job: EDIT

01.05

UWIN.SCHULUNG.IDCAMS(REORG) -

COMMAND

.

-

SCROLL

===> *****************************

000001 000002 000003 000004 000005

//UWIN217C JOB (UWIN,ABTDG02),'M.WINTER1,NOTIFY=UWIN, // CLASS=T,MSGCLASS=Y //*************************************^ //* //*

TQp op DATA

===>

REORG EINER VSAM KSDS

000006 //* 000007 //*************************************************************** 000008 //DELETE EXEC PGM=IDCAMS 000009 //SYSPRINT DD SYSOUT=* DD * 000010 //SYSIN DELETE UWIN.SCHULUNG.VSAM.KSDS.BACK 000011 IF MAXCC = 8 THEN SET MAXCC = 0 000012 000013 //*************************************************************** 000014 000015 000016 000017 000018

//* SICHERN DER KSDS //* //* //**************************************^ EXEC PGM=IDCAMS //REPR01

000019 //SYSPRINT DD SYSOUT=* 000020 //INVSAM DD DSN=UWIN.SCHULUNG.VSAM.KSDS,DISP=SHR DD DSN=UWIN.SCHULUNG.VSAM.KSDS.BACK, 000021 //OUTSEQ 000022 // DISP=(,CATLG,DELETE), 000023 // UNIT=SYSDA, 000024 // SPACE=(CYL,(10,1)), 000025 //_RECFM=FB, LRECL=80_

Das

Beispiel wird auf der folgenden Seite fortgesetzt.

PAGE

*****************************

******

257

VSAM 000026 000027 000028 000029 000030 000031 000032 000033 000034 000035 000036 000037

DD

//SYSIN

*

REPRO INFILE page

*****************************

,

notify=uwin

// //deldef //sysprint //sysin

exec pgm=idcams dd sysout=* dd

*

delete -

uwin.schulung.vsam.ksds.aix -

aix if maxcc

=

8 then set maxcc

=

0

define aix

(name(uwin.schulung.vsam.ksds.aix) relate(uwin.schulung.vsam.ksds)

-

-

cyl (11)-

(dsk005)

vol

-

freespace ( 00 00 ) recsz ( 49 84 ) keys ( 29 5 )

-

-

-

imbed repl reuse upgrade nonuniquekey ) data -

-

-

(name(uwin.schulung.vsam.ksds.aix.data)) -

index -

(name(uwin.schulung.vsam.ksds.aix.index )) bottom of data

****************************

Pfade für AIX-Datasets mit DEFINE PATH definieren Mit dem Kommando DEFINE PATH wird eine Basiscluster und dem AIX-Cluster hergestellt.

logische Verbindung

zwischen dem

Der Pfad selbst besteht nur aus einem Eintrag im Katalog. Er sorgt dafür, daß der AIXCluster geöffnet wird, wenn der Basiscluster geöffnet wird, ohne daß dadurch zusätzlicher Codieraufwand in einem Anwendungsprogramm entsteht.

MVS/ESA JCL

264

Syntax:

DEFINE PATH

(NAME(Katalog-Eintrag) PATHENTRY(Katalogeintrag) UPDATE I NOUPDATE)

-

NAME

Syntax:

NAME(Katalogeintrag) NAME gibt den Namen des Pfades daß es sich um einen Pfad handelt.

an.

Wählen Sie den Namen so, daß

man

erkennen

kann,

PATHENTRY

Syntax:

Abkürzung: PENT

PATHENTRY(Katalogeintrag) Im PATHENTRY-Parameter muß der Name des AIX-Clusters dem Kommando DEFINE AIX vergeben wurde.

angegeben werden,

der mit

UPDATE/NOUPDATE

Syntax: UPDATE

|

Abkürzung:

NOUPDATE

Der UPDATE/NOUPDATE-Parameter hat Alternativschlüssel direkt verarbeitet wird Alternativschlüssel gelegt sind.

nur

und

dann über

Bedeutung,

einen

|

UPD

NUPD der mehrere

wenn

Cluster

Beim direkten Verarbeiten des Alternativschlüssels wird der Pfad und nicht der Basiscluster in der DD-Anweisung angesprochen. Wenn UPDATE angegeben wird, so werden alle AIX-Cluster mit geöffnet und, falls erforderlich, upgedated. Wird nur lesend zugegriffen, so kann man mit NOUPDATE das der anderen Alternativschlüssel sparen.

überflüssige Mitschleppen

265

VSAM

Beispiel für Anlegen eines Pfades Im

folgenden Beispiel wird ein Pfad zum Zugriff auf den AIX-Cluster definiert: 01.00

edit-uwin.schulung.cntl(defpath)

.

-

command ******

columns 001 072 ===> page

scroll

===> *****************************

top of data

000001 //uwin217x (998,abtdg02),'m.winter 000002 // class=r, 000003 // msgclass=y, 000004 //* notify=uwin,typrun=scan notify=uwin 000005 // 000006 //defpath exec pgm=idcams 000007 //sysprint dd sysout=* dd * 000008 //sysin 000009 define path job

1

*****************************

,

-

(name(uwin.schulung.vsam.ksds.aix.path) pathentry(uwin.schulung.vsam.ksds.aix) update)

000010 000011 000012 ******

****************************

bottom of data

-

-

***************************

Alternativindex laden mit BLDINDEX

Mit dem BLDINDEX-Kommando wird der AIX-Cluster ähnlich dem REPRO-Kommando.

geladen.

Die

Wirkungsweise

ist

Syntax: BLDINDEX

INFILE(ddname) | INDATASET(Katalog-Eintrag) OUTFILE(ddname) j OUTDATASET(Katalog-Elntrag) -

EXTERNALSORT

-

j INTERNALSORT

Die Benutzung von INFILE/OUTFILE bzw. INDATASET/OUTDATASET ist wie beim REPRO. Bei INFILE bzw. INDATASET ist der Name des Basisclusters anzugeben, bei OUTFILE bzw. OUTDATASET der des AIX-Clusters. EXTERNALSORT INTERNALSORT -

Syntax:

EXTERNALSORT I INTERNALSORT

Abkz.: ESORT I ISORT

MVS/ESA JCL

266

Mit Hilfe dieses Parameters wird angegeben, ob das Sortieren der Alternativindices nur im virtuellen Speicher (ISORT) oder auf Platte (ESORT) geschieht. Wird ESORT verwendet, so sind unbedingt zwei Datasets mit den DD-Namen IDCUT1 und IDCUT2 anzugeben. Diese Datasets werden auch dann benutzt, wenn beim ISORT der virtuelle Speicher nicht ausreicht. Die Zwischenspeicher-Datasets brauchen eine UNIT- und VOLUME-Angabe. Bei VOLUME dürfen maximal 5 Plattenangaben stehen. Beachten Sie auch den Parameter AMP=AMORG', der darauf verweist, daß diese Workdatasets VSAM-Datasets sind. Diese Datasets werden von VSAM angelegt und sofort wieder gelöscht (trotz DISP=OLD und anderslautender Meldungen im Job). Ist bei Ihnen SMS aktiv, so lassen Sie die IDCUT1- und IDCUT2-Angabe weg, da eine explizite Volume-Allokation in der Regel nicht möglich sein wird. Brauchen Sie dennoch eine externes Sort-Workfile, so übernimmt SMS die gesamte Arbeit des Erstellens und Löschens dieses Files.

Beispiel für BLDINDEX Das folgende Beispiel zeigt die JCL für das Laden eines AIX-Clusters: 01.00

EDIT-UWIN.SCHULUNG.CNTL(BLDINDEX)

.-.

-

COMMAND ******

SCROLL

===> *****************************

-pop OF DATA

000001 //UWIN217X 000002 // 000003 // 000004 //* 000005 // 000006 //BLDINDEX 000007 //SYSPRINT 000008 //IDCUT1

(998,ABTDG02),'M.WINTER 1, CLASS=G, MSGCLASS=Y, NOTIFY=UWIN,TYPRUN=SCAN

000009 000010 000011 000012 000013 000014 000015 000016

//

UNIT=3390,VOL=SER=PRM001,AMP='AMORG' DD DSN=UWIN.SORT.TWO,DISP=0LD, UNIT=3390,VOL=SER=PRM001,AMP='AMORG'

******

****************************

//IDCUT2 // //BASECL //ALTCL //SYSIN

===>

PAGE

*****************************

JOB

NOTIFY=UWIN EXEC PGM=IDCAMS DD SYSOUT=* DD DSN=UWIN.SORT.ONE,DISP=OLD,

DD DSN=UWIN DD DD

SCHULUNG.VSAM.KSDS,DISP=SHR DSN=UWIN.SCHULUNG.VSAM.KSDS.AIX,DISP=OLD .

*

BLDINDEX -

INFILE(BASECL) OUTFILE(ALTCL) BOTTOM OF DATA

***************************

267

VSAM Der

folgende SYSPRINT meldet das erfolgreiche Erstellen (Laden) des Alternativindexes:

********************************

IDCAMS

fop OF DATA

**********************************

TIME: 09:43:23

SYSTEM SERVICES

BLDINDEX -

INFILE(BASECL) OUTFILE(ALTCL) IDC0652I UWIN.SCHULUNG.VSAM.KSDS.AIX SUCCESSFULLY BUILT IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 *******************************

BOTTOM OF DATA

********************************

Überprüfen

Sie unbedingt den SYSPRINT für den BLDINDEX. Auch ein RC 0 nicht, daß das Laden des Alternativindexes erfolgreich war. Der folgende SYSPRINT zeigt eine Fehlerbedingung, die auftreten kann, wenn bei nichteindeutigen Schlüsseln die maximale Record-Länge nicht ausreichend ist. In diesem Fall können nicht alle Sekundärschlüssel, die zum Primärschlüssel gehören, aufgenommen werden. Damit ist ein erfolgreicher Zugriff über den Sekundärschlüssel nicht in allen Fällen bedeutet

gewährleistet.

SYSPRINT

BROWSE

1-- LINE

BLDINDEX-- PAGE

1-- COLS

1

80

-

COMMAND

SCROLL

===>

********************************

IDCAMS

TOP OF DATA

===>

SCREEN

**********************************

TIME: 09:39:16

SYSTEM SERVICES

BLDINDEX -

INFILE(BASECL) OUTFILECALTCL) IDC1646I

3 EXCESS PRIME KEY VALUES FOR AIX KEY D4E4C5D3D3C5D9404040

IDC0652I UWIN.SCHULUNG.VSAM.KSDS.AIX SUCCESSFULLY BUILT IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0

IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 *******************************

Die

Hex-Angabe

BOTTOM OF DATA

********************************

verweist auf den Namen MUELLER. Tritt eine solche

Fehlerbedingung

auf, so redefinieren Sie den AIX-Cluster mit einer ausreichenden Schlüssellänge.

MVS/ESA JCL

268 Erstellen und Laden des AIX Das

der einen AIX

folgende Beispiel zeigt den kompletten Job,

definiert, den Pfad erstellt

und den AIX lädt. ******

*****************************

top 0f data

*****************************

000001 //uwin217x job (998,abtdg02),1m.winter , 000002 // class=r,msgclass=y,notify=uwin exec pgm=idcams 000006 //deldef 000007 //sysprint dd sys0ut=* 000008 //sysin dd * 000009 delete 000010 uwin.schulung.vsam.ksds.aix purge 000011 000012 aix if maxcc = 8 then set maxcc = 0 000013 1

-

-

-

000014 000015 000016

define aix

(name(uwin.schulung.vsam.ksds.aix) relate(uwin.schulung.vsam.ksds) (11)(dsk005)

-

-

000017 000018 000019 000020

-

freespace ( 00 00 ) recsz ( 49 84 )

-

-

000021 000022 000023 000024 000025 000026 000027 000028 000029

( 29 5 )

keys

-

imbed repl

reuse upgrade -

nonuniquekey ) data

-

-

(name(uwin.schulung.vsam.ksds.aix.data)) -

index -

000030 (name(uwin.schulung.vsam.ksds.aix.index )) 000031 /* 000032 //defpath exec pgm=idcams 000033 //sysprint dd sysout=* dd * 000034 //sysin 000035 define path 000036 (name(uwin.schulung.vsam.ksds.aix.path) 000037 pathentry(uwin.schulung.vsam.ksds.aix) -

-

-

000038 000039 /*

Das

update)

Beispiel wird auf der folgenden Seite fortgesetzt.

269

VSAM

000040 000041 000042 000043 000044 000045 000046 000047 000048 000049 000050

//BLDINDEX EXEC PGM=IDCAHS //SYSPRINT DD SYSOUT=*

******

****************************

//IDCUT1

DD

//

UNIT=3390,VOL=SER=PRM001,AMP=lAMORGl

DSN=UWIN.SORT.ONE,DISP=OLD,

//IDCUT2 // //BASECL //ALTCL

DD

DD

DSN=UWIN.SCHULUNG.VSAM.KSDS.AIX,DISP=0LD

//SYSIN

DD

*

DSN=UUIN.SORT.TWO,DISP=OLD,

UNIT=3390,VOL=SER=PRM001,AMP=1AMORG1 DD DSN=UWIN.SCHULUNG.VSAM.KSDS.DISP=SHR

BLDINDEX -

INFILE(BASECL) OUTFILE(ALTCL) BOTTOM OF DATA

***************************

Diesen kompletten Job müssen Sie nur beim ersten Definieren laufen lassen. Da der AIXCluster mit REUSE definiert wurde, reicht für einen eventuell notwendigen Update des AIX ein Job, der nur den BLDINDEX durchführt. Sofern Sie sich dafür entscheiden, den AIX-Cluster ohne UPDATE zu definieren, müssen Sie den Alternativindex täglich mit BLDINDEX auf den neuesten Stand bringen. Achten Sie jedoch darauf, daß es auch im AIX-Cluster zu Splits kommen kann, die die Performance beeinträchtigen. Wenn Sie Splits im AIX-Cluster feststellen, so fahren Sie einen kompletten Job, der den AIX reorganisiert.

Ansprechen über den AIX im Batch Die folgende JCL wird verwendet, um im Dataset über den Alternativschlüssel

zu

Batch einen machen.

Zugriff

auf ein VSAM KSDS-

Es sei an dieser Stelle nochmals darauf hingewiesen, daß die Performance im Batch sehr schlecht ist, so daß Sie auf die Möglichkeit, den Basiscluster umzusortieren und sequentiell zu

verarbeiten, zurückgreifen sollten.

folgende Vorgehensweise ist nur dann angebracht, wenn auf diese Weise eine nur sehr geringe Zahl von Datensätzen gelesen werden soll.

Die

MVS/ESA JCL

270 ******

*****************************

jQp op daTA

*****************************

000001 //UWIN217Z JOB (998,ABTDG02),1M.WINTER 1,CLASS=C,NOT IFY=UWIN, MSGCLASS=Y 000002 // 000003 //********************************** 000004 //* ZUGRIFF AUF RECORDS UEBER DEN ALTERNATIVINDEX 000005 //* 000006 //*

* * *

000007 000008 000009 000010 000011 000012 000013 000014 000015 000016

//*********************************************************************

******

****************************

//STEP1 //STEPLIB //SYSPRINT //SYSABOUT //SYSDBOUT

EXEC PGH=KSDSAIX DD

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

DD SYSOUT=* DD SYSOUT=* DD SYSOUT=*

DD SYSOUT=* //SYSOUT //VSAMFILE DD DSN=UWIN.SCHULUNG.VSAM.KSDS,DISP=SHR

//VSAMFIL1

DD

//INPFILE

DD

DSN=UWIN.SCHULUNG.VSAM.KSDS.AIX.PATH,DISP=SHR DSN=UWIN.SCHULUNG.KSDSINP.SEQ,DISP=SHR BOTTOM OF DATA

***************************

Beachten Sie die zusätzliche Angabe VSAMFIL1. Sie muß gemacht werden, auch wenn im COBOL-Programm keine SELECT ASSIGN-Anweisung steht. Der DSN unter VSAMFIL1 muß auf den Pfad verweisen, um einen Zugriff über den Alternativschlüssel zu ermöglichen. Sind mehrere AIXe definiert, so müssen sie unter den DD-Namen VSAMFIL2, VSAMFIL3 VSAMFI10 angegeben werden. Das Maximum ist 99. Im COBOL-Programm muß die SELECT ASSIGN-Anweisung um die ALTERNATE KEY IS-Klausel erweitert werden. Beim READ ist ...

READ filename KEY IS

alt-key

anzugeben. VSAM Informationen mit LISTCAT abrufen Alle mit VSAM in Zusammenhang stehenden Einträge stehen im ICF Katalog. Diese Einträge kann man sich mit dem LISTCAT-Kommando ausgeben lassen. LISTCAT funktioniert auch für nicht-VSAM-Datasets, doch sind die Informationen nicht sehr

ergiebig.

271

VSAM

Syntax: LISTCAT

-

ENTRIES(Katalogeintrag) | LEVEL(Ebene) Eintrag-Typ

-

-

NAME

I

HISTORY

|

VOLUME

|

ALLOCATION

|

ALL

Den LISTCAT können Sie als IDCAMS-Job laufen lassen. Sie können aber auch jederzeit mit den gleichen Anweisungen einen LISTCAT als TSO-Kommando absetzen. Der Nachteil dieser Vorgehensweise ist, daß Sie dann keine Möglichkeit zum Blättern haben.

Als

Eintrag-Typ sind zulässig:

EINTRAG-TYP ALTERNATEINDEX CLUSTER DATA GENERATIONDATAGROUP INDEX NONVSAM PATH USERCATALOG

ABKÜRZUNG AIX

GDG

USERCAT

Über die Parameter ENTRIES und LEVEL läßt sich die Auswahl der

zu

listenden

Katalogeinträge steuern. Werden beide Parameter weggelassen, so werden alle Katalogeinträge ausgegeben und das können sehr viele sein. Erfolgt das Suchen über den ENTRIES-Parameter, so erfolgt die Suche gemäß dem dort angegebenen Namen. Eine Ebene läßt sich durch einen Stern ersetzen. Mit dem LEVEL-Parameter wird der Beginn der Datasetnamen angegeben. VSAM listet dann alle Katalogeinträge auf, die diesen Kriterien entsprechen und zwar unabhängig von der Anzahl der Ebenen, die auf den LEVEL Eintrag folgen. Wie dies im einzelnen funktioniert, soll anhand folgender Beispiele verdeutlicht werden: 1.

LISTCAT

ENTRIES(UWIN.TEST.VSAM.KSDS.MASTER)

Listet alle Informationen über das Dataset mit dem

2.

LISTCAT

Listet alle

ENTRIES(UWIN.*)

angegebenen Namen auf.

ALL

Einträge auf, die mit UWIN beginnen und aus zwei Qualifiern bestehen.

ALL

MVS/ESA JCL

272 3.

LISTCAT

LEVEL(UWIN)

ALL

Einträge auf, die mit UWIN beginnen unabhängig von der Zahl der Qualifier. Der Umfang der auszugebenden Information läßt sich durch Auswahlparameter steuern. Der Default ist NAME. Wird er benutzt, so listet VSAM nur den Katalogeintrag, den Eintrag-Typ und, falls vorhanden, den zugeordneten User-Katalog. Wird HISTORY angegeben, so wird zusätzlich die Owner-ID, Erstellungsdatum, Listet alle

Schutzfrist bzw. Ablaufdatum und die Nummer des VSAM Release, unter dem das Dataset erstellt wurde, angegeben. Außerdem werden alle mit dem angegebenen Katalogeintrag zusammenhängenden Einträge angezeigt. Wird z.B. der Name eines Clusters angegeben, so wird auch die Daten- und Index-Komponente mit ausgegeben. Existieren auch Pfade oder Alternativindices, so werden diese auch mit ausgegeben. Wird VOLUMES angegeben, so wird zusätzlich zur HISTORY-Information Angaben über alle Volumes ausgegeben, auf denen Daten- und Indexkomponente liegen. Wird ALLOCATION angegeben erfolgen zusätzliche Information über Anzahl und Lage der Extents. Diese Informationen lassen Rückschlüsse auf den Organisationsgrad des Datasets zu. Bei der

von ALL erfolgt die umfangreichste Informationsausgabe. Sie umfaßt der Records, geänderte und gelöschte Records, Shareoptionen, Anzahl über Zahl Angaben der CI- und CA-Splits.

Der

Angabe

Output des LISTCAT

Nachfolgend ist der Output eines LISTCAT für ein VSAM KSDS-Dataset abgebildet.

273

VSAM

.

TSO COMMAND PROCESSOR .•

ENTER TSO

COMMAND, CLIST,

OR REXX EXEC BELOW:

LISTCAT ENTRIESCUWIN.SCHULUNG.VSAM) ALL UWIN.SCHULUNG.VSAM CLUSTER UCAT.T800 IN-CAT

===>

.

---

HISTORY ***

OWNER-IDENT UWIN CREATION 2 RELEASE EXPIRATION PROTECTION-PSWD (NULL) ASSOCIATIONS UWIN.SCHULUNG.VSAM.DATA DATA INDEX UWIN.SCHULUNG.VSAM.INDEX UWIN.SCHULUNG.VSAM.DATA DATA

1990.240 0000.000 RACF (NO)

.

IN-CAT UCAT.T800 HISTORY OWNER-IDENT (NULL) 2 RELEASE PROTECTION-PSWD (NULL) ASSOCIATIONS CLUSTER--UWIN.SCHULUNG.VSAM ---

1990.240 0000.000

CREATION EXPIRATION RACF

(NO)

ATTRIBUTES KEYLEN 5 RKP 0

AVGLRECL MAXLRECL

SHROPTNSd ,3) NOWRITECHK

30 30

BUFSPACE 45568 EXCPEXIT (NULL)

RECOVERY

NOIMBED

UNIQUE

NOREPLICAT

CISIZE

CI/CA NOERASE

UNORDERED

22528 30 INDEXED NOREUSE

NONSPANNED

STATISTICS

REC-TOTAL REC-INSERTED

10 0 0

REC-UPDATED REC-RETRIEVED

0 0

REC-DELETED

SPLITS-CI SPLITS-CA

FREESPACE-%CI FREESPACE-%CA FREESPC-BYTES

0 0 0

0 653312

EXCPS EXTENTS SYSTEM-TIMESTAMP:

X'A362EF924CB5F300'

16 1

274

MVS/ESA JCL ALLOCATION SPACE-TYPE

CYLINDER

HI-ALLOC-RBA

1 1

SPACE-PRI SPACE-SEC

HI-USED-RBA

675840 675840

VOLUME VOLSER

DSK018 PHYREC-SIZE

22528 2 15

DEVTYPE X'3010200E' PHYRECS/TRK VOLFLAG PRIME TRACKS/CA

HI -ALLOC-RBA

HI-USED-RBA

675840 EXTENT-NUMBER 1 675840 EXTENT-TYPE X1001

EXTENTS: LOW-CCHH

LOW-RBA 0 HIGH-RBA 675839

X'OOAIOOOO1 X'OOAIOOOE1

HIGH-CCHH

TRACKS

15

UWIN.SCHULUNG.VSAM. INDEX

INDEX ---

UCAT.T800

IN-CAT HISTORY

OWNER-IDENT

CREATION

RELEASE

EXPIRATION

(NULL) 2 PROTECTION-PSWD (NULL)

1990.240 0000.000 (NO)

RACF

ASSOCIATIONS CLUSTER--UWIN.SCHULUNG.VSAM ATTRIBUTES

KEYLEN RKP

5 0

AVGLRECL

0 505

MAXLRECL

SHROPTNS(1,3)

RECOVERY

BUFSPACE CI-SIZE 0 512 EXCPEXIT (NULL) 46 CI/CA UNIQUE NOERASE NOWRITECHK

NOREPLI CAT

NOIMBED

UNORDERED

NOREUSE

STATISTICS

REC-TOTAL

SPLITS-CI

REC-DELETED

SPLITS-CA

REC-INSERTED REC-UPDATED

FREESPACE-%CI FREESPACE-7.CA

REC-RETRIEVED 0

FREESPC-BYTES 23040

3 1 SYSTEM-TIMESTAMP : X'A362EF924CB5F300' EXCPS EXTENTS

SPACE-PRI SPACE-SEC

TRACK

1 1

HI-ALLOC-RBA

HI-USED-RBA

1

ENTRIES/SECT SEQ-SET-RBA

0

HI -LEVEL-RBA 0

ALLOCATION SPACE-TYPE

INDEX: LEVELS

23552 512

275

VSAM

IVOLUME VOLSER DEVTYPE VOLFLAG EXTENTS: LOW-CCHH HIGH-CCHH

DSK018 X'3010200E' PRIME

X'0007000E' X'0007000E'

PHYREC-SIZE 512

PHYRECS/TRK TRACKS/CA

46 1

HI-ALLOC-RBA HI-USED-RBA

23552 EXTENT-NUMBER

1 512 EXTENT-TYPE X'OO1

0 TRACKS 23551

LOW-RBA HIGH-RBA

Dies ist der Output eines TSO LISTCAT-Kommandos für ein VSAM KSDS-Dataset. Leider ist er am Bildschirm nicht so schön formatiert wie hier.

History Section Die Angaben unter History sind wenig interessant. Sie letzte Reorganisationsdatum des Datasets.

geben lediglich

Hinweise auf das

Attributes Section In der Attributes Section sind die

physischen Eigenschaften des Dataset niedergelegt.

Keylen und RKP steht für die Länge des Schlüssels, RKP für Relative Key Position, gibt also die Position des Schlüssels an, wobei bei 0 zu zählen begonnen wird. Bei ESDS- und RRDSDatasets ist dieser Wert 0.

Keylen

AVGLRECL und MAXLRECL Im Datenteil ist hier die

Länge der Records, wie sie im DEFINE CLUSTER-Kommando angegeben wurde, abgelegt. Im Indexteil steht die von VSAM ermittelte Länge, wobei MAXLRECL die Größe der CISIZE 7 Byte ist. Der AVGLRECL für den Indexteil steht -

immer auf 0. BUFSPACE

Der BUFSPACE-Wert zeigt entweder den im DEFINE CLUSTER codierten Wert oder den Default, den VSAM benutzt. In unserem Fall ist der Wert 45.568. Dies ist ausreichend, um 2 Kontrollintervalle des Datenteils (2 x 22.528 Byte) und ein Kontrollintervall des Indexteils (512 Byte) aufzunehmen.

MVS/ESA JCL

276 CISIZE

Die Angabe unter CISIZE entspricht entweder dem VSAM korrigierten Wert, wenn: 1. eine

eingegebenen Wert oder aber dem von

ungültige Kontrollintervallgröße angegeben wurde oder

2. die Kontrollintervallgröße des Indexteils Area aufzunehmen.

zu

klein ist,

um

alle Schlüssel einer Control

CI/CA Hier wird die Anzahl der Kontrollintervalle in einer Control Area angegeben. Dieser Wert kann sich bei Benutzung des IMBED-Parameters ändern. Wird der IMBED-Parameter benutzt, so wird auf dem ersten Track des Datenteils der Sequence Set Record gespeichert und so oft wie möglich wiederholt. In diesem Fall steht das erste Track für den Datenteil nicht mehr zur Verfügung. Der CI/CA Wert für den Datenteil wird von VSAM

entsprechend angepaßt. Statistics Section

In der Statistics Section werden Laden des Clusters erfolgt sind.

Angaben über die Aktivitäten geliefert, die seit dem letzten

Records Im Abschnitt Records der Statistics Section werden wichtige Hinweise auf die Art und Weise gegeben, in der auf das Dataset zugegriffen wird. Bei KSDS-Datasets ist besonders darauf zu achten, wie viele Records eingefügt werden. Einfügeaktivität ist immer I/Ointensiv und kann zu Splits von CIs und CAs führen.

Splits Diese Werte sollte man immer genau im Auge behalten. Werden sie hoch, so sollte das Dataset reorganisiert werden. Das gilt besonders bei einem hohen Anteil von CA-Splits, die eine enorme I/O-Aktivität besitzen. Cl-Splits sind ebenfalls unschön, besonders bei sequentieller Verarbeitung, allerdings längst nicht so I/O-intensiv wie CA-Splits. Sind die Split-Raten eines VSAM-Datasets abends wieder hoch, obwohl sie erst am selben Tag reorganisiert wurden, so sollte der Freespace überprüft werden.

Freespace Die Werte für FREESPACE-%CI und FREESPACE-%CA sind DEFINE CLUSTER angegeben wurden.

dieselben, die beim

Mit FREESPC-BYTES wird die Summe des freien Platzes in Bytes in völlig unbelegten Kontrollintervallen der Komponente angegeben. Freier Platz in teilweise belegten CIs ist hierbei nicht enthalten.

VSAM

277

EXCPS Die Abkürzung EXCPS steht für EXecuted Channel Programs und gibt Hinweise auf die Zahl der physischen I/Os. Beim Tunen von VSAM-Datasets ist die Beobachtung dieses Wertes von großer Bedeutung.

EXTENTS Unter EXTENTS ist die Zahl der Primär- und Sekundärextents

zusammengefaßt.

Für den

Fall, daß der zusammenhängende Platz auf der Platte nicht ausreicht, kann jeder Request

für eine Primär- oder Sekundärallokation mit maximal fünf Teilallokationen befriedigt werden. Auf diese Weise kann aber das Dataset sehr stark fragmentiert werden. Insbesondere bei sequentieller Verarbeitung von VSAM-Datasets kann sich dies sehr nachteilig auswirken, da die Zahl der physischen I/Os erhöht wird.

Allocation Section Im Abschnitt Allocation Section finden sich Platten das Dataset liegt.

Informationen, die angeben, auf welchen

SPACE TYPE

Hier wird mitgeteilt, mit welcher Einheit der Platz allokiert wurde. Dies ist meist, aber nicht notwendigerweise, die Einheit, die beim DEFINE CLUSTER verwendet wurde. SPACE-PRI und SPACE-SEC

Hier wird die Zahl der Primär- und Sekundärallokationen wiedergegeben. Wenn bei SPACE-TYPE nicht CYLINDER angegeben wurde, so werden die Angaben unter SPACEPRI und SPACE-SEC von VSAM zur Berechnung der Größe der Control Area herangezogen. Ergibt sich dabei, daß der kleinere der beiden Werte mehr als ein Cylinder auf der Platte einnimmt, so wird ein Cylinder als Größe der CA festgelegt, andernfalls der kleinere Wert in Tracks. In der Regel ist es günstiger, die Allokation in Cylindern durchzuführen. HI-ALLOC-RBA und HI-USED-RBA Dieser Wert

gibt die Highest ALLOCated Relative Byte Address bzw. die HIghest-Used Relative Byte Address an. Für die Datenkomponente eines KSDS oder RRDS-Dataset ist HI-USED-RBA immer an der Grenze einer Control Area. Mit Hilfe dieser Angabe läßt sich die Zahl der benutzten Control Areas Daten gespeichert sind.

ermitteln, in denen

VOLUME Section In der VOLUME Section werden die RBAs der einzelnen Extents wiedergegeben.

MVS/ESA JCL

278

VOLSER, DEVTYPE und VOLFLAG Für jedes VOLUME, auf dem der gesamte oder Teile des Clusters liegen, gibt

es einen VOLUMES Abschnitt. Dort ist die Vol-Ser-Nummer festgehalten ebenso wie der DeviceType. Bei großen Datasets kann es sinnvoll sein, Daten- und Indexkomponente auf unterschiedlichen Volumes anzulegen. DEVTYPE ist eine Codierung für den Plattentyp. X'30T0200E' steht für die IBM 3380 Modelle BE4, AE4, A04, AA4 und B04, X'3010200F' steht für eine 3390.

Bei VOLFLAG sind drei Angaben möglich: PRIME, OVERFLOW und CANDIDATE. Die Angabe PRIME-Volume bedeutet, daß das Volume unter Vol-Ser-Nummer das erste Volume ist, auf dem die Komponente liegt. OVERFLOW ist ein Volume, auf dem Extents liegen und CANDIDATE ist ein Volume, das zwar noch nicht belegt ist, das aber für eine Erweiterung zur Verfügung steht.

PHYREC-SIZE, PHYRECS/TRK und TRACKS/CA PHYREC-SIZE ist die physische Record-Länge, die VSAM beim Schreiben von Daten benutzt. PHYRECS/TRK ist die Anzahl der physischen Records, die auf eine Spur der Platte passen. TRACKS/CA gibt die physische Größe einer CA in Tracks an. In unserem Beispiel ist sie 15 für den Datenteil und 1 für den Indexteil. EXTENT-NUMBER und EXTENT-TYPE

Extent-Number gibt die Zahl der Extents auf dem Volume für die Zahl sollte immer klein sein.

Komponente

an.

Diese

Die Angabe Extent-Type ist nur interessant, wenn EXTENT-TYPE X'00' angegeben ist. Die dort angegebene HI-USED-RBA ist bei der Berechnung der Index Set und Sequence Set Records zu verwenden. HI-ALLOC-RBA und HI-USED-RBA

Diese Angaben beziehen sich auf das Allokation genannten.

VSAM-Datasets

recovern

-

angegebene Volume,

im

Gegensatz

zu

den unter

VERIFY

Besonders in Testumgebungen kann es vorkommen, daß Programme abbrechen und VSAM-Datasets nicht ordnungsgemäß geschlossen werden. Häufiger Grund ist z.B. der Absturz eines CICS-Systems. In diesem Fall kann das Feld High-Used RBA nicht mehr upgedated werden. Bei einem folgenden OPEN sind dann die Records, die vor dem Absturz ans Ende eines VSAM-Datasets geschrieben wurden, nicht mehr verfügbar. Das VERIFY Kommando kann diese Situation beheben.

Syntax:

VERIFY

-

FILE(ddname) | DATASET(Eintrag-Name)

VSAM

279

Wenn Sie bei Datasets, die in On-Line-Umgebungen eingebunden sind, vor dem Beginn der Batch-Verarbeitung keinen expliziten VERIFY durchführen, so kann es passieren, daß MVS einen impliziten VERIFY durchführt. Dabei kann beim OPEN ein File Status von 97 zurückgegeben werden. Dies ist aber kein Zeichen für einen Fehler. Wenn Sie VSAM-Datasets, die in On-Line Systeme eingebunden sind, im Batch verarbeiten wollen, so setzen Sie vor der Verarbeitung einen Step, der einen IDCAMS VERIFY macht. Dies vermeidet die o.a. Situation. Im folgenden Beispiel läuft ein VERIFY über zwei VSAM-Datasets: UWIN.SCHULUNG.IDCAMS(VER01)

EDIT -

COMMAND ******

01.05 -

.

SCROLL

===> *****************************

TOP OF DATA

===>

PAGE

*****************************

000001 //UWIN217C JOB (UWIN.ABTDG02),1M.WINTER 1,NOTIFY=UWIN, 000002 // CLASS=T,MSGCLASS=Y 000003 //*************************************************************** 000004 //* 000005 //* IDCAMS ZUM VERIFY 000006 //* 000007 //*************************************************************** 000008 //PRINT EXEC PGM=IDCAMS 000009 //SYSPRINT DD SYS0UT=* 000010 //V1 DD DSN=UWIN.TEST.VSAM.KSDS.MASTER,DISP=SHR 000011 //V2 DD DSN=UWIN.TEST.VSAM.KSDS.TESTDAT,DISP=SHR DD * 000012 //SYSIN VERFIFY FILE(V1) 000013 VERFIFY FILECV2) 000014 *******************************

BOTTOM OF DATA

*******************************

JCL für existierende VSAM-Datasets Um VSAM-Datasets ansprechen zu können, reicht die Angabe des DSN- und des DISPParameters in der DD-Anweisung aus. Über den Katalogeintrag erhält MVS die Information darüber, daß es sich um ein VSAM-Dataset handelt und welcher Typ von VSAM-Dataset angesprochen wird. Der DlSP-Parameter kann, sofern SMS bei Ihnen nicht aktiviert ist, sinnvollerweise nur auf SHR oder OLD gesetzt werden. Andere Angaben sind zwar zulässig, werden aber ignoriert. Dies gilt aber nicht, wenn SMS aktiv ist.

Der AMP-Parameter in der

DD-Anweisung

Der AMP (Access Method Parameter) ist für VSAM-Datasets das, was der DCB (Data Control Block) für nicht-VSAM-Datasets ist. Im Normalfall braucht er nicht verwendet werden, mit Ausnahme einiger spezieller Situationen, auf die jetzt eingegangen wird.

MVS/ESA JCL

280

Syntax:

AMP='([AMORG][,BUFND=n][,BUFNI=n])' Will man ein VSAM-Dataset auf DUMMY setzen, sein Vorhandensein also nur simulieren, so kann logischerweise kein Katalogeintrag vorhanden sein, dem MVS die notwendigen Informationen entnehmen könnte. Daher muß:

//VSAMFILE

DD

DUMMY,AMP='AMORG'

Der AMP-Parameter teilt MVS

mit, daß es sich bei dem Dataset um ein VSAM-Dataset handelt. Bei einem Lesezugriff wird die End-of-File Bedingung zurückgegeben. Schreibzugriffe werden ignoriert. Mit Hilfe der BUFND (BUFfer Number Data) und des BUFNI (BUFfer Number Index) läßt sich die Performance des Programms beim direkten Lesen beeinflussen. Der DefaultWert für den Datenbuffer ist 2, der für den Indexbuffer ist 1. Erfolgt nun ein Zugriff auf einen Record, dessen Daten nicht im Buffer stehen, so muß dieser erst geladen werden. Steht auch der Indexrecord nicht im Buffer, so muß auch dieser geladen werden. Beide Vorgänge kosten Zeit. Nun könnte man durch eine entsprechend große Zahl von Buffern erreichen, daß Daten- und Indexkomponente fast vollständig in den Buffer geladen werden, doch dazu reicht seine Kapazität nicht aus. Sinnvoll ist in jedem Fall, beim direkten Lesen soviele Indexbuffer zu belegen, wie der Index Levels (Ebenen) hat (Angabe im LISTCAT). Für das

sequentielle Lesen empfiehlt es sich, die Zahl (Standardmäßig werden nur 2 zur Verfügung gestellt).

der Datenbuffer zu erhöhen Die Erhöhung der Zahl der Datenbuffer kann den Nachteil kleiner Daten-CI-Größen bei sequentieller Verarbeitung vermindern. Im folgenden Beispiel werden für das Dataset acht Index- und drei Datenbuffer allokiert:

//VSAMFILE DD DSN=UWIN.VSAM.KSDS.TESTFILE, DISP=SHR, // AMP='(BUFNI=8,BUFND=3)' // VSAM-Datasets drucken mit dem PRINT-Kommando Mit Hilfe des PRINT-Kommandos läßt sich der Inhalt von VSAM- und nicht-VSAMDatasets ausgeben. Dabei kann das Ausgabeformat gewählt werden, ebenso kann Anfang und Ende des Drucks bestimmt werden.

281

VMM

Syntax:

PRINT

-

INFILE(ddname) | INDATASET(Elntrag-Name) CHARACTER

|

HEX

|

DUMP

-

-

FROMKEY(lowkey) | FROMNUMBER(lownumber) | FROMADDRESS(lowaddress) | SKIP(zahl) -

TOKEY(highkey) | TONUMBER(highnumber) | TOADDRESS(highaddress) | COUNT(zahl) Der Name des zu druckenden Dataset kann über INFILE dann ist die Angabe eines DDNamens erforderlich oder über INDATASET hier, muß der Datasetname eingesetzt werden, mitgeteilt werden. Die Ausgabe kann in Schriftform (CHARACTER), HexZeichen (HEX) oder beiden Formen (DUMP) erfolgen. DUMP ist der Default. -

-

-

Bei KSDS-Datasets kann eine Angabe des Start- und/oder Ende-Schlüssels mit den FROMKEY- und TOKEY-Parametern gemacht werden. Bei ESDS-Datasets heißen die entsprechenden Parameter FROMADDRESS und TOADDRESS. Bei RRDS-Datasets müssen diese Angaben mit den Parametern FROMNUMBER und TONUMBER erfolgen. Wenn diese Angaben nicht erfolgen, wird das Dataset von Anfang bis Ende gedruckt. Mit SKIP läßt sich eine bestimmte Zahl von Records am Anfang des Datasets überspringen. Mit COUNT läßt sich eine maximale Zahl der zu druckenden Records definieren. SKIP und COUNT können bei jeder VSAM-Datasetform angegeben werden. Von irgendeiner Form der Begrenzung sollte immer Gebrauch gemacht werden, da der Ausdruck eines kompletten VSAM-Datasets sehr umfangreich sein kann. Im folgenden Beispiel werden die Records 1 3 eines VSAM KSDS-Datasets gedruckt: -

MVS/ESA JCL

282 edit-uwin.schulung.idcams(prt01)

01.05

.

-

command ******

scroll

===>

*****************************

fop of data

===>

page

*****************************

000001 //uwin217c job (uwin,abtdg02),'m.winter', 000002 // class=t, 000003 // msgclass=y, 000004 // time=(,10), 000005 // notify=uwin 000006 //* notify=uwin,typrun=scan 000007 //******************************* 000008 //* 000009 //* idcams zum drucken eines vsam ksds

000010 //* 000011 //* 000012 //*

es werden nur die ersten drei records gedruckt

000013 //******************************** exec pgm=idcams 000014 //print 000015 //sysprint dd sysout=* 000016 //sysin dd * print indataset(uwin.schulung.vsam.ksds) 000017 000018 count(3)

-

000019 /* *******************************

bottom of data

********************************

Der Hexteil des nachfolgend abgebildeten Outputs ist nicht vollständig VSAM-Datasets mit Schlüssel wird der Schlüssel mit angegeben: command idcams

scroll

===>

********************************

top of data

system services

print indataset(uwin.schulung.vsam.ksds)

c0unt(3)

Die

wiedergegeben. Bei

Ausgabe wird auf der Folgeseite fortgesetzt.

===>

screen

**********************************

time: 09:25:43

06/03/92

page

1

VSAM

283

LISTING OF DATA SET -UWIN.SCHULUNG.VSAM.KSDS KEY OF RECORD

F0F0F0F0F1 F0FOF0FO F1D4E4C5 D3D3C5D9 40404040 4040C1D4 40C8C1D5 C740F4F4 40404040 40404040 40404040 40404000 0002076F -

000000 000020 000040

F0F0F0F0F2 KEY OF RECORD F0F0F0F0 F2E2C3C8 D5C5C9C4 C5D94040 000000

*00001MUELLER * AM HANG 44 *

*

SABINE

5000KOELN

* *

_?

-

000020 000040

4040D6C2 C5D9E6C5 C740F740 40404040 C7404040 40404040 40404000 0003801F

*00002SCHNEIDER * OBERWEG 7 *G

WERNER

*00003SIELDER

NORBERT

*

2001 HAMBURG

_

KEY OF RECORD

F0F0F0F0F3 FOF0F0FO F3E2C9C5 D3C4C5D9 40404040 4040E6C1 D3C4C7C1 E2E2C540 F2F14040 40404040 40404040 40404000 0004721F -

000000 000020 000040

*******************************

*

WALDGASSE 21

1000BERLIN*

*

*

.

BOTTOM OF DATA

*

********************************

VSAM-Datasets löschen mit IDCAMS DELETE Mit dem

DELETE-Kommando

lassen

sich

komplette VSAM-Datasets,

VSAM-

Komponenten wie DATA, INDEX, Pfade und Alternativindices löschen. Auch die Basiseinträge von Generation Data Groups (GDGs) lassen sich mit IDCAMS löschen. Die folgende Übersicht listet die wichtigsten Parameter des DELETE-Kommandos auf: Syntax: DELETE

-

Eintrag-Typ Katalogeintrag

-

PURGE I NOPURGE ERASE I NOERASE

-

Als Eintragtyp können die gleichen Parameter verwendet werden, die beim LISTCAT Kommando aufgezählt wurden. Beim Katalogeintrag können einzelne Level durch '*' ersetzt werden. Diese Option ist aber sehr gefährlich, weil man unter Umständen mehr Datasets löscht als beabsichtigt. Das DELETE-Kommando löscht das Dataset nicht bei VSAM-Datasets lediglich den Katalogeintrag.

physisch von der Platte,

sondern löscht

MVS/ESA JCL

284

Wenn der DELETE normal durchläuft, so wird ein Return Code 0 zurückgegeben. Ein Return Code von 8 deutet meist darauf hin, daß der entsprechende Katalogeintrag nicht existierte, das Dataset also schon gelöscht war. RC 8 ist meist harmlos. =

PURGE -NOPURGE Sollen Datasets gelöscht werden, deren Schutzfrist noch nicht durch die Angabe des PURGE-Parameters erzwungen werden.

abgelaufen ist,

so

kann dies

ERASE NOERASE -

Der normale DELETE löscht lediglich den Katalogeintrag des VSAM-Datasets. Der durch das Dataset auf der Platte eingenommene Platz wird wieder zur Benutzung freigegeben. Die Daten werden aber nicht überschrieben. Sie stehen nach wie vor auf der Platte und können zufällig oder aber durch die Benutzung besonderer Utilities wieder zugänglich gemacht werden. Für wichtige, z.B. personenbezogene Daten ist dieser Zustand unbefriedigend. Wenn man sicher gehen will, daß sensible Daten auf jeden Fall gelöscht werden sollen, so kann durch die Angabe des ERASE-Parameter bewirkt werden, daß die Daten mit Low-Values (Hex '00') überschrieben werden. Man sollte jedoch bedenken, daß dies sehr zeitaufwendig sein kann.

Sofern das VSAM-Dataset schon mit ERASE definiert wurde, erfolgt eine Überschreibung auch dann, wenn beim Löschen der ERASE-Parameter nicht gesetzt wird. Wer auf Nummer Sicher gehen will, der sollte die ERASE-Option beim DELETE setzen, sofern der Datenschutz dies verlangt. IDCAMS DELETE Im

-

folgenden Beispiel

ist, gelöscht.

Beispiel wird ein VSAM-Dataset, dessen Schutzfrist noch nicht abgelaufen enthält, werden die Daten mit binären Nullen

Da das Dataset sensitive Daten

überschrieben:

285

VSAM

edit command

-

uwin.schulung.idcamscdel01)

01.05

.

-

scroll

===>

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010

//uwin217c job (uuin,abtdg02),1m.winter1,notify=uwin, class=t,msgclass=y // //*************************************************************** //* idcams zum loeschen vsam-datasets //* //* //********************************

yep of data

page

*****************************

exec pgm=idcams //delete //sysprint dd sysout=* dd * //sysin 000011 indatasekuwin.schulung.vsam.ksds) -

000012 000013

purge

000014

cluster

erase

*******************************

bottom of data

********************************

Der SYSPRINT eines Löschens einer normalen KSDS

(ohne AIX) sieht folgendermaßen

aus: ********************************

idcams

top of data

**********************************

system services

time: 9:47:16

delete -

uwin.schulung.vsam.ksds purge -

erase -

cluster

idc0550i entry (d) uwin.schulung.vsam.ksds.data deleted idc0550i entry (i) uwin.schulung.vsam.ksds.index deleted idc0550i entry (c) uwin.schulung.vsam.ksds deleted idc0001i function

completed,

highest condition code was 0

idc0002i idcams processing complete. maximum condition code was 0 *******************************

Es erscheinen

bottom of data

********************************

Einzelmeldungen für die Daten-, die Indexkomponente und den Cluster.

MVS/ESA JCL

286

Sollte ein Löschen wider Erwarten nicht erfolgreich sein, dann prüfen Sie mit Hilfe des Kommandos LISTCAT die Komponente, die nicht gelöscht werden konnte. Achten Sie dabei auf mögliche Verknüpfungen, die im Feld ASSOCIATIONS aufgelistet werden. Möglicherweise ist die Komponente mit einem falschen Clustemamen verbunden. Dies kann z.B. dann passieren, wenn man sich beim DEFINE CLUSTER verschreibt. Sofern dieser Fall eingetreten ist, machen Sie einen DELETE auf den falsch angegebenen CLUSTER Namen. Sofern zum Cluster auch ein AIX gehört, wird der AIX und alle zugehörigen Komponenten (auch der Pfad) gelöscht. Die Meldung ist dementsprechend umfangreich. An den in Klammern gesetzten Buchstaben wird erkennbar, welche Komponente gelöscht wurden. ********************************

idcams

tqp Qp data

**********************************

system services

time:09:45:27

delete -

uwin.schulung.vsam.ksds purge -

cluster

idc0550i entry (r) uwin.schulung.vsam.ksds.aix.path deleted idc0550i entry (d) uwin.schulung.vsam.ksds.aix.data deleted idc0550i entry (i) uwin.schulung.vsam.ksds.aix.index deleted

idc0550i entry (g) uwin.schulung.vsam.ksds.aix deleted idc0550i entry (d) uwin.schulung.vsam.ksds.data deleted idc0550i entry (i) uwin.schulung.vsam.ksds.index deleted idc0550i entry (c) uwin.schulung.vsam.ksds deleted

idc0001i function completed, highest condition code was 0 idc0002i idcams processing complete. maximum condition code was 0 *******************************

bottom of data

********************************

287

VSAM

Return Codes verändern mit IDCAMS Modal-Kommandos Mit Modal-Kommandos lassen sich Return Codes, die bei der Ausführung von IDCAMSKommandos zurückgegeben werden, abfragen und ändern. Im Gegensatz zum CONDParameter auf Job- oder Step-Ebene, können einzelne Kommandos innerhalb eines Steps abgefragt werden. Es können zwei verschiedene Felder abgefragt werden: 1. 2.

LASTCC enthält den Return Code, der bei der Ausführung des letzten IDCAMSKommandos zurückgegeben wurde. MAXCC enthält den höchsten bisher zurückgegebenen Return Code.

Beim Vergleich werden: =

A= > < >=

*****************************

jop OF DATA

===>

PAGE

*****************************

000001 //UWIN217C JOB (UWIN,ABTDG02),'M.WINTER 1,NOTIFY=UWIN, 000002 // CLASS=T,MSGCLASS=Y 000003 //CLRCAT EXEC PGM=IDCAMS 000004 //SYSPRINT DD SYS0UT=* DD * 000005 //SYSIN 000006 DELETE UWIN.SCHULUNG.VSAM.KSDS CLUSTER 000007 000008 0 IF MAXCC 8 THEN SET MAXCC ******************************* BOTTOM OF DATA -

=

=

********************************

Durch das Zurücksetzen des Return Codes ist die

sichergestellt.

5.3

Ausführung

der

folgenden Steps

COBOL für VSAM-Datasets

Die folgenden Abschnitte zeigen, wie man VSAM-Datasets mit COBOL verarbeiten kann. Es werden Beispiele für die Datasetarten KSDS, ESDS und RRDS gezeigt. Um VSAMDatasets mit COBOL verarbeiten zu können, werden eine Reihe spezieller Anweisungen

benötigt.

Die SELECT

ASSIGN-Anweisung

Die SELECT ASSIGN-Anweisung für VSAM-Datasets ist wesentlich umfangreicher als die für sequentielle Datasets. Über diese Anweisung wird mitgeteilt, welche VSAMDatasetform verarbeitet werden soll, wie der Zugriff erfolgen soll, wie das Schlüsselfeld heißt (sofern es eines gibt) und wie das Feld heißt, in dem der File Status aufgenommen wird.

SELECT ASSIGN für KSDS-Datasets

SELECT VSAMFILE ASSIGN TO VSAMFILE IS INDEXED ORGANIZATION ACCESS MODE IS DYNAMIC RECORD KEY IS VSAM-KEY FILE STATUS IS FS1 FS2.

289

VSAM

ORGANIZATION IS INDEXED weist darauf hin, daß es sich um ein KSDS-Dataset handelt. Als ACCESS MODE ist bei einem KSDS-Dataset zulässig: 1. SEQUENTIAL (dies ist gleichzeitig Default). SEQUENTIAL erlaubt nur einen sequentiellen Zugriff auf das KSDS-Dataset. In diesem Fall wird nur das Sequence Set gelesen und die dort vorhandenen horizontalen Pointer benutzt. RANDOM. Wird RANDOM angegeben, so kann nur direkt gelesen werden. Sequentielle Zugriffe sind dann nicht möglich. DYNAMIC. DYNAMIC erlaubt sowohl direkte als auch sequentielle Zugriffe. Die 3. Art des Zugriffs wird im Programm gesteuert und kann gewechselt werden. RECORD KEY verweist auf das Schlüsselfeld des KSDS-Dataset. Das Feld muß später im FD-Eintrag der Satzbeschreibung des Datasets definiert werden. FILE STATUS kann aus zwei Feldern bestehen. FS1 ist ein zwei Byte langes Feld in der Working-Storage Section, in dem der normale File Status abgestellt wird. FS2 ist ein 6 Byte langes Feld, das folgendermaßen aufgebaut ist:

2.

Ol

FS2. 05 REG15-FELD 05 AIX-FELD 05 FEEDBACK-FELD

PIC PIC PIC

9(4) COMP. 9(4) COMP. 9(4) COMP.

FS2 darf nur dann abgefragt werden, wenn FS1 ungleich '00' ist. In Feld REG15-Feld von FS2 steht dann der Inhalt des Registers 15 mit den möglichen Werten 0, 8 oder 12. Sofern ein AIX im Spiel ist, wird im Feld AIX-Feld die Werte 0 5 abgestellt. Die Werte '0', '2' und '4' zeigen eine erfolgreiche Operation an, die Werte T, '3' und '5' weisen auf einen Fehler hin. Das Feld FEEDBACK enthält die meisten Informationen. Es kann vor allem dann wichtig sein, wenn der durch FS1 zurückgegebene Status sehr nebulös ist, wie z.B. bei einem FS1 von '90', der schlicht als 'Logic Error' beschrieben ist. -

Leider ist die Bedeutung des FS2 Feldes nicht sonderlich gut dokumentiert. IBM verweist die Benutzer auf das Manual: VSAM Administration: Macro Instruction Reference. Dies ist aber für die VSAM-Programmierung in Assembler gedacht, so daß die Angaben dort sich nicht auf COBOL-Programme beziehen. Vielleicht gibt es aber in Ihrer Installation Systemprogrammierer, die Ihnen eine Übersicht und die Bedeutung der Felder für COBOL erstellen können. Es bleibt zu hoffen, daß IBM diese dokumentarische Lücke so bald wie möglich schließt.

SELECT ASSIGN für ESDS-Datasets Für ESDS-Datasets sieht die SELECT-Anweisung etwas anders aus. Sie darf kein RECORD KEY-Feld enthalten, da ESDS-Datasets keinen Schlüssel besitzen:

MVS/ESA JCL

290

SELECT VSAMFILE ASSIGN TO AS-VSAMFILE IS SEQUENTIAL ORGANIZATION IS SEQUENTIAL MODE ACCESS IS FS1 FS2. FILE STATUS ORGANIZATION IS SEQUENTIAL weist darauf hin, daß es sich um ein ESDS-Dataset handelt. In der SELECT ASSIGN-Anweisung muß dem DD-Namen die Zeichenfolge ASvorangestellt werden. Während dies sonst meist nur als Kommentar betrachtet wird, ist es bei ESDS-Datasets zwingend vorgeschrieben. Bei ESDS-Datasets ist als ACCESS MODE nur SEQUENTIAL zulässig. Für FS1 und FS2

gilt das bei KSDS-Datasets Gesagte.

SELECT ASSIGN für RRDS-Datasets Für RRDS-Datasets muß die

SELECT-Anweisung wie folgt aussehen:

SELECT VSAMFILE ASSIGN TO VSAMFILE ORGANIZATION IS RELATIVE ACCESS IS RANDOM KEY RELATIVE IS VSAM-KEY FILE STATUS IS VSAM-STATUS. ORGANIZATION IS RELATIVE weist darauf handelt.

hin,

daß

es

sich

um

ein RRDS-Dataset

Als ACCESS MODE ist bei RRDS-Datasets: RANDOM, SEQUENTIAL und DYNAMIC zulässig. Die Bedeutung entspricht der bei einem KSDS. Der RELATIVE KEY wird als Feld in der WORKING-STORAGE SECTION definiert. Er ist nicht Teil der Satzbeschreibung des Datasets. Für FS1 und FS2 gilt das bei KSDS-Datasets Gesagte.

Die

FD-Anweisung

Bei der FD-Anweisung sind

folgende Punkte zu beachten:

1.

Die RECORDING MODE IS F Klausel darf nicht verwendet werden.

2.

Die BLOCK CONTAINS Klausel wird als Kommentar betrachtet. Da sie überflüssig ist, sollte man sie weglassen.

VSAM 3.

Die

291 Die LABEL RECORDS ARE Klausel muß auf jeden Fall stehen. Ob dann STANDARD oder OMITTED genommen wird, ist ohne Bedeutung.

OPEN-Anweisung

Die OPEN-Anweisung unterscheidet sich je nach Art der Zugriffe, die vorgenommen werden sollen. Die OPEN-Anweisung fur KSDS- und ESDS-Datasets ist identisch:

OPEN filename INPUT OUTPUT EXTEND 1-0 OPEN INPUT bedeutet, daß nur

Lesezugriffe mit READ erlaubt sind. einem ungeladenen (leeren) Dataset

OPEN OUTPUT muß bei zum erstmaligen Beschreiben (Laden) verwendet werden. Beachten Sie, daß, wenn Sie ein VSAM-Dataset mit REUSE definiert haben, dieses Dataset überschrieben wird. Bei einem REUSEable Dataset wird der Record Pointer auf den Anfang gesetzt und mit dem Schreiben begonnen. Evtl. vorhandene Daten werden einfach überschrieben.

Wird OPEN OUTPUT bei einem nicht-leeren Dataset verwendet, so kommt es zu einem Fehler. Ein Dataset gilt auch dann als nicht-leer, wenn alle Records durch DELETEKommandos gelöscht wurden. OPEN EXTEND bewirkt, daß neue Records an das Ende des Datasets angehängt werden sollen. Sie kann bei KSDS-Datasets nur dann verwendet werden, wenn mit dem Laden fortgefahren werden soll, die zu ladenden Records aufsteigend sortiert sind und nicht kleiner sein dürfen, als der höchste bisher geladene Record. OPEN EXTEND wird meist bei ESDS-Datasets verwendet, um neuen OUTPUT ans Ende des Datasets zuschreiben. Bei RRDS-Datasets gibt es die Option EXTEND nicht. OPEN 1-0 läßt Lese- und Schreibzugriffe zu. Diese Option wird häufig bei KSDS- und RRDS-Datasets verwendet. Bei ESDS-Datasets hat 1-0 nur dann Bedeutung, wenn ein REWRITE gemacht werden soll.

Mögliche FS1 RC

Return Codes bei OPEN:

00

Bedeutung Erfolgreiches Öffnen.

35

Dataset nicht vorhanden. Falsche oder fehlende DD-Anweisung.

37

OPEN wird vom Dataset nicht unterstützt. KSDS zu öffnen versucht.

Möglicherweise

wurde ein ESDS als

MVS/ESA JCL

292

39

File Attribut Problem. Bei KSDS

häufig

falsche

Schlüsselposition

im COBOL-

Programm. 90 91 92 93 95

KSDS wurde für OUTPUT geöffnet und ACCESS MODE ist entweder RANDOM oder DYNAMIC. Passwort-Fehler. Kann auch ein RACF-Fehler sein (keine Zugriffsrechte).

Logischer Fehler. Meist ist das zu öffnende Dataset bereits geöffnet. Ungenügender virtueller Speicher. REGION-Parameter erhöhen. Dataset, das für OUTPUT geöffnet wurde, ist nicht leer. Schlüssellänge oder -position inkonsistent Ein KSDS-Dataset wurde wie ein ESDS-Dataset eröffnet.

96 97

DD-Anweisung fehlt. Impliziter VERIFY durchgefühlt. OPEN erfolgreich.

Lesezugriffe Um ein VSAM-Dataset lesen zu können, muß eröffnet worden sein. Wenn mit FILE STATUS KEY-Bedingung nicht verwendet werden. Sofern ACCESS Ende gelesen:

mit OPEN INPUT oder OPEN 1-0 gearbeitet wird, so sollte die INVALID

es

SEQUENTIAL angegeben wurde, wird das

Dataset mit READs bis

zum

READ filename

[INTO identifier] [AT END imperative Anweisung] Sofern ACCESS MODE ist DYNAMIC angegeben wurde, kann zwischen den Zugriffen hin- und hergeschaltet werden. Um sicher zu gehen, sollte beim sequentiellen Lesen mit NEXT RECORD gearbeitet werden, beim direkten Lesen sollte vorher immer das Schlüsselfeld besetzt werden.

Beispiel für sequentielles Lesen bei ACCESS DYNAMIC: READ

filename NEXT RECORD

[INTO identifier] [AT END imperative Anweisung]

293

VSAM

Schreibzugriffe Voraussetzung für eine Schreib-Operation ist ein erfolgreiches Öffnen mit OPEN I-O oder OPEN OUTPUT.

Auch bei der WRITE-Anweisung sollte man auf die INVALID KEY-Klausel verzichten und mögliche Fehler über den FS1 abfangen. Der WRITE für ein VSAM-Dataset sieht folgendermaßen aus:

WRITE

record-name

[FROM identifier] Die REWRITE-Anweisung

entspricht weitgehend der WRITE-Anweisung:

REWRITE

record-name

[FROM identifier] Ein REWRITE ist bei einem ESDS-Dataset nur nach einem Die Record-Länge darf nicht geändert werden.

Löschen

von

vorherigen

READ

möglich.

Records

Zum Löschen eines Records kann die DELETE-Anweisung verwendet werden. Dies ist nur bei KSDS- und RRDS-Datasets möglich. Records von ESDS-Datasets können nicht

gelöscht werden. DELETE

file-name START und READ NEXT Mit Hilfe der START-Anweisung kann man mitten in einem VSAM-Dataset aufsetzen und von dort aus sequentiell weiterlesen. Zu diesem Zweck wird bei der START-Anweisung ein Schlüssel oder ein Schlüsselfragment übergeben.

START file-name [KEY IS EQUAL TO GREATER THAN NOT LESS THAN

data-name]

>

NOT
*****************************

fop OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

ID DIVISION. PROGRAM-ID. KSDSALL. ************************************************************** *

* * *

USE THIS PROGRAM TO READ, RECORDS FROM A VSAMFILE

WRITE,

REWRITE OR DELETE

* *

*

*

**************************************************************

AUTHOR. M.WINTER.

ENVIRONMENT DIVISION. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT INPFILE ASSIGN TO INPFILE FILE STATUS IS INP-STATUS. SELECT VSAMFILE ASSIGN TO VSAMFILE ORGANIZATION IS INDEXED ACCESS IS DYNAMIC RECORD KEY IS VSAM-KEY FILE STATUS IS FS1 FS2. DATA DIVISION. *_.

FILE SECTION. k_

FD

01

INPFILE RECORDING MODE F BLOCK 0 RECORDS. INP-REC. 05 INP-FLAG 05 INP-DATA.

10 10 10 10

INP-KEY INP-NAME

PIC

X(01).

PIC

9(05).

INP-VORNAME

PIC X(14). PIC X(10).

INP-REST

PIC

X(50).

Beispiel wird auf der folgenden Seite fortgesetzt.

MVS/ESA JCL

296

000035 000036 000037 000038 000039 000040 000041 000042 000043 000044 000045 000046 000047 000048 000049 000050 000051 000052 000053 000054 000055 000056 000057 000058 000059 000060 000061 000062 000063 000064 000065 000066 000067 000068 000069 000070 000071 000072

Das

FD

VSAMFILE

01

VSAM-REC.

LABEL RECORDS OMITTED.

05 05 05 05

9(05). X(15). PIC X(14). PIC X(46).

VSAM-KEY

PIC

VSAM-NAME

PIC

VSAM-VORNAME VSAM-REST

k_

WORKING-STORAGE SECTION.

01 01

01 01 01 01 01 01 01 01

FS1

PIC XX

FS2. 05 VSAM-RETCODE 05 VSAM-AIXCODE 05 VSAM-FEEDBACK INP-STATUS

PIC 9(04) COMP. PIC 9(04) COMP. PIC 9(04) COMP.

ERROR-REASON

PIC

REC-READ

PIC

REC-WRITTEN

PIC

REC-DELETED REC-STARTED REC-REWRITTEN EOF-SWITCHES. 05 END-OF-INP-SW 88 END-OF-INP

PIC

PIC

PIC PIC

VALUE '00'

X(02) X(60). 9(05) COMP-3 9(05) COMP-3 9(05) COMP-3 9(05) COMP-3 9(05) COMP-3

PIC X VALUE 'N'

VALUE

1

Y

VALUE '00' VALUE VALUE VALUE VALUE VALUE

0. 0. 0. 0. 0.

.

.

*_

PROCEDURE DIVISION. OPEN INPUT INPFILE. IF INP-STATUS NOT

=

'00'

DISPLAY 'OPEN ERROR INPFILE STATUS

=

1

INP-STATUS

MOVE 12 TO RETURN-CODE GO TO PROG-STOP. OPEN 1-0 IF FS1 NOT

VSAMFILE. =

'00'

MOVE 'OPEN ERROR VSAMFILE STATUS

PERFORM FATAL-ERROR GO TO PROG-STOP.

Beispiel wird auf der folgenden

Seite

fortgesetzt.

'

TO ERROR-REASON

VSAM

000073 000074 000075 000076 000077 000078 000079 000080 000081 000082 000083 000084 000085 000086 000087 000088 000089 000090 000091 000092 000093 000094 000095 000096 000097 000098 000099 000100 000101

Das

297 MOVE 0

TO REC-READ.

MOVE 0 MOVE 0

TO REC-WRITTEN. TO REC-STARTED.

MOVE 0 MOVE 0

TO REC-REWRITTEN TO REC-DELETED.

READ INPFILE AT END MOVE Y TO END-OF-INP-SW. PERFORM 'READ-INPFILE UNTIL END-OF-INP OR RETURN-CODE PROG-STOP. *. 1

DISPLAY 'RECORD ACTIVITY ON VSAMFILE DISPLAY

'.

DISPLAY 1 '. DISPLAY 'RECORDS READ DISPLAY 'RECORDS STARTED DISPLAY 'RECORDS WRITTEN

=

1

=

1

=

1

DISPLAY 'RECORDS REWRITTEN

=

'

DISPLAY 'RECORDS DELETED CLOSE VSAMFILE.

=

1

CLOSE INPFILE. STOP RUN. *.

READ-INPFILE

.

*.

IF INP-FLAG

=

'W'

PERFORM WRITE-VSAMREC ELSE IF INP-FLAG

=

'R1

PERFORM READ-VSAMREC ELSE

Beispiel wird auf der folgenden Seite fortgesetzt.

1

.

REC-READ. REC-STARTED. REC-WRITTEN. REC-REWRITTEN. REC-DELETED.

>

0.

MVS/ESA JCL

298

000102 000103 000104 000105 000106 000107 000108 000109 000110 000111 000112 000113 000114 000115 000116 000117 000118 000119 000120 000121 000122 000123 000124 000125 000126 000127 000128 000129 000130 000131 000132 000133 000134 000135 000136 000137 000138 000139 000140 000141 000142

Das

IF INP-FLAG

=

'S'

PERFORM START-VSAMREC ELSE

IF INP-FLAG

=

IF INP-FLAG

=

'C PERFORM REWRITE-VSAMREC ELSE 1D1 PERFORM DELETE-VSAMREC ELSE IF INP-FLAG = 'X' MOVE INP-KEY TO RETURN-CODE. READ INPFILE AT END MOVE 'Y' TO END-OF-INP-SW.

READ-INPFILE-EXIT. *. *.

WRITE-VSAMREC. *.-

PERFORM MOVE-FIELDS. WRITE VSAM-REC. = '00' ADD 1 TO REC-WRITTEN ELSE = IF FS1 '22' ' DISPLAY 'DUPLICATE KEY ON WRITE FOR INP-KEY ELSE MOVE 'WRITE ERROR VSAMFILE STATUS ' TO ERROR-REASON PERFORM FATAL-ERROR. WRITE-VSAMREC-EXIT.

IF FS1

*. *.

READ-VSAMREC. *.-

PERFORM MOVE-FIELDS. READ VSAMFILE. = IF FS1 '00' ADD 1 TO REC-READ ELSE = IF FS1 '23' DISPLAY 'READ RECORD NOT FOUND FOR ELSE

Beispiel wird auf der folgenden Seite fortgesetzt.

'

INP-KEY

VSAM

000143 000144 000145 000146 000147 000148 000149 000150 000151 000152 000153 000154 000155 000156 000157 000158 000159 000160 000161 000162 000163 000164 000165 000166 000167 000168 000169 000170 000171 000172 000173 000174 000175 000176 000177 000178 000179 000180 000181 000182 000183 000184

Das

299 HOVE

1

READ ERROR VSAMFILE STATUS

TO ERROR-REASON

1

PERFORM FATAL-ERROR.

READ-VSAMREC-EXIT. *.-. *.

START-VSAMREC. *.

PERFORM MOVE-FIELDS. START VSAMFILE KEY GREATER IF FS1

THAN VSAM-KEY.

'00' ADD 1 TO REC-STARTED PERFORM READ -VSAMFILE-NEXT =

ELSE IF FS1

=

'23'

DISPLAY 'START RECORD NOT FOUND FOR

INP-KEY

1

ELSE

MOVE 'START ERROR VSAMFILE STATUS PERFORM FATAL-ERROR.

1

TO ERROR-REASON

START-VSAMREC-EXIT. *. *--.-.

READ -VSAMFILE-NEXT. *---.-

READ VSAMFILE NEXT RECORD. IF FS1 ADD 1 ELSE

=

'00'

TO REC-READ

= IF FS1 '94' DISPLAY 'NO SEQUENTIAL READ POSSIBLE FOR

'

INP-KEY

ELSE MOVE 'READ

ERROR VSAMFILE STATUS

PERFORM FATAL-ERROR. READ-VSAMFILE-NEXT-EXIT. *. *---.

REWRITE-VSAMREC.

*. PERFORM MOVE-FIELDS. REWRITE VSAM-REC. IF FS1 ADD 1 ELSE

'00' TO REC-REWRITTEN =

Beispiel wird auf der folgenden Seite fortgesetzt.

1

TO ERROR-REASON

MVS/ESA JCL

300 000185 000186 000187 000188 000189 000190 000191 000192 000193 000194 000195 000196 000197 000198 000199 000200 000201 000202 000203 000204 000205 000206 000207 000208 000209 000210 000211 000212 000213 000214 000215 000216 000217 000218 000219 000220 000221 000222 000223 000224 000225

= IF FS1 '23' DISPLAY 'REWRITE RECORD NOT FOUND FOR

INP-KEY

ELSE MOVE 'REWRITE

ERROR VSAMFILE STATUS

'

TO ERROR-REASON

'

INP-KEY

'

TO ERROR-REASON

PERFORM FATAL-ERROR.

REWRITE-VSAMREC-EXIT.

DELETE-VSAMREC. PERFORM MOVE-FIELDS. DELETE VSAMFILE. IF FS1

'00' TO REC-DELETED =

ADD 1 ELSE IF FS1

=

'23'

DISPLAY 'DELETE RECORD NOT FOUND FOR ELSE MOVE 'DELETE ERROR VSAMFILE STATUS

=

PERFORM FATAL-ERROR. DELETE-VSAMREC-EX IT.

MOVE-FIELDS. k_

MOVE INP-KEY

TO VSAM-KEY.

MOVE INP-NAME

TO VSAM-NAME.

MOVE INP-VORNAME TO VSAM-VORNAME. MOVE INP-REST

TO VSAM-REST.

MOVE-FIELDS-EXIT.

FATAL-ERROR. DISPLAY ERROR-REASON

'

'

FS1

DISPLAY 'VSAM-RETCODE

DISPLAY DISPLAY DISPLAY MOVE 12

'VSAM-AIXCODE 'VSAM-FEEDBACK INP-REC. TO RETURN-CODE.

VSAM-RETCODE. VSAM-AIXCODE. VSAM-FEEDBACK.

FATAL-ERROR-EXIT. ****************************

Die

'

BOTTOM OF DATA

****************************

JCL, mit der das Programm läuft, ist auf dieser Seite abgebildet.

VSAM

301

EDIT

01.03

UWIN.SCHULUNG.CNTL(VSAHALL)

COMMAND ******

.

-

-

===> *****************************

yep OF DATA

COLUMNS 001 072 SCROLL ===> PAGE

*****************************

000001 //UWIN217G JOB (998,ABTDG02),1M.WINTER1,CLASS=C,NOTIFY=UWIN, 000002 // MSGCLASS=9, 000003 // TIME=(,05), 000004 // MSGLEVEL=(1,1) EXEC PGM=VSAMALL 000005 //STEP1

000006 000007 000008 000009 000010

//STEPLIB //SYSPRINT //SYSABOUT //SYSOUT //VSAMFILE

DD

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR

DD SYSOUT=* DD SYSOUT=*

DD SYSOUT=* DD DSN=UWIN.SCHULUNG.VSAM.KSDS,DISP=OLD

000011 //********************************* 000012 //* 000013 //* FOLGENDE ZEICHEN SIND IM ERSTEN BYTE VON INPFILE ZULÄSSIG 000014 //* 000015 //* R = READ 000016 //* C = REWRITE 000017 //* W WRITE DELETE 000018 //* D =

=

000019 000020 000021 000022 000023 000024 000025 000026

START //* S //* //*******************************************************

******

*************************

=

//INPFILE DD * W00040BECKER C00039BEHRENDT

WILHELM ANGELIKA

STABGASSE 3 WALMSTRASSE 45

6000 FRANKFURT 5000 KOELN

R00038

D00037 000027 S00403 BOTTOM OF DATA

****************************

Storage Management Subsystem

6

SMS

-

SMS, das gelegentlich auch als System Managed Storage bezeichnet wird, ist ein

Subsystem, das unter MVS/ESA eingesetzt wird. Die Ziele des Einsatzes sich in drei Punkten zusammenfassen:

von

SMS lassen

Anwendungsprogrammierer soll sich beim Anlegen von Platten-Datasets nicht physischen Sicht der Daten befassen müssen. (SMS hat nur sehr eingeschränkte Bedeutung für Datasets auf Kassette oder Band.) Das Anlegen von Datasets soll vereinfacht werden.

1. Der

mehr mit der 2.

3. Die Kontrolle über Plattenspeicherplatz soll vereinfacht werden.

Mit SMS kommen auf die IBM-Welt erstmals seit langer Zeit umfangreiche JCLÄnderungen zu. So gibt es allein 10 neue JCL-Parameter, die im Zusammenhang mit SMS eingeführt werden. SMS kann so eingerichtet werden, daß es entweder den gesamten oder aber einen Teil des Plattenbestandes kontrolliert. Datasets, die auf diesen Platten angelegt werden, fallen ebenfalls unter die Kontrolle von SMS. Darüber hinaus ist es möglich, SMS die Kontrolle bestimmter DSN-Gruppen zu ermöglichen. Versucht der User, ein Dataset anzulegen, deren DSN-Merkmale der Kontrolle von SMS unterstehen, so wird dieses Dataset automatisch auf einer Platte angelegt, die ebenfalls der Kontrolle von SMS untersteht. In einer gemischten Umgebung, die sowohl SMS- als auch Nicht-SMS-Datasets enthält, ist folgender Grundsatz zu beachten: SMS kontrollierte Datasets (SMS-inanaged data sets) können nur auf von SMS kontrollierten Platten (SMS-managed volumes) angelegt werden. SMS arbeitet mit einem Konzept von Speicherklasse (Storage Class), Datenklasse (Data Class) und Managementklasse (Management Class). Die Angabe einer Speicherklasse (STORCLAS) bewirkt, daß ein Dataset der Kontrolle von SMS unterstellt wird (unabhängig vom DSN). Mit der Angabe der Datenklasse (DATACLAS) lassen sich standardisierte Parameter z.B. für Record-Format, logische Record-Länge, Space und einige weitere übernehmen. Die Angabe einer Managementklasse (MGMTCLAS) dient der Übernahme von Defaults für das Migrieren und Sichern von Datasets. In der Praxis wird wahrscheinlich

einer ähnlichen

Weise, wie

es

häufigsten mit STORCLAS gearbeitet und zwar in mit dem Parameter UNIT=groupname geschieht. Die

am

jetzt

MVS/ESA JCL

304

komplette Übernahme einer Datenklasse wird Managementklasse wird man wahrscheinlich explizite Angabe machen zu müssen.

nur

eingeschränkt möglich sein,

mit Standardwerten

bei der

arbeiten, ohne eine

Die verschiedenen Klassen können unter SMS explizit zugewiesen werden. Es ist jedoch auch möglich, sog. Automated Class Selection Routinen (ACS) zu definieren. Sie erkennen ein neu anzulegendes Plattendataset anhand bestimmter DSN-Merkmale und sorgen für eine automatische Zuweisung der jeweiligen Klassen. Erkundigen Sie sich, ob und inwiefern bei Ihnen mit ACS gearbeitet wird. Eine weitere Neuheit, die SMS bietet, ist die Möglichkeit, VSAM-Datasets mit normaler JCL anzulegen. Bisher war dies nur mit IDCAMS möglich. Es ist allerdings die Frage, ob die so angelegten standardisierten VSAM-Datasets den besonderen Anforderungen der verschiedenen Anwendungen gewachsen sind. Unter SMS wird es mit der Version 4 von MVS/ESA eine neue Form des Partitioned Data Set geben, nämlich ein Partitioned Data Set Extended (PDSE). Es unterscheidet sich von den normalen PDS vor allem durch die interne Organisation. PDSE benötigen keinen Compress mehr, d.h. beim Updaten eines Members wird der zur Verfügung stehende Platz neu organisiert. Dies bedeutet aber auch, daß die bisher zur Verfugung stehenden Möglichkeiten, alte Memberversionen wieder verfügbar zu machen, bei einem PDSE nicht mehr existieren. Bei der Installation von SMS sind zwei Zustände zu unterscheiden: 1. SMS installiert und nicht aktiviert. 2. SMS installiert und aktiviert.

Bereits im nicht aktivierten Zustand werden.

6.1

SMS

bringt

SMS Vorteile, die hier zunächst

dargestellt

installiert, aber nicht aktiviert

Sofern bei Ihnen SMS bereits installiert ist, können Sie eine Reihe von Vorteilen nutzen, die SMS bietet. Dies gilt auch dann, wenn Migrationsprodukte wie GO-SMS installiert sind.

Wegfall der Blocksize-Angaben Die Angabe einer Blocksize beim Anlegen eines Datasets ist nicht mehr erforderlich. SMS sucht sich selbständig eine optimale Blockgröße für den jeweiligen Datenträger. Dies gilt sowohl für Datasets auf Platte wie auch auf Kassette oder Band. Voraussetzung dafür ist, daß das Programm, das das Dataset anlegt, einen OPEN absetzt. Geschieht dies nicht, z.B. bei dem Utility-Programm IEFBR14, so wird eine BLOCKSIZE von 0 angelegt und das Dataset wird unbenutzbar. Diese Änderung ist auch unter MVS/XA verfügbar. Sie wurde von IBM 1989 im Zusammenhang mit der Auslieferung der Magnetplatten vom Typ 3390 erstellt. Dadurch ist

SMS -

305

Storage Management Subsystem

möglich, gemischte Plattengruppen von 3380er und 3390er Platten über einen UNITanzusprechen und dennoch für eine optimale Blocksize zu sorgen, obwohl die Spurgröße von 3380 und 3390er Platten unterschiedlich ist. Sofern bei Ihnen SMS installiert ist und noch JCL mit BLKSIZE-Angaben im Einsatz ist, so prüfen Sie nach, ob darauf nicht verzichtet werden sollte. Dies gilt ganz besonders dann, Parametern unter bei Ihnen den wenn UNIT=gruppenname oder STORCLAS=speicherklasse Plattengruppen angesprochen werden, die aus 3380er und es

Namen

3390er Platten bestehen.

In dieser Situation ist es völlig unmöglich, eine optimale BLKSIZE selber anzugeben, da Sie nicht wissen können, auf welchem Typ von Platte Ihr Dataset angelegt wird.

Zwei abschreckende Beispiele sollen zeigen, was versuchen, eine BLKSIZE selber zu spezifizieren. edit-uwin.schulung.sms(blkszi)

01.02

passieren kann,

.

-

command ******

wenn

Sie trotzdem

columns 001 072 ===> page

scroll

===> *****************************

yop op data

****************************

//uwin217c job (uwin,abtdg02),'m.winter1,not ify=uwin, // class=t,msgclass=y //*************************************************************** //* anlegen eines sequentiellen dataset mit fester blksize 000005 //* 000006 //* 000007 //*************************************************************** 000001 000002 000003 000004

000008 //define exec pgm=idcams 000009 //sysprint dd sysout=* 000010 //sysin dd * 000011 delete uwin.schulung.output.seq1 000012 if maxcc = 8 then set maxcc 0 000013 //step1 exec pgm=p808401 =

000014 //steplib 000015 //sysout 000016 //sysabout 000017 //sysdbout 000018 //0ut1 000019 // 000020 // 000021 // 000022 // ******

dd

dsn=p808.loadlib,disp=shr

dd sysout=*

dd sysout=* dd sysout=* dd

dsn=uwin.schulung.output.seq1,

disp=(new,catlg),

dcb=(recfm=fb,lrecl=80,blksize=23440), unit=dskprm, space=(cyl,(80,8),rlse)

***************************

bottom of data

**************************

Dies ist eine JCL mit einer BLKSIZE, die für eine Platte des aber passiert, wenn Ihr Dataset auf einer 3390 angelegt wird:

Typs 3380 optimiert ist.

Was

MVS/ESA JCL

306

zwei Blöcke zu 23440 Lücke der 3390

46880 666 47542

Byte

Byte Byte Byte

ergeben: Spurgröße der 3390 beträgt aber 56664 Byte. Somit bleiben 9118 Byte ungenutzt. Dies entspricht 16% des Spur- und damit Plattenplatzes.

Die

edit-uwin. schulung. sms (blksz2)

01.02

.

-

command

===>

columns 001 072 scroll ===> page

****************************

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009

//uwin217c job (uwin,abtdg02),'m.winter1,n0tify=uwin, // class=t,msgclass=y //*************************************************************** //* anlegen eines sequentiellen dataset mit fester blksize //* //* //***************************************************************

000010 000011 000012 000013 000014 000015 000016 000017

//define exec pgm=idcams //sysprint dd sysout=* //sysin dd * delete uwin.schulung.output.seq1 if maxcc = 8 then set maxcc = 0 exec pgm=p808401 //step1 dd //steplib dsn=p808.loadlib,disp=shr dd sys0ut=* //sysout //sysabout dd sysout=* //sysdbout dd sysout=*

000018 //out1 000019 // 000020 // 000021 // 000022 // ******

fop of data

dd

dsn=uwin.schulung.output.seq1,

disp=(new,catlg),

dcb=(recfm=fb,lrecl=80,blksize=27920), unit=dskprm, space=(cyl,(80,8),rlse)

***************************

bottom of data

**************************

Dies ist eine JCL mit einer BLKSIZE, die für eine Platte des aber passiert, wenn Ihr Dataset auf einer 3380 angelegt wird: ein Block zu 27920 Byte 27920 Byte auf die

Typs 3390 optimiert ist.

Was

Spur einer 3380 paßt nur ein Block mit der Größe 27920 Byte ! Die Spurgröße der 3380 beträgt aber 47476 Byte. Somit bleiben 19556 Byte ungenutzt. Dies entspricht 41% des Spur- und damit Plattenplatzes. Es ist daher besser, auf die Angabe der BLKSIZE zu verzichten. Durch den Wegfall der BLKSIZE-Angaben wird der Wechsel zwischen verschiedenen Datenträgern erleichtert. Dies wird an folgendem Beispiel demonstriert.

307

Storage Management Subsystem

SMS -

01.02 .-.columns 001 072

edit-uwin schulung .sms (de fseq) command ===> .

******

-

scroll

*****************************

top of data

===>

page

*****************************

000001 //uwin217c job (uwin,abtdg02),'m.winter1,not ify=uwin, 000002 // class=t,msgclass=y 000003

//********************************

000004 //* 000005 //* 000006 //* 000007 //*

anlegen eines dataset auf platte oder kassette mit variabler blksize

000008 000009 000010 000011 000012 000013 000014 000015 000016

//***************************************************************

000019 000020 000021 000022 000023 000024

// // //*

******

***************************

//define exec pgm=idcams //sysprint dd sysout=* //sysin dd * delete uwin.schulung.output.seq1 if maxcc = 8 then set maxcc = 0

//step1

exec pgm=p808401 //steplib dd dsn=p808.loadlib,disp=shr dd sysout=* //sysout 000017 //sysabout dd sysout=* 000018 //out1 dd dsn=uwin.schulung.output.seq1,

disp=(new,catlg),

recfm=fb,lrecl=80, unit=dskprm,

//* // //

space=(cyl,(80,8),rlse) unit=cass, expdt=99000 bottom of data

**************************

Je nachdem, ob die Zeilen 21 und 22 oder 23 und 24 Kommentar sind oder nicht, wird das Dataset entweder auf Platte oder auf Kassette angelegt. Die optimale BLKSIZE wird

automatisch errechnet.

Konkatenieren

von

Kassettendatasets

Beim Konkatenieren von Datasets, die auf Band oder Kassette stehen, braucht jetzt nicht mehr auf die Blocksize geachtet werden. Bisher mußte das Dataset mit der größten Blocksize zuerst genannt werden bzw. die größte vorkommende Blocksize beim ersten Dataset angegeben werden:

//CASSIN // // //

DD

DSN=UWIN.CASS1,DISP=0LD,

DCB=BLKSIZE=32760 DD DD

DSN=UWIN.CASS2,DISP=OLD DSN=UWIN.CASS3,DISP=OLD

MVS/ESA JCL

308

Diese Form der Angabe mußte gemacht werden, wenn die Blocksize von CASS1 kleiner war als die von CASS2 oder CASS3. Mit SMS spielt die Blocksize der einzelnen Datasets und ihre Reihenfolge in der Konkatenation keine Rolle mehr. Bei Plattendatasets mußte seit der Einführung von DFP (Data Facility Product) 2.3 auf die Blocksize von konkatenierten Datasets nicht mehr geachtet werden.

Konkatenieren

von

ungleichen Datenträgern

Bisher konnten Datasets auf ungleichen Datenträgern nicht konkateniert werden (Ausnahme: Datasets, die unter SORTIN beim SYNCSORT oder DFSORT angesprochen werden). Unter SMS gibt es diese Beschränkung nicht mehr.

//INPUT // Ohne SMS käme

DSN=UWIN.CASSl,DISP=OLD DD DSN=UWIN.DISK1,DISP=SHR DD

es zu

einem S637-0C ABEND.

Ändern des LIMITS eines Generationdatasets Mit SMS ist das Ändern eines LIMITs eines Basiseintrags eines Generationdatasets (GDG Generation Data Group) eine einfache Sache geworden. Dazu kann jetzt das ALTERKommando von IDCAMS benutzt. -

EDIT-UWIN.SCHULUNG. IDCLOES(GDGALT) ******

.

SCROLL

===> *****************************

COLUMNS 001 072

01.02 -

COMMAND

fop OF DATA

===>

PAGE

*****************************

000001 //UUIN217A JOB (998,ABTDG02),'M.WINTER',CLASS=C,NOTIFY=UWIN, 000002 // MSGCLASS=9, 000003 // TIME=(,05), 000004 // MSGLEVEL=(1,1) 000005 //* MSGLEVEL=(1,1),TYPRUN=SCAN 000006 //CRGDG EXEC PGM=IDCAMS 000007 //SYSPRINT DD SYS0UT=* 000008 //SYSIN DD * 000009 ALTER UWIN.SCHULUNG.GDG LIMIT(4) ****** **************************** BOTTOM OF DATA ***************************

Im

vorhergehenden Beispiel wurde das LIMIT einer GDG von 5 auf 4 herabgesetzt: Der folgende SYSPRINT liefert das Ergebnis der Ausführung des ALTER-Kommandos. Das älteste zur Generation gehörende Dataset mit dem absoluten DSN UWIN.SCHULUNG.GDG.G0002V00 wurde aus der Generation entfernt und gelöscht. Das Entfernen aus der Generation wird mit der Meldung HAS BEEN ROLLED OFF gemeldet.

309

Storage Management Subsystem

SMS -

********************************

IDCAMS

fop OF DATA

**********************************

TIME: 08:46:28

SYSTEM SERVICES

ALTER UWIN.SCHULUNG.GDG LIMIT(4) IDC0196I UWIN.SCHULUNG.GDG.G0002V00 HAS BEEN ROLLED OFF AND DELETED

IDC0531I ENTRY UWIN.SCHULUNG.GDG ALTERED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 BOTTOM OF DATA ********************************

*******************************

Bisher mußten, nämlich: 1.

um

den

gleichen Zweck

zu

erreichen, vier Schritte ausgeführt werden,

Entkatalogisieren aller Generationen. Basiseintrages. Neudefinieren des GDG Basiseintrages mit dem neuen Limit. Rekatalogisieren der Generationen.

2. Löschen des GDG 3.

4.

Kilobytes und Megabytes beim Anlegen eines VSAM-Dataset Mit SMS kann beim Anlegen von VSAM-Datasets mit IDCAMS Platz mit KILOBYTES oder MEGABYTES unabhängig von der Art der Platte angefordert werden. Abgesehen davon, daß es dann egal ist, ob auf einer 3380 oder 3390 angelegt wird, ist diese Angabe besser umsetzbar im Hinblick auf die zu erwartende Datasetgröße (Die Angabe CYLINDER oder TRACKS mußte erst bezogen auf den Datenträger umgerechnet werden).

MVS/ESA JCL

310 01.02

edit-uwin.schulung.idcloes(defksds)

.

-

command

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010 000011

//uwin217a // // //

//*

*****************************

job (998,abtdg02),1m.winter1,class=c,notify=uwin, msgclass=9, time=(,05), msglevel=(1,1) msglevel=(1,1),typrun=scan

//defksds exec pgm=idcams //sysprint dd sysout=* //sysin dd * delete -

uwin.schulung.vsam.ksds cluster define cluster (name(uwin.schulung.vsam.ksds) indexed

000012 000013 000014

-

recordsize(80 80) keys(5 0) freespaceo0 10)

000015 000016 000017 000018 000019 000020 000021 000022 000023 000024 000025 *******

top of data

columns 001 072 scroll ===> page

volumes(prm001 prm002) megabytes(5 1) shareoptions (2 3)

-

replicate imbed ) data (name(uwin.schulung.vsam.ksds.data) -

cisz(4096)) -

index (name(uwin.schulung.vsam.ksds.index) -

cisz(1536)) ***********************

bottom of data

********************************

Die Angabe KILOBYTES oder MEGABYTES tritt an die Stelle der Angabe CYLINDER oder TRACKS. Intern wird diese Angabe jedoch wieder in Cylinder und Tracks

umgerechnet.

6.2

SMS installiert und aktiviert

Sobald SMS aktiviert ist, ergeben sich einschneidende Änderungen. Zum einen werden JCL-Parameter verfügbar sein, zum anderen sind Auswirkungen auf vorhandene JCL

neue

möglich.

SMS -

Storage Management Subsystem

311

Neue JCL-Anweisungen für SMS Für die Arbeit mit SMS gibt es 10 neue DD-Parameter. Außerdem haben einige bekannte Parameter mit SMS eine neue Bedeutung bekommen. Sie alle werden nunmehr im

einzelnen

vorgestellt.

AVGREC und SPACE

Syntax:

AVGREC=U

I KI

M

SPACE=(reclen,(prim-alloc,sec-alloc),RLSE) AVGREC wird benutzt, um die Platzallokation in Records vorzunehmen. Die Parameter U, K und M werden als Multiplikatoren eingesetzt. U 1, K 1.024 und M 1.048.576. Wenn der SPACE-Parameter zusammen mit dem AVGREC-Parameter eingesetzt wird, so wird diesem Fall die Zahl als logische Record-Länge interpretiert. Wird SPACE ohne AVGREC eingesetzt, so wird die Zahl als physische Record-Länge interpretiert. =

//DDNAME

DD

=

=

AVGREC=U,SPACE= (100, (500,100))

Hier wird Platz für maximal 2.000 Records (500 für den Primary Extent + maximal 15 x 100 für die Secondary Extents) angefordert. U A= 1. Da die logische Record-Länge 100 Byte ist, werden insgesamt 200KB angefordert.

//DDNAME

DD AVGREC

=

K,SPACE=(80, (50,10))

Hier wird Platz für maximal 200.000 Records (50 x 1.000 für den Primary Extent + maximal 15 x 10 x 1.000 für die Secondary Extents) angefordert. K A= 1.000. Da die logische Record-Länge 80 Byte ist, werden insgesamt ca. 16MB angefordert.

Auch bei SMS-kontrollierten Datasets können bis zu 16 Extents erzeugt werden. Die Logik entspricht der der nicht-SMS-Datasets. Bei variabel langen Records ist die durchschnittliche Record-Länge anzugeben. Sie wird dann zur Allokation herangezogen. DATACLAS

Syntax:

DATACLAS=Datenklassenname Der DATACLAS-Parameter wird beim

Anlegen

von

neuen

Datasets verwendet. Er

bewirkt, daß für das neue Dataset die Angaben, die für die Datenklasse spezifiziert wurden,

MVS/ESA JCL

312

übernommen werden. DATACLAS kann auch für Band- bzw. Kassettendatasets

spezifiziert werden. Die Datenklasse beinhaltet folgende Informationen: Record Organization

-

-

-

(RECORG)* (welche Art von VSAM-Dataset). Record-Format (RECFM) *. Record-Länge (LRECL)*.' Schlüssel-Länge (KEYLEN)* (nur für VSAM-Datasets). Schlüssel-Position (KEYOFF)* (nur für VSAM-Datasets). Platzanforderung (AVGREC* und SPACE*) Retention Period oder Expiration Date (RETPD* oder EXPDT*). Volume Count

.

IMBED, REPLICATE, CISIZE, FREESPACE und SHARE-OPTIONS (nur für VSAM-Datasets). Die mit einem * gekennzeichneten Parameter können in der gleichen DD-Anweisung -

überschrieben werden.

Auf die

Angabe von DATACLAS kann verzichtet werden, wenn eine sogenannte Automatic Class Selection Routine installiert ist. Dann wird aufgrund bestimmter Merkmale des DSN eine Zuweisung zu einer Datenklasse erfolgen. Ob und welche Art von ACS bei Ihnen installiert ist, können Sie unter ISMF erfahren. Beispiel: ohne ACS

//OUTFILE // //

DD

DSN=UWIN.SCHULUNG.OUTFILE,

DISP=(,CATLG,DELETE), DATACLAS=SEQ80,STORCLAS=S21PERM

mit ACS

//OUTFILE //

DD

DSN=UWIN.SCHULUNG.COBOL, DISP=(,CATLG,DELETE)

Das zweite

Speicher-

Beispiel funktioniert nur dann, wenn für den DSN eine und Datenklasse mit Hilfe von ACS möglich ist.

KEYLEN

Syntax:

KEYLEN=schlüssellänge

Zuweisung

zu

einer

SMS -

Storage Management Subsystem

313

Dieser Parameter wird bei SMS dazu benutzt, einem VSAM KSDS-Dataset eine Schlüssellänge zuzuweisen. Die Länge kann zwischen 1 und 255 liegen. Wird KEYLEN explizit angegeben, so werden die Angaben der Datenklasse überschrieben. KEYLEN ist nur gültig, wenn RECORG=KS ist. Er wird zusammen mit dem KEYOFFParameter (s.u.) eingesetzt. KEYOFF

Syntax: KEYOFF=offset Mit dem KEYOFF-Parameter wird die Position des Schlüssels in einem VSAM KSDSDataset angegeben. KEYOFF wird nur beim Anlegen einem VSAM KSDS-Dataset benötigt. Der erste Offset ist 0.

Beispiel:

//NEUVSAM // //

DD

DSN=UWIN.VSAM.KSDS.NEU,

DATACLAS=KSDS01,

DISP=(,CATLG,DELETE),KEYLEN=10,KEYOFF=5

Es wird ein VSAM KSDS-Dataset neu angelegt und die Werte aus der Datenklasse KSDS01 übernommen. Die Angaben der Datenklasse für Schlüssellänge und -position weiden überschrieben. In der Datenklasse würde wahrscheinlich als Schlüsselposition der Default 0 angenommen. Der Schlüssel

beginnt auf dem 6. Byte.

LIKE

Syntax:

LIKE=dsname Der LIKE-Parameter kann unter SMS dazu verwendet werden, Datasetattribute eines Modelldatasets zu kopieren. Dies bezieht sich auf folgende Parameter: 1. RECORG

2. 3.

(nur Bedeutung bei VSAM-Datasets),

RECFM, LRECL,

4. KEYLEN (nur Bedeutung bei VSAM-Datasets), 5. KEYOFF (nur Bedeutung bei VSAM-Datasets), 6.

AVGREC,

MVS/ESA JCL

314 7. SPACE

Wird LIKE=dsname Dataset übernommen.

angegeben,

so

werden die Datasetattribute für das

neu

anzulegende

RETPD- und EXPDT-Angaben des Modelldatasets werden nicht übernommen. Das Modelldataset muß katalogisiert sein. Keinesfalls darf es ein temporäres Dataset (DSN=&&dsname) sein. Mit Membem eines PO-Datasets und GDGs funktioniert LIKE ebenfalls nicht. Werden zusätzlich zu LIKE weitere DD-Parameter angegeben, so überschreiben diese Angaben die vom Modelldataset kopierten.

mit REFDD verwendet werden. Im Gegensatz zu den meisten anderen JCL-Parametern, die mit SMS in Verbindung stehen, kann LIKE auch bei Band- bzw- Kassettendatasets eingesetzt werden. LIKE darf in einer DD-Anweisung nicht

zusammen

Beispiel:

//OUTPUT // //

DD

DSN=UWIN.SCHULUNG.OUTPUT2,

DISP=(,CATLG,DELETE), LIKE=UWIN.MODEL.OUTPUT

Die Attribute des Dataset UWIN.MODEL.OUTPUT werden diesem Dataset UWIN.SCHULUNG.OUTPUT2 übernommen.

//OUTPUT // // // //

DD

Beispiel für das neue

DSN=UWIN.SCHULUNG.OUTPUT.VSAM,

DISP=(,CATLG,DELETE), LIKE=UWIN.MODEL.VSAM.KSDS, KEYOFF=5, KEYLEN=15

In diesem

Beispiel wird ein neues VSAM-Dataset angelegt. Als Modell dient UWIN.MODEL.VSAM.KSDS. Die Angaben für Schlüssellänge und -position werden überschrieben. MGMTCLAS

Syntax:

MGMTCLAS=managementklassenname Zuordnung zu einer Managementklasse dient dazu, das Dataset nach bestimmten Gesichtspunkten zu migrieren und Backups zu erstellen. Es können nur gültige Klassen, die von der Systemprogrammierung aufgesetzt werden, verwendet werden. Die Attribute der Managementklasse können mit JCL nicht beeinflußt werden.

Die

SMS -

Storage Management Subsystem

entsprechende ACS-Routinen existieren, greifen sie, Managementklasse gemacht wurden. Sofern

315

falls keine

Angabe

zur

Bedeutung.

Mit

RECORG

Syntax:

RECORG=KS

|

ES

I

RR

I

LS

Der RECORG-Parameter hat nur in Zusammenhang mit VSAM-Datasets ihm wird angeben, welche Art von VSAM-Dataset angelegt werden soll.

Möglich sind: Key Sequenced Data Set (VSAM-Dataset mit Schlüssel). Entry Sequenced Data Set (Sequentielles VSAM-Dataset). 3. RR Relative Record Data Set (VSAM-Dataset mit relativem Schlüssel). Linear Space Data Set (Lineares VSAM-Dataset). 4. LS Wird RECORG nicht angegeben, erwartet SMS, daß eine Bibliothek oder ein sequentielles Dataset angelegt werden soll. 1. KS 2. ES

-

-

-

-

REFDD

Syntax: \ddname

REFDD=

*.stepname.ddname

_*.stepname.procstepname.ddname_ Der REFDD-Parameter erfüllt die

gleiche Funktion wie der LIKE-Parameter. Der Unterschied zwischen beiden besteht darin, daß sich REFDD auf ein im Job neu angelegtes Dataset bezieht, während LIKE sich auf ein bereits katalogisiertes Dataset bezieht. Dies ist der Grund dafür, daß REFDD mit einem Rückbezug arbeitet. Bei LIKE genügt die Angabe des DSN. Es gelten die gleichen Einschränkungen wie bei LIKE. REFDD und LIKE dürfen nicht zusammen in einer DD-Anweisung verwendet werden. Im Gegensatz zu den meisten anderen JCL-Parametem, die mit SMS in Verbindung stehen, kann REFDD wie LIKE auch bei Band- bzw- Kassettendatasets eingesetzt werden.

MVS/ESA JCL

316

Beispiel:

//STEP1 //0UT1 // // // // //OUT2 // // //

EXEC PGM=P808401 DD DSN=UWIN.SCHULUNG.OUTPUT.SEQ1,

DISP=(NEW,CATLG), STORCLAS=S21PERM, DATACLAS=SEQSMALL, LRECL=65 DD

DSN=UWIN.SCHULUNG.OUTPUT.SEQ2,

DISP=(NEW,CATLG), STORCLAS=S21PERM, REFDD=*.OUTl

Beim Anlegen des Dataset unter dem DD-Namen OUTPUT 1 werden die Angaben der Datenklasse SEQSMALL übernommen, wobei die logische Record-Länge mit 65 überschrieben wird. Bei OUTPUT2 werden die Attribute von OUTPUT1 übernommen, also auch die logische Record-Länge von 65 Byte. Die übrigen Attribute entsprechen der Datenklasse SEQSMALL, die ja zum Anlegen unter OUTPUT1 herangezogen wurde. SECMODEL

Syntax:

SECMODEL=(profilname[,GENERIC]) Mit dem SECMODEL-Parameter kann für das neu anzulegende Dataset ein bestimmtes existierendes RACF-Profil übernommen werden. Dies macht aber nur Sinn, wenn der DSN des neu anzulegenden Dataset nicht unter ein existierendes RACF-Profil fällt. Soll ein generisches Profil kopiert werden, so ist der entsprechende Schlüsselname anzugeben.

Änderungen an RACF-Parametera können über JCL nicht eingegeben werden. STORCLAS

Syntax:

STORCLAS=speicherklasse Wird für ein neues Dataset der STORCLAS-Parameter Kontrolle von SMS unterstellt.

verwendet,

so

wird das Dataset der

SMS -

317

Storage Management Subsystem

Mit dem STORCLAS-Parameter wird festgelegt, in welcher Speicherklasse ein Dataset angelegt werden soll. Die Speicherklasse besteht aus einer Gruppe gleichartiger Plattenspeicher. Die Zuweisung einer Speicherklasse kann auch implizit über die Automatic Class Selection erfolgen. Datasets, die einer Speichelklasse zugeordnet werden, werden als SMS-managed bezeichnet. STORCLAS ersetzt die Angabe von UNIT=gruppenname.

der Speicherklassen ist Sache des Storage Administrators. Attribute der über JCL nicht geändert werden. können Speicherklasse Bei der Verwendung von UNIT und VOL=SER ist im Zusammenhang mit SMS Vorsicht geboten. Sie werden nur dann wirksam, wenn die Speicherklasse das Attribut GUARANTEED SPACE=YES besitzt. Ist dies nicht der Fall, so werden UNIT- und Die

Festlegung

VOLUME-Angaben ignoriert. Neue IDCAMS-Parameter für SMS

Syntax:

STORAGECLASS(speicherklasse) DATACLASS(datenklasse) MANAGEMENTCLASS(managementklasse) Die Parameter werden wie andere IDCAMS-Parameter eingesetzt. Ihre Bedeutung entspricht denen der entsprechenden JCL-Parameter. Durch die Angabe von STORAGECLASS wird ein neues VSAM-Dataset der Kontrolle von SMS unterstellt, sofern dies nicht automatisch mit ACS geschieht.

6.3

SMS-managed

vs.

nicht-SMS-managed

Wenn SMS aktiviert wird, so kann theoretisch die gesamte Datasetverwaltung unter seine Kontrolle gestellt werden. Durch die Zuordnung von DATACLAS, STORCLAS und MGMTCLAS werden einem neu zu erstellenden Dataset physische Attribute zugewiesen.

//NEUDAT // // // //

DD

DSN=UWIN.SCHULUNG.COBOL,

DISP=(NEW,CATLG), DATACLAS=PODAT, STORCLAS=PERMDSK, MGMTCLAS=NORM

Diese Form der Definition ist etwas einfacher als die bisher mit JCL übliche. Die Datasetattribute RECFM, LRECL, SPACE usw. werden über die DATACLAS Durch STORCLAS wird das Dataset auf ein permanentes Volume gelegt, dies zugeordnet. -

-

MVS/ESA JCL

318

entspricht in etwa dem bisherigen Parameter UNIT=gruppenname. MGMTCLAS sorgt für die Zuordnung bestimmter Migrations- und Backupattribute. Trotzdem ist diese Form der Definition noch umfangreich. Es gibt aber eine noch weitergehende Möglichkeit, nämlich die Definition der sogenannten Automatic Class Selection (ACS). ACS fußt auf Merkmalen des DSNs eines anzulegenden Dataset. Erfüllt der DSN bestimmte Konventionen, so übernimmt ACS die Zuordnung zu bestimmten Klassen. Im Endstadium sollte mit ACS

//NEUDAT //

DD

folgendes möglich werden:

DSN=UWIN.SCHULUNG.COBOL,

DISP=(NEW,CATLG)

Durch eine entsprechende systemseitige Definition ordnet ACS das so anzulegende Dataset bestimmten Klassen zu, weil hier der dritte Qualifier des DSN COBOL heißt. Die Zuordnung erfolgt zur Datenklasse PODAT, es wird also ein Partitioned Data Set erzeugt, mit einer Record-Länge von 80 Byte und Record Format. Als Speicherklasse wird PERMDSK zugeordnet.

In der Praxis wird es aber schwierig werden, alle DSNs so weit zu standardisieren, daß sie ohne weiteres von ACS erkannt werden können. Aus diesem Grund wird das explizite Zuweisen über STORCLAS erforderlich bleiben.

Anlegen von Datasets unter SMS ohne ACS Sequentielle Datasets Ohne ACS unterscheidet sich das Zustand ohne SMS:

//NEUDAT // // // //

DD

Anlegen

eines Datasets zunächst

nur

unwesentlich

vom

DSN=UWIN.SCHULUNG.DS99,

DISP=(NEW,CATLG), STORCLAS=PERMDSK,

SPACE=(TRK, (10,1) ,RLSE)

,

RECFM=FB,LRECL=80

Durch die Angabe des STORCLAS-Parameters wird das neue Dataset der Kontrolle von SMS unterstellt und auf einem Volume angelegt, das ebenfalls von SMS kontrolliert wird und zur Speicherklasse mit dem Namen PERMDSK gehört. Sofern die entsprechenden ACS-Routinen existieren, kann auf die Angabe von STORCLAS verzichtet werden. ACS weist dann aufgrund des DSN eine bestimmte Storage Class zu. Eine der wichtigsten Auswirkungen der Zuordnung zu SMS besteht darin, daß das Dataset jetzt am Step-Anfang katalogisiert wird und nicht wie bisher, am Step-Ende. Sollte ein Katalogeintrag gleichen Namens bestehen, so kommt es jetzt zu einem JCL-Fehler:

SMS -

319

Storage Management Subsystem

IEF344I

jobname stepname

-

ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR DATA SET dsname NOT

IGD17101I

DEFINED BECAUSE

DUPLICATE NAME EXISTS IN THE CATALOG Dies stellt einen wesentlichen Fortschritt zur bisherigen Situation dar, in der man ein zweites Dataset gleichen Namens anlegen konnte, dieses Dataset aber dann nicht katalogisiert wurde. Hinzu kam, daß dieser Fehler sich nicht einmal im Return Code ausdrückte, sondern lediglich in den Messages anhand der Meldung NOT CATLGD 2 erkennbar war. Sofern eine entsprechende Datenklasse definiert ist, lassen sich die Angaben beim Anlegen des Datasets weiter vereinfachen:

//NEUDAT // //

DD

DSN=UWIN.SCHULUNG.DS99,

DISP=(NEW,CATLG), STORCLAS

=

PERMDSK,DATACLAS PS 8 0 SMAL =

Im obigen Beispiel werden die gesamten Attribute der Datenklasse PS80SMAL übernommen. Hier werden mehrere Probleme deutlich: 1.

Intransparenz: Der User muß um die Attribute der Datenklasse wissen, die von JCL können erhebliche Probleme entstehen. Neue User müssen mit den Datenklassen vertraut

hohen Dokumentationsaufwand. 2. Flexibilität: Wenn

er

einsetzt. Bei der Wartung

gemacht werden.

Dies erfordert einen

Attribute der Datenklasse überschrieben werden müssen, kann der Kodieraufwand ähnlich hoch wie früher werden. Unter Umständen ist es dann besser, auf die Zuordnung zur Datenklasse zu verzichten. Datasets mit Hilfe des VOL=SER-Parameters auf ganz bestimmte Platten zu legen, wird unter SMS nur dann möglich sein, wenn die Storage Class mit dem Attribut GUARANTEED SPACE=YES versehen ist. Andernfalls werden UNIT und VOLUME-

Angaben ignoriert.

MVS/ESA JCL

320

//NEUDAT // // // //

DD

DSN=UWIN.SCHULUNG.DS99,

DISP=(NEW,CATLG), STORCLAS=S21PERM,VOL=SER=PRM0 0 8,

SPACE=(TRK,(10,1),RLSE), RECFM=FB,LRECL=80

Das Dataset wird nur dann auf die Platte PRM008 gelegt, wenn die Platte zur Storage Class S21PERM gehört und die Storage Class das Attribut GUARANTEED SPACE=YES besitzt. Ist eine dieser Bedingungen nicht erfüllt, so kommt es zu den Problemen, die ab Seite 372 beschrieben sind.

VSAM-Datasets Unter SMS lassen sich jetzt auch VSAM-Datasets im Job anlegen. Ganz ohne IDCAMS kommt man aber auch dann nicht aus, denn der Katalog muß vor dem Anlegen bereinigt werden.

Beim Anlegen von VSAM-Datasets muß eine Datenklasse angegeben werden. Sie enthält neben den überschreibbaren Parametern wie KEYLEN und KEYOFF auch Parameter, die nicht überschrieben werden können. Dazu zählt zum Beispiel die Kontrollintervallgröße. Die Wahl der optimalen CI-Größe ist aber für die Performance eines VSAM Dataset von ausschlaggebender Bedeutung. Entweder muß dann eine große Zahl von Datenklassen für VSAM-Datasets definiert werden oder man greift auf IDCAMS zurück.

SMS

321

Storage Management Subsystem -

edit-uuin.schulung. idcloes(defksds) 01.02 .columns 001 072 scroll ===> page command ===> ****** ***************************** top of data ***************************** 000001 //uwin217c job (uwin.abtdg02),'m.winter',not ify=uwin, 000002 // class=t,msgclass=y 000003 //*************************************************************** 000004 //* 000005 //* idcams zum anlegen eines vsam ksds-dataset mit sms 000006 //* -

000007 000008 000009 000010 000011 000012

//*************************************************************** //define exec pgm=idcams //sysprint dd sysout=* //sysin dd * delete -

uwin.schulung.vsam.ksds

cluster 000013 000014 //define exec pgm=iefbr14 000016 //vsamout dd dsn=uwin.schulung.vsam.output1, 000017 // disp=(new,catlg), 000018 // storclas=s21perm, 000019 // recorg=ks, 000020 // dataclas=ksdstest, 000021 // space=(200,(100,10)),avgrec=k, 000022 // lrecl=80, 000023 // keylen=12 ******

***************************

bottom of data

**************************

So angenehm die Möglichkeit des Anlegens von VSAM-Datasets auf den ersten Blick sein mag, so hat sie doch den Nachteil, daß viele Optionen, die unter IDCAMS zur Verfügung stehen, hier nicht gegeben sind. Hinzu kommt, daß viele Parameter als Teil der Datenklasse übernommen werden, was die Transparenz nicht gerade fördert. Da man unter SMS VSAM-Datasets im Job anlegen kann, kann man sie auch ohne IDCAMS löschen und zwar durch die Angabe (OLD,DELETE) im DISP-Parameter. Von dieser Möglichkeit sollte man keinen Gebrauch machen. Sollte im folgenden Beispiel das VSAM-Dataset zum Zeitpunkt des Step-Beginns bereits gelöscht sein, so kommt es zu einem JCL-Allokationsfehler, da ein DATASET NOT CATALOGED-Fehler auftritt. Die Folge: Der Job stirbt bereits in diesem Step. IDCAMS hätte lediglich einen Return Code von 8 geliefert.

MVS/ESA JCL

322

01.02 .columns 001 072 scroll ===> page top of data *****************************

edit-uwin.schulung. idcloes(delksds)

-

command

===>

******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010

//uwin217c job (uwin,abtdg02),'m.winter1,notify=uwin, // class=t,msgclass=y

******

***************************

//*************************************************************** //* //* //*

iefbr14 zum loeschen eines vsam ksds-dataset mit sms

//*************************************************************** //delete //delvsam //

exec pgm=iefbr14 dd dsn=uwin.schulung.vsam.output1

,

disp=(old,delete) bottom of data

**************************

Aus diesem Grand sollte man für das Löschen nach wie vor nur IDCAMS verwenden.

Anlegen von Datasets unter SMS mit ACS Sequentielle Datasets Mit Hilfe der Automated Class Selection lassen sich die Zuweisungen von Storage Class, Data Class und Management Class automatisieren. Die Zuordnung erfolgt aufgrund von festgelegten DSN-Merkmalen des neuen Dataset. Die Zuordnung kann in zweierlei Form erfolgen. 1.

Ohne Überschreibungsmöglichkeit: Erkennt eine ACS-Routine einen DSN, so erfolgt die Zuordnung zu bestimmten Klassen aufgrund der Angabe in der ACS. Zusätzlich in der JCL kodierte Parameter wie STORCLAS oder DATACLAS werden ignoriert.

2.

Mit Überschreibungsmöglichkeit:

Erkennt eine ACS-Routine einen DSN, so erfolgt die Zuordnung zu bestimmten Klassen aufgrund der Angabe in der ACS. Zusätzlich in der JCL codierte Parameter wie STORCLAS oder DATACLAS ersetzen dabei die Standardangaben der ACS. Sie sich, ob und in welchem Umfang ACS-Routinen bei Ihnen eingesetzt werden. Sie verlangen ein hohes Maß an DSN-Standardisierung, so daß der mögliche Nutzen vom Definitionsaufwand aufgefressen werden kann. Dort, wo es bereits standardisierte DSNs gibt, ist der Nutzen eher gering. So lassen sich DSNs, die COBOL, LOAD oder CNTL als Bestandteil enthalten, natürlich leicht identifizieren, nur werden diese Datasets meist unter ISPF angelegt und nicht im Job. Ein weiteres Problem der ACS ist seine Intransparenz. Dem User müssen die vom ACS erfaßten DSNs geläufig sein. Ansonsten könnte es ihm passieren, daß ACS von sich aus

Erkundigen

SMS -

323

Storage Management Subsystem

gesetzte Parameter in der JCL Klaren ist.

überschreibt, ohne daß sich der User über diese Tatsache im

Anlegen eines sequentiellen Datasets mit ACS: 01.02 .-COLUMNS 001 072

EDIT-UWIN.SCHULUNG.SMS(DEFSEQ) -

COMMAND

SCROLL

===>

******

*****************************

000001 000002 000003 000004

//UWIN217C job (UWIN,ABTDG02),1M.WINTER1, // NOTIFY=UWIN, // CLASS=T,

top OF DATA

===>

PAGE

*****************************

// MSGCLASS=Y 000005 //******************************** 000006 //* 000007 //* IEFBR14 ZUM ANLEGEN EINES SEQUENTIELLEN DATASET MIT ACS 000008 //* 000009 //*************************************************************** 000010 //DELETE EXEC PGM=IDCAMS 000011 //SYSPRINT DD SYSOUT=* ,

000012 //SYSIN DD * 000013 DELETE 000014 UWIN.SCHULUNG.NEUDAT 000015 IF MAXCC = 8 THEN SET MAXCC -

0 000016 //DEFINE EXEC PGM=IEFBR14 000017 //NEUFILE DD DSN=UWIN.SCHULUNG.NEUDAT, 000018 // DISP=(NEW,CATLG) ******

Die

*****************************

=

BOTTOM OF DATA

***************************

Zuweisung von Storage Class und den weiteren Datasetattributen übernimmt ACS.

MVS/ESA JCL

324 VSAM-Datasets

Anlegen eines VSAM-Dataset mit ACS: 01.02

EDIT-UUIN.SCHULUNG.SMS(DEFKSDS)

.

COLUMNS 001 072

-

COMMAND ******

SCROLL

===>

*****************************

TOP OF DATA

===>

PAGE

*****************************

000001 //UWIN217C JOB (UWIN,ABTDG02),'M.WINTER', 000002 // NOTIFY=UWIN, 000003 // CLASS=T, 000004 // MSGCLASS=Y EXEC PGM=IDCAMS 000005 //DELETE 000006 //SYSPRINT DD SYSOUT=* 000007 //SYSIN DD * DELETE 000008 UWIN.SCHULUNG.VSAM.KSDS 000009 000010 CLUSTER EXEC PGM=IEFBR14 000011 //DEFINE 000012 //NEUFILE DD DSN=UWIN.SCHULUNG.VSAM.KSDS, 000013 // DISP=(NEW,CATLG), 000014 // KEYLEN=8, DATACLAS=KSDS01 000015 // -

******

*****************************

BOTTOM OF DATA

***************************

Beim Anlegen von VSAM-Datasets wird man um die Angabe einer Datenklasse in der Praxis nicht herumkommen, da es kaum möglich sein wird, alle Attribute über den DSN zu steuern.

6.4

Mögliche Probleme beim Einsatz von SMS

Probleme beim Einsatz von SMS können überall dort auftreten, wo JCL eingesetzt wird, deren Qualität zweifelhaft ist. So ist es bisher möglich, in einem Step Datasets anzulegen, die bei Step-Ende nicht katalogisiert werden. Diese Katastrophe (!) wird sich unter SMS in einem JCL-Fehler niederschlagen und somit nicht mehr unbemerkt bleiben. Das Problem liegt in diesem Fall nicht im Einsatz von SMS, sondern in der zugrunde liegenden schlechten JCL.

VOL=SER in der JCL Andere Probleme können auftreten,

wenn

JCL

volume-spezifisch ist.

SMS -

Storage Management Subsystem

//DEFINE //NEUFILE // // // //

325

EXEC PGM=IEFBR14, DD DSN=UWIN.SCHULUNG.NEUDAT,

DISP=(NEW,CATLG), UNIT=SYSDA,VOL=SER=PRM0 05,

SPACE=(CYL,(5,1)), DCB=(BLKSIZE=23440,LRECL=80,RECFM=FB)

Dies ist ein Beispiel für eine vielerorts nicht gern gesehene JCL. Durch sie wird ein Dataset auf einer ganz bestimmten Platte angelegt. Probleme können auftreten, wenn der DSN UWIN.SCHULUNG.NEUDAT von einer ACSRoutine erkannt wird und das Dataset somit der Kontrolle von SMS unterliegt. Damit wird automatisch eine Storage Class zugeordnet. Es sind folgende Situationen möglich: 1.

Die Platte PRM005 fällt ebenfalls unter die Kontrolle von SMS. Die durch den DSN zugeordnete Storage Class hat das GUARANTEED SPACE=NO Attribut: Die VOL=SER-Angabe wird ignoriert und SMS sucht sich ein anderes Volume in der durch den DSN zugeordneten Speicherklasse.

2.

Die Platte PRM005 fällt ebenfalls unter die Kontrolle von SMS. Die durch den DSN zugeordnete Storage Class hat das GUARANTEED SPACE=YES Attribut:

VOL=SER-Angabe wird übernommen, sofern die Platte gleichen Speicherklasse hat, wie der DSN. Ansonsten siehe 1. Die 3.

4.

passendes

eine

Zuordnung

zur

Die Platte PRM005 fällt nicht unter die Kontrolle von SMS. Die durch den DSN zugeordnete Storage Class hat das GUARANTEED SPACE=NO Attribut: Die VOL=SER-Angabe wird ignoriert und SMS sucht sich ein anderes passendes Volume in der durch den DSN zugeordneten Speicherklasse. Die Platte PRM005 fällt nicht unter die Kontrolle von SMS. Die durch den DSN zugeordnete Storage Class hat das GUARANTEED SPACE=YES Attribut: Es kommt zu einem JCL-Fehler, weil versucht wird, ein von SMS kontrolliertes Dataset auf einem nicht von SMS kontrollierten Volume anzulegen.

MVS/ESA JCL

326

DISP=(OLD,DELETE) bei VSAM-Datasets Das

folgende Beispiel zeigt einen Produktionsjob nach der Umstellung auf SMS:

******

*****************************

000001 000002 000003 000004 000005 000006

//P124A001

TOP oF DATA

*****************************

JOB (124,HKL23),1H.WINTER 1,NOTIFY=U124002, CLASS=U,MSGCLASS=B,USER=U124002

//

//*******************************

//* //* //* 000007 //* 000008 //*

MONATLICHES ERSTELLEN DER ABRECHNUNGEN

SACHGEBIET 124 -

AUF DER BASIS DER IM SYSTEM24 VERWENDETEN EINGABEDATEIEN

000009 //******************************* 000010 //STEP1 EXEC PGM=P124001 000011 //STEPLIB DD DSN=P124.LOADLIB,DISP=SHR DD DSN=P124.PROD.VSAM.KSDS001, 000012 //VSAMIN

DISP=(0LD,DELETE)

000013 // 000128 000129 000130 000131

//STEP22 //STEPLIB

******

***************************

//VSAMIN //

EXEC PGM=P124004G DD DD

DSN=P124.LOADLIB,DISP=SHR DSN=P124.PROD.VSAM.KSDS001,

DISP=SHR BOTTOM OF DATA

**************************

Wurde diese JCL bisher ohne SMS verwendet, so passierte nichts Aufregendes. Da die Disposition (OLD,DELETE) für VSAM-Datasets ungültig war, wurde sie im STEP1 in (OLD,KEEP) umgeändert. Diese JCL ist natürlich Unfug und vermutlich ein nur übersehener Fehler. Unter SMS

passiert im Stepl folgendes:

Das VSAM-Dataset wird

gelöscht

DELETE ist unter SMS eine für VSAM-Datasets gültige Disposition geworden. Da SMS das Anlegen von VSAM-Datasets mit normaler JCL ermöglicht, können VSAM-Datasets mit normaler JCL auch wieder gelöscht werden. Es ist einleuchtend, daß es jetzt im STEP22 zu einem DATASET NOT CATALOGED-Fehler kommt.

Sollten Ihnen nach der Aktivierung von SMS in einem Job plötzlich VSAM-Datasets abhanden kommen, so prüfen Sie nach, ob die oben beschriebene Fehlerbedingung unter Umständen eingetreten ist.

Datasets auf mehreren Platten Unter SMS ist es nicht mehr möglich, sequentiellen Datasets die Ausdehnung auf mehrere Platten zu erlauben. Alle sekundären Extents müssen auf dem gleichen Volume sein, auf

SMS -

Storage Management Subsystem wurde. Sind sie

327

erschöpft,

dem das Dataset ABEND.

angelegt

Löschen und

entkatalogisieren von Datasets

Bevor Datasets neu angelegt werden, muß der verschiedene Weise geschehen: 1.

Mit IDCAMS

//UNCAT //SYSPRINT //SYSIN

so

kommt

Katalog bereinigt

es zu

einem SB37-04

werden. Dies kann auf

(ohne NSCR)

EXEC PGM=IDCAMS DD SYSOUT=* DD

*

DELETE dsname IF MAXCC

=

8 THEN SET MAXCC

=

0

Diese Form wird unter SMS keinerlei Probleme bereiten. Alle anderen Möglichkeiten, die jetzt vorgestellt werden, sind von zweifelhaftem Wert, obwohl sie zumindest teilweise funktionieren. Unter SMS kann es aber zu massiven Problemen kommen. 2.

Mit IEHPROGM

//UNCAT //SYSPRINT //DDI // //SYSIN SCRATCH

EXEC PGM=IEHPROGM DD SYSOUT=*

UNIT=PRMDSK, VOL=SER=PRM0 01,DISP=OLD DD

DD

*

DSNAME=DSNAME,VOL=PRMDSK=PRM001

UNCATLG DSNAME=DSNAME Diese Methode ist sehr umständlich, da man wissen muß, daß sich das Dataset auf der Platte PRM001 befindet. Unter SMS kann das nur noch funktionieren, wenn die Storage Class das Attribut GUARANTEED SPACE=YES besitzt. In diesem Fall wird bei Ausführung des SCRATCH Kommandos gelöscht und entkatalogisiert. (SMS läßt keine nicht katalogisierten Datasets zu.) Das folgende UNCATLG Kommando liefert einen Return Code von 4. Werden die Kontrollanweisungen getauscht (erst UNCATLG, dann SCRATCH), so wird entkatalogisiert und gelöscht. Das nachfolgende SCRATCH Kommando liefert dann einen Return Code von 8, was unter Umständen die Ausführung folgender Steps verhindern kann. Unter SMS sollte IEHPROGM für Plattendatasets nicht mehr eingesetzt werden.

MVS/ESA JCL

328 3.

Mit IDCAMS

//UNCAT //SYSPRINT //SYSIN

(mit NSCR)

EXEC PGM=IDCAMS DD SYSOUT=* *

DD

DELETE dsname NSCR

IF MAXCC

8 THEN SET MAXCC

m

0

=

Unter SMS ist die Angabe von NSCR fur Plattendatasets nicht mehr generell erlaubt, weil diese Operation zwar den Eintrag im User-Katalog, nicht aber die Einträge auf der Platte (VTOC und den SMS-Kontrolleintrag) löschen würde. Die Folge wäre ein nicht katalogisiertes Dataset, daß es unter SMS nicht geben darf.

Schon in der Vor-SMS-Umgebung war die Benutzung dieses Parameters mehr als zweifelhaft. Er löschte Katalogeinträge für nicht mehr auf der Platte existierende Datasets. Ein Zustand, den es erstens gar nicht geben dürfte und zweitens bei seinem Auftreten Nachforschungen über die Ursache auslösen sollte. Den Katalogeintrag unter SMS wiederherzustellen, berechtigten Personenkreis möglich:

//RECAT //SYSPRINT //SYSIN

ist sehr umständlich

nur

einem

speziell

EXEC PGM=IDCAMS DD SYSOUT=* DD

*

(NAME(dsname) VOLUME(PRM028) DEVICETYPE(33 90) RECATALOG) DEFINE NONVSAM

-

-

Die RECATALOG muß unbedingt angegeben werden. Geschieht dies nicht, so wird im User-Katalog ein Eintrag erzeugt, der auf ein nicht von SMS kontrolliertes Dataset verweist. Unter SMS soll beim Löschen von Datasets auf Platte unter keinen Umständen mit der Option NSCR (NOSCRATCH) gearbeitet werden.

SMS -

Storage Management Subsystem

329

4. IEFBR14 mit DISP=(OLD,UNCATLG)

//UN CAT //DDI // //CAT //DD2 // // //

EXEC PGM=IEFBR14 DD

DSN=UWIN.SCHULUNG.TEST,

DISP=(OLD,UNCATLG) EXEC PGM=IEFBR14 DD

DSN=UWIN.SCHULUNG.TEST,

DISP=(NEW,CATLG), UNIT=PRMDSK,RECFM=FB,LRECL=2 3 3,

SPACE=(TRK, (5,1))

Abgesehen davon, daß diese JCL hanebüchen ist es gibt keinen vernünftigen Grund, das Dataset nur zu entkatalogisieren, da es dann als 'Leiche' auf der Platte zurückbleibt hat sie bisher fast immer funktioniert. (Ausnahme: wenn beim Anlegen zufällig die Platte ausgewählt wird, auf der das Dataset als 'Leiche' zurückblieb.) Unter SMS wird dies auf keinen Fall mehr funktionieren, da die Disposition (OLD,UNCATLG) in (OLD,KEEP) umgewandelt wird. Es wird also nicht entkatalogisiert. Dadurch kann DD2 nicht angelegt werden, es kommt zu einem Katalogisierungsfehler (JCL-Fehler). Folge: Der Job stürzt ab. -

-

Nicht optimierte Blocksize

Benutzung von AVGREC ist zu beachten, daß SMS bei der Berechnung des Platzes, der zur Verfügung gestellt werden soll, von einer optimalen Blockgröße ausgeht, Bei der

die entweder vom User angegeben wurde oder vom

//NEUDAT // // // //

DD

System errechnet wurde.

DSN=UWIN.SCHULUNG.NEUDAT,

DISP=(NEW,CATLG,DELETE), S TORCLAS S 21PERM, =

SPACE=(80,100000),AVGREC=U, DCB=(BLKSIZE=80,RECFM=FB,LRECL=80)

Durch diese Angabe soll Platz für 100.000 Records ä 80 Byte angefordert werden. Da aber die Blockung völlig unzureichend ist, ist der Platzbedarf sechsmal so groß wie bei optimaler Blockung. Diesen erhöhten Platzbedarf deckt SMS aber nicht ab. Deshalb kann es leicht zu einem D37-04 ABEND kommen.

JOBCAT und STEPCAT Die JOBCAT und STEPCAT eingesetzt werden.

DD-Anweisungen

dürfen in

Zusammenhang mit

SMS nicht

MVS/ESA JCL

330

Neue Defaults beim DISP-Parameter Sofern SMS aktiv ist, kann der DISP-Parameter neue Defaults annehmen. Da SMS ausschließlich mit katalogisierten Datasets arbeitet, wird z.B. beim Anlegen eines Datasets die DISP=(NEW,KEEP) umgewandelt in DISP=(NEW,CATLG). Das Gleiche gilt sinngemäß für den Abnormal-Disp-Subparameter. Auf diese Weise verhindert SMS das Anlegen nicht katalogisierter Datasets auf Platte. Dies stellt einen wesentlichen Fortschritt dar. Da SMS mit nicht katalogisierten Datasets nicht arbeiten kann, wird auch die Disposition UNCATLG, sofern sie angegeben wird, umgewandelt in KEEP (mögliche Folgen s.o.). Die

folgende Übersicht zeigt die Defaults für VSAM-Datasets:

Datasetart:

VSAM

Angabe in der JCL

nimmt

DISP=(NEW,KEEP)

DISP=(NEW,CATLG)

DISP=(NEW,PASS)

DISP=(NEW,CATLG)

DISP=(OLD,PASS)

DISP=(OLD,KEEP)

DISP=(SHR,PASS)

DISP=(SHR,KEEP)

DISP=(OLD,UNCATLG)

DISP=(OLD,KEEP)

DISP=(SHR,UNCATLG)

DISP=(SHR,KEEP)

DISP=(OLD,CATLG)

DISP=(OLD,KEEP)

DISP=(SHR,CATLG)

DISP=(SHR,KEEP)

folgenden Default an

SMS

Storage Management Subsystem

331

-

Die

folgende Übersicht zeigt die Defaults für Nicht-VSAM-Datasets.

Datasetart:

nicht-VSAM

Angabe in der JCL

nimmt

DISP=(NEW,KEEP)

DISP=(NEW,CATLG)

DISP=(MOD,KEEP)

DIS P wenn

wird)

folgenden Default an

=

(MOD, CATLG) (gilt nur,

MOD in NEW umgesetzt

DISP=(OLD,UNCATLG)

DISP=(OLD,KEEP)

DISP=(SHR,UNCATLG)

DISP=

DISP=(OLD,CATLG)

DISP=(OLD,KEEP)

DISP=(SHR,CATLG)

DISP=

(SHR,. KEEP)

(SHR, KEEP')

JCL-Schnittstellen

7

Normalerweise werden Jobs als Member eines PO-Dataset erstellt. Um einen Job zu submitten, gibt man auf der Kommandozeile des ISPF den SUBMIT-Befehl ein. Darüber hinaus gibt es jedoch einige andere Möglichkeiten, Jobs zu submitten. Dies ist wichtig vor allem in Hinblick auf eine weitgehende Automatisierung. In diesem

Kapitel soll auf folgende Möglichkeiten eingegangen werden:

1. Jobs

aus

2. Jobs

aus

CLISTen submitten. REXX EXECs submitten.

3. Jobs mit Hilfe der File submitten.

Tailoring Services des ISPF Dialog Managers zu erstellen und zu

(Command List) ist wie REXX (Restructured Extended Executor) eine Interpretersprache, die auf IBM-Systemen eine Verarbeitung im Vordergrund durchfuhren CLIST

kann.

7.1

JCL

aus

CLISTen submitten

Batch Jobs lassen sich aus CLISTen heraus auf zweierlei Art submitten. Entweder werden die JCL-Anweisungen zusammen mit den CLIST-Anweisungen codiert oder die JCLAnweisungen stehen in einem Member einer Bibliothek. Im zweiten Fall wird dieses Member mit dem SUBMIT-Kommando aufgerufen. Anhand des folgenden Jobs soll demonstriert werden, wie Batch Jobs aus CLISTen heraus submitted werden. Der Job führt das Programm IEFBR14 aus. edit-uwin. schulung. cntl(

iefbr14)

01.06

---.

-

command ******

*****************************

000100 000200 000300 000400 000500

//uwin217c //step1

******

****************************

//

//dd 1 //

columns 001 072 ===> page

scroll

===>

jQp op data

******************************

(uwin,abtdg02),n0tify=uwin, class=c,msgclass=9 job

exec pgm=iefbr14 dd dsn=uwin.schulung.test, disp=shr bottom of data

****************************

MVSESA/JCL

334

Um den Job aus der CLIST heraus zu submitten, muß in der CLIST mit dem TSOKommando: SUBMIT gearbeitet werden. Die JCL wird ebenfalls einfach in die CLIST die JCL-Anweisungen auf die SUBMIT-Anweisung eingestellt. Da im folgenden Beispiel folgen, wird dies durch einen * kenntlich gemacht (entspricht SYSIN DD * in normaler JCL). Das END($$) ist eine Delimiter-Anweisung. Sie zeigt an, wo der Job-Stream endet und entspricht dem DLM-Parameter in der DD-Anweisung. Der vorangehende DISPLAY PANEL dient zum Anzeigen eines Panels, auf dem der Benutzer entscheiden kann, ob er den Job submitten will oder nicht. edit-uwin.schulung.clist(cl24)

01.06

.-.

-

command ******

===>

*****************************

000100 /* clist zum submitten eines 000200 ispexec display panel(p0024) 000300 if &lastcc = 8 then + 000400 000500 000600

columns 001 072 ===> page

scroll

tqp of data ****************************** batch jobs */

in_stream

do exit end

000700 submit * end($$) 000800 //uwin217c job (uuin,abtdg02),n0tify=uwin, 000900 // class=c,msgclass=9 exec pgm=iefbr14 001000 //step1 dd dsn=uwin.schulung.ds99, 001100 //dd1 disp=shr 001200 // 001300 $$ ****** **************************** bottom of data

****************************

Bis dahin ist die Sache noch nicht besonders spannend. Interessant wird es erst dann, wenn in der JCL Variable enthalten sind. Diese Variable werden in der CLIST vorbelegt. Verbindet man die CLIST mit einem Panel (Eingabebildschirm), so können die Variablen auch auf diese Weise belegt werden. Die Variablen sind in einer CLIST am vorangestellten & erkennbar. Dies kennen Sie bereits aus JCL-Prozeduren. Um nun Variableninhalte aus dem Panel zu übernehmen, müssen in die JCL Variable eingefügt werden. In unserem Beispiel soll die USERID, die Job-Klasse und der Name des unter DDI angesprochenen Dataset übergeben werden. Dazu muß der JCL-Teil der CLIST folgendermaßen geändert werden. Die

SET-Anweisungen dienen der Vorbelegung der Variablen mit Standardwerten.

335

JCL-Schnittstellen edit-uwin.schulung.clistccl24)

01,06

.

columns 001 072

-

command

scroll

===>

*****************************

000100 000200 000300 000400 000500 000600 000700 000800 000900 001000 001100

/* clist zum submitten eines in-stream batch jobs */

******

****************************

set &acct set &abt

= =

set &klasse

Tgp of data

===>

page

******************************

******

998 abtdg02 =

c

set &neudsn = 1 schulung.test submit * end($$)

1

//&sysuid.xxxx job (&acct.,&abt.),notify=&sysuid, //

//step1

//dd 1 // 001200 $$

class=&klasse,msgclass=9 exec pgm=iefbr14 dd

dsn=&sysuid..&neudsn,

disp=shr bottom of data

****************************

Der Jobname wird mit Hilfe der USERID, die sich in einer Systemvariablen mit der Bezeichnung &SYSUID befindet, und den vier Zeichen XXXX generiert. Für Account und Abteilung werden die vorbelegten Variableninhalte übernommen. Der doppelte Punkt im Parameter DSN kommt dadurch zustande, weil der erste Punkt der Variablenbegrenzer ist, der zweite Punkt trennt die verschiedenen DSN-Bestandteile.

CLISTen, die zum Submitten dienen, sollten nicht in einer Schleife laufen, da der Benutzer

unübersehbare Zahl von Jobs abschicken kann. Wer Dialog Manager Kenntnisse besitzt, kann sich ein Eingabepanel erstellen, in dem die Variablen belegt werden. Im Panel werden alle notwendigen Vorverarbeitungen vorgenommen.

sonst eine

MVSESA/JCL

336 01.05

edit-uwin.schulung.panels(p0024)

.

-

command ******

*****************************

000001 )body 000002 %. 000003 000004 000005 000006 000007 000008 000009 000011 000012 000013 000014 000015 000016 000017 000018

columns 001 072 ===> page

scroll

===>

fop of data

batch jobs submitten

*****************************

.

%command ===>_zcmd % % % job-klasse :_z°/.(nur c oder n) % % aufgabennummer:_nmr% % % abteilung :_abt %(ohne ortsangabe) % % neuer dsn % :_neudsn % % (geben sie den dsn ohne (!) die aufgaben-nummer an) % % %

000019 % 000020 % abbrechen mit pf3 000021 % 000022 )init 000023 .zvars=i(klasse)1 000024 )proc 000025 ver(&klasse,nb) 000026 ver(&klasse,li st,c,n,msg=mpan241) 000027 ver(&nmr,nb,num) 000028 ver(&abt,nb) 000029 ver(&neudsn,nb,dsname,msg=mpan242) 000030 )end ******

****************************

Die VERify-Anweisungen gemacht werden.

bottom of data

im Panel stellen

***************************

sicher, daß die Eingaben des Benutzers korrekt

Um das Panel verarbeiten zu können, wird die CLIST abgeändert. Die DISPLAYAnweisung ruft das Panel auf. Die nachfolgende Abfrage überprüft, ob der Benutzer die PF3-Taste gedrückt hat. Wenn dies nicht der Fall ist, wird der Job submitted.

337

JCL-Schnittstellen 01.06

edit-uwin.schulung.clist

*****************************

TOP of data

columns 001 072 scroll ===> page

******************************

000100 /* clist zum submitten eines in-stream batch jobs */ 000200 ispexec display panel(p0024) 000300 if &lastcc = 8 then +

000400 do 000500 exit 000600 end 000700 submit * end($$) 000800 //&sysuid.xxxx job

000900 // 001000 //step1 001100 //ddi 001200 // 001300 $$ ******

(&acct.,&abt.),notify=&sysuid, class=&klasse,msgclass=9 exec pgm=iefbr14

dd

dsn=&sysuid.-&neudsn,

disp=shr

****************************

bottom of data

****************************

Aus einer CLIST heraus läßt sich auch ein Job abschicken, der als Member eines PODataset gespeichert ist. In diesem Fall werden aber keine Variablen substituiert. Der Membername folgt unmittelbar auf die SUBMIT-Anweisung. Eine END-Anweisung wird hier nicht benötigt: 01.06 .-.columns 001 072

edit-uuin.schulung.clistccl24) -

command

scroll

===>

===>

page

top of data ****************************** in-stream batch jobs */ submitten 000100 /* clist zum eines 000200 ispexec display panel(p0024) ******

*****************************

000300 if &lastcc = 8 then + 000400 do 000500 exit 000600 end 000700 submit uwin.schulung.cntl(cl) ******

7.2

****************************

JCL

aus

bottom of data

****************************

REXX EXECs submitten

Um den Job aus der REXX EXEC heraus zu submitten, muß in der REXX EXEC ebenfalls mit dem TSO-Kommando SUBMIT gearbeitet werden. Die Art und Weise, wie in einer REXX EXEC die JCL-Anweisungen erzeugt werden, unterscheidet sich jedoch deutlich von der CLIST-Syntax. Die JCL wird nicht auf normalem Wege eingegeben, sondern mit Hilfe von QUEUE-Kommandos als String auf einen privaten Datenstapel gestellt. Dieser private Datenstapel wurde vorher mit der

MVSESA/JCL

338

Anweisung NEWSTACK angelegt. Das SUBMIT-Kommando bezieht sich dann auf die im Datenstapel abgelegten JCL-Anweisungen. Die anschließende Anweisung DELSTACK löscht den privaten Datenstapel wieder: edit-uwin.schulung.exec(rexx024)

01.04

.

-

command ******

*****************************

000001 000002 000003 000004 000005 000006 000007 000008

/* rexx */ /* /* keine schleife /* /* /*

000009 000010

top of data

*****************************

.

998 abt 1abtdg021 klasse = 'c neudsn = 'test' address ispexec "display panel(p0024)" = =

000011 000012 000013 if rc = 8 then do 000014 exit 000015 000016 end

*

/

*/ */ */

!!

.-.

nmr

columns 001 072 ===> page

scroll

===>

*

/

/* /* /* /* /* /*

initialisierung initialisierung umgebung auf ispf panel anzeigen

*/ */ */ */ */ */

/* /*

der user hat pf 3 gedrueckt deshalb ende

*/ */

initialisierung initialisierung

000017 address tso /* umgebung auf tso */ 000018 1newstack1 /* neuen stack eröffnen */ 000019 queue '//uwinrexx job (uwin,abtdg02),notify=uwin,1 000020 queue '// class=c,msgclass=9' 000021 queue '//create exec pgm=iefbr14' 000022 queue '//sysprint dd sysout=*' dd dsn=uwin.schulung.test, ' 000023 queue '//ddi queue disp=shr' 000024 '// 000025 queue '$$' 000026 "submit * end($$)" /* stack submitten */ 000027 delstack /* stack wieder löschen */ ****** **************************** bottom of data ***************************

Wenn Variablen benutzt werden sollen, so macht sich eine Besonderheit von REXX bemerkbar. Im Gegensatz zu CLIST haben REXX-Variable keinen führenden & und sind damit in der JCL nicht leicht auszumachen. Eine REXX-Variable beginnt dort, wo ein String explizit endet. Sie endet mit dem Beginn eines neuen Strings. Dies soll am Beispiel der ersten Zeile der JOB-Anweisung erläutert werden: Auf den String "//" folgt die Variable mit dem Namen user, darauf der String mit den Zeichen "XXXX JOB (". Es folgt die Variable mit der Bezeichnung NMR, darauf der String "," und dann die Variable ABT. Auf sie folgt ein weiterer String, der einen String enthält: "),'M.Winter',CLASS=". Aus diesem Grund wurde als Stringbegrenzer das Zeichen

JCL-Schnittstellen "

verwendet. Danach

String

339

folgt

die Variable KLASSE. Beendet wird die erste Zeile mit dem

Wie man sieht, muß man bei JCL-Anweisungen innerhalb einer REXX EXEC genau hinschauen. Mit einiger Übung macht es dann jedoch kaum noch Schwierigkeiten. EDIT-UWIN.SCHULUNG.EXEC(REXX024)

01.04

--.

-

COMMAND ******

COLUMNS 001 072 ===> PAGE

SCROLL

===> *****************************

jop OF DATA

*****************************

000001 /* REXX */ 000002 /*

.

KEINE SCHLEIFE !! 000003/* 000004 /*.-.-. 000005 NMR 998 /* INITIALISIERUNG 000006 AßT 'ABTDG021 /* INITIALISIERUNG 'C 000007 KLASSE /* INITIALISIERUNG 'TEST' 000008 NEUDSN /* INITIALISIERUNG 000009 ADDRESS ISPEXEC /* UMGEBUNG AUF ISPF 000010 "DISPLAY PANEL(P0024)"

*

/

*/ /

*/ */

=

=

*/ */

= =

*/

000011 IF RC = 8 THEN DO 000012 EXIT 000013 /* UND RAUS V END 000014 000015 ADDRESS TSO /* UMGEBUNG AUF TSO 000016 'NEWSTACK' /* NEUEN STACK ERÖFFNEN 000017 USER = USERIDO /* USERID REINHOLEN 000018 QUEUE "//"USER"XXXX JOB ("NMR","ABT"),1 M.WINTER 1,CLASS="KLASSE"," 000019 QUEUE "// MSGCLASS=9," 000020 QUEUE "// MSGLEVEL=(1,1)" 000021 QUEUE "//CREATE EXEC PGM=IEFBR14" 000022 QUEUE "//SYSPRINT DD SYS0UT=*" 000023 QUEUE "//DD1 DD DSN="USER". "NEUDSN"," DISP=SHR" 000024 QUEUE "// 000025 QUEUE "$$" 000026 DELSTACK /* STACK WIEDER LÖSCHEN */ ****** **************************** BOTTOM OF DATA ***************************

7.3

JCL mit File Tailoring Services generieren

Mit Hilfe der sogenannten Dateierstellungs-Services (engl. File Tailoring Services FTS) lassen sich mit dem Dialog Manager Batch Jobs zusammenstellen. Die JCL wird als Member in der als ISPSLIB allokierten Bibliothek abgelegt. Für eine bestimmte Funktion gibt es ein Member, das als Gerüst (Skeleton) für die zu generierende JCL dient. -

MVSESA/JCL

340

Mit FTS kann dann ein oder mehrere Member dazu benutzt werden, einen kompletten Job zu erstellen. Als Steuersprache wird in den folgenden Beispielen REXX verwendet. Der Job kann in einer temporären oder einer permanenten Datei oder als Member einer bereits existierenden Bibliothek abgelegt werden. Wird der Job temporär erzeugt, so geht die JCL nach dem SUBMIT verloren. Eine der größten Vorteile des Dateierstellungsservice ist die Tatsache, daß alle Elemente der JCL, auch SYSIN Daten, mit Variablen versehen werden können. Dies ergibt eine sehr große Flexibilität.

Erzeugen eines temporären Jobs Der Job wird aus den

folgenden zwei Skeletons erstellt.

edit-uwin.schulung.skels(job) -

command ******

===> *****************************

01.03 .-columns 001 072 scroll ===> page fop of data *****************************

000001 //uwin217c job (998,abtdg02),'m.winter1,class=&jobclass,notify=uwin, 000002 // msgclass=&meldung ******

****************************

bottom of data

edit-uwin.schulung.skels(iefbr14)

01.03

.

-

command ******

===> *****************************

***************************

columns 001 072 ===> page

scroll top of data

*****************************

exec pgm=iefbr14 000001 //create 000002 //sysprint dd sys0ut=* dd dsn=&sysuid..&neudsn,disp=shr 000003 //dd1 ****** **************************** bottom of data

***************************

Die Variablen JOBCLASS, MELDUNG und NEUDSN können in einem Panel eingegeben werden. Die REXX EXEC verarbeitet das Panel und erstellt aus dem Skeleton einen Job, der anschließend submitted wird.

341

JCL-Schnittstellen EDIT-UWIN. SCHULUNG .EXEC (REXX025)

01 .01 .COLUMNS 001 072 SCROLL ===> PAGE ***************************** jop OF DATA -

COMMAND ******

===> *****************************

/* REXX */ /* TRACE R */ * /* / */ /* REXX ZUM AUFRUF VON SKELETON-JCL */ /* ERSTELLT WIRD EIN TEMPORAERES FILE */ /* */ /* * /* / ADDRESS ISPEXEC /* UMGEBUNG SETZEN ,* "DISPLAY PANEL(P0025)' I* PANEL ANZEIGEN 000011 IF RC 8 THEN /* BEI RC 8 HAT USER PF3 GEDRUECKT DO /* 000012 /* ALSO ENDE 000013 EXIT

000001 000002 000003 000004 000005 000006 000007 000008 000009 000010

=

END 000014 000015 "FTOPEN TEMP"

/* /*

TEMPORAERE SKELETON DATEI OEFFNEN

000016 IF RC 000017 DO

>
< 0 THEN 000026 DO "FTCLOSE"

000027 000028 000029 000030 000031 000032 000033 000034 000035

ADDRESS TSO "FREE

FI(ISPFILE),

EXIT END

•

V */ *t "/ V V */ */ */

/*

WIEDER ZUMACHEN

*/

I* I*

UMGEBUNG AUF TSO

*/

DATEI FREIGEBEN

*/

I* I*

UND RAUS

*/

/* /* /*

SKELETON MEMBER JOB ANZIEHEN

/*

*/ SKELETON MEMBER IEFBR14 ANZIEHEN

*/

RC NE 0 ==> MEMBER EXISTIERT NICHT V ALSO FEHLER */

/*

WIEDER ZUMACHEN

*/

/* /* /* /*

UMGEBUNG AUF TSO

V */ */

DATEI FREIGEBEN UND RAUS

*/

"FTCLOSE"

,* DATEI,

"VGET (ZTEMPF)" ADDRESS TSO "SUBMIT "'ZTEMPF.

t*

DIESER VGET INITIALISIERT ZTEMPF

t*

UMGEBUNG AUF TSO SETZEN UND

DIE JCL

I* JOB SUBMITTEN

ENTHAELT,

ZUMACHEN

*/ V */

*/

Der File Tailoring Service benutzt die Anweisungen FTOPEN, FTINCL(ude) und FTCLOSE. Der Job wird in einer temporären Datei mit dem DD-Namen ISPFILE abgestellt. Der VGET ist notwendig, um eine evtl. bestehende Allokation zu überschreiben. Der Job wird nur temporär erzeugt. Nach dem SUBMIT-Kommando werden die JCL-

Anweisungen gelöscht.

342

MVSESA/JCL

Erzeugen des Jobs als Member einer Bibliothek Das Skeleton ist das Gleiche wie im vorhergehenden Beispiel. In der REXX EXEC wird mit der ALLOCATE-Anweisung gearbeitet. Mit ihr wird die Bibliothek, auf die der Job gestellt werden soll, allokiert.

Die Variablen fur den Bibliotheksnamen werden vorbesetzt oder können über ein Panel eingegeben werden. Den Namen wird jeweils die USERID als erster DSN Qualifier

vorangestellt.

EDIT-UUIN.SCHULUNG.EXEC(REXX026)

01.04 -

COMMAND ******

.

===>

COLUMNS 001 072 ===> PAGE

SCROLL

*****************************

fop OF DATA

*****************************

/* REXX */ /* /* REXX ZUM AUFRUF VON SKELETON-JCL /* DATEI WIRD IN MEMBER ABGESPEICHERT /* /* /* 000008 ADDRESS ISPEXEC /* UMGEBUNG SETZEN 000001 000002 000003 000004 000005 000006 000007

*

I

*/ */ */ */ *

I

--.

000009 CLASS 000010 MSGCLASS 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020 000021 000022 000023 000024 000025 000026 000027 000028 000029 000030

Das

=

'C

/* VORBELEGUNG

*/ */

JOBKLASSE

/* VORBELEGUNG MSGKLASSE /* VORBELEGUNG BIBLIOTHEK MEMNAME 'TEST1 /* VORBELEGUNG MEMBERNAME MSGID f* MSGID INITIALISIEREN Y USERIDO /* USERID IN Y STELLEN /* DO FOREVER WIRD DURCHLAUFEN, BIS ENDE ODER PROBLEM DISPLAY DO FOREVER /* ERST WENN EINGABE O.K. KOMMT ES "DISPLAY PANEL(P0026) MSGC'MSGID")" /* ZUM JOB SUBMIT DATNAME

IF RC

=

'9'

=

1

>=

8 THEN

/*

/*

DO

EXIT

/*

PF3 GEDRUECKT ODER PROBLEM WENN JA DANN ENDE

ELSE

/*

/*

DO CALL SUCHE BIB

/* /*

*/ */ */ */ V

*/ •V */ */ */

/*

Beispiel wird auf der folgenden Seite fortgesetzt.

*/

*/

ANSONSTEN WEITERMACHEN UND PRUEFEN

JETZT IST ALLES O.K. ADDRESS TSO /* UMGEBUNG AUF TSO SETZEN "ALLOC FILECISPFILE) DA("NEUDAT") SHR REUSE" /* BIBLIOTHEK ADDRESS ISPEXEC /* UMGEBUNG WIEDER AUF ISPF "FTOPEN" /* SKELETON DATEI OEFFNEN END

*/

*/

/*

END

END

*/

SCHULUNG.CNTL'

ALLOK

*/ */ */ */ */ */

JCL-Schnittstellen 0 THEN 000031 IF RC >< DO 000032 "FTCLOSE" 000033 ADDRESS TSO 000034 "FREE FI(ISPFILE)" 000035 EXIT 000036 END 000037 000038 "FTINCL" JOB 000038 "FTINCL" IEFBR14 000039 IF RC >< 0 THEN 000040 DO 000041 "FTCLOSE"

343 /* RC NE 0 ==> FEHLER BEIM SERVICE /* ALSO FEHLER /* WIEDER ZUMACHEN /* UMGEBUNG AUF TSO /* DATEI FREIGEBEN /* UND RAUS

*/ */ */ */ */ */

/* SKELETON MEMBER ANZIEHEN */ /* SKELETON MEMBER ANZIEHEN */ /* RC NE 0 ==> MEMBER EXISTIERT NICHT */ /* ALSO FEHLER */ /* DATEI, DIE JCL ENTHAELT, ZUMACHEN */ /* UMGEBUNG AUF TSO */ /* DATEI FREIGEBEN */ /* UND RAUS */

ADDRESS TSO 000042 "FREE FI(ISPFILE)" 000043 EXIT 000044 000045 END 000046 "FTCLOSE NAMEC'MEMNAME") LIBRARY(I SP FILE)" /* NEUES MEMBER ERSTEL 000047 "VGET (ISPFILE)" /* ISPFILE INITIALISIEREN 000048 ADDRESS TSO /* UMGEBUNG AUF TSO SETZEN UND 000049 "SUBMIT"("NEUDAT")" /* JOB SUBMITTEN 000050 EXIT

000051 /* 000052 /* 000053 /* 000054 /* 000055 /* 000056 /* 000057 /* 000058 000059 000060 000061 000062 000063 000064 000065 000066

/* /* /* /* /* /* /* /* /*

.-.---.-.-.

*/ */ */ */ *

UNTERROUTINE ZUM ZUSAMMENSETZEN VON

1. BIBLIOTHEKSNAME IN LIBNAME 2. BIBLIOTHEKS- UND MEMBERNAME IN NEUDAT ANSCHLIEßEND WIRD DER STATUS GEPRUEFT. DER USER MUß EINE EXISTIERNDE BIBLIOTHEK ANGEBEN. ER KANN KEINE NEUE ANLEGEN. DER USER MUß EIN MEMBER NEU ANLEGEN. ER DARF EIN EXISTIERENDES MEMBER NICHT UEBERSCHREIBEN. -.

Das Beispiel wird auf der folgenden Seite

fortgesetzt.

*

/

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ /

MVSESA/JCL

344

000067 000068 000069 000070 000071 000072 000073 000074 000075 000076 000077 000078 000079 000080 000081 000082

000083 000084 000085 000086 000087 000088 000089 000090 000091 000092 000093 000094 000095 ******

*/

/* ZUSAMMEN SETZEN BIBNNAME UND MEMNAME '.' !! DATNAME !! '(' !! MEMNAME !! ')' = Y !! '.' !! DATNAME = X /* STATUS ERMITTELN */ SYSDSN(NEUDAT) = MSGID /* MELDUNG AUF FEHLER SETZEN */ 1MP2611

SUCHE_BIB:

NEUDAT LIBNAME

=

Y !!

/* JE NACH STATUS WIRD MELDUNG GESETZT

SELECT WHEN X

=

'DATASET NOT FOUND'

DO

MSGID

'MP264'

=

*/

THEN

/* USER HAT EINE NICHT EXISTIERENDE DATEI */ */ /* EINGEGEBEN

END WHEN X

=

'MEMBER

SPECIFIED,

BUT DATASET IS NOT PARTITIONED' THEN

DO MSGID

=

'MP265' /*

/*

END WHEN X

=

'OK'

BIBLIOTHEK ANGEGEBEN

*/ */

THEN

/*

DO MSGID

USER HAT EINE SEQUENTIELLE STATT EINER

=

'MP266' /*

STATUS O.K.

==>

MEMBER EXISTIERT UND

DIES IST EINE FEHLERBEDINGUNG

*/ */

END WHEN X = 'MEMBER NOT FOUND' THEN DO /* NUR BEI MEMBER NOT FOUND IST ALLES */ MSGID = " /* O.K. */ = 'YES' OK END OTHERWISE DO /* UNGEWOEHNLICHE FEHLERBEDINGUNG, DER ALS */ MSGID = 'MP261' /* SYSTEMFEHLER AUSGEGEBEN WIRD */ END END RETURN **************************** BOTTOM OF DATA ***************************

Der FTCLOSE stellt den Job auf die unter ISPFILE allokierte Datei. Die Routine setzt den DSN und den DSN(memname) zusammen und prüft den Status ab. Dieser muß 'MEMBER NOT FOUND' sein, da der User keine Überschreibung eines existierenden Members machen soll.

Erzeugen des Jobs aus mehreren SKEL Membern Aus den

folgenden drei Skeletons wird durch die REXX EXEC ein Job erzeugt:

345

JCL-Schnittstellen EDIT-UWIN.SCHULUNG.SKELS(JOB) COMMAND ******

-

01.00

.

COLUMNS 001 072 ===> PAGE

SCROLL

===> *****************************

yep OF DATA

*****************************

000001 //UWIN217C JOB (998,ABTDG02),'M.WINTER 1,CLASS=&CLASS,NOTIFY=UWIN, 000002 // MSGCLASS=&MSGCLASS ******

****************************

BOTTOM OF DATA

01.00

edit-uwin.schulung.skels(del)

***************************

.

-

command ******

===> *****************************

top of data

columns 001 072 scroll ===> page

*****************************

exec pgm=idcams

000001 //delete 000002 //sysprint dd sys0ut=* 000003 //sysin dd * delete &neudsn 000004 ******

****************************

bottom of data

***************************

Beachten Sie, daß es selbst bei der Benutzung von Prozeduren unmöglich wäre, in der SYSIN DD * Anweisung eine Variable aufzunehmen. In der REXX EXEC ist dies möglich, weil Zeile fur Zeile interpretiert wird. 01.00

edit-uwin.schulung.skels(alloc) -

command

.

===>

******

*****************************

000001 000002 000003 000004

//alloc

exec pgm=iefbr14

//neu1

dd

******

****************************

// //

top of data

columns 001 072 scroll ===> page

*****************************

dsn=&neudsn,disp=(,catlg,delete), space=(trk,(5,1)), unit=&unit,recfm=fb,lrecl=&laenge bottom of data

***************************

Die folgende REXX EXEC verarbeitet ein Panel, setzt den DSN neu zusammen die USERID muß vorangestellt werden und ruft den Dateierstellungsservice auf. Dort werden alle drei Skeletons nacheinander aufgerufen und zu einem Job zusammen gebunden: -

-

346

MVSESA/JCL

edit-uwin.schulung.exec(rexx027)

01.00

.

-

command

columns 001 072 ===> page

scroll

===>

******

*****************************

000001 000002 000003 000004 000005

/* /* /* /* /*

000006 000007 000008 000009 000010 000011 000012 000013 000014 000015 000016 000017 000018 000019 000020

address ispexec = class 'c = msgclass '9'

rexx

top of data

*****************************

*/ *

/ */ */ */

rexx zum aufruf von skeleton-jcl erstellt wird ein temporaeres file .

000021 000022 000023

= unit 1sysda 1 "display panel(p0027)" if rc = 8 then

do exit

umgebung setzen

I* r t*

jobklasse initialisieren msgclass initialisieren panel anzeigen

t*

bei rc 8 hat user pf3 gedrueckt

i* i*

also ende

i* /* /* /*

x

= userido neudsn = x ! ! 1 "ftopen temp" if rc >< 0 then


< 0 then 000029 do

******

/*

*/ */ *l */ */

*/ */ userid reinholen */ dsn zusammensetzen */ temporaere skeleton datei oeffnen */ rc ne 0 */ */ wieder zumachen */ umgebung auf tso */ datei freigeben V und raus */

I* /* /* /* /* /*

*/ */

skeleton member für jobkarte skeleton member für delete skeleton member für neue datei

*/ V

==>

*/ */ member existiert nicht */

also fehler

*/

/* wieder zumachen /* umgebung auf tso I* datei freigeben

*/ V

****************************

r:' /* I* /* /* /*

rc ne 0

und raus

datei, die jcl enthaelt, zumachen dieser vget initialisiert ztempf umgebung auf tso setzen und job submitten

bottom of data

*/

*/ */ */ */ */ */

***************************

JCL-Schnittstellen

7.4

347

TSO-Kommandos mit JCL absetzen

Jedes TSO-Kommando läßt sich auch mit JCL absetzen. Dazu bedarf es des Aufrufs des Programmes IKJEFT01, welches TSO im Hintergrund aufruft. Dieses Programm benötigt einige spezielle DD-Anweisungen mit besonderen DD-Namen. Es handelt sich dabei um die SYSTSPRINT-Anweisung. Sie entspricht der SYSPRINT-Anweisung bei Utilities und der SYSTSIN-Anweisung, die'der SYSIN DD-Anweisung entspricht. Auf die Anweisung SYSTSIN DD * folgen die TSO-Kommandos. Das folgende Beispiel zeigt das Absetzen eines HLIST-Kommandos. Dies ist ein HSM-Kommando, das die vorhandenen Backups für ein Dataset anzeigt. 01.06

edit-uwin.schulung.cntl(hlist)

.

-

command

===>

*****************************

******

top of data

columns 001 072 scroll ===> page

*****************************

000100 //uwinlist job (uwin,abtdg02),notify=uwin, 000200 // class=c,msgclass=9 000300 //step1 exec pgm=ikjeft01 000400 //systsprt dd sysout=* 000500 //systsin dd * 000600 hlist dataset('uwin.schulung.test 1 ) bcds sys0ut(9) ******

****************************

Im Job

Summary erscheinen die Felder SYSTSPRT und SYS00001:

.-.-.

command

bottom of data

iof job summary

****************************

.-.-.

===>

scroll

===>

screen

--jobname--jobid--status---ran/received-day.de st.copies. uwin217h j29514 output 14:01 5/29/92 today fra21 1 -rc- -step.procstep--proc.comments.---.-

recover

0

.ddname-step.stat-act-grp-cls--records--dest.forms-copies 1

log

*

held

2 3 4 5

jcl

*

held

messages

*

held

systsprt recover

held

sys00001 recover

held

9 9 9 9 9

15 6

30 4 13

SYSTSPRT enthält das erzeugte TSO-Kommando. SYS00001 ist ein generierter DDName, der den Output des TSO-Kommandos enthält. Durch die Angabe SYSOUT(9) wurde ein Umleiten des Outputs in das Job Menü erzwungen. Ansonsten wäre der am Bildschirm zu sehen gewesen:

Output

348

MVSESA/JCL

BROWSE COMMAND

PAGE

RECOVER

SYS00001 -

1-- LINE

--

===>

********************************

DFHSM CONTROL DATASET

-pop OF DATA

**********************************

BACKUP DATASET-- LISTING

-

1- COLS 1 80 SCROLL ===> SCREEN

-

AT 14:00:12 ON

92/05

-

DSNAME

=

BACKUP FREQ

UWIN.SCHULUNG.DS99

BACKUP VERSION DATA SET NAME

BACKUP

HSM.BACK.T005001.UWIN.SCHULUNG.12101 HSM.BACK.T451802.UWIN.SCHULUNG.12100

BACKUP

SYS

GEN

VERS

BACKUP

CAT

NMBR

NMBR

RET VERS

RACF

DATE

IND

PROF

92/04/10 92/04/09

YES

000 001

022

NO

NO

NO

021

NO

NO

NO

YES

END OF .

BACKUP DATASET -

********************************

LISTING

VOLUME

FROM VOLUME

729882 708771

DSK029 DSK029

=

000,

MAX BA

.

-

BOTTOM OF DATA

*******************************

8

JCL-Fehler und ABENDs

Die Interpretation von JCL-Fehlern ist manchmal tückisch. In diesem Kapitel sollen einige häufig vorkommende JCL-Fehler vorgestellt und die Meldungen erläutert werden.

Fehler in der JOB-Anweisung Fehler in der Job-Anweisung können dazu führen, daß der SUBMIT mißlingt. Wenn Sie nach dem SUBMIT einen Prompt mit der Aufforderung: ENTER JOBNAME CHARACTERS erhalten, dann geben Sie irgend etwas ein und drücken die Datenfreigabetaste. Der danach submittete Job wird sofort abstürzen.

Häufigste Ursache für dieses Vorkommnis sind Fortsetzungsfehler: ***************************** tqp of data 000001 //uwin217c job (uwin,abtdg02),'m.winter1, 000002 // class=b, 000003 // msgclass=y, 000004 // notify=uuin, 000005 //define exec pgm=idcams dd 000006 //sysprint sys0ut=* ******

*****************************

000007 //sysin dd * 000008 delete uwin.schulung.output.seq1 000009 if maxcc = 8 then set maxcc = 0 ******

***************************

bottom of data

***************************

Da nach dem NOTIFY=UWIN ein Komma

steht, wird die Zeile 5 als zur Job-Anweisung betrachtet. Dies führt daß die dazu, gehörend Job-Anweisung korrumpiert wird und nicht mehr als solche interpretiert werden kann. Sofern Sie Schlüsselwörter der JOB-Anweisung fehlerhaft geschrieben haben, erhalten Sie eine entsprechende Meldung, die leicht zu interpretieren ist.

Fortsetzungsfehler Um

Fortsetzungsfehler interpretieren zu können, müssen Sie unbedingt in die JCL des Jobs schauen, denn dort sehen Sie die Numerierung, auf die sich die Messages beziehen. Hier ein Job, wie er in der Bibliothek steht.

MVSESA/JCL

350 000001 //UWIN217B JOB (998,ABTDG02),'M.WINTER',NOTIFY=UWIN, 000002 // CLASS=B, 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012

MSGCLASS=Y,

// // //

TIME=(,10), MSGLEVEL=(1,1)

MSGLEVEL=(1,1),TYPRUN=SCAN

//* //STEP1

EXEC PGM=PGM01 //STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSABOUT DD SYSOUT=* DD SYSOUT=* //SYSOUT //OUTFILE DD DSN=UWIN.SCHULUNG.DS91, 000013 // DISP=(,CATLG,DELETE) 000014 // UNIT=3380, 000015 // SPACE=(TRK,(15,10),RLSE), 000016 //_RECFM=FB, LRECL=80_

Der gleiche Job, diesmal mit der erzeugten Numerierung: 1 //UWIN217B JOB

(998,ABTDG02),'M.WINTER1,NOTIFY=UWIN,CLASS=B,MSGCLASS=Y TIME=(,10),MSGLEVEL=(1,1),USER=UWIN MSGLEVEL=(1,1),TYPRUN=SCAN

// ***

2 //STEP1 3 //STEPLIB 4 //SYSPRINT 5 //SYSABOUT 6 //SYSOUT 7 //OUTFILE

// 8 // 9 //

EXEC PGM=PGM01 DD

DSN=UWIN.SCHULUNG.LOAD,DISP=SHR,

DD SYSOUT=* DD SYSOUT=* DD SYSOUT=* DD DSN=UWIN.SCHULUNG.DS91,

DISP=(,CATLG,DELETE)

UNIT=3380, SPACE=(TRK,(15,10),RLSE),

_10 //_RECFM=FB, LRECL=80_ Die

folgenden Fehlermeldungen beziehen sich auf die vorangehende Numerierung: MESSAGES

BROWSE

*

-

COMMAND

PAGE

1-- LINE

1-- COLS

1

80

--

===>

SCROLL

********************************

fop OF DATA

===>

SCREEN

**********************************

STMT NO. MESSAGE

3 8 9 10

IEF621I IEF605I IEF605I IEF605I

EXPECTED CONTINUATION NOT RECEIVED UNIDENTIFIED OPERATION FIELD UNIDENTIFIED OPERATION FIELD UNIDENTIFIED OPERATION FIELD

*******************************

BOTTOM OF DATA

********************************

JCL-Fehler und ABENDs

351

Die erste Meldung ist leicht zu interpretieren. Man findet schnell heraus, daß hinter dem DISP=SHR kein Komma stehen darf, weil die Anweisung an dieser Stelle beendet werden muß. Die Meldungen fur die Anweisungen 8-10 sind ebenfalls Fortsetzungsfehler. Sie sind Folgefehler der Anweisung 7 DISP=(,CATLG,DELETE), bei der am Ende das Komma vergessen wurde. Aus diesem Grund wird Anweisung 8 als neue Anweisung interpretiert. Sie besitzt keinen Feldnamen (das ist zulässig), aber das erste auftauchende Wort UNIT=3380 wird als Operationsfeld interpretiert. Da es nicht JOB, EXEC, DD, PROC, PEND oder OUTPUT heißt, wird es als fehlerhaft gemeldet. Danach wird versucht, Zeile 9 als JCL-Anweisung zu interpretieren. Das Ergebnis ist das Gleiche.

Häufige Laufzeitfehler gibt eine Reihe von Laufzeitfehlem, die schwierig wichtigsten von ihnen werden jetzt vorgestellt. Es

//STEP1 //STEPLIB //SYSABOUT //INFILE //OUTFILE // // // //

zu

interpretieren

sind. Die

EXEC PGM=PGM01 DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR DD SYSOUT=* DD DSN=UWIN.SCHULUNG.DS99 DD

DSN=UWIN.SCHULUNG.DS91,

DISP=(,CATLG,DELETE), UNIT=DSKPRM,

SPACE=(TRK,(15,2),RLSE), RECFM=FB,LRECL=80

Wie Sie sehen, fehlt bei dem unter INFILE angesprochenen Dataset der DISP-Parameter. Beim Job-Lauf dieser JCL tritt folgender Laufzeitfehler auf: UNIT FIELD SPECIFIES INCORRECT DEVICE NAME IEF210I UWIN217B STEP1 INFILE STEP WAS NOT EXECUTED. IEF272I UWIN217B STEP1 -

-

Um diese Meldung zu verstehen, muß man fast schon die Ursache kennen. Da der DISP-Parameter fehlt (was die Ursache des Fehlers ist ), tritt der Default DISP=(NEW,DELETE,DELETE) an seine Stelle. MVS geht davon aus, daß das Dataset neu angelegt werden soll. Beim Anlegen eines Dataset muß aber immer der UNITParameter angegeben werden. Da dieser in der oben angegebene JCL logischerweise fehlt, wird dies als Fehler moniert. Leider nicht in der Form: MISSING UNIT PARAMETER, sondern in der Form, wie sie die Meldung zeigt. Wenn Sie den Parameter VOL=SER= verwenden, können folgende Situationen auftreten: IEF245I UWIN217B STEP1 OUTFILE INCONSISTENT UNIT NAME AND VOLUME SERIAL STEP WAS NOT EXECUTED. IEF272I UWIN217B STEP1 -

-

MVSESA/JCL

352

Diese

Meldung wurde beim folgenden Job erzeugt: 1 //UWIN217B JOB

// ***

(998,ABTDG02),'H.WINTER1,NOTIFY=UWIN,CLASS=R,MSGCLASS=Y TIME=(,10),MSGLEVEL=(1,1),USER=UWIN MSGLEVEL=(1,1),TYPRUN=SCAN

EXEC PGM=PGM01 //STEP1 DD //STEPLIB DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=*

2 3 4 5 6

//SYSABOUT //SYSOUT 7 //OUTFILE // // // //

DD SYSOUT=* DD SYSOUT=*

DD

DSN=UWIN.SCHULUNG.DS91,

DISP=(,CATLG,DELETE),

UNIT=3380,VOL=SER=DSK021, SPACE=(TRK,(15,10),RLSE), RECFM=FB,BLKSIZE=23440,LRECL=80

*******************************

BOTTOM OF DATA

********************************

versucht, ein Dataset auf der Platte DSK021 anzulegen. Diese Platte ist aber vom im UNIT-Parameter steht UNIT=3380. Wenn Sie UNIT und VOL=SER 3390, Typ gleichzeitig benutzen, so stellen Sie sicher, daß Typ und Platte zusammenpassen. Es wurde

Auf ein ähnliches Problem weist die

folgende Meldung hin:

UNABLE TO ALLOCATE IEF702I UWIN217B STEP1 OUTFILE IEF272I UWIN217B STEP1 STEP WAS NOT EXECUTED. -

-

In diesem Fall gehört die Platte DSK021 nicht zur Gruppe SYSDA. Daher kann MVS das Volume nicht allokieren, was sich in der Fehlermeldung niederschlägt. 7 //OUTFILE // // // //

DD

DSN=UWIN.SCHULUNG.DS91,

DISP=(,CATLG,DELETE),

UNIT=SYSDA,VOL=SER=DSK021, SPACE=(TRK,(15,10),RLSE), RECFM=FB,BLKSIZE=23440,LRECL=80

*******************************

BOTTOM OF DATA

********************************

Unsichtbare Fehler Es gibt Fehler, die sich weder in einem Fehler niederschlagen:

syntaktischen

noch in einem Allokations-JCL-

353

JCL-Fehler und ABENDs

EXEC PGM=PGM01 //STEP1 //STEPLIB DD DSN=UWIN.SCHULUNG.LOAD,DISP=SHR //SYSABOUT DD SYSOUT=* DD DSN=UWIN.SCHULUNG.DS99,DISP=SHR //INFILE //OUTFILE DD DSN=UWIN.TEST, DISP=(,CATLG,DELETE), UNIT=DSKPRM, // SPACE=(TRK, (15,2) ,RLSE) // RECFM=FB,LRECL=80 // ,

Durch den Blank zwischen dem DSN- und dem DISP-Parameter wird die DISP-Angabe als Kommentar interpretiert. Daher greift der Default DISP=(NEW,DELETE,DELETE). Das Dataset UwTN.TEST wird also bei Step-Ende immer gelöscht, und dies ist mit Sicherheit nicht die Absicht des Users gewesen. Dieser logische Fehler macht sich nicht bemerkbar.

8.1

ABEND Codes

Hier werden

eingegangen.

einige häufig vorkommenden ABENDs

erläutert und auf mögliche Ursachen

ABEND Codes 001 bis 04F Die ABEND Codes ABEND Code

001

von

001 bis 04F sind sogenannte Data

Management ABENDs.

Bedeutung I/O Problem. Prüfen Sie ob BLKSIZE ein mehrfaches der LRECL ist. fehlt eine DD-Anweisung oder man hat sich verschrieben (Der DD-Name im Programm entspricht nicht dem in der JCL).

Möglicherweise

002

siehe 001

0C1

Operation Exception Häufigste Ursache: Falsche oder fehlende DD-Anweisungen.

354

MVSESA/JCL

ABEND Code

Bedeutung

0C4

Protection

Exception

Ein Zugriff auf eine Adresse des virtuellen Speichers, die nicht im Bereich des Programms liegt, wurde versucht. Häufige Ursache sind überlaufende Tabellen. Aber auch der Lesezugriff auf ein noch nicht geöffnetes Dataset kommt in Frage. Während dieser ABEND in Batch-Umgebungen noch harmlos ist, sieht die Sache bei IMS oder CICS ganz anders aus. Da diese Anwendungen in einer eigenen Region laufen, kann ein 0C4 eine komplette IMS-Region oder ein komplettes CICS 'abschießen'.

0C5

Addressing Exception Die Adresse im virtuellen

Speicher ist nicht zugänglich.

Mögliche Subskripte,

Ursachen:

die über dem Maximum liegen oder überlappende Tabellenbereiche. Falsche Daten-Definition in der LINKAGE SECTION, falsche Reihenfolge von Parametern, die übergeben werden, falsche

zugewiesene Parameterlänge. Arithmetische Operationen auf nicht initialisierten Feldern. 0C6

Specification Exception Gültige Instruktion aber ungültige Parameter. Mögliche Ursachen: Falsche Ausführung eines PERFORM. I/O-Bereiche wurden angesprochen, bevor es

zu

einem OPEN oder

READ kam.

Falsche LINKAGE SECTION.

Falsche Angabe

von

Recordlängen bei variabel langen Records.

Versuch auf eine Datei zu

0C7

Data Exception

schreiben, die mit INPUT eröffnet wurde.

355

JCL-Fehler undABENDs ABEND Code

Bedeutung Der bei weitem häufigste ABEND. Instruktionen und Parameter sind in Ordnung, aber das Format der Daten stimmt nicht (Meist steht auf numerisch definierten Feldern Unfug):

Mögliche Ursachen: Falsche oder fehlende Initialisierung eines numerischen Feldes. Falsche oder fehlende USAGE-Klausel. Falsche LINKAGE SECTION.

Felder, die Zahlen enthalten sollten, sind 'blank'. Literale im Literal Pool wurden zerstört.

Falsche REDEFINES-Klausel. Absichtlich, wenn man einen ABEND erzwingen will, verhindern, daß ein Folgeprogramm angestoßen wird.

um

z.B.

zu

ABEND Codes 100 bis EFF Die ABEND Codes von 100 bis EFF weisen auf Probleme bei der Ausführung von Supervisor Calls (SVC) hin. Die letzten beiden Zeichen geben den jeweiligen SVC (in Hex) an.

ABEND Code

Bedeutung

x00

Probleme beim Ausführen eines Kanalprogramms schwerwiegendes I/O-Problem aufgetreten.

x04, x05, xOA

Probleme beim Anfordern oder Freigeben von virtuellem Speicher (dürfte bei MVS/ESA kaum passieren, Ausnahme sind 24-Bit Programme). Kann auch passieren, wenn man mit dem REGIONParameter mehr an virtuellem Speicherplatz anfordert, als man benutzen darf.

806

Modul Lade-Probleme. Sie versuchen ein Programm auszuführen, daß sich nicht auf einer Ladebibliothek befindet. Möglicherweise ist ein falscher Programmname angegeben worden.

xOB

Timer Problem, das z.B. bei einem

xl3

Probleme beim Öffnen eines Dataset. Die

(SVC 0).

Es ist ein

Checkpoint Restart auftreten kann.

Endung

13 weist auf den

MVS ESA/JCL

356

ABEND Code

Bedeutung 19. SVC hin

(Hex

13

=

19). Häufig kommen vor:

013

Fehler beim Ausführen eines OPEN-Makros. Diese ausführlicher in Messages und Codes IEC143I erläutert.

213

Fehler beim Ausführen eines OPEN-Makros für ein Dataset, das auf Platte steht.

413

Fehler beim Ausführen eines OPEN-Makros für ein Dataset, das auf Platte oder auf Band steht. Diese Meldung ist ausführlicher in Messages und Codes IEC145I erläutert.

813

Falsche Angabe für eine Band- oder Kassettendatei, die geöffnet werden soll. Diese Meldung ist ausführlicher in Messages und Codes IEC149I erläutert.

xl4

Probleme beim Schließen von Dateien. Möglicherweise wurde ein CLOSE vergessen. Wirkt sich im Step meist nicht mehr aus, kann aber Folge-Steps beeinflussen.

x37

Fehler beim Ausführen eines End-of-Volume-Makros. Dies weist auf Platzprobleme hin. D37 weist darauf hin, daß der Platz für die Primärallokation erschöpft ist und keine Sekundärallokation gemacht wurde. B37 weist darauf hin, daß die Secondary Extents erschöpft sind.

222

Job wurde gecancelt. Entweder von Ihnen, vom automatisch. Ursache: Häufige Loop

Meldung

Operator in

ist

oder einem

Anwendungsprogramm. 322

Zulässige

522

ISPF-Sitzung wurde automatisch beendet. Dieser Fall tritt ein, Sie längere Zeit keinerlei Aktion am Terminal ausführen. Das ist installationsspezifisch.

722

CPU-Zeit wurde überschritten. Dies bezieht sich entweder auf die Job-Klasse oder einen TIME-Parameter in der JCL. Diese Situation kann ebenfalls auf einen Loop hinweisen. wenn

Limit

Anzahl von Output-Zeilen für SYSOUT wurde überschritten. Bezieht sich auf den OUTLIM-Parameter oder das

Zulässige

JCL-Fehler und ABENDs ABEND Code

357

Bedeutung Limit, das für die MSGCLASS gilt. Auch hier kann die Ursache ein Loop sein.

ABEND Codes xFO bis xFF Die ABEND Codes

von

xFO bis xFF weisen auf System- bzw. JES2/JES3-Fehler hin.

ABEND Codes Fxx bis FFF Die ABEND Codes von Fxx bis FFF stehen in Nummer des User-SVCs.

Zusammenhang mit User-SVCs.

xx

ist die

Anhang

9 Im

folgenden Anhang

werden

beschrieben.

9.1

wichtige physische Kenngrößen

MVS-Systemen

Aufbau von Volume und Header Records

Wenn Sie ein unbekanntes Band/Kassette lesen

wollen,

so

können Sie den Header Records

wichtige Informationen entnehmen. Aufbau des Volume Record Name des Feldes

Länge

Inhalt VOL

Identifikationsfeld Labelnummer

Volume Serial Nummer

000000 999999 -

Reserviert

Aufzeichnungstechnik

24

Reserviert Owner Identification

blank

in

29

Pb oder bb

MVSESA/JCL

360

Aufbau der Header Records 1 Name des Feldes

Länge

Inhalt

Identifikationsfeld

HDR, EOF, EOV

Labelnummer

1

Data Set Identifier

17

die 17 rechten Stellen des DSN

Data Set Serial Number

000001 -999999

Volume

0001 -9999

Sequence Number Data Set Sequence Number Generation Data Set Sequence Number

0001

Generation Version Number

00-99

Creation Date

&

cyyddd cyyddd 0, 1 oder 3

Block Count

blank

9999

0001 -9999

Expiration Date Data Set Security Indicator reserviert

-

13

Anhang

361

Aufbau der Header Records 2

Bytes

Name des Feldes

Mögliche Werte HDR, EOF, EOV

Identifikationsfeld Label-Nummer

F, V oder U

Record-Format Block-Size oder Block-Faktor

00000 32760

Logische Record-Länge

-

Schreibdichte Data Set Position Number

0 oder 1 17

Job-Name/Step-Name

Aufzeichnungstechnik Kontrollbyte

Pb oder bb

A, M oder b

blank

B, S, R oder b

Block-Attribut 41

Reserviert

Die Werte im Feld:

Pb -

bb -

Aufzeichnungstechnik haben folgende Bedeutung:

kompaktes Format (bis 750 MB) normales 3480-Format (250 MB)

Das Format der Felder: Creation Date und aufzulösen: c

=

blank

>

Expiration

19

>20 0=1

yy kann von 00 bis 99

>21

reichen, ddd von 000 bis 366.

Date

cyyddd

ist wie

folgt

MVSESA/JCL

362

Die Werte im Feld: Data Set

Security haben folgende Bedeutung:

kein Passwortschutz

Passwortschutz für Lesen, Schreiben und Löschen Passwortschutz für Schreiben und Löschen Die

Optionen

1 und 3 haben unter RACF keine

Bedeutung.

Die Werte im Feld: Record-Format bedeuten: F Undefinierte Länge.

-

fixe

Länge,

V

-

variable

Länge und U -

Die Werte im Feld: Block-Attribut bedeuten: S

geblockte Records Spannrecords, wenn das Feld Record-Format 'V ist

S

Standardrecords, wenn das Feld Record-Format 'F' ist

R

geblockte Spannrecords, wenn das Feld Record-Format 'V ist geblockte Standardrecords, wenn das Feld Record-Format 'F' ist.

B

R

Um die Volume und Header Records lesen zu können, müssen Sie mit arbeiten. Sie erhalten dann beim Lesen diese drei Records.

LABEL=(1,BLP)

Steht mehr als ein Dataset auf dem Band/der Kassette, so lesen Sie die Informationen für das zweite Dataset mit LABEL=(4,BLP), für das dritte mit LABEL=(7,BLP) usw.

363

Anhang

Nutzungsraten unterschiedlicher BLKSIZEs

9.2

Nutzungsraten verschiedener Plattenträger für ausgewählte Blocksizes Modell

3375

3380

3390

19069

47476

56664

Nutzung

Nutzung

Nutzung

13,99% 64,14% 91,63% 79,20% 96,89% 78,99% 73,72% 77,70% 98,96% 58,98% 75,02% 100,00% 0,00%

10,73% 56,81% 92,12% 82,95% 81,18% 88,24% 92,65% 97,65% 82,92% 98,82% 62,85% 83,79% 100,00%

3350

Kapazität/Spur BLKSIZE 80 870 8700

9400 11500 12500 17500 18444

23492 27999 35616 47476 56664'

30,21% 82,12% 91,25% 98,59% 60,31% 65,55% 91,77% 96,72% 0,00% 0,00% 0,00% 0,00% 0,00%

16,17% 68,40% 73,28% 79,18% 96,87% 70,19% 98,27% 51,79% 65,96% 78,61% 100,00% 0,00% 0,00%

'Diese Blocksizes sind mit normalen

Zugriffsmethoden nicht erreichbar I

!

364

9.3

MVSESA/JCL

CI-Größe und Plattennutzung Spurgröße: 47476 Byte CIs pro Physische

3380

Record-Größe 512 1024

Spur

46 31

1536 2048 2560 3072

23

3584 4096 4608

11

5120

8

5632 6144 6656

7

6

7168

6

7680 8192 10240 6144 14336 8192

5

18 15 13

10 9

7

5 4

7 3 5

6144

7

20480 22528 6144 6656 14336 6144 8192

2

2 7

6 3 7 5

Lücke: 492

Byte

Nutzung in% 49.61%

66,86% 74,41% 77,65% 80,88% 84,12% 83,04% 86,28% 87,35% 86,28% 83,04% 90,59% 84,12% 90,59% 80,88% 86,28% 86,28% 90,59% 90,59% 86,28% 90,59% 86,28% 94,90% 90,59% 84,12% 90,59% 90,59% 86,28%

365

Anhang Plattentyp: 3390 Spurgröße: 56664 Byte Lücke: 666 Byte

Physische RecordGröße

CIs pro

Spur Nutzung in%

512

49

44,28%

1024 1536

33 26

2048

21

2560

17

3072

15

3584

13

59,64% 70,48% 75,90% 76,80% 81,32% 82,23%

4096

12

4608

10

5120

9

5632

9

6144

8

6656

7

7168

7

7680

6

8192

6

10240

5

12288

4

7168

7

16384 18432 10240

3 3

5632

9

24576

2

26624

2

7168

7

10240

5

16384

3

5

86,74% 81,32% 81,32% 89,45% 86,74% 82,23% 88,55% 81,32% 86,74% 90,36% 86,74% 88,55% 86,74% 97,59% 90,36% 89,45% 86,74% 93,97% 88,55% 90,36% 86,74%

366

9.4

MVSESA/JCL

Glossar

3380

Plattenspeicher.

3880

Storage Control Unit für Magnetplatten des Typs 3380.

3390

Plattenspeicher.

3990

Storage Control Unit für Magnetplatten des Typs 3380 und

3390.

3480

Magnetkassette.

3745

Communication Controller

-

bindet Terminals

an

das

System

an.

9000

Neueste Prozessorreihe für IBM-Mainframes.

ABEND

ABnormal END. Abbruch eines Programms nicht-ausführbaren Instruktion.

ACB

Access Control Block. Ist für VSAM-Datasets DCB für sequentielle Datasets ist.

Access Method

Zugriffsmethode. Für die verschiedenen Datasetformen gibt es unterschiedliche Methoden, die den Zugriff unterstützen. Am

aufgrund

das,

einer

was

der

bekanntesten sind QSAM und VSAM. ACS

Automatic Class Selection. Automatische Klassen-Selektion. Routine, die unter SMS Datasets aufgrund bestimmter DSNMerkmale zu Speicher-, Daten- und Managementklassen zuordnet.

367

Anhang AIX

Altemate IndeX. Einrichtung für Altemativschlüssel bei VSAM KSDS- und ESDS-Datasets.

Wird auch als benutzt.

Allokation

Bezeichnung für die UNIX-Variante

Phase des Step-Ablaufs. Vor der dem Programm die benötigten

von

IBM

Programmausführung werden physischen Ressourcen zur

Verfügung gestellt. AMP

Access Method Parameter.

VSAM-Dataset-Verarbeitung AMS

Access Method Services.

Utility-Programm

Spezieller

DD-Parameter für

im Batch.

Zugriffsunterstützung,

IDCAMS

die durch das

geboten wird.

ASCII

American Standard Zeichensatz für PCs.

ASP

Asynchronous Spooling Program. Vorgänger des JES3.

Auxiliary Storage

Hilfsspeicher auf Platte als Erweiterung des Hauptspeichers.

BETA-92

Vielerorts

Bibliothek

Form der Datasetorganisation, bei der das Dataset in viele kleine Teile (Member) aufgegliedert ist. Editiert wird immer das Member. JCL wird fast ausschließlich als Member einer Bibliothek vorgehalten.

BLP

Bypass Label Processing. Label-Verarbeitung umgehen.

Code

of Information

Interchange.

eingesetztes Output-Management-System.

Wenn die Volume- und Header-Records eines Bandes/einer Kassette gelesen werden sollen, ist diese Angaben im LABEL-

MVSESA/JCL

368 Parameter erforderlich. Die unter Umständen

Benutzung dieses

Parameters kann

eingeschränkt sein.

Buffer

Platz im Speicher zur Aufnahme von Records. Records die im Buffer stehen, brauchen nicht von der Platte gelesen zu werden. Dies ergibt einen erheblichen Zeitgewinn. Beim Schreiben von Records wird erst in die Buffer geschrieben, anschließend auf Platte.

Cache

Zwischenspeicher, den es in den IBM-Systemen auf fast allen Ebenen gibt. So gibt es zum Beispiel einen CPU-Cache, in dem

Instruktionen äufbewahrt werden. Die Plattencontroller (SCUs) besitzen ebenfalls einen Cache. Er speichert vor und hilft somit, physische I/Os zu reduzieren. CA

Control Area. Zusammenfassung mehrerer CIs in einem VSAM KSDS-Dataset.

canceln

Neudeutscher Ausdruck für das Abbrechen eines Jobs. Ein Job kann automatisch, durch den Operator oder durch den User gecancelt werden.

CA-Split

Teilen einer CA. Kann beim Einfügen von Records in ein VSAM KSDS-Dataset auftreten und ist ein sehr I/O-intensiver

Vorgang. Channel

CI

Subsystem

Subsystem, das für die Abwicklung aller I/Os zuständig ist. I/Os werden von der CPU nur initiiert und wieder entgegengenommen. Die Durchführung des I/Os ist Sache des Channel Subsystem, das sich selbständig den Weg zum Datenträger und zurück zur CPU sucht. Control Interval. Physischer Record eines VSAM-Datasets. Enthält die logischen Records und Kontrollinformationen.

Anhang

369

CI-Split

Teilung eines CI. Kann beim Einfügen von logischen Records auftreten. Ist weniger I/O-intensiv als ein CA-Split.

CICS

Customer Information Control System. On-Line-System, in dem nur VSAM-Datasets als Organisationsform zulässig sind. Wird auch als Trägersystem für DB2 genutzt.

CIDF

Control Interval Definition Field. Enthält Informationen über Position und Umfang von freiem Platz in einem CI.

CLIST

Command LIST.

Interpretersprache, Vordergrund ermöglicht.

Cluster

Bezeichnung für ein VSAM-Dataset und alle zugehörigen Komponenten (Pfade, AIX, usw.).

CPU

Central Processing Unit.

Cylinder

Summe

der

übereinander Bei Platten des

Magnetplatte. Cylinder 15 Spuren.

die eine

Verarbeitung

im

liegenden Spuren auf einer Typs 3380 und 3390 umfaßt ein

DASD

Direct Access

Data

Nur-Daten Raum. Bezeichnung für einen maximal 2 GB großen Bereich des virtuellen Speichers, der unter MVS/ESA verfügbar wurde. Ein Data Space ist byte-adressierbar und vom normalen Adreßraum völlig getrennt.

Space

Storage Device. Plattenspeicher.

DB2

Data Base 2.

DCB

Data Control Block. Kontrollblock, der die physischen Eigenschaften von PO- und PS-Datasets beschreibt. Dies umfaßt z.B. Record-Länge, Record-Format, Blocksize usw.

Datenbanksystem.

MVSESA/JCL

370 DD

Data Definition.

Deallokation

Nach der Programmbeendigung werden die vom Programm benutzten physischen Ressourcen wieder freigegeben.

DFHSM

Data Facility Hierarchical Storage Manager. Softwarepaket, das der Archivierung (Migration) und Sicherung (Backup) von Datasets dient. -

DFP

Data Facility Product.

Directory

Verzeichnis einer Bibliothek.

Directory Blocks

Kontrollblöcke, die das Verzeichnis einer Bibliothek

Displacement

Abstand in

DMS

Dialog Management Services.

EBCDIC

Extended

ESDS

Entry Sequenced Data Set. Sequentielles VSAM-Dataset.

EXCPS

EXexecuted Channel Programs. Ausgeführte Kanalprogramme. Feld im LISTCAT eines VSAM-Dataset, das Auskunft über die Zahl der physischen I/Os gibt.

Expanded Storage

Halbleiterspeicher,

aufnehmen.

Byte von einer definierten Adresse.

Binary Coded Decimal Interchange Großsystemen verwendeter Zeichensatz.

Code. Auf

der als Erweiterung des Hauptspeichers dient und einen sehr schnellen Austausch mit demselben

ermöglicht.

Anhang Extent

371

Teil eines Dataset. Sequentielle Datasets können bis zu 16, VSAM-Datasets aus bis zu 123 Extents bestehen.

Physischer aus

Frame

4K großer Block im

Freespace

Freier Platz in einem CI eines KSDS-Dataset, der Aufnahme weiterer logischer Records zur Verfügung steht.

FTS

File

Tailoring

Hauptspeicher.

Services.

Dialog Managers. HASP

Houston Automatic JES2.

Header Record

Kontroll-Record, der

HI-ALLOC-RBA

Dateierstellungsservice

Spooling Program.

zur

des ISPF

Vorläufer des

heutigen

vor den Daten eines Dataset auf Band oder Kassette steht und Informationen über das Dataset enthält. Es gibt zwei Header Records mit den Nummern 1 und 2.

HIgh-ALLOCated-Relative-Byte-Address.

Höchste allokierte

Adresse eines VSAM-Dataset.

Hiper Space

High Performance Space. Nur-Daten Raum. Bezeichnung für einen maximal 2 GB großen Bereich des virtuellen Speichers, der unter MVS/ESA verfügbar wurde. Ein Hiper Space ist blockweise adressierbar und vom normalen Adreßraum völlig getrennt. Er kann als Hauptspeichererweiterung genutzt werden.

HI-USED-RBA

Hlgh-USED-Relative-Byte-Address. in einem KSDS-Dataset.

HOS

Höchste

belegte

Adresse

Head-of-String. Magnetplatten werden immer als Plattenstring

installiert, d.h. mehrere Platten werden in einem Gehäuse hintereinander gestellt. Der HOS kontrolliert die Platten des

Strings.

MVSESA/JCL

372

Storage Manager, siehe DFHSM.

HSM

Hierarchical

ICF

Integrated Catalog Facility. Katalogsystem, das Datasetverwaltung in einem MVS-System kontrolliert.

IMS

Information der IBM.

Index Set

Ebene eines Indexes eines VSAM KSDS-Dataset.

Input-Output-Facility

Output Management System, das häufig in Testumgebungen eingesetzt wird.

In-Stream

im

In-Stream-Daten

Daten im Eingabestrom, die zusammen mit der JCL submitted werden. Diese Daten sind meist Kontrollanweisungen für

die

Management System. Älteres Datenbanksystem

Eingabestrom.

Utilityprogramme. In-Stream-Prozeduren

Prozeduren im Eingabestrom. Ist zur Entwicklung von Prozeduren erforderlich. Dabei befindet sich die JCL der Prozedur und die aufrufende JCL im gleichen Member.

IOF

siehe Input-Output-Facility.

IPL

Initial Program Load. Bezeichnet den Gesamtvorgang des Startens eines MVS-Großrechnersystems. Ein IPL kann warm oder kalt durchgeführt werden. Das Hochfahren des Betriebssystems inklusive aller Subsysteme kann bis zu 30 Minuten dauern.

ISMF

Interactive

System Management Facility.

373

Anhang ISPF

System Productivity Facility. Interaktives System Benutzung von TSO.

Interactive zur

Ausgabedataset des Dialog Managers.

ISPFILE

DD-Name des

ISPPLIB

ISP Panel LIB. DD-Name der Bibliothek, die Bildschirme aufnimmt.

ISPSLIB

LIB. DD-Name der Bibliothek, die Kann zum Generieren von JCL aufnimmt. Datasetgerüste verwendet werden.

JES2

Job Entry Subsystem 2. Jobverarbeitungssystem. Ursprünglich für Einprozessorsysteme konzipiert, wird es heute in der Mehrzahl der MVS-Installationen eingesetzt.

JES3

Job

Entry Subsystem 3. Jobverarbeitungssystem, Anfang an auf Mehrprozessorsysteme ausgelegt war.

Katalog

Bezeichnung für das Katalogsystem, das aus Master- und UserKatalog besteht.

Katalogisierte

Mißverständlicher Name für Prozeduren, die als Member auf einer Prozedurbibliothek stehen. Im Gegensatz zu In-StreamProzeduren ist die JCL der Prozedur nicht in der aufrufenden JCL enthalten.

KSDS

Key Sequenced

Prozeduren

ISP

Skeleton

Data Set.

das

von

VSAM-Datasetform, die einen

index-sequentiellen Zugriff unterstützt.

LDS

Linear Data Set. Lineares VSAM-Dataset. Ist in 4K-Blöcken organisiert und wird nicht von einer Zugriffsmethode unterstützt. Die CIs von LDS enthalten nur Daten!

MVSESA/JCL

374 Linken

Bezeichnet den Vorgang des Einbindens von Systemroutinen in Anwendungsprogramme. Ohne diese Routinen wäre es dem Programm z.B. unmöglich, einen I/O durchzuführen.

LISTCAT

CATalog. AMS-Kommando zum Auflisten von Kataloginformationen. Wird häufig für die Analyse von VSAM KSDS-Datasets eingesetzt.

LTM

Leading Tape

LIST

Mark. Führende

Tape

Marke.

Angabe

im

LABEL-Parameter, die bei Bändern erforderlich ist, die nicht den IBM-Standards

Main

Storage

entsprechen.

Hauptspeicher.

Master-Katalog

Teil der Katalogstruktur. Der Master-Katalog hat als Einträge nur den ersten Teil eines DSN (High-Level-Qualifier) und einen Verweis auf den zu benutzenden User-Katalog.

Member

Teil (Mitglied) einer Bibliothek. Bibliotheken bestehen aus einem oder mehreren Membern, die ihrerseits editiert werden können. Die Bibliothek selbst kann nicht editiert werden.

MVS/370

Multiple Virtual Storage. Bezeichnet die ursprüngliche Form des MVS-Betriebssystems mit einer 24-Bit-Adressierung und einem virtuellen Speicher von 16 MB.

MVS/ESA

Multiple Virtual Storage / Enterprise System Architecture. Bezeichnet die jüngste Erweiterung von MVS, die 1988 eingeführt wurde. Durch die Möglichkeit, Data und Hiper Spaces zu benutzen, bietet MVS/ESA bei einer 31-BitAdressierung einen virtuellen Speicher von 16 TB (Tera-Byte).

MVS/XA

Multiple Virtual Storage / Extended Architecture. Bezeichnet die Erweiterung von MVS/370, die 1981 eingeführt wurde. Diese Form des MVS-Betriebssystems bietet bei einer 31-BitAdressierung einen virtuellen Speicher von 2 GB.

375

Anhang NL

No Label. Kein Label, Daten eines Bandes stehen unmittelbar am

non-volatile Cache

Bandanfang.

Zwischenspeicher

einer SCU, der bei einem Systemabsturz Netzausfall seinen Inhalt behält. Nach dem Wiederhochfahren des Systems kann der Inhalt des Cache auf Platte geschrieben werden. oder

OPTCD

OPTional CoDe. DCB-Parameter für spezielle z.B. Übersetzung EBCDIC -> ASCII.

Page

4K-Block des virtuellen

Panel

Bildschirm im ISPF.

PDSQ

Passed Data Set

Verarbeitungen,

Speichers.

Queue. Tabelle, in der Einträge über Datasets die mit DISP=(,PASS) übergeben werden, festgehalten

wurden.

Pointer

Verweis auf die RBA eines VSAM-Dataset.

PO-Dataset

Partitioned bezeichnet.

Organized Dataset. Wird auch als Bibliothek Untergliedertes Dataset, das aus vielen Membern (Mitgliedern) besteht. Wird sehr häufig für die Editierarbeit

verwendet. Auch JCL wird fast ausschließlich als Member eines PO-Dataset abgelegt. PR/SM

Partitioned Resource System Manager. Einrichtung, die es erlaubt, einen Prozessor in mehrere logische Systeme zu splitten. Diese Funktion ist beim Hersteller Amdahl unter der Bezeichnung MDF (Multiple Domain Feature) bekannt. -

PS-Dataset

Physisch-Sequentielles Dataset.

MVSESA/JCL

376

QSAM

Queued Storage

Access Method.

Zugriffsmethode

fur PS-

Datasets.

RACF

Resource Access Control Facility. Softwarepaket, das und Zugriffsschutz auf MVS-Systemen regelt.

RBA

Relative Byte Address. Relative Datasets adressiert werden.

RDF

Record Definition Field. Kontrollfeld im CI eines VSAMDatasets, das Länge oder Häufigkeit des Auftretens einer Länge eines logischen Records beschreibt.

REXX

Restructured Extended EXexutor. Interpretersprache, die eine Verarbeitung im Vordergrund ermöglicht. Ist Nachfolger des älteren CLIST.

RKP

Relative Key Position. Gibt das Displacement eines Schlüssel eines VSAM KSDS-Dataset an (Das erste Byte entspricht der relativen Position 0).

RRDS

Relative Record Data Set. VSAM-Datasetform mit einem relativen Schlüssel.

scu

Storage Control Unit. Kontrolleinheit, über die die Magnetplatten mit dem Hauptspeicher verbunden sind. SCUs verfügen über einen Zwischenspeicher (Cache), der die Zahl der physischen I/Os reduzieren hilft.

Sequence Set

Die unterste Index-Ebene eines VSAM KSDS-Dataset.

Skeleton

Zugang

Byte-Adresse, mit der VSAM-

Gerüst, das der Dateierstellungsservice benutzt. Kann auch Generieren von JCL genutzt werden.

zum

311

Anhang

logischen

Slot (RRDS)

Vorformatierter Platz zur Aufnahme eines in einem VSAM RRDS-Dataset.

Slot (VS)

4K-Block auf dem Hilfsspeicher.

SMS

Storage Management Subsystem oder System Managed Storage.

Spanning

Die Möglichkeit, logische Records zu benutzen, die größer sind als die physische Record-Länge. Höhere Programmiersprachen unterstützen solche Zugriffe meist nicht.

SUBMIT

TSO-Befehl,

jeweiligen submitten

Records

der einen Job aktiviert und ihn der Kontrolle des JES übergibt.

bezeichnet

auf Neudeutsch

den

vorher

beschriebenen

Übergabeprozeß. SVC

Supervisor Call. Aufruf von Systemroutinen, die bestimmte, privilegierte Operationen ausfuhrt. Anwendungsprogramme machen einen SVC, um Operationen wie z.B. einen OPEN oder WRITE auszuführen.

SYSIN

SYSOUT

Festgelegter

DD-Feldname. Abkürzung für SYStem INput. Unter SYSIN können Daten zusammen mit den JCLAnweisungen Ubergeben werden. Die Daten sind entweder Teil des JCL-Stroms, dann erfolgt die Angabe SYSIN DD * oder sie stehen getrennt in einem Dataset, dann ist die Anweisung SYSIN DD DSN=dsname zu benutzen.

DD-Parameter. Abkürzung für SYStem OUTput. SYSOUTwerden in das Spool-Volume geschrieben im Unterschied zu Ausgaben in normale Datasets. Wird immer bei Ausgaben auf den Drucker benötigt. Bei der Angabe SYSOUT erfolgt fast immer die Zuweisung einer Outputklasse oder aber

Ausgaben

MVSESA/JCL

378

die

Übernahme der

unter

MSGCLASS

Outputklasse mit SYSOUT=*.

angegebenen

SYSPRINT

Festgelegter DD-Feldname. Eine SYSPRINT DD-Anweisung muß bei allen Utility-Programmen stehen, da diese zusätzlichen Output erzeugen.

Tape Mark

Tape Marke. Magnetmarken auf der Band/Kassettenoberfläche, die dazu dienen, die Daten von den KontrollRecords

zu

trennen.

Track

Spur einer Magnetplatte.

Trailer Record

Identisch mit dem Header Record, befindet sich aber am Ende eines auf Band oder Kassette gespeicherten Datasets. Ist notwendig, um ein Rückwärtslesen zu ermöglichen.

TSO

Time-Sharing Option. Trägersystem des MVS, das vielen Benutzern wahlweise eine Verarbeitung im Vorder- oder Hintergrund ermöglicht (daher die Option). Das reine TSO ist für den User heutzutage fast nicht mehr zu sehen, da es durch das als Benutzeroberfläche fungierende ISPF überdeckt wird.

USERID

bis

User-Katalog

Teil der Katalogstruktur. Der User-Katalog hat als Einträge den DSN und den Verweis auf den Datenträger, auf dem das Dataset steht.

Utility-Programme

Hilfsprogramme, die Funktionen wie Kopieren oder Katalog bereinigen durchführen. Das am weitesten verbreitete Utility-

acht Zeichen langer System kennzeichnet. zu

String,

der einen User im MVS-

Programm ist IDCAMS. IEBGENER und ebenfalls häufig eingesetzt.

IEFBR14 werden

Anhang Virtual

379

Storage

Virtueller

Speicher.

Volume Record

Record am Anfang eines Bandes/einer Kassette, der unter anderem die Vol-Ser-No des Bandes/der Kassette enthält.

Volume Serial Number

Bezeichnung eines Datenträgers. Wird häufig als Vol-Ser-No bezeichnet. Als Konvention hat sich durchgesetzt, daß Platten am Anfang zumindest einen Buchstaben stehen haben, während die Vol-Ser-No von Bändern und Kassetten rein numerisch ist.

VSAM

Virtual Storage Access gleichnamigen Datasets.

VTAM

Virtual Telecommunication Access Method. für Terminals.

VTOC

Volume Table of Contents. Verzeichnis, das die Position aller auf einer Platte residierender Datasets angibt und Informationen über freien Platz auf der Platte enthält.

VVDS

VSAM

Method.

Zugriffsmethode

für die

Zugriffsmethode

Data Set. Kontrolldataset, das alle für auf der gleichen Platte residierenden VSAM-Datasets enthält.

Volume

Statistikeinträge

Work-Platten

Inoffizielle Bezeichnung für eine Gruppe vom Magnetplatten, deren Bestand in regelmäßigen Abständen gelöscht werden.

MVSESA/JCL

380

Literatur

9.5

In den vergangenen Jahren ist verstärkt auch deutschsprachige Literatur dem IBM-Großsystembereich erschienen. Einige der in der vorherigen Buches vorgestellten Veröffentlichungen sind zwischenzeitlich in erschienen. SMS wird nunmehr in fast allen Werken berücksichtigt.

Themen aus Auflage dieses

zu

neuer

Auflage

JCL D.

Lowe, MVS JCL, Mike Murach & Associates, Fresno, California, 21994

Neben dem eigentlichen JCL-Teil bietet dieses Buch einen über 100 Seiten großen Überblick über MVS/ESA und die Art und Weise, wie in einem MVS-System Jobs verarbeitet werden. Auch das Arbeiten mit VSAM-Datasets wird vorgestellt. Das Gleiche gilt für die wichtigsten Utilities. Es wird auch das heutzutage kaum noch eingesetzte ISAM behandelt. In der neuen Auflage von 1994 ist auch das Arbeiten unter SMS berücksichtigt. Die Schnittstellen zum Anwendungsprogramm werden nicht erläutert. M. Carathanassis, Expert MVS/ESA JCL, McGraw Hill, New York 1991 Dieses Buch hält, was es verspricht. Es ist in der Tat ein Buch für den JCL-Experten, und deshalb sollten Anfänger von diesem Buch die Finger lassen. Das soll beileibe nicht heißen, dieses Buch wäre schlecht. Nur ist es für einen Anfänger kaum möglich, Standard- und Ausnahmesituationen voneinander zu trennen. Deshalb sollte man schon einiges an JCLErfahrung besitzen, bevor man zu diesem Buch greift. Dann allerdings kann man ungemein davon profitieren. SMS ist in diesem Buch bereits berücksichtigt, die Version 4 von MVS/ESA (leider) noch nicht.

Gary DeWard Brown, MVS/JCL, Oldenbourg, München 21997 In diesem Buch über JCL wird die Version 4 von MVS/ESA und einige neue Parameter bereits berücksichtigt. SMS, VSAM und REXX werden in knappen Kapiteln vorgestellt.

COBOL-Programmierung für VSAM-Datasets R. Habib, VS COBOL II Band 2, Dateiorganisationsformen Vaterstetten bei München 1990

In diesem Buch werden die IDCAMS-Parameter in Aspekte der Performance wird nicht eingegangen.

und

VSAM-Zugriffe, iwt,

handbuchartiger Form vorgestellt.

Auf

Im zweiten Teil des Buches werden dann die für die VSAM-Programmierung unter COBOL notwendigen Anweisungen gezeigt. Die vorgestellte JCL ist größtenteils unkommentiert. MVS N.S.

allgemein Prasad, IBM Mainframes

21994

-

Architecture and

Design,

McGraw

Hill, New York

Wer das Innenleben eines IBM-Großsystems verstehen will, der sollte sich dieses Buch nicht entgehen lassen. Es bietet einen großzügigen Überblick über die verschiedenen IBM-

381

Anhang

von der /360-Architektur bis zu der von MVS/XA (MVS/ESA konnte in dem Buch noch nicht berücksichtigt werden), wobei die Unterschiede zwischen den Architekturen erläutert werden. Die Funktionsweise der Prozessortypen 3033, 308x, 3090, 4381 und 9370 wird ebenfalls erläutert. Obwohl man durch das Lesen dieses Buches nicht zum besseren Programmierer wird (dazu ist der Inhalt zu sehr an der technischen Ebene orientiert), ist es sehr lesenswert.

Architekturen, angefangen

TSO/ISPF M. Teuffei, TSO München 61999

Time -

Sharing Option

im

Betriebssystem MVS, Oldenbourg,

Ein hervorragendes Buch, das dem Leser das Tor zur MVS-Welt erschließt. Thema des Buches ist TSO und vor allem ISPF. Die Benutzeroberfläche und der Editor von ISPF werden ausführlich vorgestellt. Dazu gibt es Kapitel über RACF, den HSM und die Interpretersprachen CLIST und REXX. Informationen über TSO-Kommandos und eine kurze Einführung in JCL runden das Buch ab. Wer es noch nicht hat, der sollte sich dieses Buch unbedingt zulegen. Viele ISPF-Benutzer stellen beim Lesen dieses Buches zum ersten Mal fest, welche Möglichkeiten ISPF und sein Editor eigentlich bieten. REXX P.

Kees, REXX in der Praxis, Oldenbourg, München 1993

Endlich gibt es auch ein auf den Erfahrungen der Praxis basierendes Buch über REXX. Diese Programmiersprache, die hauptsächlich zur Steuerung von ISPF-Dialogen eingesetzt wird, bietet auch eine Reihe interessanter Schnittstellen zu JCL. Der Autor gibt einen großzügigen Überblick über alle relevanten Sprachelemente. Auch wurde nicht vergessen, die Entwicklung von Panels unter ISPF und die Möglichkeit zum Submitten von Jobs mit REXX EXECs vorzustellen. Alles in allem ein sehr informatives Buch zu einer sehr interessanten Programmiersprache.

382

9.6

MVSESA/JCL

Installationsspezifische Daten

Auf dieser und der

folgenden

Seite können Sie Ihre

installationsspezifischen

eintragen. Betriebssystem JES2 oder JES3?

MVS/XA oder MVS/ESA?

Zugang zum System TSO USERID:

Abrechnungsangaben in der JOB-Anweisung: Angaben zum Zugang über Großsystem-Netzwerk:

Angaben beim Anlegen von Datasets Zulässige(r) High-Level-Qualifier: Zulässige generische oder Gruppennamen für den UNIT-Parameter: Installierte und zugängliche DASDs

(Typ und Vol-Ser-No)

Name des Modell-DCBs für Generationsdatasets

Eingerichtete Klassen Job-Klassen:

SYSOUT-Klassen:

Default

Default(MSGCLASS)

SMS-abhängige Informationen Zugängliche STORAGE-Klassen Installierte Datenklassen Installierte

Managementklassen

Daten

Anhang

Sonstige installationsspezifischen Daten

383

384

9.7

MVSESA/JCL

COBOL Return Codes fur das FS 1 -Feld

Return Codes bei OPEN RC

Bedeutung

00

Erfolgreiches Öffnen.

35

Dataset nicht vorhanden. Falsche oder fehlende

37

DD-Anweisung. OPEN wird vom Dataset nicht unterstützt. Möglicherweise wurde versucht, ein

ESDS-Dataset wie ein KSDS-Dataset zu öffnen. 39

Inkonsistente Angaben bei den Datasetattributen. Die Angaben im Programm und in der JCL widersprechen sich. Bei KSDS-Dataset häufig falsche Schlüsselposition im COBOL-Programm.

90

KSDS wurde für OUTPUT geöffnet und ACCESS MODE ist entweder RANDOM oder DYNAMIC.

91

Passwort-Fehler. Kann auch ein RACF-Fehler sein (keine

92 93

95

Zugriffsrechte). Logischer Fehler. Meist ist das zu öffnende Dataset bereits geöffnet. Ungenügender virtueller Speicher. REGION-Parameter erhöhen. Dataset, das für OUTPUT geöffnet wurde, ist nicht leer. Schlüssellänge oder -position inkonsistent. Ein KSDS-Dataset wurde wie ein ESDS-Dataset eröffnet.

96 97

DD-Anweisung fehlt. Impliziter VERIFY durchgeführt. OPEN erfolgreich.

Return Codes bei Lese-/Schreibzugriffen RC

Bedeutung

00

Erfolgreiche Ausführung. Doppelter Schlüssel. Kann

02

nur beim Lesen eines KSDS-Dataset mit dem Alternativschlüssel auftreten und stellt keine Fehlerbedingung dar.

21

Reihenfolgefehler beim sequentiellen Laden eines KSDS-Dataset.

22

Record mit diesem Schlüssel existiert bereits.

23

Record mit gesuchtem Schlüssel nicht vorhanden bei READ oder REWRITE.

24

Ungenügender Platz beim WRITE bei RRDS und KSDS-Datasets.

Anhang 34 94

385

Ungenügender Platz beim WRITE für ein ESDS-Dataset. Kein Pointer für einen sequentiellen READ. Passiert, wenn nach dem START Endof-File erreicht wird. Ist meist keine Fehlerbedingung.

MVSESA/JCL

386

9.8

Index

&& 108 &SYSUID 335 //SYSOUT 63, 69, 70 /360 3 /360 Architektur Ursprünge 3 /370 3 /370 Architektur Ursprünge 3 ++ 139 3330 4 3350 4 3380 367, 4, 5, 6, 10, 51, 52, 55, 57, 58,

59, 105,214, 219, 245, 278, 305, 306, 309 3390 367, 4, 5, 6, 52, 53, 57,214,219, 245, 250, 304, 305, 306, 309 3480 367, 6 3745 367 3880 5 3880 Storage Control Unit für Magnetplatten des Typs 3380. 367 3990 367,5 9000 367 ABEND 367, 16,20,21,28,31,38,64, 353,354,355, 357 ABEND Codes 001 353 001 bis 04F 353 002 353 013 356 0C1 353 0C4 354 0C7 355 lOObisEFF 355 213 356 222 356 322 356 413 356 522 356 722 357

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

806 355 813 356 Fxx bis FFF 357 x37 356 xFO bis xFF 357

abnormal-disp 46, 49, 50, 51, Abrechnungsinformation 27

-

116

ACB 367 ACCESS 295 Access Method 367 ACCESS MODE 389,

288, 289, 290, 291,292 ACS 367, 304, 312, 315, 317, 318, 322, 323, 324, 325 ADDRESS 118, 119 AIX 368

AIX-Cluster 235, 258, 260, 261, 262, 263,264, 265, 268, 269 Allocation 277 Allokation 368 Allokationsroutinen 105 ALTER 308, 309 Alternativindex 235,237, 258, 260, 261, 269 Alternativschlüssel 217, 230, 231, 260,

261,262, 264, 269,270 AMORG 266,269,280 AMP 368, 246,266, 269, 279, 280 AMS 368 anweisung 27, 29 ASCII 368, 98, 103 ASP 368 Automatic Class Selection 312, 317, 318 Auxiliary Storage 368 AVGLRECL 273,274, 275 AVgrec 321 AVGREC 54,311,312,313,329 Band- und Kassettenverarbeitung 83 Arbeiten mit nicht katalogisierten Beständen 99 ASCII Daten verarbeiten 103 -

Anhang Bänder exportieren 100 Bänder ohne Standardlabel verarbeiten 100, 101 Datasets anlegen 85 ein Dataset auf ein Band- bzw. Kassette 86 EXPDT 86 Katalogeintrag 88 LABEL 91 Mehrere Datasets hintereinander 90 Multi-File Technik 94 Multi-Volume Datasets 97 undDISP=MOD 98 und UNIT=(„DEFER) 98 RETPD 87 SPACE 88 VOLUME 91 Standardbänder importieren 100 und Lese- Schreibstationen 84 BETA-92 368 Bibliothek 368 Datenorganisation 13 Bibliotheken compressen mit JCL s. IEBCOPY 212 BLDINDEX 235, 259, 261, 262, 265, 266,267, 269 BLKSIZE 5, 55, 57, 58, 59, 64, 66, 67, 102,214,305,306, 307 BLOCK 0 RECORDS 58 BLOCK CONTAINS 290 Blockgröße 6, 13, 56, 57, 58, 59, 101 Blocksize 308 BLP 362, 369, 102, 103 Buffer 369 BUFFERSPACE 236, 246 BUFND 280 BUFNI 280 BUFSPACE 273,274,275 BUILDING 119 CA 369,218,223,226,228,229,236,

387 CATLG

46,47, 48,49, 50, 51, 53, 78, 100, 104, 111

Channel Subsystem 369 CHARACTER 168,281 CI 369,218, 219, 220, 221, 222, 223,

224, 225,226, 227, 228,229, 232, 236, 239, 240, 241,246, 247, 250, 251, 255,259, 272,273,274, 276,280 CICS 370,3 CIDF 370,220,221,222,224,227,233 CISIZE 273,275, 276 Cl-Split 370 CLASS 27,28,31,33,34,43,44,119 CLIST 370, 377, 136, 333, 334, 335,

336,337,338 CLOSE 66, 70, 85 Cluster 370 CLUSTER 285

Compress 212,213 Compress von Bibliotheken

s. IEBCOPY 212 COND 27, 31, 32, 33, 34, 36, 37, 38, 80, 108 COND-Parameters 74 Control Area 218, 223, 224, 225, 238,

-

244, 276,277

-

241, 242, 244, 248, 255, 259, 272, 273,274, 275, 276, 277, 278

Cache 369 canceln 369 CA-Split 369

CONTROLINTERVALSIZE 236, 239, 249, 257, 259 COPIES 68, 119 COUNT

164, 165, 166, 167, 168, 169, 170, 252, 253,281,282

CPU 370 CPU-Zeit 356 CYL 54,55 in IDCAMS 268

Cylinder 4, 5, 54, 55, 218,223, 238,

-

244,248,277

Cylinder

370 CYLINDER 277,309,310 CYLINDERS 236,237,249,250,251,

252, 257, 259 DASD 370,217 DATA 167, 169,

170, 195, 200,236, 237, 238, 249, 250,251, 254, 255, 256, 257, 259, 263, 268, 270, 271, 273, 283, 288

MVSESA/JCL

388 DATA- 238 Data Space 370,3 DATACLAS 303,311,312,313,317,

321,322 DATACLASS 317 Data-in-Virtual 233

Data-in-Virtual (DIV) 233

DATASET NOT CATALOGED 42 DATASET NOT FOUND 53 Datasets

anlegen

-

-

-

BLKSIZE 57 DCB 55 DISP 46

abnormale DISPosition, 49

Beispiele

und UNIT 112 verketten 307 auf ungleichen Datenträgern 308 Verketten 66 zwischen Steps übergeben mit DISP=(,PASS) 104 Datasets drucken mit IDCAMS PRINT 167 Datasets entkatalogisieren mit IEHPROGM 178 Datasets kopieren mit IDCAMS REPRO 164 mit IEBGENER 171 mit SORT OPTION COPY 197 Datasets leer anlegen mit IEFBR14 213 Datasets löschen mit IDCAMS DELETE 157 mit IEFBR14 213 Datasets mischen 196 Datasets umformatieren mit IEBGENER 175 mit SORT Parameter INREC 190 Datasets umsortieren 180,181 Duplikate unterdrücken 195 Performance 187 Records auswählen 187 Records verkürzen 190 Reihenfolge der Records erhalten 185 Summieren 192 über ein Feld 184

50

Defaults 49 normale DISPosition, 47 status 46

DSNAME 44 LRECL 57 RECFM 56 SPACE 54 und Katalogeintrag 61 UNIT 51 unter SMS mit ACS 322 VOLUME 52 VSAM

mit KILOBYTES und MEGYBYTES 309 auf Platten neu anlegen 44 auffinden mit Hilfe des Katalogs 9, 10 mögliche Fehler 10 nicht katalogisierteg 7 temporäre 108 DSN 108 mögliche Probleme 113 nicht-eindeutige DSNs 113 Rückbezüge 109 symbolischer DSN 108 und DISP=(,PASS) 111 und Job RESTART 114 und RESTART 113

-

-

-

-

-

-

-

-

262,272 303,304,311,312,313, 316,318,319, 320, 321,324

Daten

Datenklasse

Datenmanagement SMS 11

Datenorganisation

-

PS und PO 13

Datenstapel 337,338 Datenverwaltung

-

-

-

-

DFHSM 11 ICF 7 Katalog 7 Master Katalog 7 User-Katalog 7

389

Anhang RACF 11 VTOC 6 VVDS 10 DB2 370,3 DCB 370, 55, 56, 59, 65, 67, 103, 104, 109, 110, 113 in SYSOUT 67 DD 371,2, 13, 14 DD DATA 152 DD SYSOUT 62, 63, 69, 70, 117, 118, 119 DD-Anweisung 279

-

-

-

-

-

-

-

-

-

-

allgemein 41 AVGREC 311 besondere 62 JOBCAT und STEPCAT 329 JOBLIB 64 STEPLIB 63 SYSOUT 63 SYSPRINT 62 BLKSIZE 57,304 und SMS 329 DATACLAS 311 DCB 55 OPTCD 103 DDNAME 146 DISP 46 Defaults und SMS 330

DISP=(,PASS)

104

DSN -

-

-

-

-

-

-

-

-

-

-

-

-

-

DSN=&&dsname 108 nicht-eindeutige DSNs 113 DSNAME 44 DUMMY 65 EXPDT 86 KEYLEN 312 KEYOFF 313 LABEL 91 LIKE 313 LRECL 57 MGMTCLAS 314 RECFM 56 RECORG 315 REFDD 315 RETPD 87

SECMODEL 316 SPACE 54,311 STORCLAS 316 SYSIN 70 SYSOUT 63, 67 COPIES 68 DEST 68 FREE 70 OUTLIM 68 SEGMENT (ESA/4) 69 SPIN (ESA/4) 69 und DCB 67 UNIT 51 UNIT=(„DEFER) 98 UNIT=AFF 84 VOLUME 52, 91 PRIVATE 92 RETAIN 92 VOL=REF 93 VOL=SER 93 Volume-Anzahl 92 Volume-Sequenz 92 ddname 41,84,91,94, 109, 110 DDNAME 146 Deallokation 371 Deallokationsmeldung 82 DEFAULT 117, 118, 119, 120 DEFER 98, 99 DEFINE ALTERNATEINDEX 235, 258, 259 DEFINE CLUSTER 235, 236,243, 248, -

-

-

-

-

-

-

249, 250,251,252, 257, 259, 260, 262, 275,276,277, 286

DEFINE GDG 235 DEFINE PATH 235,

259,263,264,

265,268 DELETE 47,48, 49, 50, 51, 61, 88, 90, 104, 112, 117, 157,158, 162, 183, 206, 213, 235, 243, 247,248, 256, 257, 262, 283, 284, 285,286, 287,

288,291,293

IDCAMS-ANWEISUNG 285 DELETE (IDCAMS-Kommando) Beispiele 159 NSCR 158 PURGE 158

-

-

-

390

MVSESA/JCL

DELETE GDG 210,211 DELETE NSCR 162, 163 Delimiter-Anweisung 124 DELSTACK 338,339 DEPT 120 DEST 68, 69, 74, 120 DEVTYPE 274, 275, 278 DFHSM 371, 11 DFP 371,217,218,233 Dialog Manager 335, 339 Die OUTPUT JCL-Anweisung ADDRESS (ESA/4) 118 allgemein 117 BUILDING (ESA/4) 119 CLASS 119 COPIES 119 DEFAULT 119 DEPT (ESA/4) 120 DEST 120 NAME (ESA/4) 120 ROOM (ESA/4) 120 TITLE (ESA/4) 121 dir-blocks 54 Directory 371 Directory Blocks 371 DISP 41, 43, 44,46,47,48, 49,

-

-

-

108 und COND oder IF/ELSE 108 und Eindeutigekeit 108

symbolischer

DUMMY 65, 171,280 DUMP 168, 169,281 EBCDIC 371, 103 END($$) 334, 335, 337 ENTRIES 271,274 ERASE 236, 243, 259,283, 284, 285 ESDS 371,389,390,217,221,222,

231,232, 235, 239, 249, 250, 253, 257,260,275, 281,288, 289, 290, 291,292, 293,294 EXCPS 371,273,274,277 EXEC 2, 13, 14

EXEC-Anweisung

-

-

-

-

-

-

-

-

-

-

-

50, 51, 53, 54, 57, 63, 64, 67, 70, 78, 83, 85, 98,99, 104, 105, 111, 112, 156, 169, 170, 173, 183, 212, 213,215, 254, 256,257, 266, 270, 279, 280

Displacement

371 DISPLAY PANEL 334, 337, 338, 339, 341,342, 346 Disposition Processing s. IEFBR14 213 DIV 233 DLM 72 DMS 371 DSN 7, 10, 14, 19,20,25,41,42,43, -

44, 45, 48, 50, 51, 52, 53, 61, 63, 64, 67, 70, 82, 83, 99, 100, 101, 102, 103, 104,105, 108, 109, 111, 129, 130, 132, 133, 134, 135, 136, 139, 140, 144,145, 147, 149, 150, 152 für temporäre Datasets 108 mit &&

beginnend

108

Ausführen mit IF/ELSE unter ESA V. 4 38 COND 36 PARM 35 PGM 34

PROC 35 Syntax 34 TIME und REGION 38 Existierende Datasets auf Platte ansprechen 41

-

-

Expanded Storage

371

EXPDT 86, 87, 90, 100, 158, 179 EXPDT=99000 158, 173, 179 Extent 372, 54, 278 EXTENT-NUMBER 274,275 EXTENTS 273,274,275,277 EXTENT-TYPE 274,275, 278 EXTERNALSORT 265 FASTSRT 180 FB 58 FBS 56,57 FD 289, 290, 295, 296

Fehlermeldungen

ABEND 20 JCL Error 20 als Allokationsfehler 20 als syntaktischer Fehler 20 FIELD 175, 176, 177 FIELD 184 FIELDS 181, 184, 191

-

-

391

Anhang FIELDS 196 FILE 278, 279, 289, 290, 292 FILE STATUS 288, 295 File Tailoring Services 333, 339 FOR 204, 236, 247 FORCE 210,211

Fortsetzungsfehler 349,351 Frame 372

Freespace 372, 220, 221, 229, 233, 241, 251,276 FREESPACE 222,236,241,249,253, 257, 259, 263, 268, 273, 274, 276 FROMADDRESS 252,253,281 FROMKEY 252,253,281 FROMNUMBER 252, 253,281 FTCLOSE 341,343,344,346 FTINCL 341,343,346 FTOPEN 341, 342, 346 FTS 372 GDG 308,309 GENERATE 175, 176 Generation Data Groups LIMIT ändern mit SMS 308 GENERATIONDATAGROUP 271 Generationsdatasets allgemein 203 Basiseintrag erzeugen 204 Basiseintrag löschen 210, 211 Besonderheiten 212 existierende Generationen ansprechen 210 LIMIT ändern mit SMS 209 ohne SMS 208 neue Generation erzeugen 205 Parameter ändern 207 genetischer name 51

HiPer Space 3 HISTORY 271,272,273,274 HI-USED-.i.RBA 274,275, 278

HI-USED-RBA 277 HI-USED-RBA 372 HLIST 347 HOS 372 HSM 373 ICF 373,7,

7 IDCAMS 11, 14,48, 55, 61, 63, 67, 70,

88, 89, 90, 96, 146, 148, 155, 156, 157, 163, 164, 167, 169, 170, 171, 173, 180, 184, 186, 196, 204, 207, 208, 209, 215, 233,234, 236, 248, 249, 250, 251, 252,253, 254, 255, 256, 257, 261, 263, 265, 266, 267, 268, 269, 271, 279, 282, 283, 285, 286, 287, 288, 304, 307, 308, 309, 310, 317, 320, 321, 322, 327, 328 ALTER 209,210,211 -

-

-

gruppenname 51,53,98

HASP 372 Header Record 372 Header Records Aufbau 359 HEX 168,281 HI-ALLOC-.i.RBA 274,275 HI-ALLOC-RBA 372 Hiper Space 372

-

107, 108,218,270

ICF-Katalog

BLDINDEX 265 Beispiel 266, 267 EXTERNALSORT INTERNALSORT 265 DEFINE AIX 259 Beispiel 262 KEYS 260 NAME 260 RECORDSIZE 260 RELATE 260 REUSE NOREUSE 262 -

-

UNIQUEKEY NONUNIQUEKEY 261 -

-

UPGRADE NOUPGRADE 261 DEFINE CLUSTER 236 Allocation Unit 237 CONTROLINTERVALSIZE 239 DATACLASS 317 ERASE NOERASE 243 IMBED NOIMBED 243 KEYRANGES 245 KEYS 240 KILOBYTES und MEGABYTES 309 MANAGEMENTCLASS 317 -

-

-

-

MVSESA/JCL

392 NAME 237

Organisation des Dataset 239 RECORDSIZE 239 REPLICATE NOREPLICATE 244 SHAREOPTIONS 241 Syntax 236 VOLUMES 238 DEFINE PATH 263 Beispiel 264 NAME 264 PATHENTRY 264 UPDATE NOUPDATE 264 DELETE 157 Beispiele 159 für VSAM-Datasets 283 Beispiel 284 ERASE NOERASE 284 PURGE 284 NOPURGE 158 NOSCRATCH 158 NSCR 158 PURGE 158 DELETE* 212 DELETE GDG 210,211 FORCE 211 DELETE NSCR 328 für VSAM-Datasets 234 Kontrollkommandos funktionale 234 modale 234 Syntax 234 LISTCAT 270, 272 Modal-Kommandos 287 -

-

-

-

-

-

-

-

-

-

-

-

-

-

PRINT 167,280 REPRO 164,252 SET Return Codes ändern 287 SYSPRINT 80 VERIFY 278

IDCAMS REPRO 85 IDCUT1 266,269 IDCUT2 266,269 Identifikationsfeld 23, 24 IEBCOPY 155,212 IEBGENER 155, 167, 171, 175, 184

-

IEF142I 78, 80, 88 IEF210I 351 IEF212I 114 IEF237I 78,88 IEF245I 351 IEF285I 78, 79, 80 IEF286I 212 IEF605I 350 IEF611I 131 IEF621I 350 IEF702I 352 IEFBR14 155,208,213,214,215,322, 323 IEHPROGM 155, 157, 178, 179,327 und SMS 327 IKJEFT01 347 IMBED 236, 238, 243, 244, 248, 249, 257, 259, 263, 268, 276 IMS 373 INCLUDE 152, 181, 187, 188, 189, 190 IN-CLUDE 152 INDATASET 164, 168, 252, 253, 255, 265,281,282, 285 Index 272 INDEX 236,237, 238, 249, 257,259,

-

263,268, 271,273,274,283 Index Set 373,223, 229, 278 INDEXED 236, 239, 249, 257, 273,

288,289 164, 166, 167, 168, 169, 170, 252, 253, 254, 255, 257, 265, 266, 267, 269,281

INFILE

Initial Volume Record 101 Initiator 16, 17,47,76 allgemein 17 Job-Ende 20 Job-Initiation 17

-

Programm-Ausführung

19 17 Initiation Step Step Termination 19 Step-Allokation 18 Input-Output-Facility 373 INREC 181, 190, 191, 194, 195, 196, 199, 200 In-Stream 373 In-Stream-Daten 373

-

393

Anhang In-Stream-Prozeduren 373 allgemein 136 Identifikationsfelder 139 *** 138 +/ 138 138 ++* 138

++

PEND-Anweisung 138 PROC-Anweisung 138 Symbolische Parameter

139 INTERNALSORT 265 IOF 373, 17,28,74, 125, 145 IOF JOB SUMMARY 74 IPL 373 ISAM 12 Zugriffsmethode 12 ISMF 373 ISPF 374, 1,2,7, 13, 14,333 ISPFILE 374, 341, 342, 343, 344, 346 ISPPLIB 374 ISPSLIB 374 JCL Aufbau der Anweisungen 23 Default-Werte 26 Parameter 26 und Performance 1 und SMS 2 Ursprünge 1 JCL ERROR 16 JCL-Fehler 349 Fortsetzungsfehler 349 IEF210I 351 IEF245I 351 IEF605I 351 IEF621I 351 IEF702I 352 in JOB-Anweisung 349 Laufzeitfehler 351,352 Probleme beim SUBMIT 349 unsichtbare Fehler 352 JCLLIB 39, 129, 152 JCL-Prozeduren allgemein 123 Arten 124 symbolische Parameter nicht besetzen 149 -

-

-

-

-

-

-

-

-

-

-

symbolische Parameter vorbesetzen 148 und SYSIN DD DDNAMEAn Weisung 146 und SYSIN DD DSN=-Anweisung 147 und SYSIN DD-Anweisung 146 Variablenersetzung 145 JCL-Prozeduren unter ESA V. 4 Die INCLUDE-Anweisung 152 Die JCLLIB ORDER Anweisung 129 Die SET-Anweisung 151 Schachteln von Prozeduren 151 JES2 374, 68, 69, 76, 79, 109, 111, 124, 128, 138, 152 JES3 374 JOB 2, 13, 14, 18 Job Summary JCL 75 LOG 75 MESSAGES 75 PROC 75 PROCSTEP 75 RC 75 STEP 75 SYSABOUT 75 SYSOUT 75 SYSPRINT 75 Job Termination 20, 106, 107, 111, 115 Job Termination-Routine 105 Jobablauf allgemein 13 Jobphasen 14 Ausgabe-Verarbeitung 16 Jobausführung 16 Kovertierung und Syntax-Prüfung 15 Purge Processing 16 SUBMIT 14 JOB-Anweisung 349 allgemein 26 Beginn 27 CLASS 28 COND 31 MSGCLASS 28 -

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

394

MVSESA/JCL

MSGLEVEL 29 NOTIFY 30 REGION 30 RESTART 33, 114 Syntax 27 TIME 31 TYPRUN 31 Job-Ausführung 17 JOBCAT 39, 124, 329 Job-Initiation 17 jobklasse 28 Job-Klasse 28, 38, 76 JOBLIB 39, 64, 65, 66, 123, 124 Job-Name 26,27 Job-Termination 20

keylen 321 Keylen 275

-

KEYLEN 312,313,314,320 KEYOFF 312,313,314,320 KEYRANGES 236, 244,245 KEYS 236, 240,249,250, 257, 259, 260,263, 268 KILOBYTES 309,310 kommentar 156, 175 Kommentar 25 Kommentare 25 Konkatenieren 307 Konkatenieren von Datasets 307 auf ungleichen Datenträgern 308 Kontrollintervall 275

-

-

-

-

-

-

2, 4, 6, 11, 12, 19, 41, 42, 44, 45, 58, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 97, 98, 99, 100, 101,

Kassette

102

213

Kontrollkommandos 171

Konvertierung 15 KSDS 374,389,390,217,218,219,

374 Auffinden eines Datasets 9 ICF 7 Master Katalog 7

Katalog -

Kontrollkommando 156, 175, 176, 190,

220, 221, 222, 223, 224, 226, 227, 230, 231, 232, 235, 237, 238, 239, 240, 241, 244, 246, 247, 249, 250, 253,254, 255, 256, 257,269, 270, 272,275, 276, 277, 280, 281, 285, 288,289, 290, 291,292,293, 294

Master-Katalog Aufbau 8

High-Level Qualifier User-Katalog 7

10

Aufbau 8

Katalogeintrag 82 Katalogisierte Prozeduren Anweisungen ungültig machen auf privater Bibliothek 128

134

label 156 LABEL 67, 87, 91, 95, 99, 101, 102, 103 LABEL RECORDS 290,296 Laden 389,218,222,223,231,237,

241,243, 248, 253, 254,255, 262, 266, 267, 291, 294

Aufruf 124

-

124 DD-An Weisungen ändern 131

LASTCC 287 Laufzeitfehler 351 LDS 374, 217, 233, 234, 235, 239, 240,

gesamte Prozedur beeinflussen 135

LEVEL 271,274 LIKE 313,314,315 LIMIT 308, 309 LINEAR 236, 239, 252 Linear Data Sets Aufbau 233 Einführung 233 undDB2 234 undDIV 233

Benutzung

DD-Anweisungen hinzufügen 132 EXEC-Anweisungen ändern 130

Identifikationsfelder 128 *** 128 XI 128 XX 128 Parameter Ändern und Einfügen gleichzeitig 133 und verkettete Datasets 134 KEEP 47, 48, 49, 50, 78, 105, 111,116

242,251,253,255

-

-

-

395

Anhang und Window 234 Linken 374 LISTCAT 375,235,270, 271, 272, 275, 280, 283, 286 logische Records 6, 12, 13 LRECL 55, 57, 58, 59, 66, 67, 102, 256 LTM 375, 102, 103, 104 Main Storage 375

-

Managementklasse 303,304,314,315

Master Katalog 7

Master-Katalog 375, 7, 10 MAXCC 215, 250, 251, 252, 256, 263, 268, 287, 288 MAXFLDS 175, 176 MAXLITS 175, 176 MAXLRECL 273,274,275 MEGABYTES 310 Member 375

Messages 48, 63, 74, 75, 77, Messages and Codes 78

80

MGMTCLAS 303,314,317,318 MOD 41,42, 43, 44, 46,47, 48, 50, 51, 54, 57, 85, 98, 99, 104 MSGCLASS 27, 28, 29, 33, 34, 43, 44,

63,119 MSGLEVEL 27, 29, 30, 34, 63 Multi-Volume Dataset 85 MVD 85,92,97,98,99 MVS Betriebssysteme 3 Geschichte 3 MVS/370 375, 3

MVS/ESA 375,217 Merkmale 3 MVS/XA 375, 2, 3, 57, 217, 233, 240 Merkmale 3 nachricht 29

120, 204, 236, 237, 249, 250, 251, 252, 257, 258, 259, 260, 263, 264, 265,268, 271,272 Namefeld 24, 25 NEW 42, 44, 46, 47,48,49, 50, 51, 53,, 78, 112 NAME

NEWSTACK 338, 339 NL 375, 102 NOERASE 236, 243, 259, 273, 274, 283

NOIMBED 236, 243, 259, 273, 274 NONINDEXED 236, 239, 250 NONSPANNED 236, 239, 247, 273

NONUNIQUEKEY 259,261,263,268 non-volatile Cache 376 NOPURGE 157,283 NOREPLICATE 236, 244,259 NOREUSE 236,246,259, 262,273,274 normal-disp 46,47, 48, 49, 50, 51 NOT CATLGD 2 82, 146 NOTIFY 27, 30, 34 NOUPDATE 264 NOUPGRADE 261 NSCR 327, 328 NUMBERED 236,239,250,251 OCCURS DEPENDING ON 60 OLD 41, 42, 43, 46, 47, 48, 50, 51, 53, 83, 105, 112, 117 OMIT 181, 187, 188, 189, 190 OPEN 389, 53, 57, 66, 85, 98, 99, 240, 246, 248, 278, 279, 291, 292, 296 operation 156, 175 Operation Exception 353 Operationsfeld 24 OPTCD 376, 103, 104 OPTION COPY 181, 198 ORDER 129, 152 ORDERED 236,244,245 ORGANIZATION 288, 289, 290, 295 OUTDATASET 164, 252, 253,254, 255, 265 OUTDATA-SET 253 OUTFILE 164, 166, 167, 252,253, 254,

257, 265, 266, 267,269 68, 357

OUTLIM

Output Management allgeimein 73 -

-

-

-

-

BETA92 16 Gefahren von RC IOF 16 JCL 77 Job LOG 76 Job Summary 74 Messages 77

outputklasse 27,28 OUTREC 181

=

0 80

MVSESA/JCL

396 376 Panel 376, 334, 335, 336, 340, 342, 345 parameter 156, 175 PARameter 36 Parameterfeld 24,25 PARM 34, 35, 130, 133, 135, 136 PASS 33,47,48, 104, 105, 108, 111, 112 Passed Data Set Queue 104,105,106, 107 PASSen von Datasets 104 die Passed Data Set Queue (PDSQ) 105 PATHENTRY 264, 265,268 PDSQ 376, 104, 105, 107, 108 PEND 138, 139, 152 PGM 34, 35, 37, 38, 40, 41, 43,44, 109 PHYRECS/TRK 274, 275, 278 PHYREC-SIZE 274, 275,278

Page

-

physische

Daten 1

PO 12, 13, 14,45,54,66 PO-Dataset 376 Pointer 376 positioneile Parameter 26 Positionelle Parameter 25 PR/SM 376 primär 54 Primärschlüssel 217, 230,

231, 257, 258, 261,267 PRINT 157, 167, 168, 169, 170,235, 279,280, 281,282 PRIVATE 91,92 PROC 24,34,35, 124, 151 PROC 144 PROC-und PEND- 137 Prozeduren schachteln 151 PS 13 PS-Dataset 376 PURGE 157, 158, 204, 247, 268, 283, 284, 285, 286 QSAM 376, 12, 59, 218, 231, 237, 249 Zugriffsmethode 12 QUEUE 337, 338, 339 RACF 377, 10, 11,45

RBA

377, 223, 224, 225, 232, 246, 274, 275,278 RDF 377,221,222,224,232 READ 390,270,291,292,293,294, 297, 298, 299 READ NEXT 293 RECFM 55, 56, 58, 59, 60, RECORD 175, 176 RECORD 169, 170, 175 Record Formate allgemein 12 Blockung 13 fixe 13

67, 100, 102

maximale Blockgröße 13 undefinerte 13 variable 13 RECORD KEY 288, 289, 295 Record-Format 13,43,56,58,60,64,

-

101 Record-Formate 12 RECORDING MODE 290,295 RECORDS 259 RECORDS 238, 239, 254, 270 RECORDSIZE 236,239,249,250,251, 257, 259, 260 RECORG 312,313,315,321 RECOVERY 236,243, 259, 273,274 RECSZ 268 REFDD 314,315 REGION 389, 27, 30, 34, 38, 182, 183, 292 RELATE 259, 260,263, 268 Relative Byte Adresse 232 relative Byte-Adresse 232 REPL 268 REPLICATE 236, 244, 248, 249,257, 259 REPRO 157, 164, 166, 167, 235, 248, 252, 253, 254, 255, 257, 265 RESTART 27,33, 113 und temporäre Datasets 113 und temporäre Datasets 114 RETAIN 91,92,94,95 RETPD 86, 87, 90, 158, 179 Return Code 32, 36, 37, 38, 39, 40, 61,

74, 75,78, 80,81,82, 106, 113

Anhang

397

nicht gelaufener

Step

75

Steps

74

Return Codes ändern mitlDCAMS 287 REUSE 236, 246, 259, 260, 262, 263, 268, 269, 291 REWRITE 390,291,293,294,299,300 REXX 377, 2, 136, 333, 337, 338, 339,

-

-

340, 341,342, 344, 345,346 RKP 377, 240, 273, 274, 275 RLSE 54, 55 ROOM 120 RRDS 377,390,217,221,232,235,

239,250,253, 260, 275, 277, 281, 288,290, 291,293,294 Rückbezug 107, 108, 110, 111, 117 auf vorhergehenden Step 110, 111 auf vorhergehenden Step einer Prozedur 110 im Step 109, 110

111 S322 31,38 S637-0C 308 S722 28, 68 S806 64 SCAN 27,31,34 Schlüsselwörter 349 Schutzfrist 158,247,272,284 SCRATCH 157, 180, 204, 206, 209, 210 SCU 377,5 SECMODEL 316 SEGMENT 69, 70 sekundär 54, 55

Rückbezüge 94,95, 109, 110,

-

Sekundärschlüssel 217, 231, 257, 258,

261,267 SELECT ASSIGN Sequence Set 377,

42, 43, 270, 288, 290 223, 224, 225, 228, 229, 238,244, 276,278,289

Sequentielle Datasets Datenorganisation

13 SET 148, 151, 152 SHAREOPTIONS 236,241,242,249,

250,251,252, 257,259 41,43,44,46,47,48, 50,51,53, 63, 64, 70, 78 Skeleton 377,340,342 SHR

Skeletons 340,344,345 SKIP 164, 165, 166, 167, 168,252,253, 281 Slot (RRDS) 377 Slot(VS) 378 SMS 378, 2, 11, 18, 19, 20,48, 52, 53, 54, 66, 83, 146 aktiviert 310 Datasets anlegen mit ACS 322 Mögliche Probleme 324 DISP=(OLD,DELETE) und VSAM Datasets 326 Löschen und Entkatalogisieren von Datasets 327 mit Datasets auf mehreren Platten 326 mit DISP Defaults 330 mit DISP=(OLD,DELETE) 326 mit IDCAMS DELETE NSCR 328 mit IEHPROGM 327 mit JOBCAT und STEPCAT 329 mit nicht optimaler BLOCKSIZE 329 mit UNCATLG 329 mitVOL=SER 324 neue IDCAMS-Parameter DATACLASS 317 MANAGEMENTCLASS 317 neue JCL-Anweisungen 311 AVGREC und SPACE 311 DATACLAS 311 KEYLEN 312 KEYOFF 313 LIKE 313 MGMTCLAS 314 RECORG 315 REFDD 315 SECMODEL 316 STORCLAS 316 sequentielle Datasets anlegen mit ACS 323 SMS vs. nicht SMS-managed 317 VSAM Datasets anlegen

-

MVSESA/JCL

398

mit ACS 324 ohne ACS 321 11

allgemein

installiert 304 -

KILOBYTES und MEGABYTES beim Anlegen von VSAMDatasets 309 Konkatenieren von Datasets auf ungleichen Datenträgern 308

Konkatenieren von Kassettendatasets 307 LIMIT einer GDG ändern 308

Wegfall BLKSIZE 304 VSAM Datasets löschen 322 Ziele 303 SMS-managed data sets 303 SORT 155, 171, 180, 181, 183, 184,

-

-

185, 186, 187, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201,255

Duplikate unterdrücken

SUM FIELDS=NONE 195 EQUALS NOEQUALS 185 JCL-Anweisungen 181 Kopieren von Datasets OPTION COPY 197 Mischen von Datasets MERGE FIELDS 196 Performance 187 INCLUDE COND und OMIT COND 187 Feld-Feld Vergleich 189 Feld-Konstante Vergleich 189 INREC 190 SORT FIELDS 184 Summieren SUM FIELDS 192 SORTIN 182, 183, 187, 198 SORTOUT 182, 183, 187, 198, 201, 202 SORTWKnn 182, 183 SPACE 54,55,67, 88, 311,312,314,

-

-

-

317,318,319, 320, 325,327, 329 SPACE-PRI 274, 277 SPACE-SEC 274,277 SPANNED 236, 239, 247 Spanning 378

Specific Volume Request

92

SPEED

236, 243, 259 Speicherklasse 303,317,318,325

Speichermedien

Bänder und Kassetten physische Merkmale 5 Kassetten und Bänder 4 logische und physische Records 6 Lücken 6 Plattenspeicher 4 3390 4 Cylinder 4 physische Merkmale 5 Spur 4 Spurkapazität 5 Storage Control Units 5 SPIN=UNALLOC 69,70

Spur 4, 6 Spurkapazität

5 SRTMSG 183, 186, 193 START 390, 258, 293, 294, 299 status

46,48,49,50

Step

nicht ausgeführt Return Code 74 Return Code 75 Step-Allokation 19 STEPCAT 329

Step-Initiation 17,20

STEPLIB

35, 63, 64, 66, 78

Step-Termination 19,20 STORAGECLASS 317 store las 321

STORCLAS 52,303,316,317,318,322 SUBALLOCATION 236, 240, 259 SUBMIT 378, 2, 14, 16, 333, 334, 335, 337, 338, 340, 341, 343, 346, 349 submitten 378 SUM FIELDS 181, 192, 193, 194, 195, 196, 199, 200, 255 SVC 378,20 symbolische Parameter 125, 140, 143,

144, 145,146

nicht besetzen 149

Symbolische Parameter 140, SYNCGENR 171

145

Anhang

399

SYNCSORT 4, 171, 181 Syntax Check 16,20

UNCATLG 47,48,49 UNCATLG DSNAME 179

Syntax-Prüfung 15,77

UNIQUE 236,240,250,251,252,259, 273, 274 UNIQUEKEY 259,261 unit 51, 54, 99, 100, 102, 103, 104 UNIT 42,48, 51, 52, 53, 67, 78, 83, 84, 86, 93,98, 99, 105, 107,112

SYS1.PROCLIB 123,124,129,136 SYS1.SORTLIB 181 SYSABOUT 75 SYSDA 51, 52, 112 SYSIN 378, 15, 61, 70, 77, 128, 130, 132, 133, 134, 135, 136, 146, 147 SYSIN DD 167,171,175,184,234,

254,255,287 147 DDNAME 146 DSN 147 SYSIN DD* 71,72 und Variable 147 SYSIN DD DATA 72 SYSIN DD DDNAME SYSIN-Daten 71,72 SYSOUT 378, 67, 357

UNIT=groupname

303 UNIT=TAPE 86 UPDATE 264, 265,268, 269 UPGRADE 261,263,268 USERID 379

*

-

-

-

User-Katalog 379, 7, 8, 10, 11, 19, 20, 80

71, 146

SYSPRINT 378, 61, 62, 63, 69, 74, 75, 77, 78,79, 80, 90, 117, 118, 119 SYSTSIN 347 SYSTSPRT 347 SYSUT1 155, 171, 172, 174 SYSUT2 155, 171 SYSUT3 213 SYSUT4 213 TAPE 51,52, 83 Tape Mark 379 TIME 27,31,34,38,90,356 TITLE 121 TO 236,247,290,293 TO 204 TOADDRESS 252,253,281 TOKEY 252,253,281 TONUMBER 252,253,281

Track 379, 4, 59, 223, 238, 244, 276 TRACKS 236, 237, 259, 274, 275, 278,

309,310

Trailer Record 379 TRK 54,55 TSO 379, 11,30,45 TSO/ISPF 155 TSO-Kommando 347 TYPRUN 27,31,34

UNIT=AFF 84 UNIT=CASS 86

Utility-Programme 379, 2, 19, 63, 70, 155

allgemeine Merkmale

155

Kontrollkommandos 156 V 56

Variable 334, 338, 339, 345

VB 56,58 VBS 58 VERIFY 389,278,279,292 Verketten von Datasets 66 Virtual Storage 379 VOL in IDCAMS 268 VOL=REF 93,94,95, 107 VOL=SER 52, 53, 99, 100, 317,

-

319,

325 VOLFLAG 274,275,278 VOLSER 274,275 Volume 4, 5, 6, 10, 11, 16, 52, 53, 63, 79, 82,92, 97, 98, 101, 105 VOLUME 42, 48, 52, 53, 91, 93, 105, 107 Volume Anzahl 92 Volume Record 379, 100, 101 Volume-Anzahl 91,92,97 VOLUMES 236, 238, 245, 249, 250,

251,252, 257, 259,272,278

Volume-Sequenz 91,92

400

MVSESA/JCL

380,2, 7, 10, 11, 12, 47, 65, 304,309,312,313,314,315,317, 320, 321, 322, 324, 326, 330, 331

VSAM

-

Alternativschlüssel 257 Anlegen eines AIX für ein KSDSDataset 262 Art des Schlüssels festlegen 261 Arten 258 Beispiel für Pfad anlegen 264 Bezug herstellen 264 Bezug zum Basis-Cluster festelegen 260 Cluster wiederverwendbar machen 262 definieren mit DEFINE AIX 259 definieren und laden 268 eindeutige Sekundärschlüssel erzeugen 258 im Batch mit COBOL verarbeiten 269 laden Beispiel 266 mögliche Probleme 267 laden mit BLDINDEX 265 Name des AIX-Clusters festlegen 260 Name des Pfads festlegen 264 Pfad definieren 263 Record-Länge festlegen 260 Schlüssel festlegen 260 UPDATE Optionen festlegen 264 Update-Optionen festlegen 261 COBOL Programmierung 288 Aufsetzen mit START 293 Beispiel 294 FD-Anweisung 290 FSl-Feld 289 FS2-Feld 289

Schreib-Zugriffe

-

Record-Länge festlegen 239 Schlüssel festlegen 240 Share Optionen festlegen 241

-

-

-

-

Lese/Schreibzugriffe

Return Codes 294

Lese-Zugriffe READ 292 READ NEXT 293 Löschen von Records DELETE 293 OPEN-Anweisung 291

REWRITE 292 WRITE 292 SELECT ASSIGN-Anweisung 288 fürESDS 289 fürKSDS 288 START und READ NEXT 293 Datasetarten 217 Datasets anlegen auf Platte plazieren 238 CI-Größe festlegen 239 DEFINE CLUSTER 236 Syntax 236 Löschoptionen festlegen 243 Name vergeben 237 Performance Optionen 243, 244, 245 Platz anfordern 237

-

-

Typ auswählen 239 Datasets drucken mit IDCAMS PRINT 280 Datasets laden mit IDCAMS REPRO 252 mögliche Probleme 254 Datasets löschen mit IDCAMS DELETE 283 Datasets recovern mit VERIFY 278 Einführung 218 ESDS Datasets anlegen 249 ESDS-Datasets Eigenschaften 231 Grundlagen 217 IDCAMS 234 Informationen über Datasets abrufen der LISTCAT-Output 272 mit LISTCAT 270 JCL für VSAM Datasets 279 AMP 279 AMP-AMORG' bei DUMMY 279 KSDS Datasets anlegen 247 KSDS Datasets reorganisieren

401

Anhang

Beispiel eines REORG-Jobs Notwendigkeit 255

-

-

KSDS-Datasets 218 Alternativschlüssel 230 CA-Splits 229 CI-Splits 228 Datenkomponente 218 Indexkomponente 223 Records einfügen 226 Records lesen 225 Records löschen 230 LDS Datasets anlegen 251 LISTCAT Attribute 275 AVGLRECL 275 BUFSPACE 275 CI/CA 276 CISIZE 276 DEVTYPE 278 EXCPS 277 EXTENT-NUMBER 278 Extents 277 EXTENT-TYPE 278 Freespace 276 Hi-Alloc-RBA 277,278 Hi-Used-RBA 277, 278

Keylen

275 MAXLRECL 275 PHYRECS/TRK 278 PHYREC-SIZE 278 Records 276 RKP 275 Space-Pri 277 Space-See 277 Space-Type 277

256

Splits 276 TRACKS/CA 278 VOLFLAG 278 VOLSER 278 Pufferung

BUFND für Datenpuffer 279 BUFNI für Indexpuffer 279 RRDS Datasets anlegen 250 RRDS-Datasets Eigenschaften 232 Struktur Control Areas 223 Kontrollintervalle 219 Aufbau eines Daten-CIS 220 und Kontrollinformationen 222 Relative Byte Adresse 232 undICF 218 Zugriffsmethode 12 VSAM Datasets

-

-

-

anlegen

unter SMS 321,324 löschen unter SMS 322

VTAM 380 VTOC 380,

6, 7, 10, 19, 42, 48, 52, 61, 80, 82, 83, 88, 107 VVDS 380, 10, 11,218 Window 234 Work-Platten 380 WRITE 390, 220, 293,294, 298 X/ 132 XX 128

Zugriffsmethoden QSAM 12 -

-

VSAM 12