geoff@ugc.uucp (Geoff Coleman) (06/07/91)
We have come across an interesting problem that IBM seem's unable (or unwilling) to duplicate. At times when our machine is running full out (ie. no idle time for 60+ minutes) if a person cu's to another machine on exiting the cu the rs/6000 will not always drop dtr. This in turn means the phone line may not get dropped. This can become a very expensive proposition when you are supporting customers across Canda. The latest response from IBM (the problem report has been open for months) is to run the lines as share rather than delay but whenever I run the lines as "share" they immediately get locked and you can't cu out on them. If anyone out there has telebit's (either 2500, 1000 or pluses) running on an RS/6000 in share mode I would appreciate a copy of your register settings. Or if you have tried to get modems to work in share mode on version 3003 or greater and haven't been able to I would like to know (the support person I was talking to said that as far as they knew everyone was using share rather than delay) Thanks for any info Geoff Coleman e-mail: geoff@edm.uucp
Robin D. Wilson (06/08/91)
In article <1991Jun7.034510.4004@ugc.uucp> geoff@ugc.uucp (Geoff Coleman) writes: > > We have come across an interesting problem that IBM seem's unable > (or unwilling) to duplicate. At times when our machine is running full out > (ie. no idle time for 60+ minutes) if a person cu's to another machine > on exiting the cu the rs/6000 will not always drop dtr. This in turn means > the phone line may not get dropped. This can become a very expensive > proposition when you are supporting customers across Canda. IBM is never "unwilling" to duplicate a problem. This one just doesn't exist. Sorry Geoff, but thems the facts. I have worked EXTENSIVELY with tty's and modems... the simple fact is, when the port is properly closed, the tty device driver HANGS UP (this means drops DTR). Now, it is possible that the process you have running on the port is not exiting cleanly, but I have NEVER seen this happen with "cu". It is also possible that the carrier is not being dropped on the remote end... (Do you use "~." to exit, or do you log out of the remote machine?) If you logout, then I would look at the remote machine's tty/modem setups, if you use the "~." method to exit, then I would look at both the local and the remote machine's tty/modem setups. Make sure that you have "HUPCL" set in "stty settings for run time/login". > The latest response from IBM (the problem report has been open for > months) is to run the lines as share rather than delay but whenever I run the > lines as "share" they immediately get locked and you can't cu out on them. I am not surprised by this answer, even if it is wrong. You should be able to use DELAY without trouble after the 3003 update has been applied (I know I could). The problem you describe with "SHARE" here seems to be the same as the old 3002 problems. You really need to verify that you have 3003 install. If you do, you need to check and make sure that the modem has CD set to "follow true carrier" (Hayes command mode == AT&C1; Enhanced (telebit) command mode == S131=1). You also need to set "DTR signal handling" to be "Modem disconnects and enters command mode when DTR is dropped" (Hayes command mode == AT&D2 (or &D3); Enhanced command mode == S52=4 OR S52=2). Mail me at "pensoft!robin" and I will send you a "modem setup guide" that will explain why all this is necessary. > If anyone out there has telebit's (either 2500, 1000 or pluses) > running on an RS/6000 in share mode I would appreciate a copy of your > register settings. Or if you have tried to get modems to work in share mode > on version 3003 or greater and haven't been able to I would like to know > (the support person I was talking to said that as far as they knew > everyone was using share rather than delay) Who said this... (Please mail me directly.) I will straighten them out. DELAY works fine. +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: pensoft!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)343-1111 | +-----------------------------------------------------------------------------+
rbraun@spdcc.COM (Rich Braun) (06/12/91)
geoff@ugc.uucp (Geoff Coleman) writes: > The latest response from IBM (the problem report has been open for >months) is to run the lines as share rather than delay but whenever I run the >lines as "share" they immediately get locked and you can't cu out on them. I think you just plain lose, whether you're running 3.1.1, 3.1.3, or 3.1.5. I've thus far gotten no resolution out of IBM on this topic, though to their credit they've kept in contact with me fairly well. The problem, as I see it, is that getty doesn't respect the Carrier Detect signal if "share" is selected. It should *not* assert the /etc/locks file until Carrier Detect is present, but it does (and hence prevents cu or uucp from sharing the line). As I understand it, "delay" is not to be used for dialups. It causes the device driver to ignore Carrier Detect entirely, which means a session can remain logged in indefinitely as you've reported (whether dial-in or dial-out, as in your case). The IBM doc doesn't say this explicitly enough, IMHO. The only suitable settings for dialups are "share" and "enable", and "share" doesn't work. I wish to file a formal, written bug report on this topic, now that IBM has closed out the problem number I'd previously filed via phone/e-mail. How do I go about this? -rich
jfh@rpp386.cactus.org (John F Haugh II) (06/12/91)
In article <7815@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >As I understand it, "delay" is not to be used for dialups. It causes >the device driver to ignore Carrier Detect entirely, which means a session >can remain logged in indefinitely as you've reported (whether dial-in or >dial-out, as in your case). The IBM doc doesn't say this explicitly >enough, IMHO. The only suitable settings for dialups are "share" and >"enable", and "share" doesn't work. A setting of "delay" is supposed to work for dialups, as is "share". The only difference between "share" and "delay", in theory, is that "delay" causes TSM to wait for a single character to be read prior to setting the lock in /etc/locks and "share" sets the lock the moment that DCD comes up. Ignoring DCD is caused, most likely, by an incorrect setting of HUPCL and CLOCAL in the SMIT panel for terminal settings. Even on this system, if you turn on CLOCAL and turn off HUPCL, hanging up the phone leaves the session connected. This is how it is supposed to work. If you go into SMIT and "clocal" is turned off and "hupcl" is turned on and "delay" still doesn't log off the user, open an APAR. >I wish to file a formal, written bug report on this topic, now that IBM >has closed out the problem number I'd previously filed via phone/e-mail. >How do I go about this? Call the Defect Support number and tell them that the PMR/APAR that you had opened earlier wasn't fixed correctly. One other point - the IBMer that closed your problem should be chewed out for doing so. APARs should only be closed after the testcase that is provided (by you or worked up by them) has successfully passed. I'm sure that Brad is laying around here somewheres waiting to explain what happened with this particular problem. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "If liberals interpreted the 2nd Amendment the same way they interpret the rest of the Constitution, gun ownership would be mandatory."
geoff@ugc.uucp (Geoff Coleman) (06/13/91)
In article <19375@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > >A setting of "delay" is supposed to work for dialups, as is "share". That's what I thought :-) >Ignoring DCD is caused, most likely, by an incorrect setting of >HUPCL and CLOCAL in the SMIT panel for terminal settings. Even on >this system, if you turn on CLOCAL and turn off HUPCL, hanging up the ^^^^ But in this case it is on. Further more the problem only surfaces when we are consistently running with 10 or greater % wait i/o. If the machine is not doing anything it has no problem hanging up DTR and the phone. >John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Any more ideas Geoff Coleman
Robin D. Wilson (06/13/91)
In article <7815@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: > geoff@ugc.uucp (Geoff Coleman) writes: > > The latest response from IBM (the problem report has been open for > >months) is to run the lines as share rather than delay but whenever I run the > >lines as "share" they immediately get locked and you can't cu out on them. > > The problem, as I see it, is that getty doesn't respect the Carrier Detect > signal if "share" is selected. It should *not* assert the /etc/locks file > until Carrier Detect is present, but it does (and hence prevents cu > or uucp from sharing the line). This is not true. When "SHARE" is selected "getty" uses CD to determine when to lock the port (as you suggest it should). In fact, when the modem and the tty are correctly set-up, this works just fine (after applying the 3003 update). I have corresponded with Rich on this very subject and it appears to me that he is using a back level "patch" that he is applying over the update. This is not a good thing to do. (This is so far... PURE CONJECTURE ON MY PART.) Anyway, it works fine for me after 3003 with Telebits, and Hayes. > As I understand it, "delay" is not to be used for dialups. It causes > the device driver to ignore Carrier Detect entirely, which means a session > can remain logged in indefinitely as you've reported (whether dial-in or > dial-out, as in your case). The IBM doc doesn't say this explicitly > enough, IMHO. The only suitable settings for dialups are "share" and > "enable", and "share" doesn't work. As far a "DELAY" not being used for dial-ups, please stop spreading this nasty rumor. "DELAY" works fine with both dial-up and direct connect. DELAY does use CD to control when to read and write the port, but it does not use CD to determine when to lock the port. DELAY waits to see a character on the serial input buffer before locking the port. THIS WORKS AFTER 3003. I have tried it with both direct connect serial connections, and modems. > I wish to file a formal, written bug report on this topic, now that IBM > has closed out the problem number I'd previously filed via phone/e-mail. > How do I go about this? You call 1-800-237-5511. I think you are wasting your time, this is not a software defect. Sorry. +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: pensoft!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)343-1111 | +-----------------------------------------------------------------------------+
rbraun@spdcc.COM (Rich Braun) (06/14/91)
pensoft!robin writes: >I have corresponded with Rich on this very subject and it appears to >me that he is using a back level "patch" that he is applying over the update. >This is not a good thing to do. (This is so far... PURE CONJECTURE ON MY >PART.) This is getting tedious; I don't really like the tone of your entire posting. Believe me, my system *does not work* even after looking at the guide you so graciously provided and at the documentation provided by IBM. The terminal line has 'hupcl' set and clocal not set. The patch (IX11286) is *clearly marked* by IBM as "for 3005 systems", and I am running 3005. There is one inconsistency, though: it also says "64-port fix" and I have an 8-port card. >As far a "DELAY" not being used for dial-ups, please stop spreading this nasty >rumor. "DELAY" works fine with both dial-up and direct connect. You should state this more clearly in the guide you put out; the way I interpreted it, the 'getty' program will do the wrong thing by locking the port if 'delay' is set and a character is received. *Most* modems these days will send characters at numerous points when carrier detect is not present. This needs to be spelled out in any documentation on the subject. Your document clearly implies that getty ignores carrier detect in making the decision to lock the port, if 'delay' is selected. >You call 1-800-237-5511. I think you are wasting your time, this is not a >software defect. Sorry. It need not be a software defect in order to be a major hassle for me. There are numerous line-control parameters which may not be set correctly, and I have yet to learn any means of fixing the problem. Therefore there *is* a problem with the software, the documentation, or (more likely) both. Please understand my point of view. thanks, -rich
jfh@rpp386.cactus.org (John F Haugh II) (06/15/91)
In article <7868@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >pensoft!robin writes: >>As far a "DELAY" not being used for dial-ups, please stop spreading this >>nasty rumor. "DELAY" works fine with both dial-up and direct connect. > >You should state this more clearly in the guide you put out; the way I >interpreted it, the 'getty' program will do the wrong thing by locking >the port if 'delay' is set and a character is received. *Most* modems >these days will send characters at numerous points when carrier detect >is not present. This needs to be spelled out in any documentation on >the subject. Your document clearly implies that getty ignores carrier >detect in making the decision to lock the port, if 'delay' is selected. OK. This is getting a bit silly. The code that handles "delay" does so by waiting for open to return then waiting for a character to be read. After this happens it sets the lock. If the lock fails, the port is opened by another application. This is exactly what the code does, and I know this because I wrote it. It has nothing to do with "ignoring carrier detect". It sounds to me like the TTY device driver is letting the open succeed if a character is present, or else the modem is doing strange things with the signals. I did try various tricks with TTY's and modems while working on the code, and it does appear to work quite correctly. My leaning is towards a problem with the modem [ since the machine that supports AIXServe is a S/6000 and uses modems and we know it works ] >>You call 1-800-237-5511. I think you are wasting your time, this is not a >>software defect. Sorry. Robin, you do not speak for IBM. Quit pretending you speak for IBM. You are no longer a contractor working on Level 2 support. >It need not be a software defect in order to be a major hassle for me. >There are numerous line-control parameters which may not be set correctly, >and I have yet to learn any means of fixing the problem. Therefore there >*is* a problem with the software, the documentation, or (more likely) both. This is what you are supposed to need for delay to work - * Modem set so DCD follows real DCD * Cable which supports DCD * Port set to "Delay" * CLOCAL turned off You can simulate your modem working in the following manner. Take a dumbascii terminal and connect it to your machine. Set up the parameters as described. Turn off the terminal and then turn it on. Press the <ENTER> key _once_. You should get a login prompt. Login as any user. Make certain that CLOCAL is off and HUPCL is on. Turn off the terminal. From another terminal check that your login session has been killed off. Turn back on the dumbascii and don't do anything for a minute or three. Notice that you don't get a prompt. Press the <ENTER> key once and you will get a prompt. If it doesn't work pretty much as I've described, something is wrong. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
mbrown@testsys.austin.ibm.com (Mark Brown) (06/16/91)
jfh@rpp386.cactus.org (John F Haugh II) writes: |>pensoft!robin writes: |>>You call 1-800-237-5511. I think you are wasting your time, this is not a |>>software defect. Sorry. | |Robin, you do not speak for IBM. Quit pretending you speak for IBM. |You are no longer a contractor working on Level 2 support. Um, folks, *none* of us here speak for IBM in any official capacity, so let's halt this particular thing right here, eh? Both of you have, and I hope will continue to, provide needed information here. I'd rather not have that lost in a flame-fest due to "tone" of postings. There's work being done on getting real Net-based customer support; until then (whenever "then" is) I'd like to see S/N remain as high as it has. Even with problems as sticky as this one seems to be. (ducks) -- DISCLAIMER: My views may be, and often are, independent of IBM official policy. Mark Brown IBM PSP Austin, TX. | Crazed Philosophy Student (512) 823-3741 VNET: MBROWN@AUSVMQ | Kills 15 In Existential Rage! MAIL: mbrown@testsys.austin.ibm.com | --tabloid headline
jackv@turnkey.tcc.com (Jack F. Vogel) (06/17/91)
In article <8512@awdprime.UUCP> mbrown@testsys.austin.ibm.com (Mark Brown) writes: >jfh@rpp386.cactus.org (John F Haugh II) writes: >|>pensoft!robin writes: >|>>You call 1-800-237-5511. I think you are wasting your time, this is not a >|>>software defect. Sorry. >| >|Robin, you do not speak for IBM. Quit pretending you speak for IBM. >|You are no longer a contractor working on Level 2 support. > >Um, folks, *none* of us here speak for IBM in any official capacity, so >let's halt this particular thing right here, eh? Of course *none* of us speaks for IBM in an official capacity! Hell, they'd have to pay me a lot more than I make now to take that kind of heat :-}! But in John's defense, not that he can't defend himself :-}, there is a slight difference between a posting from an experienced user, and one from an actual support or development person. John wrote a fair amount of code for AIX v3 and today works as an LCC contractor working on AIX 1.2.x. All he was saying is that Robin was coming across as if he was in this role and he no longer is. (I've never been to Austin and I don't know Robin, so no personal offense intended, just taking John's word). There are a lot of very knowledgeable end users out there and their wisdom is invaluable to this group. However if someone says the system does A and a level 3 person, looking at the source says it does B, who's word are you going to take?? Enough said? Peace! Disclaimer: I don't wear ties so of course I don't speak for LCC or IBM!! :-} -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
Robin D. Wilson (06/17/91)
In article <7868@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: > pensoft!robin writes: > This is getting tedious; I don't really like the tone of your entire posting. Frankly Rich, I don't care if you like the tone of my postings or not... I am not here as an official IBM representative, and I am not bound by any constraints to make any one person (or many people) happy here. I am responding to requests that I might have a little more inside knowledge on simply because I used to work with the group of people who actually did know what was going on with this system... You will note that I don't post responses to articles that I know nothing about, and I try not to get too snotty with people, simply because that's the way I AM... On the other hand, never bite the hand that feeds you. > Believe me, my system *does not work* even after looking at the guide > you so graciously provided and at the documentation provided by IBM. > The terminal line has 'hupcl' set and clocal not set. The patch (IX11286) > is *clearly marked* by IBM as "for 3005 systems", and I am running 3005. > There is one inconsistency, though: it also says "64-port fix" and I have > an 8-port card. It is possible I am wrong about the IX11286, if so I am sorry about mis-leading you. On the other hand, let me call my friends at level 2.... (I am calling right now).... (5 minute delay in this posting was caused by various discussions with a friend (including the fix level of IX11286)). I stand corrected (partially), the fix for IX11286 is in the 2006 update. Also, as Rich noted the IX11286 fix is for the 64port adapter card, and should not affect the 8 port card. > >As far a "DELAY" not being used for dial-ups, please stop spreading this nasty > >rumor. "DELAY" works fine with both dial-up and direct connect. > > You should state this more clearly in the guide you put out; the way I > interpreted it, the 'getty' program will do the wrong thing by locking > the port if 'delay' is set and a character is received. *Most* modems > these days will send characters at numerous points when carrier detect > is not present. This needs to be spelled out in any documentation on > the subject. Your document clearly implies that getty ignores carrier > detect in making the decision to lock the port, if 'delay' is selected. That is not what the guide says. Allow me to quote: DELAY: This setting is nearly identical to the "SHARE" setting, except the getty is called as: "getty -r" (which is the same as the AT&T uugetty -r) and this version of getty is waiting to see a character on the serial input buffer (read() on the tty doesn't return '0'). before it attempts to lock the port. So in the paragraph above, just replace all occurances of "CD" and "Carrier" with "Character on the serial input buffer". NOTE: the text says "...to lock the port." I never said, DELAY ignores carrier, or carrier is irrelavent to delay. In fact, carrier is always relavent on the serial port driver. If carrier is not high, the serial port driver does not read (OR WRITE) characters from/to the serial port. Unless the "CLOCAL" bit is set. When the modem is writing to the serial port, BEFORE carrier is high, those characters are buffered by some modems, and presented after carrier is high, and on other modems they are just discarded. STILL, some modems do like to talk to the serial port, before, during and after the conneciton is being established. They say things like "RING", and "CONNECT", and the serial port interprets these things as attempted logins. The way to solve this is to setup the modem correctly. (I believe if you read the rest of the guide you will find the string: Command Response should be set to respond to "LOCAL" commands only. In the text that follows, (a complete paragraph) I attempt (possibly this part is not well written) to describe why this is neccessary. Even so, I believe that this is needed on ANY VENDOR's system to prevent invalid LOGINS. Even on out old VAX 8650 (running VMS) this was a neccessary setting to prevent the modems from registering an invalid login. > >You call 1-800-237-5511. I think you are wasting your time, this is not a > >software defect. Sorry. > > It need not be a software defect in order to be a major hassle for me. > There are numerous line-control parameters which may not be set correctly, > and I have yet to learn any means of fixing the problem. Therefore there > *is* a problem with the software, the documentation, or (more likely) both. I disagree. The documentation is intended as a reference for users, and System Admins. It is not a text book with all you need to know about every part of the system. Given that many people seem to have the same problems with ttys that I had when I started learning about them, I wrote a "beginners" book on getting modems set up. But this is not to be mis-construed as an IBM book, or official IBM documentation. It is MY OPINION ONLY! The fact that you are having a problem understanding how to get this particular task done, does not make it a software DEFECT. Instead, you should take this up with an SE, or a marketing rep. > Please understand my point of view. Try to understand, this flame is not a result on not wanting to help. I am merely responding to the idea that I am here to serve you (or anyone on the net). I am here to serve my own special interests, and nothing else. I answer questions because I think (please note that even though I sometimes write using the tone: "I do know what I am talking about" -- it is ALL my OPINION, and I "at most" can only provide what I "THINK") I know the answer; nothing else. -- +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: pensoft!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)343-1111 | +-----------------------------------------------------------------------------+
Robin D. Wilson (06/17/91)
In article <19388@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > Robin, you do not speak for IBM. Quit pretending you speak for IBM. > You are no longer a contractor working on Level 2 support. I ALWAYS sign my posts with the following .signature: |The views expressed herein, are the sole responsibility of the typist at hand| Nyahh! -- +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: pensoft!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)343-1111 | +-----------------------------------------------------------------------------+
pa@curly.appmag.com (Pierre Asselin) (06/19/91)
In article <1991Jun17.142205.14173@pensoft.uucp> pensoft!robin writes: >...does not make it a software DEFECT. Instead, you should take this >up with an SE, or a marketing rep. In my case, and I don't think I am alone, this would be futile. The front-line support structure does not work; people in defect support have to understand that. Comp.unix.aix is vital. Meanwhile, Robin is right. This is Usenet. Nobody owes nobody nothin. -- --Pierre Asselin, R&D, Applied Magnetics. I speak for me.
robin@batman (Robin D. Wilson) (06/21/91)
In article <726@curly.appmag.com> pa@curly.appmag.com (Pierre Asselin) writes: > In article <1991Jun17.142205.14173@pensoft.uucp> pensoft!robin writes: > > >...does not make it a software DEFECT. Instead, you should take this > >up with an SE, or a marketing rep. > > In my case, and I don't think I am alone, this would be futile. The > front-line support structure does not work; people in defect support > have to understand that. Comp.unix.aix is vital. Granted, the SEs don't always know which end is up, but they do have a support structure for "how-to" and "config" problems. If it never gets used, it will never get better. This does not mean, "Don't use comp.unix.aix." It is just intended to emphasize that there is a plan in place, it just needs exercise. Also, (for everyone out there who'll listen) try to remember that comp.unix.aix is not an IBM official channel, so the information you get here, is (at best) subject to serious scrutiny. Even though many IBMers (and former contractors) post notes here, they do not speak for IBM "officially". > Meanwhile, Robin is right. This is Usenet. Nobody owes nobody nothin. (You can't see my head swelling up right now, I just love it when someone says I'm right!) -- +-----------------------------------------------------------------------------+ |The views expressed herein, are the sole responsibility of the typist at hand| +-----------------------------------------------------------------------------+ |UUCP: pensoft!robin | |USNail: 701 Canyon Bend Dr. | | Pflugerville, TX 78660 | | Home: (512)251-6889 Work: (512)343-1111 | +-----------------------------------------------------------------------------+
mike@bria.UUCP (mike.stefanik) (06/22/91)
In an article, pa@curly.appmag.com writes: >In my case, and I don't think I am alone, this would be futile. The >front-line support structure does not work; people in defect support >have to understand that. Comp.unix.aix is vital. Methinks that "futile" is a bit too strong. True enough, I have had my problems with bewildered support people; however, in the past few months, life has gotten considerably easier with these folk. Give 'em a break -- a few will even suprise ya'. :-) -- Mike Stefanik, MGI Inc., Los Angeles -- Opinions stated are never realistic! "To sin by silence when they should protest makes cowards out of men." -Lincoln