Welche Kommunikation?

[Fuerchau]

Ich bleibe immer noch bei "Stored Procedures".
Diese können neben einzelnen Parameter-Werten auch Recordsets (geöffnete Cursor) zurückgeben. Um nun die Kommunikation zu vermindern, gibt es auch die Variante, eine programmbeschriebene Struktur als "Datensatz" oder auch mehrere Datensätze (wenn die Struktur ein Mehrfachvorkommen ist "occurs") zurückzugeben.

"Create Procedure" verlangt keine zusätzlichen Lizenzen, wenn auf externe Programme verwiesen wird. Erstelle ich SQL-Prozeduren (SQL-Script) benötige ich vor V5 einen C-Compiler. Da du aber COBOL verwenden willst, definierst du halt nur "externe" Prozeduren.

Was den wesentlichen Unterschied zu SQL ausmacht ist bereits das Berechnen von Daten / Teilergebnissen, Verknüpfungen (Joins), Gruppieren, Sortieren.
Vieles was man vorher programmieren mußte, kann durch SQL bereits erledigt werden.

Und wenn das nicht reicht, können auch UDF's (User defined Functions) geschrieben werden (als externe Programme), die wiederum Teilergenmisse berechnen können, die SQL selber nicht beherrscht.

Zusätzlich kann man auch noch Trigger einsetzen, die auch noch das erledigen, was sonst das Dialogprogramm macht (Daten ergänzen, in weiteren Tabellen fortschreiben, löschen, updaten usw).

Was die Performance angeht, so sollte man halt nie mit "select * from " arbeiten, da dann auch nicht benötigte Informationen übertragen werden.
Jedes Programm sollte also auch nur die Informationen lesen, die es tatsächlich benötigt.

Die Socket-Programmierung ist tatsächlich sehr aufwändig, da du noch zusätzlich die verschiedenen Codes (EBCDIC/ASCII/ANSI) berücksichtigen musst (mit ODBC erledigt).
Ausserdem mußt du für jedes Datenformat / Struktur eine Kommunikation haben. Änderungen sind immer auf 2 Seiten zu Programmieren, bei SQL reicht fast immer 1 Seite.

APPC gibts nur bei SNA und wird auf PC's kaum noch unterstützt.
DDM basiert wiederum auf APPC (gibts inzwischen auch für IP) und funktioniert nur zwischen AS/400'ern.
Ausserdem ist DDM gänzlich ungeeignet (nur Dateizugriffe).
Früher gab es noch die ICF-Files, ob die noch funktionieren ???

Trotzdem:
SQL ist da allemal besser, komfortabler, schneller (wenn man mit DB's zu tun hat) !

[Neptun]

@Fuerchau
Ich versuche mich so langsam aber sicher mit diesen 'Stored Procedures' anzufreunden. Wie du schon richtig bemerkt hast würde ich hier wohl zunächst mal die Variante mit den externen Programmen ins Auge fassen.
Wenn ich das alles richtig verstanden habe wäre folgendes Szenario möglich:
- Erstellen der Stored Procedure auf der AS/400 mittels ODBC-Treiber vom PC aus; kann ich einfach per SQLExecDirect den 'Create Procedure' Befehl ausführen ?
- diese Prozedur kann ich dann über den ODBC-Treiber aufrufen (werde ich mich noch in der ODBC-Hilfe schlau machen), inkl. Übergabe von Parametern (müssen wohl vorher gebunden werden mit SQLBindParameter)
- in dieser Prozedur habe ich nun den Aufruf eines COBOL-Programms definiert (oder geht das SO nicht?)
- in diesem COBOL-Programm führe ich nun meine Datenzugriffe durch und evt. diverse weitere Verarbeitungen
- jetzt wird das COBOL-Programm beendet und es werden Ergebnisse zurück an den PC gemeldet (stellt die Rückgabe der Parameter ein besonderes Problem dar?)

Oder ist da irgendwo etwas falsch/nicht möglich/schlecht im beschriebenen Ablauf?

Wo liegt denn das Besondere in diesen 'UDF's? Wären das nicht einfach Unterprogramme vom aufgerufenen COBOL-Programm?


Beste Grüße
Neptun

[Fuerchau]

Jetzt verstehe ich langsam deine Probleme. Du kannst die ODBC-Aufrufe nicht als "embedded SQL" definieren ?
Dann ist natürlich der Aufwand, SQL im Programm zu verwenden genauso gigantisch wie mit Sockets zu experimentieren.
Von SQLCreateHandle bis Fetch, BindColumn, BindParam usw. muss alles manuell durchgeführt werden.
Ich rate dir massiv davon ab !!!
Versuche lieber, deinen COBOL-Compiler auf dem PC zu "embedded SQL" zu bewegen !!!
Notfalls musst du auf WebSphere zurückgreifen.

Ich dachte bisher, du kannst SQL direkt verwenden, aber so ....

Der Austausch von Parametern in jede Richtung stellt kein Problem dar.
Die Prozeduren kannst du auch auf der AS/400 mittels RUNSQLSTM bzw. REXX definieren, da das auf jedem System ein einmaliger Vorgang ist.
Klar kann das Client-Pgm dies immer wieder durchführen, Fehler (Prozedur schon da) sollten aber ignoriert werden.

Zu Verwendung der SQLxxx-Routinen schau mal ins Handbuch SQLCLI-Interface, aber wie gesagt, tus lieber nicht.

[Neptun]

@Fuerchau
Also, der Reihe nach:
Selbstverständlich kann ich 'Embedded SQL' in meinem Cobol-Compiler unter Windows nutzen, der Hersteller bietet da einen PreCompiler an.
Ich habe eine andere Anwendung die bereits vor über 5 Jahren komplett portiert wurde von herkömmlichen Cobol Datei-Zugriffen mit READ/WRITE/REWRITE/DELETE auf die Nutzung von ODBC mit Aufrufen per CALL und Nutzung der ODBC-API's, also komplett mit SQLAllocStmt (mittlerweile SQLAllocHandle), SQLBindParameter, SQLBindCol, SQLPrepare, SQLExec, SQLExecDirect, SQLFetch (mittlerweile teilweise SQLFetchScroll), etc. etc.
Läuft stabil und problemlos mit diversen Datenbanken.
Von daher ist hier Know-How vorhanden, im Gegensatz zu 'Sockets'.
Wie ich vorher schonmal erwähnt hatte habe ich die Anwendung die nun umzustellen ist mal probehalber teilweise umgestellt (habe einfach die Cobol-Befehle 1 zu 1 umgestellt auf SQL via ODBC), dieser Ansatz ist zwar RELATIV schnell gemacht, aber natürlich auch verdammt langsam ...

So, nun aber zu den Stored Procedures.
Habe heute mal einen Test gemacht. Per ODBC-Treiber 'Create Procedure' ausgeführt. Die Prozedur war vom Typ 'External', es wurde ein Cobol-Programm auf der AS/400 aufgerufen.
Ich habe 2 Parameter gebunden mit SQLBindParameter, 1 Eingabe- und 1 Ausgabeparameter. In der Eingabe war eine Satznummer die das Cobol-Programm auf der AS/400 lesen sollte, die Ausgabe enthielt den Datensatz. Das funktionierte auch einwandfrei.
Dann habe ich versucht mittels 'Create Procedure' eine SQL-Prozedur zu erstellen. Das schlug fehl und im Joblog fand ich dann auch den Grund: Es wird der ILE C-Compiler benötigt. Hattest du ja schon erwähnt das man diesen bei Release 4.x benötigt.

Ich finde diesen Aufruf mit den Stored Procedures vom Type External eigentlich ganz interessant.
Ich denke das eigentlich nur noch 2 Ansätze für mich interessant sind:
- Embedded SQL
- Stored Procedures 'External'

Das Embedded SQL funktionieren wird, da mache ich mir keine Sorgen.
Für den Weg über die External Prozeduren habe ich eine Idee:
Ich denke mal das Programm, ich nenne es mal PGM1, welches man von dieser Prozedure aus aufruft wird grundsätzlich beendet (sprich STOP RUN) und dieses kann man vermutlich auch nicht verhindern, oder?
Jetzt könnte PGM1 doch ein weiteres Cobol-Programm, ich nenne es mal PGM2, aufrufen welches permanent aktiv ist und (zunächst mal) nicht beendet wird. PGM2 wartet nun auf Daten von PGM1. Sobald Daten anliegen verarbeitet PGM2 diese und gibt Daten zurück an PGM1. PGM1 setzt nun seine Verarbeitung fort, beendet sich und gibt die Daten zurück an die PC-Anwendung.
Wie könnte man das auf der AS/400 realisieren.
Unterstützt OPM Cobol Entry Points? Gibt es irgendwelche Queue's die man hierfür nutzen könnte?
Oder gibt es sonst eine "valide Denkoption" ?
Bin auf der AS/400 leider zuwenig bewandert

Beste Grüße
Neptun

[malzusrex]

Wenn ich dich bei, überfliegen des Textes richtig verstanden habe, suchst du eine Möglichkeit deine 5250 auf Windows zu portieren. Dann nimm doch SEAGULL oder ML/4.
Dort läuft im Hintergrund der "normale" 5250-Datenstrom. Dieser wird dann in einer Windows-Oberfläche umgesetzt.
Auch wenn jetzt wieder einige sagen werden, bevor man sowas macht, sollte man die Anwendung neu proggen..

Salue Ronald

[Fuerchau]

Das mit dem Beenden ist nicht unbedingt so, wenn du eine benannte ACTGRP verwendest und mit GOBACK / EXIT PROGRAM an Stelle von STOP RUN abschließt (ILE COBOL only!).
Dadurch entfällt auch das Initialisieren bei jedem Aufruf usw. usw.

OPM-Cobol hat keine Entry-Points (like DLL?), bei ILE gibt es da noch die Service-PGM'e, die quasi wie DLL's funktionieren, aber nicht direkt als SQL-Procedure aufrufbar sind.

Das mit der 2. Kommunikatins-Schiene (zus. Batch-Programm) würde ich nicht machen, da damit Commit-Regeln verletzt werden können. Wie siehts da mit Satzsperren, konkurierenden Updates usw. aus !

Bei den Ausgabeparametern sollte man insofern aufpassen, dass keine Strukturen funktionieren (es sei denn alles Character/Zoned).
Besser ist es da mit Pseudo-Cursor'n zu arbeiten, da die Strukturen als offenes Recordset zurückgegeben werden können (Typumwandlung, CCSID's werden korrekt berücksichtigt).

Noch eins:
Stored Procedures are not growable !
Jedenfalls dann nicht, wenn sie bereits im Einsatz sind.
Wenn also die Schnittstelle nicht korrekt festgelegt ist (Ein-/Ausgabe-Parameter) kann sie nicht mehr erweitert werden.
Wobei es da durchaus zu "Überladungen" kommen kann. Definiert man eine andere Prozedur mit dem gleichen Namen aber anderen Parametern, so gilt diese als eigenständige Prozedur !!!

Auch die Anzahl der Parameter ist beschränkt (ich glaube 256).
Es wäre also zu überlegen, für die Ausgaben Cursor zu verwenden (auch wenn nur 1 Satz zurückgegeben wird). Die Statusbehandlung ist einfacher (EOF = nix da), es können mehrere Sätze zurückgegeben werden.

@Ronald
Ich glaube, dass das Thema hier ein anderes ist

[Neptun]

@Fuerchau

Zunächt mal zur "2. Kommunikationsschiene" wie du es nennst.
Habe heute mal folgenden Test gemacht:
- vom PC Cobol Programm PCPGM1 per ODBC eine Stored Procedure vom Typ External erstellt
- diese startet ein OPM Cobol Programm A4PGM1 auf der AS/400
- A4PGM1 schreibt etwas in eine DTAQ (*keyed)
- nun gibt es noch das OPM Cobol Programm A4PGM2 auf der AS/400
- A4PGM1 ruft zu Beginn per QCMDEXC mit SBMJOB das Programm A4PGM2 auf (wenn das System stabil läuft ist dieser Aufruf z.B. nur einmal täglich nötig)
- PCPGM1 ruft nun immer wieder die External Prozedur auf
- A4PGM1 schreibt nun Anweisungen für A4PGM2 in die DTAQ, z.B. 'OPEN', 'READ', 'START', 'CLOSE', etc.
- A4PGM2 wartet nach dem ersten Start auf dem API-Aufruf 'QRCVDTAQ'
- sobald etwas in der DTAQ (mit dem gewünschten KEY) drin ist verarbeitet A4PGM2 die Anweisung und schreibt eventuell mit 'QSNDDTAQ' etwas in die DTAQ
- je nach Verarbeitung hat A4PGM1 ebenfalls mit 'QRCVDTAQ' auf einen bestimmten KEY gewartet und gibt nun z.B. den Inhalt der DTAQ zurück an den PC

Habe auf diese Art einfach mal einen START mit anschließendem READ NEXT von 1000 Sätzen durchgeführt. Das hat unglaublich langsame 19 Sekunden gedauert. Ist ein völlig indiskutabler Datendurchsatz. Dasgleiche Szenario nur mit 'READ datei INVALID KEY' und ebenfalls 1000 Zugriffen benötigte fast dieselbe Zeit. *grummel*
Von Multi-User Szenarien und den von dir angedeuteten Problemen will ich noch gar nicht träumen ...

Also wenn es da keine entscheidenden Verbesserungsmöglichkeiten gibt ist das wohl kein gangbarer Weg. Die Technik mit der DTAQ und dem permanenten Starten/Beenden des Programms welches aus der External Prozedur gestartet wird schluckt wohl einfach zuviel Zeit!?


Nun zur anderen Option mit ILE Cobol. Hier gibt es wohl verschiedene Möglichkeiten. Mir ist heute jedoch ganz schwindelig geworden als mir im Handbuch Begriffe über den Weg liefen wie 'Run Unit', 'Serviceprogramm', 'Static Procedure Calls', 'Dynamic Programm Calls', 'Activation Groups' etc.
Aus diesem Wust von Möglichkeiten diejenigen rauszufiltern welche für mein Problem sinnvoll einzusetzen sind ist für einen von der 'Mausschieberfraktion' nicht trivial

Wäre für Tips mehr als dankbar! Sonst verrennt man sich in Dinge die von vornherein zum Scheitern verurteilt sind und merkt das selbst erst viel zu spät ...

Beste Grüße
Neptun

[Fuerchau]

Also, die "einfachste" Variante für ILE-Cobol, ist, die OPM-Programme einfach nur auf ILECBL umzustellen und zu wandeln. Beim Erstellen gib einfach eine ACTGRP mit Namen und nicht mit *CALLER an.
Beende die Programme grundsätzlich mit EXIT PROGRAM. Ich habe früher immer EXIT PROGRAMM und GOBACK direkt hintereinander verwendet, so dass das PGM sowohl als Upro als auch als Hauptprog verwendet werden konnte.
Beachte allerdings bei wiederholten Aufrufen den Status geöffneter Dateien.

RUN UNIT ist das alte COBOL-Problem (was RPG'ler nicht kennen), dass STOP RUN alle Programme der RUN UNIT beendet (PGMA->PGMB->PGMC->... STOP RUN: bis einschließlich PGMA beendet). Mit ACTGRP's gibt es eben eine RUN UNIT pro ACTGRP.

Service-PGM'e sind im ersten Schritt nicht erforderlich. Dies sind Programme, die häufig benötigte Routinen enthalten sollen. Alle SQLxxx-Funktionen liegen z.B. in Service-PGM'en.

Wenn man mit CALL PROCEDURE arbeitet, sind das sog. STATIC-Calls, da der Name nicht in einer Variablen stehen kann und bereits zum Aufrufzeitpunkt (Service-PGM'e) bzw. zur Compile-Zeit die Adresse zum Modul / zur Routine ermittelt wird.

Mit CALL aufgerufene PGM'e sind dynamisch, da erst zur Laufzeit das externe Programm über die Libliste ermittelt wird. Dabei ist es unerheblich, ob ein OPM- oder ILE-Programm aufgerufen wird.

Nun zu deinem Test:

Dieses Vorgehen (ich bitte um Entschuldigung) war ja sowas von unsinnig !!!
Mit 19 Millisekunden pro Satz bist du doch noch relativ fix gewesen, wenn man sich mal vorstellt, was da alles ablaufen musste.

Beim Erstellen der DTAQ ist zu beachten, ob jeder QSNDDTAQ unbedingt auf die Platte geschrieben werden muss. Dies sollte man abschalten, da es nach diesem Verfahren keinen Sinn macht, DTAQ-Inhalte über IPL hinweg aufzuheben.

Und was sollte diese Funktion bringen ?

Wenn nur Daten gelesen werden sollen, ist keine SQL-Prozedur erforderlich, da ein direkter Select/Fetch BEDEUTEND schneller abgewickelt wird !!!
Das gleiche gilt auch für INSERT/UPDATE/DELETE !!!
Insbesonders im Multiuser-Betrieb würde eigentlich jeder User einen solchen Batchjob benötigen, da du sonst Satzsperren nicht unter Kontrolle hast (UPDATE ohne READ).

SQL-Prozeduren sind nur dann sinnvoll, wenn ein komplexer Vorgang KOMPLETT auf den Server verlagert werden kann. Will heißen, dass durch Parameter gezielt bestimmte Funktionen ausgelöst werden (z.B. ein Buchungsvorgang über mehrere Dateien) und nur das Ergebnis (falls überhaupt) wieder benötigt wird.

Es kann auch sinnvoll sein, wenn z.B. eine Subfile (Liste) gefüllt werden muss und die Daten nicht einfach durch einen Select (egal wie komplex) ermittelt werden können.

Untersuche deine Programme doch mal nach folgenden Kriterien:
1. Dialog-Programme
Diese kann man einfach erstmal auf SQL umstellen, wobei ggf. geprüft werden sollte, welche Felder einer Datei überhaupt benötigt werden (Crossref) um die Selects/Updates zu verkürzen.

2. Unterprogramme
Dies sind typischerweise Programme, die als SQL-Prozeduren in Frage kommen, da sie keine Benutzeraktion benötigen und die Paramter (Ein-/Ausgabe) per Linkage-Section ja vorgegeben sind.
Dies können natürlich auch CLP's sein, die z.B. einen SBMJOB für Batch auslösen.

Teste doch mal deinen START / READ NEXT / READ INVALID direkt als SQL-Programm in 2 Varianten:
1. mit komplettem Satz
2. nur mit relevanten Feldern (max. 10)

Für START/READ NEXT benötigst du einen Cursor (OPEN/FETCH into, hier ist auch Blocken möglich).
Für READ INVALID benötigts du keinen Cursor, da ein direktes SELECT INTO möglich ist.

[Neptun]

@Fuerchau

Habe heute mal die 'einfachste' Methode ausprobiert. Hat nach einigen mir nicht erklärlichen Problemen dann doch funktioniert.

Merkwürdigerweise funktionierte es mit CRTBNDPGM inkl. Angabe der ACTGRP nicht. Erst mit CRTCBLMOD und anschließendem CRTPGM mit Angabe der ACTGRP funktionierte es das das Programm im Hauptspeicher gehalten wurde.
Zunächst wurde ein OPEN durchgeführt und bei den Folge-Aufrufen dann wieder READ's und zum Schluß dann ein CLOSE und STOP RUN. Dann war die ACTGRP auch weg.
Aber irgendwie hatte ich Probleme mit dem Befehl EXIT PROGRAM. Der Befehl wurde einfach ignoriert und das Programm linear fortgesetzt. Erst die Änderung in 'EXIT PROGRAM AND CONTINUE RUN UNIT' als ALLERLETZTE Zeile im Cobol-Programm brachte den gewünschten Erfolg.
Ich frage mit ob ich da etwas falsch mache? Bin noch nicht dazugekommen das mit weiteren Unterprogrammen zu probieren ... mal sehen wie es dort ausschaut.


Zum Test mit der DTAQ und dem Lesen von 1000 Sätzen: Mag sein das der Test *SO* nicht sehr sinnvoll war. Ging auch primär erstmal darum zu testen ob das technisch so funktioniert ... bin wie gesagt kein AS/400 Freak und habe gestern zum ersten Mal DTAQ's "gesehen"
Und du hast völlig recht: External-Prozeduren machen erst Sinn wenn komplexere Verarbeitungen auf der AS/400 durchgeführt werden sollen!! Ganz klar!!
Und das ist ja auch mein Ziel!!
So viel wie eben möglich auf der AS/400 ablaufen lassen und so wenig wie eben möglich auf dem PC.


Zu deinem Vorschlag was ich mal testen soll:
Was meinst du mit 'direktem SQL-Programm'?

Beste Grüße
Neptun

[Fuerchau]

Das "AND CONTINUE RUN UNIT" war mir noch nicht bekannt, aber ist genau das was du brauchst. Ob unbedingt als allerletzte Zeile oder als letzter Befehl einer Section ist wohl nicht so entscheidend. Du musst schließlich unterscheiden können ob die RunUnit aktiv bleiben soll oder nicht. Bei EOF könnte man durchaus EXIT PROGRAM ansonsten halt mit AND CONTINUE ...

CRTCBLMOD mit anschließendem CRTPGM ist so die korrekte Vorgehensweise (COBOL ist nun mal doch etwas anders als RPG, wo vieles einfacher ist).

Direktes SQL meine ich ein Programm auf dem PC, dass die SQL's (embed oder nicht) per ODBC absetzt und zwar in den beiden Varianten. Es gibt häufig Dateien mit mehr als 100 Feldern, die aber vom Programm nicht benötigt werden. Warum also nicht benötigte Daten überhaupt erst lesen ?
Für eine performante Lösung muss man auch schon mal die Funktionalität prüfen, ob nicht z.B. eine Leseschleife über mehr als 1 Datei nicht auch als Join direkt aufgelöst werden kann.
Zu prüfen ist auch, ob bestimmte Berechnungen der Daten nicht bereits per SQL erledigt werden können, man braucht manchmal nur das Ergebnis aber nicht die 2 - 5 Felder der Berechnung usw. usw.

[Neptun]

@Fuerchau

Besten Danke für deine erstklassige Hilfestellung! Fühle mich schon fast als halber AS/400-Experte, *LOL*

Also der Exit Program reicht tatsächlich als letztes Statement in einer Section, hatte da etwas übersehen.
Gibt es eigentlich etwas Spezielles zu beachten wenn man umstellt von OPM Cobol auf ILE Cobol? Vermute mal nicht ...
Ich konnte im Handbuch nicht herausfinden wie man einen anderen ENTRY POINT als den normalen Programmstartpunkt, also die erste Zeile nach PROCEDURE DIVISION, bestimmen kann. Und als ich dann mit SET {Procedure-Pointer} ENTRY {PGM1} und anschließendem CALL {Procedure-Pointer} kam die Meldung das rekursiver Aufruf nicht zugelassen ist. Ich frage mich nun wo liegt da der Unterschied zum herkömmlichen dynamischen CALL?
Offenbar ist es wohl nicht möglich wenn eine Aufrufkette von PGM1 -> PGM2 -> PGM3 -> PGM4 besteht direkt aus PGM4 zurück zum PC zu gehen. Man muss offenbar rückwärts durch alle Programme gehen bis zum Hauptprogramm (aufgerufen durch die External Procedure) um zurück zum PC zu kommen!?!? Oder gibt es doch eine Möglichkeit? (STOP RUN geht natürlich, aber dann ist die ganze ACTGRP weg)
Interesssant wäre z.B. die Möglichkeit von einer beliebigen Stelle in einem beliegen Cobol-Programm der RUN UNIT zurück zum PC zu verzweigen und nach Verarbeitung auf dem PC einfach mit der nächsten Programmzeile (oder auch einem ENTRY POINT) weiterzumachen.
Was mir auch noch unklar ist warum folgendes Szenario nicht funktioniert hat:
CRTCBLMOD PGM1
CRTCBLMOD PGM2
CRTPGM PGM1 mit Angabe von PGM1 und PGM2 als Module
Wenn man nun vom PC aus per External Procedure PGM1 startet und PGM1 versucht PGM2 aufzurufen (dynamischer CALL) dann wird PGM2 nicht gefunden (Auflösung nicht möglich ...)

Habe dann immer CRTCBLMOD PGM1, CRTCBLMOD PGM2, CRTPGM PGM1 und CRTPGM PGM2 gemacht. Dann funktionierte es. Ist das die normale Vorgehensweise?



Das mit dem direkten SQL-Programm ist sicher mittel- bis langfristig die bessere Lösung. Denn das wäre definitiv eine Lösung die dann auch auf allen Datenbanken funktioniert. Vorraussetzung für eine gute Performance ist da sicherlich eine kritische Analyse der Datenzugriffe und einer vernünftigen Anpassung.

Vermutlicherweise wird dennoch eine Lösung ohne Umsetzung der Dateizugriffe auf SQL-Basis nötig werden, da diese Lösung für uns einfach schneller fertigzustellen wäre und sich da ein Termindruck andeutet ...

Beste Grüße
Neptun