4 Replies Latest reply on Jan 20, 2010 4:47 PM by cjrancur

    Distributed Architecture of ACE Scheduler, Manager and Wizard, and ODBC connection program configuration

    cjrancur

      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?

        • Re: Distributed Architecture of ACE Scheduler, Manager and Wizard, and ODBC connection program configuration
          hanyong

          Carrie Rancuret

          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?

          This setup would work. =)

           

          Carrie Rancuret

          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?

          I am not sure what you are referring to as "PI ACE" in this case. Ultimately, the ACE program runs on the ACE scheduler machine hence one of the steps in distributed architecture is that you need to move the dll files to the ACE scheduler machine. If ODBC DSN is configured correctly on the ACE scheduler for ACE programs to establish ODBC connection on runtime, then it should be fine

           

           

          • Re: Distributed Architecture of ACE Scheduler, Manager and Wizard, and ODBC connection program configuration
            mheere

            Hi Carrie,

             

            So let's start with the architectural terminology.  You have an ACE wizard which integrates with Visual Studio.NET on a developer workstation.  You also have an ACE scheduler running somewhere (in your case, not the development workstation) which executes the ACE calcs.  The development process is to create the ACE calculation DLL files on the developer environment, and then move them to the scheduler environment.  Part of the ACE code may be to create ODBC connections, and so the ODBC setup also needs to be replicated from the developer environment to the scheduler environment.  I think I have all that straight.  Please correct me if I've misunderstood your situation.

             

            Now, what you need to know is that ODBC drivers can be built as either 32 or 64 bit, and Windows only allows for a process to call a driver that is of the same build type - regardless of the OS build.  So, if you have a 32 bit process, you can only call 32 bit ODBC drivers no matter whether you're running on 32 or 64 bit Windows.

             

            ACE (currently) is only available as a 32 bit process, so regardless of your Windows flavor you need to make sure that you're installing the 32 bit ODBC drivers everywhere:  developer workstation and scheduler node.  Generally, 32 bit ODBC drivers install just fine on a 64 bit OS.  In fact, you can usually install both 32 and 64 bit drivers on the same server if it's a 64 bit OS.  They install to different directories, and operate independantly.  Either way, for now ACE will only use the 32 bit drivers.

             

            If there is some specific incompatibility between the 32 bit DB2 driver and 64 bit Windows OS that prevents the driver from installing or working correctly, then you probably will have to use some sort of an intermediary.  SQL Server linked server definitions are a good solution for this, but I hope it doesn't come to that!

             

            Good Luck!

             

            Matt