|
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 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.