Why not use the EVENTS macro to handle the list of ECBs?  I think that it
provides the same functionality, perhaps in a slightly different form.

Kind Regards

John R Dravnieks


From:   "Blaicher, Christopher Y." <[email protected]>
To:     [email protected],
Date:   27/11/2013 00:49
Subject:        Re: MultiTasking question
Sent by:        IBM Mainframe Assembler List <[email protected]>



There was a macro that came with BTAM called TWAIT that provided an index
to the ECB that was posted.  You can then use that to do an indexed branch.

&NAME    TWAIT &RREG,&ECBLIST=
**********************************************************************
*  THIS MACRO IS FROM THE BTAM ACCESS METHOD.  IT WAITS FOR 1 ECB    *
*  TO BE POSTED.                                                     *
*                                                                    *
*    &RREG - ON EXIT HAS THE ADDRESS OF THE POSTED ECB               *
*            CANNOT BE R13, R14, R15, R0, R1                         *
*                                                                    *
*    &ECBLIST - ADDRESS OF ECB LIST TO WAIT ON                       *
*                                                                    *
*  ON EXIT:                                                          *
*    &RREG - ADDRESS OF THE POSTED ECB                               *
*    R15   - OFFSET IN ECB LIST TO THE ECB (0,4,8,...,N*4)           *
*            TO CONVERT TO INDEX (0,1,2,...,N) DO THE FOLLOWING:     *
*             SRL   R15,2                                            *
*                                                                    *
**********************************************************************

I don't know if it is still distributed in any DLIB anymore.  It was in the
MVS 3.8 release, so you can get it from there, I assume.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: [email protected]


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of Sam Siegel
Sent: Tuesday, November 26, 2013 11:15 AM
To: MVS List Server 2
Subject: Re: MultiTasking question

On Tue, Nov 26, 2013 at 6:57 AM, [email protected] <[email protected]> wrote:

> > Then it will probably also need to be passed a flag which can be
> > tested
> to
> > see if it is time to shutdown or continue processing.
> >
> > The main task can post the shutdown flag at the appropriate time.
Once
> > shutdown its posted, the subtask winds up its processing, posts the
> > completion ECB and exits.
>
>
>
> Why not use a WAIT LISt with 2 ECBS being waited on 1ECB is used to
> process work 2ECB is used to QUIESCE or Shutdown
>

I agree this is a good way to proceed also.


>
>
>
>
> ---------- Original Message ----------
> From: Scott Ford <[email protected]>
> To: [email protected]
> Subject: Re: MultiTasking question
> Date: Mon, 25 Nov 2013 17:44:38 -0500
>
> Yes sir exactly ...
>
> Scott ford
> www.identityforge.com
> from my IPAD
>
> 'Infinite wisdom through infinite means'
>
>
> > On Nov 25, 2013, at 5:37 PM, Sam Siegel <[email protected]> wrote:
> >
> > Then it will probably also need to be passed a flag which can be tested
> to
> > see if it is time to shutdown or continue processing.
> >
> > The main task can post the shutdown flag at the appropriate time.
Once
> > shutdown its posted, the subtask winds up its processing, posts the
> > completion ECB and exits.
> >
> > Sam
> >> On Nov 25, 2013 2:26 PM, "Scott Ford" <[email protected]> wrote:
> >>
> >> Sam,
> >>
> >> More or less ...it will be passed a socket-description..it will do the
> >> rest, so essentially we will listen on two ports ..one will direct
> inbound
> >> requests to RACF via RACF API. Second port will do the other functions
> ...
> >>
> >> Scott ford
> >> www.identityforge.com
> >> from my IPAD
> >>
> >> 'Infinite wisdom through infinite means'
> >>
> >>
> >>> On Nov 25, 2013, at 5:13 PM, Sam Siegel <[email protected]> wrote:
> >>>
> >>> Scott.   That sample code might be overly complex for what you need.
> >>>
> >>> Is the new sub-task attached from your true mainline?   Or from
another
> >>> sub-task?
> >>>
> >>> Does the sub-task need to handle some type of shutdown signal from
the
> >>> attachor?  Or can it be forcibly detached without consequences?
> >>>
> >>> Sam
> >>>> On Nov 25, 2013 2:06 PM, "Scott Ford" <[email protected]>
wrote:
> >>>>
> >>>> Sam,
> >>>>
> >>>> We are thinking about modifying our original design...we need one
> >>>> additional subtask to handle racf commands and password requests so,
I
> >> am
> >>>> trying to figure out how to retrofit our cobol code with assembler
> >> changes
> >>>> so I can multitask ...I am looking over your example you sent me
> >> sometime
> >>>> ago ...between crazy customer requests .....
> >>>>
> >>>> Scott ford
> >>>> www.identityforge.com
> >>>> from my IPAD
> >>>>
> >>>> 'Infinite wisdom through infinite means'
> >>>>
> >>>>
> >>>>> On Nov 25, 2013, at 4:35 PM, Sam Siegel <[email protected]> wrote:
> >>>>>
> >>>>> Scott - Yes ... at the high-level this seems correct.
> >>>>>
> >>>>> I'm assuming that the mainline will be doing other work while the
> >>>> sub-task
> >>>>> is running.
> >>>>>
> >>>>> If the task which attaches the sub-task abends, the sub-task will
> also
> >> be
> >>>>> abended by z/OS.  So you will probably need to consider how the
> >> sub-task
> >>>>> handles unexpected abend conditions in addition to handling
> >>>>> abends/return-codes related to the tcp processing.
> >>>>>
> >>>>>
> >>>>>> On Mon, Nov 25, 2013 at 12:29 PM, Scott Ford <
> [email protected]>
> >>>> wrote:
> >>>>>>
> >>>>>> Guys and gals,
> >>>>>>
> >>>>>> I have a mainline that attaches a subtask via an ATTACH macro, the
> >>>> subtask
> >>>>>> will do Some TCPIP work, all self contained, my question is the
> >>>> structure,
> >>>>>> i.e.;
> >>>>>>
> >>>>>> Mainline --> attach .......do work and post
> >>>>>> Check post ..detach?
> >>>>>>
> >>>>>> Is my thinking correct ?
> >>>>>>
> >>>>>>
> >>>>>> Scott ford
> >>>>>> www.identityforge.com
> >>>>>> from my IPAD
> >>>>>>
> >>>>>> 'Infinite wisdom through infinite means'
> >>>>>>
> >>>>
> >>
>

Reply via email to