mp.os.os2.misc,comp.os.os2.beta   
   /3Qhuaf+mMOfi8MMowntC4YQygQ9DY7kg1jpMXAVqeXT+KvDRTbGdFxRv/IwHEQh   
   //nNWmh67Yb2pTfFK3EfYSw0U4MMotzPUH3p48NK5UR56zdWTq+OeLS3a0UahXwUHEM=   
   p.os.os2.programmer.misc:2090 comp.os.os2.misc:3135 comp.os.os2.beta:126   
   From: "Allan"    
      
   On Sun, 3 Apr 2011 21:29:19 UTC, Jonathan de Boyne Pollard  wrote:    
      
   > > (I suggest that those with JFS source code access check what SFFSI    
   > > structure is passed to an "L" function.)   
   > >   
   >    
   > Thanks to Dave Yeo, I've been able to check this out.  The "L" functions    
   > take the same sffsi structure, except that it has two 64-bit fields    
   > tacked on to the end: sfi_sizel and sfi_positionl.  Obviously, by their    
   > names, these replace the 32-bit sfi_size and sfi_position fields earlier    
   > in the structure.  Quite how the kernel tells which set of fields, the    
   > 32-bit ones or the 64-bit ones, an IFS driver is maintaining is    
   > unclear.  I see no sign of JFS setting a flag to tell the kernel which    
   > fields it is maintaining, and it maintains the 64-bit fields, and *only*    
   > the 64-bit fields, even in the non-"L" entrypoints.  (The non-"L"    
   > entrypoints simply call the "L" ones.  Perhaps this is a JFS bug.  Have    
   > there been reports of the 2003 JFS.IFS not working on OS/2 prior to    
   > version 4.5?   
      
   JFS came with WSEB - aka OS/2 4.5   
   JFS have never been designed to work with prior kernels.   
      
   --    
     Allan.   
      
   It is better to close your mouth, and look like a fool,   
   than to open it, and remove all doubt.   
      
   --- Internet Rex 2.31   
    * Origin: Datemas.de http://www.news.datemas.de (1:261/20.999)