Application generates error 005

[JohnC]

I apologize preemptively for this but I have receive almost no help from the application developer and was hoping someone here may have some more insight into what is going on with this application.  First off they are running PxPlus-2017 Pro Version 14.00 on a Windows 2019 Server.  The application generates an error frequently when running specific reports.   

The program appears to generate error 005
and shows

Unlock Region Failure
Likely hardware/network issue

The report is apparently working with a very large amount of data but I see no errors on the server side to speak of regarding a read error or any other data problem.   the application developer basically has washed their hands of it and says it is a hardware problem which I might believe if the system showed any signs of other problems but it does not.  Any guidance or direction would be highly appreciated if it is even possible with that limited information.

[Mike King]

An unlock region failure is typically caused when a network drive/file is in the process of being updated and the network connection is lost.

The most typical cause of this is accessing a mapped drive on Windows and Windows resetting the connection while you have the file open.  Windows, by default, will disconnect a mapped drive connection if there is no activity for a period of time -- this is called a idle-timeout. 

Assuming this is the problem you are encountering, here is an article that may assist: https://eddiejackson.net/wp/?p=16319

[Mike King]

One other thing, if you are using mapped drives or UNC connections between the application running on a workstation connected to the server, have a look at the event log on the workstation (not just the server).

We have seen instances where the workstation event log shows "Delayed Write Failures" to the server which is a sign that the network is having trouble. 

The server may not report any errors since it wouldn't know the workstation was trying to communicate.

[JohnC]

Mike,

Thank you for the insight.  That is actually helpful,  a previous set of instructions did not inform me the the KeepConn was limited to 65535.  That aside I did have group policies in place to create the registry entries for these items but they may not have been working.

In context, what is happening is a customer is running a report and the report takes LONG to run,  about 25 minutes (personally I don't think there is any excuse for an application report to take 25 minutes but that is not terribly relevant).   The report spends most of its time displaying "sorting" in the toolbar. During this sorting time if there is no action on the drive it could possibly disconnect under the default 10 minute value. 

Just seems odd that the application would be "sorting" and that would cause no network activity.  I think the user typically runs a second session of the application and runs other parts of the application while the report is being created.   I will review the registry on the workstation that runs these reports tomorrow and I will see if that makes any difference.  I will also look for those delayed write failures,  but there isn't really much "writing" going on in this process.

[Mike King]

A lot would depend on how the sorting is being done.  We have seen applications that internally build an array of string then use a simple bubble sort to sort the data.  While this is fine for a few hundred entries, when dealing with thousands of entries these can take a long time.

For example the SRT function provided by PxPlus does a basic bubble sort which can take a long time if sorting a lot of entries.

If sorting a lot of entries we suggest instead of using the SRT function that they use a memory file (*MEMORY*) to perform the sort.  You can see the difference if you run the code below:

Code Select Expand


  x$=""
!
  for i=1 to 20000
  x$+=str(rnd(1000):"000")+str(rnd(1000):"000")+str(rnd(1000):"000")+"/"
  next
  print "x$ Built..."
!
  wait 0 ! Flush output
!
  x=tmr(0) ! Reset timer
  y$=srt(x$,"/")
  print "SRT function took ",tmr(0)," seconds"
!
  open (1)"*memory*"
  for v$ from x$
  write (1,key=v$)v$
  next v$
  print "Memory file took ",tmr(0)," seconds"

If you run this you will see a significant difference in the time to sort the values. 

For example, on my system the SRT took just under 2 seconds; but to build the memory file the system only took 0.018 seconds. 

While that's not bad to sort 20,000 values, if you increase the number of elements (change the FOR loop to 100000) you will see an exponential increase in the SRT time.  On my system the 2 seconds went to 58 seconds, far more than the 5 fold increase on the number of elements.  The memory file however only increased to .138 seconds -- much closer to the actual increase in the record count.

Now it should be mentioned that using either the SRT or a MEMORY file does not involve any disc activity so if your sort took 25 minutes and was memory resident a mapped drive could easily get disconnected due to inactivity.