Ensuring your development won’t be affected

Synergy/DE version 10 is coming soon. Along with the changes to support Rev 6 ISAM, Windows 8, multi-user Repository, and other new features, we’ve made some less newsworthy changes that could be just as important to your development as your upgrade to version 10.

These changes relate to the version number itself: 10 is our first two-byte version number. To prepare for this, we began analyzing our source code and published APIs over a year ago to identify changes we would need to make and changes you might need to make, depending on your use of Synergy version number strings. And in Synergy/DE 9.5.3, we enhanced our APIs to enable you to start making any necessary changes well in advance of the version 10 release. Use the information in this article to help you determine if the transition to a two-byte Synergy version number will affect your development.

During our analysis phase, we made sure that buffers used for version numbers were long enough to store two-byte versions, and we identified places where strings were compared against the version. Because our version strings are stored left-justified, we updated some version strings to use alphabetic letters for version 10 and higher, which ensures that string comparisons will continue to work as expected in deployed applications. For example, the compiler version defined by SYN_VER is A.1.1 for version 10. (If we instead changed it to 10.1.1, comparing this to 9.5.3 would result in 9.5.3 being evaluated as higher.) And because you may be passing SYN_VER to U_CHECKVERSION, U_MINVERSION, or U_PARSEVERSION, we modified these routines in version 10 to handle both digits and letters so that deployed code won’t break. Moving forward, however, we recommend that you modify your code to instead use a new define, SYN_VERSION, which is one byte longer. (SYN_VER and SYN_VERSION are defined in the distributed dbl.def file.)

Similarly, we updated the version argument to U_VERSION to return A.1.1 for version 10. And in 9.5.3 we added a second argument that allocated leading space (e.g., “ 9.5.3”) in preparation for version 10. We also made the first U_VERSION argument optional, so you don’t have to obtain both formats to get the new one. Be sure to update your code to use the new U_VERSION argument if needed.

If you use the Repository Subroutine Library and use the repository version ci_ver (in ddinfo.def) in a string comparison, you may need to change your code. In version 10 the ci_ver string starts with 1, so deployed applications could break since string comparison logic will not evaluate as expected. We recommend you modify your code to use U_PARSEVERSION instead.

For U_PARSEVERSION, note that if you pass a d1 for the version number argument, the return value will be truncated in version 10. We recommend passing an integer instead.

Finally, %VERSN returns the Synergy runtime version in a text string (e.g., “DBL/MS Windows Version v.r.m”). If you have code that parses the string for the version number and then uses the number in a string comparison against an earlier version, you may need to make changes to your comparison logic before moving to version 10.

We recommend that you review all logic in your application related to Synergy version strings before upgrading to version 10. Following the above recommendations now will help ensure that your transition to version 10 is a smooth one.