$RXCOUNT and comgetc

[putz0999]

Hi,

I am curious if anyone has experienced a problem with $RXCOUNT showing a positive value (received data waiting in receive buffer), but the comgetc command returns a -1, which indicates no data in the receive buffer.

If I continue looping, the correct data appears in the recieve buffer, and the comgetc command then returns a valid character.

It looks like the $RXCOUNT value is updated prior to the data actually appearing in the receive buffer.

This problem only occurs during a long response (>1000 chars received) and does not always happen at the same depth. Adding "fluff" code seems to change the apparent response depth when the condition occurs.

I have a possible work around, but am curious how others have resolved this problem.

Any suggestions.

Thank you.

Putz

 

[knob]

I've not run into this problem myself, but I almost never use comgetc. Is there a reason you need to get data character by character, or could you use rget to grab it in chunks, or use snapshot to save the screen to a text file and get the information that way?

http://www.aspectscripting.com

 

[putz0999]

Thanks, knob, for the response.

I'm developing some code to handle unattended file uploads to a couple of different models of Nortel DMS switches, over a 10mb telnet connection. I want to make the "background" app be smart enough to take appropriate action based on many different response possibilities. This "backend" program will be used as a frontend for several types of ongoing needs, both for translations and system maintenance.

I have written a couple of similar app's in the past, but always using a different comm package. Telix is actually my favorite.

Because I am reasonably new to Aspect (20+ years programming other languages), I am still searching for and investigating the "quirks".

I have put a loop in the code to just ignore the -1 return and keep checking till the return is valid. This seems to work ok.

The strange thing about this problem, is that the receive buffer has data in it, when it "fails". In testing, I had it print the $RXCOUNT value and the character received from the comgetc function on every loop. I watched the $RXCOUNT value jump up to >1000 and begin counting down as the characters were read, no problem. Because the response was actually 5000-6000 characters, the $RXCOUNT value jumped up from around 500 to 5000 as it continued reading the data from the switch. When I ran the code this way, it never failed. I am speculating that by multi-processing every character (eating cpu time), I slowed the frequency of the comgetc command just enough to allow the buffer to adjust. I was able to move the point of failure to different depths in the response, by adding or subtracting "fluff" code.

I don't know the internal handling of the receive buffer, but it seems like it is taken "offline" momentarily, while it reallocates itself, or adjusts the data within it.

Does anyone know the size of the receive buffer, or how/when it would need to reallocate the space??

Thanks again, knob. I hope we chat more soon. I'll probably check this forum out a bit for other "Tips and Tricks". I'm curious about pointers, memory allocation, structures, filename handling, date/time, etc. The little I've seen of the forum so far, looks interesting.

Putz