Bug 1816 - Mapping of Print job numbers from Samba to OpenVMS
Summary: Mapping of Print job numbers from Samba to OpenVMS
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Printing (show other bugs)
Version: 3.0.7
Hardware: All OpenVMS
: P3 enhancement
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-09-23 20:58 UTC by John Malmberg
Modified: 2005-03-07 16:24 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description John Malmberg 2004-09-23 20:58:54 UTC
This is for tracking the issue on OpenVMS Only.

Platforms are VAX, Alpha, and Itanium.

Printjobs on OpenVMS are assigned a 32 bit unsigned number.  There is no
guarantee of the order that the numbers will be assigned.  This numbering system
is also shared with all batch jobs.  So at any one time there will be only one
print or batch job with a specific number.

Samba uses a 16 bit job number, which is specific to a print queue.

Some way needs to be found to resolve the mapping.

On small VMS systems, the print job number appears to usually stay in the range
that is directly mapped to Samba, so users can be mislead into thinking that
there is not a problem.

On medium to large VMS environments, while it will still be possible to use
SAMBA to print, SAMBA will not be able to show the status of some print jobs.
Comment 1 John Malmberg 2004-09-23 21:01:49 UTC
Forgot to set severity to Enhancement
Comment 2 Gerald (Jerry) Carter (dead mail address) 2004-09-24 05:40:25 UTC
John,  the 16-bit rap jobid is mapped internally to a 32-bit smbjobid 
(used by the spolss rpc printing calls).  Is this what you are referring to ?
Comment 3 John Malmberg 2004-09-26 10:44:17 UTC
I do not understand the term "rap jobid".  I am assuming it is the print job
number seen by the client.

If there is a one to one relation ship between the 32 bit smbjobid and the the
32 bit VMS host jobid, then the only problem should be of purging stale print
jobs from the queue.

It would indicate that the SAMBA print functions can only be used on print jobs
that were sent through SAMBA.  This could be a necessary restriction.

I posted this bug for VMS specific tracking as the last time I brought up the
issue on SAMBA-TECHNICAL, the indication was that VMS was the only platform that
had job ids that could not be mapped on a one to one basis to the SMB print job ids.

I did not get a bugzilla notification of your comments by e-mail even though my
preferences were set to get them.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2004-10-19 09:51:06 UTC
John, There is a one to one mapping between the host's jobid numbad 
and the allocated 32-bit smbjobid.  I don't understand what the 
problem is here.  What am I missing?
Comment 5 John Malmberg 2004-10-19 20:48:48 UTC
There may not be a problem.  I will not know until that section of code is
tested on the VMS port.  That is why I entered it as a tracking issue, as it was
a known (but not widely known) problem with previous SAMBA ports to VMS, and
previous discussions on the Samba Technical list that I took part in indicated
that it was not an issue on UNIX.  Apparently since that time it was found to be.

If SAMBA is maintaining a database of smbjobid's then it is likely that only the
print jobs submitted through SAMBA will be visible in it.  A system
administrator would not be able to use a Windows system to manage/monitor all
print jobs on a SAMBA host.  A user would not be able to see the status of a
print job that they did not submit through SAMBA.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2004-10-20 06:10:38 UTC
Based on your comments, I think everything will be ok for 
windows and unix print jobs.  If you run into problems let 
me know.
Comment 7 Gerald (Jerry) Carter (dead mail address) 2005-03-07 16:24:33 UTC
John, if this really is any issue, please reopen.  But so 
far everything looks ok.