× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 04-Jan-2012 15:28 , CRPence wrote:
<<SNIP>> If for example the job had a break message handler event
active which responded with ENDRQS upon receipt of a message, then
the DLYJOB would be interrupted; but so too would the active program
[as controlled by the defined\registered invocation exit]. If the
DLYJOB were implemented in its own stack entry, the processing would
probably be easiest; the call to the program doing the DLYJOB could
signal an exception that is monitored by the caller. <<SNIP>>

Hmmm... After a re-read, the above text seems somewhat deceptive for the capability generally available using End Request. A new call stack entry is probably moot, because all of the stack entries would terminate down to the request processor [that is monitoring for the CPF1907].

Reviewing the code in which I had incorrectly recalled that I had actually implemented an EndRqs via a break message handling program, I verified that instead, the code was implemented to send an exception\escape message from the Break Handling exit program to the CLP doing the DLYJOB. That messaging was the means by which the receiving program was informed, and thus decided how to react, via global and\or command-specific MONMSG; i.e. the CLP had not been shut down by End Request processing as alluded might be done in the quoted text. The program QWCDLYJB as the CPP for DLYJOB would terminate early as the effect of the exception being signaled to the CLP earlier in the stack.

So... the code actually terminates the DLYJOB upon request, via a message to a queue setup in break mode to a break msg program, irrespective the time remaining for the wait-time interval.

<code>

monmsg cpf9898 exec(*N) /* Ignored [except on DLYJOB] */
mainline: /* Application program: AppPgmName */
chgmsgq AppMsgq dlvry(*break) pgm(AppBrkMsg) sev(0)
chgjob brkmsg(*normal) /* "*hold" prevents brkmsgpgm too */
...
dlyjob 600
monmsg cpf9898 exec(do) /* specific reaction to msg or: */
... /* No-Op or (global no-op + no MONMSG), ends DLYJOB */
enddo
...

</code>

<code>

pgm (&mqnm &mqlb &msgk) /* Break Handling pgm: AppBrkMsg */
dcl &mqnm *char 10
dcl &mqlb *char 10
dcl &msgk *char 4
rcvmsg msgq(nada) msgkey(&msgk) rmv(*yes) /* msgdta(&msgdta) */
sndpgmmsg msgid(cpf9898) msgf(qcpfmsg) topgmq(*same (AppPgmName)) +
tomsgq(*topgmq) msgtype(*escape) msgdta('Interruption' /* or &msgdta */)

</code>

In the above code snippets... A message sent to the external message queue [*MSGQ] object named AppMsgq would cause the AppPgmName [highest in the stack] to receive an escape message CPF9898 from the AppBrkMsg break handling program. The message text [e.g. first level text for impromptu messages] or the message data [¿best defined as Message data fields formats per FMT() on an ADDMSGD?] could be retrieved by the Break Handler program and then passed to the application program, if something specific needed to be communicated.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.