This topic includes the following DBL features:
Data encryption
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.
Prototyping
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 (dblproto) 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.
All non-private types (structures that aren’t inside a routine, classes, enums, etc.) are also prototyped. If a prototype for a type exists, it will check the prototype against the actual type declaration to ensure they match. These prototypes determine whether an argument passed to a routine matches the parameter type. If an imported prototyped type doesn’t match the real definition, a prototype mismatch error will occur at compile time.
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.)
Profiling
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:
- Routine profiling, which shows which routines are being accessed and what resources are associated with each routine, gives you a picture of a program’s execution process.
- Line profiling, which shows you which lines in a routine are being executed the most, enables you to identify potential bottlenecks within a routine.
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.
Messaging
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.
Printing
On Windows, we recommend using the Synergy Windows Printing API for printing. (The LPQUE statement is also available, but it is deprecated on Windows.)
On Unix, you have two options:
- For spooled printers, use the LPQUE statement.
- For nonspooled printers, open the device directly and write to it. (However, if more than one person is printing at the same time, the print jobs will be intermixed.) For example,
open(1, o, "/dev/tty02")
On OpenVMS, you can
- Open the device directly. On spooled printers, OpenVMS directs the output through the spooling system so the printer is not locked by one process. On nonspooled printers, it is your program’s responsibility to handle device sharing between processes.
- Use the LPQUE statement to add a job to the print-batch services queues.
