In this issue....

The Latest Synergy and SDI Releases

The most recent Synergy/DE and SDI releases are now live!

First up, we have the first Feature Release in the Synergy/DE 12.4 series, version 12.4.1.1001. Available to download in the Synergex Resource Center, this release delivers support for performance tracing of Synergy programs on Linux with LTTng (Linux Trace Toolkit: next generation). When handling large and complex applications, having a profiler capable of tracing all routine calls and ISAM I/O (including Select and xfServer calls) can significantly improve the time it takes to resolve system performance issues.

In addition, the latest SDI release, version 2024.09.2004, is now available for download. This release introduces major improvements, including support for a new multi-mainline configuration, performance optimizations, and several key bug fixes. You can read all the details on the Synergex Blog.

In the rapidly evolving realm of software development, the accelerated pace of technological innovation has driven the demand for resilient cybersecurity systems and practices. As software systems grow increasingly interconnected and data-driven, accompanying risks and vulnerabilities also increase, requiring heightened vigilance and proactive security measures. Among these measures, SOC 2 Type 2 compliance has emerged as a critical standard, setting the benchmark for security, privacy, and reliability. This article explores SOC 2 Type 2 compliance and discusses how incorporating security early in the development process and balancing modern software development with escalating cybersecurity needs can lead to more effective compliance.

Continual Modernization and Synergy .NET Propel Venerable Fuel Industry App to Business Success

Rural Computer Consultants, Inc. (RCC) has made a habit of investing in a significant software update every 7 to 10 years—a strategy that’s more than paid off. 

The founders had started by custom-programming a COBOL software application for the LP gas business. Fast-forward to the late 1990s: they realized the look and feel of their application was less than friendly and wanted to move their application forward so they could act on future technology opportunities more quickly. Impressed by both the Synergy/DE technology and the committed people behind it, RCC ultimately decided to convert their application to Synergex’s Synergy DBL.

“Moving to Synergy .NET was a game changer for us,” says their head of development. “If we hadn’t made that move when we did, the business wouldn’t have grown nearly as fast as it did. We couldn’t have been able to produce code as fast as we can now. We were able to get more developers onboarded and contributing faster. Our competition is two to three times bigger than us, but we’re able to keep up.”

Have you ever migrated a database, server, or network from one environment to another? This could include duplicating it for both development and production instances, executing disaster recovery procedures, or transitioning from a local server to a cloud service. If you’ve experienced any of these scenarios, I’m sure you felt some frustration and worry as you endeavored to replicate all settings exactly as they were in the source. Shouldn’t there be an easier way?

Enter infrastructure as code (IaC), which is designed to handle and set up computing infrastructure through script files that are machine-readable, as opposed to traditional methods involving manual configuration or interactive tools. With IaC, code is used to define and manage infrastructure components like servers, networks, and databases, typically in a declarative language.

Want real-time product updates and access to the latest tech articles written by the Synergex development team? Subscribing to the Synergex Blog is the best way to stay in the loop.

When debugging, examining a literal may show a value that doesn't match the value that was set for that field. Since literals can't change value from the value they're initially assigned, this can cause confusion. This is a purely visual bug that is based on where the debugger is looking in memory for the literal value, and it is caused by the debugger being set to level 1. By design, level 1 has a lower scope to reduce debug emission output, including some field data.

The following is an example of what this behavior looks like: the literal field TEST_LIT is set to a value of 45, but in the debugger it looks like this:

DblDbg> EX TEST_LIT
-9<

By increasing the debug level to 2 (“/DEBUG=2” on OpenVMS or “-qdebug=2” on Windows and Unix), the debugger will show all of the literals with the correct values.

Industry News & Articles

• .NET 9 Preview 7 Is Now Available!
• 8 Practices Software Engineers Should Adopt and Champion for Cybersecurity
• Devs Gaining Little (if Anything) from AI Coding Assistants
• How Software Teams Should Prepare for the Digital Twin and AI Revolution
• The Pre-Mortem: Preventing Product Failure Before It Strikes
• Announcing SharePoint Framework 1.20 With Updates on Building Enterprise Extensibility Within Microsoft 365
• Non-Code Contributions Are the Secret to Open Source Success

Looking for past issues of Synergy-e-News?