info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OMVS Telnet Client
1,589 views
Skip to first unread message
Bill Hecox
Oct 3, 2011, 7:26:21 AM10/3/11
to
Hi,
Does OMVS have a Telnet client? I was able to use SSH but not all servers have SSH.
I tried entering Telnet and MAN Telnet and got nothing.
Thanks,
Bill
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Does OMVS have a Telnet client? I was able to use SSH but not all servers have SSH.
I tried entering Telnet and MAN Telnet and got nothing.
Thanks,
Bill
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Chris Mason
Oct 3, 2011, 10:19:09 AM10/3/11
to
Bill
You might like to see how far you get using the old "TCP/IP for MVS" - originally "TCP/IP for VM" and strictly now the IP
component of z/OS Communications Server (CS) - TELNET command. I always used to believe that this operated according to the original TELNET "network virtual terminal" (NVT) but I have seen a recent post which throws doubt on this belief.
However, let's just go by what the excellent manuals say - the old-fashioned manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you very much!
Incidentally, you didn't actually say, but I can guess, that you didn't enter the TELNET command in simple old-fashioned antediluvian TSO because, assuming an unmodified installation of TSO, you should have had a response from entering the TELNET command and, assuming that the server addressed by the IP address - assuming the address actually identified a server rather than an interface as is possible with more highly-developed CS IP servers - or an interface to an IP node where the TELNET server is running is actually running under an UNIX platform, you *should* have succeeded - if the following text from the z/OS V1R13 Communications Server IP User's Guide and Commands manual is to be believed:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B9A0/2.1
<quote>
2.1 Using the TSO TELNET command
When you use the TSO TELNET command you are running a Telnet client to connect to a remote host running a Telnet server. The data that is displayed on your terminal is managed by the Telnet client, which communicates using TCP/IP with the Telnet server at the remote host. As a result, the operation of your terminal can differ from what you are used to seeing when you are directly logged on to TSO or to another MVS application. For example, the remote host might be running UNIX, VM, or another operating system that provides a Telnet server. You need to use the terminal operation procedures of the remote host operating system while you have a TELNET session with that remote host.
TELNET management of your terminal for the remote host can also cause operational differences. For example, the function keys that are described in "Using the TELNET function keys" in topic 2.13 can result in different actions.
When all of the display data does not fit on your screen, Linemode displays the HOLDING message in the lower right corner of your screen. If this message appears, press the CLEAR key to see the rest of the data.
If your TELNET session ends for any reason, the following message is displayed:
Session ended. <ENTER> to return to TSO.
If you invoke the services of the MVS Telnet 3270 server from a Telnet client that is not Telnet 3270 capable, you cannot use applications in full-screen mode. Once in line-mode, all nested Telnet sessions continue to be line mode. If you use TELNET in line-mode to access an MVS or VM TELNET server, all subsequent nested TELNET requests are automatically connected in line-mode as a start-stop TTY terminal, and transparent (full-screen) operations are not possible.
When you return to TSO, a message explaining why the TELNET session ended is displayed. The following is an example of what is displayed when you return to TSO:
TELNET terminated -- Foreign host is no longer responding
Restrictions:
- The z/OS TELNET client does not support the Secure Sockets Layer (SSL) protocol.
- The TELNET client uses the Pascal socket API, so VMCF must be started for the command to be successful. If VMCF is not started, an ABEND0D6 can occur.
- The TELNET client does not use the TCPSTACKSOURCEVIPA value for its local address. It uses any applicable SOURCEVIPA or SRCIP configuration.
</quote>
Incidentally, you don't have TELNET *sessions*, you have TELNET TCP *connections*. In a context which can involve SNA, it seems reasonable to try to avoid confusion by reserving the word "session" for any SNA involvement.
I leave it to you to read further and verify that TELNET negotiation should have led both parties to conclude that a basic - as I used to believe - NVT TELNET connection would finally be agreed.
Actually I checked and I cannot actually see where this is properly explained. I'm obliged to quote some of the notes from when I used to teach this topic regarding the option of adding the "(LINEMODE" or "(L" at the end of the TELNET command:
<quote>
Not entering "(LINEMODE" or the abbreviation "(L" will result in attempting to "negotiate", using the TELNET application
protocols, a 3270 full-screen connection, called "transparent" mode in the User's Guide. If a 3270 full-screen connection cannot be "negotiated", a line-by-line mode connection will be used. The purpose of having the option to specify the LINEMODE parameter is to force the "negotiation" of a line-by-line mode connection when a 3270 full-screen connection would be agreed by the partner TELNET server.
A line-by-line mode connection is often the only possible connection to UNIX-based hosts. This mode of operation is often described as a teletypewriter (TTY) start-stop terminal emulation and is similar to the X.28 packet assembler/disassembler access to an X.25 network.
</quote>
-
You need to be aware that the TSO TELNET command is on the deprecated list since it relies on the Pascal API.
VMCF is "Step 3" of the "Required steps before starting TCP/IP" you will find in the CS IP Configuration Guide. It's an ongoing project for many installations finally to dispense with this relic of the "port" from "TCP/IP for VM".
Any program component which depends on the Pascal API is condemned to reside perpetually in the hobbled realm of IPv4. From the z/OS V1R13 Communications Server IPv6 Network and Application Design Guide we find the following:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1f190/6.2
<quote>
The Pascal socket application programming interface enables you to develop TCP/IP applications in the Pascal language. It supports only TCP/IP communications over IPv4. It is unlikely that this API will be enhanced to support IPv6 in the future. Applications using this API are encouraged to migrate their application to one of the other socket APIs that are IPv6 enabled.
</quote>
However, I don't believe that CS IP development are necessarily going to follow their own advice in the case of the TSO TELNET command.
-
It's not so much what you know as if you know where to look. Since any sort of TELNET depends on the IP component of z/OS CS, the CS IP manuals suggest themselves as a good place to include in your research if not actually the place to start.
And, as always, the list offering the greatest concentration of expertise in anything to do with IP-related topics on the traditional range of IBM machines is IBMTCP-L to which list I have just checked you subscribe.
Chris Mason
You might like to see how far you get using the old "TCP/IP for MVS" - originally "TCP/IP for VM" and strictly now the IP
component of z/OS Communications Server (CS) - TELNET command. I always used to believe that this operated according to the original TELNET "network virtual terminal" (NVT) but I have seen a recent post which throws doubt on this belief.
However, let's just go by what the excellent manuals say - the old-fashioned manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you very much!
Incidentally, you didn't actually say, but I can guess, that you didn't enter the TELNET command in simple old-fashioned antediluvian TSO because, assuming an unmodified installation of TSO, you should have had a response from entering the TELNET command and, assuming that the server addressed by the IP address - assuming the address actually identified a server rather than an interface as is possible with more highly-developed CS IP servers - or an interface to an IP node where the TELNET server is running is actually running under an UNIX platform, you *should* have succeeded - if the following text from the z/OS V1R13 Communications Server IP User's Guide and Commands manual is to be believed:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B9A0/2.1
<quote>
2.1 Using the TSO TELNET command
When you use the TSO TELNET command you are running a Telnet client to connect to a remote host running a Telnet server. The data that is displayed on your terminal is managed by the Telnet client, which communicates using TCP/IP with the Telnet server at the remote host. As a result, the operation of your terminal can differ from what you are used to seeing when you are directly logged on to TSO or to another MVS application. For example, the remote host might be running UNIX, VM, or another operating system that provides a Telnet server. You need to use the terminal operation procedures of the remote host operating system while you have a TELNET session with that remote host.
TELNET management of your terminal for the remote host can also cause operational differences. For example, the function keys that are described in "Using the TELNET function keys" in topic 2.13 can result in different actions.
When all of the display data does not fit on your screen, Linemode displays the HOLDING message in the lower right corner of your screen. If this message appears, press the CLEAR key to see the rest of the data.
If your TELNET session ends for any reason, the following message is displayed:
Session ended. <ENTER> to return to TSO.
If you invoke the services of the MVS Telnet 3270 server from a Telnet client that is not Telnet 3270 capable, you cannot use applications in full-screen mode. Once in line-mode, all nested Telnet sessions continue to be line mode. If you use TELNET in line-mode to access an MVS or VM TELNET server, all subsequent nested TELNET requests are automatically connected in line-mode as a start-stop TTY terminal, and transparent (full-screen) operations are not possible.
When you return to TSO, a message explaining why the TELNET session ended is displayed. The following is an example of what is displayed when you return to TSO:
TELNET terminated -- Foreign host is no longer responding
Restrictions:
- The z/OS TELNET client does not support the Secure Sockets Layer (SSL) protocol.
- The TELNET client uses the Pascal socket API, so VMCF must be started for the command to be successful. If VMCF is not started, an ABEND0D6 can occur.
- The TELNET client does not use the TCPSTACKSOURCEVIPA value for its local address. It uses any applicable SOURCEVIPA or SRCIP configuration.
</quote>
Incidentally, you don't have TELNET *sessions*, you have TELNET TCP *connections*. In a context which can involve SNA, it seems reasonable to try to avoid confusion by reserving the word "session" for any SNA involvement.
I leave it to you to read further and verify that TELNET negotiation should have led both parties to conclude that a basic - as I used to believe - NVT TELNET connection would finally be agreed.
Actually I checked and I cannot actually see where this is properly explained. I'm obliged to quote some of the notes from when I used to teach this topic regarding the option of adding the "(LINEMODE" or "(L" at the end of the TELNET command:
<quote>
Not entering "(LINEMODE" or the abbreviation "(L" will result in attempting to "negotiate", using the TELNET application
protocols, a 3270 full-screen connection, called "transparent" mode in the User's Guide. If a 3270 full-screen connection cannot be "negotiated", a line-by-line mode connection will be used. The purpose of having the option to specify the LINEMODE parameter is to force the "negotiation" of a line-by-line mode connection when a 3270 full-screen connection would be agreed by the partner TELNET server.
A line-by-line mode connection is often the only possible connection to UNIX-based hosts. This mode of operation is often described as a teletypewriter (TTY) start-stop terminal emulation and is similar to the X.28 packet assembler/disassembler access to an X.25 network.
</quote>
-
You need to be aware that the TSO TELNET command is on the deprecated list since it relies on the Pascal API.
VMCF is "Step 3" of the "Required steps before starting TCP/IP" you will find in the CS IP Configuration Guide. It's an ongoing project for many installations finally to dispense with this relic of the "port" from "TCP/IP for VM".
Any program component which depends on the Pascal API is condemned to reside perpetually in the hobbled realm of IPv4. From the z/OS V1R13 Communications Server IPv6 Network and Application Design Guide we find the following:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1f190/6.2
<quote>
The Pascal socket application programming interface enables you to develop TCP/IP applications in the Pascal language. It supports only TCP/IP communications over IPv4. It is unlikely that this API will be enhanced to support IPv6 in the future. Applications using this API are encouraged to migrate their application to one of the other socket APIs that are IPv6 enabled.
</quote>
However, I don't believe that CS IP development are necessarily going to follow their own advice in the case of the TSO TELNET command.
-
It's not so much what you know as if you know where to look. Since any sort of TELNET depends on the IP component of z/OS CS, the CS IP manuals suggest themselves as a good place to include in your research if not actually the place to start.
And, as always, the list offering the greatest concentration of expertise in anything to do with IP-related topics on the traditional range of IBM machines is IBMTCP-L to which list I have just checked you subscribe.
Chris Mason
Paul Gilmartin
Oct 3, 2011, 10:53:32 AM10/3/11
to
On Mon, 3 Oct 2011 09:17:40 -0500, Chris Mason wrote:
>
>However, let's just go by what the excellent manuals say - the old-fashioned manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you very much!
>
It was pretty clear that the OP wants a telnet client running under USS as opposed to
>
>However, let's just go by what the excellent manuals say - the old-fashioned manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you very much!
>
TSO. One likely reason is that he wants to connect to a Curses application on the
host. A condescending and needlessly voluminous quotation of manual text, impregnated
with your scarcely-veiled contempt of UNIX isn't going to help him.
-- gil
Kirk Wolf
Oct 3, 2011, 11:29:45 AM10/3/11
to
I'm not sure why you would want to telnet from z/OS to a host instead of
from your workstation to that host: perhaps there are network/firewall
issues?
If that is the case, you could log into z/OS using ssh from your workstation
and start a local port forwarder from your worstation through the z/OS host
to the target server. Then simply use telnet from your local workstation
through the forwarder.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
from your workstation to that host: perhaps there are network/firewall
issues?
If that is the case, you could log into z/OS using ssh from your workstation
and start a local port forwarder from your worstation through the z/OS host
to the target server. Then simply use telnet from your local workstation
through the forwarder.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Chris Mason
Oct 3, 2011, 1:02:33 PM10/3/11
to
Paul
> ... impregnated with your scarcely-veiled contempt of UNIX ...
It's always a problem when dealing with the inhabitants of the land between the shining seas that, despite being the source of some superb humour - or should that be humor? - there are vast areas which are irony-free!
I'm actually quite keen on UNIX and all who sail in her ever since I was set up to run a class dealing with NetView/6000 many years ago. Unfortunately - in the eyes of some - I never went through the cloud chamber treatment one can see in many science fiction films where a perfectly normal ordinary human being was transformed into an UNIX geek, a being characterised by being able to do the most amazing things with strings of characters - usually including "grep" and "pipe" and the like. I was always consumed with admiration regarding the skill but had something of a dread of becoming such a being.[1]
It just so happens that in this case, available from what I know as the armoury available from IBM, there is no equivalent to the "telnet" command as I seem to recall I used to use in an AIX context - was it normally from an X-windows device perhaps?
There may be some non-IBM offering or an offering from an obscure IBM source. It's just an IP-based application after all.
If so I would have thought responding in this thread would require actually to be able to propose such an answer rather than carping about a genuine contribution - but maybe I just adopt the wrong attitude regarding what contributors to IBM-MAIN are supposed to contribute - am I wrong or am I wrong?
-
> A condescending and needlessly voluminous quotation of manual text, ...
That's your opinion and it's my style and I don't believe I've had any complains which actually make sense rather than reflecting deficiencies on behalf of the author.
You can always attempt to redeem yourself by taking the trouble actually to point out what you found "condescending" and "needlessly voluminous" - you can try ...
No response will, of course, be taken as an admission of guilt accompanied by crawling back into the corner from which you "needlessly" emerged.
-
> ... isn't going to help him.
Insofar as I quite clearly pointed out how he could use a TELNET command available to a TSO user, I believe this constituted a helpful contribution. I would be interested whether there are any other sensible opinions on the matter. Note that the little joke about "MAN-pages" was for the purposes of emphasising that Bill needed to be directing his attention to TSO - to which I applied the counterbalancing "slur" of "antediluvian" in case you didn't notice. Like Lauren Bacall, I feel like adding "You know what 'antediluvian' means, don't you?".
Incidentally, I was in the process of putting together an additional post - no doubt to be condemned as "condescending" and "needlessly voluminous" in some quarters - regarding something interesting which appeared at the end of Chapter 2, "Logging on to a host using TELNET" of the z/OS Communications Server (CS) IP User's Guide and Commands manual.
Eventually I realised that the two sections at the end of the chapter, "Using TELNET 3270 DBCS transform mode" and "Terminal and conversion type", were misleadingly placed. They should have been more clearly identified as an extension of "linemode" support involving the SNA-oriented TELNET server, particularly curiously named the TN3270E server in this context. What these last two sections cover is how a suitably configured SNA-oriented TELNET server can be configured so that, say, a workstation emulating VT100, as the likely implementation these days, could access SNA 3270 applications by "transformation" of VT100 full-screen to 3270 full-screen data streams.
This "trick" used to be a capability of "Communication Subsystem for Interconnection" (CSFI).
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=Demonstration&htmlfid=897/ENUS299-371
<quote>
- Gives you native access from 3270 terminals to VT100, VT220, TTY, and Minitel applications, and Dynamic Keyboard Mapping and printing functions.
- Enables access from a number of supported ASCII terminals to SNA applications, and to ...
</quote>
I got the impression that the sections at the end of Chapter 2 might be describing the first capability but it's actually the second capability. Tant pis!
At this point I was debating with myself simply to warn him off this apparently temping possibility when this highly flawed post appeared. Thus I can incorporate the warning within the rebuttal.
-
> One likely reason is that he wants to connect to a Curses application on the host.
While I will agree that the Irish peasant's observation that "If oi were goin' to go t'ere, oi wouldn't be startin' from here, so oi wouldn't!" applies to very many queries on the list, when an OP does not actually detail his reasons for wanting any particular capability, I believe we are entitled to offer him the next best seemingly available. Of course, there may be a debate over whether an alternative is really an alternative, but we do the best we can.
Well, some of us do!
> ... a Curses application ...
You know, some posts prompt me to want to apply a few curses, so they do!
-
> It was pretty clear that the OP wants a telnet client running under USS as opposed to TSO.
Whether emulating a 3270 device or a 3767 ("linemode"), it's quite normal to use USS and from there to access TSO or any other SNA application - as everybody who doesn't pretend not to understand knows very well!
For the benefit of those relatively new to the topics usually discussed on IBM-MAIN - not always related to z/OS as one of the self-promoting gurus I suppose in principle correctly pointed out with emphasis! - who are being most *un*helpfully confused by perpetual and mischievous misuse, please take a look in the z/OS CS IP Configuration Guide manual Chapter 11, "Accessing remote hosts using Telnet", section "Using the Telnet solicitor or USS logon screen" and Configuration Reference manual Chapter 16, "TN3270E Telnet server", sections "USSTCP statement" and "Telnet USS table setup" in order to see the use to which USS is put in the context of TELNET and reflect on how you are being shamelessly and, dare I say, "condescendingly" misled by those who set themselves up as specialists and are so often just behaving as worse than "wastes of space"!
Incidentally, we still haven't heard how you enjoyed your hat!
http://bama.ua.edu/cgi-bin/wa?A2=ind1108&L=ibm-main&F=&S=&P=597644
-
[1] I have even seen the "before" and "after".
One of my students was very much taken with the "trick" I used to teach for "help desk" support which involved causing an USS message 5 to appear while a session was in progress - and possibly hung[2]. He promised to introduce the end-user procedure when he got back to his "shop" after the class.
A few years later, chatting over a beer, he helped me out with some AIX problem in such a way that it became clear he had gone through the personality change procedure which creates an UNIX geek!
[2] Unfortunately the author of RFC 2355 was not aware of this possibility for the use of USS messages while a session was in place and so this massively useful function is denied to TN3270E users.
-
Chris Mason
On Mon, 3 Oct 2011 09:52:32 -0500, Paul Gilmartin <PaulGB...@AIM.COM> wrote:
>On Mon, 3 Oct 2011 09:17:40 -0500, Chris Mason wrote:
>>
>>However, let's just go by what the excellent manuals say - the old-fashioned manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you very much!
>>
>It was pretty clear that the OP wants a telnet client running under USS as opposed to
>TSO. One likely reason is that he wants to connect to a Curses application on the
>host. A condescending and needlessly voluminous quotation of manual text, impregnated
>with your scarcely-veiled contempt of UNIX isn't going to help him.
>
>-- gil
> ... impregnated with your scarcely-veiled contempt of UNIX ...
It's always a problem when dealing with the inhabitants of the land between the shining seas that, despite being the source of some superb humour - or should that be humor? - there are vast areas which are irony-free!
I'm actually quite keen on UNIX and all who sail in her ever since I was set up to run a class dealing with NetView/6000 many years ago. Unfortunately - in the eyes of some - I never went through the cloud chamber treatment one can see in many science fiction films where a perfectly normal ordinary human being was transformed into an UNIX geek, a being characterised by being able to do the most amazing things with strings of characters - usually including "grep" and "pipe" and the like. I was always consumed with admiration regarding the skill but had something of a dread of becoming such a being.[1]
It just so happens that in this case, available from what I know as the armoury available from IBM, there is no equivalent to the "telnet" command as I seem to recall I used to use in an AIX context - was it normally from an X-windows device perhaps?
There may be some non-IBM offering or an offering from an obscure IBM source. It's just an IP-based application after all.
If so I would have thought responding in this thread would require actually to be able to propose such an answer rather than carping about a genuine contribution - but maybe I just adopt the wrong attitude regarding what contributors to IBM-MAIN are supposed to contribute - am I wrong or am I wrong?
-
> A condescending and needlessly voluminous quotation of manual text, ...
That's your opinion and it's my style and I don't believe I've had any complains which actually make sense rather than reflecting deficiencies on behalf of the author.
You can always attempt to redeem yourself by taking the trouble actually to point out what you found "condescending" and "needlessly voluminous" - you can try ...
No response will, of course, be taken as an admission of guilt accompanied by crawling back into the corner from which you "needlessly" emerged.
-
> ... isn't going to help him.
Insofar as I quite clearly pointed out how he could use a TELNET command available to a TSO user, I believe this constituted a helpful contribution. I would be interested whether there are any other sensible opinions on the matter. Note that the little joke about "MAN-pages" was for the purposes of emphasising that Bill needed to be directing his attention to TSO - to which I applied the counterbalancing "slur" of "antediluvian" in case you didn't notice. Like Lauren Bacall, I feel like adding "You know what 'antediluvian' means, don't you?".
Incidentally, I was in the process of putting together an additional post - no doubt to be condemned as "condescending" and "needlessly voluminous" in some quarters - regarding something interesting which appeared at the end of Chapter 2, "Logging on to a host using TELNET" of the z/OS Communications Server (CS) IP User's Guide and Commands manual.
Eventually I realised that the two sections at the end of the chapter, "Using TELNET 3270 DBCS transform mode" and "Terminal and conversion type", were misleadingly placed. They should have been more clearly identified as an extension of "linemode" support involving the SNA-oriented TELNET server, particularly curiously named the TN3270E server in this context. What these last two sections cover is how a suitably configured SNA-oriented TELNET server can be configured so that, say, a workstation emulating VT100, as the likely implementation these days, could access SNA 3270 applications by "transformation" of VT100 full-screen to 3270 full-screen data streams.
This "trick" used to be a capability of "Communication Subsystem for Interconnection" (CSFI).
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=Demonstration&htmlfid=897/ENUS299-371
<quote>
- Gives you native access from 3270 terminals to VT100, VT220, TTY, and Minitel applications, and Dynamic Keyboard Mapping and printing functions.
- Enables access from a number of supported ASCII terminals to SNA applications, and to ...
</quote>
I got the impression that the sections at the end of Chapter 2 might be describing the first capability but it's actually the second capability. Tant pis!
At this point I was debating with myself simply to warn him off this apparently temping possibility when this highly flawed post appeared. Thus I can incorporate the warning within the rebuttal.
-
> One likely reason is that he wants to connect to a Curses application on the host.
Well, some of us do!
> ... a Curses application ...
You know, some posts prompt me to want to apply a few curses, so they do!
-
> It was pretty clear that the OP wants a telnet client running under USS as opposed to TSO.
For the benefit of those relatively new to the topics usually discussed on IBM-MAIN - not always related to z/OS as one of the self-promoting gurus I suppose in principle correctly pointed out with emphasis! - who are being most *un*helpfully confused by perpetual and mischievous misuse, please take a look in the z/OS CS IP Configuration Guide manual Chapter 11, "Accessing remote hosts using Telnet", section "Using the Telnet solicitor or USS logon screen" and Configuration Reference manual Chapter 16, "TN3270E Telnet server", sections "USSTCP statement" and "Telnet USS table setup" in order to see the use to which USS is put in the context of TELNET and reflect on how you are being shamelessly and, dare I say, "condescendingly" misled by those who set themselves up as specialists and are so often just behaving as worse than "wastes of space"!
Incidentally, we still haven't heard how you enjoyed your hat!
http://bama.ua.edu/cgi-bin/wa?A2=ind1108&L=ibm-main&F=&S=&P=597644
-
[1] I have even seen the "before" and "after".
One of my students was very much taken with the "trick" I used to teach for "help desk" support which involved causing an USS message 5 to appear while a session was in progress - and possibly hung[2]. He promised to introduce the end-user procedure when he got back to his "shop" after the class.
A few years later, chatting over a beer, he helped me out with some AIX problem in such a way that it became clear he had gone through the personality change procedure which creates an UNIX geek!
[2] Unfortunately the author of RFC 2355 was not aware of this possibility for the use of USS messages while a session was in place and so this massively useful function is denied to TN3270E users.
-
Chris Mason
On Mon, 3 Oct 2011 09:52:32 -0500, Paul Gilmartin <PaulGB...@AIM.COM> wrote:
>On Mon, 3 Oct 2011 09:17:40 -0500, Chris Mason wrote:
>>
>>However, let's just go by what the excellent manuals say - the old-fashioned manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you very much!
>>
>It was pretty clear that the OP wants a telnet client running under USS as opposed to
>TSO. One likely reason is that he wants to connect to a Curses application on the
>host. A condescending and needlessly voluminous quotation of manual text, impregnated
>with your scarcely-veiled contempt of UNIX isn't going to help him.
>
>-- gil
Bill Hecox
Oct 3, 2011, 3:04:05 PM10/3/11
to
>I'm not sure why you would want to telnet from z/OS to a host instead of
>from your workstation to that host: perhaps there are network/firewall
>issue
I am telnet hopping to bypass an interface that is down. Nothing illegal going on here.
>from your workstation to that host: perhaps there are network/firewall
>issue
When I get where I want, I can fix the interface and I will then be able to telnet directly.
I tried doing a telnet to TSO in line mode. Then when I entered telnet under TSO I got
a message that indicated that telnet would only work from a 327x terminal.
The SSH port forwarding sounds interesting. Not sure I know how to make it work in my case.
I do not have SSH on my windows XP machine so I guess I can not try it.
So I did the foillowing:
Did a telnet directly to z/OS USS in line mode from my XP machine. Port 123 on our host.
Then used SSH under OE to get to my target host. Works fine.
Fortunately my target machine supports SSH connections.
Thanks,
Bill
Grinsell, Don
Oct 3, 2011, 3:15:38 PM10/3/11
to
Putty will give you an ssh client for your workstation.
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Once you have the windows executable installed, ssh to your z/OS system and from there use the mainframe's ssh client to get to your other system. This assumes you have openssh on your mainframe.
--
Donald Grinsell
State of Montana
406-444-2983
dgri...@mt.gov
"They have computers, and they may have other weapons of mass destruction."
-- Janet Reno
http://www.chiark.greenend.org.uk/~sgtatham/putty/
Once you have the windows executable installed, ssh to your z/OS system and from there use the mainframe's ssh client to get to your other system. This assumes you have openssh on your mainframe.
--
Donald Grinsell
State of Montana
406-444-2983
dgri...@mt.gov
"They have computers, and they may have other weapons of mass destruction."
-- Janet Reno
0 new messages