Sending out commands to TTA0 ?
Syltrem
I have an MSA1000 controller for which the console port is connected to
TTA0:
I can get there with :
$ SET HOST/DTE/SPEED=19200 TTA0:
and to get back to DCL I do Ctrl-\
Is there any simple way to do this in a batch job ? That is, I want to send
a command to the MSA console, get the response back into a file (SYS$OUTPUT
is fine), and disconnect.
I'd just like to get a SHOW TECH_SUPPORT regularly without having to do it
manually.
There's not monitoring tool that I know about, for VMS. HP has tools if you
have a Windows machine connected to the MSA, which I don't.
If you can share ideas...
Thanks
Syltrem
abrsvc
I believe that proper use of the assign of sys$input to sys$command
should do the trick. The assignment will change the input stream to
the command file. Sys$output should already be the logfile.
Dan
Simon Clubley
What's the current state of C-Kermit for VMS ?
This is a obvious candidate for a Kermit script.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Syltrem
"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
message news:inkpoh$4rn$1...@dont-email.me...
> On 2011-04-07, Syltrem <syltr...@videotron.ca> wrote:
>> Hi
>>
>> I have an MSA1000 controller for which the console port is connected to
>> TTA0:
>>
>> I can get there with :
>> $ SET HOST/DTE/SPEED=19200 TTA0:
>>
>> and to get back to DCL I do Ctrl-\
>>
>> Is there any simple way to do this in a batch job ? That is, I want to
>> send
>> a command to the MSA console, get the response back into a file
>> (SYS$OUTPUT
>> is fine), and disconnect.
>>
>> I'd just like to get a SHOW TECH_SUPPORT regularly without having to do
>> it
>> manually.
>> There's not monitoring tool that I know about, for VMS. HP has tools if
>> you
>> have a Windows machine connected to the MSA, which I don't.
>>
>> If you can share ideas...
>>
>
> What's the current state of C-Kermit for VMS ?
>
> This is a obvious candidate for a Kermit script.
>
I have not used Kermit in years and currently only have it for VAX. Will get
it for Alpha and IA64 and give that a try.
BTW, development for Kermit will end July 2011, for all platforms. (c.f.
http://www.columbia.edu/kermit/)
Thanks for the hint.
Simon Clubley
>
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
> message news:inkpoh$4rn$1...@dont-email.me...
>>
>>
>> This is a obvious candidate for a Kermit script.
>>
>
> I have not used Kermit in years and currently only have it for VAX. Will get
> it for Alpha and IA64 and give that a try.
> BTW, development for Kermit will end July 2011, for all platforms. (c.f.
> http://www.columbia.edu/kermit/)
>
That is most annoying; I didn't know about this.
Amongst other things, I've found Kermit makes a excellent tool for things
like scripting boot and image load sequences on some SBCs.
At least the current source should continue to work ok for a number of years.
Still, it's probably time to see what other open source comms programs have
a decent scripting language built in these days. The last time I looked
several years ago there was just Kermit.
> Thanks for the hint.
>
You are welcome.
Syltrem
"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
> On 2011-04-07, Syltrem <syltr...@videotron.ca> wrote:
>>
>> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>> message news:inkpoh$4rn$1...@dont-email.me...
>>>
>>> What's the current state of C-Kermit for VMS ?
>>>
>>> This is a obvious candidate for a Kermit script.
>>>
>>
>> I have not used Kermit in years and currently only have it for VAX. Will
>> get
>> it for Alpha and IA64 and give that a try.
>> BTW, development for Kermit will end July 2011, for all platforms. (c.f.
>> http://www.columbia.edu/kermit/)
>>
>
> That is most annoying; I didn't know about this.
>
> Amongst other things, I've found Kermit makes a excellent tool for things
> like scripting boot and image load sequences on some SBCs.
>
> At least the current source should continue to work ok for a number of
> years.
>
> Still, it's probably time to see what other open source comms programs
> have
> a decent scripting language built in these days. The last time I looked
> several years ago there was just Kermit.
>
>> Thanks for the hint.
>>
>
> You are welcome.
>
Only thing is, so far I could not find a binary for Alpha or IA64.
The link for the binaries table
http://www.columbia.edu/kermit/ck80binaries.html on the kermit web page
http://www.columbia.edu/kermit/ck80.html goes to a blank page...
Still looking. for it.
I may have to build it myself but didn't want to spend too much time over
it.
Syltrem
Jan-Erik Soderholm
Not tested, but maybe a simple "OPEN/RED/WRITE MSA_PORT TTA0:"
and then just "READ MSA_PORT" and "WRITE MSA_PORT" ?
Maybe with a /TIMEOUT=x on the READ so you don't hang if you
are reading in a loop...
Syltrem
"Jan-Erik Soderholm" <jan-erik....@telia.com> wrote in message
news:inkt00$lpf$1...@news.albasani.net...
Hi
This is the 1st thing I tried as it's so simple, but it does not return
anything
$ OPEN/REaD/WRITE MSA_PORT TTA0:
$ write MSA_PORT "show tech_support"
$ read MSA_PORT rec
--> gets stuck there
Syltrem
Syltrem
"Syltrem" <syltr...@videotron.ca> wrote in message
news:oFmnp.6938$qz1....@en-nntp-02.dc1.easynews.com...
I finally got it from http://www.columbia.edu/kermit/ckdaily.html and
building it was a breeze, and it includes Multinet support (which I need).
Now I just have to find out how to use it for my purpose.
C-Kermit 9.0.299 Alpha.09, 21 Sep 2010, for OpenVMS Alpha
Copyright (C) 1985, 2010,
Trustees of Columbia University in the City of New York.
Type ? or HELP for help.
Syltrem
Martin Vorlaender
> Only thing is, so far I could not find a binary for Alpha or IA64.
> The link for the binaries table
> http://www.columbia.edu/kermit/ck80binaries.html on the kermit web page
> http://www.columbia.edu/kermit/ck80.html goes to a blank page...
Yep, seems already fallen victim to bit rot.
> Still looking. for it.
You can find the last released binary versions (8.0.211 of April 2004) at
ftp://kermit.columbia.edu/kermit/bin/ckv-(vax|axp|i64)-vms*-(nonet|tgv|ucx)*.exe
(see ftp://kermit.columbia.edu/kermit/bin/ for a list).
> I may have to build it myself but didn't want to spend too much time over
> it.
Try it - it's easy.
cu,
Martin
--
One OS to rule them all | Martin Vorlaender | OpenVMS rules!
One OS to find them | work: m...@pdv-systeme.de
One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/
And in the Darkness bind them.| home: martin.v...@t-online.de
Jan-Erik Soderholm
OK.
Is it a given that TTA0: must be used ?
Normaly I think one would have put an terminal server
close to the MSA and done a TELNET/CREATE to create an
TNA-device (or if you have LAT, an LTA-device) and then
use that one for the I/O.
On one of my systems I just checked TTA0: has "device
type unknown", I do not know it it could help to set
it to something "known".
We set all terminal devices used to speak serialy over terminal
servers to PLCs and other serial interfaced equipment to "LA120".
Don't know why that one was selected...
Anyway, just guessing around here... :-)
Martin Vorlaender
> I finally got it from http://www.columbia.edu/kermit/ckdaily.html and
> building it was a breeze,
As I wrote - I built several versions, and it was easy every time.
(thanks Frank!)
> and it includes Multinet support (which I need).
>
> Now I just have to find out how to use it for my purpose.
>
> C-Kermit 9.0.299 Alpha.09, 21 Sep 2010, for OpenVMS Alpha
> Copyright (C) 1985, 2010,
> Trustees of Columbia University in the City of New York.
> Type ? or HELP for help.
Have a look at http://www.columbia.edu/kermit/ckscripts.html
It's not black magic (though I must admit the ilosetup script
is kind of tough).
Steven Schweda
> I finally got it fromhttp://www.columbia.edu/kermit/ckdaily.htmland
> building it was a breeze, and it includes Multinet support (which I need).
Building it _how_ was a breeze? The "x.zip" kit which I
just got seems to be missing "ckvker.mms". (Your Multinet is
too old to do UCX emulation properly?) Also, if you want to
evade compiler warnings in the SSL stuff, then "ck_ssl.c"
needs a couple of type casts:
http://antinode.info/ftp/kermit/v9r0_299_2010-09-21/
(Apparently, I failed to persuade Frank.) Otherwise, I don't
seem to have changed much lately, but I haven't done much with
it lately.
My usual build command looks like this:
@ CKVKER.COM S D "CK_SSL"
so my Kermit's ID string mentions SSL:
C-Kermit 9.0.299 Alpha.09, 21 Sep 2010, for OpenVMS Alpha+SSL
> [...]
> BTW, development for Kermit will end [...]
> [...]
Sad. I must be getting old.
jbriggs444
wrote:
> Syltrem wrote 2011-04-07 19:54:
>
>
>
>
>
As I understand it, It's a separate physical device. You
need a physical port to get there. A pseudo-device can't
put bits out into a DB-25 or a DB-9.
> Normaly I think one would have put an terminal server
> close to the MSA and done a TELNET/CREATE to create an
> TNA-device (or if you have LAT, an LTA-device) and then
> use that one for the I/O.
>
> On one of my systems I just checked TTA0: has "device
> type unknown", I do not know it it could help to set
> it to something "known".
Irrelevant. The device type doesn't affect anything
meaningful at the level of an DCL read or write. It's
a hint to humans and possibly to some utility
programs. I believe that setting the device type also
sets a suite of terminal settings appropriately.
The kind of thing that could make a WRITE followed
by a READ hang would more likely be either a flow
control event or the lack of a typeahead buffer.
OP _is_ setting the port /TYPEAHEAD after
allocating it in the batch job, I hope?!
Also, if one is doing line-at-a-time reads and
writes, and if the expected output is larger
than the type ahead buffer size, then the larger
/ALTYPEAHD (sp?) buffer may be appropriate.
Kermit and set host /dte presumably have enough
smarts to keep reads posted while writes are taking
place. You might be able to tolerate the lack of a
typeahead buffer with such tools.
The typeahead buffer is where input data goes if
there is no current read pending on the device.
In the absence of both, input data is bit bucketted.
Syltrem
"Martin Vorlaender" <m...@pdv-systeme.de> a écrit dans le message de news:
op.vtkyx...@notemv-tap.mv.privat...
Good day
I tried and I got some problems.
My script is like this :
set line tta0:
set speed 19200
SET CARRIER-WATCH OFF
set flow /direct-serial XON/XOFF
set session-log text
log session msa.txt new
if fail exit 2
SET INPUT BUFFER-LENGTH 32000
output show tech_support\13
input 10 MSA-Left> /count:2
close session
quit
It keeps loosing most characters coming out of the TTA0 device.
The "show tech_support" command outputs a few pages worth of things, but
Kermit only catches a few lines. And it's not because of the timeout of 10
seconds (I also tried a simple SHOW UNIT 0 which is pretty short)
I did use the SET FLOW, still no change in behaviour.
My TTA0 is like this :
$ sh ter tta0
Terminal: _TTA0: Device_Type: Unknown Owner: No Owner
Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24
Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase No Tab
Wrap Scope No Remote No Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo Autobaud No Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad No ANSI_CRT No Regis No Block_mode
No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input <CTRL-H> Backspace
$
If anyone has ideas... I wrote to the kermit news group yesterday but it
looks like it's mostly idle these days.
Thanks
Syltrem
Simon Clubley
>
> It keeps loosing most characters coming out of the TTA0 device.
> The "show tech_support" command outputs a few pages worth of things, but
> Kermit only catches a few lines. And it's not because of the timeout of 10
> seconds (I also tried a simple SHOW UNIT 0 which is pretty short)
> I did use the SET FLOW, still no change in behaviour.
>
> looks like it's mostly idle these days.
>
If you do a connect from within Kermit and issue the command manually,
do you still get dropped characters ?
Are you sure the remote device supports Xon/Xoff flow control ?
Have you tried hardware flow control ?
Simon Clubley
> On 2011-04-08, Syltrem <syltr...@videotron.ca> wrote:
>>
>> It keeps loosing most characters coming out of the TTA0 device.
>> The "show tech_support" command outputs a few pages worth of things, but
>> Kermit only catches a few lines. And it's not because of the timeout of 10
>> seconds (I also tried a simple SHOW UNIT 0 which is pretty short)
>> I did use the SET FLOW, still no change in behaviour.
>>
>> If anyone has ideas... I wrote to the kermit news group yesterday but it
>> looks like it's mostly idle these days.
>>
>
> If you do a connect from within Kermit and issue the command manually,
> do you still get dropped characters ?
>
> Are you sure the remote device supports Xon/Xoff flow control ?
>
> Have you tried hardware flow control ?
>
Also (although it shouldn't make any difference because Kermit should
be controlling this) have you tried turning on /HOSTSYNC on TTA0 ?
Martin Vorlaender
> "Martin Vorlaender" <m...@pdv-systeme.de> a écrit...
>> Syltrem <syltr...@videotron.ca> wrote:
>>> I finally got it from http://www.columbia.edu/kermit/ckdaily.html and
>>> building it was a breeze,
>>
>> As I wrote - I built several versions, and it was easy every time.
>> (thanks Frank!)
>>
>>> and it includes Multinet support (which I need).
>>>
>>> Now I just have to find out how to use it for my purpose.
>>>
>>> C-Kermit 9.0.299 Alpha.09, 21 Sep 2010, for OpenVMS Alpha
>>> Copyright (C) 1985, 2010,
>>> Trustees of Columbia University in the City of New York.
>>> Type ? or HELP for help.
>>
>> Have a look at http://www.columbia.edu/kermit/ckscripts.html
>> It's not black magic (though I must admit the ilosetup script
>> is kind of tough).
>
>
> My script is like this :
>
> set line tta0:
> set speed 19200
> SET CARRIER-WATCH OFF
> set flow /direct-serial XON/XOFF
> set session-log text
> log session msa.txt new
> if fail exit 2
> SET INPUT BUFFER-LENGTH 32000
> output show tech_support\13
> input 10 MSA-Left> /count:2
> close session
> quit
>
> It keeps loosing most characters coming out of the TTA0 device.
> The "show tech_support" command outputs a few pages worth of things, but
> Kermit only catches a few lines. And it's not because of the timeout of 10
> seconds (I also tried a simple SHOW UNIT 0 which is pretty short)
> I did use the SET FLOW, still no change in behaviour.
>
> My TTA0 is like this :
>
> If anyone has ideas... I wrote to the kermit news group yesterday but it
> looks like it's mostly idle these days.
For any serial speed beyond 2400 bps you should set the SYSGEN parameter
TTY_ALTYPAHD to something sensible, like a few kB.
Martin Vorlaender
> For any serial speed beyond 2400 bps you should set the SYSGEN parameter
> TTY_ALTYPAHD to something sensible, like a few kB.
Sorry, I forgot: ...and set TTA0: to use it: SET TERMINAL TTA0: /ALTYPEAHD
JF Mezei
terminal sending an XOFF).
/HOSTSYNC controls input into the computer from terminal. Computer sends
an XOFF when its buffer is full.
You might want to SET TERM tta0 /PERM HOSTSYNC/TTSYNC to get flow
control to work in both directions all the time. Then you don't have to
worry about setting it within Kermit.
You want both because you expect input into the computer at a pace that
is much faster than someone typing.
Yesm, you want a systeb parameter for altypahd to be large, and then,
while the port is idle:
SET TERM TTA0/PERM/ALTYPAHD.
This must be done with /PERM while the terminal is idle before you
assign a channel to it. Once a channel is assigned, you can't change
that characteristic.
In sysgen, I have set TTY_ALTYPAHD to 30000
Syltrem
"jbriggs444" <jbrig...@gmail.com> a écrit dans le message de news:
613c22be-620b-4d72...@q36g2000yqn.googlegroups.com...
> allocating it in the batch job, I hope?!
>
> Also, if one is doing line-at-a-time reads and
> writes, and if the expected output is larger
> than the type ahead buffer size, then the larger
> /ALTYPEAHD (sp?) buffer may be appropriate.
I raised TTY_TYPAHDSZ and TTY_ALTYPAHD and that did the trick.
Works like a charm now.
Thanks to all who helped, including Frank Da Cruz at Columbia.
Syltrem
Johnny Billquist
No Hostsync...
It's a good start anyway. ;-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist
> On 2011-04-08, Syltrem<syltr...@videotron.ca> wrote:
>>
>> It keeps loosing most characters coming out of the TTA0 device.
>> The "show tech_support" command outputs a few pages worth of things, but
>> Kermit only catches a few lines. And it's not because of the timeout of 10
>> seconds (I also tried a simple SHOW UNIT 0 which is pretty short)
>> I did use the SET FLOW, still no change in behaviour.
>>
>> If anyone has ideas... I wrote to the kermit news group yesterday but it
>> looks like it's mostly idle these days.
>>
>
> If you do a connect from within Kermit and issue the command manually,
> do you still get dropped characters ?
>
> Are you sure the remote device supports Xon/Xoff flow control ?
>
> Have you tried hardware flow control ?
It's DEC stuff. There is no hardware flow control!
Johnny Billquist
> On 2011-04-08, Simon Clubley<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2011-04-08, Syltrem<syltr...@videotron.ca> wrote:
>>>
>>> It keeps loosing most characters coming out of the TTA0 device.
>>> The "show tech_support" command outputs a few pages worth of things, but
>>> Kermit only catches a few lines. And it's not because of the timeout of 10
>>> seconds (I also tried a simple SHOW UNIT 0 which is pretty short)
>>> I did use the SET FLOW, still no change in behaviour.
>>>
>>> If anyone has ideas... I wrote to the kermit news group yesterday but it
>>> looks like it's mostly idle these days.
>>>
>>
>> If you do a connect from within Kermit and issue the command manually,
>> do you still get dropped characters ?
>>
>> Are you sure the remote device supports Xon/Xoff flow control ?
>>
>> Have you tried hardware flow control ?
>>
>
> Also (although it shouldn't make any difference because Kermit should
> be controlling this) have you tried turning on /HOSTSYNC on TTA0 ?
Kermit don't control the VMS flow control settings... You need to have
flow control enabled for both directions, on both sides!
Simon Clubley
> On 2011-04-08 18:48, Simon Clubley wrote:
>>
>> Also (although it shouldn't make any difference because Kermit should
>> be controlling this) have you tried turning on /HOSTSYNC on TTA0 ?
>
> Kermit don't control the VMS flow control settings... You need to have
> flow control enabled for both directions, on both sides!
>
That is a major surprise. I wasn't really expecting it to make a difference
when I suggested it, but suggested it anyway "just-in-case".
On Unix/Linux, which is the only place I do any real serial port work these
days, you don't have to worry about running stty before running your comms
program.
Simon Clubley
>>
>> If you do a connect from within Kermit and issue the command manually,
>> do you still get dropped characters ?
>>
>> Are you sure the remote device supports Xon/Xoff flow control ?
>>
>> Have you tried hardware flow control ?
>
> It's DEC stuff. There is no hardware flow control!
>
While DEC equipment is mainly software flow control, I've come across
equipment in the past which does have hardware flow control support and
VMS does have hardware flow control support built in ($ set term/commsync)
for directly connected ports.
What I didn't know is if the equipment Syltrem was working with was
hardware or software flow control based.
Jan-Erik Soderholm
> On 2011-04-09, Johnny Billquist<b...@softjar.se> wrote:
>> On 2011-04-08 18:44, Simon Clubley wrote:
>>>
>>> If you do a connect from within Kermit and issue the command manually,
>>> do you still get dropped characters ?
>>>
>>> Are you sure the remote device supports Xon/Xoff flow control ?
>>>
>>> Have you tried hardware flow control ?
>>
>> It's DEC stuff. There is no hardware flow control!
>>
>
> While DEC equipment is mainly software flow control, I've come across
> equipment in the past which does have hardware flow control support and
> VMS does have hardware flow control support built in ($ set term/commsync)
> for directly connected ports.
>
> What I didn't know is if the equipment Syltrem was working with was
> hardware or software flow control based.
>
> Simon.
>
And most (all ?) terminal servers (which for a long time back has
been the prefered method to serialy connect equipment to VMS) has
always had hardware flow control as an option to "None" or "Xon/Xoff".
JF Mezei
>> Have you tried hardware flow control ?
>
> It's DEC stuff. There is no hardware flow control!
Hardware flow control has been supported on modem-control interfaces
since 5.5-2 if I recemember correctly (set term/COMMSYNC was added).
I had hardware flow control between my all mighty Microvax II and those
dialup modems connected to a DHQ11.
Serial ports with MMJ connectors did not offer hardware flow control.
RTS/CTS were looped together. Console ports for Microvax boxes did not
support hardware flow control.
However, DHV11 and DHQ11 did. As did decservers with modem support (such
as the decserver 200.
Johnny Billquist
> On 2011-04-09, Johnny Billquist<b...@softjar.se> wrote:
>> On 2011-04-08 18:48, Simon Clubley wrote:
>>>
>>> Also (although it shouldn't make any difference because Kermit should
>>> be controlling this) have you tried turning on /HOSTSYNC on TTA0 ?
>>
>> Kermit don't control the VMS flow control settings... You need to have
>> flow control enabled for both directions, on both sides!
>>
>
> That is a major surprise. I wasn't really expecting it to make a difference
> when I suggested it, but suggested it anyway "just-in-case".
>
> On Unix/Linux, which is the only place I do any real serial port work these
> days, you don't have to worry about running stty before running your comms
> program.
Sure you do. It's no different in Unix than VMS.
It might just be that by default you have flow control enabled on the
port you use? But then again, people very seldom actually use real
serial ports on their Unix/Linux machines... But it might also be that
the comms program is setting the serial port in the right state for your
needs so that stty itself isn't needed.
The same can be true for VMS as well, if we talk about running a program
on the VMS system itself. I thought the "Kermit should be controlling
this" comment was for the Kermit on the PC, or whatever was used to
connect to the VMS system. You only run Kermit on the VMS system in this
case if you want to transfer files to/from the VMS system. Orherwise,
Kermit is used in a way where it is not running on the VMS system, so
how could it control settings on the VMS system?
Johnny Billquist
> On 2011-04-09, Johnny Billquist<b...@softjar.se> wrote:
>> On 2011-04-08 18:44, Simon Clubley wrote:
>>>
>>> If you do a connect from within Kermit and issue the command manually,
>>> do you still get dropped characters ?
>>>
>>> Are you sure the remote device supports Xon/Xoff flow control ?
>>>
>>> Have you tried hardware flow control ?
>>
>> It's DEC stuff. There is no hardware flow control!
>>
>
> While DEC equipment is mainly software flow control, I've come across
> equipment in the past which does have hardware flow control support and
> VMS does have hardware flow control support built in ($ set term/commsync)
> for directly connected ports.
Indeed. I hadn't seen /COMMSYNC before. However, DEC did not recommend
it's use for interactive terminals. So yes, DEC did at least partially
relax their attitude towards hardware flow control over time, since so
many others did it.
> What I didn't know is if the equipment Syltrem was working with was
> hardware or software flow control based.
Me neither.
Johnny Billquist
> Johnny Billquist wrote:
>
>>> Have you tried hardware flow control ?
>>
>> It's DEC stuff. There is no hardware flow control!
>
>
> Hardware flow control has been supported on modem-control interfaces
> since 5.5-2 if I recemember correctly (set term/COMMSYNC was added).
>
> I had hardware flow control between my all mighty Microvax II and those
> dialup modems connected to a DHQ11.
Well, DEC definitely recommended not using /COMMSYNC for dial up modem
lines, since that brings with it the loss to detect modem hangups and
automatic logout. So it introduces the problem that you can loose the
phone line, and then someone else dials in, and can take over your
session...
> Serial ports with MMJ connectors did not offer hardware flow control.
> RTS/CTS were looped together. Console ports for Microvax boxes did not
> support hardware flow control.
Eh. Even "worse". There is no RTS/CTS on a MMJ.
> However, DHV11 and DHQ11 did. As did decservers with modem support (such
> as the decserver 200.
Well, yes, the DHV11, as just about any other serial interface with
modem control, will pass the modem status signals on to the software.
What the software does, based on that, however, is a different story...
But yes, DECservers do support hardware flow control. As do atleast the
newer terminals DEC did (such at the VT5xx series).
BillPedersen
>
> Kermit don't control the VMS flow control settings... You need to have
> flow control enabled for both directions, on both sides!
>
Actually, ckermit DOES do flow control on OpenVMS by using QIOs with
the proper function modifiers. So for instance, when you say XON/XOFF
it sets TT$M_HOSTSYNC and TT$M_TTYSYNC. This is in ckvtio.c if you
want to check out the code yourself.
So, given the OP made multiple changes it probably masked that he did
not need to do the SET TERMINAL commands.
The real solution here was getting the Alternate Typeahead Buffer
enabled. Having a buffer available as close to the device as possible
(short code path) is most important to getting good response to
communications data flow. So if you wait for the OS to give you the
data in your buffer before you send the XOFF then you will, as has
happened here, lose data.
Bill.
Jan-Erik Soderholm
> On Apr 9, 6:54 am, Johnny Billquist<b...@softjar.se> wrote:
>>
>> Kermit don't control the VMS flow control settings... You need to have
>> flow control enabled for both directions, on both sides!
>>
>
> Actually, ckermit DOES do flow control on OpenVMS by using QIOs with
> the proper function modifiers.
What he actualy said/ment was that the Kermit running on the other
end doesn't control the VMS flow control settings. Of course...
If you read the parts that you stripped from Johnnys post, this
was quite clear.
Dennis Boone
> It might just be that by default you have flow control enabled on the
> port you use? But then again, people very seldom actually use real
> serial ports on their Unix/Linux machines... But it might also be that
> the comms program is setting the serial port in the right state for your
> needs so that stty itself isn't needed.
It's patently ridiculous to claim that kermit doesn't configure the
port when you give it a SET SPEED or SET FLOW command.
De
JF Mezei
> Well, DEC definitely recommended not using /COMMSYNC for dial up modem
> lines, since that brings with it the loss to detect modem hangups and
> automatic logout.
My experience however showed that using /MODEM enabled hardware flow
control on the DHV/DHQ11. It seemed to be done by the board, not by the
operating system.
> Eh. Even "worse". There is no RTS/CTS on a MMJ.
I believe that MMJ does use the outermost leads for RTS/CTS. (or is it
DTR/CSR ?) but the adaptors and connectors simply connect both so that
hardware flow control is always "ON" (aka: both parties can always send
and neither can tell the other to stop sending).
Wilm Boerhout
MMJ pinout:
6=DSR
5=RX+
4=RX-
3=TX-
2=TX+
1=DTR
--
Wilm Boerhout |
Zwolle, | 'These are the times that try men's souls'
The Netherlands | (Thomas Paine, The Crisis)
Johnny Billquist
Sorry, but this is starting to cause confusion. I didn't mean to imply
that Kermit don't manipulate the local port on the machine where you are
running Kermit. I just meant that Kermit does not manipulate, or affect,
the remote port to which you connect, using Kermit. You need to set the
remote port correctly yourself. Kermit does not do that for you.
And both sides needs to be set right for things to work.
Johnny Billquist
Yes. If people actually bothered to read through the thread instead of
jumping the guns, you would know that the OP wanted to script a session
that would connect to a remote machine running VMS, and capture the
output frmo that VMS machine. The script sets up the local kermit
(running on I don't know what), and sends a command to the remote VMS
machine to make it output something ("show tech_support"). That produces
a lot of output, but kermit only catches a few lines.
Now, can we get back to actually helping him instead of throwing bad
advice and misdirected comments into this thread?
Johnny Billquist
> JF Mezei mentioned on 10-4-2011 8:25:
>> Johnny Billquist wrote:
>>
>>> Well, DEC definitely recommended not using /COMMSYNC for dial up modem
>>> lines, since that brings with it the loss to detect modem hangups and
>>> automatic logout.
>>
>> My experience however showed that using /MODEM enabled hardware flow
>> control on the DHV/DHQ11. It seemed to be done by the board, not by the
>> operating system.
Trying to remember here, but I think you can set up those boards to stop
output when CTS is not active, but that's totally a programmable option.
For input, I'm pretty sure that they don't use RTS to signal that the
buffers are getting full. So you can get some half-assed hardware flow
control done by the hardware if you want to, but not really all the way
without software involvement.
And /MODEM (on VMS) do not imply hardware flow control. It implies
respecting modem control signals. CTS/RTS is a pair of signals used by
modems when in half-duplex mode. Their use as flow control is really an
abuse of the RS-232 signaling. Even their names makes no sense, if you
talk about flow control. What is "request to send" in a flow control
context? (It do make sense in a halt-duplex situation, however.)
>>> Eh. Even "worse". There is no RTS/CTS on a MMJ.
>>
>> I believe that MMJ does use the outermost leads for RTS/CTS. (or is it
>> DTR/CSR ?) but the adaptors and connectors simply connect both so that
>> hardware flow control is always "ON" (aka: both parties can always send
>> and neither can tell the other to stop sending).
>
> MMJ pinout:
>
> 6=DSR
> 5=RX+
> 4=RX-
> 3=TX-
> 2=TX+
> 1=DTR
Right. So with MMJ, you will have terminals noticing if the computer is
not running, and the terminal will be stopped. And the computer will
notice if the terminal is powered off (or modem hangs up), and will log
you out in that case.
Simon Clubley
> On 2011-04-10 02:09, Jan-Erik Soderholm wrote:
>> BillPedersen wrote 2011-04-10 02:03:
>>> On Apr 9, 6:54 am, Johnny Billquist<b...@softjar.se> wrote:
>>>>
>>>> Kermit don't control the VMS flow control settings... You need to have
>>>> flow control enabled for both directions, on both sides!
>>>>
>>>
>>> Actually, ckermit DOES do flow control on OpenVMS by using QIOs with
>>> the proper function modifiers.
>>
>> What he actualy said/ment was that the Kermit running on the other
>> end doesn't control the VMS flow control settings. Of course...
>>
>> If you read the parts that you stripped from Johnnys post, this
>> was quite clear.
>
> Yes. If people actually bothered to read through the thread instead of
> jumping the guns, you would know that the OP wanted to script a session
> that would connect to a remote machine running VMS, and capture the
> output frmo that VMS machine. The script sets up the local kermit
> (running on I don't know what), and sends a command to the remote VMS
> machine to make it output something ("show tech_support"). That produces
> a lot of output, but kermit only catches a few lines.
>
I see the confusion now. (I've just re-read the original message to make
sure that I didn't misunderstand Syltrem's problem).
You think Syltrem wants to connect to a remote system running VMS and
capture the response in a Kermit session running on a local machine
(for example, a PC).
That isn't the case. The MSA1000 is a storage controller, not a VMS system,
and he wants to connect to it from a VMS system and capture the output in
a file on the VMS system.
The MSA1000 console is a serial port console and according to Syltrem's
description, has been physically connected to the serial port (TTA0:) on
the machine on which the VMS system is running.
In this case, C-Kermit is running as a VMS process on the VMS system and
is directly controlling the TTA0: port.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world
Simon Clubley
> On 2011-04-09 13:27, Simon Clubley wrote:
>> On 2011-04-09, Johnny Billquist<b...@softjar.se> wrote:
>>> On 2011-04-08 18:48, Simon Clubley wrote:
>>>>
>>>> Also (although it shouldn't make any difference because Kermit should
>>>> be controlling this) have you tried turning on /HOSTSYNC on TTA0 ?
>>>
>>> Kermit don't control the VMS flow control settings... You need to have
>>> flow control enabled for both directions, on both sides!
>>>
>>
>> That is a major surprise. I wasn't really expecting it to make a difference
>> when I suggested it, but suggested it anyway "just-in-case".
>>
>> On Unix/Linux, which is the only place I do any real serial port work these
>> days, you don't have to worry about running stty before running your comms
>> program.
>
> Sure you do. It's no different in Unix than VMS.
> It might just be that by default you have flow control enabled on the
> port you use? But then again, people very seldom actually use real
> serial ports on their Unix/Linux machines... But it might also be that
> the comms program is setting the serial port in the right state for your
> needs so that stty itself isn't needed.
Just to clarify, I don't actually login to my Linux machines via a serial
console. In this case, the comms programs themselves are running as Linux
processes. I am controlling devices connected to the various serial ports
(AVR programmer, debug and control outputs from various microcontrollers,
etc) from the Linux PC and the comms programs setup the ports as required.
> The same can be true for VMS as well, if we talk about running a program
> on the VMS system itself. I thought the "Kermit should be controlling
> this" comment was for the Kermit on the PC, or whatever was used to
> connect to the VMS system. You only run Kermit on the VMS system in this
> case if you want to transfer files to/from the VMS system. Orherwise,
> Kermit is used in a way where it is not running on the VMS system, so
> how could it control settings on the VMS system?
>
I've mentioned in another message that there's some confusion here.
According to Syltrem's problem description, Kermit needs to run on
the VMS system itself and it's the VMS based Kermit process which is
controlling the storage controller via the VMS machine's serial port.
Johnny Billquist
Correct.
> That isn't the case. The MSA1000 is a storage controller, not a VMS system,
> and he wants to connect to it from a VMS system and capture the output in
> a file on the VMS system.
>
> The MSA1000 console is a serial port console and according to Syltrem's
> description, has been physically connected to the serial port (TTA0:) on
> the machine on which the VMS system is running.
>
> In this case, C-Kermit is running as a VMS process on the VMS system and
> is directly controlling the TTA0: port.
Ok. If that is the case, then yes, you can get Kermit to control the
flow control of the serial port on the VMS side.
That, however, is not neccesarily done by default. I don't offhand
remember the exact syntax, but there is some commands in Kermit that
control this. Check for "set line flow" or something similar. I would
need to fire up C-Kermit somewhere to find out the exact syntax needed.
Also, Kermit can then be selected to do hardware flow control, XON/XOFF
flow control, or no flow control (and possibly something else as well).
Make sure it is set to match whatever the storage controller use. Also
make sure that the storage controller in fact do have some kind of flow
control, or else this whole exercise is not going to help anyway.
And, it is still important to check for both transmit and receive on
both sides. It won't help if you manage to turn on flow control for
output, and you get overflows on input...
Bob Koehler
>
> It's DEC stuff. There is no hardware flow control!
Every DEC serial interface I've ever had on VAXen, all the way back
to DZ11, had hardware flow control. Some versions of VMS (IIRC prior
to 3.0) didn't support this, but it was in the hardware.
Of course, I've also had to deal with Stallman's code being run over
lines that didn't even have enough wires for hardware flow control.
(All those emacs users who were told they should be able to decide
what ^Q and ^S are for).
Syltrem
"Syltrem" <syltr...@videotron.ca> wrote in message
news:SCKnp.7132$qz1....@en-nntp-02.dc1.easynews.com...
>
>
>
> I raised TTY_TYPAHDSZ and TTY_ALTYPAHD and that did the trick.
> Works like a charm now.
> Thanks to all who helped, including Frank Da Cruz at Columbia.
>
> Syltrem
>
Just to clear out some confusion I saw on this thread over the weekend...
I connected the MSA1000 SAN controller console port to my TTA0 on the VMS
box and I want to issue commande to the MSA100 CLI :
Here's what I got, and which works well (from the look of it, kermit *does*
some setup on the terminal) :
$ sh ter tta0
Terminal: _TTA0: Device_Type: Unknown Owner: No Owner
Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24
Terminal Characteristics:
Interactive Echo Type_ahead No Escape
No Hostsync TTsync Lowercase No Tab
Wrap Scope No Remote No Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo Autobaud No Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup No Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad No ANSI_CRT No Regis No Block_mode
No Advanced_video No Edit_mode No DEC_CRT No DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input <CTRL-H> Backspace
$
$ mc sysgen
SYSGEN> SH/TTY
Parameters in use: Active
Parameter Name Current Default Min. Max. Unit
Dynamic
-------------- ------- ------- ------- ------- ---- -------
TTY_TYPAHDSZ 32767 156 1 32767 Bytes
TTY_ALTYPAHD 32767 400 1 32767 Bytes
SYSGEN>
$ ty f.ker
set line tta0:
set speed 19200
SET CARRIER-WATCH OFF
set flow /direct-serial XON/XOFF
set session-log text
log session msa.txt new
if fail exit 2
SET INPUT BUFFER-LENGTH 32000
output show tech_support\13
input 120 MSA-Left> /count:2
close session
quit
$
$ sh sym kermit
KERMIT == "$PUB:KERMIT"
$
$ KERMIT F.KER
$ SEARCH MSA.TXT FAILED ! or whatever you're looking for
Have a good day everyone !
Syltrem
Johnny Billquist
> In article<inpdsm$v0l$2...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@softjar.se> writes:
>>
>> It's DEC stuff. There is no hardware flow control!
>
> Every DEC serial interface I've ever had on VAXen, all the way back
> to DZ11, had hardware flow control. Some versions of VMS (IIRC prior
> to 3.0) didn't support this, but it was in the hardware.
I can mention several interfaces without modem control. :-)
But modem control abused as hardware flow control requires more than
just the hardware being able to control the signals. The software needs
to know about it as well. But newer versions of VMS can do this, as was
noted a few messages ago. (But I had missed that "feature".)
Also, ever tried hardware flow control on most any DEC terminal? How
about anything else than VMS? :-)
Or ever used the DEC MMJ connectors and cables?
> Of course, I've also had to deal with Stallman's code being run over
> lines that didn't even have enough wires for hardware flow control.
> (All those emacs users who were told they should be able to decide
> what ^Q and ^S are for).
That is a different (and fun) story all on its own...
Bob Koehler
>
> Also, ever tried hardware flow control on most any DEC terminal? How
> about anything else than VMS? :-)
> Or ever used the DEC MMJ connectors and cables?
At least some of the DEC terminals had hardware flow control.
We used fully populated DB25, partially populated DB25, a
couple DB25 with a few invidual strands of copper between them,
DB15, MMJ, RJ-11 (ouch), ...
And I never set up a DEC terminal to be Stallman compatable. I just
killed processes when folks hung up thier terminals trying to
follow his advice, then pointed them to instructions to set up
something like PF1 for incremental-search-forward.
Paul Sture
koe...@eisner.nospam.encompasserve.org (Bob Koehler) wrote:
I recall inheriting a setup where the terminal servers wouldn't respond
to CTRL/S CTRL/Q, and just as annoying, CTRL/O. I can't remember
exactly how I fixed that, but it was easy to do (IIRC TCP/IP was
involved, where it didn't need to be).
--
Paul Sture