Register today for the 2015 Synergy DevPartner Conference May 11-15 in Philadelphia, PA

"There is no question that attending the conference is beneficial. Having direct access to other Synergy/DE users and the Synergex personnel is priceless. A simple five minute conversation at last year's conference dramatically changed our development environment!"

- Nick Hennemann, Jack Henry

The 2015 Synergy DevPartner Conference is packed with informative sessions, customer demonstrations, and instructional hands-on workshops to illustrate how your applications can benefit immediately from the latest Synergy/DE enhancements. 

Are your Synergy/DE skills a little rusty? Haven’t been to a conference in a few years? No worries. Join us on Monday, May 11 for a pre-conference workshop to get you up-to-date on Synergy/DE so you’re ready to jump right in when the conference begins.

Can’t wait to get your hands dirty with the latest and greatest? Stay on for an extra day to learn advanced topics such as running applications on mobile devices. Sign up for the post-conference workshop on Friday, May 15.

Register at http://conference.synergex.com.

The difference in Synergy device licensing

By James Sahaj, Project Manager, Synergy .NET compiler

Experienced Synergy developers are familiar with traditional Synergy server-based licensing. When a Synergy application starts up, it sends a license login request to a Synergy license server. If the quota for that license has not been reached, the request is granted and the program can proceed. Otherwise, the user is prevented from running the application. This licensing model has worked very well for many years over a large selection of computer platforms supported by Synergy DBL. However, this model makes a big assumption: that the client program can connect to the license server every time the program is run.

Over the past few years devices have taken hold of the industry. Most devices are connected to the Internet; however, assuming a device can always connect to a license server sitting somewhere locally on the network all the time is a mistake. Sometimes devices are used in scenarios where they are purposely not connected to any network or to the Internet. For example, delivery drivers may download their schedules in the morning and not reconnect their devices to the network until they get back later in the day. This type of disconnected computing does not fit well with the traditional Synergy licensing model.

Device licensing is a new 10.3 licensing model that supports a “sometimes connected” scenario. That is, at some point the device has the ability to connect to the Internet. When this happens, the device can be authorized to use a license for 30 days. Before that 30-day period is over, the device renews the license with the Internet-based license service for another 30-day period. This ability to be connected only sometimes is a great advantage and suits the work environments in which some devices are used.

It is important to note that traditional Synergy licensing makes a login request every time the program is run. If the program cannot reserve a license, the program is prevented from executing. Device licensing is a bit more forgiving. When the program is run for the first time, the device license client runtime attempts to connect to the device license service to reserve a license using authorization information entered by the user. If it can connect, the request is made, and, if the authorization information is correct, the license is reserved for 30 days. If it can’t connect, or if the authorization information is incorrect, the client program is put into a 7-day grace period, and the client program is allowed to run unobstructed for those 7 days. While under the grace period, the user is re-prompted to activate every time the program is run. Once successfully activated, the program will run, unprompted and unobstructed, for 30 days. During the last 7 days of that period, the device licensing client runtime will quietly attempt to synchronize the license to renew the licensing period for another 30 days, and it will continue this cycle every 30 days until the license subscription expiration is reached. If the customer is unable to activate the device before the initial grace period ends, the runtime will prevent the application from starting.

As previously described, for traditional Synergy licensing a Synergy license server must run somewhere on the network on which the client runs. For devices that are not always on the local network, that would mean the license server would have to run on the device itself. However, installing a license server on every device requires too much overhead and a lot of unnecessary installations on the client, making the configuration of regular Synergy licensing unwieldy and impractical for devices.

In contrast, device licensing uses an Internet-based license service to make licensing requests. For device licensing to work, each device must have the device licensing client runtime installed and HTTPS access to the device license service only when a device request is made. This device license service, found at https://licensing.synergex.com/licensing, supports four different types of licensing requests: get a unique device identifier, activate a device, synchronize a device, and deactivate a device. Because the service is web based, Synergex can set up an entire purchased block of licenses for a customer before the devices are given to users. This makes the installation and distribution of licenses much easier, because it reduces the amount of work required to install on each device. In addition, license administrators can access extra functionality through the Synergy licensing website for such tasks as revoking an entire license block, defining new password/token combinations, or deactivating a particular device on the website if a device becomes lost or stolen.

Traditional Synergy licensing doesn’t require any extra coding unless you use the Synergy/DE Licensing Toolkit API to enforce licensing for your application.  Support for device licensing, on the other hand, takes a bit more coding. For device licensing you will need to add the assembly attribute SynergyDeviceLicenseAttribute and provide an implementation of the ISynergyDeviceCallback interface containing three methods: Init, ActivationDialog, and Synchronize.

• Init initializes the device by making a call to DeviceLicensing.GetDeviceGUID().
• ActivationDialog should present a dialog to get a token, password, and device description and make a call to DeviceLicensing.Activate() to activate the device license.
• Synchronize should make a call to DeviceLicensing.Synchronize() to renew the device license.

Within your implementation of these methods you should handle error conditions returned from calls to the license service and display the results as you wish.

You can find WPFDeviceLicense, an example of the recommended use of device licensing in a WPF application, in Synergy CodeExchange in the Resource Center on the Synergex website. Also, you can check out the Android version of device licensing by creating a Synergy Android application using the project template in Synergy/DE version 10.3. Synergy device licensing makes installing, configuring, managing, and using licenses on a device much easier. If you haven’t seen it in action yet, grab Synergy version 10.3 today and see for yourself.

For more information about Synergy/DE 10.3, go to our Web site.

Read how a Synergex customer is using the new device licensing and saving their customers thousands!

Ensuring data integrity with binary data

If your data files have binary data, you’ll need to take precautions to prevent data corruption or loss when using Synergy DBMS utilities, particularly when unloading and reloading ISAM files on Windows and UNIX systems. When unloading and loading files, some portions of binary data can be mistaken for record terminators or control characters, resulting in unexpected record splits and other data corruption. But don’t let this stop you from using binary data. By keeping a few things in mind, you can prevent these problems from occurring.

But first, you may not be aware of how many types of fields and keys result in binary data in data files. For example, did you know that this is true of the ISAM Revision 6 autokey types (SEQUENCE, TIMESTAMP, and CTIMESTAMP)? This is because autokey types are i8 keys, and all integer values are stored as binary values in data files. This includes integer fields and keys, alpha fields with characters less than 0x20 or greater than 0x7E, fields with RFAs, and autokeys.

If you do have binary data in your files, keep the following in mind:

• Unloading data into sequential or stream files can cause data corruption or loss. Once the data has been unloaded to a sequential or stream file, Synergy utilities probably won’t be able to interpret the binary data correctly when the file is reloaded.
• We highly recommend using fconvert to unload and load (convert) files with binary data. Fconvert is faster than other utilities and is less likely to cause corrupted or lost data when used properly. Unload to a relative or counted file (‑or or ‑oc), and then reload using thecorresponding switch. For example, if you unload the file using ‑oc to create a counted file, use ‑ic when you load the ISAM file. 
• Isutl ‑f (load) can result in data corruption or loss if used incorrectly. It should never be used on a sequential file that contains binary data, unless the file is a counted file. In that case, use the ‑k option.
• Native integers cannot be moved to a system with a different endian type—with some exceptions: Integer keys, fields with RFAs, autokeys, and portable integer data (explicitly qualified by the portable integer ISAMC option—e.g., I=20:4). All other integers must be converted to portable integers with %CNV_IP and %CNV_PI.

And remember that except for ISAM files, fconvert and other Synergy DBMS utilities have no way to determine a file’s type. They can’t tell whether a file is a sequential file, a stream file, a relative file, or a counted file. If you frequently unload a large number of files, you can use a naming convention to keep the file types straight for yourself. For example, counted files could always have a .cnt extension, while relative files could have a .rel extension. (By default, all non-ISAM files are .ddf.)

We will be closed Monday, February 16, in honor of Presidents’ Day.

If you anticipate needing our assistance on this day, please let us know.