Subject: Re: JMP> Proposed Rules for jmJobSubmissionId

From: Harry Lewis <[email-masked]>
Date: Tue, 18 Nov 1997 10:58:02 -0500

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 14:36:23 -0500

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.

> practical system where the client is getting job progress information from two

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

Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
From: Harry Lewis <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 18 Nov 1997 10:58:02 -0500

Ron,

Stuart Rowley