ATDE

[muta...@gmail.com]

There is ATD which means dial, I think some default.

ATDP which says to use pulse.

ATDT which says to use tone.

I am proposing ATDE which means dial an EBCDIC
remote.

I guess ATDTE and ATDET would both be acceptable?

And default is the same as you currently use? So an
EBCDIC system by default assumes it is dialing another
EBCDIC system.

So software just needs to do an ATD and you don't
need to worry whether you're EBCDIC or ASCII or
have a pulse or tone phone line.

BFN. Paul.

[Joe Monk]

> I am proposing ATDE which means dial an EBCDIC
> remote.

Doesnt work. Mainframes dont use ASYNC, they use SYNC.There is no dialing in SYNC land.

Joe

[muta...@gmail.com]

I suggest you get a better mainframe.

BFN. Paul.

[JJ]

But if an EBCDIC system A connect to an ASCII system B, won't both receive
gardbled data after the connection is estalished? Because system B doesn't
know whether system A is an EBCDIC or an ASCII system.

[Grant Taylor]

On 6/11/21 5:43 AM, muta...@gmail.com wrote:
> I suggest you get a better mainframe.

~spittake~

That's not quite how that works.

When you're at the top of a multi-billion dollar industry and have been
there the longest, as well as arguably starting it, you tend to get to
set the rules.



--
Grant. . . .
unix || die

[Grant Taylor]

On 6/11/21 12:07 AM, muta...@gmail.com wrote:
> There is ATD which means dial, I think some default.

It should be configurable.

> I am proposing ATDE which means dial an EBCDIC remote.

Phones don't dial with ASCII or EBCDIC or anything else for that matter.

Phones dial with either tone or pulse.

Modems are tantamount to being a phone thus must adhere to the same
standards.

> I guess ATDTE and ATDET would both be acceptable?

No.

That's like saying that there needs to be a new AM / FM / PM standard
that specifies how you listen to the radio; Bluetooth headset or a
9-track tape recorder.

How the signal is consumed and what the signal is going across it is
immaterial to how the connection is established.

> And default is the same as you currently use? So an
> EBCDIC system by default assumes it is dialing another
> EBCDIC system.
>
> So software just needs to do an ATD and you don't
> need to worry whether you're EBCDIC or ASCII or
> have a pulse or tone phone line.

The conversion is the responsibility of the terminal (emulation)
software that's using the modem.

The modem is just what modulates / demodulates that audio between serial
data which is incompatible with hone lines and audio data which is
compatible with phone lines.

You don't use different types of gas in a car with an automatic
transmission vs the same make / model / year car with a manual transmission.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 1:07:37 AM UTC+10, JJ wrote:

> > And default is the same as you currently use? So an
> > EBCDIC system by default assumes it is dialing another
> > EBCDIC system.
> >
> > So software just needs to do an ATD and you don't
> > need to worry whether you're EBCDIC or ASCII or
> > have a pulse or tone phone line.
>

> But if an EBCDIC system A connect to an ASCII system B, won't both receive
> gardbled data after the connection is estalished? Because system B doesn't
> know whether system A is an EBCDIC or an ASCII system.

The calling system is the one that knows that the
remote is configured to be ASCII/EBCDIC and thus
its responsibility to do the conversion.

When you call phone someone in China, expect to
hear "way" not "hello".

If you have no idea who you are calling, then try
English/ASCII and if it doesn't work out for you,
bad luck Donald Duck.

BFN. Paul.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 2:02:49 AM UTC+10, Grant Taylor wrote:

> > I suggest you get a better mainframe.
>

> That's not quite how that works.
>
> When you're at the top of a multi-billion dollar industry and have been
> there the longest, as well as arguably starting it, you tend to get to
> set the rules.

As the saying goes, "the bigger they are, the harder
they fall". Probably a good time to sell your IBM
shares. I'm the guy with an EBCDIC mainframe modem.
It only took 30 years to produce. I'm now writing some
software to drive it.

BFN. Paul.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 2:08:40 AM UTC+10, Grant Taylor wrote:

> > I am proposing ATDE which means dial an EBCDIC remote.

> Phones don't dial with ASCII or EBCDIC or anything else for that matter.

But I'm expecting the modem to do an ASCII-EBCDIC
translation when presented with an "E" or "A" that
doesn't match the configured setting being used by
the terminal.

> How the signal is consumed and what the signal is going across it is
> immaterial to how the connection is established.

Until now.

> > And default is the same as you currently use? So an
> > EBCDIC system by default assumes it is dialing another
> > EBCDIC system.
> >
> > So software just needs to do an ATD and you don't
> > need to worry whether you're EBCDIC or ASCII or
> > have a pulse or tone phone line.

> The conversion is the responsibility of the terminal (emulation)
> software that's using the modem.

I want the modem to do it. Is there a technical barrier
to that?

Thanks. Paul.

[Joe Monk]

> But I'm expecting the modem to do an ASCII-EBCDIC
> translation when presented with an "E" or "A" that
> doesn't match the configured setting being used by
> the terminal.

Bad juju. Modems speak 1 and 0 (i.e. TTY levels on the serial cable), not ASCII/EBCDIC. That's up to the UART on the MoBo to decide/decode character formats. Thats why a modem stands for modulate/demodulate.

Joe

[muta...@gmail.com]

On Saturday, June 12, 2021 at 10:09:34 AM UTC+10, Joe Monk wrote:
> > But I'm expecting the modem to do an ASCII-EBCDIC
> > translation when presented with an "E" or "A" that
> > doesn't match the configured setting being used by
> > the terminal.

> Bad juju. Modems speak 1 and 0 (i.e. TTY levels on the serial cable),
> not ASCII/EBCDIC.

They recognize "ATDT" in ASCII already.

Soon you will have a modem that recognizes that in
EBCDIC too.

BFN. Paul.

[Joe Monk]

> They recognize "ATDT" in ASCII already.

The modem itself does not recognize ATDT. That is the controller chip in the modem. Remember the days of the acoustic coupler modems? Do they recognize ATDT? I think not...

Remember: the AT command set was invented by the Hayes corporation.

Joe

[muta...@gmail.com]

Well how do you want to word it then?

Soon I will have a modem that recognizes ATDE and has
a "controller chip" that does EBCDIC to ASCII conversion
as required.

BFN. Paul.

[Grant Taylor]

On 6/11/21 12:22 PM, muta...@gmail.com wrote:
> But I'm expecting the modem to do an ASCII-EBCDIC translation when
> presented with an "E" or "A" that doesn't match the configured setting
> being used by the terminal.

There are a lot of people expecting things. I'm expecting fellow
citizens to be polite and respectful. Yet I'm disappointed every day
that I leave my house. :-(

> Until now.

I'm taking "now" to be "as soon as Paul E. gets it working and starts
using it.

> I want the modem to do it.

<ASCII ButWhy.gif>

> Is there a technical barrier to that?

Conceptually, wanting an device between the computer and the phone line
to do character encoding conversions is theoretically possible.

But you're going to have to have something that can /interpret/ *and*
/understand/ both ASCII and EBCDIC. This is probably multiple orders of
magnitude more complex than any analog / asynchronous modem has ever been.

Not to mention the fact that EBCDIC can mean multiple different things.
To simplify -- partially because I don't know the proper terms -- EBCDIC
has it's own version of code pages to support different language, quite
similar to how DOS has multiple code pages. What's worse is that some
of the various EBCDIC ""code pages are incompatible with each other.
I've also heard tell from multiple mainframe people that there is no
reliable way to detect which EBCDIC ""code page is in use, much less
automatically convert between them. Each EBCDIC ""code page has keys /
characters / glyphs unique to it. Thus, you have one or more characters
that have zero translation between EBCDIC ""code pages.

I really don't understand why you want to do this in a modem.

There's also the fact that the mainframe doesn't communicate the same
way that PCs do. In that what goes across the line, the sentence
structure is completely different. It's like one side using words, and
the other side using melodies (which don't contain words). There simply
isn't any direct translation.

[Grant Taylor]

On 6/11/21 8:57 PM, muta...@gmail.com wrote:
> Soon I will have a modem that recognizes ATDE and has a "controller
> chip" that does EBCDIC to ASCII conversion as required.

Is that tone or pulse dialing?

[muta...@gmail.com]

On Saturday, June 12, 2021 at 1:19:43 PM UTC+10, Grant Taylor wrote:

> > But I'm expecting the modem to do an ASCII-EBCDIC translation when
> > presented with an "E" or "A" that doesn't match the configured setting
> > being used by the terminal.

> There are a lot of people expecting things. I'm expecting fellow
> citizens to be polite and respectful. Yet I'm disappointed every day
> that I leave my house. :-(
>
> > Until now.
>
> I'm taking "now" to be "as soon as Paul E. gets it working and starts
> using it.

Yes, is that a problem?

> > I want the modem to do it.
> <ASCII ButWhy.gif>

So that the application software that drives the modem
doesn't need to be aware of ASCII vs EBCDIC differences.

> > Is there a technical barrier to that?

> Conceptually, wanting an device between the computer and the phone line
> to do character encoding conversions is theoretically possible.
>
> But you're going to have to have something that can /interpret/ *and*
> /understand/ both ASCII and EBCDIC. This is probably multiple orders of
> magnitude more complex than any analog / asynchronous modem has ever been.

That's odd. Modems can do FAX etc, but can't do a simple
translation?

> Not to mention the fact that EBCDIC can mean multiple different things.
> To simplify -- partially because I don't know the proper terms -- EBCDIC
> has it's own version of code pages to support different language, quite
> similar to how DOS has multiple code pages. What's worse is that some
> of the various EBCDIC ""code pages are incompatible with each other.
> I've also heard tell from multiple mainframe people that there is no
> reliable way to detect which EBCDIC ""code page is in use, much less
> automatically convert between them. Each EBCDIC ""code page has keys /
> characters / glyphs unique to it. Thus, you have one or more characters
> that have zero translation between EBCDIC ""code pages.

I only have an interest in the 819/1047 conversion. All EBCDIC
code pages need to adjust to match their ASCII equivalent
after the above conversion.

> There's also the fact that the mainframe doesn't communicate the same
> way that PCs do. In that what goes across the line, the sentence
> structure is completely different. It's like one side using words, and
> the other side using melodies (which don't contain words). There simply
> isn't any direct translation.

My EBCDIC mainframe modem is identical to an ASCII PC modem
at that level. They couldn't connect otherwise.

BFN. Paul.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 1:21:10 PM UTC+10, Grant Taylor wrote:

> > Soon I will have a modem that recognizes ATDE and has a "controller
> > chip" that does EBCDIC to ASCII conversion as required.

> Is that tone or pulse dialing?

Whatever the default config setting is.

BFN. Paul.

[Grant Taylor]

On 6/11/21 9:28 PM, muta...@gmail.com wrote:
> Yes, is that a problem?

I don't know.

It's not a thing until it actually exists.

Prior to that it's just an idea.

> So that the application software that drives the modem doesn't need
> to be aware of ASCII vs EBCDIC differences.

So ... you'll do a translation from Cyrillic / English (?name?)
characters but you still have Russian words, not English equivalents.

Something, e.g. the application using the modem, is going to have to
translate Russian words (in English, not Cyrillic, characters) to
English counterparts. Meaning that the application still has to do the
translation.

Even if it is all English and not the hypothetical scenario above, you
still have the problem that the way that a mainframe (the only thing --
that I'm aware of -- that still uses EBCDIC) communicates vs how a PC
communicates.

> That's odd. Modems can do FAX etc, but can't do a simple translation?

Modem's don't do fax. Modem's translate audio tones that represent a
fax into a serial string of characters that represent a fax and an
application on the computer interprets that serial string of characters
into a fax that can be displayed / printed / etc. The modem is actually
quite dumb.

> I only have an interest in the 819/1047 conversion. All EBCDIC code
> pages need to adjust to match their ASCII equivalent after the above
> conversion.

LOL

ASCII code pages aren't even compatible with each other. And you want
to try to force systems that have a 50 year history of backward
compatibility (largely by not changing) to change to match something
that isn't itself uniform?

I can't even ....

Good luck with that.

> My EBCDIC mainframe modem is identical to an ASCII PC modem at that
> level. They couldn't connect otherwise.

I'm talking about the serial stream that flows across / on top of the
modems.

Presuming that a mainframe could talk to an async serial modem (which I
have serious questions about sync vs async) what the mainframe sends
across the modem and expects to receive from it is completely different
than what micro computers send and expect to receive.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 3:30:39 PM UTC+10, Grant Taylor wrote:

> > So that the application software that drives the modem doesn't need
> > to be aware of ASCII vs EBCDIC differences.

> So ... you'll do a translation from Cyrillic / English (?name?)
> characters but you still have Russian words, not English equivalents.

I have no idea what you are talking about.

> Something, e.g. the application using the modem, is going to have to
> translate Russian words (in English, not Cyrillic, characters) to
> English counterparts. Meaning that the application still has to do the
> translation.

The application will be very simple, just a terminal
program that allows the user to enter ATDE.

The modem will do the rest.

> Even if it is all English and not the hypothetical scenario above, you
> still have the problem that the way that a mainframe (the only thing --
> that I'm aware of -- that still uses EBCDIC) communicates vs how a PC
> communicates.

I have no idea what you are talking about.

> > I only have an interest in the 819/1047 conversion. All EBCDIC code
> > pages need to adjust to match their ASCII equivalent after the above
> > conversion.

> LOL
>
> ASCII code pages aren't even compatible with each other. And you want
> to try to force systems that have a 50 year history of backward
> compatibility (largely by not changing) to change to match something
> that isn't itself uniform?

Other people are trying to force EBCDIC to die completely.

All I'm requesting is that the 819/1047 translation be set
in stone.

> > My EBCDIC mainframe modem is identical to an ASCII PC modem at that
> > level. They couldn't connect otherwise.

> I'm talking about the serial stream that flows across / on top of the
> modems.

I have no idea what you are talking about.

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.

And I'm providing that hardware (Hercules/380).

> Presuming that a mainframe could talk to an async serial modem (which I
> have serious questions about sync vs async) what the mainframe sends
> across the modem and expects to receive from it is completely different
> than what micro computers send and expect to receive.

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.

Looks like I will have the world's first mainframe EBCDIC BBS.

BFN. Paul.

[Grant Taylor]

On 6/11/21 11:44 PM, muta...@gmail.com wrote:
> I have no idea what you are talking about.

That's apparent.

> 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
standard.

> 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?

[wolfgang kern]

On 12.06.2021 07:44, muta...@gmail.com wrote:

> And I'm providing that hardware (Hercules/380).

OK, I'll buy one.
But only if it has an USB-connector and understand gypsy-glyphs.
__
wolfgang

[muta...@gmail.com]

On Saturday, June 12, 2021 at 4:56:09 PM UTC+10, Grant Taylor wrote:

> > 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?

For now I am only supporting mainframe applications
that send EBCDIC ANSI data streams.

> 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

Yes, I have some familiarity with 3270 data streams.

> 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.

Upgrade your mainframe to one that is character-oriented.

> 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.

Yes. And I'm improving the hardware. And OS. And
C library.

> > 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.

I'm the modem manufacturer. You don't have much choice.

> > 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

I'm not running standard applications. I'm running
applications that also work on PDOS/386, at least
at the C source code level.

> 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?

I want to move the complication into the modem. One place.
Instead of polluting my application code with character set
knowledge.

> There's also the complication that people need to
> interact with the mainframe in EBCDIC to start application, custom or
> standard.

And you can interact the same way you would an
ASCII host.

It's just a matter of selecting a decent mainframe OS.

> > 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.)

Yes, is that a problem?

> 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....

Yes, it's largely already in place.

> > 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.

I am overthrowing the lot.

> > Looks like I will have the world's first mainframe EBCDIC BBS.

> And what EBCDIC clients will connect to it?

I'll provide that too.

BFN. Paul.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 5:13:38 PM UTC+10, wolfgang kern wrote:

> > And I'm providing that hardware (Hercules/380).

> OK, I'll buy one.
> But only if it has an USB-connector and understand gypsy-glyphs.

USB to connect to what, and for what purpose?

And what are gypsy-glyphs? If it's a special character set, then
yes, so long as you have a Windows or Linux system that
can display that character set, it will work. And you also need
to not demand some specific mapping on the EBCDIC side.
You need to accept what you are given and make sure your
EBCDIC data is in that format.

BFN. Paul.

[Grant Taylor]

On 6/12/21 1:29 AM, muta...@gmail.com wrote:
> For now I am only supporting mainframe applications that send EBCDIC
> ANSI data streams.

What, pray tell, is "EBCDIC ANSI"?

> Upgrade your mainframe to one that is character-oriented.

What model mainframe would that be?

Even the latest mainframe running z/OS / z/VM is still predominantly
3270 data streams. Or are you referring to OMVS / USS via SSH (or maybe
telnet)?

> Yes. And I'm improving the hardware. And OS. And C library.

LOL

> I'm the modem manufacturer. You don't have much choice.

Sure I do.

I have the choice to spend my time / money, -- here's the important part
-- or not.

> I'm not running standard applications. I'm running applications that
> also work on PDOS/386, at least at the C source code level.

Well, at least you have prior art on your side. There was a version of
AIX/370 that could share binaries with AIX/PS/2 Though IBM actively
destroyed any copies of that software.

> I want to move the complication into the modem. One place. Instead of
> polluting my application code with character set knowledge.

So you want your modem to do what a 3172 / 3174 did.

Remember, the 3172 / 3174 supported traditional Unix dumb serial
terminals in that it (the 3172 / 3174) would run software to maintain
state to translate between the 3270 data stream and the VT100 (for the
sake of discussion) connected to an async RS-232 serial port. The 3172
/ 3174 worked by having a virtual 3270 terminal and translating between
that virtual terminal and the serial port.

> And you can interact the same way you would an ASCII host.

How do you propose logging into the MVS / OS/390 / z/OS and starting
your custom application? Or are you throwing the entire operating
system out?

> It's just a matter of selecting a decent mainframe OS.

LOL ....

> Yes, is that a problem?

How are you going to physically connect your modem to an entirely
virtual system?

Or is your modem virtual too?

> Yes, it's largely already in place.

Okay ....

> I am overthrowing the lot.

Whatever floats your boat.

> I'll provide that too.

Okay.

[Grant Taylor]

On 6/12/21 1:33 AM, muta...@gmail.com wrote:
> USB to connect to what, and for what purpose?

Hypothetically to connect a modem via a USB-to-serial adapter.

> And what are gypsy-glyphs? If it's a special character set, then yes,
> so long as you have a Windows or Linux system that can display that
> character set, it will work. And you also need to not demand some
> specific mapping on the EBCDIC side.

Why can't we demand some specific mapping on the EBCDIC side if you get
to demand some specific mapping on the EBCDIC side.

pot / kettle

> You need to accept what you are given and make sure your
> EBCDIC data is in that format.

Sure.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 6:04:46 PM UTC+10, Grant Taylor wrote:

> > For now I am only supporting mainframe applications that send EBCDIC
> > ANSI data streams.

> What, pray tell, is "EBCDIC ANSI"?

To clear the screen of the remote terminal, you
send ESC [ 2 J in EBCDIC. So that sequence
starts with x'27'.

> > Upgrade your mainframe to one that is character-oriented.

> What model mainframe would that be?
>
> Even the latest mainframe running z/OS / z/VM is still predominantly
> 3270 data streams. Or are you referring to OMVS / USS via SSH (or maybe
> telnet)?

PDOS/3X0 running under Hercules/380.

> > I'm the modem manufacturer. You don't have much choice.

> Sure I do.
>
> I have the choice to spend my time / money, -- here's the important part
> -- or not.

No, you have no choice. On my EBCDIC BBS is going to
be the best porn you will have ever seen. And the only
way you can get to it is by typing ATDE.

> Remember, the 3172 / 3174 supported traditional Unix dumb serial
> terminals in that it (the 3172 / 3174) would run software to maintain
> state to translate between the 3270 data stream and the VT100 (for the
> sake of discussion) connected to an async RS-232 serial port. The 3172
> / 3174 worked by having a virtual 3270 terminal and translating between
> that virtual terminal and the serial port.

If IBM has the equivalent, feel free to buy from them instead.

> > And you can interact the same way you would an ASCII host.

> How do you propose logging into the MVS / OS/390 / z/OS and starting
> your custom application? Or are you throwing the entire operating
> system out?

Yes. But it still uses MVS executables.

> How are you going to physically connect your modem to an entirely
> virtual system?
> Or is your modem virtual too?

Of course.

>> USB to connect to what, and for what purpose?

> Hypothetically to connect a modem via a USB-to-serial adapter.

Ok. You can use the internet instead if you want.

>> And what are gypsy-glyphs? If it's a special character set, then yes,
>> so long as you have a Windows or Linux system that can display that
>> character set, it will work. And you also need to not demand some
>> specific mapping on the EBCDIC side.

> Why can't we demand some specific mapping on the EBCDIC side if you get
> to demand some specific mapping on the EBCDIC side.

> pot / kettle

You're welcome to fork my code and do that if you want.

BFN. Paul.

[Rod Pemberton]

On Thu, 10 Jun 2021 23:07:25 -0700 (PDT)

"muta...@gmail.com" <muta...@gmail.com> wrote:

> There is ATD which means dial, I think some default.
>

> ATDP which says to use pulse.
>
> ATDT which says to use tone.
>

> I am proposing ATDE which means dial an EBCDIC
> remote.
>

> I guess ATDTE and ATDET would both be acceptable?
>

> And default is the same as you currently use? So an
> EBCDIC system by default assumes it is dialing another
> EBCDIC system.
>
> So software just needs to do an ATD and you don't
> need to worry whether you're EBCDIC or ASCII or
> have a pulse or tone phone line.
>

<after reading the entire thread>

So, you're wanting people with ASCII based systems, like x86 PCs, to
dial in to your BBS which is EBCDIC based system, and you need a method
to do the ASCII-to-EBCDIC translation seemlessly in the background? ...

What is wrong with piping the streams through a conversion program?
E.g., EBCDIC-to-ASCII (outbound) and ASCII-to-EBCDIC (inbound).

The conversion program is only going to convert text characters, yes?
E.g., valid characters for isprint() or isgraph() for C.

Shouldn't this just be two 256 byte translation tables?

--
What is hidden in the ground, when found, is hidden there again?

[Joe Monk]

What about terminals like an ASR 33 teletype, that speak current loop and dont have a modem?

Joe

[Rod Pemberton]

Stop trolling Paul.

He'll probably take you up on that and VT100,
VT220, as well as all the IBM stuff.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 9:41:33 PM UTC+10, Rod Pemberton wrote:

> So, you're wanting people with ASCII based systems, like x86 PCs, to
> dial in to your BBS which is EBCDIC based system, and you need a method
> to do the ASCII-to-EBCDIC translation seemlessly in the background? ...

Yes.

> What is wrong with piping the streams through a conversion program?
> E.g., EBCDIC-to-ASCII (outbound) and ASCII-to-EBCDIC (inbound).

Who should do that? Me, on my EBCDIC system?
No fucking way!!!

(moves to a different country, puts on a different hat)

Who should do that? Me, on my ASCII system?
No fucking way!!!

> The conversion program is only going to convert text characters, yes?
> E.g., valid characters for isprint() or isgraph() for C.

That's an interesting question. My primary interest is
to get text working, but I have been considering what
changes need to be made to zmodem (I have my own
public domain zmodem code) to handle binary data.

My first thought was that I would need the binary converted
to hex text. But then I thought that the zmodem code needed
an extra parameter to say whether it was an originator
responsible for conversion, or a receiver responsible for
conversion. (And I'm not sure yet whether it makes a
difference). (And note that the receiver is normally not
going to be responsible for conversion, but we can allow
for that possibility). You can thus predict how the data
has been mangled and correct for it.

> Shouldn't this just be two 256 byte translation tables?

Yes, it should be a simple thing to add to modems which
already handle a lot of AT-stuff.

BFN. Paul.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 10:28:27 PM UTC+10, Joe Monk wrote:

> What about terminals like an ASR 33 teletype, that speak current loop and dont have a modem?

I don't know what that means, but if you have a synchronous
modem, or 2 tin cans and a piece of string, rather than a
modem that supports ATDE, you will need to find another
solution.

BFN. Paul.

[muta...@gmail.com]

On Saturday, June 12, 2021 at 6:26:28 PM UTC+10, muta...@gmail.com wrote:

> No, you have no choice. On my EBCDIC BBS is going to
> be the best porn you will have ever seen. And the only
> way you can get to it is by typing ATDE.

Bugs fixed, a fair amount of work, but my EBCDIC BBS
is now operational.

kerravon.mooo.com 64000

You'll need to negotiate the EBCDIC to see the status
of the porn.

I can no longer test it myself because I don't have my
modem operational yet.

Updated Hercules/380 available in custom.zip at http://pdos.org
I'm no longer providing executables though.

BFN. Paul.

[Joe Monk]

As is my experience with most things that Paul does, his BBS doesnt work either.

When you connect it gives you 3 options, all of which claim they are "not implemented". Just for grins I tried option 1, followed by the Enter key, and got "Thats not a valid option Hex 0A"...

Joe

[muta...@gmail.com]

On Monday, June 14, 2021 at 10:32:20 PM UTC+10, Joe Monk wrote:

> As is my experience with most things that Paul does, his BBS doesnt work either.

It's more in "proof of concept" stage. I need to figure
out an XON-based protocol, now that I know what I
actually want to do.

> When you connect it gives you 3 options, all of which claim
> they are "not implemented".

That means you deciphered the EBCDIC. Cool. How did you
do that?

> Just for grins I tried option 1, followed by the Enter key,

You shouldn't need to press enter. It is a character-based BBS.

> and got "Thats not a valid option Hex 0A"...

That's on you. You sent ASCII to an EBCDIC system.
Try sending an x'F1' instead. And if the screen hadn't
been cleared because of the multiple keystrokes
entered, you would have seen it complain about the
x'31' and maybe x'0D' first. If you log the traffic you
should be able to see that.

BFN. Paul.

[Joe Monk]

On Monday, June 14, 2021 at 9:11:57 AM UTC-5, muta...@gmail.com wrote:
> On Monday, June 14, 2021 at 10:32:20 PM UTC+10, Joe Monk wrote:
>
> > As is my experience with most things that Paul does, his BBS doesnt work either.
> It's more in "proof of concept" stage. I need to figure
> out an XON-based protocol, now that I know what I
> actually want to do.
> > When you connect it gives you 3 options, all of which claim
> > they are "not implemented".

> That means you deciphered the EBCDIC. Cool. How did you
> do that?

I set the code page in my telnet client for an EBCDIC code page.

> > Just for grins I tried option 1, followed by the Enter key,
> You shouldn't need to press enter. It is a character-based BBS.
> > and got "Thats not a valid option Hex 0A"...
> That's on you. You sent ASCII to an EBCDIC system.
> Try sending an x'F1' instead. And if the screen hadn't
> been cleared because of the multiple keystrokes
> entered, you would have seen it complain about the
> x'31' and maybe x'0D' first. If you log the traffic you
> should be able to see that.

I DID send x'F10A'. Thats 1 followed by a CR in EBCDIC. You should accept the CR as well if its within x seconds of a valid option.

>
> BFN. Paul.

[muta...@gmail.com]

On Tuesday, June 15, 2021 at 2:44:51 AM UTC+10, Joe Monk wrote:

> > That means you deciphered the EBCDIC. Cool. How did you
> > do that?

> I set the code page in my telnet client for an EBCDIC code page.

For what reason does telnet support EBCDIC? Who
else is emitting EBCDIC and what does the data
stream look like?

> I DID send x'F10A'. Thats 1 followed by a CR in EBCDIC.

As I said, the x'F1' should have generated a different
message, which you would see if you put logging on.

CR in EBCDIC is x'0D', not x'0A'. Regardless, nothing in
PDOS/3X0 or its applications know what to do with
x'0D'. They operate on x'15' for newline. x'0A' is the
ASCII counterpart and unknown.

> You should accept the CR as well if its within x seconds of a valid option.

Accept it to do what? It already took action when it read the
first character.

Regardless, I have never heard of anything that behaves the
way you describe. I have run micro-emacs for over 30 years
and if I type "1" then hit enter, it's very different from 1 without
enter, and the time between keystrokes is irrelevant. And timing
is fraught with danger - computer networks are able to make
that time gap both decrease (to 0) and increase (up to infinity).

BFN. Paul.

[Joe Monk]

> For what reason does telnet support EBCDIC? Who
> else is emitting EBCDIC and what does the data
> stream look like?

On my macOS shell (terminal app), I can set the code page to Western (EBCDIC latin 1), which as I understand it is code page 037.

I connect (in ASCII to kerravon.mooo.com port 64000). Then I change the code page to the above. Pressing ENTER does nothing, so I type a "?", which gives me:

…"Welcome to the Ten Minute Limit BBS…Back in action 24 years after a fascist kicked me off Fidonet…brought to you in glorious EBCDIC…enter an option below:…1. Message area (not yet implemented)…2. File area (not yet implemented)…3. The highest quality porn ever produced (coming soon)"

When I press a single character, it just sits there, and does nothing.When I type a "1" followed by the ENTER key, it gives me:

"You entered an invalid option! (hex 71)…it wasn't even a digit!!!… …Welcome to the Ten Minute Limit BBS…Back in action 24 years after a fascist kicked me off Fidonet…brought to you in glorious EBCDIC…enter an option below:…1. Message area (not yet implemented)…2. File area (not yet implemented)…3. The highest quality porn ever produced (coming soon)…ÝJYou entered an invalid option! (hex 0A)…it wasn't even a digit!!!… …Welcome to the Ten Minute Limit BBS…Back in action 24 years after a fascist kicked me off Fidonet…brought to you in glorious EBCDIC…enter an option below:…1. Message area (not yet implemented)…2. File area (not yet implemented)…3. The highest quality porn ever produced (coming soon)"

Joe

[muta...@gmail.com]

On Tuesday, June 15, 2021 at 8:13:43 PM UTC+10, Joe Monk wrote:

> > For what reason does telnet support EBCDIC? Who
> > else is emitting EBCDIC and what does the data
> > stream look like?

> On my macOS shell (terminal app), I can set the code page to Western (EBCDIC latin 1), which as I understand it is code page 037.

Ok, cool.

> I connect (in ASCII to kerravon.mooo.com port 64000). Then I change the code page to the above. Pressing ENTER does nothing, so I type a "?", which gives me:

If ENTER does nothing, try it again. The BBS should react
to that and complain. Unless nothing is being sent.

> …"Welcome to the Ten Minute Limit BBS…Back in action 24 years after a fascist kicked me off Fidonet…brought to you in glorious EBCDIC…enter an option below:…1. Message area (not yet implemented)…2. File area (not yet implemented)…3. The highest quality porn ever produced (coming soon)"
>
> When I press a single character, it just sits there, and does nothing.When I type a "1" followed by the ENTER key, it gives me:
>
> "You entered an invalid option! (hex 71)…it wasn't even a digit!!!…

Ok, I'm thinking the Mac software is stripping the high bit, and
at some point it did actually generate a hex F1.

I doubt that it is my end that is stripping it.

> (coming soon)…ÝJYou

That funny "Y" character is probably the ESC. It's not
interpreting the ANSI escape sequence, ESC [ 2 J
It will have never been exposed to that before I think.
Although I don't know how IBM USS or whatever it is
called manages to run emacs and vi. Don't they send
ANSI control characters to drive a terminal? They're
running in an EBCDIC environment - what choice do
they have?

Note that you can see the BBS software here, it's not
that complicated:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/s370/bbs.c

Ah, actually - the "Y" is probably "[". If you're using 037
instead of 1047, the "[", which is sent as x'AD', will not
be translated correctly. Even if the Mac recognized
EBCDIC ANSI escape sequences.

> entered an invalid option! (hex 0A)

And this looks like an ASCII newline that was never translated
to EBCDIC. It should have been converted to one of LF x'25',
CR x'0D', NL x'15'. It is only the last one that is used anywhere
in my software.

So it sounds like multiple issues.

Very interesting!!! Thanks for doing that test. ASCII and
EBCDIC colliding.

BFN. Paul.

[muta...@gmail.com]

On Tuesday, June 15, 2021 at 8:42:48 PM UTC+10, muta...@gmail.com wrote:

> > When I press a single character, it just sits there, and does nothing.When I type a "1" followed by the ENTER key, it gives me:
> >
> > "You entered an invalid option! (hex 71)…it wasn't even a digit!!!…

> Ok, I'm thinking the Mac software is stripping the high bit, and
> at some point it did actually generate a hex F1.
>
> I doubt that it is my end that is stripping it.

Someone else has independently reported that when using
Putty, and entering a "1", it does detect that it is a digit.

However, they seem to only get that reported intermittently.

All of the software involved is too immature (or at least,
not gone through this code path) to be sure of who is at
fault at the moment.

BFN. Paul.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:

> On Saturday, June 12, 2021 at 2:08:40 AM UTC+10, Grant Taylor wrote:
>
> > > I am proposing ATDE which means dial an EBCDIC remote.
>

> > Phones don't dial with ASCII or EBCDIC or anything else for that matter.

>
> But I'm expecting the modem to do an ASCII-EBCDIC
> translation when presented with an "E" or "A" that
> doesn't match the configured setting being used by
> the terminal.

<snip>
> I want the modem to do it. Is there a technical barrier
> to that?

For some time my e-mail was on VM/CMS accessed via modem
from a PC. Plain ATDT worked fine to establish connection.
Terminal emulator (Kermit) knew that it was connected to
EBCDIC system and did needed translation.

Doing translation in modem actually would complicate
terminal emulator. Namely, beside running terminal
programs on mainframe terminal emulator also handled
file transfers. Character translation inside modem
would complicate file transfers, either terminal
program would have to switch off character translation
or somewhat compensate for it in file transfer protocol.

So, you can do what you want, by why complicate things
without need?

P.S. To folks who say that mainframe can not do ASYNC:
this was done via a hardware hack on mainfraime side.

--
Waldek Hebisch

[muta...@gmail.com]

On Friday, June 18, 2021 at 5:50:19 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> For some time my e-mail was on VM/CMS accessed via modem
> from a PC. Plain ATDT worked fine to establish connection.
> Terminal emulator (Kermit) knew that it was connected to
> EBCDIC system and did needed translation.
>
> Doing translation in modem actually would complicate
> terminal emulator.

Why? Kermit is already complicated by having the
burden of ASCII to EBCDIC translation, isn't it?

And you suddenly restrict yourself to terminal software
that has this complication.

> Namely, beside running terminal
> programs on mainframe terminal emulator also handled
> file transfers. Character translation inside modem
> would complicate file transfers, either terminal
> program would have to switch off character translation
> or somewhat compensate for it in file transfer protocol.

Yes, I agree that file transfers (instead of the terminal)
would need some complication added. Is this actually
a worse situation?

Regardless, solutions available are:

1. Use a file transfer protocol that sends binary data as
two hex characters for links that are considered to be
problematic. This will also bypass problems with other
characters like XON and Telnet.

2. Rely on the fixed 819/1047 translation being done and
compensate appropriately.

Note that I'm not trying to solve every problem in the
world simultaneously. I have a specific EBCDIC use-case
that I want to see work.

> So, you can do what you want, by why complicate things
> without need?

To take the burden off the vast bulk of the terminal
software. Terminal software already normally allows
you to set the modem dial string, e.g. ATDP or ATDT.
Why not ATDE?

> P.S. To folks who say that mainframe can not do ASYNC:

> this was done via a hardware hack on mainframe side.

Can you provide more details of this please?

Also, I assume that your VM/CMS software was still
operating on line mode, you couldn't run a character-based
application like micro-emacs?

Thanks. Paul.

[anti...@math.uni.wroc.pl]

Translation between 8-bit code pages can be done via
table lookup. That costs 512 bytes (for two way
translation) and single indexed memory access per
character. This is not much burden, either for
software or for hardware. However, you need to
know which code page to use and when. Sofware
simply is better place to put translation because
it anyway needs to know about state of connection,
so switching translation tables comes naturally.

But I will stop arguing here. Apparently you
love solutions that other folks find awkward.
Since you are doing this, ulitmately your
opinion is most important here.

> > P.S. To folks who say that mainframe can not do ASYNC:
> > this was done via a hardware hack on mainframe side.
>
> Can you provide more details of this please?

Not much. I was just a user (one of users as this
line was shared with several other folks). The
guy who did that said that it was enough to add
one wire, to connect internal signal to external
connector. He also said that transmissin was
via interrupts and that "IBM does not like
interrupts". I take this to mean that each
character triggered a separate interrupt.
My guess is that the guy connected "external
interrupt" line (which IIUC is standard thing
for IBM processors) to parallel-port style
connector so that modem could interrupt the
mainframe. Concerning "IBM does not like
interrupts": transmiting one character per
interrupt was horribly inefficient by IBM
standards. Since this was single line, there
was no problem. But the machine had probably
about 80 terminals connected using standard
IBM interfaces. Running 80 terminals in
async mode probably would not work (I mean
running in hacky way without something
like 3705).

> Also, I assume that your VM/CMS software was still
> operating on line mode, you couldn't run a character-based
> application like micro-emacs?

I only used e-mail. IIUC e-mail software were done
using standard CMS utilitis (including some hairy
scripts). I really can not say it this was
line mode or 3270 emulation (AFAIK other terminals
were 3270).

For e-mail system felt sluggish, since
for other work I had fast PC I did not try other
things on mainframe. Just as extra explantion:
on mainframe I got a single VM, limited to 8M
virtual memory that could run only single program
at given time (due to limitation of CMS). On
PC I had 386 BSD and later Linux. While I had
4M real memory I could get tens of megs virtual
memory. And I could run time-consuming tasks
in background, without worry that other folks
get angry on me for blocking shared e-mail
connection.

--
Waldek Hebisch

[muta...@gmail.com]

On Friday, June 18, 2021 at 10:14:22 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> Translation between 8-bit code pages can be done via
> table lookup. That costs 512 bytes (for two way
> translation) and single indexed memory access per
> character. This is not much burden, either for
> software or for hardware.

I would like simple comms programs to work out of
the box so long as both ends are EBCDIC or both
ends are ASCII. I expect "ATDT" to work.

> However, you need to
> know which code page to use and when.

Most people don't support EBCDIC at all. I support one
single EBCDIC codepage. Other EBCDIC codepages are
supported if they survive the 819 to 1047 transition. I
don't know how many that is. But all other EBCDIC users
can find their own solutions.

> Sofware
> simply is better place to put translation because
> it anyway needs to know about state of connection,
> so switching translation tables comes naturally.

Not sure what you mean by "state of connection".

> But I will stop arguing here. Apparently you
> love solutions that other folks find awkward.
> Since you are doing this, ulitmately your
> opinion is most important here.

Very diplomatic. :-)

> connector. He also said that transmissin was
> via interrupts and that "IBM does not like
> interrupts". I take this to mean that each
> character triggered a separate interrupt.
> My guess is that the guy connected "external
> interrupt" line (which IIUC is standard thing
> for IBM processors) to parallel-port style
> connector so that modem could interrupt the
> mainframe. Concerning "IBM does not like
> interrupts": transmiting one character per
> interrupt was horribly inefficient by IBM
> standards. Since this was single line, there
> was no problem. But the machine had probably
> about 80 terminals connected using standard
> IBM interfaces. Running 80 terminals in
> async mode probably would not work (I mean
> running in hacky way without something
> like 3705).

I would hope that after 30 years (or whenever you were
doing this) of technology improvement that mainframes
can now cope with 80 terminals where previously they
could only do 1. I wonder what percentage of a modern
z/Arch CPU would be consumed coping with 80 monkeys
banging away on keyboards as fast as they can, with
each keystroke causing an interrupt.

BFN. Paul.

[Joe Monk]

>I wonder what percentage of a modern
> z/Arch CPU would be consumed coping with 80 monkeys
> banging away on keyboards as fast as they can, with
> each keystroke causing an interrupt.

Modern z/arch doesnt just have 1 CPU, they start at 34 go up to 190 or so for the larger models... each processor chip has 12 cores and runs at 5.2 GHz with 256MB of L3 cache. As far as memory, it starts at 512GB and can go up to 40TB.

With an OSA express 7S card, all network based interrupt processing doesnt even touch the CPU, it is all handled by the firmware/hardware of the OSA card.

http://books.google.com/books?vid=ISBN:9780738458120

Joe

[muta...@gmail.com]

If it was changed to interrupt the CPU so that the
application had immediate access to every keystroke
that a monkey pressed, could z/Arch in 2021 keep
up with the monkeys or not?

Let's say 100 monkeys. What percentage of the
combined CPU power would be "wasted" keeping up
with them?

BFN. Paul.

[Joe Monk]

> If it was changed to interrupt the CPU so that the
> application had immediate access to every keystroke
> that a monkey pressed, could z/Arch in 2021 keep
> up with the monkeys or not?
>
> Let's say 100 monkeys. What percentage of the
> combined CPU power would be "wasted" keeping up
> with them?

It doesnt need to be changed. Thats the whole point. And yes it has access to every keystroke (how do you think it runs interactive linux?). At 100 monkeys, the zBox is laughing at you.

Joe

[anti...@math.uni.wroc.pl]

Note that I wrote "character", not a keystroke. Most
people can not type faster than 10 cps and most of
the time will type slower. So 80 persons will
generate on average probably less than 200-300 keystrokes per
second. But characters include system answers, which
typically are much larger. And file transfers
where as fast as link would allow (something like
480 cps or 960 cps). Some of terminals were PC with
3270 interface, they could tranfer files rather
fast.

To put this differently, on 386 with its standard dumb
serial port it was quite possible to lose charaters
at higher transmission speeds because CPU was too slow
to handle interrups on time. Certainly such machine
would be overlowded by 30 standard dumb serial ports.
OTOH 386 machine generously equipped with memory (which
probably meant 16MB) was able to handle about 30-40
students connected via telnet and editing/compiling C
programs. Telnet transmits each keystroke separately
(in separate network packet) and normally keystrokes
were echoed by application (shell or editor) running on
386. So you got process switch and packet with echo.
Each packet were acknowledged so there were 2
acknowledgments. Normally one acknowledgment was
carried by echo packet, so there were 3 packets
per keystroke. Looks like a lot of activity, but
machine could handle it. However, opening file in editor
or paging trough file would cause screen redraw which
probably went in two packets. With dumb async link
screen redraw means 2000 interrupts.

Coming back to mainframes, 3705 (maybe 2 or 3 for faster lines)
could easily handle 80 async lines. I pretty sure that
limitation of line or 3270 mode was mostly software one.
That is hardware had enough CPU power enough to handle
input in character mode. Tricky thing is memory, in
3270 mode mainframe discs were fast enough to swap in/
swap out user VMs when needed. In line mode there
are more context switches, so more disc trafic.
Character-by-character is worse, probably 50-100
times as many context switches as in 3270 mode.
100 times as many context switches means more/faster
discs or enough real memory to keep all active code
and data in RAM.

Of course, with modern machines 80 users should be no
problem. But if you pay for z/Arch machine you
probably want more from it. Several years ago
IBM reported that is z/Arch machine handled 100000
web server hits pers second. For traditional
mainframe app that would mean generating 100000
screens per second. Typical expectation is that
user will want new screen on average once per 30
seconds. That means that this machine could
handle 3000000 users simultaneously. If you have
smaller number of simultaneous users, say 10000
than PC class machine will do. But you need to
program your system in efficient way. Allow
waste and you may have trouble with 50 users.

--
Waldek Hebisch

[Grant Taylor]

On 6/17/21 7:44 PM, muta...@gmail.com wrote:
> I would hope that after 30 years (or whenever you were doing this) of
> technology improvement that mainframes can now cope with 80 terminals
> where previously they could only do 1. I wonder what percentage of a
> modern z/Arch CPU would be consumed coping with 80 monkeys banging
> away on keyboards as fast as they can, with each keystroke causing
> an interrupt.

30 years ago the company my mom worked for had an IBM mainframe (I don't
remember the model) that had 500 to 1,000 users ~> terminals connected
to it in the regional office building and hundreds more users from
around the multi-state region connected to it remotely. The mainframe
handled everything perfectly fine.

[Grant Taylor]

On 6/17/21 9:17 PM, Joe Monk wrote:
> At 100 monkeys, the zBox is laughing at you.

At 100 monkeys you're crying over how massively over provisioned the
mainframe is.

Put a few zeros behind that and the mainframe might stop laughing for a
fraction of a second, do some work, and then continue laughing at you.

[muta...@gmail.com]

On Friday, June 18, 2021 at 1:35:08 PM UTC+10, anti...@math.uni.wroc.pl wrote:

> > I would hope that after 30 years (or whenever you were
> > doing this) of technology improvement that mainframes
> > can now cope with 80 terminals where previously they
> > could only do 1. I wonder what percentage of a modern
> > z/Arch CPU would be consumed coping with 80 monkeys
> > banging away on keyboards as fast as they can, with
> > each keystroke causing an interrupt.

> Note that I wrote "character", not a keystroke. Most
> people can not type faster than 10 cps and most of
> the time will type slower. So 80 persons will
> generate on average probably less than 200-300 keystrokes per
> second. But characters include system answers, which
> typically are much larger.

I only wish to have keystrokes transmitted to the
application immediately. I don't mind if screen
buffer returns and file transfers are bundled up.

I just object to needing to hit enter. There may have
been an excuse 30 years ago. Or 50 years ago. There's
no excuse in 2021. Get a better mainframe if yours
doesn't support EBCDIC ANSI terminals so that you
can run micro-emacs.

BFN. Paul.

[muta...@gmail.com]

My EBCDIC BBS has been replaced by an ASCII BBS for now.

You can access it with:

telnet bbs.pdos.org 64000

(try pressing "1" after connecting)

The BBS resides in a "cloud" in Vietnam.

I had to make some changes to the old BBS source code.
New code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/src/simpbbs.c

The intention is to add zmodem upload facility to this code.
To that end I have provided a new beta pdpzm available in
custom.zip from http://pdos.org

It is running under qemu because Bochs doesn't work
(constantly reboots). Bochs is being debugged currently.

I didn't see an INT 14H call to drop DTR, and even if it
existed, qemu doesn't support dropping a TCP/IP
connection in response to DTR being dropped. So that
means there is no way to "logoff" and you need to terminate
the telnet connection yourself.

BFN. Paul.