Mit großen Schritten geht es in Richtung 7.3, des neuen Release des Betriebssystems IBM i für unsere System-i-Maschinen. Bereits jetzt sind signifikante Neuerungen im Vormarsch und wecken Lust auf den Einsatz des neuen Release – und diese machen auch vor RPG nicht halt. Einige dieser Neuerungen sind bereits in TR-Updates zu finden, die für 7.2 zur Verfügung stehen und einen Ausblick auf die neueste Generation der RPG-Funktionen bieten.

RPG – die „altmodische“ Programmiersprache, wie sie von „Kennern“ immer wieder gerne kommentiert wird, setzt ihre Verjüngungskur auch mit der Version 7.3 weiter fort. Zugegeben, einige Neuerungen sind dringend und bilden eine konsequente Notwendigkeit – denn ein eingeschränktes freies Format (bezogen auf die nutzbaren Spalten) ist eben nicht frei. Das ändert sich mit der Version 7.3. Denn jetzt steht dem RPG-Entwickler ein größerer Codierbereich zum Schreiben der Programmcodes zur Verfügung.

Mit der Anweisung **FREE in der ersten Programmzeile wird dem Editor und dem Compiler mitgeteilt, dass der Code bereits in der ersten Spalte beginnen kann. Die Beschränkung auf nur 80 Spalten fällt damit ebenfalls weg. Somit steht für das Codieren nun endlich die volle Bandbreite bzw. Spaltenanzahl zur Verfügung.

Aber Achtung: Ein guter Programmcode zeichnet sich auch und insbesondere durch eine gute Lesbarkeit aus. Deshalb liegt es an den Anwendungsentwicklern, diese neue Codieroption im RPG auch sinnvoll einzusetzen.

Mit der neuen **FREE-Anweisung fällt allerdings auch die Mischnutzung von Fix- und Free-Format-RPG weg. In einem **FREE-Programmcode werden ausschließlich Free-Format-Anweisungen unterstützt. Mit Hilfe von /COPY- und /INCLUDE-Anweisungen lassen sich aber auch „ältere“ Free-Format-Elemente einbinden, deren Codierformate die nun hinfällige Beschränkung auf die Spalten 6 bis 80 aufweisen. Die bisherigen Sonderspalten 6 und 7 sind in dieser Free-Format-Version hinfällig.

Neue Built-in Function%SCANR

Die Erweiterungen der Built-in Functions in RPG sind auch in den letzten Release-Versionen immer wieder als sinnvolle Ergänzung und Erleichterung für die RPG-Entwicklung bereitgestellt worden. Die bisherige%SCAN BIF wird mit 7.3 um die BIF%SCANR erweitert. Wenn Sie bereits mit%SCAN gearbeitet haben, dann wird Ihnen die Funktionsweise von%SCANR sicher sehr nützlich erscheinen.%SCANR arbeitet ähnlich wie%SCAN, nur quasi „anders herum“. Während bei der Verwendung von%SCAN das erste übereinstimmende Ergebnis verarbeitet wurde, wird mit%SCANR das letzte Ergebnis zurückgeliefert. Das spart Verarbeitungszeit und erleichtert das Codieren.

Nachfolgendes Codebeispiel zeigt exemplarisch die Verwendung von%SCANR.

Hier wird das letzte Vorkommen des /-Zeichens gesucht, um den Dateinamen zu ermitteln. Der Codeblock für diese Anforderung lässt sich mit Hilfe von%SCANR im Vergleich zu anderen RPG-Lösungen deutlich reduzieren.

Der Aufbau der%SCANR BIF ist wie folgt zu verwenden:

%SCANR(Suchargument : Suchzeichenfolge {: Startposition {: Länge}})

Wenn Sie die BIF%SCAN bereits einsetzen und kennen, dann wird Ihnen sicher auffallen, dass bei der BIF%SCANR die Startposition und die Länge mit angegeben werden können. Dabei handelt es sich um optionale Parameter. Werden diese nicht angegeben, dann nutzt%SCANR die gesamte zu durchsuchende Zeichenfolge.

Diese optionalen Argumente sind auch in einer weiteren Neuerung in RPG 7.3 zu finden: der Erweiterung in der Built-in Function%SCAN, mit der nun auch die Länge mit angegeben werden kann.

Erweiterung der Built-in Function%SCAN

Neben der neuen BIF%SCANR wurde auch die bereits bestehende BIF%SCAN angepasst. Hier besteht nun die optionale Nutzung der eingeschränkten Suche. Dazu hat IBM die BIF um den Parameter Start / Ende erweitert. Auf diese Weise kann nun gezielter in einer Zeichenfolge nach den betreffenden Vorkommen gesucht werden.

Ein Beispiel dafür zeigt der nachfolgende Codeabschnitt.

Der Aufbau der neuen%SCAN BIF ist wie folgt zu verwenden:

%SCAN(Suchargument :Suchzeichenfolge {: Start der Suche {:Länge}})

Die Angabe von Start und der Länge ist optional. Werden diese Argumente nicht angegeben, dann verwendet die BIF%SCAN die gesamte Länge der zu durchsuchenden Zeichenfolge, beginnend mit der ersten Position.

Flexible Dateiverwendung

Die Nutzung von Dateien innerhalb eines RPG-Programms bedarf einer Angabe, wie die Daten der Datei zu verwenden sind. Bisher musste in Datenstrukturen angegeben werden, ob diese als Schlüssel, zur Eingabe oder zur Ausgabe zum Einsatz kommen soll. Mit der Neuerung *ALL können nun die Eingabe-/Ausgabeanweisungen in RPG flexibel genutzt werden.

Ein Beispiel dafür zeigt das nachfolgende Codebeispiel.

Die Datenstruktur DS01 wird mit der Angabe *ALL für Ein- und Ausgabe definiert.

Man kann geteilter Meinung sein, ob das in der Praxis hilfreich ist, denn der qualifizierte Einsatz der differenziert definierten Datenstrukturen (jeweils für*INPUT und *OUTPUT) verhindert zum Beispiel ungewolltes Fortschreiben.

Behandlung von Nullfeldern

Die Nutzung von Nullfeldern ist mit unterschiedlichen Neuerungen im Release 7.3 erweitert worden. Diese finden sich in

der Erweiterung für die Angabe EXTNAME und LIKEREC sowie

dem Schlüsselwort NULLIND.

Sowohl bei der Verwendung von EXTNAME als auch bei der Verwendung von LIKEREC wird mit dem Zusatz *NULL festgelegt, dass die Datenstruktur mit Subfeldern erstellt wird, die einen Datentyp-Indikator haben.

Mit dem neuen Schlüsselwort NULLIND, das für Felder und Subfelder angegeben werden kann, kann die spezifische Nullbehandlung auf diesen RPG-Ebenen gesteuert werden, indem Indikatoren zugeordnet werden können, die Null-Capable-Felder einfacher identifizieren, als es zum Beispiel mit der Built-in Function%NULLIND alleine der Fall war. Natürlich können Sie auch weiterhin%NULLIND nutzen, doch der Einsatz des Schlüsselwortes NULLIND in Verbindung mit dem Indikator ist deutlich einfacher in der Handhabung.

Das nachfolgende Codebeispiel zeigt die Nutzung von NULLIND.

In diesem Beispiel wird der Indikator NULLIND in Verbindung mit dem Array KdUmsatz eingesetzt.

NULLIND kann auch für die Unterfelder einer Datenstruktur genutzt werden. Das Schlüsselwort NULLIND kann dann auf der Ebene der Unterfelder codiert werden.

In diesem Codebeispiel werden die Unterfelder FLD1 und FLD2 der Datenstruktur KundDS mit dem Schlüsselwort NULLIND versehen. Dabei wurde den beiden Feldern jeweils ein Indikator zugeordnet, der im weiteren Programmverlauf dann abgefragt werden kann. Diese Abfrage finden Sie exemplarisch in der Bedingung „if KundDs.Fld1_null“.

Aliasverwendung für extern beschriebene Dateien

Die Nutzung von Alias in RPG ist nicht neu, wird aber in Verbindung mit extern beschriebenen Dateien bisher nicht unterstützt. Mit 7.3 kann nun auch für die aus RPG-Sicht extern beschriebenen Dateien Alias verwendet werden. Damit lassen sich zum Beispiel Feldnamen in RPG eindeutig anwenden. Dies bildet eine Alternative für Prefix-Angaben.

Wenn Sie für eine extern beschriebene Datei das Schlüsselwort ALIAS angeben, dann werden innerhalb des RPG die Feldnamen angepasst und genutzt.

Schauen Sie sich ein einfaches Beispiel an. Dazu wurde eine Datei KUNDENDEMO angelegt. In der Datei befindet sich unter anderem das Feld KDNAME, dem auf der Dateiebene ein Alias (KUNDENNAME) zugeordnet wurde.

Im RPG-Programm wird die Datei jetzt mit der Angabe ALIAS deklariert.

Der Compiler verwendet nun, basierend auf den Aliasangaben, innerhalb des Programms die definierten Aliasnamen der Felder – im Beispiel also für den Kundennamen den Alias KUNDENNAME.

Die Angabe von Alias kann auch mit extern beschriebenen Dateien qualifiziert erfolgen. Dabei wird wie gewohnt die Erweiterung „qualified“ angegeben. In diesem Fall sind die Aliasnamen im qualifizierten Format zu verwenden.