HP3000-L Archives

January 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jon Diercks <[log in to unmask]>
Reply To:
Jon Diercks <[log in to unmask]>
Date:
Tue, 16 Jan 2001 08:43:26 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
Patrick--

If your intent also implies that anyone who does NOT have access
to the stdlist should NOT be able to find out who aborted the job,
then yes your enhancement is probably the cleanest way to get
what you want. If restricting access to that information is not a big
deal, then you could still use a UDC wrapper for ABORTJOB that
logs the info, and then create a second UDC like WHOABORTED
#Jnnn that would grep the log file for the desired information. The
logfile would have to be world-readable, and appendable by anyone
who can do ABORTJOB.

You're certainly right that it would be nice for MPE to include this
information in the STDLIST automatically. I'm just trying to suggest
alternatives since enhancements like this typically take awhile to
make it into a production release.

HTH

--Jon

From:                   Patrick Santucci <[log in to unmask]>
> No, my main goal, as stated, is to allow anyone who can read the $STDLIST to
> know WHO aborted the job (and from what ldev), the same as they can now tell
> WHO streamed it (and from what ldev). The stats are secondary and can
> probably be gathered, as you said, in other ways. But it sure would make MPE
> more user-friendly to have a meaningful, *informative* JOB ABORTED BY
> message than a generic one, yes?

_______________________
Jon Diercks
<[log in to unmask]>
http://www.diercks.net/

ATOM RSS1 RSS2