× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: 250 libraries again (was V3R1 QUSRTOOL, *PRDLOD)
  • From: "Goodbar, Loyd (AFS-Water Valley)" <LGoodbar@xxxxxxxxxxxxxx>
  • Date: Thu, 31 May 2001 08:36:23 -0400

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

Follow-Ups:

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

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.