Erfahrungsbericht IBM's freie Socket-API

[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

[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

[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.

[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?