I have a routine where i use MIAMEX,131 to check for a file on a "remote" or local PC or shared network directory. In cases when its not found, there is often some garbabe in the ATE buffer and the next INFLD statement will have garbage (1,0,0,0) or similar. If i trap for that, and enter a valid string in the INFLD, it will still hiccup on that field. (not process the input for some reason?.. just goes back to that infld... i have not debugged that)
Is there a command that will reset or clear all ATE commands or buffers? I found MIAMEX 88 FLUSH STREAM BUFFER but not sure that would apply here.
Thanks.
[ May 01, 2012, 13:25: Message edited by: Frank - edgeMED Healthcare ]
From: Deerfield Beach, Florida | Registered: Sep 2002
| IP: Logged |
posted
This sounds like an old problem that should have been resolved. What version of the server and ATE are we dealing with?
The only reason I can see for this symptom is if the MX_FILESTATS (131) took longer than the allotted timeout period (about 10 seconds) to respond, in which case when it did respond, the response would probably make its way into the input buffer. That might happen in the case where the specified path is a network path and it can't be resolved.
Unfortunately, clearing the ATE response buffer would depend on the current state of things. If the response hadn't yet been returned, then ATE would still be waiting for it (even though the server may have given up and gone on to issue another command). If the response had already made it into the input buffer, then you could clear the input buffer in the usual way on the server side, i.e. using an XCALL TINKEY loop, or a GETKEY(0) loop (i.e. while getkey(0) >= 0 : loop).
But rather than trying to work around it, I would rather we just get to the bottom of it. Turning on the ATE trace in the debug window would be the place to start (so we can see when the response gets returned, relative to the command).
From: Woodland Hills, CA | Registered: Jun 2001
| IP: Logged |
posted
Thanks for the reply. I have to run out of the office now.. I will conjure up some traces and get back with you... in the meantime this is under:
posted
I suspect that the fix to this was in 5.1.1174.8 (Feb 2010) when the timeout on the MX_FILESTATS function was increased.
You may want to see if it still happens in the current version before spending a lot of time debugging. But note that it is a server-side fix, so updating ATE by itself would not be sufficient.
[ May 01, 2012, 17:00: Message edited by: Jack McGregor ]
From: Woodland Hills, CA | Registered: Jun 2001
| IP: Logged |
posted
Unfortunately as luck would or would not have it, this is one of our largest servers (75lic) and we aren't in a good position to update them yet.
What I can show you is the debug at the start of our signing program that uses the miamex call. Then i will show you the debug when I enter data in the infld control and it ignores it (probably due to buffer garbage). Then i will show you the small snippet of code im using with the miamex call.
CHECK'NETWORK: ! ! Check to see if this PC is "licensed" by looking for the ICON ! in the windows APPS DIRECTORY. ! BYTES=0 WORK=APPS'DIR$+"\edgescan.ico" LOGG$="Looking for ZOOM Scan: "+WORK : CALL UPDATE'LOG XCALL MIAMEX,131,"R",WORK,BYTES ! Lookup file in PC Format ! ! Pause here for Miamex to finish ! FOR X=1 TO 5 XCALL SLEEP,.5 XCALL NBUF,A IF A=13 OR BYTES<>0 X=5 NEXT X ! IF BYTES=<1 LOGG$="NOT FOUND! Bytes="+STR(BYTES) : CALL UPDATE'LOG : ! LOGG$="FOUND! Activated ZOOM Scan. Bytes="+STR(BYTES) : CALL UPDATE'LO ZSCAN=2 RETURN
ps: 7 seconds also seems to be a long delay for the miamex command to respond... Any way to decrease the timeout?
Thanks.
[ May 02, 2012, 13:28: Message edited by: Frank - edgeMED Healthcare ]
From: Deerfield Beach, Florida | Registered: Sep 2002
| IP: Logged |
1. You appear to be checking redundantly for the zoom1.bmp file - see trace lines 14 and 26. (No harm, no foul, but does waste time.)
2. Indeed, the check for \\fl-nas01\ZOOM\Scan_Files\zoom\apps\edgescan.ico (line 70) is failing, and taking 7 seconds to respond. Unfortunately, what the client-side trace doesn't show is that the server-side XCALL MIAMEX has probably already returned by the time ATE sends the response (since it's timeout was 5 seconds). So the response ends up in the keyboard buffer.
Your code is waiting an extra 2.5 seconds after the MIAMEX,MX_FILESTATS returns, but that isn't really accomplishing anything since the value of BYTES (passed to MIAMEX,MX_FILESTATS) isn't going to change during that time. Nor is the value of A. (I suspect that loop was left over from an earlier implementation which used TAB(-10,AG_FILESTATS) instead of MIAMEX, MX_FILESTATS.)
Also, although the actual delay seems to be about 7 seconds, I'm not sure that adding your 2.5 to the initial 5 is quite enough to be safe.
A workaround (short of updating A-Shell) would be to change the code to detect when it timed out (BYTES = -15) and then wait another few seconds and actually suck up the keyboard response. Something like...
code:
XCALL MIAMEX, MX_FILESTATS, "R", WORK, BYTES
! If the above timed out, BYTES will be -15 ! in which case we should wait to retrieve ! the delayed response
As for decreasing the timeout, the problem here is that it is occurring within a system call to check the stats of the specified file. Normally such an operation would take microseconds, but if the filespec is a network path and the network doesn't respond quickly either with an actual connection or a failure, there no easy way for us to interrupt that. We can tinker with the timeout in the MIAMEX, MX_FILESTATS call, but that timeout occurs on the server side, and making it quit earlier doesn't solve the problem of ATE waiting for the check-stats-of-file system call to return, after which it puts the result codes into the keyboard buffer to send back to the server (not knowing that the server has already given up).
What we could do (but it would require more updating of A-Shell and/or ATE), would be to send some kind of time limit indicator in advance to ATE (say, 3 seconds). Then, although ATE couldn't prevent the actual delay while waiting for the network to respond, it could detect after the fact that the delay was more than 3 seconds, so there would be no point in sending back any response.
But for now, I would suggest trying to come up with a different way to detect whether that file exists. Keep in mind that the problem is not the non-existence of the file, it's the non-existence (or non-responsiveness) of the network mapped directory. If you could arrange to put that file (or some other indicator) in some directory presumed to be local to the workstation (%MIAME%, %TEMP%, %ATEPERMCACHE%, etc.) then checking for its existence would be uniformly quick.
From: Woodland Hills, CA | Registered: Jun 2001
| IP: Logged |
1. I set an environment variable in our main housekeeping subroutine by looking for the zoom1.bmp file. The only other time i reference this file is when it is displayed. Is it possible the code to display the bmp does a "precheck" of the file? I am not calling miamex,131 twice here. If it is indeed ashell, perhaps that is redundant and can be removed?
2. A couple things worth noting up front. Unfortunately the customer sets up the best place for this directory. (it is for scanned images. We merely check for this .ico file as a basis of knowing if the PC is mapped properly). In the case of this customer they have remote stations as well, which also provides for a delay. (The trace above was from MY local ATE to their server).
You are correct in that if the PC "sees" the directory it will return an OK very quickly. If it doesnt, the delay persists. It is our intention to upgrade all sites to 6.0 as needed, perhaps if you add the timeout option it would provide me additional incentive when talking them into upgrading
As an aside, in all my test cases, BYTES is never -15. It is always a -1 or -2 if the result is negative. So i suppose i could use your example above when BYTES<0? Just to make sure the input buffer is empty after the call. I think you are correct about the coded 2.5 second delay, i will remove that logic thanks.
Since this is only 1 program, it is convenient to make some local changes if it resolves the issue. If there are additional updates to 6.0 I can test those inhouse and if it provides a performance enhancement i can move towards an upgrade to this customer.
As always, thanks for your assistance.
From: Deerfield Beach, Florida | Registered: Sep 2002
| IP: Logged |
I added your recommendation and it has helped to clear the input buffer, thanks. I thought you might be interested in the trace below. It looks like when the return from miame,131 = -2 the buffer gets hungup. Thanks again for your help.
posted
My mistake on the -15 vs -2. (-15 occurs when there is a total breakdown of the ATE protocol, not just a timeout as in your case.) I think it would be safe to consider anything less than -1 as a probable timeout (particularly if there was a time delay of 5+ seconds during the call).
In your trace above, the XCALL GET following an immediate return of -1 from MIAMEX,131 (ex. lines 0-3) is just wasting 4 seconds, since you've already gotten the response and nothing else is going to arrive. It is only needed in the case where you receive -2 and there was a 5+ second delay (as in lines 12-15). Note that the XCALL GET (line 14) returned within 1 second, indicating that the MIAMEX,131 timeout occurred just before ATE sent its response (i.e. just before the network timeout).
So to improve my earlier example...
code:
T1 = TIME ! time the MX_FILESTATS call...
XCALL MIAMEX, MX_FILESTATS, "R", WORK, BYTES
! If the above timed out, BYTES will be -2 (or less), ! and at least 5 seconds will have elapsed, ! in which case we should wait to retrieve ! the delayed response
IF BYTES < -1 and (TIME-T1) >= 5 THEN CHAN = 0 ! keyboard BYTES'REQ = -2 ! input until CR BUFFER$ = "" TIMEOUT = 8000 ! 8 secs max XCALL GET, BUFFER$, CHAN, BYTES'REQ, BYTES'RCV, TIMEOUT BYTES = val(BUFFER$) ENDIF
On point #1, perhaps we should discuss that offline, as I think it is going to require looking at your code or adding more traces (to the server side) to pin down where the redundant MX_FILESTATS call is coming from. It's hard for me to imagine it could be generated within A-Shell, because A-Shell wouldn't have any other way of knowing about that particular .bmp filespec.
As for improving the actual performance of testing for an inoperative network location, 6.0 isn't going to solve that. I'm not sure anything can solve it. (This is based on the likely fact that if you type that UNC path into the Start menu Run/Search box, you'll probably get the same delay.) 6.0 would most likely eliminate the need for the workaround code snippet above (to deal with the timeout), since the timeout has been increased enough to probably prevent it from happening. But that isn't going to improve the "performance" (i.e. responsiveness).
About the only way I can see to improve the responsiveness in the MX_FILESTATS call would be to implement some kind of two-step, multi-thread mechanism. On receipt of the request, ATE could spawn a separate thread to do the file lookup, while setting a short timeout in the main thread (maybe 1.5 seconds). If the timer expires before the lookup has returned, it could send back a special code to the MX_FILESTATS call indicating that the operation is taking longer than expected. The application could then go on to do some other operations without waiting for the network timeout. Meanwhile, when the network lookup finally returns, ATE would just store the result, until the application requested it via a subsequent variation of the MX_FILESTATS call.
That would allow you to avoid the wait (or more specifically, to do something else during that time), but it requires rather complicated changes to your app, not to mention updating both ATE and A-Shell to support the new protocol. Furthermore, since the typical network timeout (*see below) seems to be several seconds, it would only be useful if you actually had several seconds worth of other stuff to do in the meantime. (Maybe if you sent the query immediately on startup and didn't need the answer until you got into an actual program, that might work, but if you need the result for the main menu display, several seconds would probably be way too long anyway.)
* Further note on the network timeout: Using the Start menu search/run box is probably a good way to test the range of delays. On my Windows 7 machine in a P2P workgroup, if I type in a totally bogus \\xyz\abc path, it takes about 25 seconds for it to respond that it couldn't find the directory. So that seems like a worst-case scenario, but one that could easily happen on a remote machine. If I enter \\server\abc where \\server is valid but there is no \abc share, the delay is not much better (maybe 20 seconds). But if I enter both requests in sequence, then the second delay is much shorter than the first. Also, the first time I enter a valid \\server\path, it sometimes takes a few seconds to respond, whereas subsequently it responds instantly to the same path. So in other words, the network delay is hard to predict (although most likely it would be much faster in a domain environment).
What we really need is a faster way to identify if a network path is valid or not.
From: Woodland Hills, CA | Registered: Jun 2001
| IP: Logged |
posted
It would certainly be nice to have a faster method to identify if a network host/path was valid, but if there was a reliable faster method there would be a Window's API call for it.
I just can't see how you can make it any faster; except, for perhaps in a domain environment where you have an authoritative WINS master.
-------------------- Stephen Funkhouser Diversified Data Solutions
From: Northwest Arkansas | Registered: Nov 2006
| IP: Logged |
posted
Thanks again for the analysis and recomendations.
With these latest tweaks i think we have souped up this hot rod about as much as we can for now.
Sometimes it comes straight down to the answer of "it is what it is". As is the case with the network search. Since this is a 1 time sign-in event for the customer i think a 4-5 second delay won't hinder productivity too much...
With fixing the input buffer and only waiting "if necessary" i think we are in good shape.
As far as the zoom1.bmp, dont worry, doesnt seem to be stealing away too many cpu cycles.. if for some reason you get bored and are fearing an onset of senility unless you debug something... let me know
From: Deerfield Beach, Florida | Registered: Sep 2002
| IP: Logged |
UBBFriend: Email this page to someone!
Printer-friendly view of this topic
![[Smile]](smile.gif)
![[Wink]](wink.gif)
