← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 407 · network

UZAK İŞ GİRİŞİ PROTOKOLÜ

Yazar
Kurum
Tarih
16 Ekim 1972
Durum
Network Working Group Yorum Talebi
Kanal
network/

(16 Ekim 1972)

RFC 407 NIC 12112

Robert Bressler, MIT-DMCG
Richard Guida, MIT-DMCG
Alex McKenzie, BBN-NET

RFC 360’ın Yerine Geçer

UZAK İŞ GİRİŞİ PROTOKOLÜ

Uzak İş Girişi Protokolü
(16 Ekim 1972)
RFC 407 NIC 12112

GİRİŞ

Uzak iş girişi, bir konumdaki bir kullanıcının, başka bir konumda toplu işleme tabi bir işin çalıştırılmasını sağlamasına olanak veren mekanizmadır. Bu protokol, böyle bir kullanıcının Ağ üzerinden uzak bir toplu işleme sunucusu ile iletişim kurarak, bu sunucunun bir iş-girdi dosyasını almasını, işi işlemesini ve işin çıktı dosya(lar)ını uzak bir konuma iletmesini sağlayan Ağ standart yordamlarını tanımlar. Protokol, kullanıcı ile sunucu RJE süreçleri arasındaki tüm denetim iletişimi için bir TELNET bağlantısı (soket 1 değil, özel olarak standartlaştırılmış bir kaydediciye) kullanır. Sunucu tarafı daha sonra iş-girdi dosyasını almak ve çıktı dosya(lar)ını iletmek için Dosya Aktarım Protokolü’nü kullanır.

İki tür kullanıcı vardır: doğrudan kullanıcılar (kişiler) ve kullanıcı süreçleri. Doğrudan kullanıcı, bir TIP’e ya da herhangi bir ana makineye bağlı etkileşimli bir terminalden iletişim kurar. Bu kullanıcı, girdinin ve/veya çıktının belirtilen ana makinede belirli bir soket üzerinden alınmasını/gönderilmesini sağlayabilir (örneğin, bir TIP üzerindeki kart okuyucular veya yazıcılar için) ya da dosyaların Dosya Aktarım Protokolü kullanılarak dosya kimliği ile aktarılmasını sağlayabilir. Diğer kullanıcı türü ise, bir uzak ana makinedeki bir RJE Kullanıcı-sürecinin başka bir ana makinedeki RJE Sunucu-süreci ile iletişim kurmasıdır. Bu tür kullanıcı, nihai olarak talimatlarını bir insan kullanıcıdan alır, ancak tanımlanmamış dolaylı bir yol üzerinden. Bu protokolün komut ve yanıt akışları, hem insan kullanıcı hem de kullanıcı süreci tarafından kolayca kullanılacak ve yorumlanacak şekilde tasarlanmıştır.

Belirli bir kullanıcı sitesi, her mantıksal iş için TELNET denetim bağlantısını kurmayı seçebilir ya da denetim bağlantısını uzun süreler boyunca açık bırakabilir. Denetim bağlantısı açık bırakılırsa, birden fazla iş-dosyası alınacak şekilde yönlendirilebilir ya da isteğe bağlı olarak (girdi akışından bir mantıksal işin sonunu belirleyebilen ve tek bir girdi dosyasından birden fazla iş oluşturabilen sunucular için) tek bir sürekli alım yapılabilir (bir TIP kart okuyucudan olduğu gibi). Bu durumda, TELNET bağlantısının bir “iş izleyici” olarak hizmet verdiği, belirli bir sunucuya bağlı bir “sıcak” kart okuyucu oluşur. Çıktı her zaman çıktı soketine bağlantı başına iş bazında aktarıldığından, bu “sıcak” okuyucudan gelen çıktı hazır olduğunda, bir “sıcak” yazıcıya geliyormuş gibi görünür. Daha karmaşık ana makineler için başka bir olasılık da, bir RJE Kullanıcı-sürecini bir kart okuyucuya bağlamak ve bir öncü denetim kartından talimatlar alarak, uygun ana makineye uygun oturum açma ve girdi alma komutlarıyla bir RJE denetim TELNET’inin açılmasını sağlamaktır. Bu kart okuyucu, insan kullanıcıya bir Ağ “sıcak” kart okuyucu olarak görünür. Bu RJE Kullanıcı-sürecinin ayrıntıları bu protokolün kapsamı dışındadır.

GENEL ÖZELLİKLER

Kullanıcı

Gerçek bir terminaldeki bir insan kullanıcı ya da bir işin uzaktan gönderilmesine neden olan komut denetim akışını sağlayan bir süreç, Kullanıcı olarak adlandırılacaktır. Bir süreç kullanıcısının talimatlarını alma yöntemi bu protokolün kapsamı dışındadır.

Kullanıcı TELNET

Kullanıcı, komutlarını Ağ üzerinden Ağ Sanal Terminali kodu ile, Kullanıcının Ana Makinesindeki bir Kullanıcı TELNET süreci aracılığıyla iletir. Bu Kullanıcı TELNET süreci, istenen RJE-sunucu Ana Makinesindeki standart “RJE Logger” soketine (soket 5) ICP aracılığıyla etkinliğini başlatır.

RJE-Sunucu TELNET

RJE-sunucu süreci, komut akışını TELNET kanalı üzerinden alır ve yanıt akışını sunucu ana makinedeki bir RJE-sunucu TELNET süreci aracılığıyla gönderir. Bu süreç, “RJE Logger” soketinde ICP’yi dinlemeli (ve uygun ICP soket kaydırmasını sağlamalıdır).

TELNET Bağlantısı

RJE mekanizması için komut ve yanıt akışları, geçerli NWG TELNET protokolüne göre tam özelliklere sahip, özel bir sokete yapılan TELNET benzeri bir bağlantı üzerinden sağlanır.

RJE-Sunucu

RJE-Sunucu süreci, Uzak Toplu İş Girişi hizmeti sağlayan Ana Makinede bulunur. Bu süreç, RJE-sunucu TELNET’ten girdi alır, “oturum açma” yordamı üzerinden erişimi denetler, girdi iş dosyalarını alır, işleri toplu işleme sistemi tarafından çalıştırılmak üzere kuyruğa alır, durum sorgularına yanıt verir ve mevcut olduğunda iş çıktı dosyalarını iletir.

Kullanıcı FTP

Tüm girdi ve çıktı dosyaları, RJE-sunucu sürecinin kendi inisiyatifiyle denetimi altında aktarılır. Bu dosyalar, belirli bir Ana Makine/sokete Bağlantı-İsteği yoluyla doğrudan aktarılabilir ya da Dosya Aktarım Protokolü kullanılarak aktarılabilir. İkinci yöntem kullanılırsa, RJE-sunucu aktarımı gerçekleştirmek için yerel Kullanıcı FTP süreci aracılığıyla hareket eder. Bu süreç, yabancı ana makinedeki “FTP Logger”a etkin bir Bağlantı-İsteği ile etkinliğini başlatır.

Sunucu FTP

Uzak bir ana makinedeki (RJE-sunucudan uzak) bu süreç, Kullanıcı FTP’den gelen bir ICP’yi dinler ve ardından Kullanıcı FTP’den gelen komutlara göre uygun dosya aktarımını gerçekleştirir.

FTP

RJE dosyaları için Dosya Aktarım Protokolü kullanıldığında, geçerli NWG FTProtocol tarafından tam olarak tanımlanan standart FTP mekanizması kullanılır.

RJE Komut Dili

RJE sistemi, Kullanıcıdan TELNET bağlantısı üzerinden gelen; kullanıcının kimliğini (oturum açma), iş girdi dosyasının kaynağını, işin çıktı dosyalarının durumunu, iş durumu hakkında sorgulama yapmayı, iş durumunu ya da çıktı durumunu değiştirmeyi belirten bir komut akışı ile denetlenir. Çıktı durumunu etkileyen ek komutlar iş girdi dosyasına dahil edilebilir. Bu komut dili, bu protokolün ilerleyen bir bölümünde açıkça tanımlanmıştır.

RJE Komut Yanıtları

Kullanıcıdan TELNET üzerinden girilen her komut, RJE-sunucunun TELNET bağlantısı üzerinden Kullanıcıya bir yanıt iletmesini gerektirir. Bazı diğer koşullar da bir yanıt iletisini gerektirir. Bu iletiler, hem insan Kullanıcılar hem de Kullanıcı süreçleri tarafından yorumlamayı kolaylaştırmak için standart bir biçimde düzenlenmiştir. Bu protokolün ilerleyen bir bölümünde yanıt iletileri tanımlanmaktadır.

TELNET BAĞLANTISI ÜZERİNDEN RJE KOMUTLARI

GENEL KABULLER

  1. Komutların her biri, standart TELNET “crlf” ile sonlandırılmış tek bir girdi satırı içinde yer alacaktır. Satır, kullanıcının istediği herhangi bir uzunlukta olabilir (açıkça, fiziksel bir terminal satır genişliği ile sınırlı değildir). “cr” ve “lf” karakterleri, açıkça “crlf” sırası dışında RJE-sunucu tarafından yok sayılacaktır ve yerel terminal denetimi için gerektiğinde kullanılabilir.

  2. Tüm komutlar, tanınan bir komut adıyla başlayacak ve ardından tanınan sözdizimsel öğe dizgeleri ile serbest biçimli değişken dizgeleri (kullanıcı kimliği, dosya kimlikleri vb. için) içerebilir. Tanınan sözcükler, alfasayısal dizgelerden (harfler ve rakamlar) veya noktalama işaretlerinden oluşur. Tanınan alfasayısal dizge öğeleri, birbirlerinden ve tanınmayan dizgelerden en az bir boşluk ya da sözdizimsel olarak izin verilen bir noktalama işareti ile ayrılmalıdır. Diğer boşluklar, herhangi bir sözdizimsel öğeden önce veya sonra istenildiği gibi serbestçe kullanılabilir (“boşluk” burada ASCII SPACE (sekizlik 040) anlamına gelir; biçimsel olarak: <blank>::= <blank><ASCII SPACE> | <ASCII SPACE>; dolayısıyla, <blank> yerine birden fazla SPACE dizisi de kabul edilebilir, ancak birden fazla olmasına sözdizimsel bir gereklilik yoktur). OUT ve CHANGE dışındaki tüm komutlarda, komut adından sonraki “=” isteğe bağlıdır.

  3. Tanınan alfasayısal dizgeler, sözdizimsel bir ayrım olmaksızın büyük harfler veya küçük harfler ya da her ikisinin herhangi bir karışımını içerebilir. Tanınmayan dizgeler, sonradan dizgeyi kullanan ana makine aksi yönde tanımlamadıkça, büyük/küçük harf ayrımı tam olarak korunarak, sunulduğu şekliyle kullanılacaktır.

  4. Tanınmayan dizgelerin iki türü vardır: son ve gömülü. Son dizgeler, bir komutun son sözdizimsel öğesi olarak görünür ve girdi akışındaki bir sonraki boşluk olmayan karakterden başlayıp “crlf”ten önceki son boşluk olmayan karaktere kadar uzanacak şekilde ayrıştırılır.

Gömülü dizgeler, OUT, CHANGE ve ALTER komutlarındaki “job-id” ve “job-file-id” alanlarını içerir. Şu anda bu alanlar sınırlandırılmadan bırakılacaktır, çünkü bunların yalnızca sunucu ana makine tarafından tanınması gerekir ve umarız ki kendi iş kimliklerini ve dosya adlarını tanıyabilir.

SÖZDİZİM

Aşağıdaki komut açıklamaları BNF sözdiziminde verilmiştir. Köşeli ayraçlar içindeki adlar, izleyen sözdizimsel denklemlerde açılan, terminal olmayan sözdizimsel öğelerdir. Her denklemde, tanımlanan ad solda ::=’nin solunda, alternatif tanımlar kümesi ise sağda ve dikey çizgiler | ile ayrılmış olarak yer alır.

YENİDEN BAŞLAT

REINIT

Bu komut, kullanıcıyı RJE-sunucuya başarılı bir bağlantıdan hemen sonraki, TELNET bağlantısı üzerinden herhangi bir komut göndermeden önceki durumla özdeş bir duruma getirir. Etkili olarak yapılan işlem, bir ABORT ve tüm GİRDİ, ÇIKTI ve KİMLİK bilgilerinin temizlenmesidir. Doğal olarak, kullanıcı REINIT komutundan önce oluşan tüm kullanım ücretlerinden sorumlu olmaya devam eder. TELNET bağlantısı hiçbir şekilde etkilenmez.

USER

User = <user-id>

Bu komut, yeni bir TELNET bağlantısı üzerinden gönderilen ilk komut olmalıdır. Bu nedenle, bir “oturum açma” dizisini başlatır. Bu komuta verilen yanıt aşağıdakilerden biridir:

  1. Kullanıcı kodu hatalı.
  2. Parola girin (kullanıcı kodu geçerliyse).
  3. Oturum açma tamam, devam edin (parola istenmiyorsa).

Kullanıcı, kullanıcıyı değiştirmek için herhangi bir zamanda başka bir USER komutu gönderebilir. Sonraki girdiler yeni kullanıcıya faturalandırılacaktır. Bir sunucu, mevcut durumunda işleyemeyecekse (örneğin, girdi dosyası aktarımı sırasında) yeni bir USER komutunu kabul etmeyi reddedebilir, ancak protokol, önceki etkinliği değiştirmeden USER komutuna her zaman izin verir. Hatalı bir sonraki USER komutu ya da onu izleyen PASS komutu, hata yanıtı ile birlikte yok sayılacak ve özgün Kullanıcı oturumda kalacaktır.

Bir sunucunun, ilk USER/PASS komutları sunucu tarafından belirlenen bir süre içinde tamamlanmazsa TELNET bağlantısını kapatması kabul edilebilirdir. “Oturum açmış” Kullanıcının kullanıcı kimliğinin, dosya aktarımı veya iş yürütme için kullanılan kimlik olması gerekli ya da ima edilen bir durum değildir; bu kimlik yalnızca komut akışını göndereni tanımlar. Sunucular, kullanıcı kimliği ile iş yürütme kullanıcısı arasındaki ilişkiyi, İş veya Çıktı değiştirme komutları için kendi kurallarına göre belirleyecektir.

Başarılı bir “oturum açma”, her zaman önceki tüm Girdi veya Çıktı varsayılan parametrelerini (INID vb.) temizler.

PASS

Pass = <password>

Bu komut, bir USER komutunu hemen izler ve “oturum açma” yordamını tamamlar. Belirli bir Sunucu parola gerektirmese ve USER komutundan sonra zaten “oturum açma tamam” yanıtını vermiş olsa bile, her Sunucu bir PASS komutuna izin vermeli (ve gerekirse yok saymalıdır) ve oturum açma tamamlanmışsa bunu “oturum açma tamam” ile onaylamalıdır.

BYE

BYE

Bu komut, bir Kullanıcıyı sonlandırır ve RJE sunucusundan TELNET bağlantısını kapatmasını ister. Girdi aktarımı sürmüyorsa, TELNET bağlantısı hemen kapatılabilir; girdi aktarımı sürüyorsa, bağlantı sonuç yanıtı için açık kalmalı ve ardından kapatılmalıdır. Bu ara sürede, yeni bir USER komutu (ve başka hiçbir komut) kabul edilebilir.

TELNET bağlantısının beklenmedik şekilde kapanması, sunucunun ABORT ve BYE etkili işlemlerini gerçekleştirmesine neden olur.

INID / INPASS

INID = <user-id>
INPASS = <password>

Belirtilen kullanıcı kimliği ve parola, girdi dosyasını almak için yapılan Dosya Aktarım isteğinde gönderilecektir. Bu parametreler Sunucu tarafından başka hiçbir şekilde kullanılmaz. Bu komut görünmezse, USER/PASS parametreleri kullanılır.

INPATH / INPUT

INPATH = <file-id>
INPUT = <file-id>
INPUT

NOT: Aşağıdaki sözdizim, çıktı için de kullanılacaktır.

<file-id>      ::= <host-socket> | <host-file>
<host-socket> ::= <host>,<socket><attributes> |
                  <socket><attributes>
   <host> bölümünün olmaması, Kullanıcı-sitesi ana makinesini ifade eder
<host>        ::= <integer>
<socket>      ::= <integer>

UZAK İş Girişi Protokolü

(16 Ekim 1972)
RFC 407
NIC 12112


<integer>      ::= D<decimal-integer> | O<octal-integer> | H<hexadecimal-integer>
<host-file>   ::= <host><attributes>/<pathname>
<attributes>  ::= <empty> | :<transmission><code>
<transmission>::= <empty> | T | A | N
<code>         ::= <empty> | E
<pathname>     ::= <dosyanın bulunduğu sitedeki FTP Sunucusu tarafından tanınan herhangi bir dizge>

Aktarım Seçenekleri

Kod Seçenekleri


<file-id> sözdizimi, girdi veya çıktı için belirli bir dosya kaynağını ya da hedefini belirtmeye yönelik genel RJE mekanizmasıdır. <host-socket> biçimi kullanılırsa, RJE-Sunucu belirtilen <attributes> kullanılarak adlandırılan sokete doğrudan aktarım yapacaktır. <host-file> biçimi kullanılırsa, RJE-sunucu gerçek aktarımı yapmak üzere yerel FTP-kullanıcı sürecini çağırır. Bu kipteki veri akışı, TELNET benzeri ASCII ya da bloklu kayıtlar biçimindedir (birinci sütunu ASA satır denetimi için kullanabilir).

A kipi girdide izinli olsa da (birinci sütun silinir), olağan kip varsayılan N’dir. Çıktı, her kaydın ilk karakterinde satır denetimini sağlar ("boşluk" = tek boşluk, "1" = yeni sayfa vb.), isteğe bağlı N kipi ise yalnızca veriyi aktarır (bir kart delgecine olduğu gibi).

<pathname>, RJE-sunucu tarafından saklanan ve uygun dosyaları almak ya da depolamak üzere FTP-sunucuya FTP üzerinden geri gönderilen, tanınmayan keyfi bir dizgedir.

INPATH veya INPUT komutları, eğer sağlanmışsa önce belirtilen <file-id>’yi saklar ve ardından INPUT komutu girdiyi başlatır. INPATH adı, daha sonra girdi için bir dosya kimliği belirtmekte kullanılabilir ve dosya kimliği olmadan verilen INPUT komutu, daha önce belirtilmiş bir dosya kimliği üzerinden girdinin başlatılmasına neden olur. Önceden herhangi bir <file-id> belirtilmeden verilen bir INPUT crlf komutu geçersizdir.


ABORT

ABORT

Bu komut, sürmekte olan herhangi bir girdi alımını durdurur, halihazırda alınmış kayıtları atar ve alım bağlantısını kapatır.

Not: Parametreli ABORT bir Çıktı Aktarım denetimidir (aşağıya bakınız).


OUTUSER / OUTPASS

OUTUSER = <user-id>
OUTPASS = <password>

Belirtilen kullanıcı kimliği ve parola, çıktı dosya(lar)ını göndermek için yapılan Dosya Aktarım isteğinde gönderilecektir. Bu parametreler Sunucu tarafından başka hiçbir şekilde kullanılmaz. Bu komut görünmezse, USER/PASS parametreleri kullanılır.


OUT

OUT <out-file> = <disp>
<out-file>    ::= <empty> | <job-file-id>
<job-file-id>::= <Sunucu tarafından tanınan, işten gelen belirli bir çıktı dosyasını temsil eden dizge>

::= | (H) | (S) | (D)


- `<empty>`, işin birincil yazdırma dosyasını ifade eder
- `<empty>` yerleşimi Gönder ve ardından at anlamına gelir
- **(H)** yalnızca Beklet’i belirtir, gönderme
- **(S)** Gönder ve Kaydet’i belirtir
- **(D)** göndermeden atmayı belirtir

*Not:* Parantezler yukarıdaki öğelerin bir parçasıdır.

`<file-id>` ::= (INPUT komutu için olanla aynı)

Bu komut, iş tarafından üretilen çıktı dosyalarının yerleşimini belirtir. Belirtilmeyen dosyalar varsayılan olarak yalnızca Beklet olacaktır. OUTUSER, OUTPASS ve OUT komutlarının etkili olabilmesi için INPUT komutundan önce belirtilmesi gerekir. Bu komutlar, bu KULLANICI tarafından bu RJE-TELNET bağlantısı üzerinden gönderilen izleyen tüm işleri etkileyecektir. Belirli bir iş, giriş dosyasının başındaki NET denetim kartlarıyla bu komutların üzerine yazabilir.

Çıktı yerleşimi bu OUT komutu veya bir NET OUT kartı ile belirtildikten sonra, bilgi nihai çıktı yerleşimine kadar iş ile birlikte tutulur ve CHANGE komutu ile değiştirilebilir.

Bazı durumlarda sunucu, çıktının hedefinin “meşgul” olduğunu (yani Server-FTP’ye veya belirtilen sokete RFC’nin reddedildiğini) ya da çıktıyı alması gereken ana makinenin kapalı olduğunu saptayabilir. Bu durumlarda sunucu birkaç dakika beklemeli ve ardından yeniden göndermeyi denemelidir.

---

## OUTPUT RE-ROUTE

CHANGE =


Bu komut, iş gönderimi sırasında sağlanan çıktı yerleşimini değiştirir. `<job-id>`, RJE-sunucusu tarafından tanınır kabul edilir; sunucu, bu KULLANICININ belirtilen işi değiştirmeye yetkili olup olmadığını doğrulayabilir. İş tanımlandıktan sonra, diğer bilgiler özgün OUT komutuyla aynı sözdizimi ve anlamsal içeriğe sahiptir. CHANGE komutu, gönderim sırasında belirtilmemiş bir job-file-id için de verilebilir ve özgün bir OUT komutuyla aynı etkiye sahiptir.

---

## OUTPUT CONTROLS DURING TRANSMISSION


::= RESTART | RECOVER | BACK | SKIP | ABORT | HOLD


Bu komutlar sırasıyla şunları belirtir:

- İletimi yeniden başlat (yeni RFC vb.)
- Kurtar: son FTP Restart-marker-reply’den itibaren iletimi yeniden başlatır (FTP’ye bakın)
- Çıktıyı `count` blok geri al
- Çıktıyı `count` blok ileri atla
- Çıktıyı iptal et, at
- Çıktıyı iptal et, ancak Beklet

::= | ::= @ |


- `<empty>`, tanımlı olduğu yerlerde 1 anlamına gelir

::= (OUT komutu için olanla aynı) ::= (INPUT komutu için olanla aynı) ::= (INPUT komutu için olanla aynı) ::= <INP tamamlandığında sağlanan sunucu tarafından tanınan iş tanımlayıcısı> ::= <sunucu tarafından tanınan dosya tanımlayıcısı veya birincil yazıcı çıktısı>


Bu komutlar kümesi, devam eden ya da yakın zamanda iptal edilmiş çıktı iletimini değiştirir. Çıktı iletimi tamamlanmadan kesilirse, RJE-sunucusu ya dosyanın `<disp>` değeri Gönder-ve-at ise tüm dosyayı yeniden göndermeyi dener ya da `<disp>` **(S)** Gönder-ve-Kaydet ise dosyayı daha ileri Kullanıcı denetimi için Bekletir.

İletim sırasında, Gönder-ve-Kaydet’in Kaydet kısmı sırasında veya yalnızca Beklet olan bir dosya için, yukarıdaki komutlar iletimi denetlemek için kullanılabilir. `<what>`’ın `@<file-id>` biçimine yalnızca iletim gerçekten devam ediyorsa izin verilir.

Dosyanın durumu komutla tutarsızsa, komut geçersizdir ve yanıtla birlikte yok sayılır.

---

## STATUS

STATUS STATUS


Bu komutlar sırasıyla RJE-sunucusunun, belirli bir işin ya da bir çıktı veya girdi dosyasının iletiminin durumunu ister. Status yanıtının bilgi içeriği siteye bağlıdır.

---

## CANCEL / ALTER

CANCEL ALTER


Bu komutlar gönderilmiş bir işin seyrini değiştirir. CANCEL, işin derhal sonlandırılacağını ve tüm çıktının atılacağını belirtir. ALTER; iş önceliğinin değiştirilmesi, işlem sınırları, İptal etmeden Sonlandır gibi sistem bağımlı seçenekler sağlar.

---

## OP

OP (any string)


Belirtilen dize, Sunucunun toplu iş kuyruğundan izleyen herhangi bir iş başlatıldığında Sunucu sitesi operatörüne gösterilecektir. Bu komut genellikle giriş dosyasında bir NET OP denetim kartı olarak görünür, ancak bir TELNET komutu da olabilir. OP `crlf` komutu (metin sağlanmadan) ile tüm işler için geçerli bir komut olmaktan çıkarılır.

---

# RJE CONTROL CARDS IN THE INPUT FILE

Bazı RJE komutları, giriş dosyasının başındaki denetim kartlarıyla belirtilebilir. Bu denetimler görünürse, RJE-TELNET bağlantısı üzerinden verilen aynı komuta göre öncelik alırlar ve yalnızca bu belirli işi etkilerler. Bu RJE denetim kartlarının tümü işin giriş dosyasının ilk kayıtları olarak yer almalıdır. Hepsinde 1–3 sütunlarında **NET** denetim sözcüğü bulunur. 1–3 sütunlarında NET bulunmayan ilk kartla karşılaşıldığında bu denetimler için tarama durur.

Denetim komutları tekil kayıtlarda görünür ve kayıt sonu (genellikle 80 sütunluk kart görüntüsü) ile sonlandırılır. Bir sonraki kaydın 1–4 sütunlarında **NET+** görünmesiyle bir sonraki kayda devam etmeye izin verilir. Sonraki kaydın 5. sütunu, önceki kaydın son karakterini hemen izler.

NET OUTUSER = NET OUTPASS = NET OUT = NET OP


Ayrıntılar için ilgili TELNET komutuna bakın. TELNET bağlantısından mümkün olmayan ancak NET OUTUSER ve NET OUT denetimleriyle izin verilen bir seçenek, farklı OUT’lar için farklı OUTUSER’ların belirtilmesidir; çünkü TELNET yalnızca ilk bir OUTUSER’ı saklar ve sağlar, oysa denetimler her OUT denetimiyle karşılaşılmadan önce OUTUSER’ları değiştirebilir.

---

# RJE USE OF FILE TRANSFER PROTOCOL

TIP olmayan dosyaların çoğu, RJE-sunucusuna ya da sunucudan FTP süreci aracılığıyla aktarılacaktır. RJE-sunucusu, yerel FTP-kullanıcısını çağırarak istenen aktarımın Ana Makine, Dosya-yolu, Kullanıcı-kimliği, Parola ve Kip bilgilerini sağlar. FTP-kullanıcısı daha sonra belirtilen ana makinedeki FTP-sunucu karşılığına bağlanır ve bir aktarım yolu kurar.

Ardından veriler, Sunucu içindeki RJE-FTP arayüzü üzerinden, Ağ boyunca, yabancı FTP-sunucusundan ya da ona doğru ve sonra yabancı ana makinenin dosya depolama alanındaki belirtilen Dosya-yolundan ya da ona doğru akar. Çıktı dosyalarında, dosya-yolu yabancı ana makine tarafından bir yazıcıya yönlendirme talimatları olarak tanınabilir ya da dosya basitçe saklanabilir; bir Kullanıcı-RJE-süreci, kendi Server-FTP’si tarafından yazıcıya yönlendirme olarak tanınan bir çıktı `<file-id>`’sini varsayılan olarak sağlayabilir.

RJE-Sunucu/Kullanıcı-FTP arayüzünün birçok ayrıntısı siteye bağlı olsa da, RJE-Sunucuları tarafından standart bir şekilde kullanılacak birkaç FTP seçeneği vardır:

1. Aktarılacak her dosya için yeni bir FTP bağlantısı başlatılacaktır. Bağlantı, RJE Kullanıcısının sağladığı Kullanıcı-kimliği (OUTUSER veya INUSER) ve Parola ile açılacaktır.
2. Veri bayt boyutu 8 bit olacaktır.
3. FTP Tür, Yapı ve Kip parametreleri; RJE aktarım yönü (I/O) ile Kullanıcının sağladığı `<transmission>` ve `<code>` seçenekleri tarafından belirlenir:

I/O FTP-TYPE FTP-STRUCTURE FTP-MODE I* N - A R B I N E E R B I T - A F S I T E E F S I A - P R B I A E F R B

O* A - P R B O A E F R B O N - A R B O N E E R B O T - A F S O T E E F S

(* varsayılanı gösterir)


4. Kullanılacak hizmet komutları, girdi için Retrieve ve çıktı için Append (oluşturma ile) olacaktır. FTP yol adı, RJE Kullanıcısı tarafından sağlanan `<pathname>` olacaktır.
5. **B** biçimindeki çıktılarda, RJE-Sunucu sitesindeki Kullanıcı-FTP, periyodik aralıklarla (örneğin her 100 satırda) Restart-marker’lar gönderecek ve dosyayla birlikte en son Restart-marker-reply’yi hatırlayacaktır. Dosya aktarımı tamamlanmazsa ve `<disp>` **(S)** ise, dosya Kullanıcı müdahalesi beklenerek Bekletilecektir. Kullanıcı daha sonra RECOVER komutunu kullanarak son hatırlanan Restart-marker-reply’den bir FTP yeniden başlatması gerçekleştirebilir.
6. FTP Abort komutu, RJE ABORT ve CANCEL komutları için kullanılacaktır.
7. FTP-MODE’un **B** olarak tanımlandığı aktarımlarda, kullanıcı FTP isteğe bağlı olarak **H** kipini kullanmayı deneyebilir.

Bir RJE-Sunucu sitesinin kullandığı FTP komutlarının özel biçimi ve hangi sırayla kullanıldıkları bu protokolde belirtilmeyecektir.

# REMOTE Job Entry Protocol

*(16 Ekim 1972)*  
RFC 407 — NIC 12112

FTP tarafından karşılaşılan hatalar üç kategoriye ayrılır:

- **a)** erişim hataları veya depolama alanı yok hatası;
- **b)** komut biçimi hataları; ve
- **c)** aktarım başarısızlığı hataları.

Komutlar RJE-Sunucu süreci tarafından üretildiğinden, bir hata bir programlama problemidir ve dikkat için kayda alınmalı ve durum mümkün olduğunca güvenli biçimde ele alınmalıdır. Girdide iletim başarısızlığı veya erişim başarısızlığı, etkili bir **ABORT** ve kullanıcı bildirimiyle sonuçlanır. Çıktıda iletim başarısızlığı, `<disp>` değerine bağlı olarak **RESTART** veya **Save** ile sonuçlanır (**OUT** komutuna bakın). Çıktıda erişim başarısızlığı bir problemdir; çünkü Kullanıcı erişilebilir olmayabilir. Kendisi sorgulama yaparsa diye bir durum yanıtı onun için kuyruğa alınmalıdır; `<disp> = (S)` olan bir dosya **Bekletilmeli**; `<disp> = <empty>` olan Gönder-ve-at dosyası ise geçici olarak tutulmalı ve talep edilmezse ardından atılmalıdır.

“Geçici olarak” burada, özellikle Kullanıcıya büyük maliyetle çok hacimli çıktı üreten işler söz konusu olduğunda, kendisine haklı çıktısını geri alma için her fırsatın verilmesi gerektiğinden, en az birkaç gün anlamına gelir. Ancak sunucular, Bekletilen çıktının kapladığı dosya depolama alanı için Kullanıcıdan ücret almayı tercih edebilir.

---

## REPLIES OVER THE TELNET CONNECTION

TELNET komutlarının her birinin girişi dâhil olmak üzere RJE-sunucusunun her eylemi, TELNET bağlantısı üzerinden Kullanıcıya bildirilir. Bu RJE-sunucu yanıtları, İnsan veya Süreç tarafından yorumlanacak şekilde biçimlendirilmiştir. Başta üç haneli sayısal bir kod, ardından bir boşluk ve iletinin metinsel açıklaması bulunur.

Sayısal kodlar, RJE dışında (FTP gibi) diğer protokolleri de kapsaması umuduyla gelecekte genişletme için gruplar hâlinde atanmıştır. Sayısal kod, süreçler tarafından yorumlamayı kolaylaştıracak şekilde tasarlanmıştır. Kodun üç hanesi aşağıdaki gibi yorumlanır:

### Birinci Hane — Yanıt Türü

- **000**  
  Sunucu tarafından, sunucu sisteminin bazı durumlarını Kullanıcıya bildirmek amacıyla gönüllü olarak verilen, tamamen bilgilendirici yanıtlar.

- **100**  
  Belirli bir durum sorgusuna verilen yanıtlar. Bu yanıtlar hem bilgi sağlar hem de durum isteğinin alındığını bildirir.

- **200**  
  Önceki bir komut/isteğin olumlu onayı. **200** yanıtı, başka bir yorum gerektirmeyen komutlar için genelleştirilmiş bir “tamam”dır. Diğer 2xx yanıtları, belirli başarılı eylemler için tanımlanmıştır.

- **300**  
  Şu ana kadar eksik bilgi sağlanmıştır. Büyük bir problem yoktur, ancak belirtilen girdilerle etkinlik ilerleyemez.

- **400**  
  Başarısız yanıt. Bir istek doğru şekilde belirtilmiştir, ancak doğru şekilde tamamlanamamıştır. Sonraki denemeler Kullanıcı komutları gerektirecektir.

- **500**  
  Yanlış veya geçersiz komut. Komut ya da parametreleri sözdizimsel açıdan geçersiz veya eksiktir ya da komut önceki bir komutla tutarsızdır. Söz konusu komut tamamen yok sayılmıştır.

- **600–900**  
  Genişletme için ayrılmıştır.

### İkinci Hane — Yanıtın Konusu

- **x00–x29**  
  Diğer konulara atanamayan, genel amaçlı yanıtlar.

- **x30**  
  Birincil erişim. Bu yanıtlar, bir Sunucu hizmetine (RJE, FTP vb.) “oturum açma” girişimine ilişkindir.

- **x40**  
  İkincil erişim. Birincil Sunucu, ikincil bir hizmete erişebilme yeteneği hakkında yorum yapar (RJE, uzak bir FTP hizmetine oturum açmalıdır).

- **x50**  
  FTP sonuçları.

- **x60**  
  RJE sonuçları.

- **x70–x99**  
  Genişletme için ayrılmıştır.

### Üçüncü Hane — İleti Ayrıntısı

Son hane, belirli bir ileti türünü belirtir. Kod, bir otomaton sürecinin yorumlaması için tasarlandığından, bir yanıtın her varyasyonunun benzersiz bir numaraya sahip olması gerekli değildir; yalnızca temel anlamın benzersiz bir numaraya sahip olması yeterlidir. Bir yanıtın metni, yanıtın özel nedenini insan Kullanıcıya açıklayabilir.

Sunucudan gelen her TELNET satırı (`crlf` ile sonlanan), tek başına eksiksiz bir yanıt iletisi olacak şekilde tasarlanmıştır. Bir yanıtın metnini izleyen satırlara devam ettirmek gerekirse, bu devam yanıtları üç boşluktan oluşan özel yanıt kodunu içerir.

---

## Assigned RJE Reply Codes

- **000** Genel bilgi mesajı (günün saati vb.)
- **030** Sunucu kullanılabilirlik bilgisi
- **050** FTP yorum veya kullanıcı bilgisi
- **060** RJE veya Batch sistemi yorumu veya bilgisi
- **100** Sistem durumu yanıtı
- **150** Dosya durumu yanıtı
- **151** Dizin listeleme yanıtı
- **160** RJE sistemi genel durum yanıtı
- **161** RJE işi durum yanıtı
- **200** Son komut başarıyla alındı
- **201** İstenildiği gibi bir ABORT etkinliği sonlandırdı
- **202** ABORT isteği yok sayıldı, devam eden etkinlik yok
- **203** İstenen İletim Kontrolü yürürlüğe girdi
- **204** Bir REINIT komutu istenildiği gibi yürütüldü
- **230** Oturum açma tamamlandı
- **231** Oturum kapatma tamamlandı, hoşça kalın.
- **232** Oturum kapatma kaydedildi, aktarım bittiğinde tamamlanacak
- **240** Dosya aktarımı başladı
- **250** FTP Dosya aktarımı başarıyla başladı
- **251** FTP Yeniden Başlatma-İşaretleyici-Yanıtı  
  Metin: `MARK yyyy = mmmm`  
  burada `yyyy` veri akışı işaretleyici değeridir (sizinki) ve `mmmm` alıcının eşdeğer işaretidir (benimki)
- **252** FTP aktarımı başarıyla tamamlandı
- **253** Yeniden adlandırma tamamlandı
- **254** Silme tamamlandı
- **260** `<job-id>` işi işlenmek üzere kabul edildi
- **261** `<job-id>` işi tamamlandı, çıktı aktarımı bekleniyor
- **262** `<job-id>` işi istenildiği gibi iptal edildi
- **263** `<job-id>` işi istenildiği gibi `<status>` durumuna değiştirildi
- **264** `<job-id>,<job-file-id>` işi için iletim devam ediyor
- **300** Bağlantı karşılama mesajı, girdi bekleniyor
- **301** Mevcut komut tamamlanmadı (eğer `crlf` değilse, uygun bir gecikmeden sonra gönderilebilir)
- **330** Parolayı girin (gizli-girdi modu ile gönderilebilir)
- **360** INPUT hiçbir zaman bir INPATH belirtmedi
- **400** Bu hizmet uygulanmamıştır
- **401** Bu hizmet şu anda oturum açmayı kabul etmiyor, hoşça kalın.
- **430** Oturum açma süresi veya deneme sayısı aşıldı, hoşça kalın.
- **431** Oturum açma başarısız, kullanıcı ve/veya parola geçersiz
- **432** Kullanıcı bu hizmet için geçerli değil
- **434** Operatör işlemiyle oturum kapatıldı, lütfen siteyi arayın
- **435** Sistem problemi nedeniyle oturum kapatıldı
- **436** Hizmet kapatılıyor, hoşça kalın
- **440** RJE, girdi aktarımı için uzak FTP’ye oturum açamadı
- **441** RJE, FTP üzerinden belirtilen girdi dosyasına erişemedi
- **442** RJE, `<host-socket>` girdi bağlantısını kuramadı
- **443** RJE, çıktı teslimi için uzak FTP’ye oturum açamadı
- **444** RJE, çıktı için verilen dosya alanına erişemedi
- **445** RJE, `<host-socket>` çıktı bağlantısını kuramadı
- **450** FTP: Adı verilen dosya mevcut değil (veya erişim reddedildi)
- **451** FTP: Adı verilen dosya alanı SİZİN tarafınızdan erişilebilir değil
- **452** FTP: Aktarım tamamlanmadı, veri bağlantısı kapatıldı
- **453** FTP: Aktarım tamamlanmadı, yetersiz depolama alanı
- **460** İş girdisi tamamlanmadı, ABORT gerçekleştirildi
- **461** İş biçimi işleme için kabul edilebilir değil, iptal edildi
- **462** Daha önce kabul edilen iş gizemli biçimde kayboldu
- **463** Daha önce kabul edilen iş tamamlanmadı
- **464** STATUS, CANCEL, ALTER, CHANGE veya İletim Kontrolü tarafından başvurulan iş kimliği bilinmiyor (veya erişim reddedildi)
- **465** Belirtilen iş için İstek Değişikliği izinli değil
- **466** Teslim edilemeyen, sahiplenilmeyen `<job-id>` çıktısı atıldı
- **467** İstenen REINIT gerçekleştirilemedi
- **500** Son komut satırı tamamen tanınmadı
- **501** Son komutun sözdizimi hatalı
- **502** Son komut eksik, parametreler yok
- **503** Son komut geçersiz, yasa dışı parametre birleşimi
- **504** Son komut geçersiz, bu anda eylem mümkün değil
- **505** Son komut önceki komut(lar)la yasa dışı biçimde çakışıyor
- **506** İstenen eylem bu Sunucu tarafından uygulanmamış
- **507** `<job-id>` işi için son komut satırı tamamen tanınmadı
- **508** `<job-id>` işi için son komutun sözdizimi hatalı
- **509** `<job-id>` işi için son komut eksik, parametreler yok
- **510** `<job-id>` işi için son komut geçersiz, yasa dışı parametre birleşimi
- **511** `<job-id>` işi için son komut geçersiz, bu anda eylem imkânsız
- **512** `<job-id>` işi için son komut önceki komut(lar)la yasa dışı biçimde çakışıyor

---

## KOMUTLARIN VE YANITLARIN SIRALANMASI

Kullanıcı ile Sunucu arasındaki iletişimin dönüşümlü bir diyalog olması amaçlanmıştır. Buna göre, Kullanıcı bir RJE komutu gönderir ve Sunucu birincil yanıt istemiyle karşılık verir. Kullanıcı, ek komutlar göndermeden önce bu ilk başarı veya başarısızlık yanıtını beklemelidir.

İkinci tür bir yanıt, Kullanıcı komutlarına göre asenkron olarak Sunucu tarafından gönderilir. Bu yanıtlar, INPUT komutunun neden olduğu bir iş gönderiminin ilerleyişini rapor eder ve bu nedenle o komut için ikincil yanıtlar olarak kabul edilir.

Sunucu “yanıtları”nın son sınıfı tamamen bilgilendiricidir ve herhangi bir zamanda gelebilir. Bu “yanıtlar” aşağıda kendiliğinden olanlar olarak listelenmiştir.

---

## KOMUT–YANIT EŞLEŞME TABLOSU

| KOMUT | BAŞARI | BAŞARISIZLIK |
|--------|---------|---------|
| REINIT | 204 | 467, 500–505 |
| USER | 230, 330 | 430–432, 500–505 |
| PASS | 230 | 430–432, 500–505 |
| BYE | 231, 232 | 500–505 |
| INID | 200 | 500–505 |
| INPASS | 200 | 500–505 |
| INPATH | 200 | 500–505 |
| INPUT | 240 | 360, 440–442, 500–505 |
| ikincil girdi alma | 260 | 460, 461 |
| ikincil iş yürütme | 261 | 462, 463 |
| ikincil çıktı iletimi | — | 443–445, 466 |
| ABORT (girdi) | 201, 202 | 500–505 |
| OUTUSER | 200 | 500–505 |
| OUTPASS | 200 | 500–505 |
| OUT | 200 | 500–505 |
| CHANGE | 200 | 500–505 |
| RESTART / RECOVER / BACK / SKIP / ABORT (çıktı) / HOLD | 203 | 464, 500–506 |
| STATUS | 1xx, 264 | 460–465, 500–505 |
| CANCEL | 262 | 464, 500–506 |
| ALTER | 263 | 464, 465, 500–506 |
| OP | 200 | 500–505 |
| Kendiliğinden | 0xx, 300, 301 | 434–436 |

**Not:** Kartlar üzerinde görünen komutlar için ayrı bir hata kodları kümesi sağlanmıştır (507–512). Bu hata yanıtları asenkron olarak gönderildiğinden ve dolayısıyla kullanıcı mevcut işten sonra yeni bir iş göndermeye çalışıyorsa bazı karışıklıklara yol açabileceğinden, hata yanıtları hangi işin hatalı kart(lar)a sahip olduğunu belirtmelidir.

---

## TİPİK RJE SENARYOLARI

### HOSTX’e Sıcak Kart Okuyucu İsteyen TIP Kullanıcısı

1. TIP kullanıcısı HOSTX soket 5’e TELNET bağlantısı açar.
2. TELNET üzerinden RJE’ye gönderilen komutlar:

   - `USER=myself`
   - `PASS=dorwssap`
   - `OUT=H70002`
   - `INPUT=H50003`

3. RJE-sunucusu TIP’in aygıt 5’ine bağlanır ve okumaya başlar. İş-sonu kartı tanındığında, iş çalıştırılmak üzere kuyruğa alınır. Kart okuyucuya olan bağlantı, başka bir iş için daha fazla girdi almak üzere açık kalır.
4. İlk iş biter. TIP’in aygıt 7’sine RJE-sunucusu tarafından bir bağlantı kurulur ve çıktı bir NVT akışı olarak gönderilir.
5. 3. adımda başka bir deste ile istenilen zamanda devam edilir.

### İş-Başına-Bir Kart Okuyuculu TIP

1. 1’den 4’e kadar olan adımlar aynıdır, ancak Kullanıcı desteden sonra Okuyucu’yu kapatır.
2. Çıktı biter ve yazıcı bağlantısı kapanır.
3. 3. adım tamamlandıktan sonra INPUT herhangi bir zamanda yazılabilir ve başka bir iş 3. adımdan başlayarak girilir.

### HOSTA Kullanıcısı İşi HOSTC’de Çalıştırır, Girdi HOSTB’den

1. Kullanıcı RJE için HOSTC soket 5’e TELNET ile bağlanır:

   - `USER=roundabout`
   - `PASS=aaabbbc`
   - `OUTUSER=roundab1`
   - `OUT=:E/.sysprinter`
   - `OUT puncher=(S)HOSTB:NE/my.savepunch`
   - `INUSER=rounder`
   - `INPASS=x.x.x`
   - `INPUT=HOSTB:E/my.jobinput`

2. RJE-sunucusu, `my.jobinput` adlı dosya için `rounder` Kullanıcı kimliği ve `x.x.x` Parolası ile HOSTB’den girdiyi FTP aracılığıyla alır.
3. İş biter. RJE-sunucusu FTP kullanarak iki dosya gönderir: yazdırma çıktısı, ASA satırbaşı denetimi ile EBCDIC olarak `.sysprinter` dosyasına HOSTA’ya gönderilirken, `puncher` olarak bilinen dosya satırbaşı denetimi olmadan EBCDIC olarak `my.savepunch` dosyasına HOSTB’ye gönderilir.
4. Çıktılar bittiğinde, HOSTC’deki RJE-sunucusu yazdırma dosyasını atar ancak `puncher` dosyasını saklar.
5. İş gönderiminden sonra oturumu kapatmış olan Kullanıcı çıktısını almış ve HOSTB’deki `my.savepunch` dosyasını kontrol etmiştir. Kaydedilen kopyayı HOSTC’de silmek için HOSTC’de RJE’yi yeniden çağırır.

## Kullanıcı Kimlik Bilgileri

- **USER**: `roundabout`
- **PASS**: `aaabbbcc`

## İş Denetimi

- `ABORT job 123 puncher`

**veya**

- `CHANGE job 123 puncher = (D)`