I/O error hangs Macro Scheduler

[Bob Hansen]

I have finally made the time to troubleshoot an intermittent problem I have had for a few years!.. As part of a nightly backup routine I would periodically get an error message from Macro Scheduler. The error message is like "I/O error 51". The value is not always 51, but I know sometimes it was 53 instead. This halts the macro and needs to be restarted.

It appears that the last item in the log is the DateStamp> command.

The destination is a file on a mapped drive. It does not happen every day, it does not always happen on the same drive letter. I cannot duplicate it on demand.
Here is a sample from the last line in the log tonight, output to Drive P:

Code: Select all

1/3/2008 21:26:51:875 - DateStamp>P:\Data\Backups\Logs\20080103Msg.log, Ending Backup of P:\*\* to U:\Compaq\

The next command line never runs, it is just a simple Let> command. The error message comes up before that line is executed.

I suspect that there may be a timing issue where the DateStamp is trying to connect to the mapped drive on another system, and is timing out because of some delay in the network connection. An earlier IfFileExists> command does check for a file on the same mapped drive, so I know that the drive can be accessed.

Doing a WaitWindowOpen> for the error window does not work, the error kills the macro, not allowing that line to run.

Is there a way that I can get some type of delay or a return code that can be checked to make sure the DateStamp> process has been completed? Is there something else that could be causing this error?

[Marcus Tettmar]

53 is file not found. So it would suggest an issue with the network - it was unable to find the path - i.e. the network share was not available. Maybe you need the script to refresh/reload the network share before it tries to write to it?

[JRL]

seems to me TimeStamp is nothing more than a writeln> So why not use WriteLn> instead?

Something like:

Hour>hh
Min>mm
Sec>ss
WriteLn>your filename,wres,%hh%:%mm%:%ss% - Message
If>wres0
//DoSomething
EndIf

Will give you the error checking you desire.

[Bob Hansen]

Thanks Marcus and Dick for your suggestions.
Will try and see what happens.

Problem with intermittent problem is how do you know when its fixed?

[Bob Hansen]

Well, it appears that the problem is some type of network issue, and/or a problem with XXCopy and SnapDrives OS. Found that problem is not always after DateStamp. It happens any time doing XXCopy in the middle of writing to a mapped Snap drive. I have changed to UNC vs. mapping but no change.

So, I will have to do some more diagnosing on that issue, but Macro Scheduler is affected by the error. Here are my notes from the recent error:
-----------------------

Close the error window. Macro still shows flashing icon in systray, and hover shows name of macro running.

Click on Stop. Icon stops flashing but hover message says macro is running.

Look at full MS screen, status line says macro running, but Kill is greyed out, and Run is available.

Click File/Exit or upper right "X" to exit MS, cannot quit. Cannot quit from systray. Need to use Task Mgr to kill MS and restart.
-------------------------------

This is repeatable when I get the I/O error. I was expecting that Macro Scheduler would recover normally when closing the error window. Or the hover message would disappear when the status looks like no macro really running. Or would be able to exit normally.

But, my biggest problem is the non Macro Scheduler issue of the XXCopy.SnapDrive across the network. This info is just for Marcus to ponder in your spare moments while I chase my own demons.

[jpuziano]

Well, it appears that the problem is some type of network issue, and/or a problem with XXCopy and SnapDrives OS. Found that problem is not always after DateStamp. It happens any time doing XXCopy in the middle of writing to a mapped Snap drive. I have changed to UNC vs. mapping but no change....

...But, my biggest problem is the non Macro Scheduler issue of the XXCopy.SnapDrive across the network.

Hi Bob,

I was wondering how you're doing on this one. If you think this is a network problem, have you contacted the XXCopy folks to see if they have any known issues wrt an unreliable network? If so, perhaps they have a workaround.

I know you like XXCopy, but perhaps there are other products out there and can better deal with an unreliable network when moving large files. When I saw the following in my Versiontracker updates, it reminded me of this post of yours:

GatherBird Copy Large Files - 2.3
copy files over unreliable & slow network connections
http://www.versiontracker.com/dyn/moreinfo/win/150695

I have never used this and I'm not sure if there's a command line driven version... but it could probably be scripted or... you could look around for another comand line driven tool that specializes in moving files across unreliable networks... just a thought.

Take care

[Bob Hansen]

Thanks for the feedback, jpuziano.

I am committed to XXcopy, too many existing applications, scripts, installations to undo/change. I have contacted their tech support. They have indicated that SnapDrive devices are using a proprietary OS that may be the culprit. I have gone thru two different "patch/upgrades", but neither of them solved the problem. Don't think this is limited to large files, I think it may be any size. But it always/only when working with SnapDrives Source and destination from all others are OK from DOS thru XP PRO. (Avoiding Vista for a while).

Not sure yet, but think I may be able to put in some delay values for the XXCopy command. There are over 200 switches, very complex, but makes it very flexible. I just need to make the time to solve an intermittent problem. This is about 2 years old.

I do wonder if Marcus is looking into the Macro Scheduler problem that results when I get the I/O error. I have not seen any response to that issue. I suspect it can also be caused by other applications.

Thanks again for your support, not just for this, but for all else you do on this forum.