Conference csc32::consolemanager

    Bob,
      DO you have the Cisco's console port attached to a decserver 
    and if so how is the decserver port configured?
    
    Regs,
      Dan

    Dan,
    
    No DECserver, just a direct cable connection between the PCM host port
    and the Cisco's console port. Thinking about it a little more it seems
    like it's some kind of burst problem. I can connect and press return
    repeatedly and get the cisco's console prompt, but when I do something
    that outputs a few lines of data, I get disconnected or hung up.
    
    Bob

Bob,

  A wild guess, but is the cisco trying to do wierd modem control
  type stuff? which may cause the tt driver to think the line has
  hung up.

Cheers,
Phil

    Well, I think I've got it working ... I fell back on some old VCS
    settings for type ahead buffers and so far, it has worked. I set the
    following:
    
    TTY_ALTALARM = 320
    TTY_ALTYPAHD = 1500
    
    Then enabled type ahead on the Cisco's port:
    
    $ SET TERMINAL /PERMANENT /ALTYPEAHD TXA0:
    
    If anyone has better values, I'm all ears. BTW, the Cisco console port
    settings don't seem to matter. Works OK with the default settings.
    
    Bob

Bob,
    have you installed the ECO-1 kit for PCM as we did some work on direct
connect problems which we found to be associated with ALTYPEAHD and we ended up 
doing some explicit setting of port characteristics.

Phil just looked up the patch code and he says that he does now set the
ALTTYPEAHD param when setting up a direct connect.

So please try ECO-1.


Cheers Simon...

    I have not installed ECO-1, but I will. But please note that simply
    enabling ALTTYPEAHD on the terminal port was not enough. This let me
    know I was on the right track, cause I got more data out before PCM
    disconnected, but increasing the size of the alternate typeahead buffer
    is what prevents any lose of data. 
    
    Also, to respond to a couple notes back, modem signals were not the
    porblem, I eliminated all pins but 2,3, and 7 and still had the
    problem. This also helped me zero in on a XON/XOFF buffering problems.
    
    The single problem was typehead buffers being to small.
    
    Bob

  Bob, please install ECO1, you will most probably
  have to adjust the size of your typeahead buffers,
  but PCM will at least set ALTTYPEAHEAD on your
  direct lines.

  Let us know how you get on.

Cheers,
Phil

    OK, ... we're making progress. I've got ECO-1 installed. Everything
    looks good and the buffering seems to be working. But, of course, I'm
    not done yet! I'm now working on a DIALOG script ... and I'm having
    problems again. I can issue the same command interactively via the
    CONSOLE CONNECT and the output is fine. When I issue the command from a
    DIALOG script, I lose data. Any thoughts? Any suggestions for my TTY
    SYSGEN parameters? I've got them at:
    
    TTY_ALTYPAHD = 3000
    TTY_ALTALARM = 750
    
    I guess I can continue to bump them up ...
    
    Bob

    hmmmmmmm... when PCM is running, do a SHO TERM TXA1. See if the line
    is set Hostsync. If it isn't then this is also a problem as the PCM
    engine won't XOFF the Cisco thus increasing the size of the typeahead
    buffer (shile still a good idea and the correct thing to do) is
    only a band-aid. It could still break if you sent sufficient characters
    down the pipe.
    
    Regs,
      Dan

    HOSTSYNC is on ... even before the ECO-1. PCM takes of that. Still
    something going on here ...
    
    Bob

    You shouldn't have to bump these up if XON/XOFF flow control is 
    working and it seems to me that it isn't. VMS systems can send many
    opcom messages in a very short time and setting the altypahd/altalarm
    values to 1000/320 respectively has *always* been suffcient. These were
    the recommended values in the VCS environment and have worked since day
    1. Any time I have run into this problem it was becuase the remote side
    either failed to honor flow control or we had a busted port. If you plug 
    a terminal into the Cisco, issue a command that causes some lengthy output 
    and press ctrl-s, does the Cisco stop sending data? If it doesn't we
    have found the culprit.
    
    Regs,
      Dan

    Dan,
    
    Yes, I hear you Dan ... that's why its been a little frustrating ...
    one of the first things I did was connect a VT220 ... works great ... so
    does CONSOLE CONNECT no that I have the alternate typeahead buffer
    enabled.
    
    I've been told that even with XON/XOFF working properly, both ends of
    the line can still have problems seeing (and responding to) the XOFF
    character, depending on the implentation of the device driver or port
    software. My gut feel is that the Cisco just doesn't treat the XOFF
    with enough priority and it's response is too slow to prevent loss of
    data.
    
    Anyway, at this point everyting works OK but the DIALOG command. I'm
    just wondering if some thing is different about the DIALOG command, or
    just it simply introduce more timming issues. I guess I can test my
    theory above, by continuing to bump up the buffer sizes.
    
    Thanks,
    Bob

Bob,

  Is the problem the speed at which your DIALOG script sends
  its data to the CISCO box? if so, you may want to play with
  the RATE and undocumented SPEED dialog commands, RATE is
  documented as the time to wait (in seconds) between each
  SEND command, SPEED is the time to wait (in milliseconds)
  between each character in a send command (the default is 0).

  E.G.

!
! Wait for 1000 milliseconds between each character xmit on SEND
!
SPEED 1000 
!
SEND "HELLO"


Cheers,
Phil

    Phil,
      The problem is not sending as it is receiving. If he issues a command
    via DIALOG that causes some lengthy output he will run into the
    problem. Using WAIT statements to delay between command transmission
    would certainly help however.
    
    Re -2.
    
    
    Okay, let's assume that it is the Cisco box that is not responding to
    XOFF in a timely manner. So of course we will need a larger type-ahead
    buffer to give us a more "breathing room". My suggestion is to bump
    TTY_ALTYPAHD to 5000 and set TTY_ALTALARM to 1000. This would allow the
    terminal driver to XOFF when there is 1000 characters in the typeahead
    buffer which leaves us 4000 bytes to accomodate what may have already
    be coming down the pipe. At 9600 baud that would mean the Cisco
    has to respond to XOFF in roughly 4 seconds. If it doesn't then there's
    something *really wrong*.
    
    Regs,
      Dan

    Well,  something is really wrong!
    
    I've increased the buffer sizes and I get more data, but PCM still
    disconnects before I get it all. But, again, note, when I do a CONSOLE
    CONNECT it works OK. When I connect a VT220 it works OK.
    
    I'm at a loss to explain this behaivor. I would guess that the Cisco
    wasn't really doing XON/XOFF, but it does work with a terminal or a
    CONNECT. I can stop/start the display or let it go; no problem. Only
    DIALOG has the problem. 
    
    But I think I can get what I need by making the typeahead buffer big
    enough to handle my worst case burst of data. A kluge, but I suspect
    workable.
    
    Any other thoughts? ...
    
    Thanks for all the help so far,
    Bob

    I'm just having to much fun with this problem ...
    
    It appears that the larger buffers ARE working ... it just takes
    awhile, like 5 minutes, before it shows up in the logs! It seems that
    this large amount of data causes PCM to quit writing to the logs for
    awhile maybe? Anyway, I see the following:
    
    19-Oct-1994 12:44:33  access-list 101 permit ...
    19-Oct-1994 12:44:33  access-list 101 permit ...
    19-Oct-1994 12:44:33  access-list 101 permit ...
    19-Oct-1994 12:49:28  access-list 101 permit ...
    19-Oct-1994 12:49:28  access-list 101 permit ...
    19-Oct-1994 12:49:28  access-list 101 permit ...
    
    OR
    
    19-Oct-1994 12:50:07  access-list 102 permit ...
    19-Oct-1994 12:50:07  access-list 102 permit ...
    19-Oct-1994 12:50:07  access-list 102 permit ...
    19-Oct-1994 12:57:18  access-list 102 permit ...
    19-Oct-1994 12:57:18  access-list 102 permit ...
    
    It doesn't appear I'm lossing any data. Anyway I can count on the data
    being available in some know amount of time?
    
    Thanks,
    Bob

    It seems to me that I need to touch this system via a CONSOLE MONITOR
    command to get it to flush the data to the logs that I'm trying to
    extract.
    
    What I want to do is run a DIALOG script and, as soon as possible, get
    the results of the script into a file. I was doing the following:
    
    $ CONSOLE DIALOG ...
    $ WAIT ...
    $ CONSOLE EXTRACT ...
    
    But, no matter how long I wait, the data never shows up (not all of it
    anyway) until I do a CONSOLE MONITOR.
    
    Any other ideas on how to do this ... I'm so close. ;-)
    
    Thanks,
    Bob

    Bob,
      What you are seeing is expected behavior at this point in time. A
    change is forthcoming and Phil can give you a firmer committment. Your
    surmisal is correct too. If you do a MONITOR or CONNECT the 
    daemons ring-buffers are flushed.
    
    Regs,
      Dan

  OK, as V2.0 will not be available for about 12 months for customers,
  I am looking at trying to get a small piece of code into
  the daemon to do a regular flush of the daemons buffers, this
  will be available in the next ECO/MUP kit we produce, but it
  will take some time for us to test before we will feel comfortable
  with releasing it.

Cheers,
Phil

    Hi Phil,
    
    Is there any work around to force the buffers to be flushed that can be
    executed from batch? MONITOR and CONNECT don't do it from batch.
    
    Any idea when the next MUP/ECO would be available ... not trying to
    press, just curious ;-)
    
    This delay of flushing, which is reflected in the timestamps ... isn't
    this a problem? Doesn't this mean the time stamps reflect when the
    buffers were flushed, instead of when the data was produced at the
    console?
    
    Thanks for all the help on this "collection" of problems.
    Bob

Bob,

    
>>    Is there any work around to force the buffers to be flushed that can be
>>    executed from batch? MONITOR and CONNECT don't do it from batch.

  I guess an extract would do it.
    
>>    Any idea when the next MUP/ECO would be available ... not trying to
>>    press, just curious ;-)
  
  Weeelll, the guy who puts our ULTRIX and OSF kits together just went on 5
  weeks vacation and we were planning to start the ball rolling on the MUP
  when he returns, so, say the first/second week of December should see
  something "on the streets".
  
>>    This delay of flushing, which is reflected in the timestamps ... isn't
>>    this a problem? Doesn't this mean the time stamps reflect when the
>>    buffers were flushed, instead of when the data was produced at the
>>    console?

  Correct!! I am at the moment investigating having a timer go off in the
  daemon in order to flush these buffers on a more regular basis, perhaps
  say once every minute, the next major release will of course remove this
  problem entirely.
    
>>    Thanks for all the help on this "collection" of problems.

  Anytime.

Cheers,
Phil
 

    Phil,
    
    EXTRACT does not do the trick. That's the problem, see .17. I'm looking
    for something else I can do from batch that will flush the buffers
    before I issue the extract so I can get the results of the DIALOG.
    Maybe the answer is there's nothing I can do, but anything that would
    do this would get me working until the next release.
    
    Thanks,
    Bob

Bob,

  It looks like you have hit the problem I have been investigating, that
  is, EXTRACT tells the daemon to do a flush, however, the data doesnt
  appear to be available immediately, I hope this too will be fixed for
  the MUP kit. Its just that I have sooo much to do and sooo little time,
  but, I am sure you know all about that story ;-)

Cheers,
Phil

    Any word on a patch for this problem or when the next release is due?
    
    Thanks,
    Brad

    There's been a new release since last Oct. Please try it and see if
    the problem is fixed. My guess is that it has. We haven't heard of
    anyone else having this problem.
    
    Dave