×
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 08-Sep-2011 11:36 , Dennis wrote:
I know this post was in jest, but for the record: that won't end a
job that has an active monitor for MCH* messages.
"Musselman, Paul"<pmusselman@xxxxxxxxxxxxxxxx> wrote:
Won't the "DLTPGM" command end a running job as well? (:
FWiW...
A "call" or "transfer control" to a program that has previously been
deleted would effect an error condition that can be monitored. Though
depending on the mechanism for the call request, not necessarily
manifest to the caller as a message in thee MCH0000 range.
However AFaIK any "return" to a previous invocation in the call stack
which is to a non-existent program is not a condition that can be
monitored. In my experience, for that scenario the job ends with a
function check VLog, manifest to the *EXT program message queue as
CPC1220, even though MCH3203 is the diagnosed error code. Of course the
job could possibly continue running fine up until that return
instruction. In the lab I used to take advantage of that effect to
resolve various "loop" scenarios that others would insist required a
pwddwn\IPL to recover.
Regards, Chuck
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.
midrange.com
