From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: RE: Wrong version number assigned
Date: 14 Oct 92 03:32:49 GMT
Article-I.D.: uu3.9210140334.AA24561
Distribution: world
Organization: The Internet


	This is probably a FAQ but what the heck.

I very much doubt it!

						   Occasionally I have a
	problem with file version numbers being wrong.  As I have noticed it
	most often with FTP, I will use that as an example.

There are at four common TCP/IP implementations for VMS, plus most likely
other less-common ones, each with its own FTP.  You'll have to be more
specific about which one you are running if you want a specific response
(though I give a generic response below).

	FTP to remote system.
	Start transfer of file.
	Get about half when timeout occurs.
	FTP to remote system again.
	Start transfer of file.
	Timeout occurs again.
	Give up for awhile.
	.....
	Do dir. Two versions of file are present ;1 and ;2
	Sometime in here a purge is done. 
	Now only ;2 is present.
	FTP to remote system.
	Start transfer of file. 
	Yipes! It completes.
	Disconnect.
	Do dir.  Now have two versions again. ;1 and ;2! With ;1 being the
		last complete file!
	Hopefully awake enough to recognize disparity and not do PURGE but
		delete ;2

It's not hard to explain how this might happen.  I'm assuming the other end is
also a VMS system.  I think what's going on is that the final transfer is
using the full specification of the remote file, including the version number.
That version number happens to be 1, so you get a new version 1, along with
the old version 2.

How, then, did you get a version 2?  Perhaps the earlier transfer was done
with a slightly different FTP command - MGET vs. GET, explicit output spec
vs. fully defaulted, who knows.  Or perhaps your FTP is being too clever:
It tries to preserve the file version number, but if it gets a conflict for
the specific version it needs, it creates a new version of the file.  The
only way to find out - since such stuff is rarely documented in full detail -
is to try some experiments.

	I have seen this problem when editing a file where it will start over
	with ;1 and I think it happened with rename once.

All it takes is an explicit ;1 on the output file.  I know of no way for it
to happen without that - and I've never seen it happen without that.

	Yes, I have double, triple and quadupled checked.  The filenames are
	the same.  I even did a purge by the filename, and all that was left
	was the lastest incomplete one.  Here is an example.

	REDUNTENTA.LIS;2        186  12-OCT-1992 22:06:32.89
	REDUNTENTA.LIS;1        313  12-OCT-1992 22:11:40.28
                             ^^^^^^^^^^^^^^^^^^^^^^^
	Sure looks like to me that ;1 is a later version than ;2.  

Nothing in VMS guarantees that the highest version number belongs to the most
recent version of the file.  However, as long as you create files by handing
the file system a file spec without a version number, or with a version number
of just ";", it will create a new version higher than any existing one - and
indeed the versions will be ordered in time.

	So, does anyone else see this problem? or should I just cut back on
	the caffine?

There MIGHT be some odd corner in your FTP's file spec handling, but my bet
is "foot on gas, not brake".
							-- Jerry