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: 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 --
----------------------------------------------------------------------
--------------9791DEBD129EDC602A63C50F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from lms03.us.ibm.com (lms03.ny.us.ibm.com [198.133.22.39]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id QAA10025 for <jkm@underscore.com>; Tue, 18 Nov 1997 16:35:04 -0500 (EST)
Received: from US.IBM.COM (d03lms03.boulder.ibm.com [9.99.80.13])
by lms03.us.ibm.com (8.8.7/8.8.7) with SMTP id RAA06634;
Tue, 18 Nov 1997 17:31:34 -0500
Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032
id 5030300014752019; Tue, 18 Nov 1997 16:40:34 -0500
From: Harry Lewis <harryl@us.ibm.com>
To: <rbergma@dpc.com>, <STUART@KEI-CA.CCMAIL.compuserve.com>,
<jkm@underscore.com>, <jmp@pwg.org>
Subject: Re: JMP> Proposed Rules for jmJobSubmissionId
Message-ID: <5030300014752019000002L092*@MHS>
Date: Tue, 18 Nov 1997 16:40:34 -0500
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1
Yes, I consider this topic (appropriately) re-opened (along with the
collated/un-collated topic).
Without repeating your example (attached, below)... and referencing Stu=
art'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 monit=
oring is
turned off then
it should not be wrapping jmJobSubmissionID with the job. If client mon=
itoring
is favored over server back channel, then the fact that legacy LPR subm=
ission
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 @ i=
nternet,
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 convin=
ced 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 ti=
me on
the same job? Why would the end-user want 2 ways to monitor the print j=
ob?
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. T=
his 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 map=
ping
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 convince=
d there
is a practical use for this. Could someone offer a high level diagram o=
f a
practical system where the client is getting job progress information f=
rom 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 o=
n
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 jmJobSubmissionI=
d
for job monitoring. It is clearly undesirable for something downstream=
,
such as NDPS, to then stomp on the jmJobSubmissionId created by the dri=
ver.
Allowing multiple jmJobSubmissionIds to point to the same jmJobIndex se=
ems
to be a more straight forward solution. I know the consensus was to no=
t
re-open this, but maybe others are having second thoughts. Can someone=
refresh my memory on the negatives of allowing multiple jmJobSubmission=
Ids?
Stuart Rowley
Kyocera Electronics, Inc.
-----------------------------------------------------------------------=
---------
=
--------------9791DEBD129EDC602A63C50F--