Subject: Re: JMP> Resource table - Missile or Camera

From: Tom Hastings <[email-masked]>
Date: Wed, 2 Apr 1997 10:54:41 PST

Harry,

I agree with you that none of the attributes you listed are needed by an 
accounting program.  However, I think that they are useful for end
users and operators that are monitoring jobs.  That is why I have 
resisted your suggestion to change the name of the Resource Table to the 
Accounting Table, since the contents of the table are for more purposes 
than just accounting.  I think that the name Attributes is more 
appropriate, since the contents of the table include information that is not
of interest to accounting programs.  I would think that
accounting programs would not be interested in any requested attributes,
not just the ones you listed.  Furthermore, the consumed attributes
in the table are of interest to non-accounting programs before the job 
is finished.  The consumed attributes are dynamic, in that they start at 
0 and count up, so even the consumed attributes are not used only by 
accounting programs, but by monitoring programs that want to display the 
progress of the job before the job completes.  Ok?

By the way all of the attributes that you listed are the ones for
which we don't have separate attributes (or multiple entries) for
requested vs. consumed.  In otherwords, the same entry is used for
both (and the requested and consumed value should be the same, so it
wasn't worth having two enums for each.  See Ron Berman mail on this
subject.

Ok?

Tom

At 21:40 04/01/97 PST, Harry Lewis wrote:
>Classification:
>Prologue:
>Epilogue: Harry Lewis - IBM Printing Systems
>
>I do not understand the need for requested values for any of the
>following "attributes" within the context of a resource accounting
>table such as we have defined.
>
>>Most attributes are either the requested value or the consumed (updated
>>as the job progresses), but not both.  The only attributes that are both
>>requested/used are:
>
>>outputBinIndex*56
>>outputBinIndex*56
>>outputBinName*56
>>sides*56
>>documentFormatIndex*56
>>documentFormatEnum*56
>>physicalDeviceIndex*57
>>physicalDeviceName*57
>
>Harry Lewis - IBM Printing Systems
>
>

---

From: Chris Wellens <[email-masked]>
Date: Thu, 3 Apr 1997 08:09:38 -0800 (PST)

Tom,

Everyone should have your work ethic.  

(1)  The Job Monitoring MIB is still on the schedule for the Tuesday,
April 8, 2-3 p.m.

(2)  Bring extra copies of the draft to the meeting.

(3)  Send a concise announcement of the date, time, and URL for
the document to [email-masked].  That will be the best way to
advertise it to other attendees.

By the way, I will not be there, because of a meeting I must
attend on Monday that is all day, and causes me to miss the last
flight.

On Wed, 2 Apr 1997, Tom Hastings wrote:

> I'm terribly embarrassed, but I didn't make the IETF cutoff time
> for the Job Monitoring MIB.
> 
> I just talked to Steve Coya of the IETF staff.
> He said that there is no problem with discussing what was supposed to
> be the I-D, at the IETF meeting next week, as long as the printmib
> chair (Chris Wellens and Don) agree.  Most chairs don't have a problem
> with discussing papers that aren't I-Ds.  The unfortunate thing is that
> we don't get feed back from non-PWG members.  Ok Chris to discuss the
> Job Monitoring MIB draft at the printmib meeting next week, even though
> it wasn't posted as an Internet Draft?  I don't know how we can advertize
> the location of the document on the pwg server to others who might attend.
> 
> Also we have to resubmit the draft after the meeting.  The IETF doesn't
> keep a queue.  I suggest that we submit it as soon as we can, in order 
> to get more IETF feed back, rather than waiting for the next IETF meeting
> where all the I-Ds get bunched up.
> 
> What happened:
> 
> Steve said that my Email didn't
> make the 5:00 pm EST (2:00 pm PST) cutoff time by 4 minutes on
> March 26.  The IETF looks at the posting time, not the arrival time, 
> so mail delays don't enter in.
> 
> Unfortuantely, when I went to send the I-D at 1:50 pm PST, my mail 
> server was down, even though everything else on my Sun workstation was 
> working fine.  So I had to copy the file to a diskette and send it from 
> Stan's PC.  By that time, I had run past 5:00 pm by 4 minutes.  I've never
> seen this problem before.  Sorry.
> 
> Even if I had gotten it posted, it still had the overstrike formatting
> problem.  While I think it could have been printed ok, it isn't readable
> on a screen.  The lines that are overstruck with CR and a bunch of spaces
> appear on the next line on the screen.  I'm in the process of getting a
> program to undo overstrikes that the Generic text print driver uses
> to output page number, cross reference page numbers, and tables.  I will
> make this program available for all to use along with the cscan and maxln
> tools I have already contributed (courtesy of Ira McDonald).
> I had removed all bolding, since I knew that the generic print driver
> sends three lines with the bold material present on the second and third
> pass.
> 
> BTW we should add these tools for creating I-Ds and RFCs to the PWG
> web page for use by all our projects.
> 
> So the document for the IETF printmib meeting next week (and this
> week JMP meeting) should be the one that is formatted with TimesRoman
> font:
> 
>   ftp://ftp.pwg.org/pub/pwg/jmp/mibs/jmp-mib.pdf
> 
> (and has the cover page that is not part of the I-D and has the change
> history that is not part of the I-D.)
> 
> NOT the one formatted with the fixed pitch Courier throughout:
> 
> ftp://ftp.pwg.org/pub/pwg/jmp/internet-drafts/draft-ietf-printmib-job-monito
> ring-00.pdf
> 
> Steve said to resubmit as 00.txt after April 14 including any changes
> we want to make (which may be considerable after Harry's presentation).
> 
> Tom
> 
>