Re[2]: Separate library for each business unit

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