As Windows XP is no longer available as of June 30th, I’d like to talk about your options regarding Synergy/DE support for Windows Vista.
While Microsoft may have pulled the plug on Windows XP as of June 30, it still continues to offer the home version for ultra low end PCs that can’t run Vista. However, if you go to Dell or HP, you won’t be able to select XP for a new system. Manufacturers can continue to sell XP while “stocks last” but in today’s highly evolving marketplace, who would stock XP just in case someone might buy it one day? Further, volume license customers can’t purchase XP licenses any more—the only way for a business customer to get it is to buy Vista Enterprise and downgrade to XP.
So, where does that leave Synergy/DE customers sitting on the fence and using versions of Synergy/DE prior to 9? Well, as of July 1, the supported route is to upgrade to version 9. Any new machines your customers/users buy will be running Vista, which means you need version 9 for that user (if you want to deploy a supported version). We just shipped our latest version in the 9 series, version 9.1.5, which we recommend using.
So what do you do if you want to use Vista and Server 2008 but your installed base is using 8.3.1# and you don’t want to upgrade them all at once? We have customers who have been accomplishing all of this successfully by continuing to build their .dbr and .elb files with 8.3 and then running those 8.3-built files under Synergy/DE 9. In the rare documented cases where version 9 finds an issue not present in 8.3 (e.g., the new duplicate global data section of differing sizes), the issue can be fixed back in the 8.3 code base producing a .dbr that runs perfectly on both 8.3 and 9. This same technique should be used if you are requiring a hotfix for a problem in 8.3. Synergex’s policy is to provide Synergy/DE 9 for deployments of the fix rather than an 8.3 patch.
Now you may ask, what about development? We still recommend you use the latest version 9 tools to build and develop your applications (so you can take advantage of improved error detection and increased developer productivity), but you can rebuild the tested .dbr files under 8.3 for mass deployment.
Given that the XP era has ended, I recommend that all ISVs test their current pre-9 applications under Synergy/DE 9.1.5 so they can be assured of continued customer satisfaction when the inevitable Vista machine is encountered. I also recommend that all new customer installations be V9 throughout, or at least adopt the built-under-8.3-deployed-under 9 model described above.
In my last post, I talked about some issues with Windows Server 2008 and Vista SP1 that caused me to recommend not upgrading to them yet. These issues represent just one example where an operating system problem might hinder performance for our customers.
In another example, we recently had a customer report that it was taking our SQL OpenNet server 20 times longer to retrieve records from a SCO OpenServer 6 or UnixWare system than from SCO OpenServer 5.0.6. We tracked this down to a bug in the SCO implementation of the Nagle algorithm on the TCP/IP stack. We produced a simple C program that was sent to SCO and a fix is pending.
While we were able to assist the customer in the above situation, this isn’t always the case. We try hard to reproduce operating system and other layered product problems with our support team even when Synergy/DE is not at fault, but we unfortunately can’t support every OS and product in the field. There is an increasing need for our ISVs and end customers to maintain software support contracts with the vendors they work with to solve problems.
In many cases the problems we come across are third-party interaction issues (like virus scanners) and configuration issues with the OS that are beyond the scope of Synergy/DE support. A prime example of this is the use of operating system virtualization, where Synergy/DE is supported on the target OS, and the virtualization software acts as a hardware layer underneath the OS. As we have found out, Microsoft will not entertain any calls being logged if the problem is not reproducible in a non-virtual environment. So just as the device drivers of a server require a maintenance contract with the hardware supplier, so the use of virtualization software requires the same (effectively hardware) support contract with the virtualization supplier.
So I recommend you evaluate the level of support you may need for your non-Synergy/DE products and then obtain the appropriate support contracts.
It’s been some time since I posted. We’ve been busy with our 9.1.3 release, which has some great new .NET interop features and more flexible xfNetLink .NET client capabilities. I’ve also had some international travel.
Windows Server 2008 and Windows Vista SP1 have now shipped. (9.1.3 was tested with both). Both use an identical code base and identical DLL and kernel versions – which is great for maintainability.
Unfortunately it appears that these operating systems are 40% slower at file write operations than Server 2003. This means that writing out a log file or update/insert/delete operations to Synergy databases is therefore 40% slower than Server 2003. This can only be seen when using large files because the average commercial application does small blocks of random I/O. One of our customers provided a Synergy test program and a C# .NET test program that showed significant differences in time taken. We looked into the differences and re-coded the C# program to use the same WriteFile() win32 API that the Synergy Runtime uses, and the C# program also shows the same degradation that the Synergy Runtime shows. The issue has been logged with Microsoft support to get a resolution.
Why does this matter? Well, several things are affected on a large file server:
- Throughput as the number of users increases
- Time taken to write large log files
- Time taken to create work files and rebuild Synergy DBMS databases
- Time taken to sort files
At this time I would recommend not moving to the new servers until Microsoft has had time to fix the performance degradation.
Now you might ask why the initial C# program ran faster. Synergy/DE has never buffered files opened with “O:S” mode, because on VMS we can’t (each record is a separate RMS record) and on Unix and prior Windows operating systems, buffering has had minimal if any performance gain – that was the job of the operating system. It turns out the newer Windows operating systems have significant overhead, so we will look into some buffering for a future release for both the runtime and the compiler. (The linker and librarian and isutl all perform large block I/O).
As applications move forward, they support only newer versions of third-party software and remove support for older versions. It’s not really surprising; it’s all to do with QA and being able to take advantage of newer functionality.
There is one area in particular of the Synergy/DE toolset that is constantly moving forward to support newer 3rd party tools, with extended functionality and in some cases bug fixes – and that’s xfODBC. With the newer technologies like ADO.NET and new client tools that use it, we had to enhance many parts of the whole stack to support ADO .NET properly. This means that if you try to use years old versions of Synergy/DE with current 3rd party tools, it most likely won’t work, or at the very least performance won’t be great. If you expect current technologies such as SQL Server reporting tools, Visual Studio 2008, or Office 2007 (Excel) to work with xfODBC, you/your customers really must be using the latest versions of Synergy/DE. Synergex is really no different than Oracle or SQLServer in this regard. We make constant improvements to our optimizer, just like the other database vendors – and these changes can provide dramatic improvements in ad hoc query performance with Synergy databases.
Vista support is another area that requires you to stay current. Just like most 3rd party software was enhanced to work with Windows Vista, so was Synergy/DE. We had significant work to do to ensure we worked well with Vista and its whole UAC mechanism and to ensure both install and uninstall worked well. I don’t really understand why someone would try to run an older 8.3.1 or 8.1.7e version of Synergy on this newer platform – I understand that there is testing to do with application compatibility, but now that Service PAK 1 is ready to roll, businesses will start to move over more quickly. Our customers have been successful using 9.1.1b as the deployment platform for Server and Vista, with the clients and the .dbr files still using 8.3.1. Any fixes required to allow 8.3.1/9.1.1 co-existence can be made to be compatible with both while compiling under 8.3.1; however, unless there are bugs in original code, this is extremely rare.
In conclusion, if a company (or an ISV’S customers) wants to keep current with newer, rapidly changing technology, the base technology (Visual Studio, Synergy/DE) must be current as well.