Until recently, we have used the ACE Scheduler, Manager, and Wizard together on a server that was dedicated primarily to ACE and to Process Control applications. For ACE input purposes and for leveraging PI Server Batch system for Process Control purposes, this same hardware platform also included a small PI server.
In order to provide cluster or HA redundancy for the PI server and PI Batch portion of this system, OSIsoft tech support has recommended that we should change our architecture and begin to use distributed architecture for ACE. The recommendation was to avoid putting the Wizard and Scheduler on the same machine as a PI server. We planned to put the Wizard on the developer's PC (mine), and put the Scheduler on another 32 bit Windows server. All three boxes, my PC, the 32 bit scheduling server, and the PI ACE data server (the new 64 bit PI Process Control server) would have an instance of the PI ACE manager installed.
Here's the question. Can we put the ACE scheduler on a 32 bit Windows machine, and configure the ODBC DSN on the machine where the scheduler resides, while still keeping the 64 bit OS on the PI ACE data server? We have found that our DB2 connections are incompatible with a 64 bit OS. If we don't have an ODBC connection that is required within the ACE vb.net program on the PI ACE, but only on the machine where the ACE scheduler runs, will the ODBC calls work? Is there a creative programming solution that might allow this distributed architecture to work? I mean, is it possible to configure the ACE programming so that ODBC calls are made from the scheduler ACE machine only, not from the ACE data server?
An earlier idea presented on another post was to use separate executables to perform ADO.net operations. Could this provide a solution? What if the ACE data server calls ODBC executables located on the ACE scheduler server? Is there a way to 1) make this remote call to another server, and 2) return the data received from this call back to ACE, without requiring use of a huge number of PI tags as an interface for returning the data? Maybe I could rewrite the ACE program to use AF data configuration under SQL Express 2005. Do you see any showstoppers with those ideas? Are they workable?
The new server was configured with a 64 bit Windows OS. Existing ACE applications use ODBC to contact an older DB2 system. Obtaining this DB2 data is essential in order to provide the basic functionality required of this server. But, the DB2 server is too old to be compatible with newer IBM 64 bit ODBC clients. Upgrade of the older IBM DB2 database server does not seem to be an option at this time.
Unfortunately, we are facing some time pressure to find the answer, since our plan was to upgrade to the newer hardware tomorrow, Jan 20. We discovered the ODBC 64 bit incompatibility yesterday.
Can anyone help me to find a workaround for this issue, something that can provide a useful work-around until others in IT can upgrade the functions of the DB2 server to a SQL server that we can access from a 64 bit OS?