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