> 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 monitoring (NDPS)
> or a "3rd party" application (UNIX print server/monitor/notification) is in
> effect... in which case "upstream" monitoring should be disabled. Maybe 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 --
----------------------------------------------------------------------