RPG-CALL mit Parameter aus VB...

[Fuerchau]

Welche Proceduren da sind, kannst du ja aus "procedures" erfahren.
Welche Parameter eine Prozedur hat erfährst du aus "Sysparms" !

Proceduren müssen leider genauso wies sie erstellt wurden, gelöscht werden.
Es können ja durchaus gleiche Prozeduren mit unterschiedlichen Parametern erstellt werden. Dies nennt man "Overloading", bekannt aus der C++-Programmierung.

Beim "drop procedure" muss die genaue Parameterliste angegeben werden, im Zweifel sogar die Ausprägung:

drop procedure lib.name (char, char, ...)
drop procedure lib.name (char(10), char(5), ...)

usw.

Das gleiche gibt es übrigens auch für Funktionen "create function".
Vorteil hierbei ist, dass diese Funktionen im "Select" bzw. überall wo Scalar-Funktionen erlaubt sind, verwendet werden können.
Seit V5 kann man sogar reine SQL-Funktionen erstellen, da der intern verwendete C-Kompiler nicht extra lizensiert werden muss.
Ich kann also relativ komfortable Funktionen in SQL erstellen ohne RPG bemühen zu müssen.

[BeWe]

Ja so klappt das anscheinend recht gut , und ich kann
nur abermals tausend Dank aussagen.

In C++ ist das Überladen von Funktionen, mit genügend
Vorsicht ja durchaus eine Interessante Sache. Wusste
bis eben nicht, dass dies auch hier als solches Phänomen
zu verstehen ist.

Aber ganz ehrlich,... habe mal gehört, dass ein gut durch-
dachtest RPG-Programm schneller sei, als SQL. Ist da etwas
dran, oder ist das falsch?

[Fuerchau]

Ja und Nein !
Es gibt 1000+ Argumente, die da eine Rolle spielen.

1. DB-Design
Es gibt Designs, da ist RPG einfach schneller, da SQL damit nicht zurechtkommt (Stichwort Normalisierung). Probleme bieten z.B. Schlüsselungleichheiten (Numerisch/Alpha) bei Join's oder Beziehungen, die nur per Programm aufgelöst werden können.

2. Recordlevel-Access (Einzelsatzverarbeitung)
Hier sollte man bei RPG folgendes wissen:
Dateizugriffe erfolgen immer über interne Puffer, also nie mit den Feldern direkt.
Durch die F-Bestimmung wird ja automatisch eine I-Bestimmung generiert. Der Compiler generiert aber ausschließlich die Felder, die eine Referenz aufweisen.
Nach einem READ/CHAIN werden aus dem Puffer die Felder gefüllt und vor dem WRITE/UPDATE der Puffer aus den Feldern gefüllt.
Arbeitet man aber mit einer externen DS, die alle Felder enthält auch wenn man sie nicht benötigt, werden jede Menge Move's generiert, die nichts als Zeit kosten.

Bei SQL sollte man IMMER die Felder selektieren (und fetchen) die man benötigt, man spart sich da also ein bißschen. Merkbar ist das aber nur bei sehr vielen (>100.000) Datensätzen.

Bei der Feldart sollte man darauf achten, dass nach Möglichkeit der gleiche Typ verwendet wird, das spart Konvertierungen.
Leider kennen DSPF/PRTF's keine gepackten Felder (auch wenn man sie definiert, der Compiler macht immer zoned daraus), was fast immer zu einer Konvertierung führt.

Auch SQL führt Anpassungen durch, die man aber durch explizite Definition minimieren kann.

3. Massen-Funktionen
Ganz klar bietet SQL den Vorteil bei Select mit Gruppierungen, Scalar-Funktionen o.ä.
Hier reicht oftmals ein Select, was in RPG mühsam programmiert und berechnet werden muss. Hier ist SQL schneller, da dies auf sehr tiefer Ebene in der DB gelöst wird.
Auch ein Massen-Update sowie Massen-Delete bietet große Vorteile.

Fazit:
Es kommt immer auf die gewünschte Funktion an, ob SQL oder RPG schneller ist.
Übrigens: COBOL kennt viele Overheads von RPG nicht und ist insbesonders bei nativen Dateizugriffen schneller (hier wird im Programm direkt mit den Dateipuffern gearbeitet).

Ein großer Vorteil von SQL ist, dass ich Optimierungen der DB vornehmen kann, ohne an den Programmen etwas zu ändern (Formatebenen-Id) oder einfach nur Spalten hinzufügen kann.
Ist ein SQL-Zugriff langsam, kann ich ihn beschleunigen indem ich einen Index erstelle. Will ich das RPG-Programm beschleunigen erfordert das ggf. ein Redesign.

[Fuerchau]

Nachtrag

29 Parameter sind ja doch releativ viel, da die Gesamtanzahl Paramter auf (ich glaube) 32 beschränkt ist.
Wenn dies alles Ausgabeparameter sind, bietet sich eine andere, flexiblere Lösung an:

as400db.Execute "CREATE PROCEDURE MyLib.MyPgm (IN :PARM1 CHAR (512), IN :PARM2 DEC(15, 5)) LANGUAGE RPG RESULT SET 1 NOT DETERMINISTIC NO SQL EXTERNAL NAME MyLib.MyPgm PARAMETER STYLE GENERAL", , adExecuteNoRecords

Damit kannst du eine dynamisches Recordset zurückgeben:

h dftactgrp(*no) actgrp('MyGroup')

d MyStruct ds
d Field1 10
d Field2 5
d Field3 10p 2
:

/exec sql set result sets array MyStruct for 1 row
/end-exec

eval *inlr = *off

Wichtig ist, das das Programm aktiv bleiben muss, da auf die Variablen von SQL noch zugegriffen werden muss.

Vorteil:
Die Anzahl der Prozedur-Paramter reduziert sich und bei Erweiterung der Return-Werte braucht die Prozedur nicht neu beschrieben werden.

Die Anzahl der Zeilen kann auch dynamisch festgelegt werden:

d MyCount s 5p 0
d MyStruct ds dim(1000)

/exec sql set result sets array MyStruct for :MyCount row
/end-exec

Anzahl kann natürlich auch 0 sein (leeres Recordset).

Mit "set MyRcd = as400cmd.Execute" wird dann ein Recordset zurückgegeben.

Ich denke, dass dieses Verfahren für Dich vielleicht die bessere Lösung darstellt.

[BeWe]

Hallo Fuerchau,

vielen Dank für den Tip, werde das auf jeden Fall mal versuchen
zu testen, jedoch weiss ich nicht, wie ich in RPG eine Struktur
zurückgeben kann, bzw. wie dann der Parameter definiert werden
muss.

Folgendes Problem hat sich neuerdings ergeben...

D UrProg s 11S 2 DIM(12)

anstatt 12 einzelne Paramter gilt es nun dieses (ich denke mal)
eindimensionale Array zurückzugeben, wobei ich mich frage
welchen Typ für diesen Parameter ich dann bei der CREATE PROCEDURE
angeben soll. Char und Dec doch sicher nicht, oder?

Weisst du da eine Lösung bezüglich dieses Problems?

Nochmals danke für den Tip, und sorry für die späte Antwort.
PS.: lautet der SQL-Code in deinem Beispiel wirklich so, oder ist
das einfach nur englischer Pseudo-Code

[BeWe]

Nachtrag:

** umwandeln mit COMMIT *NONE
** ALWCPYDTA *NO
***********************************************
h dftactgrp(*no) actgrp('MyGroup')
/free
d MyStruct ds
d Field1 10
d Field2 5
d Field3 10S 2
:

/exec sql
set result sets array MyStruct for 1 row
/end-exec

*inlr = *off

/end-free


Habe das Programm so erstellen wollen, wobei ich allerdings
auf mehrere Fehler gestoßen bin. Zum Beispiel einen 40er
Fehler der da heist "Das Umwandlungsprogramm kann nicht
bestimmen wie das Programm enden kann"

Was mache ich falsch? Semikolons vergessen? kommen die
ausnahmslos hinter jede Zeile?

[Fuerchau]

Den Code habe ich aus dem Handbuch "SQL Programming Concepts" entnommen und ist dort in ähnlicher Form zu entnehmen.

Arrays werden von SQL grundsätzlich nicht unterstützt. Hier bietet sich geradezu obige Methode an, da hier im Recordset 12 Sätze zurückgegeben werden können.

Im übrigen frage ich mich hier, was du mit den vielen Prozeduren überhaupt so treibst und du nicht ggf. in konzeptionelle Schwierigkeiten kommst.
Das Design des Ganzen sollte man vielleicht mal etwas detaillierter betrachten. Ich kann auch gerne hierzu Unterstützung leisten (siehe meine Homepage).

[Fuerchau]

"/free" ist nur im C-Teil der Quelle erlaubt.

"/exec sql" ist nicht im Free-Format möglich (daher kein Semikolon) weil der Pre-Compiler Nicht-Free-Formate generiert.

Im Free-Format ist immer ein Semikolon am Ende einer Anweisung erforderlich, da der Compiler sonst nicht weiß wie es weiter geht.

Der Einfachheit halber hatte ich mein Beispiel auch nicht im Free-Format angegeben.

[BeWe]

Aha, ja gut, das muss ich ja auch erst einmal wissen, gell .
Werde das mal gleich probieren...

Zum Konzept... ich arbeite in einem größeren Unternehmen
für welches hier intern Programmlösungen und -Anpassungen
geschrieben werden müssen. Das ganze hat alles auf einer
As400 angefangen wo die Daten auch jetzt noch Dank der
hohen Stabilität bleiben sollen.
Allerdings wollen wir uns etwas von den Scharz-grünen
Bildschirmmasken lösen und suchen daher Alternativen in
anderen Programmiersprachen wie z. B. Visual Basic, wo
ich mich ganz gut auskenne.

Unsere AS400-Programmierer tendieren eher zu Java,
wobei ich finde dass dort alles wesentlich umständlicher
ist, oder liegt das nur in meiner Java-Unwissenheit begründet?

Ich denke gerade im Office - AS400 - Datenaustausch und
überall sonst, wo Microsoft-Produkte eingesetzt werden kommt
man doch sehr, sehr viel schneller mit VB ans Ziel, oder was
kannst du da empfehlen?

[Fuerchau]

Im MS-Office-Bereich ist tatsächlich der bessere Weg VB, VBA. Nach Möglichkeit sollte man Standard-ODBC-Zugriffe verwenden können ohne komplizierte Prozeduraufrufe !
Funktionen im Select (mittels Create Function) machen auch noch Sinn, aber für alles andere muss man ja doch schon programmieren, AddIn's entwickeln usw.

Java ist genauso gut oder schlecht wie VB, kommt auf die Entwicklungsumgebung an.
Bei VB muss ich mich ja auch nicht mehr um alles kümmern, genauso gilt dies für Java.
Der einzige Nachteil bei Java sind die Resourcen:
welche JVM soll laufen (Microsoft, IBM, Sun, ...)
wie schnell ist die Hardware
usw.
Vorteile von Java kann dir Dieter Bender sicherlich genug ausführen.

Tipp's:
Für den Download (Excel, Word-Serienbrief) sollte man die Stand-ODBC-Funktionen (MS-Query) verwenden und nicht die CA-Transfer's (siehe hierzu auch meine anderen Beiträge).
Für den Upload (aus Excel) kann ich mein Tool Upload400 wärmstens empfehlen.

[BeWe]

Also diese hier gewünschten Lösungen bestehen nicht "nur"
darin, bestimmte Daten nach Excel zu bringen sondern schon
in richtigen Frontends, wie Lagerverwaltungen, Terminplanung
Logistik usw.
Wir haben zwar eine Lösung in Access über verknüpfte
Tabellen mal getestet jedoch ist das mit Access eine
sehr bescheidene Sache und VBA kann halt doch nicht all
das bieten, was VB kann, schon allein wegen der Unabhängig-
keit. Auch in VB habe ich über DAO-Zugriffe schon einiges
schreiben können, jedoch sind die Geschwindigkeitseinbußungen
einfach zu groß.

Die Lösung mit den RPG-Programmen ist einfach nur deswegen
sehr interessant, da es schon eine Menge davon gibt, und
es ja doch schon sehr erleichternd ist, diese Programme in
VB nicht nochmal alle neu schreiben zu müssen.

Mit deinem Beispiel komme ich allerdings immer noch nicht
ganz klar. Wie soll denn das Umwandlungsprogramm nun
wissen, wie es enden kann?

[Fuerchau]

"return" ist der Schlüssel zum Erfolg !
Das hatte ich doch glatt vergessen.