Home > Archive > Cobol > May 2005 > How to make IBM COBOL send in text in Telnet mode?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to make IBM COBOL send in text in Telnet mode?
|
|
| dave@pixieware.com 2005-04-21, 3:55 am |
| Hello,
I am new to this forum, and I may not be in the correct place, but here
goes.
I need to find a way for a Cobol program (on AS400) to send output
through the Telnet port, as pure Telnet (character by character), not
IBM block-mode. The Telnet communications will be tranlated via a IIS
Web-Server to HTTP, and then on to a Browser.
Basically, I have a methodology/technique, that if programmed into a
text-serving source code (for example: C, Basic, COBOL, on a Win PC),
it will allow a Browser to be attached as the terminal, and provide a
fully interactive graphical user interface.
IBM AIX seems a more difficult proposition, so I need to discuss what
options are available to me on that platform. This is only a brief
introduction and I will happily answer any questions when posed.
Thanks.
Dave Johnstone.
| |
| Michael Wojcik 2005-04-24, 8:55 pm |
|
In article <1114055159.725184.76020@z14g2000cwz.googlegroups.com>, dave@pixieware.com writes:
>
> I need to find a way for a Cobol program (on AS400) to send output
> through the Telnet port, as pure Telnet (character by character), not
> IBM block-mode. The Telnet communications will be tranlated via a IIS
> Web-Server to HTTP, and then on to a Browser.
I think you're laboring under some confusion. The "Telnet port" is
port 23; it's the well-known port for Telnet clients to connect to a
server. If you're sending *from* the Telnet port, that almost always
means you're a Telnet server.
And Telnet is a connection-oriented protocol, so you don't send
anything unless you have a conversation established. Your COBOL
program can't just send Telnet data; it has to either connect to a
Telnet server (active open) or accept an incoming Telnet connection
(passive open).
And there is no such thing as "pure Telnet". There's NVT mode and
there's Binary mode; there's half-duplex and full-duplex; there's
record-oriented, line-oriented (which is really just half-duplex),
and character-oriented Telnet. But there is no Telnet mode where
data can simply be streamed byte by byte. The closest you can get to
that is Telnet in Binary mode with Suppress Go-Ahead and without EOR,
I suppose, but even there you have to escape octets with value 255 so
they're not interpreted as Telnet IACs.
In this case, you say the recipient of the data you're sending is
IIS, but we still don't know whether it's the client, that is the
party doing the active open, or the server. That's rather mysterious
in itself, since IIS is an HTTP server, and neither a Telnet client
nor a Telnet server. Is your COBOL program actually talking to an
ISAPI module or some other sort of IIS extension?
> Basically, I have a methodology/technique, that if programmed into a
> text-serving source code (for example: C, Basic, COBOL, on a Win PC),
> it will allow a Browser to be attached as the terminal, and provide a
> fully interactive graphical user interface.
A web-based screen scraper? There's quite a bit of prior art there
which you may want to investigate before you put too much effort into
this.
(Full disclosure: We sell a web-based screen-scraping product for
front-ending 3270 and 5250 CUI apps.)
This description makes me wonder if you're not trying to get AS/400
5250-based COBOL apps to run in character-by-character mode, under
your virtual terminal. That's not going to work. The whole point of
TN5250 is to simulate the block-mode operation of real 5250-series
terminals; the terminal I/O performed by those applications is
architected around block-mode operations. To do 5250 screen scraping,
you need to speak TN5250, and that includes doing block mode correctly.
I'm not sure what's involved in TN5250, as I've never had to
implement it. I suspect it's similar to TN3270, which uses Telnet's
Binary, EOR, and Terminal-Type options to negotiate a channel with
record-oriented messages and disable NVT controls; or TN3270E, which
uses a single option to similar effect. At any rate, Telnet is not a
trivial protocol, either to understand or to implement, particularly
since few implementations conform to the spec.
> IBM AIX seems a more difficult proposition, so I need to discuss what
> options are available to me on that platform.
I suspect whatever it is you're trying to do would in fact be less
difficult on AIX, where Telnet already operates in character mode and
there's a well-established and documented pseudo-tty interface.
--
Michael Wojcik michael.wojcik@microfocus.com
They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James
| |
| Michael Wojcik 2005-04-27, 3:55 am |
|
In article <1114055159.725184.76020@z14g2000cwz.googlegroups.com>, dave@pixieware.com writes:
>
> I need to find a way for a Cobol program (on AS400) to send output
> through the Telnet port, as pure Telnet (character by character), not
> IBM block-mode. The Telnet communications will be tranlated via a IIS
> Web-Server to HTTP, and then on to a Browser.
I think you're laboring under some confusion. The "Telnet port" is
port 23; it's the well-known port for Telnet clients to connect to a
server. If you're sending *from* the Telnet port, that almost always
means you're a Telnet server.
And Telnet is a connection-oriented protocol, so you don't send
anything unless you have a conversation established. Your COBOL
program can't just send Telnet data; it has to either connect to a
Telnet server (active open) or accept an incoming Telnet connection
(passive open).
And there is no such thing as "pure Telnet". There's NVT mode and
there's Binary mode; there's half-duplex and full-duplex; there's
record-oriented, line-oriented (which is really just half-duplex),
and character-oriented Telnet. But there is no Telnet mode where
data can simply be streamed byte by byte. The closest you can get to
that is Telnet in Binary mode with Suppress Go-Ahead and without EOR,
I suppose, but even there you have to escape octets with value 255 so
they're not interpreted as Telnet IACs.
In this case, you say the recipient of the data you're sending is
IIS, but we still don't know whether it's the client, that is the
party doing the active open, or the server. That's rather mysterious
in itself, since IIS is an HTTP server, and neither a Telnet client
nor a Telnet server. Is your COBOL program actually talking to an
ISAPI module or some other sort of IIS extension?
> Basically, I have a methodology/technique, that if programmed into a
> text-serving source code (for example: C, Basic, COBOL, on a Win PC),
> it will allow a Browser to be attached as the terminal, and provide a
> fully interactive graphical user interface.
A web-based screen scraper? There's quite a bit of prior art there
which you may want to investigate before you put too much effort into
this.
(Full disclosure: We sell a web-based screen-scraping product for
front-ending 3270 and 5250 CUI apps.)
This description makes me wonder if you're not trying to get AS/400
5250-based COBOL apps to run in character-by-character mode, under
your virtual terminal. That's not going to work. The whole point of
TN5250 is to simulate the block-mode operation of real 5250-series
terminals; the terminal I/O performed by those applications is
architected around block-mode operations. To do 5250 screen scraping,
you need to speak TN5250, and that includes doing block mode correctly.
I'm not sure what's involved in TN5250, as I've never had to
implement it. I suspect it's similar to TN3270, which uses Telnet's
Binary, EOR, and Terminal-Type options to negotiate a channel with
record-oriented messages and disable NVT controls; or TN3270E, which
uses a single option to similar effect. At any rate, Telnet is not a
trivial protocol, either to understand or to implement, particularly
since few implementations conform to the spec.
> IBM AIX seems a more difficult proposition, so I need to discuss what
> options are available to me on that platform.
I suspect whatever it is you're trying to do would in fact be less
difficult on AIX, where Telnet already operates in character mode and
there's a well-established and documented pseudo-tty interface.
--
Michael Wojcik michael.wojcik@microfocus.com
They had forgathered enough of course in all the various times; they had
again and again, since that first night at the theatre, been face to face
over their question; but they had never been so alone together as they were
actually alone - their talk hadn't yet been so supremely for themselves.
-- Henry James
| |
| dave@pixieware.com 2005-04-29, 3:55 pm |
| Thanks Michael,
Our method does rely on a IIS extension, so IIS is really acting as a
Telnet
client. What I need is for AIX to act as a Telnet server, and I need a
COBOL
program to send/receive to/from the Telnet server.
I will look at the pseudo-tty interface.
By the way, this is not a screen scraping process. By generating HTML
directly from within a COBOL program (successfully done it if COBOL
resides
on a PC), we can generate fully interactive, and field-by-field
validation,
on-the-fly. And yes, this is not got for free, as some re-engineering
of
an existing program must take place to create a browser capable
interface.
Dave Johnstone.
Michael Wojcik wrote:
> In article <1114055159.725184.76020@z14g2000cwz.googlegroups.com>,
dave@pixieware.com writes:
not[color=darkred]
IIS[color=darkred]
>
> I think you're laboring under some confusion. The "Telnet port" is
> port 23; it's the well-known port for Telnet clients to connect to a
> server. If you're sending *from* the Telnet port, that almost always
> means you're a Telnet server.
>
> And Telnet is a connection-oriented protocol, so you don't send
> anything unless you have a conversation established. Your COBOL
> program can't just send Telnet data; it has to either connect to a
> Telnet server (active open) or accept an incoming Telnet connection
> (passive open).
>
> And there is no such thing as "pure Telnet". There's NVT mode and
> there's Binary mode; there's half-duplex and full-duplex; there's
> record-oriented, line-oriented (which is really just half-duplex),
> and character-oriented Telnet. But there is no Telnet mode where
> data can simply be streamed byte by byte. The closest you can get to
> that is Telnet in Binary mode with Suppress Go-Ahead and without EOR,
> I suppose, but even there you have to escape octets with value 255 so
> they're not interpreted as Telnet IACs.
>
> In this case, you say the recipient of the data you're sending is
> IIS, but we still don't know whether it's the client, that is the
> party doing the active open, or the server. That's rather mysterious
> in itself, since IIS is an HTTP server, and neither a Telnet client
> nor a Telnet server. Is your COBOL program actually talking to an
> ISAPI module or some other sort of IIS extension?
>
a[color=darkred]
PC),[color=darkred]
a[color=darkred]
>
> A web-based screen scraper? There's quite a bit of prior art there
> which you may want to investigate before you put too much effort into
> this.
>
> (Full disclosure: We sell a web-based screen-scraping product for
> front-ending 3270 and 5250 CUI apps.)
>
> This description makes me wonder if you're not trying to get AS/400
> 5250-based COBOL apps to run in character-by-character mode, under
> your virtual terminal. That's not going to work. The whole point of
> TN5250 is to simulate the block-mode operation of real 5250-series
> terminals; the terminal I/O performed by those applications is
> architected around block-mode operations. To do 5250 screen
scraping,
> you need to speak TN5250, and that includes doing block mode
correctly.
>
> I'm not sure what's involved in TN5250, as I've never had to
> implement it. I suspect it's similar to TN3270, which uses Telnet's
> Binary, EOR, and Terminal-Type options to negotiate a channel with
> record-oriented messages and disable NVT controls; or TN3270E, which
> uses a single option to similar effect. At any rate, Telnet is not a
> trivial protocol, either to understand or to implement, particularly
> since few implementations conform to the spec.
>
what[color=darkred]
>
> I suspect whatever it is you're trying to do would in fact be less
> difficult on AIX, where Telnet already operates in character mode and
> there's a well-established and documented pseudo-tty interface.
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> They had forgathered enough of course in all the various times; they
had
> again and again, since that first night at the theatre, been face to
face
> over their question; but they had never been so alone together as
they were
> actually alone - their talk hadn't yet been so supremely for
themselves.
> -- Henry James
| |
| Michael Wojcik 2005-05-01, 3:55 pm |
|
In article <1114789034.177346.280990@g14g2000cwa.googlegroups.com>, dave@pixieware.com writes:
>
Please don't top-post. Intersperse new text in your reply with concise
quoted material relevant to it:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-- David Bonde
[I've also reformatted wrapped lines in the following quoted material.]
> Our method does rely on a IIS extension, so IIS is really acting as a
> Telnet client. What I need is for AIX to act as a Telnet server, and
> I need a COBOL program to send/receive to/from the Telnet server.
AIX has a Telnet server, like every Unix implementation for the past
20 years or so. AIX itself does not "act as a Telnet server" -
either something is a Telnet server or it isn't, and with AIX as with
most OSes it's implemented separately from the kernel. I want to be
precise here because with distributed applications it's vital to have
an accurate understanding of how they work.
In the case of AIX (at least with 4.2; I haven't bothered checking a
more recent version), the telnet server is /usr/sbin/telnetd, and it's
usually run under the auspices of inetd. This is typical for Unix
systems.
Running a COBOL program under a Telnet server is easy. Normally you'd
just log in through Telnet and then execute it under your login shell.
That's the whole point of Telnet, after all.
If you want to cut out the middleman - the shell - then just do so.
telnetd runs /usr/sbin/login, which requests a username and (optionally)
a password and then runs whatever's listed as the initial program for
that username in /etc/passwd. Normally that's a shell, but it could
be your COBOL program. (Note that you need superuser permission to
assign a program not listed in /etc/shells as the initial program for
an account.)
For example, you create an entry in /etc/passwd that looks like this:
myapp::500:100:COBOL application:/home/myapp:/path/to/myapp
(adjusting all of those fields as appropriate for your installation)
and have your Telnet client log in as "myapp". (In this case, no
password is required, because the second field above is empty.)
login will run /path/to/myapp automatically, and its console I/O will
be through the pty which is attached to the Telnet connection, just
as if it were a shell.
That would still require that your Telnet client - the IIS extension -
pass a username to login when prompted for it. If it's not capable of
doing that, I think you'll have to find another Telnet server (there
are open-source ones available), as I don't believe AIX telnetd has an
option to invoke anything other than /usr/sbin/login once Telnet nego-
tiation has finished.
The best references for implementing Telnet in Unix are W. Richard
Stevens' classic _Advanced Programming in the UNIX Environment_ and
_UNIX Network Programming_, but you shouldn't need that level of detail.
A book on Unix system administration should explain the relationships
among telnetd, login, and the shell or other initial program in more
detail if this is unclear.
> I will look at the pseudo-tty interface.
Unless you're writing your own Telnet server you don't need to.
Now, things will be trickier on the AS/400, because OS/400 and
applications written for it are designed to be used with block-mode
5250 terminals, and with the TN5250 Telnet variant which emulates
them. OS/400 does have support for "classic" Telnet for terminal
types that it recognizes such as VT100 (they have to provide adequate
support for things like cursor positioning so that it can emulate
full-screen mode by drawing each screenful of data). Since COBOL
applications on OS/400 typically want to do block-mode screen-by-
screen displays, it may be difficult to get streaming console I/O
from a COBOL program. The various OS/400 C implementations have a
special stream-I/O mode, to support the vast code base of C programs
that expect to do console I/O that way, but I'm not sure it's
available to COBOL programs.
Out of curiousity I just tried a little COBOL program on OS/400 that
did a couple of displays, and it displayed a screen with a "job
started" line and the first line of output; I had to hit Enter to get
the next line, and it looked like it was positioning the cursor for
it. Not simply streaming console output, in other words.
I'd suggest taking up the AS/400 issues on comp.sys.ibm.as400.misc.
If there's a FAQ for that group, it may already be addressed there.
Personally, a Telnet connection would not be my choice for this
application anyway. Telnet is not designed for tunnelling applica-
tion to application data. (The RFCs mention that possibility, and
NVT is used for some connections that are typically app-to-app like
FTP and SMTP, but it was a secondary consideration.) There's a
reason why HTTP was invented: to transmit HTML and related data. It'd
be much cleaner to just run your COBOL applications as CGI programs
under an HTTP server.
--
Michael Wojcik michael.wojcik@microfocus.com
I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_
| |
| Richard 2005-05-01, 8:55 pm |
| > Please don't top-post.
Actually the problem is more that posters don't trim the original
message down to the bit they are replying to. Taking a long rambling
message to which they want to make a couple of points they will either
put their points at the top and leave all the rambling irrelevant
quote, or, because they have been told not to top-post, will scroll
down to the end of the rambling message and add a one line reply.
They need to learn to trim the message they are replying to so as to
leave just the essentials, the original message is still available if
the reader needs to refer back. Or, if they start with a blank
response (which is usual for google now) they can cut-n-paste the
phrases being responded to, the thread keeps it relevant.
I don't care whether people top-post or intersperse or bottom-post,
just as long as they don't re-quote the whole thread just to put a
single line reply.
| |
| Pete Dashwood 2005-05-02, 3:55 am |
| That is a reasonabl
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1114974389.692617.269070@g14g2000cwa.googlegroups.com...
>
> Actually the problem is more that posters don't trim the original
> message down to the bit they are replying to. Taking a long rambling
> message to which they want to make a couple of points they will either
> put their points at the top and leave all the rambling irrelevant
> quote, or, because they have been told not to top-post, will scroll
> down to the end of the rambling message and add a one line reply.
>
> They need to learn to trim the message they are replying to so as to
> leave just the essentials, the original message is still available if
> the reader needs to refer back. Or, if they start with a blank
> response (which is usual for google now) they can cut-n-paste the
> phrases being responded to, the thread keeps it relevant.
>
> I don't care whether people top-post or intersperse or bottom-post,
> just as long as they don't re-quote the whole thread just to put a
> single line reply.
>
>
| |
| Pete Dashwood 2005-05-02, 3:55 am |
| (Bloody cursor over the send icon again... bloody GUI interfaces... I
dunno... :-))
As I was saying...:-)
That is a reasonable and much less  position than your previous one. (I
think you were hard on Bill, but that's entirely a matter for you... :-))
I was going to trim your post and respond to specific bits, but I like all
of it so much, it is reproduced below in its entirety...:-)
Pete.
(TOP POST no more from me, but read below anyway...it is good stuff...)
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1114974389.692617.269070@g14g2000cwa.googlegroups.com...
>
> Actually the problem is more that posters don't trim the original
> message down to the bit they are replying to. Taking a long rambling
> message to which they want to make a couple of points they will either
> put their points at the top and leave all the rambling irrelevant
> quote, or, because they have been told not to top-post, will scroll
> down to the end of the rambling message and add a one line reply.
>
> They need to learn to trim the message they are replying to so as to
> leave just the essentials, the original message is still available if
> the reader needs to refer back. Or, if they start with a blank
> response (which is usual for google now) they can cut-n-paste the
> phrases being responded to, the thread keeps it relevant.
>
> I don't care whether people top-post or intersperse or bottom-post,
> just as long as they don't re-quote the whole thread just to put a
> single line reply.
>
>
| |
| Richard 2005-05-02, 3:55 am |
| > I was going to trim your post and respond to specific bits, but I
like all
> of it so much, it is reproduced below in its entirety...:-)
Well, obviously, _my_ posts are worth repeating in their entirity,
twice even, as you have done, but I will resist reposting it yet again
by leaving it all as I reply ;-)
> much less position than your previous one.
'Angry' ? I can't even control the shape of your characters or the
colour of your text, any 'tone' you hear in your head is entirely your
imagination.
> (I think you were hard on Bill
OK, I agree, I was.
| |
| dave@pixieware.com 2005-05-02, 8:55 am |
| Thanks Michael,
Our method does rely on a IIS extension, so IIS is really acting as a
Telnet
client. What I need is for AIX to act as a Telnet server, and I need a
COBOL
program to send/receive to/from the Telnet server.
I will look at the pseudo-tty interface.
By the way, this is not a screen scraping process. By generating HTML
directly from within a COBOL program (successfully done it if COBOL
resides
on a PC), we can generate fully interactive, and field-by-field
validation,
on-the-fly. And yes, this is not got for free, as some re-engineering
of
an existing program must take place to create a browser capable
interface.
Dave Johnstone.
Michael Wojcik wrote:
> In article <1114055159.725184.76020@z14g2000cwz.googlegroups.com>,
dave@pixieware.com writes:
not[color=darkred]
IIS[color=darkred]
>
> I think you're laboring under some confusion. The "Telnet port" is
> port 23; it's the well-known port for Telnet clients to connect to a
> server. If you're sending *from* the Telnet port, that almost always
> means you're a Telnet server.
>
> And Telnet is a connection-oriented protocol, so you don't send
> anything unless you have a conversation established. Your COBOL
> program can't just send Telnet data; it has to either connect to a
> Telnet server (active open) or accept an incoming Telnet connection
> (passive open).
>
> And there is no such thing as "pure Telnet". There's NVT mode and
> there's Binary mode; there's half-duplex and full-duplex; there's
> record-oriented, line-oriented (which is really just half-duplex),
> and character-oriented Telnet. But there is no Telnet mode where
> data can simply be streamed byte by byte. The closest you can get to
> that is Telnet in Binary mode with Suppress Go-Ahead and without EOR,
> I suppose, but even there you have to escape octets with value 255 so
> they're not interpreted as Telnet IACs.
>
> In this case, you say the recipient of the data you're sending is
> IIS, but we still don't know whether it's the client, that is the
> party doing the active open, or the server. That's rather mysterious
> in itself, since IIS is an HTTP server, and neither a Telnet client
> nor a Telnet server. Is your COBOL program actually talking to an
> ISAPI module or some other sort of IIS extension?
>
a[color=darkred]
PC),[color=darkred]
a[color=darkred]
>
> A web-based screen scraper? There's quite a bit of prior art there
> which you may want to investigate before you put too much effort into
> this.
>
> (Full disclosure: We sell a web-based screen-scraping product for
> front-ending 3270 and 5250 CUI apps.)
>
> This description makes me wonder if you're not trying to get AS/400
> 5250-based COBOL apps to run in character-by-character mode, under
> your virtual terminal. That's not going to work. The whole point of
> TN5250 is to simulate the block-mode operation of real 5250-series
> terminals; the terminal I/O performed by those applications is
> architected around block-mode operations. To do 5250 screen
scraping,
> you need to speak TN5250, and that includes doing block mode
correctly.
>
> I'm not sure what's involved in TN5250, as I've never had to
> implement it. I suspect it's similar to TN3270, which uses Telnet's
> Binary, EOR, and Terminal-Type options to negotiate a channel with
> record-oriented messages and disable NVT controls; or TN3270E, which
> uses a single option to similar effect. At any rate, Telnet is not a
> trivial protocol, either to understand or to implement, particularly
> since few implementations conform to the spec.
>
what[color=darkred]
>
> I suspect whatever it is you're trying to do would in fact be less
> difficult on AIX, where Telnet already operates in character mode and
> there's a well-established and documented pseudo-tty interface.
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> They had forgathered enough of course in all the various times; they
had
> again and again, since that first night at the theatre, been face to
face
> over their question; but they had never been so alone together as
they were
> actually alone - their talk hadn't yet been so supremely for
themselves.
> -- Henry James
| |
| Richard 2005-05-04, 3:55 am |
| > Please don't top-post.
Actually the problem is more that posters don't trim the original
message down to the bit they are replying to. Taking a long rambling
message to which they want to make a couple of points they will either
put their points at the top and leave all the rambling irrelevant
quote, or, because they have been told not to top-post, will scroll
down to the end of the rambling message and add a one line reply.
They need to learn to trim the message they are replying to so as to
leave just the essentials, the original message is still available if
the reader needs to refer back. Or, if they start with a blank
response (which is usual for google now) they can cut-n-paste the
phrases being responded to, the thread keeps it relevant.
I don't care whether people top-post or intersperse or bottom-post,
just as long as they don't re-quote the whole thread just to put a
single line reply.
| |
| Michael Wojcik 2005-05-04, 3:55 am |
|
In article <1114789034.177346.280990@g14g2000cwa.googlegroups.com>, dave@pixieware.com writes:
>
Please don't top-post. Intersperse new text in your reply with concise
quoted material relevant to it:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-- David Bonde
[I've also reformatted wrapped lines in the following quoted material.]
> Our method does rely on a IIS extension, so IIS is really acting as a
> Telnet client. What I need is for AIX to act as a Telnet server, and
> I need a COBOL program to send/receive to/from the Telnet server.
AIX has a Telnet server, like every Unix implementation for the past
20 years or so. AIX itself does not "act as a Telnet server" -
either something is a Telnet server or it isn't, and with AIX as with
most OSes it's implemented separately from the kernel. I want to be
precise here because with distributed applications it's vital to have
an accurate understanding of how they work.
In the case of AIX (at least with 4.2; I haven't bothered checking a
more recent version), the telnet server is /usr/sbin/telnetd, and it's
usually run under the auspices of inetd. This is typical for Unix
systems.
Running a COBOL program under a Telnet server is easy. Normally you'd
just log in through Telnet and then execute it under your login shell.
That's the whole point of Telnet, after all.
If you want to cut out the middleman - the shell - then just do so.
telnetd runs /usr/sbin/login, which requests a username and (optionally)
a password and then runs whatever's listed as the initial program for
that username in /etc/passwd. Normally that's a shell, but it could
be your COBOL program. (Note that you need superuser permission to
assign a program not listed in /etc/shells as the initial program for
an account.)
For example, you create an entry in /etc/passwd that looks like this:
myapp::500:100:COBOL application:/home/myapp:/path/to/myapp
(adjusting all of those fields as appropriate for your installation)
and have your Telnet client log in as "myapp". (In this case, no
password is required, because the second field above is empty.)
login will run /path/to/myapp automatically, and its console I/O will
be through the pty which is attached to the Telnet connection, just
as if it were a shell.
That would still require that your Telnet client - the IIS extension -
pass a username to login when prompted for it. If it's not capable of
doing that, I think you'll have to find another Telnet server (there
are open-source ones available), as I don't believe AIX telnetd has an
option to invoke anything other than /usr/sbin/login once Telnet nego-
tiation has finished.
The best references for implementing Telnet in Unix are W. Richard
Stevens' classic _Advanced Programming in the UNIX Environment_ and
_UNIX Network Programming_, but you shouldn't need that level of detail.
A book on Unix system administration should explain the relationships
among telnetd, login, and the shell or other initial program in more
detail if this is unclear.
> I will look at the pseudo-tty interface.
Unless you're writing your own Telnet server you don't need to.
Now, things will be trickier on the AS/400, because OS/400 and
applications written for it are designed to be used with block-mode
5250 terminals, and with the TN5250 Telnet variant which emulates
them. OS/400 does have support for "classic" Telnet for terminal
types that it recognizes such as VT100 (they have to provide adequate
support for things like cursor positioning so that it can emulate
full-screen mode by drawing each screenful of data). Since COBOL
applications on OS/400 typically want to do block-mode screen-by-
screen displays, it may be difficult to get streaming console I/O
from a COBOL program. The various OS/400 C implementations have a
special stream-I/O mode, to support the vast code base of C programs
that expect to do console I/O that way, but I'm not sure it's
available to COBOL programs.
Out of curiousity I just tried a little COBOL program on OS/400 that
did a couple of displays, and it displayed a screen with a "job
started" line and the first line of output; I had to hit Enter to get
the next line, and it looked like it was positioning the cursor for
it. Not simply streaming console output, in other words.
I'd suggest taking up the AS/400 issues on comp.sys.ibm.as400.misc.
If there's a FAQ for that group, it may already be addressed there.
Personally, a Telnet connection would not be my choice for this
application anyway. Telnet is not designed for tunnelling applica-
tion to application data. (The RFCs mention that possibility, and
NVT is used for some connections that are typically app-to-app like
FTP and SMTP, but it was a secondary consideration.) There's a
reason why HTTP was invented: to transmit HTML and related data. It'd
be much cleaner to just run your COBOL applications as CGI programs
under an HTTP server.
--
Michael Wojcik michael.wojcik@microfocus.com
I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_
| |
| Pete Dashwood 2005-05-04, 8:55 am |
| (Bloody cursor over the send icon again... bloody GUI interfaces... I
dunno... :-))
As I was saying...:-)
That is a reasonable and much less position than your previous one. (I
think you were hard on Bill, but that's entirely a matter for you... :-))
I was going to trim your post and respond to specific bits, but I like all
of it so much, it is reproduced below in its entirety...:-)
Pete.
(TOP POST no more from me, but read below anyway...it is good stuff...)
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1114974389.692617.269070@g14g2000cwa.googlegroups.com...
>
> Actually the problem is more that posters don't trim the original
> message down to the bit they are replying to. Taking a long rambling
> message to which they want to make a couple of points they will either
> put their points at the top and leave all the rambling irrelevant
> quote, or, because they have been told not to top-post, will scroll
> down to the end of the rambling message and add a one line reply.
>
> They need to learn to trim the message they are replying to so as to
> leave just the essentials, the original message is still available if
> the reader needs to refer back. Or, if they start with a blank
> response (which is usual for google now) they can cut-n-paste the
> phrases being responded to, the thread keeps it relevant.
>
> I don't care whether people top-post or intersperse or bottom-post,
> just as long as they don't re-quote the whole thread just to put a
> single line reply.
>
>
| |
| Richard 2005-05-04, 8:55 am |
| > I was going to trim your post and respond to specific bits, but I
like all
> of it so much, it is reproduced below in its entirety...:-)
Well, obviously, _my_ posts are worth repeating in their entirity,
twice even, as you have done, but I will resist reposting it yet again
by leaving it all as I reply ;-)
> much less position than your previous one.
'Angry' ? I can't even control the shape of your characters or the
colour of your text, any 'tone' you hear in your head is entirely your
imagination.
> (I think you were hard on Bill
OK, I agree, I was.
| |
| Richard 2005-05-06, 3:55 am |
| > Please don't top-post.
Actually the problem is more that posters don't trim the original
message down to the bit they are replying to. Taking a long rambling
message to which they want to make a couple of points they will either
put their points at the top and leave all the rambling irrelevant
quote, or, because they have been told not to top-post, will scroll
down to the end of the rambling message and add a one line reply.
They need to learn to trim the message they are replying to so as to
leave just the essentials, the original message is still available if
the reader needs to refer back. Or, if they start with a blank
response (which is usual for google now) they can cut-n-paste the
phrases being responded to, the thread keeps it relevant.
I don't care whether people top-post or intersperse or bottom-post,
just as long as they don't re-quote the whole thread just to put a
single line reply.
| |
| Michael Wojcik 2005-05-07, 8:55 am |
|
In article <1114789034.177346.280990@g14g2000cwa.googlegroups.com>, dave@pixieware.com writes:
>
Please don't top-post. Intersperse new text in your reply with concise
quoted material relevant to it:
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-- David Bonde
[I've also reformatted wrapped lines in the following quoted material.]
> Our method does rely on a IIS extension, so IIS is really acting as a
> Telnet client. What I need is for AIX to act as a Telnet server, and
> I need a COBOL program to send/receive to/from the Telnet server.
AIX has a Telnet server, like every Unix implementation for the past
20 years or so. AIX itself does not "act as a Telnet server" -
either something is a Telnet server or it isn't, and with AIX as with
most OSes it's implemented separately from the kernel. I want to be
precise here because with distributed applications it's vital to have
an accurate understanding of how they work.
In the case of AIX (at least with 4.2; I haven't bothered checking a
more recent version), the telnet server is /usr/sbin/telnetd, and it's
usually run under the auspices of inetd. This is typical for Unix
systems.
Running a COBOL program under a Telnet server is easy. Normally you'd
just log in through Telnet and then execute it under your login shell.
That's the whole point of Telnet, after all.
If you want to cut out the middleman - the shell - then just do so.
telnetd runs /usr/sbin/login, which requests a username and (optionally)
a password and then runs whatever's listed as the initial program for
that username in /etc/passwd. Normally that's a shell, but it could
be your COBOL program. (Note that you need superuser permission to
assign a program not listed in /etc/shells as the initial program for
an account.)
For example, you create an entry in /etc/passwd that looks like this:
myapp::500:100:COBOL application:/home/myapp:/path/to/myapp
(adjusting all of those fields as appropriate for your installation)
and have your Telnet client log in as "myapp". (In this case, no
password is required, because the second field above is empty.)
login will run /path/to/myapp automatically, and its console I/O will
be through the pty which is attached to the Telnet connection, just
as if it were a shell.
That would still require that your Telnet client - the IIS extension -
pass a username to login when prompted for it. If it's not capable of
doing that, I think you'll have to find another Telnet server (there
are open-source ones available), as I don't believe AIX telnetd has an
option to invoke anything other than /usr/sbin/login once Telnet nego-
tiation has finished.
The best references for implementing Telnet in Unix are W. Richard
Stevens' classic _Advanced Programming in the UNIX Environment_ and
_UNIX Network Programming_, but you shouldn't need that level of detail.
A book on Unix system administration should explain the relationships
among telnetd, login, and the shell or other initial program in more
detail if this is unclear.
> I will look at the pseudo-tty interface.
Unless you're writing your own Telnet server you don't need to.
Now, things will be trickier on the AS/400, because OS/400 and
applications written for it are designed to be used with block-mode
5250 terminals, and with the TN5250 Telnet variant which emulates
them. OS/400 does have support for "classic" Telnet for terminal
types that it recognizes such as VT100 (they have to provide adequate
support for things like cursor positioning so that it can emulate
full-screen mode by drawing each screenful of data). Since COBOL
applications on OS/400 typically want to do block-mode screen-by-
screen displays, it may be difficult to get streaming console I/O
from a COBOL program. The various OS/400 C implementations have a
special stream-I/O mode, to support the vast code base of C programs
that expect to do console I/O that way, but I'm not sure it's
available to COBOL programs.
Out of curiousity I just tried a little COBOL program on OS/400 that
did a couple of displays, and it displayed a screen with a "job
started" line and the first line of output; I had to hit Enter to get
the next line, and it looked like it was positioning the cursor for
it. Not simply streaming console output, in other words.
I'd suggest taking up the AS/400 issues on comp.sys.ibm.as400.misc.
If there's a FAQ for that group, it may already be addressed there.
Personally, a Telnet connection would not be my choice for this
application anyway. Telnet is not designed for tunnelling applica-
tion to application data. (The RFCs mention that possibility, and
NVT is used for some connections that are typically app-to-app like
FTP and SMTP, but it was a secondary consideration.) There's a
reason why HTTP was invented: to transmit HTML and related data. It'd
be much cleaner to just run your COBOL applications as CGI programs
under an HTTP server.
--
Michael Wojcik michael.wojcik@microfocus.com
I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_
|
|
|
|
|