|
Short Description
|
TEACTION WAITFOR
|
|
Entered
|
By:
PeteL
When: 1998-05-21 12:57:51 Build: 1.03.11b
|
|
Categories
|
Type:
Problem
Department: Product
Category:
Screen Recognition
|
Description
|
(this would probably fall better into a generic SurferScript category, but I didn't see one)
I coded a TEACTION WAITFOR with a timeout of 5 seconds (this is for a "foreign" CICS system, I have no control over response time). It got a Screensurfer "ran out of stack" message, it suggested I run a trace. I did - this time it worked OK, but the trace showed a solid loop of restarting the template section with the WAITFOR. I don't have a problem with the loop, but is there something that's not getting cleaned up during the loop, and allocating stack entries?
|
|
|
|
Append
|
By: PeteL When: 1998-05-21 13:05:01 New Status:
Pending IE
|
|
Comment
|
here's the exact message:
During Execution of Template Section "nvas.medco_logoff" the enhancement code ran out of stack-- check for recursive execution of a screen section using the trace facility
it did it again after I took the trace out - maybe trace slowed it down some.
|
|
|
|
Append
|
By: WindSurfer When: 1998-05-21 13:10:35 New Status:
Accepted
|
|
Comment
|
SurferScript as a category is towards the bottom of the categories list, pending a minor upgrade to the way our JavaScript creates this list...
It sounds like the WAITFOR is recursing-- is the WAITFOR inside the section that is being "waited for"?
It sounds like the recognition engine isn't getting a SKIPCODE indicator during the WAITFOR loop--it is then finding the current screen and running it, which in turn encounters the WAITFOR and recurses-in to create a challenge to the stack allocation :) .
Will try to reproduce & fix for build 12 (available 5-22-98).
|
|
|
|
Append
|
By: PeteL When: 1998-05-21 13:29:30 New Status:
Pending IE
|
|
Comment
|
The WAITFOR is not in the section being waited for - it is an "extra" message sent during logoff from Merck-Medco's CICS system - when I get it, I don't want Screensurfer to stop, so I "recognized" the message, and simply told it to WAITFOR my application selection menu, which I know will be next. Certainly, since the current screen is already recognized, and it stays there until the waited-for screen shows up, if recognition is running, which it obviously must be to find the waited-for screen, in the meantime it will continue to find the current screen, which simply does the WAITFOR. There is no SKIPCODE, because that applies to the waited-for screen, which I want to process normally.
|
|
|
|
Append
|
By: PeteL When: 1998-05-21 13:32:56 New Status:
Pending IE
|
|
Comment
|
maybe internally do something like the RESTRICT on EXPECTING so that it won't recognize anything else besides what is being waited for during the timeout timeframe? This shouldn't be an added parameter, since this should be the default behavior of a WAITFOR anyway.
|
|
|
|
Append
|
By: WindSurfer When: 1998-05-21 16:40:00 New Status:
Accepted
|
|
Comment
|
Guess what-- RESTRICT was in the WAITFOR all along, and I'm not sure if you used it before or not-- do you have a grep or find utility? I've just put a nice one at ftp://ftp.ieinc2.com/pub/surfer/ff.exe, which you just run from the command line in a directory--ff *.stml waitfor will search all .stml files for the string waitfor and report to you where it is.
Stupid thing is, the RESTRICT was NOT the default, so if you left it out, it wouldn't restrict, and that is what is happening.
I've made it to be the default and changed the flag to NORESTRICT and updated the documentation (which made no mention of RESTRICT for WAITFOR!).
Fix in build 1.3.12, meanwhile, add the RESTRICT to your WAITFOR and it should fix the problem.
|
|
|
|
Append
|
By: WindSurfer When: 1998-05-22 15:51:54 New Status:
Pending Customer
|
|
Comment
|
Build 1.3.12 is now available at ftp://ftp.ieinc2.com/pub/surfer/ss1_3_12.zip
|
|
|
|
Append
|
By: PeteL When: 1998-05-26 08:50:08 New Status:
Closed
|
|
Comment
|
everything seems to be working OK, but my test case didn't trace the way I expected it to. Since it's not broken, I'm not going to worry about it.
|