RAB on VAX and Alpha

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