|
>>>There're probably historical reasons for using separate libraries. E.g., I >>>think key field handling was not so easy in S/34 or S/36, hence the >>>separate files methodology? >> >>Key handling wasn't the issue for us on our old S/3; it was the pace of >>acquisitions. When you have an organisation that has a key like this: >>SLSM (2,0) >>CUST(5,0) >>and you buy another company, you'll be faced with this choice: >>a) change umpteen dozen files to have a new key structure, or >>b) make a new library to segregate one business from another. >> >>Mostly, we picked (b) because it goes quickly, and with few >>hidden gotcha's. > >In our case, we control the key, since we're not necessarily dealing with >acquisitions so much as selling our services to, say mortgage lenders. So >we end up with exactly the same file structure in multiple libraries. It's >a little like the library is another key field. > >In the case you describe, it seems you're keeping the structure of files >that the new company already has. In our case, as I say, we are just adding >a new 'code'. Same thing for us. We basically translated/converted the new company's data to fit our format, then built a new library for "company 02", "company 03" etc. There's a huge problem consolidating, say, year end reports across all the separate companies. Any time we place data outside the database (say company 02 in *this* library, company 03 in *that* library, or, even worse multiple members, then it makes it difficult to work with the entire database. Take the world's simplest RPG program: A/R totals, level break by company. Can't do it if your "company" isn't part of the record. All in all, I completely concur that we have to make every effort to bring AS/400 applications and databases into more modern shape. It'll be tough to transition from green screens to GUI without a modern database design to work with. Buck Calabro Commsoft +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@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.