Now, if I just reach out and DLTPGM the program currently executing in your I think I've just pulled the rug out from under you...
I created a program that sends me a break message, and when I respond to the message it does a DLYJOB 66.
While the job was delaying, I deleted the program. The job was still counting to 66, so nothing happened immediately.
After the delay, the job displayed:
+------------------
End of Job
System: GCC#2
Job: DSP01PEM User: myprofile Number: 986133
Job ended abnormally.
Display the job log for more information.
-------------------------------------+
And promptly ends. The joblog shows:
*NONE Command 09/08/11 17:35:40.113403 QCADRV QSYS 03B8 *N *N *N
Message . . . . : 1200 - DLYJOB DLY(66)
CPC1220 Completion 50 09/08/11 17:36:46.303623 QWTPITP2 QSYS 061B *EXT *N
Message . . . . : Job ended abnormally because of error code MCH3203.
Cause . . . . . : The job was ended by the system because an error was
found, and the job was in a condition where the process default exception
handler (QMHPDEH) could not be given control. The system will not give
control to QMHPDEH when the job is in between the starting phase and the
problem phase, or between the problem phase and the ending phase. Some of
the more common error codes and their meanings follow:
...
MCH3203 - A machine function check occurred. A
possible cause is that the program stack for a routing step was nested too
deeply. This is probably due to repeated calling of the programs. It may
also be caused by deleting a program that is active in the program stack.
...
If MCH3203 is not previously
described, display the message (DSPMSGD command) to see what is causing the
error. There is no message for MCH3203 in the job log because the error
occurred at a time when a message could not be sent. If there is a problem
invoking the program that the job routed to, using a CALL command to invoke
the program may generate the MCH3203 error as a message with message data
that further describes the problem. If a problem occurs when activating a
program (*PGM), the problem may be caused by a service program (*SRVPGM).
After clearing out QTEMP, the job ends:
CPF1164 Completion 00 09/08/11 17:37:17.841350 QWTMCEOJ QSYS 0148 *EXT *N
Message . . . . : Job 986133/myprofile/DSP01PEM ended on 09/08/11 at 17:37:17;
.122 seconds used; end code 30 .
Cause . . . . . : Job 986133/myprofile/DSP01PEM completed on 09/08/11 at
17:37:17 after it used .122 seconds processing unit time. The job had
ending code 30. The job ended after 1 routing steps with a secondary ending
code of 0. The job ending codes and their meanings are as follows: 0 - The
job completed normally. 10 - The job completed normally during controlled
ending or controlled subsystem ending. 20 - The job exceeded end severity
(ENDSEV job attribute). 30 - The job ended abnormally. ...
So I still think a DLTPGM for a currently active program will end the job!
Paul E Musselman
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
midrange.com
