PxPlus User Forum

Twitter Twitter Twitter

Author Topic: Error 105 & local file  (Read 1425 times)

yonman

  • Member
  • **
  • Posts: 12
    • View Profile
Error 105 & local file
« on: November 14, 2018, 09:32:22 AM »
We are getting a rash of Error 105 on files that are not damaged in any way.  At the error occurrence, closing the file, issuing a wait 0, then re-opening the file will result in a successful read/write to that file.  We suspect that the file is getting loaded into local memory and getting corrupted. 

At some installations, the error occurs exclusively on one workstation in a company.  At other installations, the error occurs throughout all workstations, randomly through the day.

We have been researching Microsoft registries that controls caching, etc, but having found any solution yet.  Any thoughts?  Most appreciated in advance!

Note, we are using Mapped Drives.  No WindX used at all.

Error #105
Keyed file error (Short key block)

Reported whenever a key/data block is read from the file and the OS reports that the data read is less than was expected. Normally this indicates a truncated file caused by OS failure.

Devon Austen

  • Administrator
  • Diamond Member
  • *****
  • Posts: 382
  • Don’t Panic
    • View Profile
    • PVX Plus Technologies
Re: Error 105 & local file
« Reply #1 on: November 14, 2018, 10:41:03 AM »
Has this issue just started recently for systems that were running fine before? If so I would look into what has changed with those systems around the time the issue started i.e. application change, PxPlus upgrade, or Windows OS update.

The problem is likely related to your use of mapped drives and how it handles flushing writes and caching are out of our control and can change with updates to the OS.

Here is an except from a old mail list entry with some general advice about using mapped drives

Quote
Microsoft is logically disconnecting mapped drives that have been idle and reconnecting them when activity resumes.  This disconnect has the unfortunate side-effect that it will drop any outstanding record locks and that causes us some pretty serious problems. 

We generally suggest that sites that are using any sort of mapped devices issue the following command on their workstations/server.

                net config server /autodisconnect:-1

This was documented by Microsoft on http://support.microsoft.com/kb/297684

Another setting that needs to be looked at depending on the servers is to ensure that opportunistic locking is really turned off. There are some links that you can use to confirm it as the method used is different for servers.

http://support.microsoft.com/kb/2696547
http://blogs.technet.com/b/josebda/archive/2012/06/06/windows-server-2012-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-or-smb-3-0-you-are-using-on-your-file-server.aspx
http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html

One option would be to run the KEY LOAD directive on the files prior to running the days end procedure.

Due to these changes in Windows, we have developed a new file IO server that can be used to replace mapped drives -- PxServer.  Not only does this provider safer data file access but tests have shown it to be much faster than mapped drives.
Principal Software Engineer for PVX Plus Technologies LTD.