Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Random Capture File Corruption (ADP/R&R)

Status
Not open for further replies.
Apr 16, 2007
7
US
Hi,

Am using aspect to capture output from ADP and Reynolds & Reynolds DMS boxes.

Typically, we connect in the mid 20k bps range using internal USR 56k modems (that I *think* have 16550 UARTs).

And, almost without fail (esp on the ADP systems) we run into the problem of corrupt capture files. Example:

JAN 0 2
FEB 2 0
MA2 JUN 2 0

MA2 should never show up, nor should the JUN on that same line. I realize that this is likely not a problem w/aspect, but I'm at my breaking point w/this issue. The capture files vary in size - sometimes this problem manifests in a capture files w/no more than 100 lines. Other times we are able to get 100+ MB of ASCII data w/o a single error.

Crap modems? Crap phone lines? Crap programming skills?

RTS/CTS is enabled as is V42/LAPM/V34 (sry my BBS days have long been over, pls excuse any erroneous acronym usage).

Suggestions/comments are greatly appreciated. Thank you.


Signed,

1337hax0rz
 
Do you see the same problem if you look in Procomm's scrollback buffer and compare it to the capture file output? You can bump up the memory allocated to the scrollback buffer by selecting the Options | Data Options | Terminal Options, selecting your particular terminal emulation if necessary, and increasing the value of the scrollback pags field.

What happens if you manually open and close a capture file outside of your script? That would help narrow down where the problem may be and eliminate the script as the issue.

Does it seem to occur during a specific sequence or output from a particular command?



 
Just ran it again, paying closer attention to the scrollback buffer, and yes, the problem appears on-screen as well as in the capture file.

These errors crop up while capturing reports generated by the wacky "query" languages that these systems use.

It seems to occur most often when the incoming text seems to pause for a bit and then gets dumped at a seemingly-faster rate. I vaguely remember this being a fairly common occurrence from my BBS days, but back then the integrity of the on-screen text was of no import.

I was considering attempting initiating an ASCII getfile rather than capture on - any chance that this would make a difference?

Thanks for your assistance!
 
Ok, well I took another look at the captured scrollback buffer, and noticed that there were no errors in the capture file (non-scrollback).

I had the scrollback page buffer set to 500, and there are no errors in either of the files at at that location.

I *did* however notice errors on the scrollback when I was running the report, but they aren't in the scrollback that I just saved to disk.

I'll try running it again at 1300 pages (the max for scrollback?)

Thanks again!
 
Ok, tried it again, but this time found the same error in the scrollback as is in the capture file.

I tried throttling back the port speed to no avail.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top