PC Online 1997 October

home *** CD-ROM | disk | FTP | other *** search

/ PC Online 1997 October / PCO1097.ISO / FilesBBS / OS2 / NETREXX.ARJ / NETREXX.ZIP / NetRexx / nrinst.doc < prev next >

Wrap

Text File | 1997-08-03 | 33.1 KB | 837 lines

NetRexx 1.113 NetRexx Installation and User's Guide ===================================== Copyright(c) IBM Corporation, 1996, 1997. All rights reserved. Introduction """""""""""" This document is the "User's Guide" for the reference implementation of NetRexx. NetRexx is a new programming language; a blend of Rexx and Java; the rules of syntax closely follow those of Rexx, while the semantics often follow Java. It is a dialect of Rexx that is as efficient and portable as Java, while preserving the philosophy and ease of use of Rexx. This document covers: o Unpacking the NetRexx packages o Installing the NetRexx package -- documentation and samples o Installing the NetRexx executables (for any Java platform): o How to install the NetRexx compiler o Problem solving o How to install just the NetRexx runtime classes o Using the NetRexxC compiler o Using NetRexx classes with World Wide Web applets o Installing and using the NetRexx print package o Current restrictions, _etc._ The NetRexx documentation and software are distributed free of charge under the conditions of the IBM Employee Written Software program. If you download or use a NetRexx package you agree to the terms in the _IBM License Agreement_ included in the package as the file license.txt. For details of the NetRexx language, and the latest news, please see the NetRexx documentation included with this package or available on the World Wide Web, for example at: http://www2.hursley.ibm.com/netrexx/ Mike Cowlishaw IBM UK Laboratories Unpacking NetRexx packages """""""""""""""""""""""""" The NetRexx packages are shipped in two forms, identified by a suffix following the name: o .zip format -- commonly used on OS/2 and other operating systems for the IBM PC o .tar.Z format -- (tape archive plus compress) commonly used on AIX and other Unix systems. You probably know how to handle these, but a word of caution: the packages contain directory structures, and files with 'long names' (that is, not of 8.3 maximum length names) which are case-sensitive. Many utilities, including some versions of UNZIP and TAR, can lose case information, truncate names, or fail to restore directories. --- Unpacking .zip files --- The most common packages for 'unzipping' these are Info-ZIP and PKZIP: Here are some tips: o Ensure that you are unzipping to a disk that supports long file names (for example, an HPFS disk or equivalent on OS/2 or Windows). o Info-ZIP: use version 5.12 (August 1994) or later. The syntax for unzipping NetRexx.zip is simply unzip NetRexx which should create the files and directory structure directly. Please see later in this document for complete installation instructions. o PKZIP: use a version that supports long file names. The syntax for unzipping NetRexx.zip is pkunzip -d NetRexx which should create the files and directory structure directly. The '-d' flag indicates that directory structure should be preserved. --- Unpacking .tar.Z files --- You need an up-to-date version of two programs: 'tar' and 'uncompress'; these are available for most operating systems. Here are some tips: o Ensure that you are unpacking to a disk that supports long file names (for example, any Unix disk, or an HPFS disk or equivalent on OS/2 or Windows). o Ensure that the version of tar that you use preserves case in names. If all the files created by tar have all-lowercase names, you need a new version of tar. The process of unpacking the file takes two steps: 1. Uncompress the file, using uncompress (this may be called simply 'compress' on some systems). The syntax for uncompressing NetRexx.tar.Z is probably one of: uncompress NetRexx.tar.Z compress -d NetRexx.tar.Z (the '-d' means decompress, and may be optional). This should replace the file with one called NetRexx.tar 2. Unpack the files and directories from the .tar file. The syntax for this is tar -xvf NetRexx.tar This should create the files and directories from the package, displaying the name of each as it is unpacked. You may see error messages where directories already exist; these can be ignored. After unpacking the files, the .tar file can be erased. Installation procedure - online documentation and samples """"""""""""""""""""""""""""""""""""""""""""""""""""""""" The NetRexx package (NetRexx.zip, or NetRexx.tar.Z) contains the NetRexx online documentation, together with samples and examples, and the packages of executables. 1. Copy the package file to the root directory of your choice, preserving the original name. 2. With your chosen directory as your current directory, unpack the package, following the instructions in 'Unpacking NetRexx packages' above. This should add the directory 'NetRexx' to your chosen directory, containing the documentation and samples for NetRexx, along with the packages of executables. There should also be a subdirectory ('NetRexx/netrexx/lang' or 'NetRexx\netrexx\lang') containing runtime class files used by some of the samples. The online documentation comes in two forms: plain ASCII (files with extension '.doc'), and World Wide Web hypertext format (files with extension '.htm' or '.html', '.gif', etc.). To view the hypertext version, start your browser at the file "netrexx.htm". For example, if you are using the IBM Web Explorer then the command explore netrexx.htm (executed when the documentation directory is the current directory) should show the NetRexx front page. Included in the documentation collection are a number of examples and samples (Hello, HelloApplet, etc.). To run any of these, you must have the Java runtime environment installed. Some of the examples must be viewed using the Java toolkit applet-viewer or a Java-enabled browser. Please see the hypertext pages describing these for detailed instructions. In general, if you see a message from Java saying: void main(String argv[]) is not defined this means that the class cannot be run using just the 'java' command. Installation of NetRexx Executables """"""""""""""""""""""""""""""""""" The NetRexx package includes two packages of software (each will have the same suffix as the package you unpacked it from, that is, '.zip' or '.tar.Z'): 1. nrtools -- the files for the NetRexx compiler, of which the most important is NetRexxC.zip, which contains the Java .class files that implement the compiler. The NetRexx compiler is in fact a translator; it translates NetRexx programs to Java source code, which is then compiled using the javac compiler (or you can use the Java compiler of your choice, if you prefer). This package requires that the Java toolkit (1.1.0 or later) be installed. nrtools also includes a separate copy of the NetRexx runtime classes, in NetRexxR.zip 2. nrping -- the Pinger sample application. Please see Pinger.htm for information about this. To install and use either of these packages, you must have already installed the Java Development Kit (JDK) runtime (and toolkit, if you want to compile NetRexx programs). For more information on these: o For OS/2 and AIX and other IBM operating systems, see the _IBM Centre for Java Technology_ page at: http://ncc.hursley.ibm.com/javainfo/hurindex.html o For other operating systems, see the _Sun Microsystems Java_ page at http://www.javasoft.com, or other suppliers of Java toolkits. Installation of the NetRexx compiler '''''''''''''''''''''''''''''''''''' Here's how to install the NetRexx compiler and runtime classes. These instructions apply to the majority of Java platforms (for use with Visual J++, please see below). 1. Copy the 'nrtools.zip' or 'nrtools.tar.Z' file from the NetRexx documentation directory to the Java home directory, using the original name. The name of the Java home directory will vary depending on the operating system you are using. Some possibilities are: /java \java11 \jdk1.1 It will contain directories such as 'bin' and 'lib'. [Note: if your Java home directory is on a CD-ROM, or otherwise inaccessible, you'll need to choose a different directory and set up a CLASSPATH environment variable that points to it. Consult your Java toolkit documentation for details on how to do this.] 2. With the Java home directory as your current directory, unpack the package, following the instructions in "Unpacking NetRexx packages" above. This should add the .zip files for the NetRexx runtime and compiler classes (NetRexxR.zip and NetRexxC.zip) to the Java 'lib' directory. In addition, some sample scripts and a test program should have been added to the Java 'bin' directory: hello.nrx -- a simple NetRexx program for testing NetRexxC.cmd -- the NetRexx compiler command in Rexx NetRexxC.bat -- similar NetRexx compiler command (Windows .bat) nrc.cmd -- shorter name for NetRexxC.cmd nrc.bat -- shorter name for NetRexxC.bat The .cmd files are simple Rexx scripts for making it easier to use the compiler. You don't have to use these, but they save some typing. They should require little modification to run under the Rexx interpreter for your platform; for details of Rexx interpreters, see: http://www2.hursley.ibm.com/rexx/ Under Windows, the .bat files should work -- they are not as flexible as the .cmd files, but will save typing. 3. Check that the names are correct in the 'lib' directory: there should be a file in the directory called 'NetRexxC.zip'; if the name is all in upercase or all in lowercase the package has not been unpacked correctly (see "Unpacking NetRexx packages"). 4. For Java to be able to find the NetRexx classes, you must update the CLASSPATH environment variable by adding the full path and name of the NetRexxC.zip file to the CLASSPATH setting. There will often already be a CLASSPATH variable set, including a path to the standard Java classes.zip file. Specify or add the full path (disk, directories, and file specification) for NetRexxC.zip, making sure that the case of every letter is exactly right (Java is very case-sensitive). For example, the full path might be something like: e:\java11\lib\NetRexxC.zip The procedure for setting the CLASSPATH variable depends on your operating system (and there may be more than one way). Here are some examples: o In OS/2 or Windows, use a SET CLASSPATH= command in CONFIG.SYS (for OS/2) or in AUTOEXEC.BAT (for Windows) and re-boot after changing. In both cases the command syntax is the same, and might look like this: set classpath=.;f:\javaos2\lib\NetRexxC.zip In this example, the first segment of the value (before the semicolon) lets classes in the current directory be found, and the second segment includes the classes needed by NetRexx. Both environments normally include the standard Java classes automatically. Under Windows NT 4.0 the CLASSPATH can be set using Start, Settings, Control Panel, System, Environment tab, System Variables, and clicking on CLASSPATH. o For Unix (Korn shell or Bourne shell), use: CLASSPATH=<newdir>:$CLASSPATH export CLASSPATH and changes for re-boot or opening of a new window should be placed in your .login (Bourne) or .profile (Korn) file o For Unix (C shell), use: setenv CLASSPATH <newdir>:$CLASSPATH and changes for re-boot or opening of a new window should be placed in your .cshrc file If you are unsure of how to do this, check the documentation you have for installing the Java toolkit. Note: If you add NetRexxC.zip to the CLASSPATH value then you do not need to add NetRexxR.zip; the latter contains only the NetRexx runtime classes (which are provided separately for people who don't want to run the NetRexx compiler). These runtime classes are also included in NetRexxC.zip. Whichever zip is used, the NetRexx runtime classes can be referred to from Java or NetRexx as being in the 'netrexx.lang' package. For example, a string might be of class 'netrexx.lang.Rexx'. --- Checking your installation is correct --- To check installation, change directory to the Java 'bin' directory, then (being very careful to get the case of letters correct): o Enter the command java COM.ibm.netrexx.process.NetRexxC hello This should run the NetRexx compiler, which converts the NetRexx program 'hello.nrx' to the Java program 'hello.java'. It then invokes the default Java compiler (javac), to compile the file 'hello.java' to make 'hello.class'. The intermediate .java file is then deleted, unless an error occurred. o Enter the command java hello This runs (interprets bytecodes from) the 'hello.class' file, which should display a simple greeting. On some systems, you may first have to add the directory that contains the 'hello.class' file to the CLASSPATH setting (see above) so Java can find it. With the sample scripts provided (NetRexxC.cmd or NetRexxC.bat), or the equivalent in the scripting language of your choice, the steps above can be combined into a simple single command: NetRexxC -run hello This package also includes a trivial 'nrc.cmd' and matching 'nrc.bat' file that simply passes on its arguments to NetRexxC; 'nrc' is just a shorter name that saves keystrokes, so for the last example you could type: nrc -run hello Note that scripts may be case-sensitive; unless running the OS/2 Rexx script, you will probably have to spell the name of the program exactly as it appears in the filename. You could also edit the nrc.cmd or nrc.bat and add your favourite 'default' NetRexxC options there (if you do this, keep a backup copy, so that if you install a new version of the NetRexx package you won't overwrite your changes). --- Installing NetRexx for use with Visual J++ --- (Many thanks to Bill Potvin and Bernhard Hurzeler for the details in this and the following section.) 1. Copy the following file into the [java_root]\Lib directory: NetRexxC.zip For example, if [java_root] is "E:\Java": C:\>copy NetRexxC.zip E:\Java\Lib 2. Similarly, copy the nrc.bat and NetRexxC.bat files to the [java_root]\Bin directory. 3. Add the zip file explicitly to the CLASSPATH: C:\>set CLASSPATH=%CLASSPATH%;[java_root]\Lib\NetRexxC.zip; For example, if [java_root] is "E:\Java", your CLASSPATH might then look like this: CLASSPATH=E:\Java\Lib;E:\Java\TrustLib;E:\Java\Lib\NetRexxC.zip; Under Windows NT 4.0 this can be done using Start, Settings, Control Panel, System, Environment tab, System Variables, and clicking on CLASSPATH. --- Using NetRexx with Visual J++ --- 1. Use the J++ "jview" command to invoke the NetRexx translator to convert a NetRexx program (e.g., hello.nrx) into a Java program (hello.java). You must specify the "-nocompile" option to NetRexx in order to prevent it from trying to invoke the Java toolkit compiler (which isn't in the MicroSoft J++ classes). For example, if hello.nrx is in the current directory: jview COM.ibm.netrexx.process.NetRexxC hello -nocompile The result of this step should be a Java source file called "hello.java". 2. Use the J++ "jvc" command to compile the Java source file: jvc hello.java The result of this step should be a Java .class file called "hello.class". 3. Execute the class file with the J++ command "jview": jview hello Note that all the commands above probably have to be typed exactly as shown (Java is very case-sensitive). The supplied NetRexxC.bat can be modified to work with the above commands by using 'jview' instead of the 'java' command and adding the 'jvc' step. Problems? ''''''''' If the 'hello' example doesn't work, one of the following problems may be the cause: o A "Can't find class COM.ibm.netrexx.process.NetRexxC..." message probably means that the NetRexxC.zip file has not been specified in your CLASSPATH setting, or is misspelled, or is in the wrong case. The CLASSPATH is the setting that Java uses to find classes for execution; please refer to your Java installation instructions for information on setting the CLASSPATH. o A "Can't find class hello..." message may mean that the directory with the hello.class file is not in your CLASSPATH, or either the filename or name of the class (in the source) is spelled wrong (the java command is [very] case-sensitive). o You didn't install on a file system that supports long file names (for example, on OS/2 or Windows you should use an HPFS disk or equivalent). Like most Java applications, NetRexx uses long file names. o You have a down-level Unzip or Tar program. Check that the file 'NetRexxC.zip', with just three capital letters, exists in the subdirectory 'lib' below the Java home directory. o You have only the Java runtime installed, and not the toolkit. If the toolkit is installed, you should have a program called javac on your computer. o You have a down-level version of Java installed. NetRexxC 1.1xx will run only on Java version 1.1.0 (and later versions). You can check the version of Java you have installed using the command 'java -version'. An older version of the NetRexx package is available for Java 1.0, however that version will no longer be enhanced or supported in any way. o Your Java toolkit installation has .class files from an earlier installation of NetRexx in classes/java/lang, classes/netrexx/lang, or other subdirectories in the 'classes' directory below the Java home directory. A message that reports ambiguous class references is a likely sign of this problem. The easiest way to solve it is to re-install the Java toolkit in a clean subdirectory. o If, when reporting an error or warning, the compiler gives a rather cryptic identifier and reports 'Sorry, full message not available', this means that it could not find the NetRexxC.properties (error messages) file, which should be in the COM.ibm.netrexx.process package (in NetRexxC.zip). o An 'Exception 0005' when using the OS/2 beta Java 1.1.1 toolkit is probably caused by the just-in-time compiler. Try turning it off before running NetRexxC by setting the environment variable: SET JAVA_COMPILER=no (and ignore the 'unable to load dll' message). Installation of just the NetRexx classes '''''''''''''''''''''''''''''''''''''''' To install only the NetRexx runtime classes (you don't need to do this if you already installed the NetRexxC compiler), follow the instructions for installing the compiler, but set your CLASSPATH to refer to NetRexxR.zip instead of NetRexxC.zip. Only the NetRexxR.zip is needed, so you may prefer to extract just this file from the nrtools package. The NetRexx class files can then be referred to from Java or NetRexx programs as from package 'netrexx.lang'. For example, a string might be of class 'netrexx.lang.Rexx'. Using the NetRexx compiler """""""""""""""""""""""""" The installation instructions for the NetRexx compiler describe how to use the package you installed to compile and run a simple NetRexx program. This section explains more of the options available to you. --- Invoking the compiler as a command --- The compiler is a Java program (class) which is called COM.ibm.netrexx.process.NetRexxC (NetRexxC for short). This can be invoked using the Java interpreter, for example, by the command: java COM.ibm.netrexx.process.NetRexxC or by using a system-specific command (such as 'NetRexxC' or 'nrc'). In either case, the compiler invocation is followed by one or more file specifications (these are the names of the files containing the NetRexx source code for the programs to be compiled). File specifications may include a path; if no path is given then NetRexxC will look in the current (working) directory for the file. NetRexxC will add the extension '.nrx' to input program names (file specifications) if no extension was given. So, for example, to compile 'hello.nrx' in the current directory, you can use any of: java COM.ibm.netrexx.process.NetRexxC hello java COM.ibm.netrexx.process.NetRexxC hello.nrx NetRexxC hello.nrx nrc hello (the first two should always work, the last two require that the system-specific command be available). The resulting .class file is placed in the current directory, and the .crossref (cross-reference) file is placed in the same directory as the source file (if there are any variables and the compilation has no errors). Here's an example of compiling two programs, one of which is in the directory 'D:\myprograms': nrc hello d:\myprograms\test2.nrx In this case, again, the .class file is placed in the current directory. Note that when more than one program is specified, they are all compiled with the same class context: that is, they can 'see' the classes, properties, and methods of the other programs being compiled, much as though they were all in one file. This allows mutually interdependent programs and classes to be compiled in a single operation (but see the section "Compiling multiple programs" below, if you use the PACKAGE instruction). The programs do, however, maintain their independence (that is, they may have different options, import, and package instructions). On completion, the NetRexxC command will exit with one of three return values: 0 if the compilation of all programs was successful, 1 if there were one or more Warnings, but no errors, and 2 if there were one or more Errors. As well as file names, you can also specify various option words, which are distinguished by the first character of the word being '-'. These may be any of the option words allowed on the NetRexx OPTIONS instruction (see the NetRexx language documentation), prefixed with '-'. These options words can be freely mixed with file specifications. The compiler also implements some additional option words, which cannot be used on the OPTIONS instruction: o -keep keep the intermediate .java file for each program. It is kept in the same directory as the NetRexx source file as xxx.java.keep, where xxx is the source file name. The file will also be kept automatically if the javac compilation fails for any reason. o -nocompile do not compile (just translate). Use this option when you want to use a different Java compiler. The .java file for each program is kept in the same directory as the NetRexx source file, as the file xxx.java (where xxx is the source file name); any -keep option is ignored. o -time display translation, javac compile, and total times (for the sum of all programs processed). If you are using the provided NetRexxC or nrc scripts, then an additional option is available: o -run run the resulting JAVA class as a stand-alone application, provided that the compilation had no errors. Here are some examples: java COM.ibm.netrexx.process.NetRexxC hello -keep -strictargs java COM.ibm.netrexx.process.NetRexxC -keep hello wordclock java COM.ibm.netrexx.process.NetRexxC hello wordclock -nocompile nrc hello nrc hello.nrx nrc -run hello nrc -run Spectrum -keep nrc hello -binary -verbose1 nrc hello -noverbose -format -keep Option words may be specified in lowercase, mixed case, or uppercase. File specifications are platform-dependent and may be case sensitive, though NetRexxC will always prefer an exact case match over a mismatch. Note that the -run option is implemented by the script, not the compiler; some scripts (such as NetRexxC.bat) may require that the '-run' be the first word of the command arguments, and/or be in lowercase. They may also require that only the name of the file be given if the -run option is used. See also the earlier section "The NetRexx home directory" if you need to change the place where the compiler finds its messages (for example, if error messages report 'Sorry, full message unavailable'). --- Compiling multiple programs --- When you specify more than one program for NetRexxC to compile, they are all compiled with the same class context: that is, they can 'see' the classes, properties, and methods of the other programs being compiled, much as though they were all in one file. This allows mutually interdependent programs and classes to be compiled in a single operation. For example, consider the following two programs (assumed in your current directory, as the files X.nrx and Y.nrx): /* X.nrx */ class X why=Y null /* Y.nrx */ class Y exe=X null each contains a reference to the other, so neither can be compiled in isolation. However, if you compile them together, using the command: nrc X Y then the cross-references will be resolved correctly. The total elapsed time will be less, too, as the class files for the NetRexxC compiler will only be loaded once. This example works as you would expect for programs that are not in packages. There's a restriction, though, if the classes you are compiling _are_ in packages (that is, they include a PACKAGE instruction). Currently, NetRexxC uses the javac compiler to generate the .class files, and for mutually-dependent files like these, javac requires that the source files be in the Java CLASSPATH, in the sub-directory described by the PACKAGE instruction. So, for example, if your project is based on the tree: D:\myproject then if the two programs above specified a package, thus: /* X.nrx */ package foo.bar class X why=Y null /* Y.nrx */ package foo.bar class Y exe=X null then: 1. You should put these source files in the directory: D:\myproject\foo\bar 2. The directory D:\myproject should appear in your CLASSPATH setting (if you don't do this, javac will complain that it cannot find one or other of the classes). 3. You should then make the current directory be D:\myproject\foo\bar and then compile the programs using the command 'nrc X Y', as above. With this procedure, you should end up with the .class files in the same directory as the .nrx files, and therefore also on the CLASSPATH and immediately usable by other packages. Note that when javac is used to generate the .class files, no new .class files will be created if any of the programs being compiled together had errors. --- Invoking the compiler from Java --- The compiler may be called from a Java program directly, by invoking the method in the COM.ibm.netrexx.process.NetRexxC class described as follows: method main(arg=Rexx) constant returns int The Rexx string passed to the method can be any combination of program names and options (except -run), as described above. A sample NetRexx program that invokes the NetRexx compiler to compile a program called 'test' is: /* compiletest.nrx */ s='test -keep -verbose4 -utf8' say COM.ibm.netrexx.process.NetRexxC.main(s) The returned int value will be one of the return values described above. NetRexxC is thread-safe (the only static properties are constants), but it is not known whether javac is thread-safe. Hence the invocation of multiple instances of NetRexxC on different threads should probably specify -nocompile, for safety. NetRexx classes and Applets for the Web """"""""""""""""""""""""""""""""""""""" If you write applets for the World Wide Web (or your intranet) in NetRexx, you will probably need to use the NetRexx classes (netrexx.lang.Rexx, _etc._); they will be used automatically if the default compilation options (specifically, options nobinary) are in effect. A good way of setting up an HTTP (Web) server for this is to keep all your applets in one subdirectory; you can then make the NetRexx runtime classes (that is, the classes in the package known by Java as netrexx.lang) available to all the applets by unzipping NetRexxR.zip into a subdirectory netrexx/lang below your applets directory. For example, if the root of your server tree is D:/mydata then you might put your applets into D:/mydata/applets and then the NetRexx classes (unzipped from NetRexxR.zip) should be in the directory D:/mydata/applets/netrexx/lang The same principle is applied if you have any other Java packages that you want to make available to your applets: the classes in a package called fred.math.quicksorts would go in a subdirectory below applets called fred/math/quicksorts, for example. Note that with Java 1.1 it should be possible to use the classes direct from the NetRexxR.zip file (which is in fact a Java 'jar' file), providing that the browser being used is at a Java 1.1 level. See the Java 1.1 documentation for details. Printable documentation """"""""""""""""""""""" The NetRexx printable package (NetRexxD.zip, or NetRexxD.tar.Z) contains the printable NetRexx documentation, in PostScript format. 1. Copy the package file to the root directory of your choice for documentation, preserving the original name. 2. With your chosen directory as your current directory, unpack the package, following the instructions in 'Unpacking NetRexx packages' above. This should add the directory 'NetRexxD' to your chosen directory, containing the printable documentation for NetRexx. 3. You can print files from the new directory that have the extension '.ps' on any PostScript printer, using the appropriate method for printing for your operating system. There are also utilities, such as 'GhostScript', available from public sources for viewing PostScript files and for printing them on non-PostScript printers. Current restrictions """""""""""""""""""" The NetRexx processor is now functionally complete, though work continues on usability and performance improvements. As of this version there are still a number of restrictions, listed below. Please note that the presence of an item in this section is not a commitment to remove a restriction in some future update; NetRexx enhancements are dependent on on-going research, your feedback, and available resources. You should treat this list as a 'wish-list' (and please send in your wishes). --- Short-term restrictions --- The following problem may occur in larger methods, with Java 1.0.1, 1.0.2, or 1.1.1 (it may have been fixed in later versions): o NetRexxC does not restrict the number of local variables used or generated. However, the 1.0 javac compiler fails with unrelated error messages (such as 'statement unreachable' or 'variable may be uninitialized') if asked to handle more than 63 local variables. The following restriction requires new methods in the Rexx class before it can be removed: o Automatic conversions from java.lang.String references to netrexx.lang.Rexx objects will fail with a 'NullPointerException' if the reference equals null. --- Long term restrictions --- The following restrictions are due to the use of a translator, and would probably only be lifted if a direct-to-bytecodes NetRexx compiler were built. o Externally-visible names (property, method, and class names) cannot be Java reserved words (you probably want to avoid these anyway). o There are various restrictions on naming and the contents of programs (the first class name must match the program name, etc.). o The javac compiler requires that mutually-dependent source files be on the CLASSPATH, so javac can find the source files. NetRexxC does not have this restriction, but when using javac for the final compilation you will need to follow the convention described under 'Compiling multiple programs', above. o The 'symbols' option applies to all programs compiled together if any of them specify that option. o Some binary floating point underflows may be treated as zero instead of being trapped as errors. o Side-effects of calls to this() and super() in constructors may be seen before the method and method call instructions are traced -- this is because Java does not permit tracing instructions to be added before the call to this() or super(). o The results of expressions consisting of the single term 'null' are not traced.