SAMBA V2.0.6-VMS0 for OpenVMS	 (VAX and Alpha)	04-Jun-2000

	Ported by John Malmberg <wb8tyw@qsl.net>

	based as an extension of previous ports by
	Eckart Meyer <meyer@ifn.ing.tu-bs.de>

	This is the V2.0.6-VMS0 release of Samba for VMS.

	Samba 2.0.6 for VMS should compile with DEC-C V6.0 and later,
	and possibly earlier versions.

	I expect that should run on all VMS systems from V5.5-2 on
	(VAX and Alpha).  Testing has been limited so far to OpenVMS Alpha 7.2.

	For the current status see:

	http://eisner.decus.org/~malmberg/samba/


========================= CAUTION =======================
This is the second release of Samba V2. The VMS port has
been almost startet from scratch again. Thus it may contain
new bugs... Using of this release for production systems
is not recommended.
=========================================================

========================= CAUTION 2 =============================
This port was done mostly independent of the previous 2.0.3 port
So it does not currently have feature parity.  Some 2.0.3 specific
options do not work.

However this release is basically feature and bug compatible with
the UNIX SAMBA 2.0.6 code.

I have only done testing with COMPAQ's TCPIP product, so the notes
on using Process Technology's TCP/IP stack are copied from the
2.0.3 release notes.
==================================================================
STATUS

	Supports UCX or UCX emulation of other TCP/IP packages.
	Tested with UCX. MultiNet, TCPware and Pathway are supported in command
	procedures. CMU/IP does not have UCX emulation and is therefor
	not supported.

	Developed on Alpha VMS V7.2 with DEC-C V6.0.

	Compiled on VAX VMS V 7.2 with DEC-C V6.0

	This release of Samba V2 the compiled objects will are linked against
	the FRONTPORT C runtime library shared image.  It is maintained as a
	separate distribution kit.

	The FRONTPORT C runtime library shared image can be used with the
	DEC C backport library or the DEC C shared image.  This is documented
	with the FRONTPORT C library documentation.

	While the AACRTL060 library is probably no longer needed on VMS 5.5-2
	I would still recommend using it.

	Samba for VMS can be downloaded in two flavours: The binary kit
	and the full source kit.

	Binary means object libraries, so they can be linked to the
	target system libraries (e.g. LIBRTL, LIBOTS).

USING BINARY DISTRIBUTION

	At this time, I can only provide binaries that have been tested on
	OpenVMS Alpha 7.2 and VAX 7.1 / 7.2.
	(VAX binaries untested, and NMBD.EXE_VAX has a link warning)

	Using earlier versions may require building from sources.

	Executables are not provided, only the objects. Extract the archive
	to a temporary directory.

	$ @LINK_SAMBA_VMS

	Proceed with ...

INSTALLATION

	See the file INSTALLING_SAMBA_VMS_2_0_6.TXT

	If you don't already have a time zone logical SYS$TIME_ZONERULE
	(or POSIX$DEFAULT_TZ), you must do so now. See the file
	TIME_ZONERULE.TXT for the format of that logical. Add the definition
	of the logical to SYS$MANAGER:SYSTARTUP_VMS.COM
	(or SYS$MANAGER:SYSTARTUP_V5.COM for older VMS versions).


	With this release SMBD is no longer linked against the system
	symbol table.  That is handled by the FRONTPORT library.  The
	installation for the FRONTPORT library makes sure that the executable
	is relinked automatically when the version of OpenVMS is upgraded.


MULTINET SUPPORT (Copied from previous versions)

	Samba seemed to work fine on a MultiNet V4.0 Rev A system.
	It is expected to work ok on a V3.5 Rev A or Rev B
	system; not necessarily on earlier MultiNet versions.

	No source changes are required for MultiNet support. The
	command procedures will automatically detect a MultiNet system.

	Make sure that UCX emulation is enabled:

	$ SHOW LOGICAL/SYSTEM UCX$DEVICE
		"UCX$DEVICE" = "BG:" (LNM$SYSTEM_TABLE)

	If this logical is not defined, then enable UCX emulation:

	$ MULTINET CONFIGURE
	NET-CONFIG> SET LOAD-UCX-DRIVER TRUE
	NET-CONFIG> EXIT
	(reboot)

	If you have questions on MultiNet, please ask Aaron Leonard
	of TGV <aaron@tgv.com>.

TCPWARE SUPPORT

	No source changes are required for TCPware support. The
	command procedures will automatically detect a TCPware system.

	If you have questions on TCPware, please ask Bernie Volz of
	Process Software Corporation <VOLZ@PROCESS.COM>.

PATHWAY SUPPORT

	No source changes are required for Pathway support. The
	command procedures will automatically detect a Pathway system
	(this package was formerly known as "Wollongong TCP/IP").

	If you have questions on Pathway, please ask Charles Don Hall of
	Attachmate <chall@eco.twg.com>.


USING THE CLIENT PROGRAMS

	SMBCLIENT	- Seems to work ok. Ignore some error messages
			  concerning "ioctl" for now...

	NMBLOOKUP	- Since it will send broadcast messages to the net,
			  this program must be installed with privileges if
			  unprivileged user should use it.

	SMBSTATUS	- shows a hexadecimal UID which is the complete
			  32-bit VMS UIC. The GID is the VMS UIC group number.
			  If an identifier exists for the UIC, the identifier
			  name is displayed instead.

	SMBPASSWD	- Works

	SWAT		- Untested.



BUILDING FROM SOURCES

	See the file BUILDING_SAMBA_VMS.TXT included with the source kit.


WHY SAMBA FOR VMS
[This chapter is now more than 3 years old. It may not reflect current status]

	There is Digital's Pathworks. It's not that expensive.
	The licensing policies for Pathworks V6 and V7 are even better
	than earlier versions.

	The Pathworks product is based on code and other information
	licensed from Microsoft Corporation.  Professional support
	contracts are available for it.

	With SAMBA for VMS, you are on your own for finding support.

	SAMBA is implemented both from published specifications for
	the LANMAN over TCP/IP protocol and from observing how the
	protocol works on the wire.

	SAMBA has client utilities for accessing shares on LANMAN
	Servers.

	SAMBA comes with complete sources so that you can examine
	what it is doing.  It is a great way to learn how the LANMAN
	protocols work.

	You can implement it on platforms that are not supported by
	the Pathworks product.

	There are no license fees with SAMBA.


	Some dissadvantages of SAMBA:

	SAMBA is TCP/IP only.  Pathworks supports NetBeui and DECNET
	protocols.

	The "COM" object product for Compaq OpenVMS requires Pathworks.

	External Authentication requires Pathworks.

	Interoperation with NT security domains is not as good as Pathworks.


PROCESSES and SECURITY

	SAMBA generally creates one process per SMB session. In VMS
	the process is created by the auxilliary server of the TCP/IP
	package (so called in UCX or Compaq TCPIP, this may differ for
	other packages - it's the same mechanism than UNIX' inetd).

	Each session can handle many connections and each connection
	can be established for another user (only if samba's security
	setting is not 'user'). The process "becomes" the process of
	the actual user by changing it's own username, UIC, privilege
	mask and identifiers for the time of the access (when idle,
	the process belongs to SYSTEM). This way the process has
	exactly the rights of the connected user. If a service allows
	for public access, the guest account may be used. The process
	name is changed to reflect the (netbios-) name of the connecting
	client.

	Generally SAMBA always uses the host's security mechanisms.
	SAMBA does not implement it's own security checking.

PARAMETERS

	Some recommendation for parameters:

	Please review the SMB.CONF_SAMPLE file.  The command files used
	for printing have changed.

	printcap name = /sys$manager/ucx$printcap.dat

		For UCX it's printcap file is o.k. For other
		TCP/IP packages I don't know. If it not present,
		create one.

	read prediction = yes

		Transfer from server is slightly faster for stream and
		fixed files. For variable record files this may slow down
		the transfer since the "prediction read" reads from
		1024 byte boundaries which causes seek calls. The seek
		routine for record files will have to rewind and re-read
		the files.

	[I am not sure on this effect on SAMBA 2.0.6 - J.E.M.]

	socket options = TCP_NODELAY

		If it is really used by UCX there seem no difference.

	read raw = yes

		Is 'yes' by default. Setting to 'no' slows down
		the transfer.

LOGICALS

	Some VMS specific parameters can be set with systemwide logical
	names. These logicals are normally set in SYS$STARTUP:SAMBA_STARTUP.COM

	SAMBA_SWAP_FILE_TIMES

		If present, swap VMS Creation Time and VMS Modification Time
		when presenting them to the client.

	SAMBA_ALTERNATE_DIRECTORY_PROTECTION

		If present, ignore VMS directory protection policy and
		unconditionally use samba specific settings from SMB.CONF
		This allows directories created with Delete-bit set.
	[For this release, this parameter is ignored.  The FRONTPORT
	 library will attempt to turn the O:Delete bit on for a directory
	 if a rename or delete is attempted from the SMBD process.]


	SAMBA_FILESPEC_ENCODE

		Controls encoding of file specification:

		0 or CHECK	- no encoding if EFS is present (ODS5)
				  not possible on VAX or VMS before V7.2
				  default on Alpha
		1 or ALWAYS	- always use encoding
				  default on VAX
		2 or NEVER	- never use encoding (disks must be ODS5)
	[See the FRONTPORT Library documentation also, as other logical
	 names from it will affect things.]

	SAMBA_CASE_ENCODE

		If present, case is encoded in the filespec so that it is
		preserved as seen by the client.
		[Ignored for this release]

	SAMBA_SMBD_OPTIONS

		Option to any SMBD process (in UNIX format, so enclose in
		double quotes).

	SAMBA_NMBD_OPTIONS

		Option to any NMBD process.

	SAMBA_ANNOUNCE_VERSION

		Set this logical name to true to get the additional
		information to display when reporting a problem.

	SAMBA_CVT_DUNDER

		For ODS-2 volumes, it suppresses file names with the
		double underlines from being decoded for file serving.


FILE FORMATS

	Files sent to VMS will always have STREAM format, unless a
	template for a different specification for that file extension
	exists in SAMBA_ROOT:[FILE_TEMPLATES]

	For large file transfers to VMS, make sure that the file is
	transfered as FIX format.  The other formats will not always
	work at the present time.  I do not know how large of a file
	that will have these problems.

	Stream:

		Client's "native" format. Valid for all types of files.
		Textfiles have a CR/LF pair as line terminator.
		The file's size will be reported correctly.

	Stream_Linefeed:

		The UNIX format. Binary files will appear correctly.
		On text files, each line is terminated by only one LF.
		Some programs may work, other may not (e.g. Windows' notepad).

	Fixed:

		Since the file does not contain any format information, this
		file format should be o.k. for binary files.

	Other formats:

		These are VMS specific and does not make much sense
		at the client.

FILE NAMES

	File names which contain characters not possible for VMS are
	converted using the same scheme that Digital's Pathworks uses:
	The character is converted to two underlines followed by the
	two character hex ascii code (this means that non-ASCII letters
	like german umlauts are NOT converted to lowercase).

	If the VMS disk uses the ODS5 file system, encoding is not needed.
	See logical names.

PRINT QUEUES

	This version of SAMBA follows the UNIX code for spawning a
	subprocess to execute print commands.  Work is currently
	being done in the main UNIX distribution to make it more
	like NT.

	It is not as efficient as previous versions of SAMBA-VMS but it does
	allow users to customize the command files for special items like
	TCP/IP relay queues.


BUGS
	ODS-5 and Case Preserving are not currently implemented in the
	FRONTPORT library.


	Probably still many unknown bugs...

