Middleware Assignment (Computer Science)

TH VV

U S I N G M I D D L E -

W A R E , C U S T O M E R S

C A N D E P L O Y C O S T -

E F F E C T I V E A N D

H I G H L Y

F U N C T I O N A L

C L I E N T / S E R V E R

A P P L I C A T I O N S

O N C E T H E Y W O R K

O U T T H E K I N K S .

BY RICH FINKELSTEIN

B roadly speaking, middleware ties application components together. This definition en- c o m p a s s e s too many prod- ucts to cover in one article, so instead I'll look at signifi-

cant products that can be used to manage cross-platform connectivity in a database environment. Within this context, mid- dleware products provide several impor- tant functions, including:

• d a t a a c c e s s to h e t e r o g e n e o u s data- bases; • g a t e w a y s to r e m o t e mainframe data- bases; • appficafion partitioning across multiple hardware platforms; and • distributed updates across a homoge- neous or h e t e r o g e n e o u s set of relational databases.

M a n y m i d d l e w a r e p r o d u c t s have ap- p e a r e d o v e r the l a s t s e v e r a l y e a r s t h a t have attempted to solve the various prob- l e m s a s s o c i a t e d with a c c e s s i n g and up- dating databases over local and wide area n e t w o r k s (LANs and WANs). F o r the most part, p r o g r e s s in deploying produc- tion applications that utilize middleware has been slow - - much slower than what you m i g h t first think. C u s t o m e r refer- e n c e s for m i d d l e w a r e p r o d u c t s are still few and far between. M o s t applications that use middleware s e e m to have a rela- tively simple application profile; that is, low v o l u m e s of read-only t r a n s a c t i o n s . However, in some cases, middleware has b e e n u s e d Successfully to s u p p o r t very large, mission-critical systems. Develop- ing t h e s e types of systems usually takes a substantial amount of time, resources,

and c o m m i t m e n t ; in o t h e r w o r d s , you m u s t have a h i g h tolerance for b u g s and p e r f o r m a n c e p r o b l e m s t h a t h a v e to b e w o r k e d out of t h e m i d d l e w a r e software methodically.

Products that were introduced several years ago to address the simpler problems of m i d d l e w a r e , s u c h as s i m p l e d a t a ex- traction or update of mainframe-based re- lational d a t a b a s e s , have r e a c h e d a level of performance and stability that m a k e s t h e m g o o d c h o i c e s for i m p l e m e n t i n g a wide variety of c l i e n t / s e r v e r applications. Transaction monitors and c e r t . i n r e m o t e p r o c e d u r e call (RPC) m e c h a n i s m s have also proved to be very useful for a b r o a d set of applications. T h u s , w h e r e a s mid- d l e w a r e m u s t still b e given t i m e to ma- ture, t h e r e are many cost-effective prod- ucts available today that work well.

Connecting to Heterogeneous Data Al1 S Q L b a s e d d a t a b a s e s e r v e r s c o m e with client program libraries that include an a p p l i c a t i o n p r o g r a m m i n g i n t e r f a c e (API), and a set of network libraries that let client application p r o g r a m s attach to SQL database s e r v e r s using various net- work protocols. On the server side of the network, a companion program called the network listener waits for and g r a b s mes- s a g e s f r o m t h e c l i e n t a p p l i c a t i o n a n d h a n d s t h e m off to the d a t a b a s e s e r v e r . T h e listener then r o u t e s data e x t r a c t i o n result sets or other m e s s a g e s b a c k to the client.

m m m n l m m m

Rich Finkelstein is president of Performance Computing Inc., a database technology con- sulting company based in Chicago.

FEBRUARY 1995 D~MS

102 $ I G M O D R e c o r d , V o l . 2 4 , N o . 4, D e c e m b e r 1!)93

SIGMOD Record, Vol. 24, No. 4, December 1995 10:3

applications and a wide breadth of ap- plication servers. Already, organizations are h a m m e r i n g vendors for links to Lo- tus Notes, imaging database.,;, and text- p r o c e s s i n g databases. OLE can poten- tially provide this mechanism. For now, OLE appears to be not only Microsoft's direction within its own product line, but also the direction of most of the c l i e n t / server industry.

Gateways to Mainframe D a t a b a s e s It is no surprise that the most mature middleware products on the market are designed to c o n n e c t workstation appli- cations to critical mainframe databases such as DB2. Despite the excitement sur- rounding c l i e n t / s e r v e r and PC comput- ing, most corporate data still resides on mainframes. T h e r e are several reasons for the slow migration off mainframes. Mainframes are still m o r e reliable and have more mature and well-defined data integrity a n d security m e c h a n i s m s . An enormous a m o u n t of investment money and knowledge is associated with main- frame applications, and it takes time and substantial resources to understand the nature of these mainframe applications, much less reengineer them for minicom- puters and PCs. Mainframe applications are tightly linked among themselves and to shared databases, making it difficult to migrate one application without affecting many others.

Database gateways, such as those pro- vided by Micro Decisionware Inc.'s (MDI) Database Gateway (recently acquired by Sybase) and Information Builder Inc.'s (IBI) E n t e r p r i s e Data Access ( E D A ) / SQL, are designed to promote gradual mi- gration from traditional dumb-terminal/ mainframe database e n v i r o n m e n t s into a client/server architecture. While many a p p l i c a t i o n s a r e still m o r e t h a n ade- quately serviced by traditional architec- tures, new b u s i n e s s requirements often m a n d a t e the i n t r o d u c t i o n of PC work- stations. U s i n g gateways, an organiza- tion has the option of keeping the data- base server exclusively on the mainframe platform, or u s i n g a c o m b i n a t i o n of In- tel, Unix, and m a i n f r a m e d a t a b a s e s to process an application. Each database can contain a logical partition of an en- tire database, or it can contain data that has been replicated from the mainframe database. Moving data to Intel- or Unix- based platforms tends to improve acces- sibility and performance, but also com- plicates application d e v e l o p m e n t a n d administration.

Database gateways sit b e t w e e n the c l i e n t application and the target main- frame database. Their primary functions are to: t r a n s l a t e LAN protocol packets into WAN packets (for example, IPX/ SPX into APPC); translate client-gener-

ated SQL commands into commands that are understood by the target database; and extract data from the target database and r e t u r n it to the r e q u e s t i n g applica- tion.

Based upon most surveys, MDI Data- base Gateway is the most popular gate- way of this type. You can install the net- work and SQL c o n v e r s i o n functions as OS/2 or Unix servers, or on individual OS/2 workstations. A server-based data- base g a t e w a y acts as a c o n c e n t r a t o r , which provides gateway services for sev- eral workstations in a workgroup. Server solutions are more cost-effective and off- load communications work from the work- station.

IBI's EDA/SQL has an advantage over MDI Database Gateway in that you can install it on Windows workstations, Unix servers, or on the mainframe. Organiza- tions often deploy IBI's gateway on the mainframe to eliminate the need for an intermediary Unix or OS/2 server.

T h e m a i n f r a m e c o m p o n e n t of MDI Database Gateway i n c l u d e s a DB2 ac- c e s s m o d u l e that c a n e x t r a c t data di- rectly from a DB2 database. T h e r e are also facilities called remote stored pro- cedures, which c o n s i s t of user-written CICS p r o g r a m s t h a t a c c e s s non-DB2 databases such as IMS, CA-IDMS, and VSAM. Remote stored p r o c e d u r e s let customers customize and tune access to nonrelational data sources, and are pow- erful m e c h a n i s m s for a t t a c h i n g n e w client/server applications to legacy data- bases. S y h a s e / M D I also licenses a set of gateway modules from Trinzic Corp., called InfuHub, which can access a num- ber of different mainframe data sources, i n c l u d i n g IMS a n d VSAM files. How- ever, InfoHub has a relatively small mar- ket p r e s e n c e and it is difficult to j u d g e the performance and stability levels of these modules.

IBI's E D A / S Q L also offers gateway modules that access many different types of data sources. EDA/SQL has a longer history when it comes to accessing non- relational databases - - especially IBM's mainstay IMS databases. Because of this, EDA/SQL is often chosen for IMS gate- way access, but performance tends to be- come a problem as queries grow in com- plexity and volume. IBI likes to advertise its ability to join any amount of data from any type of data source, but you should take this claim with a grain of salt. Un- less the queries are trivial, performance will be so poor that this approach simply becomes impractical. As with MDI Data- b a s e Gateway, E D A / S Q L c u s t o m e r s have the option to build their own CICS database access programs that are func- tionally similar to MDI's remote stored procedures.

MDI D a t a b a s e G a t e w a y is u s u a l l y chosen over EDA/SQL because of per-

formance, its ability to service a larger n u m b e r of c o n c u r r e n t u s e r s , a n d its b u l k - t r a n s f e r c a p a b i l i t i e s . E D A / S Q L tends to be the choice when transaction v o l u m e is l i g h t a n d c u s t o m e r s m u s t quickly implement a mainframe gateway to a nonrelational DBMS such as IMS, but they do not have the time to write a more customized and efficient CICS pro- gram. In addition, some customers may choose EDA/SQL b e c a u s e it does not r e q u i r e an i n t e r m e d i a t e Unix or O S / 2 server, thereby simplifying the environ- ment and allowing quick deployment of a prototype or simple production appli- cation.

D o n ' t F o r g e t a b o u t D R D A IBM's Distributed Relational Database Architecture (DRDA) offers an interest- i n g a l t e r n a t i v e to d a t a b a s e gateways. T h e DRDA specification s t a n d a r d i z e s the network protocol formats (APPC and T C P / I P ) , SQL syntax, and data repre- sentation format used to link IBM's re- lational d a t a b a s e s . T h i s allows I B M ' s DB2 databases on OS/2, RS/6000, A S / 400, and MVS to share data without the need for intermediary gateways. DRDA tightly integrates the various DB2 plat- forms and provides a high degree of re- liability and performance. Many compa- n i e s have i m p l e m e n t e d critical o n l i n e transaction-processing applications us- ing DRDA. Usually, these applications are some mix of OS/2 workstations with D B 2 / O S 2 a n d D B 2 / M V S m a i n f r a m e databases.

A d d i n g V a l u e to D a t a b a s e G a t e w a y s Several middleware products work in c o n j u n c t i o n with and add value to the MDI and E D A / S Q L gateways. One of t h e b e t t e r - k n o w n p r o d u c t s is T r i n z i c Corp.'s In foPump. InfoPump is a data ac- cess m a n a g e m e n t tool that lets organi- zations schedule periodic data extracts from a variety of data sources, and then direct the output of these r e q u e s t s to a local database server such as Oracle or Sybase. InfoPump includes a scripting language that developers use to specify the data sources, data targets, and data extract schedule. It connects to a main- frame database via E D A / S Q L or MDI Database Gateway, or to local database servers via direct drivers. Unlike MDI Database Gateway and EDA/SQL, Info- Pump is still relatively new in the mar- ket; and it is difficult to gauge its perfor- mance capacity. Customer reports vary, so you m i g h t b e n e f i t from c u s t o m e r checks or in-house b e n c h m a r k s before signing on to the product.

InterViso, from Data Integration Inc., is attempting to go far beyond the data- integration capabilities of most middle- ware products on the market. InterViso's

104 S I G M O D R e c o r d , V o l . 2 4 , N o . 4, D e c e m b e r 1.9fl5

objective is to provide complete, trans- parent access to a set of heterogeneous d a t a b a s e s - - what is s o m e t i m e s re- ferred to as a "federated database." To a c c o m p l i s h this o b j e c t i v e , I n t e r V i s o translates data types, provides common n a m e s to s i m i l a r f i e l d s in d i f f e r e n t databases, supports data encoding, man- ages data that is replicated among sev- eral databases, provides a single view of records that are fragmented across mul- tiple d a t a b a s e s , optimizes d i s t r i b u t e d ( m u l t i d a t a b a s e ) queries, and p e r m i t s h e t e r o g e n e o u s updates without sacri- ficing security, transaction-management support, or t h e local autonomy of each database.

T h e key to InterViso is its Data Dic- tionary/Directory (DD/D), which stores a complete description of all databases in the environment. DBAs are then free to define federated data "views," which can include data from one or more het- erogeneous databases. InterViso's "con- troller" uses the D D / D to map views to underlying physical tables and then op- timizes any queries that span more than one database. T h e controller also con- trols multisite updates using a specially designed COMMIT protocol, which allows transactions to continue even if a node is unavailable. T h e Database Manage- m e n t S y s t e m Interface (DBMSI) con- verts fields with similar meaning but dif- f e r e n t d a t a t y p e s i n t o f i e l d s w i t h a common data type. InterViso can handle even very difficult situations where one field may have a numeric data type while another field with a similar meaning has a character data type. InterViso will con- vert the numeric data type to a character field so that the values stored in the two fields can be merged together.

Data I n t e g r a t i o n Inc. claims that In- terViso can support fragmented tables (tables that are horizontally or vertically partitioned) and replicated data auto- matically. Considering the complexity of the problem, you might want to approach this claim with some skepticism. How- ever, if the product works as claimed, it can be tremendously useful when you're implementing decision-support databases or migrating applications from mainframe databases. I would recommend that any customer considering InterViso should spend some time interviewing customer references and prototyping with the prod- uct in order to understand the functional and performance limitations of InterViso's distributed query and update capabilities. Even if it does not have all the capabili- ties you require, it may be adequate for solving many types of distributed appli- cation problems.

Partitioning Application Logic Application partitioning - - splitting ap- plication logic across multiple platforms - -

is now in vogue. However, application par- titioning is not new to client/server pro- cessing. Stored procedures, which Sybase promoted heavily when it first introduced its SQL Server database, are good exam- ples of simple application partitioning.

T h e r e are t i m e s w h e n a p p l i c a t i o n logic must be deployed on the server, and either the logic is too complicated for stored procedures or the server does not offer stored procedures. One of the benefits of stored procedures and appli- cation partitioning is that they help min- imize n e t w o r k traffic by m o v i n g t h e database access application logic onto

I I Y o u s h o u l d n o t

u n d e r t a k e t h e t a s k o f

a p p l i c a t i o n p a r t i t i o n -

i n g w i t h o u t s o m e

f o r e t h o u g h t . P a r t i -

t i o n e d a p p l i c a t i o n s

a r e m o r e d i f f i c u l t t o

d e s i g n a n d m a i n t a i n .

the server. Application partitioning also offloads work from workstations, which are often overtaxed. One of the problems with c l i e n t / s e r v e r p r o c e s s i n g is that workstations are often incapable of sup- porting complex application processing. One way to get m o r e life out of work- stations is to move processing logic to the server. It is far more economical to upgrade one server (if necessary) than to u p g r a d e h u n d r e d s or t h o u s a n d s of workstations.

You should not undertake the task of application partitioning without some forethought. Partitioned applications are more difficult to design and maintain. An application that is split up into several pieces is more complex and has more po- tential points of failure. You must design partitioning into the program at its in- ception so that logical points exist from which to divide the application. T h i s is exactly the situation that exists today when developers design and program ap- plications that implement stored proce- dures: Overly partitioned applications can result in unnecessary network traffic and unstable systems.

RPC Solutions Products that support RPCs offer a straightforward way to partition applica- tion logic without programming complex network communication protocols. This category of products includes companies such as NobleNet Inc., Netwise Inc., and

NetWeave Corp. GVilmington, Del.). As with most products in the middleware cat- egory, R.PC products have enjoyed only limited use until recently, although de- mand is growing as c l i e n t / s e r v e r appli- cations scale up in complexity. There is typically very little reason to implement RPCs in simple workgroup environments (which represent the lion's share of the c l i e n t / s e r v e r applications in production at this time).

A good example of the use of RPCs is an application that my company recently helped develop. This application consisted of a local FoxPro database that needed to c o n n e c t to a remote Informix database whenever a customer wanted to retrieve data that was unavailable in the FoxPro database. Because FoxPro was r u n n i n g u n d e r DOS in this case, we wrote a cus- tomized network protocol that sent a Fox- Pro-initiated SQL r e q u e s t over to the server. On the server, an extract program received the request, extracted the data from Informix, and sent the data back to the workstation.

U n d e r DOS, we wrote the n e t w o r k c o m m u n i c a t i o n layer that s e n t the re- quests and returned the data packets. But under Windows, you can take advantage of a product such as NobleNet, which an- alyzes the client and server application programs and automatically generates the client and server networking communi- cation programs (called "stubs"). This saves a considerable amount of time, and does not require specialized network com- munications expertise. Most developers who can write a C program can use No- bleNet to partition an application across a network.

Netwise recently i n t r o d u c e d Trans- Access Application/Integrator Worksta- tion (A/IW), which lets developers define the communications interface using a GUI specification tool. GUI definition is pre- sumably easier to use and maintain than generated C language code.

Several vendors have introduced appli- cation development tools that they claim can partition applications across multiple heterogeneous sites easily and dynami- cally. Foremost among this class of prod- ucts are Dynasty and Forte. Unfortunately, the vendors are so far unable to provide evidence that their products can really per- form these tasks efficiently and reliably. Because the products are so new, most customers seem to be making little or no use of application partitioning within their deployed production applications. These products may prove to be worthwhile, but I hesitate to recommend them because of the lack of proof of concept.

Transaction Managers in a Distributed Environment As client/server applications grow in size, importance, and complexity, there is a

FEBRUARY 1995 DBMS

S I G M O D R e c o r d , V o l . 2 4 , N o . 4, D e c e m b e r 1 9 9 5 1 0 5

corresponding need for greater reliabil- ity, security, availability, and performance. On mainframes, transaction m a n a g e r s (TMs) - - also called t e l e p r o c e s s i n g m o n i t o r s (TPs) - - such as CICS and IMS/DC (or IMS/TM) have always held a position of great importance. TMs help ensure predictable response time, guar- antee that transactions are completed suc- cessfully, allow messaging among appli- cations, and support a very granular level of security. Security officers using TMs can define which users can access which transactions. It is also possible to define which terminals can be used to execute specific transactions.

TMs on Unix and Intel platforms have not achieved as strong an e n d o r s e m e n t in client/server environments as in main- frame e n v i r o n m e n t s , b u t t h i s s h o u l d c h a n g e over the next several years as client/server matures and is better able to support high-volume distributed appli- cations in a cost-effective manner.

Novell's Tuxedo and IBM's CICS are two of the most popular TMs on the mar- ket today. Tuxedo supports several Unix platforms, but the most popular are Sun, Hewlett-Packard, and RS/6000. CICS runs on OS/2, RS/6000, a n d t h e AS/400, as well as on IBM mainframes. Currently, TMs do not support Windows NT or Nov- ell NetWare. NoveU has stated that it in- tends to port Tuxedo to Intel platforms, b u t it may take some time. NetWare is simply incapable of supporting a TM re- liably, and it is unlikely, for competitive r e a s o n s , that Novell is g o i n g to be in much of a hurry to support Windows NT.

TMs, like other middleware products, receive requests from an application pro- gram and route the requests to a server application, which updates the target data- base. TMs provide specific capabilities for managing large distributed applications. Tuxedo g u a r a n t e e s that the application request is delivered to the target database server platform by utilizing disk-based message queues that are not lost in case of system failure. Tuxedo also provides built-in logging to recover transactions that were in the process of updating but were not completed at the time of system failure. It can also support heterogeneous database updates with a two-phase com- mit protocol, although I have not seen this feature in any production application at this time.

Up until now, writing Tuxedo code has b e e n cumbersome. However, newer ap- plication development tools such as JY- ACC's JAM 6 have high-level language support for Tuxedo that is much easier to write and maintain, JAM 6 automatically generates the client and server stubs that interface with Tuxedo and the target data- base server. A word of caution: JAM 6 is a new product and has not been widely de- ployed, but the architecture merits a look.

IBM's CICS has enjoyed widespread popularity, primarily because it provides reliable connectivity across IBM's hard- ware and database platforms. Organiza- tions commonly use CICS as the means of linking OS/2-based applications to main- frame DB2 and IMS databases. In my own consulting practices, I have noticed that when large institutions need to deploy crit- ical applications that access mainframe data, they usually tuna to CICS and OS/2. A large number of developers are familiar with the CICS API because of its long-term use on the mainframe. This makes CICS more accessible to large organizations that have developed a substantial CICS knowl- edgebase over the last 20 years.

Both Tuxedo and CICS offer viable so- lutions for companies that demand system integrity and cannot tolerate the large in- tegrity holes that exist in current client/ server software and hardware products. My primary concern with Tuxedo is the fact that it is now owned by Novell. In the past, Novell has shown little interest in Tuxedo because of its own obvious preoc- cupation with NetWare. UnixWare has also suffered from neglect. In recent months, however, Novell has shown renewed in- terest in promoting Tuxedo, possibly be- cause of its long-term value to Novell's en- terprise connectivity strategy.

IBM's CICS is firmly entrenched in the market, and it is a good choice for IBM plat- forms. Until recently, IBM and Hewlett- Packard were cooperating in using the Encina TM as the core technology for both IBM's RS/6000 CICS system and Hewlett- Packard's forthcoming TM. However, when IBM purchased Encina, Hewlett-Packard backed out of the Encina agreement, and the future of the CICS and Encina non-IBM operating platforms is unclear.

Another c o n c e r n with CICS for RS/ 6000 is that it implements a layered archi- tecture that consists of Encina technology as well as other connectivity layers. This layering t e n d s to impact performance, and some customers report that t h e RS/ 6000 version of CICS is just too slow. IBM may decide to merge all of the code or use the 0 S / 2 CICS codebase for future releases of CICS on IBM and Unix plat- forms. W h a t e v e r h a p p e n s c o n c e r n i n g CICS on Unix, CICS will probably con- tinue to do well because of its maturity and proven capabilities.

T h e F u t u r e o f M i d d l e w a r e Two years ago, I wrote an article for DBMS on middleware ("Making C o n n e c t i o n s Across the Enterprise," January 1993) and there is certainly a lot more to talk about today than there was then. Interestingly enough, while products with great-looking features continue to pour into the market, the adoption of m i d d l e w a r e has b e e n rather slow. I believe that most organiza- tions are still getting their feet wet with

client/server and they are stiI1 trying to es- tablish a firmly grounded knowledgebase. infrastructure, and migration plan before moving ahead with client/se~'er. During this waiting period, client/server technob ogy - - including middleware technol- ogy - - will have a chance to mature.

The best strategy at this time is to rely mainly on proven middleware products and gradually add more technology as in- house knowledge grows. Several solid products, such as MDI Database Gatew W, EDA/SQL, CICS, and Tuxedo, have been a r o u n d for s o m e time a n d have had a chance to find comfortable positions in d i s tributed client/server applications. Other products, such as InfoPump and RPC pro- grams, have also enjoyed a good amount of success. As middleware gradually be, comes more mainstream, customers will he able to deploy cost-effective and highly functional client/server applications. • • Data Integration Inc., 11965 Venice Blvd., Ste. 305, Los Angeles, CA 90066:310-313- 9150 or fax 310-313-9151. • Dynasty Technologies Inc.. 500 Technology Dr., Ste. 100, Naperville, IL 60563: 708-355- 8300 or fax 708-355-9345. • Fortd Software Inc., 1800 Harrison St.. 15th FI., Oakland, CA 94612; 510-869-3400 or fax 510-834-1508. • IBM Corp. Old Orchard Rd.. Armonk, NY 10504; 800-342-6672 or 914-765-1900. • Information Builders Inc., 1250 Broadway. 30th FI., New York, NY 10001-3782: 800-969- 4636, 212-736-4433, or fax 212-268-7470. • Intersolv Inc. (Q+E), 3200 Tower Oaks Blvd., Rockville, M D 20852; 800-547.4000 or fax 301-984-3047. • JYACC Inc., 116 John St.. 20th FI., New York, NY 10038; 800-458-3313.212-267-7722. or fax 212-608-6753, • Microsoft Corp., One Microsoft Way, Red- mond, WA 98052; 800-426-9400, 206.882- 8080, or fax 206-883-8101. • Netwise Inc., 2477 55th St.. Boulder, CO 80301;800-733-7722, 303-442-8280, or fax 303-442,3798. • NobleNet Inc., 337 Turnpike Rd.. Southboro Technology Park, Southboro, MA 01772: 508- 460-8222 or fax 508-460-3456. • Novell Inc., 122 East 1700 South, Provo. UT 84606; 800-453-1267, 801-429-7000, or fax 801-429-5155. • Oracle Corp., 500 Oracle Parkway, Red- wood Shores, CA 94065; 800-633-0596.415- 506-7000, or fax 415-506-7200. • PageAhead Software Corp., 2125 Western Ave., Ste. 301, Seattle, WA 98121: 800-967- 9671,206-441-0340, or fax 206-441.9876. • Sybase Inc., 6475 Christie Ave.. Emeryville. CA 94608; 800-879-2273, 510-922-3500, or fax 510-658-9441. • Trinzic Corp., 101 University Ave.. Palo Alto. CA 94301; 800-845-2466, 415-328-9595, or fax 415-321-7728. • Visigenic Software, 951 Mariners Island Blvd., Ste, 460, San Mateo, CA 94404:415- 286-1900 or fax 415-286.2464.

FEBRUARY 1995 D B M S

106 S I G M O D R e c o r d , V o l . 2 4 , N o . 4, D e c e m b e r 1~)!)7)