Welche Kommunikation?

[Neptun]

@Fuerchau

Erstmal danke für die Antwort!
Aber ohne konkret zu wissen was sich hinter [SQL-CALL-Schnittstelle mittels
"Create Procedure"] verbirgt vermute ich das ich mich eventuell unklar ausgedrückth habe.
Vom Namen her würde ich vermuten das diese SQL-CALL Schnittstelle SQL-Befehle übergibt und das diese per "Create Procedure" ausgeführt werden!?
Das möchte ich ja gerade nicht. Der Client (PC) soll ja nur die Oberfläche (GUI) auf Windows erstellen.
Die Daten sollen ausschließlich (Ausnahmen könnten sich-nicht-verändernde Daten für das GUI-Programm sein) auf der AS/400 (Server) liegen (Stammdaten / Bewegungsdaten).
Und die Daten sollen mit herkömmlichen COBOL-Befehlen (Read / Write / Rewrite / ...) verarbeitet werden und nicht mit SQL.

Beispielszenario:
- Anwender startet auf Client (PC) die Oberfläche
- Benutzer und Passwort wird eingegeben
- PC-Programm sendet Datenstring (plus Anweisungen was mit den Daten zu geschehen hat) an die AS/400
- dort nimmt ein (wartendes) Programm die Daten entgegen
- entsprechend der Anweisungen werden die Daten an das zuständige Programm weitergeleitet
- wenn die Anweisung abgearbeitet wurde wird ein Datenstring (z.B. der Bildschirminhalt) zurückgegeben von der AS/400 an den PC
- dieser Vorgang wiederholt sich dann solange bis der Anwender das Programm beendet
(über das Netzwerk soll also im Prinzip nur der Bildschirminhalt gehen)

Ist dafür tatsächlich SQL-CALL geeignet? Dann würde ich mich in dieser Hinsicht mal schlau machen.
Ich hatte eher an eine direkte Programmkommunikation gedacht, z.B. über 'Sockets' (TCP/IP). Weiß aber nicht ob ich mit COBOL/400 die AS/400 Socket-API's ansprechen kann.
Auf dem PC weiß ich das es mit dem eingesetzten COBOL-Compiler problemlos möglich ist 'Sockets' zu nutzen.

Zusammengefasst könnte man sagen das das Ziel ist quasi eine eigene 'Runtime' auf der AS/400 zu haben welche die vom PC geschickten Daten direkt verarbeiten kann. Diese 'Runtime' sollte falls möglich in COBOL sein da die ganze Anwendung in COBOL programmiert ist.

Kann man aus COBOL/400 die AS/400 Socket-API's aufrufen? Und ab welchem Release ist das möglich?


Bezüglich der dürftigen Performance der ODBC-Anwendung:
Dafür gibt es mehrere Gründe:
1. Es wurde kein neues Datenformat erstellt sondern einfach die verschiedenen COBOL-Datensätze in verschiedenen Tabellen untergebracht
2. Es wird jeder Datensatz mit SQLFetch gelesen. SQLScrollFetch um z.B. Arrays von Datensätzen zu übertragen wird nicht genutzt.
3. Es wurden einfach nur die entsprechen READ / WRITE / REWRITE / DELETE -Befehle durch die entsprechenden SQL-Befehle ersetzt (es musste eine schnelle Lösung her und so kam man relativ zügig zu einer ablauffähigen ODBC-Anwendung)


Beste Grüße
Neptun

[Fuerchau]

Naja, so implementiert man eigentlich keine Client-Server-Lösungen.
Ich bin zwar auch nicht DER Fachmann, aber die Lösung heutzutage sieht eigentlich so aus:

Sämtliche Zugriffe erfolgen nur noch per SQL !
Dazu gibt es mehrere Methoden:
- die bekannte mittels Select/Fetch, Update, Insert, Delete
- Create Procedure mit Übergabe-/Return-Parametern, Aufruf per CALL
- Create Procedure mit Übergabe-Parametern und Return-Recodset, Aufruf per Call und lesen mit Fetch
- Trigger
- Constraints (Foreign-Keys)

Ach ja: und ganz wichtig Journalisierung mit Commit-/Rollback-Steuerung

Und nur was damit nicht gelöst werden kann, erfolgt z.B. mit Sockets o.ä.

Die Socket-API's lassen sich mittels "Call Procedure ... using ... returning ..." aus ILE-COBOL verwenden.

Naja, und ansonsten sollte man neue Anwendungen mit Java lösen.

[Neptun]

@Fuerchau
Also die ganzen SQL-Lösungen können mich nicht begeistern.
Es gibt halt eine fertige Anwendung die auf herkömmlichen COBOL-Index Dateien basiert. Diese läuft stabil und soll nun halt, obwohl weiterhin auf der AS/400 laufend, mit unserer Windows-GUI zusammenarbeiten.
Bei einer Neuerstellung wäre der Ansatz mit SQL sicher interessant.

Noch eine Frage hierzu: "Aufruf per CALL" sagst du. Du meinst man kann vom PC aus diese Sachen wie "Create Procedure" aufrufen?

Geht Socket-API auch aus COBOL/400 oder nur aus ILE Cobol?
Und welche Alternativen würde es noch zu Sockets geben?
Habe da mal was von DDM und DDM-RLIO oder so gehört !?

Frage mich z.B. wie es ODBC-Treiber im Detail machen? Oder OLE DB Provider? Gehen die über Sockets?

Beste Grüße
Neptun

[Fuerchau]

Schau dir SQL einmal genauer an.
Mit "Create Procedure" definierst du eine Prozedur, die mittels SQL-CALL aufgerufen werden kann. Du kannst sowohl Eingabe- als auch Ausgabe-Parameter definieren (wie in direkter "Call ProgName using ... " halt auch), du nutzt halt nur die fertige Kommunikation.

Da ODBC zur AS/400 nun mal über TCP/IP geht, spielen natürlich Sockets eine Rolle, da das die einzige TCP-Kommunikation ist.

Die API's kannst du nur per ILE-COBOL aufrufen, da es C-Funktionen und keine OPM-Programme sind.

Beim OLEDB IBMDA400 gibt es sogar eine direkte CALL-Schnittstelle, die mit SQL nichts zu tun hat (etwas aufwändiger als SQL).

Warum etwas neu erfinden, wenn es schon Standards gibt ?

[Neptun]

@Fuerchau

Warum das Rad neu erfunden? Tja, gute Frage

Bietet diese SQL-CALL-Schnittstelle denn Performance-Vorteile gegenüber ODBC?
Und wie spricht man diese Schnittstelle von einem COBOL-Programm welches auf dem PC läuft an? Gibt es da sowas wie einen Treiber?

Wie würdest du denn vorgehen wenn du eine FERTIGE Anwendung hättest die auf COBOL-Index-Dateien basiert.
Es gibt eine AS/400 Version und eine Windows-Version mit GUI (die ODBC-Version ist eigentlich mehr experimentell ...).
Nun sollen die Programme (speziell die Batch-Programme) weiterhin auf der AS/400 ablaufen. Aber die Oberfläche natürlich auf einem Windows-PC mit schicker GUI laufen.
Würdest du tatsächlich nur den Weg sehen alles auf SQL-Basis umzustricken, gibt es keine vernünftigen Alternativen bei denen man die COBOl-Dateizugriffe auf die Index-Dateien so lassen kann?

Beste Grüße
Neptun

[Fuerchau]

Also: der SQL-CALL ist eine SQL-Anweisung wie SELECT mit dem Unterschied, dass eben eine Prozedur (ein externes Programm) auf dem Zielrechner aufgerufen wird.
Der CALL gehört zum Funktionsumfang von SQL, bedarf keines speziellen Treibers und wird auch via ODBC/OLEDB aufgerufen.
Der Vorteil liegt einfach darin, dass ich ein Programm aufrufe, dass einfach mehr kann als ein direkter SQL-Befehl.

Auf der AS/400 gibt es keine spezifischen COBOL-Indexdateien, sondern ganz normale PF's und LF's, die auch per SQL angesprochen werden können.
Es stellt also kein Problem dar, die Datei-Zugriffe als embedded SQL-Zugriffe umzustellen. Performance-Einbussen gibt es nur über das Netz.
Das größere Problem ist wohl eher die 5250 in eine GUI zu übersetzen. Sicherlich gibt es da genug Tools, aber "schön" ist das eher nicht. Also erfordert das hier ggf. ein Redesign.

Die Batchprogramme stellen nun mal überhaupt kein Problem dar.

Die "vernünftige" Alternatve zu SQL ?
Die muss wohl erst noch erfunden werden.

Warum gibt es dann soviele Datenbanken, insbesonders bei PC-Anwendungen wie MS-SQL-Server, MySQL, Firebird, MS-Access und und und... ?

Weil SQL eine genormte Schnittstelle zu Dateisystemen bietet und sehr einfach zu handhaben ist.

Also nochmal:
Warum etwas neues erfinden, wenn SQL alles bietet was man braucht ?

[Neptun]

@Fuerchau

Danke für deine Geduld und deine Auskunftsbereitschaft

Habe heute auch herausgefunden das man über den ODBC-Treiber 'stored procedures' aufrufen kann. In der Hilfe-Datei vom ODBC SDK 3.5 wird auch davon gesprochen das diese 'stored procedures' zunächst mit 'Create procedure' zu erstellen sind.
Das sind doch die SQL-Calls die du meinst, oder?
Unklar ist mir ob ich einfach per 'SQLExecDirect' über den ODBC-Treiber diesen Befehl 'Create Procedure' auf der AS/400 ausführen kann. Denn ich hatte in den IBM Online Manuals etwas davon gelesen das für 'Create Procedure' diverse Lizenzprogramme installiert sein müßen, die aus meiner Sicht nicht zum Standard-Umfang gehören!?

Du schreibst das es Performance-Einbußen nur über das Netz gibt. Ok! Nehmen wir doch einmal an wir stellen unsere Dateizugriffe auf SQL um. Nun möchten wir vermeiden diese Datensätze über das Netz zu schleusen. Stattdessen sollen (fast) alle Programme auf der AS/400 laufen und dort per SQL auf die Daten zugreifen. Über das Netzwerk sollen nur noch die Informationen gehen die der Client (PC) am Bildschirm anzeigen soll. Auf dem PC soll also nur die GUI laufen. Dadurch wird der Netzverkehr auf ein Minimum reduziert und eine Verarbeitung von mehreren hunderttausend Sätzen läuft ohne Performance-Verlust (im Vergleich zur SELBEN Anwendung im "grünen" Bildschirm) auf derAS/400 ab. Wir möchten halt wenn irgend möglich diese Datensätze nicht übers Netz transportieren.
Und nun "Back to the roots": Welche Kommunikation? Gibt es da etwas außer 'sockets'? Sind APPC oder DDM dafür geignet?

Beste Grüße
Neptun

[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