<<When will we get some new file system intrinsics that can read/write
more than about 40 KB to 64 KB?>>
 
Good point; it's clearly time that both HP and the users start thinking
about these issues.
 
<<FWRITE is fundamentally limited by the size of the "tcount" parameter
(16 bits) to a theoretical maximum of 32768 bytes or 32767 16-bit words,
but some DDS tapes have data records larger than this!   FREAD/FWRITE
can't be extended correctly, so I suggest four new intrinsics:
 
function HPFREAD (
                var status  : hpe_status;       {32-bit output parameter)
                    filenum : integer;          {32-bit value}
                    buffer  : globalanyptr;     {64-bit address}
                    bytes   : bit32)            {32-bit value}
        : bit32;
 
  function HPFWRITE (
                var status  : hpe_status;       {32-bit output parameter)
                    filenum : integer;          {32-bit value}
                    buffer  : globalanyptr;     {64-bit address}
                    bytes   : bit32;            {32-bit value}
                    cctl    : integer)          {32-bit value}
        : bit32;
 
function HPFREADDIR (
                var status  : hpe_status;       {32-bit output parameter)
                    filenum : integer;          {32-bit value}
                    buffer  : globalanyptr;     {64-bit address}
                    bytes   : bit32;            {32-bit value}
                    recnum  : longint)          {32-bit value}
        : bit32;
 
Similar to HPFREAD above, but positions the file to logical record
      number "recnum" first.  NOTE: if this is a byte stream file, then
      recnum is the absolute byte offset from the start of the file.
      (Thus allowing 4GB and GREATER files to be read)
 
function HPFWRITEDIR (...
       Exercise for the reader.>>
 
The "32K at a time" issue is definitely in need of correction. However,
since we're looking at "future compatibility" here, why constrain the
values of "bytes" and "recnum" to 32-bit integers? The suggested
implementation of HPFREADDIR gives "4GB and GREATER"-but only to a
maximum of 8GB for a byte-stream or 1-byte-record file.
 
In the same spirit, maybe we also need "HPFPOINT" and "HPFSPACE"
intrinsics that take 64-bit parameters. How about "HPFREADSEEK' with a
64-bit record number? And others.
 
IOW, we want to avoid a "quick hack" solution that resolves the immediate
32K problem, but fails to address, and may turn out to be incompatible
with, a "real" long-term 64-bit solution.
 
Of course, current HP language products don't support 64-bit integers
(maybe FORTRAN?), so we'd have to have conventions for building up 64-bit
integral values from 32-bit pieces. But that's a minor issue (he says
glibly ;-). Given the choice, I'd prefer to avoid the way Windows NT did
it, where the functions calls accept two explicitly-identified 32-bit
pieces of a 64-bit value; if possible, I'd much rather use a structure to
contain the pieces, and have the compiler figure out how to convert it.
 
Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]