Capture feature

[KentIsland]

I'm having a little problem with the "capture" feature. While in a telent connection I issue a command to a Unix appl. that runs for a while then pours out a few hundred fairly short lines. After that I manually close the "capture" feature. When I review the file a few (5-6) lines are missing from the file. I work around and verify this by cutting and pasting the screen output (few hundred lines not too bad). Anybody else ever experience anything similiar, go figure. Think it may be a disk sector delay thing or something since it occurs at about the same place in the file every time.....huh!

 

[knob]

Are you using the capture command in your script, or are you using the Data | Capture File menu item manually? Is the data missing from the beginning or ending of the session?

 

[KentIsland]

I'm manually open the capture file, then after the screen output I manually close it, very straightforward. The missing few lines occur about 3/4 of the way into the file. When I cut and paste the screen output and put it into a file, the capture file is a few lines short.....
Huh!

 

[knob]

Hmm, that's an odd one. About how large is the capture file? When you look back in the scrollback buffer to copy the missing lines, approximately how many "pages" in the scrollback buffer are used in all? If you select the Edit | Scrollback Buffer to | File menu item, does this save the entire contents to a file successfully (there will likely be some extra data at the beginning of the file)?

 

[PhilBreau]

What capture options are used? If it's set up to capture as it appears on screen, there may be some escape sequences that re-position the cursor and not scroll the screen. This is not picked up by basic capture. Try selecting raw text including all escapes in your capture options.

 

[KentIsland]

I think I have the scroll back buffer set to 1000 pages way more than enough to hold the output. Since I telnet from Procomm I usually set the screen to 80x25 to avoid weirdness while using a VT100 terminal emulation. The output is usually about 400-500 30 byte lines. If I highlite and save to a file every line from the screen selection appears in the file, however the file created directly from the file capture feature drops some. Just to inject some sanity into the situation I sniffed the lan while the transfer from Unix(AIX4.3) was occurring and I didn't see any strange characters in the packets. I will try the "raw" setting to see if the problems changes. I think I will "cat" the file from a Linux box I have at home to see if I can reproduce it. If I can, you may be able to see it first hand. That way I wouldn't have to stare at the wall thinking I'm losing my mind. [

 

[KentIsland]

A breakthrough. I discovered that while using 132x50 the problem occurs in 3 term emulators (TTY,VT100,BBS), however if I use the (write raw or write filtered) recording options the problems goes away. If I change the screen size to 80x25 any of the recording options works with any of the 3 emulators. As to what the problem is don't have a clue. It seems like a reasonable remedy though......

Thanks for the interst.

If you think it's a real problem and find an answer I'd be interested.

 

[Guest_imported]

i am convinced this capture "feature" is a serious procomm flaw that never got fixed... there's more than one of these type of features in aspect-- by the way (PWMODE, $CONNECTOPEN, etc). my workaround requires taking total control of terminal display logging using file I/O... completely abandoning file capture.