|
CUSTOMER
SUCCESS STORY: SYNERGY/DE CUSTOMER JACK HENRY RELEASES BROWSER-BASED
VERSION OF CORE DIRECTOR BANKING APPLICATION
Monett,
MO and Gold River, CA, June 7, 2004--Jack Henry & Associates,
Inc., announces the release of a browser-based version of
their Core Director application. Already live at 15 sites,
the new version enables bank personnel to access their customers'
account and transaction details via an easy-to-use browser
user interface.
Recently
ranked as one of "100 Fastest-Growing Technology Companies"
in Business 2.0 magazine, Jack Henry & Associates,
Inc., provides integrated computer systems and processes ATM
and debit card transactions for banks and credit unions. Looking
for a new, more modern interface for their Synergy/DE-based
Core Director application, they recently decided to upgrade
to Synergy/DE 8.1 and browser-enable their application.
To read
the entire press release, visit the Synergex
Web site.
^
Top
SYNERGY/DE
8.1.7 BETA TEST ENDS; GENERAL RELEASE PLANNED FOR JUNE 28
The beta
test for Synergy/DE 8.1.7 has ended, and the Synergy/DE team
is preparing to release at the end of this month. Here's what
one beta tester had to say:
"We are very anxious to see how customers react to
our product, following our own recent engineering efforts
and the inclusion of new Synergy/DE features and functions.
Aside from all the many other enhancements in Synergy/DE 8.1.7,
we are especially interested in the ability to specify the
TCP port number programmatically for xfNetLink .NET.
We are also getting positioned to fully utilize the current
Synergy DBMS utilities, such as isutl, which have been enhanced
in the past few Synergy/DE releases."
-Keith
Schneider
WorkWise
Synergy/DE 8.1.7 beta tester
The 8.1.7 feature Keith refers to enables developers using
xfNetLink .NET to specify the xfServerPlus host
and port at runtime. This means you can now change these settings
programmatically instead of specifying them in a configuration
file, as was previously required. The new process is easier
and offers you much more flexibility. (Note that this feature
cannot be used with pooling.)
Version
8.1.7 will provide important improvements to developers, including
| - |
|
Support
for more image file formats, such as GIF and JPEG, in the Synergy Windows
printing API and on UI Toolkit buttons. (Synergy/DE currently
supports only the BMP format.) |
 |
| - |
|
Support for the XML "CDATA" syntax,
which will enable users to embed XML
or HTML content within XML documents |
|
| - |
|
Performance improvements
in the Synergy XML API |
|
| - |
|
Support for passing
variable-length arrays of structures in xfNetLink .NET and
xfNetLink Java |
|
| - |
|
Support for custom
package names in xfNetLink Java |
|
| - |
|
xfODBC enhancements
to improve our support of COGNOS Impromptu and certain
Microsoft products |
|
| - |
|
Miscellaneous fixes
to many Synergy/DE products |
Synergy/DE
8.1.7 is on target for general release on June 28. Stay tuned
to Synerg-E-News for details.
^
Top
SUPPORT
TECH TIP: File record length versus performance
Question:
I have a Synergy ISAM file with variable-length records where
the maximum record length is 1400 bytes, and I'd like to be
able to write larger records in the future. Can I change the
maximum record length to something like 5K or even 6K without
affecting performance?
Answer:
Generally yes. However, in terms of overall performance, there
may be some additional things to consider. Overall performance
can be measured using the following criteria:
1. File access performance (read/write performance)
2. File size performance (disk usage)
3. File recoverability performance (best file recovery in
the event of failure)
File Access Performance
The disparity between the maximum record size and the actual
record size written will have little impact on performance.
In other words, a 1K record written to a file with a maximum
record size of 1400 will perform similarly if the maximum
record size is changed to 6K, because it's the same 1K record
written both times. Therefore, there's no difference in access
performance.
File Size Performance
The larger the disparity between maximum record size and actual
record size written, the greater the potential for wasted
space used by a Synergy ISAM file. Wasted space is measured
in terms of unused bucket space. All variable-length data
segments are sized based on 32 different bucket sizes, which
are multiples of the overall maximum record size. A maximum
record size of 1400 separates the buckets by about 44 bytes,
whereas a maximum record size of 6K separates the buckets
by about 192 bytes. So, a record segment that exceeds the
size of a bucket by only 1 byte will be deposited into a bucket
of the next size, wasting 191 bytes. On average, you could
expect about half of that to be wasted per record. You can
view the bucket allocation for a Synergy ISAM file by using
isutl -vb (or ismvfy -b). Since disk space is relatively inexpensive
these days, this may not be an issue. However, read and write
access (due to disk seek time) may perform poorly on a very
large data file if the file is not contiguous. Use a disk
defragmenter to make the file contiguous, and isutl -ro to
optimize the data (ordered contiguous with respect to a commonly
used key). Compressing the data (using the COMPRESS file option)
is also a good way to reduce the size of the data file.
File Recoverability Performance
While not usually considered performance, file corruptions
do happen, and file recovery is very important when it comes
to the amount of time spent restoring a file. The most common
form of file corruption is when the index gets out of sync
with the data file. Total recovery of this sort of corruption
is as simple as creating a new index, which is very quick
using the isutl utility (using just the -r option). In some
rare instances, though, the data in the data file itself becomes
corrupted. In these cases, total recovery is not possible,
and the amount that is recovered may depend on certain file
attributes. When raw data is written to the data file, it's
very difficult for any utility to recognize where one record
stops and the next starts. As long as all the records in a
fixed-length record file remain constant, or all the variable-length
records start immediately following the previous variable
record segment, only the bytes of the record containing the
corruption will be lost. It is more likely the case where
a fixed record gets written out with the wrong size (which
is typically seen after a system crash) or a variable-segment-length
byte somehow gets clobbered in a variable record file, and
all remaining records to the end of the file are not recoverable.
However, by simply adding data compression, you not only reduce
the overall size of a record being written (reducing the overall
disk usage as well as reduced disk seek time), but you also
provide a tracing mechanism for recovery. Files that employ
data compression have the best rate of recovery. The isutl
utility (using the -a option) has the ability to identify
a bad data segment and then re-sync to the next valid data
segment (using the compression codes) and resume recovery.
This is not possible without data compression. Also, the overhead
in performance added by data compression is usually absorbed
by its performance benefits (disk usage and seek time).
So, perhaps the most important thing to consider on any Synergy
ISAM file (and especially one with large records) is to add
data compression. Note: When using RFAs or manual locks in
a file that is compressed, it is important that you also add
the STATIC_RFA flag to the file to keep RFAs static after
record updates.
A future enhancement is in the works for isutl to optimize
the bucket sizes of an existing Synergy ISAM file based on
its contents. This would allow you to create a file where
the maximum record size is unlimited (only limited by the
physical 64K file record limit) without paying the cost of
wasted space.
^
Top
WARNING
FOR DEVELOPERS USING MICROSOFT ACCESS WITH SYNERGY/DE xfODBC
A recent
Microsoft security update for Windows (kb837001) includes
Microsoft Jet 4.0 Service Pack 8. (Jet is a database engine
that sits between Microsoft Office and ODBC drivers such as
xfODBC.) It has been reported that this Jet service
pack may cause significant performance issues when using Microsoft
Access with xfODBC. (We are also aware of at least
one other database having similar performance problems.) While
we work with Microsoft to determine the cause of these issues,
we strongly recommend that customers using Microsoft Access
with xfODBC wait to install the security update or
Jet Service Pack 8. Customers who have already installed the
security update or Jet Service Pack 8 and are experiencing
slowdowns in Microsoft Access should uninstall the update
or service pack.
Once these
performance issues have been resolved, we recommend that customers
upgrade to Synergy/DE 8.1.5 or 8.1.7 (to be released June
28) before installing the security update or Jet Service Pack
8. (Note that Synergy/DE 8.1.3 is the minimum Synergy/DE version
that works with Jet Service Pack 8, so you must at least be
running 8.1.3. Also note that Synergy/DE 8.1.7 will include
an optimization that improves performance on select statements
where Microsoft Access requests data using a segmented key
of more than one column.) As always, in order to ensure optimum
xfODBC performance and reliability, customers upgrading
third-party products or operating systems should also upgrade
to the latest version of Synergy/DE.
ANOTHER
NOTE ABOUT MICROSOFT ACCESS
As a reminder, we strongly advise against using Microsoft
Access (or Query or other applications that use the Microsoft
Jet database engine) to update Synergy databases. These applications
often have record-locking issues (they may lock more than
just the record that's being updated), and there are often
no referential checks or triggers to ensure database integrity.
In addition, these applications may allow users to make bulk
changes without your control. To update a Synergy database,
we recommend that you use a Synergy application that is designed
to maintain database integrity.
^
Top
ARE
YOU USING ANOTHER BRAND OF LINUX?
There
are many companies and organizations offering Linux solutions:
Red Hat, SuSE, Mandrake, and Debian to name just a few. Synergex
has chosen to support the most popular brands of Linux being
used by our customers, Red Hat and SCO Linux. Although these
are the only Linux platforms Synergex officially supports,
we have successfully tested Synergy/DE with SuSE, and customers
have successfully used Synergy/DE with other Linux platforms.
We would
like to find out what other platforms are working successfully
with Synergy/DE. If you are using Synergy/DE on a brand of
Linux other than Red Hat or SCO, please send us an e-mail
and let us know a) what brand of Linux you are using, b) what
version of that brand you are using, and c) which Synergy/DE
version you are using.
^
Top
EDUCATION
LISTINGS
June 14-18,
2004, Synergy/DE
UI Toolkit Essentials--Billings, MT
June 21-25,
2004, Synergy/DE
Integration Essentials for Advanced Programmers ("Advanced
Synergy/DE Class")--Gold River, California
October
11-15, 2004, Synergy
Language Essentials--Gold River, California
^
Top
Subscribe
to Synerg-E-News.
To view
past headlines from Synerg-E-News, see the Synerg-E-News
Archive.
To remove yourself from the Synerg-E-News mailing list, please
click here.
Trademarks:
Synergex, Synergy, Synergy Development Environment, Synergy/DE,
and all other Synergy/DE product names are trademarks of Synergex.
All other product and company names in this newsletter are trademarks
of their respective holders.
Synergex
International · 2330 Gold Meadow Way · Gold River,
CA 95670
916.635.7300 | 800.366.3472 (North America) | 0800.898.368 (United
Kingdom)
Copyright © 2004 Synergex International Corporation. All rights
reserved.
Synerg-E-News
06092004
|
