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.
Forgot to set severity to Enhancement
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 ?
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.
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?
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.
Based on your comments, I think everything will be ok for
windows and unix print jobs. If you run into problems let
John, if this really is any issue, please reopen. But so
far everything looks ok.