Author
Topic: NetRexx on OS/2 (Read 2557 times)

We keep on having announcements. The screen shot is from 3.04, the current release is 3.08.

Running 3.08 is unchanged from 3.06. Is there some way to run NetRexx on OS/2 that I overlooked?

Quote

java -jar NetRexxF.jar -exec helloException in thread "main" java.lang.UnsupportedClassVersionError: org/eclipse/jdt/internal/compiler/tool/EclipseCompiler : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at org.netrexx.process.NetRexxC.process(NetRexxC.java:417) at org.netrexx.process.NetRexxC.main2(NetRexxC.java:338) at org.netrexx.process.NetRexxC.main2(NetRexxC.java:318) at org.netrexx.process.NetRexxC.main2(NetRexxC.java:314) at org.netrexx.process.NetRexxC.main(NetRexxC.java:168)

/* Translate and compile a NetRexx program *//* *//* use as: NetRexxC hello [file2]... *//* *//* which will use the NetRexx translator to *//* translate hello.nrx to hello.java *//* then will use javac to compile hello.java *//* *//* OPTIONS keywords may be added (with a -) before or *//* after the file specification, along with the extra *//* flags known to NetRexxC (such as -keep). For *//* example: *//* *//* NetRexxC -keep -format -comments hello *//* *//* Invoke with no parameters for a full list of flags. *//* *//* To run the class after compilation, specify -run as *//* an option word. Each file will be run in turn. *//* *//* NetRexxC -run hello *//* *//* Multiple programs may be specified; in this case *//* they are all run (if requested) after all compiles. *//* *//* ---------- *//* 1996.09.02 -- handle Warnings from NetRexxC (rc=1) *//* 1996.12.14 -- use COM.ibm.netrexx.process *//* 1998.05.25 -- pass NETREXX_JAVA setting to java.exe *//* 2011.09.01 -- use org.netrexx.process *//* 2011.09.01 -- remove -xms4M */

if subv>=6.0 then CALL VALUE 'CLASSPATH', '.;'this'\lib\NetRexxC.jar;'j_path'\lib\tools.jar', 'ENVIRONMENT' else if subv>=4.1 then NOP else if subv>=0.2 then javaopts='-norestart'; else if subv <> '' then do; say subv; javaopts='-noasyncgc'; end

/* Add any options from NETREXX_JAVA environment variable */ if subv < 4.2 then do nrjava=value('NETREXX_JAVA',,'ENVIRONMENT') if nrjava\='' then javaopts=javaopts nrjava end else javaopts=value('NETREXX_JAVA',,'ENVIRONMENT') end otherwise /* Add any options from NETREXX_JAVA environment variable */ javaopts=value('NETREXX_JAVA',,'ENVIRONMENT') end

An usual quality improvement: if this is supposed to be OS/2-specific Rexx code, without overdoing it, then you should support entered valid file name arguments like "C:\NetRexx test\text.txt", or "", or "test file.class, or "C:\CONFIG.SYS", each including the quote(s).

The modified NetRexxC.cmd nearly works. It gets through the Java version problem, and only fails for running hello. I only quoted the end of the output to show what is happening. hello.class is on the libpath, path and classpath.

By the way, every time I run NetRexxC, the path gets longer. Paths longer than 1024 bytes overwrite kernel memory, so this should be avoided.

That part of the code come from the original NetRexxC.cmd and was left alone as it is/was a design decision by the NetRexx Team.

If posted as some generic solution or reference here, not by the NetRexx Team but by you, then such a solution or reference is broken too. I'm not using their non-OS/2 software. So I'm not going to report a bug, nor will I fix their broken software for myself. Actually it'll be an old bug in IBM's code.

Please note exactly the same bug applies to quite a few OS/2 Rexx apps, regardless of the author. Hence the sample code.

So if I need updated NetRexxC.cmd, do I also need some updated NetRexxR.cmd?

Both appear to be worth checking, because it seems to be about as old as IBM Object Rexx for Windows. I can see a few possible updates for my old copy of NetRexxC.cmd, so there are reasons to assume OS/2 wasn't the target OS. No support for valid CLI file name arguments with quote(s) is a sample, and so is the mixed use of both ENVIRONMENT and OS2ENVIRONMENT.

The different package Rexx2Nrx may have an own, possibly conflicting NetRexxC.cmd file name. Which, in my case, is an eCS 1.2-customized version of Rexx2Nrx' original NetRexxC.bat file. Presumably written for Windows, because the file name Externals.bat is a little bit too long for x:\OS2\MDOS\COMMAND.COM.

The modified NetRexxC.cmd nearly works. It gets through the Java version problem, and only fails for running hello. I only quoted the end of the output to show what is happening. hello.class is on the libpath, path and classpath.

By the way, every time I run NetRexxC, the path gets longer. Paths longer than 1024 bytes overwrite kernel memory, so this should be avoided.

The problem is that the NetRexxC.cmd does not set classpath correctly. I'm not going to patch an increasingly bad REXX program, but rather I'll try to construct a useful one for the present day, that does not necessarily run original Java 1.1-based NetRexx from the 1990's.

The problem is that the NetRexxC.cmd does not set classpath correctly. I'm not going to patch an increasingly bad REXX program, but rather I'll try to construct a useful one for the present day, that does not necessarily run original Java 1.1-based NetRexx from the 1990's.