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

>It's probably six of one, half a dozen of the other, generally speaking.
>However, as we move into disparate environments, we end up jumping through
>hoops on the AS/400 to be able to coexist with SQL/ODBC and other
>client/server apps. Multiple members, multiple format logicals, and (to a
>lesser extent) libraries are just not a part of the rest of the world.

Hear, hear.  One might think one is saving time and effort, but when it
comes time to consolidate information across multiple members or libraries,
one will be sorely disappointed to find out how hard it is to do quarter-to-
quarter comparisons when each month is in a separate member!

Buck Calabro

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


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