The problem arises because the VAX, and also DECstation, loads computational registers with bytes of increasing address starting at the right moving to the left, whilst tape, disk, and memory are mapped according to increasing byte address. For example, supposing we had an exchange format record starting with the following numbers:
1 - bit pattern: hex 0123CDEF 2 - integer: 292 hex 00000124 3 - floating: 1.0 hex 3F800000 4 - Hollerith: ABCD hex 41424344 ...
the record would start with the following bytes:
number: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... value : 01 23 CD EF 00 00 01 24 3F 80 00 00 41 42 43 44 ...
Reading the record to memory will transmit the bytes in this order to increasing byte addresses, but under the VAX optic showing association to registers we have to write it as:
number: ... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 value : ... 44 43 42 41 00 00 80 3F 24 01 00 00 EF CD 23 01
This is right as it is only for Hollerith (for which this scheme has been designed, of course), but it is upside-down for integers and bit patterns; floating-point has to be converted anyway.
Since all the control-information is integer, and Hollerith is relatively rare, FZIN on the VAX for simplicity (and speed) converts the whole record with one call (to VXINVB), inverting the 4 bytes of each word, giving:
number: ... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 value : ... 41 42 43 44 3F 80 00 00 00 00 01 24 01 23 CD EF
Conversion from Exchange Data Format to VAX internal transforms only floating-point and Hollerith, the integers being ready, giving:
number: ... 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 value : ... 44 43 42 41 00 00 40 80 00 00 01 24 01 23 CD EF
FZOUT on the VAX goes through the inverse process.
Byte inversion in FZIN/FZOUT operates only for exchange data format; bytes are not swopped for native data format, not even with the exchange file format.