EBCDIC/ASCII Mapping for Network RJE
RFC 338

Document Type RFC - Unknown (May 1972; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf ps html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 338 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        R.T. Braden
Request for Comments: 338                                       UCLA/CCN
NIC: 9931                                                    17 May 1972



   Under NETRJS [1], CCN's Network rje protocol [2], a virtual remote
   batch terminal may be either EBCDIC or ASCII.  CCN operates an IBM
   360/91 which performs all of its normal processing in EBCDIC.  When a
   virtual ASCII terminal signs onto NETRJS, CCN translates the "card
   reader" stream to EBCDIC and translates the "printer" stream back to
   ASCII [3].

   In recent months, a number of ASCII hosts (RAND PDP-10, Utah PDP-10,
   Illinois PDP-11) have completed user processes for NETRJS.  Several
   users at these sites have noted deficiencies in the ASCII/EBCDIC
   mapping rules originally implemented in NETRJS.  Since their
   objections were well founded, we have altered the existing mapping
   and added a new one.

   This RFC has three purposes:

      (1) to make all users of NETRJS aware of the changed ASCII mapping

      (2) to call this problem to the attention of the Network RJE
          Protocol Committee

      (3) to knowledge and support Joel Winett's pioneering work [4] in
          this area.


   A year ago, Joel Winett Published RFC #183, containing the results of
   his careful research into just what EBCDIC really means.  He sounded
   a clarion call for all EBCDIC sites to join in defining a Network
   standards mapping.  At this time, we at CCN were primarily absorbed
   in the timely implementation of the NETRJS protocol to serve an
   EBCDIC (!) user site, RAND, so we were not very supportive of his

   RFC #183 is a valuable document; we hope a copy falls into the hands
   of Armonk.  It is clear from RFC #183 that EBCDIC consists of a
   standard ("basic") set of characters, combined with a number of
   overlapping ad-hoc character happenings.  Fortunately, if we exclude

Braden                                                          [Page 1]
RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

   special-purpose text composition programs, IBM 360 programs use only
   the 89 "basic" EBCDIC graphics [5] shown in RFC #183 as well as in
   Figure 1.  An IBM 029 "EBCDIC" keypunch can create 63 graphics: the
   89 basic EBCDIC graphics less the 26 lower case letters.  In fact,
   OS/360 requires an even smaller subset of EBCDIC, 60 characters
   commonly called the "PL/1 character set".  The PL/1 set consists of
   the 89 basic graphics, less the 26 lower case letters as well as the
   three graphics <cent sign>!" (cent sign, exclamation point, and


   We consider now the requirements of a ASCII/EBCDIC mapping for NETRJS
   or any rje protocol.  These requirements are as follows:


      The translation should be character-to-character, so that the CPU
      operation "translate" can be used and character scans obviated.
      This is important because a significant volume of character data
      may be moved during rje operations.


      (1) All of the 89 EBCDIC graphics should be mapped into
          corresponding ASCII characters.

      (2) The mapping should be as nearly transparent as possible, i.e.,
          whenever the same graphic appears in both sets, it should map
          onto itself.

      (3) To minimize the adaptation required of an EBCDIC-oriented
          programmer, the ASCII graphics should evoke the corresponding
          EBCDIC graphic, when they are not identical.

   Theses considerations led us to incorporate Winett's rules II (a) and
   III (b) (see page 4 of the RFC #183) into NETRJS:

        ASCII                EBCDIC
        -----                ------
          |                     |

          ~                 <bent bar>

          \                 <cent sign>

Braden                                                          [Page 2]
RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972

   This defines all 89 basic EBCDIC graphics in terms of ASCII.
   However, there is still a question of how to map the 6 "maverick"
   ASCII characters ( []{}^` ) which are not in EBCDIC and not in the
   list above.

   We could (and did) take the view that all CCN users are concerned
   only with writing and executing normal 360 programs using EBCDIC and
   that they would enter one of the maverick ASCII graphics only in
   error.  Our original choice, therefore, was to map the mavericks in
   the input into EBCDIC question marks.  We also assumed that, if a
   user needs to access a larger subset of EBCDIC than the basic 89, he
   should do so by doing his rje directly in EBCDIC.

   We now realize that there were two deficiencies in the original
   mapping rules.

      1. The 360 program may be intended to manipulate ASCII text from
Show full document text