Re: setting default Java version

Do not suggest this kind of setting, unless you are pretty sure about it.
A *SYS level of setting of JAVA_HOME would affect every JVM on the system
, including some system jobs.
Suggest to create your own script/CL to call java , and setup the
JAVA_HOME env before the java call. This would only affect your own jobs.

Best regards.
____________________________________________________________________________________________

Gavin, Zhang Gan --
https://w3-connections.ibm.com/profiles/html/profileView.do?key=d77158d7-c5cd-4e6e-a90d-23dddc9cbaba&lang=en

IBM i J9 Team Lead,
Email: zhanggan@xxxxxxxxxx
Phone: +86-10-82452719
Address: 1/F, 28, ZhongGuanCun Software Park, No.8 Dong Bei Wang West
Road, Haidian District, Beijing P.R.China 100193
J9 on i: http://www.ibm.com/developerworks/ibmi/techupdates/java



CRPence <CRPbottle@xxxxxxxxx>
Sent by: java400-l-bounces@xxxxxxxxxxxx
05/31/2013 04:21 AM
Please respond to
Java Programming on and around the IBM i <java400-l@xxxxxxxxxxxx>


To
java400-l@xxxxxxxxxxxx,
cc

Subject
Re: setting default Java version






On 30 May 2013 12:53, Glenn Holmer wrote:

On 05/23/2013 08:58 AM, Dan Kimmel wrote:

Extend the ADDENVVAR command with LEVEL(*SYS) to set the default
for the machine.

From:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/unix1a.htm


System-level environment variables. The system-level environment
variables are stored in a global environment space that is
persistent across IPLs and is not associated to a particular job.
<<SNIP>>

That only needs to be done once, right? (i.e. not in QSTRUP?)

Yes. Just set once... whenever, wherever. As the doc snippet says,
the storage for the System-Level (*SYS) Environment Variables is
"persistent across" system end\start activity.

However... The setting is a /change/ to the system that should be
included in the System Change Management, to ensure that the desired
setting is established again when appropriate; e.g.upon migration to
another physical system. Some CM implementations may activate that
within the QSTRUPPGM which may have an always-set path or an optional
path based on conditional logic that recognizes a change for which a
[re]set is deemed appropriate; e.g. a value retrieved from an object
that is not part of the Backups that would be used for Disaster
Recovery, such that if the object does not exist or the value
mis-compares to the expected, then the optional path effects the
[re]setting along with the creation and\or resetting of the stored value.