PDA

View Full Version : iSeries Access API für Windows 64Bit



Sysprog
26-03-11, 17:45
Hallo,

ich beschäftige mich nur sporadisch mit iSeries-Programmierung. Solange ein Kunde das wünscht.

Wir haben bei einem Kunden seit Längerem erfolgreich eine .NET-Software unter Windows 32Bit laufen, die mit iSeries Data-Queues kommuniziert, und zwar direkt über die API der CWBCO.DLL (cwbCO_CreateSystem() etc.) und CWBDQ.DLL (cwbDQ_OpenEx() etc.).

Der Kunde möchte nun auf Windows 64Bit umstellen. Dazu hieß es aber von Seiten IBM, daß die CWBDQ.DLL als 64Bit-Variante verfügbar ist, nicht aber die CWBCO.DLL. Diese benötigen wir für eine ordentliche Anmeldung mit Username und Passwort.

Das ist für mich nicht plausibel. Wieso sollte man ausgerechnet die für die Anmeldung benötigte DLL weglassen. Und wieso werden nicht alle DLLs als 64Bit-Variante angeboten. Hat dafür jemand eine Erklärung?

Um Aufwand zu sparen, möchte der Kunde die Software nun weiter im 32Bit-Modus betreiben. Fragt sich, wann es an anderer Stelle ein Problem geben wird.

Fuerchau
28-03-11, 07:40
Auch in .NET gibt es über einen Umweg die Möglichkeit, 32-Bit und 64-Bit zu mischen.
Dazu muss man nur den 32-Bit-Anteil in eine ActiveX.EXE als "Out of Process"-Server realisieren.
Einfach eine EXE-Anwendung (für x86 markieren) schreiben, die Klassen als "für COM sichtbar" definieren.
Die Funktionsaufrufe starten dann die externe Anwendung, der Rest kann dann in 64-Bit laufen.
COM kommuniziert dann zwischen den Anwendungen über Windows-Messages, so dass es egal ist, ob der Aufruf von 32 nach 64 oder 64 nach 32 ist.

Sysprog
28-03-11, 19:58
Auch in .NET gibt es über einen Umweg die Möglichkeit, 32-Bit und 64-Bit zu mischen. ...

Das wußte ich nicht. Danke für die Info, ich werde es als Möglichkeit berücksichtigen.

Bislang habe ich es nur mit einen vorhergehenden Aufruf von CWBLOGON geschafft. Aber ich scheue bisher den Aufwand, diese Krücke in einem Windows-Dienst auszuprobieren, wo es laufen soll.