× 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: DDS Support
  • From: "James W. Kilgore" <eMail@xxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 27 Jun 2000 00:46:43 -0700
  • Organization: Progressive Data Systems, Inc.

Mark, Al, all,

Having a DDS/SQL data dictionary/repository isn't rocket science.
We've done it since the S/3.

I think (although have never experienced) that products like Hawkeye
create their own PF with a data dictionary and the ability to use
REFFLD.  At least that's what we did.  This is how the open source
WyattERP project was originally created.  I've been debating about
putting my tools out on open source, but that's another topic.

From there you can create DDS or SQL or I/O internally defined specs or
(gasp) IDDU.

We have three files: DEFN (definitions), LINK (record to field linkages
(and others)), and TEXT (record and field (and others) narratives).  Now
I know, you're thinking how did you define records and fields in the
same file, not to mention files, programs, commands and what not and
have a normalized data base.  Simple answer: we didn't.  I know, shame
on us.

There was an early discussion on the openerp400 mailing list that
pointed out that by having a service program perform all file I/O, you
would not need to define the file in the program, just the record
format.  It was promoted as "a good thing".  Now since I don't have to
define the file, just the format of a record, the old (multiple format
files) can be resurrected by having a service program that you pass
FORMAT and KEY and it will pass back to you DATA.  The calling program
does not need to know, nor need to care, if the data came from a single
file or multiple files.  And through hiding the actual physical layer
from the logical layer you can now have multi format flat files and call
it "modern". <VBG>

On the other hand you can define the 18 different formats as 18
different physical files and exponentially increase the difficulty of
the project and feel good about the amount of time spent doing it
"right", what ever that is.

So, if you can write getCustomerNumber(definition), "how" is not really
important. Or is it?

Now before you flame me, does it really matter to you what the
underlying physical construct is when you use an API?  Do you really
know how many places that API call went to for the information returned?
Should you care?

"M. Lazarus" wrote:
> 
> Al,
> 
> At 6/26/00 03:53 PM -0400, you wrote:
> 
> >Clearly DDS is no longer strategic to IBM.  They want everybody to go with
> >SQL for file definition, which IMHO is brain dead.
> 
>   I agree wholeheartedly.
> 
> >SQL does not support all of the features of DDS.
> 
>   This is a big problem.
> 
> >IBM is of the opinion that they want to reduce everything to it's lowest
> >common denominator.
> 
>   Does SAA ring any bells?
> 
> >To force you to go to SQL, new database functions are only being added
> >through SQL.  We are actively looking at extending DDS through TAA
> >Tool.  This is not a pre announcement, but something under investigation.
> 
>   That would be great.  I encourage your efforts.  Maybe someone @ IBM will
> get the hint.
> 
> >Hey IBM, do it the AS/400 way, and you'll get a better product.
> 
>   That s/b the next ad slogan!!
> 
>   -mark
+---
| 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:
Replies:

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.