Tips und Techniken für die AS/400

Der 2. Teil der jährlichen Tips und Techniken jetzt online:

Blitz Links:
Der Entwurf von Prozedur-Schnittstellen
Zurückfordern von Ressourcen mit benannten Aktivierungsgruppen
Listen-Ansicht zur Fehlerbehebung
Ersetzen von veränderten Modulen
Probleme beim Binden: Sehen Sie im Jobprotokoll nach
Ausführen von Befehlen mit QCMDEXC

ILE

Der Entwurf von Prozedur-Schnittstellen

Integrated Language Environment (ILE)-Prozeduren können mehrere Parameter akzeptieren, sie geben jedoch immer nur einen Wert zurück. Bei den Parametern kann es sich jedoch um Eingabe-, Aktualisierungs- oder Ausgabeparameter handeln. Es stellt sich also die Frage, welches die beste Methode für den Entwurf von Prozedur-Schnittstellen ist. Sie erleichtern sich die Arbeit, wenn Sie die folgenden beiden Regeln beachten: Prozeduren, die einfache Datentypen handhaben, wie die eingebauten RPG IV-Funktionen, akzeptieren nur Eingabeparameter und geben ihr Ergebnis als Prozedur-Rückgabewert aus. Prozeduren, die komplexe Datentypen handhaben, definieren erst die Ein- und dann die Ausgabeparameter. Sämtliche Ausgabeparameter müssen bei jedem Prozedur-Aufruf gelöscht werden. Am Rückgabewert der Prozedur läßt sich ablesen, ob die Ausführung gelungen ist oder nicht. Sehen wir uns die beiden Regeln einmal in der Praxis an. Ein Serviceprogramm definiert Prozeduren zur Datumshandhabung. Bei einem Datum handelt es sich um einen einfachen Datentyp, d.h. jede Prozedur akzeptiert Eingabeparameter und gibt einen einzigen Wert zurück. Das folgende Beispiel beschreibt den Pseudocode für einige Prozeduren in dem Datums-Seviceprogramm:

Days        = DaysBetweenDates(FromDate: ToDate)
Day         = DayOfWeek(Date)
LeapYear    = IsLeapYear(Date)

Das Beispiel macht deutlich, daß ein Modell mit eingebauten Funktionen sich besonders gut für diesen Datentyp eignet. Das folgende Beispiel beschreibt ein Serviceprogramm für Benutzerbereiche. Bei Benutzerbereichen handelt es sich um einen komplexen Datentyp, d.h. jede Prozedur definiert erst die Ein- und dann die Ausgabeparameter, und zeigt anschließend mit einem Wert an, ob die Ausführung der Prozedur gelungen oder fehlgeschlagen ist. Das Beispiel zeigt den Pseudocode für einige Prozeduren in dem Benutzerbereich-Serviceprogramm:

Ok = CreateUserSpace( InName: InSize )
Ok = SetUserSpace( In Name: InData:
                   InPos: InLen )
Ok = GetUserSpace( InName: InPos:
      	           InLen: OutData )

Die Interface Struktur erlaubt Prozedur-Aufrufe in logischen Operationen, um die Verarbeitung zu steuern. Zum Beispiel:

If	GetUserSpace( InName: InPos:
                  InLen: OutData ) = *On
Eval Data = OutData
EndIf

Zurückfordern von Ressourcen mit benannten Aktivierungsgruppen

RclRsc (Ressource zurückfordern) ist ein bekannter AS/400-Befehl, mit dem Sie „Aufräumen“ können, nachdem eine Anwendung ihre Aufgabe beendet hat. In der ILE-Standardaktivierungsgruppe schließt der Befehl RclRsc alle Dateien und deaktiviert sämtliche noch aktivierten Programme. Falls die Anwendung in einer benannten oder neuen Aktivierungsgruppe (*New) läuft, muß die Aktivierungsgruppe mit dem Befehl RcIActGrp (Aktivierungsgruppe zurückfordern) gelöscht werden. Beim Löschen schließt RclActGrp alle noch offenen Dateien und deaktiviert sämtliche aktiven Programme in der Aktivierungsgruppe. Der Befehl RclActGrp muß außerhalb der Aktivierungsgruppe ausgegeben werden, die zurückgefordert werden soll. Außerdem darf kein aktives Programm in dem aktuellen Aufruf-Stapel in der Aktivierungsgruppe laufen, die zurückgefordert werden soll. RelActGrp akzeptiert die beiden folgenden Parameter:

• Der Parameter ActGrp spezifiziert den Namen der Aktivierungsgruppe, die zurückgefordert werden soll. Mit dem Spezialwert *Eligible können Sie alle zugelassenen Aktivierungsgruppen zurückfordern.
• Der Parameter Option akzeptiert die Werte *Normal oder *Abnormal. Wenn Sie den Wert als *Normal definieren, werden alle noch nicht übernommenen Transaktionen übernommen. Beim Schließen von gemischten, Kommunikations-, BSC- (Binary Synchornous Communications) und ICF-Dateien (Intersystem Communications Function) wird eine normale Schließmeldung an das verbundene Hostsystem gesendet. Wenn Sie den Wert als *Abnormal definieren, werden sämtliche noch nicht übernommenen Transaktionen zurückgenommen. Beim Schließen von gemischten, Kommunikations- , BSC- und ICF-Dateien wird eine Meldung über einen unnormalen Schießvorgang an das verbundene Hostsystem gesendet.

Listen-Ansicht zur Fehlerbehebung

Wenn Sie beim Debugging von ILE-Programmen die Meldung erhalten, daß die Modul-Quelle nicht verfügbar ist („Module source not available“), sollten Sie in der Testhilfesitzung F15=Select View (Ansicht wählen) auswählen. Wenn die Listen-Ansicht (Listing View) verfügbar ist (d.h., wenn Sie diese Ansicht bereits beim Erstellen der Programmodule spezifiziert haben), können Sie die Ansicht beim Debugging nutzen. Die Listen-Ansicht erstellt eine neue Textrepräsentation der tatsächlichen Kompilierungsliste in einem Modul. Die Repräsentation umfaßt auch den Text aus Teildatei-Kopien und Beschreibungen extern beschriebener Dateien.

Ersetzen von veränderten Modulen

Normalerweise werden die Objekte eines ILE-Moduls immer dann geändert, wenn Sie mit dem Befehl CRTPGM (Programm erstellen) oder CRTRVVPGM (Serviceprogramm erstellen) ein neues Programm oder Serviceprogramm erstellen. Solange die Parameter für ein Modul noch unverändert sind, ist es aber in der Regel einfacher und schneller, die betroffenen Module mit dem Befehl UPDPGM (Programm aktualisieren) oder UPDSRVPGM (Serviceprogramm aktualisieren) zu ersetzen. Damit werden nur die geänderten Module ausgetauscht, ohne daß ein neues Binden notwendig ist.

Probleme beim Binden: Sehen Sie im Jobprotokoll nach

Wenn Sie beim Binden von Modulen mit den Befehlen CRTPGM (Programm erstellen) oder CRTSVRPGM (Serviceprogramm erstellen) Probleme haben, sollten Sie sich statt der Ausgabe des Befehls das Jobprotokoll ansehen. Hier ist das aufgetretene Problem mit Sicherheit verzeichnet. Die CRTPGM- und CRTSRVPGM-Ausgabe bietet wesentlich weniger Hilfestellung, da die Ausgabe keine Diagnose-Informationen umfaßt. Das Verfahren unterscheidet sich von der regulären AS/400-Kompilierung, bei der die Ausgabe der Befehle CRTxxxMOD (xxx Modul erstellen) und CRTBNDxxx (Gebundenes xxx Programm erstellen) die Diagnose-Informationen bietet und nicht das Jobprotokoll.

Ausführen von Befehlen mit QCMDEXC

Das API QCMDEXC führt einen Befehl aus. RPG IV ermöglicht das Erstellen von Prototypen für externe Programme, so daß Sie die Programme wie Prozeduren aufrufen können (siehe Abbildung 5A).

Das Verfahren funktioniert, hat aber einen Nachteil – die CallP-Operation enthält kein Feedback darüber, ob der Befehl gelungen ist oder nicht. Sie wissen also nicht, ob die Datei gelöscht wurde. Sie sollten QCMDEXC in ein Serviceprogramm einbetten. Teildatei-Kopie CmdH (Abbildung 5B) dient als Header-Teildatei für das Serviceprogramm Cmd (Abbildung 5C).

Beide Teildateien verwenden die Teildatei-Kopie StdTypH, die bereits unter „Vereinfachte Datendefinition“ (Abbildung 1) besprochen wurde. Das Serviceprogramm Cmd enthält die Prozedur ExecCmd, um einen Befehl auszuführen. Anhand des Fehlerergebnis-Indikators in der Call-Operation überprüft die Prozedur, ob der Befehl ausgeführt wurde oder nicht. Wenn der Befehl erfolgreich war, gibt die ExecCmd-Prozedur *On zurück. Wenn der Befehl nicht ausgeführt werden konnte, gibt die Prozedur *Off zurück. Verwenden Sie den in Abbildung 5D aufgeführten Code, wenn Sie mit dieser Prozedur eine Datei löschen möchten.

---

Ein dritter Teil folgt.
Mit freundlichen Grüßen

Ihr Burgy Zapp