Hi Andrew,
On 23.06.2022 01:42, Andrew Rowley wrote:
On 22/06/2022 9:44 pm, Rony G. Flatscher wrote:
/* ... do whatever you need to do, if anything ... */
/* now wait until the stop event gets received in rexxCallBack */
rexxCallBack~waitForStop /* invocation will block */
I don't know ooRexx so I'm working mainly from your comments, but the sample I wrote doesn't do
something then block waiting for the stop command. It does something (sleep) continually, checking
regularly to see if the stop command has been received.
Of course, in a real program sleep would be replaced with the actual function
you wanted to perform.
Ah, I see what you meant!
This is a simple example, there are also more complex ways of interrupting/stopping a thread in
Java than periodically checking a status.
Sure.
Maybe a few comments what I intended to show followed by an ooRexx version below that does also a
loop with sleep to match your Java sample conceptually in all aspects.
ooRexx is a language that is multithreaded and makes it easy to kick off (and synchronize) threads
if need be. I remember one American software engineer who ran a business creating software
simulations for robotics about 25 years ago who used OS/2 Warp and its contained Object REXX (IBM's
product which later turned into today's ooRexx) for that purpose back then; he told me at an
International RexxLA symposium that the reason for him using Object REXX was an experiment he
undertook to create a simple simulation of an airport where planes would be landing, taking off and
taxiing, and all would take him only about 120 lines of code.
By default ooRexx supports inter-object multithreading and intra-object multithreading. In addition
it allows for fine grained control of multithreading with the GUARD ON/OFF [WHEN test of control
variable[s]] keyword statement.
In this transcription of your Java program I tried to demonstrate synchronizing the Java thread that
reports the command events with the main (ooRexx) thread. ooRexx will stop (block) in the main
thread at the statement
rexxCallBack~waitForStop
until the method handleStop() gets invoked on the MvsCommandCallback thread which will cause
waitForStop to gain control and return to allow the main thread to continue (which in this case ends
the program and thereby Java). One could have any number of commands before and after that
particular synchronization point.
---
As your intention was to use a loop to execute code in intervals repeatedly until the
MvsCommandCallback reports the handleStop() event by invoking that event method which sets the
'stopped' attribute to .true/1, here a version that uses such a loop in the main (ooRexx) thread
which executes as long as the MvsCommandCallback event method handleStop was not invoked (which will
set the value of the attribute 'stopped' to .true) on the MvsCommandCallback (Java) thread.
Here the (untested) ooRexx program:
/* load the Java class into ooRexx, it will understand ooRexx messages */
MvsConsole = bsf.loadClass("com.ibm.jzos.MvsConsole")
if \MvsConsole~isListening then /* if not yet a command listener
thread */
MvsConsole~startMvsCommandListener
rexxCallBack = .CommandCallback~new /* create a Rexx value of type
"CommandCallback" */
/* wrap/box the Rexx value/object as a Java value/object */
boxedCallBack = BsfCreateRexxProxy(rexxCallBack, ,
"com.ibm.jzos.MvsCommandCallback")
MvsConsole~registerMvsCommandCallback(boxedCallBack)
/* now loop until the stop event gets received in rexxCallBack */
do while \rexxCallBack~stopped
call sysSleep 1 /* sleep a second or do something else */
end
::requires "BSF.CLS" /* get ooRexx-Java bridge */
/* ooRexx class defines the Java methods it will serve. Invoking these
Java methods will cause a message of the same name and same arguments
to be sent to the ooRexx value/object which will search and invoke
the appropriate ooRexx method here. */
::class CommandCallback /* implements MvsCommandCallback methods */
::method init /* runs when a value of this type gets created */
expose startTime stopped /* access object variables (attributes)*/
startTime=.DateTime~new /* remember current date and time */
stopped = .false /* set attribute to 0 */
::method handleModify
expose startTime /* access object variable (attribute) */
use arg arg0
if arg0="REPORT" then
say "Runtime:" .dateTime~new - startTime /* deduct current date and
time */
else
say arg0 "not recognized. Valid commands: REPORT"
::method handleStart /* do nothing */
::method handleStop
expose stopped /* access object variable (attribute) */
stopped = .true /* set attribute to 1 */
return .false /* return 0 */
::attribute stopped get /* allow getting the attribute's value */
A remark to this solution: the Rexx class (type, structure) makes the attribute "stopped" available
to others using the attribute directive with the "get" option (such that the attribute's value can
be read but not changed by others). One just needs to send the name of the attribute ("stopped") to
the Rexx object (value, instance) which will answer with its current value, which is done to control
the loop in the main thread.
A last remark: if you have access to a Linux subsystem you should actually be able to run the above
ooRexx program as there is a s390x port available for download at
<https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0beta/> and BSF4ooRexx (the ooRexx-Java
bridge) at <https://sourceforge.net/projects/bsf4oorexx/files/GA/BSF4ooRexx-641.20220131-GA/> which
includes a s390x port of its JNI part as well which should get picked when installed after unzipping
the archive.
HTH,
---rony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
