Subject: JMP> LPR/LPD format for jmJobSubmissionID object value

From: JK Martin <[email-masked]>
Date: Thu, 29 May 1997 20:37:59 -0400 (EDT)

Harry,

Sorry for not responding to your question sooner...

> So, what about my proposal to add a new jmJobSubmissionID format for LPR
> JobOwner? The owner information would have to be truncated to 30 bytes and
> someone, most likely the NIC, would have to prepend the assigned
> jmJobSubmissionID format number to the attribute.

Your proposal (as documented in the San Diego meeting minutes, page 4)
suggested this encoding of the 30 available octets:

    Job owner:       6
    Owner's host:    8
    Server job ID:  16

This doesn't look like it will work, as the owner/host values are too
severely truncated.  To ensure the required uniqueness, the server job
ID must be at least 12 bytes to cover the Unix case; many (but not all)
Unix systems restrict queue names to 9 bytes, and when combined with
the 3 bytes required for the job number (0-999), this makes a total of
12 bytes.  This means we have 4 more bytes to use for either the owner
and/or host components.  This is still too restrictive, unfortunately.

We need the jobOwner field.  (Sorry!)  However, I don't think we need
to take Tom's suggestion of changing the JobID table to include
jobOwner and make the table indexed by *both* the submission ID *and*
the jobOwner values, as this makes life more complex for ALL other
environments.

If jobOwner is added to the jobID or jobState tables, then those
monitoring apps that need to key off of jobOwner will simply have
to do their own indexing on the jobOwner value in each job entry.

Comments?

	...jay

---

From: JK Martin <[email-masked]>
Date: Thu, 29 May 1997 21:15:15 -0400 (EDT)

In that previous message I forgot to state that I think it would be
a good idea to formally define a job submission ID specifically for
LPR/LPD, even though such an ID would not necessarily help the kinds
of monitoring apps we've been talking about recently (ie, "out-of-band"
job monitors).

The encoding of the ID for LPR/LPD is quite trivial and follows the
format defined in RFC 1179 for the encoding of the control/data files.
Control file names follow this form:

	cfAnnn<hostname>   example:  cfA027punky.underscore.com

That is, a fixed prefix of "cfA" followed by a three-digit job number
(000-999) followed by the hostname (usually fully qualified).

Data files are similar, except that the "cfA" prefix is replaced with
"dfA".  (Hence the common references to "cf/df" files when talking
about LPD spooling.)

The idea here is that the names of the control and data files are very
similar, with the only exception being the first character (ie, "c"
vs.  "d").  Since this distinction in prefixes is relatively
meaningless for job identification, we shouldn't need to include the
first three characters in the Job MIB job submission ID string.

This results in an encoding of:

	nnn<hostname>   example:  027punky.underscore.com

Of course, the <hostname> component would have to be truncated after
the 27th character, but since hostnames are formed with a left-to-right
hierarchy, this should be sufficient for most environments (right??).

The LPD encoding would be tagged with "04" in the list of defined
job submission ID formats.

By the way, why in the world do we need TWO octets for the format
descriptor?  As it stands we have only 5 formats (including this
new LPD definition)!  If we reduce this to a single byte (and continue
to use a decimal-digit encoding technique), then we have room for
5 additional formats.  Even if we needed more, we could then use
a hex-like technique and start using letters (a-z, etc).

This is a classic case of over-engineering, IMHO.  Here we are worrying
about truncating valuable information when we're wasting it elsewhere.
We should change this.

Comments?

	...jay

---

From: Harry Lewis <[email-masked]>
Date: Fri, 30 May 1997 11:16:01 -0400

Jay, thanks for your informative response on this topic. I agree that 2 bytes
is over-kill. I have no problem moving back to one byte for the Format ID.
Since LPR is already a defined standard, and cfA always
precedes the control file naming string, why not just reserve cfA as the LPR
format identifier? I know it uses more bytes, but this would alleviate the need
for adding the Format ID somewhere in the process.

Harry Lewis - IBM Printing Systems

------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM -----

        [email-masked]
        05/29/97 07:17 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet
cc:
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value

Comments?

 ...jay

---

From: JK Martin <[email-masked]>
Date: Fri, 30 May 1997 13:55:03 -0400 (EDT)

Harry,

I'm a bit confused by your response.  You suggest that the format
identifier for LPR/LPD could be the "cfA" prefix string; however,
don't we want to be completely consistent with the form for the
format descriptor?

That is, all the other format descriptors are two-digit numeric
characters, and I would have thought that we'd want to define all
format descriptors in that manner to simplify parsing/lookup, etc.

Perhaps I'm missing something here?

Thanks for being agreeable to moving from a two-digit descriptor
to a single-digit descriptor.  Let's see if the rest of the group
can agree to that.

	...jay

----- Begin Included Message -----

>From [email-masked] Fri May 30 11:14 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value
Date: Fri, 30 May 1997 11:16:01 -0400

------ Forwarded by Harry Lewis/Boulder/IBM on 05/30/97 09:05 AM -----

        [email-masked]
        05/29/97 07:17 PM

Comments?

 ...jay

----- End Included Message -----

---

From: JK Martin <[email-masked]>
Date: Fri, 30 May 1997 14:12:51 -0400 (EDT)

I guess I can agree with Patrick's proposal for the LPR/LPD submission
ID encoding.  I'm still concerned about the length restrictions for
this object (currently a max of 30, but could become 31 if we move from
a 2-digit format field size to a single-digit field).

The question now might be:  can this format serve as a useful way to
identify the job owner, thereby eliminating the need to have the
jobOwner object in the jobState table?

I still think the answer is No, due to the length restrictions for the
jmJobSubmissionID object.  If that object were to increase in size to,
say, 63 bytes, then maybe this could work.  (I can hear Harry cringing
even as I write this... ;-)

If the submission ID object were increased to 63 bytes (hey, or even
more! ;-), then it might very well be that jobOwner can stay in the
quickly-aged-out jobAttribute table.

If we were to make this move, then I would definitely prefer Patrick's
encoding form, and think that jobOwner can then stay in the jobAttribute
table.

Comments on such a change to increase the size of jmJobSubmissionID?

	...jay

----- Begin Included Message -----

>From [email-masked] Fri May 30 12:10 EDT 1997
Date: Fri, 30 May 1997 09:08:46 -0700 (PDT)
From: Patrick Powell <[email-masked]>
To: [email-masked]
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value

# Date: Thu, 29 May 1997 21:15:15 -0400 (EDT)
# From: JK Martin <[email-masked]>
# To: [email-masked]
# Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value

# In that previous message I forgot to state that I think it would be
# a good idea to formally define a job submission ID specifically for
# LPR/LPD, even though such an ID would not necessarily help the kinds
# of monitoring apps we've been talking about recently (ie, "out-of-band"
# job monitors).

# The encoding of the ID for LPR/LPD is quite trivial and follows the
# format defined in RFC 1179 for the encoding of the control/data files.
# Control file names follow this form:

# 	cfAnnn<hostname>   example:  cfA027punky.underscore.com

I would like to suggest:
    user@host+jobnumber

For example:
    root@dickory+024  or [email-masked]+024

The job ID embeds the user, originating host, and job number id
into one  'string'.

The job ID would fix up the problem of conflicts in job numbers
which could occur from different hosts,  if there was not a distinguisher.
In addition,  I like to see the user's name in the id.

Patrick Powell

----- End Included Message -----