RFC338 EBCDIC/ASCII Mapping for Network RJE

0338 EBCDIC/ASCII Mapping for Network RJE. R.T. Braden. May 1972. (Format: TXT=11494, PS=2386987, PDF=1871020 bytes) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

Network Working Group                                        R.T. Braden
Request for Comments: 338                                       UCLA/CCN
NIC: 9931                                                    17 May 1972

                  EBCDIC/ASCII MAPPING FOR NETWORK RJE


A. INTRODUCTION

   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.


THE EBCDIC CHIMERA

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

   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, exclamation point, and
   quotation).

C. CHARACTER MAPPING IN NETRJS

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

      Efficiency:

      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.

      Usability:

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

          ~                 

          \                 





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
          the Network.  In that case, the Network user needs to have all
          ASCII characters, including the mavericks, uniquely mapped
          into EBCDIC in some (standard) manner.

      2. The present mapping is convenient only if a user at an AT&T
          Model 33/35 Teletype (or simulator thereof) needs a different
          mapping for ease of use.

   For the first case, we have changed the mapping of the 6 maverick
   ASCII characters from "?", using instead Winett's rules III (c) and
   III (d):


      ASCII             EBCDIC
      -----             ------
        [                X'AD'
        ]                X'BD'
        {                X'8B'
        }                X'9B'
        ^                X'71'
        `                X'79'

   For the user with a Model 33/35 Teletype, we have expanded the set of
   virtual remote batch terminal types, adding "TTY" to "ASCII" and
   "EBCDIC".  A user establishes his virtual remote batch terminal as
   type TTY by either doing his initial ICP to socket 15 (vs. 11 for
   EBCDIC, 13 for ASCII), or by doing an ICP to Socket 1 and entering
   the command "TTYRJS" (vs. "RJS" for EBCDIC, "ARJS" for ASCII).  The
   mapping used by NETRJS for a TTY remote is:





Braden                                                          [Page 3]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972


   Model 33          Corresponding
   Graphic               ASCII               EBCDIC
   --------          -------------           ------
      \                   \                   

                ^                     |

              _                     _

      [                   [                  

      ]                   ]                   X'BD'

   This is ugly, but it is probably the best we can do.

D. CONCLUSIONS

   It is obvious that one pair of translation tables won't do the job;
   NETRJS needs (at least) two mappings for each direction.  How long
   will it be before an important set of users appears with a different
   terminal character set, requiring yet a different mapping? [6] An rje
   server site needs to be prepared to provide a variety of translation
   tables, and perhaps to allow a user to specify his own table(s); this
   mini-subset of "Date Reconfiguration Service" might be necessary to
   prevent translation-table-proliferation.  The tendency in Network
   discussions has been to put the burden upon the user sites to adapt
   to different conventions.  In the real world of users and servers,
   the server will often have to do the adapting.

NOTES AND REFERENCES

      [1] R.T. Braden, Interim NETRJS Specifications, RFC #189 (NIC
          #7133), July 15, 1971.

      [2] Please note that "RJS" is the proper name of a particular rje
          package written at CCN the generic name for remote batch
          service is "rje".

      [3] Notice that the mapping question discussed in this RFC is
          significant only for the virtual card reader and printer
          connections in NETRJS.  The punch connection is always
          transparent, i.e., never translated.  The remote operator
          connections use the extended EBCDIC/ASCII mapping including
          the maverick characters, but this is not important since
          operator commands require only a limited character set.

      [4] Joel Winett, "_The_ EBCDIC Codes and their Mapping to ASCII",
          RFC #183 (NIC #7127), July 21, 1971.



Braden                                                          [Page 4]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972


      [5] Winett lists only 88 basic EBCDIC graphics, excluding the
          space which he regards as a control character.  This is a
          matter of taste, but we find it less confusing to include the
          space as a graphic.

      [6] CCN recently received a new Teletype-replacement terminal.
          This machine has a bastardized graphic character set -- mostly
          ASCII, with a sprinkling of both (!) EBCDIC and TTY.


              +-------------------------------------+
              |                          Full ASCII |
              | a b ... z  | ` ^ { }  ~             |
              |                                     |
        +-----+-------------------------------------+--------------+
        |33/35|                                     |   AT&T TWX   |
        |     |          `   [   ]                  | (Mod 33/35   |
        |     |                                     |      tty)    |
 +------+-----+------+-----------------------+      |              |
 |Basic |     |      |                       |      |              |
 |EBCDIC|     |      |                   |      |              |
 |      |     |   "  |     A B ... Z         |      |  |
 |      |     |   !  |     0 1 ... 9         |      |              |
 |      |     |      |     + - * / ( )       |      |    |
 |      |     |      |     . , ' =           |      |              |
 |      |     |      |     $ &               |      |              |
 |      |     |      |   < > : ? % # @       |      |              |
 |      |     |      |                       |      |              |
 |      +-----+------+-----------------------+------+--------------+
 |            |      |                       |      |
 |            |      |        _              |      |
 |            |      |                       |      |
 |            +------+-----------------------+------+
 |                   |                       |
 |                   | PL/1    |   |
 |                   |  Set                  |
 |                   +-----------------------+
 |                                |
 |  Basic EBCDIC                             |
 +-------------------------------------------+

               Figure 1.  Character Sets Commonly Abused

[This RFC is also available in .PS and .PDF format.]

        [This RFC was put into machine readable form for entry]
    [into the online RFC archives by Helene Morin, Viagenie, 12/99]




Braden                                                          [Page 5]

RFC 338           EBCDIC/ASCII MAPPING FOR NETWORK RJE          May 1972





















































Braden                                                          [Page 6]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

文字コード表(Unicode UTF-8 UTF-16) [21420/21420]

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る