Subject: JMP> JMP Conf Call - revisited

From: Harry Lewis <[email-masked]>
Date: Wed, 19 Nov 1997 18:59:22 -0500

I'm setting up a call tomorrow (Firday) Noon-2 MST (2-4 wayEast; 11-1 wayWest).

Number is 1-888-687-2860
pass code is 404724

Topics:  1. nested JmJobSubId
                 2. collatted / uncollated

I have 8 lines (we had 6 participants today). Hope you can be there!!!

Harry Lewis - IBM Printing Systems

---

From: Ron Bergman <[email-masked]>
Date: Thu, 20 Nov 1997 08:14:51 -0800 (Pacific Standard Time)

Harry,

I have a conflict with the time scheduled and will not be able to
participate in the call.

A quick comment for the discussion:  My goal in drafting the Mapping
document was to provide guidance in creating jmJobSubmissionId without any
changes to current job submission protocols.  I now propose that this is
incorrect.  I believe that this corresponds to what you have been stating
for quite some time.

jmJobSubmissionIds should only be generated when there is a coupled Job
Monitoring application that requires its use.  Therefore, a Job Monitoring
agent for the printer should only generate jmJobSubmissionId when
explicitly required by the Job Monitoring Ap.  This requires the agent to
only develop jmJobSubmissionIds when properly formatted within the job.

This reduces the problem I originally formulated, but there still is the
issue of multiple submission ids.  Unless an alternate solution can be
developed, I am in favor of allowing multiple jmJobSubmissionIds to be
created for the same job.  

	Ron Bergman
	Dataproducts Corp.

---

From: Jay Martin <[email-masked]>
Date: Thu, 20 Nov 1997 15:29:13 -0500

Ron,

> only develop jmJobSubmissionIds when properly formatted within the job.

It's too bad you couldn't make the second telecon.  Others in
that call also believed that "driver-like" software (ie, components
that package and deliver a job to the next element in the printing
system chain) would OF COURSE be intimately tied to the Job MIB.

Dave Kellerman and I showed how this wasn't necessarily true, citing
existing real-world implementations in the field today.  Upon hearing
our explanation, the others in the call seemed to understand and
agree with us.

If anyone on the list (who wasn't on the telecon today) needs more
info, then I'll take the (substantial) time to document the situation
and post it to the list.  However, I'd prefer to wait until the
upcoming Los Angeles meeting so that we can talk face-to-face and
draw diagrams, etc.

> created for the same job.

Everyone on the telecon today agreed that, despite our somewhat
differing views on "expected implementations", the solution as
proposed by Harry certainly appears to satisfy everyone's needs
without substantial heartburn.

Harry's solution can be summarized as: Multiple jmJobSubmissionId
values can exist for a single job, but all of them reference a
single jmJobIndex.

	...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: Ron Bergman <[email-masked]>
Date: Thu, 20 Nov 1997 14:06:53 -0800 (Pacific Standard Time)

Jay,

Thanks for the update.  If you have time, maybe a short summary regarding
the position presented by yourself and Dave?  (But if you don't have the
time I can wait for the LA meeting.)

	Thanks again,

	Ron