RAB on VAX and Alpha

[Vir Thanvi]

I copied a file (Binary) from VAX to Alpha and observed that the blocks allocated to the file had changed and also some of the record properties. I tried to open that files through FORTRAN code [in which there are calls of SYS$GET(RAB)] on Alpha machine and did not get any success. During debugging, I observed that the values of RAB.RAB$xxx parameters were different on VAX and Alpha Machines and that is where the code was failing.
Is it because the structure RABDEF is different on VAX and Alpha?
How can use VAX RABDEF on Alpha machine?
Is there a different way of copying the file from VAX to Alpha to save the attributes?

[John Gillings]

Vir,

Allocated blocks might change if the cluster size was different, but nothing else should have changed. How did you copy the file? What does DIR/FULL look like on old and new files?

RABDEF on Alpha is different from the VAX version, but that's mostly to do with Alpha new features (like 64 bit support), and there may have been some alignment tweaks. It shouldn't affect your program unless you're using hard coded values to find stuff in the RAB, rather than symbolic names from $RABDEF.

For this kind of issue, you're probably better off logging a case with your local customer support centre (too much question & answer required for a web forum).

[Hein van den Heuvel]

Stop worrying about the RAB, start worrying about the copy.

>> I copied a file (Binary) from VAX to Alpha

How? Judging by the word 'Binary' you use FTP. Yikes! That'll munge a file, unless it is fixed-length 512.


>> Is there a different way of copying the file from VAX to Alpha to save the attributes?

Yes.
1) DECNET!
2) Wrap it in a backup or zip container first, then transfer that, and unwrap.
3) Lie!... note down record/file attributes. Change to RFM=FIX,LRL=512,MRS=512,ORG=SEQ.
Transfer (COPY/FTP?).
Reset to original attributes.

> Is it because the structure RABDEF is different on VAX and Alpha?

No it is not.

> How can use VAX RABDEF on Alpha machine?

No need. Just compile and go with the Alpha libraries.

Good luck,
Hein.

[Vir Thanvi]

All right folks,

I apologize for providing less info. The point when I posted the query, I had a blank to start with, but after that I did couple of experiments and still NO success.
1. The Binary file is a record sectors file created by organizing binary segments into a set pattern (e.g. one chunk of data from one binary segment, other from second segment, and so on).
2. I copied the file over DECnet from VAX machine to Alpha machine. Both machines are in cluster.
3. The ANALYZE/RMS_FILE for both files (bucket size and record length, etc.) are identical except that the allocated blocks are more on Alpha. I don't know why?
4. I tried modifying the attributes of copied file, but still did not work.
5. I am still searching the code to determine if RAB values are hard-coded anywhere. None found so far.

I will post more facts until you guys can provide me a great answer. Thanks a lot to all who devoted precoius time and effort on this issue.

[Antoniov.]

Hi Vir,
I copied in the past binary files from vax to alpha without problem. I used DecNet and file on alpha had different allocation size due different parameters on alpha disk (allocation unit).
I also recompilated by old vax source on alpha vms (in 1996) and they worked fine. I still use RAB and I don't remember of any modification of structure.

I guess you can try with VEST, just for seeing what it happens.
You have to look carefully at fortran qualifier because the major trouble in porting is different alignment between the two processors.

Antonio Vigliotti

[Willem Grooters]

Both Hein and Antonio gave good clues.

Copying files using FTP is a big cause of trouble unless the file is stricktly sequential. Relative _might_ do if the record size is EXACTLY 512 byets and even then I wouldn't trust it; for indexed files, it's a disaster. The only way to do it right is indeed to warp it, copy the result binary and unpack afterwards. Writing down the file and record attributes is always a good idea to check afterwards. (ana/RMS/FDL/OUT=(file) and copying the FDL file will do the trick as well, and may save a lot of trouble: a FDL file is plain ASCII).

Note, and that's right of Antonio, you may need to consider your IO on Alpha. Alignment matters (even more on Itanium, BTW). So it might be useful to check your FORTRAN program

[Edwin Gersbach_2]

Vir,

To make shure that the problem is not caused by copying the file, you may try to access the datafile on the Alpha with the program on the VAX using the NODE::DEVICE:[DIR] syntax and the reverse, using the VAX datafile from the Alpha executable.

I rather expect a alignment problem. Check the /ALIGNMENT swich on both vax and alpha to see the defaults and use the right switch on the Alpha to be compatible with the VAX.

You may use the debugger to check the size of each field making up the file record or create a test program out of your application containing all the fields used to create the data file. Add code to display the actual size of each field and compile/link/run the testprogram on both architectures.

Edwin

[Hein van den Heuvel]

>>> 3. The ANALYZE/RMS_FILE for both files (bucket size and record length, etc.) are identical except that the allocated blocks are more on Alpha. I don't know why?

John G already explained this: Cluster size.
The allocted file size MUST be in whole multiples of the cluster size. The unit of allocation is the cluster. two simple examples:
VAX: cluster size 3, used blocks 4 --> alloation is 2 clusters = 6 blocks.
ALPHA: cluster size = 19 --> allocation is 1 cluster = 19 blocks.
but if the ALPHA uses the new, larger then 1m bitmaps, the cluster size migth be 2 and the allocation can be 4.

fwiw,
Hein.

[Vir Thanvi]

Hi Guys,

I think Hein just nailed the heart of the issue. After more system level analysis, I figured out that the cluster size on my VAX and Alpha machines are different. This explains different bucket size and allocated blocks. As I am a programmer, my system level skills are not that strong. I would highly appreciate if someone can post some lines about how to modify cluster size for file/directory/system on my Alpha machine to match with that on VAX. I am 90% sure, this will fix my problem. Any help is highly appreciated as always.

[Willem Grooters]

Changing clustersize is fairly straigtforward, providing you have a spare disk of at least the same size: you cannot change the clustersize of a disk once it has been initialzed. INITIALIZE will determine the default clustersize based on capacity of the disk: The bigger the disk, the grater clustersize. Of course (as usual on VMS) you can override the default....

With that, it's not that difficult:

1. $ SHO DEV/FULL and note the clustersize
2. $ INITIALIZE/CLUSTER_SIZE= . This will recreate a number of system files and set the clustersize to what you specify.
3. $ MOUNT/FOREIGN
4. $ BACKUP/IMAGE/NOINITIALIZE to get all data from the old disk to the new one. /NOINIT will NOT initialize the disk (to the default of that size) - just what you need.
5. $ DISMOUNT
6. $ MOUNT (/SYSTEM if you wish)

You could now dismount OldDisk, and re-label the sparedisk. Eventually, relabel the olddisk before mounting the sparedisk, you can then relabel it to the Olddisk's label.

Without a spare disk, you have to make a backup of the disk first (to tape, presumably). Then, do as above, (read OldDisk for sparedisk) and copy files (step 4) from the backup(tape).