Spawn to call a TSO command..
Itschak Mugzach
I am trying to call a TSO command from Spawn. The Rexx exec starts under
native TSO and calls Unix Spawn to call a TSO command. Syscall returns zero
rc, but does nothing (so I think). Here is a sample of what I am trying to
do:
/* Rexx */
Cmd.0 = 1
Cmd.1 = "TSO RECEIVE" /* I placed a message with Xmit and whant receive
to prompt */
"execio 0 diskR STDIN (Open" /* DD preallocated, trying to communicate with
RECEIVE */
"ExecIO 0 DISKW (Open"
Fmap.0 = '0' /* STDIN */
Fmap.1 = '1' /* STDOUT */
Fmap.2 = '2' /* err */
UnixStat = Syscalls('ON') /* make syscall active */
Address SYSCALL 'Spawn / 10 fmap. Cmd. __Environment.'
Say RC
RC is allways zero, but I don't get a prompt from RECEIVE as expected. Any
idea what I am doing wrong?
ITSchak
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
James Campbell
you are using TSO Session Manager (which has its own hook in the TPUT
SVC) you cannot intercept the response.
James Campbell
Paul Gilmartin
You need then to check RETVAL (-1 indicates error), ERRNO,
and ERRNOJR to diagnose any error.
You use '/' as the pathname for the command. This should cause
an error.
You supply 10 as fd_count, but only 3 entries in fd_map. I'd
be more comfortable if these agreed.
At some point you should do SYSCALL wait (or waitpid) to
check completion of the command.
James Campbell has pointed out the design shortcomings of RECEIVE.
I've never got RECEIVE to work from a Unix command.
Why are you using SYSCALL spawn rather than simply
"address TSO 'RECEIVE'"?
-- gil
Itschak Mugzach
I am using Spawn in order to create a subtask. My intent is to run several
subtasks under the main program in REXX and to swap between with an hot key.
STDIN & STDOUT are pointing to the terminal (DA(*)). I double checked this.
Receive is just an example of a program that communicate in TPUT/TGET which
is what I am trying to get: TSO commands running concurrent.
Itschak
Jeremy Nicoll - LStsrx
> My understanding is that RECEIVE uses a TPUT to write its prompt. Unless
> you are using TSO Session Manager (which has its own hook in the TPUT
> SVC) you cannot intercept the response.
I looked at an exec I wrote a long time ago which ran a loop to receive a
set of files. The guts of the exec contained:
/* Queue commands for RECEIVE which, if any data is waiting, will */
/* cause it to be received to a new dataset named as above. Issue */
/* RECEIVE command while trapping the entire command dialog text. */
rst#parms = "SHR SPACE(5 5) TRACKS RELEASE SYSOUT(*)"
rcv#parms = "USER("txuserid") NODISPLAY NONAMES"
wst = PROMPT('ON')
QUEUE "RESTORE DSN('" || nextdsn || "')" rst#parms
QUEUE "END"
QUEUE "" /* null line marks end of command queue */
wst = OUTTRAP('RECV.','*','NOCONCAT')
"RECEIVE LOGDSNAME('"rlogdsn"')" rcv#parms
wst = OUTTRAP('OFF')
DELSTACK
wst = PROMPT('OFF')
which might form a useful basis for experimentation.
I cannot remember whether was used in a batch tso step or from a logged-on
user; what's certain is it had nothing to do with Unix, because it predates
that.
--
Jeremy C B Nicoll - my opinions are my own.
Itschak Mugzach
Thanks for the code, but the problem is not to communicate with receive, but
force it to direct its input & output to the terminal.
ITschak
Paul Gilmartin
>
> Thanks for the code, but the problem is not to communicate with
> receive, but
> force it to direct its input & output to the terminal.
>
go to SYSTSPRT, and the prompts are answered in SYSTSIN.
Is this information helpful to you?
-- gil
Jeremy Nicoll - LStsrx
> Hi James,
I'm not James...
> Thanks for the code, but the problem is not to communicate with receive,
> but force it to direct its input & output to the terminal.
The code I posted traps the output from receive in a stem array. The rexx
exec could 'say' that to the terminal if there's any need.
Rather than providing all the required responses for a receive to process a
file (as I did) I think it's possible to provide a response which collects
info for whatever file is waiting to be received and then not do it - ie
model what would happen if a user typed in 'receive' and got info and
decided not to do it at that time.
This is why I said the code was a basis for experimentation, rather than a
solution.
Jeremy Nicoll - LStsrx
> Thanks for the response.
>
> I am using Spawn in order to create a subtask. My intent is to run several
> subtasks under the main program in REXX and to swap between with an hot
> key. STDIN & STDOUT are pointing to the terminal (DA(*)). I double checked
> this.
>
> Receive is just an example of a program that communicate in TPUT/TGET
> which is what I am trying to get: TSO commands running concurrent.
You'd better be careful with processing not intended to be run in parallel.
I also wonder if attaching a subtask mightn't be better than spawn (or is
that what it does internally in TSO)?
You probably don't mean running several receives at the same time? But if
you do, how do you plan to stop them each trying to process the same
incoming file? Remember the files are queued under JES, and any use of
receive just tackles them in turn. If two tasks attempt the same thing I'd
expect them both to start at the top of the list of waiting files.
--
Jeremy C B Nicoll - my opinions are my own.
----------------------------------------------------------------------
Paul Gilmartin
> Itschak Mugzach <imug...@GMAIL.COM> wrote:
>>
>> I am using Spawn in order to create a subtask. My intent is to run
>> several
>> subtasks under the main program in REXX and to swap between with
>> an hot
>> key. STDIN & STDOUT are pointing to the terminal (DA(*)). I double
>> checked
>> this.
>>
>> Receive is just an example of a program that communicate in TPUT/TGET
>> which is what I am trying to get: TSO commands running concurrent.
>
> You'd better be careful with processing not intended to be run in
> parallel.
> I also wonder if attaching a subtask mightn't be better than spawn
> (or is
> that what it does internally in TSO)?
>
spawn doesn't use ATTACH. It submits a BPXAS job (if needed) to run
the command in a separate address space, providing excellent
isolation for processing not normally intended to run in parallel.
> You probably don't mean running several receives at the same time?
> But if
> you do, how do you plan to stop them each trying to process the same
> incoming file? Remember the files are queued under JES, and any
> use of
> receive just tackles them in turn. If two tasks attempt the same
> thing I'd
> expect them both to start at the top of the list of waiting files.
>
Use INDSNAME/INFILE.
But can the output from TPUT be trapped?
--gil
Itschak Mugzach
Receive is only my way to check the possibility of running TSO command the
communicate with the terminal user via Tget/TPUT in parralel with other
programs. It will NOT run in the future under this programs, but other tso
commands like RMF (in one task, not with ISPF interface) and, for example,
Control-M user interface on other subtask.
ITschak