Erfahrungsbericht IBM's freie Socket-API

[RobertPic]

Ich habe es in anderen Beiträgen schon angekündigt - hier meine ersten Erfahrungen mit den freien IBM „TCP/IP Socket Client APIs“ von hier: http://www-03.ibm.com/servers/eserver/services/assets/tcp_scktclient.html

Es gibt viele Fälle, wo der Einsatz von DataQueues ideal ist - inbesondere wenn die Kommunikationsdaten nicht verloren gehen sollen. Aber die DataQueues werden dann kompliziert, wenn es viele verschiedene Clients gibt, welchen geantwortet werden soll. Dann braucht man entweder eine andere Art von Antwort (Datenbank, File) oder pro Client eine eigene Antwort-Dataqueue und am besten noch ein Session-Managment um Leichen in den Anwort-DataQueue’s zu erkennen.

Daher habe mich entschlossen meine Anfragen von 5250-Onlinejobs (Volltextsuche der eigenen Artikel, Katalog-DB, Lieferantenartikel, Speditionsabfragen (http), WebServiceanfragen...) mit Sockets (zu einem Javaserverjob) abzuwickeln.

Erfreulicherweise musste ich meine C-Kenntnisse nicht auffrischen - es steht eine ganz brauchbare Middle(Free)ware von IBM zur Verfügung.

Die Freeware von IBM ist einfach noch eine Schicht zwischen den System-API’s und der Applikation. Die Funktionen stehen als OPM- oder ILE-Module zur Verfügung.

Im Open wird die gewünsche Zielcodepage angegeben - damit ist die EBCDIC/ASCII-Umwandlung auch schon erledigt!

Für die Kommunikation gibt es Send und Receive bzw. Receive mit Waittime. Wenn man zeilenorientiert arbeitet, ähnelt das Arbeiten sehr stark den DataQueues.

Meine bisherigen Tests verliefen gut. Man bekommt sofort eine Fehlernummer, wenn der Server nicht erreichbar ist. Somit kann ich schnell z.B. auf einen anderen Server wechseln. Auch die Waittime beim Empfangen tut so wie sie soll (allerdings geht die Warterei nach dem ersten empfangenen Byte auf endlos). Ich habe bisher noch keinen Hänger provozieren können.

Derzeit teste ich mit 3 Serverdiensten (in Java geschrieben) - Anfragen werden abwechselend an 2 Linuxserver gestellt, die AS/400 ist nur das Backup, wenn beide Linuxserver nicht erreichbar sind.

Wobei die 1000CPW-Maschine die RAM-Datenbank (H2) auch locker wegsteckt, JDBC-Zugriffe auf fremde Datenbanken, sowie HTTP-Zugriff sind sowie recht harmlos - ich habe da allerdings (noch) keine großen Mengen.

Robert P.

[RobertPic]

Hier noch das mitgelieferte Demoprogramm:



h dftactgrp(*no) actgrp(*new) bnddir('QZRDSSRV/QZRDSSRV')
*
* This is an example of a program that opens a connection, sends
* a message, displays the reply, and closes the connection.
*
/COPY SOCKSTD
*
* The input parameters are designed to work with the CALL command.
* The port parameter is usually a 4 byte binary number, but the
* prototype for the TCPOPEN procedure will handle the conversion.
*
d host s 32
d port s 15p 5
d message s 32
*
d length s 10i 0
d rc s 10i 0
*
d reply s 52
*
* Entry parameters
*
* This routine gets called with three parameters:
* The system name
* The port number
* The message to send
*
* This parameter should be passed to the TCPACPT API.
*
c *ENTRY PLIST
c PARM host
c PARM port
c PARM message
************************************************** ***************
* Main routine
************************************************** ***************
*
* Open a connection and automatically translate data from ASCII to EBC
* The remote CCSID value of 819 is a good ASCII CCSID.
*
c callp tcpopen(host:port:0:819:rc)
c if rc = 0
*
* Send a message to the server delimited by a carriage return/linefeed
*
c callp tcpsend(message:%len(%trim(message)):
c 'C':' ':rc)
c if rc = 0
*
* Receive the response message.
*
c callp tcprecv(reply:%size(reply):'C':' ':length
c if rc = 0
c eval reply = %subst(reply:1:length)
*
* Display the response message.
*
c reply dsply
c endif
c endif
c endif
*
* Close the connection.
*
c callp tcpclose(rc)
c return

[schatte]

Hallo Robert,

leider ist der Link zu den Programmen nicht mehr aktuell. Gibt es hierzu einen aktuellen Link oder werden die Freeware Programme nicht mehr von der IBM angeboten?

Gruß
Matthias

[BenderD]

die originäre Frage kann ich nicht beantworten, aber mit dem Tutorial von Scott Scott Klement's web page (http://www.scottklement.com/) sollte man das auch hinbekommen.
Ergänzend noch drei Bemerkungen:
- Socket Server in RPG würde ich die Finger von lassen (vor V6R1 in jedem Fall) wg. bis dato fehlender Unterstützung von Multi Threading.
- Clients kann man durchaus in RPG schreiben
- DTAQ mit eigener ResponseQ pro Job ist deutlich einfacher und das löschen der DataQs kann elegant per Ile Exithandler (CEE4RAGE ist dein Freund) oder hölzern per CL Programm beim IPL erfolgen.

D*B

Hallo Robert,

leider ist der Link zu den Programmen nicht mehr aktuell. Gibt es hierzu einen aktuellen Link oder werden die Freeware Programme nicht mehr von der IBM angeboten?

Gruß
Matthias

[RobertPic]

Hallo Matthias,

ich habe mit einigen Wörtern aus Doku bei Google und IBM gesucht - Fehlanzeige.

In der IBM Suchdatenbank steht zwar noch der alte Text, wenn man draufklickt, landet man aber wieder bei der neuen Seite.

Laut Doku war davon die Rede, dass die API in neueren Version in Usertools wandern sollen. Bei den Usertools (V5R4) habe ich allerdings nichts davon gesehen.

Du kannst das Zeug auch von mir haben, aber wenn IBM das nicht mehr anbietet, kann ich das für neue Projekte auch nicht gerade empfehlen.

Ansonsten kann ich nur Positives von der API berichten. Es ist soetwas wie unsere Standard-Middleware für flüchtige Daten (alle Arten von Abfragen) bzw. wenn die Gegenstelle keine Dataqueues zulässt (z.B. Waage RS232 nach TCP/IP-Wandler, http get). Von den gefürchteten Hängern hatten wir noch überhaupt keinen.

Ansonsten kann ich weitgehend Dieters Ausführungen zustimmen.

bedingt für den Servertrieb geeignet
bekommt man Notfalls auch mit RPG hin, wobei es mit der API doch deutlich einfacher/kürzer ist
das die DataQueue Lösung mit ResponseQueue deutlich einfacher sein soll, sehe ich nicht so:
Vor allem wenn man zeilenorientiert arbeitet, ist die Arbeitsweise bzw. der Code fast ident mit einer DataQueuelösung.

Im Gegensatz zur DataQueuelösung habe ich immer eine leere Queue und brauche mir keine ResponseQueue "ausmachen".

Auf der Serverseite kann ich TCP-Socketserver aus jedem 2. (Java) Lehrbuch kopieren.

Aber sobald "nicht flüchtige Daten" und asynchrones Arbeiten in's Spiel kommen, sind die DataQueues natürlich die bessere Wahl./Robert

[Fuerchau]

Um mit mehreren Job's zu kommunizieren und ggf. auch zu parallelisieren kann eine Keyed-DTAQ verwendet werden.
Hierzu benötigt man dann auch nur 1 für Senden und Empfangen mit mehreren Teilnehmern.

Jeder Teilnehmer "denkt" sich eine ID aus und sendet die Anfrage an "MyRPGPgm" als Key und mit seiner ID in den Daten.
Anschließend wartet man mit dieser ID als Key auf Antwort.

Das Server-PGM wartet mit seiner Id "MyRPGPgm", arbeitet den Request ab und antwortet auf der mitgeteilten ID.

Durch mehrere Batchjob's können parallel auch mehrere Requests verarbeitet werden, die DTAQ serialisiert die Zugriffe.

Zum Aufräumen der DTAQ kann dann ggf. QCLRDTAQ verwendet werden.

[schatte]

Hallo Robert,

hast du diese APIs auch für V4R5?

Gruß
Matthias

[RobertPic]

Ich habe es weder getestet noch kann ich sagen, ob er sich beim "restoren wehrt", aber

aber laut DSPPGM und DSPSVRPGM


Niedrigstes Release für Serviceprogrammausführung: V4R2M0


/Robert

[BenderD]

das Problem dürfte eher sein, zu einem SaveFile mit TargetRelease V4R5 oder älter zu kommen.

Was die Frage Socket versus DataQ angeht:
- bezüglich Java sind mir funktionierende Socket Klassen auch lieber als der Wackelhaufen Toolbox (außer JDBC alles preBeta!)
- was RPG angeht bin ich vielleicht gebranntes Kind, ich habe mich mal dazu überreden lassen, eine humpelnde Sockets Anwendung zu analysieren (ich habe das Problem zwar gefunden, aber Spass hat das keinen gemacht). DataQs bringen halt doch ein wenig mehr mit als eine Call Schnittstelle (Error Handling, Journalisierung...) könnte man mit einem Sockets Serviceprogramm auch alles machen, aber wer macht das dann schon - oder hat das angeführte API das alles?

D*B


Ich habe es weder getestet noch kann ich sagen, ob er sich beim "restoren wehrt", aber

aber laut DSPPGM und DSPSVRPGM


/Robert

[Fuerchau]

Das ist bei Verwendung von C-Funktionen (hier Socket's) eher nicht aussagefähig.
Hier kommt es dann auf die verwendeten Prozedurimporte an, ob diese auf früheren Releases auch vorhanden sind.
Ich hatte da mit anderen C-Funktionen auch schon so meine Problemchen.

Die Angabe "Niedrigstes Release..." bezieht sich einzig und allein auf den ausführbaren MI-Code.