What are CDFs?
By: Jesse Brin, President, LANimation Consulting
Corporation
Beginning with release 4.5 of the DataEase for DOS product, DataEase International
included a new feature known as the Custom-Defined Function(CDF) capability. Through this
one relatively obscure technological feat, the DataEase application development platform
has been transformed from an also-ran in the mission-critical applications toolkit to a
viable platform alternative on par with Paradox, FoxPro, and other commonly employed 4GLs
in the corporate world.
This is the first in a series of articles intended to introduce DataEase users
unfamiliar with the CDF concept to the new power and versatility offered by this exciting
development. This first article is concerned with educating the DataEase user in
fundamental concepts of CDF design and usage. The next two articles examine specific CDF
implementations and the commercial impact and ramifications of the technology.
The Problem with DataEase (or any other 4GL)
A wise man once told me, 'Before someone buys a solution,
they have to believe that they have a problem.'.
DataEase has long been praised for giving the user unparalleled power to take an
information processing problem from concept to working model faster than other platforms.
However, many users have long been frustrated by DataEase's lack of low-level programming
tools. Many argue, perhaps rightfully so, that while providing unparalleled application
rough-prototyping productivity, DataEase gives back all of those productivity gains, and
then some, because of its limited extent.
These limitations often lead to obtuse and, at the same time, heroic workarounds for
problems that could easily be handled within the constructs provided by competing
application development platforms that, while not offering such a clear 'concept to
execution' path as DataEase, possess considerably more depth.
For example, some lengthy batch processing procedures that rely on the availability of
a minimum amount of scratch disk space have no straight-forward way, within native
DataEase, to check free disk space prior to executing the procedure. Prior to CDF
libraries, this information had to be obtained in some external fashion. I have actually
seen one instance where a batch file performed a directory listing, redirecting the output
to a file, then the file was imported and processed until the 'Bytes Free' figure was
found! Serious MIS department technologists scoff at such ramblings.
Likewise, there are no inherent methods available to create, rename, erase DOS files.
Screen I/O is strictly limited to that which can be provided by DataEase' internal form
and query processors, making the creation of simple ad-hoc question and answer dialogues
tedious chore.
These limitations, along with others, have long been a problem for DataEase and have
lent credence to a prevailing attitude in corporate MIS departments that DataEase is a
great prototyper, but should never be relied on to develop mission-critical systems.
This lack of depth has caused many DataEase users to defect to other platforms, despite
their stated affinity for DataEase' approach to application design. I, for one, have had
to sit across the desk from many a regretful MIS director asking me to detail conversion
options for his DataEase application because he feels the application has reached a dead
end. Needless to say, such an attitude does not bear great tidings for the future of the
platform.
In addition, I hear many DataEase users complain that requests for added functionality
seem to get lost in the myriad of other feature requests that DEI must deal with.
Still, it remains a widely acknowledged fact that DataEase is the quickest 'concept to
execution' development environment around. It is only after you get past rough execution
and you want to fine-tune things that you run into trouble. As stated previously, from a
technical design standpoint, what DataEase lacks is depth, not innovative application
design tools.
Thankfully, DataEase has now provided an answer to all of the aforementioned
deficiencies with its new (relatively) Custom-Defined Function facility.
The CDF Library
DataEase has long been acclaimed for its data import and export capabilities. In fact,
many DataEase users employ the software for nothing more than a data 'bridge' between two
disjoint systems, such as a mainframe-based DB2 application and a WordPerfect mail-merge
application. The CDF facility now gives DataEase the capability to import logic
external to DataEase, as well as data. Suddenly, DataEase has become an
'open-architecture' development environment.
A CDF library is a specially-designed program that consists of one or more functions or
routines written in a lower-level programming language like C, Pascal, or Assembler. A CDF
function may perform virtually any computing process from simply multiplying two numbers
together to executing a complex multimedia application. A CDF function may access all
system resources and, basically, perform any function any stand-alone program might do.
A CDF library is akin to a Dynamic Link Library (DLL) for those familiar with the
Windows and OS/2 operating environments. In fact, DataEase Express and DataEase for OS/2
implement CDF Libraries as DLLs.
A CDF Library, as well as individual functions, are made known to DataEase by entering
a record describing each function in a database's Custom Function form. Information
recorded in the Custom Function form includes the library program's name, the function's
name, the function's input parameters, and the function result data type. Armed with this
information, DataEase can access the library on demand.
DataEase does a very good job of seamlessly integrating the CDF library into the
development environment. Calls to CDFs are allowed to appear anywhere a standard DataEase
function appears. The High-Level Interactive mode during DQL composition allows you to
choose CDF functions from a pull down menu.
How DataEase Accesses a CDF
When DataEase first encounters a reference to a CDF function during execution of a form
or DQL procedure, it looks for the program file named in the CDF form. Provided the file
is found, DataEase loads the program into memory. A CDF program must be constructed in
such a manner that it performs whatever initialization as may be necessary and then
returns program control back to DataEase. At this point DataEase may access any of the
functions 'exported' by the library.
One of the initialization steps that the CDF program performs is to provide DataEase
with a table listing the names and memory addresses of each of its exported functions.
This allows DataEase to match the names of the functions against the Custom Function form
records and to know the memory location to transfer control to when a function is invoked.
The CDF program library is kept loaded into memory until the user returns to a main
menu from the form or procedure. This means that other functions in the library can be
used and re-used within the calling procedure or form without re-loading the program from
disk. Likewise, once the CDF library is unloaded by DataEase, any data maintained inside
the CDF program is destroyed. In a sense, a CDF library is like a short-lived Terminate
and Stay Resident(TSR) program.
DataEase can and will load multiple CDF libraries in memory at the same time. The only
limit to the number of CDF libraries is the amount of available conventional memory
remaining after DataEase is started.
Each time a CDF function is called, DataEase properly sets up the input parameters
called for in the Custom Functions form. DataEase then transfers control to the CDF
function. The function then does whatever it was designed to do. When the function
completes its processing, it fills in the result parameter and returns control back to
DataEase. The DataEase procedure or derivation formula is then free to employ the result
in whatever manner it requires.
Considerations
First, since DEASE.EXE doesn't leave much available memory, only the most compact CDF
libraries may be called from within DEASE.EXE. I recommend that users only employ the 16M
version of DataEase, since it can provide up to 512k of conventional space for CDF
libraries. On a similar note, DE16M users must set up a .VMC file that specifies a
RESERVELOW setting that sets aside adequate conventional memory for the library's
purposes. Each CDF library should be accompanied with documentation that details the
library's memory requirements.
Second, CDF functions must be written in a lower-level language, such as C, Pascal or
Assembler. Not all DataEase licensees possess either the skill or the desire to spend time
on such a project. However, the introduction of the CDF capability has provided a
commercial opportunity to companies, such as LANimation Software and others, wishing to
develop commonly needed CDF libraries for distribution.
Last, CDFs can't provide answers to all of the items you may have on your DataEase wish
list. There are still some significant issues that need to be addressed in the core
product, such as allowing procedural pre-input/post-input functions within field
definitions. However, properly selected CDF toolkits can go a long way towards fulfilling
significant requirements that simply had no outlet in previous releases.
|