800.366.3472 Support

Get Support

Documentation

Resource Center

Synergex

Synergex Blog

A New Release Strategy for Synergy

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

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.

Permalink • Leave a comment (no comments)
Tags: Synergy/DE

Announcing Synergy/DE 11.1.1h

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

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.

Permalink • Leave a comment (no comments)
Tags: Linux, OpenVMS, Synergy/DE, UNIX, Visual Studio, Windows

Updating Synergy/DE production licenses to REV11 licensing / Jan. 1 requirement

By Cindy Limburg, Posted on October 28, 2020 at 11:44 am

Last month we announced via email that starting January 1, all new and renewing production subscription licenses will need to use REV11 licensing. (The announcement is also on our website and in our Oct. 1 Synergy-e-News.) We’ve gotten a few questions about this, so I wanted to provide some additional information. This info is also in the FAQ on our website, and we’ll continue to add to that site as new questions come in. This information applies to customers with Synergy/DE 9.5.3b – 10.3.3 on supported Windows and Unix platforms. [Note that the minimum version was updated from 9.3.1 to 9.5.3b on 1/27/2021.]

What’s the requirement?

After January 1, 2021, when you renew any 9.5.3b–10.3.3 subscription licenses on currently-supported Windows or Unix systems, those licenses must be on REV11 licensing. You will need to update them to REV11 licensing before their renewal dates. Also, new 9.5.3b–10.3.3 licenses will be issued with REV11 licensing on these platforms.

This requirement does not apply to licenses lower than 9.5.3b, to licenses on OpenVMS or retired Windows/Unix systems, or to traditional (non-subscription) licenses. See our platforms page for information about supported platforms. If your platform is on the Retired Platforms list (meaning current Synergy/DE versions are not supported on it), REV11 licensing is not available on it. If you’re not sure if a license is subscription, you can run the lmu utility to see if the license has an expiration date. (After each product, it specifies the date the product was licensed and if subscription, the date the subscription expires.) Although REV11 licensing will not be required for traditional (non-subscription) licenses, we do recommend it for those licenses. One benefit there is that when you add users, your keys will be automatically updated.

Why is Synergex requiring this?

REV11 licensing has been out since October 2019. It has been required for DevPartner (development) licenses, and many customers have also updated their production licenses to it. It’s important that we get the rest of the production licenses updated this coming year as it will make managing licenses much easier for you and for Synergex.

What else should I know?

REV11 licensing does not change how your application accesses licenses on your license server; it mainly provides a new mechanism for getting and installing product keys. Once your application is set up with REV11 licensing and the keys are downloaded and installed, the licensing on your system works pretty much the same as it did previously. What’s new is that your license server will now communicate with the Synergy License Web Server periodically (once/week initially) to poll for new license data. (If there is ever a problem connecting to the Web Server, that will be logged, and you and Synergex will be notified.)

You will be able to check the connectivity between your license server and the Synergy License Web Service before you install REV11 licensing (with our lmcheck utility).

When you update to REV11 licensing, you’re not updating to Synergy/DE version 11. We realize that the name “REV11 licensing” makes this a little confusing, but REV11 licensing is just the current revision of Synergy/DE licensing, and it’s for Synergy/DE 9.5.3b and higher versions.

If your application has code that processes the Synergy/DE license registration string, you will probably need to update that code because the size of the registration string increased from 12 alpha characters to 31. We’re aware of a very small number of customers who came across this as their applications use the SERIAL routine, which returns the registration string. We’re recommending that all customers search their code for calls to the SERIAL routine. For example, do a case-insensitive search for just SERIAL and look for instances of “xcall SERIAL” (in case there are tabs/spaces/returns between the words). See this topic in the FAQ for more info.

If you use the Synergy/DE Licensing Toolkit, be sure to get the latest License Key Generator from Customer Service. And if your code processes the registration string, you’ll probably have to update it to handle the larger string size. See more details for this topic in the FAQ.

Should I be using the Licenses site in the Synergex Resource Center to manage my licenses?

Yes! Make sure you are fully utilizing the features on this site. There you can take care of many of your license tasks, including generating keys and generating REV11 install codes. Doing these tasks yourself instead of contacting Synergex Customer Service is better for you since the site is available whenever you need it, and it’ll free up our Customer Service team to assist customers with tasks that they can’t do themselves.

If you don’t yet have a Resource Center account, go to the Resource Center and click Create Account in the top right corner. Your company should have at least one Site Admin who can access your licenses and also control access to your Resource Center privileges. If you need to add any Site Admins, contact Customer Service.

How should I prepare for the 2021 REV11 licensing requirement?

Make sure you’re set up to manage your licenses in the Resource Center. (See above.)
Check to see if your application is using the SERIAL routine or the Licensing Toolkit and if so, address those accordingly. (See above.)
Determine which of your licenses will require REV11 licensing and when they renew. You can view your licenses in the Resource Center, show only Subscription licenses, and sort by End Date. It shows which licenses are already using REV11 licensing. You can click on a license to see if it’s a major version (e.g., 9 or 10). For v9 licenses, you can run LMU on your version 9 systems to determine if they are 9.5.3b or higher.
Make plans to update your licenses to REV11 licensing before the month they renew so the keys will be automatically updated when Synergex processes your renewal.
Review the information and instructions on the Synergex REV11 website and in the documentation for Windows or Unix.

Thank you for your efforts to update your licenses. Please let me or your account executive know if you would like any assistance in preparing for your updates.

Permalink • Leave a comment (no comments)
Tags: licensing, rev11, synergex, Synergy/DE

Old Dog … New Tricks … Done!

By Steve Ives, Posted on June 3, 2015 at 3:59 pm

The old adage tells us that you can’t teach an old dog new tricks. But after the last three days, I beg to differ! It’s been an interesting few days for sure; fun, challenging, rewarding and heated are all words that come to mind when reflecting on the last few days. But at this point, three days into a four-day engagement, I think that we may just have dispelled that old adage. For one this “old dog” certainly feels like he has learned several new tricks.

So what was the gig? It was to visit a company that has an extensive application deployed on OpenVMS, and to help them to explore possible ways to extend the reach of those applications beyond the current OpenVMS platform. Not so hard I hear you say, there are any number of ways of doing that. xfServerPlus immediately comes to mind, as do xfODBC and the SQL Connection API, and even things like the HTTP API that could be used to allow the OpenVMS application to do things like interacting with web services. All true, but there was one thing that was threatening to throw a “spanner (wrench) in the works”. Did I mention that the application in question was developed in COBOL? That’s right, not a line of DBL code anywhere in sight! Oh and by the way, until about a week ago I’d never even seen a single line of COBOL code.

Now perhaps you understand the reason that challenging was one of the words I mentioned earlier. But I’m up for a challenge, as long as I think I have a fighting chance of coming up with something cool that addresses a customers needs. And in this case I did. I didn’t yet know all of the details, but I figured the odds of coming up with something were pretty good.

Why all of this confidence? Well, partly because I’m really good at what I do (can’t believe I just said that), but seriously, it was mainly because of the fact that a lot of the really cool things that we developers just take for granted these days, like the ability to write Synergy .NET code and call it from C#, or write VB.NET code and call it from Synergy .NET, have their roots in innovations that were made 30+ years ago by a company named Digital Equipment Corporation (DEC).

You see OpenVMS had this little thing called the Common Language Environment. In a nutshell this meant that the operating system provided a core environment in which programming languages could interoperate. Any language that chose to play in that ball park would be compatible with other such languages, and most languages on OpenVMS (incuding DIBOL and DBL) did just that. This meant that BASIC could call FORTRAN, FORTRAN could call C, C could call PASCAL and … well you get the idea. Any YES it means that COBOL can call DBL and DBL can call COBOL. OK, now we’re talking!

So why is this such a big deal? Well it turns out that Digital, later Compaq, and later still HP didn’t do such a great job of protecting their customers investments in their COBOL code. It’s been quite a while since there was a new release of COBOL on OpenVMS, so it’s been quite a while since OpenVMS COBOL developers had access to any new features. This means that there isn’t a way to call OpenVMS COBOL routines from .NET or Java, there isn’t a way for OpenVMS COBOL code to interact with SQL Server or Oracle, and there isn’t an HTTP API … so don’t even think about calling web services from COBOL code.

But wait a minute, COBOL can call DBL … and DBL can call COBOL … so YES, COBOL CAN do all of those things … via DBL! And that fact was essentially the basis for my visit to Toronto this week.

I’m not going to get into lots of details about exactly what we did. Suffice it to say that we were able to leverage two core Synergy/DE technologies in order to implement two main things:

A generic mechanism allowing COBOL code executing on OpenVMS to interact with Windows “stuff” on the users desktop (the same desktop that their terminal emulator is running on).
A generic mechanism allowing Windows “stuff” executing on the users desktop to interact with COBOL code back on the OpenVMS system.

The two core technologies have already been mentioned. Outbound from OpenVMS was achieved by COBOL calling a DBL routine that in turn used the Synergy HTTP API to communicate with a WCF REST web service that was hosted in a Windows application running in the users system tray. Inbound to OpenVMS was of course achieved with a combination of xfNetLink .NET and xfServerPlus.

So just who is the old dog? Well as I mentioned earlier I probably fall into that category at this point, as do several of the other developers that it was my privilege to work with this week. But as I set out to write this article I must admit that the main old dogs in my mind were OpenVMS and COBOL. Whatever, I think that all of the old dogs learned new tricks this week.

It’s been an action packed three days but I’m pretty pleased with what has been accomplished, and I think the customer is too. I have one more day on site tomorrow to wrap up the more mundane things like documentation (yawn) and code walkthroughs to ensure that everyone understands what was done and how all the pieces fit together. Then it’s back home on Friday before a well deserved vacation next week, on a beach, with my wife.

So what did I learn this week?

I really, really, REALLY don’t like COBOL!
OpenVMS was WAY ahead of its time and offered LOTS of really cool features. Actually I didn’t just learn this, I always knew it, but I wanted to recognize it in this list … and it’s MY BLOG so I can .
Synergy/DE is every bit as cool as I always believed; and this week I proved it to a bunch of people that had never even heard of it before.
New fangled elevators are very confusing for old dogs!

Permalink • Leave a comment (no comments)
Tags: COBOL, DBL, HTTP API, OpenVMS, Synergy/DE, WCF, Web Services, Windows, xfServerPlus