License Question?

[ThSITC]

Hi Rene, and *all*,

would it be possible for those knowing the details to:

a) DESIGN a simple CSV-File describing the dependencies (in a *parent* column, for instance, as in Hierachical Databases)
c) After Design, to Fill out those Files for any & all Machines where NetRexx shall be installed ?

I'm using this approch in my own (still not yet completed) Installer....

You might also name the *parent* column  as a *requires* column (to follow ooRexx Terms).

After the *requires* (or *parent*) column shall be the complete URL where this software piece shall and should be
*downloaded from* :-)

I'm, for my case, *NOT* using any Database for this, but a simple EXCEL Spreadsheet then stored as a
CSV file (with the semicolon (';')) as the column separarator.

When loading this file into Memory, my Installer does build a GRAPH of dependencies!

(As You all do know, meanwhile, I'm a FAN of GRAPH Theory since my Student times ...)

(( I did write my Diploma Theasis on this, still on my desk, for planning UNIVERSITY *TIME- and ROOM Planning*,
based on the so called MINIMAL-GRAD-FOLGE as an Algorithm to COLOUR a double sided, double weighted Graph)

The max. Colour number is the so called TURAN NUMBER (has been, at least, 40 years, or so, ago)

The Whole intent of those kinds of GRAPH Theory problems is to find an approximation to the so called

Chromatic Number   (denoted as the greek letter CHI  (oh, whoops, I did also learn OLD GREEK and LATIN in SCHOOL))

The summary of this (very ancient, sorry, and very un-NetRexx related story was:

1.) I wrote my DIPLOMA THESIS (on my desk)
2.) I wrote all the algorithms (in Fortran IV, back in those times)
3.) I went to the ASSISTANT Professor and said:

OK, Dr. Gerd Baron, I shall now SORT the Inscriptions of all Student of this TU (Technical University Vienna, Austria)

*and*

Got the reply:

Only Professors and Assistants are allowed to sort on our IBM 7090 (TAPE SORT ONLY) ...
... STUDENTS NOT!

My reply:

Thanks, ok, and deposited my master thesis and never came back ...

... as I already have been working at IBM (in RPG, later PL/I), and customers of IBM,
and the Honeywell Bull, the Bull-General Electric, Then General Electric Information Services (GEISCO),
on the so called Mark III Service (first in Basic (which GE did invent, my dears!), then Fortran IV,
and a *lot of* so called FOURTH GENERATION Languages, as TABOL, DMS, Mitrol's MIMS, etc etc etc)

Anyway, not having my diploma (Dipl.Ing. in Austria) didn't harm my career ...

... nevertheless, I did now beome a Student again, making my Doctor Thesis on:

Applied Graph Theory Applications (as Natural Language Translation, etc).

Thus, my personal summary is:

Forgive me, *totally ***NOT*** Rexx, nor NetRexx related*

But:

It's never bad to LEARN the WHOLE LIVE (*NEW THINGS, of COURSE*)

Time will come to re-use the accumulated *knowledge* any way.

Full Stop.

Massa Thomas ;-)

PS: Maiking progress with my NetRexx related contributions, but still a hell of a work
to revise the ancient www.Rexx2Nrx.comn doc's, as *I FOOL* did adjust any & all
method names to Java Standards...

FOOL ON THE HILL !!!

(I do really hope some of you do still know this very old song!)

CRAZY UNCLE TOM (as somebody did already *rename me*, here, I think!)

Have a nice day, anyway,
*and*:

Sorry for any disruption (not (or yes???) intended!) ;-)
======================================================================================. .
Am 13.09.2012 00:35, schrieb René Jansen:

I see machines with several releases of several brands of JVM on it every day - there is just no telling what you will meet. The location of the Java files is completely orthogonal to that of the NetRexx jar. The process context determines what is used. There can be no assumptions on this - not even that Oracle keeps locations stable. My windows VM's have IBM, Oracle and OpenJDK on it. And some research VM's. I would like to follow Kermit's suggestion of just a \NetRexx in the root of some disk - that space in 'Program Files' has cost the world economy a lot of money.

René.

On 13 sep. 2012, at 00:05, Bill Fenlason <[hidden email]> wrote:

I don't have any problem with that - if it is a standard approach across all of the various distros, then it should be followed. 

My point is that the installation in each operating system should be such that it provides no surprises.  Where are the Java installed files?

On 9/12/2012 5:56 PM, Jason Martin wrote:

And /usr/share/java has nothing to do with the java install.

On Wed, Sep 12, 2012 at 5:45 PM, Jason Martin <[hidden email]> wrote:

On most linux distro's jars go in /usr/share/java/  ; program gets executed with a script in a bin/ directory ;  the script contains java -jar yourjarname

On Wed, Sep 12, 2012 at 5:36 PM, Bill Fenlason <[hidden email]> wrote:

Rene,

I think that moving things into the Java directories should be discouraged totally or endorsed totally.  In other words, either do it or don't do it.

Overall, it just seems to me that currently, all three of the bullet points under "Installing the NetRexx translator" suggest or imply (even by mentioning the deprecation) that it is OK to move things into the Java directories. 

I think that is a bad idea.  My recommendation is to eliminate any suggestion of tinkering with the Java directories, and to provide specific alternative instructions.

From a practical standpoint for a reasonably knowledgeable user (or developer), moving everything into the Java directories is actually an effective, simple solution, and I can understand why that was the original suggestion years ago.  I can also see merit in the argument that NetRexxR should be included in the Java ext directory so that all java has access to it.

But the bottom line at this point is that we should specifically tell the users that the Java directories belong to Java, and that in no circumstances should any NetRexx files be moved there. 

That is a good way to prevent problems with Java updates, and besides, would we want users moving things into any NetRexx directories we might create?

I would assume that when the installation process is finalized, nothing will be moved into the Java directories either.  (With the possible exception of the NetRexxR runtime if specifically requested by the user).

Bill

PS In a standard windows installation, C:\Program Files\Java\ contains the Java files such as the JRE and JDK.  In general, each application has a directory in \Program Files\.  I think it would be appropriate to have the NetRexx files end up in C:\Program Files\NetRexx\ as a default.  Other operating systems have their own conventions, and I believe that they should be followed as well.  For windows systems, to do otherwise will certainly cause lots of grief.  B.

On 9/12/2012 4:37 PM, René Jansen wrote:

Bill,

The scripts to the /bin directory in the Java installation tree must not be confused with the jars to the extensions directory, which may or may not (on some JVM's, depending on the value of an environment variable) be in the Java installation tree. This is fine, as long as it is writeable for the user, in order to not have compilations fail with an authorization error on some platforms, when choosing this directory to compile the example, or other code. This has happened recently to someone and the Quick Start Guide contains a caveat to this effect. I am not sure if this made the release or not; it will be in the next version if not. We deprecate the use of the extension library. The ' perhaps the bin directory [...]' is not my sentence, it is probably in there since the previous century,  but I can hardly find fault with it - if we observe the caveat. As it is limited to the script files it should be ok and removes the need to change the path - some people would be happy to hear that.

Do you suggest we also deprecate installation of the NetRexx compile scripts to the Java install tree? There are no technical reasons for this (things do not mysteriously fail), there is only overlap with one of the arguments for not using the extension directory (losing files if changing Java install tree locations), or should we take this out and only recommend installing the script files outside of the Java install tree - (on systems that have directory trees)? 

best regards,

René.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2437/5264 - Release Date: 09/12/12

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jason Martin]

On Ubuntu/debian its /usr/lib/jvm/onejavaver and /usr/lib/jvm/twojavaver and some on and some on. You could have thousands if you wanted.
Just change main environment variables or symlinks to the one you want or each user can set own or call the one you want with scripts or call each manually.

On Wed, Sep 12, 2012 at 6:05 PM, Bill Fenlason <[hidden email]> wrote:

I don't have any problem with that - if it is a standard approach across all of the various distros, then it should be followed. 

My point is that the installation in each operating system should be such that it provides no surprises.  Where are the Java installed files?

On 9/12/2012 5:56 PM, Jason Martin wrote:

And /usr/share/java has nothing to do with the java install.

On Wed, Sep 12, 2012 at 5:45 PM, Jason Martin <[hidden email]> wrote:

On most linux distro's jars go in /usr/share/java/  ; program gets executed with a script in a bin/ directory ;  the script contains java -jar yourjarname

On Wed, Sep 12, 2012 at 5:36 PM, Bill Fenlason <[hidden email]> wrote:

Rene,

I think that moving things into the Java directories should be discouraged totally or endorsed totally.  In other words, either do it or don't do it.

Overall, it just seems to me that currently, all three of the bullet points under "Installing the NetRexx translator" suggest or imply (even by mentioning the deprecation) that it is OK to move things into the Java directories. 

I think that is a bad idea.  My recommendation is to eliminate any suggestion of tinkering with the Java directories, and to provide specific alternative instructions.

From a practical standpoint for a reasonably knowledgeable user (or developer), moving everything into the Java directories is actually an effective, simple solution, and I can understand why that was the original suggestion years ago.  I can also see merit in the argument that NetRexxR should be included in the Java ext directory so that all java has access to it.

But the bottom line at this point is that we should specifically tell the users that the Java directories belong to Java, and that in no circumstances should any NetRexx files be moved there. 

That is a good way to prevent problems with Java updates, and besides, would we want users moving things into any NetRexx directories we might create?

I would assume that when the installation process is finalized, nothing will be moved into the Java directories either.  (With the possible exception of the NetRexxR runtime if specifically requested by the user).

Bill

PS In a standard windows installation, C:\Program Files\Java\ contains the Java files such as the JRE and JDK.  In general, each application has a directory in \Program Files\.  I think it would be appropriate to have the NetRexx files end up in C:\Program Files\NetRexx\ as a default.  Other operating systems have their own conventions, and I believe that they should be followed as well.  For windows systems, to do otherwise will certainly cause lots of grief.  B.

On 9/12/2012 4:37 PM, René Jansen wrote:

Bill,

The scripts to the /bin directory in the Java installation tree must not be confused with the jars to the extensions directory, which may or may not (on some JVM's, depending on the value of an environment variable) be in the Java installation tree. This is fine, as long as it is writeable for the user, in order to not have compilations fail with an authorization error on some platforms, when choosing this directory to compile the example, or other code. This has happened recently to someone and the Quick Start Guide contains a caveat to this effect. I am not sure if this made the release or not; it will be in the next version if not. We deprecate the use of the extension library. The ' perhaps the bin directory [...]' is not my sentence, it is probably in there since the previous century,  but I can hardly find fault with it - if we observe the caveat. As it is limited to the script files it should be ok and removes the need to change the path - some people would be happy to hear that.

Do you suggest we also deprecate installation of the NetRexx compile scripts to the Java install tree? There are no technical reasons for this (things do not mysteriously fail), there is only overlap with one of the arguments for not using the extension directory (losing files if changing Java install tree locations), or should we take this out and only recommend installing the script files outside of the Java install tree - (on systems that have directory trees)? 

best regards,

René.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2437/5264 - Release Date: 09/12/12

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jason Martin]

But this is really true of any OS. It is about learning what you have, what you need and what you can do. It is all up to each individual.

PS:
and I know I did not reply to the main thread the last few times.

On Wed, Sep 12, 2012 at 7:51 PM, Jason Martin <[hidden email]> wrote:

On Ubuntu/debian its /usr/lib/jvm/onejavaver and /usr/lib/jvm/twojavaver and some on and some on. You could have thousands if you wanted.
Just change main environment variables or symlinks to the one you want or each user can set own or call the one you want with scripts or call each manually.

On Wed, Sep 12, 2012 at 6:05 PM, Bill Fenlason <[hidden email]> wrote:

I don't have any problem with that - if it is a standard approach across all of the various distros, then it should be followed. 

My point is that the installation in each operating system should be such that it provides no surprises.  Where are the Java installed files?

On 9/12/2012 5:56 PM, Jason Martin wrote:

And /usr/share/java has nothing to do with the java install.

On Wed, Sep 12, 2012 at 5:45 PM, Jason Martin <[hidden email]> wrote:

On most linux distro's jars go in /usr/share/java/  ; program gets executed with a script in a bin/ directory ;  the script contains java -jar yourjarname

On Wed, Sep 12, 2012 at 5:36 PM, Bill Fenlason <[hidden email]> wrote:

Rene,

I think that moving things into the Java directories should be discouraged totally or endorsed totally.  In other words, either do it or don't do it.

Overall, it just seems to me that currently, all three of the bullet points under "Installing the NetRexx translator" suggest or imply (even by mentioning the deprecation) that it is OK to move things into the Java directories. 

I think that is a bad idea.  My recommendation is to eliminate any suggestion of tinkering with the Java directories, and to provide specific alternative instructions.

From a practical standpoint for a reasonably knowledgeable user (or developer), moving everything into the Java directories is actually an effective, simple solution, and I can understand why that was the original suggestion years ago.  I can also see merit in the argument that NetRexxR should be included in the Java ext directory so that all java has access to it.

But the bottom line at this point is that we should specifically tell the users that the Java directories belong to Java, and that in no circumstances should any NetRexx files be moved there. 

That is a good way to prevent problems with Java updates, and besides, would we want users moving things into any NetRexx directories we might create?

I would assume that when the installation process is finalized, nothing will be moved into the Java directories either.  (With the possible exception of the NetRexxR runtime if specifically requested by the user).

Bill

PS In a standard windows installation, C:\Program Files\Java\ contains the Java files such as the JRE and JDK.  In general, each application has a directory in \Program Files\.  I think it would be appropriate to have the NetRexx files end up in C:\Program Files\NetRexx\ as a default.  Other operating systems have their own conventions, and I believe that they should be followed as well.  For windows systems, to do otherwise will certainly cause lots of grief.  B.

On 9/12/2012 4:37 PM, René Jansen wrote:

Bill,

The scripts to the /bin directory in the Java installation tree must not be confused with the jars to the extensions directory, which may or may not (on some JVM's, depending on the value of an environment variable) be in the Java installation tree. This is fine, as long as it is writeable for the user, in order to not have compilations fail with an authorization error on some platforms, when choosing this directory to compile the example, or other code. This has happened recently to someone and the Quick Start Guide contains a caveat to this effect. I am not sure if this made the release or not; it will be in the next version if not. We deprecate the use of the extension library. The ' perhaps the bin directory [...]' is not my sentence, it is probably in there since the previous century,  but I can hardly find fault with it - if we observe the caveat. As it is limited to the script files it should be ok and removes the need to change the path - some people would be happy to hear that.

Do you suggest we also deprecate installation of the NetRexx compile scripts to the Java install tree? There are no technical reasons for this (things do not mysteriously fail), there is only overlap with one of the arguments for not using the extension directory (losing files if changing Java install tree locations), or should we take this out and only recommend installing the script files outside of the Java install tree - (on systems that have directory trees)? 

best regards,

René.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2221 / Virus Database: 2437/5264 - Release Date: 09/12/12

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hi Kermit, and all,

******************************************
NOW, I DO Totally DIS-AGREE with Mr. Kermit Kiser!

ANY, and ALL major Software Packages I do have on my Windows XP (very old) DESKTOP

*are following those very bloody* Microsoft Rules...

... please DO TRUST me, this time:

I do have on my Windows XP Desktop nearly any & all Compilers available (PL/I, COBOL IT, C, C++, C#, etc etc,
as well as a LOT of useful other Software as Adobe ..., ArcSoft, ... , etc,etc etc)

*AND*

All of them *do use* this bloody MicroSoft Architecture.

*THUS*:

Why shall a +novice NetRexx user+ have the need to *learn something ***NOT FOLLOWING THE ESTABLISHED RULES*** * ???

Please:

Let us, together, NOT re-INVENT the WHEEL(s), when the CAR is already there !!!

We cannot change the CAR, thus: USE IT!

No advertisement!

JUST a *STRONG HINT* from a 66 year old Informati(c)ker (german joke of mine)

Massa Thomas ,-)
===================================================================================================


Am 13.09.2012 00:24, schrieb Kermit Kiser:

Bill -

I agree that NetRexx items should never be placed in Java directories.

But I have to disagree with your PS.  "C:\Program Files" was Microsoft's most successful effort at screwing the world up. Especially for Java environments because of the arcane and contradictory rules about spaces in classpath depending on how it is specified. (The environment variable rules are different than the operand rules, etc.) Putting NetRexx in a reasonable directory with no spaces in it's path name will help to eliminate installation woes on Windows systems. I suggest "C:\NetRexx" which is what I personally use.

-- Kermit

On 9/12/2012 11:36 AM, Bill Fenlason wrote:

Rene,

I think that moving things into the Java directories should be discouraged totally or endorsed totally.  In other words, either do it or don't do it.

Overall, it just seems to me that currently, all three of the bullet points under "Installing the NetRexx translator" suggest or imply (even by mentioning the deprecation) that it is OK to move things into the Java directories. 

I think that is a bad idea.  My recommendation is to eliminate any suggestion of tinkering with the Java directories, and to provide specific alternative instructions.

From a practical standpoint for a reasonably knowledgeable user (or developer), moving everything into the Java directories is actually an effective, simple solution, and I can understand why that was the original suggestion years ago.  I can also see merit in the argument that NetRexxR should be included in the Java ext directory so that all java has access to it.

But the bottom line at this point is that we should specifically tell the users that the Java directories belong to Java, and that in no circumstances should any NetRexx files be moved there. 

That is a good way to prevent problems with Java updates, and besides, would we want users moving things into any NetRexx directories we might create?

I would assume that when the installation process is finalized, nothing will be moved into the Java directories either.  (With the possible exception of the NetRexxR runtime if specifically requested by the user).

Bill

PS In a standard windows installation, C:\Program Files\Java\ contains the Java files such as the JRE and JDK.  In general, each application has a directory in \Program Files\.  I think it would be appropriate to have the NetRexx files end up in C:\Program Files\NetRexx\ as a default.  Other operating systems have their own conventions, and I believe that they should be followed as well.  For windows systems, to do otherwise will certainly cause lots of grief.  B.

On 9/12/2012 4:37 PM, René Jansen wrote:

Bill,

The scripts to the /bin directory in the Java installation tree must not be confused with the jars to the extensions directory, which may or may not (on some JVM's, depending on the value of an environment variable) be in the Java installation tree. This is fine, as long as it is writeable for the user, in order to not have compilations fail with an authorization error on some platforms, when choosing this directory to compile the example, or other code. This has happened recently to someone and the Quick Start Guide contains a caveat to this effect. I am not sure if this made the release or not; it will be in the next version if not. We deprecate the use of the extension library. The ' perhaps the bin directory [...]' is not my sentence, it is probably in there since the previous century,  but I can hardly find fault with it - if we observe the caveat. As it is limited to the script files it should be ok and removes the need to change the path - some people would be happy to hear that.

Do you suggest we also deprecate installation of the NetRexx compile scripts to the Java install tree? There are no technical reasons for this (things do not mysteriously fail), there is only overlap with one of the arguments for not using the extension directory (losing files if changing Java install tree locations), or should we take this out and only recommend installing the script files outside of the Java install tree - (on systems that have directory trees)? 

best regards,

René.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Tom Maynard]

On 9/12/2012 5:24 PM, Kermit Kiser wrote:
> Putting NetRexx in a reasonable directory with no spaces in it's path
> name will help to eliminate installation woes on Windows systems. I
> suggest "C:\NetRexx" which is what I personally use.

Indeed, the earlier (IzPack v4.x) installer and the current (IzPack
v5.x) installer both have C:\netrexx as the default location ... but the
user may override this destination if they so choose.  At least that's
the way it stands now.  If the majority mandates a different default --
and/or that the user choice be removed -- then of course the installer
behavior will change accordingly.

Of course on other platforms the default installation location is
changed accordingly, but in a coherent manner.

Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

I recommend that the default be the standard windows default of
C:\Program Files\NetRexx\

The whole discussion about the installers can be summed up with the
saying "When in Rome, do as the Romans".  And another one is "Play nice".

In other words, On a windows system, make the installation look just
like any other installation.  Don't try to be "special".  Don't mess
with any other applications directory, and in particular, do not put
anything into directories belonging to Java.

On linux and OSX, "Play nice" means have the install follow all the
appropriate conventions to the letter.  Don't mess around with any other
installation.  Don't be "different".  Be willing to have it be boring.  
Ho-hum, just another install.

Bill

On 9/12/2012 11:56 PM, Tom Maynard wrote:

> On 9/12/2012 5:24 PM, Kermit Kiser wrote:
>> Putting NetRexx in a reasonable directory with no spaces in it's path
>> name will help to eliminate installation woes on Windows systems. I
>> suggest "C:\NetRexx" which is what I personally use.
>
> Indeed, the earlier (IzPack v4.x) installer and the current (IzPack
> v5.x) installer both have C:\netrexx as the default location ... but
> the user may override this destination if they so choose.  At least
> that's the way it stands now.  If the majority mandates a different
> default -- and/or that the user choice be removed -- then of course
> the installer behavior will change accordingly.
>
> Of course on other platforms the default installation location is
> changed accordingly, but in a coherent manner.
>
> Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[measel]

Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
Sent: Thursday, September 13, 2012 12:02 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga

I recommend that the default be the standard windows default of
C:\Program Files\NetRexx\

The whole discussion about the installers can be summed up with the
saying "When in Rome, do as the Romans".  And another one is "Play nice".

In other words, On a windows system, make the installation look just
like any other installation.  Don't try to be "special".  Don't mess
with any other applications directory, and in particular, do not put
anything into directories belonging to Java.

On linux and OSX, "Play nice" means have the install follow all the
appropriate conventions to the letter.  Don't mess around with any other
installation.  Don't be "different".  Be willing to have it be boring.  
Ho-hum, just another install.

Bill

On 9/12/2012 11:56 PM, Tom Maynard wrote:

> On 9/12/2012 5:24 PM, Kermit Kiser wrote:
>> Putting NetRexx in a reasonable directory with no spaces in it's path
>> name will help to eliminate installation woes on Windows systems. I
>> suggest "C:\NetRexx" which is what I personally use.
>
> Indeed, the earlier (IzPack v4.x) installer and the current (IzPack
> v5.x) installer both have C:\netrexx as the default location ... but
> the user may override this destination if they so choose.  At least
> that's the way it stands now.  If the majority mandates a different
> default -- and/or that the user choice be removed -- then of course
> the installer behavior will change accordingly.
>
> Of course on other platforms the default installation location is
> changed accordingly, but in a coherent manner.
>
> Tom.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[christel.u.w.pachl christel.u.w.pachl]

Unfortunately Program Files is the bane that Windows chose :-(

---- "Measel schrieb:

> Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
> Sent: Thursday, September 13, 2012 12:02 AM
> To: IBM Netrexx
> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga
>
> I recommend that the default be the standard windows default of
> C:\Program Files\NetRexx\

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[billfen]

Spaces in the directory name have to be handled in any event, since the
user might decide to name the directory "Net Rexx".

It was an unfortunate choice by M$, but most applications use the
standard default.  I suggest that NetRexx do the same.  After all, it is
just a default.  You, like any user, can change it if you wish.

Personally I find the space a pain, but having all the applications in
one place is a good thing for me.

Again, I'm recommending "Go with the flow".  The last thing we need are
non-standard installations procedures.


On 9/13/2012 8:56 AM, Walter Pachl wrote:

> Unfortunately Program Files is the bane that Windows chose :-(
>
> ---- "Measel schrieb:
>> Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
>> Sent: Thursday, September 13, 2012 12:02 AM
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga
>>
>> I recommend that the default be the standard windows default of
>> C:\Program Files\NetRexx\

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[measel]

Java wasn't built by M$ and it doesn't like spaces. There is no "default", just the way that some people (lemmings) do it to conform to the sad M$ format.

But since the objective here seems to be to make it usable even for people that regularly watch TLC, then go right ahead.  Best of luck using it that way.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
Sent: Thursday, September 13, 2012 8:36 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga

Spaces in the directory name have to be handled in any event, since the
user might decide to name the directory "Net Rexx".

It was an unfortunate choice by M$, but most applications use the
standard default.  I suggest that NetRexx do the same.  After all, it is
just a default.  You, like any user, can change it if you wish.

Personally I find the space a pain, but having all the applications in
one place is a good thing for me.

Again, I'm recommending "Go with the flow".  The last thing we need are
non-standard installations procedures.


On 9/13/2012 8:56 AM, Walter Pachl wrote:

> Unfortunately Program Files is the bane that Windows chose :-(
>
> ---- "Measel schrieb:
>> Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
>> Sent: Thursday, September 13, 2012 12:02 AM
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga
>>
>> I recommend that the default be the standard windows default of
>> C:\Program Files\NetRexx\

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

While we are in this mood, let me tell you what happened at work just
now. As an infrastructure teamlead (my current role, not a development
project) have to produce certain asset and configuration numbers. This
is, of course, all automated using NetRexx and runs for a year or so.

This morning I needed to make a change. An accountcode changed. The
program does not compile. That is odd.
I switch to the say 'hello world' program. It tells me:

Program test.nrx
    +++ Error: The class 'java.lang.Object' cannot be found
Compilation of 'test.nrx' failed [one error]

This is on Linux [hostname] 2.6.18-308.11.1.el5xen #1 SMP Fri Jun 15
16:19:17 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
with java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr11-20120806_01(SR11))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
jvmxa6460sr11-20120801_118201 (JIT enabled, AOT enabled)
J9VM - 20120801_118201
JIT  - r9_20120608_24176ifx1
GC   - 20120516_AA)
JCL  - 20120713_01

I am running with a mixed release compiler that contains 3.01 and some
of Kermit's after3.01 collection class work, on the standard IBM JRE
with ecj as compiler. Of no relevance but in the light of full
disclosure. I am not root on this machine, just mq and was admin.

I have a look at the java version date. I see it is very close -
20120801 - so the machine was patched.

My classpath starts with
CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.10.1/jre/lib/vm.jar:

this now needs to be
CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.11.0/jre/lib/vm.jar:

because I know that NetRexx needs the IBM JVM vm.jar on the classpath
when it misses java.lang.Object. Exactly why this is, I do not know and
we need to find out. We might have to ask someone who worked on J9 or
read the source.

This must be easier. Although all this is in the Quick Start Guide, we
should be able to fix this by looking closely at the Java runtime and
the use of the classloaders.

As long as we don't fix this, the installer should know it and take
care of it; in this case, a quick reinstall should be able to fix the
problem for the user.

best regards,

René.

On 2012-09-13 14:56, Walter Pachl wrote:

> Unfortunately Program Files is the bane that Windows chose :-(
>
> ---- "Measel schrieb:
>> Oh please NO. Spaces in directory name ("Program Files") cause all
>> manner of things to work incorrectly.
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Bill
>> Fenlason
>> Sent: Thursday, September 13, 2012 12:02 AM
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath
>> saga
>>
>> I recommend that the default be the standard windows default of
>> C:\Program Files\NetRexx\
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[kenner]

That space in "Program files" sure led me on long fruitless debugging trail for many hours. Microsloth is my least favorite os.

"C:\Netrexx" is a clean, simple answer but in my case at least, not viable. I have no write access to the root drive on my employers workstation. "%HOME%" would be my advice.

Kenneth Klein

Kermit Kiser <[hidden email]>
Sent by: [hidden email]

09/12/2012 06:47 PM

Please respond to
IBM Netrexx <[hidden email]>

To	IBM Netrexx <[hidden email]>
cc
Subject	Re: [Ibm-netrexx] eternal headache of the java classpath saga

Bill -

I agree that NetRexx items should never be placed in Java directories.

But I have to disagree with your PS.  "C:\Program Files" was Microsoft's most successful effort at screwing the world up. Especially for Java environments because of the arcane and contradictory rules about spaces in classpath depending on how it is specified. (The environment variable rules are different than the operand rules, etc.) Putting NetRexx in a reasonable directory with no spaces in it's path name will help to eliminate installation woes on Windows systems. I suggest "C:\NetRexx" which is what I personally use.

-- Kermit

On 9/12/2012 11:36 AM, Bill Fenlason wrote:
Rene,

I think that moving things into the Java directories should be discouraged totally or endorsed totally.  In other words, either do it or don't do it.

Overall, it just seems to me that currently, all three of the bullet points under "Installing the NetRexx translator" suggest or imply (even by mentioning the deprecation) that it is OK to move things into the Java directories.  

I think that is a bad idea.  My recommendation is to eliminate any suggestion of tinkering with the Java directories, and to provide specific alternative instructions.

From a practical standpoint for a reasonably knowledgeable user (or developer), moving everything into the Java directories is actually an effective, simple solution, and I can understand why that was the original suggestion years ago.  I can also see merit in the argument that NetRexxR should be included in the Java ext directory so that all java has access to it.

But the bottom line at this point is that we should specifically tell the users that the Java directories belong to Java, and that in no circumstances should any NetRexx files be moved there.  

That is a good way to prevent problems with Java updates, and besides, would we want users moving things into any NetRexx directories we might create?

I would assume that when the installation process is finalized, nothing will be moved into the Java directories either.  (With the possible exception of the NetRexxR runtime if specifically requested by the user).

Bill

PS In a standard windows installation, C:\Program Files\Java\ contains the Java files such as the JRE and JDK.  In general, each application has a directory in \Program Files\.  I think it would be appropriate to have the NetRexx files end up in C:\Program Files\NetRexx\ as a default.  Other operating systems have their own conventions, and I believe that they should be followed as well.  For windows systems, to do otherwise will certainly cause lots of grief.  B.


On 9/12/2012 4:37 PM, René Jansen wrote:
Bill,

The scripts to the /bin directory in the Java installation tree must not be confused with the jars to the extensions directory, which may or may not (on some JVM's, depending on the value of an environment variable) be in the Java installation tree. This is fine, as long as it is writeable for the user, in order to not have compilations fail with an authorization error on some platforms, when choosing this directory to compile the example, or other code. This has happened recently to someone and the Quick Start Guide contains a caveat to this effect. I am not sure if this made the release or not; it will be in the next version if not. We deprecate the use of the extension library. The ' perhaps the bin directory [...]' is not my sentence, it is probably in there since the previous century,  but I can hardly find fault with it - if we observe the caveat. As it is limited to the script files it should be ok and removes the need to change the path - some people would be happy to hear that.

Do you suggest we also deprecate installation of the NetRexx compile scripts to the Java install tree? There are no technical reasons for this (things do not mysteriously fail), there is only overlap with one of the arguments for not using the extension directory (losing files if changing Java install tree locations), or should we take this out and only recommend installing the script files outside of the Java install tree - (on systems that have directory trees)?

best regards,

René.



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

May I, *just as a reminder* for all of us, repeat, that I *exactly
therefore* did request some (long?) time ago
to *revise* and *redefine* the Rexx/ooRexx/NetRexx *PARSE Statement* to
handle QUOTES in a special
manner, and did propose an OPTION QUOTES (in any and all languages of
the *Rexx Family of Languages*,
NetRexx included, of course!!)

such that a Rexx (any dialect, NetRexx included) user can simple use the
famous PARSE invention
once forever (Leding QUOTES are a SPECIAL Case, *by CONVENTION*, in any
and all computer Languages I do
personally know) ....

They are called *Literals*, by the way, in some (when not all) IT
Professional documentations ...

The FOOL ON THE HILL   (CRAZY UNCLE TOM)
========================================================================================
Am 13.09.2012 15:35, schrieb Bill Fenlason:

> Spaces in the directory name have to be handled in any event, since
> the user might decide to name the directory "Net Rexx".
>
> It was an unfortunate choice by M$, but most applications use the
> standard default.  I suggest that NetRexx do the same.  After all, it
> is just a default.  You, like any user, can change it if you wish.
>
> Personally I find the space a pain, but having all the applications in
> one place is a good thing for me.
>
> Again, I'm recommending "Go with the flow".  The last thing we need
> are non-standard installations procedures.
>
>
> On 9/13/2012 8:56 AM, Walter Pachl wrote:
>> Unfortunately Program Files is the bane that Windows chose :-(
>>
>> ---- "Measel schrieb:
>>> Oh please NO. Spaces in directory name ("Program Files") cause all
>>> manner of things to work incorrectly.
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of Bill Fenlason
>>> Sent: Thursday, September 13, 2012 12:02 AM
>>> To: IBM Netrexx
>>> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga
>>>
>>> I recommend that the default be the standard windows default of
>>> C:\Program Files\NetRexx\
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030
Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx
Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's
Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Hi space haters,

I'm somewhat surprised at the hostility to spaces in paths.  After all, users of NetRexx presumably subscribe to the notion of human orientation in computer matters.

Most humans separate words with spaces (pace Thai readers).

As the dominant user-oriented OS, Windows could hardly require users to name folders and files with geek syntax.  Hate to say anything good about MS, but they got this right.

Isn't the real problem antediluvian OSs that preserve 40 year-old anachronisms like case sensitivity -- and can't deal with spaces?   :)

On Thu, Sep 13, 2012 at 9:48 AM, rvjansen <[hidden email]> wrote:

While we are in this mood, let me tell you what happened at work just now. As an infrastructure teamlead (my current role, not a development project) have to produce certain asset and configuration numbers. This is, of course, all automated using NetRexx and runs for a year or so.

This morning I needed to make a change. An accountcode changed. The program does not compile. That is odd.
I switch to the say 'hello world' program. It tells me:

Program test.nrx
   +++ Error: The class 'java.lang.Object' cannot be found
Compilation of 'test.nrx' failed [one error]

This is on Linux [hostname] 2.6.18-308.11.1.el5xen #1 SMP Fri Jun 15 16:19:17 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
with java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr11-20120806_01(SR11))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr11-20120801_118201 (JIT enabled, AOT enabled)
J9VM - 20120801_118201
JIT  - r9_20120608_24176ifx1
GC   - 20120516_AA)
JCL  - 20120713_01

I am running with a mixed release compiler that contains 3.01 and some of Kermit's after3.01 collection class work, on the standard IBM JRE with ecj as compiler. Of no relevance but in the light of full disclosure. I am not root on this machine, just mq and was admin.

I have a look at the java version date. I see it is very close - 20120801 - so the machine was patched.

My classpath starts with
CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.10.1/jre/lib/vm.jar:

this now needs to be
CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.11.0/jre/lib/vm.jar:

because I know that NetRexx needs the IBM JVM vm.jar on the classpath when it misses java.lang.Object. Exactly why this is, I do not know and we need to find out. We might have to ask someone who worked on J9 or read the source.

This must be easier. Although all this is in the Quick Start Guide, we should be able to fix this by looking closely at the Java runtime and the use of the classloaders.

As long as we don't fix this, the installer should know it and take care of it; in this case, a quick reinstall should be able to fix the problem for the user.

best regards,

René.

On 2012-09-13 14:56, Walter Pachl wrote:

Unfortunately Program Files is the bane that Windows chose :-(

---- "Measel schrieb:

Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
Sent: Thursday, September 13, 2012 12:02 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga

I recommend that the default be the standard windows default of
C:\Program Files\NetRexx\

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
"One can live magnificently in this world if one knows how to work and how to love."  --  Leo Tolstoy

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

BUT, HEY Mike Measel !!!!!

It's a WINDOWS Standard  (worldwide, by the way)!

Fortunately, in German speaking Countries, as *Austria*, this Folder is
named:

*Programme*

(That's the plural of *Programm*, in german, which is named *Program*
(in english))

Ende of Natural Language Education....


The FOOL on the HILL (Crazy Uncle Tom).
==========================================================================

Am 13.09.2012 14:25, schrieb Measel, Mike:

> Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
> Sent: Thursday, September 13, 2012 12:02 AM
> To: IBM Netrexx
> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga
>
> I recommend that the default be the standard windows default of
> C:\Program Files\NetRexx\
>
> The whole discussion about the installers can be summed up with the
> saying "When in Rome, do as the Romans".  And another one is "Play nice".
>
> In other words, On a windows system, make the installation look just
> like any other installation.  Don't try to be "special".  Don't mess
> with any other applications directory, and in particular, do not put
> anything into directories belonging to Java.
>
> On linux and OSX, "Play nice" means have the install follow all the
> appropriate conventions to the letter.  Don't mess around with any other
> installation.  Don't be "different".  Be willing to have it be boring.
> Ho-hum, just another install.
>
> Bill
>
> On 9/12/2012 11:56 PM, Tom Maynard wrote:
>> On 9/12/2012 5:24 PM, Kermit Kiser wrote:
>>> Putting NetRexx in a reasonable directory with no spaces in it's path
>>> name will help to eliminate installation woes on Windows systems. I
>>> suggest "C:\NetRexx" which is what I personally use.
>> Indeed, the earlier (IzPack v4.x) installer and the current (IzPack
>> v5.x) installer both have C:\netrexx as the default location ... but
>> the user may override this destination if they so choose.  At least
>> that's the way it stands now.  If the majority mandates a different
>> default -- and/or that the user choice be removed -- then of course
>> the installer behavior will change accordingly.
>>
>> Of course on other platforms the default installation location is
>> changed accordingly, but in a coherent manner.
>>
>> Tom.
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>
>

--
Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030
Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx
Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's
Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

Ach - we have to indirect it somehow if we want to use the standard.

Good point Tom.

best regards,

René.


On 2012-09-13 17:03, Thomas Schneider wrote:

> BUT, HEY Mike Measel !!!!!
>
> It's a WINDOWS Standard  (worldwide, by the way)!
>
> Fortunately, in German speaking Countries, as *Austria*, this Folder
> is named:
>
> *Programme*
>
> (That's the plural of *Programm*, in german, which is named *Program*
> (in english))
>
> Ende of Natural Language Education....
>
>
> The FOOL on the HILL (Crazy Uncle Tom).
>
> ==========================================================================
>
> Am 13.09.2012 14:25, schrieb Measel, Mike:
>> Oh please NO. Spaces in directory name ("Program Files") cause all
>> manner of things to work incorrectly.
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Bill
>> Fenlason
>> Sent: Thursday, September 13, 2012 12:02 AM
>> To: IBM Netrexx
>> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath
>> saga
>>
>> I recommend that the default be the standard windows default of
>> C:\Program Files\NetRexx\
>>
>> The whole discussion about the installers can be summed up with the
>> saying "When in Rome, do as the Romans".  And another one is "Play
>> nice".
>>
>> In other words, On a windows system, make the installation look just
>> like any other installation.  Don't try to be "special".  Don't mess
>> with any other applications directory, and in particular, do not put
>> anything into directories belonging to Java.
>>
>> On linux and OSX, "Play nice" means have the install follow all the
>> appropriate conventions to the letter.  Don't mess around with any
>> other
>> installation.  Don't be "different".  Be willing to have it be
>> boring.
>> Ho-hum, just another install.
>>
>> Bill
>>
>> On 9/12/2012 11:56 PM, Tom Maynard wrote:
>>> On 9/12/2012 5:24 PM, Kermit Kiser wrote:
>>>> Putting NetRexx in a reasonable directory with no spaces in it's
>>>> path
>>>> name will help to eliminate installation woes on Windows systems.
>>>> I
>>>> suggest "C:\NetRexx" which is what I personally use.
>>> Indeed, the earlier (IzPack v4.x) installer and the current (IzPack
>>> v5.x) installer both have C:\netrexx as the default location ...
>>> but
>>> the user may override this destination if they so choose.  At least
>>> that's the way it stands now.  If the majority mandates a different
>>> default -- and/or that the user choice be removed -- then of course
>>> the installer behavior will change accordingly.
>>>
>>> Of course on other platforms the default installation location is
>>> changed accordingly, but in a coherent manner.
>>>
>>> Tom.
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>> _______________________________________________
>> Ibm-netrexx mailing list
>> [hidden email]
>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>
>>

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

*Fully agreed*, George!
(I do think I should abbreviate this message to:   +1)

May I also note, that COBOL did and does permit the hyphen (-), also used as the Minus Sign (also '-')
in a way, as PL/I and also many other languages did use the UnderLine (_) ...

From the *semantic point of view*, in Languages in General,

*what would have happened in Computer Languages*

when the authors would have been WISE ENOUGH (at those days, very, very past)

TO ALLOW *MultiWord* (in the Rexx Sense)  ***Variable Names ***???

... and Function Names, as well ??

Many, many mistakes would have been never taken ...

But, as well do know, you cannot change History :-)

You (we, together), can only plan a *better Future*

SIC! (Latin: So ist es (german), ... Look up Google Translate for this, please ... ;-)

The FOOL on the HILL!
==========================================================================
Am 13.09.2012 17:02, schrieb George Hovey:

Hi space haters,

I'm somewhat surprised at the hostility to spaces in paths.  After all, users of NetRexx presumably subscribe to the notion of human orientation in computer matters.

Most humans separate words with spaces (pace Thai readers).

As the dominant user-oriented OS, Windows could hardly require users to name folders and files with geek syntax.  Hate to say anything good about MS, but they got this right.

Isn't the real problem antediluvian OSs that preserve 40 year-old anachronisms like case sensitivity -- and can't deal with spaces?   :)

On Thu, Sep 13, 2012 at 9:48 AM, rvjansen <[hidden email]> wrote:

While we are in this mood, let me tell you what happened at work just now. As an infrastructure teamlead (my current role, not a development project) have to produce certain asset and configuration numbers. This is, of course, all automated using NetRexx and runs for a year or so.

This morning I needed to make a change. An accountcode changed. The program does not compile. That is odd.
I switch to the say 'hello world' program. It tells me:

Program test.nrx
   +++ Error: The class 'java.lang.Object' cannot be found
Compilation of 'test.nrx' failed [one error]

This is on Linux [hostname] 2.6.18-308.11.1.el5xen #1 SMP Fri Jun 15 16:19:17 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
with java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr11-20120806_01(SR11))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr11-20120801_118201 (JIT enabled, AOT enabled)
J9VM - 20120801_118201
JIT  - r9_20120608_24176ifx1
GC   - 20120516_AA)
JCL  - 20120713_01

I am running with a mixed release compiler that contains 3.01 and some of Kermit's after3.01 collection class work, on the standard IBM JRE with ecj as compiler. Of no relevance but in the light of full disclosure. I am not root on this machine, just mq and was admin.

I have a look at the java version date. I see it is very close - 20120801 - so the machine was patched.

My classpath starts with
CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.10.1/jre/lib/vm.jar:

this now needs to be
CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.11.0/jre/lib/vm.jar:

because I know that NetRexx needs the IBM JVM vm.jar on the classpath when it misses java.lang.Object. Exactly why this is, I do not know and we need to find out. We might have to ask someone who worked on J9 or read the source.

This must be easier. Although all this is in the Quick Start Guide, we should be able to fix this by looking closely at the Java runtime and the use of the classloaders.

As long as we don't fix this, the installer should know it and take care of it; in this case, a quick reinstall should be able to fix the problem for the user.

best regards,

René.

On 2012-09-13 14:56, Walter Pachl wrote:

Unfortunately Program Files is the bane that Windows chose :-(

---- "Measel schrieb:

Oh please NO. Spaces in directory name ("Program Files") cause all manner of things to work incorrectly.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Bill Fenlason
Sent: Thursday, September 13, 2012 12:02 AM
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga

I recommend that the default be the standard windows default of
C:\Program Files\NetRexx\

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
"One can live magnificently in this world if one knows how to work and how to love."  --  Leo Tolstoy

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

Hey Rene, *and all*

The indirection is *very Easy*, as Kermit (I think, at least) did
already provide his famous

enviroment.nrx   (when I do recall the name correctly, by brain, without
looking at my BiblioGraphy)

There IS (in his program above) a Java Standard EnvironMent Variable
mentioned (as far as I can
recall by brain, wiothout looking up all of my printed out folders, you
know, I'm already 66 Years old,
time to die, maybe, somtimes ...)

*********************************************
ANYWAY (not joking, this time!)    ((( BUT I do *Love JOKES*, and I do
LOVE *LAUHGING*   ;-))
*********************************************

There is an Environnment Java Variable in Kermit's enviroment.nrx
*which directly does return* the Name of the so called

Progroam Files Folder   (english version)

TRUST ME, BABIES ... !!!

Hasta La Vista!
TERMINATOR VI   (Pure Steel ...)
=========================================================================================

Am 13.09.2012 17:11, schrieb rvjansen:

> Ach - we have to indirect it somehow if we want to use the standard.
>
> Good point Tom.
>
> best regards,
>
> René.
>
>
> On 2012-09-13 17:03, Thomas Schneider wrote:
>> BUT, HEY Mike Measel !!!!!
>>
>> It's a WINDOWS Standard  (worldwide, by the way)!
>>
>> Fortunately, in German speaking Countries, as *Austria*, this Folder
>> is named:
>>
>> *Programme*
>>
>> (That's the plural of *Programm*, in german, which is named *Program*
>> (in english))
>>
>> Ende of Natural Language Education....
>>
>>
>> The FOOL on the HILL (Crazy Uncle Tom).
>>
>> ==========================================================================
>>
>>
>> Am 13.09.2012 14:25, schrieb Measel, Mike:
>>> Oh please NO. Spaces in directory name ("Program Files") cause all
>>> manner of things to work incorrectly.
>>>
>>> -----Original Message-----
>>> From: [hidden email]
>>> [mailto:[hidden email]] On Behalf Of Bill Fenlason
>>> Sent: Thursday, September 13, 2012 12:02 AM
>>> To: IBM Netrexx
>>> Subject: Re: [Ibm-netrexx] eternal headache of the java classpath saga
>>>
>>> I recommend that the default be the standard windows default of
>>> C:\Program Files\NetRexx\
>>>
>>> The whole discussion about the installers can be summed up with the
>>> saying "When in Rome, do as the Romans".  And another one is "Play
>>> nice".
>>>
>>> In other words, On a windows system, make the installation look just
>>> like any other installation.  Don't try to be "special". Don't mess
>>> with any other applications directory, and in particular, do not put
>>> anything into directories belonging to Java.
>>>
>>> On linux and OSX, "Play nice" means have the install follow all the
>>> appropriate conventions to the letter.  Don't mess around with any
>>> other
>>> installation.  Don't be "different".  Be willing to have it be boring.
>>> Ho-hum, just another install.
>>>
>>> Bill
>>>
>>> On 9/12/2012 11:56 PM, Tom Maynard wrote:
>>>> On 9/12/2012 5:24 PM, Kermit Kiser wrote:
>>>>> Putting NetRexx in a reasonable directory with no spaces in it's path
>>>>> name will help to eliminate installation woes on Windows systems. I
>>>>> suggest "C:\NetRexx" which is what I personally use.
>>>> Indeed, the earlier (IzPack v4.x) installer and the current (IzPack
>>>> v5.x) installer both have C:\netrexx as the default location ... but
>>>> the user may override this destination if they so choose. At least
>>>> that's the way it stands now.  If the majority mandates a different
>>>> default -- and/or that the user choice be removed -- then of course
>>>> the installer behavior will change accordingly.
>>>>
>>>> Of course on other platforms the default installation location is
>>>> changed accordingly, but in a coherent manner.
>>>>
>>>> Tom.
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>> _______________________________________________
>>> Ibm-netrexx mailing list
>>> [hidden email]
>>> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>>>
>>>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
> Online Archive : http://ibm-netrexx.215625.n3.nabble.com/
>

--
Thomas Schneider CEO ThSITC IT Consulting KG Erdbergstr. 52-60/1/13 1030
Wien Austria, Europe Skype ID: Thomas.Schneider.Wien Member of the Rexx
Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's
Team (www.netrexx.org)

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Jason Martin]

On Linux there is usually a virtual package call default-java or default-jre they are just symlinks to a java version,
If they exist your  CLASSPATH=$CLASSPATH:/usr/lib/jvm/java-1.6.0-ibm-1.6.0.10.1/jre/lib/vm.jar:
would read CLASSPATH=$CLASSPATH:/usr/lib/jvm/default-jre/jre/lib/vm.jar: and when there is an update it does not break things.



_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

The way to indirect is to use a %foobar%  [I forget the correct spelling of
'foobar' for 'Program Files'].

Another technique is to use the 8.3 spelling of the name: Progra~1
(All folders have an 8-character no-blank unique name in Windows.)

> > (That's the plural of *Programm*, in german, which is named
> > *Program* (in english))

In English it is 'Programme', too.  In American English it is abbreviated to
'Program'.  In general, in England, we use 'programme' when talking about a
programme of events (e.g., at a theatre) and 'program' to refer to computer
software.  A useful distinction :-).

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/