Dieses Dokument beschreibt, wozu Entire Output Management dient und wie es funktioniert.
Es behandelt folgende Themen:
Ausgaben nach Entire Output Management von dezentralen Großrechner-Knoten übertragen
Ausgaben nach Entire Output Management unter UNIX übertragen
Wenn Sie beginnen, Entire Output Management zu benutzen, brauchen Sie Ihr vorhandenes System zur Behandlung von Druckausgabedaten nicht mit einem Male zu ändern, sondern Sie können die Verarbeitung Ihrer Druckausgabedaten schrittweise an Entire Output Management übergeben. Dies ermöglicht einen sanften Übergang von der gegenwärtigen Behandlung der Druckausgabedaten hin zur Benutzung einer ganzen Palette an Möglichkeiten der Verarbeitung von Druckausgabedaten, die Ihnen Entire Output Management bietet.
Um die Druckausgabedaten in Entire Output Management zu verarbeiten, brauchen die Anwendungen, die diese Daten erstellen, nicht geändert zu werden.
Sofern nicht anderes angegeben ist,
gelten Information in der Entire Output Management-Dokumentation für Entire Output Management auf allen unterstützten Plattformen.
gelten Information bezüglich Großrechnern für alle unterstützten Großrechner-Betriebssysteme.
gelten Information bezüglich UNIX für alle unterstützten UNIX-Systeme.
gelten Information bezüglich Windows für alle unterstützten Windows-Versionen.
Entire Output Management ist ein Werkzeug, das jegliche Art von Druckausgabedaten in heterogenen Umgebungen aufbereitet und verteilt. Diese Ausgabedaten können aus verschiedensten Datenquellen stammen:
Druckausgabedaten von Anwendungen,
Daten von Spooling-Systemen,
Daten, die in Dateien gespeichert sind.
Die von Entire Output Management erzeugten Druckausgabedaten werden als Reports bezeichnet. Bei der Definition eines Reports geben Sie an, welche Druckausgabedaten einer Datenquelle verarbeitet werden sollen, und legen fest, auf welche Weise sie verarbeitet und verteilt werden sollen.
Ein Report kann gesendet werden:
an einen Drucker,
an eine Datei,
an einen Folgeprozess zur Weiterverarbeitung.
Der Einfachheit halber werden diese "Ausgabegeräte" innerhalb von Entire Output Management allgemein unter dem Begriff Drucker zusammengefasst.
Darüber hinaus kann Entire Output Management dazu benutzt werden, die Druckausgabedaten durch Speicherung von Reports in sequenziellen Dateien zu archivieren.
Eine Report-Definition besteht aus verschiedenen Attributen. Durch Angabe dieser Attribute bestimmen Sie:
die Datenquelle der für den Report zu benutzenden Druckausgabedaten,
welche Druckausgabedaten aus der Datenquelle extrahiert werden sollen,
welche Entire Output Management-Benutzer den Report zur Weiterverarbeitung erhalten sollen,
wie und auf welchem Drucker der Report gedruckt werden soll,
ob und wie der Report archiviert werden soll.
Der tatsächliche Report, den Entire Output Management aufgrund der Report-Definition erstellt, wird als aktiver Report bezeichnet.
Reports können zu größeren Datenpaketen, sogenannten "Bündeln", zusammengefasst und als Einheit verarbeitet werden. Eine solche Bündelung ist auch dann möglich, wenn die Reports auf unterschiedliche Datenquellen zeigen.
In einer Bündel-Definition können Sie angeben, welche Reports Bestandteil des Bündels sein sollen. Darüber hinaus können Sie Bündel-Attribute zur Steuerung der Bündelverarbeitung angeben.
Wird ein aktiver Report, der einem Bündel zugewiesen ist, verarbeitet, erstellt Entire Output Management ein aktives Bündel, das auf der Bündel-Definition basiert.
Ein Fach ist ein Container für aktive Reports. Wenn Sie einen Report definieren, können Sie ihn Benutzern zuweisen, die den resultierenden aktiven Report empfangen sollen.
Jeder Entire Output Management-Benutzer hat ein Fach mit dem Namen
#Listeneingang (englisch: #Inbasket). Die aktiven
Reports, die Ihnen zugewiesen werden, erscheinen in diesem Fach.
Zusätzlich zu Ihrem Fach #Listeneingang können Sie
andere Fächer definieren und aktive Reports aus dem Fach
#Listeneingang in diese Fächer übertragen.
In der Liste der aktiven Reports in einem Fach können Sie dann einen aktiven Report zur Verarbeitung auswählen.
Zusätzlich können Sie anderen Benutzern die Berechtigung erteilen, auf eines Ihrer Fächer zuzugreifen.
Anmerkung:
Das Anlegen des Fachs #Listeneingang für einen
Benutzer erfolgt automatisch bei der Definition der Benutzerkennung. Das Fach
#Listeneingang kann nicht umbenannt oder gelöscht werden.
Um die Verteilung von Reports an verschiedene Benutzer zu erleichtern, können Sie Verteiler anlegen. Ein solche Verteilerliste kann einzelne Benutzer enthalten, aber es können auch Verteiler innerhalb einer Verteilerliste vorhanden sein. Anstatt einen Report mehreren Benutzern zuzuweisen, können Sie ihn einem Verteiler zuweisen. Er wird dann an alle Mitglieder dieses Verteilers verteilt.
Das Drucken eines aktiven Reports kann entweder automatisch, in Abhängigkeit von Attributangaben in der Report-Definition oder manuell von einem Benutzer ausgelöst werden.
In der Report-Definition geben Sie an, auf welchem Drucker der aktive Report gedruckt werden soll. Ein Drucker, der einem Report zugewiesen ist, wird als logischer Drucker bezeichnet. In der Definition des logischen Druckers geben Sie einen bestimmten Satz von Attributen an, die mit einem tatsächlichen physischen Drucker verknüpft sind und die Druckeigenschaften und das Druckformat des Reports auf dem physischen Drucker bestimmen.
Wenn alle auf einem physischen Drucker zu druckenden Ausgaben auf die gleiche Weise gedruckt werden sollen, brauchen Sie nur einen logischen Drucker zu definieren, der sich auf einen physischen Drucker bezieht. Wenn Sie verschiedene Reports unterschiedlich auf demselben physischen Drucker drucken möchten, müssen Sie mehrere logische Drucker definieren, die sich auf denselben physischen Drucker, aber mit unterschiedlichen Druckausgabeeigenschaften beziehen.
Es wird dringend davon abgeraten, beim Erstellen und Definieren von Entire Output-Management-Objekten (Reports, Bundles usw.) Objektnamen zu verwenden, in denen Leerzeichen oder Sterne (*) enthalten sind.
Sie können festlegen, wie lange ein aktiver Report den Benutzern in Entire Output Management online zur Verfügung stehen soll. Dazu geben Sie in der Report-Definition eine Aufbewahrungszeit an. Nach Ablauf der Aufbewahrungszeit ist der aktive Report nicht mehr online verfügbar.
Wenn Sie einen aktiven Report länger behalten möchten, können Sie ihn in einer sequenziellen Datei archivieren. In der Report-Definition geben Sie an, wie lange ein aktiver Report im Archiv aufbewahrt werden soll.
Bei Bedarf können Sie einen solchen Report aus dem Archiv reaktivieren, d. h. dem Online-System wieder verfügbar machen.
Um Archivdatenbestände, die aus sequenziellen Dateien bestehen, so klein wie möglich zu halten, führt Entire Output Management so genannte Verdichtungsjobs aus. Diese Jobs löschen im Archiv alle aktiven Reports, deren Archivierungszeit abgelaufen ist.
Mit der Funktion Standardwerte für die automatische Archivierung können Sie einen Schwellenwert für die Anzahl der Reports definieren, ab der Archivdateien für die Verdichtung markiert werden.
Zum Entfernen abgelaufener Dateien und zum Löschen nicht mehr benötigter Quellen bietet Entire Output Management verschiedene Bereinigungsfunktionen.
Es gibt drei Arten der Bereinigung:
Tägliche Bereinigung
Quell-Bereinigung
Report-Bereinigung
Die Hauptbereinigungsart ist die tägliche Bereinigung. Entire Output Management führt eine tägliche Bereinigung genau einmal täglich bei seiner nächsten Aktivierung nach der in den System-Standardeinstellungen angegebenen Zeit durch. Ist hier keine Zeit angegeben, wird die tägliche Bereinigung bei der ersten Aktivierung nach Mitternacht durchgeführt.
Quell- und Report-Bereinigung sind optional und können über die entsprechende Systemverwaltungsfunktion aktiviert werden. Sie können einzeln aktiviert werden, und es kann ein Zeitplan für sie definiert werden. Sie können den Zeitplan beliebig festlegen. Mittels eines Kalenders können Sie angeben, an welchen Wochen- und Monatstagen die Bereinigung laufen soll, ob sie vor oder nach arbeitsfreien Tagen laufen soll, in welchem Zeitraum sie laufen soll und wie oft. Sie könnten beispielsweise definieren, dass die Quell- bzw. Report-Bereinigung montags, mittwochs und freitags zwischen 8:00 und 20:00 Uhr alle zwei Stunden durchgeführt werden soll.
Die tägliche Bereinigung verarbeitet alle abgelaufenen Einheiten:
Aktive Reports, die abgelaufen sind, werden entweder gelöscht oder als zu archivieren markiert.
Aktive Bündel, Druckaufträge und Protokolleinträge, die abgelaufen sind, werden gelöscht.
Reaktivierte Reports werden "ent-reaktiviert", das heißt, ihr Inhalt wird gelöscht, wenn der Report auf die Datenbank reaktiviert wurde, und der aktive Report wird auf seinen archivierten Status zurückgesetzt.
Archivierte aktive Reports werden gelöscht.
Aktive Report-Quellen (Spool-Dateien oder Container-Datei-Einträge) werden geprüft und gelöscht, wenn sie nicht länger benötigt werden.
Die Quell-Bereinigung prüft die Quellen von Entire Output Management (zum Beispiel JES- oder Power-Spool-Dateien in Entire Output Managements temporären Klassen oder Einträge in den Container-Dateien), um festzustellen, ob sie noch benötigt werden - und löscht sie, falls sie nicht mehr benötigt werden. Sie gelten als nicht mehr benötigt, wenn sich kein aktiver Report mit Speicherort "S" (Source) mehr auf sie bezieht. Nicht länger benötigte Container-Dateien werden auch dann gelöscht, wenn das Feld Spool-Bereinigung nicht markiert ist.
Die Report-Bereinigung prüft alle aktiven Reports mit Speicherort "S" (Source), um herauszufinden ob die Quell-Datei noch verfügbar ist. Falls nicht, wird der aktive Report gelöscht.
Der tägliche Bereinigungsvorgang kann sehr zeitaufwendig sein (in einer typischen Produktionsumgebung dauert er in der Regel 30 bis 60 Minuten), und während dessen kann der Monitor keine andere Aufgabe ausführen, da der Monitor als "Single Task" läuft; das heißt, solange die tägliche Bereinigung stattfindet, können keine Reports, Bündel oder Druckaufträge verarbeitet werden.
Um dieses Problem zu vermeiden, kann die tägliche Bereinigung in
einem asynchronen Stapeljob laufen. Hierzu führen Sie das Programm
NOMCLEAN in einem Standard-Batch-Natural aus (mit den
entsprechenden Parametern, wie etwa LFILE 206). Dieser Stapeljob
kann dann von einem Job-Scheduler aktiviert werden und ein paar Stunden, bevor
die tägliche Bereinigung durch den Entire Output Management-Monitor ansteht,
laufen. Unmittelbar bevor dann der Monitor seine tägliche Bereinigung startet,
kann der Monitor feststellen, dass NOMCLEAN bereits gelaufen ist
und er selbst daher keine Bereinigung mehr durchführen muss.
NOMCLEAN und der Monitor verständigen sich mittels
zweier Kontrollsätze in der Entire Output Management-Systemdatei über ihren
jeweiligen Status. Der Zugriff auf diese Kontrollsätze erfolgt über die View
NRM-ARCHIVE-TASK und den Deskriptor M-MONITOR-ID =
'CLEANUP' oder M-MONITOR-ID = SYSNOM (d. h. die Bibliothek,
von der aus Entire Output Management ausgeführt wird).
Die Kommunikationswege sind wie folgt:
Wenn NOMCLEAN startet, setzt es
SYSNOMs CLEANUP-IDENTIFIER auf CLEAN,
CLEANUP-ACTIVE-NOW auf TRUE und
CLEANUP-RESCHEDULE auf FALSE, um zu zeigen, dass es
aktiv ist.
RMONITOR (Monitor-Hauptschleife) löscht nicht
länger benötigte Quellen nur, wenn SYSNOMs
CLEANUP-IDENTIFIER nicht auf CLEAN bzw.
CLEANUP-ACTIVE-NOW nicht auf TRUE gesetzt ist (das
heißt, nur wenn NOMCLEAN nicht aktiv ist). Um
Parallelverarbeitungsprobleme beim Erstellen aktiver Reports zu verhindern,
setzt RMONITOR außerdem CLEANUPs
REPORT-PROCESSING-NOW während des Erstellens aktiver Reports auf
TRUE und anschließend wieder auf FALSE. Dies ist
nötig, um zu verhindern, dass NOMCLEAN Reports oder Quellen
löscht, mit denen der Monitor gerade arbeitet.
RMARCSCH (Monitor-Zeitplanfunktionen) führt die
tägliche Bereinigung nur durch, wenn SYSNOMs
CLEANUP-RESCHEDULE und CLEANUP-ACTIVE-NOW beide
FALSE sind (d. h. nur wenn NOMCLEAN nicht aktiv ist
und an diesem Tag nicht bereits gelaufen ist). Wenn
CLEANUP-RESCHEDULE auf TRUE ist, heißt das, dass
NOMCLEAN bereits gelaufen ist, und RMARCSCH setzt
CLEANUP-RESCHEDULE auf FALSE sowie den Zeitpunkt für
die nächste geplante tägliche Bereinigung auf dieselbe Zeit am nächsten Tag
zurück. RMARCSCH führt Quell- bzw. Report-Bereinigung nur durch,
wenn SYSNOMs CLEANUP-ACTIVE-NOW auf
FALSE gesetzt ist. Dadurch werden Konflikte mit
NOMCLEAN, das ebenfalls Quellen bereinigt, vermieden.
RMSRCK (Quell-/Report-Bereinigung) kann vom
Monitor oder von NOMCLEAN aufgerufen werden. Beim Aufruf durch
NOMCLEAN müssen die oben erwähnten Parallelverarbeitungsprobleme
vermieden werden. Hierzu prüft NOMCLEAN den
REPORT-PROCESSING-NOW und verwendet, wenn er auf TRUE
gesetzt ist, den View NPR EVENTING und versetzt sich selbst in
Wartezustand (wiederholt, jeweils für 5 Sekunden), bis
REPORT-PROCESSING-NOW auf FALSE steht, woraufhin
RMSRCK dann die Verarbeitung dort wieder aufnimmt, wo sie
unterbrochen wurde.
Wenn Multi-Tasking aktiv ist (d. h. mehr als ein Monitor-Task definiert ist), werden die Monitor-Bereinigungsfunktionen vom Haupt-Task (Task 1) durchgeführt. Dadurch ist es möglich, die Bereinigung von anderen Monitor-Funktionen wie Erstellen von aktiven Reports und Druckaufträgen zu trennen.
Entire Output Management verfügt über Methoden, um Drucker direkt zu adressieren. Dies wird via TCP/IP erreicht. Diese Druckmethode ist dazu gedacht, Drucker zu nutzen, die entweder eine speziell dafür vorgesehene IP-Adresse oder auf die über einen Drucker-Warteschlangen-Namen eines Drucker-Servers zugegriffen werden kann.
Diese Druckmethode dient vor allem dem direkten Drucken von kurzen Dokumenten direkt aus der Online-Anwendung heraus. Da das Drucken als Natural-Subtask ausgeführt wird, ist kein Speicher (wie z.B. CICS-Speicher) nötig. Kein Spooling-System ist notwendig und kein separater Adressraum wird gebraucht, auch kein Entire Systems Server. Diese Vorgehensweise macht das Drucken unabhängig von Stapelverarbeitung, Broker, CA Spool, Entire Systems Server, JES und Natural Advanced Facilities.
Hierdurch können Durchsatz-Verbesserungen erreicht werden. Ferner werden 4 MB Speicher für einen Entire Output Management-Druckauftrag pro 1000 Seiten gebraucht, sobald der Drucker (Server) den Erhalt des Auftrages bestätigt.
Zur Druckzeit wird die Druckausgabe online oder mittels des Monitors initialisiert und in einem der in Entire Output Management definierten Druckaufträge ausgeführt. Zur Ausführungszeit wird die Druckausgabe im virtuellen Speicher gehalten und dann mittels des LPR/LPD-Protokolls (RFC1179) direkt (per Socket-Programmierung) an TCP/IP gesandt.
Mit Entire Output Management können Sie auch Binärdaten verarbeiten, d.h., Sie können jede Art von Datei oder Druckauftrag in Entire Output Management halten, archivieren, drucken, verteilen oder an ein Zielsystem schicken.
Möglich ist dies mit UNIX- und Windows-Dateisystemen, aber nicht mit Großrechner-Spool-Systemen.
Anmerkung:
Werden Binärdaten gelesen, die von einem Großrechner stammen,
kann es bei der Weiterverarbeitung zu Natural-Programmabbrüchen kommen, z.B.
IW060 oder 0C7. Auf Großrechnern können nur Textdaten
verarbeitet werden. Aus Performance-Gründen erfolgt jedoch keine Prüfung zur
Sicherstellung, dass die Eingabedaten keine Binärdaten enthalten.
Um Binärdaten nach Entire Output Management zu übertragen, definieren Sie einen Report, der binäre Daten von einem UNIX- oder Windows-Verzeichnis empfängt. In der Report-Definition muss das Kontrollkästchen Binär lesen markiert werden, um anzugeben, dass die Datei in Binärformat verarbeitet werden soll.
Der Report wird durch die Entire Output Management-Trigger-Queue
weitergereicht, ähnlich wie bei der NOMPUT-Schnittstelle. Dazu
muss die Trigger-Queue aktiviert werden (Trigger-Container-Datei).
Der geöffnete aktive Report erhält den Typ "binär" (spezieller
CC-Typ).
Ein Binär-Dokument kann auf der zeichenbasierten Großrechner-Benutzungsoberfläche nicht angezeigt werden. Der Entire Output Management GUI Client hingegen kann die Daten empfangen, sie auf einem PC speichern (bitte beachten Sie, dass die ganze Datei übertragen werden muss) und sie mit der Windows-Standardanwendung für den betreffenden Dateityp (z. B. ".doc" oder ".pdf") anzeigen.
Binäre aktive Reports können mit UNIXLP-Druckern oder
auf BS2000 mit einem SYSPRBS2-Druckertyp gedruckt werden. Unter
UNIX steht der Druckertyp NATUNIX zur Verfügung, der die Daten an
die lp- oder lpr-Utility übergeben kann (in diesem
Fall muss die Option -l verwendet werden, um sicherzustellen, dass
die Daten im transparenten Modus weitergeleitet werden), oder an ein Programm
oder Skript oder an eine Datei in einem UNIX-Verzeichnis.
Bitte beachten Sie, dass ein binärer Report, der die Ausgabe eines Windows-Druckertreibers ist, an die Hardware gebunden ist, für die er erstellt wurde. Die Entscheidung, wo die Daten, die Entire Output Management möglicherweise schon vor längerer Zeit erhalten hat, gedruckt werden, wird bereits bei der Erstellung getroffen. Wenn Sie binäre Daten langfristig aufbewahren möchten, sollten Sie die Verwendung von Dateiformaten wie PDF in Erwägung ziehen.
Entire Output Management wandelt binäre Daten in das Format BASE64 um. So können die Daten über Plattformen und Codepages hinweg weitergeleitet werden, da BASE64 ausschließlich aus druckbaren Zeichen besteht. Dies bedeutet allerdings auch, dass die Datenmenge größer ist als der ursprüngliche Binärdatenstrom. Wenn aktive Reports an Ziele ausgegeben werden, wird der BASE64-Datenstrom wieder in das Binärformat decodiert.
Eine Ausgabe über Druckertreiber resultiert oft in große Datenströme, da ein Druckertreiber Druckseiten mit allen grafischen Anweisungen der betreffenden Druckersprache erzeugt.
Theoretisch können Separation Exits verwendet werden. Allerdings können binäre Daten nicht mit Standard Exits separiert werden, da sie nicht lesbar sind.
Weitere Informationen und Beispiele finden Sie im Abschnitt Umgebungen für binäre Dokumente einrichten in der Systemverwaltung-Dokumentation.
Bei Systemen, die auf mehreren Knoten in heterogenen Umgebungen laufen, empfiehlt es sich, die folgenden Empfehlungen hinsichtlich der Benutzung von Codepages zu beachten.
Grundsätzlich ist sicherzustellen, dass die benutzte Codepage die Erfordernisse Ihrer Terminal-Emulation und System-Software erfüllt.
Empfohlene Codepage für IBM-Systeme: IBM01140 bei
englischsprachigen Systemen, IBM01140 oder IBM01141
bei deutschsprachigen Systemen.
Empfohlene Codepage für BS2000: EDF03DRV.
Die verwendete Codepage muss mit dem Natural-Profilparameter
CP angegeben werden.
Empfohlene Codepage für Windows: WINDOWS-1252.
Empfohlene Codepage für UNIX: ISO-8859-15.
Diese Codepages werden für englisch- und deutschsprachige Systeme empfohlen, weil sie sowohl englische Zeichen als auch deutsche Umlaute und das Euro-Zeichen zur Verfügung stellen.
Definieren Sie die verwendete Codepage:
in Ihrem Windows/UNIX-Betriebssystem,
im Entire System Server für UNIX in der Datei
npr.ini z.B. als: Locale_String=ISO-8859-15,
im Natural-Parametermodul, z.B.:
CP=ISO-8859-15,
im Natural RPC-Parametermodul, z.B.:
CPRPC=ISO-8859-15,CP=ISO-8859-15;
in der Broker-Attributdatei, z.B.:
DEFAULTS=CODEPAGE DEFAULT_ASCII=ISO-8859-15 DEFAULTS=SERVICE CONVERSION=SAGTCHA *ICU* CLASS=NPR, SERVER=*, SERVICE=*, DEFERRED=NO, APPMON=NO DEFAULTS=SERVICE CONVERSION=SAGTRPC *ICU* CLASS=RPC, SERVER=*, SERVICE=*, DEFERRED=NO, APPMON=NO
Informationen zur Definition von Knoten und Codepages innerhalb von Entire Output Management siehe Standard-Codepages und Knoten-Definitionen in der Systemverwaltung-Dokumentation.
Entire Output Management liest die Daten binär vom Entire System
Server und verwendet Entire Network oder den Entire Systems Management Adapter
(nur bei BS2000) als Transportschicht. Die Daten werden in die
Trigger-Container-Datei kopiert (siehe
Trigger-Container-Datei
in der Systemverwaltung-Dokumentation). Mit Hilfe von
Natural (unter Verwendung des Natural-Statement MOVE ENCODED)
konvertiert Entire Output Management die Daten von der Codepage des dezentralen
Großrechner-Knotens in die Codepage von Entire Output Management.
Weitere Informationen zu Codepages siehe Unicode and Code Page Support in der Natural-Dokumentation.
Entire Output Management kann Ausgaben von Großrechner-Betriebssystemen und von- UNIX- oder Windows-Systemen handhaben. Diese Ausgaben müssen als ASCII- oder EBCDIC-Dateien gespeichert werden (auf Großrechnern mit oder ohne Steuerzeichen).
Grundsätzlich handhabt Entire Output Management auf UNIX die selben Ausgabeformate wie auf Großrechnern, außer wenn Binärdaten verarbeitet werden müssen. Binärdaten müssen, bevor Sie von Entire Output Management verarbeitet werden, in das ASCII-Datenformat konvertiert werden.
Um Ausgabedaten aus UNIX- oder Windows-Verzeichnissen zu holen, benutzen Sie die UNIX-Knoten-Definitionen. Siehe Attribute eines UNIX- oder Windows-Knotens in der Systemverwaltung-Dokumentation.
UNIX-Anwendungen können direkt in ein Entire Output
Management-Dateiverzeichnis (ASCII-Dateien) drucken oder auf Spool-Systeme,
z.B. CUPS, zugreifen, um Ausgaben in die Druckerschlange eines virtuellen
Druckers zu drucken. In diesem Fall muss die Druckerschlange von CUPS mit einem
CUPS Backend, z.B. "pipe", verbunden sein (Standardeinstellung:
/usr/lib/cups/backend), das die Daten als ASCII-Dateien in dem
Entire Output Management-Verzeichnis speichert, das bei den Standwerten für
UNIX definiert ist. Siehe
Attribute eines
UNIX- oder Windows-Knotens in der
Systemverwaltung-Dokumentation.
Es gibt jedoch einige Schnittstellen, die unter UNIX nicht existieren und deshalb in einer Entire Output Management UNIX-Umgebung nicht benutzt werden können:
CA Spool
NOMPUT
Unter UNIX ist Entire Output Management so ausgelegt, dass man nur auf Druckern des Typs NATUNIX und DISKUNIX drucken kann. Ausführliche Informationen siehe Abschnitt Physische Drucker verwalten in der Systemverwaltung-Dokumentation.
Anstatt die Druckausgaben von Natural-Anwendungen in ein Spool-System zu leiten, können Sie sie direkt in eine Entire Output Management-Container-Datei leiten, ohne irgendwelche Zwischendateien in einem Dateisystem erstellen zu müssen.
Dies ist nur auf Großrechnern möglich. Siehe Direktes Drucken aus Natural nach Entire Output Management in der Installation und kundenspezifische Anpassung-Dokumentation.
Die Ausgabe kann während der Druckausgabe in eines der üblichen Multimedia-Formate konvertiert werden.
Der Druckertyp DISKUNIX steht zur Verfügung, um eine Datei zu konvertieren, nachdem sie auf die Platte geschrieben worden ist. Voraussetzung ist, dass die zu konvertierende Datei in Entire Output Management im Format "Text" (ASCII, ASA, Maschinencode), PDF oder PostScript (oder gemischt in Bündeln) gespeichert werden. Der DISKUNIX-Drucker konvertiert die Text-Reports gemäß den Formatdefinitionen in das gewünschte Format. Reports, die schon als PDF oder im PostScript-Format vorliegen, werden nicht formatiert, weil sie ja schon berechnet und gerendert wurden. Reports, die in PDF oder PostScript formatiert worden sind, werden lediglich in das gewünschte Ausgabeformat konvertiert, ohne dass dabei die Enscript-Parameter zur Anwendung kommen (siehe Formatierungsattribute für die Dateiformatkonvertierung unter DISKUNIX-Drucker in der Systemverwaltung-Dokumentation).
Wenn Trennblätter definiert sind, unterliegen diese jedoch den Formatdefinitionen, da es sich bei ihnen um Textteile des Reports handelt.
Wenn Bündel gedruckt werden sollen, sammelt DISKUNIX alle Reports, und zwar unabhängig davon, ob sie im Format Text, PDF oder PostScript vorliegen, und stellt sie in eine Einzeldatei des gewünschten Ausgabeformats. Alle Textteile (Text-Reports, Trennblätter) werden gemäß der Definition in den Formatparametern konvertiert. Zur Durchführung der Konvertierung benutzt DISKUNIX die Utilities Ghostscript und Enscript. Diese Utilities müssen auf dem UNIX-System installiert sein, auf das DISKUNIX schreibt.
Wenn UTF-8 als Datei-Codepage für das Lesen und Schreiben verwendet wird, können Sie anstelle von Enscript die UNIX-Utility Uniprint zum Berechnen und Ausgeben ("Rendering") benutzen. Uprint ist Bestandteil des UNIX-Pakets "yudit" (Unicode-Editor), das auf dem Knoten installiert werden muss, auf dem die Konvertierung erfolgt.
Die Konvertierung wird durch Eingabe im Ausgabeformat-Attributfeld in der Report-Definition angestoßen.
Bei Reports im Format PDF kann auf jeder Seite eine Maskendatei zur Anwendung kommen. Dabei handelt es sich um eine PDF-Datei mit transparentem Hintergrund. Diese Datei wird auf jeder Seite wie ein Stempel behandelt: Nur in den Teilen der Maskendatei, die transparent sind, erscheint der Originalbericht. Enthält die Maskendatei mehr als eine Seite, werden die entsprechenden Seiten des Originalreports überlagert.
Um die Überlagerungsfunktion in Entire Output Management benutzen
zu können, muss das Software-Paket "pdftk" (PDF-Toolkit) auf dem
Konvertierungsknoten installiert werden. Dieses Paket steht für Windows- und
UNIX-Maschinen zur Verfügung. Wenn das Feld Command
ausgefüllt wird, kann diese Kommandozeile benutzt werden, um die resultierende
Datei nach der Konvertierung weiter zu verarbeiten. Beispielsweise können die
Utilities ps2afp oder pdf2afp (die im IBM-Produkt
Infoprint enthalten sind) benutzt werden, um schließlich AFP-formatierte
Dateien zur Weiterverarbeitung zu erstellen.
Die oben erwähnten UNIX-Utilities sind Produkte von Drittanbietern. Sie sind kein Bestandteil von Entire Output Management. Die Software AG liefert diese Utilities nicht und leistet keinen Support dafür.
Der DISKUNIX-Drucker schreibt Textdateien in das UNIX-Dateisystem unter Verwendung der Codepage UTF-8. Wenn für eine Textausgabe kein Rendern erforderlich ist (z. B. PDF), aber die Codepage auf eine andere geändert werden soll, gehen Sie wie folgt vor:
Installieren Sie die Utility iconv auf Ihrem
UNIX-System (falls sie nicht bereits installiert ist).
Geben Sie dann die DISKUNIX-Druckerattribute an (siehe DISKUNIX-Drucker in der Systemverwaltung-Dokumentation) wie im folgenden Beispiel gezeigt:
Command: iconv
Filename: test
Filetype: txt
Opt1: -f UTF-8
Opt2: -t ISO_8859-15
Parm1: > destination.file
In diesem Beispiel erstellt der DISKUNIX-Drucker eine Textdatei
test.txt, ruft dann die Utility iconv auf und
übergibt die Datei test.txt als Eingabedatei. Die Datei hat das
Format UTF-8 und wird in die Datei destination.file
im Format ISO_8859-15 konvertiert.
Um weitere Operationen durchzuführen, schreiben Sie ein Skript,
das die Utility iconv entsprechend aufruft.
Entire Output Management überträgt Daten vom und zum Entire System Server auf UNIX. Erfolgt die Datenübergabe per Remote-Übertragung, werden die auf der Quellmaschine und Zielmaschine verwendeten Codepages in den meisten Fällen verschieden sein. Das bedeutet, dass Sie eines oder mehrere Middleware-Produkte einsetzen müssten, um eine Codepage-Umsetzung zu realisieren. Das kann letztlich komplexe Umgebungen zur Folge haben, in denen Sonderzeichen auf der Zielmaschine dennoch nicht immer in die gewünschten Zeichen umgewandelt werden.
Um dieses Problem zu vermeiden, senden Entire Output Management und Entire System Server benannte Zeichen anstelle der eigentlichen Zeichen. Entire Output Management benutzt die Trigraphen-Funktionalität des Entire System Server. Das bedeutet, dass nur 7-Bit-ASCII-Tabellen und EBCDIC-Basistabellen für die plattformübergreifende Umwandlung von Zeichen benutzt werden.
Entire Output Management benutzt folgende Adabas-Dateien:
die Definitionsdaten-Datei (logische Dateinummer 206),
die Aktivdaten-Datei (logische Dateinummer 91),
eine oder mehrere Container-Dateien,
die Trigger-Container-Datei.
Sie können dieselbe Adabas-Datei sowohl für die NOM-Definitionsdaten-Datei als auch für die NOM-Aktivdaten-Datei benutzen, jedoch ist in beiden Fällen die Angabe der logischen Dateinummer 206 bzw. 91 erforderlich.
Entire Output Management kann, wie im Folgenden beschrieben, Druckdateien aus ihrer ursprünglichen Quelle (z.B. JES Spool) in eine Container-Datei oder in die Aktivdaten-Datei kopieren.
Informationen zur Trigger-Container-Datei siehe Trigger-Container-Datei in der Systemverwaltung-Dokumentation.
Entire Output Management speichert Ausgaben in Arrays zu jeweils 16 KB. Adabas komprimiert Nullwerte und nachgezogene Leerstellen in alphanumerischen Feldern. Textdatenausgaben enthalten oftmals Blöcke mit Leerstellen, um die Daten in Listen- oder Tabellenform darzustellen. Diese Leerstellenblöcke werden von Entire Output Management selbst komprimiert. Das bewirkt eine effizientere Nutzung des Adabas-Datenbank-Speicherplatzes und weniger Datenbankzugriffe, und somit eine Verbesserung der Performance.
Entire Output Management kopiert die Report-Sourcen in eine Container-Datei, wenn einer der folgenden Umstände zutrifft:
Wenn Entire Output Management auf UNIX benutzt wird.
Wenn die Druckdaten von CA Spool, Natural Advanced Facilities
(NAF) oder der 3GL-Schnittstelle (einschließlich der virtuellen
VTAM-Druckeranwendung NOMVPRNT mit der Parametereinstellung
STORE=DB) kommen.
In BS2000: Wenn die Option Datei kopieren im Dialog Monitor-Standardwerte gewählt und mindestens eine Destination (Ausgabemedium) definiert ist. Siehe Monitor-Standardwerte - Register Container-Dateien.
In JES2, JES3 und POWER: Wenn eine Spool-Datei mit einer
DEST-Angabe verarbeitet wird, die mit einer der Destinationen
(Ausgabemedien) übereinstimmt, die im Dialog
Monitor-Standardwerte
definiert wurden. Siehe Monitor-Standardwerte
- Register Container-Dateien.
Trennen, Blättern und teilweises Drucken führt gewöhnlich dazu, dass ein Direktzugriff auf Satzbereiche der Ausgabe erforderlich ist. Der Zugriff auf Original-Druckdaten an der Quelle ist jedoch nicht immer möglich.
Wenn Container-Dateien benutzt werden, speichert Entire Output Management die Druckdaten vor der Verarbeitung von Report-Definitionen in einer Container-Datei. Die Original-Druckdaten werden als Ganzes kopiert, alle darauffolgenden Vorgänge wie Trennen, Durchblättern und teilweises Drucken erfordern keinen Zugriff auf die Original-Datenquelle, sondern verwenden die Druckdaten in der Container-Datei. Die Verarbeitung erfolgt daher sehr schnell.
Entire Output Management hält die gesamte Original-Druckdaten in
der Datenbank gespeichert, solange es wenigstens einen aktiven, darauf
zeigenden Report mit Speicherort (Adresse) S gibt. (Dabei steht
S für Source, nicht für Spool.) Dies kann
bedeuten, dass die Container-Datei mit sehr großen Ausgaben gefüllt wird, auch
wenn tatsächlich nur ein Bruchteil davon benötigt wird.
Die Speicherung von Druckausgabedaten in einer Container-Datei ist immer dann sinnvoll, wenn intensive Trennverarbeitung, Durchblättern oder teilweises Drucken erforderlich ist.
Wenn Sie intensive Trennverarbeitung durchführen, aber die sich daraus ergebenden Reports nur ein Bruchteil aus dem Gesamtoriginal sind, sollten Sie die Druckdaten in die Aktivdaten-Datei kopieren.
Das Speichern der Druckdaten in der Aktivdaten-Datei wird in der Report-Definition mittels der Option Reportinhalt in NOM-Datenbank kopieren gesteuert.
Ist diese Option markiert, wird der sich daraus
ergebende aktive Report von der in der Container-Datei liegenden
Original-Ausgabe in die Aktivdaten-Datei kopiert. (Die Speicherort-Markierung
des aktiven Reports ist D.) Wenn die nächste Bereinigung
durchgeführt wird und es keine aktiven Reports mit Speicherort S
gibt, die auf die Original-Ausgabe zeigen, wird sie aus der Container-Datei
gelöscht.
Sie sollten die Aktivdaten-Datei benutzen, wenn intensive Trennverarbeitung erforderlich ist, aber nur kleine Teile der Original-Druckdaten benötigt werden, oder wenn die resultierenden aktive Reports sehr unterschiedliche Ablaufdaten haben.
Auf lokalen z/OS-Systemen sollten aktive Reports nur dann in die Aktivdaten-Datei kopiert werden, wenn dies absolut nötig ist (z.B. um unbeabsichtigten Verlust durch Spool-Löschung zu vermeiden), weil das Speichern umfangreicher Reports in der Datenbank beträchtlichen Mehraufwand bedeutet.
Es ist jedoch zu beachten, dass, während der Lebenszeit der
Original-Ausgabe in der Container-Datei, dies für Reports, die mit der Option
Reportinhalt in
NOM-Datenbank kopieren bei der Report-Definition
erstellt wurden, bedeutet, dass diese Teile der Ausgabe tatsächlich wieder in
der Aktiven-Daten-Datei gespeichert werden, wohingegen Entire Output Management
bei der Speicherortangabe S nur Zeiger auf die Container-Datei
aufbewahrt.
Denken Sie daran, dass der aktive Report mit dem spätesten Ablaufdatum die Lebenszeit der gesamten Original-Ausgabe in der Container-Datei festlegt.
Die folgende Übersicht verweist auf die relevanten Abschnitte in der Systemverwaltung-Dokumentation.
Die Definition von Container-Dateien für
Großrechner-Spooling- und Jobeingabe-Systeme sowie die Spool-Destination-Angabe, die in die zugehörige Container-Datei kopiert wird, erfolgt unter Monitor-Standardwerte.
Entire Output Management auf UNIX erfolgt unter Knoten-Definitionen für einen UNIX- oder Windows-Knoten.
CA Spool erfolgt unter Standardwerte für CA Spool.
Natural Advanced Facilities erfolgt unter Standardwerte für Natural Advanced Facilities (NAF).
3GL-Schnittstellen erfolgt unter Verwaltung der 3GL-Schnittstellen.