Intermittent error 261 and 278

[Dave Fullerton]

Hi folks:

We have a client that has just changed their servers and configuration.  The user workstations are UserVMs: Windows 10 1909, Servers are 2019 Standard, and they are using ESXI Hosts: 7.0.  Under this configuration, the client is running our application in a mapped drive configuration.  Intermittently, a user will get an error 261 - Invalid/output or error 278 Invalid argument, usually in *winproc.  The PxPlus level was 12.5 but I upgraded them to 16.2 with the same results.

I have gotten connected to the workstations that have experienced the issue, and can bash the software around and I won't get any error - things work as expected.  I get out, and shortly after, while doing something reasonably mundane, the system hangs, and the user sees the stack level and the console prompt running down the screen when they press the Enter key. 

The error 278 happened on this statement
0320 let _header_obj_type$=""; read (%scr_lib,key=scrn_k$+"0000",dom=8800)iol=8010; let _header_obj_type$=_obj_type$
but we can start a new session, and all works well.

The error 261 happened on this statement
14311 let %_wp_dir$=msg("_WP_DIR",lwd),%_wp_prefix$=msg("_WP_PREFIX",pfx)

I am sure that this is a network issue and I have not got the most confidence in our client's IT support - well intentioned as they are.  Does anyone have any suggestions as to what may be done to resolve these issues?

Regards

Dave Fullerton

[Devon Austen]

I would agree with you and I also suspect a networking issue.

Using mapped drives is always risky in your application because there is no fault tolerance in the protocol really. If there is any networking issue while accessing/modifying data on a mapped drive it will likely result in a error or possible data loss or corruption. That is why we developed the PxServer product to allow more reliable and secure remote data access.

Now I am guessing you don't really have an option here and mapped drives must be used. In that case the best you can do is make the network as reliable as it can be made. Unfortunately I can't really help you there as I am not an expert in VM networking.

You also want to make sure the program can handle the errors when they do happen by for example retrying the read. This would allow a blip in the network to not cause an error it would just try again and it would likely succeed. Now you would probably have to add error handling like that around all mapped drive file IO to make it really reliable. This obviously may be a big change which is not really possible given this customer had a working system until the server change.

[Dave Fullerton]

Hi Devon:

The problem is, that the errors seem to happen in *winproc, where I don't have a lot of control, and one of them wasn't associated with a Read.  I could suggest moving to client/server, but they will be winding down use of our application in the next seven months, so that really isn't an option.  As far as retries are concerned, I have tried going back to the statement to re-execute it, without success. 

Before this server change, the application was running quite well for over a decade without issue.

Thanks for the input - I am hoping that their tweaks (which seem to take an inordinate amount of time) will work.  If not, I may need to get them to go to WindX.

Dave

[Mike King]

Dave

Make sure they have disable the Windows idle timeout on the mapped drives.  What can happen with mapped drives is if there is no activity for an extended period of time the OS drops the connection which then causes trouble when we try to do subsequent IO.

Here is a link that lets you know how to change the timeout setting:

https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/mapped-drive-connection-to-network-share-lost

[Dave Fullerton]

Hi Mike:

Thanks for the link - I will pass it on.  I had mentioned to their IT support that this might be a reason, but they didn't know anything about the setting.   I checked the status of the drives in File Explorer, and did not see the red X that usually indicates the disabled drive, and the drive was being used pretty regularly (or so I'm told), but hopefully this link will remove that issue from the equation.

Dave