Are LANMAN job numbers limited to 16 bits?

[Greg Dickie]

errr how do you only get 255 from 8 bits?

Greg

On Sun, 28 May 2000, John E. Malmberg wrote:

> Date: Sun, 28 May 2000 14:41:38 +1000
> From: John E. Malmberg <wb8tyw at qsl.net>
> To: Multiple recipients of list SAMBA-TECHNICAL <samba-technical at samba.org>
> Subject: Re: Are LANMAN job numbers limited to 16 bits?
> 
> James Sutherland <jas88#cam.ac.uk> wrote:
> 
> > On Sun, 28 May 2000, John E. Malmberg wrote:
> >
> > > Hello SAMBA experts,
> > >
> > > Examining the source code for printing in SAMBA 2.0.6 shows that the
> > > messages generated to contain print job numbers only have room for 16
> bits.
> > >
> > > Of this, SAMBA is only preserving the bottom 8 bits of the job number
> and
> > > encoding the service number in the upper 8 bits.
> > >
> > > This leaves me in a quandary.  On OpenVMS, the job number is 32 bits.
> This
> > > job number is unique with in all queues in a cluster of systems.
> > >
> > > Passing a truncated job number to a delete job command could have
> disastrous
> > > consequences.
> [edit]
> > > section so any suggestions?
> >
> > How about just keeping a bidirectional mapping of Samba 16-bit job numbers
> > to OpenVMS 32-bit ones? This will limit you to "only" 65536 queued Samba
> > jobs, but that shouldn't be a problem.
> 
> As I just mentioned, Samba is only using 8 bit job numbers, so only 255 can
> to be tracked.  It is possible and even probable on most systems that would
> be sufficient to track all files.
> 
> This of course presumes that the user would get a listing of print jobs
> before they attempted to delete them. :-)
> 
> Scanning even 50 potential print jobs each time a request is made could be
> bad for performance.
> 
> What mechanism would be used to track when a specific mapping is no longer
> needed?
> 
> This presenting of fake job numbers to the client also can be a problem for
> help desks as the job number the Windows user is seeing is different from
> the one that the Help desk support people are seeing from the host operating
> system.
> 
> This mapping would have to be stored on disk, since multiple systems in a
> VMScluster could be servicing requests.  If the session get's broken from a
> time out or other event after the mapping was created, the delete job
> request could get serviced from another node in a cluster.  This also means
> that the file would be potentially updated from multiple sources and that
> complicates things with locking code.
> 
> 
> I have not seen SAMBA configured to use a common IP address for all systems
> in a cluster, but I see nothing in the code to prevent it from working that
> way for a high availability configuration.  So existing SAMBA-VMS sites may
> already be in that configuration.
> 
> 
> A VMS cluster can consist of over 200 systems sharing disk storage, over an
> area of over 100 miles.  I know it is probably unlikely that a system of
> that nature would be doing file serving directly to PC clients, but who
> knows?
> 
> 
> One solution is to change print command to invoke a script that changes the
> job name after the print job is scheduled to contain the lower 8 bits of the
> job number.
> 
> The other scripts would then have to check all of the jobs on that queue to
> see if the name matches the job name to obtain the target job number.  A bit
> on the CPU intensive side.
> It runs the chance that a user might actually submit a job with the same
> naming convention.
> The SAMBA client would not be able to manipulate jobs that were not
> submitted through SAMBA.
> 
> It would also mean that every time a version of SAMBA is ported to OpenVMS,
> the job numbering convention may need to be verified.
> 
> -John
> wb8tyw at qsl.network
> 

---------------------------------------------------------------------
Greg Dickie
Just A Guy
greg at discreet.com