Re: LIBL limitation of 25 libraries

I'm with ya on keeping things simple, but I wouldn't count on a larger LIBL
anytime soon... <grin>
I don't see batch processing as an issue since most batch jobs could be
written  to run in different parts if the need was warranted.
If the primary issue is interactive jobs, and the users only access these
jobs by menu, then pehaps this might help:  create a cmd by the same name
as the menu.  The CPP for the cmd will set the LIBL appropriately, then go
to the menu.  At end of pgm, LIBL is restored.  
Doing this will perhaps minimize the pain of implementing the save/restore
LIBL management technique if all menu options are similar and use less than
10 separate libraries.
The only ways I can think of making more room on the LIBL would be to merge
the data and pgm libraries, or use "helper" funcions/pgms that incorporate
OVRDBF to control object selection.

Certainly not a solution, but perhaps it'll help in the evolution of a
solution.

Rob



At 03:54 PM 11/27/98 -0500, you wrote:
>Swapping the library list could be made to work. But they are
co-dependence (The production system need access to the sales system for
customer info...). The thing is i would need to establish all those
dependencies and modify all programs to include the swap routines. This can
work but i would much prefer adding more entry to the libary list. Less
work, more simple code, less maintenance when a new application is added...
If there is extra processing du to the library list, i would upgrade the
AS/400 (cheaper than the software modification)
>
>Denis Robitaille
>Cascades inc.
>Tel: 819-363-5187
>DRobitaille@cascades.com
>
>>>> Rob Marssdorf <Rob@cascade400.com> 11/27 2:46 pm >>>
>I understand how you are segmenting the data.  Makes sense.  You're right
>about the OVRDBF on the data files.
>
>I know I work on a machine with a lot of co-dependence, where 25 librs is
>plenty of space.  My thought is that since you've got essentially 11 librs
>available, things either have to be done with explicit overrides or you
>need to manage the LIBL at run time of each app.
>
>Would saving off the LIBL when entering an application work for you?  You
>know - enter the app, save LIBL, set LIBL to what you need, run app,
>restore LIBL when exiting app.  Or are the applications really co-dependent
>upon one another, requiring all libraries to be in the list?
>
>I know I've seen a utility pgm to save/restore the LIBL - didn't pay too
>much heed to it, but it might make sense in your case.
>
>Whaddaya think?
>
>Rob
>
>
>
>
>
>At 01:24 PM 11/27/98 -0500, you wrote:
>>
>>
>>Denis Robitaille
>>Cascades inc.
>>Tel: 819-363-5187
>>DRobitaille@cascades.com 
>>
>>>>> Rob Marssdorf <Rob@cascade400.com> 11/27 11:52 am >>>
>>>Can the job stream be broken up into multiple runs - say one for North
>>>America, another for Europe?  Sounds like both could run at the same time
>>>that way.
>>
>>It is. In fact this setup allows us to run both english and sweddish on
>the same machine. The english users have the APP*ENG libraries in theire
>librairy list and the sweed users have the APP*SWE libraries in their. That
>is why we need 2 library per applications.
>>
>>>If not, I think that if the processing program were to explicitly override
>>>the files for each application to the appropriate library at run time, you
>>>could bypass the library list issue - you're not doing an ADDLIBLE, you're
>>>just pointing the file to the library location with the OVRDBF.
>>
>>We would have to override message files, display files, printer files,
>panel group(for help), menus. I'am not even sure if all those are
>overidable. Also, this can add a lot of codes to ALL programs (Ex: clp pgm
>A call rpg pgm B that call rpg pgm C ... then all override must be coded in
>pgm A, maintenance hell). Also, when you explicitly use a library name,
>this makes things harder in test mode (you can not use the library list to
>access test object).
>>
>>Overriding data files would save 2 entries and put my maximun number of
>application to 11
>>
>>+---
>>| 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 
>>+---
>>
>>
>=======================================================
>http:\\www.cascade400.com      IBM AS400 User Group    
>mailto:rob@cascade400.com      Portland, Oregon 
>=======================================================
>+---
>| 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
>+---
>
>
=======================================================
http:\\www.cascade400.com       IBM AS400 User Group    
mailto:rob@cascade400.com       Portland, Oregon 
=======================================================
+---
| 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
+---