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/eserve...cktclient.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 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.

[RobertPic]

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

Das ist bei Verwendung von C-Funktionen (hier Socket's) eher nicht aussagefähig.

Ich sehe schon, ihr wollt das genau wissen.


Aus der Doku:

Terms:
 OS/400 - V3R1 and above compatible.
 Y2K ready.
 Code is "as is" Type II material.
 A Programming Guide is included.
 Support and consulting time will be billed hourly if needed.

DSPSAVF:

Kennsatz der Sicherungsdatei anzeigen

Sicherungsdatei . . . . . . . . . . . : QZRDSAPI
Bibliothek . . . . . . . . . . . . . : QGPL
Sätze . . . . . . . . . . . . . . . : 500
Sicherungsoperation:
Sicherungsbefehl . . . . . . . . . . : SAVLIB
Gesichert am/um . . . . . . . . . . : 28.08.03 12:52:05
Sicherung im aktiven Zustand . . . . : *NO
Verdichtete Daten . . . . . . . . . : Ja
Release-Stand . . . . . . . . . . . : V4R2M0

Das ganze liegt mir als PC-File vor.

Was die Frage Socket versus DataQ angeht:
...eine humpelnde Sockets Anwendung zu analysieren...(Error Handling, Journalisierung)...oder hat das angeführte API das alles?

Eine komplexere Client-Socket-Anwendung würde ich (mit oder ohne API) auch ungern in einer Single-Thread-Umgebung machen.

Die API bleibt auch bei Störungen (Netzwerkkabel ziehen..) nie stecken und liefert immer nur brav Fehlernummern. Das Wichtigste: Sie hat eine funtionierenden Timeoutparameter.

Journalisierung hat sie nicht. Aber nocheinmal: Ich verwende Sockets nur für Daten, welche nur für die Anzeige bestimmt sind. Also z.B. die Ergebnisliste einer Volltextsuche. Wenn der Bildschirm abstürzt/ausfällt braucht die Daten keiner mehr.

Für viele andere Fälle (Passwortsync, LDAP-Sync, EDIFACT-Converter steuern..) verwende ich (mittlerweile via iASP gespiegelte) DataQ's.

/Robert

[schatte]

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

aber laut DSPPGM und DSPSVRPGM


/Robert

Kannst du mir das Savefile evtl. schicken oder irgendwo zum Download bereit stellen?