RE: *** ADMIN: Wiki spam endjob\dltpgm

L.I.B. :) This is contrary to my prior understanding, but you learnt me
sump'm. Sorry to cause any confusion.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"A banker warned the British poet Robert Graves that one could not grow rich
writing poetry. He replied that if there was no money in poetry, there was
certainly no poetry in money, and so it was all even."
-- Robert Graves

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.