Subject: JMP> JMP Conference call needed

From: Harry Lewis <[email-masked]>
Date: Tue, 18 Nov 1997 20:08:47 -0500

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
 ---------------------------

[email-masked] on 11/18/97 04:45:09 PM
Please respond to [email-masked] @ internet
To: Harry Lewis/Boulder/IBM@ibmus
cc: [email-masked] @ 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:   [email-masked]          --
--  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

[email-masked] on 11/18/97 03:16:03 PM
To: Harry Lewis/Boulder/IBM@ibmus
cc: [email-masked]
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:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

--------------------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Tue, 18 Nov 1997 20:19:19 -0500

(Sorry, but I didn't know if public ping replies were requested.)

I'll be available for the call.  Please post the calling info once
you make the arrangements!

	...jay

---

From: Ron Bergman <[email-masked]>
Date: Tue, 18 Nov 1997 18:29:22 -0800 (Pacific Standard Time)

Harry,

I will be able to participate.  (But the limit has to 1 hour due to a
conflict with other meetings.)

	Ron Bergman