I was about to disagree with Paul's assertion re the "streamed by" info,
until I realized that the wealth of info to which I'm accustomed comes from
MPEX, not MPE...

 JOB SOMEJOB,MANAGER.SYS,PUB.
 Priority = DS; Inpri = 8; Time = UNLIMITED seconds.
 Job number = #j2040.
 WED, JAN 17, 2001,  2:16 AM.
 HP3000  Release: C.55.00   User Version: C.55.00
 MPE/iX  HP31900 C.05.08  Copyright Hewlett-Packard 1987.
 All rights reserved.
 STREAMED BY NUTHAJOB,OPERATOR.SYS (#J2038) ON LDEV# 10
    STREAM DATE:   WED, JAN 17, 2001,  2:16 AM
 I am HOBBES (HP3000 series 957LX)...
 Welcome!  You are now signed on.
 :COMMENT   STREAM FILE SOMEJOB.JOBS.SYS
 :COMMENT     STREAMED BY NUTHAJOB,OPERATOR.SYS,OPERATOR (A JOB STREAM)
 :COMMENT     RUNNING PROGRAM MAIN.PUB.VESOFT
 :COMMENT     ON WED, JAN 17, 2001,  2:16 AM

It would be nice if the source of the ":COMMENT"s were better identified,
but I'd consider that completely unnecessary if we can assume it's "the OS".

Adding more ":COMMENT"s by the OS should no more interfere with 3rd party
jobstream manglers than any other comment.  So I'm with Paul 100% - the more
info, the better, especially in exceptional conditions such as "Aborted by
system management".

Somebody complained that these OS insertions might interfere with in-line
reporting contained in $stdlists; I really don't see that as an issue:  if
you want your report IN the $stdlist, you could always produce it externally
and then copy it in:

Instead of...
:file myreport=$stdlist
:run mypgm

why not...
:run mypgm
:print myreport

...?  Maybe because you want to see exactly how far MYPGM got before it was
aborted?


Here's my One more vote for more info, but I dunno about its priority; there
are more important problems, such as 36GB disc or disk.

Tracy Pierce
> -----Original Message-----
> From: Paul H Christidis [mailto:[log in to unmask]]
> Sent: Wednesday, January 17, 2001 11:12 AM
> To: [log in to unmask]
> Subject: Re: ABORTJOB Enhancement Idea
>
>
> To All,
>
> The $stdlist is a record of all actions performed during the
> execution of a
> batch job causing the generation of the desired result.
> While the 'record'
> only shows actions taken by the batch process we should not forget the
> recording of actions taken in behalf of that process.  Most
> of us don't
> think about these 'external' events until these events have some major
> impact in subsequent processing.   Consider, for example, missing the
> cutoff time for transmitting monthly sales information to the
> corporate
> center because someone suspended a related process and resumed it some
> hours later or forgot to ever resume it.
>
> At the same time I don't think that  application managers or
> programmers
> should have to go 'hunting', on their own or by asking the
> system manager,
> for any 'external' events that interfered with a specific
> batch job.  They
> should be able to follow the $stdlist and see a complete record.
>
> Currently the commands 'breakjob', 'resumejob' and 'abortjob' add a
> 'console log' record into the system log file, indicating who and when
> issued the corresponding command.  I'm sure that the method
> for writing to
> another process's $stdlist already belongs (or is better
> suited) within the
> OS, instead of some external wrapper that would require
> someone else to
> maintain and the constant vigilance at each site to make sure
> that it is
> not overlaid every time an update to the OS occurs.
>
> One idea, to address concerns about third party utilities
> that would break
> with the introduction of these additional messages, would be
> to classify
> these as informational displays and thus not to interfere with the
> operation of these utilities.  I'm sure, however, that third
> party vendors
> would quickly incorporate these additional data points, since
> they would
> enable them to present a better picture of the transpired events.
>
> One other command that could affect the elapsed time of a
> batch job, and
> which currently is not recorded, is the 'reply' command.  I
> feel that the
> $stdlist should contain a 'record' of when the request was
> first issued and
> when the operator replied to it.  And since we are visiting
> this subject
> let us be opportunistic and request that the 'streamed by'
> information be
> amended to include the name of the file used in submitting
> the batch job.
>
> Regards
> Paul Christidis
>