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

Synergex Blog


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.


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

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

Cindy Limburg

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?

  1. Make sure you’re set up to manage your licenses in the Resource Center. (See above.)
  2. Check to see if your application is using the SERIAL routine or the Licensing Toolkit and if so, address those accordingly. (See above.)
  3. 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.
  4. 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.
  5. 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.


Old Dog … New Tricks … Done!

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

Steve Ives

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:

  1. 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).
  2. 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?

  1. I really, really, REALLY don’t like COBOL!
  2. 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 Smile.
  3. 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.
  4. New fangled elevators are very confusing for old dogs!

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