- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: File Revision Number XAB$W_RVN (Fortran 90/77)
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 08:22 AM
тАО05-18-2009 08:22 AM
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-
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 09:00 AM
тАО05-18-2009 09:00 AM
SolutionThat'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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 09:19 AM
тАО05-18-2009 09:19 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 09:43 AM
тАО05-18-2009 09:43 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 10:01 AM
тАО05-18-2009 10:01 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 10:07 AM
тАО05-18-2009 10:07 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 10:11 AM
тАО05-18-2009 10:11 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
That is good advice.
I like that approach (using the hex values instead)...it fits into my general "work habits" well.
Much obliged.
-H-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 11:21 AM
тАО05-18-2009 11:21 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 11:56 AM
тАО05-18-2009 11:56 AM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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-
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-18-2009 02:39 PM
тАО05-18-2009 02:39 PM
Re: File Revision Number XAB$W_RVN (Fortran 90/77)
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"))