I will be able to participate. (But the limit has to 1 hour due to a
conflict with other meetings.)
Ron Bergman
On Tue, 18 Nov 1997, Harry Lewis wrote:
> I agree we need a conf call to discuss
>
> A. nested jmJobSubmissionIDs
> B. Collated/Un-collated copies
>
> I propose tomorrow (Wednesday) 9-10am MST (8am west coast; 11am east coast). I
> will try to figure out how to originate such a call. Please ping.
>
> Harry Lewis - IBM Printing Systems
>
>
> ---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/18/97 05:52 PM
> ---------------------------
>
>
> jmp-owner@pwg.org on 11/18/97 04:45:09 PM
> Please respond to jmp-owner@pwg.org @ internet
> To: Harry Lewis/Boulder/IBM@ibmus
> cc: jmp@pwg.org @ internet
> Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
>
>
> This is a multi-part message in MIME format.
> --------------------------------------------------------------------------------
> Umm...I think I'm getting really lost and confused here.
>
> Perhaps this subject would be best handled (at least initially)
> via a telecon?
>
> ...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 --
> ----------------------------------------------------------------------
> --------------------------------------------------------------------------------
> Herein lies one of our major problems, I'm sure...
>
> >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 have
> tried to put forth. I searched the Job MIB draft for the language but could not
> find it.
>
> The rule should be... the Job MIB agent always uses the last encountered
> jmJobSubmissionID (in fact, we recommended this rule for ANY potentially nested
> attribute... it's probably in the doc somewhere but I just couldn't find 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 local app
> is monitoring and has applied the ID, this should be the final ID encountered
> and all's well. If the local app is not monitoring (or any component, for 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 only raises
> it's head if you go Client (off) --- LPR (legacy, on by default) --- LPR 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 create a
> jmJobSubmissionID for every intermediate form of legacy submission. So there
> should only be one jmJobSubmissionID created due to the submission vehicle
> 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 still
> 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 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 --
> ----------------------------------------------------------------------
>
>
>
>
> --------------------------------------------------------------------------------
>
>
>
>