Re: Library List question...

How I handle it in my applications is each time I work with
a company with multiple environtments like that there is
something that will tell me which
division/company/warehouse to use (in the case of different
warehouses, divisions, etc).  That's usually stored in a
cookie.

So first I set up two libraries prod and devo (maybe even a
test one too) for CGI apps.  Each CGI library has a file
that contains the library list to use, keyed by the
information that says which company to use.

How the system knows which CGI library to use is determined
by the config (usually on different ports, 80 for prod,
8080 for devo/test).

So this way my app just calls a subprocedure that sets the
library list for each company, and each environment (prod
or devo) can use it's own seperate library list as well.

Works very well...

Brad
www.bvstools.com

On Wed, 13 Apr 2005 15:07:59 -0500
 rob@xxxxxxxxx wrote:
> Makes sense, however in a "shared" program library scheme
> like you 
> mentioned you keep you programs in one library.  Let's
> say DHTDIVO.  Then 
> you may keep you files in other libraries.  Let's say
> DHT001F and DHT002F 
> for plant 1's files and plant 2's files.  Now, if you
> follow the 
> suggestion to add the library containing the program to
> your library list 
> from reading the psds or whatever, that doesn't buy you
> jack.  Or, if you 
> read some job description and then use the api to get
> it's library list (I 
> wrote my own RTVJOBD command), let's say job description
> 

STANDARD out of 
> the library containing the program that still doesn't buy
> you jack, unless 
> you can figure out another way to differentiate which job
> description to 
> load up.  I suppose you could look at the job description
> associated with 
> the user profile logged in at the time.  I'll admit I am
> still in the 
> lurking stage on web design but from what I hear figuring
> out the user 
> logged in isn't simply a field in the psds of a rpg
> program.
> 
> Rob Berendt
> -- 
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "Peter Vidal" <Peter_Vidal@xxxxxxxx> 
> Sent by: web400-bounces@xxxxxxxxxxxx
> 04/13/2005 07:08 AM
> Please respond to
> Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
> 
> 
> To
> Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
> cc
> 
> Subject
> RE: [WEB400] Library List question...
> 
> 
> 
> 
> 
> 
> "I'm trying to understand what the advantage of using a
> library list is?
> If the program has to be aware of the library (regardless
> of whether it
> gets this info from a constant in the program or whether
> it reads it
> from a file, data area, parameter, etc) then why not just
> specify the
> libraries explictly when opening the file?  What good is
> the library
> list?"
> 
> On shared applications, you do not want to specify
> libraries in programs. 
> You want the application to behave consistently with the
> same database, 
> regardless if it is working against the production
> environment (libraries) 
> 
> or test environment.  That is why is really important the
> *LIBL.  It will 
> define to the program "to whom I am talking to":
> production or test? 
> 
> 
> Peter Vidal 
> PALL Corporation / SR Programmer Analyst, IT Development
> Group
> 10540 Ridge Rd., Ste 203, New Port Richey, FL 34654-5111
> http://www.pall.com
> 
> "Courage is the strength or choice to begin a change.
> Determination is the 
> 
> persistence to continue in that change." 
> -- Anonymous ---- 
> This is the Web Enabling the AS400 / iSeries (WEB400)
> mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
> 
> 
> -- 
> This is the Web Enabling the AS400 / iSeries (WEB400)
> mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com