Multi-threaded REXX
Evans, James R. , RET-DAY
I'm working on a REXX based project which would benefit from
multi-threading. Here's my need. I want to have a control routine
(written in REXX) invoke another REXX routine which would run as a
subtask. It is important that the control routine not lose control
while the called REXX routine is running.
My research into LINK/LINKMVS/LINKPGM and ATTACH/ATTACHMVS/ATTACHPGM
interfaces doesn't show me the separate thread ability I had hoped to
get. In fact, I guess I don't really see a difference between the LINK
and ATTACH family of interfaces. Perhaps I just don't understand
multi-threaded code, but the documentation does a poor job of
differentiating those interface families.
I've also seen references on the web to MTREXX. Unfortunately, I'm
working in a TSO/MVS Batch environment so I don't believe MTREXX will
help me. Due to the time line for this project, I'm not free to develop
my own custom assembler routine to achieve the multi-threading.
Have I misunderstood the documentation?? Is there a canned solution
which would help here??
All suggestions welcome.
TIA
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
>
> I'm working on a REXX based project which would benefit from
> multi-threading. Here's my need. I want to have a control routine
> (written in REXX) invoke another REXX routine which would run as a
> subtask. It is important that the control routine not lose control
> while the called REXX routine is running.
>
> My research into LINK/LINKMVS/LINKPGM and ATTACH/ATTACHMVS/ATTACHPGM
> interfaces doesn't show me the separate thread ability I had hoped to
> get. In fact, I guess I don't really see a difference between the
> LINK
> and ATTACH family of interfaces. Perhaps I just don't understand
> multi-threaded code, but the documentation does a poor job of
> differentiating those interface families.
>
> I've also seen references on the web to MTREXX. Unfortunately, I'm
> working in a TSO/MVS Batch environment so I don't believe MTREXX will
> help me. Due to the time line for this project, I'm not free to
> develop
> my own custom assembler routine to achieve the multi-threading.
>
> Have I misunderstood the documentation?? Is there a canned solution
> which would help here??
>
I've pondered coding a custom assembler routine for the purpose,
passing an attached task (which might be IRXJCL) arguments in
the format of ATTCHPGM (more general than and a superset of ATTCHMVS).
My concept founders on the following: if the target program is
attached asynchronously, is there a hazard that the argument
blocks would be moved before the target program can access them?
I.e., does Rexx storage management move strings to defragment
storage?
If I did the ATTCHMVS form, I could copy the argument strings to
obtained storage. But then the values couldn't be modified
by the called program (SYS1.SAMPLIB(CSFTEST) uses this technique.)
-- gil
Bill Schoen
much hope.
If that is not necessary, you might look at Address Syscall 'spawn ...'
in the USS Using REXX book. The rexx program that runs as a subtask
must be loaded from the unix file system. The environment variable
BPXSHAREAS controls whether the spawned program will run as a subtask
(YES) or in another address space (NO). For an example of spawn, look
at ishell in sys1.sbpxexec. You can pass arguments and use pipes to
pass data back and forth.
Bill Schoen
adrianstern
>
> > ----------------------------------------------------------------------
> > For TSO-REXX subscribe / signoff / archive access instructions,
>
> ----------------------------------------------------------------------
> For TSO-REXX subscribe / signoff / archive access instructions,
>
> - Show quoted text -
In the past I've "managed" hundreds of sub-tasks by simply submitting
jobs and picking up their output. On one occasion one such monitor
started around 10000 jobs. No problem except that while performing
their tasks the "sub-tasks" couldn't communicate with the mother ship
- but that wasn't a requirement.
Could this be of any help?
Lindy Mayfield
Here is what it does. I run the main Rexx as a batch job (or started task):
//SRVR EXEC PGM=IKJEFT01
//SYSEXEC DD DSN=EURLIM.LINDY.REXX,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
%DAEMON PORT=1964
/*
http://lilliana.eu/downloads/daemon.rexx
When it is running I can telnet into the server:port.
> telnet server.com 1964
If I type help I get a little menu of some test commands. The main Rexx (server) is setup so that I can make multiple TCP/IP telnet connections to it.
If I enter the spawn command it creates a listen port, runs the /u/eurlim/rexx/child.rx and passes it the TCP/IP information to do a givesocket/takesocket. So after the spawn command to the main Rexx, my telnet session is then connected to the child process running in USS and any commands from telnet go to that Rexx exec.
http://lilliana.eu/downloads/child.rx
This isn't exactly what you want to do since all of this example was made to work with telnet connections so that I could interact with it more. But I think all the pieces are there.
/* Lindy */
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Evans, James R. (RET-DAY)
Sent: 10. maaliskuuta 2009 18:43
To: TSO-...@VM.MARIST.EDU
Subject: [TSO-REXX] Multi-threaded REXX
Hello!
I'm working on a REXX based project which would benefit from
multi-threading. Here's my need. I want to have a control routine
(written in REXX) invoke another REXX routine which would run as a
subtask. It is important that the control routine not lose control
while the called REXX routine is running.
----------------------------------------------------------------------
Lindy Mayfield
Lindy
Lindy Mayfield
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bill Schoen
Sent: 11. maaliskuuta 2009 1:34
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Multi-threaded REXX
If you need to share the variable pool or the stack, there may not be
much hope.
If that is not necessary, you might look at Address Syscall 'spawn ...'
in the USS Using REXX book. The rexx program that runs as a subtask
must be loaded from the unix file system. The environment variable
BPXSHAREAS controls whether the spawned program will run as a subtask
(YES) or in another address space (NO). For an example of spawn, look
at ishell in sys1.sbpxexec. You can pass arguments and use pipes to
pass data back and forth.
Bill Schoen
----------------------------------------------------------------------
Horacio Villa
I'm interested in this type of processing, so I tried to download your
samples.
But I haven't found them there.
Cheers,
Horacio
Lindy Mayfield <lindy.m...@SSF.SAS.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
10/03/2009 16:02
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] Multi-threaded REXX
Lindy Mayfield
The server part:
http://lilliana.eu/downloads/daemon.rexx
The other part that does the takesocket:
http://lilliana.eu/downloads/child.rx
Note that this is not at all what the OP asked for. These two things do TCP/IP. I can telnet into the daemon.rexx running and then have it start another process and do a takesocket.
These use Rexx sockets. I'm sure it could be made MUCH better using some of the Rexx and USS calls as Bill suggested.
Lindy
Grant Ward Able
Over the last few days there was a discussion during which someone posted
a link then later posted an amendment, as the first link was going to
expire. I have searched the archives but I cant find this posting. Would
someone please send me a copy?
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.
arlen stovall
http://home.roadrunner.com/~mvsrexx/REXX/
On Thu, Mar 19, 2009 at 12:56 PM, arlen stovall <arlens...@gmail.com>wrote:
> Grant, this is the new link that was posted before.
> --
> Thanks
> Arlen Stovall
>
--
Thanks
Arlen Stovall
arlen stovall
On Thu, Mar 19, 2009 at 12:29 PM, Grant Ward Able <GWar...@dtcc.com>wrote:
--
Thanks
Arlen Stovall
Grant Ward Able
--
Regards - Grant
=====================================
Note: Any opinion expressed is my own
arlen stovall <arlens...@GMAIL.COM>
Sent by: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
03/19/2009 04:56 PM
Please respond to
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject
Re: [TSO-REXX] Looking for link