News and Updates for Synergy/DE Developers

June 14, 2013

There are some exciting new developments in the works

Find out what's next for Synergy/DE

Read More

Introducing the power and flexibility of ISAM REV 6

By John Brunett, Senior Software Engineer

Read More

---

Quiz

Take Quiz

Synergy/DE Tech Tip

Which libraries do you need when running Synergy/DE on Linux?

Read More

---

Platform News

Read More

Synergex's first patch to Synergy/DE 10.1 is now available to download.

In addition to numerous quality improvements, version 10.1.1a includes new features that improve code optimization, make Synergy easier to use, and increase Synergy DBL compatibility with other .NET languages. Features include:

• Case-insensitive SELECT queries
• String class methods for traditional Synergy
• Synergy .NET language enhancements
• Visual Studio enhancements

10.1.1a is supported on Synergy/DE's Windows, OpenVMS, and Unix/Linux platforms. Learn more about 10.1.1a at the Synergy DevPartner conference.
View the 10.1.1a release notes (Resource Center password required).
Download 10.1.1a now.

---

By John Brunett, Senior Software Engineer

One of the highlights of Synergy/DE version 10 is a new revision of ISAM files. REV 6 ISAM comes with several new features, as well as plenty of room for growth before a future revision upgrade is required.

REV 6 includes a new on-disk file structure that's optimized for the new "Advanced Format" large sector drives being sold today. All index blocks are now aligned to 4K by default. (As a result, to make room for the new 8K header and 4K default PAGE size, you can expect empty ISAM files to take a slightly larger disk footprint.)

Along with the new file structure, a few other features are well worth mentioning. One is a new key type called an autokey. An autokey is a key declared in a file's record that is automatically filled-in by the Synergy DBMS. In Version 10.1, two types of autokeys are supported: a sequence autokey and a timestamp autokey. The sequence autokey is simply an i8 counter that increments each time a new record is stored. The timestamp autokey is an i8 datetime (in microseconds) that is set to the current time when a record is stored and again when the record is updated. Using the %DATETIME_FROM_I8 routine, you can convert the i8 datetime value to a string similar to that returned by %DATETIME. Both of these autokeys are guaranteed to be unique in a file.

Another exciting new feature is Change Tracking, which allows you to transparently keep track of all changes made to a file. After enabling Change Tracking on a file, you can replicate to a central database changes made between two points in time (snapshots), roll back changes made on a failed posting run, or access records exactly as they were at a single point in time. How you actually use Change Tracking is up to you, but the possibilities are endless. More details on Change Tracking will appear in a future article.

If you're using GRFAs (which were released in version 9.3), you might be interested in the new Stored GRFA feature. GRFAs can be used to implement optimistic locking. One of the caveats discovered with this technique is that the extra overhead required to generate the GRFA can have a negative effect on performance. Our new SGRFA file option, however, moves that overhead to the STORE and WRITE operations, which occur far less often than the READ/READS operations, thus resulting in better performance.

Also new with REV 6 is the ability to store text to a file's header and then programmatically retrieve it later. What text you store is entirely up to you. You might store a name to identify a particular file, your file's version string, a string that identifies field types and offsets, or an entire XML document describing your file. Then, using %ISINFOA (FILTXT), you can retrieve that information whenever you need it. Initially, with Synergy version 10.1.1, you must define your file text upon file creation, and the text is read-only. In a future release, you will be able to modify the file text at any time.

To prepare for the future, the maximum TBYTE file size in a REV 6 file has been increased from 1Tb to 256Tb. Also, there are several new defaults for REV 6 files: static RFA is now default and is required for all files, the default PAGE size has been increased from 1024 to 4096, and files configured with Change Tracking also include the TBYTE (addressing=48) file attribute.

Patching and converting a prior-revision file to REV 6 are slightly different than in previous releases. The isutl utility is now used in both cases. Using isutl -p, small files are automatically converted, but larger files that will take longer to convert are only patched. When patched, a file becomes an intermediate REV 6 file (designated 4r6 or 5r6 when viewed from ipar). This intermediate revision is much like the REV 5 revision, which was the result of patching old revision 2 and 3 files. However, an intermediate REV 6 file is automatically converted to a full Revision 6 file the next time it is cleared or rebuilt using isutl. Also, you can choose to override the patch or convert decision by explicitly specifying the isutl -qfile=[no]convert option.

To facilitate future growth, a Revision 6 file now contains a compatibility level. As new file features are added that change a file's structure, using one of these features in a file will appropriately elevate the compatibility level for that file such that an older Synergy version will not be allowed access (although it will still have access to files without that feature). This enables us to add new features that require structure changes without requiring a new file revision to be introduced.

For more information about REV 6 ISAM, see the Synergy Tools manual and the version 10.1 Quick Migration Guide.

Learn more about REV 6 ISAM at the Synergy DevPartner Conference.

Synergy/DE pros, see if you can answer this question!

Assuming the following:

1. myIPAddress resolves to a real host that can accept connections.
2. myPort is a valid port on myIPAddress and will accept the connection.
3. MYFILE.TXT exists (and in this case is 6088 bytes long).
4. The program is linked against WND:tklib.elb.

What will the program below output?

1. message box with Success!
2. message box with Socket error = n (where n is the error number)
3. message box with File error = n (where n is the error number)
4. any of the above (a) - (c) could happen
5. it won't compile
6. it won't run

main
external function
        transmit_file   ,^val
record
        errFlag         ,int
        myIPAddress     ,a*,"127.0.0.1"
        myPort          ,int,1000
        
proc
        xcall u_start
        if (%transmit_file("MYFILE.TXT", myIPAddress, myPort, errFlag)) then
                xcall u_message("Success!")
        else if (errFlag > 0) then
                xcall u_message("Socket error = " + %string(errFlag))
        else
                xcall u_message("File error = " + %string(-errFlag))
        xcall u_finish
end

;----------------------

function transmit_file  ,^val
        req in argFileToSend    ,a
        req in argIPAddress     ,a
        req in argPort          ,n
        req out argErrorCode    ,n

.include "DBLDIR:synsock.def"

external function
        get_actual_file_size    ,^val
        get_buffer_from_file    ,^val
        
.define M_BADRET(f)     if (argErrorCode = f) freturn false 

record fileBuffer
        bufferField             ,a2048

record
        actualLength            ,int 
        fileChannel             ,int,0
        localAddress            ,D_ADDR 
        packet_length           ,int
        socket                  ,D_ADDR 
        totalBytes              ,int,0

record
        group trxStartPacket    ,a
                soh             ,a1
                length          ,d10
                stx             ,a1
        endgroup
        trxEndPacket            ,a1,%char(3)
        
proc
        trxStartPacket.soh = %char(1)
        trxStartPacket.stx = %char(2)
        
        M_BADRET(%get_actual_file_size(argFileToSend, fileChannel, trxStartPacket.length))
        M_BADRET(%ss_inet_addr(argIPAddress,localAddress))
        M_BADRET(%ss_socket(socket, SS_SOCK_STREAM))
        M_BADRET(%ss_connect(socket, argPort, localAddress))
        M_BADRET(%ss_sendbuf(socket, trxStartPacket))
        
        packet_length = ^size(fileBuffer.bufferField)
        repeat
                begin
                M_BADRET(%get_buffer_from_file(fileChannel, fileBuffer.bufferField, actualLength))
                M_BADRET(%ss_sendbuf(socket, fileBuffer.bufferField(1:actualLength)))
                ;; in case we want to keep track of how much has been sent...
                totalBytes += actualLength
                if (actualLength != packet_length) exitloop
                end
        
        M_BADRET(%ss_sendbuf(socket, trxEndPacket))
        freturn true
end

;-----------------------

function get_actual_file_size   ,^val
        req in  argFileName     ,a
        req inout argChannel    ,n
        req out argTotalLength  ,n

record
        actualFileName  ,a500
        actualSize      ,int,0
        errFlag         ,int
        
proc
        clear argChannel
        xcall u_open(argChannel, "I", argFileName,,, errFlag)
        if (errFlag)
                freturn -errFlag                ;; return negative value with file issues
        xcall filnm(argChannel, actualFileName)
        ;; there are OS specific ways to do this as well as the ability to read to end of file and
        ;; determine the length that way.
        ;;
        ;; For the purpose of this exercise, assume the "best" approach for the situation has been
        ;; followed and the result is in actualSize
        ;;
        ;; We will leave determining the approaches to this to another exercise...
        ;; for now, we will hard code a value...
        actualSize = 6088
        
        argTotalLength = actualSize
        freturn 0
end

;-----------------------

function get_buffer_from_file   ,^val
        req in  argChannel      ,n
        req out argBuffer       ,a
        req out argActualLength ,n

record
        retval  ,int
        
proc
        retval = 0
        
        try 
                begin
                gets(argChannel, argBuffer)
                argActualLength = ^size(argBuffer)
                end
        catch (ex, @Synergex.synergyde.EndOfFileException)
                begin
                ;; we hit end of file, so figure out our actual length
                argActualLength = %rsize
                ;; close the channel - we don't need it anymore
                xcall u_close(argChannel)
                end
        catch (ex, @Synergex.synergyde.SynException)
                begin
                ;; any other type of error should return a bad result
                retval = -ex.Errno
                ;; before we return, we should try to close the file
                xcall u_close(argChannel)
                end
        catch (ex, @Exception)
                begin
                ;; any other type of error should just return a bad result, but we don't know the number
                retval = -9999
                ;; before we return, we should try to close the file
                xcall u_close(argChannel)
                end
        endtry
        
        freturn retval
end

--------------------------

Click here to read the answer.

Which libraries do you need when running Synergy/DE on Linux?

Recently, several customers have reported problems with missing libraries on Linux. Unfortunately, the error returned is more mystifying than illuminating, with text such as "no such file or directory" and no mention of the missing library name. We suspect that a recent OS update may have caused this problem.

On all Linux platforms, Synergy/DE requires these libraries:

libstdc++.so.6  (required by the compiler)
libc.so.6  (required by all Synergy components)
libncurses.so.5  (required by the runtime -- dbr and dbs)

If these are not present on your system, download and install them using a package manager. (Some common package managers are apt-get, dpkg, rpm, and yum.) For example, you can download libraries for Red Hat from http://rpmfind.net/linux/RPM/index.html, libraries for Ubuntu from http://packages.ubuntu.com, and for information on Fedora packages start at http://fedoraproject.org/wiki/Using_the_package_database.

There's an easy way to check which libraries are required by any application: Just run the ldd (that's a lowercase 'L') command followed by the program name. This command is supported on all Unix platforms. For example, to see which libraries the Synergy runtime requires, you'd use this command:

ldd dbr

For more information on Linux libraries and other Linux installation issues, see Synergex KnowledgeBase article 2094.  

---

Read a selection of recent articles

Windows

Microsoft rushes out early-bird release of Visual Studio 2013
http://www.infoworld.com/t/microsoft-net/microsoft-rushes-out-early-bird-release-of-visual-studio-2013-219793

Developers clamor for unified dev tools for Microsoft's 3 OSs
http://www.computerworld.com/s/article/9239836/Developers_clamor_for_unified_dev_tools_for_Microsoft_s_3_OSs?taxonomyId=89

Java

Java: Out of the spotlight, but still spry
http://www.infoworld.com/t/java-programming/java-out-of-the-spotlight-still-spry-220129

Oracle reveals plans for Java security improvements
http://www.infoworld.com/d/security/oracle-reveals-plans-java-security-improvements-219744

 

---

Synergex holiday reminder

Back to top