Of course the user isn't going to want information from both monitoring
apps, but they likely will not know that the driver is inserting a
jmJobSubmissionID. When they use their NDPS/Unix monitoring component and
it can't find the job, are they going to slap their forehead and suddenly
realize they must turn off "Insert Job Submission ID" in their driver?
If we can say that client monitoring is ALWAYS favored over server back
channel, then our current design (last ID encountered) is ok. I would
assume that Novell and others would not be happy with this decision, but we
are not hearing from them. The current design works ok for the client
monitoring/driver folks (which I represent) but I'm not sure it is the best
overall solution for the user.
Stuart Rowley
Kyocera Electronics, Inc.
______________________________ Reply Separator _________________________________
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Author: INTERNET:harryl@us.ibm.com at CSERVE
Date: 11/18/97 4:35 PM
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
jmp-owner@pwg.org on 11/18/97 12:40:30 PM
Please respond to jmp-owner@pwg.org @ internet
To: jmp@pwg.org @ internet
cc: rbergma@dpc.com @ internet, STUART@KEI-CA.CCMAIL.compuserve.com @ 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: 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 --
----------------------------------------------------------------------
--------------------------------------------------------------------------------
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
jmp-owner@pwg.org on 11/17/97 06:15:16 PM
Please respond to jmp-owner@pwg.org @ internet
To: JMP@pwg.org @ internet, rbergma@dpc.com @ 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.
--------------------------------------------------------------------------------