File Revision Number XAB$W_RVN (Fortran 90/77)

[HDS]

Hello.

I am working with Fortran-90 and 77 on an ALPHA VMS V8.3 system.

There exists a file whose revision number is 52262. (See attachment for $DIRECTORY/FULL)

According to $XABDEF, the revision number is in an I*2 field. (XAB$W_RVN)

STRUCTURE /XABDEF/
BYTE XAB$B_COD ! xab id code
BYTE XAB$B_BLN ! block length
INTEGER*2 %FILL ! (spare)
INTEGER*4 XAB$L_NXT ! xab chain link
INTEGER*2 XAB$W_RVN
INTEGER*2 %FILL
.
.
.


A revison number of 52262 is more than can be held within an I*2 field.

Am I misunderstanding something?
Are revision numbers now INTEGER*4, where XAB$W_RVN kind'a bleeds into that next I*2 filler field?

I do find that I can reference it as an I*4
by moving it into another (I*4) variable as follows:

882: C Get Revision #
883: CALL LIB$MOVC3(4,RDTXAB.XAB.XAB$W_RVN,REV)
884: WRKBUF = 'NONE'
885: WRITE(WRKBUF,FMT='(I5)')REV
- OUT -output------------------------------

data TEST\TEST\REV
address: 262156
atomic type, longword integer, size: 4 bytes

TEST\TEST\RDTXAB.XAB.XAB$W_RVN: -13275

stepped to TEST\TEST\%LINE 884

TEST\TEST\REV: 52261


Note that I moved "FOUR" bytes of XAB$W_RVN (not TWO) into the I*4 variable named REV.
REV now contains the actual revision number of 52261.

Have revision numbers recently been expanded to allow for values greater than (2**31)-1 ? (>32,767)

Is there some place other than $XABDEF where
the RVN is defined ?

If not, is it reliable to treat XAB$W_RVN as an I*4 (its I*2 PLUS the I*2 FILLER) ?

Many thanks....

-Howard-

[Hein van den Heuvel · Accepted solution]

Revision numbers are 16-bit UNSIGNED.
That's all.

INTEGER*2 is the wrong way to express that. I know, not your choice, but it's wrong.

Like you indicated, just move those 16 bits to a large int, using MOVC3 or using a Fortran COMMON will solve that.

But why bother? RVN's wrap aroudn and you can detect change just as easily by comparing negative numbers.

What problem are you really trying to solve?!

It is relatively rare to try do something useful with them in Fortran.

Just use DCL F$FILE(x,"RVN") ?

You are not confusing VERSION numbers with Revision numbers right?
VERSION numbers have a hard stop.
RVN's just roll over and over as needed.


Hope this helps some,
Hein.

[HDS]

Hello.

Thank you. This is the answer...I suppose. Although, I am not sure how a revision number of 52k+ can fit into a 16bit unsigned 2-byte word. But, I suppose it is what it is. I guess that internally, it may display that 52K revision number based on the negative value...or something.

Your validation that referencing it as (or moving it into) a 4 byte field supports what I believe I am seeing.

As for the "VERSION"/"REVISION"...
I am not using this in lieu of the version number. In short (and I realize that this may invoke more questions than it may answer), I am using a fortran routine to compare a bunch of information from the file (including, but not limited to) the revision number to see if the file had changed in any way. I am using this as sort of a "fingerprint" of a series of RMS files that comprise a sort of database, you might say. The "fingerprint" of all of a DB's files are quickly obtained and compared against another earlier fingerprint. This comparison is quick and will identify that a file had changed. (With the understanding that none of them are currently open with WRITE access.)

This method is far faster than a checksum or a BACKUP/COMPARE or a $DIFFERENCE or the like. It makes note of the following fields of a file and identifies if any have changed since the last time it was checked:

C Fields being included
C ---------------------
C File Created Date
C File Revised Date
C File Revision #
C File Organization
C Record Format
C Maximum Record Size
C Longest Record Size
C Record Attributes
C Number of Keys(Indexed Files Only)
C Number of Areas(Indexed Files Only)
C ---------------------

The above values are checked in addition to any changes in the filly qualified name, including the version number.

Thanks again for your help. I am grateful.

-Howard-

[Hein van den Heuvel]

Revised-date is a superset of all.

CDT + RDT is more than enough.

FID should be and interesting addition/

Things like RVN and ALQ are interesting, but not conclusive.

keys, record format and other attributes can not really be changed (legally).
The only attribute you list which can legally change is LRL... but that's rare to change after a file has been in production for a while.

2 bytes = 16 bits = 2*16 -1 = 65535

So 52261 will fit.


Thanks for explaining the reason behind the question!

Hein

[HDS]

2 bytes = 16 bits = 2*16 -1 = 65535
So 52261 will fit.

Hmmm.....

Here I am reading it as though 16 bits would hold (2**15)-1 = 32767

Nonetheless, I cannot dispute what I am seeing. This must be because it is unsigned (as you stated in your initial response). How quickly one forgets. I am using that high-order bit as the sign...my bad.

I thank you for that additional information on the XAB fields. I will discuss your suggested adjustments with my group.

And, additionally, I thank you for the refresher in reading bits. Its funny...those times that you swear you know what your seeing is wrong yet it is what you are seeing so it must be right :)

Be well...

-H-

[Mike Kier]

You'll run in to this fairly often if you use Fortran for dealing with VMS structures, since the language lacks an unsigned data type.

As Hein says, for most uses, one need not be concerned with negative values. It is usually only the human display of it that causes issues.

I do a lot of system/RMS programming in Fortran and I tend to output any of these types of values using a Hex format specifier (or the equivalent using $FAO, or EXAM/HEX under Debug) - you don't see a negative value, the output is generally more compact than decimal, and you can easily determine the state of any specific bit.

[HDS]

Thank you.

That is good advice.
I like that approach (using the hex values instead)...it fits into my general "work habits" well.

Much obliged.

-H-

[Hoff]

Seems like you're rolling your own MD5-like scheme.

Something akin to CHECKSUM /ALGORITHM command or your own MD5 or SHA-1 or SHA-2 tests or the CDSA pieces and tools, depending on what sort of problem you're defending against.

The MD5 source code is openly available in C as are other options, and there are various and better signing and cryptographic hashing tools around.

Another caveat here: tying checksums to the FID can get you in trouble after a BACKUP /NOIMAGE restoration; you'll either want to avoid that, or you'll need to roll some sort of FID recovery processing scheme for use when that (or a file or directory restoration from a BACKUP or a COPY, for instance) happens.

[HDS]

Oh my...

I thank you for that information...Looks like I have some reading to do. We were intentionally trying to avoid checksumming or hashing ...and, for the purposes of this specific case where we use these file-info "fingerprints", we are reasonably and predictably okay without having to use hashes. (There is much information behind our reasoning to use and acept this file info fingerprint approach.)

It is understandable that there'd be a need to use certain known methods for hashing algorithms...just not for this specific purpose.

That said, I will do some further research to see if the means [that you mentioned] would serve us in other ways.

This is a tangent to my original inquiry, but is helpful information nonetheless. For that, I thank you.

-Howard-

[John Gillings]

Howard,

I've done something similar in DCL for detecting changes in files without having to read the whole file. There are many files I want to keep track of, and a full MD5 or similar, cryptographic grade checksum just isn't practical.

Yes, I realise that there are tricky ways that the file could change without being detected, and yes, I'm sampling (far!) more attributes than I really need, but that doesn't really matter.

My "fingerprint" (and I've even used the same term) is a concatenation of file attributes DVI, FID, Name, OWNER UIC, EOF, FFB, RDT and CDT. For image files I also add link time, image ident and build ident.

For your purposes, you really don't need to worry about the value or interpretation of RVN (or any other field). You don't care if it's signed or unsigned, all you're interested in are the bits. Equal or not-equal. Indeed, you could treat it as I*4 if that's more convenient, as long as the filler is invariant.

Assuming the common case is no change, Concatenate all your attributes and compare the whole string in one hit. If they don't match, then you can worry about which attribute changed.

DCL extract:
$! Calculate the fingerprint, start with atributes for all files
$!
$ finger=F$FAO("!''KeyLen'AS|!AS|!AS|!UL|!UL|!AS|!AS",-
F$FILE(File,"DVI")+F$FILE(File,"FID"),F$PARSE(";",F$SEARCH(File)),F$FILE(File,"UIC"),-
F$FILE(File,"EOF"),F$FILE(File,"FFB"),F$FILE(File,"RDT"),F$FILE(File,"CDT"))