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:
Reply To:
Date:
Wed, 17 Jan 2001 14:45:02 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (36 lines)
X-no-Archive:yes
Very interesting idea! It breaks nothing that now exists. I would assume
then that one might even want a ;JOB parm. It could either mean also jobs,
or only jobs. In either case, we might want more values for this parm to
make explicit other meanings. I guess I would favor an only jobs meaning,
and also allow a default only sessions meaning, as well as a both/either
meaning. It goes without saying that the current behavior of TELL would have
to be the default, so that we could still TELL jobs and test for the CIWARN
that you cannot TELL a job versus testing for being told that no such job
exists.

Greg Stigers
http://www.cgiusa.com
This opinion and a fiver will get you an overpriced cup of coffee at
Starbucks.

-----Original Message-----
From: Russ Smith [mailto:[log in to unmask]]
Sent: Tuesday, January 16, 2001 4:36 PM
To: [log in to unmask]
Subject: Re: ABORTJOB Enhancement Idea

Is anyone aware of a way to append lines to the STDLIST (i.e. STDOUT) of
another process, which I believe is what a TELL message does?

My thought being this.  Instead of changing how ABORTJOB works, if the
modification were to the TELL command to allow it to write to a job's
STDLIST, the UDC idea put foward by Jeff would work, and would gain much
more flexibility.

While the modification to the ABORTJOB command would probably be simpler, I
think modifying TELL to include the ability to tell a JOB something would be
a better enhancement, and would then allow users to place any information
they wanted at the bottom of an aborted job.
<snip>

ATOM RSS1 RSS2