Re: [RexxLA] Ok guys. . .

[Thomas.Schneider.Wien]

An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100208/4d381f49/attachment.html

[Mike Cowlishaw-2]

> And, just a question, *who* is maintaining NetRexx nowadays (as Mike
> F. Cowlishaw is obvioulsy
> REDIGNING from IBM (read in other messages))) .... [sic]

Tom, please do not spread false rumours.  I am not resigning from IBM.  I
am taking early retirement.

As to your question; no one has 'maintained' NetRexx in IBM for ten years
or thereabouts.  It's absurd to demand that the IBM NetRexx web pages be
updated when NetRexx is in the process of being moved to the RexxLA.

Mike






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





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

[Thomas.Schneider.Wien]

An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100208/46dfc62c/attachment.html

[Thomas.Schneider.Wien]

Hi Kermit,

   thanks a lot for the -classpath hint. I have been NOT aware of this,
and will read up the doc's
to use this .... :-)

Tom.
==================================================================
Kermit Kiser schrieb:

> Bruce ;
>
> Did you read my note? I am pretty sure that if you use the correct
> classpath with a period added for the current directory as I mentioned
> in item #3 that you will not need to "unset" the classpath to execute
> your program.
>
> BTW: The CLASSPATH environment variable has been "deprecated" since
> Java 1.3 and is not recommended for various reasons. The correct way
> to call Java is now with a "-classpath" operand which specifies the
> path on the command line. That would give you a much simpler way to
> specify the classpath differently in the stages in your shell script.
>
> -- Kermit
>
>
> Bruce Skelly wrote:
>> I don't know, we may be saying the same thing.
>>
>> I do know that even though both classes.jar and NetRexxC.jar are in
>> the default (implicit) CLASSPATH, that NetRexxC would fail trying to
>> create the '.java' file.  That is before the java compiler is
>> invoked.  In fact, using the -verbose argument to java, showed me
>> that many classes were loaded from both .jar files.
>>
>> If I gave it a CLASSPATH that contained just classes.jar, then it
>> would fail, looking for a NetRexx class.  If I gave it a CLASSPATH
>> that contained just NetRexxC.jar, it would fail looking for a java
>> class.  Specifying both classes.jar and NetRexxC.jar would produce a
>> .java file that could then be compiled into a .class file.
>>
>> At that point if I tried to execute the program, i.e. java
>> hello.class, it would fail.  If I then *unset* the CLASSPATH, I could
>> then type java hello.class and it would execute.
>>
>> I modified the distributed NetRexxC.sh file to do this on Darwin
>> systems  (Mac OS X), since it appears on my system, CLASSPATH is only
>> needed in the translation phase from .nrx to .java.
>> ...
>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/Extensions
>> if [ "`uname`" = "Darwin" ]
>> then
>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/Library/Frameworks/JavaVM.framework/Classes/classes.jar
>> export CLASSPATH
>> fi
>> ...
>> # Again for Mac OS X;
>> if [ "`uname`" = "Darwin" ]
>> then
>>      unset CLASSPATH
>> fi
>> ...
>>
>> Bruce
>>
>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote:
>>
>>> Hi Bruce;
>>>
>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
>>>
>>> 2) There are three stages to compiling and running a NetRexx program
>>> - first the NetRexx translator (NetRexxC) parses your code and
>>> converts it to Java code, second the translator calls the Java
>>> compiler (javac) to convert the Java code to "bytecode", third the
>>> Java virtual machine loads the bytecode, links it and executes it.
>>> At each stage a different program is handling your code and each one
>>> has to be able to find all the related classes. Sometimes they don't
>>> use the same procedure/path to find things but generally they will
>>> all obey the CLASSPATH environment variable. Each program has an
>>> internal default classpath but the environment variable will
>>> *override* the internal paths.
>>>
>>> 3) Solution: When you specify the CLASSPATH, you must include the
>>> code directory, usually with a "." (a period) or your program will
>>> not be found. Likewise you must include the Java classes and the
>>> NetRexx classes because you are overriding the default paths.
>>>
>>> 4) You can add NetRexxC.jar to the Java extensions directory so Java
>>> can find it in it's default path search but that may not help
>>> NetRexxC to find the classes it needs.
>>>
>>> 5) You may find that it is simpler to install the jEdit IDE with
>>> NetRexxDE and NetRexxScript plugins to compile and interpret NetRexx
>>> code, since the NetRexxC.jar file is automatically installed that
>>> way. (You will still need to download the NetRexx zip if you want
>>> the samples and docs.) If you wish to use the jEdit environment with
>>> the NetRexxScript plugin, be aware that jEdit uses custom
>>> classloaders to dynamically load things. Therefore if NetRexxC.jar
>>> is in the extensions directory for the Java VM that runs jEdit,
>>> NetRexxScript will encounter "invocation" errors when interpreting
>>> scripts due to the conflict between multiple classloader versions of
>>> the NetRexx classes.
>>>
>>> Hope some of this info helps,
>>>
>>> -- Kermit
>>>
>>>
>>> Bruce Skelly wrote:
>>>> If I understand this correctly, after spending some time playing
>>>> with it, it isn't really that NetRexx doesn't execute unless you
>>>> specify the CLASSPATH.  What I *think* is happening is that the
>>>> NetRexx Compiler, in the course of generating java code needs to
>>>> look at the classes to determine their dependancies.  Kind of like
>>>> header files in C.  After the compile is complete, the "headers"
>>>> are no longer needed, and the compiled NetRexx (java) program runs
>>>> just fine without the CLASSPATH.  
>>>>
>>>> Please note in my messages, that NetRexxC was executing, but
>>>> issuing error messages stating that it couldn't find things
>>>> (classes).  Also, my compiled NetRexx program executes just fine
>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
>>>> and the Java runtime.
>>>>
>>>> Bruce
>>>> On Feb 8, 2010, at 8:53 AM, Alan Sampson wrote:
>>>>
>>>>>
>>>>> Before you start you should look at this overview:
>>>>> http://java.sun.com/j2se/1.5.0/docs/guide/extensions/extensions.html.
>>>>>  It explains how Java handles any optional packages (NetRexx is a
>>>>> Java optional package) without modifying the CLASSPATH environment
>>>>> variable.
>>>>>
>>>>> The basic principal is simple; drop your extension jarfiles in the
>>>>> appropriate directory.  I've been doing this for years with
>>>>> NetRexx (and other tools too) and I run multiple versions of Java
>>>>> on my systems.
>>>>>
>>>>> The extensions directory is typically $JDK_HOME/jre/lib/ext where
>>>>> JDK_HOME is the location in which your JDK is installed.
>>>>>
>>>>> The nice thing about using the extensions directory is when I
>>>>> install a new JDK all I need do is synch. the ext directories and
>>>>> all my Java programs work as I expect.
>>>>>
>>>>> BTW  I long ago gave up on installing just a JRE; as Mike alluded
>>>>> to in a previous message, I'm a developer, I need developer tools.
>>>>>  The Java Run Time is for my customers. :-)
>>>>>
>>>>> Alan.
>>>>>
>>>>> _______________________________________________
>>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>  
>>>
>>> _______________________________________________
>>> rexxla-members mailing list -- mailto:[hidden email]
>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rexxla-members mailing list -- mailto:[hidden email]
>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rexxla-members mailing list -- mailto:[hidden email]
> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>  

[Fernando Cassia-2]

On Mon, Feb 8, 2010 at 4:24 PM, Mike Cowlishaw <[hidden email]> wrote:

> > And, just a question, *who* is maintaining NetRexx nowadays (as Mike
> > F. Cowlishaw is obvioulsy
> > REDIGNING from IBM (read in other messages))) .... [sic]
>
> Tom, please do not spread false rumours.  I am not resigning from IBM.  I
> am taking early retirement.
>
> As to your question; no one has 'maintained' NetRexx in IBM for ten years
> or thereabouts.  It's absurd to demand that the IBM NetRexx web pages be
> updated when NetRexx is in the process of being moved to the RexxLA.
>
> Mike

Hi Mike,

Good to hear from you. What I found "absurd" is the time used for these
discussions, when the same time could be applied to update the mentioned web
page. If NetRexx is in the process of being moved to the RexxLA, the
official IBM Netrexx page should say something about it, if it doesn?t
already (I didn?t check).

IBM?s web pages as a whole are notorious for having out of date
information.... phantom projects from days gone by... without any reference
about the current status.

It?s almost as if an Inmense Bureaucratic Machine (pun intended) prevents
easy update of web pages...

FC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100208/ac572d50/attachment.html

[Jeff Hennick]

An HTML attachment was scrubbed...
URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100208/3cec4661/attachment.html

[Thomas.Schneider.Wien]

Hello Fernando,
   Rene Vincent Jansen is doing a great JOB there in the Netherlands to
put out
NetRexx as open source.....

   On the same time, I *do agree*, it does *now take*  too much time
already.

I therefore did decide to put my stuff (Rexx for Java) OPEN SOURCE out
immediately.

When you like to get the Details, pls. Join GOOGLE GROUP Rexx2Nrx.

Sincerely,
Tom.

www.db-123.com
www.Rexx2Nrx.com
==========================================================
Fernando Cassia schrieb:

>
>
> On Mon, Feb 8, 2010 at 4:24 PM, Mike Cowlishaw <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > And, just a question, *who* is maintaining NetRexx nowadays (as Mike
>     > F. Cowlishaw is obvioulsy
>     > REDIGNING from IBM (read in other messages))) .... [sic]
>
>     Tom, please do not spread false rumours.  I am not resigning from
>     IBM.  I am taking early retirement.
>
>     As to your question; no one has 'maintained' NetRexx in IBM for
>     ten years or thereabouts.  It's absurd to demand that the IBM
>     NetRexx web pages be updated when NetRexx is in the process of
>     being moved to the RexxLA.
>
>     Mike
>
>
> Hi Mike,
>
> Good to hear from you. What I found "absurd" is the time used for
> these discussions, when the same time could be applied to update the
> mentioned web page. If NetRexx is in the process of being moved to the
> RexxLA, the official IBM Netrexx page should say something about it,
> if it doesn?t already (I didn?t check).
>
> IBM?s web pages as a whole are notorious for having out of date
> information.... phantom projects from days gone by... without any
> reference about the current status.
>
> It?s almost as if an Inmense Bureaucratic Machine (pun intended)
> prevents easy update of web pages...
>
> FC
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>  

[Thomas.Schneider.Wien]

Hi Kermit,
   I *do totally* agree with *your points*, mentioned below.

The only concern I do have:

   When the *OPEN Source Code* of NetRexx becomes not released (very soon),
We all do have to replicate Mike F.Cowlishaws work by our own....

... and that *is a pity*


I'm now thru with my development work, but still busy updating all the
documentation,
namely on www.Rexx2Nrx.com, which is a *hell of work* (still under
progress).

Tom.
=========================================================
 Kermit Kiser schrieb:

> Thomas ;
>
> The stuff I wrote is not worth publishing except perhaps as an
> introduction. It is oversimplified and omits a lot of details for
> clarity. A real document would need to provide the details somewhere.
> Some of those details are not yet available. Until we have seen the
> actual NetRexx compiler code, it is hard to say exactly how NetRexxC
> locates the classes that it uses to error check NetRexx code. Likewise
> I have no idea how MAC Java locates stuff except that it is clearly
> different than Windows or even Linux. An OS/X Java expert would have
> to provide those details.
>
> Here is an example of one of the missing details:
>
> If a Java program is correctly bundled into a "jar" file, it can be
> executed directly from the jar file via a java command with the "-jar"
> operand. What is not obvious is that a Java VM started with the "-jar"
> operand will silently ignore ALL CLASSPATH variables and "-classpath"
> operands. For example, the standard jEdit installation creates a
> startup launcher with "-jar" and therefore any classpath you have set
> does not affect programs running under jEdit. This is why the
> NetRexxDE and NetRexxScript plugins both provide a classpath option
> internally.
>
> -- Kermit
>
>
> Thomas Schneider wrote:
>> Can SOMEONE of you (Chip Davis) Please put that info in the
>> NetRexx.ZIP file, *please* ??
>>
>> And, just a question, *who* is maintaining NetRexx nowadays (as Mike
>> F. Cowlishaw is obvioulsy
>> REDIGNING from IBM (read in other messages))) ....
>>
>> It *is* of *utmost importance*, as I'm feeling, that this information
>> of KERMIT does *not get* *LOST*,
>> but makes it's way directly straightforwad to the IBM NetRexx
>> home-pages...
>>
>>
>> Hence, who will DO this Job ?
>> Tom.
>> =============================================================================
>>
>> Kermit Kiser schrieb:
>>> Hi Bruce;
>>>
>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
>>>
>>> 2) There are three stages to compiling and running a NetRexx program
>>> - first the NetRexx translator (NetRexxC) parses your code and
>>> converts it to Java code, second the translator calls the Java
>>> compiler (javac) to convert the Java code to "bytecode", third the
>>> Java virtual machine loads the bytecode, links it and executes it.
>>> At each stage a different program is handling your code and each one
>>> has to be able to find all the related classes. Sometimes they don't
>>> use the same procedure/path to find things but generally they will
>>> all obey the CLASSPATH environment variable. Each program has an
>>> internal default classpath but the environment variable will
>>> *override* the internal paths.
>>>
>>> 3) Solution: When you specify the CLASSPATH, you must include the
>>> code directory, usually with a "." (a period) or your program will
>>> not be found. Likewise you must include the Java classes and the
>>> NetRexx classes because you are overriding the default paths.
>>>
>>> 4) You can add NetRexxC.jar to the Java extensions directory so Java
>>> can find it in it's default path search but that may not help
>>> NetRexxC to find the classes it needs.
>>>
>>> 5) You may find that it is simpler to install the jEdit IDE with
>>> NetRexxDE and NetRexxScript plugins to compile and interpret NetRexx
>>> code, since the NetRexxC.jar file is automatically installed that
>>> way. (You will still need to download the NetRexx zip if you want
>>> the samples and docs.) If you wish to use the jEdit environment with
>>> the NetRexxScript plugin, be aware that jEdit uses custom
>>> classloaders to dynamically load things. Therefore if NetRexxC.jar
>>> is in the extensions directory for the Java VM that runs jEdit,
>>> NetRexxScript will encounter "invocation" errors when interpreting
>>> scripts due to the conflict between multiple classloader versions of
>>> the NetRexx classes.
>>>
>>> Hope some of this info helps,
>>>
>>> -- Kermit
>>>
>>>
>>> Bruce Skelly wrote:
>>>> If I understand this correctly, after spending some time playing
>>>> with it, it isn't really that NetRexx doesn't execute unless you
>>>> specify the CLASSPATH.  What I *think* is happening is that the
>>>> NetRexx Compiler, in the course of generating java code needs to
>>>> look at the classes to determine their dependancies.  Kind of like
>>>> header files in C.  After the compile is complete, the "headers"
>>>> are no longer needed, and the compiled NetRexx (java) program runs
>>>> just fine without the CLASSPATH.  
>>>>
>>>> Please note in my messages, that NetRexxC was executing, but
>>>> issuing error messages stating that it couldn't find things
>>>> (classes).  Also, my compiled NetRexx program executes just fine
>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
>>>> and the Java runtime.
>>>>
>>>> Bruce
>>>> On Feb 8, 2010, at 8:53 AM, Alan Sampson wrote:
>>>>
>>>>>
>>>>> Before you start you should look at this overview:
>>>>> http://java.sun.com/j2se/1.5.0/docs/guide/extensions/extensions.html.
>>>>>  It explains how Java handles any optional packages (NetRexx is a
>>>>> Java optional package) without modifying the CLASSPATH environment
>>>>> variable.
>>>>>
>>>>> The basic principal is simple; drop your extension jarfiles in the
>>>>> appropriate directory.  I've been doing this for years with
>>>>> NetRexx (and other tools too) and I run multiple versions of Java
>>>>> on my systems.
>>>>>
>>>>> The extensions directory is typically $JDK_HOME/jre/lib/ext where
>>>>> JDK_HOME is the location in which your JDK is installed.
>>>>>
>>>>> The nice thing about using the extensions directory is when I
>>>>> install a new JDK all I need do is synch. the ext directories and
>>>>> all my Java programs work as I expect.
>>>>>
>>>>> BTW  I long ago gave up on installing just a JRE; as Mike alluded
>>>>> to in a previous message, I'm a developer, I need developer tools.
>>>>>  The Java Run Time is for my customers. :-)
>>>>>
>>>>> Alan.
>>>>>
>>>>> _______________________________________________
>>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>  
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rexxla-members mailing list -- mailto:[hidden email]
>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rexxla-members mailing list -- mailto:[hidden email]
>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rexxla-members mailing list -- mailto:[hidden email]
> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>  

[Thomas.Schneider.Wien]

Hi Kermit, again,

after reading your message the third time:

Could you please explain the -jar option in Detail ?

With the new (version 7.00)  release of Rexx2Nrx I do have one major  
Jar File:

ReyC.jar     -- the Rey-Compiler.
ReyR.jar     -- the Rey  Runtime (included in ReyC.jar, anyway)

What syntax do I have to use, when I ant to invoke the major module PP
(The Program Porting Machine)
from an ordinary DOS batch file.

PP has some actions (as parameters):

PP TRANSFORM *.rex TO NetRexx
PP COMPILE *.rex   (for instance)

Any Advise will be appreciated
Thomas.


 


Thomas Schneider schrieb:

> Hi Kermit,
>   I *do totally* agree with *your points*, mentioned below.
>
> The only concern I do have:
>
>   When the *OPEN Source Code* of NetRexx becomes not released (very
> soon),
> We all do have to replicate Mike F.Cowlishaws work by our own....
>
> ... and that *is a pity*
>
>
> I'm now thru with my development work, but still busy updating all the
> documentation,
> namely on www.Rexx2Nrx.com, which is a *hell of work* (still under
> progress).
>
> Tom.
> =========================================================
> Kermit Kiser schrieb:
>> Thomas ;
>>
>> The stuff I wrote is not worth publishing except perhaps as an
>> introduction. It is oversimplified and omits a lot of details for
>> clarity. A real document would need to provide the details somewhere.
>> Some of those details are not yet available. Until we have seen the
>> actual NetRexx compiler code, it is hard to say exactly how NetRexxC
>> locates the classes that it uses to error check NetRexx code.
>> Likewise I have no idea how MAC Java locates stuff except that it is
>> clearly different than Windows or even Linux. An OS/X Java expert
>> would have to provide those details.
>>
>> Here is an example of one of the missing details:
>>
>> If a Java program is correctly bundled into a "jar" file, it can be
>> executed directly from the jar file via a java command with the
>> "-jar" operand. What is not obvious is that a Java VM started with
>> the "-jar" operand will silently ignore ALL CLASSPATH variables and
>> "-classpath" operands. For example, the standard jEdit installation
>> creates a startup launcher with "-jar" and therefore any classpath
>> you have set does not affect programs running under jEdit. This is
>> why the NetRexxDE and NetRexxScript plugins both provide a classpath
>> option internally.
>>
>> -- Kermit
>>
>>
>> Thomas Schneider wrote:
>>> Can SOMEONE of you (Chip Davis) Please put that info in the
>>> NetRexx.ZIP file, *please* ??
>>>
>>> And, just a question, *who* is maintaining NetRexx nowadays (as Mike
>>> F. Cowlishaw is obvioulsy
>>> REDIGNING from IBM (read in other messages))) ....
>>>
>>> It *is* of *utmost importance*, as I'm feeling, that this
>>> information of KERMIT does *not get* *LOST*,
>>> but makes it's way directly straightforwad to the IBM NetRexx
>>> home-pages...
>>>
>>>
>>> Hence, who will DO this Job ?
>>> Tom.
>>> =============================================================================
>>>
>>> Kermit Kiser schrieb:
>>>> Hi Bruce;
>>>>
>>>> 1) I don't know much about Mac stuff. (OK, zero ;-)
>>>>
>>>> 2) There are three stages to compiling and running a NetRexx
>>>> program - first the NetRexx translator (NetRexxC) parses your code
>>>> and converts it to Java code, second the translator calls the Java
>>>> compiler (javac) to convert the Java code to "bytecode", third the
>>>> Java virtual machine loads the bytecode, links it and executes it.
>>>> At each stage a different program is handling your code and each
>>>> one has to be able to find all the related classes. Sometimes they
>>>> don't use the same procedure/path to find things but generally they
>>>> will all obey the CLASSPATH environment variable. Each program has
>>>> an internal default classpath but the environment variable will
>>>> *override* the internal paths.
>>>>
>>>> 3) Solution: When you specify the CLASSPATH, you must include the
>>>> code directory, usually with a "." (a period) or your program will
>>>> not be found. Likewise you must include the Java classes and the
>>>> NetRexx classes because you are overriding the default paths.
>>>>
>>>> 4) You can add NetRexxC.jar to the Java extensions directory so
>>>> Java can find it in it's default path search but that may not help
>>>> NetRexxC to find the classes it needs.
>>>>
>>>> 5) You may find that it is simpler to install the jEdit IDE with
>>>> NetRexxDE and NetRexxScript plugins to compile and interpret
>>>> NetRexx code, since the NetRexxC.jar file is automatically
>>>> installed that way. (You will still need to download the NetRexx
>>>> zip if you want the samples and docs.) If you wish to use the jEdit
>>>> environment with the NetRexxScript plugin, be aware that jEdit uses
>>>> custom classloaders to dynamically load things. Therefore if
>>>> NetRexxC.jar is in the extensions directory for the Java VM that
>>>> runs jEdit, NetRexxScript will encounter "invocation" errors when
>>>> interpreting scripts due to the conflict between multiple
>>>> classloader versions of the NetRexx classes.
>>>>
>>>> Hope some of this info helps,
>>>>
>>>> -- Kermit
>>>>
>>>>
>>>> Bruce Skelly wrote:
>>>>> If I understand this correctly, after spending some time playing
>>>>> with it, it isn't really that NetRexx doesn't execute unless you
>>>>> specify the CLASSPATH.  What I *think* is happening is that the
>>>>> NetRexx Compiler, in the course of generating java code needs to
>>>>> look at the classes to determine their dependancies.  Kind of like
>>>>> header files in C.  After the compile is complete, the "headers"
>>>>> are no longer needed, and the compiled NetRexx (java) program runs
>>>>> just fine without the CLASSPATH.
>>>>> Please note in my messages, that NetRexxC was executing, but
>>>>> issuing error messages stating that it couldn't find things
>>>>> (classes).  Also, my compiled NetRexx program executes just fine
>>>>> when I unset CLASSPATH, so it can find both the NetRexx runtime,
>>>>> and the Java runtime.
>>>>>
>>>>> Bruce
>>>>> On Feb 8, 2010, at 8:53 AM, Alan Sampson wrote:
>>>>>
>>>>>>
>>>>>> Before you start you should look at this overview:
>>>>>> http://java.sun.com/j2se/1.5.0/docs/guide/extensions/extensions.html.
>>>>>>  It explains how Java handles any optional packages (NetRexx is a
>>>>>> Java optional package) without modifying the CLASSPATH
>>>>>> environment variable.
>>>>>>
>>>>>> The basic principal is simple; drop your extension jarfiles in
>>>>>> the appropriate directory.  I've been doing this for years with
>>>>>> NetRexx (and other tools too) and I run multiple versions of Java
>>>>>> on my systems.
>>>>>>
>>>>>> The extensions directory is typically $JDK_HOME/jre/lib/ext where
>>>>>> JDK_HOME is the location in which your JDK is installed.
>>>>>>
>>>>>> The nice thing about using the extensions directory is when I
>>>>>> install a new JDK all I need do is synch. the ext directories and
>>>>>> all my Java programs work as I expect.
>>>>>>
>>>>>> BTW  I long ago gave up on installing just a JRE; as Mike alluded
>>>>>> to in a previous message, I'm a developer, I need developer
>>>>>> tools.  The Java Run Time is for my customers. :-)
>>>>>>
>>>>>> Alan.
>>>>>>
>>>>>> _______________________________________________
>>>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>>  
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> rexxla-members mailing list -- mailto:[hidden email]
>>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>>  
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> rexxla-members mailing list -- mailto:[hidden email]
>>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>>  
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rexxla-members mailing list -- mailto:[hidden email]
>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members
>>  
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>
>