RobertPic
09-04-08, 21:51
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.:D
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
Das ist bei Verwendung von C-Funktionen (hier Socket's) eher nicht aussagefähig.
Ich sehe schon, ihr wollt das genau wissen.:D
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