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 me know.
John, if this really is any issue, please reopen. But so far everything looks ok.