minicom vs. hardware flow control

[jb1@btstream.com]

Package: minicom
Version: 1.83.1-8 (and later?)

Hardware flow control with a null-modem cable became inoperative after
upgrading from minicom-1.83.1-4.i386.rpm to minicom-1.83.1-8.i386.rpm on a
Red Hat 7.0 installation. I'm fairly certain that I made no other changes
that could cause this problem, and the minicom-1.83.1 installed by
Slackware Zipslack 8.0 also fails to do hardware flow control. Both, of
course, have the "Serial port setup" entries:
	F - Hardware Flow Control : Yes
	G - Software Flow Control : No
In truth, I'm not certain that hardware flow control worked even with 
version 1.83.1-4, but zmodem file transfers worked with few errors at 
moderate baud rates; with version 1.83.1-8 there are frequent errors even 
at 300 bits-per-second.

After observing that:
	stty -a -F /dev/ttyS0
reports "-crtscts" immediately after bootup, I found that issuing:
	stty -F /dev/ttyS0 crtscts
before launching minicom is an inconvenient, but effective, workaround to
enable RTS/CTS handshaking on ttyS0.

This seems to be related to bug #109 (minicom disables flow control for
real terminal) and bug #300077 (Minicom fails to initialize serial port)  
in http://lists.alioth.debian.org/pipermail/minicom-devel/2003.txt. It
appears that minicom's "Serial port setup" flow control configuration is
merely decorative.