Burroughs MCP - Burroughs MCP

„Master Control Program” przekierowuje tutaj. Dla fikcyjnego złoczyńcy programu komputerowego, zobacz Master Control Program (Tron) .
MCP
Deweloper Burroughs / Unisys
Napisane w ESPOL , NEWP
Stan pracy Aktualny
Model źródłowy Dostępne źródło
Pierwsze wydanie 1961 ; 60 lat temu ( 1961 )
Najnowsze wydanie 20,0 / maj 2021
Platformy Burroughs duże systemy, w tym Unisys Clearpath/MCP
Domyślny
interfejs użytkownika		 Tekstowy interfejs użytkownika
Licencja Prawnie zastrzeżony
Oficjalna strona internetowa Witryna MCP

MCP (Master Control Program) jest system operacyjny z Burroughs małych, średnich i dużych systemów, w tym Unisys Clearpath / MCP systemów.

MCP został pierwotnie napisany w 1961 roku w ESPOL (Executive Systems Problem Oriented Language). W latach 70. MCP został przekształcony w NEWP, który był lepiej ustrukturyzowaną, solidniejszą i bezpieczniejszą formą ESPOL.

MCP był liderem w wielu obszarach, w tym: pierwszy system operacyjny do zarządzania wieloma procesorami, pierwsza komercyjna implementacja pamięci wirtualnej oraz pierwszy system operacyjny napisany wyłącznie w języku wysokiego poziomu .

Historia

W 1961 r. MCP był pierwszym systemem operacyjnym napisanym wyłącznie w języku wysokiego poziomu (HLL). Burroughs dużego systemu ( B5000 i następcy) były wyjątkowe, zostały one zaprojektowane z oczekiwaniem, że wszystkie programy, łącznie z oprogramowaniem systemowym, byłby napisany w HLL zamiast w asemblerze , co było wyjątkowe i innowacyjne podejście w 1961 roku.

W przeciwieństwie do IBM, który zmagał się z konkurencją sprzętową po odejściu Gene'a Amdahla , oprogramowanie Burroughsa zostało zaprojektowane do działania tylko na zastrzeżonym sprzęcie. Z tego powodu Burroughs mógł swobodnie rozpowszechniać kod źródłowy całego sprzedawanego oprogramowania, w tym MCP, który został zaprojektowany z myślą o tej otwartości. Na przykład aktualizacja wymagała od użytkownika ponownej kompilacji oprogramowania systemowego i zastosowania wszelkich potrzebnych lokalnych poprawek. W tamtym czasie była to powszechna praktyka i była konieczna, ponieważ klienci (szczególnie duzi, tacy jak Rezerwa Federalna ) często modyfikowali program, aby dopasować go do swoich specyficznych potrzeb. W rezultacie utworzono Grupę Użytkowników Burroughs, która odbywała coroczne spotkania i umożliwiała użytkownikom wymianę własnych rozszerzeń do systemu operacyjnego i innych części pakietu oprogramowania systemowego. Wiele takich rozszerzeń przez lata znalazło się w podstawowym kodzie systemu operacyjnego i są teraz dostępne dla wszystkich klientów. Jako taki, MCP można uznać za jeden z najwcześniejszych projektów open source .

Burroughs nie był pierwszym producentem, który rozpowszechniał kod źródłowy i był późnym wejściem do komputerów elektronicznych (w porównaniu z tradycyjnymi rywalami NCR, IBM i Univac). Teraz, gdy MCP działa na standardowym sprzęcie, niektóre elementy pakietu oprogramowania opartego na MCP nie są już udostępniane w formie źródłowej przez Unisys.

MCP był pierwszym komercyjnym systemem operacyjnym zapewniającym pamięć wirtualną , która od samego początku była obsługiwana przez architekturę dużych systemów Burroughs . Ten schemat jest unikalny w branży, ponieważ przechowuje i pobiera obiekty zdefiniowane przez kompilator, a nie strony pamięci o stałym rozmiarze, co jest konsekwencją jego ogólnej architektury innej niż von Neumann i jednolicie opartej na stosie.

System plików

MCP zapewnia system plików z hierarchiczną strukturą katalogów. We wczesnych implementacjach MCP węzły katalogów były reprezentowane przez oddzielne pliki z wpisami katalogów, tak jak robiły to inne systemy. Jednak od około 1970 roku MCP wewnętrznie używa katalogu „FLAT” zawierającego wszystkie ścieżki plików na woluminie. Dzieje się tak, ponieważ otwieranie plików przez odwiedzanie i otwieranie każdego katalogu w ścieżce pliku było nieefektywne, a w przypadku środowiska produkcyjnego stwierdzono, że lepiej jest przechowywać wszystkie pliki w jednym katalogu, nawet jeśli zachowują hierarchiczny schemat nazewnictwa. Programowo nie ma to żadnego znaczenia. Jedyną różnicą widoczną dla użytkowników jest to, że plik encji może mieć taką samą nazwę jak katalog. Na przykład „A/B” i „A/B/C” mogą istnieć; „B” może być zarówno węzłem w pliku, jak i katalogiem.

Pliki są przechowywane na nazwanych woluminach, na przykład „to/jest/a/nazwapliku na myvol”, „myvol” to nazwa woluminu. Jest to niezależne od urządzenia, ponieważ dysk zawierający „myvol” można przenieść lub skopiować na różne dyski fizyczne. Dyski można również łączyć, dzięki czemu można zainstalować jeden wolumin na kilku dyskach, a także tworzyć kopie lustrzane w celu odzyskania poufnych danych. W celu zwiększenia elastyczności każdy program może dokonywać podstawień woluminów, a nazwę woluminu można zastąpić nazwą podstawową i dodatkową alternatywną. Nazywa się to RODZINĄ procesu. Na przykład przypisanie „FAMILY DISK = USERPACK OTHERWISE SYSPACK” przechowuje pliki logicznie wyznaczone na woluminie DISK w woluminie USERPACK i będzie najpierw wyszukiwać pliki w woluminie USERPACK. Jeśli to wyszukiwanie nie powiedzie się, kolejne wyszukiwanie pliku jest wykonywane w woluminie SYSPACK. DYSK to domyślna nazwa woluminu, jeśli nie określono żadnej.

Każdy plik w systemie ma zestaw atrybutów pliku. Atrybuty te rejestrują wszelkiego rodzaju metadane dotyczące pliku, a przede wszystkim jego nazwę i typ (który informuje system, jak obsłużyć plik, podobnie jak bardziej ograniczony czteroznakowy kod typu pliku na komputerze Macintosh ). Inne atrybuty to rozmiar rekordu pliku (jeśli jest ustalony dla zastosowań komercyjnych), rozmiar bloku (w wielokrotnościach rekordów, który informuje MCP, ile rekordów ma odczytywać i zapisywać w jednym fizycznym we/wy) oraz rozmiar obszaru w wielokrotnościach bloków, co podaje rozmiar obszarów dysku, które mają być alokowane w miarę rozszerzania się pliku.

Typ pliku wskazuje, czy plik jest danymi znakowymi, czy kodem źródłowym napisanym w określonych językach, danymi binarnymi lub plikami kodu.

Pliki są chronione przez zwykłe mechanizmy bezpieczeństwa, takie jak publiczne lub prywatne, lub plik może mieć plik ochronny, w którym właściciel może określić złożone reguły bezpieczeństwa.

Innym mechanizmem bezpieczeństwa jest to, że pliki kodu mogą być tworzone tylko przez zaufane kompilatory. Złośliwi programiści nie mogą stworzyć programu i nazwać go kompilatorem — program może zostać przekonwertowany na kompilator tylko przez operatora z wystarczającymi uprawnieniami za pomocą polecenia operatora 'mc' make compiler.

MCP implementuje system plików Journaling , zapewniający odporność na awarie w przypadku awarii dysku, utraty zasilania itp. Nie jest możliwe uszkodzenie systemu plików (z wyjątkiem systemu operacyjnego lub innego zaufanego oprogramowania systemowego z bezpośrednim dostępem do jego niższych warstw ).

W systemie plików nie jest rozróżniana wielkość liter i nie jest on zachowywany, chyba że wokół nazwy dodawane są cudzysłowy, w którym to przypadku rozróżniana jest wielkość liter.

Zarządzanie procesem

MCP procesy nazywane są „ Praca ” i „ Zadania ”. Zadanie zawiera jedno lub więcej zadań. Zadania w ramach zadania mogą być uruchamiane sekwencyjnie lub równolegle. Logika może być zaimplementowana na poziomie zadania, zwykle w języku sterowania zadaniami MCP WFL, w celu sterowania przepływem zadania. Po zakończeniu wszystkich zadań w zadaniu samo zadanie jest ukończone.

Proces MCP przechodzi cykl życia od momentu wejścia do systemu do momentu jego opuszczenia. Stan początkowy zadania to „W kolejce”. Przez pewien czas zadanie znajduje się w jednej z kilku zdefiniowanych przez użytkownika kolejek zadań. Następny stan to „Zaplanowane”, gdy zadanie przechodzi z kolejki do pamięci. Zadania w zadaniu nie czekają w kolejce; zamiast tego przechodzi bezpośrednio do stanu „Zaplanowane” po zainicjowaniu. Po uruchomieniu zadania lub zadania może przechodzić między stanem „Aktywne”, „Oczekujące” i „Zaplanowane” w miarę postępu. Gdy zadanie lub zadanie zostanie ukończone, przechodzi do stanu „Ukończone”.

Uruchomione procesy to te, które wykorzystują zasoby procesora i są oznaczone jako „uruchomione”. Procesy, które są gotowe do przypisania do procesora, gdy nie ma wolnego procesora, są umieszczane w kolejce gotowości. Procesom można przypisać priorytet „Zadeklarowany” lub „Widoczny”, zwykle 50 jako domyślny, ale może wynosić od 0 do 99 dla procesów użytkownika. Procesom systemowym można przypisać wyższe wartości. Należy zauważyć, że ten priorytet liczbowy jest drugorzędny w stosunku do priorytetu ogólnego, który jest oparty na typie zadania. Procesy, które są bezpośrednio częścią systemu operacyjnego, nazywane niezależnymi biegaczami, mają najwyższy priorytet niezależnie od wartości liczbowej priorytetu. Następnie przychodzą procesy wykorzystujące blokadę MCP, a następnie systemy kontroli wiadomości, takie jak CANDE . Następnie Zaniechane procesy. Następnie oferty pracy w języku przepływu pracy. Wreszcie przychodzą procesy użytkownika. Na niższym poziomie istnieje priorytet Fine, który ma na celu podniesienie priorytetu zadań, które nie wykorzystują pełnego wycinka procesora. Dzięki temu zadanie powiązane z IO może uzyskać czas procesora przed zadaniem powiązanym z procesorem o tym samym zadeklarowanym priorytecie.

Procesy oczekujące na inne zasoby, takie jak odczytany plik, czekają na strukturę danych EVENT . W ten sposób wszystkie procesy oczekujące na pojedynczy zasób czekają na jedno zdarzenie. Gdy zasób staje się dostępny, wywoływane jest zdarzenie, które budzi wszystkie oczekujące na niego procesy. Procesy mogą czekać na wiele zdarzeń na jedno z nich, łącznie z limitem czasu. Zdarzenia są w pełni programowalne przez użytkownika – to znaczy, że użytkownicy mogą pisać systemy korzystające z uogólnionego systemu zdarzeń udostępnianego przez MCP.

Procesy, które zostały zakończone, są oznaczane jako zakończone.

Operacyjnie status wszystkich zadań w systemie jest wyświetlany operatorowi. Wszystkie uruchomione i gotowe procesy są wyświetlane jako „aktywne” zadania (ponieważ system wdraża wielozadaniowość z wywłaszczaniem , zmiana z gotowych na uruchomione i z powrotem jest tak szybka, że ​​rozróżnianie zadań gotowych i uruchomionych jest bezcelowe, ponieważ wszystkie dostaną kawałek procesora w ciągu sekunda). Wszystkie aktywne zadania można wyświetlić za pomocą polecenia „A”.

Zakończone zadania są wyświetlane jako zakończone zadania z powodem zakończenia, EOT jako zwykły „zakończenie zadania”, a DSed z powodem niepowodzenia procesu. Wszystkim procesom przypisywany jest numer mieszanki, a operatorzy mogą używać tego numeru do identyfikacji procesu, który należy kontrolować. Jednym z takich poleceń jest polecenie DS (które oznacza Delete from Schedule, DiScontinue lub Deep Six, po wpływie personelu marynarki wojennej na wczesne projekty komputerowe, w zależności od tego, z kim rozmawiasz). Zadania zakończone przez operatora są wymienione w pełnych wpisach jako O-DS.

Zadania mogą również kończyć się z powodu błędów programu, oznaczonych jako F-DS lub P-DS, w przypadku błędów, takich jak nieprawidłowy indeks , przepełnienie liczbowe itp. Zakończone wpisy mogą być wyświetlane przez operatora za pomocą polecenia „C”.

Zadania oczekujące na zasób są wymienione pod wpisami oczekujących i powodem oczekiwania. Wszystkie oczekujące zadania można wyświetlić za pomocą polecenia „W”. Powód oczekiwania jest również wymieniony, a więcej informacji o zadaniu można zobaczyć za pomocą polecenia „Y”. Może się zdarzyć, że zadanie czeka na dane wejściowe operatora, które są wysyłane do zadania za pomocą polecenia akceptacji „AX” (należy zauważyć, że dane wejściowe operatora znacznie różnią się od danych wprowadzonych przez użytkownika, które zostałyby wprowadzone z urządzenia sieciowego z interfejsem GUI) .

Zadania oczekujące na dane wejściowe użytkownika lub odczyty plików nie byłyby normalnie wyświetlane jako wpisy oczekujące na uwagę operatora. Innym powodem oczekiwania zadania jest oczekiwanie na plik. Gdy proces otwiera plik, a pliku nie ma, zadanie jest umieszczane we wpisach oczekujących, zwracając uwagę, że czeka na określony plik. Operator (lub użytkownik będący właścicielem procesu) ma możliwość skopiowania pliku do oczekiwanego miejsca lub przekierowania zadania w celu odczytania pliku z innego miejsca, lub nawet plik może zostać utworzony przez niezależny proces, który nie jeszcze nie ukończone.

Jeśli zasób nie może być dostarczony przez operatora, operator może DS wykonać zadanie w ostateczności. Różni się to od innych systemów, które automatycznie przerywają zadanie, gdy zasób, taki jak plik, jest niedostępny. MCP zapewnia ten poziom możliwości odzyskania zadań przez operatora. Inne systemy wymuszają na programistach dodanie kodu w celu sprawdzenia obecności plików przed uzyskaniem do nich dostępu, dlatego w każdym przypadku należy napisać dodatkowy kod, aby zapewnić odzyskiwalność lub synchronizację procesów. Taki kod można napisać w programie MCP, gdy nie jest pożądane, aby zadanie czekało, ale ze względu na możliwość odtwarzania na poziomie operatora, nie jest to wymuszane i dlatego programowanie jest znacznie prostsze.

Oprócz możliwości dynamicznego mapowania żądań plików (lub baz danych) do innych plików (lub baz danych), przed lub w trakcie wykonywania programu, dostępnych jest kilka mechanizmów umożliwiających programistom wykrywanie i usuwanie błędów. Z jednej strony oświadczenie „ON” istnieje od wielu lat. Można wypisać określone błędy (np. dzielenie przez zero) lub zastosować funkcję catch-all „dowolny błąd”. Instrukcja lub blok następujący po instrukcji „ON” jest rozpoznawany przez kompilator jako kod obsługi błędów. Podczas wykonywania, jeśli w zakresie instrukcji 'on' wystąpi odwracalny błąd, stos jest odcinany, a kontrola przekazywana do instrukcji następującej po nim.

Jednym z problemów związanych z logiką obsługi instrukcji ON było to, że byłaby ona wywoływana tylko w przypadku błędów programu, a nie w przypadku zakończenia programu z innych przyczyn. Z biegiem czasu rosła potrzeba gwarantowanej obsługi nietypowych zakończeń. W szczególności potrzebny był mechanizm umożliwiający programom wywoływanie wtyczek napisanych przez klientów lub osoby trzecie bez żadnego ryzyka, gdyby wtyczka zachowywała się niewłaściwie. Oprócz ogólnych mechanizmów wtyczek, nowa forma dynamicznego łączenia bibliotek ( Biblioteki połączeń ) umożliwia programom importowanie i eksportowanie funkcji i danych, dzięki czemu jeden program uruchamia kod dostarczony przez inny.

Aby osiągnąć tak wzmocnioną ochronę, w połowie lat 90. wprowadzono nowszy mechanizm. W błędnej próbie zgodności, został nazwany po zaproponowanej wówczas konstrukcji języka C++ o tej samej nazwie. Ponieważ składnia i zachowanie tych dwóch różnią się w tak dużym stopniu, wybór tej samej nazwy spowodował jedynie zamieszanie i nieporozumienia.

Składniowo instrukcje „try” wyglądają jak instrukcje „if”: „try”, po którym następuje instrukcja lub blok, po którym następuje „else” i inna instrukcja lub blok. Dodatkowe klauzule „else” mogą następować po pierwszej. Podczas wykonywania, jeśli w kodzie następującym po klauzuli „try” nastąpi jakiekolwiek odzyskiwalne zakończenie, stos jest w razie potrzeby odcinany, a sterowanie rozgałęzia się do kodu następującego po pierwszym „innym”. Ponadto atrybuty są ustawione, aby umożliwić programowi określenie, co się stało i gdzie (w tym konkretny numer wiersza).

Większość zdarzeń, które mogą spowodować zakończenie zadania, można odzyskać. Dotyczy to przepełnienia stosu, przekroczenia zakresu dostępu do tablicy, przepełnienia/niedoliczenia liczby całkowitej itp. Operator (lub użytkownik) DS nie można odtworzyć z wyjątkiem zadań uprzywilejowanych korzystających z UNSAFE formy próby.

W ten sposób MCP zapewnia środowisko bardzo odporne na awarie, a nie zrzut pamięci typu „crash-and-burn” w przypadku innych systemów.

Podobnie jak w przypadku atrybutów plików, zadania mają również atrybuty, takie jak priorytet zadania (który jest przypisywany w czasie kompilacji lub czasu wykonywania lub może być zmieniany podczas działania zadania), czas procesora, czas oczekiwania, stan itp. Te zadania do atrybutów można uzyskać dostęp programowo, podobnie jak do atrybutów plików plików. Zadanie nadrzędne jest dostępne programowo jako atrybut zadania typu zadanie. Na przykład „myself.initiator.name” podaje nazwę procesu, który zainicjował bieżący proces.

GETSPACEi FORGETSPACEsą dwiema głównymi procedurami obsługującymi alokację pamięci i cofnięcie alokacji. Pamięć musi być alokowana przy inicjacji procesu i za każdym razem, gdy wprowadzany jest blok, który wykorzystuje tablice, pliki itp. GETSPACEi FORGETSPACEnie tylko obsługuje przestrzeń pamięci, ale również alokuje lub zwalnia miejsce na dysku, na które mogą być nałożone dane nie rezydujące w pamięci. Pamięć może być SAVE (tzn. rezydująca w pamięci), OVERLAYABLE (tzn. pamięć wirtualna) lub STICKY (tzn. rezydująca w pamięci, ale przenośna). Są wywoływane np. przez, HARDWAREINTERRUPTgdy proces adresuje niezainicjowaną tablicę lub przez FILEOPEN.

HARDWAREINTERRUPTobsługuje przerwania sprzętowe i może wywołać GETSPACE, IO_FINISHlub tym podobne.

BLOCKEXITjest wywoływana przez zadanie wychodzące z bloku. BLOCKEXIT może z kolei wywołać FILECLOSE, FORGETSPACElub podobnie podczas czyszczenia i zwalniania zasobów zadeklarowanych i używanych w tym bloku.

J_EDGAR_HOOVER jest głównym strażnikiem bezpieczeństwa systemu, wywoływanym podczas uruchamiania procesu, otwierania pliku, logowania użytkownika itp.

GEORGE jest procedurą, która decyduje, który proces jako następny otrzyma zasoby procesora, a zatem jest jednym z niewielu procesów, które używają instrukcji MoveStack.

Zadanie przechodzi przez różne stany zaczynając od NASCENT. W momencie DOSTAWY wywoływane jest zdarzenie NARODZENIE, a stan zadania zmienia się na ALIVE. Po wywołaniu PROCESSKILL stan zmienia się na DISEASED. Po spowodowaniu śmierci zadanie zostaje umieszczone w strukturze kolejki MORGUE, po czym wszystkie pozostałe zasoby są uwalniane do systemu przez proces zwany PROCESSKILL.

Gdy zadanie jest ŻYWE, funkcje MCP są uruchamiane na szczycie tego konkretnego procesu, dzięki czemu zasoby procesora są automatycznie obciążane zadaniem, powodując obciążenie MCP. Ponadto większość pracy MCP jest wykonywana z uprawnieniami bezpieczeństwa tego konkretnego stosu. Tylko przed URODZENIEM i po ŚMIERCI MCP musi działać poza jakimś innym stosem. Jeśli żaden nie jest dostępny, system utrzymuje stos bezczynności.

Komponenty oprogramowania i biblioteki

Biblioteki MCP zapewniają sposób udostępniania danych i kodu między procesami. Artykuł dotyczący dużych systemów Burroughs analizuje sposób, w jaki procesy zależne mogą być uruchamiane asynchronicznie, tak aby wiele procesów mogło współdzielić wspólne dane (z mechanizmami zapewniającymi zsynchronizowaną aktualizację). Taka rodzina powiązanych procesów musiała być napisana jako pojedyncza jednostka programowa, przetwarzająca procedury na wyższych poziomach leksyka jako procesy asynchroniczne, które nadal miały dostęp do zmiennych globalnych i innych zmiennych na niższych poziomach leksyka.

Biblioteki całkowicie odwróciły ten scenariusz z następującymi zaletami:

  • Biblioteki i niezależne procesy są pisane jako niezależne jednostki programistyczne
  • Biblioteki w pełni kontrolowały dostęp do współdzielonych zasobów ( enkapsulacja i ukrywanie danych )
  • Biblioteki i klienci mogą być napisane w różnych językach
  • Przełączanie procesów nie było wymagane do bezpiecznego dostępu do danych

Mechanizm biblioteki był tak czysty i radykalny, że wiele oprogramowania systemowego zostało poddanych poważnym zmianom, co doprowadziło do lepszej struktury systemów i zwiększenia wydajności.

Biblioteki zostały wprowadzone do systemów MCP na początku lat 80-tych, zostały opracowane przez Roya Gucka i innych w Burroughs . Są one bardzo podobne do monitorów CAR Hoare i zapewniają możliwość kontrolowanego wzajemnego wykluczania i synchronizacji między procesami klienta przy użyciu zdarzeń MCP EVENT i techniki blokowania Dahm. Biblioteki oferują klientowi proceduralne punkty wejścia, które są sprawdzane pod kątem kompatybilności interfejsu (sprawdzane są wszystkie parametry i zwracane typy importowanych procedur) przed połączeniem klienta z biblioteką. Biblioteka i jej klient mogą być napisane w różnych językach. Zaletą jest to, że cała synchronizacja jest zapewniona w bibliotece, a kod klienta nie musi w ogóle martwić się o ten poziom programowania. Skutkuje to solidnym kodem, ponieważ klienci nie mogą podważyć kodu synchronizacji w bibliotece. (Niektórzy nazwaliby to „ Inicjatywą Trusted Computing ”).

Biblioteki są bardziej wyrafinowanymi formami bibliotek w innych systemach, takich jak DLL . Biblioteki MCP mogą być 'współdzielone przez wszystkich', 'współdzielone przez jednostkę uruchomieniową' lub 'prywatne'. Przypadek prywatny jest najbliższy bibliotekom na innych systemach – dla każdego klienta wywoływana jest osobna kopia biblioteki i nie ma współdzielenia danych między procesami.

Wspólny przez wszystkich jest ciekawszy. Po uruchomieniu klient może działać przez chwilę, dopóki nie będzie wymagał usług w bibliotece. Przy pierwszym odwołaniu do punktu wejścia biblioteki inicjowane jest połączenie. Jeśli instancja biblioteki już działa, klient jest następnie dowiązywany do tej instancji biblioteki. Wszyscy klienci współdzielą tę samą instancję.

Shared by rununit to mechanizm współdzielenia pomiędzy tymi dwoma schematami współdzielenia. Został zaprojektowany specjalnie dla języka COBOL, gdzie jednostka uruchomieniowa jest zdefiniowana jako oryginalny inicjujący program klienta i wszystkie biblioteki, z którymi jest połączony. Każda jednostka uruchomieniowa otrzymuje jedną instancję biblioteki, a różne jednostki uruchomieniowe otrzymują inną instancję. Jest to jedyna dynamiczna implementacja jednostek uruchomieniowych COBOL.

Gdyby było to pierwsze wywołanie biblioteki, biblioteka uruchomiłaby swój główny program (blok zewnętrzny w programie ALGOL) w celu zainicjowania swojego globalnego środowiska. Po zakończeniu inicjalizacji nastąpi zamrożenie, w którym to momencie wszystkie wyeksportowane punkty wejścia będą dostępne dla klientów. W tym momencie mówiono, że stos biblioteki jest zamrożony, ponieważ nic więcej nie zostanie uruchomione na tym stosie, dopóki biblioteka nie zostanie odmrożona, w którym to przypadku zostanie uruchomiony kod czyszczenia i zakończenia. Kiedy klient wywołuje procedurę w bibliotece, ta procedura działa na szczycie stosu klienta, przechowując tam swoje zmienne lokalne i tymczasowe. Dzięki temu wielu klientów może uruchamiać tę samą procedurę w tym samym czasie, będąc zsynchronizowanym przez procedurę biblioteczną, która uzyskuje dostęp do danych w globalnym środowisku stosu bibliotek.

Zamrożenie może również występować w trzech formach – tymczasowej, stałej i kontrolowanej. Tymczasowe oznaczało, że gdy liczba klientów spadnie do zera, biblioteka zostanie odmrożona i zakończona. Stałe oznaczało, że biblioteka pozostawała dostępna dla kolejnych klientów, nawet jeśli liczba klientów spadła do zera – stałe biblioteki mogły zostać odmrożone przez operatora za pomocą polecenia THAW. Kontrolowane zamrożenie oznaczało, że biblioteka faktycznie działała, dzięki czemu mogła wykonywać funkcje monitorowania oraz wykonywać funkcje inicjowania i czyszczenia danych dla każdego łączącego klienta.

Dostęp do bibliotek można również uzyskać „według tytułu” i „według funkcji”. W 'by title' klient podał nazwę pliku biblioteki. 'Według funkcji' była metodą pośrednią, w której klient po prostu określił nazwę funkcji biblioteki, na przykład 'system_support', a rzeczywista lokalizacja biblioteki znajduje się w tabeli wcześniej ustawionej przez operatora z 'SL' (system biblioteka), na przykład 'SL system_support = *system/library/support'. Działa tu również postawa tolerancji błędów MCP – jeśli klient próbuje uzyskać dostęp do biblioteki, której nie ma, klient jest umieszczany w zadaniach „oczekujących” i biblioteka może być obecna lub żądanie przekierowane.

Biblioteki można również aktualizować w locie, wystarczy tylko „SL” nową wersję. Uruchomione klienty będą nadal korzystać ze starej wersji do momentu ich zakończenia, a nowi klienci będą kierowani do nowej wersji.

Biblioteki funkcyjne zaimplementowały również bardzo ważną funkcję bezpieczeństwa, klasy powiązań. Wszystkie normalne biblioteki mają klasę sprzężenia równą zero. Biblioteki używane przez MCP lub inne uprzywilejowane moduły systemowe mogą nie być dostępne z normalnych programów. Są one dostępne przez funkcję i wymuszane w pierwszej klasie powiązań. Klient w klasie powiązania zero nie może połączyć się z punktami wejścia pierwszej klasy powiązania. Biblioteka z klasą powiązania jeden, która musi oferować punkty wejścia do normalnych programów, może to zrobić, jeśli jest oznaczona jako 'zaufana'. Może oferować wybrane punkty wejścia w zerowej klasie połączeń.

Cały system bazodanowy jest zaimplementowany w bibliotekach zapewniających bardzo wydajny i dostosowany do potrzeb dostęp do baz danych współdzielonych przez wielu klientów. To samo dotyczy wszystkich funkcji sieciowych i elementów wewnętrznych systemu.

W połowie lat 90. udostępniono nowy typ biblioteki: Biblioteki Połączeń. Są to programy same w sobie, które mogą wykonywać się niezależnie, a także importować i eksportować dane i funkcje do innych programów w tablicach bloków strukturalnych. Na przykład składnik sieciowy systemu operacyjnego jest dostępny jako biblioteka połączeń, umożliwiając innym programom korzystanie z jego usług poprzez eksportowanie i importowanie funkcji. Po połączeniu każdy klient otrzymuje dedykowany blok struktury do przechowywania informacji o stanie. Program korzystający z sieci może zaimportować funkcję zapisu sieciowego i wyeksportować funkcję odczytu sieciowego. Tak więc, jeśli otworzysz połączenie sieciowe (np. używając TCP ), gdy dane przyjdą do odczytania, komponent sieciowy może bezpośrednio wywołać twoją funkcję, aby je wykorzystać, bez konieczności uprzedniego kopiowania danych do bufora i przełączania kontekstu . Podobnie możesz zapisywać dane w sieci, bezpośrednio wywołując funkcję zapisu sieciowego.

Biblioteki połączeń zapewniają znaczny stopień kontroli nad połączeniami. Każda strona połączenia może opcjonalnie zatwierdzić połączenie i może zerwać połączenie według potrzeb. Stan może być łatwo utrzymywany przez połączenie, a także globalnie.

Przenieś pliki

Inną techniką komunikacji między procesami (IPC) są pliki portów. Są one podobne do rur Unix , z wyjątkiem tego, że są uogólnione jako wielokierunkowe i dwukierunkowe. Ponieważ są one o rząd wielkości wolniejsze niż inne techniki IPC, takie jak biblioteki, lepiej jest użyć innych technik, w których IPC znajduje się między różnymi procesami na tej samej maszynie.

Najkorzystniejszym zastosowaniem plików portów jest zatem rozproszone IPC. Pliki portów zostały wprowadzone za pomocą BNA (Burroughs Network Architecture), ale wraz z pojawieniem się standardowych technologii sieciowych, takich jak OSI i TCP / IP , pliki portów mogą być również używane w tych sieciach.

Serwer nasłuchujący połączeń przychodzących deklaruje plik portu (plik z atrybutem KIND równym PORT). Każde połączenie nawiązywane z klienta tworzy podplik z indeksem, więc każdy plik portu reprezentuje wiele połączeń z różnymi klientami w sieci.

Proces serwera odbiera żądania klientów z dowolnego miejsca w sieci, wysyłając odczyt do pliku portu (podplik = 0, aby odczytać z dowolnego podpliku). Wysyła odpowiedź do klienta, który wysłał żądanie, pisząc do konkretnego fragmentu, z którego żądanie zostało odczytane.

Środowisko działania

MCP zapewnia również wyrafinowane, ale proste środowisko operatora. W przypadku dużych instalacji wielu operatorów może wymagać udostępnienia zasobów fizycznych, takich jak drukarki (ładowanie papieru, kaset z tonerem itp.). Środowiska low-end dla małych biur lub pojedynczego użytkownika mogą wymagać środowiska bez operatora (zwłaszcza implementacja laptopa).

Duże systemy mają dedykowane terminale operacyjne zwane ODT (Operator Display Terminals), zwykle przechowywane w bezpiecznym środowisku. W przypadku małych systemów maszynami można sterować z dowolnego terminala (pod warunkiem, że terminal i użytkownik mają wystarczające uprawnienia) za pomocą programu MARC (Menu Assisted Resource Control). Polecenia operatora mogą być również używane przez zaznajomionych z nimi użytkowników.

Polecenia operatora składają się w większości z dwóch liter (jak w Uniksie), a niektóre są tylko jedną literą. Oznacza to, że trzeba się nauczyć interfejsu operatora, ale jest on bardzo wydajny dla doświadczonych operatorów, którzy na co dzień obsługują duży system mainframe. W poleceniach nie jest rozróżniana wielkość liter.

Zadania są wprowadzane do programu 'mix' i identyfikowane numerami miksów, podobnie jak biblioteki. Aby wykonać program, operatorzy mogą użyć polecenia „EX” lub „RUN”, po którym następuje nazwa pliku programu. ODT są zwykle uruchamiane z ADM (Automatic Display Mode), który jest dostosowanym wyświetlaniem stanu systemu, zwykle skonfigurowanym do wyświetlania aktywnych, oczekujących i zakończonych wpisów mieszanych, a także komunikatów systemowych dla operatora w celu powiadomienia lub sytuacji wymagających działania operatora .

Pełna lista tych ekranów jest podana przez „A” (aktywny), „W” (oczekiwanie), „C” (zakończone) i „MSG” (polecenia wiadomości).

Jeśli zadanie czeka na jakąś akcję operatora, operator może dowiedzieć się, czego potrzebuje zadanie, wprowadzając jego numer mieszanki, a następnie komendę „Y”. (Zwróć uwagę na zorientowany obiektowo styl poleceń, wybierając najpierw obiekt, a następnie polecenie.) Na przykład „3456Y”.

Operator może wymusić zadanie w oczekujących wpisach za pomocą polecenia zatrzymania „3456ST” i aktywować je ponownie za pomocą przycisku OK: „3456OK”. Polecenia OK można również użyć, gdy operator udostępnił zasób dla zadania, chociaż częściej niż nie, MCP wykryje, że zasoby stały się dostępne, POWODUJĄC ZDARZENIE, na które czekały procesy bez dalszej interwencji operatora. Aby przekazać informacje tekstowe od operatora do programu, można użyć polecenia akceptacji „3456AX MORE INFO”. Programy mogą przekazywać informacje operatorom za pomocą mechanizmu DISPLAY, co powoduje dodawanie komunikatów DISPLAY do wyświetlacza MSG.

Oprócz zadań i procesów operatorzy mają również kontrolę nad plikami. Pliki można wyświetlić za pomocą polecenia PLIK, skopiować za pomocą KOPIUJ, usunąć za pomocą USUŃ i zmienić nazwę.

Środowisko operacyjne MCP jest potężne, ale proste i zwykle wymaga tylko ułamka liczby operatorów innych systemów.

Ważną częścią środowiska operacyjnego jest język przepływu pracy wysokiego poziomu .

Logowanie

Wszystkie akcje w systemie są rejestrowane, na przykład wszystkie komunikaty wyświetlane operatorowi i wszystkie akcje operatora. Wszystkie istotne działania programu są opcjonalnie rejestrowane w dzienniku systemowym i dzienniku programu, na przykład BOJ dla początku zadania WFL, BOT dla początku zadania w ramach zadania WFL, EOT i EOJ dla zakończenia zadań i zadań. Ponadto wszystkie otwarcia i zamknięcia plików i baz danych mogą być rejestrowane. Rejestrowanie wielu zdarzeń przyczynia się do widocznego spowolnienia środowiska operacyjnego MCP w porównaniu z systemami takimi jak Unix, ponieważ wszystko jest rejestrowane z wymuszonymi fizycznymi zapisami w dzienniku programu po każdym rekordzie, czego nie robią systemy takie jak Unix, chociaż one też przechowuj wiele rzeczy w dziennikach systemowych.

Dzienniki można wykorzystać do kryminalistyki, aby dowiedzieć się, dlaczego programy lub systemy mogły ulec awarii, lub do wykrywania prób naruszenia bezpieczeństwa systemu. Dzienniki systemowe są automatycznie zamykane po określonym przez system okresie i otwierane są nowe. Logi systemowe zawierają ogromną ilość informacji, które można filtrować i analizować za pomocą programów takich jak LOGANALYZER.

DUMPANALYZER analizuje zrzuty pamięci, które zostały pierwotnie zapisane na taśmie. Ponieważ wszystkie kompilatory dodały LINEINFO do plików kodu, DUMPANALYZER jest w stanie dokładnie określić, które polecenie źródłowe było wykonywane w momencie wystąpienia błędu.

Również normalny zrzut programu, w którym został zrzucony tylko jeden program, zawiera informacje o numerze sekwencyjnym kodu źródłowego i nazwach zmiennych.

Te dwa analizatory są głównymi narzędziami diagnostycznymi do wszelkiego rodzaju celów.

Innowacje

Poza wieloma innowacjami technicznymi w projekcie MCP, duże systemy Burroughs miały wiele innowacji w zakresie zarządzania, które są obecnie używane przez społeczność internetową. Oprogramowanie systemowe zostało wysłane do klientów wraz z kodem źródłowym oraz wszystkimi narzędziami do edycji i kompilacji potrzebnych do wygenerowania nowych wersji MCP dla klientów. Wielu klientów zdobyło niszową wiedzę na temat wewnętrznego działania MCP, a klienci często wysyłali „łatki” (fragmenty kodu źródłowego z numerami sekwencyjnymi) jako sugestie nowych ulepszonych funkcji lub korekty błędów (FTR – raporty o problemach w terenie). Wiele z sugerowanych poprawek zostało zawartych przez twórców systemów i zintegrowanych z następną wersją wydania MCP. Włączenie społeczności dobrowolnych, samozwańczych ekspertów do głównego nurtu prac technicznych jest obecnie szeroko praktykowane i stanowi istotę Otwartej Innowacji . Ta innowacja w zarządzaniu rozwojem społeczności sięga lat 70-tych.

Kompilatory

Unisys MCP miał w swojej historii kilka generacji kompilatorów obsługujących szeroką gamę języków programowania , w tym:

Inne produkty to:

Wcześniej istniały kompilatory dla ESPOL , COBOL(68), Fortran(66), APL i PL/I .

Monter

W systemie operacyjnym Unisys MCP nie ma asemblera, z wyjątkiem rodziny średnich systemów.

Streszczenie

MCP był pierwszym systemem operacyjnym opracowanym wyłącznie w języku wysokiego poziomu. W ciągu swojej 50-letniej historii firma miała wiele pierwszych zastosowań komercyjnych, w tym pamięć wirtualną, symetryczne przetwarzanie wieloprocesorowe i język kontroli zadań wysokiego poziomu (WFL). Od dawna ma wiele udogodnień, które dopiero teraz pojawiają się w innych rozpowszechnionych systemach operacyjnych, a wraz z architekturą dużych systemów Burroughs, MCP zapewnia bardzo bezpieczne, wydajne, wielozadaniowe i transakcyjne środowisko przetwarzania.

Bibliografia

Zewnętrzne linki