Hi somitcw
Obviously, you either didn't read my post or, once again, my English was too bad to bring my message through. So, here once again, for clarification.
My post had to parts:
The first part was a reply to Jay Jaeger's telnet negotiation problems with PuTTY. I tried to explain that it is perfectly possible to make it negotiate successfully with Hercules after applying a minimal patch (to PuTTY, not to Hercules), which I developed some years ago in the course of the APL\360 resurrection project. The motivation for this was having a single telnet client available on all three targeted systems, Windows, Linux, and OS X. Although there do of course exist suitable individual clients for each of the platforms (such as HyperTerminal on Windows, rxvt4apl on the various *i*x platforms) having a unique client at hand greatly eased the creation of the APL\360 distribution.
The second part was a reply to your rambling concerning telnet consoles on MVS. I made clear that telnet generally works perfectly with Hercules, thereby pointing out that console are only a special case of many use cases for telnet device connectivity with Hercules. This is a totally different story than the PuTTY specific negotiation issue discussed in the first part.
For whatever reason you intermixed those two independent argumentations into fantasizing about invalid conclusions I never insinuated.
I don't mind if you don't want to accept that telnet is working perfectly well for the present use cases (3215/1052/2703/3705). However, I do mind if you are insinuating malfunction, thus leading people on time consuming side tracks instead of solving their problems.
And, btw., if telnet is really that bad: Why don't you just sit down and program an alternate solution instead of rambling for 15 years?
Cheers
Juergen
Post by ***@id.ethz.ch [hercules-390]Post by ***@yahoo.com [hercules-390]or that the telnet negotiation in Hercules is behaving oddly -
at the very least it could throw out an NVT message as to why
it is terminating the session and then wait a second or two for
the user to see it.
Just a quick comment here: Yes, Hercules telnet negotiation doesn't
seem to be fully RFC compliant in all situations. There are quite a few
Yes, we have had fifteen years of posts about Windows telnet, putty
telnet, and other telnets having issues and with MVS console buffers
backing up and locking the system up. That was not introduced with
TK4-minus but it has been a long standing issue.
Post by ***@id.ethz.ch [hercules-390]posts in this group describing this in great detail from various points
of view. Whether this qualifies as a bug may be arguable. However,
as far as I know, PuTTY is the only telnet client which completely
fails to negotiate a session due to this oddity. All other clients
negotiate successfully.
You are close but I believe that various Windows telnets have been
even worse than putty.
Can we agree that any telnet with MVS consoles is asking for trouble?
Post by ***@id.ethz.ch [hercules-390]While it is not fully trivial to "fix" Hercules to work with PuTTY,
it is trivial to "fix" PuTTY to work with Hercules. This fixed version
of PuTTY works smoothly with Hercules, as a 3215/1052 console
as well as through emulated 3705 or 2703 attachments. Given its
platform independency (available for Linux, OS X and WIndows),
for me it is _the_ telnet client of choice to work with Hercules,
for my APL\360 (OS/360 MVT) distribution as well for the TK4-
(MVS 3.8j) system.
With MVS consoles, after IPL is complete, you don't even need a
telnet client connected to have backed up buffers and lock the
system up. That is to say that rewriting every telnet client that
exists might not fix the issue of MVS console backing up when
a client is not even connected.
If a secondary console, all a users sees before MVS slows
to a crawl or locks up is an intervention required message
that depending of roll-mode may be a thousand lines back.
I had noticed that for your TK4-minus system that you normally
use the web interface with a Hercules integrated console but
looking at problem reports, other users seem to be going
through IPL timing gyrations just to try to use telnet.
You normally using a Hercules integrated console for yourself
instead of any telnet client sounds like a sound move to me.
You can still try a telnet client if you need a challenge.
Post by ***@id.ethz.ch [hercules-390]As far as I can see, the Windows binary uploaded recently by
Scott/Mike is the modified PuTTY I created a few years ago.
In this thread, Mike cited one of my posts around PuTTY.
This post also has a pointer to the source of the patch I
created, plus binaries not only for Windows but also for
OS X and Linux.
There are many telnet clients that sort-of function.
It helps to know how to configure them.
Don't put down all telnet clients just because many have quirks.
Post by ***@id.ethz.ch [hercules-390]In a pragmatic sense this was/is the easiest way to get PuTTY
to work with Hercules: As it is for sure no PuTTY bug, it wouldn't
make sense to submit the patch to the PuTTY developer. On the
other hand, patching Hercules (in at least three locations,
commadpt.c, comm3705.c and console.c) wouldn't have been
worth the effort (at least not for me, of course I can't tell whether
one of the developers will pick this up some time).
If making three changes to Hercules will fix many telnet clients
and MVS console buffers from backing up enough to lock the
MVS system up, let us hope that it get down.
Post by ***@id.ethz.ch [hercules-390]So, that's the current state of affairs!
Yes, using telnet for an MVS console has issues:
1. Picking a functioning telnet client.
2. Telnet configuration issues.
3. MVS IPL timing issues. If a telnet IPL console, a telnet
client must connect before the Hercules IPL command.
4. MVS console buffer issues because MVS doesn't know
to vary a console offline just because it stops or never
started receiving messages.
Post by ***@id.ethz.ch [hercules-390]Post by ***@yahoo.com [hercules-390]- - - remainder snipped - - -
I already agreed that telnet is a bug and that it doesn't
work well for an MVS line-mode console and told you
about alternatives.
telnet isn't a bug. It is a highly standardized client/server
communications protocol. I'd greatly appreciate if you
stopped claiming telnet doesn't work well for MVS line-mode
consoles. It _is_ working perfectly with all kinds of
line/character oriented devices, including but not limited
to consoles.
You just came from claiming that telnet clients have issues
to "It _is_ working perfectly". My head is spinning.
Post by ***@id.ethz.ch [hercules-390]There are well established uses cases for both, telnet
connected devices (including consoles), as well as for
the internal (-C) consoles.
Cheers
JÃŒrgen
Since you describe both telnet client issues and telnet
perfection, I'll stick to normally using Hercules integrated
consoles until I feel that I need added difficulties.
