Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Rexx ATTACH TCB tree

54 views
Skip to first unread message

Itschak Mugzach

unread,
Oct 27, 2009, 8:29:09 AM10/27/09
to
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?

Itschak

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

Paul Gilmartin

unread,
Oct 27, 2009, 9:04:10 AM10/27/09
to
On Oct 27, 2009, at 06:28, Itschak Mugzach wrote:

> 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

Itschak Mugzach

unread,
Oct 27, 2009, 9:31:33 AM10/27/09
to
Paul,

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

Paul Gilmartin

unread,
Oct 27, 2009, 9:44:21 AM10/27/09
to
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:
>>>

Itschak Mugzach

unread,
Oct 28, 2009, 3:20:39 AM10/28/09
to
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

Binyamin Dissen

unread,
Oct 28, 2009, 7:28:19 AM10/28/09
to
On Wed, 28 Oct 2009 09:20:34 +0200 Itschak Mugzach <imug...@GMAIL.COM> wrote:

:>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.

Itschak Mugzach

unread,
Oct 28, 2009, 7:33:48 AM10/28/09
to
Thanks Binyamin,

I hope the developer of the tso based products does that...

Regards,

ITschak

Robert Zenuk

unread,
Oct 28, 2009, 8:50:59 AM10/28/09
to
While this suggestion is ISPF specific, does the &ZSCREENI variable help?

/* 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 Mugzach

unread,
Oct 28, 2009, 10:13:31 AM10/28/09
to
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.

ITschak

Paul Gilmartin

unread,
Oct 28, 2009, 10:43:40 AM10/28/09
to
On Oct 28, 2009, at 08:12, Itschak Mugzach wrote:

> 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 Mugzach

unread,
Oct 28, 2009, 10:56:28 AM10/28/09
to
That is true, but under TSO you can't navigate between sub-tasks... It might
be NAT in one task and listcat output in another task (for example).

ITschak

0 new messages