I hope you can help me or direct me to someone who can help me. I am programming in M(UMPS) and I am having a problem. In the program I am waiting for a response from the mainframe I do a read (R x:15) I understand that after 15 seconds if I did not get an answer I will stop waiting for an answer. I checked my $T and if it there is nothing there or if it is equal to zero I want to stop the program.
This works sometimes, but most often the program will abort prior to checking the $T, I don't even have a chance to see what is in x, how can I catch this before it aborts. I looked in the console log and everywhere but I do not see any error. The only error I see is when I look at the unsuccessful task it say err (getr+9 which is the line where I do my read.
R x:15 (IT STOPS HERE AND ABORTS if I run out of time)
I have tried
G:'$T END
OR
I '$T G END
OR
S TEST=$T
IF TEST=0 ..........
But none of these checks happen if I time out. If I do not time out everything works great.
By serendipity I ended up on this forum today.
So, maybe this question has been answered already. Anyway, here goes:
The answer to this question is that there can be multiple reasons why no response is received from a remote machine.
When it simply takes too long for the response to be transmitted, the following should work:
Read variable:15 If '$Test Goto ErrorHandler
However, when the communication channel between the two systems gets closed, this is treated as an error condition, so in that case, the following should work:
Set $ETrap="Goto ErrorHandler"
Read variable Set $ETrap="" ; Note that we don't need a time-out to handle this...
Hope this helps
Related
I have been tearing my hair out at this issue
The code in question is part of an Open Source project here: aiosmtpd (my fork of the actual FOSS project, here)
The file with the problem is this one: main.py
The piece of code in which the problem happens is on line 139 of main.py
Here's a snippet:
...
from aiosmtpd.smtp import DATA_SIZE_DEFAULT, SMTP, __version__
...
...
# args is the result of ArgumentParser.parse_args
factory = partial(
SMTP, args.handler,
data_size_limit=args.size, enable_SMTPUTF8=args.smtputf8)
...
server = loop.run_until_complete(
loop.create_server(factory, host=args.host, port=args.port))
...
Sometimes -- that is, not always -- the code failed at that point with RuntimeError: Event loop stopped before Future completed.
My questions:
What could be the cause of this intermittent failure?
It failed like 10% of the time during testing (using tox + nosetest2), but 90% of the time just went swimmingly well.
How should I instrument and/or check and/or assert to prevent this from happening?
What's the best strategy for "recovering" the error and redoing the action?
I will emphasize for the n-th time that the error happens INTERMITTENTLY. And infrequently, but often enough so I feel compelled to trace the root cause. And after an error, if I rerun the code again -- immediately or after a delay -- the same error nearly always did NOT happen.
Barring a bug in asyncio, the issue is likely caused by a call to loop.stop() hidden somewhere in the code base. You probably want to remove or disable those, as they are fundamentally incompatible with run_until_complete, as well as with the more modern asyncio.run.
I realize almost the same question was asked, but it was over a year and a half ago and didn't really have an answer. I need a solution and soon, so I am asking again. Here is my story:
I use Google Apps Script to teach coding to middle school students. We write and run very basic code. This website shows the types of things we do. The instructions we follow are commented out within the code itself.
Everything had been working fine, then just last night I started getting
the error "IO error when deserializing continuation" when running code. It
appears to happen randomly, as I could run the exact same code multiple
times and sometimes have the error appear, and sometimes not. This will
happen even on an extremely basic piece of code. Here is an example of code that I can't run more than 2 or 3 times without getting the error (I included the code for the menu I use to initiate the script):
function onOpen() {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var menuEntries = [ {name: "variables", functionName: "variables"} ];
ss.addMenu("Learn to Code with Google Apps Script", menuEntries);
}
function variables() {
var input;
var name=Browser.inputBox('What is your name?');
Browser.msgBox('Your name is...');
Browser.msgBox(name);
}
I am presenting the coding curriculum from the website above on Friday to a
group of educators, and if this error persists, it will ruin my
presentation.
Please help!!
It appears that this sort of thing can happen under circumstances where your script's execution is "paused" by modal UI interaction (in this case, your msgBox) as noted in this related post
Why is Browser.msgbox the common denominator? Why is "the problem disappeared on its own, as suddenly as it appeared" a common refrain? Could this issue have something to do with the time delay (latency) of the system (PC and Internet) at the time of script execution?
I experienced this problem last night for the first time with a well-proven script. As it happened, this was also the first time I was running FreeFileSync in the background, syncing my two NAS drives. On a hunch, I paused the sync process, and the script problem behavior improved enough to finish the task (though still not without occasional errors).
Time delay (latency) changes due to system load variations (with time of day, background processes, etc.), could explain such apparently random behavior. I have not seen this issue raised. If so, the problem might be fixable on Google's end, by increasing a "timeout" variable. (Other reported "solutions" may be red herrings, successful due to temporarily-reduced system latency.)
I have an interrupt in my code which sometimes works, and sometimes gives the following error message.
RuntimeError: <Process(executeJobs) object at 0x7f3542880890> has terminated and cannot be interrupted.
I have checked that the object still exists, why am I still receiving this error?
I would also be glad to receive any other resources than http://simpy.readthedocs.org/ as I have already been through the documentation many times.
Thank you!
It looks like the Process instance still exists but is no longer alive. This means that the generator function that it executes (executeJobs in your case) is exhaused / has returned.
The title says it all. I am using C++ Builder to submit a form to an Internet server using TIdHTTP->Post(), to get a response. Since that call can get stuck if there is a network problem or a server problem, I am trying to run it in a separate thread. When the Post() returns, I signal the Event that I am waiting for with WaitForSingleObject, using a timeout of 1000. At one point, I was processing messages after the timeouts, but now I am just repeating the WaitForSingleObject call with a timeout of 1000 again, until the event is signaled or my total timeout period (20 seconds) has elapsed. If the timeout elapses, I would call Disconnect() on the TIdHTTP and try again.
However, I have not been able to get this to work reliably, although it usually works. I am using CodeSite to log the progress, and I can see that, on occasion, WaitForSingleObject is called, but does not return (ever). Since WaitForSingleObject is being called on the main thread, the application is then unresponsive until it is killed.
While one must always think of memory corruption when a C++ program stalls, I don't think that is what is going on. The stall is always at the WaitForSingleObject call, and if it was a memory corruption issue, I would expect that, at least sometimes, something else would go wrong.
The MSDN page for WaitForSingleObject says that the timer does not count down while the computer is asleep, and the monitor does go blank after a while, but the computer continues to run, and in any case WaitForSingleObject does not return once the mouse is moved and the monitor comes back on.
So, again, my question. What could be causing WaitForSingleObject with a finite timeout (1000 msecs) to never return?
So, the answer to my question is "Something Else". In this case, I finally tracked it down to a library I was using that also used threads. It worked with a previous version of RAD Studio, but disabling that library fixed this issue. I am moving to the current version of that library and will re-test.
I had read about problems with WFSO causing blocks, and even where Sleep might never return if there were too many threads running (http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx), so I thought there might be something I didn't know about threads and WFSO causing this.
Thanks to everyone for your helpful comments which pointed me in the right direction, and especially to Remy Lebeau for his suggestions on managing Post timeouts with Indy, which he maintains.
I have never seen a real use for checking if a file was closed correctly. I mean, if it didn't close, then what? You have nothing smart to do. Beside, I'm not sure if there's a real world use case, where non of the write/reads/flush will fail, and only the close will.
Does anyone actually uses the return value of close?
From the close(2):
Not checking the return value of close() is a common but nevertheless serious
programming error. It is quite possible that errors on a previous write(2)
operation are first reported at the final close(). Not checking the return
value when closing the file may lead to silent loss of data. This can
especially be observed with NFS and with disk quota.
And if you use signals in your application close may be interrupted (EINTR).
EDIT: That said, I seldom bother unless I'm prepared to handle such cases and write code that has to be 100% fool-proof.