RE: RE: LIBL limitation of 25 libraries

I probably read the original mail to quickly.. but, I do have a few ideas
that may help...  see below...

Bradley V. Stone
Taylor Corporation - OASIS Programmer/Analyst   
bvstone@taylorcorp.com


> -----Original Message-----
> From: Denis Robitaille [SMTP:DRobitaille@cascades.com]
> Sent: Friday, November 27, 1998 2:36 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: RE: LIBL limitation of 25 libraries
> 
> This is excactly what we do right now. I'm sorry if i was not clear
> enought in my previous explanation, i will give it another try.
> 
> We have several types of librairies:
> 
> Data library: They all start with the letter DATA and they contains the PF
> and LF for a particular company/year
> EX: DATA001Y97  : data for company #001 for the year 97
> We need at most 2 of theese at a time in the libary list
> 
        [And Brad Said:]  Could you add a left-most key to your data files
that is the year?  Then the files could be in one data library, and you'd
simply have to change the key lists to use the year that you are looking to
retrieve data for.  

> Program libraries: They have the format APPxx where xx = the application
> code (pay roll, production ...). They contains the part of the software
> that is language independant: RPG, CL (source and object). It also
> contains the sources of all other part of the software (DSPF, PRTF, menu
> ...)
> 
        [And Brad Said:]  Hmmm... is this a canned package?  Could you
consolodate some of these libraries even further?  Or could these libraries
reside in the product library list?  I haven't messed with this part before,
but I'm guesing it may be possible.

> Language libraries: They have the format APPxxLLL where xx = application
> code and LLL = Language code. It contains language related objects:
> message files, object of DSPF, PRTF, menu ... (The sources uses messages
> constant so only one source member is needed and it is stored in APPxx) 
> 
        [And Brad Said:]  This you will have to leave.  But, you will only
need to have one specific language in the libl at a time.

> Other libraries: QTEMP, QGPL
        [And Brad Said:]  QTEMP could _possibly_ be added to the system
library list.  It's always at the top of our user library list (for temp
files, work files, etc), so I don't forsee a problem with bumping it up to
the system or production library list.  Again, I'm not sure this would work,
or haven't really put much thought into the ramifications of this.  QGPL on
the other had always resides at the bottom of our user library list.

> So, to be able to run an application, you need access to the data library,
> the application library and the language library.
> 
> Here is a complete example of the library list of an english and sweedish
> user who needs access to the same application for the same company:
> 
> English users:
> 
> QTEMP
> QGPL
> DATA001Y98            company 001  data for year 1998
> APPIVENG                english componant of the IV (inventory)
> application
> APPIV                        language independant componant of the IV
> application
> APPSAENG               english componant of the SA (sales) application
> APPSA                       language independant componant of the SA
> application
> 
> Sweedish user:
> 
> QTEMP
> QGPL
> DATA001Y98            company 001  data for year 1998
> APPIVSWE                sweedish componant of the IV (inventory)
> application
> APPIV                        language independant componant of the IV
> application
> APPSASWE               sweedish componant of the SA (sales) application
> APPSA                       language independant componant of the SA
> application
> 
> As you can see, the library list contains only the parts for one language
> 
> Denis Robitaille
> Cascades inc.
> Tel: 819-363-5187
> DRobitaille@cascades.com
> 
> >>> "Stone, Brad V (TC)" <bvstone@taylorcorp.com> 11/27 2:05 pm >>>
> Why wouldn't you use different job descriptions for each the English and
> Sweedish users?  There's no need to have english libraries in a library
> list
> for the sweedish.
> 
> Bradley V. Stone
> Taylor Corporation - OASIS Programmer/Analyst 
> bvstone@taylorcorp.com 
> 
> 
> > -----Original Message-----
> > From:       Denis Robitaille [SMTP:DRobitaille@cascades.com] 
> > Sent:       Friday, November 27, 1998 12:25 PM
> > To: MIDRANGE-L@midrange.com 
> > Subject:    Re: LIBL limitation of 25 libraries
> > 
> > 
> > 
> > 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 
> > +---
> +---
> | 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
> +---
+---
| 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
+---