NetRexx 2.05 Installation anomalies

[Aviatrexx]

OK, it took 'way too long for me to get NetRexx installed this time, and I've
installed it many times in the past.  Here's a partial list of discrepancies,
anomalies, issue, and general rough edges:

1. The read.me.first file has no indication that the user needs to download the
latest Java Developer Kit due to removal of tools.jar from JRE distribution.

  - Previously noted.  Easy editorial fix.

2. The read.me.first file makes a distinction between pre- and post-Java-1.2
versions.  This distinction is now moot (one hopes) and only serves to confuse
the user.

  - Easy editorial fix.

3. The read.me.first file does not consider that the user may have a copy of the
JDK _and_ the JRE installed at the same time.  This is most likely because some
other package installed the JRE prior to the user installing the JDK, and there
is probably a dependency that preclude un-installing it.

The problem here is that there is a 'jre' directory tree beneath the JDK
directory, with exactly the same directory structure as the one under the JRE
directory.  Therefore the instructions to place the NetRexxC.jar and tools.jar
files into the "jre/lib/ext" directory are ambiguous.

Worse yet, if the user moves the files to the [JDK]/jre/lib/ext directory,
NetRexxC is not found!  The "correct" directory (the one that works) is the
%ProgramFiles%/jre6/lib/ext directory.  Note that this is true with an
unmodified CLASSPATH variable.

  - Not an easy fix AFAICT.

4. The installation instructions in read.me.first should offer at least two
installation paths: one where the NetRexxC.jar and tools.jar files are moved to
the correct Java lib/ext directory to make them accessible, and one that does
not involve moving files around.  Supposedly this is possible by properly
updating the CLASSPATH variable, but I was unable to get that to work after
exhaustive tests.

If anyone has a working example of compiling and execution a NetRexx program
with the NetRexxC.jar and tools.jar files in their original directories, please
tell me how you did it!

Updating the system PATH and CLASSPATH variables in Windows is a Royal PITA, but
I strongly believe that is the correct approach, to avoid a bigger mess when
either NetRexx or Java is updated.  This also facilitate maintaining multiple
releases of NetRexx (not sure about Java) in order to test and validate a new
release.

  - Not an easy fix AFAICT.  It appears that Java cavalierly ignores the
CLASSPATH these days.  If this is not possible any longer, the read.me.first
file needs to remove that verbiage.

5. The invocation scripts NetRexxC.cmd, .bat, and .sh need to have the '-ms4M'
flag removed, and sad to say, the OS/2 .cmd file still runs rings around them both.

  - Easy fix (SMOP) unless you want to make the .bat file as smart as the .cmd file.

6. The read.me.first file refers in two places to additional installation
information ("full details", "detailed instructions", and "problem-solving
tips") to be found in the Users Guide.  AFAICT, there is no further information
there.

  - Easy fix to remove references; a little more difficult to add the missing
info to the Users Guide.

7. Soon the URLs for the location of the download files will need to change.

  - Easy fix.

The toughest nut to crack seems to be that of making Java and NetRexx place nice
without the need to move files around.

Can anyone offer any help?

-Chip-

[David Requena]

Chip,


2010/2/11 Chip Davis <[hidden email]>

>
> 3. The read.me.first file does not consider that the user may have a copy
> of the JDK _and_ the JRE installed at the same time.  This is most likely
> because some other package installed the JRE prior to the user installing
> the JDK, and there is probably a dependency that preclude un-installing it.
>
> The problem here is that there is a 'jre' directory tree beneath the JDK
> directory, with exactly the same directory structure as the one under the
> JRE directory.  Therefore the instructions to place the NetRexxC.jar and
> tools.jar files into the "jre/lib/ext" directory are ambiguous.
>
> Worse yet, if the user moves the files to the [JDK]/jre/lib/ext directory,
> NetRexxC is not found!  The "correct" directory (the one that works) is the
> %ProgramFiles%/jre6/lib/ext directory.  Note that this is true with an
> unmodified CLASSPATH variable.
>

In windows at least jre/jdk installs are a total mess since Sun abandoned
the JAVA_HOME env var.
Nowadays every jre you install places copies some binary files (javaw.exe,
java.exe,...) in %SystemDrive%\%SystemRoot%\System32 then sets some registry
entries to direct this binaries to their corresponding install directory for
their resources. Look under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft.
Only control the user has without firing regedit is altering order in the
path env. var. Fortunately each java.exe will find its resources thanks to
registry lookups so they don't get mixed up.
That said I have several installs of both jre and jdk. See below.


> Updating the system PATH and CLASSPATH variables in Windows is a Royal
> PITA, but I strongly believe that is the correct approach, to avoid a bigger
> mess when either NetRexx or Java is updated.  This also facilitate
> maintaining multiple releases of NetRexx (not sure about Java) in order to
> test and validate a new release.
>

According to recent posts, seems to me it very difficult to get a consistent
behaviour just by modifying CLASSPATH


> 5. The invocation scripts NetRexxC.cmd, .bat, and .sh need to have the
> '-ms4M' flag removed, and sad to say, the OS/2 .cmd file still runs rings
> around them both.
>

Besides latest java level on OS/2 is 1.4.2 I think. OS/2 users aren't
affected by this particular issue. Maybe they will if and when openJDK 1.7
makes its way to OS/2 & eCommStation...


>  - Easy fix (SMOP) unless you want to make the .bat file as smart as the
> .cmd file.
>

That'd be quite a feat, would it? :-D


> The toughest nut to crack seems to be that of making Java and NetRexx place
> nice without the need to move files around.
>
> Can anyone offer any help?
>

I do regularly by means of NetRexxDE :-)
But seriously, what I did when using the scripts was:

- having a NRX_HOME env var pointing to location of NetRexxC.jar
- having a NRX_JAVA_HOME env var pointing tho the jdk's jre.
- modify the call to java in NetRexxC.bat so it was like
     %NRX_JAVA_HOME%\bin\java.exe -cp .;%NRX_HOME% rest of the line...

It was (for me) a workable arrangement which allowed me to use different
versions of both jdk and NetRexx just by varying either of said variables.

Seems to me a sensible solution when the time comes would be setting up some
installer for the product.

--
Saludos / Regards,
David Requena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100211/69901f5f/attachment.html

[rvjansen]

I am sorry to say that these are mostly Windows issues.

- the -ms4M works fine here on Mac OSX Java, but we will have to take it out

Note that my whole nrc shell script is:

java -Xms256M -Xmx512M COM.ibm.netrexx.process.NetRexxC $*

and I never saw the need for more lines of scripting to kick off a build. I do however need more memory due to the size of my projects.

I really cannot believe Java 6 on Windows will not look at CLASSPATH environment variable setting anymore. This is contrary to all (now) Oracle documentation that is currently online.
Do note that my last email was held up by the listserver for more than 12 hours and subsequently makes me look a more stubborn person than I am in reality. Not much, but still.

I will have to install a Windows version in Virtualbox to counter these Windows issues. How ironic.

best regards,

Ren? Jansen.

On 11 feb 2010, at 14:40, David Requena wrote:

> Chip,
>
>
> 2010/2/11 Chip Davis <[hidden email]>
>
> 3. The read.me.first file does not consider that the user may have a copy of the JDK _and_ the JRE installed at the same time.  This is most likely because some other package installed the JRE prior to the user installing the JDK, and there is probably a dependency that preclude un-installing it.
>
> The problem here is that there is a 'jre' directory tree beneath the JDK directory, with exactly the same directory structure as the one under the JRE directory.  Therefore the instructions to place the NetRexxC.jar and tools.jar files into the "jre/lib/ext" directory are ambiguous.
>
> Worse yet, if the user moves the files to the [JDK]/jre/lib/ext directory, NetRexxC is not found!  The "correct" directory (the one that works) is the %ProgramFiles%/jre6/lib/ext directory.  Note that this is true with an unmodified CLASSPATH variable.
>
> In windows at least jre/jdk installs are a total mess since Sun abandoned the JAVA_HOME env var.
> Nowadays every jre you install places copies some binary files (javaw.exe, java.exe,...) in %SystemDrive%\%SystemRoot%\System32 then sets some registry entries to direct this binaries to their corresponding install directory for their resources. Look under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft.
> Only control the user has without firing regedit is altering order in the path env. var. Fortunately each java.exe will find its resources thanks to registry lookups so they don't get mixed up.
> That said I have several installs of both jre and jdk. See below.
>  
> Updating the system PATH and CLASSPATH variables in Windows is a Royal PITA, but I strongly believe that is the correct approach, to avoid a bigger mess when either NetRexx or Java is updated.  This also facilitate maintaining multiple releases of NetRexx (not sure about Java) in order to test and validate a new release.
>
> According to recent posts, seems to me it very difficult to get a consistent behaviour just by modifying CLASSPATH
>  
> 5. The invocation scripts NetRexxC.cmd, .bat, and .sh need to have the '-ms4M' flag removed, and sad to say, the OS/2 .cmd file still runs rings around them both.
>
> Besides latest java level on OS/2 is 1.4.2 I think. OS/2 users aren't affected by this particular issue. Maybe they will if and when openJDK 1.7 makes its way to OS/2 & eCommStation...
>  
>  - Easy fix (SMOP) unless you want to make the .bat file as smart as the .cmd file.
>
> That'd be quite a feat, would it? :-D
>  
> The toughest nut to crack seems to be that of making Java and NetRexx place nice without the need to move files around.
>
> Can anyone offer any help?
>
> I do regularly by means of NetRexxDE :-)
> But seriously, what I did when using the scripts was:
>
> - having a NRX_HOME env var pointing to location of NetRexxC.jar
> - having a NRX_JAVA_HOME env var pointing tho the jdk's jre.
> - modify the call to java in NetRexxC.bat so it was like
>      %NRX_JAVA_HOME%\bin\java.exe -cp .;%NRX_HOME% rest of the line...
>
> It was (for me) a workable arrangement which allowed me to use different versions of both jdk and NetRexx just by varying either of said variables.
>
> Seems to me a sensible solution when the time comes would be setting up some installer for the product.
>
> --
> Saludos / Regards,
> David Requena
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100211/7daf5cea/attachment-0001.html

[David Requena]

Ren?,

I'm afraid at least some Linux distros are affected by the heap size issue
too. Mind you the user who brought my attention to the problem
was in fact working on Linux.

This -ms4M switch should never have been there to start with as is a
non-standard option. Nothing I could find at the NetRexx documentation
seems to indicate that use of other jvms is not supported. Au contraire,
 IBM Developer Kits for Java are explicitly mentioned (frankly I don't
know if IBM's jvms support the option)

Your custom nrc script is somewhat proving our point: not experiencing
trouble at your end but, then, you're not using what is actually
being distributed with NetRexx.

On the CLASSPATH thing.. I wouldn't know, I've never used it. Definitely
seems to behave inconsistently across java versions and platforms
judging by what we've been reading lately here at the list.


2010/2/11 Ren? Jansen <[hidden email]>

> I am sorry to say that these are mostly Windows issues.
>
> - the -ms4M works fine here on Mac OSX Java, but we will have to take it
> out
>
> Note that my whole nrc shell script is:
>
> java -Xms256M -Xmx512M COM.ibm.netrexx.process.NetRexxC $*
>
> and I never saw the need for more lines of scripting to kick off a build. I
> do however need more memory due to the size of my projects.
>
> I really cannot believe Java 6 on Windows will not look at CLASSPATH
> environment variable setting anymore. This is contrary to all (now) Oracle
> documentation that is currently online.
> Do note that my last email was held up by the listserver for more than 12
> hours and subsequently makes me look a more stubborn person than I am in
> reality. Not much, but still.
>
> I will have to install a Windows version in Virtualbox to counter these
> Windows issues. How ironic.
>
> best regards,
>
> Ren? Jansen.
>
> On 11 feb 2010, at 14:40, David Requena wrote:
>
> Chip,
>
>
> 2010/2/11 Chip Davis <[hidden email]>
>
>>
>> 3. The read.me.first file does not consider that the user may have a copy
>> of the JDK _and_ the JRE installed at the same time.  This is most likely
>> because some other package installed the JRE prior to the user installing
>> the JDK, and there is probably a dependency that preclude un-installing it.
>>
>> The problem here is that there is a 'jre' directory tree beneath the JDK
>> directory, with exactly the same directory structure as the one under the
>> JRE directory.  Therefore the instructions to place the NetRexxC.jar and
>> tools.jar files into the "jre/lib/ext" directory are ambiguous.
>>
>> Worse yet, if the user moves the files to the [JDK]/jre/lib/ext directory,
>> NetRexxC is not found!  The "correct" directory (the one that works) is the
>> %ProgramFiles%/jre6/lib/ext directory.  Note that this is true with an
>> unmodified CLASSPATH variable.
>>
>
> In windows at least jre/jdk installs are a total mess since Sun abandoned
> the JAVA_HOME env var.
> Nowadays every jre you install places copies some binary files (javaw.exe,
> java.exe,...) in %SystemDrive%\%SystemRoot%\System32 then sets some registry
> entries to direct this binaries to their corresponding install directory for
> their resources. Look under HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft.
> Only control the user has without firing regedit is altering order in the
> path env. var. Fortunately each java.exe will find its resources thanks to
> registry lookups so they don't get mixed up.
> That said I have several installs of both jre and jdk. See below.
>
>
>> Updating the system PATH and CLASSPATH variables in Windows is a Royal
>> PITA, but I strongly believe that is the correct approach, to avoid a bigger
>> mess when either NetRexx or Java is updated.  This also facilitate
>> maintaining multiple releases of NetRexx (not sure about Java) in order to
>> test and validate a new release.
>>
>
> According to recent posts, seems to me it very difficult to get a
> consistent behaviour just by modifying CLASSPATH
>
>
>> 5. The invocation scripts NetRexxC.cmd, .bat, and .sh need to have the
>> '-ms4M' flag removed, and sad to say, the OS/2 .cmd file still runs rings
>> around them both.
>>
>
> Besides latest java level on OS/2 is 1.4.2 I think. OS/2 users aren't
> affected by this particular issue. Maybe they will if and when openJDK 1.7
> makes its way to OS/2 & eCommStation...
>
>
>>  - Easy fix (SMOP) unless you want to make the .bat file as smart as the
>> .cmd file.
>>
>
> That'd be quite a feat, would it? :-D
>
>
>> The toughest nut to crack seems to be that of making Java and NetRexx
>> place nice without the need to move files around.
>>
>> Can anyone offer any help?
>>
>
> I do regularly by means of NetRexxDE :-)
> But seriously, what I did when using the scripts was:
>
> - having a NRX_HOME env var pointing to location of NetRexxC.jar
> - having a NRX_JAVA_HOME env var pointing tho the jdk's jre.
> - modify the call to java in NetRexxC.bat so it was like
>      %NRX_JAVA_HOME%\bin\java.exe -cp .;%NRX_HOME% rest of the line...
>
> It was (for me) a workable arrangement which allowed me to use different
> versions of both jdk and NetRexx just by varying either of said variables.
>
> Seems to me a sensible solution when the time comes would be setting up
> some installer for the product.
>
> --
> Saludos / Regards,
> David Requena
>
>  _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>

--
Saludos / Regards,
David Requena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100211/5071a3e9/attachment.html

[Mike Cowlishaw]

 " This -ms4M switch should never have been there to start with as is a
non-standard option. Nothing I could find at the NetRexx documentation
seems to indicate that use of other jvms is not supported. Au contraire,
IBM Developer Kits for Java are explicitly mentioned (frankly I don't  know
if IBM's jvms support the option) "
 
Chuckle -- it was standard at the time (hence no leading X) because it was
in both the IBM and Sun JVMs (the only widely-distributed JVMs at the time).
And it was necessary because without it any moderately large compile (e.g.,
of the compiler itself) would fail -- and my main testcase for the scripts
was to compile the compiler.
 
Good to hear it's no longer necessary.
 
Mike
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100211/bb0c498d/attachment.html

[David Requena]

Uh, oh.. A sinking feeling..

I guess I left off the 'probably' I had in my mind at the start of that sentence.

I understand that standard or not raising the heap size form the paltry (even for that time) 2MB default was a necessity.

I've seen also re-reading the User's Guide' that these're described as just 'sample scripts'.

Anyway I think it's the jvm who is ultimately at fault here. Initializing with a bigger heap size than the minimum requested by the user instead of refusing to initialize, would still literally honour the user's request!

We have to live with the constraints of the hosting environment. OTOH it's interesting getting to know of this kind of anecdotal bits from the origins of the language.

BlackBerry de movistar, all? donde est?s est? tu oficin@

-----Original Message-----
From: "Mike Cowlishaw" <[hidden email]>
Date: Thu, 11 Feb 2010 16:58:57
To: 'IBM Netrexx'<[hidden email]>
Subject: RE: [Ibm-netrexx] NetRexx 2.05 Installation anomalies

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

> Uh, oh.. A sinking feeling..

:-)
 
> Anyway I think it's the jvm who is ultimately at fault here.

Yes, "run anywhere" should include "continue to run on the same platform 5
years from now".

In contrast, I've been re-viewing some of my VM/CMS programs recently.  Some
were last compiled/assembled in the late 1970s -- yet still run perfectly
now, dozens of operating systems updates later...

> Initializing with a bigger heap size than the minimum
> requested by the user instead of refusing to initialize,
> would still literally honour the user's request!

Agreed!
 
> We have to live with the constraints of the hosting
> environment. OTOH it's interesting getting to know of this
> kind of anecdotal bits from the origins of the language.

:-)

Mike

[Aviatrexx]

On 2/12/10 08:13 Mike Cowlishaw said:
>> Anyway I think it's the jvm who is ultimately at fault here.
>
> Yes, "run anywhere" should include "continue to run on the same platform 5
> years from now".

Which is another reason I'm not very happy with the necessity to move files
around (one of them a Java file) just to get NetRexx to work.  What are the odds
that this week's directory will be correct when the next release comes out?

Unless someone offers a more elegant solution than David's use of NetRexx
environment variables, that's the approach I will take as well.

I don't know enough Java even to be dangerous (that's why I have NetRexx, to hid
the ugly :-) but I wonder if a small Java program could determine where the
active JDK and NetRexx installations reside and create the necessary NetRexx
environment variables?

A side benefit would be that it could also create the small uninstall routine
for NetRexx, and place itself in the "Add or Remove Programs" list (which is
magic as far as I can tell).

I don't suppose there are .bat file facilities that could do all that, are there?

It sure would be nice if NetRexx installed on Windows as easily as oh, say,
Regina... ;-)

> In contrast, I've been re-viewing some of my VM/CMS programs recently.  Some
> were last compiled/assembled in the late 1970s -- yet still run perfectly
> now, dozens of operating systems updates later...

It does seem that the hardware guys take backwards-compatibility much more
seriously than the software guys... :-/

-Chip-

[rvjansen]

Chip,

I am sympathetic to the troubles you went through, but having platform
specific code around to support a platform independent runtime is a
line I'd personally rather not cross. Which does not mean the
soon-to-be-blossoming NetRexx community will not solve it.

This exchange has taught me several things:

- always try out the current situation myself before answering based
on own but stale experience
- the heated rear view mirror always breaks the car

I am going to move the scripts to a "samples" directory. In my current
opinion (of today) there are a lot of JVM options relevant to the
execution of NetRexx programs, including the translator - garbage
collection, heap size, classpath, to name a few, which (in my
practice) are changed frequently according to changing requirements of
different projects. The example kickoff scripts should serve as a base
for the user to change according to their own requirements and
experience. As soon as one starts using packages for ones classes,
something needs to be done to classpath anyway - I see no point in
making a jar every time and copying that to a fixed destination before
testing the change.

As I mentioned, Rony did some rather nifty tricks for getting BSF4Rexx
to work with both Object Rexx and Open Office. These have more or less
the same JVM class library location trouble as other Java programs do.
I am thinking along the lines of adding something like that - to write
a bullet proof startup script for that particular users setup. This
also is an excellent place to add environmental wisdom to, instead of
adding this to the translator itself.

Now that I think back on this easy Friday afternoon at work (everybody
is gone), I removed a -ms4M myself only some weeks ago when installing
on someone's windows box. I probably did not see this as significant
enough to remember in quickly accessible storage.

I am still wondering if your remark on the handling of the classpath
environment variable on Java 6 could be correct - did you restart
shell after changing it? This would deviate from all other
implementations I know. Word was a few years ago that the extra flags
were only added for platforms without a usable environment concept,
like some phones. The extension directories were added for less
problematic handling of other XML libraries than the internals ones -
this was when Java added the Apache Xerces and Xalan, but old versions
of those.

Please let me know.

best regards,

Ren?




On Fri, Feb 12, 2010 at 11:34 AM, Chip Davis <[hidden email]> wrote:

> On 2/12/10 08:13 Mike Cowlishaw said:
>>>
>>> Anyway I think it's the jvm who is ultimately at fault here.
>>
>> Yes, "run anywhere" should include "continue to run on the same platform 5
>> years from now".
>
> Which is another reason I'm not very happy with the necessity to move files
> around (one of them a Java file) just to get NetRexx to work. ?What are the
> odds that this week's directory will be correct when the next release comes
> out?
>
> Unless someone offers a more elegant solution than David's use of NetRexx
> environment variables, that's the approach I will take as well.
>
> I don't know enough Java even to be dangerous (that's why I have NetRexx, to
> hid the ugly :-) but I wonder if a small Java program could determine where
> the active JDK and NetRexx installations reside and create the necessary
> NetRexx environment variables?
>
> A side benefit would be that it could also create the small uninstall
> routine for NetRexx, and place itself in the "Add or Remove Programs" list
> (which is magic as far as I can tell).
>
> I don't suppose there are .bat file facilities that could do all that, are
> there?
>
> It sure would be nice if NetRexx installed on Windows as easily as oh, say,
> Regina... ;-)
>
>> In contrast, I've been re-viewing some of my VM/CMS programs recently.
>> ?Some
>> were last compiled/assembled in the late 1970s -- yet still run perfectly
>> now, dozens of operating systems updates later...
>
> It does seem that the hardware guys take backwards-compatibility much more
> seriously than the software guys... :-/
>
> -Chip-
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

[Thomas.Schneider.Wien]

Hello Rene,
   first thanks for your full explanation of all the details affected.

Second, I did bother similar problems with my Rexx2Nrx & DB-123
software, and did SOLVE it
there by the use of a so called Rexx2Nrx.globals & DB123.globals file,
wich must be
accessible by the PATH, but may be modified by the user as it likes.

Then, by using my symbol(...)  and value(...) emulations (currently see
\Rexx2RT\RexxSymb at www.Rexx2Nrx.com :-)),

I am setting the proper (global) 'properties' at the start of each task ...

In the current version I am working on, I also eliminated the need of
any BATCH-Files except one (the major one).

... and wrote some small NetRexx Programs reading (loading) the globals
first, and then invoking the other
steps....

Might be that this technique might be useful/helpful for NetRexx as well...

We should discuss this further, of course, when you like.

Tom.
================================================================================

Ren? Jansen schrieb:

> Chip,
>
> I am sympathetic to the troubles you went through, but having platform
> specific code around to support a platform independent runtime is a
> line I'd personally rather not cross. Which does not mean the
> soon-to-be-blossoming NetRexx community will not solve it.
>
> This exchange has taught me several things:
>
> - always try out the current situation myself before answering based
> on own but stale experience
> - the heated rear view mirror always breaks the car
>
> I am going to move the scripts to a "samples" directory. In my current
> opinion (of today) there are a lot of JVM options relevant to the
> execution of NetRexx programs, including the translator - garbage
> collection, heap size, classpath, to name a few, which (in my
> practice) are changed frequently according to changing requirements of
> different projects. The example kickoff scripts should serve as a base
> for the user to change according to their own requirements and
> experience. As soon as one starts using packages for ones classes,
> something needs to be done to classpath anyway - I see no point in
> making a jar every time and copying that to a fixed destination before
> testing the change.
>
> As I mentioned, Rony did some rather nifty tricks for getting BSF4Rexx
> to work with both Object Rexx and Open Office. These have more or less
> the same JVM class library location trouble as other Java programs do.
> I am thinking along the lines of adding something like that - to write
> a bullet proof startup script for that particular users setup. This
> also is an excellent place to add environmental wisdom to, instead of
> adding this to the translator itself.
>
> Now that I think back on this easy Friday afternoon at work (everybody
> is gone), I removed a -ms4M myself only some weeks ago when installing
> on someone's windows box. I probably did not see this as significant
> enough to remember in quickly accessible storage.
>
> I am still wondering if your remark on the handling of the classpath
> environment variable on Java 6 could be correct - did you restart
> shell after changing it? This would deviate from all other
> implementations I know. Word was a few years ago that the extra flags
> were only added for platforms without a usable environment concept,
> like some phones. The extension directories were added for less
> problematic handling of other XML libraries than the internals ones -
> this was when Java added the Apache Xerces and Xalan, but old versions
> of those.
>
> Please let me know.
>
> best regards,
>
> Ren?
>
>
>
>
> On Fri, Feb 12, 2010 at 11:34 AM, Chip Davis <[hidden email]> wrote:
>  
>> On 2/12/10 08:13 Mike Cowlishaw said:
>>    
>>>> Anyway I think it's the jvm who is ultimately at fault here.
>>>>        
>>> Yes, "run anywhere" should include "continue to run on the same platform 5
>>> years from now".
>>>      
>> Which is another reason I'm not very happy with the necessity to move files
>> around (one of them a Java file) just to get NetRexx to work.  What are the
>> odds that this week's directory will be correct when the next release comes
>> out?
>>
>> Unless someone offers a more elegant solution than David's use of NetRexx
>> environment variables, that's the approach I will take as well.
>>
>> I don't know enough Java even to be dangerous (that's why I have NetRexx, to
>> hid the ugly :-) but I wonder if a small Java program could determine where
>> the active JDK and NetRexx installations reside and create the necessary
>> NetRexx environment variables?
>>
>> A side benefit would be that it could also create the small uninstall
>> routine for NetRexx, and place itself in the "Add or Remove Programs" list
>> (which is magic as far as I can tell).
>>
>> I don't suppose there are .bat file facilities that could do all that, are
>> there?
>>
>> It sure would be nice if NetRexx installed on Windows as easily as oh, say,
>> Regina... ;-)
>>
>>    
>>> In contrast, I've been re-viewing some of my VM/CMS programs recently.
>>>  Some
>>> were last compiled/assembled in the late 1970s -- yet still run perfectly
>>> now, dozens of operating systems updates later...
>>>      
>> It does seem that the hardware guys take backwards-compatibility much more
>> seriously than the software guys... :-/
>>
>> -Chip-
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>>    
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>
>  

[Aviatrexx]

Thanks for the thoughtful response, Ren?.  I find that this discussion group is
a good oven in which to perfect my half-baked ideas.

I agree that a platform-independent runtime should not have platform-specific
code in it.  However, given that there are (and always will be) OS-level
platform differences, I see no way around such code at the installation and
invocation levels.  One benefit of my approach is that no longer would there be
a collection of invocation scripts for the (possibly na?ve) user to choose from,
or inadvertently invoke.  That single script would be created by the installer
based upon the environment it finds.

It appears to me that the problem is to create an installer that is smart enough
to figure out where it is, and capable enough to customize the installation and
invocation routines appropriately.

Fortuitously, all NetRexx installations should have Java available, thus my
suggestion.  Yes, I was specifically using Windows as a target environment, but
it seems to me that some sort of customization of the NetRexx invocation routine
(and de-install process) are going to be necessary on every Java platform.  Once
NetRexx is installed, the Java Runtime Environment will level the playing field
for application programs.

To my mind, having a platform-aware installation process which is run once does
not compromise the platform-independent integrity of the NetRexx processor or of
NetRexx applications themselves.

And no, I don't know how to actually write such an installer in Java.  I leave
that as "an exercise for the (smarter) student..." :-))

As for your question about Java not finding the .jar files when they were stored
in '\Java\jdk1.6.0_18\jre\lib\ext\' versus '\Java\jre6\lib\ext', note that I was
specifically not modifying the CLASSPATH for that test.  I wanted to see if the
published installation procedure would work, even if the user put the .jar files
in the "wrong" lib\ext\ directory.

At that point, CLASSPATH was ".;C:\Program Files\Java\jre6\lib\ext\QTJava.zip."
  In an argument against the documentation referencing (the somewhat evanescent)
Java file names, the only directory that exactly matched the read.me.first file
("jre/lib/ext") was the wrong one.  The files needed to be in "jre6/lib/ext".
Unless (I assume) one also updates the CLASSPATH, in which case I suppose it
does not matter where the .jar files reside, and one can (and should) not move
them in the first place.

-Chip-

On 2/12/10 15:53 Ren? Jansen said:

> Chip,
>
> I am sympathetic to the troubles you went through, but having platform
> specific code around to support a platform independent runtime is a
> line I'd personally rather not cross. Which does not mean the
> soon-to-be-blossoming NetRexx community will not solve it.
>
> This exchange has taught me several things:
>
> - always try out the current situation myself before answering based
> on own but stale experience
> - the heated rear view mirror always breaks the car
>
> I am going to move the scripts to a "samples" directory. In my current
> opinion (of today) there are a lot of JVM options relevant to the
> execution of NetRexx programs, including the translator - garbage
> collection, heap size, classpath, to name a few, which (in my
> practice) are changed frequently according to changing requirements of
> different projects. The example kickoff scripts should serve as a base
> for the user to change according to their own requirements and
> experience. As soon as one starts using packages for ones classes,
> something needs to be done to classpath anyway - I see no point in
> making a jar every time and copying that to a fixed destination before
> testing the change.
>
> As I mentioned, Rony did some rather nifty tricks for getting BSF4Rexx
> to work with both Object Rexx and Open Office. These have more or less
> the same JVM class library location trouble as other Java programs do.
> I am thinking along the lines of adding something like that - to write
> a bullet proof startup script for that particular users setup. This
> also is an excellent place to add environmental wisdom to, instead of
> adding this to the translator itself.
>
> Now that I think back on this easy Friday afternoon at work (everybody
> is gone), I removed a -ms4M myself only some weeks ago when installing
> on someone's windows box. I probably did not see this as significant
> enough to remember in quickly accessible storage.
>
> I am still wondering if your remark on the handling of the classpath
> environment variable on Java 6 could be correct - did you restart
> shell after changing it? This would deviate from all other
> implementations I know. Word was a few years ago that the extra flags
> were only added for platforms without a usable environment concept,
> like some phones. The extension directories were added for less
> problematic handling of other XML libraries than the internals ones -
> this was when Java added the Apache Xerces and Xalan, but old versions
> of those.
>
> Please let me know.
>
> best regards,
>
> Ren?
>
>
>
>
> On Fri, Feb 12, 2010 at 11:34 AM, Chip Davis <[hidden email]> wrote:
>> On 2/12/10 08:13 Mike Cowlishaw said:
>>>> Anyway I think it's the jvm who is ultimately at fault here.
>>> Yes, "run anywhere" should include "continue to run on the same platform 5
>>> years from now".
>> Which is another reason I'm not very happy with the necessity to move files
>> around (one of them a Java file) just to get NetRexx to work.  What are the
>> odds that this week's directory will be correct when the next release comes
>> out?
>>
>> Unless someone offers a more elegant solution than David's use of NetRexx
>> environment variables, that's the approach I will take as well.
>>
>> I don't know enough Java even to be dangerous (that's why I have NetRexx, to
>> hid the ugly :-) but I wonder if a small Java program could determine where
>> the active JDK and NetRexx installations reside and create the necessary
>> NetRexx environment variables?
>>
>> A side benefit would be that it could also create the small uninstall
>> routine for NetRexx, and place itself in the "Add or Remove Programs" list
>> (which is magic as far as I can tell).
>>
>> I don't suppose there are .bat file facilities that could do all that, are
>> there?
>>
>> It sure would be nice if NetRexx installed on Windows as easily as oh, say,
>> Regina... ;-)
>>
>>> In contrast, I've been re-viewing some of my VM/CMS programs recently.
>>>  Some
>>> were last compiled/assembled in the late 1970s -- yet still run perfectly
>>> now, dozens of operating systems updates later...
>> It does seem that the hardware guys take backwards-compatibility much more
>> seriously than the software guys... :-/
>>
>> -Chip-
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>

[Thomas.Schneider.Wien]

Hello Chip & all,

   ... based on the Input I got from David and Kermit, I'm currennlty
trying to write a JAVA-Based installer
for my 'new' product Rey (an acronym for Rexx for Java).

((the 'successor' of Rexx2Nrx))

   .... I am still testing some major new things, like my implementation
of INTERPRET, TRACE, and EXECIO etc
(for classic REXX Source only, of course, no need to re-do that for
NetRexx) ...

Just to get my feed-back to the LIST relating the installation issue(s):

In my opinion, there are there TOO many BASH Scripts, BAT scripts, CMD
scriptes etc around in the current
NetRexx installation procedure:

For instance, nrc.*  calls NetRexxC.* etc.

I can live with that, for the time beeing, but my  *thinking is*:

there should be only one ...
Thomas.
===============================================================================

 

 
Chip Davis schrieb:

> Thanks for the thoughtful response, Ren?.  I find that this discussion
> group is a good oven in which to perfect my half-baked ideas.
>
> I agree that a platform-independent runtime should not have
> platform-specific code in it.  However, given that there are (and
> always will be) OS-level platform differences, I see no way around
> such code at the installation and invocation levels.  One benefit of
> my approach is that no longer would there be a collection of
> invocation scripts for the (possibly na?ve) user to choose from, or
> inadvertently invoke.  That single script would be created by the
> installer based upon the environment it finds.
>
> It appears to me that the problem is to create an installer that is
> smart enough to figure out where it is, and capable enough to
> customize the installation and invocation routines appropriately.
>
> Fortuitously, all NetRexx installations should have Java available,
> thus my suggestion.  Yes, I was specifically using Windows as a target
> environment, but it seems to me that some sort of customization of the
> NetRexx invocation routine (and de-install process) are going to be
> necessary on every Java platform.  Once NetRexx is installed, the Java
> Runtime Environment will level the playing field for application
> programs.
>
> To my mind, having a platform-aware installation process which is run
> once does not compromise the platform-independent integrity of the
> NetRexx processor or of NetRexx applications themselves.
>
> And no, I don't know how to actually write such an installer in Java.  
> I leave that as "an exercise for the (smarter) student..." :-))
>
> As for your question about Java not finding the .jar files when they
> were stored in '\Java\jdk1.6.0_18\jre\lib\ext\' versus
> '\Java\jre6\lib\ext', note that I was specifically not modifying the
> CLASSPATH for that test.  I wanted to see if the published
> installation procedure would work, even if the user put the .jar files
> in the "wrong" lib\ext\ directory.
>
> At that point, CLASSPATH was ".;C:\Program
> Files\Java\jre6\lib\ext\QTJava.zip."  In an argument against the
> documentation referencing (the somewhat evanescent) Java file names,
> the only directory that exactly matched the read.me.first file
> ("jre/lib/ext") was the wrong one.  The files needed to be in
> "jre6/lib/ext". Unless (I assume) one also updates the CLASSPATH, in
> which case I suppose it does not matter where the .jar files reside,
> and one can (and should) not move them in the first place.
>
> -Chip-
>
> On 2/12/10 15:53 Ren? Jansen said:
>> Chip,
>>
>> I am sympathetic to the troubles you went through, but having platform
>> specific code around to support a platform independent runtime is a
>> line I'd personally rather not cross. Which does not mean the
>> soon-to-be-blossoming NetRexx community will not solve it.
>>
>> This exchange has taught me several things:
>>
>> - always try out the current situation myself before answering based
>> on own but stale experience
>> - the heated rear view mirror always breaks the car
>>
>> I am going to move the scripts to a "samples" directory. In my current
>> opinion (of today) there are a lot of JVM options relevant to the
>> execution of NetRexx programs, including the translator - garbage
>> collection, heap size, classpath, to name a few, which (in my
>> practice) are changed frequently according to changing requirements of
>> different projects. The example kickoff scripts should serve as a base
>> for the user to change according to their own requirements and
>> experience. As soon as one starts using packages for ones classes,
>> something needs to be done to classpath anyway - I see no point in
>> making a jar every time and copying that to a fixed destination before
>> testing the change.
>>
>> As I mentioned, Rony did some rather nifty tricks for getting BSF4Rexx
>> to work with both Object Rexx and Open Office. These have more or less
>> the same JVM class library location trouble as other Java programs do.
>> I am thinking along the lines of adding something like that - to write
>> a bullet proof startup script for that particular users setup. This
>> also is an excellent place to add environmental wisdom to, instead of
>> adding this to the translator itself.
>>
>> Now that I think back on this easy Friday afternoon at work (everybody
>> is gone), I removed a -ms4M myself only some weeks ago when installing
>> on someone's windows box. I probably did not see this as significant
>> enough to remember in quickly accessible storage.
>>
>> I am still wondering if your remark on the handling of the classpath
>> environment variable on Java 6 could be correct - did you restart
>> shell after changing it? This would deviate from all other
>> implementations I know. Word was a few years ago that the extra flags
>> were only added for platforms without a usable environment concept,
>> like some phones. The extension directories were added for less
>> problematic handling of other XML libraries than the internals ones -
>> this was when Java added the Apache Xerces and Xalan, but old versions
>> of those.
>>
>> Please let me know.
>>
>> best regards,
>>
>> Ren?
>>
>>
>>
>>
>> On Fri, Feb 12, 2010 at 11:34 AM, Chip Davis <[hidden email]> wrote:
>>> On 2/12/10 08:13 Mike Cowlishaw said:
>>>>> Anyway I think it's the jvm who is ultimately at fault here.
>>>> Yes, "run anywhere" should include "continue to run on the same
>>>> platform 5
>>>> years from now".
>>> Which is another reason I'm not very happy with the necessity to
>>> move files
>>> around (one of them a Java file) just to get NetRexx to work.  What
>>> are the
>>> odds that this week's directory will be correct when the next
>>> release comes
>>> out?
>>>
>>> Unless someone offers a more elegant solution than David's use of
>>> NetRexx
>>> environment variables, that's the approach I will take as well.
>>>
>>> I don't know enough Java even to be dangerous (that's why I have
>>> NetRexx, to
>>> hid the ugly :-) but I wonder if a small Java program could
>>> determine where
>>> the active JDK and NetRexx installations reside and create the
>>> necessary
>>> NetRexx environment variables?
>>>
>>> A side benefit would be that it could also create the small uninstall
>>> routine for NetRexx, and place itself in the "Add or Remove
>>> Programs" list
>>> (which is magic as far as I can tell).
>>>
>>> I don't suppose there are .bat file facilities that could do all
>>> that, are
>>> there?
>>>
>>> It sure would be nice if NetRexx installed on Windows as easily as
>>> oh, say,
>>> Regina... ;-)
>>>
>>>> In contrast, I've been re-viewing some of my VM/CMS programs recently.
>>>>  Some
>>>> were last compiled/assembled in the late 1970s -- yet still run
>>>> perfectly
>>>> now, dozens of operating systems updates later...
>>> It does seem that the hardware guys take backwards-compatibility
>>> much more
>>> seriously than the software guys... :-/
>>>
>>> -Chip-
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>>
>>>
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>>
>>
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>