RE: Cancelling a program in a program stack

Well that was the plan B I was talking about, I needed to know whether
your "server" program had a PSSR or not otherwise it would collapse. Now
you could be even more elegant by getting the invocation level of your
server program and issuing and ENDRQS to this level from your break
handling program.   

> -----Original Message-----
> From: Bob Luebbe [SMTP:bluebbe@conn2000.com]
> Sent: Thursday, April 15, 1999 4:47 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Cancelling a program in a program stack
> 
> Someone helped us figure it out.
> 
> Here is the answer:
> 
>    1) Create a message queue(using CRTMSGQ)  for the server
> application-(you
> should only have to do this step once),
>    2) In the Init routine of the server app, issue a call to QCMDEXC
> to
> allocate the message queue that was created in #1 above exclusively,
>    3) Next, issue another call to QCMDEXC to assign a break handling
> program
> to the message queue created in #1 above,
>    4) In the break handling program, use the sndpgmmsg (or the
> QMHSNDPM
> message api) to send an *escape message(with your unique id or at
> least
> unique message text, if using CPF9898 or CPF9897--so you can
> distinguish it
> from others) to your server program,
>    5) To stop the program, you need to issue a SNDMSG (or a call to
> QMHSNDM)
> to the
> message queue created in #1 to invoke the break handling program and
> interrupt the job.
> 
> Since the system will interrupt the current jobstream (that has
> exclusively
> allocated the message queue in #1) and transfer control to the break
> handling program; and since the break handling program is higher(or
> deeper)
> in the program stack than the system api generating the list of
> physical
> file names; the execution of the sndpgmmsg in #4 will cause the
> program
> stack to collapse back to the call instruction to the system api in
> the
> server program, at which point you would need to trap the exception on
> the
> call to the system api (analyzing the program exception status DS to
> ensure
> that your exception message caused the exception) or allow the
> exception to
> be thrown to a *PSSR routine where a similar process of analyzing the
> status
> DS would need to be instituted.
> 
> 
> ----- Original Message -----
> From: Tim McCarthy <TimM@softwarejungle.com>
> To: <MIDRANGE-L@midrange.com>
> Sent: Thursday, April 15, 1999 2:28 PM
> Subject: RE: Cancelling a program in a program stack
> 
> 
> > No. SNDPGMMSG will only send to invocations in the current stack.
> > STRSRVJOB doesn't (at least last time I looked) give you that kind
> of
> > control over the serviced job.
> >
> >
> > > -----Original Message-----
> > > From: Henrik Krebs [SMTP:hkrebs@hkrebs.dk]
> > > Sent: Wednesday, April 14, 1999 5:06 PM
> > > To: MIDRANGE-L@midrange.com
> > > Subject: Sv: Cancelling a program in a program stack
> > >
> > > Is this quite true?
> > >
> > > Can't STRSRVJOB or such do a SNDPGMMSG *ESCAPE to pgmq 3?
> > >
> > > ----------
> > > > Fra: James W Kilgore <email@james-w-kilgore.com>
> > > > Til: MIDRANGE-L@midrange.com
> > > > Emne: Re: Cancelling a program in a program stack
> > > > Dato: 14. april 1999 17:01
> > > >
> > > > Bob,
> > > >
> > > > AFAIK, the only way is to design into the applications a
> mechanism
> > > for
> > > > external influence, like a data queue.
> > > >
> > > >
> > > >
> > > > Bob Luebbe wrote:
> > > > >
> > > > > Is there a way, for instance from JobA,  to cancel a program
> in
> > > the
> > > stack of
> > > > > JobB, without actually ending JobB.
> > > > >
> > > > > For instance, JobB has the following program stack:
> > > > >   Program1
> > > > >   Program2
> > > > >   Program3
> > > > >
> > > > > Is it possible for JobA to only cancel Program3 in JobB and
> return
> > > control
> > > > > to Program2.
> > > > >
> > > > >
> > > > +---
> > > > | This is the Midrange System Mailing List!
> > > > | To submit a new message, send your mail to
> > > MIDRANGE-L@midrange.com.
> > > > | To subscribe to this list send email to
> > > MIDRANGE-L-SUB@midrange.com.
> > > > | To unsubscribe from this list send email to
> > > MIDRANGE-L-UNSUB@midrange.com.
> > > > | Questions should be directed to the list owner/operator:
> > > david@midrange.com
> > > > +---
> > > +---
> > > | This is the Midrange System Mailing List!
> > > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > > | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> > > MIDRANGE-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list owner/operator:
> > > david@midrange.com
> > > +---
> > +---
> > | This is the Midrange System Mailing List!
> > | To submit a new message, send your mail to
> MIDRANGE-L@midrange.com.
> > | To subscribe to this list send email to
> MIDRANGE-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
> >
> 
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---