Möglichkeit Timeout bei ProgrammCall

[BenderD]

Hallo Robert,

ich hatte mit dem extend auf die DataQueue mehr die Zentralisierung in einem Objekt im Blick; im Grunde will eine Applikation Daten und sonst nix, es sei denn es geht was schief, dann wird eine exception erwartet; dass das ganze irgendwo durch eine DataQ durchgeknebelt wird, ist der Applikation egal.
Mit den Sockets bin ich mir nicht sicher, ob du da einen guten Tausch machst, es sei denn du schreibst den zentrale Dispatcher, der die Anfragen annimmt und verteilt in C. Wenn du für jeden 5250 Client von vornherein einen eigenen Server startest, dann gibt das einigen Overhead und Probleme, wenn so'n Ding wegschläft oder abschmiert, bei einer 1 zu n Lösung geht nix ohne Multithreading und das kann weder RPG noch Cobol auf der AS/400.
Ich würde da als Schmalspur zu einem DataQ basierten Dispatcher tendieren und den in Java schreiben. Wenn man es schick machen will, dann könnte man das ganze auch als WebService erscheinen lassen; dann kann man einen fertigen Server verwenden und braucht dann für die Clients eine schmale Schicht, die die Daten aufbereitet; dafür würde dann ein Schmalspur Parser als Adapter reichen.

mfg

Dieter Bender

Hallo

Das wäre sicher einen Tick schöner, allerdings kommt der DataQueue.read bei mir nur einmal in meinem (oft verwendeten) DataQueueListener vor.


Derzeit habe ich nur 2 Arten von Kommunikation:
1. Javajob (auf AS/400, Linux, PC) wird per DataQueue getriggert. z.B. PDF-Wandlung, neue Daten für Spedition...

2. Wenn die Daten von "Außen" kommen, z.B. XML-Datei vom EDIFACT-Konverter werden die Arbeiten vom Javaprogramm erledigt/vorbereitet (z.B. XML-Datei in die Datenbank mappen) und anschließend eine stored Procedure aufgerufen, welche z.B. die EDFIACT-Bestellung verarbeitet.

Bei den nächsten Projekten müssen viele 5250-Clients (schnell) bedient werden. Ich werde daher eine Lösung mit Sockets anstreben.

Für den Client-(ILE)-Teil gibt es Freeware von IBM, welche angeblich ganz brauchbar ist (aus RPG, Cobol... ähnlich einfach wie DataQueues).
Seit der Registrierung ist jetzt eine Woche vergangen....ich berichte dann über die "Tauglichkeit".

[RobertPic]

Mit den Sockets bin ich mir nicht sicher, ob du da einen guten Tausch machst, es sei denn du schreibst den zentrale Dispatcher, der die Anfragen annimmt und verteilt in C.

1. Die bestehenden Anwendungen bleiben. Es geht nur um "interaktive" Abfragen: fremde Datenbanken, WebService....

2. Keine Sorge, der (Socket-) Serverteil/Dispatcher ist in Java geschrieben. Ich habe schon so ein Teil laufen, um unseren externen WebServer mit Daten zu füttern.

...... wenn so'n Ding wegschläft oder abschmiert, bei einer 1 zu n Lösung geht nix ohne Multithreading und das kann weder RPG noch Cobol auf der AS/400.

Ich will ja nur den Client-Teil mit 3GL "verseuchen". Für den Client ist es ja eine 1:1 Verbindung. Die große Frage für mich ist noch, was die IBM-Freeware taugt (denke doch in C geschrieben). Ich werde berichten.

Ich würde da als Schmalspur zu einem DataQ basierten Dispatcher tendieren und den in Java schreiben.

Das entspricht weitgehend meinem Plan B, PLAN C wäre die Clientseite mit selbst mit C zu coden.

Als Vorteil der Sockets sehe ich, dass ich mich nicht um den Rückantwortkanal kümmern muss bzw. irgendwelche Daten "auseinanderklauben" muss. Ob die Vorteile überwiegen, wird sich noch zeigen....

Robert P.