Itschak
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
> I am collecting information about REXX ATTACH. Does it work like
> MVS ATTACH?
> My idea is to write a Rexx program that will display a menu. Each
> selection
> from the dialog will start a subtask using Rexx attachpgm. If the
> user hits
> a hot key, let say, PF01, the mother task will get control without
> stopping
> the child task. Is this possible to do with Rexx Attach cmd?
>
I believe that all of the subcommand environments ATTACH/ATTCHPGM/
ATTCHMVS
issue MVS ATTACH then, disappointingly, WAIT for the child to complete
then DETACH it before returning to the Rexx program.
-- gil
If it works this way, it is really disappointing. I hope it not :-( The
solution must be inexpensive, so I don't want to code assembler there at
all.
ITschak
If you need concurrency, you might consider "address SYSCALL spawn".
I considered writing an assembler interface to the ATTACH SVC,
but the stumbling block is that I have no assurance that Rexx
won't relocate the argument variables before the child accesses
them. Does anyone know the details of Rexx storage management?
> On Tue, Oct 27, 2009 at 3:03 PM, Paul Gilmartin
> <PaulGB...@aim.com>wrote:
>>>
ITschak
:>Let's say I solved the task switching problem, I still have to save &
:>restore the screen image. Any idea how to "read" & "write" the screen image
:>including the attribute characters?
Under TSO a program should be ready to refresh itself from an out-of-line
message. Typical way is via PA2.
:>On Tue, Oct 27, 2009 at 3:43 PM, Paul Gilmartin <PaulGB...@aim.com>wrote:
:>> On Oct 27, 2009, at 07:31, Itschak Mugzach wrote:
:>>> If it works this way, it is really disappointing. I hope it not :-
:>>> ( The
:>>> solution must be inexpensive, so I don't want to code assembler
:>>> there at
:>>> all.
:>>> The designers failed to grasp the concept of ATTACH.
:>> If you need concurrency, you might consider "address SYSCALL spawn".
:>> I considered writing an assembler interface to the ATTACH SVC,
:>> but the stumbling block is that I have no assurance that Rexx
:>> won't relocate the argument variables before the child accesses
:>> them. Does anyone know the details of Rexx storage management?
:>> On Tue, Oct 27, 2009 at 3:03 PM, Paul Gilmartin
:>>> <PaulGB...@aim.com>wrote:
:>>>>> I believe that all of the subcommand environments ATTACH/ATTCHPGM/
:>>>>> ATTCHMVS
:>>>> issue MVS ATTACH then, disappointingly, WAIT for the child to
:>>>> complete
:>>>> then DETACH it before returning to the Rexx program.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
I hope the developer of the tso based products does that...
Regards,
ITschak
/* rexx */
address ISPEXEC "VGET (ZSCREENI)"
say zscreeni
Rob
In a message dated 10/28/2009 12:20:39 A.M. US Mountain Standard Tim,
imug...@GMAIL.COM writes:
Let's say I solved the task switching problem, I still have to save &
restore the screen image. Any idea how to "read" & "write" the screen
image
including the attribute characters?
ITschak
On Tue, Oct 27, 2009 at 3:43 PM, Paul Gilmartin
<PaulGB...@aim.com>wrote:
> On Oct 27, 2009, at 07:31, Itschak Mugzach wrote:
>
>>
>> If it works this way, it is really disappointing. I hope it not :-
>> ( The
>> solution must be inexpensive, so I don't want to code assembler
>> there at
>> all.
>>
>> The designers failed to grasp the concept of ATTACH.
>
> If you need concurrency, you might consider "address SYSCALL spawn".
>
> I considered writing an assembler interface to the ATTACH SVC,
> but the stumbling block is that I have no assurance that Rexx
> won't relocate the argument variables before the child accesses
> them. Does anyone know the details of Rexx storage management?
>
> On Tue, Oct 27, 2009 at 3:03 PM, Paul Gilmartin
>> <PaulGB...@aim.com>wrote:
>>
>>>
>>>> I believe that all of the subcommand environments ATTACH/ATTCHPGM/
>>>> ATTCHMVS
>>>>
>>> issue MVS ATTACH then, disappointingly, WAIT for the child to
>>> complete
>>> then DETACH it before returning to the Rexx program.
>>>
>>
> -- gil
ITschak
> Rob, not really. The problem I am trying to solve (Multi-session under
> single TSO seesion) is not a problem under TSO, as it support
> spliting the
> screen into logical screens.
>
Doesn't TSO (and under it ISPF) adamantly resist concurrent
processing of TSO commands? (Regardless, a TSO session may
CALL a single program which itself ATTACHes multiple concurrent
children.)
ITschak