terminal designed for C

Discussion in 'C Programming' started by kerravon, Oct 23, 2012.

  1. kerravon

    kerravon Guest

    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, Oct 23, 2012
    #1
    1. Advertising

  2. kerravon

    kerravon Guest

    On Tuesday, October 23, 2012 3:34:57 PM UTC+11, wrote:
    >
    > 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.
    kerravon, Oct 23, 2012
    #2
    1. Advertising

  3. kerravon

    Sjouke Burry Guest

    kerravon <> wrote in
    news::

    > 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.
    Sjouke Burry, Oct 23, 2012
    #3
  4. Sjouke Burry <s@b> writes:
    > kerravon <> wrote in
    > news::
    >> 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.


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

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 23, 2012
    #4
  5. kerravon

    kerravon Guest

    On Wednesday, October 24, 2012 7:16:57 AM UTC+11, Keith Thompson wrote:
    > Sjouke Burry <s@b> writes:
    >
    > > 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.


    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.
    kerravon, Oct 23, 2012
    #5
  6. kerravon

    Lew Pitcher Guest

    On Tuesday 23 October 2012 00:19, in comp.lang.c, wrote:

    > 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
    --
    Lew Pitcher
    "In Skills, We Trust"
    Lew Pitcher, Oct 23, 2012
    #6
  7. kerravon

    Eric Sosman Guest

    On 10/23/2012 6:46 PM, kerravon wrote:
    > [...] 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.

    --
    Eric Sosman
    d
    Eric Sosman, Oct 24, 2012
    #7
  8. kerravon

    Lew Pitcher Guest

    On Tuesday 23 October 2012 20:29, in comp.lang.c,
    d wrote:
    [snip]
    >
    > 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.

    --
    Lew Pitcher
    "In Skills, We Trust"
    Lew Pitcher, Oct 24, 2012
    #8
  9. Lew Pitcher <> writes:
    [...]
    > 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.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 24, 2012
    #9
  10. kerravon

    kerravon Guest

    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.
    kerravon, Oct 24, 2012
    #10
  11. In article <>,
    kerravon <> wrote:
    >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.

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
    Edward A. Falk, Oct 24, 2012
    #11
  12. kerravon

    Eric Sosman Guest

    On 10/24/2012 5:59 AM, kerravon wrote:
    > 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.


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

    --
    Eric Sosman
    d
    Eric Sosman, Oct 24, 2012
    #12
  13. kerravon <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Oct 24, 2012
    #13
  14. kerravon

    Lew Pitcher Guest

    On Wednesday 24 October 2012 05:59, in comp.lang.c, 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

    --
    Lew Pitcher
    "In Skills, We Trust"
    Lew Pitcher, Oct 24, 2012
    #14
  15. kerravon

    kerravon Guest

    On Wednesday, October 24, 2012 9:55:29 AM UTC+11, Lew Pitcher wrote:
    > 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.
    kerravon, Oct 25, 2012
    #15
  16. kerravon

    Eric Sosman Guest

    On 10/24/2012 7:10 PM, kerravon wrote:
    > On Wednesday, October 24, 2012 9:55:29 AM UTC+11, Lew Pitcher wrote:
    >> 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.


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

    --
    Eric Sosman
    d
    Eric Sosman, Oct 25, 2012
    #16
  17. kerravon

    Lew Pitcher Guest

    On Wednesday 24 October 2012 19:10, in comp.lang.c, wrote:

    > On Wednesday, October 24, 2012 9:55:29 AM UTC+11, Lew Pitcher wrote:
    >> 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.


    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.

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


    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.

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


    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.

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


    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.

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


    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.

    --
    Lew Pitcher
    "In Skills, We Trust"
    Lew Pitcher, Oct 25, 2012
    #17
  18. kerravon

    kerravon Guest

    On Thursday, October 25, 2012 12:15:21 PM UTC+11, Lew Pitcher wrote:
    > On Wednesday 24 October 2012 19:10, in comp.lang.c, wrote:
    > > 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 happy to use the character set defined by GCCMVS,
    which was basically copied from IBM C/370.

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


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

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


    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.

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


    > 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

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


    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.

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


    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.
    kerravon, Oct 25, 2012
    #18
  19. kerravon

    BartC Guest

    "kerravon" <> wrote in message
    news:...

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


    Yet your message was posted in ASCII ... ?

    --
    Bartc
    BartC, Oct 25, 2012
    #19
  20. kerravon

    kerravon Guest

    On Thursday, October 25, 2012 9:30:27 PM UTC+11, Bart wrote:
    > "kerravon" <> wrote in message
    >
    > > For the purpose of this conversation, I hate ASCII and
    > > love EBCDIC.

    >
    > Yet your message was posted in ASCII ... ?


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

    BFN. Paul.
    kerravon, Oct 25, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Skybuck Flying

    Ok cpu designed now what ? ;)

    Skybuck Flying, Aug 2, 2005, in forum: VHDL
    Replies:
    1
    Views:
    519
    Martin Thompson
    Aug 2, 2005
  2. Francis Shanahan

    "Cannot Be Designed" error

    Francis Shanahan, Jul 7, 2003, in forum: ASP .Net
    Replies:
    5
    Views:
    433
    Francis Shanahan
    Jul 8, 2003
  3. =?Utf-8?B?Um9iZXJ0?=
    Replies:
    0
    Views:
    446
    =?Utf-8?B?Um9iZXJ0?=
    Apr 6, 2004
  4. gaurav kashyap
    Replies:
    3
    Views:
    6,642
    Paul Boddie
    Oct 31, 2008
  5. Steve
    Replies:
    2
    Views:
    932
    edicionsdigitals.com edicions digitals xarxa socia
    Dec 7, 2010
Loading...

Share This Page