Open topic with navigation
This topic includes the following DBL features:
With the number of security regulations on the rise, data encrypting has become a critical requirement for most application developers. Synergy DBL enables you to encrypt and decrypt sensitive data using industry standard cipher techniques. This is accomplished on an on-demand basis using a set of Synergy subroutines that encrypt and decrypt a specified data region. You determine which data is encrypted as well as how it is encrypted.
The Synergy data encryption feature interfaces with a third-party library, OpenSSL, to provide SSL support. We use PKCS #5 (Password-Based Cryptography Specification) in conjunction with PBKDF2 key derivation function (an ISO standard) provided by OpenSSL. To learn more about PKCS, visit tools.ietf.org/html/rfc2898.
See Data encryption for more information.
As of version 9.1, Synergy DBL provides strong prototype validation of system-supplied routines at compile time. This means that the compiler compares each system-supplied routine used in your program to its prototype to ensure it has the correct number and type of arguments, correct return type, and so on. (If you need to relax some of the strong prototype validation, use the -qrelaxed option(s) when you compile.)
Synergy .NET code that you write is always strongly prototyped. For traditional Synergy object-oriented code, strong prototyping is required and takes place within a compilation unit at compile time. However, outside a compilation unit, such as when you use multiple dbl commands, you must generate prototypes with the Synergy Prototype utility so that validation can take place.
Traditional non-object-oriented code can also be strongly prototyped using the Synergy Prototype utility. Doing so will ensure that calls match their routine definitions, which enables you to detect more problems at compile time rather than waiting until runtime. If a prototype exists, the compiler will check the signature of the prototype to ensure it matches the declaration.
For nonprototyped routines in the same compilation unit, the compiler will automatically perform weak prototype checking. This means the compiler will issue warnings based on the local definitions that are available at compile time. The amount of checking that takes place depends on the information available to the compiler. (If you need to relax some of the weak prototype validation, use the -qrelaxed:local option when you compile.)
See Synergy Prototype utility (dblproto) for more information on prototyping.
An often-overlooked developer tool is the Synergy DBL Profiler. The profiler provides information that enables you to analyze the resources required by your application. It can help you significantly improve application performance by identifying the areas that are not as efficient as they could be.
Two profiling techniques are available:
You can also exclude specific routines from the profiler trace by specifying an exclusion list. (See Decoding the profile.dat or lines.dat file.)
Profiling is enabled either by setting system option #40, #41, or #52 and using the profiling compiler option (-u on Windows and UNIX or /profile on OpenVMS) or by setting system option #42. (Refer to Synergy DBL Profiler for the distinctions between these system options and under what circumstances you would want to use each one.) When you execute your program, profiling information is stored in a file called profile.dat. You can then run the profile or profline utility (depending on whether you are using routine profiling or line profiling) to produce a report of the results.
You can send messages between routines using the SEND and RECV statements. Synergy DBL provides two types of message facilities to process these messages: the local message facility (which is the default) and the Synergy message manager. Using these message facilities, your program can communicate with other programs that are currently running or that will be running soon. For example, a program can send messages that affect how processing will be performed by programs to which it subsequently chains.
Both message facilities maintain local, group, and global queues. If you only use the local message facility, messages are only available to the current job stream. Routines are in the same job stream if they are called as subroutines or functions or if they are chained to. On OpenVMS, routines that are chained to are only considered to be in the same job stream if the program is bound. Once the runtime terminates, message queues are reinitialized.