VORBRUEG@DBNPIB5.BITNET.UUCP (06/14/87)
I think there's some misunderstanding about who does what in VMS. Like UNIX, VMS has a very much device-independant I/O system, and there is no 64 KB limit for one I/O operation, provided the device can handle it. (This is true for VMS 4.0 and up.) All disk drivers will handle requests for up to 4 GB (which you can't do anyway, as you virtual address space is limited to 2 GB.) If actually do an I/O to a disk, you read/write a number of bytes, starting at a specified virtual block (512 byte multiple, starting at 1). The file system does the virtual-to-logical block trans- lation, but otherwise keeps its fingers strictly away from the data. The limit you see with C (and a number of other languages, e.g. FORTRAN) is created by RMS, which sits on top of the file system and does a few nice things: It makes life easier because it does file name searching and wildcarding, and it defines and operates on a number of file structures. Now, if you want to view your file as a stream of bytes with no structure, you're welcome; just don't use RMS in this case (what do you think the acronym stands for, anyway?). In fact, you can ask RMS to do the file name handling and opening for you, and then do the I/O yourself. (I can send you an example program on request). On the other hand, why not just map the file you want to read into virtual memory, that's much more efficient... So the conclusion is: It's not a VMS problem, it's the way the VAX C RTL writers decided to provide a set of services. Nothing will stop them (or you) from doing it the way UNIX does it. --- Jan Vorbrueggen