File pointer problem on PC-IDL

[landsman(at)stars.gsfc.nasa.gov (Wayne Landsman)]

I am trying to debug a program (a "FITS" reader) that is failing on PC-IDL 
Unfortunately, I don't have access to PC-IDL myself so I apologizing for not 
doing as much debugging as I would have liked before posting my problem.     

Basically, then internal file position is getting screwed up.    I open a 
binary file, readu 2880 bytes, and find myself located 4095 bytes into the 
file.   Below is the simple script (as done by a remote user with PC-IDL).

IDL> print, !version
{ x86 Win32 Windows 5.2 Oct 30 1998}

IDL> openr,lun,'C:\burst_image_1.fit',/block,error=error,/get_lun
IDL> if eof(lun) then message, 'Reached end of file'
IDL> buf = replicate(32b,80,36)                    ;Total of 2880 bytes
IDL> readu,lun,buf 
IDL> help,/str,fstat(lun)
** Structure FSTAT, 12 tags, length=36:
   UNIT            LONG               100
   NAME            STRING    'C:\ROTSE\GRB 990123\burst_image_1.fit'
   OPEN            BYTE         1
   ISATTY          BYTE         0
   ISAGUI          BYTE         0
   INTERACTIVE     BYTE         0
   READ            BYTE         1
   WRITE           BYTE         0
   TRANSFER_COUNT  LONG              2880
   CUR_PTR         LONG              4095
   SIZE            LONG             25920
   REC_LEN         LONG                 0


How did the current pointer get at 4095 bytes???    Calling EOF() is not 
supposed to change the file position.    The situation seems reminiscent of 
a VMS mode where one always reads in multiple of 512 bytes.  (To avoid this
problem is why the VMS-only /BLOCK keyword is added to the OPENR statement 
above.)    But I wasn't aware of such fixed block I/O on a PC.      

Anyone have any ideas?    (The file burst_image_1.fit is available at
ftp://idlastro.gsfc.nasa.gov/landsman/fits)  

thanks,  --Wayne Landsman                  landsman@mpb.gsfc.nasa.gov