Decsystem-20 Na Uniwersytecie Columbia (1977-1988)

Source: http://www.columbia.edu/cu/computinghistory/dec20.html

Franka da Cruz i Christine Gianone

Frank da Cruz i Christine M. Gianone,

Wszelkie prawa zastrzeżone.

Zobacz niedawno odkopany film przedstawiający likwidację jednego z DEC-20 Uniwersytetu Columbia w 1986 roku:

Nietechniczne wspomnienie napisane w 1988 roku (przy okazji odłączenia ostatniego DECSYSTEM-20 Uniwersytetu Columbia) na potrzeby książki Digital Press, która miała upamiętniać 36-bitowe maszyny DEC serią artykułów, ale nigdy nie została opublikowana. Drobne zmiany, notatki, glosariusz, linki i formatowanie HTML dodane w styczniu 2001 (oraz drobne aktualizacje od czasu do czasu). Więcej informacji na temat historii informatyki na Uniwersytecie Columbia KLIKNIJ TUTAJ .

UWAGA: Ten artykuł został „ przecięty” 18 stycznia 2001 roku i był czytany przez wiele osób, nie mając pojęcia, o czym jest. Proszę pamiętać, że nie ma to na celu wprowadzenia ani wyjaśnienia wpływowych 36-bitowych komputerów Digital Equipment Corporation (DEC) z lat 1964–1988; miał to być raczej jeden esej w książce, w którym inne eseje wyjaśniałyby architekturę i historię technologii. Niektóre strony tematyczne znajdziesz w sekcji LINKI na końcu.

Tym, którym koncepcja komputera 36-bitowego wydaje się dziwna: pierwszym komercyjnym komputerem binarnym (w przeciwieństwie do dziesiętnego) był IBM 701 , który po raz pierwszy pojawił się w Internecie w 1952 roku. Miał 36-bitowe słowo. Po nim pojawił się model 704 (w którym pierwszy język wysokiego poziomu, Fortran, został opracowany w latach 1953-57 i którego 6-bitowy zestaw znaków BCD i 36-bitowe słowo wyjaśniają limit 6 znaków w nazwach zmiennych Fortran), 709 , 7090 i 7094 , wszystkie 36 bitów. 36-bitowe maszyny IBM były kolebką LISP-a (*) i ( prawdopodobnie ) podziału czasu (kompatybilny system podziału czasu MIT, CTSS, około 1962 r.), a także były inspiracją dla36-bitowy PDP-6 firmy DEC (1964), który był prekursorem PDP-10 i DECSYSTEM-20 , który istniał do 1988, kiedy DEC zaprzestał produkcji maszyn 36-bitowych. Zatem architektury 36-bitowe były dominującą (i pod wieloma względami dominującą) cechą krajobrazu komputerowego od 1952 do 1988: 36 lat.

WSTĘP

Do połowy lat siedemdziesiątych Uniwersytet Columbia był mocno zakorzeniony w przetwarzaniu w trybie wsadowym OS/360 na komputerach mainframe IBM. Obszar „ Samoobsługowe wejście/wyjście ” został z dumą nazwany, ponieważ stanowił ogromny krok naprzód w stosunku do czasów, gdy studenci i badacze potulnie prezentowali operatorom swoje talie kart i wracali następnego dnia roboczego po swoje wyniki – zwykle po to, by się przekonać, że ich SYSMSG był pełen niezrozumiałych skarg, których bolesne rozszyfrowanie zazwyczaj prowadziło sfrustrowanego użytkownika do brakującego przecinka lub dodatkowej spacji w języku kontroli zadań. Lub jeśli JCL przeszedł inspekcję, istniał zrzut rdzenia o grubości 3 stóp, przy którym można było się zwinąć. Obszar SSIO był pomieszczeniem wypełnionym otępiającą kakofonią uderzeń klawiszy i wrzaskiem przerażających drukarek IBM 1403, staccato trzepotania czytników kart , sortowników kart i tłumaczy ; niespokojne tłumy zgromadziły się wokół drukarni, po pas w wyrzuconych wydrukach…

IBM 360 Model 91 firmy Columbia z interfejsem 360/75 był jednym z największych, najszybszych, najcięższych i najgłośniejszych komputerów na świecie, gdy został zainstalowany pod koniec lat sześćdziesiątych. Zajmował akry powierzchni i można było oglądać rdzenie magnetyczne przez okna w wysokich na 6 stóp skrzynkach pamięci rdzeniowych , stojących w rzędach, które znikały w punkcie zbiegu. Zasilanie zapewniał dudniący żeliwny generator silnikowy wielkości małej ciężarówki, a chłodzenie schłodzoną wodą destylowaną (dostarczaną z Deer Park w dużych szklanych butelkach w drewnianych skrzyniach) pompowaną kilometrami wewnętrznej kanalizacji. Panel sterowania procesoramiał więcej świateł niż Times Square. Według legendy wśród tysięcy przełączników i przycisków znajdował się ten, którego zabójcza misja polegała na „Wyrzuceniu żarówki” — pewna śmierć dla każdego, kto go naciśnie. Panel kontrolny [1988] leży teraz w spoczynku w Muzeum Komputerowym w Bostonie, a jego hipnotyczne żarówki zgasły na zawsze ( 1 ).

To masywne, szaro-niebieskie Stonehenge, którego grube macki sięgały obszaru SSIO, wykonywało dla naszych inżynierów ciężkie „kody” w języku Fortran: kręcone mosty; bombardowanie nieszczęsnych substancji neutronami; obliczanie Pi do milionów cyfr; przekształcanie ziemskiego pola magnetycznego w muzykę... Dla naszych socjologów rok po roku przewidywało to wynik wyborów prezydenckich w 1956 roku ze śmiertelną dokładnością. Administratorom przesyłał czeki, transkrypcje i wyciągi księgowe. I w końcu jego niewielki fragment przydzielono naszym studentom inżynierii, stosując ich pracochłonne pętle DO i GOTO do szeregu Taylora, reguły Simpsona, kwadratury Gaussa i transformaty Laplace'a. Uczniowie ci mieli stosunkowo proste zadanie: napisać program, umieść go w kanapce z magicznymi kartami JCL, włóż kanapkę do czytnika kart i zbierz wynikowy wynik. Wielu nauczycieli wracało, by wspominać te proste dni z melancholijnym sentymentem, choć wspomnienia uczniów częściej nawiedzały obrazy śliskich palców zbierających stosy upuszczonych kart dziurkowanych.

Terminale zaczęły pojawiać się na początku lat 70. XX wieku, początkowo jedynie jako rozproszenie wśród tajemniczych programistów systemowych na Olimpie, którzy potrafili rozmawiać w tajemnych językach z „monitorami terminali” o nazwach takich jak Milten, Cleo, Orvyl i Wylbur, a ostatecznie APL i TSO (pierwsza to „Irtnog” języków komputerowych, druga to forma JCL wpisana na terminalu). Interakcja z komputerem była atrakcyjna, ale jednocześnie niezadowalająca. Polecenia były niejasne, a obliczenia – poza APL – nadal znajdowały się w partii.

W 1975 roku wprowadziliśmy nasz pierwszy prawdziwy system podziału czasu, DEC PDP-11/50 z systemem operacyjnym RSTS/E. Miał to być niskobudżetowy eksperyment z prawdziwie interaktywną informatyką. Zbudowany wokół języka BASIC, RSTS umożliwił maksymalnie 32 jednoczesnym użytkownikom siedzącym w DECwriters programowanie, debugowanie, komunikację między sobą i ogólnie niewłaściwe zachowanie – wszystko w czasie rzeczywistym. RSTS okazał się niezwykle popularny i PDP-11 wkrótce został przytłoczony przez chętnych uczniów.

Wybrano DEC, ponieważ IBM tak naprawdę nie oferował w tamtych czasach żadnego rodzaju interaktywnego podziału czasu ogólnego przeznaczenia. W porównaniu do innych konkurentów, oferta DEC była lepiej rozwinięta, bardziej dojrzała i… zabawniejsza. Jako system operacyjny wybrano RSTS, a nie, powiedzmy, UNIX, ponieważ wersja 6 UNIXa była potężnym, zaufanym systemem, który pozwalał każdemu zrobić wszystko. Mieliśmy zalążek pomysłu, że system powinien odegrać pewną rolę w ochronie użytkowników przed sobą nawzajem i przed nimi samymi. Chociaż UNIX oferował niewiele lub nie oferował żadnych udogodnień w tym obszarze, RSTS nie był pozbawiony własnych słabości. Użytkownicy szybko dowiedzieli się, że mogą przypisać wszystkie TTY, tak aby nikt inny nie mógł z nich korzystać. Co więcej, po przypisaniu TTY mogliby uruchomić na nim program udający proces logowania,

WELCOxE T@\R\~~~~xxx }}}}}~~

Inni pomysłowi użytkownicy odkryli, że jeśli otworzą nowy plik w celu uzyskania dostępu zorientowanego na rekordy, będą mogli przeczytać rekordy przed ich zapisaniem, pobierając stare dane z usuniętych plików innych użytkowników lub systemowego pliku haseł.

W pewnym momencie nasz system został zainfekowany przez klikę nastolatków z pobliskiej szkoły podstawowej, którzy włamali się, wykorzystując błąd w procesie logowania. Walczyli z systemem przez kilka tygodni, zanim zostali wykryci, a wyeliminowanie licznych zapadni i bomb zegarowych, które pozostawili, zajęło kilka dni całodobowej pracy.

Pomimo swoich problemów RSTS okazał się dość popularny i szybko został przeciążony. Eksperyment uznano za sukces i zaczęliśmy rozglądać się za czymś większym i nieco bardziej wyrafinowanym – BASIC nie był językiem wybieranym przez informatyków. Miało to miejsce mniej więcej wtedy, gdy DEC po raz pierwszy ogłosił DECSYSTEM-20 (jego logo jest zapisane wielkimi literami, w przeciwieństwie do starszego kuzyna DECsystem -10, uznano za wciśnięcie klawisza Caps Lock w zgłoszeniu znaku towarowego). Zanim w ogóle przyjrzeliśmy się systemowi, zmusiliśmy marketingowców do wciągnięcia pomocy technicznej i bezlitośnie przepytywaliśmy ich, czy użytkownicy mogą przypisać wszystkie urządzenia, zapełnić dysk, wyjść z procesu logowania za pomocą klawisza C, bombardować się nawzajem głupie wiadomości, nawet jeśli plik został „wyczyszczony” po usunięciu. Kiedy wszystko wydawało się być satysfakcjonujące, przyjrzeliśmy się systemowi.

Zadziwienie i zdumienie, ten komputer wie, co napiszesz i napisze to za Ciebie! Cóż prawie. Ale jego atrakcje były widoczne już na pierwszy rzut oka. Jeśli nie wiesz, co wpisać, wpisz znak zapytania, a wyświetli się lista możliwości. Nagle „wypełnij puste miejsce” stało się bardziej „wielokrotnym wyborem”. Oczywiście, że może ci powiedzieć! Wie, jakie są możliwości wyboru, więc dlaczego nie miałby ci o tym powiedzieć??? Pytanie, które można było zadać z pożytkiem dziesięć czy piętnaście lat wcześniej (wizje doświadczonych programistów systemowych przeszukujących podręcznik za podręcznikiem, szukając, co wpisać w następnym polu jakiegoś mało znanego polecenia... częsty widok na niektórych komputerach nawet ten dzień). I to "?" nie była funkcją wysoce uprzywilejowaną (podobnie jak posiadanie zestawu podręczników) — mogli z niej korzystać nawet ZWYCZAJNI UŻYTKOWNICY. Zaskoczeni odkryliśmy, że komunikaty o błędach były podawane zwykłym, zrozumiałym tekstem, a nie 17-cyfrowymi liczbami szesnastkowymi, dzięki czemu można je było zrozumieć bez książki „komunikaty i kody”.

Od razu spodobała nam się życzliwość, swobodna postawa i humor. Dopiero później wiedzieliśmy, że COOKIE (które przetrwało do dziś w systemie UNIX jako „fortuna”) nie jest standardową częścią systemu, a potem pojawił się TECO ( 2 ):

@kochać się

nie wojna?

DEC-20 był prawdziwym systemem podziału czasu ogólnego przeznaczenia. Nie był zbudowany wokół konkretnego języka, ponieważ RSTS opierał się na BASIC-u. Oferował szeroką gamę kompilatorów, interpreterów, edytorów tekstu i narzędzi, odzwierciedlając wiele lat rozwoju oprogramowania TOPS-10 i TENEX. Może wchłonąć nie tylko naszych użytkowników RSTS, ale także wielu użytkowników komputerów mainframe IBM w Fortran i APL, a jego łatwość obsługi przyciągnie również wielu początkujących użytkowników.

Nasz nowy DEC-20 przybył 29 czerwca 1977 z TOPS-20 w wersji 1B. Montaż zakończył się 26 lipca. W porównaniu z IBM 360/91, a nawet DEC PDP-11, był rozczarowująco pozbawiony funkcji — nie było o czym mówić, żadnych świateł, żadnych przełączników do wprowadzania danych, żadnych pokręteł, żadnych silników, żadnych pomp... A jednak DEC-20 był nieskończenie potężniejszy niż słaby PDP-11. Został wyposażony w cztery najnowocześniejsze dyski twarde RP06 ( 3 ), których nigdy nie można było zapełnić, oraz niewiarygodną pamięć główną o pojemności 256 KB – słów, a nie bajtów! Taka maszyna spełniałaby nasze wymagania w zakresie obliczeń instruktażowych przez wiele lat.

Ilekroć placówka komputerowa otrzymuje nowy rodzaj komputera, programiści natychmiast rozpoczynają wściekłą falę działań, aby przekształcić nowy system w ich ukochany stary system. W dostarczonej postaci jedynym edytorem DEC-20 (poza nieoficjalną kopią TECO) był tajemniczy, liniowy EDIT, wywodzący się z TOPS-10 SOS. Nasi użytkownicy byli przyzwyczajeni do Wylbur, znacznie mniej tajemniczego edytora liniowego w naszym IBM 360/91, więc natychmiast rozpoczęliśmy pisanie wersji Wylbur dla DEC-20, aby nasi użytkownicy IBM czuli się bardziej jak w domu.

Zaczęliśmy uczyć się języka asemblera DEC-20 i czytać Podręcznik referencyjny wywołań monitora. Wkrótce odkryliśmy, że to rzeczywiście wspaniała maszyna. Zestaw instrukcji i repertuar wywołań monitorujących (JSYS) były zdumiewająco bogate. Wśród wywołań monitora znajdował się specjalny zestaw, niepodobny do niczego, co kiedykolwiek widzieliśmy: w sam system operacyjny wbudowane były standardowe funkcje konwersji pomiędzy wewnętrznymi i zewnętrznymi reprezentacjami wszystkich różnych rodzajów danych mających znaczenie dla systemu: liczb w różnych podstawach, znaki, ciągi znaków, nazwy plików, nazwy katalogów, daty i godziny. Programiści z wcześniejszej epoki wiedzieli, że najtrudniejszą i najbardziej żmudną częścią pisania programu interaktywnego jest monitowanie, akceptowanie i sprawdzanie danych wprowadzanych przez użytkownika.

Co najlepsze, te funkcje konwersji zostały zebrane w jednym pakiecie o nazwie COMND JSYS, opracowanym przez Dana Murphy'ego , co umożliwiło programistom wykorzystanie w swoich programach tego samego „interfejsu użytkownika”, co w TOPS-20 Exec: pełny podpowiadanie, redagowanie, pomoc na każdym polu; skróty i rozpoznawanie słów kluczowych i przełączników; uzupełnianie nazw plików; przebaczenie, gdy użytkownik popełni literówkę itp.

Programy kodowane za pomocą COMND JSYS miały wiele zalet. Byli przyjaźni, pomocni i konsekwentni. Wszystkie programy napisane przy użyciu COMND działały w ten sam sposób: wpisz „?” aby dowiedzieć się, jakie są polecenia lub opcje, wpisz ESC, aby wypełnić bieżące pole (jeśli to możliwe) i otrzymać monit o wprowadzenie następnego pola. Ludzie mogliby używać „?” i ESC są swobodnie dostępne, aby nauczyć się obsługi nowego programu, a później mogą wpisywać zwięzłe, skrócone polecenia zwiększające szybkość. To podejście, zwane „menu na żądanie”, nie faworyzuje nowicjusza nad ekspertem (jak to robią systemy zorientowane na menu) ani eksperta nad nowicjuszem (jak robią to tajemnicze, zwięzłe zestawy poleceń APL lub UNIX).

Nasz nowy edytor podobny do Wylbura, zwany „Otto”, został napisany tak, aby w pełni wykorzystywać COMND JSYS. Pomimo wszystkich swoich uporczywych ograniczeń Otto odniósł natychmiastowy sukces, ponieważ umożliwił użytkownikom komputerów mainframe IBM bezbolesne przejście do nowego środowiska, jednocześnie indoktrynując ich w zakresie DEC-20. Jego ukrytym celem było wciągnięcie ich, a następnie sfrustrowanie na tyle, aby poświęcili czas na naukę „prawdziwego” edytora.

[ Góra ] [ Dalej ]

JĘZYKI PROGRAMOWANIA

W miarę upływu miesięcy nawiązaliśmy kontakt z innymi witrynami DEC 36-bitowymi, wiele z nich — Stanford, CMU, MIT, Rutgers, BBN, SRI — z wieloletnim doświadczeniem w TOPS-10, TENEX, WAITS lub ITS i otrzymaliśmy od nich programy, które miały nas zajmować przez lata. Niektóre były falstartami, ale inne będą się rozwijać w jakiejś formie przez całe następne stulecie, jako dziedzictwo DEC-10 i -20. Z tego doświadczenia nauczyliśmy się korzyści płynących z dzielenia się i wiedzieliśmy, że jeśli kiedykolwiek stworzymy coś, co będzie miało powszechną użyteczność, podzielimy się tym z innymi w tym samym duchu, w jakim te instytucje dzieliły się z nami swoją pracą.

Naszym głównym celem w przeszukaniu tych witryn było dowiedzenie się, co robią z programowaniem. W koncepcji interfejsy użytkownika i systemu DEC-20 były tak bliskie perfekcji, jak ktokolwiek w tamtym czasie (poza Xerox PARC) mógł sobie wyobrazić, ale w praktyce koncepcja nie została w pełni zrealizowana. Większość języków programowania pochodziła bezpośrednio z TOPS-10 i nie zapewniała dostępu do wywołań monitora TOPS-20 ani jego systemu plików. A jednak byliśmy zdecydowani, że w epoce programowania strukturalnego nie będziemy pisać kodu na poziomie systemu w języku asemblera. Po krótkich flirtach z Bliss-10, BCPL, Simulą, a nawet wczesnym Portable C (który nie był dostosowany do architektury 36-bitowej), zdecydowaliśmy się na Sail Uniwersytetu Stanforda jako nasz „język urzędowy, Ale kilka lat oddania Sailowi w końcu doprowadziło do rozczarowania. Było zbyt wiele błędów, zbyt duża zależność od systemu wykonawczego i wiedzy, gdzie się on znajduje, zbyt wiele konwersji niezbędnych w przypadku nowych wydań Saila lub TOPS-20, zbyt wiele groteskowych obejść, aby osiągnąć to, co byłoby naturalne w asemblerze — jedyne język, który naprawdę rozumiał maszynę i system operacyjny. Od tego dnia całe programowanie naszych systemów odbywało się w asemblerze. Ale kilka lat oddania Sailowi w końcu doprowadziło do rozczarowania. Było zbyt wiele błędów, zbyt duża zależność od systemu wykonawczego i wiedzy, gdzie się on znajduje, zbyt wiele konwersji niezbędnych w przypadku nowych wydań Saila lub TOPS-20, zbyt wiele groteskowych obejść, aby osiągnąć to, co byłoby naturalne w asemblerze — jedyne język, który naprawdę rozumiał maszynę i system operacyjny. Od tego dnia całe programowanie naszych systemów odbywało się w asemblerze.

Jak wiele rzeczy, zależność od asemblera jest dobra i zła. Było to dobre, ponieważ poruszało twórczą czułość — programiści byli nieskrępowani, nieskrępowani biurokratycznymi wymaganiami i autorytarnymi ograniczeniami języków wysokiego poziomu i mieli pełny dostęp do zestawu instrukcji maszyny i repertuaru wywołań monitora, które w dniu DEC- 20, oglądało się z przyjemnością. Programowanie w asemblerze było po prostu zabawą, a nasi programiści z radością stworzyli miliony linii kodu, ale z dokuczliwym poczuciem, że jest w tym coś grzesznego. Było to spowodowane złą stroną: programy w języku asemblera są specyficzne dla podstawowej maszyny i systemu operacyjnego. Co stanie się z tymi programami, gdy maszyna zniknie?

Niemniej jednak MACRO było nie do odparcia (MACRO jest tu użyte jako termin ogólny, obejmujący MACRO-10 i -20 DEC, a także Midas z MIT i FAIL Ralpha Gorina). W przeciwieństwie do FORTRAN, BASIC lub jakiegokolwiek innego języka na DEC-20 (z wyjątkiem Sail, dla którego napisaliśmy pakiet interfejsu COMND JSYS), MACRO pozwala pisać prawdziwe programy DEC-20 — programy, które były pomocne, delikatne i wyrozumiałe dla użytkownika. Dla programistów języka asemblera ze znajomością IBM 360 architektura maszyny i zestaw instrukcji były zachwycające. Liniowa przestrzeń adresowa o długości 256 tys. słów (koniec z BALR i USING!), setki egzotycznych instrukcji... A sam asembler pozwalał na stosunkowo czyste, a nawet „ustrukturyzowane” programy. Na przykład, literały liniowe MACRO są prawie równoważne blokom „początek… koniec” w Algolu lub Pascalu, eliminując straszliwą logikę spaghetti, która jest plagą większości programów w języku asemblera. Oto na przykład konstrukcja JEŻELI-TO-ELSE z wieloma instrukcjami w każdej części, bez GOTO i etykiet (przepraszam za błędy, piszę z pamięci):

CAIL B, FOO ; JEŚLI (b >= foo) WTEDY

PUSHJ P, [; ZACZYNAĆ

HRROI A, [ASCIZ/.LT./] ; wiadomość = ".LT.";

USTAW MNIEJ ; mniej = -1;

AOS (P) ; END (pomiń część ELSE)

POPJ P, ] ; W PRZECIWNYM RAZIE

PUSHJ P, [; ZACZYNAĆ

HRROI A, [ASCIZ/.GE./] ; wiadomość = ".GE.";

SETZM MNIEJ ; mniej = 0;

POPJ P, ] ; KONIEC;

PSOUT ; DRUKUJ wiadomość;

Wszystko zawarte w nawiasach kwadratowych jest literałem; asembler znajduje miejsce, w którym można go umieścić i zastępuje dosłowny adres tego miejsca. Zatem (prawie) dowolna ilość danych lub kodu może zostać umieszczona „w linii”, a nie w oddzielnym obszarze danych. Jak widać na przykładzie, literały można zagnieżdżać. Inne popularne struktury kontrolne można również symulować za pomocą literałów, takich jak instrukcja CASE:

PRZESUŃ B, @[EXP FOO, BAR, BAZ](A)

Ten przykład przechowuje B w FOO, BAR lub BAZ, w zależności od wartości A. Taka operacja wymagałaby wielu linii kodu w większości innych języków asemblera i większości języków wysokiego poziomu.

Podsumowując, programy w języku asemblera można debugować interaktywnie na poziomie symbolicznym przy użyciu „DDT” — nie dichlorodifenylo-trichloroetanu, ale „narzędzia dynamicznego debugowania” zaprojektowanego w celu usuwania błędów równie skutecznie jak w rzeczywistości, z mniej niepożądanych skutków ubocznych (inne pomoce do debugowania nosiły podobnie owadobójcze nazwy, jak RAID). Z DDT ( 4) nie ma już potrzeby przeglądania grubych wydruków zrzutów szesnastkowych, wstawiania instrukcji print i ponownego składania itp. Składnia jego poleceń jest nieco zawiła i składa się głównie z tajemniczych pojedynczych liter, znaków interpunkcyjnych, tabulatorów i swobodnego użycia klawisza ESC („Altmode”) znak, często podwajany. Ale DDT może zrobić wszystko. W rzeczywistości, ponieważ może wykonywać wszystkie instrukcje komputerowe i usługi systemowe, twórcy „Inkompatybilnego systemu podziału czasu” (ITS) dla PDP-10 z MIT wykorzystali go jako interpreter poleceń najwyższego poziomu. Porozmawiaj o przyjaznych dla użytkownika...

Zestaw instrukcji DEC-10/20, wywołania monitora, asembler i debuger zwabiły wielu skądinąd rozsądnych programistów do długich sesji kodowania, czyli „ataków hakerskich”. Powstała subkultura programistów DEC-10/20, mówiących dziwnymi słowami i wyrażeniami, których etymologię można było głównie prześledzić w Podręczniku obsługi sprzętu PDP-10. Dodanym przez hakerów składnikiem (wówczas nie było to określenie pejoratywne) była wymowa mnemoników nigdy nie przeznaczonych dla ludzkich narządów mowy (AOS, BLT, JRST, ILDB, HRROI) i rozszerzenie ich znaczeń na inne obszary życia ( głównie jedzenie). Ostatecznie leksykon ten został zebrany i skodyfikowany przez Guya Steele z CMU i innych jako „Żargon hakera”, pierwotnie opublikowany jako plik, później rozszerzony do postaci książki (patrz bibliografia).

Hakerzy z DEC-10/20 stanowili początkowo małą grupę, głównie ze względu na niedostatek użytecznej dokumentacji. Aby napisać działający program, można zapoznać się z Podręcznikiem referencyjnym sprzętu, Podręcznikiem referencyjnym wywołań monitora i Podręcznikiem referencyjnym MACRO Assemblera. Podręczniki te były jednak jedynie listami instrukcji, wywołań monitorów i pseudooperacji i nie dawały najmniejszego pojęcia, jak złożyć program w całość. W 1981 roku sytuacja zmieniła się dramatycznie wraz z publikacją książki Ralpha Gorina o programowaniu w języku asemblerowym DEC-20 i świat wkrótce stał się przeludniony licencjackimi programistami DEC-20.

Chris Ryland i Frank pracowali nad przewodnikiem programowania w języku asemblerowym DEC-20 w latach 1979-80, który mógłby stać się książką, gdyby Ralph nas nie ubiegł :-) KLIKNIJ TUTAJ, aby wyświetlić jego wersję w postaci zwykłego tekstu , niedawno odkopany (wrzesień 2002), około 220 stron.

Niemniej jednak brak spójnego zestawu języków programowania wysokiego poziomu, w pełni zintegrowanych z systemem operacyjnym i systemem plików, był jedną z fatalnych wad DEC-20. Ta słabość została naprawiona przez DEC w VAX/VMS, gdzie programy napisane w różnych językach mogą wymagać wspólnego lub kompatybilnego wsparcia środowiska wykonawczego, a programy systemowe można pisać praktycznie w dowolnym języku - nawet w BASIC-u lub FORTRAN.

Wiele pozostałości TOPS-10 działało – i nadal będzie działać aż do ostatniego tchnienia ostatniego DEC-20 – w „trybie zgodności”. Oznaczało to, że programy napisane w tych językach mogły uzyskiwać dostęp do plików jedynie zgodnie z zasadami TOPS-10: żadnych długich nazw plików, żadnych śmiesznych znaków w nazwach plików, żadnych wyraźnych odniesień do katalogów lub numerów generacji. W szczególności programy źródłowe dla większości języków programowania miały to ograniczenie: większość kompilatorów nie została zoptymalizowana w formacie TOPS-20, a nawet gdyby tak było, LINK nie zrobił tego. Ostatecznie oznaczało to, że użytkownik musiał wiedzieć o TOPS-10, aby móc korzystać z TOPS-20, a programistom języków wysokiego poziomu odmówiono dostępu do wielu funkcji TOPS-20.

Narzędzia deweloperskie

(Ta sekcja została dodana w styczniu 2019 r.) Kilkadziesiąt lat później trudno znaleźć prawdziwe DECSYSTEM-20, ale istnieją emulatory; wyszukaj w Google, żeby je znaleźć. Używanie emulatora DEC-20 przypomina używanie prawdziwego DEC-20. Można na przykład pisać i wykonywać programy w języku asemblera. Aby to zrobić, będziesz potrzebować podręczników. Oto niektóre lokalnie archiwizowane kopie:

Tytuł	Temat	Data	Format	Rozmiar
Podręcznik referencyjny procesora DECsystem-10 DECSYSTEM-20	Architektura i zestaw instrukcji	czerwiec 1982	PDF	29 MB
Podręcznik referencyjny asemblera makro DECSYSTEM-20	Podręcznik w języku asemblera	Kwiecień 1978	PDF	5MB
Podręcznik referencyjny TOPS-20 Monitor Calls	inaczej podręcznik JSYS (usługi systemowe)	grudzień 1982	PDF	26MB
Podręcznik TOPS-20 DDT	Narzędzie do dynamicznego debugowania	maj 1985	PDF	5MB
ŻAGIEL	Język sztucznej inteligencji Stanforda	sierpień 1976	PDF	5MB

Zobacz program Kermit DEC-20 jako przykład kodowania w języku asemblera.

SAIL (język programowania wysokiego poziomu opracowany przez Stanforda) zwykle nie jest instalowany w modelach DEC-20, więc jeśli instrukcja Cię zaintryguje, będziesz musiał poszukać pliku do pobrania.

[ Góra ] [ Następny ] [ Poprzedni ]

Radzenie sobie ze wzrostem

W ciągu roku nasz DEC-20 został beznadziejnie przeciążony, średnie obciążenie osiągnęło szczyt, a dyski regularnie się zapełniały. W tym stanie pozostał przez kolejny rok, aż do momentu, w którym udało nam się kupić drugą maszynę. Wkrótce i ten się zapełnił, a w ciągu następnych lat przyszedł trzeci i czwarty, a także DEC-20 na wydziale informatyki w Columbii i kolejny w Columbia Teachers College. Systemy Centrum Komputerowego zostały zmodernizowane poprzez dodanie pamięci i dysków, a ostatecznie poprzez połączenie ich wszystkich za pomocą systemu CFS oraz zainstalowanie napędów dyskowych RA-81 i HSC-50. Ostatecznie wszystkie procesory zostały zmodernizowane do wersji 2065 z maksymalną pamięcią i nie mogliśmy nic więcej zrobić, aby uzyskać z nich większą wydajność. Podobnie jak inni lojaliści DEC-20, zapełniliśmy naszą maszynownię DEC-20 po brzegi i nie było już miejsca na więcej. Naszą jedyną opcją rozbudowy byłby nowy model o większej mocy na mniejszej powierzchni. Przez kilka lat okresowo jeździliśmy do Marlboro, aby omówić nadchodzącą maszynę. Właściwie były 2 projekty.

DOLPHIN zaczynał jako system high-end oferujący prawdziwie rozproszoną architekturę 36-bitową. Duże DOLPHINY będą znajdować się wśród małych MINNOWS dla jednego użytkownika w sieci o dużej przepustowości. Zarówno DOLPHIN, jak i MINNOW uległy problemom technologicznym. DOLPHIN używał specjalnie zaprojektowanych chipów Motoroli, które miały problemy z niezawodnością. Gęste opakowanie MINNOW, zaprojektowane tak, aby zmieściło się w obudowie terminala VT52 , w połączeniu z koniecznością lokalnie podłączonego napędu dyskowego RP06 (!) było jego wadą. Do komercyjnego wykorzystania Ethernetu brakowało jeszcze lat, a problem z siecią również pozostał. [2]

Projekt JUPITER pojawił się kilka miesięcy po odwołaniu projektu DOLPHIN. Jego projekt nie obejmował rozproszonych MINNOW, ale potwierdzał wymóg szybkiego, scentralizowanego procesora. Miało być 10+MIPS i tanio. Długi i trudny proces projektowania nie doprowadził do osiągnięcia żadnego z tych celów i w 1983 roku projekt został anulowany, chociaż jego części ostatecznie trafiły na rynek – CI, HSC-50 itp. [2]

Kierownictwo i inżynierowie LCG zawsze zapewniali nas podczas każdej wizyty w Marlboro (MA) (czasami obejmującej przelot helikopterem i limuzyną oraz zakwaterowanie w hotelach „tematycznych”), że nowy system został zaledwie „18 miesięcy” od ogłoszenia, niezależnie od jego kryptonimu . Koszt posiadania któregokolwiek systemu byłby znacznie niższy niż równoważna liczba KL.

Czekając na pojawienie się Jowisza, nadal potrzebowaliśmy sposobów na jak najsprawiedliwsze rozdzielenie naszych istniejących zasobów DEC-20 pomiędzy użytkowników. To budziło obawy od samego początku. DEC-20 w oryginalnie dostarczonym stanie umożliwiał zwykłym użytkownikom przejęcie maszyny na różne sposoby, czyniąc ją bezużyteczną dla innych. Użytkownicy pisali programy, aby w nieskończoność tworzyć samoreplikujące się forki, przypisywali wszystkie PTY i używali ich do pisania programów kradnących hasła, uruchamiali programy w nieskończonych pętlach, które pochłaniały wszystkie dostępne cykle procesora, monopolizowali ograniczone linie końcowe na długie godziny, zapełniali kolejki wsadowe, bombardowali operatorów tysiącami fałszywych żądań podłączenia taśmy, drukowali miliony stron bzdur itp.

Jako monitorująca i wykonawcza witryna źródłowa, Columbia była w stanie wprowadzić modyfikacje ograniczające dostęp do pewnych zasobów określonym klasom użytkowników na podstawie identyfikatora użytkownika lub ciągu konta lub przejmując „nieużywane” bity w słowie możliwości. Jednak już w czasach, gdy korzystaliśmy z systemu OS/360, wyciągnęliśmy bolesną lekcję, że lokalne modyfikacje systemów operacyjnych wracają, by nas prześladować, gdy pojawiają się nowe wersje: aktualizacja naszego mocno zmodyfikowanego systemu IBM OS/360 21.0 do wersji 21.8 zajęła lata. Dlatego czuliśmy się zobowiązani przekonać DEC, że nasze wymagania mają zastosowanie uniwersalne. W tym celu przeszukaliśmy kanały, najpierw przesyłając formularze raportu dotyczącego działania oprogramowania, następnie pisząc listy, a na koniec odbyliśmy serię spotkań z grupą monitorującą w Marlboro.

Jednym z produktów tych spotkań była praca związana z kontrolą dostępu. Było to zadanie zlecone przez klienta, z którym podmiot monitorujący konsultował się za każdym razem, gdy użytkownicy poprosili o dostęp do określonych zasobów. ACJ może zdecydować o udzieleniu lub odmowie dostępu w oparciu o własne kryteria witryny klienta. Niektóre z tych zasobów obejmowały logowanie, udostępnianie możliwości, tworzenie zadań, tworzenie forków, przypisywanie urządzeń, przesyłanie zadań wsadowych, montowanie taśm, montowanie struktur, tworzenie katalogów, zmiany klas programu planującego, dostęp i łączenie itp. Było to wielkim dobrodziejstwem dla bezpieczeństwa i zarządzanie zasobami.

ACJ nie pozwoliła nam jednak regulować bieżącego zużycia zasobów. W tym celu musieliśmy stworzyć program monitorujący, który zbierałby statystyki poszczególnych użytkowników dotyczące procesora i czasu połączenia. Studenci otrzymali tygodniowy budżet na czas połączenia i procesora oraz otrzymywali okresowe ostrzeżenia, gdy zbliżali się do limitu. Nawet po odcięciu mogli wrócić poza godzinami szczytu, aby dokończyć pracę. ACJ i Omega umożliwiły naszym DEC-20 obsłużenie ponad 6000 aktywnych studentów na czterech maszynach w szczytowym okresie ery DEC-20.

Jeden obszar był dla nas szczególnie interesujący. Terminale nie były podłączone bezpośrednio do naszych DEC-20, ale były przełączane przez centralę PBX. Dlatego DEC-20 nie wiedział, że TTY37 (na przykład) to terminal numer X w pomieszczeniu Y budynku Z. Zarówno ze względów bezpieczeństwa, jak i wygody posiadanie tej wiedzy było konieczne. Jeśli użytkownik był podejrzany o niewłaściwe zachowanie, personel musiał znać jego fizyczną lokalizację. Podczas tworzenia zadania kierownik musiał znać typ i szybkość terminala, aby użytkownik nie był zdezorientowany popękanymi i pomieszanymi ekranami. Na szczęście centrala danych miała terminal konsolowy, który prowadził rejestr połączeń. Zostało ono podłączone za pomocą kabla Octopus RS-232 do portów każdego z DEC-20, w którym przechowywana była baza danych portów PBX, lokalizacji, typów terminali i prędkości.

Dzienniki prowadzone przez ACJ i Omega zawierały fizyczną lokalizację zadania. Dzienniki te umożliwiły nam wyśledzenie więcej niż kilku potencjalnych i rzeczywistych osób naruszających bezpieczeństwo systemu i prywatność innych użytkowników.

[ Góra ] [ Następny ] [ Poprzedni ]

SIEĆ

Nasz pierwszy DEC-20 został podłączony do IBM 360/91 przy użyciu produktu HASP/RJE firmy DEC, który wymagał własnego, dedykowanego interfejsu DN20. Ta metoda komunikacji była dość bolesna, wymagała od DEC-20 udawania czytnika kart i drukarki liniowej w systemie IBM. Napisaliśmy serię programów Sail, które miały zbudować „magiczną kanapkę JCL” dla naszych użytkowników, którzy chcieli wysyłać pliki lub przesyłać zadania do systemu IBM.

Gdy tylko otrzymaliśmy drugi DEC-20, połączyliśmy go z pierwszym za pomocą DECnet [1980], a następnie połączyliśmy tę małą sieć z innymi systemami DEC na terenie kampusu. DECnet był także używany na komputerach w centrum komputerowym Uniwersytetu Carnegie-Mellon, dlatego połączyliśmy nasze dwie sieci DECnet w jedną z dzierżawioną linią telefoniczną między Nowym Jorkiem a Pittsburghiem, nazywając rozszerzoną sieć CCnet [1982] (CC oznacza Computer Center, a może Carnegie-Columbia). Wkrótce do sieci dołączyły inne instytucje — Stevens Institute of Technology, Case Western Reserve University, New York University, University of Toledo i inne. Główną korzyścią było dzielenie się oprogramowaniem i pracami programistycznymi przez kadrę zarządzającą komputerami w tych lokalizacjach, co obejmowało systemy DEC-20, DEC-10, VAX, PDP-11 i inne systemy DEC. Przez wiele lat, Columbia i CMU korzystały ze wspólnego, wspólnie opracowanego systemu DEC-20 Galaxy, który umożliwiał przezroczyste drukowanie za pośrednictwem sieci DECnet i szpulowanych taśm drukujących dla drukarki Xerox 9700. Jeden z urządzeń DEC-20 firmy Columbia służył jako brama pocztowa między CCnet a BITNET, dużą siecią akademicką opartą na protokołach RSCS komputerów mainframe IBM.

Najważniejszym wkładem DEC-20 w rozwój sieci była obsługa protokołów ARPANET, najpierw NCP, a później TCP/IP. Przez wiele lat firma DEC była jedynym głównym dostawcą komputerów obsługującym te protokoły, które zostały opracowane głównie na 36-bitowych maszynach DEC w systemach TENEX, TOPS-10 i TOPS-20 (a później w VAX dla Berkeley UNIX). Pod koniec lat 70. i na początku 80., kiedy ARPAnet rozwijał się i prosperował poza swoje pierwotne, niewielkie zadania badawcze, był zdominowany przez 36-bitowe maszyny DEC, a wiele podstawowych protokołów i procedur internetowych zostało opracowanych w tym ramach. Sam DEC miał DEC-20 w sieci ARPANET, co umożliwiało głównym ośrodkom akademickim i badawczym DEC-20 bezpośrednią komunikację z inżynierami TOPS-20, wysyłanie raportów o błędach lub poprawek pocztą elektroniczną, przesyłanie plików i tak dalej. Lista mailingowa ARPANET menedżerów TOPS-20 została utworzona przez Marka Crispina na Uniwersytecie Stanforda. Lista mailingowa obejmowała programistów TOPS-20 z DEC i zawierało wiele przydatnych informacji, które pozwalały ominąć uciążliwą procedurę SPR.

Lokalnie nasze własne DEC-20 otrzymały interfejsy Ethernet NIA20, które zastąpiły niewygodne i przewymiarowane fronty DN20. Ethernet umożliwił nam współpracę protokołu TCP/IP z DECnet i wkrótce [około 1982 r.] istniała duża sieć Ethernet obejmująca cały kampus, łącząca centrum komputerowe DEC-20 z systemami wydziałowymi w całym kampusie i poza nim, dzięki Internetowi wydziału informatyki członkostwo [1982?], a później [1984?], nasze własne członkostwo w innych rozległych sieciach opartych na protokole TCP/IP, takich jak NYSERNET i JVNCNET. Ethernet i TCP/IP pozwoliły nam nawet odrzucić nasze łącze HASP RJE do komputerów mainframe IBM, które do tej pory znajdowały się w sieci Ethernet i uruchamiały kod TCP/IP z Uniwersytetu Wisconsin (później włączony przez IBM do własnej linii produktów).

[ Góra ] [ Następny ] [ Poprzedni ]

KERMIT

U szczytu popularności DEC-20 zapotrzebowanie wśród studentów i wykładowców na identyfikatory użytkowników było tak duże, że nie mogliśmy już sobie pozwolić na wydawanie identyfikatorów wieczystych. Zamiast tego identyfikatory instruktorskie były przydzielane dla poszczególnych kursów, a następnie usuwane na koniec każdego semestru. Mimo że kopie zapasowe plików były skrupulatnie kopiowane na taśmie, studentom nie wolno było prosić o przywrócenie plików z poprzedniego semestru ze względu na ograniczoną pojemność napędu taśmowego i zasięg operatora. Nawet w trakcie semestru miejsce na dysku studentki (35 KB — K, a nie M czy G!) często nie wystarczało, aby wszystkie jej pliki były dostępne online w tym samym czasie.

Gdyby użytkownicy DEC-20 posiadali jakiś nośnik wymienny, mogliby przejąć odpowiedzialność za zarządzanie i archiwizację własnych plików. Nasze pierwsze wysiłki w tym obszarze dotyczyły mało znanego produktu o nazwie DN200, zdalnej stacji DECnet, która pierwotnie została zaprojektowana do podłączenia 32 terminali i drukarki liniowej do DEC-20 (produkt ten nigdy nie został do końca dojrzały). DN200 był PDP-11/34 obsługującym jakąś pochodną RSX. Nasz — jedyny w swoim rodzaju — zawierał 8-calowy napęd dyskietek. Nasz plan zakładał napisanie oprogramowania DN200 do kopiowania plików pomiędzy dyskietkami a systemem plików DEC-20. Użytkownicy po prostu wkładali własne dyskietki i wydawali polecenia COPY, aby zapisać lub przywrócić swoje pliki. Na szczęście projekt ten nigdy nie ujrzał światła dziennego.

Ale pomysł nośników wymiennych wydawał się słuszny. Użytkownicy komputerów mieli to od lat w postaci kart, taśmy papierowej, a nawet własnych, nieodpartych, małych, obracających się tam i z powrotem taśm DEC firmy DEC, takich jak urządzenie PDP-8, -9, -10, -11, - 12 itd. i bardzo brakuje -20. Rozważano i odrzucano wiele szalonych planów: umożliwienie użytkownikom wysyłania plików do dziurkacza karty komputera mainframe IBM, umieszczenie 9-ścieżkowego „samoobsługowego” napędu taśmowego w miejscu publicznym, napisanie programu, który konwertowałby dane użytkownika na kody kreskowe dla druk na naszych drukarkach Printronix...

Mniej więcej w tym czasie (1980) na scenie pojawiły się 8-bitowe mikrokomputery CP/M. Nawet jeśli nie nadawały się do niczego innego, potrafiły się komunikować oraz czytać i zapisywać dyskietki. Umieść kilka z nich w miejscach publicznych, podłącz je do DEC-20, a uczniowie będą mieli swoje nośniki wymienne — małe dyskietki, które będą mogli zabrać ze sobą, przechowywać i wykorzystywać ponownie bez konieczności polegania na personelu centrum komputerowego. Najważniejszym pytaniem było, jak przenieść plik z dużego komputera mainframe z podziałem czasu na mały komputer osobisty.

Przyjrzeliśmy się rynku i zobaczyliśmy, że istnieje kilka komercyjnych pakietów komunikacyjnych RS-232 dla mikroprocesorów, ale żaden nie jest przeznaczony dla DEC-20. Martwiliśmy się nie tylko komputerami DEC-20 i mikro, ale także naszymi komputerami mainframe IBM. Gdybyśmy kupili oprogramowanie do przesyłania plików pomiędzy DEC-20 a Intertec Superbrain(był to mikro, który wybraliśmy, głównie ze względu na jego konstrukcję przypominającą czołg, odporną na użytkownika i pomimo swojej głupiej nazwy), zakładając, że byłby dostępny, musielibyśmy kupić kolejny pakiet oprogramowania dla naszych użytkowników komputerów mainframe IBM, aby zrobili to samo. Musieliśmy również wziąć pod uwagę, że Superbrain może nie być mikro wyborem dla każdego. Kolumbia, będąca organizacją wysoce zdecentralizowaną i zróżnicowaną, prawdopodobnie miała tyle różnych rodzajów komputerów, ile było miejsc, w których można je było umieścić. Jeśli do połączenia każdej unikalnej pary systemów potrzebny byłby oddzielny pakiet oprogramowania, potrzebowalibyśmy prawie n -kwadratowych odrębnych pakietów, gdzie n jest liczbą różnych rodzajów systemów komputerowych, z wystarczającą liczbą kopii, aby pokryć każdą instancję każdego system.

O wiele lepiej jest mieć jeden pakiet oprogramowania na każdym komputerze, pakiet umożliwiający wymianę danych ze wszystkimi pozostałymi komputerami. Zmniejsza to liczbę wymaganych programów do n , co z kolei odciąża budżet i ułatwia życie użytkownikowi.

Wszystkie te pytania zaowocowały decyzją o inwestycji we własnych programistów, a nie w firmy produkujące oprogramowanie. W ten sposób moglibyśmy mieć oprogramowanie zaprojektowane specjalnie dla naszych własnych potrzeb. Efektem końcowym był protokół przesyłania plików Kermit. Nasze pierwsze programy Kermit zostały napisane dla DEC-20 i Superbrain. Superbrains umieszczono w miejscach publicznych, aby umożliwić uczniom kopiowanie własnych plików na dyskietki i późniejsze przywracanie ich na DEC-20.

Na protokół Kermita duży wpływ miały ograniczenia DEC-20. DEC-20 z interfejsem PDP-11/40 został zaprojektowany przy założeniu, że wejście terminala pochodzi bezpośrednio od osób siedzących przy klawiaturze i piszących palcami ze stosunkowo małą szybkością — może 10 znaków na sekundę, góra — podczas gdy duże pewna ilość trwałego sygnału wyjściowego może zostać przesłana z komputera na ekran. Dlatego RSX20F, system operacyjny frontonu, przydziela małe bufory na wejściu i duże na wyjściu. Przekonaliśmy się o tym na własnej skórze, kupując nasze pierwsze terminale wyposażone w funkcję „ekranu nadawczego” (HDS Concept-100s). Gdy tylko ktoś tego spróbował, przód się rozbił. Podobne zjawiska zaobserwowano przy klawiszach autorepeat (jak wtedy, gdy jeden z naszych programistów zasnął na klawiaturze)( 5) i ponownie, gdy DEC po raz pierwszy wypuścił swój terminal VT100 : podczas płynnego przewijania z szybkością 9600 bps terminal przytłoczył kiepski interfejs XOFF i XON. Późniejsze wydania RSX20F radziły sobie z tymi problemami w drakoński sposób — jeśli bufory wejściowe nie mogły być przydzielone wystarczająco szybko, interfejs ustawiał prędkość linii na zero na sekundę lub dwie! Lekcja? Nie wysyłaj ciągłych impulsów danych terminala do DEC-20 — to jakby próbować nakłonić wróbla do zjedzenia bohatera klopsików. Dlatego zwykłe pakiety Kermita są dość krótkie, maksymalnie 96 znaków — nasiona, owady i robaki, które może strawić wróbel.

Kolejną osobliwością DEC-20 jest jego wrażliwość na sterowanie postaciami. Podczas normalnego okna dialogowego terminala 17 z 33 znaków kontrolnych ASCII jest używanych do specjalnych celów — edycji, przerywania programu, kontroli przepływu, raportowania stanu, sygnalizowania końca pliku itp. — zamiast być akceptowane jako dane. Chociaż program DEC-20 może otworzyć terminal w „trybie binarnym”, aby ominąć specjalne przetwarzanie tych znaków, nie jest to koniecznie pożądane, ponieważ niektóre z tych funkcji mogą być przydatne podczas przesyłania danych. Lekcja z tego jest taka, że podczas przesyłania danych nie należy wysyłać znaków kontrolnych „nagich”. W rzeczywistości protokół Kermita (w swojej najbardziej podstawowej konfiguracji) wysyła pakiety składające się z krótkich linii tekstu.

Komputer mainframe IBM (do tego czasu 360/91 został zastąpiony przez 4341 z systemem operacyjnym VM/CMS) miał swój własny zestaw osobliwości. W przeciwieństwie do DEC-20, wykorzystywał komunikację półdupleksową i 7 bitów danych z parzystością podczas komunikacji z zewnętrznym światem ASCII. Oznaczało to, że nasz protokół przesyłania plików również musiałby być półdupleksowy i wymagałby specjalnego mechanizmu do przesyłania 8-bitowych danych binarnych za pośrednictwem 7-bitowego łącza komunikacyjnego. Co więcej, ponieważ cała komunikacja odbywała się albo przez interfejs front-end 3705 (tryb liniowy), albo przez konwerter protokołu IBM Series/1 (lub jego odpowiednik, np. 7171 lub 4994) 3270, w obu przypadkach wiele znaków sterujących traktowano jako polecenia do natychmiastowego wykonania, wzmocniono zakaz stosowania samych znaków kontrolnych w danych. Sprowadzenie protokołu do najmniejszego wspólnego mianownika sprawiło, że zadziałał on we wszystkich przypadkach, ale kosztem wydajności i elegancji. Niektóre z wynikających z tego niedociągnięć naprawiono w późniejszych latach poprzez dodanie do protokołu długich pakietów i pełnodupleksowego transportu pakietów w przesuwanym oknie, a także opcji „bez prefiksu” znaku kontrolnego.

Szczęśliwym zbiegiem okoliczności połączone dziwactwa DEC-20, komputera mainframe IBM i mikrokomputera CP/M zaowocowały projektem, który można dostosować do praktycznie każdego komputera zdolnego do komunikacji asynchronicznej. Plik został po raz pierwszy przesłany za pomocą protokołu Kermit 29 kwietnia 1981 r. przez dwie instancje Kermit-20 działające na jednym DEC-20, przy użyciu dwóch portów szeregowych połączonych kablem zerowego modemu.

Pomysł udostępnienia naszych programów Kermit i udostępnienia kodu źródłowego był naturalnym następstwem naszych doświadczeń ze społecznością stron DEC-10/20. Otrzymaliśmy tak wiele własnego oprogramowania z innych witryn, że było to sprawiedliwe. Umieściliśmy Kermita na naszych taśmach eksportowych i przesłaliśmy go do DECUS. DEC była pierwszą firmą, która uznała Kermit za narzędzie o powszechnej wartości i opublikowała go w swoich ulotkach i biuletynach dotyczących dużych systemów (np. Copy-N-Mail , Large Systems News i EDU). DEC był pierwszą organizacją, która przeniosła Kermita na nową platformę — VT-180 CP/M micro. Ponieważ chcieliśmy, aby oprogramowanie Kermit było udostępniane w sposób otwarty, nie umieściliśmy naszych programów Kermit w domenie publicznej. Choć może się to wydawać sprzeczne, uważaliśmy, że zapewniając prawa autorskie do programów, możemy zapobiec ich wykorzystywaniu przez przedsiębiorców i sprzedawaniu ich jako produktów komercyjnych, co wydawało się konieczne, ponieważ słyszeliśmy historie o innych uniwersytetach, którym zakazano korzystania z programów, które same zostały napisane przez firmy, które przejęły ich dzieła z domeny publicznej i objęły je prawami autorskimi dla siebie.

Ze względu na powszechną dystrybucję wczesnych programów Kermita, wraz z kodem źródłowym i specyfikacją protokołu, strony posiadające inne rodzaje komputerów zaczęły pisać własne programy Kermita i wysyłać je do nas. Niektóre z wczesnych wkładów w tym duchu to programy DECsystem-10 i VAX/VMS Kermit ze Stevens Institute of Technology (napisane w Common Bliss, aby kod mógł być współdzielony pomiędzy TOPS-10, VMS i P/OS), PDP-11 Kermit z Uniwersytetu w Toledo i pierwszy Unixowy Kermit w języku C z naszego własnego działu informatyki. Proces ten trwał przez wiele lat, w wyniku czego powstał duży zbiór programów Kermit, który można dziś znaleźć na stronie internetowej projektu Kermit .

Projekt Kermit firmy Columbia wykorzystywał DEC-20, nasz system CU20B, jako stanowisko testowe, bibliotekarkę i dom sieciowy od samego początku aż do wyłączenia CU20B (naszego ostatniego pozostałego DEC-20) we wrześniu 1988 r. Wydano elektroniczny biuletyn Info-Kermit i wysyłane do osób w sieciach akademickich i korporacyjnych na całym świecie z DEC-20 za pomocą MM, programu pocztowego DEC-20. Ci sami użytkownicy mogą używać MM i innych klientów poczty e-mail do wysyłania zapytań i informacji, a także mogą uzyskiwać dostęp do programów, kodu źródłowego i dokumentacji za pośrednictwem serwerów plików DECnet i TCP/IP DEC-20. Nawet nasze taśmy dystrybucyjne zostały pierwotnie wysłane z naszych DEC-20 w formatach DUMPER, BACKUP i ANSI.

Do około 1985 roku Kermit DEC-20 był „punktem odniesienia”, względem którego wszystkie inne Kermity miały być sprawdzane pod kątem interoperacyjności. Wiele nowych funkcji Kermit zostało dodanych najpierw do Kermita DEC-20 (tryb serwera, makra itp.). Interfejs użytkownika DEC-20 stał się wzorem dla większości programów Kermita, dlatego miliony ludzi używają dziś (niezwykłej symulacji) COMND JSYS DEC-20, nie wiedząc o tym. Długo po tym, jak DEC-20 zniknął ze sceny, programy Kermita na Windows, UNIX, VMS, MS-DOS i wiele innych platform nadal „podtrzymują wiarę”.

Wkrótce po pojawieniu się Kermita, mikrokomputery stały się ważną siłą wraz z wprowadzeniem komputera IBM PC . Komputery PC nagle stały się samodzielnymi, użytecznymi komputerami ogólnego przeznaczenia. W odpowiedzi na pilne prośby ze strony wykładowców Uniwersytetu Columbia, którzy otrzymali pierwsze komputery IBM PC, pospiesznie opracowaliśmy wersję 1.0 programu IBM PC Kermit i odkryliśmy, że Kermit był używany w sposób, którego się nie spodziewaliśmy. Zamiast używać dyskietek komputera do przechowywania plików na komputerze mainframe, użytkownicy wykonywali większość prac związanych z tworzeniem i manipulowaniem plikami na komputerze PC, a następnie wysyłali wyniki do komputera mainframe w celu archiwizacji i udostępniania. Kermit stał się wczesnym modelem przetwarzania rozproszonego.

[ Strona główna projektu Kermit ] [ Problemy z wiadomościami Kermit ] [ Archiwa list mailingowych Kermit ] [ Archiwa grup dyskusyjnych Kermit ]

[ Góra ] [ Następny ] [ Poprzedni ]

PAKIETY OPROGRAMOWANIA

Duże 36-bitowe systemy DEC były źródłem niektórych z najbardziej wpływowych i trwałych pakietów oprogramowania, jakie kiedykolwiek napisano. Tutaj arbitralnie wymieniamy kilka z naszych ulubionych, przepraszając setki, które zaniedbaliśmy.

Redaktorzy

Najważniejszym spośród programów tworzonych w tych systemach jest edytor tekstu EMACS, stworzony przez Richarda M. Stallmana w oparciu o ITS, „Niekompatybilny system podziału czasu” MIT dla PDP-10. EMACS ucieleśnia rewolucyjną koncepcję, zgodnie z którą ekran terminala powinien działać jak okno, w którym edytowany jest tekst, a wszelkie zmiany w tekście powinny być natychmiast odzwierciedlane na ekranie. Po wielu latach edycji liniowej (a wcześniej wciskania klawiszy) na początku trudno było nam zrozumieć możliwości i wygodę edytora ekranowego. Była nawet dyskusja, czy powinniśmy zezwolić na to w naszym systemie, jakby to był wywrotowy wpływ… „Po co nam to? Każde naciśnięcie klawisza powoduje 37 przełączeń kontekstu!” itp. itp. Ale wkrótce nawet sceptycy zaczęli doceniać EMACS za jego ogromny wzrost produktywności ludzkiej, i szybko stał się ulubionym redaktorem zarówno pracowników, studentów, jak i wykładowców. W Kolumbii narodził się przemysł chałupniczy, polegający na dodawaniu nowych typów terminali i operacji do bazy danych TECO (EMACS DEC-10/20 został napisany w TECO), a także nowych bibliotek dla samego EMACS.

Choć niektórzy mogą dziś uważać EMACS i jego potomków i krewnych za „przestarzałe”, w porównaniu z edytorami GUI i edytorami tekstu, mają one jedną wielką przewagę nad nowszymi edytorami: w całości korzystają ze zwykłych znaków ASCII ( 6) (w przeciwieństwie do klawiszy funkcyjnych lub strzałek, myszy itp.), dzięki czemu osoby piszące na klawiaturze dotykowej nigdy nie będą musiały opuszczać klawiszy Home, a wykwalifikowani użytkownicy EMACS-a będą mogli wprowadzać i manipulować tekstem szybciej niż eksperci z innymi edytorami, szczególnie nowoczesne, ale pracochłonne edytory GUI . A poprzez ograniczenie zestawu poleceń do zwykłych znaków ASCII, EMACS może być używany na dowolnej platformie, bez względu na sposób dostępu do niej (własna klawiatura i ekran stacji roboczej, okno xterm, telnet, dialin, rlogin, ssh itp.). Kolejną zaletą EMACS jest oczywiście jego dostosowywalność i programowalność, ale tylko starsze pokolenia użytkowników komputerów wiedzą lub dbają o takie rzeczy.

Formatory tekstu

EMACS jest edytorem zwykłego tekstu, co oznacza, że sam w sobie nie jest w stanie zwykle generować specjalnych efektów drukarskich, takich jak pogrubienie, kursywa, podkreślenie, zapis matematyczny, różna wielkość czcionki, grafika itp. Do tego potrzebujemy — przynajmniej w świecie znaków terminale — formater tekstu. EMACS był jednym z kilku edytorów ekranowych w DEC-20 (innymi wczesnymi pretendentami były TV i TVEDIT), było też kilka programów formatujących tekst. DEC-20 jest oczywiście wyposażony w RUNOFF, standardowy formater firmy DEC. RUNOFF jest prosty, niezbyt wydajny, ale ma tę zaletę, że pliki RUNOFF są w większości przenośne wśród PDP-11, VAX, DEC-10 i DEC-20. Jednak RUNOFF jest zastrzeżony i dlatego nie jest dostępny w systemach innych niż DEC. RUNOFF ma także trzy podstawowe wady. Po pierwsze, ma ona charakter ściśle proceduralny, co oznacza, że piszący musi zachowywać się jak programista, instruując RUNOFF w najdrobniejszych szczegółach. Po drugie, nie potrafi matematyki. Po trzecie, nie obsługuje szerokiej gamy urządzeń wyjściowych.

Te niedociągnięcia są usuwane przez kilka formaterów tekstu opracowanych przez użytkowników dużych systemów DEC, a co za tym idzie, niektóre z jego mniejszych systemów (na przykład UNIX został pierwotnie napisany dla PDP-7, a później przeniesiony do PDP-11 ; UNIX nroff i troff są prawdopodobnie odgałęzieniami RUNOFF). Wczesne wysiłki w systemach 36-bitowych obejmowały R i Pub.

Brian Reid, pracujący nad systemem DECsystem-10 na potrzeby swojej pracy doktorskiej na CMU, opracował język tworzenia dokumentów o nazwie Scribe, który uwzględniał element proceduralny. Tam, gdzie w RUNOFF trzeba powiedzieć „wyśrodkuj i podkreśl to słowo, zostaw 7 pustych linii, wcięcie 4 spacje itp.”, w Scribe mówi się: „To jest artykuł, tu jest tytuł, tu jest sekcja, tu jest przypis , tutaj jest cytat bibliograficzny, umieść to w indeksie, wstaw tutaj fotografię i przeskaluj ją w ten sposób itp.”, a decyzje stylistyczne i szczegóły pozostawia Scribe, który zawiera obszerną bazę danych typów dokumentów i stylów publikacji. Na przykład, jeśli napisałeś artykuł dla CACM, możesz poprosić Scribe'a o sformatowanie go w stylu wymaganym przez CACM. Kiedy CACM odrzuci, po prostu powiedz Scribe'owi, aby zrobił to ponownie w formacie komputerowym IEEE,7 ).

W trakcie swojego rozwoju Scribe był swobodnie udostępniany innym uniwersytetom, a Brian i użytkownicy na całym świecie wiele dawali i brali. Kiedy jednak Brian opuścił CMU, prawa do Scribe zostały sprzedane prywatnej spółce Unilogic Ltd, która sprzedała ją jako produkt komercyjny ( 8 ). Scribe był stałym elementem wielu witryn DEC-10 i -20 i został przekonwertowany z oryginalnego Bliss na inne języki do użytku w systemach takich jak UNIX, VMS, a nawet komputery mainframe IBM.

W międzyczasie na Uniwersytecie Stanforda Donald Knuth planował nowe wydania swojego wielotomowego dzieła Sztuka programowania komputerowego . Wkrótce jednak odkrył, że od czasu publikacji jego pierwszych wydań sztuka składu matematycznego, podobnie jak kamieniarstwa architektonicznego, umarła: nie mógł znaleźć zecera, który byłby w stanie sprostać temu zadaniu. Przystąpił więc do pracy nad programem komputerowym do składu matematycznego i zestawem harmonijnych czcionek nadających się do komputerowego pobrania na drukarkę laserową. Prace wykonano na komputerze PDP-10 w Uniwersytecie Stanforda, na którym działa ich autorski system operacyjny WAITS („Czeka na ciebie z rąk i nóg”) w języku Sail. W rezultacie powstał system o nazwie TEX (tau epsilon chi) i towarzyszący mu narzędzie do tworzenia czcionek METAFONT przyciągnęły wielu wielbicieli, a oryginalny program Sail został wkrótce przetłumaczony na inne języki, aby ułatwić przenośność. Obecnie działa na wielu różnych platformach i jest odpowiedzialny za produkcję wielu książek i artykułów o niezrównanym pięknie typograficznym.

Zarówno TeX, jak i Scribe obsługują szeroką gamę urządzeń wyjściowych i są jednymi z pierwszych programów formatujących tekst, które to robią. Kiedy firma Xerox pozwoliła kilku swoim drukarkom XGP (eksperymentalna drukarka kserograficzna z czcionkami pobranymi z hosta) uciec do laboratoriów w Stanford, MIT i CMU na początku lat 70-tych, szybko podłączono je do PDP-10 i sterowano nimi formatery, takie jak R i Pub. Ich elastyczność dała impuls ludziom takim jak Don i Brian do uwzględnienia w swoich projektach pełnowymiarowych koncepcji składu i dzięki temu możliwe było później dodanie obsługi TeX i Scribe dla drukarek takich jak GSI CAT-4 (wówczas powszechnie używanych w firmie Bell Labs z Troffem), Xerox Dover, Imagen i dzisiejsze drukarki PostScript (i jeśli się nie mylimy, Brian był także siłą przewodnią stojącą za PostScriptem).

W nowym tysiącleciu Scribe praktycznie zniknął, a szkoda. Ale w pewnym sensie żyje w LaT E X, który jest językiem podobnym do Scribe'a zbudowanym na bazie T E X. Podobnie jak wiele narzędzi z lat 70. i 80., Scribe, T E X i LaT E X (oraz, na przykład, to ważne, EMACS) wymagają sporo nauki, aby zacząć, ale warto, ponieważ gdy już poczujesz się w nich komfortowo, możesz przewyższyć wszystkich!

Poczta elektroniczna

Nie trzeba wychwalać zalet poczty elektronicznej, ale był czas, kiedy ludzie z niej nie korzystali i nie ufali jej. Dziś wielu z tych samych ludzi nie może bez tego żyć. Jego główną zaletą jest to, że umożliwia osobom biorącym w nim udział wygodną komunikację i pewność, że wiadomość zostanie odebrana. W przeciwieństwie do poczty tradycyjnej, pocztę elektroniczną można wysłać pod wpływem chwili, a pojedynczą wiadomość można wysłać do więcej niż jednej osoby naraz. W przeciwieństwie do rozmów telefonicznych, poczta e-mail nie jest uzależniona od obecności odbiorcy podczas wysyłania wiadomości. Są tacy, którzy twierdzą, że to odczłowieczający wpływ, że ludzie w sąsiednich biurach, którzy kiedyś odwiedzali się i rozmawiali, teraz siedzą przyklejeni do ekranów i wysyłają do siebie e-maile, wiadomości, których prawdziwych intencji nie można wywnioskować z wyrazu twarzy, mowa ciała, lub ton głosu. Może to być prawdą, ale poczta e-mail pozostanie na stałe i większość ludzi znajdzie sposób, aby w rozsądny sposób dopasować ją do swojego życia.

Chociaż poczta elektroniczna była dostępna do użytku w komputerze od wczesnych lat sześćdziesiątych XX wieku (np. w systemie współdzielenia czasu CTSS MIT), poczta elektroniczna między komputerami rozpoczęła się 20 grudnia (lub, ściśle mówiąc, KL-10 z systemem TENEX, „proto-TOPS-20”) w BBN w Cambridge w stanie Massachusetts w 1972 r., kiedy Ray Tomlinson z BBN zaadaptował swój program pocztowy TENEX do wysyłania wiadomości do innych węzłów ARPANET. Wiązało się to nie tylko z nowym oprogramowaniem i protokołami, ale także z nową notacją: wszechobecnym obecnie formatem adresu użytkownik @ host .

Jeśli wykonałeś SYSTAT dowolnego DEC-20 w Kolumbii pomiędzy 1978 a 1988 rokiem, zobaczyłbyś, że około połowa użytkowników korzysta z EMACS-a, a druga połowa z MM, z okazjonalnymi przerwami na formatowanie tekstu, kompilację programów, przesyłanie plików i inne rodzaje „prawdziwej pracy”. MM to Menedżer poczty, pierwotnie napisany przez Mike'a McMahona, a później przejęty przez Marka Crispina. Jest to strona „klienta użytkownika” systemu pocztowego. MM to zwykły program dla nieuprzywilejowanych użytkowników, który pozwala czytać pocztę, tworzyć i wysyłać pocztę do innych użytkowników, przesyłać dalej pocztę i zarządzać plikami pocztowymi. MM umożliwia przenoszenie wiadomości do różnych plików, drukowanie wiadomości, usuwanie ich, oznaczanie ich do późniejszego wykorzystania i tak dalej.

Każda operacja, którą MM może wykonać na pojedynczej wiadomości, może również zostać zastosowana do sekwencji wiadomości. Jest to jedna z najpotężniejszych funkcji MM. Funkcje wyboru wiadomości MM pozwalają traktować plik pocztowy prawie jak bazę danych i wysyłać złożone zapytania, takie jak „pokaż mi (lub odpowiedz, usuń, prześlij dalej, oznacz lub wydrukuj) wszystkie wiadomości od tak a tak wysłanych pomiędzy takimi a takimi datami, które są dłuższe niż określona liczba znaków i zawierają w temacie słowo „foo”.

MM jest niezwykle potężny, ale jest także łatwy w użyciu, ponieważ w pełni wykorzystuje COMND JSYS. Użytkownicy mogą w dowolnym momencie dowiedzieć się, czego się spodziewać, wpisując znak zapytania (z wyjątkiem tworzenia tekstu wiadomości, w którym to przypadku znak zapytania staje się częścią tekstu). Istnieje polecenie SET, które pozwala dostosować wiele operacji MM i zmienić jego domyślne działania. Użytkownicy mogą zapisać te dostosowania w pliku inicjującym, dzięki czemu będą one dokonywane automatycznie przy każdym uruchomieniu MM.

MM został szybko przyjęty na korzyść MAIL i RDMAIL DEC-20 i początkowo był używany przez personel programistyczny. Jego zastosowanie szybko rozprzestrzeniło się na studentów i wykładowców, do tego stopnia, że kilka kursów całkowicie od niego zależało. Zadano zadania domowe i lektury, przeprowadzono konferencje, oddano zadania, zadano pytania i udzielono na nie odpowiedzi, a wszystko to z MM. MM służy także do publikowania wiadomości na publicznych „tablicach ogłoszeń”, które wykorzystywano do wszystkiego, od sprzedaży używanych motocykli, przez quizy o ciekawostkach, po szalejące kontrowersje na tematy polityczne.

W Columbii wiele wydziałów jest rozmieszczonych w różnych budynkach, na terenie kampusu i poza nim. Działy te były idealnymi kandydatami na pocztę elektroniczną, a wiele z nich na co dzień prowadziło działalność za pomocą MM. MM równie dobrze czuje się w środowisku sieciowym. Mając odpowiednie połączenia sieciowe i agenta doręczającego, MM może być — i jest — używany do przesyłania poczty elektronicznej na cały świat szybciej, niż jakakolwiek poczta lub firma kurierska byłaby w stanie dostarczyć papier. Z Kolumbii wysyłamy e-maile do tak odległych miejsc, jak Utah, Anglia, Norwegia, Australia, Brazylia, Japonia, Chiny i ZSRR, a odpowiedzi otrzymujemy w ciągu kilku minut (zakładając, że nasi korespondenci pracują w tych samych nieparzystych godzinach, co my). Do!).

Postscriptum z maja 2003 r.: Dopiero kolejna dekada sprawiła, że poczta elektroniczna stała się bardziej przekleństwem niż błogosławieństwem, a każdego użytkownika komputera zasypano śmieciami i/lub złośliwymi wiadomościami e-mail, zwanymi „spamem”. DEC-20 również był pionierem w tej dziedzinie: pierwszy spam został wysłany 1 maja 1978 r. 1233-EDT z DEC-MARLBORO.ARPA (a DEC-20) do wszystkich kontaktów ARPANET (z bazy danych WHOIS), reklamując nowe Modele DEC-20.

W 2015 roku Columbia zleciła Google obsługę poczty e-mail.

[ Góra ] [ Następny ] [ Poprzedni ]

INNE WAŻNE WKŁADY

Architektura DEC-20 tak naprawdę sięga połowy lat sześćdziesiątych XX wieku, czasów PDP-6 firmy DEC, który został zaprojektowany z myślą o LISP-ie - półsłowa i powiązane instrukcje są idealne dla CAR i CDR (to jest mowa LISP, wywodząca się z zestawu instrukcji IBM 704, gdzie po raz pierwszy opracowano LISP). Większość dużych wdrożeń LISP-a została wykonana dla 36-bitowych maszyn DEC — MACLISP, INTERLISP — a wśród opartych na nich aplikacji, MACSYMA z MIT wyróżnia się jako punkt orientacyjny. MACSYMA jest używana przez naukowców i inżynierów do manipulowania wyrażeniami matematycznymi o dowolnej złożoności na poziomie symbolicznym, a nie numerycznym. Istnieje jedna słynna (być może apokryficzna) opowieść o XIX-wiecznym astronomie-matematyku, który poświęcił swoje życie na sformułowaniu dokładnego równania ruchu Księżyca. W rezultacie zapełniono 300-stronicową książkę.

W 1971 roku Ralph Gorin z Uniwersytetu Stanforda napisał pierwszy znany komputerowy moduł sprawdzania pisowni tekstu, SPELL for TOPS-10. Został później dostosowany do DEC-20 i „połączony” z pakietami takimi jak EMACS i MM. Potomków SPELLA jest mnóstwo — żaden szanujący się program do edycji tekstu na komputery PC nie pojawiłby się publicznie bez korektora ortografii.

[ Góra ] [ Następny ] [ Poprzedni ]

KONWERSJA NA UNIX

[Pamiętajcie: ten dokument powstał w 1988 r.]

„ Płynna żegluga przez lata 80-te…” Pod koniec lat 80. popyt na usługę DEC-20 ustabilizował się, a następnie zaczął spadać. DEC-20 przypominał kliper i był najwyższym wyrazem technologii, która przez wielu była uważana za przestarzałą — dużego centralnego komputera z podziałem czasu Studenci byli teraz gotowi zrezygnować z udogodnień DEC-20 na rzecz kontroli i przewidywalności własnego komputera PC. Dzięki członkostwu Columbii w konsorcjum Apple University Consortium wkrótce w rękach studentów znalazły się tysiące komputerów Macintosh. Specjalne ustalenia z IBM umieścili także komputery IBM PC w setkach biur i pokojów w akademikach. Systemy te zaspokajały potrzeby studentów w zakresie drobnych zadań programistycznych w językach Pascal i Basic, a także skromnego przetwarzania tekstu i odciążały systemy centralne od dużego obciążenia. Jednak komputery PC nie spełniały na potrzeby Wydziału Informatyki i innych wydziałów inżynierskich,gdzie większe projekty były przydzielane w językach takich jak Fortran, C, Prolog i Lisp, które nie były łatwo i niedrogo dostępne dla komputerów PC.

W międzyczasie UNIX przejął kontrolę nad światem komputerów — na komputerach typu mainframe, mini, stacjach roboczych, a nawet komputerach PC. Nasza główna grupa użytkowników dydaktycznych — studentów CS — wykonywała większość swojej pracy na wydziałowych komputerach ATT 3B2, ale bardzo potrzebowała scentralizowanego, niezawodnego środowiska z akceptowalną wydajnością, kopiami zapasowymi, obsługą i całą resztą. Już od kilku lat korzystaliśmy z systemu UNIX na VAX 750 (do wewnętrznych prac programistycznych), a także Amdahl UTS na komputerze mainframe IBM, więc zdobyliśmy pewną wiedzę na temat UNIX-a.

Z tych powodów zdecydowaliśmy, że nadszedł czas, aby rozpocząć konwersję z TOPS-20 na UNIX. Ze względów finansowych wybraliśmy do tego celu VAX 8650. Transakcja z 20 grudnia była atrakcyjna i udało nam się zatrzymać nasze stare napędy dysków i taśm. Tak naprawdę doszliśmy do wniosku, że w ciągu 3 lat zakup VAX-a był tańszy niż trzymanie DEC-20. Był też potężniejszy, miał większą przestrzeń adresową i zajmował mniej miejsca niż DEC-20, który zastąpił.

VMS nie został wybrany z kilku powodów. Po pierwsze, poczuliśmy się nieco zdradzeni porzuceniem przez DEC TOPS-20 i nie chcieliśmy narażać się na takie samo traktowanie w przyszłości. UNIX, w przeciwieństwie do VMS, nie wiąże Cię z konkretnym dostawcą. Co więcej, UNIX oferuje sieci i komunikację dla wszystkich naszych głównych wymagań: Ethernet, TCP/IP, DECnet (nasz początkowy UNIX to Ultrix-32), BITNET (UREP), terminale RS-232 i LAT, Kermit. Sam UNIX ma wiele zalet: bardzo wydajne środowisko tworzenia aplikacji dla doświadczonych programistów, programowalną powłokę, potok programów, proste, ale potężne narzędzia.

UNIX jest jednak notorycznie zwięzły, tajemniczy i nieprzyjazny, zwłaszcza dla początkujących użytkowników komputerów. VMS, choć pozbawiony COMND JSYS z DEC-20, jest z pewnością bardziej przyjazny niż UNIX i aż do przesady gadatliwy. Dlatego nie bez obaw przystąpiliśmy do nawrócenia.

Wielu z nas, użytkowników DEC-20, było odpornych na zmiany. Znajomość, na dobre i na złe, jest często bardziej atrakcyjna niż niepewność. Jednak konwersja na UNIX zmusiła nas do rezygnacji z niektórych funkcji, które pierwotnie przyciągnęły nas do DEC-20.

„Przyjazna dla użytkownika” powłoka dostarczana przez TOPS-20 Exec, która zapewnia pomoc tym, którzy jej potrzebują, ale nie karze doświadczonych użytkowników, to prawdopodobnie cecha, której najbardziej brakowało. W systemie UNIX większość poleceń to programy, co do których zakłada się, że mają argumenty składające się wyłącznie z opcji lub nazw plików. Oznacza to, że nie możesz mieć znaku „?” dla poleceń i argumentów w powłoce, ponieważ programy, które miałyby zareagować na żądanie pomocy, nawet jeszcze nie zaczęły działać. Jest to przeciwieństwo TOPS-20, w którym większość głównych funkcji jest wbudowana w plik exec, ale który nie pozwala na łączenie zwięzłych programów składających się z bloków konstrukcyjnych, tak jak robi to UNIX.

Aby przytoczyć przykład radykalnej różnicy między filozofią TOPS-20 i UNIX, załóżmy, że chcesz utworzyć procedurę, która utworzy listę katalogów, posortuje ją w odwrotnej kolejności według rozmiaru pliku i sformatuje listę na ponumerowane strony z trzema kolumnami na każdej strona nadająca się do druku. W TOPS-20 spędziłbyś tydzień na pisaniu programu w języku asemblera, który zrobiłby to wszystko. W systemie UNIX narzędzia już tam są i należy je jedynie połączyć w pożądany sposób:

ls -s | sortuj -r | pr -3

Dzięki temu UNIX wygląda całkiem atrakcyjnie. Ale program DEC-20 po napisaniu będzie zawierał wbudowaną pomoc, uzupełnianie poleceń i nazw plików itp., podczas gdy procedura UNIX może być używana tylko przez tych, którzy dokładnie wiedzą, co robią. Jeśli wpisałeś „ls -s | sort”, ale nie wiesz, jaka jest odpowiednia opcja sortowania, wpisanie w tym miejscu znaku zapytania nic nie da, ponieważ program sortujący nie jest jeszcze uruchomiony.

DEC-20 (podobnie jak większość popularnych systemów operacyjnych) używa poleceń i nazw plików niezależnych od wielkości liter. Jednakże zależność od wielkości liter jest cechą systemu UNIX, której stanowczo bronią jego zwolennicy. Może to być dość mylące dla użytkowników innych systemów operacyjnych. Ogólnie rzecz biorąc, polecenia UNIX bardzo różnią się od poleceń używanych w innych systemach. Nawet gdyby DEC-20 nie oferował pomocy w postaci menu na żądanie, przeciętny użytkownik prawdopodobnie odgadłby właściwe polecenia do wpisania — DELETE, aby usunąć plik, COPY, aby skopiować plik, ZMIEŃ NAZWĘ, aby zmienić nazwę pliku itp. Jak w systemie UNIX usunąć plik? USUWAĆ? Nie.... USUNĄĆ? Nie, to „rm” (tylko małe litery!).

Bez instrukcji pod ręką, jak możesz się tego dowiedzieć? Nawet jeśli wiedziałeś o „man -k” (wyszukiwanie słów kluczowych w podręczniku online), UNIX nie daje ci zbyt wiele pomocy: „man -k usuń” nie wyświetla niczego istotnego, podobnie jak „man -k usuń” . Ale przynajmniej „rm” w pewnym stopniu sugeruje słowo „usuń” i rzeczywiście „man -k usuń” odkryłoby nieuchwytne polecenie (wczesne wersje UNIX-a miały jeszcze bardziej nieuchwytną nazwę tego polecenia: dsw, skrót od „do swedanya”, rosyjskie na pożegnanie, przetłumaczone na polski lub może niemiecki; to nie jedyne miejsce, w którym cenzor zadziałał… Obecne „standardowe” wersje UNIX-a nie mają polecenia „pomoc”, ale w wcześniejsze wydania,

Ja (fdc) nie pamiętam, gdzie wykopałem wzmiankę o „do swedanya”, ale najwyraźniej jest to miejska legenda. Dennis Ritchie powiedział w poście w Usenecie z 1981 r., że rzeczywista etymologia brzmi „usuń z przełączników”; oryginalny program dsw PDP-7 był prekursorem „rm -i” (usuń interaktywnie), w którym przełączniki procesora zapewniały interakcję.

Szczególną zaletą TOPS-20 jest przechowywanie wielu generacji (wersji) każdego pliku, co daje możliwość przywrócenia wcześniejszej wersji, jeśli najnowsza ucierpi z powodu ludzkiego błędu, szaleństwa lub tragedii. To, w połączeniu z możliwością przywrócenia pliku po jego usunięciu, daje poczucie komfortu i bezpieczeństwa, które można docenić dopiero po przejściu na bardziej konwencjonalny i niepewny system plików. Jeśli usuniesz plik w systemie UNIX lub utworzysz nowy plik o tej samej nazwie, co istniejący, stary plik po prostu zniknie. Polecenie „rm *” w systemie UNIX jest po prostu zbyt potężne i zbyt ciche. Tak, zrobił to, co powiedziałeś, ale skąd wiedział, że miałeś na myśli to, co powiedziałeś? UNIX nie chroni użytkowników przed nimi samymi.

Kolejną ważną cechą TOPS-20 jest logiczna nazwa urządzenia, którą można definiować w nieskończoną różnorodność dla systemu jako całości, jak i dla każdego indywidualnego użytkownika. Każda nazwa logiczna może wskazywać na konkretne urządzenie i/lub katalog lub całą ich serię, które należy przeszukiwać w określonej kolejności. Są one wbudowane w sam system operacyjny, podczas gdy pojęcia PATH i CDPATH są przemyślane, wszczepione w powłokę UNIX, niedostępne z poziomu programów i nie mają zastosowania poza ich ograniczonymi sferami działania.

Następnie mamy języki programowania, które nie byłyby już dostępne — ALGOL (60 i 68), APL, BASIC, BCPL, BLISS (10, 11 i 36), CPL (i „prawdziwy” PL/I), ECL, FOCAL , PPL, SAIL, SIMULA, SNOBOL, ... I TECO! Oraz MACRO, Midas i Fail... Tak naprawdę niewiele osób przeoczy którekolwiek z nich, z możliwymi wyjątkami APL (używanego w niektórych klasach) i SNOBOL (które nadal można znaleźć dla UNIX-a na wybranych platformach).

Oczywiście wszystkie nasze własne aplikacje napisane w języku asemblera musiały zostać przerobione dla systemu UNIX: wprowadzanie identyfikatorów użytkowników i zarządzanie nimi (w przeciwieństwie do edycji pliku passwd), księgowość, ograniczenia użytkowników (ACJ, Omega). Jedną z funkcji, bez której nie moglibyśmy się już obejść, jest MM, potężny system zarządzania pocztą, z którego mogą korzystać zarówno nowicjusze, jak i eksperci.

Pozytywną stroną jest to, że nie rezygnowalibyśmy z EMACS, Scribe, TeX, Kermit ani narzędzi TCP/IP Telnet i FTP. Wszystkie te programy są dostępne w jakiejś formie dla systemu UNIX. Niektóre implementacje UNIX-a stanowią zdecydowane ulepszenia, jak na przykład GNU EMACS z Free Software Foundation, bez ograniczeń pamięciowych TOPS-20 EMACS. Dostępny jest również wysokiej jakości Fortran firmy DEC dla naszych inżynierów i oczywiście całe środowiska programistyczne C i LISP dla studentów CS i innych twórców oprogramowania, a także zestaw potężnych narzędzi do manipulacji tekstem, takich jak sed, grep, awk, lex i yacc , których funkcje powinny być oczywiste z ich nazw.

Instalacja VAX była znacznie szybsza niż typowa instalacja DEC-20. Wydajność 8650 była dość żwawa, a jego niezawodność doskonała. Po roku model 8650 został sprzedany, a drugi DEC-2065 został sprzedany firmie DEC za VAX 8700. Model 8700 ma mniej więcej taką samą moc jak model 8650, ale w przeciwieństwie do modelu 8650 jest kompatybilny z nowymi urządzeniami BI, i można go rozbudować do większego modelu VAX, gdyby zabrakło mu pary.

Okazało się jednak, że gdy przyszedł czas na rozbudowę, bardziej opłacalne było kupienie systemów Sun UNIX niż modernizacja 8700 do większego VAX. Jest to wybór, którego nie można uzyskać w przypadku zastrzeżonego systemu operacyjnego, takiego jak TOPS-20, VMS itp. Konwersja z VAX na SUN wymaga pewnego „poddania się” (np. DECnet), ale nie tak bardzo, jak podróż z DEC -20 do VAX, a w zamian otrzymujesz bardzo potężną maszynę zajmującą ułamek powierzchni VAX — taką, jaką powinien być Jupiter, ale z UNIXem zamiast TOPS-20.

[ Góra ] [ Następny ] [ Poprzedni ]

GŁÓWNE PROBLEMY Z KONWERSJĄ

[Pamiętajcie: to zostało napisane w 1988 r.]

Najważniejszym pytaniem podczas konwersji na UNIX była edukacja użytkowników. UNIX nie pomaga użytkownikom tak jak TOPS-20. Nie ma stylu COMND? pomocy, nie ma nawet polecenia „pomoc”. Same polecenia nie mają intuicyjnych nazw: użytkownikowi trudno będzie odgadnąć, że „mv” to polecenie zmiany nazwy pliku, „cat” polecenia wpisania pliku itp. Skąd użytkownicy będą wiedzieć, jak zareagować na wyciszenie „$” (lub „%”) patrząc im w twarz? Czy powinniśmy napisać dla nich przyjazną dla użytkownika powłokę? A może mnóstwo tutoriali i podręczników?

Mimo całej swojej tajemniczej zwięzłości, UNIX stał się bardzo popularny. Systemy UNIX działają na komputerach wszelkiego rodzaju, od komputerów stacjonarnych po superkomputery. W związku z tym księgarnie komputerowe są zapełnione książkami typu „Teach Yourself UNIX”. Nasze poczucie było takie, że niezależnie od tego, jak tajemniczy i nieprzyjazny może być sam UNIX, nie należy go zmieniać. W przeciwnym razie stracimy kompatybilność z innymi systemami UNIX, książkami i artykułami, narażamy się na koszmar konserwacji i pozwalamy naszym użytkownikom na niemiłą niespodziankę, jeśli kiedykolwiek zetkną się z prawdziwym systemem UNIX.

Kolejną kwestią jest system pocztowy. Jako agent poczty na poziomie użytkownika masz do wyboru pocztę UNIX lub GNU EMACS RMAIL. Poczta UNIX jest prymitywna i nieintuicyjna, a RMAIL jest dostępny tylko dla tych, którzy znają EMACS. Zaletą RMAIL jest spójny interfejs — brak konieczności wchodzenia i wychodzenia z edytora — ale ma stosunkowo ograniczony repertuar poleceń.

Nasi użytkownicy przyzwyczaili się do poczty elektronicznej, głównie dzięki możliwościom, wygodzie i przyjazności MM. Wielu największych użytkowników MM to wykładowcy lub administratorzy, którzy nie muszą uczyć się nowego systemu pocztowego. Ale program tak potężny jak MM wymaga wielu poleceń, a gdy masz wiele poleceń, potrzebujesz wbudowanej pomocy, która jest dostępna bezpłatnie w DEC-20. Podobne uwagi dotyczą innych skomplikowanych programów, na przykład (w naszym systemie) programów do wprowadzania i zarządzania identyfikatorami użytkowników, interfejsu operatora (jak OPR w DEC-20) itp.

Z tego powodu zdecydowaliśmy się „przemienić nasz nowy system w nasz ukochany stary”, pisząc pakiet COMND dla systemu UNIX. Pakiet ten, CCMD, powstał jako część projektu „Hermit”, wysiłku badawczego Columbii finansowanego przez DEC, 1983-87. Próbowaliśmy zaprojektować architekturę sieci, która umożliwiłaby różnym rodzajom komputerów PC — IBM, Rainbow, Pro-380, VAXstation, SUN, Macintosh itp. — dostęp do plików i usług naszych komputerów mainframe DEC-20 i IBM w spójny i przejrzysty sposób. Projekt ostatecznie się nie powiódł, ponieważ technologia nas ominęła (tanie połączenia i bramy Ethernet i Token Ring, Sun NFS, serwery plików Macintosh oparte na VAX itp.).

CCMD, napisany w całości w C, wykonuje wszystkie funkcje COMND i więcej, analizuje terminal, plik, przekierowane standardowe wejście lub ciąg znaków w pamięci. Nie jest zorientowany na żadną konkretną klawiaturę ani ekran. Nie faworyzuje ani nowicjusza, ani eksperta. Działa pod kontrolą 4.xBSD, Ultrix, AT&T System V, SunOS i MS-DOS i powinien być łatwo przenośny do VAX/VMS i dowolnego innego systemu z kompilatorem C.

CCMD jest w pełni rozwiniętą implementacją COMND, umożliwiającą łączenie baz FDB (np. analizowanie nazwy pliku, liczby lub daty), przekierowywanie danych wejściowych poleceń i tak dalej. Dodatki do COMND JSYS z DEC-20 obejmują listy pomocy „?” umożliwiające dopasowywanie nazw plików, częściowe uzupełnianie nazw plików (aż do pierwszego znaku, który nie jest unikalny), bardzo elastyczny analizator czasu i daty oraz dodatkowe typy danych.

Używając CCMD, programiści Columbii byli w stanie napisać klon DEC-20 MM w całości w C. Posiada on wszystkie cechy DEC-20 MM i kilka innych. Obsługuje różne formaty plików pocztowych, w tym DEC-20, Babyl (RMAIL) i mbox (poczta UNIX). Używa UNIX sendmail jako systemu dostarczania i powinien być przystosowany do usług dostarczania systemów innych niż UNIX.

Autorzy — i zaskakująca liczba innych osób na całym świecie — nadal używają Columbia MM jako swojego klienta pocztowego (ale, niestety, nie w Columbii od 2015 roku). Można go zbudować i zainstalować na (przynajmniej) Linuxie, FreeBSD, OpenBSD, NetBSD, Solaris i SunOS. Możesz go znaleźć TUTAJ .

[ Góra ] [ Następny ] [ Poprzedni ]

SŁOWA KOŃCOWE...

[Pamiętajcie: to zostało napisane w 1988 r.]

Kolumbia jest wysoce zdecentralizowana i boryka się z ograniczeniami budżetowymi typowymi dla wszystkich instytucji szkolnictwa wyższego. Nie ma centralnego nakazu umieszczania drogich stacji roboczych na każdym biurku, połączonych gigabitowymi sieciami światłowodowymi. Studenci, wykładowcy i pracownicy w większości korzystają z funduszy własnych lub wydziałowych, aby kupić najlepszy komputer PC, jakiego mogą używać, zazwyczaj IBM PC lub Macintosh z interfejsem RS-232. Większość użytkowników komunikuje się sporadycznie za pośrednictwem modemu lub zanosząc dyskietkę do publicznego laboratorium komputerowego, gdzie komputery PC są podłączone do sieci lub drukarki laserowej.

W miarę jak komputery PC stają się tańsze i wydajniejsze, co pozostało do zrobienia centralnie? Są tacy, którzy twierdzą, że wszystko, co potrafi VAX lub DEC-20, można również zrobić na komputerze PC. Jedynymi wyjątkami mogą być bardzo duże aplikacje, współdzielone i/lub duże i/lub stale zmieniające się bazy danych oraz ogólnie komunikacja — sieci rozległe, poczta, współdzielone biblioteki programów, tablice ogłoszeniowe, konferencje itp.

Masowa decentralizacja przetwarzania oznacza jednak ogromne powielanie wysiłków i wydatków związanych ze sprzętem, licencjami na oprogramowanie i konserwacją. Każdy staje się menedżerem systemu, wykonującym kopie zapasowe, rozwiązującym problemy, instalującym i debugującym oprogramowanie, konsultującym, szkolącym i poszukującym części. Naukowcy, którzy niegdyś byli na tropie leku na raka lub AIDS, teraz kręcą przełącznikami DIP, uruchamiają narzędzia Norton na swoich uszkodzonych dyskach twardych i przeglądają ostatnie strony BYTE w poszukiwaniu okazji. Każda osoba lub grupa może posiadać unikalną kolekcję oprogramowania i sprzętu, co znacznie utrudnia nauczanie, współpracę i większość innych funkcji niż w czasach podziału czasu. A miejsce na sprzęt komputerowy należy znaleźć praktycznie w każdym pokoju biurowym i akademiku, a nie w jednym centralnym miejscu. Pewnego dnia, osoby odpowiedzialne za budżet mogą zauważyć skumulowany efekt całego rozproszonego przetwarzania danych i wahadło zacznie się odchylać w drugą stronę. Jak brzmi wyrażenie „ekonomia skali”?…

Kilka lat temu, podczas kryzysu paliwowego, w gazecie pojawił się artykuł o przywróceniu kliprów... Duże systemy DEC, klipery z ery podziału czasu, nigdy nie powrócą, ale będą żyć w oprogramowaniu, które stworzyli — EMACS, TeX, Scribe, Spell, MM, Kermit, zaawansowane dialekty LISP i tak dalej. Tymczasem, gdy przemysł komputerowy stara się przekształcić komputery PC w systemy dla wielu użytkowników oraz wymyślić na nowo przetwarzanie wieloprocesorowe, bezpieczeństwo i inne zapomniane koncepcje, warto zatrzymać się, aby spojrzeć wstecz na ostatnie dziesięciolecia, kiedy koszty i ograniczenia sprzętu komputerowego zmusiły projektantów i programistów do bądź... cóż, mądrzejszy.

[ Góra ] [ Następny ] [ Poprzedni ]

EPILOG

(styczeń 2001)

Dzisiaj, kiedy możesz wejść do zwykłego sklepu i kupić komputer o 10 razy większej mocy (i 100 razy większej pamięci głównej i 1000 razy większej pojemności dysku) największego i najszybszego KL10, jaki kiedykolwiek wyprodukowano, za mniej niż 1000 dolarów, podłącz go do zwykłego gniazdka ściennego i gniazda telefonicznego (lub dekodera telewizji kablowej itp.) i za kilka minut uzyskaj dostęp do Internetu z pełnokolorową grafiką, wideo, dźwiękiem i kto wie, czym jeszcze, możemy łatwo zapomnieć, jak komputery ewoluowały od dużych samodzielne kalkulatory z zapisanymi programami w „komunikatory”. Przynajmniej dla nas, na Uniwersytecie Columbia, zmiana rozpoczęła się od dużych systemów DEC, które udostępniły nam jednocześnie możliwość udostępniania plików, poczty elektronicznej oraz sieci lokalnych i rozległych, otwierając możliwości współpracy i komunikacji w pracy i życiu: w komputerze, na terenie kampusu i na całym świecie.

Sekcja zwłok PDP-10 była długa i bolesna (kto go zabił i dlaczego, jak mógł przetrwać i jak wyglądałby dzisiejszy świat, gdyby tak się stało), ale ci, którzy nadal mogą chcieć rzucić okiem na ekscytujące czasy lat 70. i lata 80., kiedy komputery po raz pierwszy stały się zjawiskiem kulturowym i środkiem komunikacji, dzięki kilku realizowanym projektom emulacji PDP-10 opartym na oprogramowaniu. Być może największą spuściznę tamtych czasów można odnaleźć w dzisiejszym ruchu otwartego oprogramowania, w ramach którego programiści na całym świecie współpracują nad projektami obejmującymi systemy operacyjne (Linux, FreeBSD itp.) po wszelkiego rodzaju aplikacje, podobnie jak oryginalny PDP-10 ARPANET „hakerzy” to zrobili ( czy jest to wykonalny model biznesowy, to osobna kwestia :-)

Tymczasem wielu z nas, którzy przeżyli tę epokę, zachowało swoje stare nawyki, nadal korzystając z aplikacji tekstowych, takich jak EMACS i MM, zamiast ich modnych, ale pracochłonnych zamienników GUI, ale na platformach UNIX, takich jak Linux, zamiast PDP-10. Za każdym razem, gdy nowy wirus komputerowy pogrąża całą planetę w chaosie i panice, ledwo to zauważamy . Jest coś do powiedzenia na temat starych sposobów.