Apocalypse 32767
It's here! Today is the much anticipated and much over-hyped Mayan Apocalypse. Thus far — and this day is nearly complete — today's prognostications have turned out to be more apocryphal than apocalyptic. However, for one of my clients, today was not so uneventful. They had experienced an apocalypse that was not manifest in the numerology of the ancient Mayan calendar; their apocalypse was rooted in the stored binary numerics of the OpenVMS file system. Yes, they hit the OpenVMS file version number limit.Generally, a file attaining the OpenVMS file version limit — 32,767 — is not the end of the world! It can certainly be a nuisance but it's usually not nefarious. As it was in this case, it was primarily a nuisance; however, the files in question could not just be deleted, nor could they be purged away and the remaining files renamed to version one. Some of these files contain transaction data which the client needed to maintain. Only after an established period of time could these files be purged away with a
DELETE/BEFORE... or a PURGE/BEFORE... command. So, what was needed was a way to rename a collection of files with the oldest file being renamed back to version ;1 and then, through subsequent versions to account for the newer files as they had been created before the version apocalypse.The problem here is that the OpenVMS
RENAME command cannot wildcard rename a collection of files. RENAME can reversion a single file name to back to version;1 but it cannot or will not accept a wildcard version number in its input file specification to rename a glob of files. The client was faced with a daunting task of renaming hundreds of files manually to maintain the required archive of these transaction data files as well as to maintain their chronological order. One other aspect of this exercise was that there could be holes in the file version number continuum. Some files, if a transaction did not complete, would be deleted.My first thought was, "Somebody must have written a DCL procedure to do this very thing." So, I consulted Google with hopes that it could find a DCL procedure to provide my client to a quick solution to their dilemma. Google turned up several promising links but when I reviewed the DCL code, I was underwhelmed. None of the procedures I reviewed would handle a wildcard in the file name specification. This was paramount because this wasn't just a single file name needing reversioning; there were hundreds of file names needing reversioning! There was only one solution. I'd have to write such a procedure myself.
The first hurdle to tackle was the possibility of "holes" in the version number continuum. I thought about this for a while and then, realized that it really wasn't a problem if I could sort the files that needed to be renamed in a fashion that would present the files in chronological — with respect to the version number — order. The OpenVMS
SORTcommand should be perfect for this; however, there was one catch. The OpenVMS DCL SORT command, applied to file name, would sort based on an ASCII collating precedence. What would this mean? It meant that the files FILE.EXT;10 and FILE.EXT;11 would collate before the file FILE.EXT;2. This simply would not do. Fortunately, because I've spent several decades with the OpenVMS file system, I knew a few useful tricks. For example, the version number of the file can have leading zeroes, and RMS and the file system will still handle them correctly. So, I set out to format the file names in question with leading zeroes.
"''F$parse(F$fao(";!5ZL",F$integer(F$parse(FILE,,,"VERSION")-";")),FILE)'"
The above would take the current file name and prefix its version number with zeroes. From a pure ASCII collating perspective, this would allow the OpenVMS DCL
SORT command to properly collate the list of files. This is also an example of another practical use of the F$fao() (F$ForgottenAvoidedOverlooked) lexical function.The rest of the task at hand was pretty straightforward complements of simple exploitation of the OpenVMS DCL lexical functions. The first thing to do was to
F$parse() a provided file specification. Yes, even wildcarded file specifications. Then, the F$search() lexical availed itself to find the actual file names which needed to be reversioned. These commands were then placed in a loop, allowing the procedure to traverse files within a directory and to even traverse directories. The collected file names were written to a temporary file with a named created using the F$unique() lexical. When the F$search() loop was exhausted, the file was closed.Now, the procedure only needed to invoke the OpenVMS DCL
SORT command to order all of the files written to file containing the file names which were scanned with F$search(). Because these files were written with a version number that was extended with leading zeroes, the files would all be collated in the proper sequence for renaming.It was now time to address the required task. The previously assembled file was opened and read. Each record read is the full file specification of a file which needs to be renamed to a new version number. This was another simple task, complements of the
F$parse() lexical. A DCL symbol containing the current reversioning version number is passed, along with the file name, to the F$parse() lexical to compose the RENAME target output-filespec. The result — a short and simple DCL procedure which can rename any supplied file specification containing any acceptable wildcard patterns back to version ;1.Here is the download link for the complete DCL source code of the described REVERSION.COM procedure.
Post Scriptum
Post apocalypse, the REVERSION.COM procedure has been modified to accept an optional
/LOG qualifier. The procedure, in order for this new, optional /LOG qualifier feature to function as intended, must first be defined to be executed from a DCL symbol.
Frontpage
