Thanks for the insight, Jeff.

Based on what you've said, the more general solution of providing such info
via an intrinsic called by ABORTJOB would make a lot more sense.  Then
REPLY, etc, could make the same call, issue their old tried-n-true message,
plus the WHODUNNIT info.

Tracy Pierce


> -----Original Message-----
> From: VANCE,JEFF (HP-Cupertino,ex1) [mailto:[log in to unmask]]
> Sent: Wednesday, January 17, 2001 1:36 PM
> To: [log in to unmask]
> Subject: Re: ABORTJOB Enhancement Idea
>
>
> > Yes, I would vote in favor of this enhancement.
> ...
>
> The ABORTJOB command starts life in CM. After verifying a
> valid user.acct or
> #Jnnn value and the user has the authority to abort the job,
> it switches to
> NM.
> At this point there is no information kept about who issued
> the ABORTJOB
> command.
>
> If an abort is not already pending it calls the routine
> abort_job(), which
> sends
> a message to JOB.pub.sys.  The message only contains: message
> #, job vs.
> session
> flag, and job number. JOB wakes up and calls do_abortjob(),
> which sends a
> message to the corresponding JSMAIN process.  stop_user(), running on
> JSMAIN's
> stack, calls kill_child() to terminate all the job's
> processes.  stop_user()
> also calls genmsg() to post CPU time and the "JOB ABORTED BY SYSTEM
> MANAGEMENT"
> message.  genmsg() writes the message to $STDLIST.  Since
> JSMAIN opened the
> $STDLIST spoolfile for the target job, genmsg's write to
> $STDLIST works
> correctly.
>
> To change MPE to support this enhancement, the message first
> sent to JOB
> would need to contain the user.acct name and job/sess ID of
> the aborter.
> Likewise, the message sent by JOB to JSMAIN would need these
> fields too.
> Then stop_user could write them to $STDLIST via another
> genmsg() call. This
> also implies that a new message is needed in the catalog.
>
> Hope this helps,
>
>  Jeff Vance, CSY
>