Programmaufruf auf der AS400

[alex61]

Hallo zusammen,
kann ich von der WINDOWS-Welt aus auf der AS400 ein Programm aufrufen ?
Wenn ja, wie säh das aus ?
Für Infos wäre ich wie immer dankbar.
Schönen Abend.
A.

[Robi]

Bei uns läuft das AS400 Pgm in der QBATCH und horcht auf eine Dataq
Das PC pgm schreibt diese und bekommt auch Ergebnisse auf diesem Weg

[Fuerchau]

Dafür gibts die WinAPI des ACS.
Es werden direkte Calls über eigene API's unterstützt, alternativ kann man jedes Programm mit einfachen Parametern auch in SQL direkt aufrufen.
Man muss da nur die richtigen Parameter genau in der korrekten Länge definieren.
Am Einfachsten ist da jedoch der CALL QCMDEXC, da der nur 2 Parameter hat.

Das obige API unterstützt sogar Returnparameter.

Du kannst natürlich auch per SQL eigene Prozeduren und Funktionen entwickeln, die dann Programmaufrufe noch kapseln können.

Der Overhead mit DTAQ ist da nicht mehr nötig.

[Robi]

Wenn der PC Mensch keine Dataq schreiben kann geht auch eine Datei via odbc/jdbc.
Wenn es dann zeitkritisch ist, schreibt ein Trigger auf der Datei die dataq ...

[Fuerchau]

Schon mal einen direkten "CALL MYPROG (P1, P2)" via SQL probiert?
Einen Create Procedure benötigst du dafür nicht.

[alex61]

vielen Dank an alle, ich probiere mal aus !!

[alex61]

könnte man von Windows aus auch folgenden Aufruf absetzen:

/QSYS.LIB/EUREXC.CSJ.LIB/EXCCSJCALL.PGM "CALL EUREXC/XRCSJCLRSB PARM('$P01' '$P02' '$P03' '$P04' '$P05' '$P07' 'ORDERS')"

[Fuerchau]

Nein, IFS-Notation geht generell nicht.
Wie gesagt, per SQL via ODBC/JDBC, z.B. per ACS-SQL-Script:

CALL QCMDEXC ('CALL .....', 1234567890,00000)

Der erste Prameter ist dein Befehl (Hochkomma sind zu verdoppeln!), der 2. Parameter ist die Länge des Befehls, aufbereitet mit Vornullen (10 Stellig). Die Nachkommata konstant 5 Nullen.
SQL macht dann ein packed(15, 5)-Parameter daraus.

Wenn du nicht auf die Ausführung warten willst, kannst du auf dieselbe Weise auch einen "SBMJOB ..." absetzen.

[BenderD]

da gibt es noch mehr:
ftp rcmd, rexec, rsh habe ich noch nicht probiert, müsste auch gehen. Bei den Unix Varianten müssen dann AS/400 Programme über system ausgeführt werden. Was da sinnvoll sein mag, kann man nur im Lichte der konkreten Anforderungen einschätzen. Eigene Dienste (DataQ, Datei mit Trigger , SQL stored procedure sind frühere Würgdrumherums und nicht mehr erforderlich.

D*B

[Robi]

Eigene Dienste (DataQ, Datei mit Trigger , SQL stored procedure sind frühere Würgdrumherums und nicht mehr erforderlich.

Andererseits sind sie lange erprobt, laufen stabil, können so gestaltet werden, das Sie auch funktionieren wenn mal eins der Systeme nicht zur Verfügung steht.

Etwas funktionierendes ändern wir nicht, nur damit es hinterher 'modern' ist.
Wir ändern nur, wenn das 'moderne' Vorteile hat, die wir benötigen.

Jeder was er mag ...

[BenderD]

Lieber Robi,

hier ging es um eine Neuimplementierung und wenn da schon ein selbst geschriebener Serverdienst zur Verfügung gestanden hätte, dann wäre allenfalls was anderes gefragt worden. Ob man eine vorhandene Lösung damit neu schreiben würde oder sollte, steht auf einem ganz anderen Blatt. Ich habe diese Frage schon in beide Richtungen beantwortet. Man sollte allerdings in jedem Fall darauf achten, den technischen Teil der Kommunikation von der fachlichen Anwendung zu trennen und in einem eigenen Modul zu kapseln, dann ist der Austausch eines Kommunikationsprotokolls leichter durchführbar.

Gruß

Dieter,
der schon mehr als einen hausgemachten Serverdienst gesehen hat, der nicht stressfest war. Ganz früher mal von AS/400 zu BTX und auch schon einen modern aussehenden über Sockets, die in bestimmten Fehlersituationen einfach hängengeblieben sind.