TSS (system operacyjny) - TSS (operating system)

TSS
IBM logo.svg
Deweloper IBM
Stan pracy Wycofane
Model źródłowy Dostępne źródło
Pierwsze wydanie 1967 ; 54 lata temu ( 1967 )
Dostępne w język angielski
Platformy System/360 Model 67 , Modele System/370 z DAT
Domyślny
interfejs użytkownika		 Interfejs linii komend
Licencja TSS/360: bezpłatny
TSS/370: zastrzeżony
Historia systemów operacyjnych IBM mainframe
Wczesne systemy operacyjne dla komputerów mainframe
Różne systemy operacyjne linii S/360
DOS/360 i następcy (1966)
OS/360 i następcy (1966)
Linia maszyny wirtualnej
Linia TPF
UNIX i uniksopodobny
IBM System/360 model 67-2. To jest model komputera, na którym uruchomiłoby się TSS/360

IBM Czas Udostępnianie systemu TSS / 360 jest przerwane wcześnie czas dzielenia system operacyjny zaprojektowany specjalnie dla specjalnego modelu System / 360 linii mainframe, w modelu 67 . Udostępniony w wersji próbnej dla ograniczonej liczby klientów w 1967 roku, nigdy nie został oficjalnie wydany jako produkt wspierany przez IBM. TSS był pionierem wielu nowatorskich funkcji, z których niektóre pojawiły się później w bardziej popularnych systemach, takich jak MVS . TSS został zmigrowany do systemów System/370 i 303x , ale pomimo wielu postępów i nowatorskich możliwości, TSS nie spełnił oczekiwań i został ostatecznie anulowany. TSS/370 został wykorzystany jako podstawa dla portu UNIX na mainframe IBM. TSS/360 zainspirował również rozwój systemu operacyjnego TSS-8 .

Nowatorska charakterystyka

TSS/360 był jedną z pierwszych implementacji ściśle sprzężonego symetrycznego przetwarzania wieloprocesowego . Para komputerów mainframe Model 67 współdzieliła wspólną fizyczną przestrzeń pamięci i uruchamiała pojedynczą kopię kodu jądra (i aplikacji). Operacja we/wy uruchomiona przez jeden procesor może zakończyć się i spowodować przerwanie w drugim. Model 67 używał standardowej instrukcji 360 o nazwie Test and Set do implementacji blokad w krytycznych dla kodu sekcjach .

Zaimplementowano również pamięć wirtualną i maszyny wirtualne przy użyciu kodu niezależnego od pozycji .

TSS/360 zawierał wczesną implementację „Table Driven Scheduler” – konfigurowanej przez użytkownika tabeli, której kolumny zawierały parametry takie jak bieżący priorytet, rozmiar zestawu roboczego i liczba używanych do tej pory przedziałów czasu. Jądro odwołuje się do tej tabeli podczas obliczania nowego priorytetu wątku . Pojawiło się to później w systemach tak różnych, jak Honeywell CP-V i IBM z/OS .

Zgodnie ze standardem w przypadku oprogramowania systemu operacyjnego w tamtym czasie, klienci TSS/360 (np. General Motors Research Laboratories ) otrzymali pełny dostęp do całego źródła kodu systemu operacyjnego i narzędzi programistycznych. Opracowane przez użytkowników ulepszenia i łatki były często włączane do oficjalnego kodu źródłowego.

Interfejs użytkownika

TSS zapewnia użytkownikom interfejs wiersza poleceń . Użytkownicy wchodzą w interakcję z systemem poleceń . Format polecenia składa się z Command_Name[ operands]. Nazwa polecenia składa się z jednego do ośmiu znaków bez osadzonych spacji. Operandy są opcjonalne w zależności od polecenia i muszą być oddzielone od nazwy polecenia co najmniej jednym odstępem. Wiele operandów należy oddzielić znakami TAB lub przecinkami. Wiersze poleceń można kontynuować, wpisując myślnik ("-") na końcu wiersza, który ma być kontynuowany, i wpisując kontynuację na początku następnego wiersza. W jednym wierszu można zapisać wiele poleceń, oddzielając je średnikami (";"). Komentarze są dozwolone w wierszach poleceń, oddzielone od polecenia średnikiem i ujęte w pojedyncze cudzysłowy ("'"). Operandy mogą być pozycyjne lub słowa kluczowe w formacie „słowo kluczowe=wartość”.

Polecenia systemowe podzielone są na siedem kategorii:

  • Zarządzanie zadaniami – LOGON, LOGOFF, ABEND itp.
  • Zarządzanie danymi – CATALOG, DDEF, DELETE itp.
  • Zarządzanie programami – LOAD, DUMP, DISPLAY, TRAP, itp.
  • Tworzenie poleceń – PROCDEF, BUILTIN
  • Obsługa wiadomości
  • Profil użytkownika – SYNONYM, DEFAULT, PROFILE itp.
  • Interfejs języka programu – ASM ( Assembler (F) ), COBOL , HASM ( Assembler (H) ), PLI ( PL/I (F) ), PLIOPT ( PL/I Optimizing Compiler ), FTNH ( FORTRAN (H)) , itp.

Kod niezależny od pozycji

TSS zapewniło wczesną implementację kodu niezależnego od pozycji , możliwość uruchamiania przez różne procesy pojedynczej kopii pliku wykonywalnego, prawdopodobnie zmapowanego na różne adresy wirtualne w każdym procesie.

Każda procedura może mieć publiczny CSECT tylko do odczytu, zapisywalną prywatną sekcję prototypową (PSECT) i zapisywalny obszar zapisu, zwykle zlokalizowany w PSECT. Stałe adresowe procedur zewnętrznych i punktów wejścia muszą znajdować się w PSECT, ponieważ dynamiczny program ładujący nie umieści procedury pod tym samym adresem wirtualnym w każdym procesie. Program, który przestrzega konwencji powiązań typu I, jest ogólnie odpowiedzialny przy wejściu za zapisywanie swoich rejestrów w obszarze zapisywania wskazywanym przez rejestr 13, pobierając adres swojego PSECT ze słowa 19 obszaru zapisywania, łącząc obszar zapisywania z nowym obszarem zapisywania i umieszczenie adresu nowego obszaru zapisu w rejestrze 13. Wywołujący, który przestrzega konwencji powiązania typu I, ładuje stałą V dla procedury do rejestru ogólnego 15 (GR15) i kopiuje stałą R dla PSECT procedury do 19. słowa obszaru zapisu wskazywanego jako GR13 przed wywołaniem tych procedur.

Gdy dynamiczny program ładujący ładuje program, tworzy kopię PSECT i przenosi adcons, aby odzwierciedlić wirtualne adresy przypisane w bieżącym procesie, dlatego każdy użytkownik programu ma unikalną kopię PSECT.

Dynamic Loader nie ładuje stron programu ani nie rozwiązuje stałych adresów aż do pierwszego błędu strony.

Krytyka

TSS/360 cierpiał z powodu problemów z wydajnością i niezawodnością oraz brakiem kompatybilności z OS/360 , chociaż te problemy zostały ostatecznie rozwiązane. IBM próbował rozwijać TSS według bardzo agresywnego harmonogramu z dużą liczbą programistów, aby konkurować z Multics . W 1967 stało się jasne, że TSS/360 cierpi z powodu tych samych opóźnień, co OS/360. W lutym 1968, w czasie SHARE 30, osiemnaście stron S/360-67 próbowało uruchomić TSS. Podczas konferencji IBM ogłosił „niebieskim listem”, że TSS/360 jest zwalniany – wielki cios dla społeczności korzystającej z time-sharingu. Ta decyzja została tymczasowo cofnięta, a TSS/360 nie został oficjalnie anulowany do 1971 roku. Jednak TSS/360 nadal był przez pewien czas po cichu dostępny dla obecnych klientów TSS/360, jako środek tymczasowy.

Po anulowaniu TSS/360 IBM włożył swoje główne wysiłki w opcję Time Sharing Option (TSO), monitor z podziałem czasu dla OS/360. Kilka innych grup opracowało mniej ambitne, bardziej skuteczne systemy współdzielenia czasu dla S/360-67, w szczególności CP-67 w Cambridge Scientific Center IBM , wczesny monitor maszyny wirtualnej, który przekształcił się w VM/370 , MTS na Uniwersytecie Michigan oraz ORVYL na Uniwersytecie Stanforda . IBM dostarczył również TSS/370 PRPQ jako ścieżkę migracji dla istniejących klientów TSS/360, która przeszła wiele wersji.

Zobacz też

Bibliografia

Dalsza lektura

Linki zewnętrzne