Discussion:
TELNET/CREATE_NTY
(too old to reply)
Christoph Gartmann
2011-02-09 14:57:22 UTC
Permalink
Hello,

under Multinet V5.3 I am trying to send a single command to a webserver.
Interactively I would do something like this:
TELNET/PORT=80 web.server
GET /
Now I would like to do the same from within a DCL procedure.
I tried
$ TELNET/CREATE_NTY/PORT=80 web.server
$ OPEN/WRITE tfile telnet_nty
$ WRITE tfile "GET /"
$ CLOSE tfile
But for some reason no requests reach web.server. What is wrong here?
Any other ideas on how to achive what I want?

Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
Immunbiologie und Epigenetik
Postfach 1169 Internet: ***@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Fred Zwarts
2011-02-10 09:29:32 UTC
Permalink
I once did something like this, but using an smtp server instead of a webserver.
There are several problems with it.
First, the terminal settings (like echo, etc.) may interfere with the dialog.
Further, the formatting of the request.
DCL WRITE adds not only a carriage return, but also a line feed to the line written,
sometime at the beginning of a line, which may cause the webserver to disconnect.
So, I always used READ/PROMPT, with in the prompt a carriage return.
The following short DCL procedure produced the first line of the reply from our webserver.
To get the remaining part of the reply is left as a exercise.

$ set noon
$ CR[0,8]=13 ! Create a carriage-return character
$ TELNET/CREATE_NTY/PORT=80 web.server
$ show log telnet_nty
$ set terminal telnet_nty /nobroadcast/noecho/nottsync/nolineedit
$ show terminal telnet_nty
$ open/read/write tfile telnet_nty
$ show log tfile
$ read /time=5 /prompt="get /''CR'" tfile line
$ show sym line
$ close tfile
$ dealloc telnet_nty
$ show dev nt


This produces the following output on my VMS 7.3-1 system with Multinet 5.0:
(I hope that for newer systems things have not been changed too much.)

Trying... TELNET session now connected to _NTY31:
%DCL-I-ALLOC, _$1$NTY31: allocated
"TELNET_NTY" = "_$1$NTY31:" (LNM$PROCESS_TABLE)
Terminal: _NTY31: Device_Type: Unknown Owner: FTA104:ZWARTS
Username: ZWARTS
Remote Port Info: [0.0.0.0]/80

Input: 9600 LFfill: 0 Width: 80 Parity: None
Output: 9600 CRfill: 0 Page: 24

Terminal Characteristics:
Interactive No Echo Type_ahead No Escape
No Hostsync No TTsync Lowercase No Tab
Wrap Scope Remote No Eightbit
No Broadcast No Readsync No Form Fulldup
No Modem No Local_echo Autobaud Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync No 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
"TFILE" = "_KVIASV$NTY31" (LNM$PROCESS_TABLE)
LINE = "<html><head>"

Device Device Error
Name Status Count
NTY0: Online 0
NTY31: Offline 0
Post by Christoph Gartmann
Hello,
under Multinet V5.3 I am trying to send a single command to a
TELNET/PORT=80 web.server
GET /
Now I would like to do the same from within a DCL procedure.
I tried
$ TELNET/CREATE_NTY/PORT=80 web.server
$ OPEN/WRITE tfile telnet_nty
$ WRITE tfile "GET /"
$ CLOSE tfile
But for some reason no requests reach web.server. What is wrong here?
Any other ideas on how to achive what I want?
Regards,
Christoph Gartmann
Christoph Gartmann
2011-02-10 11:03:23 UTC
Permalink
Post by Fred Zwarts
I once did something like this, but using an smtp server instead of a
webserver. There are several problems with it.
First, the terminal settings (like echo, etc.) may interfere with the dialog.
Further, the formatting of the request. DCL WRITE adds not only a carriage
return, but also a line feed to the line written, sometime at the beginning
of a line, which may cause the webserver to disconnect.
Ah, I see.
Post by Fred Zwarts
So, I always used READ/PROMPT, with in the prompt a carriage return.
The following short DCL procedure produced the first line of the reply from our webserver.
To get the remaining part of the reply is left as a exercise.
Unfortunately I get:

"TFILE" = "_MPI7$NTY31" (LNM$PROCESS_TABLE)
%RMS-F-RER, file read error
-SYSTEM-F-HANGUP, data set hang-up
%DCL-W-UNDSYM, undefined symbol - check validity and spelling

Multinet V5.3 under OpenVMS 7.3-1.
Could it be that the connection is closed so fast that the read is to late?

Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
Immunbiologie und Epigenetik
Postfach 1169 Internet: ***@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Fred Zwarts
2011-02-11 09:13:55 UTC
Permalink
Post by Christoph Gartmann
Post by Fred Zwarts
I once did something like this, but using an smtp server instead of a
webserver. There are several problems with it.
First, the terminal settings (like echo, etc.) may interfere with
the dialog. Further, the formatting of the request. DCL WRITE adds
not only a carriage return, but also a line feed to the line
written, sometime at the beginning of a line, which may cause the
webserver to disconnect.
Ah, I see.
Post by Fred Zwarts
So, I always used READ/PROMPT, with in the prompt a carriage return.
The following short DCL procedure produced the first line of the
reply from our webserver.
To get the remaining part of the reply is left as a exercise.
"TFILE" = "_MPI7$NTY31" (LNM$PROCESS_TABLE)
%RMS-F-RER, file read error
-SYSTEM-F-HANGUP, data set hang-up
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
Multinet V5.3 under OpenVMS 7.3-1.
Could it be that the connection is closed so fast that the read is to late?
I don't think so. But I have no good idea of what is going on.
Can you check the log file of the web server?
Are you able with "telnet/prot=80 web.server" when used interactively,
to get some information interactively?
Christoph Gartmann
2011-02-11 09:59:18 UTC
Permalink
In article <ij2ukj$qvj$***@news.albasani.net>, "Fred Zwarts" <***@KVI.nl> writes:
[...]
Post by Fred Zwarts
I don't think so. But I have no good idea of what is going on.
Can you check the log file of the web server?
Yes, the request is seen and the answer bytes are transmitted.
Post by Fred Zwarts
Are you able with "telnet/prot=80 web.server" when used interactively,
to get some information interactively?
Again yes, no problem. But the answer of the webserver is very long,
13103 bytes. But even with a server returning only 72 bytes I get this
"%RMS-F-RER, file read error". I have the impression that Multinet removes or
closes the device as soon as the web server terminates the connection. So the
read is naturally unsuccessfull.

I tried to verify this. So I used the procedure to connect to port 25 and
then read with a prompt of "HELO test". Everything went all right, I got the
welcome message of the SMTP server. Next I did the same but sent a "QUIT"
instead. This time I got the error again :-(

Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
Immunbiologie und Epigenetik
Postfach 1169 Internet: ***@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Christoph Gartmann
2011-02-11 14:11:10 UTC
Permalink
Hello,

meanwhile I came a bit further.

$ cr[0,8] = 13
$ ntycp := $multinet:ntycp
$ ntycp CREATE PORT nty10: /NODE=web.server/PORT=80/LOGICAL=(NAME=telnet_nty)
$ SET TERMINAL telnet_nty /PERMANENT/NOBROADCAST/NOECHO/NOTTSYNC/NOLINEEDIT
$ SET NOON
$ OPEN/READ/WRITE tfile telnet_nty
$ READ/TIME_OUT=5/PROMPT="GET /''cr'" line
$ SHOW SYMBOL LINE
$ CLOSE tfile
$ ntycp delete port nty10:
$ SET ON
$ DEASSIGN telnet_nty

This gives no read error anymore but the symbol line remains undefined.
Obviously the READ is somewhat behind. If I test it with the SMTP server,
I realize that "line" contains the output of the previous prompt, e.g.

HELO test
-> welcome message of the mailserver
NOOP
-> welcome message from the previous HELO
HELP
-> 250 OK (result of NOOP)
QUIT
-> 214 -.... (result of HELP=

Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
Immunbiologie und Epigenetik
Postfach 1169 Internet: ***@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Fred Zwarts
2011-02-11 14:50:38 UTC
Permalink
Post by Christoph Gartmann
Hello,
meanwhile I came a bit further.
$ cr[0,8] = 13
$ ntycp := $multinet:ntycp
/NODE=web.server/PORT=80/LOGICAL=(NAME=telnet_nty) $ SET TERMINAL
telnet_nty /PERMANENT/NOBROADCAST/NOECHO/NOTTSYNC/NOLINEEDIT $ SET
NOON $ OPEN/READ/WRITE tfile telnet_nty
$ READ/TIME_OUT=5/PROMPT="GET /''cr'" line
$ SHOW SYMBOL LINE
$ CLOSE tfile
$ SET ON
$ DEASSIGN telnet_nty
This gives no read error anymore but the symbol line remains
undefined. Obviously the READ is somewhat behind. If I test it with
the SMTP server,
I realize that "line" contains the output of the previous prompt, e.g.
HELO test
-> welcome message of the mailserver
NOOP
-> welcome message from the previous HELO
HELP
-> 250 OK (result of NOOP)
QUIT
-> 214 -.... (result of HELP=
Yes, you should start with a read with an empty prompt
to get the welcome message of the smtp server.
(I don't think that a webserver starts with a welcome message.)

If you don't know the number of lines that the server sends,
you may create a loop with reads with an empty prompt and a short time-out.
Exit the loop when a time-out occurs.
Then read with prompt for the next command.
Fred Zwarts
2011-02-11 14:42:32 UTC
Permalink
Post by Christoph Gartmann
Post by Fred Zwarts
I don't think so. But I have no good idea of what is going on.
Can you check the log file of the web server?
Yes, the request is seen and the answer bytes are transmitted.
Post by Fred Zwarts
Are you able with "telnet/prot=80 web.server" when used
interactively, to get some information interactively?
Again yes, no problem. But the answer of the webserver is very long,
13103 bytes. But even with a server returning only 72 bytes I get this
"%RMS-F-RER, file read error". I have the impression that Multinet
removes or closes the device as soon as the web server terminates the
connection. So the
read is naturally unsuccessfull.
I tried to verify this. So I used the procedure to connect to port 25 and
then read with a prompt of "HELO test". Everything went all right, I
got the welcome message of the SMTP server. Next I did the same but
sent a "QUIT"
instead. This time I got the error again :-(
What is the "type ahead" setting of the telnet_nty terminal?
If this is set to /notype_ahead, you may loose input.
This might be an explanation, if your script is slow.
Christoph Gartmann
2011-02-11 15:03:04 UTC
Permalink
Post by Fred Zwarts
What is the "type ahead" setting of the telnet_nty terminal?
If this is set to /notype_ahead, you may loose input.
This might be an explanation, if your script is slow.
It was /NOTYPE_HEAD, now I changed it but the behaviour is the same as before.
Could it be a difference in Multinet versions? Mine is V5.3 with all patches.

Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -80464
Immunbiologie und Epigenetik
Postfach 1169 Internet: ***@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html
Fred Zwarts
2011-02-11 16:05:43 UTC
Permalink
Post by Christoph Gartmann
Post by Fred Zwarts
What is the "type ahead" setting of the telnet_nty terminal?
If this is set to /notype_ahead, you may loose input.
This might be an explanation, if your script is slow.
It was /NOTYPE_HEAD, now I changed it but the behaviour is the same
as before. Could it be a difference in Multinet versions? Mine is
V5.3 with all patches.
We have an old version of Multinet, because we stopped maintenance
of our OpenVMS systems several years ago.
We left a few on power to test some software.
So, I can't say anything about Multinet 5.3.
However, I would consider it a severe bug if one could not
read the data left in a network connection closed by the partner.
It would pop up at many more places.

Another possibility is that there are other reasons to miss the remainder of the data.
13103 bytes might me too much for some terminal or RMS buffers,
in particular if there are no proper line separators,
or if line separators are not properly recognized.
Maybe some terminal settings (such as passall or passthrough)
may change the behaviour. I remember that I had to fiddle
around a lot with such details before I had a reasonably reliable
smtp client in DCL. Unfortunately, I lost the code years ago.

Loading...