Die Version 3.4.1 steht nur für Großrechner-Plattformen zur Verfügung, aber nicht für UNIX-Plattformen. Bei der nächsten Produktfreigabe wird Entire Output Management wieder für Großrechner- und für UNIX-Plattformen zur Verfügung stehen.
Diese Release Notes informieren Sie über Verbesserungen und neue Funktionalität, die mit Version 3.4.1 des Output Management (Produktkürzel NOM) zur Verfügung gestellt werden.
Folgende Themen werden behandelt:
Bevor Sie Entire Output Management auf einem Großrechner installieren können, müssen folgende Software AG-Produkte bereits in Ihrer Umgebung installiert sein:
Adabas Version 8 oder höher.
Natural Version 8.2 oder höher; bei der Natural-Installation muss die Software AG Editor-Komponente mit installiert worden sein.
Entire System Server Version 3.5 oder höher.
Entire System Server Version 2.1.4.17 für UNIX/Windows, oder eine höhere Version (optional, für Zugang zu UNIX bzw. Windows).
System Automation Tools Version 3.4.1 oder höher.
Natural Security (optional, für openUTM-Benutzer unter BS2000/OSD wird Natural Security benötigt).
EntireX Version 8.2 oder höher (optional, für Multi-CPU-Unterstützung).
Entire Network (optional, für Multi-CPU-Unterstützung).
Con-nect (optional).
Bei dieser Version nicht zutreffend.
Entire Output Management Version 3.4.1 benutzt große Pufferspeicher (bis
zu 16 KB), um Datensätze für die Speicherung in Adabas zu komprimieren, wobei
die Komprimierung durch das Modul NOMCOMPR ausgeführt wird. Falls
die Größe des Natural-Puffers für lokale Daten bei einem Aufruf von
NOMCOMPR überschritten wird, gibt Natural den Fehler NAT0909 aus.
Daher wird empfohlen, den Wert des Natural-Profilparameters
DATSIZE anfangs auf mindestens 500 (KB) zu setzen.
Die Einstellung NTLFILE 91 des Makros
NTLFILE im Natural-Parametermodul ist nicht mehr
optional. Diese Angabe muss ab jetzt auch dann vorhanden sein, wenn Sie nur ein
eine einzelne Entire Output Management-Datendatei verwenden.
Ab Version 3.4.1 müssen die Adabas-Dateien, die von Entire Output Management auf Großrechnern verwendet werden, mit übergreifenden Datensätzen ("Spanned Records") benutzt werden.
Die Migration auf Version 3.4.1 ist möglich ab Version 3.2.1, 3.2.2 oder 3.3.1, jedoch nicht von früheren Versionen.
Eine ausführliche Beschreibung des Migrationsvorgangs finden Sie im Abschnitt Migration von einer früheren Version in der Installation-Dokumentation.
Zusätzlich zur Durchführung des Migrationsvorgangs sind folgende Maßnahmen nötig:
Die Namen von Parameter Data Areas (PDAs) sowie die Strukturen in Data
Areas haben sich geändert. Deshalb müssen Sie alle Entire Output Management
User Exits und Anwendungsprogrammierungsschnittstellen (APIs) an die neuen
Namen (z.B. NOMEXnnP Parameter Data
Areas in der Bibliothek SYSNOMS) und die neuen Feldformate und
-längen anpassen (z.B. ändern Sie +P-SPOOL-ATTRIBUTES-EXTENDED von
(A/120) DYNAMIC nach (A) DYNAMIC), und sie
anschließend neu katalogisieren. Weitere Informationen und Beispiele sind in
der Bibliothek SYSMOMS vorhanden.
Sie müssen mit der neuen Version alle Ihre User Exits und Programme neu katalogisieren, die Entire Output Management-Anwendungsprogrammierungsschnittstellen (APIs) benutzen.
Alle gelösten Probleme der Version 3.3. und der zugehörigen Service Packs sind in dieser Version enthalten.
Diese Version bietet folgende Verbesserungen und neue Funktionalität:
Die internen Datenstrukturen von Entire Output Management wurden durch die Verwendung von langen Adabas-Alpha-Feldern und übergreifenden Adabas-Datensätzen ("Spanned Records") verbessert. Dies führt zu einer Verbesserung der Performance.
Entire Output Management-Objekte können von einer Entire Output Management-Umgebung in eine andere exportiert werden. Dadurch können Sie in einer anderen Umgebung dieselben Objekt-Definitionen verwenden.
Weitere Informationen siehe Objekte in eine andere Entire Output Management-Umgebung kopieren in der Systemverwaltung-Dokumentation.
Ein Report kann identifizierende Attribute aus nur einer Identifikationsquelle enthalten. In früheren Versionen war es möglich, für mehrere Identifikationsquellen Attribute zu vergeben. Dies hat teilweise zu fehlerhaften Attributen in den Reports geführt, da Werte überschrieben wurden. Dies wurde berichtigt. Ab dieser Version ist es nur noch möglich, eine einzige Identifikationsquelle in einem Report zu definieren.
Enthält ein existierender Report noch mehrere Identifikationsquellen, so wird beim Öffnen des Reports darauf hingewiesen, dass beim Speichern nur noch die Attribute für die gewählte Identifikationsquelle erhalten bleiben. Die Attribute für die anderen Identifikationsquellen des Reports gehen verloren. Wenn Sie diese Attribute behalten möchten, empfehlen wir Ihnen, vor dem Öffnen eines Reports mit mehreren Identifikationsquellen Kopien des Reports anzulegen und in diesen jeweils eine andere der Identifikationsquellen zu definieren.
Ein Report kann in eines der folgenden gebräuchlichen Multimedia-Dateiformate konvertiert werden: ASCII Text, PDF und PostScript. Die Konvertierung kann entweder beim Laden oder beim Drucken des Reports erledigt werden. Weitere Informationen siehe Konvertierung des Report-Formats.
Anmerkung:
In der nächsten Version werden weitere Verbesserungen an dieser
neuen Funktionalität zur Verfügung gestellt.
Ein Report kann identifizierende Attribute aus nur einer Identifikationsquelle enthalten. In früheren Versionen war es möglich, Attribute für mehr als eine Identifikationsquelle zu definieren. Dies konnte zu inkorrekten Report-Attributen führen, weil einige einige Werte überschrieben wurden. Dies wurde nun korrigiert. Ab dieser Version können Sie beim Erstellen eines Reports nur noch Attribute für eine Identifikationsquelle definieren.
Es kann jedoch sein, dass in bereits vorhandenen Report-Definitionen Atrribute für mehr als eine Identifikationsquelle enthalten sind. Wenn Sie eine solche Report-Definition öffnen, erhalten Sie eine Meldung, die daruf hinweist, dass beim Speichern dieser Report-Definition nur die Attribute für die ausgewählte Identifikationsquelle erhalten bleiben, wohingegen die der anderen Identifikationsquelle verloren gehen. Falls Sie diese anderen Attribute behalten möchten, müssen Sie entsprechend viele Kopien dieser Report-Definition erstellen, bevor sie sie öffnen.
Bei den Monitor-Standardwerten für POWER und JES wurde eines neues Feld (Fehler) hinzugefügt, in dem Sie eine SYSOUT-Klasse für SYSOUT-Dateien definieren können, die bei der Verarbeitung zu einem Fehler führen.
Die Zugriffsberechtigungen für Benutzer (siehe zum Beispiel Berechtigungen für Report verwalten wurden nicht immer korrekt ausgewertet. Dies konnte zu inkonsistenten Zugriffsberechtigungen führen. Dies wurde behoben.
Bei der UNIX-Knoten-Definition wurde das Feld Suspend durch das Feld Status-Code mit einem größeren Wertebereich ersetzt. Siehe Felder: UNIX-Knoten-Definitionen in der Systemverwaltung-Dokumentation.
In der Bibliothek SYSNOMS stehen neue
Anwendungsprogrammierungsschnittstellen (Application
Programming Interfaces/APIs) zur Verfügung:
DOCARL11 (Englisch) und DOCARL12
(Deutsch)
Diese APIs können verwendet werden, um aktive Reports sortiert nach Erstellungszeitpunkt aufzulisten.
Entire Output Management prüft jetzt, ob die Katalogisierungsdatumswerte bei allen User Exits mit der aktuellen Produktversion konsistent sind.
Ab dieser Version werden die folgenden physischen Druckertypen nicht mehr unterstützt:
HPSPOOL
OS2PM
WINPM
WINPM32
Die vorliegende Entire Output Management-Dokumentation kann UNIX-spezifische Informationen enthalten, die für die Version 3.4.1 nicht relevant sind, weil diese Version nicht für UNIX-Plattformen verfügbar ist (siehe oben).