Today we are on BPCS ... a few years ago on MAPICS ... same scenario occurred.
We have this base package.
We have modifications to the base package from vendor-A vendor-B vendor-C etc.
Our right to use the modifications are constrained by a contract that is
periodically renewed for some $$.  At some point in the future management
might say that the value we getting from vendor-X package-Y is not enough to
justify the $$$$$ we paying, so let's remove it from our system.  How do you
do that if you have not kept it in separate library?
We also have our own modifications, then the supplier of the base package
comes along with some upgrade & we have to combine their upgrade with our
modifications.  This is so much easier if separate libraries for programs &
file objects with same names.
We also have our own modifications to the add-on 3rd party packages.
There is also the issue of testing modifications & making sure we do not get
stuff mixed up across environments (test files vs. production files, all with
same names).

When planning this, it becomes rather critical to name the libraries such
that if you do a restore of a bunch of libraries (in alphabetical sequence)
the physicals will get restored before the logicals.

> From:

>  I fear that this will break down into dogma and that someone will come up
>  with some convolutions to every argument that someone may make as to why
>  they have logicals in separate libraries.  Much like the GOTO argument.
>  Basically some reasons for different libraries primarily involve join
>  logical files:
>  1)  Two separate packages.  Financials are from one vendor - erp is from
>  another.  They reside in different libraries.
>  2)  Vendor has a 'common' data library for all divisions.  Then there are
>  multiple 'division' data libraries for each division.  Join logicals to
>  link back to common data.
>  3)  Big picture of data joins all divisions into one fat family.
>  4)  You want a division to look at another divisions data, but you want it
>  to limit fields and records.
>  Rob Berendt (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated = new name same quality wire
engineering company: fax # 812-424-6838

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by 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.