Hot-Tip Serviceprogrammerstellung und Mehrfach-Datenstruktur

11. November 2008 | Von | Kategorie: Tools, Hot-Tips

Ein Internet-Artikel aus der NEWSolutions mit NEWSabo plus Zugang zwei Hot Tips: Mehrfach-Datenstruktur als Parameter übergeben und Henne-und-Ei Problem bei Serviceprogrammerstellung

M.H., nach einen Tipp von Gary Guthrie, News/400 USA und einem News-Beitrag von Babara Morris, IBM

Henne-und-Ei Problem bei Serviceprogrammerstellung

Ich hatte bisher zwei Serviceprogramme A und B, deren Prozeduren aus Anwendungs- bzw. anderen Service-Programmen aufgerufen werden. Soweit kein Problem. Nun sind jedoch Funktionen aus A und B in einem neuen Serviceprogramm C modularisiert worden, das aber gleichzeitig Prozeduren aus A verwendet. Die Umwandlung von A schlägt nun fehl, weil die Prozeduren aus C noch nicht zur Verfügung stehen, umgekehrt lässt sich C nicht erstellen, weil A noch nicht als Programmobjekt vorliegt. Abgesehen davon, dass dieses Problem durch ein rechtzeitig durchdachtes Moduldesign hätte vermieden werden können – gibt es eine Möglichkeit aus diesem Dilemma herauszukommen?

Diese Möglichkeit gibt es tatsächlich: wandeln Sie Ihre Service-Programme wie folgt um:

    a) CRTSRVPGM C … Option(*unrslvref) b) CRTSRVPGM A … c) CRTSRVPGM B … d) CRTSRVPGM C , aber diesmal ohne Option(*unrslvref)

Option(*unrslvref) unterbindet die Auflösung der Importbestimmungen und ermöglicht so eine „provisorische„ Programmerstellung. Das Serviceprogramm ist in dieser Form allerdings nicht lauffähig (Zur Laufzeit würde ein Fehler MCH3203 – „Funktionsfehler in Maschineninstruktion..„ auftreten!). Deshalb müssen Sie zum Schluss das Service-Programm C erneut umwandeln, diesmal aber ohne diese Option.
Nach einem News-Beitrag von Babara Morris, IBM

Mehrfach-Datenstruktur als Parameter übergeben

Frage

Ich möchte eine Mehrfach-Datenstruktur von einem RPG IV Programm A an ein anderes RPG-Programm B übergeben, genauer gesagt den Pointer, der auf die Datenstruktur verweist. Der folgende Programmausschnitt aus Programm A zeigt das von mir gewählte Verfahren:

Bei (1) wird der Prototyp für Pgm B definiert, mit einem Pointer als Aufrufparameter. Bei (2) erfolgt die Definition der Mehrfachdatenstruktur mit Hilfe einer externen Dateibeschreibung (Datei1) und die Definition des zugehörigen Adresspointers (3). Bei (4) wird der Pointer mit dem Adresswert gefüllt und das Unterprogramm B aufgerufen Im Prinzip funktioniert dies auch. Ein Programmprototyp, mit dem ich das Verfahren getestet habe, hat fehlerfrei gearbeitet. Aber im Echtbetrieb scheinen am Anfang der Mehrfachdatenstruktur mehr oder weniger viele Zeilen zu fehlen. Wo könnte das Problem liegen?

Antwort

Ihr Verfahren ist im Prinzip in Ordnung. Die Probleme zur Laufzeit hängen mit der Art und Weise zusammen, wie RPG eine Mehrfachdatenstruktur bearbeitet. Nach meiner Annahme wird auch intern beim Bearbeiten der Mehrfach-DS per RPG-Anweisung OCCUR lediglich der Adresspointer auf den entsprechenden DS-Eintrag versetzt – und diesen versetzten Adresswert lesen Sie bei (4) aus und erhalten in PgmB nur einen Teil aller DS-Einträge. Gleichzeitig müsste sich in PgmB in den letzten Einträgeder Mehrfach-DS nur Müll finden. Die Lösung lautet also: Den Adresswert des ersten Eintrags der Mehrfach-DS zu ermitteln. Dafür gibt es zwei Möglichkeiten: a) Sie rufen vor (4) explizit den ersten Mehrfach-DS-Eintrag auf:

    1 occur MehrDS oder

b) Sie initialisieren den Adresspointer bereits in der D-Anweisung, bevor eine erste Operation auf der Mehrfach-DS ausgeführt werden kann:

    D PtrMehrDS S * inz( %Addr( MehrDS ) )

Die erste Möglichkeit ist selbstdokumentierend, die zweite möglicherweise eleganter ;-)
M.H., nach einen Tipp von Gary Guthrie, News/400 USA

Schlagworte: , , , , , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.