|
Two payroll/HR/financial products I have worked with (Infinium and Software Plus) require multiple program libraries due to "modularity". Both packages have a single "signon" program that manipulates the library list. Software Plus has one data library, multiple program libraries (per module), and a "custom" library. It is a decent setup. Infinium (when I last used it) not only has multiple program libraries, but multiple data libraries (one for each module). So if you have the AP module, you have AP2000 and APDBFA (and APDBFT for test) libraries. Multiply by HR, payroll, GL, AR, and you get the picture. Normally, there shouldn't be a large issue with consolidating into fewer libraries, except in three cases. First, you must ensure that program, file or other object names aren't duplicated before you consolidate. Second, as you mention, you must modify the initial program(s) to change the library list to what you desire. Third, I know from personal experience the installation and upgrade routines of Infinium and Software Plus look in specific libraries. IIRC, Infinium lets you define your own library names. Software Plus has a predefined naming convention you must follow. I would not consolidate a product's libraries unless there was a systems need (library list shortage, what have you), and even then, only after careful object analysis and knowledge of the upgrade process. As far as source is concerned, I've been lucky to use vendor software so far. The companies I worked for always customized the system, so we had access to a vast majority of the source. One casino accounting package I used had a prohibitively high price for access to source, we didn't buy the source. At my current job, we have access to most source, and have the largest amount of customization I've seen so far. There have been issues with losing in-house source... but those days are largely behind us. Loyd -----Original Message----- From: James W. Kilgore [mailto:eMail@James-W-Kilgore.com] Sent: Thursday, May 31, 2001 1:37 AM To: MIDRANGE-L@midrange.com Subject: Re: 250 libraries again (was V3R1 QUSRTOOL, *PRDLOD) <snip> How many folks are out there with missing source code where the vendor (or an in house accident) prevents you from retrieving the source, modifying the source -and- the application is doing something "cute" with the library lists? I'm really ignorant about application suites like JBA, never had the pleasure of meeting their acquaintance, but what prevents an installation from taking their gazillion libraries and just doing a MOVOBJ into a single consolidated library? Do they qualify the object names? Did they bury and continuously repeat the "cute" library list code in a whole bunch of CL programs so that you could not replace a single command with a "no-op"? How bad is it out there? +--- | 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.