Here is what I've found: 

1) The error is repeatable. 

  I used UKA17X2.EXE to produce this error over and over again.
  UKA17X2 creates ~300 files.  Other pgms that create a lot of
  files could probably be used just as well. 

  Here is the sequence that I used to reproduce the error: 

   a) Copy UKA17X2.EXE to the root directory of C: 

   b) create a new subdir in c:\ 

   c) cd to that new subdir 

   d) execute "\UKA17X2" 

  The "corrupted" directory sector appears in either the new subdir
  or in NOS\HELP under it. 

  One other curious thing:  If you move UKA17X2.EXE into the new subdir
  and then execute it without the leading "\", i.e. "UKA17X2",
  the corruption does *not* occur.  I don't know why. 

2) Disabling SMARTDRV's write caching *prevents* the corruption
  from occurring. 

  The downside of this (i.e. disabling write caching) is that UKA17X2
  takes ~3 times longer to run without write caching enabled. 

3) The directory "corruption" may *not* be related to LFNs. 

  a) The LFNs that I saw in previous "corrupted" directory sectors
     were probably already in those sectors 

  b) I've also seen source code snippets, sections of doc files,
     and other inappropriate data in "corrupted" directory sectors. 

  c) Sometimes one or more *correct* directory entries are scattered
     within all the garbage in a "corrupted" directory sector. 

  d) BTW I have yet to see a corrupted sector that was the also the
     first sector in a cluster.  But that might just be the result of

4) Per Eric's request I tried substituting NWCACHE for SMARTDRV.  I
  used DELAY=667 as the only operand.  The results were: 

  a) no corruption 

  b) run time was very close to SMARTDRV (with its write caching on) 



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Freedos-user mailing list

Reply via email to