neue BIFS nutzen %UPPER

[Andreas_Prouza]

Alle grossen DBs sind aufgeführt, DB2 - keine Spur.

Das sehe ich mittlerweile entspannt, da ich nicht möchte, dass Frontend-Applikationen auf die DB zugreifen.
Zugriffe werden ausschließlich über WebAPIs zur Verfügung gestellt.
Egal ob der/die EntwicklerIn in PHP, Python, .Net, React usw. arbeitet, sie bekommen von mir immer nur die WebAPIs.
Nicht alle sind happy damit, weil sie es nicht gewöhnt sind, hat aber viele Vorteile:
* Kann separat getestet werden
* DB Verbindung muss nur 1 x entwickelt werden
* Einfach zu monitoren
* DB Änderungen sind einfacher
* Security: Bessere Kontrolle, wer, was genau machen darf
* Dezimierung der "Schatten-IT"
* Neue Anforderungen bei DB Zugriffe sind einfacher umzusetzen, weil man nicht auf die Suche einer jeden Applikation gehen muss

[Fuerchau]

EU-Office scheint aber wieder komplett cloudbasiert zu sein.
Sowas kann und will ich mir nicht antun.
Schuld ist auch i.W. meine legacy DSL-Leitung (70down, 25up), da es keine vernünftige Alternative bei mir gibt. Jedwede Cloudlösung für privat scheitert da einfach an der Verfügbarkeit. Wenn der Nachbar streamt, geht bei mir der Download auf 45 runter. Auch die ständigen, meist kurzzeitigen, Unterbrechungen nerven einfach.

Ich glaube, meinen letzten Bluescreen hatte ich mit Windows 98.
Ich habe seit Windows XP mein System immer upgegradet, also Windows nie neu installiert.
Selbt den letzten Hardwarewechsel habe ich, dank Acronis, mit Backup vom System A und Boot von USB auf System B mit Restore durchgeführt.
Das klappte ganz hervorragend.

Selbst der Upgrade von Win10 auf Win11 klappte gut. Ich musste nur die Sperre der angeblich falschen Hardware (meine CPU war nach Stichtag 4 Wochen zu alt) umgehen und schon lief die Installation.
Auch die anschließenden Wechsel der H1/H2-Versionen funktionierten ohne Probleme. Aktuell bin ich nun bei 25H2.
Jetzt ist das halt ein Einzelrechner, aber Firmen nutzen auch entsprechende Update- und Verteilstrategien.

Ach ja:
Ich nutze i.Ü. nicht den Standard Windows-Update sondern das kleine Tool WUMT.
Mit diesem vermeide ich unnütze Updates, da man diese ausklammern kann.
Ich bin einmal mit einem Intel-Update reingefallen, da die Treiber meine Legacy-Hardware (ca. 6 Jahre) gar nicht unterstützt haben und eine Deinstallation auch nicht funktionierte. Gut, dass ich per Restore die Vorversion wieder herstellen konnte:-). Nun werden auch alle Intel-Updates ignoriert, da ich ja keine neue Hardware habe. Ggf. ist das auch die Ursache, dass ich keine Netzwerkprobleme habe;-).

Somit wird per WUMT auschließlich Security- und Windows-Updates gezielt nach einem Backup installiert.
Das ach so tolle "Windows Tool zum Entfernen bösartiger Software" von Microsoft lösche ich da immer sofort, da es halt ihm unbekanntes schon mal einfach entfernt hat.
Immerhin habe ich noch immer das Legacy CorelDrawX4 im Einsatz, was für meine Zwecke immer noch vollkommen ausreicht.

[Pikachu]

Sind SETLL / SETGT / READ / READE / READPE / WRITE / UPDATE / DELETE in RPG eigentlich auch Legacy und sollen/müssen schnellstens durch SQL in RPG ersetzt werden? Gibt’s die in Fully Free RPG überhaupt noch und falls ja warum?

[B.Hauser]

Sind SETLL / SETGT / READ / READE / READPE / WRITE / UPDATE / DELETE in RPG eigentlich auch Legacy und sollen/müssen schnellstens durch SQL in RPG ersetzt werden? Gibt’s die in Fully Free RPG überhaupt noch und falls ja warum?

Native I/O gibt es noch! Allerdings sollte man Native I/O nicht 1:1 in embedded SQL ersetzen!
Warum?
1. Jedes SQL-Statement muss mindestens ein Mal durch die volle Optimierung (FULL OPEN) was sehr zeitaufwändig ist. Sofern der ODP offen bleibt, sind die Folge Aufrufe wesentlich schneller (10-20 Mal).
2. Vergleicht man native I/O mit dem SQL-Pendant, so wird native I/O zumindest beim ersten Durchlauf gewinnen (keine Optimierung versus volle Optimierung). Ein einzelner Chain ist wahrscheinlich nach wie vor schneller als der entsprechende SELECT ... INTO. SQL ist sicher schneller, wenn geblockte Verarbeitungen erfolgen können.
3. SELECT * sollten vermieden werden und gezielt nur die Spalten, die benötigt werden ausgewählt werden. Dadurch kann zum einen das übertragene Datenvolumen reduziert werden und zum anderen kann der Optimizer u.U. einen IOA (Index only access ... alle Informationen befinden sich in Schlüssel-Werten, so dass ein Zugriff auf den eingentlichen Datensatz nicht (mehr) notwendig ist.
4. Anstatt die Zugriffe einzeln zu machen, ist es geschickter, die benötigten Tabellen entsprechend zu verjoinen. Dadurch reduziert man zum einen die Anzahl der FULL OPENS und zum anderen kann der Optimizer seine volle Power ausspielen.
5. Statisches SQL sollte dynamischem SQL vorgezogen werden, da bei jedem OPEN (nach dem PREPARE) wieder ein FULL OPEN erfolgt (es sei den man würde mit Parameter-Markern arbeiten, die dynamischen SQL Statements sichern und nur neu "PREPAREN" wenn sich das Statement geändert hat.
6. Bei der COMPILE-Option CLOSQLCSR sollte man den default *ENDACTGRP nicht ändern. Bei *ENDMOD werden am Ende des Moduls alle ODPs geschlossen, und bei Folge-Aufrufen muss wieder ein FULL OPEN erfolgen. Ebensowenig sollte man mit Aktivierungsgruppe *NEW arbeiten, da alles was zu dem Programm gehört (also auch die ODPs) am Ende des Programms gelöscht werden.

[Andreas_Prouza]

Ist es später nötig Performance-Optimierung durchzuführen, ist dies mit SQL wesentlich schneller und einfacher. Es gibt viele Werkzeuge dafür und man kann die Zugriffe von der Programmlogik getrennt betrachten.

Ich habe schon ewig kein dynamisches SQL verwendet. Bei dynamischen SQL, gibt es im Programm auch keinen Eintrag zur Tabelle (DSPPGMREF). Es ist auch möglich mit statischem SQL dynamische Filter einzubauen.

Z.B.: Habe ich 2 Filter-Variablen die ich jeweils ins SQL einbinden will, abhängig davon wenn der User eine Eingabe getätigt hat:

Select * from Tabelle1
where (:l_filter1 = '' or spalte1 = :l_filter1)
and (:l_filter2 = 0 or spalte2 = :l_filter2)

[Fuerchau]

Tut mir Leid, aber da stimmt auch nicht alles.
Grundsätzlich ist zu sagen, dass auch SQL nur mit Wasser kocht, auf der Filebasis letztlich mit den Open/Close/Read/Write/Delete/Update des Native IO umgehen muss. Dies beweist z.B. ein Jobtrace.

zu 1)
Der sog. ODP ist nichts weiter, als dass die benötigten Dateien (PF, LF) nicht geschlossen werden.
Dies erreicht man bei RPGLE schon dadurch, wenn ein Programm ohne Main mit INLR=*OFF verlassen wird. Der Autoopen der Runtime wird dann nicht wiederholt, was dann häufig durch einen RCLRSC zu einem Fehler führt. Durch SHARE(*YES) konnte man die ODP's im Callstack durchrouten, so dass da auch ein Open nicht erforderlich ist.
Der Hauptaufwand besteht eben bei der Analyse beim Ermitteln von Zugriffswegen (Indizes), die beim 1. Open halt dauern.
Zu 2)
Ein Setll/Reade bedeutet zumindest 2 Zugriffe, ein "Select * into ... from mytable where limit 1" ist da durchaus ebenbürtig. Die geblockte Verarbeitung ist ein Automatismus, der in RPG bei Open Input ebenso durchgeführt wird. D.h. i.W. dass beim Lesen ein Block intern bereitgestellt wird, der dann durch Pointerverarbeitung ausgelesen wird.
Der Where wird ggf. über Index optimiert und liest dann geblockt über eine Schleife, was dem Schleifencode des RPG aber auch wieder ebenbürtig ist. SQL schreibt sich da halt nur leichter.
Zu 3)
Ein Select * oder eine Feldliste macht in der Performance nur etwas aus, wenn tatsächlich der erwähnte IndexOnly-Zugriff zur Anwendung kommt, den es native nicht gibt. Schließlich wird ja aus der Tabelle bzw. allen Tabellen eines SQL's sowieso der gesamte Puffer gelesen und dann feldweise übergeben. Hier zu optimieren bringt eher nur Nano-, vieleicht Microsekunden. Schaut man sich die Aufrufe an, kommt per SQL ein Puffer zurück, der dann in einzelne Moves aus den SQL-Variablen in die Hostvariablen aufgelöst wird.
Wird native IO gemacht, tut dies die RPG-Runtime ebenso, zuerst lesen des Blockes, setzen des Zeigers auf die Zeile des Blockes, Einzelmoves in die I-Variablen bzw. die DS. Hier besteht also kein Unterschied.
zu 4)
Das kommt immer darauf an, wie die Daten zu verarbeiten sind. Bei einem 1:1 Join gibts kaum Unterschiede, bei einem 1:N-Join ist es vor allem einfacher, den SQL mit Where zu kodieren als wieder Schleifenkonstrukte zu verwenden. Bei Native-IO überlegt man sich ja auch, dass man via LF's, also einen Index, zugreift um performant zu arbeiten. Auch da kann man durchaus alle zu prüfenden Felder in den Index stecken. Über Bedingungen kann man ggf. zu einem vorzeitigen Ende einer Schleife kommen, was man inzwischen mit Join Lateral genauso machen kann, da der Full-Join eben alles lesen muss, der join lateral nur das benötigte.
Zu 5)
Der Hauptaufwand beim dynamischen SQL ist der Syntaxcheck, der bei jedem Prepare erneut durchgeführt wird. Bei einem Trace kann man auch feststellen, dass z.B. Konstanten in interne Hostvariablen überführt werden und in der Folge ggf. zu schlechterer Optimierung wegen Typungleichheit führen.
Der nachfolgende Fullopen unterscheidet sich dann nicht mehr.
Zu 6)
Wie der Name schon sagt, der CLOSQLCSR betrifft den Cursor und nicht den ODP. Er betrift also vergessene Close beim Verlassen eines Programmes oder Modules.
Häufig genug findet man dann in den Quellen vor dem SQL-Open Cursor einen Close Cursor, da ja der Open auf jeden Fall erforderlich ist. Wer also regelmäßig am Ende einer Schleife einen Close hat, kann den Wert vergessen. In Services lasse ich den Cursor meist offen, da ich Open/Read/Close-Services anbiete.
Im Modul sollte ich ebenso meine Close machen, ggf. kann ich es einfacher machen, weil ich ENDMOD mache. Der ODP bleibt ja trotzdem offen. Auch ein Delete/Update, der ja nur interne Cursor hat, lässt de ODP offen, schließt aber seinen Cursor.

ACTGRP(*NEW) empfehle ich meist der sog. Hauptebene der Aufrufe aus einem Menü heraus, da eben viele Programme, Services, Module vergessen, hinter sich mal aufzuräumen.
Schaut man sich die Jobs zur Laufzeit an, findet man manchmal 100te oder 1000de offene Dateien!
Hinzu kommt, dass die Module in der ACTGRP mit ihren Variablen noch im Speicher liegen und durchaus eben Speicher verbrauchen. Auch Speicher, der von den verschiedensten Services intern belegt wurde, kann bei Verlassen der *NEW-ACTGRP aufgeräumt werden.
Daneben gibt es aber auch spezielle Services, die dann in einer eigenen benannten ACTGRP laufen, wenn sie denn eine getrennte Transaktion zum Aufrufer benötigen.

Fazit:
Wer früher schon mit Native-IO effektiv programmiert hat, wird mit SQL keine Performancesteigerungen feststellen können. Man meint aber schnell, da SQL ja so grandios optimiert, auf Indizes dann verzichten zu können. Dann wundert man sich, warum am Wochenanfang die IBM i so langsam ist und zum Wochenende immer schneller wird, da SQL-Caches mit optimierten Zugriffen sich langsam aufbauen und nach dem IPL am WE wieder leer sind.
Auch Main-Programme mit globalen Datei-Definitionen (F-Bestimmungen) halten ihre Dateien dann automatisch beim Return offen. Das kommt immer dann blöd, wenn man mit vorherigen Aufrufen mal die LIB geändert oder einen OVRDBF gemacht hat, das Programm dann aber mit der falschen Datei arbeitet.

[Fuerchau]

@Andreas Prouza
Wie ich schon mal in einem anderen Thread geposted habe, kann auch ein Nullanzeiger helfen, wenn der Feldinhalt Blank/Null ein Suchwert wäre.

where (:Var :Ind is null or :Var = Value)