[Info-vax] XQP File Versions (was: Re: What does VMS get used for, these days?)

[Stephen Hoffman]

On 2022-11-06 18:18:29 +0000, Robert Carleton said:

> Going a slightly different way, does files versioning help relieve the 
> programmers from some of the work necessary to roll back a corrupted 
> dataset when something goes wrong with their job? In the IBM world, 
> they talk about the production control analysts managing the batch 
> processing. I suppose file version control might be one of the tools 
> that they use, maybe in organizations that have a lot of duty 
> separation.

For small stuff, sure. XQP file versions can and do work. For more 
complex code changes as tend to be typical, file version rollbacks get 
gnarly as most change sets lack a consistent number of versions for a 
set of related code changes across a selection of files. Rolling back 
changes with file versions then means finding the right group of file 
versions. Which is usually not ;-1 or ;-2 across all of the various 
files involved in the source code change.

XQP file versions also tend to need explicit management, and version 
cleanups can be hazardous for the practices used at some sites. And 
there's no good means to clean up intermediate file versions between 
those that a developer might wish to preserve.

IBM Rational Clearcase VOB is a very nice implementation of file 
versioning for app development, though that never really caught on more 
generally. The VOB presents a build or version or baselevel or whatever 
a developer or development team might call a collection of related 
source code changes, as a synthetic file system as a view from within 
the DVCS. The usual implementation here is based on a FUSE, which is 
fairly commonly feature available. There are undoubtedly some other and 
analogous implementations to VOBs, too. Switch the build or version or 
whatever, and the (virtual, synthetic) part of the file system you're 
looking and working within switches to what that build or baselevel 
would look like.

For the development projects I'm typically dealing with, pushing 
changes to the local DVCS is the usual approach when building stuff and 
is integrated within the IDE, and that makes rollbacks easy. Once ready 
to share, the code gets pushed from local into general availability. 
Getting better support in LSEDIT might help some, and other folks can 
choose to use VSC as that gets better integrated. If you're not using 
an IDE, then you're probably going to be getting familiar with git 
command line syntax.

As a competitive feature, I suspect there'd be much more interest in 
integration with git or hg and with common IDE such as VSC than with 
the existing file versioning scheme. But sure, XQP file versioning does 
work for smaller efforts and smaller pools, and it does work when the 
developer and the local tooling is lacking. (Which it kinda is lacking, 
on OpenVMS. VSC and VGIT only gets you so far. The current compiler 
overhaul will absolutely help, as that becomes available. And that'll 
then help with better VSC integration, too.)

As for rolling back a database, that and usually some form of 
integrated backups are part of pretty much any production database.  
XQP RMS has some gaps here, as BACKUP is not integrated, as version 
rollbacks are not integrated, and RMS journaling is not widely 
deployed, and few apps I've worked with are integrated with host-based 
RAID-1; with HBVS.

There are also some details around app scaling too, as a number of 
OpenVMS production apps around could probably be re-hosted over onto a 
big laptop, too. This in terms of storage and memory and processor 
performance—less so features, though that can be debatable. In terms of 
capacity and performance, any of the Itanium servers aren't all that 
big, by 2022 standards. NVMe/NVMe-oF/CXL/TB/USB4/etc I/O is just stupid 
fast. And obviously, VSI is and will be working on this support, 
virtualized or paravirtualized or otherwise, or eventually native.

XQP file versions have been around for over forty years, so probably 
not going to be a big draw for new apps and new developers. Not 
compared with git or hg or VSC or recent compilers or other of what are 
increasingly considered "table stakes" features.

If file versions are your marketing in an era of near-ubiquitous and 
increasingly-integrated DVCS support for developers, and for production 
rollbacks, you're going to find yourself in some comparisons and some 
discussions.

Full disclosure: I've done exactly these XQP file version rollbacks 
several times over the past couple of years. The astute reader might 
wonder why those same environments were not under source code revision 
control, but that's fodder for other discussions. That written, I've 
done more rollbacks via DVCS, for those environments that are under 
revision control.




-- 
Pure Personal Opinion | HoffmanLabs LLC