BSF4REXX Eoor when REXX invoked from Java

[regli]

I just installed BSF4REXX. After some struggles with the installation
script, I finally succeeded, at least to a degree.

The command: rexx infoBSF.rex works just fine.

However, invoking REXX from Java seems to present a problem. I get
the following:

D:\Development\Rexx\bsf4rexx>rexxj infoBSF.rex
1 *-* #
Error 13 running a_BSF4Rexx_program line 1: Invalid character in
program
Error 13.1: Incorrect character in program "#" ('23'X)

Exception of type 'org.apache.bsf.BSFException' thrown while invoking
Rexx:
1 *-* #
Error 13 running a_BSF4Rexx_program line 1: Invalid character in
program
Error 13.1: Incorrect character in program "#" ('23'X)

This is using Object Rexx 2.1 (developers edition becuase of
debugging) and:

java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)

Any ideas as to what is happening would be helpful. Thanks a lot.

[rony]

Yes, you are using a backlogged version of Object Rexx which does not honor the hash-bang line

#!/usr/bin/rexx

Either remove that line from infoBSF.rex or replace your outdated Object Rexx with the latest ooRexx
3.2 from <http://www.ooRexx.org>.

HTH,

---rony

[regli]

> ---rony- Hide quoted text -
>
> - Show quoted text -

Thanks rony. I will remove the line.

Until ooRexx supports some kind of interactive debugging, I will stick
with Object Rexx as the development environment. I use ooRexx for
deployment but ease of development is of primary importance to me.

If we want to keep REXX alive and growing then, at some point, we need
an Eclipse integration of ooRexx or Regina.

[regli]

rony,

another question. When bsf.cls gets invoked a second time within the
Object Rexx 2.1.3 workbench while debugging, it consistently fails.
As soon as I leave and reenter it works again the first time and
debugging is allowed.

The message I get on the second time in is as follows:

+++ "WindowsNT COMMAND D:\Development\Rexx\testBSF.rex"
22 *-* call bsf.cls /* get ooRexx support for BSF*/
+++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. ++
+
1373 *-* return bsf.wrap( bsf("loadClass", JavaClassName) )
305 *-* .bsf~bsf.import(arr[i]) -- make these classes accessible
as if they were ooRexx classes
22 *-* call bsf.cls /* get ooRexx support for BSF*/
Error 40 running D:\Development\Rexx\BSF.CLS line 305: Incorrect call
to routine
Error 40.1: External routine "BSF" failed
+++ "WindowsNT COMMAND D:\Development\Rexx\testBSF.rex"
22 *-* call bsf.cls /* get ooRexx support for BSF*/
+++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. ++
+
1373 *-* return bsf.wrap( bsf("loadClass", JavaClassName) )
305 *-* .bsf~bsf.import(arr[i]) -- make these classes accessible
as if they were ooRexx classes
22 *-* call bsf.cls /* get ooRexx support for BSF*/
Error 40 running D:\Development\Rexx\BSF.CLS line 305: Incorrect call
to routine
Error 40.1: External routine "BSF" failed

Is there a reusability issue? Thanks very much for your help.

[rony]

Hi Regli,

> another question. When bsf.cls gets invoked a second time within the
> Object Rexx 2.1.3 workbench while debugging, it consistently fails.
> As soon as I leave and reenter it works again the first time and
> debugging is allowed.

As I do not have the workbench anymore, using "pure" ooRexx 3.20, I cannot test it under that
environment. [You could save the Object Rexx workbench files/dlls, install ooRexx 3.20 and use the
Rexx workbench according to some reports of ooRexx users.]

>
> The message I get on the second time in is as follows:

... cut ...

> Is there a reusability issue? Thanks very much for your help.

Not that I am aware of.

Here's a rexxtry session with ooRexx 3.2.0 on Windows XP:

E:\>rexxtry
REXX-ooRexx_3.2.0(MT) 6.02 5 Dec 2007
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 WindowsNT
say .java.lang.system~getproperty("java.version")
1.6.0_02
........................................... rexxtry.rex on WindowsNT
call bsf.cls
........................................... rexxtry.rex on WindowsNT
say .java.lang.system~getproperty("java.version")
1.6.0_02
........................................... rexxtry.rex on WindowsNT

So invoking "bsf.cls" twice in the same session looks like it works.

Regards,

---rony

[regli]

On May 29, 7:20 am, rony <Rony.Flatsc...@wu-wien.ac.at> wrote:
... cut ...

>
> Not that I am aware of.
>
> Here's a rexxtry session with ooRexx 3.2.0 on Windows XP:
>
>       E:\>rexxtry
>       REXX-ooRexx_3.2.0(MT) 6.02 5 Dec 2007
>         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 WindowsNT
>       say .java.lang.system~getproperty("java.version")
>       1.6.0_02
>         ........................................... rexxtry.rex on WindowsNT
>       call bsf.cls
>         ........................................... rexxtry.rex on WindowsNT
>       say .java.lang.system~getproperty("java.version")
>       1.6.0_02
>         ........................................... rexxtry.rex on WindowsNT
>
> So invoking "bsf.cls" twice in the same session looks like it works.
>

... cut ...

Thanks again for responding so quickly.

I now adapted my debugging environment to ooRexx 3.2 which I had on a
virtual machine. When I ran it, the same thing happened:

+++ "WindowsNT COMMAND D:\Development\Rexx\testBSF.rex"

23 *-* parse source system . programname

+++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. ++
+

>>> "WindowsNT"
>>> "D:\Development\Rexx\testBSF.rex"
24 *-* parse version IPversion
>>> "REXX-ooRexx_3.2.0(MT) 6.02 30 Oct 2007"
26 *-* call bsf.cls /* get ooRexx support for BSF*/

1373 *-* return bsf.wrap( bsf("loadClass", JavaClassName) )
305 *-* .bsf~bsf.import(arr[i]) -- make these classes accessible
as if they were ooRexx classes

26 *-* call bsf.cls /* get ooRexx support for BSF*/

Error 40 running D:\Development\Rexx\BSF.CLS line 305: Incorrect call
to routine
Error 40.1: External routine "BSF" failed

I changed the script to call bsf.cls twice in a row and it worked fine
just like your rexxtry example. However, as soon as I tried to run
the script again in the same debugging session, it failed again in the
first call. It seems to lose the java environment.

Any help would be appreciated.

p.s. I adapted the Rexx 2.1 environment a little differently but much
easier. I simply copied the following ooRexx files into the ORexx
2.1.3 directory after deleting the ORexx folder folder OODIALOG. Also
make sure that the rxapi.exe process is killed first. Under Vista
X64, rxapi cannot run as a service in order for debugging to work.

Here are the files I copied:

oodialogs.cls
OODPLAIN.CLS
OODWIN32.CLS
orexxole.cls
orexxole.dll
orxscrpt.dll
rexx.dll
rexx.exe
rexx.ico
rexx.img
rexxapi.dll
rexxc.exe
rexxhide.exe
rexxpaws.exe
rexxtry.rex
rexxutil.dll
rxapi.exe
rxftp.cls
rxmath.dll
rxmigrate.exe
rxqueue.exe
rxregexp.cls
rxregexp.dll
rxsock.dll
rxsubcom.exe
rxwinsys.dll
winsystm.cls

[rony]

Hi Regli,

> Thanks again for responding so quickly.

You are very welcome!

> I now adapted my debugging environment to ooRexx 3.2 which I had on a
> virtual machine.

Great!

When I ran it, the same thing happened:

:(

... cut ...

> I changed the script to call bsf.cls twice in a row and it worked fine
> just like your rexxtry example.

Great!

However, as soon as I tried to run
> the script again in the same debugging session, it failed again in the
> first call. It seems to lose the java environment.

:(

Hmm, not sure what the reason could be, short of any information about the debugging interface and
how the Workbench takes advantage of it at all!

Maybe someone reading this list and being acquainted with that debugging interface could shed some
light here?

Regards,

---rony

[Steve Swift]

regli wrote:
26 *-* call bsf.cls /* get ooRexx support for BSF*/
> Error 40 running D:\Development\Rexx\BSF.CLS line 305: Incorrect call
> to routine
> Error 40.1: External routine "BSF" failed

That is saying that line 305 in BSF called a function incorrectly [such
as word(string,0)] and you need find what line 305 in BSF.CLS is doing.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

[regli]

rony,

What appears to be happening on the second try, at least at first
blush, is that unloading BSFLOADJAVA is not working.

rc = rxFuncDrop("BSFLOADJAVA")
results in rc = 1, i.e. not loaded OR ???
then

rc = rxFuncQuery("BSFLOADJAVA")
results in rc = 1, i.e. it is still loaded. ???

bsf.cls then thinks that it doesn't have to load. Note that any
subsequent call to "BSFLOADJAVA" fails. Something seems to be wrong
with it evidenced by the fact that it cannot be unloaded.

I hope this helps somewhat.

[rony]

Hi Regli,

> What appears to be happening on the second try, at least at first
> blush, is that unloading BSFLOADJAVA is not working.
>
> rc = rxFuncDrop("BSFLOADJAVA")
> results in rc = 1, i.e. not loaded OR ???

According to the ooRexx docs (p. 432), a success would be indicated by "0".

> then
>
> rc = rxFuncQuery("BSFLOADJAVA")
> results in rc = 1, i.e. it is still loaded. ???

Again, per the docs "1" would indicate that the function "BSFLOADJAVA" is not loaded.

> bsf.cls then thinks that it doesn't have to load. Note that any
> subsequent call to "BSFLOADJAVA" fails. Something seems to be wrong
> with it evidenced by the fact that it cannot be unloaded.
>
> I hope this helps somewhat.

Maybe. It seems that you are explicitly unloading the external function "BSFLOADJAVA"? If so, I
would speculate that in the debug environment that somehow does not work cleanly. Therefore I would
try to remove any statements that attempt to unload Java (that shouldn't be necessary at all at
present) and to unload the external BSF4Rexx Rexx functions.

HTH,

---rony

[regli]

> I hope this helps somewhat.- Hide quoted text -

>
> - Show quoted text -

One more thing that I find very interesting. The following exception
happens right after exit after I unload "BSF" even after the first
try. This seems to point to an issue within BSF. If I don't unload
BSF, everything runs fine.

+++ "WindowsNT COMMAND D:\Development\Rexx\test.REX"
12 *-* trace results

+++ Interactive trace. "Trace Off" to end debug, ENTER to Continue. ++
+

14 *-* parse source system . programname
>>> "WindowsNT"
>>> "D:\Development\Rexx\test.REX"
15 *-* parse version IPversion

>>> "REXX-ooRexx_3.2.0(MT) 6.02 30 Oct 2007"

16 *-* if Arg()>0
>>> "0"
18 *-* else
18 *-* arg_list = ""
>>> ""
27 *-* call bsf.cls
28 *-* rc = rxfuncdrop("BSF")
33 *-* exit 0 /* leave program */

-------------------------------------------------------------------------------------------
UBSF.CLS: SIGL=360 = line # with exception, line: [ call
BsfLoadFuncs -- register all the BSF4Rexx functions ...]
exception: SYNTAX
traceback:
360 *-* call BsfLoadFuncs -- register all the
BSF4Rexx functions ...
-------------------------------------------------------------------------------------------

[regli]

Our posts have overlapped. I actually didn't deliberately unload, I
just got suspicious that something might be wrong there.

What might be happening is that the debugging environment isn't
succeeding in unloading and therefore fails on a subsequent try.
Something along these lines...

[regli]

> Something along these lines...- Hide quoted text -

>
> - Show quoted text -

rony,

sorry to pepper you with all these posts.

I now ran this in a command window with no debugger involved. Is this
of help?

D:\Development\Rexx>rexx test

14 *-* parse source system . programname
>>> "WindowsNT"
>>> "D:\Development\Rexx\test.REX"

15 *-* parse version IPversion

>>> "REXX-ooRexx_3.2.0(MT) 6.02 30 Oct 2007"

16 *-* if Arg()>0
>>> "0"
18 *-* else
18 *-* arg_list = ""
>>> ""
27 *-* call bsf.cls
28 *-* rc = rxfuncdrop("BSF")

>>> "0"

33 *-* exit 0 /* leave program */

>>> "0"
BsfLoadFuncs(): error '30' while registering function 'BsfDropFuncs'
BsfLoadFuncs(): error '30' while registering function 'BsfInvokedBy'
BsfLoadFuncs(): error '30' while registering function 'BsfLoadJava'
BsfLoadFuncs(): error '30' while registering function
'BsfQueryAllFunctions'
BsfLoadFuncs(): error '30' while registering function
'BsfQueryRegisteredFunctions'
BsfLoadFuncs(): error '30' while registering function
'BsfShowErrorMessage'
BsfLoadFuncs(): error '30' while registering function 'BsfUnloadJava'
BsfLoadFuncs(): error '30' while registering function 'BsfVersion'
BsfLoadFuncs(): error '30' while registering function 'BsfAttachToTID'
BsfLoadFuncs(): error '30' while registering function 'BsfGetTID'

[rony]

Hi Regli,

> sorry to pepper you with all these posts.

Nothing to be sorry about.

> I now ran this in a command window with no debugger involved. Is this
> of help?

Hmm, would that be repeatbable, if you shutdown/kill rxapi (otherwise I would assume that indeed
something with the setup/environment is foul due to the debugger).

HTH,

---rony

[rony]

Sorry (just a little bit overworked, will go home), please remove "otherwise" from the brackets above...

---rony

[regli]

I can repeat the command line environment situation any time. It
happens actually completely outside the debugging environment. Here
is the script:

call bsf.cls

rc = rxfuncdrop("BSF")

/*
rc = rxFuncDrop("BsfLoadFuncs")

rc = rxFuncDrop("BSFLOADJAVA")

*/
exit 0

If you run it in your environment, you should encounter the same error
as the debuuger is not involved. It looks like cleanup is not
happening correctly as the trap (signal) occurs after the exit
statement. This is what I believe throws off the debugger as well.

I hope this helps.

[regli]

In my test outside the debugging environment, I did kill rxapi in
between but the results were the same every time. It made no
difference. I do believe the problem lies in BSF cleanup somewhere.

Thanks for all your help and have a great evening.

[rony]

Hi Regli,

> I can repeat the command line environment situation any time.

Indeed!

> It happens actually completely outside the debugging environment. Here
> is the script:

Thank you very much for that!

> If you run it in your environment, you should encounter the same error
> as the debuuger is not involved. It looks like cleanup is not
> happening correctly as the trap (signal) occurs after the exit
> statement. This is what I believe throws off the debugger as well.
>
> I hope this helps.

Hmm, it looks as if it was an ooRexx cleanup error!
(At least I cannot imagine at the moment any scenario where the BSF4Rexx code could be possibly
responsible for such a behaviour. A little bit baffled.)

Maybe you could file a short bug report supplying the code on the ooRexx sourceforge home at
<http://sourceforge.net/tracker/?group_id=119701&atid=684730>?

Regards,

---rony

[regli]

rony,

I did submit the issue at sourceforge. The link is here:

<a href="http://sourceforge.net/tracker/index.php?
func=detail&aid=1978536&group_id=119701&atid=684730">http://
sourceforge.net/tracker/index.php?
func=detail&aid=1978536&group_id=119701&atid=684730</a>

I am certain to have quite few more questions regarding BSF in the
future. Thanks again.

[rony]

Hi Raetus,

> I did submit the issue at sourceforge. The link is here:
>
> <a href="http://sourceforge.net/tracker/index.php?
> func=detail&aid=1978536&group_id=119701&atid=684730">http://
> sourceforge.net/tracker/index.php?
> func=detail&aid=1978536&group_id=119701&atid=684730</a>

Thanks!

> I am certain to have quite few more questions regarding BSF in the
> future. Thanks again.

Anytime!

Regards,

---rony