× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Externalize DB/IO (was What Counts as Technically Slick?)
  • From: NSmith@xxxxxxxxxxx
  • Date: Mon, 9 Apr 2001 15:59:55 -0400

It is even better if you can get away from the file layout altogether by
wrapping all the i/o functions for a given file inside a service program and
then just provide procedures for specific data, like:  EVAL Status =
CustomerStatus(CustomerID).   Now the application doesn't care how the
status field is accessed or how it is stored or if the file layout changes.


For perfomance, leave the service program active between procedure calls and
have each procedure check the key supplied against the key in a cached  data
structure in the service program from the previous call.  I've found that
80% of your programs only need 20% (or less) of the field data and usually
only a few fields at one time.  This gives your application complete
insulation from DB matters.  

If you want to load a subfile with multiple data records, just build an
interfacing module that puts selected fields together into a
mini-datastructure (multiple occurance) laid out according to your subfile
needs rather than the file layout.  Since everything stays in memory, it is
supprising fast.

> -----Original Message-----
> From: Nathan M. Andelin [SMTP:nathanma@haaga.com]
> Sent: Monday, April 09, 2001 2:30 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Externalize DB/IO (was What Counts as Technically
> Slick?)
> 
> >Date: Mon, 9 Apr 2001 08:41:36 -0700
> >From: "York, Albert" <albert.york@nissan-usa.com>
> >Subject: RE: What counts as technically slick?
> 
> >On the surface it seems like a good idea,
> >but what have you gained?
> 
> >I still have to define the record in my program,
> >so if the file changes I still have to change all the
> >programs that use that file.
> 
> I was equally skeptical, Albert.  Until I tried it.  In my case, I
> separate
> DB/IO and business rules into one module, and UI control into another.
> But
> I merge both modules into one program.  The interface between the two
> modules is a single data structure for records, and a multiple occuring
> data
> structure for record sets.
> 
> I discovered a seemily natural boundary between DB/IO-Business Rules and
> UI
> control.  Both modules, independent of the other are easier to understand,
> debug, and maintain.  Faster compilation.  Smaller listings.  Also, the
> modules, independent of the other provide better patterns for "reuse by
> copy".  A productivity boost.
> 
> Another surprise, I discovered that I can use the same DB/IO module for
> both
> a Web interface as well as a 5250 interface - only the UI control module
> changes.
> 
> I don't predict this, but if someday SQL becomes better than record level
> access for DB/IO, then only the DB/IO modules would change.
> 
> A final surprise, while statically linked subprocedures are used instead
> of
> read, update, delete, etc., the overhead is next to nil.  Not even a
> millisecond of difference in CPU usage for individual calls.
> 
> Nathan.
> 
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message. 
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer. 
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.