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 -----
Date: Fri, 30 May 1997 09:08:46 -0700 (PDT)
From: Patrick Powell <papowell at dickory.sdsu.edu>
To: jkm at underscore.com
Subject: Re: JMP> LPR/LPD format for jmJobSubmissionID object value
# Date: Thu, 29 May 1997 21:15:15 -0400 (EDT)
# From: JK Martin <jkm at underscore.com>
# To: jmp at pwg.org
# 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 at host+jobnumber
For example:
root at dickory+024 or root at dickory.sdsu.edu+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 -----