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

NETWORK RJE İÇİN EBCDIC/ASCII EŞLEMESİ

A. GİRİŞ

NETRJS [1], CCN'in Ağ rje protokolü [2] kapsamında, sanal bir uzak yığın terminali EBCDIC veya ASCII olabilir. CCN, tüm normal işlemlerini EBCDIC ile gerçekleştiren bir IBM 360/91 işletmektedir. Sanal bir ASCII terminali NETRJS'e oturum açtığında, CCN "kart okuyucu" akışını EBCDIC'e çevirir ve "yazıcı" akışını tekrar ASCII'ye çevirir [3].

Son aylarda, birçok ASCII ana bilgisayarı (RAND PDP-10, Utah PDP-10, Illinois PDP-11) NETRJS için kullanıcı süreçlerini tamamlamıştır. Bu sitelerdeki bazı kullanıcılar, NETRJS'te başlangıçta uygulanan ASCII/EBCDIC eşleme kurallarındaki yetersizlikleri fark etmiştir. İtirazları yerinde olduğundan, mevcut eşlemeyi değiştirdik ve yeni bir eşleme ekledik.

Bu RFC'nin üç amacı vardır:

1. NETRJS'in tüm kullanıcılarını değiştirilmiş ASCII eşlemesi konusunda bilgilendirmek.
2. Bu sorunu Network RJE Protocol Committee'nin dikkatine sunmak.
3. Bu alandaki öncü çalışmaları için Joel Winett'in çalışmalarını [4] kabul etmek ve desteklemek.

B. EBCDIC KİMERASI

Bir yıl önce, Joel Winett RFC #183'ü yayımlayarak EBCDIC'in gerçekte ne anlama geldiğine dair titiz araştırmasının sonuçlarını sundu. Tüm EBCDIC sitelerine bir çağrıda bulunarak, bir Ağ standartları eşlemesi tanımlamak üzere birlikte çalışmayı önerdi. O dönemde CCN olarak, EBCDIC (!) bir kullanıcı sitesi olan RAND'e hizmet vermek amacıyla NETRJS protokolünün zamanında uygulanmasına yoğunlaşmıştık; bu nedenle onun çabalarına yeterince destek veremedik.

RFC #183 değerli bir belgedir; umarız bir kopyası Armonk'a ulaşır. RFC #183'ten açıkça görüldüğü üzere, EBCDIC standart ("temel") bir karakter kümesinin, üst üste binen çeşitli ad-hoc karakter oluşumlarıyla birleşiminden oluşur. Neyse ki, özel amaçlı metin dizgi programları hariç tutulursa, IBM 360 programları yalnızca RFC #183'te ve Şekil 1'de gösterilen 89 "temel" EBCDIC grafiklerini kullanır [5].

Bir IBM 029 "EBCDIC" tuşlu delgi makinesi 63 grafik üretebilir: 89 temel EBCDIC grafiğinden 26 küçük harf çıkarıldığında kalanlar. Aslında OS/360 daha da küçük bir EBCDIC alt kümesi gerektirir; yaygın olarak "PL/1 karakter kümesi" olarak adlandırılan 60 karakter. PL/1 kümesi, 89 temel grafikten 26 küçük harfin yanı sıra <cent sign>, ! ve " olmak üzere üç grafiğin (sent işareti, ünlem işareti ve tırnak işareti) çıkarılmasıyla elde edilir.

C. NETRJS'TE KARAKTER EŞLEMESİ

Şimdi NETRJS veya herhangi bir rje protokolü için ASCII/EBCDIC eşlemesinin gereksinimlerini ele alıyoruz. Bu gereksinimler şunlardır:

Verimlilik

Çeviri karakterden karaktere olmalıdır; böylece CPU işlemi olan "translate" kullanılabilir ve karakter taramalarına gerek kalmaz. Bu önemlidir, çünkü rje işlemleri sırasında önemli miktarda karakter verisi taşınabilir.

Kullanılabilirlik

1. 89 EBCDIC grafiğinin tamamı karşılık gelen ASCII karakterlerine eşlenmelidir.
2. Eşleme mümkün olduğunca saydam olmalıdır; yani her iki kümede de aynı grafik bulunduğunda, kendisine eşlenmelidir.
3. EBCDIC odaklı bir programcının uyum çabasını en aza indirmek için, ASCII grafikleri aynı olmadıkları durumlarda karşılık gelen EBCDIC grafiğini çağrıştırmalıdır.

Bu değerlendirmeler, Winett'in II(a) ve III(b) kurallarını (RFC #183'ün 4. sayfasına bakınız) NETRJS'e dahil etmemize yol açtı:

Bu, 89 temel EBCDIC grafiğinin tamamını ASCII cinsinden tanımlar. Ancak EBCDIC'te bulunmayan ve yukarıdaki listede yer almayan altı "başına buyruk" ASCII karakterinin (`[]{}^``) nasıl eşleneceği sorusu hâlâ vardır.

CCN kullanıcılarının yalnızca EBCDIC kullanan normal 360 programlarını yazmak ve çalıştırmakla ilgilendiği ve bu başına buyruk ASCII grafiklerinden birini yalnızca hata sonucu girecekleri görüşünü benimseyebilirdik (ve benimsedik). Bu nedenle başlangıçtaki tercihimiz, girişteki başına buyrukları EBCDIC soru işaretlerine eşlemekti. Ayrıca, bir kullanıcının temel 89'dan daha geniş bir EBCDIC alt kümesine erişmesi gerekiyorsa, bunu rje işlemini doğrudan EBCDIC ile yaparak gerçekleştirmesi gerektiğini varsaydık.

Şimdi, özgün eşleme kurallarında iki eksiklik olduğunu fark ediyoruz:

1. 360 programı, Ağ'dan gelen ASCII metni işlemek üzere tasarlanmış olabilir. Bu durumda, Ağ kullanıcısının başına buyruklar da dahil olmak üzere tüm ASCII karakterlerinin EBCDIC'e bir şekilde (standart bir biçimde) benzersiz olarak eşlenmesi gerekir.
2. Mevcut eşleme, yalnızca AT&T Model 33/35 Teletype (veya bunun bir benzetimi) kullanan bir kullanıcının kullanım kolaylığı için farklı bir eşlemeye ihtiyaç duyması durumunda elverişlidir.

Birinci durum için, altı başına buyruk ASCII karakterinin ? yerine aşağıdaki gibi eşlenmesini, Winett'in III(c) ve III(d) kurallarını kullanarak değiştirdik:

Model 33/35 Teletype kullanan kullanıcı için, sanal uzak yığın terminali türleri kümesini genişlettik; ASCII ve EBCDIC'e ek olarak TTY'yi ekledik. Bir kullanıcı sanal uzak yığın terminalini TTY türü olarak, ya ilk ICP'sini soket 15'e yaparak (EBCDIC için 11, ASCII için 13) ya da soket 1'e bir ICP yapıp TTYRJS komutunu girerek (EBCDIC için RJS, ASCII için ARJS) tanımlar. NETRJS'in bir TTY uzak terminali için kullandığı eşleme şöyledir:

Bu çirkindir, ancak muhtemelen yapabileceğimizin en iyisi budur.

D. SONUÇLAR

Tek bir çeviri tablo çiftinin işi görmeyeceği açıktır; NETRJS'in her yön için (en azından) iki eşlemeye ihtiyacı vardır. Farklı bir terminal karakter kümesine sahip ve bambaşka bir eşleme gerektiren önemli bir kullanıcı grubunun ortaya çıkması ne kadar sürecek? [6]

Bir rje sunucu sitesinin çeşitli çeviri tabloları sağlamaya hazır olması ve belki de bir kullanıcının kendi tablo(lar)ını belirtmesine izin vermesi gerekir; "Veri Yeniden Yapılandırma Hizmeti"nin bu mini alt kümesi, çeviri tablosu çoğalmasını önlemek için gerekli olabilir. Ağ tartışmalarındaki eğilim, yükü farklı kurallara uyum sağlamak üzere kullanıcı sitelerinin üzerine koymak yönünde olmuştur. Kullanıcılar ve sunucuların gerçek dünyasında ise, uyum sağlamak çoğu zaman sunucunun yapmak zorunda kalacağı bir iştir.

NOTLAR VE KAYNAKLAR

1. R. T. Braden, Interim NETRJS Specifications, RFC #189 (NIC #7133), 15 Temmuz 1971.
2. Lütfen "RJS"'nin CCN'de yazılmış belirli bir rje paketinin özel adı olduğunu unutmayın; uzak yığın hizmetinin genel adı "rje"dir.
3. Bu RFC'de tartışılan eşleme sorusunun, NETRJS'teki sanal kart okuyucu ve yazıcı bağlantıları için anlamlı olduğunu unutmayın. Delgi (punch) bağlantısı her zaman saydamdır; yani asla çevrilmez. Uzak operatör bağlantıları, başına buyruk karakterleri de içeren genişletilmiş EBCDIC/ASCII eşlemesini kullanır; ancak bu önemli değildir, çünkü operatör komutları yalnızca sınırlı bir karakter kümesi gerektirir.
4. Joel Winett, "The EBCDIC Codes and their Mapping to ASCII", RFC #183 (NIC #7127), 21 Temmuz 1971.
5. Winett, boşluğu bir denetim karakteri olarak gördüğü için yalnızca 88 temel EBCDIC grafiğini listeler. Bu bir tercih meselesidir, ancak boşluğu bir grafik olarak dahil etmenin daha az kafa karıştırıcı olduğunu düşünüyoruz.
6. CCN kısa süre önce Teletype'ın yerini alan yeni bir terminal aldı. Bu makine, çoğunlukla ASCII olan, ancak hem (!) EBCDIC hem de TTY'den serpiştirilmiş öğeler içeren melez bir grafik karakter kümesine sahiptir.

Şekil 1. Sıklıkla Kötüye Kullanılan Karakter Kümeleri

[Tam ASCII, AT&T TWX (Model 33/35 TTY),
Temel EBCDIC ve PL/1 karakter kümesi arasındaki örtüşmeleri gösteren şekil;
<space>, harfler, rakamlar, noktalama işaretleri, <bent bar>, <cent sign>,
<left arrow> ve <up arrow> gibi grafikleri içerir.]

Bu RFC .PS ve .PDF formatlarında da mevcuttur.

Bu RFC, çevrimiçi RFC arşivlerine giriş için Helene Morin, Viagenie tarafından 12/99 tarihinde makine tarafından okunabilir biçime dönüştürülmüştür.