VS/9
Deweloper | Univac |
---|---|
Rodzina OS | OSP |
Stan roboczy | Przerwane |
Model źródłowy | Nieznany |
Pierwsze wydanie | koniec lat 60 |
Platformy | Komputery typu mainframe UNIVAC serii 90 |
Domyślny interfejs użytkownika |
Interfejs linii komend |
Licencja | Prawnie zastrzeżony |
VS/9 to komputerowy system operacyjny dla komputerów mainframe UNIVAC serii 90 (90/60, 90/70 i 90/80), używanych od późnych lat 60. do 80. XX wieku. Komputery 90/60 i 90/70 zostały przepakowane w komputery Univac 9700. Po RCA przez Sperry ustalono, że system operacyjny RCA TSOS był znacznie bardziej zaawansowany niż odpowiednik Univac , więc firma zdecydowała się na połączenie sprzętu Univac z oprogramowaniem RCA i wprowadziła 90/70. 90/60 został wprowadzony wkrótce potem jako wolniejszy, tańszy 90/70. Dopiero po wprowadzeniu 90/80 VS/9 w końcu miał platformę sprzętową zoptymalizowaną tak, aby w pełni wykorzystać jej zdolność do umożliwienia zarówno operacji interaktywnych, jak i wsadowych na tym samym komputerze.
Tło
We wrześniu 1971 roku RCA zdecydowała się wycofać z branży komputerów mainframe po tym, jak straciła około pół miliarda dolarów, próbując (bezskutecznie) konkurować z IBM . Większość aktywów działu komputerowego została sprzedana ówczesnemu Univac . Obejmowało to RCA Spectra , różne projekty sprzętu zewnętrznego (takie jak terminale wideo, napędy taśmowe i czytniki kart perforowanych ) oraz system operacyjny, system operacyjny z podziałem czasu ( TSOS).
TSOS mógł być lepszym systemem operacyjnym z punktu widzenia użytkownika niż którykolwiek z IBM, ale w tamtym czasie systemy operacyjne nie były uważane za coś sprzedawanego oddzielnie od komputera, producent dołączał go bezpłatnie jako część ceny zakupu. Univac wprowadził kilka dodatkowych nowych funkcji do TSOS i zmienił jego nazwę na VS/9. Nazwa „TSOS” pozostała jednak nazwą użytkownika podstawowego uprzywilejowanego konta (System Manager), które w Unix nosi nazwę „root”. RCA sprzedała również TSOS temu, co stało się Fujitsu i jest podstawą BS2000 firmy Fujitsu systemu operacyjnego na komputerach mainframe o tej samej nazwie.
Używać
Zastosowanie interaktywne
Interaktywne wykorzystanie VS / 9 odbywało się za pośrednictwem terminali podłączonych do jednostki koncentratora terminali, która przekazywała sygnały sterujące do iz terminali, w sposób podobny do sposobu, w jaki IBM dostarczałby swoje terminale w stylu IBM 3270 . Ogólnie zapewniało to wysyłanie danych wejściowych do terminala w odpowiedzi na klawisz Enter, w przeciwieństwie do praktyki na komputerach PC polegającej na wprowadzaniu jednego znaku na raz. Jednostka koncentratora była pierwotnie znana jako moduł sterowania komunikacją lub CCM. Jednak RCA sprzedała patenty i projekty swojego kontrolera terminala CCM firmie Singer Corporation , więc Univac opracował urządzenie emulujące dla CCM, które było znane jako Multiterminal Connection Controller model 16 lub MCC-16.
MCC-16 obsługiwał zarówno standardowy terminal Univac (z RCA) przemianowany na Uniscope Video Display Terminal lub VDT, jak i zwykłe głupie terminale ASCII . Uniscope VDT firmy Univac zapewniał wyrafinowane (jak na razie) możliwości edycji, w tym możliwość edytowania tekstu na ekranie i wprowadzania zmian pojedynczo w linii lub na stronie, a następnie przesyłać tekst z powrotem do komputera. VDT obsługiwał również bezpośrednie pozycjonowanie kursora i ochronę wprowadzania przez kursor , co wskazywało, że rozpoznawany ma być tylko tekst po kursorze. Obsługiwał również specjalny tryb przewijania w podzbiorze ekranu lub „oknie”, w którym zamiast przewijania całego ekranu w górę, gdy wyświetlana jest ostatnia linia, można było ustawić obszar przewijania tylko w dolnej połowie ekranu.
Rozróżniono terminale interaktywne (z podziałem czasu) i terminale transakcyjne. Tam, gdzie terminale interaktywne były kontrolowane bezpośrednio przez system operacyjny, terminale transakcyjne były kontrolowane z programu wsadowego. Początkowo ten program wsadowy, znany jako MCP dla programu komunikacji wielokanałowej, został opracowany dla wsadowych systemów operacyjnych RCA i Sperry, TDOS (system operacyjny na dysku taśmowym) i DOS (system operacyjny na dysku). Gdy stało się jasne, że zostaną one wycofane na rzecz znacznie bardziej niezawodnego interaktywnego systemu operacyjnego VMOS, MCP został przeniesiony do działania na VMOS. VMOS (Virtual Memory Operating System) stał się nowym pseudonimem TSOS na komputerach RCA Spectra 70 modele 46, 61, 3 i 7, a następnie początkowo na komputerach Univac Series 70 (dawniej RCA).
Ostatecznie MCP został rozszerzony o obsługę terminali Sperry Univac, a jego nazwa została zmieniona na COS (Communication Operating System). Porty w CCM, a później w MCK działające w trybie emulacji, mogą być oznaczone jako interaktywne lub transakcyjne, ale nie oba jednocześnie. Jeśli port został wyznaczony jako port interaktywny, był kontrolowany przez usługi współdzielenia czasu zintegrowane z systemem operacyjnym VMOS lub VS/9. Z drugiej strony porty transakcyjne były kontrolowane przez COS. Wszystkie terminale podłączone do tych portów stały się „własnością” odpowiedniego oprogramowania hosta sterującego. Do tworzenia programów wykorzystano podział czasu, umożliwiając znacznie szybsze tworzenie programów niż tradycyjny proces wsadowy, który był wówczas najnowocześniejszy. Każdy użytkownik korzystający z podziału czasu był osobnym zadaniem i mógł uruchamiać programy, tworzyć pliki i żądać zasobów systemowych w razie potrzeby. To, co w dużej mierze umożliwiło to, to zdolność systemu operacyjnego do zarządzania „pamięcią wirtualną” lub tymczasowego zapisywania stron pamięci (w tym wykonywania programów) na dysku lub bębnie, gdy nie są używane, a następnie przywracania ich później w razie potrzeby. Rozmiar strony pamięci wirtualnej został ustalony na 4096 bajtów. Pozwoliło to na jednoczesne wykonywanie znacznie większej liczby zadań, niż byłoby to ograniczone przez ograniczoną i kosztowną przestrzeń pamięci głównej. Z drugiej strony użytkownicy transacyjni byli kontrolowani przez jeden program, a ich widok środowiska ograniczał się do tego, co zostało im zaprezentowane. Nie były one identyfikowane jako pojedyncze zadania i nie miały możliwości uruchamiania programów ani żądania zasobów systemowych.
CCM i MCC działające w trybie emulacji były „głupimi” interfejsami sprzętowymi. Oznacza to, że cała inteligencja protokołów sieciowych, w tym odpytywanie terminali, usuwanie błędów i konstruowanie wiadomości, znajdowała się w komputerze głównym, podczas gdy CCM i MCC działały po prostu jako kanały między komputerem głównym a liniami telefonicznymi. Dopiero gdy MCC został użyty jako prawdziwy procesor front-end, większość tego narzutu (takiego jak odpytywanie i usuwanie błędów) została odciążona z komputera mainframe, uwalniając w ten sposób czas komputera na uruchamianie aplikacji. Nastąpiło to dopiero w erze VS/9.
Użycie wsadowe
VS / 9 obsługiwał jeden lub więcej czytników kart, które były podłączone do komputera i aktywowane przez użytkownika umieszczającego talię kart w zasobniku i naciskając przycisk „Start”. Przypuszczalnie komputer odczytałby talię źródłową i umieścił wszystkie odczytane karty w zasobniku wyjściowym. Gdyby talia kart składała się z ważnego loginu, przetwarzałaby talię kart jako zadanie do wykonania.
Operacje witryny
VS/9 był kontrolowany przez operatora komputerowego w ośrodku centralnym. Operatorzy komputerów wchodzili w interakcję z systemem za pośrednictwem konsoli systemowej. Początkowo ta konsola była urządzeniem dalekopisowym, ale później została zmodernizowana do urządzenia wyświetlającego wideo z dołączoną drukarką konsoli systemowej. Wszystkie komunikaty konsoli systemowej zostały zarejestrowane na drukarce konsoli systemowej. Niepożądane wiadomości pochodzące z systemu operacyjnego były również rejestrowane na drukarce konsoli systemowej. Operatorzy komputerów mieli szereg obowiązków:
- Zainicjuj system poprzez proces rozruchu.
- Uruchom procesy programu wsadowego.
- Załaduj program sterujący komunikacją (MCP lub COS), jeśli lokalizacja posiada terminale transakcyjne.
- Dostarczanie danych wejściowych za pomocą kart perforowanych lub taśm magnetycznych.
- Montuj/demontuj wymienne dyski i taśmy zgodnie z potrzebami do zadań wsadowych i/lub interaktywnych.
- Priorytetyzuj zadania wykonywane lub w kolejkach wejściowych.
- Dostosuj limity wsadowe i terminali interaktywnych, aby zoptymalizować wydajność systemu.
- Dostarcz papier do lokalnych drukarek podłączonych lokalnie.
- Zgłaszanie awarii systemu personelowi serwisowemu dostawcy.
- Wykonywanie innych obowiązków określonych przez zespół zarządzający klientami.
Cechy
Grupy woluminów
Jednym z bardziej użytecznych ulepszeń w późnej fazie życia VS/9 były grupy woluminów. Technologia dyskowa w tamtym czasie zapewniała ograniczoną ilość miejsca na każdym dysku. Ponieważ napędy dysków były stosunkowo duże i dość drogie, producenci napędów dysków zapewniali możliwość fizycznego usunięcia rzeczywistego dysku z urządzenia i zastąpienia go innym. W ten sposób klienci mieli możliwość przechowywania wielokrotnie większej pojemności niż ich dyski, chociaż niekoniecznie mogły być używane jednocześnie, chyba że było wystarczająco dużo wolnych dysków. Ograniczona przestrzeń dyskowa przedstawiała użytkownikom także inny problem. Bardzo często pliki byłyby większe niż mogłyby być zawarte na jednym dysku. Grupy woluminów pomogły złagodzić ten problem technologiczny, umożliwiając plikom rozmieszczenie wielu dysków. Woluminy (dyski), które miały być montowane jednocześnie, zostały oznaczone jako „grupa woluminów”. Można zdefiniować właścicieli w celu ograniczenia dostępu do danych wrażliwych. Po zamontowaniu i dołączeniu do aktywnego zadania nie można było odłączyć całej grupy woluminów, dopóki wszystkie dołączone zadania nie zwolnią jej lub nie zakończą. Każdy dysk dostępny w systemie był częścią grupy woluminów, nawet jeśli w grupie był tylko jeden wolumin. Grupy woluminów można określić jako usuwalne lub stałe. Grup woluminów o stałej wielkości nie można usunąć w dowolnym momencie. Było to konieczne w przypadku dysków, na których znajdował się system operacyjny i pliki obsługujące terminale transakcyjne.
Zdalne przetwarzanie wsadowe
Zdalne przetwarzanie wsadowe (RBP) było funkcją, która istniała w VS/9, chociaż nigdy nie została w pełni wykorzystana, prawdopodobnie ze względu na ograniczone zapotrzebowanie. RBP umożliwił zdalnym użytkownikom przesyłanie zadań wsadowych do wykonania na komputerze mainframe i odbieranie wyników z powrotem na drukarce zewnętrznej. Zazwyczaj zdalne urządzenie wsadowe składało się z czytnika kart i drukarki podłączonej do linii komunikacyjnej, która łączyła się ze zdalnymi usługami wsadowymi w systemie operacyjnym. Podobnie jak w przypadku lokalnego zadania wsadowego, operatorzy mogli otrzymywać żądania montowania/odmontowywania taśm lub dysków oraz monity programu dotyczące odpowiedzi na pytania.
Typy zadań
Zadania zarządzane przez VS/9 według typu zadania. Typy zadań mogą obejmować wykonywanie programów lub kolejek oczekujących zadań. Następujące typy zadań były używane przez VS/9:
- Wsadowa kolejka wejściowa
- Wykonywanie programów wsadowych
- Aktywni użytkownicy korzystający z podziału czasu
- Kolejka wyjściowa bufora drukowania i dziurkowania
- Drukuj i dziurkuj urządzenia drukujące lub dziurkujące
- Kolejka wyjściowa RBP
- Nieużywany
- Drukowanie urządzeń RBP
MCP i COS były zawsze zadaniami typu 2. Operator komputera zobaczy liczbę zadań w każdej kolejce na konsoli systemowej. Pełna lista kolejek zadań była dostępna z dowolnego interaktywnego terminala z dostępem administratora za pośrednictwem napisanego w terenie programu znanego jako „Stat200”. Ten program skanowałby kolejki zadań co kilka sekund i wyświetlał przewijaną listę zadań na ekranie terminala, dopóki nie został przerwany lub zakończony. Chociaż nie był to oficjalnie wydany produkt, stał się de facto standardem monitorowania zadań.
Dostęp do konta
VS/9 kontrolowany dostęp za pomocą nazwy konta i nazwy użytkownika. Nazwa konta była identyfikatorem o długości od 1 do 7 znaków, a nazwa użytkownika była również identyfikatorem o długości od 1 do 8 znaków. Identyfikatorami nazw kont i nazw użytkowników mogą być tylko litery i cyfry. Nazwa konta była odpowiednikiem nazwy katalogu pod kontami użytkowników w stylu uniksowym, z uwagą, że nazwa użytkownika wskazywała, która osoba udostępniająca to konto była stroną, która z niego korzystała. Tak więc, na przykład, gdyby istniało konto o nazwie S0103, gdyby na tym koncie było dwóch użytkowników o imionach Pat i Leslie, mieliby oni pełny identyfikator S0103 ,PAT i S0103, LESLIE. Wszystkie ich pliki byłyby przechowywane w katalogu S0103, a zatem nie mogliby tworzyć plików o tej samej nazwie. Zauważ, że gdyby istniała nazwa konta, powiedzmy PA5, gdyby istniał użytkownik o imieniu Pat, jego identyfikatorem byłby PA5, PAT i byłby całkowicie niezwiązany z jakimkolwiek innym użytkownikiem o imieniu Pat.
Konta mogą mieć ograniczenia, takie jak wymaganie hasła do użycia, limity dotyczące liczby plików, ilości użycia, czasu dozwolonego użytkowania (np. Zezwalanie na logowanie tylko po 17:00 lub przed 8:00) oraz limity procesora. Użytkownik może również wydawać polecenia, aby system przerwał program, jeśli bieżąca sesja wykorzystała więcej niż określoną ilość czasu zegara ściennego lub procesora.
Użytkownik na terminalu, który nie był zalogowany, a który chciał rozpocząć sesję, nacisnąłby czerwony klawisz Transmit na Univac VDT lub użył Control + C na terminalu ASCII. VS/9 wyda następującą odpowiedź:
- Witamy w systemie terminali VS/9. Proszę się zalogować.
Po którym następuje ukośnik („/”), aw przypadku Univac VDT znak zachęty, który wyglądał jak odwrotny kolor większy niż znak („>”). Użytkownik logowałby się, wpisując słowo „ logon” , po którym następowałby jego identyfikator, np. nazwa konta, przecinek i nazwa użytkownika. Gdyby mieli hasło do swojego konta, wpisaliby przecinek, a następnie swoje hasło, które może mieć od 1 do 4 znaków. Jeśli zawierał jedną lub więcej spacji (innych niż końcowe spacje, które można było pominąć), musiał być wpisany w pojedynczy cudzysłów. Jeśli zawierał znaki niedrukowalne lub binarne, musiał zostać wpisany za pomocą litery X, a następnie cudzysłowu i 8-znakowego szesnastkową swojego hasła. Więc jeśli konto S0103 miało hasło (w systemie szesnastkowym) A0B0C0 i spację, to użytkownik LESLIE logowałby się do systemu, wpisując
- /LOGON S0103,LESLIE,X'A0B0C0'
Jeśli ich poświadczenia były nieprawidłowe, ponieważ nazwa konta, nazwa użytkownika lub hasło były nieprawidłowe, otrzymaliby wiadomość,
- Logowanie jest nieprawidłowe, spróbuj ponownie.
i otrzyma znak / monit o ponowne zalogowanie.
Jeśli ich poświadczenia byłyby poprawne, to gdyby menedżer systemu (właściciel konta $TSOS ) opublikował komunikat systemowy, zostałby wyświetlony w tym momencie. Użytkownik byłby w trybie poleceń i pojawiłby się standard / monit, w którym mógłby wpisać różne polecenia. Użytkownik kończył sesję, wpisując LOGOFF i naciskając na Univac VDT lub Control + C na terminalu ascii.
Funkcje terminala
Terminal VDT firmy Univac miał na górze cztery klawisze funkcyjne, a VS/9 specjalnie je rozpoznawał.
- F1 był odpowiednikiem klawisza break na terminalu Ascii. Gdyby program był uruchomiony, zostałby przerwany, a użytkownik wszedłby w tryb przerwy, w którym mógłby wydać polecenie. Mogli wpisać R lub INTR, aby wznowić działanie programu, w którym nastąpiło przerwanie.
- F2 i F3 można było ustawić tak, aby były rozpoznawane przez program dla różnych funkcji, ale nie były używane przez VS/9.
- F4 wykonał natychmiastowe wymuszone wylogowanie użytkownika, jeśli został uderzony, przypadkowo lub celowo. Byłoby to odpowiednikiem w MS-DOS naciśnięcia CTRL-ALT-DEL, co powoduje natychmiastowe ponowne uruchomienie maszyny.
Polecenia systemowe
VS/9 zaakceptował polecenia, wpisując polecenie i dowolne opcje. Polecenia wydawane w strumieniu wsadowym jako karty lub jako plik wsadowy wymagały poprzedzenia ich ukośnikiem; polecenia wprowadzane na terminalu nie wymagały użycia ukośnika. Polecenia obejmowały:
- EXEC, aby załadować i uruchomić program
- LOAD, aby załadować program do pamięci i przejść do trybu poleceń bez uruchamiania, aby umożliwić debugowanie poleceń
- ZROBIĆ, aby uruchomić plik wsadowy w bieżącej sesji
- ENTER, aby uruchomić plik wsadowy tak, jakby został przesłany do czytnika kart
- SYSFILE, aby określić rozmieszczenie wydruków
- WYLOGUJ, aby zakończyć swoją sesję. Jeśli ktoś zamierzał korzystać z terminala lub chciał zmienić konto, mógł również wpisać WYLOGUJ ALE, aby od razu wysłać prośbę o nowy login. Wszelkie wydruki wygenerowane przez użytkownika podczas sesji byłyby buforowane do drukarki wierszowej i drukowane w tym czasie. Można użyć opcji „TAŚMA”, jak w przypadku LOGOFF TAPE , LOGOFF BUT, TAPE lub LOGOFF TAPE,ALE , aby wskazać, że oczekujące wydruki powinny zostać zbuforowane na taśmie magnetycznej zamiast drukowania. Żądanie zostanie wysłane do operatora systemu.
Gdyby ktoś przerwał działający program (poprzez klawisz Break na terminalu ASCII lub klawisz F1 na Univac VDT) lub użył polecenia LOAD zamiast EXEC, znalazłby się w „trybie przerwania”, w którym program został zawieszony, aby umożliwić użytkownikowi przejście w tryb poleceń. Mogli wydać powyższe polecenia, a także:
- R, aby wznowić program przerwany klawiszem break
- INTR, aby wysłać przerwanie-wznowienie do programu obsługującego INTR
- Polecenia debugowania
- VS / 9 zawierał Interactive Debugging Aid (IDA), który zapewniał polecenia przeglądania pamięci i rejestrów, przechwytywania błędów programu i przechowywania pamięci w lokalizacjach. W przeciwieństwie do innych systemów, w których interaktywny debugger wymagał albo uruchomienia programu, aby go użyć, albo połączenia modułu z programem, IDA był częścią systemu operacyjnego, a jego polecenia były dostępne w trybie przerwy.
- Innym bardzo pomocnym, ale nieobsługiwanym produktem do debugowania problemów z systemem operacyjnym był program o nazwie „CareCity”. System operacyjny VS/9 został dostarczony w postaci gotowych modułów na taśmach magnetycznych. Podczas instalacji wybrane moduły zostały ze sobą połączone na podstawie dostarczonych parametrów konfiguracyjnych w celu utworzenia działającego systemu operacyjnego, a następnie zapisane na dysku. Każdy moduł miał na końcu wyznaczoną wolną przestrzeń, która służyła do łatania istniejącego kodu w przypadku błędu, bez ponownego składania całego modułu. CareCity umożliwiło administratorowi przeglądanie zawartości pamięci systemu operacyjnego za pomocą adresów względem początku każdego modułu systemu operacyjnego . Kod poprawki można następnie wstawić do wyznaczonych obszarów poprawki zgodnie z potrzebami, a następnie można wstawić rozgałęzienia od istniejącego kodu do nowo zainstalowanego kodu. To wszystko można było zrobić, gdy system operacyjny był w użyciu .
Konwencje nazw plików
Nazwy plików mogą mieć maksymalnie 56 znaków. Plik może składać się z liter, cyfr, myślników i cyfr. Dopuszczalna była nazwa pliku złożona wyłącznie z cyfr, ale plik nie mógł mieć dwóch następujących po sobie kropek. Aby uzyskać dostęp do pliku na innym koncie, użytkownik tego konta musiał upublicznić plik. Jeśli plik był publiczny, inny użytkownik mógł uzyskać do niego dostęp, poprzedzając nazwę pliku wskaźnikiem, że plik, do którego się odwołuje, znajduje się na innym koncie, którym był znak dolara („$”), po którym następuje nazwa konta, po którym następuje okres.
Jeśli na koncie S0103 znajdował się plik o nazwie „A”, a użytkownik na koncie PA5 chciał uzyskać dostęp do pliku na koncie S0103, po pierwsze, plik musiałby zostać oznaczony jako publiczny, a po drugie, musiałby się do niego odwoływać nazwę konta i nazwę pliku. Tak więc użytkownik na koncie PA5, który chciał uzyskać dostęp do pliku A na koncie S0103, jeśli plik był publiczny, odwołałby się do niego jako $S0103.A
. Należy zauważyć, że użytkownik na koncie S0103 może odwoływać się do pliku po prostu jako „A” lub odwoływać się do niego za pomocą w pełni kwalifikowanej nazwy pliku , włączając znak dolara i własną nazwę konta, po której następuje kropka i nazwa.
Dostęp do plików publicznych na specjalnym koncie TSOS można było uzyskać, używając samego $ jako pierwszego znaku pliku, chyba że plik zaczynał się od nazwy identycznej z numerem konta, w którym to przypadku jawne odniesienie do konta $TSOS . byłoby wymagane. Również $TSOS . to coś, co można by nazwać ścieżki do brakujących plików, do których odwołuje się nazwa, a których nie znaleziono na koncie użytkownika. Na przykład, jeśli na koncie $TSOS znajdował się plik o nazwie S0103.XYZZY , a w tym systemie istniało konto o nazwie S0103, każdy użytkownik chcący uzyskać do niego dostęp musiałby uzyskać do niego dostęp jako $TSOS.S0103.XYZZY
.
TSOS był również „domyślnym” kontem dla pliku, do którego się odwoływano, a który nie istniał lokalnie. Na przykład, aby uruchomić edytora EDT , można by wydać polecenie uruchomienia programu EXEC, po którym następuje nazwa pliku, który nazywał się EDT. Tak więc, jeśli użytkownik nie utworzył pliku o nazwie EDT, mógł uruchomić edytor EDT, wpisując
- /EXEC EDT
i naciśnięcie klawisza transmisji. Gdyby z jakiegoś powodu utworzyli program o tej samej nazwie, aby użyć edytora systemowego, musieliby pisać
- /EXEC $EDT
lub mogą jawnie wpisać konto systemowe
- /EXEC $TSOS.EDT
Kiedy Unisys zaprzestał sprzedaży komputerów mainframe z serii 9000 na rzecz komputerów z serii EXEC 8 (prawdopodobnie dlatego, że nie były one już opłacalne, a rynek komputerów mainframe się skurczył), firma skutecznie porzuciła VS / 9.
Zobacz też
- Podręcznik użytkownika VS/9 , Sperry Unisys, Cinnaminson, New Jersey , 1972
- Podręcznik programisty VS/9 , Sperry Unisys, Cinnaminson, New Jersey , 1975