If like me you prefer to have a local copy of the Synergy/DE documentation available for those times when you can’t get to the internet, then you’ll be happy to hear that we have just published an updated off-line installer for the 11.1.1c documentation and it is now available for download in the Resource Center.
Important quality improvements for REV11 licensing
A new patch release for Windows and Unix is now available to download on the Synergex website. All customers are encouraged to update to 11.1.1c for important quality improvements.
This update includes new versions of the following products:
- Synergy/DE (32- and 64-bit)
- REV11 licensing upgrade package (32- and 64-bit, delivered in one installer on Windows)
- Synergy DBL Integration for Visual Studio
IMPORTANT: Previously, in REV11 licensing environments, an expired license error could occur if a license allocated by a program expired while the program was running. Even if new keys had been delivered and installed, if the license server had not been restarted since the new keys were installed, the error could occur.
It is important that all customers using subscription licensing in a REV11 environment install the 11.1.1c patch (for version 11 systems) or apply the 11.1.1c version of the licensing upgrade package (for version 9 or 10 systems).
If for any reason you are not able to do so, you should ensure that your license server is restarted as soon as possible after your new subscription keys are delivered. Long-running processes are resilient to a license server restart.
- In versions 11.1.1a and 11.1.1b, if an attempt to rename a remote file (via xfServer) resulted in an error being generated, in some cases xfServer could fail with a segmentation fault.
- In versions 11.1.1 through 11.1.1b, using the isutl utility to re-index a large multi-key ISAM file with an index exceeding 4,294,967,295 bytes caused a corrupted index to be created.
- In versions 11.1.1 through 11.1.1b, when running xfServer in Secure or Trusted mode, a client using the RUSER mechanism to provide login credentials to the server experienced a “Bad username, login rejected” error.
- In versions 11.1.1 through 11.1.1b, in some circumstances when opening a remote file via xfServer when that server did not already have other files open, the xfServer process could fail.
We significantly enhanced the Visual Studio build system for Synergy .NET projects by improving the dependency-checking algorithms. Previously, any change in the code of, for example, a class library caused all projects that reference that library to be rebuilt. With these changes in place, dependent projects will only be rebuilt if changes in the dependency library result in the signatures of externally visible items being added, changed, or removed. This will result in a significant reduction in elapsed build times in many cases.
We improved the hover-over information (QuickInfo) displayed for type declarations for variables, fields, properties, etc. We added simple colorization and documentation comments (when available), and in some cases, type names are now fully qualified.
In Microsoft Visual Studio version 16.4 a new feature was, I was going to say introduced, but snuck in might be more appropriate way of describing things. There was no mention of the new feature in any release notes that we can find, and an internet search for the name of the new feature currently returns no useful matches!
The feature is called Adaptive Formatting and apparently what it does is allows code editor windows to “heuristically determine if the current file should use tabs or spaces for indentation”. Previously this behavior was determined by a language specific setting, and those settings are still present, but if Adaptive Formatting is enabled (which it is by default by the way), then it wins!
So if your code is indented with tabs, and suddenly Visual Studio decides to start using spaces instead (or vice-versa) then it’s probably Adaptive Formatting getting it wrong! Thankfully this new feature can be disabled by going into Tools > Options > Text Editor > Advanced and un-checking the Use adaptive formatting option.
Happy coding everyone!
In recent weeks we have been working on making improvements to our SQL Replication environment, which demonstrates how to easily replicate your Synergy data to a SQL Server database. Some of these changes were undertaken in collaboration with a customer that uses the environment extensively, and we thank them for their input and support. Other changes have been on our road-map for some time and we think you’ll be excited about what has been achieved. Here’s a summary of the changes:
- Synergy 11 introduced a new SQL Connection API capability which calls the ODBC API function SQLDescribeParam behind the scenes to improve performance and avoid excessive cache memory thrashing for SQL statements that have I/O parameters when accessing SQL Server (VTX12_SQLNATIVE). Synergex recommend setting SSQL_PERFORMANCE_SQL to yes (or setting the SQLPERFORMANCESQL environment variable. We have updated the environment to do this, which should result in improved performance when running in Synergy 11 or higher environments.
- We have added the ability to run multiple instances of the replicator process side-by-side, within a single data set, and to divide up the replication of different files between these multiple replicator instances. Each instance is assigned a unique instance name and has its own associated instruction queue file, the name of which includes the instance name, as does the log file produced by each instance. In a multi-instance environment developers can chose on a file-by-file bases which data files are replicated via which queue file, and therefor via which replicator instance. It is important to understand that in this scenario there is no synchronization of the sequence in which changes are applied to the underlying SQL database between the multiple instances of the replicator.
- We have added the ability to exclude certain fields in a record from being appearing in and being replicated to the associated SQL Server database table. It is important that fields associated with keys not be excluded, unless those keys are also excluded (see the next item). Generally the fewer fields/columns that are replicated the faster the replication will be.
- We have added the ability to exclude certain keys from processing, so that matching database indexes will not be created in the associated database tables. Generally the fewer indexes that exist on a table the faster the replication will be.
- We have added the ability for the replicator to detect some kinds of database failure, caused by network errors, or the database being shut down or otherwise unavailable, and allow it to gracefully disconnect, and then attempt to reconnect, with a configurable number of retries and retry interval. This should make the replicator processes more robust.
- We have added the ability to change the database datatypes of fields. The main use case envisaged is transforming decimal fields into implied decimal fields (adding decimal places in the database data), but there may be other use cases, such as transforming Y/N fields into Boolean true/false fields, etc.
- We have also corrected an issue that could occur if replicator encountered an unexpected error and was configured to use BATCH COMMIT mode. Is some circumstances, if there were uncommitted changes at the time on an error any uncommitted changes could be lost because the change records were deleted from the instruction queue one by one before the batch was committed. Now any instructions related to uncommitted changes remain in the queue file until the batch is committed, and are then all deleted. When the replicator is restarted it will then attempt to reply the changes to the database again. This should help prevent the database getting out of sync if there is a replicator failure.
We’re excited about these new features in our SQL Replication offering and looking forward to hearing your feedback. By the way, many of these new features rely on using the latest and greatest version of CodeGen (5.4.8) which was also released today. If you’re already using an earlier version of the SQL Replication environment, or if you are interested in getting started and would like some assistance, don’t hesitate to contact us through your Synergex Account Representative.
Some time ago a customer posted in the Synergy/DE Ideas forum suggesting that a Synergy DBL language plug-in should be created for the increasingly popular Visual Studio Code editor. Over course of the next few months the post received a significant number of votes, and we also started hearing the same request from others.
Later we heard from the original customer that they had started to define some basic language integration themselves, offered to share that initial code, and agreed that it could be open sourced.
At this time we are pleased to announce that initial support for DBL in VS Code is live! We have developed this functionality as an open source project on GitHub (https://github.com/Synergex/vscode-synergydbl) and welcome your feedback and your contributions.
If you just want to try the extension you can search for “Synergy” in the extension marketplace inside of VS Code, or download and install the VSIX from the GitHub Releases page. If you do try the extension out, and have questions or problems, please use the GitHub Issues page to let us know.
The initial scope of the extension is fairly limited, but we have been using the colorization locally for a while now and it makes a huge difference when you just need to do a quick edit to a source file. We are looking forward to seeing what everyone else has to contribute.
We’re very pleased to announce the release of Synergy/DE 11. Version 11 delivers many features, including important security updates, exciting ISAM resilience features, and runtime performance improvements. It also includes new Synergy DBL and Visual Studio integration features. See our Synergy/DE 11 page for a full list of features.
Synergy/DE 11 also includes our new REV11 licensing, which automates your product key updates. REV11 licensing is used with Synergy/DE 11, and it also supports Synergy/DE 9.3 – 10.3 with a licensing upgrade package. See our REV11 licensing page for more information.
Many of the new features in Synergy/DE 11 were suggested on our Ideas site. We would like to thank everyone for their input, and we encourage you to continue to post, comment, and vote on that site to let us know what features are most important to you.
Be sure to review the new requirements before you upgrade to Synergy/DE 11. For example, version 11 doesn’t support Windows 7, Windows Server 2008 R2, or Visual Studio 2015.
We strongly encourage you to upgrade to Synergy/DE 11 for enhanced application security, resilience, and performance; a better developer experience; and a much easier process for managing product keys. Take a look, and let us know if you have any questions or if you need any assistance.
For some time CodeGen has shipped with a utility called CreateFile that (given an appropriately configured repository) could be used to create an ISAM file based on a repository FILE or STRUCTURE definition.
A customer recently asked me to create a mechanism that they could use to create multiple files, load data into those files, and also support creating both RELATIVE and ISAM files. Rather than writing something completely new I decided to extend the CreateFile utility, and that new feature has now been released along with the latest version of CodeGen (5.4.2).
Briefly, there is a new command line option -in that allows you to specify an input file containing the details of one or more files to be created and and populated. The file uses a JSON format. If you’re interested in finding out more you can find additional information in the CodeGen documentation.
It’s been a while since a GodeGen release was announced on this BLOG, but rest assured they have been coming thick and fast; in fact there have been 9 interim releases since we last announced here.
So why all the frenetic activity in CodeGen land? Well the primary driving force for so many releases and so many new features is to provide support for the ever evolving Harmony Core RESTful Web Services framework. If you’re not familiar with Harmony Core then you should check it out. More and more Synergy developers are starting to take advantage of it as a way to expose their applications data and business logic in whole new ways and to support a myriad of use cases.
So what’s new in CodeGen 5.4.0? Well the answer to that question is … a LOT! I won’t list all the new features here but if you want to check out the specifics then you can head over to the CodeGen Releases page where you’ll find a detailed change log for this and previous versions. And if you need more information than that then check out the CodeGen Documentation.
We recommend that all developers who are using CodeGen upgrade to this latest version, but particularly if you’re developing with Harmony Core.
Happy 4th Everyone!
In the 1984 movie classic Ghostbusters, we are introduced to Bill Murray’s character Dr. Peter Venkman, a professor of paranormal studies, testing subjects for the gift of clairvoyance—the ability to gain information about an object, person, location, or event through extrasensory perception. While it is clear Dr. Venkman does not take such things very seriously, we can see the advantage of such an ability, particularly for developers.
Stop me if you’ve heard this before: “We upgraded X and now Y is happening.” In this case, Y is usually associated with a negative behavior like slow performance, a slew of errors, or a bad user experience. Events like these may induce weariness, nausea, dry mouth, and other various side effects that are usually listed in American pharmaceutical commercials. In summary, they’re unpleasant. If only there were some means to predict these events and avoid them in the future…
Unfortunately, most developers are not gifted with the power of clairvoyance to anticipate problems with upgrades before they happen. But maybe instead of a crystal ball, there are tools that can help us avoid upgrade failure. Let’s look at some things that can help anticipate and/or prevent such issues from happening.
A relatively recent addition to the Synergy documentation is the Configuring for performance and resiliency topic in the Installation Configuration Guide. This topic discusses things that one should take into consideration when running Synergy on any system, and it’s based on years of experience from the Synergex Development staff and the results of their testing. If you haven’t read this section yet, I highly recommend doing so. If you’ve already read it, I recommend a quick refresher the next time you’re looking at major system or software changes.
In Support, we often see issues when developers virtualize systems that run Synergy or when data is migrated and then accessed across a network rather than being stored locally. Both scenarios are discussed in this topic. And as part of Synergy’s web-based documentation set, it’s updated regularly with the latest information. Make sure you take a look before any major upgrade in case there are changes.
Other useful tools for avoiding problems are the Synergex Blog, the Synergy migration guides, KnowledgeBase articles like Guideline for debugging performance issues, and the release notes that come with each version of Synergy. Remember that even if you are just changing the operating system and/or hardware and not your version of Synergy, you should re-review these materials. Some of the considerations they outline may now be relevant, even if they didn’t affect you previously. Also, when testing, remember to take load testing or a process running over time into account. We commonly see pitfalls when developers neglect these two factors in testing.
Now let’s say that despite your excellent planning, you do see a performance issue. What can you do? Here are some steps I’ve found helpful that might get overlooked. Most have to do with simply eliminating factors that affect performance.
- Establish a baseline
If you’re going to diagnose a problem in performance, the first thing to do is isolate code or create a piece of code that demonstrates the problem. Make this your baseline test for all of the various configurations you’re going to test. This will make your tests consistent as well as eliminate code changes as a factor.
- Use a metric
Establish a program you’re going to use to measure the difference in performance. If you’re using a traditional Synergy program as your baseline, you can use the Synergy DBL Profiler, which will count CPU time for you. Just make sure you pick the same metric for your testing—CPU time is not the same as real time. This step will enable you to get measurable results to test what is actually making a difference.
- One by one, test all the things
I’ve found that the easiest way to plan and visualize testing is to make a tree. Each layer is one aspect you’re testing that continues to branch with every different aspect. For example, I had a situation where a production machine migrated Synergy version, operating system, and hardware and virtualized the OS, all in one move. We picked one thing to change (the virtualization of the OS) and tested it.
By doing this, we established that virtualization was a factor, because a virtualized environment was slower than a non-virtualized one. We then compared those to the old and new Windows versions, but continued with virtualized and non-virtualized environments using the same virtualization software.
|Windows 8||Windows 10|
|In previous table||In previous table|
On average, this produced the same result. (It was I/O processing, so we did an average of 10-20 runs based on how volatile the results could be.) Next, we compared the Synergy 10 runtime with the Synergy 9 one.
|Windows 8||Windows 10|
|Syn 9||Syn 10||Syn9||Syn 10||Syn 9||Syn10||Syn 9||Syn 10|
|In previous||In previous||In previous||In previous|
The tree continued growing until all of the factors were considered and tested.
It can be tedious to test one change at a time, but without that kind of granularity, you can’t establish which change affected performance and by how much. In the example I mentioned above, we established that virtualizing the hardware was causing a problem because of the way the virtual machine software emulated separate cores. We never would have come to such a conclusion without carefully eliminating the many different changes one at a time.
After you’re able to establish exactly which changes caused the performance issue(s) and by how much, you can work on a fix or provide a solid case to whichever software support representative you need to contact to get a fix.
You might know most of this already. You might even know of some methods, tips, etc., for performance issues that I didn’t discuss. Maybe you are clairvoyant and you already knew the contents of this post before I did. Either way, I hope you find this information helpful when you look at performance in the future, in both preventative measures and problem diagnosis.
If you have large (and I mean LARGE) blocks of code in single source files – and by large I mean 20k lines plus – then you may be having compiler issue with “SEGBIG” errors: “Segment too big”. This issue arises because your code segment is just too big for the compiler to handle and is usually the result of many man years of development to a single routine that has just grown over time.
If you encounter SEGBIG issues, as a customer I have recently worked with did, then this quick blog will give you some practical ideas of how to manage the issue and modify the code to allow for future development and expansion, without having to rewrite the world.
First off, it’s not the physical number of lines of code in the source file that’s the issue, it’s the lines of code and data definitions within each routine block: subroutine or function. Developers have encountered the problem for many years and the resolution has previously been to chop out a section of code, make it into a subroutine or function, and somehow pass all the appropriate data to it – usually by large numbers of arguments or common/global data blocks.
The “today” way is not too dissimilar but is a little more refined: turn the code block into a class. The first major advantage is class-based data. This removes the need to create subroutines or functions that accept large numbers of arguments, or to create large common or global data blocks. As an example:
Obviously this code will not give us a SEGBIG issue, but its an example of the structure of the code. The routine has a common data include and private data. In the routine body we make multiple local label calls. When there is too much data and too many lines of code added we will encounter a SEGBIG error.
So to address this, in the same source file, we can create a class with class-level data (the routine level data) and methods for the local call labels. So, for example:
public class BigRoutineClass
private record localData
public method Execute, void
method doSomeLogic, void
method doOtherLogic, void
In this code, the Execute method becomes the entry point. All the existing code that made the label calls is moved into this routine and the calls changed to method invocations;
Then we can change the existing BigRoutine code;
routineInstance = new BigRoutineClass()
Although the code changes I’ve described here sound monumental, if you use Visual Studio to develop your Traditional Synergy code the process is actually quite simple. Once you have created the scaffolding routine and defined the base class with class level data (which really is a case of cutting and pasting the data definition code), there are a few simple regex commands we can use that will basically do the work for us.
To change all the call references to class method invocations you can use:
Find: ([\t ]+)(call )([\w\d]+)
To change the actual labels into class methods, simply use the following regex:
Find: ^([\t ]+)([a-zA-z0-9_]+)[,]
Replace: $1endmethod\n$1method $2, void\n$1proc
And to change the return statements to method returns, use:
These simple steps will allow you to take your large code routines and make manageable classes from them which can be extended as required.
If you have any questions or would like assistance in addressing your SEGBIG issues, please let me know.
If you’re a Porsche enthusiast, you probably know about the Nürburgring record set a few months back by a 911 GT2 RS, the latest iteration of the Porsche 911 (see the Wikipedia article). Like many, I find it interesting that the best* production sports car in the world isn’t a new design, but the result of continuous improvement and development since its introduction over 50 years ago. One company, Singer Vehicle Design, takes old 911s and resurrects them as carbon fiber kinetic sculptures in the aesthetic of the older 911s, but with performance that matches some of the fastest new 911s from the factory. They describe these as “Reimagined,” and you can see a video about a Singer 911 or visit the Singer website for more information.
Here in the Documentation department at Synergex, we’ve been doing some reimagining of our own. The Synergy/DE documentation has been continually improved over the years, but since 10.3.3c, we’ve published the Synergy/DE documentation with a new format, a new look, and a new set of underlying technologies and practices. The goal: documentation that is quickly updated to reflect product changes and user input, that is increasingly optimized for online viewing, and that is increasingly integrated with other Synergy/DE content. (And soon it will be better integrated with Visual Studio as well; see a recent Ideas post for details.) You can access the doc just about anywhere (even without internet access), it offers better viewing on a range of screen sizes, and it’s poised for further improvements. If you haven’t seen our new “reimagined” doc, check it out at synergex.com/docs.
Here are some of the highlights:
- A better, more responsive UI for an improved experience when viewing documentation from a desktop system, a laptop, or a tablet.
- Technologies that facilitate more frequent updates and allow us to increasingly optimize content for online use.
- Improved navigation features. The Contents tab and search field adapt to small screens, the UI includes buttons that enable you to browse through topics, and a Synergy Errors tab makes it easy to locate error documentation.
- Quick access to URLs for subheadings. To get the URL for a topic or subheading (so you can share it or save it for later), just right-click the chain-link icon next to a heading and copy the link address.
- The ability to print the current topic (without printing the Contents tab, search field, etc.) and to remove highlighting that’s added to topics when you use the search feature.
- Local (offline) access. If you’re going somewhere where internet access is limited, download and install the Local Synergy/DE Product Documentation, which is available on the Windows downloads page for 10.3.3.
See the Quick Tips YouTube video for a brief visual tour of the documentation, and let us know what you think. In the footer for every documentation topic, there is a “Comment on this page” link you can use to send us your input. We look forward to hearing from you!
*Just an opinion!
For a recent project I’ve worked with a customer who wished to provide their users with an engaging desktop application that would allow management of product formulations. They had a Synergy UI Toolkit version and also elements of the required application in a third-party system. However, neither met the needs of the users. After a review and discussions about their requirements we agreed on a Synergy .NET Windows Presentation Foundation based application using Infragistics tooling for the User Experience.
The basic requirements of the application where to allow the creation and maintenance of formulations. A formulation contains the components required to make a finished product. For this customer the final product is an aerosol.
Let’s take a look
The basic interface is built using the Infragistics control to handle navigation (Ribbon menu control), listing and selection of data (powerful DataGrid), hierarchical representation of the formulation components (TreeView) and management of finished product details (Property Grid);
Of course, using the Infragistics DockManager allows the user to drag and reposition all the available windows to their liking.
There are powerful searching facilities, or QBE (Query By Example) controls. These allow the user to provide snippets of information and the application will query the Synergy DBMS database using Symphony Harmony and the Synergex.SynergyDE.Select class;
The top line of the QBE controls allow the user to enter the data in the columns they wish to search for and so only select the data they require and not have to filter through a list of thousands of formulations.
Because the application is written in Synergy, the existing printing capabilities from the original UI Toolkit application have been retained without change;
The whole application is written in Synergy .NET and utilises the Symphony Framework for controlling the data access and presentation. If you would like more details, or would like to know how you can build modern applications with Synergy .NET please drop me an email.
We are pleased to announce the release of CodeGen version 5.2.3. The new release includes new features, addresses some issues found with previous releases, and also paves the way for once again being able to use CodeGen on non-Windows platforms through experimental support for the .NET Core environment.
As always, you can download the latest version of CodeGen from here.
CodeGen Version 5.2.3 Release Notes
- Added a new experimental utility to the distribution. The Code Converter utility can be used to automate bulk searches within and bulk edits to an applications code. This utility is in a usable form. However, it is still a work in progress and is likely to undergo substantial changes as it evolves.
- Added two new utility routines (IsDate.dbl and IsTime.dbl) that are referenced by some of the supplied sample template files.
- Corrected a regression that was introduced in the previous release which caused the field loop expansion token <FIELD_SQL_ALTNAME> not to default to using the actual field name if no alternate name was present.
- Performed an extensive code review and cleanup, updating the code in several areas to take advantage of new features available in the Synergy compiler, and also improving efficiency.
- Fixed an issue that was causing the CreateFile utility -r (replace file) option to fail, an existing file would not be replaced even if the -r option was specified.
- Fixed an issue in the CreateFile utility that would result in an unhanded exception in the event that invalid key information was passed to XCALL ISAMC.
- Made some minor code changes to allow CodeGen to be built in a .NET Core environment and we hope to be able to leverage .NET Core to once again support the use of CodeGen on non-Windows systems (starting with Linux) in the near future.
- This version of CodeGen was built with Synergy/DE 10.3.3d and requires a minimum Synergy version of 10.1.1 to operate.
Symphony Framework Components
- We no longer ship the Symphony Framework sample templates with CodeGen. You can obtain the latest Symphony Framework templates from the Symphony Framework web site (http://www.symphonyframework.net).
- There were no Symphony Orchestrator changes in this release.
- There were no Symphony Framework CodeGen Extensions changes in this release.
We are delighted to announce the availability of the CodeGen version 5.2.2 release that includes the following enhancements and changes:
CodeGen Version 5.2.2 Release Notes
- Added a new field loop expansion token <FIELD_FORMATSTRING> which can be used to access a fields format string value.
- Added a new command-line option -utpp which instructs CodeGen to treat user-defined tokens as pre-processor tokens. This means that user-defined tokens are expanded much earlier during the initial tokenization phase, which in turn means that other expansion tokens may be embedded within the values of user-defined tokens.
- Removed the RpsBrowser utility from the distribution; it was an experimental project that was never completed.
This version of CodeGen was built with Synergy/DE 10.3.3d and requires a minimum Synergy version of 10.1.1 in order to operate.
Most Synergy developers would love to use the very latest and greatest development tools to develop and maintain their Synergy applications, but how do you get started? At the recent DevPartner conference in Atlanta product manager Marty Lewis not only discussed the concepts of how to get started, but actually demonstrated the entire process with a real Synergy application. Check out his presentation entitled Developing Synergy Code in Visual Studio:
By the way, this video is just one of many from the 2017 DevPartner Conference.