>Wouldn't you agree that it would be very, VERY difficult for
>a monitoring app on the local (ie, submitting) platform to
>know the job id (much less the job id *format*) of the _last_
>component in the printing system process?
Yes, I would agree, but this is not the interpretation I have had, or h=
ave
tried to put forth. I searched the Job MIB draft for the language but c=
ould not
find it.
The rule should be... the Job MIB agent always uses the last encountere=
d
jmJobSubmissionID (in fact, we recommended this rule for ANY potentiall=
y nested
attribute... it's probably in the doc somewhere but I just couldn't fin=
d it).
The interpretation you are using it that the agent should use the
jmJobSubmissionID assigned by the last component in the printing system=
! A
major difference in how we are viewing things, there!
With my interpretation, there would be no need for the local monitoring=
app to
try and determine the ID supplied by a downstream component. If the loc=
al app
is monitoring and has applied the ID, this should be the final ID encou=
ntered
and all's well. If the local app is not monitoring (or any component, f=
or that
matter), it should not explicitly tag the job with an ID. Sure, legacy
submission vehicles (LPR/LPD), and/or IPP, will end up "causing" an ID =
to be
established according to a particular format. So the problem really onl=
y raises
it's head if you go Client (off) --- LPR (legacy, on by default) --- LP=
R or IPP
(ditto - and want's to be THE monitor). But, this isn't even a problem =
because
the printer only sees one final form of submission ... it doesn't creat=
e a
jmJobSubmissionID for every intermediate form of legacy submission. So =
there
should only be one jmJobSubmissionID created due to the submission vehi=
cle
which either is or is not (in this case) overridden by the datastream.
I'm not saying multiple entries isn't an elegant solution... I'm just s=
till
trying to flesh out the problem.
Harry Lewis - IBM Printing Systems
jkm@underscore.com on 11/18/97 03:16:03 PM
To: Harry Lewis/Boulder/IBM@ibmus
cc: jmp@pwg.org
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Harry,
> Given your assertion (and mine)... then let's re-examine said problem=
. Closest
> to submission means last encountered by Job MIB agent. This was the =
basis
> behind the rule... "always take the last
> jmJobSubmissionID".
Hmmm...we may be out of sync here. How many Job MIB agents are
involved here? It's very hard to tell. All I am saying is that
the monitoring app would likely be launched on the submitting
platform, and would therefore have the original job id as the
target for its searches for *whatever* agent(s) are contacted
by the app.
Wouldn't you agree that it would be very, VERY difficult for
a monitoring app on the local (ie, submitting) platform to
know the job id (much less the job id *format*) of the _last_
component in the printing system process?
> The only modification I would make to your statement (above) is that
> there may be configurations where the NOS provides native job monitor=
ing
(NDPS)
> or a "3rd party" application (UNIX print server/monitor/notification)=
is in
> effect... in which case "upstream" monitoring should be disabled. May=
be this
is
> the real sticky point?
Sure, I guess it could be a sticky point. Yes, one could run
multiple monitoring apps that look for different types of job ids.
But I would expect that no one would want to do this.
After all, the Number One reason why the Job MIB will be so useful
is to answer that everlasting Holy Grail question:
"Is it time for me to get up from my desk to go
fetch my completed job(s)?"
It seems natural (to me, anyway) that the user is most likely to
use a single monitoring app, one that is integrated with the local
platform to the maximum possible extent.
Do others have differing views?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
=