|
Ouch. Library lists and how to structure application libraries can be an interesting dilemna and problem. Not knowing all of your specifics is kind of limiting but here are my suggestions: 1.) Anywhere you can logically consolidate, do it. I'm sure you've looked at this a hundred times over but I'd do it again. My personal opinion is that I don't want one huge application library nor do I want one for each application. If there are no valid security or control reasons consolidate. 2.) Your process of swapping library lists is valid, it sounds like it is not universally followed or implemented. It's probably very similar to the TAA Tools (don't work for Jim Sloan, just love the product) library group processing. If I understand correctly as you move back in forth your are saving the original, modifying it, running the app, and then restoring when done. If implemented universally, this should work. Can you logically create library groups to assist in the control? 3.) In actuallity you have 42 libraries at your disposal. In a similar approach to item #2 you can use the current library and change it as necessary via the chgcurlib command. It sits above the 25 user libraries and is an additional library you can use. It's one of the few things that the S/36 had and the S/38 didn't :-). The library you specify as current will remain there until it is changed via the CHGCURLIB command. Of course this will only work if you are working with 1 library at a time. 4.) You can also use production libraries. It's similar to the current library but is available only to commands. I use this a lot and wish my third party vendors did. It's a parameter on the command. The production library is active as long as the command is running. Assume CMD A uses LIB A, CMD B uses LIB B, etc. Entere in CMD A and LIB A is your production. Enter in CMD B and LIB B is your production. Enter CMD C and LIB C is your production. End CMD C and now LIB B is your production. End CMD B and LIB A is now production. End CMD A and you have no production library. This too will only work with 1 library at a time. 5.) I hesitate to suggest but you also have 15 system library list entries available. If you have a library that is indeed global in it's usage you may want to consider placing it there. I try to avoid this because there are only 15 and many third party operation /utility applications like to use this. If you are indeed not using library qualifications and using library lists the bigger this list gets the more impact you will have on performance. That's why I strongly suggest you spend more time on #1 and #2. You are already doing #2 maybe just not well enough? Anywhere you can eliminate/consolidate I would not hesitate to do it. Respectfully Mike Crump engelkes <engelkes@xs4all.nl> on 11/27/98 04:29:15 AM Please respond to MIDRANGE-L@midrange.com To: MIDRANGE-L@midrange.com cc: (bcc: Mike Crump/IS/Ball-Foster) Subject: LIBL limitation of 25 libraries We have a lot of applications in seperated program libraries. We often encounter the problem that the library list is limited to 25 libraries maximum. At the moment we save the list in a CL variable and restore the list later on with CHGLIBL afterwards. Often the user jumps to another program between the two statements and, again, gets problems with the library list. How do You cope with this 25 libraries limitation? Suggestions for workarounds are greatly appreciated. Thanks in advance, Wijnand Engelkes. +--- | 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 +--- +--- | 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-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.