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

Synergex Blog


Announcing Synergy 12.0.1.3275

By Steve Ives, Posted on February 17, 2022 at 3:44 pm

We are pleased to announce a new Synergy/DE feature release, version 12.0.1.3275, which contains a complete implementation of all new features, changes, and improvements that will soon be released as Synergy/DE 12.1 LTS. This will be the final feature release in the 12.0 series, and we strongly encourage you to take advantage of the opportunity to test your applications with the new version prior to the upcoming LTS release.

Feature releases are similar to previous Synergex releases, i.e., they contain features and fixes, they go through our extensive and rigorous testing procedures, and they’re suitable for use in all situations. LTS releases are a new type of release to which we will only add quality and security improvements and no new features. For more general information about these types of releases, see our Release Strategy page.

Synergy .NET Support for .NET 6

As announced almost two years ago, the primary focus of Synergy 12 is to add support for .NET 6 (formerly known as .NET Core) as an alternative to .NET Framework in all the places where Synergy and .NET meet, including:

  • Building and deploying Synergy .NET applications with .NET 6
  • Using the .NET Assembly API to embed and execute .NET 6 code from traditional Synergy
  • The introduction of a new xfNetLink .NET client built with .NET Standard 2.0, and including a new object pooling mechanism (COM+ is not available in .NET 6)
  • Making all of the ancillary libraries (XML API, SQL Connection API, Repository API, etc.) available as NuGet packages

One thing that is not possible with Synergy .NET in .NET 6 is creating Windows desktop applications (Windows Forms and WPF). This is because Microsoft has decided to prevent third-party Visual Studio integrators from accessing the visual design surfaces for those environments.

As is always the case, we want all Synergy developers to test their applications with this release, but in particular, we are encouraging developers who use Synergy .NET with .NET Framework to try out their code in a .NET 6 environment as soon as possible; we are eager to receive your feedback on your experiences in that specific area.

Linux License Forwarding

Another feature in Synergy 12 is the ability to use TCP/IP licensing for Linux systems when subscription licenses are used. On new systems where licensing has not been configured, a new question during the installation provides the option to enter the name of a Windows license server, and when you do so, the Linux system will connect to that server for access to product keys.

When using a network license server, a local license server (synd) process is still present, but rather than maintaining a local license database file, it communicates with the license server to allocate licenses. Linux systems configured for network licensing access the same product keys that Windows clients use, so for this configuration, you will order Windows licenses for a new Linux system.

There are several advantages to using network-based licensing on Linux systems. It simplifies license management and enables shared concurrent-use licensing across multiple Windows and/or Linux systems and/or VMs. It is also an excellent solution for developers, who can now use the license server on their development systems to operate any number of Linux and/or Windows systems and/or VMs, without having to license each system individually.

And finally, this enhancement also removes a significant block that previously prevented Synergy applications from running in containers. For example, it is now possible to deploy Synergy applications in Docker containers and managed by a Kubernetes cluster. This opens up many new possibilities for Synergy applications, including the ability to deploy Synergy applications in the Public Cloud.

Encryption Enhancements

Another area of change in Synergy 12 is that on Windows, we no longer use OpenSSL but instead use the Microsoft Secure Channel APIs that are part of the Windows operating system. As a result, you no longer have to download and deploy OpenSSL and no longer need to create and provide “CA Files” to use the HTTP API securely.

Related to this, but affecting all platforms except for OpenVMS, we now validate certificates for authenticity, revocation, and expiration whenever they are used to establish secure connections. In most scenarios, this did not previously happen.

IMPORTANT: THIS CHANGE COULD BREAK YOUR ENVIRONMENT!

When enabling encryption for xfServer or xfServerPlus, or when enabling encryption on private Web servers accessed with the HTTP API, developers frequently use “self-signed” certificates. Unfortunately, these certificates were not validated in most cases, so some systems may likely be operating with invalid (untrusted, revoked, or expired) certificates. If a Synergy 12 upgrade is applied to such a system, the services with invalid certificates will fail to start.

If you use any cryptographic certificates in your Synergy environment, we recommend reviewing them before you update to Synergy 12 to ensure that they are from a trusted source, have not been revoked, and have not expired.

To minimize the potential impact of this change, we added a new -invcertOK command-line option to the rsynd utility and a corresponding “Allow startup with invalid PEM file certificate” check box to both of the xfServer and xfServerPlus configuration dialogs in the Synergy Configuration Program.

On Windows, it is no longer necessary to maintain your certificates in PEM files, making it easier to manage those certificates. With xfServer and xfServerPlus, a new syntax is available, allowing you to identify the certificate to be used directly from the Windows Certificate Store. And when using the HTTP API, a new “cert_store” keyword can be used in place of a “CA file,” causing the Windows Trusted Root Certification Authorities store to be used for certificate validation. Please refer to the Synergy 12.0 documentation for additional information.

Also, on Windows, the SQL Connection API no longer uses OpenSSL for data packet encryption; it also now uses Microsoft Secure Channel instead.

Other Notable Changes

  • On Windows, Unix, and Linux, we have added two new functions called %create_server_connection and %destroy_server_connection that can be used to create and terminate a connection to xfServer. The connection can then be used with subsequent OPEN statements via a new SERVERCONNECTION OPEN statement qualifier. This means that applications can now connect concurrently to multiple xfServer instances.
  • We have added a new define SYN_BUILDNUMBER which provides access to the build number of the compiler at compile time
  • We have added a limited GroupBy class for use with Select statements to provide a subset of a SQL “GROUP BY” clause functionality. We plan to add more SQL-like functionality in future releases.
  • In .NET, we have added GRFA support for READ, READS, WRITE, and WRITES statements when using stream, sequential, relative, and block files.
  • We now provide limited support for Global I/O hooks on OpenVMS and have added support for the %DATETIME_TO_I8 and %DATETIME_FROM_I8 routines already available elsewhere.
  • We have improved the isutl utility, improving re-index performance, particularly when processing very large files.
  • On Windows, the Device Licensing tools now support .NET and .NET Core, and .NET Framework.
  • In Workbench, the DPI scaling now adheres to newer Windows gdiScaling, resulting in an improved experience on high resolution and high DPI monitors.
  • And also in Workbench, we have added 17 as a selectable target version for JAR files in Java Component Projects.
  • The Synergy .NET compiler now supports multi-dimensional arrays of boxed value types.

What About .NET Support on Linux?

In addition to supporting the .NET 6 environment on Windows, we will soon introduce support for running Synergy .NET code in .NET 6 on Linux systems. This capability will not be present in the first 12.1 LTS release but will be introduced in a subsequent update.

This change is particularly important for Linux developers using Harmony Core services, as they will then be able to host their Harmony Core services on the same Linux systems that host their applications code and data, no longer requiring an intermediate Windows server to host the Harmony Core services.

Quality Improvements

In addition to the many new features and enhancements mentioned above, this release also includes quality improvements across all products, and we encourage you to refer to the release notes for your products for complete and detailed information. The release notes can be accessed online from the Feature Release Downloads page.

Windows 11 and Windows Server 2022

Please note that Windows 11 and Windows Server 2022 included some changes to screen painting code at a low level in the operating system, and these changes impacted screen painting by Synergy Windows and UI Toolkit applications on those platforms. We quickly resolved the issue, making some changes in the Synergy runtime. This fix was initially released in Synergy 11.1.1i in November 2021 and is also included in this release. Therefore, if you run any Synergy applications on Windows that use Synergy Windows or UI Toolkit, you need to upgrade to at least 11.1.1i or any later release to run successfully on Windows 11 or Windows Server 2022.

Availability

This release is available for the following platforms and can be downloaded from the Synergex Resource Center:


CodeGen 5.8.1 Now Available

By Steve Ives, Posted on February 2, 2022 at 3:31 pm

We are pleased to announce the availability of the first CodeGen release of 2022, version 5.8.1. As always, you can download the new version from our GitHub Releases page and view the documentation at https://codegen.synergex.com.

The enhancements included in this release are:

  • We added the ability to define the minimum version of CodeGen required by your environment by setting the environment variable CODEGEN_MIN_VERSION.
  • We added support for generating sample data (JSON formatted) for structure parameters when using the <PARAMETER_SAMPLE_DATA> parameter loop expansion token.
  • We added a new method loop expansion token <METHOD_RETURN_SAMPLE_DATA>.
  • We corrected an issue that prevented the -checkversion and other related operations from operating correctly.
  • We altered the <INTERFACE_NAME> token to support all case variations.
  • We changed the output of the parameter loop expansion token <PARAM_TSTYPE> to be consistent with the documentation by emitting structure names in camelCase rather than PascalCase.
  • We added a new mechanism for dealing with literal key segment values requiring trailing spaces to be maintained as part of the literal value. This change can alter the output of the <SEGMENT_LITVAL> and <LITERAL_SEGMENT_VALUE> expansion tokens.

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


Announcing SDI 2022.01.1003

By Steve Ives, Posted on January 11, 2022 at 2:46 pm

We are pleased to announce that a new version of Synergy DBL Integration for Visual Studio (SDI) version 2022.01.1003 is available for download from the Resource Center and is recommended for use by all Synergy developers. This is a quality improvement release, and as always, we encourage you to review these changes listed in the release notes.

The Synergy/DE tools included in this version of SDI (dbl.exe, dblproto.exe, dblibr.exe, dblink.exe, dbl2xml.exe, and rpsutl.exe) are from Synergy/DE version 12.0.1.3275.


Announcing SDI 2021.12.3567

By Steve Ives, Posted on December 14, 2021 at 4:03 pm

We are pleased to announce that a new version of Synergy DBL Integration for Visual Studio (SDI) version 2021.12.3567 is available for download from the Resource Center and is recommended for use by all Synergy developers. The primary reason for this release is to ensure compatibility with the version 12 Synergy .NET runtime and accompanying libraries built to target .NET Standard 2.0.

SDI now enforces a minimum .NET Framework version of 4.7.2 for Synergy .NET projects. When opening a solution, SDI will automatically upgrade any Synergy .NET projects that target older Framework versions, altering them to target 4.7.2. This may impact your ability to build if you have non-Synergy projects that reference Synergy .NET projects and target a lower Framework version. If you do experience build problems, check the warnings produced by your Visual Studio build for details on .NET Framework targeting issues.

As always, the new release also includes a range of quality improvements, and we encourage you to review these changes listed in the release notes.

The Synergy/DE tools included in this version of SDI (dbl.exe, dblproto.exe, dblibr.exe, dblink.exe, dbl2xml.exe, and rpsutl.exe) are from Synergy/DE version 12.0.1.3274.


Synergy/DE and the Log4j Vulnerability

By Steve Ives, Posted on at 9:08 am

Over the last few days, we have received inquiries from customers asking whether Synergy applications can be affected by the recently discovered zero-day vulnerability in Log4j, a Java logging library. We can confirm that we do not use this library in Synergy/DE or our OpenSource solutions. Therefore, the only way you could be affected by this vulnerability would be if your application directly uses this library.


Synergex Hackathon 2021 Was Out of This World

By , Posted on December 9, 2021 at 8:49 am

This year marked our second fully remote Synegex Hackathon! Despite not sitting together at huge tables in a large conference room—the standard hackathon setting—this year’s space-themed contest was a hit. Of course, this was mostly due to the awesome teamwork and innovation that the Synergex team brought to the (once again, virtual) table, but there is also something to be said for the strategic use of digital technology in setting a hackathon project apart from the competition. Before we dive into the tools that our teams used to take their projects and presentations to the next level, here’s a high-level summary of the goals and structure of our annual hackathon.

Leading up to the hackathon itself, Synergexians propose project ideas and organize into teams according to which idea they find the most inspiring. This is where tools like Microsoft Teams and Google Sheets come in handy, especially since we’re not currently chatting around the water cooler about which project(s) we’d like to work on.  

You’ll often hear of hackathons lasting 24 hours (or more), but the annual Synergex Hackathon takes a humble eight hours a) because we are not college students and b) because that generally winds up being enough time to put together an awesome prototype/presentation and get to know colleagues you don’t work with on a regular basis.

During the closing ceremony, each team presents their work, and everyone votes on their favorite project. In an in-person setting, this would be done using the time-tested hand raise. Virtually, we rely on the Microsoft ecosystem to present, provide feedback, and efficiently collect and tally votes.

Now that you have the general gist, here’s a sampling of the apps and sites that contributed to the success of this year’s hackathon. (If they can help a team of five frantically work their way from nothing to something in just one business day, perhaps you may find them useful as well!)

Tools for Collecting Data

Google Forms and Microsoft Forms feel interchangeable in a lot of ways, but there are some meaningful differences that may make one more suitable than the other.

We used Microsoft Forms for voting purposes since we’re fully embedded in the world of Microsoft anyway, and this allowed us to take advantage of single sign-on (SSO). The form tallied the votes for us, so we didn’t have to do much thumb twiddling when it came time to announce the winners.

That said, Google Forms features a wider variety of response types and templates. Team SpaceUX used a Google Form in their presentation to show how participants in a usability testing program would provide feedback on their experience using a given software product.

Tools for Displaying Data

Airtable

Airtable is a cloud-based spreadsheet/database hybrid that the Education team uses to track data, organize tasks, and brainstorm content ideas in several project areas. In the context of the 2021 Hackathon, this platform came in handy for determining who was on what team.

Since Airtable bases are essentially easy-to-use and easy-to-visualize databases, they do a better job at pulling up data and arranging it in different ways than standard spreadsheets. This made it a cinch to sort people into groups based on their top three team preferences—all while avoiding assigning people to multiple teams by accident or winding up with very lopsided teams.

Check out Airtable if you’ve ever looked at a spreadsheet and thought to yourself, “That oughta be a database table connected to other database tables,” but you’re not sure if you have the time or know-how to make that happen from scratch. 

Tools for Creativity

Balsamiq

Balsamiq provides a “rapid low-fidelity UI wireframing tool” meant to mimic the process of sketching while adding helpful functionality that you don’t enjoy with a pencil and paper. The prototypes generated with Balsamiq are meant to illustrate content and structure rather than design and branding, making it easier to focus on the former.

The Battleshop Galactica team used Balsamiq wireframes to show off the online retail app idea they pitched. It was the ideal tool for the (very) limited timeframe, as it allowed the team to demonstrate the functionality of the app without writing a single line of code. Despite the lack of color and distinct font, the audience was able to get a good grasp of what the product would like look and how it would behave in the real world.

Biteable

Video is a powerful medium for sparking interest and evoking emotion. Two of our teams created eye-catching videos during the Hackathon, and both used Biteable.

Biteable markets itself as the world’s simplest video maker, which is exactly why it was so well suited to this time-limited event. Compared to the deluge of options and settings in Premiere Pro, for instance, Biteable makes it easy for video production newcomers to make decisions about their final product—including its font size, dimensions and orientation, and whether to include a watermark. Biteable also offers an impressive inventory of stock animations, footage, and background images, making it the ideal solution when corners must be cut (and in this event, corners aren’t just cut, they’re hacked right off).[1]

Again, this is just a sampling of the tech that stood out this year. Honorable mention goes to other tools teams have used or considered using in the past:

If you’d be interested in hosting a hackathon within your own organization, contact our Education team! We’d be happy to help get you started.


[1] Get it? Because it’s a Hackathon? …I’ll see myself out…


Announcing Synergy/DE 11.1.1i

By Steve Ives, Posted on November 22, 2021 at 2:48 pm

Synergex is pleased to announce the immediate availability of Synergy/DE 11.1.1i on Windows, Linux, IBM AIX, Oracle Solaris, and OpenVMS. Synergy/DE 11.1.1i is a quality release that includes a wide range of improvements across most of the Synergy product line, and we strongly encourage all Synergy developers to review the release notes (available in the Synergy Resource Center) for detailed information about everything that changed.

Synergy 11.1.1i is the first version to formally support the Windows 11 and Windows Server 2022 operating systems. In some cases, earlier versions of Synergy might run successfully on a new version of Windows, but in this instance, that may not be the case for some applications and system configurations. It appears that Microsoft made some low-level changes in the Windows 11 and Windows Server 2022 operating systems that negatively impacted the way that various UI controls and backgrounds are painted in some UI Toolkit applications running in some video configurations. This issue resulted in poorly rendered UI for affected applications. It is currently unclear what scenarios cause this issue to manifest; it may be related to certain high-DPI configurations. We have addressed this issue with a change to the DBL runtime in 11.1.1i and strongly recommend that all deployments to Windows 11 and Windows Server 2022 systems be with 11.1.1i. Note that this issue also affects the current 12.0.1.3272 feature release, and the fix will be included in an upcoming feature release in that series.

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.

Synergy/DE 11.1.1i is available for download now.


Announcing SDI 2021.11.3540

By Steve Ives, Posted on November 18, 2021 at 9:49 am

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

This is primarily a compatibility release that formally supports the recently released Visual Studio 2022, and continues to support Visual Studio 2019. In addition, SDI supports both the Build Tools environments of both the 2022 and 2019 versions. The release also includes several quality improvements; as usual, please refer to the release notes for additional information.

We recommend that Synergy developers consider upgrading to Visual Studio 2022, which is the first 64-bit version of the product; the higher memory availability that results from using the 64-bit architecture yields noticeable benefits in several areas, not least of which is the improved speed at which projects load when opening a solution.

The Synergy/DE tools included in this version of SDI (dbl.exe, dblproto.exe, dblibr.exe, dblink.exe, dbl2xml.exe, and rpsutl.exe) are from Synergy/DE version 12.0.1.3272.


Updated Timeline for the first Synergy LTS Release

By Steve Ives, Posted on November 2, 2021 at 2:42 pm

In August, I announced a New Release Strategy for Synergy, and I wanted to provide a quick update on our plans, which have changed slightly since that initial announcement.

Our original plan was to release an initial Feature Release in September, followed by the first Long Term Support release at the end of 2021. The 12.0.1.3272 Feature Release took place on schedule and is available for use, but we have adjusted our plans regarding the first Synergy 12.1 LTS release, which will now be in early March of 2022.

The primary reason for the change is to allow for a more extended period of customer testing of the many new features and enhancements in the current release and allow time for an additional 12.0 Feature Release to address any issues that arise. The next 12.0 Feature Release will be in late 2021, at which time we plan to be feature complete for the subsequent LTS release, ensuring an extended testing cycle for the LTS release before it ships in March.


Announcing SDI 2021.09.3450

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

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.


When It Comes to Legacy Systems, It’s Hip to Be Square

By William Mooney, Posted on September 16, 2021 at 11:34 am

I talk to a lot of CEOs, CIOs, and CTOs who feel pressured to replace legacy (aka proven) applications that have served their multibillion-dollar organizations faithfully for 30 or 40 years or more, in a quest for “modernization.” My advice, more now than ever, is never touch a hot stove, and please don’t burn your house down.

While CEOs tend to have a longer lifespan, I’ve seen a great many CIOs and CTOs come and go because they got burned by an ill-thought-out move toward IT modernization and because, in some cases, they figuratively burned down the house, bringing line-of-business applications to their knees and significantly impacting operations—leaving it to their successors to beat a hasty retreat back to the rock-solid legacy systems that some see as old-fashioned.

Some say it’s a build versus buy question. I say it’s a built versus buy question: those legacy applications are already built and running. Yet I’ve encountered C-level executives who just two months after joining a company have made hasty—turned disastrous—decisions to throw out the old in pursuit of the new. But they’re trying to solve a problem that doesn’t really exist. Well, kind of. Yes, there are known issues and problems. However, companies typically don’t invest in solving these known issues and problems and instead kick the can down the road. Then the new CxO comes in and suddenly gets the green light to make the investment, and money that never existed before is now abundant.

Migrate your code to a new platform? Definitely. For years companies have been moving their legacy systems from OpenVMS, IBM AS/400 and AIX, Sun boxes, and other systems onto Windows or Linux, while retaining the original code of their legacy applications.

Apply a modern user interface? Go for it! With browser-based, Windows-desktop, and mobile front ends, you can change the UI at any time, without endangering the line-of-business legacy code that has kept your business prospering for decades, and you can continue to do so for decades to come.

Replicate your legacy data to a modern database? Absolutely. While preserving your existing data and logic, you also make your data available for ETL processing into a data warehouse or whatever other BI environment you choose.

Use modern development tools? Of course. Armed with the right tools, which a good developer can learn quickly, you can take advantage of the myriad developer productivity, code quality, and other features that are inherently present in modern IDEs like Microsoft Visual Studio. Your legacy application being written in DBL, COBOL, BASIC, or the like does not prevent you from using modern tools and development techniques.

It’s Hip to Be Square

When it comes to retaining your bullet-proof legacy systems that have supported your business for decades, I encourage you to have a new appreciation for the steadfastness of DBL, COBOL, and other legacy languages. As the musician Huey Lewis sings, “It’s hip to be square.” When it comes to stability, DBL, COBOL, and the like rock—as in rock solid.

In celebration of COBOL’s 60th birthday in 2019, Mike Madden posted an appreciation titled “Happy Birthday Dear COBOL,” which presented these figures:

• COBOL supports 90% of Fortune 500 business systems daily

• 70% of all critical business logic is written in COBOL

• COBOL connects 500 million mobile phone users daily

• 95% of ATM transactions pass through COBOL code

• 80% of all point-of-sale transactions rely on COBOL

• There are more COBOL transactions executed daily than Google and YouTube searches

• 1.5 million new lines of COBOL code are written every day

• 2 million people work in COBOL

Yet within the industry, there’s a tendency to judge a book by its cover, to see a green screen and cringe, and to risk one’s career by saying, “We’re going to rewrite that application to bring it into the modern era.”

Upon such statements, careers have faltered and business continuity has foundered.

Too often lost in a rush toward the new is the simple fact that you can apply a modern user interface to your legacy application’s code base, usually in a fraction of the time and at a fraction of the cost of replacing the application with something else.

One of the main techniques for enabling this type of enhancement is to create a “services layer” between your legacy code and your new UI. Usually this involves building RESTful web services APIs that expose your application’s business logic and data through modern, flexible, open, and secure protocols.

Once you have this services layer in place, it can be used by any new UI that you choose to build, using whatever tools you decide to use. But be extremely cautious about trying to rewrite the back-end code that has been reliably supporting your business operations, perhaps for decades.

Question: Do you think you can rewrite 35 years of customized applications in three years? Quick answer: No. I’m sure your business applications have been steadily upgraded and customized over the years, involving a vast number of accumulated developer hours. The nuances in that code should be considered your secret sauce. Could it be duplicated in C# or some other language? Yes—but not within a timeframe, cost, or risk profile that most organizations would want to take on.

Gap Analysis: 2 or 3 Years

In the classic American western Butch Cassidy and the Sundance Kid, the two outlaws have been tracked down by a posse. They’re at the edge of a cliff with nowhere to go except a very rough river far below. As Butch tries to talk the Sundance Kid into jumping off the cliff to the river below, Sundance finally confesses: “I can’t swim!” Butch laughs and says, “Are you crazy? The fall will probably kill you.”

That scene comes to mind when considering the essential task of performing a thorough gap analysis before trying to replicate the old legacy code that you think needs to be replaced. Just the gap analysis can take two to three years. That’s the jump. But attempting to create a new application without a gap analysis—using a needs-based approach—is equivalent to the other fate: facing certain death.

When I speak of the “secret sauce” incorporated into your legacy applications over the decades, I’m not talking about something basic like general ledger, accounts payable, or accounts receivable. I’m referring to the more complex pieces, like order entry and inventory management, that involve intricate orchestrations, workflows, and in-depth business knowledge.

For example, we worked with a company that has long provided DIBOL-based software for tracking grain in storage. That might sound simple enough, but the workflows are complex. Looking at just a subset of the tracked elements: upon arrival, the grain is measured for weight, of course, but also for moisture content, which feeds an algorithm to determine yield and value of the grain. Next, the grain is mixed with other grain in silos where it may sit for months or years, and it is tracked as it transfers from one silo to another for shipment. All along the way, there are elements and dependencies worked into the code that could take some years to identify through gap analysis, even before any actual coding starts.

We’ve seen supposed three-year modernization projects drag on for more than a decade, with still no end in sight. And there was no actual need to replace the application: other options were available that would have addressed the requirements more quickly and at a significantly lower cost. The new CxO just felt compelled to replace the application with something “modern.”

But Who Does Legacy?

A common fear is “But I can’t hire old-school developers!”

Any good developer that you hire out of a computer science program, given appropriate time and support, will learn both your environment and the language that you use. Of course, developing in a modern IDE can only help to accelerate that process. Good programmers adapt to a new language quickly.

The real question should be “Who has the business knowledge?”

What generally takes much more time for a new hire to learn is the specifics of your industry, and that learning challenge applies to all developers. This “domain knowledge” about your industry is what your legacy application has wrapped up in its code: decades of carefully acquired and crafted business logic. It’s not hard to find someone who codes. But try to find someone who knows grain elevators inside and out. Or who knows your international shipping regulations, practices, and requirements. Or your consumer-packaged goods business. Or life and casualty insurance. Those legacy systems are vast storehouses of carefully acquired wisdom, set into code as business logic.

You can put an attractive front end (and please do) on anything, through the use of web services and other modern technologies. But it could take years, perhaps decades, to capture and recast the real-life business logic sitting in that legacy code. So the next time someone suggests a multi-year modernization project, just smile and remind them: Sometimes it’s hip to be square.


Announcing Synergy 12.0

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

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

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.


Virtual Reality: How We Successfully Pulled Off Our First Remote Conference

By and Heather Sula, Posted on July 27, 2021 at 11:20 am

March 2020. We were three months away from the Synergy DevPartner Conference, an in-person learning event we hold for our customers every 18 months. Then the pandemic hit and upended everything. We had no idea that within a year, we’d have to completely reconceptualize and adapt our entire conference blueprint for a virtual audience while providing the same educational value and keeping the communal spirit of our in-person gatherings.

In the end, we were able to present 16 content-packed virtual sessions to a record number of attendees that, thanks to a boatload of planning and persistence, went off with barely a hitch. (You can watch most of the conference sessions here.)

Conference moderator Haley Hart and subject matter expert Marty Lewis lead a Q&A after a session.

Here’s how we did it.

Planning

Planning any large event is a significant logistical undertaking, requiring coordination and cooperation between multiple departments. The more you plan ahead, the less you have to panic at conference time. We won’t bore you with every detail of our particular planning process, but here are some foundational steps we took to make sure all our bases were covered.

What we did:

  • Held weekly conference check-ins. Communication is key for making sure nothing falls through the cracks.
  • Created standard branding. The conference had its own “look” that was used to design the website, PowerPoint templates, webinar rooms, session landing pages, etc., to ensure a cohesive aesthetic that distinguished it from our usual content.
  • Got organized. Whether it was shared spreadsheets, Kanban boards, etc., we made sure the key players had insight into the necessary tasks and timelines, so no one was in the dark.
  • Allowed time to work on “nice-to-haves” (informal networking sessions, giveaways, etc.) in addition to the necessary components of the conference. Sometimes it’s the little things that make an event special.

Additional Takeaway: Hold a pre-mortem. A pre-mortem is a thought experiment that encourages people to think about what could go wrong. A few members of the conference planning committee got together in April and did some brainstorming about specific issues that could arise during the conference. For example, we determined who would step in as moderator if either of our two main MCs called in sick. Or, if the Q&A portion of a session went on for longer than expected, we came up with a solution: unanswered questions would be collected and answered during the wrap-up session. Thankfully, no one wound up getting sick, but it was comforting to know we had a plan in case that did happen.

Execution

While planning is nine-tenths of the game, you still have to execute. The following are some things to keep in mind so everything goes smoothly when the time comes.

What we did:

  • Created a task force to handle registrant issues that communicated frequently. Because we had additional people on hand to field customer support, the organizers were free to focus on making the conference happen.
  • Kept an eye on statistics. We sent analytics to our sales team after every session so they could reach out to customers accordingly.

Additional Takeaway: Talking to a camera instead of an audience is…weird. Pre-recording most of the sessions was helpful for a handful of reasons: it allowed presenters to take a substantial breather between slides (grab a cup of coffee, get the demo ready without rushing), and we had the opportunity to add some creative flourishes in post-production. Still, most presenters found the camera to be a poor substitute for a live audience. In the future, we’ll consider inviting additional staff to recordings to act as a stand-in audience.

Session recording in our makeshift conference studio at Synergex HQ.

Flexibility

Ultimately, you have to be nimble, ready to adapt to changing circumstances, and take on any challenges that pop up. Luckily, you can prepare for flexibility too.

What we did:

  • Backups, backups, backups. For pre-recorded sessions, the main plan was to upload the files into the webinar platform and hit play. But we always had a backup plan in case something went wrong (private YouTube video versions of the sessions we could link to, etc.).

Additional Takeaway: You don’t need to use a one-size-fits-all formula for conference sessions. We had to work around several factors when recording the 16 sessions, including each presenter’s geographic location and level of comfort in a live vs. pre-recorded context. Rather than make everyone do everything the same way, we gave presenters flexibility in terms of how they wanted to structure and lead their sessions, and we wound up with a nice variety because of it.

We look forward to seeing you at the 2022 conference!

Check out the conference sessions and learn how to do the following:

  • Improve development productivity and practices through adopting more efficient development methodologies.
  • Enhance years of Synergy data and code with new technologies, enabling connectivity through RESTful web services and APIs.
  • Keep up to date with Synergy SSL and operating system security patches. (Security and disaster recovery are important for compliance!)
  • Use traditional Synergy in Visual Studio to gain a huge productivity boost, lower the barrier to continuous code integration, and improve processes and software quality.

Watch sessions here


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.


Recent Posts Categories Tag Cloud Archives