Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.03.1991 - 

Konvertierung innerhalb der IBM-Midrange-Welt

Fußlangeln auf dem Weg vom System /36 zur AS/400

Entgegen den Behauptungen der IBM hat die Konversion von

System/36-Anwendungen auf die AS/400 eine ganze Reihe von Tücken. Die folgenden Ratschläge von Karen Joyner* sollen umstiegswilligen Anwendern helfen, die gefährlichsten Fallstricke zu umgehen.

Man muß kein Theologe sein, um zu wissen, daß der Umzug in eine Gemeinde mit einem anderen Glaubensbekenntnis meist nur einen Ortswechsel bedeutet, während eine Konversion weitreichende

Veränderungen mit sich bringt. Ähnlich verhält sich die Sache für

/36-Anwender, die entscheiden müssen, ob sie eine frisch angeschaffte AS/400 im "native mode" oder in dem der /36er-Maschinen benutzen.

Die Portierung einer Anwendung vom System/36 in die System/36-Umgebung des AS/400 gestaltet sich mit der Umstellungshilfe von IBM recht einfach. Dabei kann es allerdings vorkommen, das daß

Ergebnis nicht optimal an die neue Umgebung angepaßt ist. Die Anwendung wird auf der AS/400 möglicherweise recht langsam laufen, unter Umständen sogar langsamer als auf dem System/36.

Konversion als beste Alternative

Eine Feinabstimmung der Systemsteuersprache

(OCL - Operation control language) erleichtert die Sache etwas. So

können zum Beispiel BLDFILE-Befehle, die zwar auf dem System/36, nicht aber auf der AS/400 effizient sind, durch permanente Plattendateien ersetzt werden. DELETE-Befehle lassen sich durch CLRPFM-Befehle (Clear physical file member - physisches Datefield löschen) ersetzen.

Schnelle, einfache Detailkorrekturen wie diese verhelfen der Anwendung zwar zu einem etwas besseren Laufverhalten in der System/36- Umgebung. Um die erweiterten Funktionen und die volle Leistung der AS/400 jedoch wirklich nutzen zu können, müssen die

Programme entweder von Grund auf umgeschrieben oder konvertiert

werden.

Die bestmögliche Anpassung einer Anwendung läßt sich natürlich durch Umschreiben erzielen, doch fehlt den meisten Anwendern dafür sowohl die Zeit als auch das nötige Fachwissen. Außerdem kann es sich kaum ein Anwender leisten, den beträchtlichen Investitionswert, den seine vorhandene /36-Software darstellt, abzuschreiben. Die Konversion ist daher im allgemeinen die schnellste und billigste Methode, mit dem Problem fertig zu werden, um sich wieder der eigentlichen Arbeit widmen zu können.

Ist die Entscheidung für die Konvertierung gefallen, fiehlt es sich kaum, sämtliche vorhandenen Anwendungen im Hauruck-Verfahren umzuschreiben und an einem Wochenende zum Laufen zu bringen. Besser ist es, sich ein Pilotprojekt auszusuchen. Am besten beginnt man mit einer relativ unkomplizierten selbstständigen Anwendung (zum Beispiel mit der Anlagevermögensverwaltung), von der der Unternehmenserfolg nicht

unmittelbar abhängt. So erhält man Gelegenheit, sich mit dem

Konvertierungsvorgang und dem neuen System vertraut zu machen und den tatsächlich erforderlichen Arbeits- und Zeitaufwand zu ermitteln.

Nach Abschluß des Pilotprojekts wird dann darüber entschieden, welche Anwendungen umgehend, welche später und welche gar nicht konvertiert werden sollen. Dabei handelt es sich um wichtige

Entscheidungen, die niemand der Unternehmensleitung abnehmen kann. Kosten und Nutzen müßen sorgfältig abgewogen werden. Dabei können folgende Überlegungen hilfreich sein:

- Zeitkritische Anwendungen sollten konvertiert werden. In den meisten Unternehmen und Organisationen stellt die Lohnabrechnung nur einmal wöchentlich oder alle zwei Wochen an. In diesem Fall ist es nicht weiter schlimm, wenn die entsprechende Anwendung in der

System/36-Umgebung nicht allzu schnell läuft. Für eine Dienstleistungsfirma, die sich ausschließlich mit Lohnabrechnungen beschäftigt, lohnt sich dagegen der Konversionsaufwand.

- Anwendungen, die normalerweise während der Hauptgeschäftszeiten laufen, wo eine erhöhte Verarbeitungsgeschwindigkeit von Vorteil ist, sollten konvertiert werden. Anwendungen, die gewöhnlich außerhalb der Bürozeiten laufen, können dagegen warten.

- Programme, die einer intensiven Weiterentwicklung unterliegen und daher ständig verbessert, erweitert und auf Fehler untersucht werden,

sollten konvertiert werden. In der systemeigenen AS/400-Umgebung läßt sich nämlich die Entwicklung leichter vorantreiben.

- Verschiedene Anwendungen, die in einem Paket integriert sind, sollten in einem Zug konvertiert werden. Als Beispiel kann ein integriertes Vertriebssystem dienen, bei dem die Module für Bestellwesen, Auftragserfaßung und Bestandskontrolle auf die gleiche Artikelstammdatei zugreifen. Werden alle Module in systemeigene Anwendungen umgewandelt, läßt sich die Artikelstammdatei extern beschreiben. Dadurch besteht die Möglichkeit, Feldspezifikationen zu ändern oder Felder hinzuzufügen, ohne daß nach dem Rekompilieren Fehler auftreten.

Gemischte Umgebung mit zusätzlichen Funktionen

Können Anwendungen in einer gemischten Umgebung Dateien gemeinsam nutzen? Theoretisch besteht diese Möglichkeit, ihre Umsetzung in die Praxis ist jedoch kompliziert. Geht man wie im obigen Beispiel davon aus, daß Bestellwesen und Auftragserfassung konvertiert werden und die Bestandskontrolle vorerst unverändert bleibt, so ergeben sich zwei Möglichkeiten, das Problem der gemeinsamen Dateinutzung zu lösen:

a) Man beschreibt die Artikelstammdatei für Bestellwesen und Auftragserfassung extern und verwendet in der Bestandskontrolle eine programminterne Beschreibung. Die Dateibeschreibung innerhalb der Bestandskontrolle muß der externen Beschreibung der Artikelstammdatei Feld für Feld genau entsprechen. Wird die externe Beschreibung der Stammdatei verändert, muß die interne Beschreibung in der Bestandskontrolle anschließend manuell angeglichen werden.

b) Man bleibt für die drei Anwendungen bei einer programminternen Beschreibung der Artikelstammdatei. Werden an der Datei Änderungen vorgenommen, müssen die Dateibeschreibungen aller drei Anwendungen abgeglichen werden.

Wie steht es mit einer Erweiterung des Funktionsumfangs einer Anwendung im Laufe des Konvertierungsprozesses?

Systemberater werden oft gebeten, quasi als Zugabe "ein paar Änderungen" vorzunehmen, wenn sie gerade ohnehin am Programmcode arbeiten. Von solchen scheinbar günstigen Gelegenheiten ist im allgemeinen abzuraten.

In den meisten Fällen ist die Konversion auch ohne zusätzliche

Komplikationen diffizil genug. Verbesserungen lassen sich im Anschluß daran leichter anbringen. Außerdem ist es praktisch unmöglich, den Zeitbedarf der Umstellung mit gleichzeitigen Änderungen abzuschätzen. Hilfsprogramme zur Beschleunigung sind effektiver, wenn nicht versucht wird, zuerst die Anwendung zu erweitern.

Die möglichen Auswirkungen auf die Testphase und auf Anwender, die sich außer mit, der Benutzung der AS/400 noch mit Software-Anderungen vertraut machen müßen, sollten ebenfalls in Betracht gezogen werden. Insgesamt folgt daraus, daß besser ist, Erweiterungen des Funktionsumfangs erst nach der Konversion vorzunehmen.

Die Regeln für Objektbenennung sind bei der AS/400 sehr viel strenger als beim System/36. Um Schwierigkeiten zu vermeiden, sollte sich der Anwender daher an einen im ganzen System durchgehend gültigen Satz von Namenskonventionen halten.

Gehen wir zum Beispiel davon aus, daß sich auf dem System /36 oder seiner Umgebung folgende Objekte befinden: eine Bibliothek ARLIB, ein RPG-Programm AR100, eine Prozedur AR100, eine temporäre physische Datei AR100S und eine Anzeigedatei AR100S. In der systemeigenen AS/400-Umgebung dürfen zwischen Objekten gleichen Typs keine Namensgleichheiten auftreten. Bei ALIB ergibt sich kein Problem, da es sich um ein Objekt vom Typ *LIB handelt, Prozeduren und Programme unterscheiden sich dagegen nach dem Kompilieren ebenso wie temporäre physische Dateien und Anzeigedateien nicht mehr im

Objekttyp.

Eine Möglichkeit, diese Klippe zu umschiffen, besteht darin, an den jeweiligen Namen einen Kennbuchstaben anzuhängen, der den Objekttypen gilt: "-R" für RPG-Programme, "-C" für CL-Programme

(Control Language), "-P" für physische Dateien und "-S" (Screen) für

Anzeigedateien. So entstehen die eindeutigen Namen AR100R, AR100C, AR100P und AR100S. Dabei ergibt sich jedoch das Problem, daß beim Ausdruck einer Bibliotheksliste aller Objekte zwar alle AR-Objekte all geschlossene Gruppe ausgegeben werden, RPG-Programme, CL-Programme und Dateien verschiedenen Typs aber wahllos über die Liste verstreut sind.

Stellt man dagegen den Objektnamen einen Kennbuchstaben voran (RAR100, CAR100, PAR100, SAR100), werden die Objekte zwar einwandfrei nach Objekttypen geordnet, dafür sind die einzelnen Gruppen mit RPG-Programmen, CL-Programmen und Dateien anderer Anwendungen (ROE100, COE10 etc.) durchsetzt.

Die beste Lösung besteht wolle darin, einen einzelnen Kennbuchstaben für den Objekttyp in den Objektnamen einzufügen. Man

verwenden mit anderen Worten die ersten zwei Zeichen zur Kennzeichnung der Anwendung (zum Beispiel AR), das dritte Zeichen stellt für den Objekttyp (R, C, P, S), die restlichen sieben Zeichen verbleiben für die Bezeichnung des individuellen Objekts. Das Ergebnis wären in unserem Fall die Objektnamen ARR100, ARC100, ARP100 und ARS 100. Auf diese Weise wird die Ausgabe wunschgemäß geordnet.

System/36-Bibliotheken enthalten Quellprogramme, kompilierte Programme (Objektprogramme) und Prozeduren, aber keine Dateien. AS/400-Libraries können dagegen alles mögliche enthalten: Quelldateien für RPG-, Cobol-, DDS-, CL- und FMT-Dateifelder, RPG-, Cobol- und CL-Programme, physische, logische und Anzeigedateien sowie andere Objekte. Auf der AS/400 gehört jeder Objekt zwangsläufig zu einer Bibliothek. Für deren Organisation bieten sich mehrere Methoden an.

Das Einrichten von Bibliotheken

Eine Möglichkeit ist das Ordnen nach Anwendungen. Dabei bilden alle Objekte der Lohnabrechnung, der Debitorenbuchhaltung und der Auftragserfaßung jeweils eine eigene Bibliothek. Bei dieser Methode liegt das Problem darin, daß von jeder Bibliothek, die ihre eigenen Datendateien besitzt, häufig Sicherungskopien erstellt werden müssen. Außerdem stellt sich die Frage, wo die Dateien einer integrierten Anwendung untergebracht werden sollen.

Die zweite Möglichkeit besteht im Ordnen nach Funktionen. Dabei füllen alle Quelldateien, ausführbaren Programme und Datendateien jeweils eine eigene Bibliothek. Sind die so entstandenen Verzeichnisse zu groß, können sie zusätzlich nach Anwendungen aufgeteilt werden. Dieses Schema ermöglicht es dem Anwender, Datendateien öfter zu sichern als Programmdateien und jederzeit die Quellbibliothek zu löschen, falls der Plattenspeicher knapp wird.

Die geeignetste Vorgehensweise liegt wohl in einer Verbindung

beider Methoden. Dabei werden Programmbibliotheken nach Anwendungen (Lohnabrechnung, Debitorenbuchhaltung, Auftragserfaßung etc.) geordnet. Dann legt der Anwender entweder eine große Datenbibliothek für sämtliche Programme an oder ordnet ihnen einzeln eine eigene Datenbibliothek zu. Auf diese Weise können die Zeitabstände der Sicherungskopien leicht an den jeweiligen Objekttyp angepaßt werden.

Dateien werden auf dem System/36 bekanntlich durch die Programme beschrieben, die auf sie zugreifen, während sie auf der AS/400 normalerweise extern beschrieben sind. Interne Beschreibungen sind auf der AS/400 ebenfalls möglich und im Falle von temporären Arbeitsdateien auch vertretbar. Das Verwenden interner Beschreibung bei kritischen Dateien bedeutet allerdings den Verzicht auf einige besondere Stärken der AS/400.

Das Problem der Dateiorganisation

Der Unterschied zwischen internen und externen Dateibeschreibungen wirft bei der Konvertierung gewisse Probleme auf. So kann zu einer System/36-Anwendung für die Auftragserfassung eine Auftragsstammdatei gehören, die einen Kopfsatz für jeden Auftrag (Kundenname, Adresse, Zahlungsbedingungen, Fälligkeitsdatum etc.), Postensätze für die Bestellposten, Kommentarsätze, diverse Gebühren und Frachtspesen enthält.

Auf dem System/36 sind solche Dateien, die aus unterschiedlich

aufgebauten Datensätzen bestehen, zulässig. Auf dem AS/400 müssen extern beschriebene physische Dateien einen einheitlichen Satzaufbau aufweisen. Dann wird es notwendig, eine einzelne /36-Datei in mehrere physische AS/400-Dateien umzuwandeln.

Um das zu bewerkstelligen, sind Änderungen in den Programmen, die auf die Datei zugreifen, nötig. Ein Programm, das auf dem System/36 eine Datei zu lesen Hatte, muß auf der AS/400 möglicherweise mehrere Dateien lesen. Eine System/36-Datei, die unterschiedliche Formate enthält, kann durch eine logische AS/400-Datei (oder "Sicht") ersetzt werden, die sich über mehrere physische Dateien erstreckt. Der Anwender kann aber auch eine Routine schreiben, die dem System mitteilt, wann welche Datei zu lesen ist. Unter Umständen muß in dem Datensatz noch ein Feld hinzugefügt werden, das die Lesefolge festlegt.

Fehler durch gleichnamige Felder

Außerdem sollte beachtet werden, daß innerhalb einer

AS/400-Anwendung die Feldnamen aller zugehörigen Dateien

unverwechselbar sein müssen. Gleichnamige Felder, die sich in Größe,

alphanumerischer Ausrichtung sind Anzahl der Dezimalstellen

unterscheiden, führen zwangsläufig zu Fehlfunktionen. Trotz des erforderlichen Aufwands lohnt sich die Durchführung dieser Änderungen.

Auf dem System/36 gibt es neben der indizierten

Dateiverarbeitung zwei weitere Verfahren zur Ordnung von Informationen: Alternativindizes und sortierte Dateien.

Einem Alternativindex entspricht auf der AS/400 eine logische Datei, die Sort-Funktion des System /36 ist mit dem

AS/400-Sort-Dienstprogramm gleichbar. Allerdings werden

Sort-Spezifikationen auf dem System/36 direkt interpretiert, wenn sie in einer Prozedur auftreten, während Formatdaten (FMTDTA - Format data) auf der AS/400 innerhalb eines CL-Programms kompiliert werden und auf einen Quelleintrag verweisen, der die Sort-Spezifikationen enthält. Daher kann das AS/400-Sort-Dienstprogramm weder Bedingungsausdrücke noch Ersatztfunktionen verarbeiten.

Als Alternative bietet sich auf der AS/400 beispielsweise die Funktion OPNQRYF (Open query file - Abfragedatei öffnen) an, die jedoch am besten auf extern beschriebene Dateien angewendet wird. Sie erlaubt es, den Inhalt physischer und logischer Dateien zu sichten, bestimmte Datensätze auszuwählen und nach verschiedenen Kriterien zu ordnen. Zudem können auch einige Bedingungsausdrücke verarbeitet werden.

Control Language auf der /36 und der AS/400

Während Datendateien und RPG-Programme relativ einfach

umzuwandeln sind, ist die Prozedur-Konvertierung von der

/36-Job-Control-Language OCL nach CL sehr viel schwieriger. Da stellt im Vergleich zu OCL eine neue Sprache dar. Für manche OCL-Befehle existieren äquivalente CL-Befehle, zu anderen System/36-Befehlen, wie REGION, CONDENSE und COMPRESS, gibt es auf dem keine Parallelen.

Auf dem System/36 läßt sich mit der Funktion IF ACTIVE feststellen, ob bestimmte Prozeduren aktiv sind. Falls andere Prozeduren laufen, können geeignete Maßnahmen getroffen werden. Da das AS/400 keine vergleichbar Funktion kennt, muß die Datenintegrität auf andere Weise sichergestellt werden. Ein möglicher Ansatz besteht darin, Dateien über den Befehl ALCOBJ (Allocate object in Objekt zuweisen) zuzuordnen und den Job nur auszuführen, wenn die geforderte Zuweisung möglich ist.

Ersatzfunktionen des System /36 werfen ein weiteres Problem bei der Konvertierung auf, das man normalerweise dadurch umgeht, daß eine Variable deklariert und - möglicherweise unter Verwendung von

Ersatzzeichenfolgen - vor Ausführung der Anweisung geladen wird.

Die Funktion "IF DATAFI" wird auf dem System/36 häufig benutzt, um festzustellen, ob eine Datei existiert, die dann entweder gelöscht oder angelegt werden soll. Auf der AS/400 ist diese Funktion überflüßig, da temporäre Dateien weder angelegt noch gelöscht werden sollten.

Auf dem System/36 kann eine ?FA.xxx'?-Teilzeichenfolge verwendet werden, um festzustellen, ob sich Sätze in einer Datei befinden. Auf der AS/400 gibt es keinen entsprechenden CL-Befehl. Dafür besteht die Möglichkeit, einen neuen Befehl oder ein Programm zu generieren, mit dessen Hilfe sich Sätze im betreffenden Dateifeld finden lassen.

Zum Schluß sollen noch einige Punkte aufgelistet werden, bei denen sich Probleme ergeben könnten:

- Die Befehle BLDFILE und DELETE funktionieren auf dem System/36

einwandfrei, sind aber auf der AS/400 äußerst ineffizient.

- Temporäre Arbeitsdateien sollten nicht eingerichtet und wieder gelöscht,

sondern als Teil der Anwendung permanent angelegt werden. Nach der

Jobausführung wird dann mit Hilfe des Befehls CLRPFM (Clear physical file member - physisches Dateilfeld löschen) nur der Dateiinhalt gelöscht.

Temporäre Arbeitsdateien führen zu Konvertierungsproblemen, wenn ihre Namen den ID-Code der jeweiligen Workstation enthalten. Das System/36 verwendet Workstation-ID-Codes von zwei Zeichen Länge, die an den Dateinamen angehängt werden (DATEI.xx). Auf der AS/400 kann der Workstation-ID-Code bis zu zehn Zeichen lang sein. Da Dateinamen nur zehn Zeichen umfaßen dürfen, stellt sich die Frage, wie Arbeitsdateien überhaupt benannt werden sollen.

Ein gangbarer Weg besteht darin, eine Datei in der

QTEMP-Bibliothek einzurichten. Diese wird automatisch angelegt, wenn sich ein Benutzer einloggt und einen Job exklusiv ausführt. Da die

QTEMP-Bibliothek gelöscht wird, sobald sich der Benutzer wieder ausloggt, ergeben sich keinerlei Schwierigkeiten, solange der Benutzer eine Task innerhalb einer Sitzung startet und wieder beendet. Andernfalls gehen sämtliche in der QTEMP-Bibliothek verbliebenen Daten verloren.

Als Alternative bietet sich an, in einer geeigneten Bibliothek eine

permanente Arbeitsdatei anzulegen, die mehrere Dateifelder enthalten darf. Sobald ein Job eine Arbeitsdatei benötigt, wird in der angegeben physischen Datei ein Dateifeld eingerichtet, dessen Name dem jeweiligen

Workstation-ID-Code entspricht. Auf diese Weise besitzt jede Workstation ihr eigenes unverwechselbares Dateifeld.

- Jeder Zugriff auf ein numerisches Feld, das nicht initialisiert ist oder

alphanumerische Zeichen enthält, verursacht einen Dezimaldatenfehler. Diesen Umstand sollte man berücksichtigen, um ernsthafte Probleme zu vermeiden. Numerische Felder, die in Datenstrukturen definiert werden, müßen initialisiert und auf Null gesetzt werden, bevor sie durch ein Programm angesprochen werden können. Bei der Konvertierung von System/36-Dateien oder dem Hinzufügen von Datensätzen zu einer Datei sollte man sich daher vergewissern, daß alle numerischen Felder der betreffenden Sätze initialisiert sind.

- Die AS/400 verwendet zur Zahlenverarbeitung ein gepacktes Format.

Numerische Felder treten deshalb normalerweise in gepackter Form auf. Trifft das System auf ein ungepacktes Feld, wird dieses gepackt, verarbeitet und wieder entpackt. Numerische Schlüsselfelder und Felder, die als Ordnungsmerkmall dienende Datumsangaben enthalten, sollten im Interesse einer effizienteren Kodierung ungepackt bleiben. Unnötige Leerzeichen sollten aus System/36-Datensätzen entfernt werden, um die AS/400-Datensätze möglichst platzsparend zu gestalten.

Insgesamt läßt sich sagen, daß eine gründliche Planung das Verhältnis von Aufwand und Nutzen bei der Portierung von /36 auf die AS/400 optimiert. Ein Pilotprojekt fördert zudem die Vertrautheit mit der neuen Umgebung.