Buck,
Yep. I forgot that. Most of our Excel jobs been moved
up as we have developed. We have a CLP that runs before
the job invokes the Excel build. And as you say, once run,
no other environment CLP will change that until the user
signs off.
So for example, JARFILECL was the first production
environment CL we used and then we built Excels with
later POI's and we used JARFILE2,3, etc.
As we progressed we killed off the older CLP's.
My point was just don't do the system environment
unless you know what you are doing. But it seems more
flexible to use the job instead of the system. Especially
for testing and those ENUMS that keep showing up in
the new releases.
Bill
From: Buck Calabro <kc2hiz@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 01/18/2018 11:23 AM
Subject: Re: Java extensions directory vs Excel generation
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
On 1/18/2018 11:22 AM, broehmer@xxxxxxxxxxxxxxx
wrote:
Those programs that call those Excel spreadsheet builds should change
the
classpath
for the job only.
We basically do this, but it needs to be stated that there is no 'for
the job only'. For each job, one gets to set the CLASSPATH exactly
once. After the JVM starts, the CLASSPATH value is never going to be
read again no matter how many times a job changes it.
This didn't matter when we only had one Java thing per job. But the day
we added a second Java thing was the day I thought about setting *SYS
CLASSPATH for all the Java classes we might use. I didn't do it, but I
am still considering it as a future change.
midrange.com
