RFC 338 (rfc338) - Page 1 of 6
EBCDIC/ASCII Mapping for Network RJE
Alternative Format: Original Text Document
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