T.R | Title | User | Personal Name | Date | Lines |
---|
201.1 | | OPG::PHILIP | And through the square window... | Thu Mar 03 1994 09:42 | 55 |
|
>> I'm working with CM1.1 for openvms, DS700, TCP/IP and VAX7610 on the
>> console lines.
>>
>> 1/ I have a problem with sending breaks (I've read 125.*):
>>
>> If the VAX7610 is at the console prompt or initialising I can send
>> breaks. OK
>> But if the VAX7610's are up either at SYSBOOT, VMS or 'Shutdown waiting
>> for a break', I can not send breaks that have any effect.
>>
>> What is going on here?, its pretty bad not being able to send breaks
>> unless are at the console prompt!
My guess is that VMS is ignoring your break signal, we dont do anything
different when the O/S is running from when the system is halted (how
are we to know which state is which?)
>> 2/ I went though a whole squence of CM failing over every time I tryied
>> to connect to a console this afternoon. I have since reset some of the
>> TCP/IP parameters on the server relating to 'brk' and it seems OK now
>> but my question is: Is there any where that I can look to see why CM
>> has fallen over or failing to connect to a port?
By "failing over" do you mean that CM was continually trying to reconnect
to the console, or do you mean the software kept exiting on you and failing
to run properly? If the latter, you should get an event each time the
reconnect fails, the event information field usually should indicate the
reason for the failure, but as we simply translate the error code, this
unfortunately is sometimes a little vague.
>> 3/ You may want to look in CONSOLE$PRIVATE_LOGICALS.TEMPLATE;1 I belive
>> the following line is a bug.
>>
>> IF F$TRNLNM("Console$LOGICAL_NAMES","LNM$SYSTEM_DIRECTORY") .ESQ. ""
>> ^^^
>> should be EQS I think. (it works better when you change it ;-) )
Thanks, fixed in the next kit.
>> 4/ Are there going to be scan profiles for VMS, UNIX and the like in
>> the final product, or do I have to write my own?
This has been discussed at length elsewhere in this conference, can I
suggest you take a look at those notes (sorry I dont know the notes
numbers offhand).
>> All in all I like CM very much compared to VCS, Thanks.
Glad you like it, this is the kind of feedback we like, keep it coming,
monetary donations will also be received with thanks ;-)
Cheers,
Phil
|
201.2 | Whens a break not a break (when its a kit kat!) | FILTON::PACK_J | Cloud Base is heaven | Fri Mar 04 1994 10:00 | 28 |
|
> My guess is that VMS is ignoring your break signal, we dont do anything
> different when the O/S is running from when the system is halted (how
> are we to know which state is which?)
Sure I didn't expect CM do be doing anything different. But the fact is
I can't get VMS to recognize the break and its a real problem. Does any
one know or can guess at whats going on here?
Are there variations in posible break signals, ie a 7 bit break and an
eight bit break does VMS only recognize one type? Any ideas?
> By "failing over" do you mean that CM was continually trying to reconnect
> to the console, or do you mean the software kept exiting on you and failing
> to run properly?
I meant BOTH! I know now to look at the events after a connect fails.
So the question remaining is there any where I should look for why CM
fails, (exits, crashes what ever). (This is not a problem right now but
if we get into this loop again I'd like to have somewhere to look for
clues)
>>> monetary donations will also be received with thanks ;-)
Yes it obvious that you and I work for the same company :-)
:J
|
201.3 | | OPG::PHILIP | And through the square window... | Fri Mar 04 1994 10:27 | 29 |
|
> Sure I didn't expect CM do be doing anything different. But the fact is
> I can't get VMS to recognize the break and its a real problem. Does any
> one know or can guess at whats going on here?
>
> Are there variations in posible break signals, ie a 7 bit break and an
> eight bit break does VMS only recognize one type? Any ideas?
Is this an AXP system? If so, break (and CTRL-P) are not guaranteed to
work all the time! Its a feature of the way VMS uses the console callbacks
in the firmware (PAL code) on these systems that causes it.
There is only one "BREAK" signal, it is when you set the transmit line to
either a mark or a space (cant remember which) for a predetermined time
span (1.5 seconds I think).
> I meant BOTH! I know now to look at the events after a connect fails.
> So the question remaining is there any where I should look for why CM
> fails, (exits, crashes what ever). (This is not a problem right now but
> if we get into this loop again I'd like to have somewhere to look for
> clues)
I refer you to note 170 which describes how to turn on debugging for Console
Manager. Do I need to mention that we are ALWAYS interested in accvio's and
you should report them in this conference enclosing an export of your
database and the sequence of commands you used to cause the accvio.
Cheers,
Phil
|
201.4 | VAX | FILTON::PACK_J | Cloud Base is heaven | Fri Mar 04 1994 14:33 | 13 |
| > Is this an AXP system? If so, break (and CTRL-P) are not guaranteed to
> work all the time! Its a feature of the way VMS uses the console callbacks
> in the firmware (PAL code) on these systems that causes it.
> There is only one "BREAK" signal, it is when you set the transmit line to
> either a mark or a space (cant remember which) for a predetermined time
> span (1.5 seconds I think).
No these are VAX7610's and if there is only one type of break its
sounding more and more like the 7610 console. I'm gonna take a walk and
talk to the hardware enginners...
:J
|
201.5 | No problem on stars | FILTON::PACK_J | Cloud Base is heaven | Fri Mar 04 1994 14:54 | 15 |
| >> There is only one "BREAK" signal, it is when you set the transmit line to
>> either a mark or a space (cant remember which) for a predetermined time
>> span (1.5 seconds I think).
>
> No these are VAX7610's and if there is only one type of break its
> sounding more and more like the 7610 console. I'm gonna take a walk and
> talk to the hardware enginners...
Well we've looked on STARS and learnt many things but we didn't find
anything documenting problems with break on VAX7610's.
Any more ideas?
:J
|
201.6 | Something to try | ZENDIA::DBIGELOW | Innovate, Integrate, Evaporate | Fri Mar 04 1994 20:47 | 49 |
| J,
Did you previously use VCS to manage this system? If so, did the
break functionality work?
I did a little experimenting to work around PCM and it goes like
this (assuming you're using VMS):
1. Shutdown PCM.
2. Create your own lat device using LATCP.
LATCP> create port lta100 (Or whatever number that is not being
used, such as lta101, lta102, etc)
LATCP> SET PORT LTA100/NODE=terminal_server_name/PORT=port_name
LATCP> SHOW PORT LTA100
Local Port Name: _LTA100: Local Port Type: Application
(Queued)
Local Port State: Inactive
Connected Link:
Target Port Name: PORT_1 Actual Port Name:
Target Node Name: LAT171 Actual Node Name:
Target Service Name: Actual Service Name:
LATCP>exit
$set host/dte lta100
%REM-I-TOQUIT, connection established
Press Ctrl/\ to quit, Ctrl/@ for command mode
( Make sure you have full connectivity. You should be able to login into)
( the console at this point. You'll have to be careful using set)
( host/dte as I noticed that it tends to hang your terminal if not used)
( properly)
(Now, press the Ctrl_@ to get to command mode)
DTEPAD> send break
( This should mimic what PCM is doing. Hopefully, you'll have the same)
( problems here, which points to the terminal server as being the)
( culprit.)
Dave
|
201.7 | I'll try it | FILTON::PACK_J | Cloud Base is heaven | Sat Mar 05 1994 23:32 | 16 |
|
Dave:
Thanks for your reply I wish I'd seen this morning I've been on site all
day. I may not be back to site for a week at least a week.
This is a virgin install no VCS, was going to be but they insisted on
TCP/IP. I personally suspect we must have a problem with the Terminal
server sending a sub standard break. I'll let you know how I get on
with the set host/dte.
:J
Btw: One of my previous notes hinted at console manager droping the
lines and not making connections. The site may have big problems with
its network - like its just seems to stop occansionally, thats DECNET, LAT
and TCP/IP stop working and then later start up again!
|
201.8 | | OPG::SIMON | | Mon Mar 07 1994 09:41 | 13 |
| Jeremy,
which version of the DS700 terminal servers are you using. Sorry, that
should read the software for the DS700 and are you setting up your connections
via LAT or TELNET. The reason I ask is that BREAK from a host initiated TELENT
session has only been supported since the Network Access Software V1.0. Older
versions of the DS700 software wont't do TELNET BREAK only through LAT.
If you are using LAT or if you have the "Network Access Software V1.0" try
putting a Break out box in the line from the terminal server to the Vax. Issuer
the break and you should see the Tx line from the server cahnge state for a
second or so ( very visabale on the break out boxes with LED displays.
Cheers Simon....
|
201.9 | WWENG1 | FILTON::PACK_J | Cloud Base is heaven | Wed Mar 09 1994 17:13 | 14 |
| Simon:
The customer claims that the server claims to be running:
WWENG1
Decserver700-08 V1.1 BL44-11
LAT V5.1
ROMV3.4-9
How do I know if this is the "Network access software V1.0" ?
I still intend to get to site sometime and try 201.6 and 201.8
:J
|
201.10 | And now for the bad news!!! | OPG::SIMON | | Wed Mar 09 1994 21:36 | 18 |
| Jeremy,
things are now clearer. The version of the DECserver software
you are running does NOT support the TELNET break option from the
TELNET listener.
You require the NAS software version 1.0 ( NAS being Network Access
software). The ral bugbear here is that I would guess the terminal
servers have 1 MByte of memory in them. the NAS requires more than
that, I think 2Mbytes was minimum, but check that with a better
authority. the TELNET Break was added with that Sware.
So the long and short of it is that PCM is send a TELNET Break protocol
message and the terminal server just ignores it.
If you want more info on this let me know.
Cheers Simon....
|