terminal designed for C

[kerravon]

Hello folks.

According to the 1990 C standard (which is what I wish to code to), there is no "escape" character. So the only way to produce an escape character is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I don't like doing that. I want to be able to write an editor like micro-emacs without having to have an #ifdef EBCDIC.

My conclusion is that I need to create a new type of terminal. Instead of having an ANSI terminal where ESC [ 2 J causes the screen to be cleared:

http://forum.codecall.net/topic/59142-how-to-clear-the-console-screen-with-ansi-any-language/

I instead want to replace the ESC with either a form feed, vertical tab or alert. All of these things are defined in 5.2.2 of the standard. But 5.2.1 of the standard says:

"control characters representing horizontal tab, vertical tab. and form feed."

ie there is no alert defined. So I guess that is ruled out. A reminder thatmy goal is an "ideal terminal from the C programmer's perspective".

I've never seen a vertical tab defined on a US keyboard, so I'm thinking that can be stolen for this purpose. But I would say that form feed is even more meaningless/useless when an escape sequence exists in order to clear the screen.

So would form-feed be the ideal character to steal?

Note that in order to maintain compatability with existing ANSI terminals, my plan is to get the operating system itself to convert form-feed (or whatever) characters into an ASCII/EBCDIC escape character. Note that form-feedis x'0c' in both ASCII and EBCDIC. I don't mind the operating system having some hard-coding in it to convert x'0c' to x'1b'/x'27'. I just don't wantto see that in my application program (in this case my application programwill be somewhat of a clone of micro-emacs).

Any room for conceptual improvement?

Note that the main target for this is PDOS/390, which can be found at http://pdos.sourceforge.net - ie this is intended to run in an EBCDIC environment being emulated on an ASCII machine. I will telnet into Hercules.

The short story is that I am happy that the people who wrote the ANSI terminal specification did a reasonable job, they just didn't quite cater for a portable C program to drive the terminal. So it's just a minor thing I wantto change. Any name for the new ANSI-like terminal? I was thinking of PANSI/PANSY, the P coming from PDOS.

Thanks. Paul.

 

[kerravon]

Is this a meaningful problem? Is there actually a terminal
(presumably emulated) that actually implements *EBCDIC* ANSI escape
sequences?

My plan was for the EBCDIC operating system to assume
the existence of an EBCDIC ANSI/PANSY terminal. Then
it would be up to Hercules to translate the ASCII
telnet ANSI terminal into the required EBCDIC form, so
that the EBCDIC application has something to drive.

How else would you propose getting micro-emacs (or
similar) to run on the mainframe?

Most EBCIDIC systems which allow the attachment of ASCII terminals
provide a considerable (and usually very clumsy) translation layer if
the application is to use EBCDIC

Yes, this is the route I intend to take.

or pass through the ASCII unchanged,
in which case the translation needs to happen in the application.

I do not wish to go this route. I think I have a fundamental
right to write an execution-character-set-neutral editor in C
without deviating from the C90 standard.

Which raises another point. I intend to make stdin/stdout
be IONBF, and leave them as text mode, since I don't think
there is a standard way to switch to binary mode.

And most EBCDIC terminals are block mode devices, or line mode devices
with very, very different characteristics than typical ASCII
terminals.

Right. Which is why micro-emacs hasn't been implemented on
MVS for decades.

Or am I missing something?

I intend to change decades of micro-emacs-less mainframes.
I have proposed a path to achieve that. I'm not aware of
a better path, but open to comment.

Thanks. Paul.

 

[Sjouke Burry]

Hello folks.

According to the 1990 C standard (which is what I wish to code to),
there is no "escape" character. So the only way to produce an escape
character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
respectively). I don't like doing that. I want to be able to write an
editor like micro-emacs without having to have an #ifdef EBCDIC.

My conclusion is that I need to create a new type of terminal.

CUT
First you should get a keyboard with an enter key.
Then spend a few hours to learn to use it.

 

[Keith Thompson]

CUT
First you should get a keyboard with an enter key.
Then spend a few hours to learn to use it.

Perhaps a let sarcastic approach would be more productive.

kerravon, the Google Groups interface is not well suited for
posting to Usenet. One of its problems is that it doesn't make
it easy to write text in a suitable manner. For a web interface,
it makes sense to write very long lines and let the web interface,
or your browser, wrap it for you. For Usenet, it's better to post
with lines no longer than 80 columns; 72 or less is even better.
You have to insert explicit line breaks to do this. (My newsreader,
for example, will wrap long lines, but not at word boundaries;
other news software may be even less friendly to very long lines.)

Google Groups has also recently started double-spacing quoted text,
which is *really* annoying.

You can work around this problem if you can compose your article
in a text editor that lets you do this, and then copy-and-paste it
into the Google Groups text window. Or, better yet, get a real
Usenet newsreader (I use Gnus, which you'll like if and only if
you like Emacs) and an account on a free or cheap Usenet server
(I use eternal-september.org).

 

[kerravon]

Perhaps a let sarcastic approach would be more productive.

Yes, I assumed that the other response was along the
lines of EBCDIC devices always operate in either line
mode or block mode, so stop trying to use character
mode, and learn to press enter to terminate text.

or your browser, wrap it for you. For Usenet, it's better to post
with lines no longer than 80 columns; 72 or less is even better.

OK.

So any comment on the C90 not defining an escape
character, while ANSI terminals requiring an
escape character? Which computers did C90 have
in mind when they left out the escape character,
but included a vertical tab?

BFN. Paul.

 

[Lew Pitcher]

Hello folks.

According to the 1990 C standard (which is what I wish to code to), there
is no "escape" character. So the only way to produce an escape character
is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I
don't like doing that. I want to be able to write an editor like
micro-emacs without having to have an #ifdef EBCDIC.

My conclusion is that I need to create a new type of terminal.

Having written code on EBCDIC-based mainframe systems for many years, and
with both hardcopy and video terminals for even more years, I gotta say,
you /are/ ambitious, aren't you.

Some things to think about (none of them C related)

1) EBCDIC is a "family" of related but slightly-differing charactersets.
While I believe that most of the EBCDIC control characters are common to
all of the EBCDIC charactersets, I don't remember the details. You should,
perhaps, specify /which/ EBCDIC you intend to deal with, and/or research to
determine that the control characters you select are common to the EBCDIC
charactersets you intend to work with.

2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
a "block oriented" device, taking a specific set of (already predefined)
commands, that are /nothing/ like the ANSI escape sequences you already
know. On such a terminal, each printing position is paired with a second,
control, octet, which governs the form and function of that position
(readable, writable, colour, intensity, etc.) Terminals are read and
written screen at a time (up to 4000 characters at a time (80x25x2),
including the non-data "status line", depending on those paired control
bytes). The equivalent to the ANSI "clear screen" escape sequence is a
full screen block (80x25) of non-rereadable blanks.

3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
clear the screen. It does not guarantee the cursor position. Alternatively,
a series of ASCII "line feed" characters will also clear such a screen,
again without guarantee of cursor position. Neither is acceptable on a
hardcopy terminal.

4) I seriously doubt that you will actually "create a new type of terminal".
Is hardware your specialty? And do you have a market? You probably mean
that you want to write some sort of "terminal emulator". This isn't easy,
but it isn't difficult either. You /do/ need a hardware terminal to target
to; you need something to display on, and you have to build your emulator
to interpret input and write or read on the hardware.

5) This seems all to 1990's for me. You are running at least 30 years behind
the times; this has all been done before, many times over. Perhaps you need
to look into prior art.

HTH

 

[Eric Sosman]

[...] Which computers did C90 have
in mind when they left out the escape character,
but included a vertical tab?

I don't know "which computers," specifically, the Committee
was concerned about. According to the Rationale, though:

"Proposals to add '\e' for ASCII ESC ('\033') were not
adopted because other popular character sets have no obvious
equivalent (see §6.4.4.4.)"

and

"The C89 Committee considered proposals to add the character
constant '\e' to represent the ASCII ESC ('\033') character.
This proposal was based upon the use of ESC as the initial
character of most control sequences in common terminal driving
disciplines such as ANSI X3.64. However, this usage has no
obvious counterpart in other popular character codes such as
EBCDIC."

At least some versions of EBCDIC feature a control character
named ESC, and I think you can safely assume the Committee was aware
of this. I do not know their reasons for declaring that EBCDIC/ESC
was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
a character-set expert. On the evidence at hand, neither are you.

 

[Lew Pitcher]

On Tuesday 23 October 2012 20:29, in comp.lang.c,

At least some versions of EBCDIC feature a control character
named ESC, and I think you can safely assume the Committee was aware
of this. I do not know their reasons for declaring that EBCDIC/ESC
was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
a character-set expert.

And neither am I. But, long ago, I dealt with characterset issues as part of
my job.

ISTM that, in ASCII, the use of the ESC character has mutated from the
original "characterset selector" (as in ISO 2022) used to select which
glyphs would activate following an SO or SI control character to a more
generic purpose that includes format effectors (like display controls and
cursor positioning controls) and vendor-specific extensions.

OTOH, IBM control characters have never strayed very far from their BSC and
3270 roots, and didn't seem to have any use for ESCape as a characterset
selector (using their "GE" Graphic Escape for that purpose - see the "3270
Data Stream Programmer's Reference" and others for details). AFAIK, there
was no teleterminal use for the EBCDIC ESCape character at all.

 

[Keith Thompson]

3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
clear the screen.

[...]

That doesn't seem to be the case.

I haven't used an ASCII-based *terminal*, as opposed to a terminal
emulator, in years. But most terminal emulators, and probably
most actual terminals, are VT-100 compatible -- and a form feed
character, as far as I can tell, doesn't clear the screen. In the
several emulators I've tried, it either does nothing or moves the
cursor down one line.

A working clear-screen sequence is "^[[H^[[2J", where "^[" denotes the
ASCII Escape character.

The comp.lang.c FAQ <http://www.c-faq.com/>, in question 19.4, says that
form-feed "will cause some displays to clear".

(Incidentally, a commonly suggested portable solution is to print enough
newlines to scroll everything of the top of the display. Drawbacks of
this approach are: (1) it's hard to tell how many newlines are needed;
(2) the cursor is left at the bottom of the screen, and (3) text can
still be seen by scrolling up, which is a problem if you want to erase
sensitive information.)

 

[kerravon]

On Wednesday, October 24, 2012 11:29:28 AM UTC+11, Eric Sosman wrote:

A truly great response - thanks Eric!

"The C89 Committee considered proposals to add the character
constant '\e' to represent the ASCII ESC ('\033') character.
This proposal was based upon the use of ESC as the initial
character of most control sequences in common terminal driving
disciplines such as ANSI X3.64. However, this usage has no

The exact situation I face.

obvious counterpart in other popular character codes such as
EBCDIC."

of this. I do not know their reasons for declaring that EBCDIC/ESC
was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
a character-set expert. On the evidence at hand, neither are you.

I am using as reference the IBM S/370 reference summary
4th edition dated November 1976 (ie more than a decade
before C90).

It has an ESC at position x'27'.

I have never seen an EBCDIC ESC used for anything though.

I wonder what it all means?

BFN. Paul.

 

[Edward A. Falk]

Hello folks.

According to the 1990 C standard (which is what I wish to code to), there is no "escape"
character. So the only way to produce an escape character is to harcode its ASCII or
EBCDIC value (x'1b'/x'27' respectively). I don't like doing that. I want to be able to
write an editor like micro-emacs without having to have an #ifdef EBCDIC.

The 60's just called, and they want their technology back. Wait, no,
they say you can keep it.

Seriously? I could hardly follow that, but it looked like you want
to redefine the ASCII control characters to support some sort of
EBCDIC compatibility.

 

[Eric Sosman]

On Wednesday, October 24, 2012 11:29:28 AM UTC+11, Eric Sosman wrote:

A truly great response - thanks Eric!


The exact situation I face.



I am using as reference the IBM S/370 reference summary
4th edition dated November 1976 (ie more than a decade
before C90).

It has an ESC at position x'27'.

I have never seen an EBCDIC ESC used for anything though.

Perhaps that's why the C89 Committee didn't deem EBCDIC/ESC
an "obvious counterpart" to ASCII/ESC: The fact that two control
codes have the same three-letter name doesn't mean they have
similar or even comparable significance. An EBCDIC table on
Wikipedia lists 001B as the "Unicode equivalent" of EBCDIC ESC,
meaning that whoever prepared the table thought there was a
correspondence, but perhaps the C89 Committee deemed Wikipedia
an insufficiently authoritative source. (At the time, they
probably also considered Wikipedia too new to be trusted.

I wonder what it all means?

One thing I think it means is that if you want to drive
X3.64 terminals from EBCDIC-based systems, you'd better find
out from those systems' experts how it's done. It's possible
that system software would notice \x27 being written and say
"Hey, that's an EBCDIC ESC, and I happen to know it's going to
an X3.64 device that expects ASCII ESC; I'll send \x1B instead."
But it seems more likely that the system would provide some
kind of curses-like facility, allowing the application to be
mostly unaware of the type of terminal hardware in use. The
abstract model presented by such a library (assuming it exists)
would be a candidate for your "terminal designed for C."

 

[Keith Thompson]

According to the 1990 C standard (which is what I wish to code to),
there is no "escape" character. So the only way to produce an escape
character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
respectively). I don't like doing that. I want to be able to write an
editor like micro-emacs without having to have an #ifdef EBCDIC.

[...]

One of C's greatest strengths it the ability to use it to write
*non-portable* code.

If you need to use the ASCII Escape character, just write:

#define ESCAPE '\x1b'

If you need the EBCDIC Escape character (assuming that it's actually
useful, and that EBCDIC defines it usefully):

#define EBCDIC_ESCAPE '\x27'

If you need one or the other, depending on the environment, this might
work:

#if '0' == 48
#define ESCAPE '\x1b' /* ASCII */
#else
#define ESCAPE '\x27' /* EBCDIC */
#endif

except that, according to N1370 6.10.1p4:

Whether the numeric value for these character constants matches
the value obtained when an identical character constant occurs
in an expression (other than within a #if or #elif directive)
is implementation-defined.

If it works for the compiler(s) you're using, that's probably good
enough. If not, you'll need to find some other way to determine whether
the target uses ASCII or EBCDIC.

I don't like doing that. I want to be able to write an
editor like micro-emacs without having to have an #ifdef EBCDIC.

My advice: grit your teeth and write "#ifdef EBCDIC". Portable code is
good, all else being equal -- but in this case all else is not equal.

 

[Lew Pitcher]

On Wednesday 24 October 2012 05:59, in comp.lang.c, (e-mail address removed) wrote:

[snip]

I am using as reference the IBM S/370 reference summary
4th edition dated November 1976 (ie more than a decade
before C90).

Gak! You get a peek at a generic EBCDIC from the "yellow card"
(the "Reference Summary"), you really cannot use that as a reference for
programming for EBCDIC-based terminals.

What the OP needs is something like the "3270 Data Stream Programmers
Reference" available at publibz.boulder.ibm.com (see [1] below for the
overlong URL) that describes exactly how to interact programmatically with
the "standard" IBM EBCDIC-based terminal.

It has an ESC at position x'27'.

I have never seen an EBCDIC ESC used for anything though.

I wonder what it all means?

It likely is so that EBCDIC-based systems could properly converse with
ASCII-based systems and devices through a simple EBCDIC-to-ASCII
translation table. EBCDIC program sends EBCDIC ESC, which the translator
translates to an ASCII ESC, and the end ASCII device/program reads as an
ESC. IBM didn't seem to ascribe a meaning to the ESC character other
than "escape" in any document I've read.

[1] "3270 Data Stream Programmers Reference"
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7P4000/CCONTENTS?DT=19920626112004

 

[kerravon]

Having written code on EBCDIC-based mainframe systems for many years, and
with both hardcopy and video terminals for even more years, I gotta say,
you /are/ ambitious, aren't you.

I've been doing other similar changes to the mainframe
platform, like making the RDW come through in RECFM=VB
when opened in binary mode, and reading and writing NL
characters to RECFM=U in text mode. This is a divergence
from how IBM did it. I think IBM got it wrong.

1) EBCDIC is a "family" of related but slightly-differing charactersets.
While I believe that most of the EBCDIC control characters are common to
all of the EBCDIC charactersets, I don't remember the details. You should,
perhaps, specify /which/ EBCDIC you intend to deal with, and/or research to
determine that the control characters you select are common to the EBCDIC
charactersets you intend to work with.

This one is easy - the Yellow Card has the definitive
reference.

2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
a "block oriented" device, taking a specific set of (already predefined)
commands, that are /nothing/ like the ANSI escape sequences you already
know. On such a terminal, each printing position is paired with a second,
control, octet, which governs the form and function of that position

I am roughly familiar with the 3270 data stream, and as
per original post, I don't want a 3270 data stream. I'm
trying to implement micro-emacs. So a new terminal type
is required.

3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
clear the screen. It does not guarantee the cursor position. Alternatively,
a series of ASCII "line feed" characters will also clear such a screen,
again without guarantee of cursor position. Neither is acceptable on a
hardcopy terminal.

I am specifically dealing with an ANSI X3.64 terminal (or
close), which is not required or designed to react to the
form feed.

4) I seriously doubt that you will actually "create a new type of terminal".
Is hardware your specialty? And do you have a market? You probably mean
that you want to write some sort of "terminal emulator". This isn't easy,
but it isn't difficult either. You /do/ need a hardware terminal to target
to; you need something to display on, and you have to build your emulator
to interpret input and write or read on the hardware.

I wish to posit the existence of an EBCDIC-equivalent of
an ANSI X3.64 terminal, which I will then drive from the
EBCDIC application.

5) This seems all to 1990's for me. You are running at least 30 years behind
the times; this has all been done before, many times over. Perhaps you need
to look into prior art.

If it has been done many times over, and given that
micro-emacs is open source, where can I download a
pre-compiled micro-emacs binary for MVS?

Regarding being 1990s - I am not yet satisfied that
1990s has been done properly. There are computer
systems in existence where a computer programmer
does not even have C90 available. Only very recently
(2011) has a free C90 compiler been made available
on every commercial platform, the last nail in the
coffin being z/VSE. Now that C90 is a universal
language for computers, the next thing bugging me is
a universal editor. When I was complaining about the
different editors on the different systems circa
1988, somebody told me I was in desperate need of
micro-emacs. I went and got micro-emacs for MSDOS
and still use it today (well, Windows command line
version anyway). But I don't have it for the
mainframe. I'm willing to replace MVS with PDOS if
that's what it takes to get micro-emacs working on
the mainframe.

BFN. Paul.

 

[Eric Sosman]

I've been doing other similar changes to the mainframe
platform, like making the RDW come through in RECFM=VB
when opened in binary mode, and reading and writing NL
characters to RECFM=U in text mode. This is a divergence
from how IBM did it. I think IBM got it wrong.


This one is easy - the Yellow Card has the definitive
reference.

Pfui. There's a green card somewhere in a box in my attic.
Vintage 1968 or thereabouts.

 

[Lew Pitcher]

I've been doing other similar changes to the mainframe
platform, like making the RDW come through in RECFM=VB
when opened in binary mode, and reading and writing NL
characters to RECFM=U in text mode. This is a divergence
from how IBM did it. I think IBM got it wrong.


This one is easy - the Yellow Card has the definitive
reference.

Only if you are dealing with (IIRC) IBM-1047 EBCDIC. It doesn't cover the
other EBCDICs, like EBCDIC-US or EBCDIC-INT, although these variants share
many common codepoints with the EBCDIC documented on the Yellow Card.

I am roughly familiar with the 3270 data stream, and as
per original post, I don't want a 3270 data stream. I'm
trying to implement micro-emacs. So a new terminal type
is required.

Then, why worry about EBCDIC at all? Programs running on modern IBM systems
can use ASCII (under the POSIX subsystem), and can talk to ASCII devices
using TCP/IP. The only case I can think of where you'd /want/ to talk
EBCDIC is when your code talks to an EBCDIC-based terminal device, and that
pretty much requires you to talk 3270 data stream (there aren't any other
EBCDIC terminals to speak of).

But, this is your project. I expect that you know what you are doing wrt
talking EBCDIC.

I am specifically dealing with an ANSI X3.64 terminal (or
close), which is not required or designed to react to the
form feed.

So, an external EBCDIC-to-ASCII translation layer? And the target program
(on an EBCDIC machine) talks EBCDIC to the translation layer, letting that
layer talk ASCII to the target terminal? OK, sounds cumbersome, but OK.

WRT an EBCDIC version of your program, it sounds like the translation layer
will have to translate outbound EBCDIC FF characters into the proper
ASCII "clear screen and reset cursor" ANSI sequence. That's ok; the
translation layer will need some intelligence; interpreting escape
sequences and such (does x'270c' represent a nonprintable, nonactionable
character, followed by a formfeed, or does it represent a two character
escape sequence that does something other than formfeed?). Of course,
that's your decision as well.

I wish to posit the existence of an EBCDIC-equivalent of
an ANSI X3.64 terminal, which I will then drive from the
EBCDIC application.

OK, a new type of terminal emulator, then. One that uses EBCDIC characters
but acts like an ANSI x3.64 terminal. But, my point was that terminals need
a physical existence; a "screen" on which to display characters, and
a "keyboard" from which to retrieve characters to send to the mainframe.
Are you building a new ANSI x3.64 terminal, one that uses EBCDIC instead of
ASCII, or are you front-ending an existing terminal with an EBCDIC-to-ASCII
translator? The simpler approach would be to build the translator, and use
someone else's X3.64 terminal (or software terminal), but you /could/
actually be building a complete software terminal, or (heaven forbid) a
complete hardware terminal. A much harder task.

If it has been done many times over, and given that
micro-emacs is open source, where can I download a
pre-compiled micro-emacs binary for MVS?

Hmmmmm.... I've been out of the mainframe world for a few years, but I can
guess....

How about http://www.jasspa.com/download.html, compiled and run under either
a Linux LPAR or the Unix System Services component of MVS. It should work;
IBM's been supporting Unix on MVS since the late 1990's, and MVS-managed
Linux since the early 2000s.

Other than that, there are a number of commercial sites who offer (or
offerred) Unix programs for MVS; Mortice Kern used to offer such, although
they seem to be out of business now.

Heck, even IBM offers emacs free for MVS (zOS, actually)
http://www-03.ibm.com/systems/z/os/zos/features/unix/tools/

Regarding being 1990s - I am not yet satisfied that
1990s has been done properly.

Amen to that, brother.

There are computer
systems in existence where a computer programmer
does not even have C90 available.

I feel your pain. Once, I tried to get a Perl CPAN package installed on a
development AIX box without a C compiler. I couldn't even convince them to
install GCC, and had to develop my solution on a Linux-based laptop
instead.

Only very recently
(2011) has a free C90 compiler been made available
on every commercial platform, the last nail in the
coffin being z/VSE.

I used to work (System Programmer) on DOS/VSE, VSE/SP, and VSE/ESA. I moved
on before it became z/VSE.

Now that C90 is a universal
language for computers, the next thing bugging me is
a universal editor. When I was complaining about the
different editors on the different systems circa
1988, somebody told me I was in desperate need of
micro-emacs. I went and got micro-emacs for MSDOS
and still use it today (well, Windows command line
version anyway). But I don't have it for the
mainframe. I'm willing to replace MVS with PDOS if
that's what it takes to get micro-emacs working on
the mainframe.

Luck be with you, my friend. If you've got a C compiler on that mainframe,
and a copy of emacs or microemacs source code, you shouldn't have too much
trouble getting it up and running against existing ASCII terminals. If your
MVS supports USS or a POSIX subsystem, you may even have a termcap or
terminfo to handle the terminal management heavy lifting for you.

If you /have/ to work with an EBCDIC compiler, then stick with the EBCDIC
variant that /it/ knows; the IBM C compiler I used 10 years ago only knew
EBCDIC-CP-US (which /isn't/ the Yellow Card EBCDIC).

As for your program, you could just use C macros defined in header files,
and provide header files based on the platform you are compiling on.
One "charset.h" file for ASCII-based platforms, and a totally different
one, defining the same macros, but with different values, for EBCDIC-based
systems. Your code just uses the macro ccESC (for instance), and leaves the
header to define it as 0x27 or 0x1b, depending on which version of the
header file you #included.

 

[kerravon]

Only if you are dealing with (IIRC) IBM-1047 EBCDIC. It doesn't cover the
other EBCDICs, like EBCDIC-US or EBCDIC-INT, although these variants share
many common codepoints with the EBCDIC documented on the Yellow Card.

I am happy to use the character set defined by GCCMVS,
which was basically copied from IBM C/370.

Then, why worry about EBCDIC at all? Programs running on modern IBM systems
can use ASCII (under the POSIX subsystem), and can talk to ASCII devices
using TCP/IP.

For the purpose of this conversation, I hate ASCII and
love EBCDIC. I don't want anything ASCII to be involved
in any step of the process. EBCDIC was invented before
ASCII, and C90 is the language of choice for EBCDIC
machines. Fantastic S/370 code is generated by the
EBCDIC C90 compilers (there are several to choose from,
and they all produce great code).

The only case I can think of where you'd /want/ to talk
EBCDIC is when your code talks to an EBCDIC-based terminal device, and that
pretty much requires you to talk 3270 data stream (there aren't any other
EBCDIC terminals to speak of).

For the purposes of this conversation, back in 1990 I was the
CEO of both General Electric and General Motors, and I told
IBM that if they didn't deliver me a character-mode terminal
that recognized the sequence x'27', x'ad', x'f2', x'd1'
(ESC [ 2 J), that I would take my business to Amdahl instead.
IBM delivered me such a terminal (dubbed PANSY) as requested,
and as a bonus it has some switches I can set on. Switch 1
will interpret x'0c' (FF) as identical to x'27'. Switch 2 will
interpret x'0b' (vertical tab) as identical to x'27'. Neither
switch is currently on, and I'm after advice from "the internet"
as to whether to switch either or both on.

I also raised a "please explain what you were smoking" to
the X3J11 committee when I saw them write "there is no
escape in EBCDIC", but I think the letter might have got
lost as I still haven't received a reply.

So, an external EBCDIC-to-ASCII translation layer?

For the purposes of this conversation, there is no ASCII
device in sight. If someone hands me an ASCII machine,
locks me in a room, and says "ha ha, no more EBCDIC", I'll
download Hercules, which emulates whatever hardware you
want it to, including but not limited to the S/370 processor.

ASCII "clear screen and reset cursor" ANSI sequence. That's ok; the
translation layer will need some intelligence; interpreting escape
sequences and such (does x'270c' represent a nonprintable, nonactionable
character, followed by a formfeed, or does it represent a two character

x'270c' = x'2727' = x'0c0c' = x'0c27'. I am not aware of
any ANSI X3.64 or PANSY escape sequence that involves two
escape characters in a row, and I guess the result of doing
so would be classified as "undefined".

OK, a new type of terminal emulator, then. One that uses EBCDIC characters
but acts like an ANSI x3.64 terminal. But, my point was that terminals need
a physical existence; a "screen" on which to display characters, and
a "keyboard" from which to retrieve characters to send to the mainframe.
Are you building a new ANSI x3.64 terminal, one that uses EBCDIC instead of
ASCII, or are you front-ending an existing terminal with an EBCDIC-to-ASCII
translator? The simpler approach would be to build the translator, and use
someone else's X3.64 terminal (or software terminal), but you /could/
actually be building a complete software terminal, or (heaven forbid) a
complete hardware terminal. A much harder task.

From both the application (micro-emacs) or from the
operating system (MVS or PDOS) perspective, I don't
see that it makes any difference. However, if it does
make a difference, then for the purposes of this
conversation I am good friends with Bill Gates (read:
I have some photos of him in a compromising position
with a sheep), and he has agreed to manufacture the
hardware terminal of my dreams.

Hmmmmm.... I've been out of the mainframe world for a few years, but I can
guess....
How about http://www.jasspa.com/download.html, compiled and run under either
a Linux LPAR or the Unix System Services component of MVS. It should work;
IBM's been supporting Unix on MVS since the late 1990's, and MVS-managed
Linux since the early 2000s.
Other than that, there are a number of commercial sites who offer (or
offerred) Unix programs for MVS; Mortice Kern used to offer such, although
they seem to be out of business now.
Heck, even IBM offers emacs free for MVS (zOS, actually)
http://www-03.ibm.com/systems/z/os/zos/features/unix/tools/

I don't wish to run an alien operating system like Linux,
especially not ASCII. Nor do I want to use USS. I want to
use the real MVS interface to drive it, not an emulator.
MVS is 20 million lines of assembler code. I'm sure it
knows how to drive a character mode terminal, e.g. the
2741.

http://en.wikipedia.org/wiki/IBM_2741

I feel your pain. Once, I tried to get a Perl CPAN package installed on a
development AIX box without a C compiler. I couldn't even convince them to
install GCC,

Terrible! What was their objection to having a free C
compiler made available to them?

I used to work (System Programmer) on DOS/VSE, VSE/SP, and VSE/ESA. I moved
on before it became z/VSE.

Cool. Were you aware that DOS/VS is available to the
hobbyist community? That's how I managed to build GCCVSE.

Luck be with you, my friend. If you've got a C compiler on that mainframe,
and a copy of emacs or microemacs source code, you shouldn't have too much
trouble getting it up and running against existing ASCII terminals. If your
MVS supports USS or a POSIX subsystem, you may even have a termcap or
terminfo to handle the terminal management heavy lifting for you.
If you /have/ to work with an EBCDIC compiler, then stick with the EBCDIC
variant that /it/ knows; the IBM C compiler I used 10 years ago only knew
EBCDIC-CP-US (which /isn't/ the Yellow Card EBCDIC).

Do you remember a code point that was different? I don't
remember seeing any code point differing from the yellow
card.

As for your program, you could just use C macros defined in header files,
and provide header files based on the platform you are compiling on.
One "charset.h" file for ASCII-based platforms, and a totally different
one, defining the same macros, but with different values, for EBCDIC-based
systems. Your code just uses the macro ccESC (for instance), and leaves the
header to define it as 0x27 or 0x1b, depending on which version of the
header file you #included.

That's a very good idea, and satisfies my technical requirement
of not having to do a #ifdef EBCDIC. However, I'd still like to
know the underlying technical reason as to why there's no \e
for ESC. For that matter I'd also like to know whether there
should be escapes for other characters, like ctrl-a for
micro-emacs beginning of line. Will that work in EBCDIC?

Thanks. Paul.

 

[BartC]

For the purpose of this conversation, I hate ASCII and
love EBCDIC.

Yet your message was posted in ASCII ... ?

 

[kerravon]

Yet your message was posted in ASCII ... ?

I was careful to restrict my message to characters
that were available in EBCDIC.

BFN. Paul.