Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

From: Harry Lewis <[email-masked]>
Date: Tue, 18 Nov 1997 17:11:11 -0500

Thanks, Jay...

>I wouldn't expect a user operates more than one job monitoring
>application at a time.  Furthermore, I would expect the user
>to invoke a monitoring application "closest" to the start of
>the job submission process stream (ie, on the local platform
>on which the job was originally submitted).

I thought I was going nuts there for a while...

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

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?

Harry Lewis - IBM Printing Systems

[email-masked] on 11/18/97 02:56:02 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.
--------------------------------------------------------------------------------
Harry,

I wouldn't expect a user operates more than one job monitoring
application at a time.  Furthermore, I would expect the user
to invoke a monitoring application "closest" to the start of
the job submission process stream (ie, on the local platform
on which the job was originally submitted).

 ...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   --
----------------------------------------------------------------------
--------------------------------------------------------------------------------
Yes, I consider this topic (appropriately) re-opened (along with the
collated/un-collated topic).

Without repeating your example (attached, below)... and referencing Stuart's
"Applet vs. NDPS" example... isn't the user going to feel like there is an echo
in the room?

Page 1 complete (applet)... Page 1 complete (Unix or NDPS monitor)
Page 2 (applet)... Page 2...(UNIX/NDPS)
etc.

I'd be quick to turn SOMETHING off in that environment! If client monitoring is
turned off then
it should not be wrapping jmJobSubmissionID with the job. If client monitoring
is favored over server back channel, then the fact that legacy LPR submission
results in a jmJobSubmissionID which is later replaced by the one found in the
job (the LAST one encountered by the agent)... is no problem.

Harry Lewis - IBM Printing Systems

[email-masked] on 11/18/97 12:40:30 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet,
Harry Lewis/Boulder/IBM@ibmus
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

This is a multi-part message in MIME format.
--------------------------------------------------------------------------------
I believe we must reopen the issue of nested job ids and how to
handle them.  I realize that this topic was consciously shelved
a while back, but further subsequent digging has resulted in the
need to readdress and handle this issue.  It appears that Stuart
Rowley has also recognized the need to rethink this topic.

Harry Lewis wrote in response to Stuart:

> I don't strongly object to moving to a design where multiple
> jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there
> is a practical use for this. Could someone offer a high level diagram of a
> practical system where the client is getting job progress information from two
> sources, simultaneously?

I don't think the operating requirements is such that a job monitoring
application is monitoring progress from two sources.  Rather, the
application is "told" to monitor job ID "XYZ", but the application
has no idea that (potentially) several intermediate servers are
involved in the complete job submission and delivery process.  And
this scenario (ie, one or more intermediate servers) is the real
problem here.

Here is a real-world scenario we frequently encounter in enterprise
environments:

  1) A Windows user submits a job to the native Windows printing
     system; the PC has been configured to automatically launch
     a "print job monitor" application, where the application is
     instructed to monitor job "XYZ", where "XYZ" is the *Windows*
     job id.

  2) The user's PC is configured to route all print jobs to a Unix
     (or NetWare, or other non-Windows) server using an appropriate
     spooling protocol, such as (gasp) LPD/LPR.

  3) The printing system on the Unix server uses printer-specific
     driver software to deliver the print job to the target printer
     using an appropriate (and potentially proprietary) delivery
     mechanism.

In this scenario there are at least two (if not three) different
job ids created by the time the paper starts rolling out of the
printer.  Yet, the PC-based monitor application only knows about
the first (original) job id.

What can we do about this problem?  Some quick options:

  1) Force the monitoring application to know about all possible
     job ids that may be subsequently created as the job moves
     thru the printing system.  This means the app must "learn"
     about all other job ids, or at least job id *patterns* that
     might be used to derive the relationship of subsequent job
     ids with the original job id.

  2) Extend the Job MIB to allow for a parallel set of job id
     "aliases" for any given job.  As a job moves thru the printing
     system, the current "handler" (job transfer agent, if you will)
     assigns an appropriate job id, then adds the previously
     assigned job id as an "alias" for the job.  The monitoring app
     can then search for the target job in both the primary job id
     list or the list of aliases for each job.

  3) Do nothing about this problem, declaring that job monitoring
     using the Job MIB is only useful in very simple printing systems.

My quick opinions on each of these options:

  1) This approach is very, very messy, and probably won't work for
     diverse environments in which several server types are used
     within a single environment (ie, Unix *and* NetWare, etc).

  2) A good approach, IMHO, that can be fairly easily solved, given
     that we have already devised clever ways to attach variable
     lists of information with any given job.

  3) This approach would disappoint us greatly, needless to say...

Given the work done to date by Ira and Tom, it's not hard to imagine
that they can come up with some wonderfully elegant approach to
providing multiple job ids in the Job MIB, one that can be designed
in the very near future.  (Right, guys?? ;-)

Again, we at Underscore strongly encourage the JMP group to address
this problem now so that simple, effective and accurate job monitoring
applications can be delivered to the marketplace independent of the
underlying platform.

 ...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   --
----------------------------------------------------------------------
--------------------------------------------------------------------------------
Stuart, are you suggesting that, in an NDPS environment (for example), BOTH  a
"driver spawned" job monitoring client application (like DocWise) AND a NOS
provided monitoring paradigm (NDPS) will be in operation at the same time on
the same job? Why would the end-user want 2 ways to monitor the print job?

Part of the decision to use "last encountered" jmJobSubmissionID was to keep
the agent simple, yes, but this decision was also based on the premise that
only one "tightly coupled" monitoring application need be in control. This is
not to say "out of band" applications can't still monitor - just not in the
"pin point" fashion provided by the jmJobSubmissionID to jmJobIndex mapping
table.

I don't strongly object to moving to a design where multiple
jmJobSubmissionID's map to one jmJobIndex. But, I'd like to be convinced there
is a practical use for this. Could someone offer a high level diagram of a
practical system where the client is getting job progress information from two
sources, simultaneously?

Harry Lewis - IBM Printing Systems

[email-masked] on 11/17/97 06:15:16 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet, [email-masked] @ internet
cc:
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

Ron,

I am increasingly uncomfortable with the agreement to use the last
submission id encountered.  I believe the original decision was based on
the idea that it was the simplest solution, but your write-up on the
Proposed Rules for jmJobSubmissionId shows that this solution is not so
simple or straight forward after all.

I can see the possibility of an application that works closely with the
driver, such as HP's DocWise, using the driver created jmJobSubmissionId
for job monitoring.  It is clearly undesirable for something downstream,
such as NDPS, to then stomp on the jmJobSubmissionId created by the driver.

Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex seems
to be a more straight forward solution.  I know the consensus was to not
re-open this, but maybe others are having second thoughts.  Can someone
refresh my memory on the negatives of allowing multiple jmJobSubmissionIds?

Stuart Rowley
Kyocera Electronics, Inc.

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

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

---

From: Jay Martin <[email-masked]>
Date: Tue, 18 Nov 1997 17:13:52 -0500

Harry,

> behind the rule... "always take the last

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?

> effect... in which case "upstream" monitoring should be disabled. Maybe this is

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