Bonjour Jean-Louis,
thank you very much for your information!
On 21.07.2021 09:21, Jean Louis Faucher wrote:
> Guten tag Rony
>
> Thanks a lot for the detailed explanations.
> After setting BSF4Rexx_JavaStartupOptions as you explained, the 3rd test case
> is ok now.
> More tests:
>
> rexx 1-030_JavaVersion.rxj works correctly.
>
> rexxj2.sh 1-010_HelloWorld.rxj did not work because of "Library not loaded:
> @rpath/librexx.4.dylib”
> Should be found with DYLD_LIBRARY_PATH, but SIP deleted it:
> - rexxj2.sh has a shebang line #!/bin/sh, which is protected by SIP
> - the default java is protected by SIP.
>
> After installing a local JDK (just unzip + set JAVA_HOME) and removing the
> shebang line of
> rexxj2.sh, that worked.
A question here: after you removed the shebang line how were you able to
successfully invoke/run
"rexx2.sh 1-010_HellowWorld.rxj"?
---
Ad background to "rexxj.sh"/"rexxj2.sh":
* purpose: run Rexx scripts /via java //instead of /via the rexx binary using
the file name of the
Rexx script as argument, optionally followed by arguments for the Rexx
script
* so "rexxj[2].sh" Java gets launched (if the environment variable
"BSF4Rexx_JavaStartupOptions"
exists then its value gets passed to /java/, which configures the Java
virtual machine, JVM)
which loads the BSF4ooRexx Java class named "org.rexxla.bsf.RexxDispatcher"
and run its static
main method supplying all command line arguments.
* the main method of the Java class "org.rexxla.bsf.RexxDispatcher" will
create an instance of
"org.apache.bsf.BSFManager"
o all the command line arguments as parsed and supplied by Java and
passed on to the static
main method as a Java String array get registered with the BSFManager
instance under the
name "allCommandLineArguments";
o BSFManager needs to find and create the engine for Rexx: it looks up
the BSF defined engine
names and dynamically loads the Java class
"org.rexxla.bsf.engines.rexx.RexxEngine" which
extends the abstract class "org.apache.bsf.util.BSFEngineImpl" which
implements the
interface class "org.apache.bsf.BSFEngine"
+ an instance of "org.rexxla.bsf.engines.rexx.RexxEngine" gets
created and the current set
of BSFManager registered beans will get registered with the
RexxEngine instance
+ the RexxEngine instance will have its "initialize()" method invoked
# the RexxEngine creates an instance of
"org.rexxla.bsf.engines.rexx.RexxAndJava"
which serves as the interface for this combination of this
BSFManager instance and
this RexxEngine instance
* the very first time the
"org.rexxla.bsf.engines.rexx.RexxAndJava" class gets
loaded its static constructor will - among other things -
load the dynamic
BSF4ooRexx library using
java.lang.System.loadLibrary(libName)
* the constructor of
"org.rexxla.bsf.engines.rexx.RexxAndJava" will use a native
method from the BSF4ooRexx dynamic library to initialize it
# the RexxEngine registers the BSFManager's registered beans with
its instance such
that a Rexx programmer can get at the Java parsed arguments (a
Java array of type
String) with the statement:
argsByJava=bsf.lookupBean("allCommandLineArguments")
o the freshly created RexxEngine is then used to execute the supplied
Rexx script (which will
be read from file), supplying the arguments to the Rexx script
+ at the very first time a Rexx script needs to be executed, the
RexxEngine creates a
RexxInterpreter instance for that purpose, and reuses it each time
Rexx code needs to
get executed via this RexxEngine
+ Remark: for Java programmers it is possible to configure the
RexxInterpreter before the
very first usage (e.g. command handlers, exits, file extensions,
etc.); the BSF4ooRexx
samples demonstrate this in form of nutshell samples
o BSF.CLS when called or required from a Rexx script will check, whether
Java is already
loaded (which in this use case will be the case) and if so, it does not
load Java (even if a
Rexx programmer attempted to do that, a Rexx condition would be raised:
/BSF4ooRexx/routine/BsfLoadJava(), error 1.999: JVM is already loaded/);
BSF.CLS uses the external Rexx function BsfInvokedBy() which returns
"0" if Java is not
loaded yet, "1" if Java loaded ooRexx, "2" if ooRexx loaded Java
---
Ad necessity to use "rexxj.sh"/ "rexxj2.sh" on MacOSX if running Rexx scripts
that use any of the
Java GUI classes (awt, swing, JavaFX): unfortunately it is not possible to use
the Java GUI classes
if Java gets loaded via Rexx. The reason being that an MacOSX event loop on
MacOSX is not started
and present, such that awt/swing/JavaFX cannot be intertwined with the MacOS
event loop.
[If ooRexx was somehow able to initialize this support one could use rexx to
run the Rexx scripts on
this platform as well. If anyone has any ideas, knowledge or experimental code,
I would really
appreciate it a lot to learn about them! It may be even some silly little piece
of "how-to" to make
this work.]
However starting Java first initializes its runtime environment in a way that
it allows for using
the MacOSX event loop and therfore its GUI classes. Therefore "rexxj.sh" on
MacOSX is mandatory in
the case the Rexx program uses any of the GUI classes. This is also the reason
why "rexxj.sh" gets
associated with the Rexx scripts on MacOSX.
---rony
>
> Side note about the shebang:
> https://stackoverflow.com/questions/12296308/shell-script-working-fine-without-shebang-line-why
> <https://stackoverflow.com/questions/12296308/shell-script-working-fine-without-shebang-line-why>
> "An executable file without a shebang and not matching an binary executable
> format is run with sh."
> sh is protected by SIP, so DYLD_LIBRARY_PATH should be deleted... But it’s
> not. At least under
> High Sierra.
>
>
> Jean-Louis
>
>> On 20 Jul 2021, at 13:55, Rony G. Flatscher <rony.flatsc...@wu.ac.at
>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> Bonjour Jean-Louis,
>>
>> thank you /very /much for looking into this!
>>
>> In this use case in which rexx (because of BSF.CLS) loads
>> libBSF4ooRexx.dylib which then tries to
>> locate and loadlibjvm.dylib et.al. the following would apply:
>>
>> * rexx -e "call bsf.cls"
>> rexx -e "call bsf.cls; say .bsf4rexx~display.version; say
>> .java.lang.System~getProperty('java.library.path')"
>>
>> o rexx needs to be able to load libBSF4ooRexx.dylib
>>
>> o even if /opt/BSF4ooRexx existed rexx would not load anything from
>> there as that location
>> is unknown to it
>>
>> o so either DYLD_LIBRARY_PATH needs to be set and point to the
>> directory
>> wherelibBSF4ooRexx.dylib can be loaded from or place a symbolic link
>> into
>> /usr/local/lib/libBSF4ooRexx.dylib such that the system can find and
>> load it
>>
>> * oncelibBSF4ooRexx.dylib got loaded successfully from rexx the
>> initialization code ("prolog")
>> of BSF.CLS will use it to see whether Java is already loaded and if not
>> load libjvm.dylib
>> ("Java") at that point in time
>>
>> o Since yesterday's version of libBSF4ooRexx.dylib ("BSF
>> 641.20210719") MacOS uses these
>> places to find and load Java (libjvm.dylib):
>>
>> + /opt/BSF4ooRexx/libjvm.dylib
>> # comment: if you used the install script a symbolic link to
>> the Java version that
>> got used to install BSF4ooRexx will be created there, such
>> that that version (as
>> long as it did not get updated) can be found and used; one
>> could delete this
>> symbolic link to have the next searches for libjvm.dylib
>> take place:
>>
>> + if JAVA_HOME is defined then the following two attempts get
>> carried out (this got
>> added this past weekend, a long standing intent)
>>
>> # ${JAVA_HOME}/lib/server/libjvm.dylib and if not found, then
>> # ${JAVA_HOME}/jre/lib/server/libjvm.dylib
>> * comment: starting with Java 9 (and then adjusted
>> accordingly for Java 8 LTS)
>> the directory layout of Java got changed such that these
>> two locations may
>> carry libjvm.dylib, depending on the installed Java
>> versions
>>
>> + /System/Library/Frameworks/JavaVM.framework/JavaVM
>> # comment: this location (Apple only) stems from the days when
>> Apple supplied its
>> own Java which now seems to find the default installed Java
>>
>> + libjvm.dylib
>> # comment: this causes the operating system lookup to be
>> employed to locate
>> libjvm.dylib
>>
>> o after loading Java eventually successfully from the Rexx side (which
>> is the case in all
>> of your test cases!), the next step is using a Java class that
>> causes the Java BSF
>> scripting support for Rexx to be initialized; in this process
>> libBSF4ooRexx.dylib needs
>> to be loadable by the Java side which uses java.library.path to
>> search for libraries; if
>> not found the error message "/[BSFManager.loadScriptingEngine()]
>> unable to load language:
>> rexx: java.lang.UnsatisfiedLinkError: no BSF4ooRexx in
>> java.library.path/" gets issued;
>> e.g. (from above)
>>
>> rexx -e "call bsf.cls; say .bsf4rexx~display.version; say
>> .java.lang.System~getProperty('java.library.path')"
>>
>> will display the java.library.path in effect; since yesterday ("BSF
>> 641.20210719") the
>> new default for Unix (including Apple) is defined to be (note the
>> current directory as
>> the last one to look up):
>>
>>
>> /opt/BSF4ooRexx:/usr/lib:/usr/lib64:/usr/local/lib:/usr/local/lib64:.
>>
>> such that libBSF4ooRexx.dylib needs to be in one of these six
>> locations
>> + comment: it would be possible to set the value for
>> java.library.path that gets used
>> by defining an environment symbol named
>> "BSF4Rexx_JavaStartupOptions" with the Java
>> desired startup options (just enter "java" in a Terminal to see
>> the standard startup
>> options), in this case you would need to have also something
>> like the following as
>> sole entry or as part of it (a supplied definition for
>> java.library.path will inhibit
>> BSF4ooRexx to use its default):
>> -Djava.library.path=the:paths:to:lookup:by:java
>>
>> If libBSF4ooRexx.dylib cannot be loaded by Java at this stage then
>> the loading of the
>> Rexx script engine will cause an exception with the error message
>> that you experience:
>>
>> So with this context the test cases behave as expected.
>>
>> ---
>>
>> Ad JAVA_HOME: this environment variable is very common in the Java world. It
>> allows to have many
>> different Java versions on the same computer (there are zip archives for
>> Java which one merely
>> can unzip) and use different Java versions in different processes. Changing
>> JAVA_HOME then allows
>> one to test an application on a different/specific Java version.
>>
>> ---
>>
>> A hint ad using BSF4ooRexx in a non-installed use-case: if you change into
>> the unzipped directory
>> of the BSF4ooRexx zip-archive, i.e. "bsf4oorexx/install" and
>>
>> * run "setupBSF.rex" in "bsf4oorexx/install", then the installation and
>> companion scripts get
>> created and a symbolic link to the system's libBSF4ooRexx.dylib (there
>> may be different on
>> different Linuxes) gets created in the unzipped "bsf4oorexx" directory;
>> the created script
>> "setEnvironment4BSF.sh" will allow you to temporarily set your session's
>> environment to use
>> this version of BSF4ooRexx, just source it and the appropriate CLASSPATH
>> environment variable
>> will be set
>>
>> o if you have OpenOffice or LibreOffice installed and want to use it
>> for the AOO/LO Rexx
>> sample and utility scripts (file extensions ".rxo", rexx script for
>> OpenOffice), then run
>> "setupOOo.rex" in "bsf4oorexx/install" which will also create a
>> "setEnvironment4OOo.sh"
>> which you can source (CLASSPATH gets changed to point to the AOO/LO
>> jar files that allow
>> to use AOO/LO via BSF4ooRexx)
>>
>> * if you then use PATH and DYLD_LIBRARY_PATH to point to the unzipped
>> "bsf4oorexx" directory
>> you should be able to run all ooRexx scripts of BSF4ooRexx in that
>> session.
>>
>> Again, many thanks for taking the time to test this version!
>>
>> ---rony
>>
>>
>> On 20.07.2021 11:36, Jean Louis Faucher wrote:
>>> Guten tag Rony
>>>
>>> I have the same error in the 3 test cases.
>>>
>>> Note:
>>> I don’t have a directory /opt/BSF4ooRex
>>> I don’t have an environment variable with value /opt/BSF4ooRex
>>>
>>>
>>> *1st test case*
>>> Nothing in DYLD_LIBRARY_PATH
>>> libBSF4ooRexx.dylib copied in oorexx5 lib
>>>
>>> rexx -e “call bfs.cls”
>>> [BSFManager.loadScriptingEngine()] unable to load language: rexx:
>>> java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path
>>>
>>> libBSF4ooRexx.dylib is correctly loaded from oorexx5 lib
>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>> dyld: loaded:
>>> /local/rexx/oorexx/build/official/main/trunk/macos/clang/release/64/delivery/lib/libBSF4ooRexx.dylib
>>>
>>> libjvm is not found
>>> dlopen(/opt/BSF4ooRexx/libjvm.dylib, 0x00000009)
>>> dlopen() failed, error: 'dlopen(/opt/BSF4ooRexx/libjvm.dylib, 9): image
>>> not found'
>>>
>>>
>>> *2nd test case*
>>> remove libBSF4ooRexx.dylib from oorexx5 lib
>>> Put my install directory of libBSF4ooRexx.dylib in DYLD_LIBRARY_PATH
>>> libjvm directory not put in DYLD_LIBRARY_PATH
>>>
>>> rexx -e “call bfs.cls”
>>> [BSFManager.loadScriptingEngine()] unable to load language: rexx:
>>> java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path
>>>
>>> libBSF4ooRexx.dylib is correctly loaded from my install directory
>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>> dyld: loaded:
>>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210719-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
>>>
>>> libjvm is not found
>>> dlopen(/opt/BSF4ooRexx/libjvm.dylib, 0x00000009)
>>> dlopen() failed, error: 'dlopen(/opt/BSF4ooRexx/libjvm.dylib, 9): image
>>> not found'
>>>
>>>
>>> *3rd test case*
>>> Add libjvm directory in DYLD_LIBRARY_PATH
>>>
>>> rexx -e “call bfs.cls”
>>> [BSFManager.loadScriptingEngine()] unable to load language: rexx:
>>> java.lang.UnsatisfiedLinkError: no BSF4ooRexx in java.library.path
>>>
>>> libBSF4ooRexx.dylib is correctly loaded from my install directory
>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>> dyld: loaded:
>>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210719-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
>>>
>>> libjvm is loaded (despite the path passed to dlopen)
>>> dlopen
>>> x/libjvm.dylib, 0x00000009)
>>> dyld: loaded:
>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
>>>
>>>
>>>> On 19 Jul 2021, at 18:01, Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>>
>>>> Bonsoir Jean-Louis,
>>>>
>>>> today I finished up a new version of BSF4ooRexx that should work in this
>>>> use-case. You can get
>>>> it from
>>>> <https://sourceforge.net/projects/bsf4oorexx/files/beta/20200928/BSF4ooRexx_install_v641-20210719-beta.zip/download>.
>>>> (This version got tested against MacOS, Linux and Windows.)
>>>>
>>>> If you test this version in your environment then please let me know of
>>>> any difficulties or
>>>> problems that you encounter. (This version of BSF4ooRexx is still supposed
>>>> to be usable against
>>>> ooRexx 4.1 and higher, however 5.0 is *strongly* advised due to its stable
>>>> multithreadingness.
>>>> For that reason some JavaFX samples will deny being run on ooRexx prior to
>>>> 5.0. This is another
>>>> reason for me to ask for a release version of ooRexx 5.0 beta *as is*, as
>>>> it is much stabler,
>>>> faster and powerful than any earlier version of ooRexx.)
>>>>
>>>> ---rony
>>>>
>>>>
>>>> On 18.07.2021 00:02, Jean Louis Faucher wrote:
>>>>> Gute nacht Rony
>>>>>
>>>>> I have an atypical configuration where I use DYLD_LIBRARY_PATH to locate
>>>>> the BSF4OORexx library.
>>>>> This is because I don’t “install” BSF4OORexx, I just unzip the delivery,
>>>>> copy and rename the
>>>>> libraries to bsf4oorex/install/64
>>>>> With this configuration, your test cases are working (not saying this is
>>>>> the solution).
>>>>>
>>>>>
>>>>> If I don’t set DYLD_LIBRARY_PATH, I get the same error than yours.
>>>>>
>>>>> I compared the output of the next command in both cases
>>>>> DYLD_PRINT_LIBRARIES="1" DYLD_PRINT_APIS="1" rexx -e "call bsf.cls”
>>>>>
>>>>> In the working session:
>>>>> dlopen(librexxapi.dylib, 0x00000001)
>>>>> dlopen(librexxapi.dylib) ==> 0x10936da50
>>>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>>>> dyld: loaded:
>>>>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/install/64/libBSF4ooRexx.dylib
>>>>> dyld: loaded:
>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/lib/server/libjvm.dylib
>>>>> dyld: loaded: /usr/lib/libstdc++.6.0.9.dylib
>>>>>
>>>>> In the not working session:
>>>>> dlopen(librexxapi.dylib, 0x00000001)
>>>>> dlopen(librexxapi.dylib) ==> 0x10dd4a990
>>>>> dlopen(libBSF4ooRexx.dylib, 0x00000001)
>>>>> dlopen() failed, error: 'dlopen(libBSF4ooRexx.dylib, 1): image not
>>>>> found'
>>>>> dlopen(/usr/lib/libBSF4ooRexx.dylib, 0x00000001)
>>>>> dlopen() failed, error: 'dlopen(/usr/lib/libBSF4ooRexx.dylib, 1): image
>>>>> not found'
>>>>> 919 *-* ::routine xBSF PUBLIC EXTERNAL "LIBRARY
>>>>> BSF4ooRexx BSF
>>>>> "
>>>>> 1 *-* call bsf.cls
>>>>> Error 98 running
>>>>> /local/rexx/bsf4oorexx/BSF4ooRexx_install_v641-20210715-beta/bsf4oorexx/BSF.CLS
>>>>> line 919:
>>>>> Execution error.
>>>>> Error 98.903: Unable to load library "BSF4ooRexx".
>>>>>
>>>>> I find "/usr/lib” in one file:
>>>>> SysLibrary.cpp
>>>>>
>>>>> // try loading directly
>>>>> libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>>>>> // if not found, then try from /usr/lib
>>>>> if (libraryHandle == NULL)
>>>>> {
>>>>> sprintf(nameBuffer, "/usr/lib/lib%s%s", name,
>>>>> ORX_SHARED_LIBRARY_EXT);
>>>>> libraryHandle = dlopen(nameBuffer, RTLD_LAZY);
>>>>>
>>>>> The part to investigate is how to make the first dlopen work without
>>>>> using DYLD_LIBRARY_PATH:
>>>>> If I put libBSF4ooRexx.dylib in the lib folder of oorexx then it works
>>>>> (RPATH).
>>>>> If I put libBSF4ooRexx.dylib in the current directory then it works (see
>>>>> man dlopen).
>>>>> I don’t know if other solutions are possible for the first dlopen
>>>>>
>>>>> The other solution could to add “/usr/local/lib” as 2nd fallback.
>>>>> But that brings the question of order.
>>>>> Maybe a more general solution would be to use an environment variable
>>>>> like REXX_LIBRARY_PATH.
>>>>> We have already REXX_PATH for locating the rexx files.
>>>>>
>>>>>
>>>>> Jean-Louis
>>>>>
>>>>>> On 17 Jul 2021, at 21:56, Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>>>>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>>>>>
>>>>>> On MacOSX the BSF4ooRexx library is named "libBSF4ooRexx.dylib".
>>>>>>
>>>>>> Testing the changes in the BSF4ooRexx installation scripts and then
>>>>>> testing the resulting
>>>>>> installations surfaced a problem on MacOSX: libBSF4ooRexx.dylib can be
>>>>>> loaded via Java and
>>>>>> used successfully.
>>>>>>
>>>>>> However, loading "libBSF4ooRexx.dylib" via ooRexx is not successful. To
>>>>>> be precise, the
>>>>>>
>>>>>> ::routine xbsf PUBLIC EXTERNAL "LIBRARY BSF4ooRexx BSF"
>>>>>>
>>>>>> fails with the execution error:
>>>>>>
>>>>>> Error 98.903: Unable to load library "BSF4ooRexx".
>>>>>>
>>>>>> Here two rexxtry.rex sessions, the first one is run with "rexxj.sh
>>>>>> /usr/local/bin/rexxtry.rex" which loads a Java program that will load
>>>>>> the BSF4ooRexx library
>>>>>> to then execute /usr/local/bin/rexxtry.rex. This is followed by a "rexx
>>>>>> rexxtry.rex" session
>>>>>> which yields the exection error. This is then followed by the "rexx -e"
>>>>>> statement which does
>>>>>> a call BSF.CLS which then shows the full error message:
>>>>>>
>>>>>> rony@ronymac2014 ~ % rexxj.sh /usr/local/bin/rexxtry.rex
>>>>>> REXX-ooRexx_5.0.0(MT)_64-bit
>>>>>> 6.05 12 Jul 2021 rexxtry.rex lets you interactively try REXX
>>>>>> statements. Each string is
>>>>>> executed when you hit Enter. Enter 'call tell' for a description of
>>>>>> the features. Go on -
>>>>>> try a few... Enter 'exit' to end. call bsf.cls
>>>>>> .............................................. rexxtry.rex on DARWIN
>>>>>> say
>>>>>> .bsf4rexx~display.version ooRexx 5.0.0 r12280 (12 Jul 2021) / BSF
>>>>>> 641.20210715 / Java
>>>>>> 1.8.0_162, 64-bit / Darwin 20.5.0
>>>>>> ..............................................
>>>>>> rexxtry.rex on DARWIN exit
>>>>>> rony@ronymac2014 ~ % rexxtry.rex REXX-ooRexx_5.0.0(MT)_64-bit 6.05
>>>>>> 12 Jul 2021
>>>>>> rexxtry.rex lets you interactively try REXX statements. Each string
>>>>>> is executed when you
>>>>>> hit Enter. Enter 'call tell' for a description of the features. Go
>>>>>> on - try a few...
>>>>>> Enter 'exit' to end. call bsf.cls Oooops ! ... try again. Execution
>>>>>> error. Unable to load
>>>>>> library "BSF4ooRexx". rc = 98.903 ..................................
>>>>>> rexxtry.rex on
>>>>>> DARWIN exit
>>>>>> *rony@ronymac2014 ~ % rexx -e "call bsf.cls"****919 *-* ::routine
>>>>>> xBSF PUBLIC EXTERNAL
>>>>>> "LIBRARY BSF4ooRexx BSF "****1 *-* call bsf.cls****Error 98 running
>>>>>> /usr/local/bin/BSF.CLS line 919: Execution error.****Error 98.903:
>>>>>> Unable to load library
>>>>>> "BSF4ooRexx".*
>>>>>> rony@ronymac2014 ~ %
>>>>>>
>>>>>> It is the first of five external "LIBRARY BSF4ooRexx XXX" directives
>>>>>> (these five external
>>>>>> function names are: "BSF", "BsfCreateRexxProxy", "BsfRexxProxy",
>>>>>> "BsfUninit4JavaBean",
>>>>>> "BsfLoadJava"). So it is the first time the "BSF4ooRexx" library needs
>>>>>> to be proecessed by
>>>>>> ooRexx in this way.
>>>>>>
>>>>>> This was tested against the Sourceforge version of ooRexx r12280, July
>>>>>> 12 2021.
>>>>>>
>>>>>> Is there anything I could do to help pinpoint the problem?
>>>>>>
>>>>>> ---
>>>>>>
>> _____________________
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
