> 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

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

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

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

>> 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
>> <PaulGBoul...@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

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

> :>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 <PaulGBoul...@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
> :>>> <PaulGBoul...@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 <bdis...@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.

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

>> 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
>>  <PaulGBoul...@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

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

> /* rexx */
> address ISPEXEC "VGET (ZSCREENI)"
> say zscreeni

> Rob

> In a message dated 10/28/2009 12:20:39 A.M. US Mountain Standard Tim,
> imugz...@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
> <PaulGBoul...@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
> >>  <PaulGBoul...@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

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

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

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

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

> -- gil

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