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



Hi,

At 07:39 PM 12/11/97 -0500, you wrote:
>on 12/11/97at 01:00 PM, the Great and Grand  Wazir Vern Hamberg
><hambergv@goldengate.net> said:
>
>
>>Also, multiple libraries do not translate easily to other platforms, esp.
>>using SQL.
>
>>Can you say more about benefits of the multiple library method?
>>Personally, I don't see much benefit.
>
>I lack experience with the SQL solution, that would be a real issue I
>think for an SQL shop.
>
>So far as the library list though, well...  here goes.
>
>I made a library for each business unit, and a general group-wide library. 
>The programs all reside in the group-wide library, as do a few files with
>group-wide data.  The group wide library has a menu that has selections
>for a choice of unit.  When presented with that menu, a user must choose
>an option, or return from whence they came.  Once a unit is chosen, the
>corresponding unit library is made their current library.  In the unit
>library is only the unit's individual data, and a query library and a
>unit-specific menu for the queries.
>
>The security works like this: All users have authority for the group-wide
>library.  Unit libraries have authority lists.  There is more to it of
>course, but that is pretty much the whole thing.

Thanks for the reply.

We have a similar structure for some of our applications, established some
years ago. We use the concept of 'company', similar to what your 'unit'.
There can be multiple company-specific data libraries and one program
library at each site. Each user is assigned to a company, and library lists
are modified according to this company number.

I see the security issues. But, since noone has access to anything, except
through applications (no command line, etc., for users), the same thing can
be accomplished with the 'company/unit' as a key field.

We also have applications based on counties. These, for some reason, were
designed with county as a key field, not as separate libraries. Go
(con)figure! You can imagine that this mix of methods causes some
difficulties. But what else is new with "12-years" of code.

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?

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.

Cheers

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480


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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.