PDA

View Full Version : appserver4rpg dtaq auf 1024 Bytes erweitern



Seiten : [1] 2

Fuchtel
09-06-13, 12:32
Hallo miteinander,

ich hab' seit ein paar Tagen das geniale Teil Appserver4RPG von Dieter Bender erfolgreich bei einem Kunden im Einsatz. Ob mir vielleicht jemand erklären könnte, welche Stellschrauben ich denn drehen müsste, um die DTAQs auf 1024 Bytes zu ändern? Ich weiss, es gibt eine Pakettierung, aber ich würde gerne die DTAQ erweitern.

Grüsse und Dankeschön im Vorraus.

BenderD
10-06-13, 08:44
Hallo,

gegenwärtig ist keine Konfigurierbarkeit der Größe der DataQ vorgesehen und bisher ist auch noch kein Change Request in dieser Richtung an mich herangekommen. Selber sehe ich da bisher auch keine Notwendigkeit. Das zu Fuß zu machen mit aufbohren von 512 auf 1024 könnte man machen (muß im native Teil und im Java gemacht werden und das Deployment müsste angepasst werden) - von diesem Weg würde ich allerdings abraten, da dann die Kompatibilität mit den Vorversionen nicht gegeben wäre.

Wo siehst Du denn die Notwendigkeit, oder die Vorteile für das aufbohren?

D*B

Fuchtel
10-06-13, 09:58
Hallo Dieter,
sagen wir mal so: ich kann aus dem JDBCGATE.RPGLE nicht sofort erkennen, wie die Pakettierung funktioniert, dachte mir deshalb dass das Aufbohren der Größe der DTAQ einfacher wäre. Wenn Du mir vielleicht grob erklären könntest, welche Zeilen wichtig wären, würde ich die Pakettierung bevorzugen, da natürlich die Größenbeschränkung der Informationen wegfallen würde. Oder kann ich das irgendwo nachlesen?

Grüsse Fuchtel

Fuerchau
10-06-13, 10:24
Die Paketierung erfolgt automatisch, eine Größenbeschränkung gibt es nur bzgl. der SQL-Befehlslänge, die allerdings auf 32KB beschränkt ist.
Ich sehe auch keinen Vorteil in der Verlängerung der DTAQ, da diese am zeitunkritischten ist.

Welche Größenbeschränkung gibt es denn bei dir?

BenderD
10-06-13, 10:39
Hallo Dieter,
sagen wir mal so: ich kann aus dem JDBCGATE.RPGLE nicht sofort erkennen, wie die Pakettierung funktioniert, dachte mir deshalb dass das Aufbohren der Größe der DTAQ einfacher wäre. Wenn Du mir vielleicht grob erklären könntest, welche Zeilen wichtig wären, würde ich die Pakettierung bevorzugen, da natürlich die Größenbeschränkung der Informationen wegfallen würde. Oder kann ich das irgendwo nachlesen?

Grüsse Fuchtel

Hallo,

auf der unteren Schicht (JVAGATE) gibt es die procedure fireEvent, die arbeitet mit 512 Länge und ist deprecated.
Dann gibt es die fireEventP die kann 65535 und packetiert automatisch.
ArdGate verwendet die fireEventP, da braucht man nix machen, damit die packetiert, das macht die immer von selbst.

D*B

Fuchtel
10-06-13, 12:01
Hallo miteinander,

so... hab's jetzt nach Dieters Hilfe umgestellt, init(), exit(), Copystrecken, zugehörige Felder im RPG-PGM eingefügt, und auf beiden Seiten (RPG und Java) die Länge der Datenstrukturen um 300 Bytes (jetzt insgesamt über 800 Bytes Länge) erhöht, und siehe da !!! es funktioniert!!

Muchos Gracias an Dieter und natürlich auch allen anderen!!!!

BenderD
10-06-13, 12:52
... falls ich da nicht deutlich genug war:
Ich rate eindringlich davon ab an solchen Sachen rumzuschrauben, man koppelt sich damit vom Releasestand ab und macht damit jeglichen Support unmöglich - und das in diesem Fall für zweifelhaften Nutzen.

D*B

Fuerchau
10-06-13, 12:56
Trotzdem würde mich interessieren, warum du auf 800 erweitern musstest und was ohne diese Erweiterung nicht funktioniert hat.

Fuchtel
10-06-13, 13:34
Hallo miteinander,

vielleicht hab' ich mich etwas undeutlich ausgedrückt. Ich habe den Aufruf in meinem RPG-PGM von "fireEvent" auf "fireEventP" geändert, deswegen auch das Hinzufügen der init()... usw. Geschichten.

Ich hatte mich als Erstlösung (d.h. vor meinem Anliegen an Euch) an TESTGATE.RPGLE gehalten

Grüsse Fuchtel

Fuerchau
10-06-13, 13:40
Bindest du ArdGate in ein RPGLE-Programm irgendwie ein?
Irgendwie verstehe ich hier nicht, wie du ArdGate nutzt.

Ich habe ArdGate einfach installiert, einen RDBDIRE-Eintrag gemacht und nutze nur embedded SQL mit Connect.
Java-Aufrufe o.ä. benötige ich überhaupt nicht.