[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

4058.0. "RS232 Console Interface" by UFHCOP::KMORRISSEY (California here I come) Tue Nov 10 1992 04:47

    Generally speaking,how would I go about managing a device with a serial
    (RS232) console interface.
    
    Today we would typically talk to the console via a reverse LAT Terminal
    Server port.
    
    Could I use this configuration with MCC (via the Ethernet/TS AM's ?) & 
    if so,how would I "pasthru" from my Product/Protocol specific AM ??
    
    I would think that the above would be a fairly common requirement ?.
    
    Any help much appreciated.
    
    
    				Kev.
    
    
T.RTitleUserPersonal
Name
DateLines
4058.1Can be very simple.TOOK::MCPHERSONpre-retinal integrationTue Nov 10 1992 08:4227
>    Generally speaking,how would I go about managing a device with a serial
>    (RS232) console interface.


    If you just want to open a terminal emulator session to the device and
    use the device's 'native' command line interface then that's trivial:

    	- register the deivce a REFERENCE object,  
    	- write a quicky launched application that picks up one of the
    	  objects identifiers,  
    	- create a file somewhere (a priori) that maps the objects
    	  identifier to a TTY (or LTA) port, 
    	- create a decterm do a set host/dte <port name> voila.

    If you have kermit installed on the system, that might be a little more
    robust that the "set host/dte" option.    also Kermit's dialling
    procedures would be a little more straightforward if the devices you
    want to talk to are dial-up in nature.  

    If you want to do more integrated things, then you'll need to do more
    sophisticated things like parse the ascii strings (or whatever the
    protocol is) etc.    [The less-defined the protocol, the uglier it
    gets...]    You may also be able to do some interesting things via the
    Script AM, but I haven't sat down and thought that one out very well...

    /doug

4058.2?UFHCOP::KMORRISSEYCalifornia here I comeTue Nov 10 1992 10:329
    Thanks,
    
    I do indeed wish to do some more sophisticated stuff than the standard
    CLI of the device,but wondered if there was some "vanilla" code that
    would help me get the Command Strings to/from the Box to MCC,thus
    simplifying the issue.
    
    Kev.
    
4058.3pointerCSOADM::ROTHKick out the jams!Wed Nov 11 1992 15:169
Check out the conferece UFP::MODEM, that tool might do the trick. It supports
scripts that can conditionally do various things based on input received. Also,
it supports sending out 'canned' character sequences.

MODEM is the internal product but it is availale as an ASSET tool for customers
as well.

Lee (long-time MODEM user)

4058.4Go to TBGTOOK::MATTHEWSThu Nov 12 1992 13:369
    You should also get in touch with the people in TBG in VBO. Pierre
    Jardin and John Harper are looking at doing an ASCII AM that would
    reduce the effort to develop support for such devices.
    
    FERIC::HARPER will get you in touch with John who is the group
    manager. He will put you in touch with the appropriate engineers
    or project leader.
    
    wally