Problem with capture files (sometimes they're empty)

[worknman]

I'm using the following code to capture the Procomm session while running an aspect script:

-------------------------------
set capture OVERWRITE ON
set capture recordmode FILTERED
set capture path <capturepath>
set capture file <filename>
capture ON
-------------------------------

It seems that Procomm only writes the capture session to the capture file when the script is done. However, we use a program at work (which I did not write and cannot modify) that runs a bunch of aspect scripts with the above code in a batch. If one of these scripts hangs (which they do from time-to-time), the program running the batch kills the running Procomm process after a certain time limit is reached, and thus terminates the aspect script before Procomm has a chance to write to the capture file. As a result, I end up with a 0k capture file, and I have no idea what went wrong with the script

Is there a way to tell Procomm to write to the capture file as it goes along, instead of waiting til the very end, or maybe some other way around this problem?

 

[knob]

To the best of my knowledge, the only way to force a write to a capture file is to use the capture OFF command to close it. If you are running multiple scripts, it would probably be a good idea to have each script close the capture file when it has finished so you can ensure that the data for that script was written successfully. You could then use the clear command to clear the screen (suggested so data on the last screen doesn't have the chance to appear twice in the capture file), then also modify each script to reopen the capture file when necessary. However, I noticed that the first set command in the code you copied overwrites an existing capture file of the same name. If that is only present in the first script you run, then you should be OK.

http://www.aspectscripting.com

 

[worknman]

However, I noticed that the first set command in the code you copied overwrites an existing capture file of the same name. If that is only present in the first script you run, then you should be OK.

Yeah, I should've been more clear about that The scripts run one at a time, since they are on a modem. Each script has its own capture file (there are 400+ running on several machines.)

To the best of my knowledge, the only way to force a write to a capture file is to use the capture OFF command to close it.

The only problem with this approach is that when/if a script happens to hang (usually because of crappy modem connections causing scripts to 'act weird' sometimes, and because I am not an expert ASPECT programmer), the code never reaches the capture OFF command before it is killed by the program running the batch of scripts (time limit exceeded), hence the log/capture file never gets written to. But if that's the only way to go about it, then perhaps the best I can do is multiple capture on/off commands in a single script, so at least I get part of a log instead of none at all.

 

[knob]

Sorry I haven't been around to follow up on this, was out of town the week before Memorial Day and then out again that weekend.

One thing you could try adding to the scripts is a when QUIET command at the beginning which could call a procedure that would close the capture file if no characters had been received for a specific time, possibly indicating that the script and the remote site are out of sync. You would want the delay time to be a bit shorter than the timeout value used by the utility that launches Procomm and the script. You would also need an exit or pwexit command at the end of the procedure to stop the script and/or close Procomm.

http://www.aspectscripting.com

 

[kxboy]

You can also try the snapshot command. Some terminal emulations do not write to the capture file until the screen is full, or it scrolls.

If the script is closed, before the screen scrolls, some of the data could be lost. I had this same problem with a script. It was driving me crazy, until I used the snapshot command after a waitquiet as knob suggested.