Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


Announcing SDI 2021.09.3450

By Steve Ives, Posted on September 23, 2021 at 6:08 pm

Steve Ives

We are pleased to announce that a new version of Synergy DBL Integration for Visual Studio (SDI) is available and recommended for use by all Synergy developers.

As with the recent SDE release, you will notice that we have adopted a new version numbering scheme for SDI, which now uses a year.month.build# format. This change emphasizes that SDI is on a separate development timeline than SDE and that regardless of the SDE version you deploy your application with, we recommend always using the latest version of SDI, in conjunction with runtime version targeting if necessary.

IMPORTANT: In this document and in other places, the term .NET refers to Microsoft .NET 5 and higher, while the term .NET Framework refers to the original .NET Framework product through its final 4.8 version. The term .NET Core refers to the interim product which culminated with a final 3.1 release.

Installation

We improved the SDI installer so that the files deployed are compatible with Build Tools for Visual Studio 2019. This makes it easier to set up build systems supporting Synergy project builds without requiring the Visual Studio IDE.

We also added validation to the installer to ensure that both 32-bit and 64-bit Synergy/DE (Professional Series Development Environment) are installed before SDI is installed.

Synergy .NET Compiler

We added support for INITONLY properties. We added a new keyword, INITONLY, that generates an init accessor and a get accessor. If a property is INITONLY, the value of the field cannot be changed once it is created. This feature is available only when targeting .NET Core or .NET.

We added support for covariant return types. A method within an inheritance hierarchy can now be overridden with a return type that is a subtype of the return type of the virtual method being overridden. This is known as a covariant return type and can be used to avoid casting between types, which would otherwise be necessary. This can also apply to the return types of read-only properties.

We added support for default interface methods. Interface methods and properties can now have default implementations, making them similar to abstract base classes but with the added possibility of multiple inheritance. A class that implements an interface containing default implementations does not have access to those methods and properties defined for the interface unless that class instance is cast to a variable of the exact interface type.

We added support for nullable regions via a new .NULLABLE compiler directive. When used with the enable argument (i.e., “.NULLABLE enable”), this marks the start of a nullable region. When used with disable (“.NULLABLE disable”), it marks the end of a nullable region. In a nullable region, a level 3 warning error is generated if a potentially null variable, field, etc., is assigned to a non-null variable. For example, a level 3 warning will be generated if a method return value that could possibly be null is assigned to a non-null variable.

We added support for GetEnumerator extension methods. A collection that does not inherit from IEnumerable or IEnumerable<T> can now be used in a FOREACH loop if it has an extension method named GetEnumerator() that returns an IEnumerator. These extension methods can have different overloads and can be defined for an interface. Only the overload with exactly one parameter will be chosen by the FOREACH loop. That first parameter must also have the correct type (the same as the class representing the collection).

We added a new compile-time define SYN_BUILDNUMBER that can be used to access the build number of the compiler at compile time. This is also available in the traditional Synergy compiler.

Color Coding

SDI now supports syntax colorization (color coding for keywords, types, etc.) for repository schema files. By default, SDI treats files with the following extensions as repository schema files and applies this color coding to these files: .rps, .scm, .schema, .sdl, and .sch, but other file extensions can be configured.

We added support for the new INITONLY auto property, which is now treated as a keyword when it is in a property definition.

IntelliSense

We added IntelliSense support for the new .NULLABLE enable/disable compiler directives, and IntelliSense now supports the null forgive operator (!.) and the null conditional operator (?.)

Project System

Synergy .NET Core projects created with earlier versions can now be configured to target .NET 5 and .NET 6, and the SDI build, IntelliSense, and property page components now support the Synergy 12.0 Runtime and compilers.

Unit Tests

SDI now supports loading and running unit tests for Synergy .NET Core projects in the Test Explorer window, and we have added a new “Unit Test (.NET Core)” project template.

There is a known issue caused by a problem with a Microsoft component that means it is not possible to mix Synergy .NET Framework and Synergy .NET Core unit test projects in the same solution. More information can be found in the release notes.

Visual Studio Support

This version of SDI supports Visual Studio 2019 (version 16.1 or higher is recommended) with the “.NET desktop development” workload, and, as was announced previously, Visual Studio 2017 is no longer supported.

And while this version does provide Synergy capabilities in the Visual Studio 2022 Preview release, we are not yet ready to announce support for that environment. We are still in the process of testing with the Visual Studio 2022 preview versions, and there are known issues with these versions.

If you do use SDI with 2022, do let us know if you discover any issues. Note that upcoming preview versions may require SDI updates to continue functioning. At this time, please do not use Visual Studio 2022 for production code.

For more information on SDI requirements, please refer to https://www.synergex.com/synergy-dbl-integration.

Quality Improvements

As usual, in addition to the new features and enhancements detailed here, this release also includes various quality improvements. As always, please refer to the release notes for complete information.


Announcing Synergy 12.0

By Steve Ives, Posted on September 10, 2021 at 2:48 pm

Steve Ives

For the last several months the Synergy development team has been building out the features and functionality for the next version of Synergy, including the not-insignificant task of adding support for Microsoft .NET (in addition to .NET Framework) throughout the product. We are now ready to start sharing some of that work with you.

Some of you may have noticed something slightly unusual in the title of this announcement; the version number includes an even number! The complete version number of the release is 12.0.1.3272, which is also somewhat different from previous releases. We have implemented a new release strategy involving two types of releases: Long-Term Support (LTS) Releases and Feature Releases. You can find more information about that on the Synergex website.

Synergy 12.0 is a feature release, providing early access to some of the features and enhancements that will be part of the Synergy 12.1 LTS release later this year.

IMPORTANT: In this document and in other places, the term .NET refers to Microsoft .NET 5 and higher, while the term .NET Framework refers to the original .NET Framework product through its final 4.8 version. The term .NET Core refers to the interim product which culminated with a final 3.1 release.

Primary Focus of this Release

As previously announced, the primary focus of our current development is to add support for Microsoft .NET, and in some cases .NET Core, in all the places in Synergy where .NET Framework is currently supported. Some of these changes are being shipped for the first time in this release, while others will follow in subsequent 12.0 feature releases. Not all of the included changes are related to .NET; there are changes throughout the product set, as detailed below.

New Features and Enhancements

This section presents information about new features and enhancements included in this release:

.NET Support for Synergy APIs and Utilities

Several Synergy libraries and tools are now available as NuGet packages and provide support for .NET:

Library                     NuGet Package Name
Gennet Utility              Synergex.SynergyDE.gennet
Repository API Library      Synergex.SynergyDE.ddlib
UI Toolkit Library          Synergex.SynergyDE.tklib
XML API Library             Synergex.SynergyDE.synxml
xfNetLink .NET Library      Synergex.SynergyDE.xfnlnet

xfNetLink .NET

In addition to the Windows installer package, the xfNetLink .NET library is also now distributed as a NuGet package. The NuGet version of the library is built with .NET Standard 2.0 and so is usable from .NET Framework 4.7.2 and higher, .NET Core 3.1, and .NET 5 and higher environments.

The gencs utility now generates a C# project file that you can use with Visual Studio, MSBuild, or the dotnet build utility to build a client assembly. Note also that gencs no longer creates a strong-name key file by default; if you rely on this feature, you must explicitly specify a key file via the gencs -s option.

In .NET Framework applications, configuration settings were usually set in configuration files, but this is not supported with .NET Core or .NET applications. To address this, we have added several new environment variables that can be used to specify configuration settings in all environments. Refer to the release notes and documentation for a list of the new environment variables.

The COM+ pooling mechanism supported with .NET Framework is not available for .NET Core or .NET applications. As an alternative, we provide a pooling mechanism that can be implemented within your application, similar to the way that pooling worked with xfNetLink Java. For additional information refer to the Microsoft documentation for ObjectPool and use the BlockingPooledObjectPolicy class that we provide in an assembly within the NuGet package.

Synergy .NET assembly API

We added support for using the Synergy .NET assembly API in .NET Core and .NET environments, in addition to the current .NET Framework support.

The gennet40 utility continues to produce code for .NET Framework, and in addition, a new gennet utility is available from NuGet as a .NET global tool (Synergex.SynergyDE.gennet). This utility produces code for the version of .NET Core or .NET in which it is running.

Synergy Runtime Enhancements

We have added platform support for Windows 11 and Windows Server 2022 and new identifiers to allow for conditional compilation based on these new platforms.

The Synergy windowing API is now available in .NET environments.

On Windows, the data encryption routines (DATA_ENCRYPT, DATA_DECRYPT, and DATA_SALTIV) now use the Windows “Cryptography API: Next Generation” (CNG) instead of OpenSSL.

Related to our version numbering scheme changes, XCALL VERSN and %VERSN now have an optional second parameter that returns the Synergy build number.

On Linux, Synergy no longer has a dependency on the libtinfo.so.5 libraries.

Synergy DBMS Utilities

Continuing with our recent theme of improving performance when accessing ISAM files, or undertaking routine file maintenance or recovery operations, more enhancements have been made to the isutl utility that can result in performance improvements in some cases, particularly when processing very large files. Refer to the release notes for additional information.

License Manager

Linux systems can now be optionally configured to forward licensing requests to a Synergy license server on a Windows system, using TCP/IP communication. This is only supported when the license server hosts subscription licenses, and note that Linux system(s) will share the same pool of license keys available to Windows clients. Amongst several benefits is the simplification of Synergy deployment on Linux to virtualized or containerized environments, including deployment in cloud-based scenarios.

If you wish to implement IP-based licensing with existing Linux systems, you will need to work with Synergex Customer Service, as they will need to consolidate any existing Linux licenses into Windows licenses, and you will have to reset and reconfigure licensing on your Linux systems.

We have improved license server operation on UNIX and Linux systems to simplify running the license server under a non-root user account. Specifically, if file permissions prevent the license file from being written to the /usr/lib directory, it will now be written to /var/synergy instead. Additionally, if the license file is in /var/synergy, the location of the license server log file will default to the same location.

Quality Improvements

As usual, in addition to the new features and enhancements detailed here, Synergy 12.0 includes quality improvements throughout the product set. Again, refer to the release notes for complete information.

Documentation and Downloads

Documentation for feature releases will be available online only at https://www.synergex.com/docs. This website will always default to displaying the documentation for the current LTS release, but until Synergy 12.1 is released, the current default is the 11.1 documentation. To view the updated documentation for the 12.0 release, be sure to select “12.0 (feature release)” from the version dropdown.

In addition, the release notes that document everything that changed in this release can be viewed in the product downloads area of the Synergex Resource Center. Similar to the documentation, the downloads area defaults to displaying the latest LTS release, and currently defaults to displaying the 11.1 downloads. Click on the prominent red “Feature Release” button to view the downloads and release notes for the feature release.

What About SDI?

Synergy DBL Integration for Visual Studio now follows a separate development timeline and release cycle, and releases may not coincide with SDE. The SDI team has been hard at work, and you can expect an SDI release that supports Visual Studio 2019 and the upcoming Visual Studio 2022 very soon.


A New Release Strategy for Synergy

By Steve Ives, Posted on August 10, 2021 at 4:23 pm

Steve Ives

For some time now, we have been contemplating changing the way we release Synergy products. This will not be a surprise to many of you; we’ve been “testing the waters” during conversations with many of you for well over a year now, and I presented information about the likely changes in my Product Update presentation at the DevPartner conference back in May. What has changed since then is that our plans have been formalized, the changes are definitely happening, and we are drawing close to what will be the first release under the new scheme. With that in mind, it’s probably a good time to tell you all about the changes that you can expect.

Before I talk about the actual changes, let me first explain what we are trying to achieve by making the changes.

Known Release Cadence

Previously, Synergy products have not had a pre-set release cadence; we released a new version of the product when we felt a significant new functionality or change in technology justified doing so. As a result, the time between releases could vary from as little as a few months for minor releases (e.g., 9.3 in December 2009 and 9.5 in November 2010) to several years between major releases (10.1 in December 2012 and 11.1 in September 2019).

While this probably works fine for most of our “end-user” customers, it can be challenging for ISV customers that release their products on pre-determined schedules. A known release cadence will make it easier for them to plan their releases, specifically when to adopt new Synergy versions, because they will know when to expect a new Synergy release in advance.

Known Support Window

Similar to the release cadence, the support period for the current Synergy version has previously also been undefined. Our commitment has been to support the current and previous major or minor releases (currently 10.3.3 and 11.1.1), and any earlier versions are technically unsupported. By the way, in this context, “supported” refers to the versions of the product for which we will issue patches if a customer finds a serious problem, not to the ability to call the Developer Support team for assistance. Our support engineers will always try to help supported customers, regardless of product version.

Improved Stability

As our development practices became more “agile” in recent years, so did the way we released software. We got to the point where every release we published (even “patch letter” releases) typically included new or updated functionality in addition to quality enhancements. While this is great for developers who want access to the “latest and greatest” features, the strategy sometimes wasn’t great from the point of view of product stability. It’s a fact of life in software development that new or altered code means an opportunity for new bugs, but it’s frustrating if that happens in the context of a patch letter release that is supposed to fix bugs, not introduce new ones.

We have already partially addressed this issue, as I discussed in my Improving Our Internal Development Process blog post last September, but the changes we are about to make will enhance product stability even further.

Introducing Long-Terms Support (LTS) Releases

We are switching to what is referred to as a Long-Term Support (LTS) release strategy. LTS releases provide customers with a pre-defined schedule of Synergy releases that they can plan against, as well as the opportunity to deploy applications in an inherently more stable environment.

Each LTS release will contain a pre-determined set of new and enhanced features that will not change post-release. Further, the features introduced in an LTS release will have been previously made available and thoroughly tested in earlier “feature releases” (more on this later).

LTS releases provide an inherently more stable environment because of the absence of newly introduced or altered code. Although an LTS release may have subsequent updates, those updates will only contain quality improvements or security enhancements, not new functionality.

We plan to make a new LTS release available every two years, the first being before the end of this year. Synergy has many close ties with Microsoft .NET, and we will be broadly aligning our release schedule with that of .NET, which also uses an LTS strategy with a two-year cadence.

LTS releases will be labeled with a version number, an odd revision number, and an incrementing build number. The first LTS release will be 12.1.n (n being the build number). After that will be the 12.3 LTS release in late 2023, the 12.5 LTS release in late 2025, and so on. There will be no patch letter releases under the new scheme.

Each LTS release will be supported for a minimum of four years, or one year after the next LTS release ships, whichever is longer. So if you adopt the 12.1 LTS release when it ships in late 2021, you know it will be supported until at least late 2025.

Feature Releases

Of course, some developers will take advantage of LTS releases for the improved stability they offer, but others will want to get their hands on the latest and greatest features that have just been developed, and that is where feature releases come in.

Feature releases are interim releases that provide early access to new features and enhancements that will eventually become part of the next LTS release. They may include partial (but usable) implementations of new features. They will also address any quality and security issues identified within the feature release branch.

Occurring on a more frequent cadence than LTS releases, multiple feature releases may occur each year. You can think of feature releases as being more similar to the way that we have released our software in recent years.

Feature releases will typically be made available for all supported platforms, but if the changes in any release do not apply to or are not usable on a particular platform, no release will be made for that platform.

We will fully test feature releases to the best of our ability, but developers should bear in mind that quality may be lower in areas where new code has been added or significant changes have been made. Quality will solidify as developers exercise the new or updated features and as our automated test suites are extended.

The support period for feature releases will be much shorter than for LTS releases, ending three months after the next feature or LTS release.

Feature releases will be labeled with a version number, an even major revision number, and an incrementing build number. This may seem a little strange, but remember that feature releases build-up to the next LTS release. The feature releases to support the upcoming 12.1 LTS release will be labeled as 12.0.n. We’re currently in the process of putting together the first such feature release, which you may see towards the end of this month or in September.

This first release may not seem too unusual because we will be going from 11.1 to 12.0 and then to 12.1 later in the year. But shortly after the 12.1 LTS release, the first 12.2 feature release will occur (leading up to the 12.3 LTS release in 2023). For the next two years, you will see releases in both the 12.1 and 12.2 release branches, not necessarily at the same time! For example, there may be a 12.2 feature release in March, followed by a 12.1 LTS release in April!

The build number will start at 1000 the first time we build the product in a new feature release series and will increment by 1 every time we build the product, regardless of whether that build is internal, or released to customers. And the sequence of build numbers used with a feature release will carry forward to the associated LTS release. For example, if the final 12.2 feature release is 12.2.1263, then the first 12.3 LTS release might be something like 12.3.1279.

Remember that you can take advantage of runtime version targeting, which allows you to ship your products to customers (external or internal) using an earlier and stable version of the Synergy runtime (the LTS runtime) while developers use the latest feature release to build the product, enabling them to take full advantage of all of the ever-improving productivity enhancements in our Visual Studio IDE tools.

If you have any questions about anything that I have presented here, please do not hesitate to contact me via email at steve.ives@synergex.com. And if you are interested in the changes that will be included in the upcoming 12.0 feature release, watch this space—I will post about that soon.


Announcing Synergy/DE 11.1.1h

By Steve Ives, Posted on July 19, 2021 at 9:49 am

Steve Ives

Synergex is pleased to announce the immediate availability of Synergy/DE 11.1.1h on all platforms. A quality release that includes a wide range of improvements across the entire Synergy product line, and we strongly encourage all Synergy developers to review the release notes for detailed information about everything that changed.

If you are one of the many developers using Synergy DBL Integration for Visual Studio (SDI), please note that this will be the final release that supports Visual Studio 2017. From the next release, SDI will support Visual Studio 2019 as well as the upcoming Visual Studio 2022.

As we continually enhance the isutl utility for improved performance and better recoverability in system crash scenarios, we recommend that all customers using Synergy DBMS download the latest version of the Synergy DBMS Utilities package, regardless of the version of Synergy that you are currently using.

And finally, we want to point out an important bug fix that we applied to xfServer in this release: “On Windows and UNIX/Linux, a pre-version 11.1.1 client connecting to an 11.1.1 through 11.1.1g encrypted xfServer caused the connection to hang on certain functions, such as ISSTS, CLEAR, and STORE. This has been fixed in this release.”

Synergy/DE 11.1.1h is available for download in the Resource Center now.


CodeGen 5.7.3 Released

By Steve Ives, Posted on July 9, 2021 at 6:47 pm

Steve Ives

There’s a new version of CodeGen out there, so if you’re using it, here’s what’s changed in this version:

  • We added a new special structure expression token <STRUCTURE_HAS_FIELD_name> that allows you to detect the presence or absence of a named field within the structure.
  • We improved the logic used when processing unique key loops and unique alternate key loops and made a slight change to the way that the unique alternate key loops operate. Previously the loop would not compare alternate key segments with the primary key, but now it does. So the loop now processes any alternate keys that do not have identical key segments to the primary key or any previous alternate keys.
  • We fixed a problem with the implementation of the -pa command line option that would cause CodeGen to fail when used with an input file containing multiple structures.
  • We fixed a problem with the implementation of the -tweaks option which could result in a null reference exception in some rare circumstances.
  • We reviewed and updated all sample templates that ship with CodeGen to ensure they use the latest capabilities such as taking advantage of complex expressions to simplify template complexity resulting from nested expressions.
  • This version of CodeGen was built with Synergy/DE 11.1.1g and requires a minimum of version 10.1.1 to operate.

As always, this new release is backward compatible with earlier releases, so we recommend that everyone download the new version as soon as possible.


Updated Visual Studio Development Tools Update

By Steve Ives, Posted on March 29, 2021 at 10:44 am

Steve Ives

Synergex is pleased to announce the immediate availability of a new release of the Synergy DBL Integration for Visual Studio, Version 11.1.1g-3045.

As always, this latest release contains improvements across the board, but in particular, the focus was placed on these specific areas:

  • Improving the development experience in both the editing and debugging of .NET Core code.
  • Improvements in working with Repository projects in various scenarios.

Some of the improvements in this release were actually in the Synergy .NET Compiler, so in addition to updating the SDI installation, developers working on .NET Core projects (including any Harmony Core projects) should upgrade the version of the Synergex.SynergyDE.Build NuGet package used in the projects to version 11.1.1070.3045 also.

We encourage everyone undertaking any type of Synergy development in Visual Studio to upgrade to this new release as soon as possible. And remember, if you are not ready to upgrade the runtime versions on your production systems yet, you can use runtime version targeting to give you access to the latest-and-greatest development tools while continuing to support older runtime installations.

Head on over to the Resource Center Downloads page to download the new release now.


CodeGen 5.6.9 Released

By Steve Ives, Posted on March 11, 2021 at 8:10 pm

Steve Ives

We are pleased to announce another release of CodeGen, once again including some significant advances in the technology. We recommend that all developers using CodeGen, and especially developers working with Harmony Core, should upgrade to this latest version as soon as possible. This new version includes these changes and enhancements:


Announcing Synergy/DE 11.1.1g

By Steve Ives, Posted on February 26, 2021 at 3:33 pm

Steve Ives

Synergex is pleased to announce the immediate availability of Synergy/DE 11.1.1g, a quality release that includes a wide range of improvements across the entire Synergy product line. We strongly encourage all Synergy developers to review the release notes for detailed information about everything that changed.

Besides a significant focus on quality, we have also made several feature enhancements in our Visual Studio integration tools, enhancing the developers’ experience and improving their productivity.

First off, we have introduced collapsible-region support for many DBL statements and other language constructs. For example, some of the now collapsible statements include BEGIN-END blocks, USING-ENDUSING, CASE-ENDCASE, IF-THEN-ELSE statements, and more. This feature was specifically requested and voted on by developers in the Synergy Ideas Forum.

We also added support for activating the go-to-definition feature via mouse clicks, in addition to using the existing keyboard shortcut-based mechanism. The default behavior is activated via Ctrl + Left-Click but is customizable in the Tools/Options dialog under Text Editor settings.

Another area that we focused on is improving the accuracy of those “red squiggles” that show up in your code when something is wrong and occasionally when something is not wrong! Inaccurate red squigglies should occur less frequently now, although we do know that have some additional work still to do in this area.

To give developers more options when they need to get in quickly and look at something specific, especially in solutions with large numbers of projects, we also implemented support for Visual Studio 2019’s “Filtered Solution” feature that allows you to check a “Do not load projects” option in the Project Open dialog. Visual Studio opens the solution very quickly when you do this, but all projects are in an unloaded state. The developer can then select the projects they wish to work on in Solution Explorer and use the “Reload Project” context menu to load them. The context menu then includes options to allow you to load either direct dependencies or all dependencies of the projects you loaded, meaning that you can quickly get to a buildable scenario without having all projects loaded. Solution Explorer also has options to show or hide unloaded projects.

Having filtered your solution the way you want it, you can then use the “Save as Solution Filter” context menu to save the state of your solution for the next time you need it that way. The file is saved as a .slnf file and can be reopened the same way you open the solution.

We have overhauled our project build system, reduced memory usage, and improved performance for Visual Studio and command-line builds. And at the same time, we have improved and standardized the way they interact with MSBuild, allowing us to adopt new features more quickly.

And armed with our new MSBuild capabilities, we added support for a new feature known as /graphBuild, making pre-build analysis of inter-project dependencies work much more effectively. In turn, MSBuild can now more effectively perform parallel builds of multiple projects simultaneously, in some situations resulting in improvements in overall build time.

We are confident that most developers should experience improvements in overall build times across the board, particularly for traditional Synergy projects. And in some cases, with the right combination of projects and resources, those improvements could be significant.

For example, suppose you have a small number of base libraries used by a large number of higher-level projects. In that case, once those base libraries have been built, there is a good chance that higher-level projects can build in parallel, with the overall process completing more quickly. The more CPU and memory resources that are available, the faster things can proceed. In some environments, such as on dedicated build servers running CICD pipelines, we have seen improvements of up to 30 – 40% in overall build time as compared to the previously released version. But improvements of that order do require access to considerable resources; most improvements will be more modest.

If you’re already using Visual Studio to develop your Synergy code, we encourage you to upgrade to this new version as soon as possible; remember, you can always use runtime version targeting if you’re not ready to upgrade your production systems. And don’t let the fact that you only develop traditional Synergy code or deploy to Unix, Linux, or OpenVMS deter you; Visual Studio can make a great development environment for those scenarios too! Talk to your Synergex account representative for more information.


CodeGen 5.6.6 Released

By Steve Ives, Posted on February 5, 2021 at 3:05 pm

Steve Ives

A quick post to announce the availability of CodeGen 5.6.6.  This is a quality release that addresses an issue that could occur when generating code from templates containing certain complex expressions. In particular, several Harmony Core templates contain such complex expressions, so we recommend that all Harmony Core developers upgrade to this new version of CodeGen at their earliest convenience. As always, documentation for this new release can be found at https://codegen.synergex.com.


CodeGen 5.6.5 Released

By Steve Ives, Posted on January 24, 2021 at 11:13 pm

Steve Ives

I am pleased to announce the release of a new version of CodeGen, and this release is quite a big one. The changes include the following:

This version of CodeGen was built with Synergy/DE 11.1.1f and requires a minimum of version 10.1.1 to operate.

We recommend that all CodeGen users upgrade to this version, particularly if you are doing Harmony Core development. You can download the new version from GitHub.


SQL Replication Enhancements

By Steve Ives, Posted on December 4, 2020 at 3:21 pm

Steve Ives

For several years now, Synergex has maintained an open-source example that provides an example of how to implement the replication of a Synergy applications data to a Microsoft SQL Server database, in near-to-real-time. The example environment makes considerable use of CodeGen to generate the bulk of the code needed to implement the interaction with the SQL Server database, and much of the remaining required code can be used out-of-the-box, requiring very little, if any change to the original Synergy application to enable the data replication to take place. The example environment has been used as a template by many customers, and our Professional Services team has assisted many others by delivering either proof of concept examples, or full-scale implementations.

As technologies and product capabilities evolve, we periodically revisit the code to ensure that it is taking advantage of the latest features and adhering to best practices. Good performance is also of critical importance in products like this, so we frequently revisit the code looking for opportunities to make improvements in throughput.

We have just completed the latest review of the code, and on this occasion, we did make some changes, which are briefly described below.

  • We now generate an additional function that returns the key number of the first unique key for each ISAM structure. This allows us to avoid the need for code that previously detected the first unique key number at runtime; that code required that the replicator had an open channel to each data file being replicated.
  • We also generate an additional function that, when passed a record containing data, returns the key value of the first unique key. Previously, the code used the Synergy routine %KEYVAL for this purpose, but it also requires that the replicator has an open channel to every data file replicated.
  • Because of the previous two changes, we were able to remove the replicator’s requirement to open the underlying data files that are being replicated. The only files that the replicator now opens are the instruction queue file and log file.
  • We added code to make the replicator more resilient to interruptions to network connections when using xfServer to access the instruction queue file on a remote system. If a network problem is detected, the replicator now closes the instruction queue file and then attempts to re-open it on a new channel. If this operation fails, it will retry several times with a delay between attempts. The number of retries and the delay between retries are both configurable via command-line options or environment variables.

If you already have a SQL Replication environment based on our sample environment, then you might consider checking out the latest version and applying the changes to your own codebase, and if you’d like some help with that, then our Professional Services team will be happy to assist. And if you haven’t yet implemented a SQL Replication environment but are interested in doing so, get in touch with your Synergex account rep and ask them to set up a demo.


Announcing Synergy/DE 11.1.1f

By Steve Ives, Posted on September 22, 2020 at 2:11 pm

Steve Ives

We are pleased to announce the release of Synergy/DE 11.1.1f. This is a quality improvement release available immediately on all Synergy-supported platforms. Please refer to the release notes f0r important information on issues addressed by this release.

Amongst other things, this release addresses several issues relating to running xfServer with encryption enabled. This is a configuration that we highly recommend for all xfServer deployments. If you are doing so and are running an earlier version of Synergy 11, we encourage you to upgrade your server and client systems to 11.1.1f.


Improving Our Internal Development Process

By Steve Ives, Posted on September 21, 2020 at 11:21 am

Steve Ives

We’re about to release another version of Synergy, and when we do you may notice that we’re not documenting any new features in the release. This is an intentional change, and I wanted to let you know about it ahead of time.

In addition to working on Synergy/DE, our development teams are also working on re-organizing many of our internal systems, tools, and practices. We’re centralizing almost all of our development around Microsoft Azure DevOps; we’re consolidating all version control on Git (currently, depending on the product area and platform, we also use PVCS and Subversion), we’re making extensive use of CICD principles and tools to build automated build and test pipelines for all aspects of the product, and much more.

The only exceptions to this are our open source products, CodeGen and Harmony Core, which will remain in their current locations on GitHub. This will be an on-going process extending well into 2021 and, when complete, will put us in a great position to be able to return our focus entirely to Synergy/DE within a modern, highly efficient and productive development environment.

And as part of this reorganization of our environment, tools and practices, we have also made some decisions about how we’re going to release changes to the Synergy/DE products. For the core Synergy/DE runtime products, we have decided to revert to our earlier practice of only releasing quality improvements in patch releases; new features will be released less frequently, in numbered product releases. There are some other changes coming down the pipeline, but we’re still fleshing out some of the details, we’ll let you know as soon as things are firmed up.

This decision applies to the runtime products only, not to the development tools; you will still see regular releases for the Visual Studio-based development tools (and maybe more) in the near future. And development and releases of CodeGen and Harmony Core will continue as normal.


Migration to New Downloads Site Completed

By Steve Ives, Posted on August 14, 2020 at 2:40 pm

Steve Ives

Back in June, I announced the launch of a new product downloads site, which at the time provided access to all of the Synergy 11 downloads, and that downloads for earlier versions would be migrated over the coming months. I am pleased to announce that process is now complete and that the downloads for products all the way back to Synergy 7.1 are now available from the new site and have been removed from the old resource center.

The old download pages also included downloads for the Synergy V6 products but, because the way the software was distributed was so different back then, we decided not to migrate those old versions to the new site. For now, the version 6 files can still be downloaded from the old resource center, and we will make those files available via some alternate mechanism before that site is eventually decommissioned.


Announcing Synergy/DE 11.1.1e

By Steve Ives, Posted on July 14, 2020 at 2:04 pm

Steve Ives

Due to the discovery of a potentially serious issue in the 11.1.1d release of Synergy/DE, we have decided to withdraw that release on Windows and UNIX platforms and replace it with 11.1.1e, which is now available.

To understand the issue, it is first necessary to understand that enabling compression on a data file can, in rare cases, result in a small increase in the size of some records! This can only occur if the data in a record is not compressible, yet the compression itself adds a small overhead.

It was found that when reading records from a compressed file, by RFA, any records exhibiting this “negative compression” would have one byte of bad data returned at the end of the record.

11.1.1e includes new versions of Synergy/DE 32-bit and 64-bit for Windows and Unix platforms, and Synergy DBL Integration for Visual Studio (build #2769).

We strongly recommend that anyone who has updated to Synergy/DE 11.1.1d on the affected platforms should immediately upgrade to 11.1.1e.

As we needed to release a new version to address the READ by RFA issue, we decided to also include several other quality improvements that had already been completed.

Synergy/DE Runtime

(Windows) In 11.1.1d, when using SYN_RESIZE_SCALE or having a monitor DPI change, some .NET controls would fail to repaint if the application moved between monitors of different DPI or scaling.

Traditional Synergy Compiler

A global structure with the same name as a subroutine no longer causes a segmentation fault when loading prototype files when there are different prototype files for the global structure and the subroutine.

Synergy Configuration Program

We addressed an issue in rsynd that was causing the SynConfig utility to fail with a “Could not complete services import” error when specifying a user account during service import.

Synergy DBMS

We enhanced the isutl utility when recovering change tracking files with bad change tracking links, and the utility no longer crashes if certain wildcard file operations are attempted.

Visual Studio Build System

We fixed an issue in the incremental build feature in SDI 11.1.1d-2749 through 11.1.1d-2763 that caused full project builds to occur when only partial builds were necessary for projects using common.props and with non-Synergy references.

We fixed an issue that prevented low-level libraries in Synergy .NET Core solutions from automatically rebuilding when an output file was missing.

Visual Studio Property Pages

We fixed an issue that prevented Visual Studio settings imported from a file from working until a Synergy DBL option page (Tools > Options > Text Editor > Synergy DBL > …) was opened.

We fixed an issue with Synergy .NET Core and .NET Standard projects that prevented SDI from resolving known MSBuild properties used for pre-build and post-build events.

For additional information and tracker numbers associated with each of these items, please refer to the release notes.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives