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).

[Hein van den Heuvel]

Now that we explained the allocation size differences we need to go back to the basic problem, because for 99.99% of the usage the allocation size should have no impact what-so-ever. It is relatively common so significantly over-allocate VMS file to avoid costly extents. The reason you did not know about cluster size is that is normally does nto matter at all. It is just used during allocation and shoudl remain transparant otherwise.

"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"

What did you get? What specific RMS call did not get success? SYS$OPEN? SYS$CONNECT? SYS$GET? Was there an error status?
Can you get the full RMS error status? (RAB$L_STS + RAB$L_STV)

Fortran programs typically use native fortan file IO, not touching RABs. TO help understand the problem it may help to know why the program (thinks it) needs SYS$GET calls. May we assume that you were using a FOR$RAB to get to the RAB address? Other magic. It would not surprise me if there were minor variant in points / functions around obtaining a rab address when going from VAX to Alpha. When you look into the RAB (and FAB) does it look at all reasonable? Starts with @FAB=0x5003 and @RAB=0x4401 for a valid BLN+BID?

hth,
Hein.

[Vir Thanvi]

Hello Folks,

I highly appreciate all your help, but I am still in the pit. I cannot modify the cluster size since I have only one disk on my machine. Second, I have been thinking on one of the responses that the problem might be at SYS$OPEN and SYS$CONNECT calls rather than SYS$GET. I am planning to post the RAB outputs from VAX and Alpha later today. I hope that will give you all a better in-sight. The issue has become so critical that my job stability is now questioned over this. I will truly appreciate any help. Thanks a lot.

[Vir Thanvi]

Hi Folks,
Please find attached the RAB output dumps from VAX and Alpha machines and provide your inputs ASAP. Thanks a lot for your help.

[Vir Thanvi]

I am retrying the attachments.

VAX:
! RAB$B_BID: 1
! RAB$B_BLN: 68
! RAB$W_ISI: 5
!
! (1): 5
! (2): 0
! RAB$L_ROP: 1048584
!
! (1): 8
! (2): 0
! (3): 16
! (4): 0
!
! (1): 8
! RAB$B_ROP1: 0
! RAB$B_ROP2: 16
! RAB$B_ROP3: 0
! RAB$L_STS: 65537
! RAB$L_STV: 0
! RAB$W_STV0: 0
! RAB$W_STV2: 0
! RAB$W_RFA
! (1): 1
! (2): 0
! (3): 0
! RAB$L_RFA0: 1
! RAB$W_RFA4: 0
! RAB$L_CTX: 0
! RAB$B_RAC: 1
! RAB$B_TMO: 0
! RAB$W_USZ: 8648
! RAB$W_RSZ: 8648
! RAB$L_UBF: 118597
! RAB$L_RBF: 118597
! RAB$L_RHB: 0
! RAB$L_KBF: 118589
! RAB$L_PBF: 118589
! RAB$B_KSZ: 4
! RAB$B_PSZ: 4
! RAB$B_KRF: 0
! RAB$B_MBF: 4
! RAB$B_MBC: 51
! RAB$L_BKT: 0
! RAB$L_DCT: 0
! RAB$L_FAB: 3810592
! RAB$L_XAB: 0

ALPHA:

! RAB$B_BID: 1
! RAB$B_BLN: -112
! RAB$W_ISI: 1
! %fill: 1
! RAB$L_ROP: 1048584
! %fill: 1048584
! %fill: 8
! %fill: 8
! RAB$B_ROP1: 0
! RAB$B_ROP2: 16
! RAB$B_ROP3: 0
! RAB$L_STS: 65537
! RAB$L_STV: 0
! RAB$W_STV0: 0
! RAB$W_STV2: 0
! RAB$W_RFA
! (1): 1
! (2)-(3): 0
! RAB$L_RFA0: 1
! RAB$W_RFA4: 0
! %fill: 0
! RAB$L_CTX: 0
! RAB$W_ROP_2: 0
! %fill: 0
! RAB$B_RAC: 1
! RAB$B_TMO: 0
! RAB$W_USZ: 8648
! RAB$W_RSZ: 8648
! RAB$L_UBF: 524797
! RAB$L_RBF: 524797
! RAB$L_RHB: 0
! RAB$L_KBF: 524789
! RAB$L_PBF: 524789
! RAB$B_KSZ: 4
! RAB$B_PSZ: 4
! RAB$B_KRF: 0
! RAB$B_MBF: 4
! RAB$B_MBC: 51
! RAB$L_BKT: 0
! RAB$L_DCT: 0
! RAB$L_FAB: 8809472
! RAB$L_XAB: 0

[Hein van den Heuvel]

Thanks for the detailed output Vir, but unfortunately I can not spot a problem so far.

The main difference visible is RAB$B_BLN

Vax = 68 = RAB$C_BLN

Alpha = -112 = 144 as a signed byte = RAB64$C_BLN64

So the Alpha RAB is a RAB64, but that should be fine since the extention fields that come with that are only used if the corresponding base fields (like RAB$L_UBF) contain -1.
IN your case those all contain a normal valid 32 bit address. Those addresses are different form the VAX, but that is to be expected.

MBF and MBC are a little odd, but the some and should be transparant anyway.

I would have expected the ISI to be the same.
The ISI is returns by the $CONNECT, so it looks like the $OPEN and $CONNECT worked. Normally they are pretty much handed out in serial order. So the 5th file gets isi 5, and I would expect that order to have stayed the same between vax and alpha. You may want to verify that the isi is the correct value, but normally software does not play with that... is not supposed to play with that.
If one overrides the 5 with a 1, then RMS will 'blindly' start operating on the file that received isi=1.

Good luck!
Hein.

[Vir Thanvi]

I Know you all are trying hard to help me and I highly appreciate it. I dumped the values of FAB and RAB right after OPEN and CONNECT. May be this will help a little bit. Please remember that the files was simply copied over from VAX to Alpha without any fancy stuff. I understand that Allocated blocks for the files is decided by the cluster size of Machine, but I am observing 368640 blocks allocated on VAX and 368667 blocks allocated on Alpha. This is really getting a tumor in my brain.

FAB ON VAX at SYS$OPEN

! FAB$B_BID: 3
! FAB$B_BLN: 80
! FAB$W_IFI: 5
!
! (1): 5
! (2): 0
! FAB$L_FOP: 1056
!
! (1): 32
! (2): 4
! (3): 0
! (4): 0
! FAB$L_STS: 65537
! FAB$L_STV: 640
! FAB$L_ALQ: 368640
! FAB$W_DEQ: 1446
! FAB$B_FAC: 31
!
! (1): 31
! FAB$B_SHR: 15
!
! (1): 15
! FAB$L_CTX: 0
! FAB$B_RTV: 127
! FAB$B_ORG: 16
!
! (1): 16
! FAB$B_RAT: 0
!
! (1): 0
! FAB$B_RFM: 1
! FAB$B_JOURNAL: 0
!
! (1): 0
! FAB$B_RU_FACILITY: 0
! FAB$L_XAB: 2146049200
! FAB$L_NAM: 3679088
! FAB$L_FNA: 118521
! FAB$L_DNA: 118541
! FAB$B_FNS: 20
! FAB$B_DNS: 20
! FAB$W_MRS: 8648
! FAB$L_MRN: 2147483647
! FAB$W_BLS: 26112
! FAB$B_BKS: 51
! FAB$B_FSZ: 0
! FAB$L_DEV: 474824968
! FAB$L_SDC: 474824968
! FAB$W_GBC: 0
! FAB$B_ACMODES: 0
!
! (1): 0
! FAB$B_RCF: 0
!
! (1): 0

RAB ON VAX AT SYS$CONNECT

! RAB$B_BID: 1
! RAB$B_BLN: 68
! RAB$W_ISI: 6
!
! (1): 6
! (2): 0
! RAB$L_ROP: 67090
!
! (1): 18
! (2): 6
! (3): 1
! (4): 0
!
! (1): 18
! RAB$B_ROP1: 6
! RAB$B_ROP2: 1
! RAB$B_ROP3: 0
! RAB$L_STS: 65537
! RAB$L_STV: 0
! RAB$W_STV0: 0
! RAB$W_STV2: 0
! RAB$W_RFA
! (1): 0
! (2): 0
! (3): 0
! RAB$L_RFA0: 0
! RAB$W_RFA4: 0
! RAB$L_CTX: 0
! RAB$B_RAC: 1
! RAB$B_TMO: 0
! RAB$W_USZ: 0
! RAB$W_RSZ: 0
! RAB$L_UBF: 0
! RAB$L_RBF: 0
! RAB$L_RHB: 0
! RAB$L_KBF: 3678908
! RAB$L_PBF: 3678908
! RAB$B_KSZ: 0
! RAB$B_PSZ: 0
! RAB$B_KRF: 0
! RAB$B_MBF: 4
! RAB$B_MBC: 51
! RAB$L_BKT: 0
! RAB$L_DCT: 0
! RAB$L_FAB: 3679008
! RAB$L_XAB: 0

FAB ON ALPHA AT SYS$OPEN

! FAB$B_BID: 3
! FAB$B_BLN: 80
! FAB$W_IFI: 1
! %fill: 1
! FAB$L_FOP: 1056
! %fill: 1056
! FAB$L_STS: 65537
! FAB$L_STV: 432
! FAB$L_ALQ: 368667
! FAB$W_DEQ: 1446
! FAB$B_FAC: 31
! %fill: 31
! FAB$B_SHR: 15
! %fill: 15
! FAB$L_CTX: 0
! FAB$B_RTV: 127
! FAB$B_ORG: 16
! %fill: 16
! FAB$B_RAT: 0
! %fill: 0
! FAB$B_RFM: 1
! FAB$B_JOURNAL: 0
! %fill: 0
! FAB$B_RU_FACILITY: 0
! %fill: 0
! FAB$L_XAB: 2062175344
! FAB$L_NAM: 8809560
! FAB$L_NAML: 8809560
! FAB$L_FNA: 524721
! FAB$L_DNA: 524741
! FAB$B_FNS: 20
! FAB$B_DNS: 20
! FAB$W_MRS: 8648
! FAB$L_MRN: 2147483647
! FAB$W_BLS: 26112
! FAB$B_BKS: 51
! FAB$B_FSZ: 0
! FAB$L_DEV: 474824712
! FAB$L_SDC: 474824712
! FAB$W_GBC: 0
! FAB$B_ACMODES: 0
! %fill: 0
! FAB$B_RCF: 0
! %fill: 0
! %fill: 0

RAB ON ALPHA AT SYS$CONNECT

! RAB$B_BID: 1
! RAB$B_BLN: -112
! RAB$W_ISI: 1
! %fill: 1
! RAB$L_ROP: 67090
! %fill: 67090
! %fill: 18
! %fill: 18
! RAB$B_ROP1: 6
! RAB$B_ROP2: 1
! RAB$B_ROP3: 0
! RAB$L_STS: 65537
! RAB$L_STV: 0
! RAB$W_STV0: 0
! RAB$W_STV2: 0
! RAB$W_RFA
! (1)-(3): 0
! RAB$L_RFA0: 0
! RAB$W_RFA4: 0
! %fill: 0
! RAB$L_CTX: 0
! RAB$W_ROP_2: 0
! %fill: 0
! RAB$B_RAC: 1
! RAB$B_TMO: 0
! RAB$W_USZ: 0
! RAB$W_RSZ: 0
! RAB$L_UBF: 0
! RAB$L_RBF: 0
! RAB$L_RHB: 0
! RAB$L_KBF: -1
! RAB$L_PBF: -1
! RAB$B_KSZ: 0
! RAB$B_PSZ: 0
! RAB$B_KRF: 0
! RAB$B_MBF: 4
! RAB$B_MBC: 51
! RAB$L_BKT: 0
! RAB$L_DCT: 0
! RAB$L_FAB: 8809472
! RAB$L_XAB: 0

[Hein van den Heuvel]

Well, that does not tell me much more.

Just that the cluster_size on the alpha is probably 39 (or possibly 69)
Verify with: "$SHOW DEV/FULL xxx" or "$write sys$output f$getdvi("xxx","cluster")"

And it shows the file is in fact a RELATIVE file. Nothing wrong with that though.

I'm still a little surprised that the ISI on the Alpha is not 5 or 6, but there is nothing really wrong with that either.

I think you have shown all that you can show here.
Focus back on defining 'did not get any succes' from your opening line.
hat did you get? And error? any data? bad data? you did use copy right.. not convert?

It may be time to open a support call!

Regards,
Hein.

[Phillip Thayer]

Try creating an FDL of the file on the VAX using

ANALYZE/RMS_FILE/FDL/OUTPUT=fdl-file data-file

Then copying the FDL file and data file over the the Alpha.

On the Alpha, do a: EDIT/FDL/NOINTERACTIVE/ANALYSIS=fdl-file fdl-file

to create a FDL file for the Alph.

Then do a

CONVERT/FDL=fdl-file data-file data-file

using the output FDL from the EDIT. See if this creates a usable file on the Alpha.

Good luck.

Phillip

[Hein van den Heuvel]

Philip wrote:
vax: ANALYZE/RMS_FILE/FDL/OUTPUT=fdl-file data-file
alpha: EDIT/FDL/NOINTERACTIVE/ANALYSIS=fdl-file fdl-file

That is only useful / valid for an indexed files. We are dealing with a relative file.

philip> This is only valid for an
to create a FDL file for the Alph.

Sorry, no. Vax and Alpha FDL files, as well as the data files they describe are 100% identical.

philip> CONVERT/FDL=fdl-file data-file data-file

Sorry, no. This is fine (but needles) for an indexed file, but for a relative file this will 'pack' the records which is probably not desirable. sparse files become dense.

Cheers,
Hein.

[Volker Halle]

Vir,

up to now, you have never specified what 'error' you are really seeing. Maybe you could provide the system call and the returned status code of the 'failing FORTRAN code'.

Did you consider, that this may also be an error in your program, which has not shown up on VAX or happens to due compiling/linking it on Alpha ?

You said both machines are in a cluster. Couldn't you access the data file on the VAX disk (is it MSCP-served ?) directly from the Alpha ? This would quickly verify, whether there really was a problem in transferring the file.

Volker.

[Vir Thanvi]

Hi Guys,

You all have been waiting to see the error and so am I. Actually all the STATUS and IOSTATUS are coming out to be fine, at-least by programming point of view. What I mean here is that after reading and connecting and GET calls of RAB and FAB, the STATUS are coming out to be permissible by FORTRAN as it does not enter any error statements I put in the code.

The problem I am facing is that the record being extracted from the data file is not the correct one on Alpha machine. Yesterday I did step by step debugging on VAX and Alpha and observed that almost all values like record number and other attributes turn out to be same but the record being accessed are different.

I modified the attributes of file copied to Alpha to be identical as one on VAX except that I was not able to change ALLOCATED blocks on Alpha. On VAX I have 368640/368640 but on Alpha I have 368640/368667.

I will post more facts and observed numbers later today as I do more testing.

Just FYI, the copying of FDL file and conversion of data file did not work. Hein already clarified the reason. The cluster size on Alpha machine is coming out to be 137, this might be something to look into.

Later today I will try to access the file on VAX from the code running on Alpha and keep you all posted on the happenings.

Thanks to you all for your time, help and support.

Best Regards,
Vir

[Antoniov.]

Vir,
just for give some clue ...
STS=65537
It's apparently successfull code but when I saw it in my code there was some light trouble.
I'm not sure this status is fine.

Antonio Vigliotti

[Volker Halle]

Antonio,

I64VMS $ sea sys$library:starlet.req 65537,rms/match=and
literal RMS$_SUC = 65537;
literal RMS$_NORMAL = 65537;

This is the RMS success status.

Volker.

[Antoniov.]

Volker,
I know 65537 should be success but in my experience on alpha this code was a warning.

Antonio Vigliotti

[Vir Thanvi]

Hello All,

I have no additional info to post today as we lost power at our work-place for the entire day. I did not get a chance to run any tests like accessing the file directly from VAX using Alpha code.

Someone here at work suggested to try reverse compatibility. This means that create the same file on Alpha and try to run it on VAX. I am thinking of giving that a shot too later today.

The number 65537 was observed on both VAX and Alpha, so I really did not pay too much attention to that, but in the discussion, it appears like it can mean different things on I64 and Alpha. This prompts me to search on VAX and Alpha system libraries to find out if it means different on both or is it the same.

Please stay tuned for more analysis info as input from all of you is becoming very crucial. Can someone please post a note about how can I obtain support from HP over this topic. This is the first time ever I have ran into this type of problem.

Thanks to all who are being such a big help.