Are LANMAN job numbers limited to 16 bits?

[John E. Malmberg]

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