Procomm waituntil command issues

[kyle83]

Hi,

I am using the script below to execute another script exactly every 3 minutes. Most of the time it works perfectly fine, but sometimes it seems that the script randomly doesn't acknowledge the waituntil command, and loops the "quantities" script over and over, really quickly. I run the script all day long and, again, it works like 90 percent of the time. Sometimes a couple hours in, it may crap out and start looping without waiting, and sometimes it will run flawlessly all day long. Today for example, right when i began running the script it started doing it, i restarted procomm and the computer (not the server), and it still does it. And it will probably continue to malfunction for another hour or so. I am running Procomm Plus 4.8, WinXP Home, and the server is an SCO Unix server. I connect to it via Telnet, which runs an OLD custom terminal application (inventory control). Can anyone help me or have any suggestions? Thanks in advance..

- Kyle

proc main
string QScript = "QUANTITIES"
string TimeString
long TimeNum
integer Loops = 0
while (Loops) < 1000
TimeString = $Time24
strsltime $DATE TimeString TimeNum
execute QScript
waituntil TimeNum + 180
Loops++
endwhile
endproc

 

[kodr]

I'm guessing here, but try adding 180 to TimeNum on a seperate line above the waituntil. See if that makes a difference.

 

[knob]

I don't see anything obviously wrong with the script or anything "tricky" for lack of a better word. In addition to kodr's suggestion, add a 'l' to the end of the addition to force ASPECT to recognize the 180 as a long (probably won't make a difference, but one possible gotcha). It would look like this:

TimeNum = TimeNum + 180L

You might also add the following lines below the waituntil command to check the return code (success or failure):

if success
statmsg "success"
else
statmsg "waituntil failed"
endif

If you see the "waituntil failed" message, you will know that the command failed for some reason and can investigate that further. If the "success" message shows up, then it is probably elsewhere in the script. You may need to switch from statmsg to usermsg if you are doing much that overwrites that contents of the status line.

Can you post the QUANTITIES script to see if there is anything possibly causing the problem there, or just replace it with some harmless like Procomm's hints script?

http://www.aspectscripting.com

 

[kyle83]

Thanks for the replies guys. I have implemented your suggestions and will be testing them for the next few days.. Like i said, its random, and my existing script is currently working for some reason, but will surely fail again some time soon.

Knob, here is the Quantities script, thanks a lot:
----------------------------------------------------------

proc main

transmit " PRINT IMSKU IMDLS IMDLR XIMQMN XIMQOM XIMQOH XIMQOO XIMQAL XIMQTD XIMQB\"
pause 1
transmit "^M"
waitfor "->"
pause 1
transmit "WHERE IMSEQNUM<99999"
pause 1
transmit "^M"
waitfor "'T'erminal, 'P'rinter, or 'F'ile? "
transmit "F^M"
waitfor " File Name? "
transmit "QUANTITIES.TXT^M"
waitfor "Q>"
endproc

 

[knob]

Does the Quantities script ever take more than the three minutes you have specfied in the waituntil command? With four waitfor commands, if the script wasn't synchronized right or something was wrong with the remote system, that would be two minutes of possible "dead time" due to a waitfor command exiting if the specified string isn't received after 30 seconds.

One other thing you might try doing is adding .wax to the end of the below line (inside the double quotes):

string QScript = "QUANTITIES"

This will force Procomm to run the compiled script and not recompile the source .was file under some circumstances. I saw this cause a weird problem once in the past but don't recall the exact symptons.

http://www.aspectscripting.com

 

[geirendre]

Is it possible for you to move the Qscript into the main script as a procedure insted?
I like using a logfile for debugging scripts...like this:

string logfile = "logfile.txt"  
string logtext       ; Textstring to put in logfile
proc main
string TimeString
long TimeNum
integer Loops = 0
   fopen 0 logfile create text
   while (Loops) < 1000
      TimeString = $Time24
      strsltime $DATE TimeString TimeNum
        strfmt logtext "Loop: %d Date: %s Timestring: %s TimeNum %d `n`r" Loops $DATE TimeString TimeNum
        fputs 0 logtext   ; write variables and timestamp to logfile
      call QScript
      waituntil TimeNum + 180
      Loops++        
   endwhile
   fclose 0
endproc

proc Qscript
 transmit "  PRINT IMSKU IMDLS IMDLR XIMQMN XIMQOM XIMQOH XIMQOO XIMQAL XIMQTD XIMQB\"
   pause 1
   transmit "^M"
    waitfor "->"
    pause 1
   transmit "WHERE IMSEQNUM<99999"
    pause 1
   transmit "^M"
    waitfor "'F'ile?"
   transmit "F^M"
    waitfor "File Name?"
   transmit "QUANTITIES.TXT^M"
    waitfor "Q>"
endproc

Note1: Notice the shorter waitfor "key", makes it more likely to get a match with what you receive from the Unix-maschine.

Note2: If the script shall run "forever" until you manualy stop it, you can use a while-loop like this:

while 1
   ; Do some stuff here
   ;
   if (some condition is true)
     exitwhile      ; break out of the loop
   endif
endwhile

this will loop forever until the condition inside the loop becomes true, or you manualy stop the script.
Hope this helps

 

[geirendre]

Pardon my "silly" question, but why do you use:

waituntil TimeNum + 180

Why not just

pause 180

???

 

[kodr]

That's obviously because you never want to use the simpilest technique. You have to make it as difficult as possible, that way you're constantly challenging yourself when you have to re-visit your own code and say 'why did I do it this way?'

Er, at least that's what I constantly tell myself.

 

[kyle83]

geirendre,

I did it this way because the "QUANTITIES" script has to BEGIN executing exactly 3 minutes after the START of the previous execution. The execution time for the script varies by a second or two each time, so this is the reasoning.

 

[kyle83]

anyways, im pretty sure i've got it squared away for now, thanks for all the help guys..