|
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 mailing list archive is Copyright 1997-2025 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.
midrange.com
