|
Thanks Barbara, that looks like the best way to approach it. I'm wondering though why initial environment values can't be set with a job description, in the same way as library lists. Is that due to the usual reason (ie only 24 hours in a working day) or has the job description design fallen out of favour? Regards, John |---------+------------------------------> | | Barbara Morris | | | <bmorris@xxxxxxxxxx| | | > | | | Sent by: | | | java400-l-bounces@m| | | idrange.com | | | | | | | | | 09/11/2004 02:29 PM| | | Please respond to | | | Java Programming on| | | and around the | | | iSeries / AS400 | | | | |---------+------------------------------> >--------------------------------------------------------------------------------------------------------------| | | | To: java400-l@xxxxxxxxxxxx | | cc: | | Subject: Re: Deploying jar files | >--------------------------------------------------------------------------------------------------------------| jthompson@xxxxxxxxxxx wrote: > ... > I guess I should outline what I'm currently doing: > - any RPG program that wants to use Java classes calls a procedure > 'setClassPath' which sets the environment value CLASSPATH. This is good > because it means the classpath is set differently for developers and all > other users (the code within setClassPath is able to determine whethwer > it's a development or production environment). But it's also bad because 1) > once the JVM is started, all subsequent calls to setClassPath are > ineffective 2) developers aren't always remembering to code the call 3) > everytime I want to evaluate a new Java extension it means code changes and > re-compilations. > If developers know who they are, and possibly already call something to setup the development environment, then you could have *SYS level environment variable that sets up CLASSPATH for all-other-users, and developers could call some startup CL program that replaces that job's *JOB CLASSPATH envvar with the development version of the classpath. If the set-dev-envvar program wasn't called, the job would default to the all-other-users envvar. When you need to change the classpath, you have only two places to do it: the *SYS envvar and the program that sets the *JOB envvar. I would stay away from calling setClassPath from every program. It will become less and less reliable as more of your RPG programs use Java, for all three reasons you state. -- This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/java400-l or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.