On 6/11/21 11:44 PM, muta...@gmail.com
> I have no idea what you are talking about.
> The application will be very simple, just a terminal program that
> allows the user to enter ATDE.
So what is the terminal going to do when it receives a 3270 data stream
from the mainframe?
N.B. The 3270 data stream is nothing like a character stream that you
see on Unix systems / PCs. You can't /just/ write the 3270 data stream
to the terminal. The 3270 data stream must be processed to build a
screen with fields and then populate the fields.
A very crude analogy would be like comparing ASCII text which can be
printed character by character to a screen vs an HTML web page with
forms in it which must be processed to build the structure, translated
to something to be displayed on screen and only then data displayed in
parts of the screen.
So ... with that in mind, how are you going to do with the 3270 data
stream? Since you can't /just/ print the characters that make up the
3270 data stream as they come in.
There's also the fact that mainframes are line oriented and not
character oriented. Your terminal will have to maintain a buffer for
the line(s) that are edited, and then send said line(s) as a batch.
Mainframes operate completely differently than PCs. Simply having a
modem convert between ASCII and EBCDIC isn't going to do much at all in
the grand scheme of things.
> The modem will do the rest.
If you try to make the modem do all of what I just mentioned, then it is
no longer /just/ a modem. It is now much more akin to a terminal
controller, e.g. a 3172 / 3174. (I think I have the numbers correct.)
The terminal controller is a full blown computer in and of itself that
does a LOT more than modulate / demodulate tones to / from binary data.
> Other people are trying to force EBCDIC to die completely.
Ya.... How's that going for them? The mainframe is still going quite
strong. People are saying that it's going to die any day / week / month
now for a quarter of a century.
> All I'm requesting is that the 819/1047 translation be set in stone.
You can request it. But I would suggest that your plans not be
contingent in it happening.
> My EBCDIC mainframe application would to an ATDA to dial an ASCII
> destination. At the time the CCW is done (in EBCDIC), responsibility
> is passed off to the hardware.
A standard application on the mainframe is going to be the opposite of
above. It's going to expect to send and receive a 3270 data stream. A
custom application on the mainframe can probably be created to send
something like XML / JSON / or some other form of "open" structured
data. Maybe the ASCII / EBCDIC conversion could be done there. But why
not have the custom application on the mainframe do that and use a
simpler modem? There's also the complication that people need to
interact with the mainframe in EBCDIC to start application, custom or
> And I'm providing that hardware (Hercules/380).
Hardware that doesn't have a physical counterpart? (There was no
System/380, it's a Hercules fabrication crated for reasons.)
So, you're going to alter virtual hardware, the operating system that
runs on said virtual hardware, and somehow interface with an as yet to
be built modem that is more than a modem? Okay....
> There is no restriction, and has never been any restriction, on
> building the required hardware. IBM appears to have been able to run
> a successful scam for 50 years.
It's not /just/ hardware. There's an entire mainframe ecosystem. And
said mainframe ecosystem is designed to do something one way, consistently.
> Looks like I will have the world's first mainframe EBCDIC BBS.
And what EBCDIC clients will connect to it?