Dieses Dokument beschreibt, wozu Entire Output Management dient und wie es funktioniert.
Es behandelt folgende Themen:
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.
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.
Sie können zu einem Report Benutzer zuweisen. Diese können den aktiven Report auf ihrem Bildschirm anzeigen, revidieren, exportieren (z.B. zu einem PC) zwecks Weiterverarbeitung und ihn drucken.
Jeder Entire Output Management-Benutzer hat ein Fach mit dem Namen
#Listeneingang. Standardmäßig erscheint ein Report, der einem
bestimmten Benutzer zugewiesen wird, im Fach #Listeneingang dieses
Benutzers.
Zusätzlich können Sie öffentliche Fächer, zu denen jeder Entire Output Management-Benutzer Zugang hat, definieren und aktive Reports an diese verteilen.
Außerdem können Benutzer ihre eigenen privaten Fächer definieren und darin aktive Reports ablegen.
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.
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
Bereinigung
Spool auf N gesetzt 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 (Spool oder
Dataset) 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.
Im Prinzip gibt es zwei Möglichkeiten, Binärdaten nach Entire Output Management zu übertragen:
Sie können die Direkteingabe-Schnittstelle zusammen mit der Open Print Option (OPO) verwenden. Ein Windows-Client leitet die Ausgabe der Windows-Systeme an Entire Output Management weiter. Dies kann die Ausgabe eines Windows-Druckertreibers oder eines beliebigen Programm sein, das Daten mittels des Windows-"Pipe"-Mechanismus an die Open Print Option weiterleiten kann. (Näheres siehe Abschnitt Open Print Option installieren in der Installation-Dokumentation). Mittels EntireX Remote Procedure Call (RPC) wird die Ausgabe nach Entire Output Management umgeleitet.
Sie können einen Report definieren, der binäre Daten von einem UNIX-
oder Windows-Verzeichnis erhält. In der Report-Definition muss
das Feld Binaer lesen auf
B gesetzt werden, um
anzugeben, dass die Datei in Binärformat verarbeitet werden soll.
Der Report wird durch die Entire Output Management-Trigger-Queue
geleitet, ähnlich wie bei der NOMPUT-Schnittstelle. Dazu muss die
Trigger-Queue aktiviert werden (Entire Output Management API und
User-Exit-Standardwerte). 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 des betreffenden Dateityps (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 leiten 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.
Jeder Report, den Entire Output Management über die Open Print Option
(OPO) erhält, kann mit benutzerdefinierten Metadaten angereichert werden. Die
Metadaten können auf dem Spool-Attribute-Bildschirm eines aktiven Reports oder in einem
User Exit, der das Feld SPOOL-ATTRIBUTES-EXTENDED verwendet,
eingesehen werden. Metadatenwerte, die die Länge der Terminal-Zeilenlänge der
zeichenbasierten Benutzungsoberfläche von Entire Output Management
überschreiten, werden auf eine Zeile verkürzt und mit dem Fortsetzungszeichen
"..." markiert. Metadaten werden an Entire Output Management
mittels einer XML-Datei übergeben, die in einer OPO-Druckerdefinition definiert
werden kann. Näheres siehe Abschnitt Open Print Option
installieren in der
Installation-Dokumentation.
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 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.
Siehe Direktes Drucken aus Natural nach Entire Output Management in der Installation und kundenspezifische Anpassung auf Großrechnern-Dokumentation.
Direktes Drucken aus Natural auf UNIX ist nur bei Linux-Systemen möglich. Voraussetzung ist, dass die Open Print Option (OPO) auf Linux installiert ist.
Um direktes Drucken aus Natural auf UNIX zu nutzen, müssen Sie folgende Maßnahmen durchführen:
Weisen Sie in der Natural Configuration Utility einen Natural Report
einem Drucker mit Profiltyp NOM zu. Beschreibung siehe
Natural Configuration Utility-Dokumentation unter
Overview of Profile Parameters > Natural Execution Configuration
> Device/Report Assignments.
Binden Sie mit der Natural Configuration Utility ein Druckerprofil mit
der Methode NOM an. Beschreibung siehe Natural
Configuration Utility-Dokumentation unter Overview of
Configuration File Parameters > Global Configuration File > Printer
Profiles > NOM Printer Profiles.
Passen Sie die Konfigurationsdatei nomrptConf.xml
kundenspezifisch an. Beschreibung siehe Open Print Option
installieren.
Dadurch kann Natural auf UNIX die Open Print Option (OPO) aufrufen. OPO überträgt dann die Natural-Druckausgabedaten an eine Entire Output Management-Container-Datei auf UNIX oder Großrechner. Anschließend können aus der Container-Datei die Druckausgabedaten von Entire Output Management weiterverarbeitet werden.
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 ausgegeben wurden ("Rendering"). 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 Linus-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 auch keinen Support dafür.
Entire Output Management überträgt Daten vom und zum Entire System Server auf UNIX und von und zur Open Print Option (OPO). 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, Entire System Server und OPO benannte Zeichen anstelle der eigentlichen Zeichen. Entire Output Management benutzt die Trigraphen-Funktionalität des Entire System Server und benannte HTML-Zeichen bei OPO. 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 Bildschirm Monitor-Standardwerte gewählt und mindestens eine Destination (Ausgabemedium) definiert ist. Siehe Container-Dateien definieren.
In JES2, JES3 und POWER: Wenn eine Spool-Datei mit einer
DEST-Angabe verarbeitet wird, die mit einer der Destinationen
(Ausgabemedien) übereinstimmt, die im Bildschirm
Monitor-Standardwerte
definiert wurden. Siehe Container-Dateien
definieren.
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 darauf folgenden 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 In NOM DB kopieren gesteuert.
Ist diese Option auf Y
gesetzt, 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
In
NOM DB 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.