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:
Paul H Christidis <[log in to unmask]>
Reply To:
Paul H Christidis <[log in to unmask]>
Date:
Wed, 17 Jan 2001 11:11:30 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
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

ATOM RSS1 RSS2