MTS systemarkitektur

För bredare täckning av detta ämne, se Michigan Terminal System .
Michigan Terminal System (MTS)
MTS signon screenshot.png
MTS välkomstskärm sett genom en 3270 terminalemulator .
Utvecklare University of Michigan och 7 andra universitet i USA, Kanada och Storbritannien
Skrivet i olika språk, mestadels 360/370 Assembler
Arbetstillstånd Historisk
Initial release 1967
Senaste släppningen 6.0/1988 (slutlig)
Tillgänglig i engelsk
Plattformar IBM S/360-67, IBM S/370 och efterföljare

Standardanvändargränssnitt _ 		Kommandoradsgränssnitt
Licens Gratis ( CC BY 3.0 )
Officiell hemsida archive.michigan-terminal-system.org

MTS System Architecture beskriver programvaruorganisationen för Michigan Terminal System , ett datoroperativsystem för tidsdelning som användes från 1967 till 1999 på IBM S/360-67 , IBM System/370 och kompatibla datorer.

Översikt

MTS arkitektur
stat Läge VM Avbryter
Användarprogram problem användare på på


Kommandospråksundersystem (CLS), enhetsstödsrutiner (DSR), systemunderrutiner 		systemet
Jobbprogram (MTS, PDP, DMGR, RM eller HASP, ...) på eller av
Handledare (UMMPS) handledare n/a av av
S/360-67 eller S/370 hårdvara

University of Michigan Multi-Programming Supervisor (UMMPS), har fullständig kontroll över hårdvaran och hanterar en samling jobbprogram. Ett av jobbprogrammen är MTS, jobbprogrammet som de flesta användare interagerar med. MTS fungerar som en samling av kommandospråksundersystem (CLS). En av CLS:erna tillåter exekvering av användarprogram. MTS tillhandahåller en samling systemunderrutiner som är tillgängliga för CLS, användarprogram och MTS själv. Bland annat ger dessa systemunderrutiner standardåtkomst till Device Support Routines (DSR), de komponenter som utför enhetsberoende in-/utdata.

Organisation

Systemet är organiserat som en uppsättning oberoende komponenter med väldefinierade gränssnitt mellan dem. Denna idé är naturligtvis varken ny eller unik; men MTS-komponenter är generellt sett större, gränssnitt mellan komponenter mer stela och en komponent kommunicerar med färre andra komponenter än i många system. Som ett resultat är komponenterna mer oberoende av varandra och det är lättare att byta ut en komponent utan att påverka andra.

Gränssnittet med handledaren är detsamma för alla komponenter och mycket få specialfall är tillåtna; t.ex. görs alla inmatnings-/utmatningsoperationer med användning av samma övervakare, oavsett om inmatningen/utmatningen är för en kortläsare, en personsökningsenhet eller någon annan enhet. Den mesta åtkomsten till supervisortjänster sker via systemunderrutiner som utfärdar de nödvändiga supervisor Call-instruktionerna (SVC) snarare än genom direkt användning av SVC:er. Kontrollblock nås endast indirekt genom anrop till subrutiner inom den komponent som "äger" kontrollblocket.

Gränssnitten som används av användarprogram är de renaste av alla. Användarprogram får aldrig referera direkt till något systemkontrollblock (varken för referens eller ändring), eftersom det eller de virtuella minnessegmenten som innehåller systemkontrollblock (systemsegmenten) tas bort från ett jobbs virtuella adressutrymme när ett användarlägesprogram körs. De subrutingränssnitt som är tillgängliga för användarprogram används också av de flesta andra delar av systemet (systemlägesprogram, CLS, ...) även genom att komponenter som körs i systemläge har tillgång till "systemets" virtuella minnessegment. Övergångar från användarläge till systemläge och tillbaka hanteras av en speciell skyddad uppsättning subrutingränssnitt som kallas "the gate" (ursprungligen utvecklad vid Wayne State University).

Programmeringsinsatsen för MTS är uppdelad vertikalt snarare än horisontellt. Det innebär att en eller två individer tilldelas ansvar för en komponent och sedan följer den från design till implementering och underhåll. Den ansvariga personen har stor frihet att utforma den interna strukturen för komponenten och till och med utöka gränssnitt, så länge som alla lämpliga befintliga gränssnitt bibehålls oförändrade.

Programmeringsspråk och felsökning på systemnivå

Handledaren, de flesta jobbprogram, stora delar av MTS inklusive många DSR och CLS är skrivna på 360/370 assemblerspråk. Några jobbprogram och delar av MTS inklusive vissa DSR och CLS är skrivna på högre nivåspråk som Plus eller GOM . Användarprogram är skrivna på ett brett utbud av språk från assembler till något av de överordnade språken som är tillgängliga.

De flesta komponenter i systemet, inklusive användarprogram, CLS:er och subrutiner som laddas i delat virtuellt minne, kan felsökas och nya versioner av många kan installeras medan systemet körs utan att systemet behöver stängas av. Det är möjligt att ersätta en privat kopia av alla komponenter utom handledaren och delar av vissa jobbprogram. En "test"-version av MTS-jobbprogrammet (TMTS) är tillgänglig för att möjliggöra testning i den vanliga produktionsmiljön. SWAT är ett gränssnitt som gör att Symbolic Debugging System, som normalt används för att felsöka användarprogram, kan användas för att felsöka MTS. $PEEK är ett privilegierat MTS-kommando som använder Program Event Recording (PER) och andra faciliteter för att underlätta felsökning av ett jobbprogram från ett annat. Komponenter som inte kan felsökas på detta sätt kan felsökas genom att köras i en virtuell MTS-maskin (ett användarprogram).

Handledare

University of Michigan Multi-Programming Supervisor (UMMPS) är namnet på MTS- handledaren . UMMPS är den enda delen av systemet som körs i S/360-övervakartillstånd. Den körs med virtuellt minne (omlokalisering) avstängt och med hårdvaruavbrott inaktiverade. Med flerprocessorkonfigurationer kan den köras på mer än en processor samtidigt. UMMPS är vad som idag skulle kallas en mikrokärna , även om UMMPS utvecklades långt innan den termen var allmänt använd.

Till jobb verkar UMMPS vara en förlängning av S/360- eller S/370-hårdvaran och ansvarar för:

  • allokera alla hårdvaruresurser ( processorer , verkligt minne , in-/utgångsenheter),
  • schemalägga I/O-operationer,
  • bearbeta alla hårdvaruavbrott inklusive sidfel och programavbrott på grund av fel i jobbprogram,
  • implementera virtuellt minne inklusive:
    • tilldelningen av VM-adresser,
    • hantera segment- och sidtabeller,
    • tillhandahålla skyddat eller skrivskyddat minne genom att ställa in lagringsnycklar,
    • hantera minnesreferens och ändringsbitar,
    • hantera namngivna adressutrymmen (NAS),
    • bestämma när och vilka sidor som ska flyttas mellan verkligt minne och sekundär lagring för att implementera efterfrågesökning ,
  • tillhandahåller tjänster till jobbprogram som utfärdar instruktioner för Supervisor Call (SVC) och Monitor Call (MC), inklusive:
    • starta och avsluta jobb,
    • initiering av in-/utgångsoperationer (kanalprogram),
    • schemaläggningstimeravbrott,
    • kommunikation med systemoperatören,
    • tillhandahålla kommunikationstjänster mellan olika uppgifter,
    • tillåta jobb att förvärva och släppa mjukvarulås,
    • tillåta jobb att gå in i och lämna användar- och systemläge, där användarlägesprogram inte har tillgång till vissa virtuella minnessegment och hela utbudet av SVC,
    • tillhandahålla tjänster för att möjliggöra synkronisering av jobbprogram,
    • tillhandahålla skuggsegment- och sidtabeller och andra tjänster som tillåter jobbprogram att tillhandahålla virtuella maskintjänster ,
  • simulerar några maskininstruktioner som finns på vissa, men inte alla, modeller av S/360- eller S/370-datorerna,
  • simulera pseudoinstruktionerna Branch on Program Interrupt (BPI),
  • maskinkontrollfelåterställning,
  • skriva jobbdumpar (gör en ögonblicksbild av det aktuella exekveringstillståndet för ett jobb genom att skriva ut allt verkligt minne, alla jobbets virtuella minne, allmänna register och programstatusord till magnetband),
  • spåra mängden processortid som används och antalet page-ins för jobb,
  • bibehålla tid på dygnet, och
  • hjälpa till med att skapa diagnostiska spårband.

Efter initialisering är UMMPS helt avbrottsdriven. Avbrotten kan bero på supervisor (SVC) eller monitor (MC) anropsinstruktioner utfärdade av jobbprogram för att begära tjänster, sidfelavbrott för virtuella minnessidor som inte finns i verkligt minne när de refereras av ett jobbprogram, programavbrott orsakade av onormala förhållanden i jobbprogram, timeravbrott på uppdrag av jobbprogram eller används internt inom arbetsledaren, avbrott från in-/utgångsundersystemet, maskinkontrollavbrott, externa (operatörsinitierade) avbrott och avbrott från andra processorer i en multiprocessorkonfiguration.

Ett programavbrott i supervisor-tillstånd är ett systemfel som resulterar i en supervisor-dump (en Super Dump, där maskintillståndet och innehållet i allt verkligt minne skrivs till magnetband) följt av en systemomstart (re-IPL).

Branch on Program Interrupt (BPI)

Pseudoinstruktionen Branch on Program Interrupt (BPI) tillhandahåller ett enkelt sätt för en kodsekvens att behålla kontrollen efter ett programavbrott. Detta kan vara användbart för att testa för giltiga adresser i en parameterlista, för att fånga överflöde, underflöde och andra undantag under beräkningar, eller egentligen alla situationer där ett programavbrott är möjligt. BPI:er kan användas till mycket låg kostnad för det vanligtvis vanligare fallet där det inte finns något programavbrott.

UMMPS implementerar pseudoinstruktionen Branch on Program Interrupt (BPI) med hjälp av en speciell typ av NOP-instruktion. Formen för BPI-instruktionen är:

 BPI M  2  , D  2  (B  2  ) [RX]

eller

 BC 0,D  2  (M  2  ,B  2  ) [RX] 
 Op Code Mask  1  Mask  2  Base Displacement +--------+--------+--- ----+-------+------------+ | x'47' |  0 |  M   2  | B   2  | D   2  | +--------------+-------+-------+-------+----- --+ 0 8 12 16 20 31

Där Mask 1 alltid är noll, är Mask 2 ett namn eller värde som beskrivs i tabellen nedan, och basen och förskjutningen anger en grenadress. Flera BPI-instruktioner kan ges i följd. BPI-instruktionen är tillgänglig för användning i problemtillstånd såväl som i supervisor-tillstånd (det vill säga inom UMMPS själv).

När en instruktion orsakar ett programavbrott, kontrolleras följande instruktion för att fastställa om det är en BPI-instruktion. Om så är fallet jämförs typen av programavbrott som inträffade med typkategorierna som specificeras i Mask 2 -delen av BPI-instruktionen. Om det finns en matchning sätts villkorskoden för att återspegla avbrottet som inträffade och grenen tas. I annat fall kontrolleras nästa instruktion för att avgöra om det är en BPI-instruktion, etc. Om det inte görs någon BPI-överföring (antingen för att det inte fanns någon BPI-instruktion eller för att programavbrottstypen inte matchade masken för några BPI:er som fanns närvarande ), sker den normala bearbetningen av programavbrottet.

När BPI-instruktionen exekveras normalt (när det inte finns något programavbrott på den föregående instruktionen), är det en NOP- eller "branch never"-instruktion.

BPI-kategorier av avbrottstyp:


Mask 2 Namn
Mask 2 Värde
Avbrottsnummer _
Avbrottsnamn _
Villkorskod på filial
OPCD 8 1 Drift 1
2 Privilegerad drift 2
3 Kör 3
OPND 4 4 Skydd 0
5 Adressering 1
6 Specifikation 2
7 Data 3
OVDIV 2 8 Fast bräddavlopp 0
9 Fast delning 1
10 Decimalspill 2
11 Decimaldelning 3
FP 1 12 Exponentspill 0
13 Exponentunderflöde 1
14 Betydelse 2
15 Flytpunktsdelning 3

Jobbprogram

Alla jobbprogram som körs i S/360-problemtillstånd, kan köras med virtuell adressering aktiverad eller inaktiverad, och kan eller kanske inte kommer in på nytt (mer än en instans av jobbprogrammet kan eller kanske inte tillåts köras). Med multiprocessorkonfigurationer kommer ett enstaka jobb bara att köras på en enda processor åt gången, men arbetsledaren kan tilldela ett jobb till olika processorer vid olika tidpunkter.

MTS-jobbprogrammet är det som de flesta användare interagerar med och tillhandahåller kommandotolkning, exekveringskontroll, fil- och enhetshantering och redovisningstjänster. Andra jobbprogram hjälper handledaren (Paging Device Processor eller PDP, OPERATOR-konsoljobbet, Diskhanteraren eller DMGR, ...), tillhandahåller gemensamma eller delade tjänster (spoolade lokala och fjärranslutna batchtjänster via HASP och HASPlingarna eller senare Resource Manager eller RM som utvecklades vid University of British Columbia för att ersätta HASP), eller tillåta systemoperatörerna att visa status och på annat sätt styra systemet (JOBS, ENHETER, STOP, BLAST, GOOSE, STARTUP, SHUTDOWN, REW, WTM, ...).

Nya jobb, förutom det allra första jobbet, startas av förfrågningar till UMMPS från andra jobb, oftast OPERATOR-jobbet. Det allra första jobbet, INIT, påbörjas omedelbart efter IPL och arbetsledareinitiering.

24-, 31- och 32-bitars adressering

Från starten och under stora delar av sin livstid fungerade UMMPS och MTS med 24-bitars adressering. UMMPS använde aldrig de 32-bitars virtuella minnesadresser som fanns tillgängliga på IBM S/360-67.

I augusti 1982 ändrade University of Alberta UMMPS för att fungera i 31-bitars adresseringsläge för att tillåta mer än 16 MB verkligt minne att användas, även om verkligt minne över 16 MB endast användes för att hålla virtuella minnessidor. Jobbprogram och användarprogram fortsatte att använda 24-bitars adresser.

1985 gjorde Rensselaer Polytechnic Institute (RPI) ändringar i UMMPS för att stödja S/370-XA som bland annat tillät antingen 24- eller 31-bitars adressering för jobbprogram och för användarprogram som körs under MTS. Ändringar gjordes vid University of Michigan 1990 för att tillåta användarprogram som använder 31-bitars adresser att fungera smidigt: objektmoduler kunde flaggas som stöd för 31-bitars adressering (eller inte), kompilatorer och assemblerare ändrades för att tillhandahålla rätt flaggor, program skulle växla mellan 24 och 31-bitars adresseringslägen efter behov vid övergång mellan system- och användarlägen.

Skydd

MTS har en stark skyddsmodell som använder den virtuella minneshårdvaran och S/360- och S/370-hårdvarans övervakare och problemtillstånd och via mjukvara delar upp problemtillståndsexekvering i system (privilegierat eller oskyddat) och användarläge (skyddat eller oprivilegierat). Relativt lite kod körs i supervisor state. Till exempel är Device Support Routines (DSR, aka device drivers) inte en del av supervisorn och körs i systemläge i problemtillstånd snarare än i supervisortillstånd.

Virtuellt minne och personsökning

Virtuellt minne (VM) och efterfrågesökningsstöd lades till UMMPS i november 1967, vilket gjorde MTS till det första operativsystemet att använda funktionerna för dynamisk adressöversättning (DAT) som lades till IBM S/360-67 .

UMMPS använder 4096-byte virtuella minnessidor och 256-sidiga virtuella minnessegment. UMMPS kunde villkorligt monteras för att använda de små (64 sidor) segment som fanns tillgängliga på S/370 hårdvara, men jobbprogram presenterades alltid med vad som verkade vara stora (256 sidor) segment. Både 2K- och 4K-blocklagringsnycklar stöds.

Det finns en lagringshierarki med tre nivåer: (1) verkligt minne, (2) höghastighetssökningsenheter och (3) personsökarskivor. Höghastighetspersonsökningsenheter inkluderar IBM 2301 Drum , IBM 2305 Fixed Head File och olika tredjeparts "solid-state" I/O-enheter som STC 4305 och Intel 3805 som simulerar snurrande skivor eller oftare tillhandahåller effektivare fast block arkitektur (FBA) åtkomst till extern RAM-baserad lagring. Höghastighetssökningsenheterna är anslutna med "två-byte" I/O-kanaler som arbetar med upp till 3,0 MB per sekund när det är möjligt. Personsökningsskivorna var separata från diskarna som användes för filsystemet och användes om personsökningsenheterna med högre hastighet blev fulla. Virtuella minnessidor migrerar mellan verkligt minne och personsökningsenheterna. I de tidiga versionerna av MTS migrerade inte sidor mellan enskilda personsökningsenheter. I senare versioner skulle mindre ofta använda sidor migrera från höghastighetssökningsenheterna till personsökningsskivorna, när höghastighetsenheterna var nära att vara fulla. Senare i sitt liv ändrades systemet till att använda IBM S/370-XA Extended Storage som en del av den andra nivån i lagringshierarkin och för att använda samma diskar för filsystemet och för personsökning.

Virtuellt minne hanteras av UMMPS med hjälp från jobbprogrammet Paging Device Processor (PDP). UMMPS svarar på förfrågningar om att allokera och frigöra VM från jobbprogram, allokerar VM-adresser, allokerar verkligt minne, hanterar segment- och sidtabeller, ställer in lagringsnycklar, hanterar referens- och ändringsbitar, bestämmer vilka virtuella minnessidor som ska sökas in eller ut, och kommunicerar med PDP. Nya virtuella minnessidor initieras till ett "kärnkonstant"-värde på x'81' vid första referens.

PDP är ett riktigt minnesjobbprogram. Den allokerar utrymme på personsökarenheterna, initierar alla I/O till personsökningsenheterna, ansvarar för återställning från I/O-fel och kommunicerar med UMMPS.

För att minska sannolikheten för att tjata använder UMMPS en "stor jobbmekanism" som identifierar jobb med fler riktiga sidor än en tröskel, begränsar antalet av dessa "stora" jobb som är kvalificerade att utföra vid en given tidpunkt, och ger de stora jobben en längre tid när de körs. Detta gör att stora jobb kan ackumulera fler riktiga minnessidor och att bättre utnyttja dessa sidor innan de tar slut, men stora jobb kommer att vänta längre mellan tidssegmenten när det finns för många stora jobb som tävlar om begränsade riktiga minnessidor. Antalet sidor som ett jobb kan ha innan det anses vara stort (den stora jobbtröskeln eller BJT) och antalet stora jobb (NBJ) som är kvalificerade för utförande är externa parametrar som omvärderas och sätts utanför arbetsledaren var 20:e sekunder baserat på den totala systembelastningen.

Förutom den stora jobbmekanismen är UMMPS-lagring, processor och I/O-schemaläggning oberoende, där varje område får "ta hand om sig självt".

Virtuellt minne är uppdelat i regioner enligt följande:

  • Segment 0: delat virtuellt är lika med verkligt minne (skrivskyddat)
  • Segment 1 till 4: delat virtuellt minne (skrivskyddat)
  • Segment 5: privat virtuellt minne (systemsegment, endast tillgängligt för systemläge (oskyddade) program)
  • Segment 6 till 12: privat virtuellt minne (användarsegment, läs-skriv till valfritt program)

Olika antal segment tilldelades de olika regionerna över tiden och med tillkomsten av 31-bitars adressering och möjligheten att använda VM-segment större än 16, utökades regionerna enligt följande:

  • Segment 0: delat virtuellt är lika med verkligt minne (skrivskyddat)
  • Segment 1 till 5: delat virtuellt minne (skrivskyddat)
  • Segment 6-7: privat virtuellt minne (systemsegment, endast tillgängligt för systemläge (oskyddade) program)
  • Segment 8: delat virtuellt minne för bifogning av namngivna adressutrymmen (NAS) (skrivskyddad)
  • Segment 9-55: privat virtuellt minne (användarsegment, läs-skriv till valfritt program)
  • Segment 56-59: privat virtuellt minne (systemsegment, endast tillgängligt för systemläge (oskyddade) program)
  • Segment 60-63: delat virtuellt minne för bifogning av namngivna adressutrymmen (NAS) (skrivskyddad)

En del verkligt minne är inte adresserbart med virtuella minnesadresser och är därför endast tillgängligt för UMMPS eller verkliga minnesjobbprogram. Skrivskyddat virtuellt minne kan ändras av privilegierade program som stänger av minnesskyddet (vanligtvis under mycket begränsade tidsperioder).

Namngivna adressutrymmen (NAS) tillåter bifogning av namngivna segment av virtuellt minne. De är delade virtuella minnesutrymmen som kan kopplas till och kopplas bort från ett visst jobbs virtuella adressutrymme och samma adresser kan ha olika innehåll beroende på vilka namngivna adressutrymmen som är kopplade. NAS-stöd används mestadels av MTS för att fästa VM-segment förladdade med systemkomponenter som ett sätt att utöka delat virtuellt minne utan att använda VM-adressutrymme under den magiska 16 MB-linjen och därmed hålla mer av detta värdefulla adressutrymme tillgängligt för användning med 24-bitars användarprogram.

Signon och projekt-ID

Alla som använder MTS tilldelas ett inloggnings-ID (även kallat användar-ID eller Computing Center ID, CCID). Signon-ID:n är alltid 4 tecken långa. Om nödvändigt utfylls kortare ID:n automatiskt till höger med strängen ".$.". Således, ID:n "MTS.", "DAB.", "ME$." eller "C.$." kan skrivas som "MTS", "DAB", "ME" respektive "C".

Signon-ID:n skyddas med lösenord som måste anges i början av varje session (som en del av eller oftare omedelbart efter $ SIGNON- kommandot). Undantag är jobb som skickas via *BATCH* som körs under samma ID som skickade in det nya jobbet, jobb som är schemalagda att köras upprepade gånger vid en viss tidpunkt eller en viss dag när jobben körs under samma ID som schemalagda dem, eller jobb som initierades från operatörens konsol. Lösenord är från 1 till 12 tecken långa, små bokstäver konverteras till versaler, andra specialtecken än kommatecken och tomma är tillåtna. Lösenord kan ändras med kommandot $SET PW . För att ändra ett lösenord från en terminalsession måste du ange det ursprungliga lösenordet, och det nya lösenordet måste anges två gånger för verifiering.

Att ange ett felaktigt lösenord räknas och rapporteras till användaren vid nästa lyckade inloggning. Alltför många lösenordsfel utan en lyckad inmatning rapporteras till systemoperatören och ännu fler lösenordsfel utan en lyckad inmatning kommer att göra att inloggnings-ID:t "låses ute" tills det återställs av kontorspersonalen. En kort fördröjning införs mellan misslyckade lösenordsinmatningsförsök för att förhindra att ett stort antal "gissningar" av lösenord görs snabbt.

Individer kan ha flera sign on-ID för användning i olika kurser, olika forskningsprojekt eller med olika finansieringskällor (universitet, regering, ideell verksamhet, industri, ...). Individer avråds från att dela signon-ID:n, men förekommer.

Signon-ID:n grupperas i projekt. Varje inloggnings-ID är medlem i ett och endast ett projekt. Projekt-ID:n, liksom signon-ID:n, är fyra tecken långa. Många projekt styrs av ett "Project Leader" signon-ID som kan allokera resurser till de konton som är medlemmar i projektet (inom de resursgränser som tilldelats projektet) med kommandot $ACCOUNTING MANAGEMENT .

Signon och projekt-ID används också för att kontrollera åtkomst till filer och för att skicka e-post.

Med ett undantag finns det inga inloggnings-ID:n med "särskilda" privilegier på grund av själva ID:n. Istället kan flaggor ställas in som tillåter specifika inloggnings-ID:n att:

  • skapa offentliga filer och ställ in offentliga programnycklar,
  • köra med noll eller negativt kontosaldo,
  • utföra privilegierade operationer, inklusive:
    • flagga filer för att köras i system (oskyddat) snarare än användarläge (skyddat) som standard,
    • använd PROT=OFF -alternativen på kommandona $SET och $RUN ,
    • använd undersystemet för testkommandospråk ( $#CLS ) ,
    • använd privilegierade alternativ för $SYSTEMSTATUS och andra kommandospråksundersystem (CLS).

Undantaget är signon-ID "MTS.", som kan läsa, men inte modifiera eller tillåta, vilken fil som helst i systemet oavsett ägande eller tillståndsstatus. MTS. ID kan också använda $SET FILEREF=OFF , som förhindrar att filreferensdatum på filer uppdateras (användbart när du återställer från filsystemproblem eller undersöker säkerhetsproblem).

Det finns ingen möjlighet för ett program eller en användare att anta privilegierna för ett inloggnings-ID annat än det som användes för att logga in på den aktuella sessionen. Istället kan program och filer tillåtas för specifika inloggnings-ID:n, projekt och programnycklar eller till kombinationer av inloggnings-ID:n, projekt och programnycklar.

Terminal-, batch- och serversessioner

MTS stöder terminal-, batch- och serversessioner. Alla tre använder samma kommandospråk.

  • Terminalsessioner är interaktiva med användaren som kan svara på utdata som produceras inklusive felmeddelanden och uppmaningar.
  • Batchjobb är inte interaktiva och därför måste all inmatning förberedas i förväg med liten eller ingen möjlighet för användaren att ändra inmatningen (åtminstone inte utan programmering) när batchjobbet börjar köras.
  • Serversessioner kan stödja interaktioner från användare till MTS eller klient till MTS och även om det kan förekomma interaktion med användaren läses MTS-kommandon vanligtvis från en kommandofil och användaren behöver sannolikt inte känna till eller ange MTS-kommandon. Serversessioner kan sponsras i vilket fall de ser ut att vara gratis för användaren och kräver inte att användaren anger ett ID och lösenord. Serversessioner kan också debiteras för och kräver ett giltigt ID och lösenord. Serversessioner kan initieras från nätverket eller från en MTS-session med kommandot $MOUNT .

University of Alberta utvecklade en studentorienterad batch-anläggning 1971 för att ge snabba arbetstillfällen för studenter som lär sig programmera i FORTRAN, ALGOL, PL/C och 360 Assembler. Det var en dedikerad hålkortsinmatning, skrivarutgångssystem som gav 5 minuters vändning och körde flera tusen jobb i veckan till en fast kostnad per jobb (15 cent).

Kommandospråk

MTS läser kommandon från *SOURCE* pseudoenheten, som initialt är användarens terminal eller batchinmatningsströmmen. Program kan utföra MTS-kommandon genom att anropa CMD-, CMDNOE- och COMMAND-subrutinerna.

Inledande och efterföljande blanktecken samt noll och alla tomma rader ignoreras. Rader som börjar med en asterisk ( * eller $* ) behandlas som kommentarer. Kommandorader som slutar med ett fortsättningstecken (som standard minustecknet) fortsätter på nästa rad. Kommandorader kan vara upp till 255 tecken långa.

MTS använder nyckelordsorienterade kommandon och kommandoalternativ. Kommandoverbet ( SIGNON , RUN , EDIT , ...) är det första nyckelordet på kommandoraden. Kommandon kan börja med ett valfritt dollartecken ( $SIGNON , $RUN , $EDIT , ...). I batch-jobb, efter ogiltiga kommandon och några andra fel, letar MTS efter nästa rad som börjar med ett dollartecken ( $ ) i kolumn 1 som nästa kommando att köra. Alla kommandon och de flesta kommandoalternativ tillåter initiala delsträngsförkortningar ( C för COPY , R för RUN , DEB för DEBUG , ...). MTS-kommandon och de flesta kommandoalternativ är skiftlägesokänsliga.

MTS har "one-shot" kommandon ( CREATE , FILESTATUS , SIGNOFF , ...) och kommandon som har underkommandolägen ( EDIT , CALC , SYSTEMSTATUS , ...). De flesta kommandon med underkommandolägen kan också anropas som engångskommandon genom att ge ett eller flera underkommandon på kommandoraden.

Alla MTS-jobb börjar med ett SIGNON- kommando och de flesta slutar med ett SIGNOFF -kommando. Kommandon kan lagras i filer och köras med kommandot SOURCE . Kommandon kan lagras i signon-filer (sigfiler) eller projekt-signon-filer (projectsigfiler) som alltid körs omedelbart efter kommandot SIGNON . Exekveringen av sigfiler kan krävas ( SIGFILEATTN=OFF ) eller valfritt ( SIGFILEATTN=ON , standard).

Lista över MTS-kommandon

Global kontroll 

 SIG  INTE {  ccid  | * } [   alternativ  ... ] [  kommentar  ]  SIGN  AV [ KORT | $ |  LÅNGT ] [ Kvitton |  NORECIPTS ]   AC  COUNTING [  alternativ  ... ]  AC  COUNTING  HANTERING  KOM  MENTAR  [  text  ]  VISA  objekt  [  OUTPUT =  FDname  ]  SE  T  alternativ  ...  SIN  K [  FDname  | FÖREGÅENDE ]   KÄLLA  [  FDname  | FÖREGÅENDE ]   SY  STEMSTATUS [  option  ]  #  CLS  FDname  [  options  ] (privilegierat kommando som kör en test CLS)

Filhantering 

 
 CR  EATE  filnamn  [ SIZE={  n  |  n  P } ] [MAXSIZE={  n  |  n  P} ] [TYPE={LINE | SEQ |  SEQWL} ]   DES  TROY  fillista  [ OK | ALLOK |  PROMPT ]   DUP  LICATE  oldname  [ AS | TO ]   nytt namn  [  alternativ  ] [ OK | ALLOK |  PROMPT ]   EDIT  [  filnamn  ] [ :  edit-command  ]  EM  PTY [  fillista  ] [ OK | ALLOK |  PROMPT ]   T  RUNCATE  fillista  [ ALLOK | PROMPT ]   RENA  ME  oldname  [ AS ]  newname  [ OK | ALLOK |  PROMPT ]   RENU  MBER  fillista  [  första  [  sista  [  börja  [  inkrement  ] ] ] ] [ ALLOK | PROMPT ]   FILESTATUS  [  fillista  ]  [  format  ] [  objekt  ]  FIL  ENU  [  fillista  ] [  objekt  ]  FM  ENU [  fillista  ] [  objekt  ]  TILLHÖJANDE  fillista  [  åtkomst till  [  accessor  ] ]  TILLÅTAR  fillista  LIKE  fillista2  [ UTOM  åtkomst  [  accessor  ] ]  LÅS  filnamn  [  hur  ] [ VÄNTA | NUWAIT ] [ AVSLUTA |  NOQUIT ]   LOCKA  K  -filnamn  LOCKS  TATUS [  filnamn  | JOBB   nnnnnn  ] [ LÅS ] [ VÄNTA ]  LS  TATUS [  filnamn  | JOBB   nnnnnn  ] [ LÅS ] [ VÄNTA ]

Fil- och enhetshantering 

 KOPIERA  [FRÅN] {  FDlist1  |  'sträng'  }  [ [ TO ] [  FDlist2  ]  SKAPA  *pdn*  TYPE={ SKRIV UT | IMPORTERA |  EXPORT |  DUMMY }   DES  TROY  *pdn*  [ OK | ALLOK |  PROMPT ]   L  IST  FD-lista  [ [ PÅ | TO ]   FDname  ] [ [ WITH ]  alternativ  ... ]  L  IST  FD-lista  MED  alternativ  [ {ON | TO}   FDname  ]  L  IST  MOUN  NT [ begäran [; begäran ] ... ]   KAN  CEL *...* [ [ JOBB ]  nnnnnn  ] [ {ID | CCID}=   ccid  ]  REL  EASE { *PRINT* | *PUNCH* |  *BATCH* |  *   pdn  * }  LOCA  TE { SYSTEM | LOKAL |  FULLT |  KORT |  HJÄLP }   LOCA  TE {  jobbnummer  |  jobbnamn  } [  alternativ  ... ]  VIE  W [  jobbnummer  [ ;  view-command  ] ]  LOGG  [  FDname1  ] { [ ON ]  FDname2  [  format  ] [  optioner  ] | AV }   FTP  [  värdnamn  ]  HÄMTA  FD  -namn  (gammaldags och föråldrat, men ibland fortfarande användbart)  NUM  BER (gammaldags och förlegat sätt att mata in data i en fil)

Utförande och kontroll av användarprogram 

  
 R  UN [  FDname  ] [  I/Units  ] [  option  ] ... [ PAR=  parametrar  ]  RER  UN [ ECHO | NOECHO ] [   I/Ounits  ] [  option  ] ... [ PAR=  parametrar  ]  DEB  UG [  FDname  ] [  I / Units  ] [  option  ] ... [ PAR=  parametrar  ]  SDS  [  sds-kommando  ]  LOA  D [  FDname  ] [  I/Enheter  ] [  option  ] ... [ PAR=  parametrar  ]  ST  ART [ [ AT ] [ RF={  hhhhhh  | GR   x  } ]  plats  ] [  I/enheter  ] [  alternativ  ] ...  ÅTERSTART  [ [ AT ]  plats  ] [  I / enheter  ] [  alternativ  ] ...  ULADA  D [ CLS=  clsname  ]  AL  TER platsvärde ... ...  D  ISPLAY [  format  ]  plats  [ OUTPUT=  FDname  ]  DU  MP [  format  ] [ OUTPUT=  FDname  ]  I  F RUNRC  condition  heltal  ,  MTS-kommando  ERR  ORDUMP (föråldrat kommando, orsakar en automatisk dumpning i batchläge efter onormal avslutning av ett användarprogram)

Diverse 

 CAL  C [  uttryck  ]  ME  SSAGESYSTEM [  meddelande-kommando  ]  FSM  ESSAGE [  FSM-meddelande-kommando  ]  N  ET [  värd  | *   pdn  * ] [ .  nätverkskommando  ]  HEX  ADD [  hexnumber1  ] [  hexnumber2  ] (föråldrad, ersatt av $Calc)  HEXS  UB [  hexnumber1  ] [  hexnumber2  ] (föråldrad, ersatt av $Calc)  PAS  SWORD (föråldrad, borttagen, tillåtna ändringar av offentliga filer innan true delad filåtkomst var tillgänglig)

Filnamnsmönster

Flera MTS-kommandon som använder filnamn eller listor med filnamn tillåter användning av filnamnsmönster: COPY , DESTROY , DUPLICATE , EMPTY , EDIT , FILESTATUS , FILEMENU , LIST , LOCKSTATUS , PERMIT , RENAME , RENUMBER , och TRUNCATE . Ett frågetecken ( ? ) är mönstermatchningstecknet. Ett enda frågetecken som används i ett filnamn matchar noll eller fler tecken. " ? " matchar alla filer för det aktuella inloggnings-ID:t, " ?.S " matchar alla filer som slutar med " .S ", " A?B " matchar alla filer som börjar med " A " och slutar med " B ", " A?B?C " matchar alla filer som börjar med " A ", slutar med " C " och innehåller ett " B ". Två eller flera på varandra följande frågetecken matchar " n -1" tecken. " ???.S " matchar alla fyra teckenfilnamn som slutar med " .S ", och " ???? " matchar alla tre teckenfilnamn. " W163:? " matchar alla filer under signon-ID " W163 " som den aktuella användaren har viss åtkomst till.

Kommandomakron

MTS-kommandotmakroprocessorn tillåter användare att definiera sina egna MTS-kommandon. Det tillhandahåller ett "skriptspråk" med villkorliga kommandon och är tillgängligt för användning med alla rader som läses från *SOURCE* av användarprogram eller kommandospråksundersystem samt med MTS-kommandon. Makroprocessorrader har vanligtvis tecknet större än ( > ). Kommandomakroprocessorn styrs med hjälp av $SET såväl som av I/O-modifierare på FD-namn.

Prefixtecken

För att hjälpa användare att hålla reda på vilket kommando, kommandodelsystem eller program de arbetar med och när inmatning förväntas, visar MTS ett prefixtecken eller ibland en prefixsträng längst fram på varje ingångs- och utgångsrad som den skriver till användarens terminal. De vanliga prefixen är:

 # MTS-kommandoläge #- Fortsättningsläge för MTS-kommando? Uppmaningar >   COPY  och  LIST  kommandona. Program loader tom Användarprogram: Editor + Symbolic Debugging System (SDS) @ Message System ftp> FTP (File-Transfer)

Kommandospråksundersystem

MTS-jobbprogrammet exekverar alltid ett av flera kommandospråksundersystem eller CLS:er. Många av MTS-kommandona är inbyggda i MTS och körs som en del av MTS CLS. Användarprogram körs som USER CLS. USER CLS har en speciell relation till Symbolic Debugging System (SDS CLS) när felsökaren är aktiv. Andra MTS-kommandon implementeras som separata moduler, förvirrande nog också benämnda kommandospråksundersystem eller CLS, som kan exekveras från delat virtuellt minne eller kan laddas från filer.

Dessa separata CLS har var och en sitt eget namn med fyra tecken och de körs som en separat CLS i termens ursprungliga betydelse. Många, men inte alla, av dessa CLS tillhandahåller sitt eget separata underkommandospråk. Det finns $SET- kommandoalternativ för att få gamla eller nya versioner av CLS:er snarare än de nuvarande versionerna att användas. Det finns ett alternativ på $UNLOAD för att ladda ner en CLS (frigör det virtuella minnet som den använder, stäng alla FD-namn och släpp alla enheter eller pseudoenheter som den har öppna).

Endast en CLS körs åt gången, men en CLS av varje typ kan vara aktiv och det är möjligt att byta från en CLS till en annan utan att lämna eller ladda ur den ursprungliga CLS och sedan återgå till den ursprungliga CLS och fortsätta arbeta därifrån en slutade. CLS:er som har sina egna underkommandon stöder vanligtvis ett STOP- kommando för att lämna CLS, ett MTS- och/eller ett RETURN -kommando för att återgå till det anropande CLS- eller MTS-kommandoläget, och kommandon som börjar med ett dollartecken ( $ ) exekveras som MTS-kommandon med en omedelbar återgång till den ursprungliga CLS.

Alla CLS utom USER CLS körs i systemläge i problemtillstånd.

Tillstånd med begränsad service

MTS-sessioner fungerar normalt i "fullservicetillstånd", men under tider av extrem systemöverbelastning kan terminalsessioner placeras i "limited-service state" (LSS). LSS-mekanismen aktiveras manuellt av systemoperatören och används normalt endast när hårdvarusystemet arbetar med reducerad kapacitet på grund av ett fel.

En terminalsession placeras i LSS om LSS har aktiverats av systemoperatören och systemet är överbelastat vid inloggning. LSS-sessioner får endast utfärda MTS-kommandon och köra program med en kort lokal tidsgräns. Istället för att ge alla användare dålig prestanda, begränsar LSS storleken på de uppgifter som vissa användare kan utföra till relativt små uppgifter som redigering av filer och läsning av meddelanden för att tillåta andra användare att få rimlig prestanda på större uppgifter. Användare kan begära att deras session ändras till fullservicetillstånd ( $SET LSS=OFF ) och sådana förfrågningar beviljas om systemet inte är överbelastat vid tidpunkten för begäran.

Kommandostatistik

Varje MTS-kommando som utfärdas spelas in, först till en diskfil och senare på magnetband. Denna information är endast tillgänglig för personal och används för att undersöka programvaruproblem, säkerhetsproblem, rabattförfrågningar och för att tillhandahålla statistik om hur kommandospråket används.

Användarprogram

Användarprogram avser ett program som drivs av användaren och som inte nödvändigtvis är ett program som tillhör eller skapats av en användare. Användarprogram kan tillhandahållas i offentliga filer, i filer tillgängliga under GAMLA: eller NYA: signon-ID:n, i filer som tillhör andra användare och som är tillåtna för användning av andra, eller så kan användarprogram utvecklas av den aktuella användaren i filer som de äger .

Användarprogram körs med kommandona $RUN , $RERUN och $DEBUG eller mindre ofta med kommandona $LOAD och $START . Kommandot $RESTART kan användas för att starta om körningen av ett program efter ett uppmärksamhetsavbrott som inte hanterades av programmet, ett programavbrott som inte hanterades av programmet (även om omstart efter ett programavbrott vanligtvis inte fungerar bra), eller efter en explicit återgång till MTS från ett samtal till MTS-subrutinen.

MTS laddar program med en dynamisk länkladdare (UMLOAD) som läser lastarposter (ESD, TXT, CSI, RDL, LCS, END, ...) från filen eller enheten som specificeras av användaren och kommer selektivt att inkludera subrutiner från bibliotek som tillhandahålls av användaren, från systemsubrutinbibliotek såsom *LIBRARY , och från systemsubrutiner förladdade i delat virtuellt minne. MTS använder standard OS/360 loader-poster vilket gör det ganska enkelt för MTS att använda kompilatorer utvecklade för användning under andra IBM-operativsystem.

När ett program börjar köras kommer ett antal logiska I/O-enheter att ställas in antingen explicit på $RUN eller annat kommando eller som standard. Alla textsträngar som ges efter nyckelordet PAR= skickas till programmet som en parameter.

Som standard körs användarprogram med programnyckeln *EXEC , men en annan programnyckel kan ställas in med kommandot $CONTROL . Program kan anropa en systemsubrutin för att förkorta programnyckeln de använder eller byta till * EXEC -programnyckeln, vilket tillfälligt ger sig själva mindre åtkomst till filer, enheter och andra tjänster som kontrolleras med programnycklar. Program kan också anropa en systemsubrutin för att förlänga eller återställa sin programnyckel enligt vissa förutbestämda regler.

MTS använder anropssekvenser av standard S-typ och, mer sällan, R-typ som används i OS/360.

Som standard körs användarprogram i användarläge i problemtillstånd. Användarlägesprogram har inte åtkomst till systemets virtuella minnessegment och har därför ingen åtkomst till systemkontrollblock, får inte anropa privilegierade systemunderrutiner och får inte utfärda privilegierade supervisorsamtal ( SVC ). Användarlägesprogram kan utfärda icke-privilegierade SVC:er, men få program gör det direkt och anropar istället systemsubrutiner för att få systemtjänster. Användarlägesprogram kan anropa systemunderrutiner som växlar till systemläge efter att ha kontrollerat att den skyddade tjänsten är tillåten för den specifika anroparen, det finns en återgång till användarläge när systemunderrutinen återvänder.

Utvalda användarprogram kan flaggas för att köras i system- snarare än användarläge av personal med privilegierade inloggnings-ID:n eller personal med privilegier kan få ett användarprogram att köras i systemläge med hjälp av ett nyckelord på kommandot $RUN eller $ SET .

Enhetsoberoende ingång/utgång

Alla in-/utmatningsförfrågningar, vare sig av MTS-jobbprogrammet självt eller av ett program som körs under MTS, görs med användning av en gemensam uppsättning subrutinanrop (GETFD, FREEFD, LÄS, SKRIV, KONTROLL, GDINFO, ATTNTRP, ...). Samma subrutiner används oavsett vilket program som gör I/O och oavsett vilken typ av fil eller enhet som används (skrivmaskin eller grafikterminal, linjeskrivare, korthålslagare, diskfil, magnet- och pappersband, etc.) . Ingen kunskap om formatet eller innehållet i systemkontrollblock krävs för att använda dessa subrutiner. Program kan använda specifika egenskaper hos en viss enhet, men sådana program kommer att vara något mindre enhetsoberoende.

MTS-ingång/utgång är inspelnings- eller linjeorienterad. Program läser rader från en terminal, kortläsare, diskfil eller band och skriver rader till en terminal, skrivare, diskfil eller band. Konvertering till och från ASCII / EBCDIC och end-of-line-behandling görs vanligtvis av en front-end-processor eller Device Support Routine (DSR) och är därför inte ett problem för de flesta program. Även om det är möjligt att göra tecken-I/O till en terminal genom att läsa eller skriva enstaka tecken, är det inte särskilt effektivt att läsa eller skriva många sådana mycket korta rader.

Varje rad som läses eller skrivs består av från 0 till 32 767 byte data och ett tillhörande radnummer (ett heltal med tecken skalat med 1000) som anger linjens plats. Längden på varje rad som läses eller skrivs anges explicit, så program behöver inte göra sin egen bearbetning av radavslutningstecken (CR/LF, NL) eller andra terminatorer (null). Vissa enheter stöder linjer med noll längd, medan andra inte gör det. För många filer och enheter är radnumret helt enkelt en sekventiell räkning av de lästa raderna, medan vissa filtyper uttryckligen associerar ett specifikt radnummer med varje rad i filen, och i andra fall syntetiseras radnumret från data som visas på start av en ingångsrad eller radnumret kan läggas till en utgående linje.

Fil- eller enhetsnamn

0 Inmatning/utdata görs direkt genom att referera till en fil eller enhet med dess namn (FDname) eller indirekt genom att referera till en logisk I/O-enhet ( SCARDS eller IN PUT, SPRINT eller PR INT, SPUNCH eller OBJ ECT, GUSER , SERCOM , till 99 ). FD-namn tilldelas logiska I/O-enheter med nyckelord på kommandospråket eller som standard.

FD-namn kan vara ett enkelt filnamn som MYFILE , ett enkelt enhetsnamn med ett större än-tecken som >T901 , eller ett pseudoenhetsnamn som *PRINT* . Alla FD-namn konverteras till versaler innan de används, så precis som MTS-kommandon är FD-namn skiftlägesoberoende.

I/O-modifierare, radnummerintervall och explicit konkatenering kan användas för att skapa komplexa FD-namn från enkla FD-namn. Till exempel:

FILE1@-TRIM (I/O-modifierare som behåller efterföljande ämnen) FILE2(1,10) (radnummerintervall som läser rader från 1 till och med 10) FIL3+*KÄLLA* (explicit sammanlänkning) FILE4(1,10)@-TRIM+ *TAPE*@-TRIM (alla ovanstående i ett enda komplext FD-namn)

Pseudoenhetsnamn

Pseudoenhetsnamn (PDN) börjar och slutar med en asterisk (t.ex. *namn*). Vanliga pseudoenheter inkluderar:

  • *KÄLLA* standardinmatning (normalt antingen en terminal eller för batchjobb, inmatningskön);
  • *SINK* standardutgång (normalt en terminal eller för batchjobb, en skrivare);
  • *MSOURCE* huvudkälla, inte omtilldelningsbar, vanligtvis en terminal eller en kortläsare;
  • *MSINK* mastersink, ej omtilldelningsbar, vanligtvis en terminal eller en skrivare;
  • *BATCH* spoolad indata till ett nytt batchjobb;
  • *PRINT* buffrad utdata till en skrivare, samma som *MSINK* för batch-jobb;
  • *PUNCH* spoolade utdata till en kortstämpel (tills kortstämplingar togs bort); och
  • *DUMMY* all data som skrivs kasseras och alla läsningar returnerar en End-of-File (ungefär som /dev/null för UNIX); och
  • *AFD* den aktiva filen eller enheten som upprättats med kommandot $GET .

Kommandona $SOURCE och $SINK kan användas för att omtilldela FD-namnen som tilldelats *SOURCE* och *SINK* . Kommandot $MOUNT tilldelar pseudoenhetsnamn (t.ex. *T22*, *NET*) till enheter som magnet- och pappersband och nätverksanslutningar (inklusive serveranslutningar). Kommandot $CREATE kan användas för att skapa pseudoenhetsnamn för användning med BITNET-import och -export, för spoolade utskriftsjobb och för dummy-enheter.

I/O-modifierare

I/O-modifierare, möjligen negerade, kan associeras med ett FDname för att ändra standardbeteenden.

En I/O-modifierare specificeras genom att lägga till ett at-tecken följt av modifierarens namn till ett FDname. Till exempel *SOURCE*@UC göra att rader som läses från *SOURCE* konverteras till versaler innan de presenteras för ett program och MYFILE@UC@-TRIM skulle göra att rader som läses från filen MYFILE konverteras till versaler och ev. bakre utrymmen i slutet av linjen skulle behållas. Några vanliga I/O-modifierare är: @S (sekventiell), @I (indexerad), @FWD (framåt), @BKWD (bakåt), @EBCD ( EBCDIC ), @BIN (binär), @UC ( versaler ) , @CC (logisk vagnkontroll), @MCC (maskinvagnskontroll), @NOCC (ingen vagnkontroll), @TRIM (trim alla utom sista träningsblanketten). Vissa I/O-modifierare bearbetas på ett enhetsoberoende sätt av MTS och andra är enhetsberoende och behandlas av Device Support Routines (DSR).

Alla filer eller enheter stöder inte alla I/O-modifierare. Olika filer och enheter har olika standard I/O-modifierare och några I/O-modifierares standardvärden kan ändras med kommandot $ SET .

Radnummerintervall

Specifika delar av en fil eller enhet kan refereras genom att inkludera start- och slutradnummer och eventuellt ett radnummersteg inom parentes avgränsade med kommatecken. Radnumren och inkrementet är heltal skalade med 1000 och kan vara positiva eller negativa (± nnnn . nnn ). Till exempel SIMPLE.F(-35,197.5) öppna filen SIMPLE.F , med början på det första radnumret större eller lika med -35 och returnera ett 'filslut' istället för det första radnumret större än 197,5. Man kan också inkludera radnummersteg – som ett exempel: SIMPLE.F(2,200,2) skulle returnera alla (och endast) jämna radnummer mellan 2 och 200 (inklusive).

De symboliska radnumren FIRST eller *F , LAST eller *L , MIN och MAX kan referera till de första, sista, minsta möjliga respektive maximalt möjliga linjerna. Till exempel SIMPLE.F(*F,0) referera till de 'negativa' raderna i filen SIMPLE.F . Det är här programmerare kan placera självdokumentation för en (ofta binär) fil, faktiska data i filen skulle börja på rad nummer 1.

Man kan också göra enkel addition och subtraktion med de symboliska linjenumren: FIRST± m , *F± m , LAST± m , *L± m , MIN+ m , MAX- m , där m är ett heltal med eller utan decimalkomma skalad med 1000 (± nnnnn . nnn ). Så för att lägga till nya rader i slutet av en befintlig fil kan man använda ett FD-namn av formen SIMPLE.F(LAST+1) .

Fil- eller enhetssammansättning

Explicit sammanlänkning gör att FD-namn kan kopplas med ett plustecken, som NAMEA + NAMEB . I det här fallet returnerar MTS transparent innehållet i NAMEA följt av innehållet i NAMEB eller skriver till NAMEB efter att ha skrivit till NAMEA når filens slut eller annat feltillstånd.

Implicit sammanlänkning inträffar när en indatarad innehåller strängen:

 $CONTINUE MED  FDname

MTS kommer att fortsätta med det FD-namn som anges som den nya datakällan. Eller, om en rad i formuläret:

 $CONTINUE MED  FDname  RETURN

läses kommer MTS att returnera innehållet i det nya FD-namnet tills och End-of-File nås och sedan returnera nästa rad i det ursprungliga FD-namnet (observera att en fil som fortsätter med sig själv orsakar en oändlig loop, vanligtvis ett misstag, men ibland används med god effekt).

Medan raden börjar med ett dollartecken, är $CONTINUE WITH inte ett MTS-kommando, utan snarare en avgränsare.

@IC I/O-modifieraren och kommandot $SET IC={ON | OFF} kan användas för att kontrollera implicit sammanlänkning.

$ENDFILE rader

Om en rad innehåller strängen $ENDFILE , returnerar MTS en "mjuk" filände.

Medan raden börjar med ett dollartecken, är $ENDFILE inte ett MTS-kommando, utan snarare en avgränsare.

@ENDFILE I/O-modifieraren och kommandot $SET ENDFILE={ALWAYS | KÄLLA | NEVER} kan användas för att styra bearbetningen av $ENDFILE .

$9700 och $9700CONTROL linjer

Rader som börjar med strängarna " $9700 " eller " $9700CONTROL " kan kopieras eller skrivas till *PRINT* för att styra utskriftsalternativ på Xerox 9700 sidskrivare. $9700 -rader träder i kraft vid den punkt där de inträffar, medan $9700CONTROL- rader gäller för hela utskriftsjobbet där de förekommer. Även om dessa rader har en form som liknar MTS-kommandon, är de egentligen enhetskommandon och inte sanna MTS-kommandon.

Filer

IBM 2314-diskenheter och IBM 2540-kortläsare/punch vid University of Michigan Computing Center, ca. 1968
IBM 2321 datacell vid University of Michigan Computing Center, ca. 1968

MTS-filer lagras som 4096 byte "sidor" på en eller flera publika eller privata diskvolymer. Volymer har volymetiketter, volymnummer och volymnamn (vanligtvis MTS001, MTS002, ..., MTSnnn). Diskvolymer lagras på traditionell cylinder-track-record och FBA ( fixed block architecture ) diskenheter eller på en gång på IBM 2321 Data Cell .

Enskilda filer sträcker sig inte över diskvolymer. Den maximala storleken på en fil är begränsad till det lediga utrymmet på diskvolymen där den finns. Som standard skapas filer en sida i storlek, men en större storlek såväl som en maximal storlek kan anges ( $CREATE namn SIZE= n P MAXSIZE= n P ). Filer kommer automatiskt att expandera tills de når sin maximala storlek eller gränsen för diskutrymme för ägarens inloggnings-ID överskrids. Användare kan begära att en fil skapas på en specifik diskvolym ( $CREATE namn VOLUME= namn ).

MTS-filer delas in i en av tre kategorier: offentliga filer , användarfiler och temporära filer :

  • Offentliga filer är filer vars namn börjar, men inte slutar, med en asterisk (t.ex. *LIBRARY , *USERDIRECTORY ) . Offentliga filer, ofta kallade "stjärnfiler", är allmänt tillgängliga filer som innehåller program och data som är allmänt tillgängliga för alla användare. Till exempel *LIBRARY ett bibliotek med vanliga systemunderrutiner. Under de tidigaste dagarna av MTS var offentliga filer de enda filerna som kunde delas och då bara som skrivskyddade filer. Senare kunde offentliga filer tillåtas och delas på samma sätt som alla andra filer.
  • Användarfiler är filer vars namn inte börjar med en asterisk eller ett minustecken. De måste uttryckligen skapas ( $CREATE ) och förstöras ( $DESTROY ) . De ägs av och tillåts ursprungligen bara det användar-ID som skapar dem, men de kan tillåtas för användning av andra användar-ID med kommandot $ PERMIT . För att referera till en fil som tillhör en annan användare, har filnamnet prefixet ägarens användar-ID följt av ett kolon (t.ex. W163:MYPROGRAM ) . Det tillkommer avgifter för mängden diskutrymme som används och de flesta inloggnings-ID:n har en maximal gräns för diskutrymme.
  • Temporära filer är filer vars namn börjar med ett minustecken (t.ex. -TEMP ). Deras namn är unika inom en enda session. De skapas implicit vid första användningen, debiteras inte, räknas inte mot ett signon-ID:s diskutrymmesgräns och förstörs automatiskt när terminal- eller batchsessionen avslutas.

MTS implementerar inte kataloger , men det finns en de facto tvåskiktsgruppering av filer på grund av inkluderingen i en fils namn av dess ägares MTS-användar-ID med fyra tecken.

Filnamn, som alla FD-namn, konverteras till versaler före användning och är därför skiftlägesokänsliga.

Filtyper

MTS stöder tre typer av fil, linjefiler, sekventiella filer och sekventiella med radnummerfiler, men linjefiler var överlägset vanligast:

Linjefiler

Linjefiler ( $CREATE namn eller $CREATE namn TYPE=LINE ) är radorienterade filer som är indexerade (och slumpmässigt tillgängliga) efter radnummer. Tillåtna radnummer är ±2147483.647 – i huvudsak ett signerat heltalsvärde dividerat med 1000, men kommandoradsreferenser var begränsade till ±99999.999. Vanliga skrivningar till en fil ökar radnumret med 1. Rader har variabel längd, och en rad kan skrivas om till valfri längd mellan 1 och radlängdsgränsen (ursprungligen 256, men senare ändrad till 32767) utan att påverka de omgivande linjerna. Om du skriver om en redan existerande rad till en längd av noll raderas den raden utan att omgivande linjer påverkas.

Som standard är det första radnumret som skrivs till en tom fil 1, och det ökas med 1 vid varje efterföljande skrivning. Som standard börjar läsningen av en fil med första radnumret vid eller över 1 och fortsätter med att läsa varje rad i ordning efter ökande radnummer. Detta betyder att negativa radnummer är "osynliga" delar av en fil, som kräver specifika referenser för att kunna läsas.

Det finns kommandon (och systemunderrutiner) för att numrera om rader. En sammanhängande uppsättning rader kan numreras om till valfri kombination av start och inkrement så länge raderna i filen inte ordnas om. Till exempel, om en fil består av raderna 10, 20, 30, 40 och 50, kan raderna 30–40 numreras om till 35,36, men inte till 135,136, eftersom det skulle ändra radföljden.

Radindex och data lagras på separata disksidor förutom de minsta (en sida) filerna, där radindex och data lagras tillsammans.

Kommandot $CREATE skapar radfiler som standard.

En bieffekt av det linjebaserade filsystemet är att program kan läsa och skriva enskilda rader stegvis. Om man redigerar en fil (vanligtvis en textfil) med MTS filredigerare ( $EDIT ), skrivs alla ändringar som görs på rader omedelbart, liksom infogning och borttagning av specifika rader. Detta skiljer sig ganska mycket från de flesta (byte-orienterade) filsystem där en fil vanligtvis läses in i och ändras i minnet och sedan sparas på disk i bulk.

På grund av hårdvaru- eller mjukvaruproblem kan linjefiler bli korrupta. Programmet *VALIDATEFILE kontrollerar strukturen för linjefiler.

Sekventiella filer

Sekventiella filer ( $CREATE namn TYPE=SEQ ) är radorienterade filer där första radnumret är implicit 1 och ökas med 1 för varje rad. När den väl skrivits kan längden på en rad (annat än den sista raden i en fil) inte ändras, även om vilken rad som helst kan ersättas med en rad med samma längd. Sekventiella filer är i allmänhet bara läsbara sekventiellt från början till slut, eller skrivna genom att lägga till i slutet. Man kan dock begära en referens för den aktuella raden i en sekventiell fil och använda den referensen för att hoppa till den specifika platsen igen.

Sekventiella filer är något mer effektiva när det gäller utrymme än linjefiler och kan också vara effektivare när det gäller CPU-tid jämfört med stora oorganiserade linjefiler. Men huvudorsaken till att SEQ-filer finns är att de stödde långa rader (upp till 32 767 tecken) innan radfiler gjorde det. Sekventiella filer var mindre vanliga när radfiler kunde stödja långa rader. Sekventiella filer används också för att tvinga nya rader att läggas till i slutet av filen utan att radnummerintervallet (LAST+1) behöver anges.

Sekventiell med radnummerfiler

Sekventiella med radnummerfiler ( $CREATE namn TYPE=SEQWL ) liknar Sekventiella filer, förutom att deras radnummer var explicit lagrade. De har alla begränsningar för sekventiella filer, förutom att radnumret kan anges specifikt när du skriver till en fil (så länge det är större än det sista radnumret som skrevs till filen). Till skillnad från Line Files returnerar den första läsningen av en SEQWL-fil den första raden i filen, även om den var negativ.

SEQWL-filer användes sällan och stöddes inte officiellt eller togs bort från dokumentationen av vissa MTS-webbplatser. Eftersom linjefiler inte fungerade bra med datacellen, implementerades SEQWL-filer som ett sätt att tillåta datacellen att användas för längre sikt billigare lagring av filer samtidigt som radnummer bevarades.

Delade filer

Med tiden utvecklades fildelningen mellan MTS-användare i fyra steg.

Steg ett tillät begränsad fildelning, där publika filer eller biblioteksfiler (filer vars namn börjar med en asterisk) var läsbara av alla användare och alla andra filer (användarfiler) endast kunde nås av deras ägare. Offentliga filer ägdes och underhålls av Computing Center-personal, så i detta skede delades endast Computing Center-filer.

Steg två tillåts för begränsad fildelning, där programmet *PERMIT kan användas för att (i) göra en fil skrivskyddad (RO) till filens ägare och alla andra MTS-användare, (ii) göra en fil tillgänglig för kopiering av medlemmar av samma projekt som filens ägare använder programmet *COPY, eller (iii) gör en fil tillgänglig för kopiering av alla andra användare som använder programmet *COPY. När det gäller steg ett hade ägare som standard obegränsad tillgång till sina egna filer och filerna var inte tillgängliga för andra användare.

Steg tre tillåts för "verkligen delade filer", där kommandot $PERMIT eller PERMIT-subrutinen kan användas för att dela en fil på en mängd olika sätt med listor över andra användare, projekt, alla andra användare eller en kombination av dessa. De typer av åtkomst som kan tillåtas är läsa, skriv-förlänga, skriv-ändra eller tom, numrera om eller trunkera, förstöra och tillåta. När det gäller steg ett och två är som standard en användarfil tillåten med obegränsad åtkomst för sin ägare och ingen åtkomst för andra. En fils ägares åtkomst kan också ändras, även om en ägare alltid behåller tillståndsåtkomst. Kommandot $FILESTATUS eller FILEINFO och GFINFO subrutiner kan användas för att erhålla en fils tillståndsstatus.

Steg fyra lade till programnycklar (PKeys) till listan över saker som en fil kan tillåtas. Således kan filer tillåtas för användare, projekt, alla andra användare, programnycklar eller en kombination av dessa. Programnycklar var associerade med MTS-kommandon och filer, vilket gjorde det möjligt för filer att tillåtas till specifika program eller till specifika MTS-kommandon. Detta möjliggjorde bland annat skapandet av körbara eller körbara program i MTS.

Filer kan också tillåtas till den initiala understrängen för ett användar-ID, projekt-ID eller programnyckel. Som ett resultat kan det hända att ett enda användar-ID, projekt-ID och programnyckel potentiellt kan ha mer än en typ av åtkomst. I sådana fall löses den faktiska åtkomsten enligt följande regler: (i) användar-ID, ensamt eller i kombination med programnycklar, har företräde framför projekt-ID och programnycklar, ii) projekt-ID, ensamt eller i kombination med programnycklar, har företräde över programnycklar, (iii) längre delsträngsmatchningar har företräde framför kortare delsträngsmatchningar, och (iv) om det inte finns något specifikt användar-ID, projekt-ID eller programnyckelmatchning används den åtkomst som anges för "andra".

PKEY-underrutinen kan användas för att förkorta programnyckeln för det program som körs för tillfället eller växla programnyckeln för det program som körs för närvarande till *EXEC och senare återställa programnyckeln, vilket tillåter ett program att frivilligt begränsa åtkomsten till filer tack vare av dess programnyckel.

Fillåsning

Som en del av "riktigt delade filer" (steg tre ovan) introducerades fillåsning för att kontrollera samtidig åtkomst till delade filer mellan aktiva MTS-sessioner (det vill säga mellan separata körande uppgifter eller processer). Fillåsning begränsar eller blockerar inte åtkomst till filer inom en enda MTS-session (mellan kommandospråksundersystem eller användarprogram som körs som en del av samma MTS-session). Fillåsning i MTS är obligatorisk snarare än rådgivande. Filer låses implicit vid första användningen av en viss typ av åtkomst eller explicit genom att använda kommandot $LOCK eller LOCK-subrutinen. Filer låses upp implicit när den senaste användningen av en fil i en uppgift stängs eller explicit med hjälp av kommandot $UNLOCK eller UNLK-subrutinen. Kommandot $LOCKSTATUS eller LSFILE och LSTASK subrutiner kan användas för att erhålla en fils eller en uppgifts aktuella låsstatus.

En fil kan vara "öppen", "ej öppen" eller "väntar på att öppna" och "inte låst", "låst för läsning", "låst för ändring", "låst för att förstöra", "väntar på läsning", " väntar på att ändra", eller "väntar på att förstöra". En fils öppna status är oberoende av dess låsstatus. Att låsa en fil för ändring låser också filen för läsning och låsning av en fil för att förstöra låser också filen för ändring och läsning. Vilket antal uppgifter som helst kan ha en fil låst för läsning vid varje given tidpunkt, men endast en uppgift kan ha en fil låst för ändring vid varje given tidpunkt och då endast om ingen uppgift har filen låst för läsning, eller låst för att förstöra. Endast en uppgift kan ha en fil låst för att förstöra vid varje given tidpunkt, och då endast om ingen uppgift har filen öppen, låst för läsning eller låst för modifiering.

När ett försök att låsa en fil inte kan tillfredsställas, kommer den anropande uppgiften att vänta antingen på obestämd tid eller under en viss period för en annan uppgift att låsa upp filen, eller tills ett uppmärksamhetsavbrott tas emot. Om filen inte kan låsas returneras ett felmeddelande som indikerar detta. Programvaran för fillåsning upptäcker låsningar mellan uppgifter med hjälp av Warshalls algoritm och returnerar en felindikering utan att låsa filen och utan att vänta.

Att låsa en fil är i själva verket att låsa namnet på den filen. Till exempel kan följande sekvens av kommandon köras medan FILE1 lämnas låst även om en fil med namnet FILE1 inte alltid finns:

$lock FIL1 BYT DAMN $rename FIL1 som FIL2 $skapa FIL1

Vid ett senare tillfälle gjorde denna förmåga att låsa namn att "fil"-låsningsrutinerna kunde användas för att implementera låsning på rekordnivå mellan uppgifter som åtkomst till den centralt hanterade filen *MESSAGES som användes av MTS $Messagesystem för att hålla postlådor och meddelanden för enskilda användare.

Tillägget av fillåsning gjorde det möjligt att ta bort begränsningen att ett enda användar-ID bara kunde loggas på en gång. Istället styrdes antalet samtidiga inloggningar av ett maximum som kunde ställas in i användarens bokföring av projektledaren eller en webbplatss affärskontor.

Spara och återställ fil

Filer säkerhetskopieras regelbundet till band om de inte har markerats som NOSAVE . Filsparningsprocessen inkluderar fullständiga och partiella säkerhetskopior. Fullständiga besparingar görs vanligtvis en gång i veckan utan att några användare är inloggade på systemet. Partiella besparingar sparar bara de filer som har ändrats sedan den senaste fullständiga eller partiella lagringen och görs vanligtvis en gång varje dag sent på kvällen eller tidigt på morgonen under normal drift med användare inloggade på systemet.

Vid University of Michigan gjordes två kopior av alla sparade band och en kopia lagrades "off-site". Save-band bevarades i sex veckor och återanvändes sedan. Banden från var sjätte helräddning behölls "för evigt".

Filer sparas för att möjliggöra återställning från "diskkatastrofer" där filsystemet blir skadat eller korrupt, vanligtvis på grund av ett maskinvarufel. Men användare kan också återställa enskilda filer med programmet *RESTORE .

Terminalstöd

En tidig datorterminal, Teletype Model 33 ASR med ansluten pappersbandläsare/stans
En DEC VT100 displayterminal
PDP-8 Data Concentrator vid University of Michigan, ca. 1971
En Tektronix 4014 displayterminal
Touch-tone telefon
Merit PDP-11-baserad primär kommunikationsprocessor (PCP) vid University of Michigan, ca. 1975
IBM 3279 displayterminal

På sin topp stödde MTS vid University of Michigan samtidigt mer än 600 terminalsessioner samt flera batchjobb.

Terminaler är anslutna till MTS via uppringningsmodem, hyrda eller dedikerade datakretsar och nätverksanslutningar. Michigan Communications Protocol (MCP), ett enkelt ramprotokoll för användning med asynkrona anslutningar som ger feldetektering och återsändning, utvecklades för att förbättra tillförlitligheten hos terminal till MTS och dator till MTS-anslutningar.

Ett mycket brett utbud av terminaler stöds, inklusive 10 tecken per sekund (cps) Teletype Model 33 , 30 cps LA-36 och 120 cps LA-120 DECWriter, 14 cps IBM 2741 och med ständigt ökande hastigheter upp till 56 000 bitar per sekund, VT100 -skärmen, Visual 550-skärmen, Ontel OP-1 och OP-1/R-skärmarna, Tektronix 4000-serien med grafiska skärmar och persondatorer från Apple (AMIE för Apple ][), IBM (PCTie för DOS) och andra som kör terminalemuleringsprogram , inklusive några speciellt utvecklade för användning med MTS. De flesta terminaler som är kompatibla med någon av dessa modeller stöds också.

MTS stöder också åtkomst från telefoner med 10 eller 12 knappar via IBM 7772 Audio Response Unit och senare Votrax Audio Response Unit, IBM 1052 -konsoler, IBM 3066-konsolskärmar och IBM 3270 -familjen av lokalt anslutna bildskärmar (IBM 3272) och 3274 kontrollenheter, men inte fjärrkontroller 3270).

Front-end kommunikationsprocessorer

MTS kan och använder kommunikationskontroller som IBM 2703 och Memorex 1270 för att stödja uppringningsterminaler och fjärranslutna batchstationer över uppringda och dedikerade datakretsar, men dessa kontroller visade sig vara ganska oflexibla och otillfredsställande för att ansluta ett stort antal olika terminaler och senare persondatorer som kör terminalemuleringsprogram med allt högre datahastigheter. De flesta MTS-sajter väljer att bygga sina egna front-end-processorer eller att använda en front-end-processor utvecklad av en av de andra MTS-sajterna för att tillhandahålla terminalstöd.

Dessa front-end-processorer, vanligtvis DEC PDP-8 , PDP-11 eller LSI-11 baserade med lokalt utvecklad anpassad hårdvara och mjukvara, skulle fungera som IBM-kontrollenheter kopplade till IBMs in-/utgångskanaler på ena sidan och till modem och telefonlinjer på den andra. Vid University of Michigan var front-end-processorn känd som Data Concentrator (DC). DC utvecklades som en del av CONCOMP-projektet av Dave Mills och andra och var den första icke-IBM-enheten som utvecklades för anslutning till en IBM I/O-kanal. Ursprungligen ett PDP-8-baserat system, DC uppgraderades för att använda PDP-11-hårdvara och en Remote Data Concentrator (RDC) utvecklades som använde LSI-11-hårdvara som kopplades tillbaka till en DC över en synkron datakrets. University of British Columbia (UBC) utvecklade två PDP-11-baserade system: Host Interface Machine (HIM) och Network Interface Machine (NIM). University of Alberta använde en PDP-11-baserad front-end-processor.

Dessa front-end-system stöder sitt eget kommandospråk för "enhetskommandon", vanligtvis rader med ett specialtecken som ett procenttecken (%), för att tillåta användaren att konfigurera och kontrollera anslutningarna. Kommandot $CONTROL och program som körs på MTS kan använda CONTROL-subrutinen för att utfärda enhetskommandon till front-end- och nätverkskontrollenheter.

Nätverksstöd

Med tiden har vissa front-ends utvecklats för att ge riktigt nätverksstöd snarare än att bara ge stöd för anslutningar till MTS.

Vid University of Michigan (UM) och Wayne State University (WSU) gjordes en parallell utvecklingsansträngning av Merit Network för att utveckla nätverksstöd. Meritnoderna var PDP-11-baserade och använde anpassad hårdvara och mjukvara för att tillhandahålla interaktiva anslutningar mellan MTS-system och mellan MTS och CDC SCOPE /HUSTLER-systemet vid Michigan State University (MSU). Meritnoderna var kända som kommunikationsdatorer (CC) och fungerade som IBM Control Units på ena sidan medan de gav länkar till andra CC:er på andra sidan. De initiala värd till värd interaktiva anslutningarna kompletterades lite senare av terminal till värd (TL) anslutningar, och senare fortfarande av värd till värd batch anslutningar som gjorde det möjligt för fjärrjobb som skickats från ett system att exekveras (EX) på ett annat med tryckt (PR) ) och hålkortsutgång (PU) returneras till det inlämnande systemet eller till en annan värd i nätverket. Fjärrbatchjobben kan skickas in från en riktig kortläsare eller via *BATCH* med ett #NET "kort" längst fram i jobbet.

Merit döpte om sina kommunikationsdatorer till primära kommunikationsprocessorer (PCP) och skapade LSI-11-baserade sekundära kommunikationsprocessorer (SCP). PCP:er utgjorde kärnan i nätverket och var kopplade till varandra över Ethernet och dedikerade synkrona datakretsar. SCP:er kopplades till PCP:er över synkrona datakretsar. PCP:er och SCP:er skulle så småningom inkludera Ethernet- gränssnitt och stödja lokala nätverksanslutningar (LAN). PCP:er skulle också fungera som gateways till kommersiella nätverk som GTE:s Telenet (senare SprintNet), Tymnet och ADP:s Autonet , vilket ger nationell och internationell nätverksåtkomst till MTS. Ännu senare tillhandahöll PCP:erna gatewaytjänster till de TCP/IP- nätverk som blev dagens Internet .

Merit PCP och SCP ersatte så småningom datakoncentratorerna och fjärrdatakoncentratorerna vid University of Michigan. När de var som mest fanns det mer än 300 Merit PCP och SCP installerade, som stödde mer än 10 000 terminalportar.

Virtuella miljöer

UMMPS tillhandahåller faciliteter som tillåter skapandet av virtuella miljöer, antingen virtuella maskiner eller virtuella operativsystem. Båda är implementerade som användarprogram som körs under MTS.

Det första arbetet med den första virtuella MTS-maskinen gjordes vid University of Michigan för att simulera IBM S/360-67 och möjliggöra felsökning av UMMPS och MTS. Senare gjorde University of British Columbia det första arbetet med att skapa en virtuell S/370 MTS-maskin. I teorin skulle dessa virtuella maskiner kunna användas för att köra vilket S/360- eller S/370-system som helst, men i praktiken användes de virtuella maskinerna endast för att felsöka MTS och så det kan finnas subtila funktioner som inte används av MTS som inte är helt eller korrekt implementerad. Den virtuella MTS-maskinen uppdaterades aldrig för att stödja S/370-XA-arkitekturen (istället användes andra verktyg som SWAT och PEEK för att felsöka MTS och IBM:s VM/XA eller VM/ESA användes för att felsöka UMMPS).

I början av 1970-talet arbetade man vid Wayne State University för att köra en version av OS/MVT i en modifierad virtuell maskin (VOS) under MTS som en produktionstjänst.

"Student" virtuella maskiner i MTS har också skapats som undervisningsverktyg. Här använder operativsystemet som körs i den virtuella maskinen (skrivet av eleven) simulerade enheter och har ingen koppling till den "riktiga" omvärlden alls (förutom möjligen en konsol).

Förutom virtuella maskiner tillhandahåller MTS två program som implementerar virtuella operativsystemmiljöer. *FAKEOS , utvecklat vid University of Michigan, tillåter program från OS/360 att köras som användarprogram i MTS. *VSS , utvecklat vid University of British Columbia, tillåter program från OS/VS1 och MVS/370 att köras som användarprogram i MTS. Inget av programmen kör faktiskt IBMs operativsystem, istället simulerar de tillräckligt mycket av operativmiljön för att tillåta individuella program som utvecklats för dessa operativsystem att köra. Båda programmen kan köras direkt, men ofta körs de från drivrutinsfiler som ger en slutanvändare intrycket att de kör ett vanligt MTS-användarprogram.

E-post

Minst tre olika implementeringar av e-post var tillgängliga under MTS vid olika tidpunkter:

  • *POST från NUMAC, men inte tillgängligt på alla MTS-webbplatser;
  • CONFER , datorkonferenssystemet skrivet av Robert Parnes vid UM; och
  • $MESSAGESYSTEM från University of Michigan Computing Center.

CONFER och *MAIL har endast skickat och tagit emot e-post till och från "lokala" användare.

Tillgängligt för användare i juli 1981, $MESSAGESYSTEM är det sista av de tre systemen som ska implementeras och blev det mest använda. Mellan 1981 och 1993 användes den för att skicka och ta emot mer än 18 miljoner meddelanden vid University of Michigan. Den kan skicka:

  • lokala e-postmeddelanden och nätverksmeddelanden,
  • utskick (omedelbara meddelanden som visas på en annan användares terminal om inte utskick har blockerats av den andra användaren),
  • bulletiner (meddelanden som skickas av systemoperatören till vissa användare som levereras automatiskt i början av en MTS-session), och
  • signon-meddelanden (meddelanden som skickas av systemoperatören till alla användare som levereras automatiskt innan en MTS-session börjar).

Några anmärkningsvärda funktioner hos $MESSAGESYSTEM inkluderar förmågan:

  • att skicka till individer med signon-ID eller namn, till grupper av individer med signon-ID, projekt-ID eller gruppnamn, eller till systemoperatören;
  • att skicka till en lista lagrad i en fil;
  • att använda programmet *USERDIRECTORY för att skapa och underhålla en databas med e-postnamn för individer och för grupper inklusive namn och grupper som inkluderar fjärr- eller nätverksanvändare;
  • att återkalla/ta bort meddelanden som inte redan hade lästs;
  • att lägga till eller ta bort mottagare till meddelanden efter att de har skickats;
  • att visa en historik över meddelanden i en e-postkedja utan att behöva inkludera texten från äldre meddelanden i varje nytt meddelande;
  • för att ställa in utgångsdatum och håll till datum och tider för e-postmeddelanden;
  • för att visa status för inkommande och utgående meddelanden;
  • att hämta inkommande och utgående meddelanden med hjälp av en databasmodell (inkommande, utgående, ny, gammal/sett, till mottagare , från mottagare , meddelandenummer, skickat datum, utgångsdatum, ...);
  • att tillåta en brevlåda som tillåter användning av andra inloggnings-ID:n än brevlådeägarens;
  • att automatiskt vidarebefordra meddelanden från en brevlåda till en annan;
  • för att arkivera äldre meddelanden, och
  • skicka och ta emot meddelanden med hjälp av ett subrutingränssnitt förutom kommandon.

En applikation för Apple Macintosh, InfoX (alias MacHost), utvecklades för att ge ett modernt gränssnitt till MTS Message System och *USERDIRECTORY .

1984 kunde MTS användas för att skicka och ta emot e-post på distans till och från över 300 platser runt om i världen.

Den första möjligheten att skicka och ta emot e-postmeddelanden till och från användare på fjärrsystem (fjärrmeddelanden eller nätverkspost) implementerades 1982 som en del av MAILNET-projektet, en gemensam ansträngning av 16 universitet och EDUCOM (senare EDUCAUSE) med stöd av finansiering från Carnegie Corporation . MIT fungerade som ett relänav mellan MAILNET-webbplatserna och som en gateway till CSNET , ARPANET och BITNET . MTS vid University of Michigan använde sina kopplingar till Merit Network och genom Merit till GTE:s kommersiella X.25 - nätverk, Telenet (senare SprintNet), för att kommunicera med MIT. MTS vid University of Michigan fungerade som en reläplats för andra platser på UM-campus och för andra MTS-platser som inte hade direkt tillgång till MAILNET-reläet vid MIT.

Fjärr-e-postadresserna för en MTS-användare vid University of Michigan var:

  • namn @UMich-MTS.Mailnet (från MAILNET och BITNET-webbplatser)
  • namn %[email protected] (från CSNET- och ARPANET-webbplatser)
  • namn @UM (från andra UM- eller MTS-webbplatser)

För att skicka e-post till en avlägsen webbplats använde MTS-användare vid University of Michigan adresser enligt formuläret:

  • namn @CARNEGIE (till Carnegie-Mellon University en MAILNET-webbplats)
  • namn @CARNEGIE.MAILNET (det mer officiella, men längre namnet för CMU)
  • namn @WSU (till Wayne State University en MTS-webbplats)
  • namn @Wayne-MTS.Mailnet (det mer officiella men längre namnet för WSU)
  • namn %[email protected] (till Brown University en CSNET Phonenet-webbplats)
  • namn @cornell.ARPA (till Cornell University en CSNET- eller ARPANET-webbplats)
  • namn @STANFORD.BITNET (till Stanford University en BITNET-webbplats)

Med tiden, eftersom fler och fler datorer hade direktanslutningar till Internet, ersattes MAILNET-relämetoden med den mer direkta och mer pålitliga peer-to-peer-e-postleveransen och Internetdomänstilen för e-postadresser som används idag (namn @um . cc.umich.edu).

InfoX

Skärmdump av InfoDisk om-fönstret, september 1988

InfoX (uttalas "info-ex", ursprungligen InfoDisk) är ett program för Apple Macintosh utvecklat av Information Technology Division vid University of Michigan. Det tillhandahåller ett modernt användargränssnitt (menyer, ikoner, fönster och knappar) som kan användas för att kontrollera MTS e-post, delta i CONFER II- konferenser, komma åt MTS User Directory och skapa, redigera och manipulera filer. InfoX lägger till ordbehandlingsfunktioner i Macintosh-stil till de mer traditionella redigeringsfunktionerna som är tillgängliga från kommandoradsgränssnitten MTS, $Message, $Edit och CONFER. Man kan använda standardkommandona Klipp ut, Kopiera och Klistra in under Macintosh Redigera-menyn för att flytta text från vilken Macintosh-fil som helst.

Bokföring och debitering

Varje inloggnings-ID tilldelas resursgränser (pengar, diskutrymme, anslutningstid, ...) som styr mängden och typerna av arbete som kan utföras av ID:t. ID:n kan begränsas till att bara använda terminalsessioner eller bara batchjobb eller begränsas till att arbeta under tider på dygnet eller veckodagarna då debiterade priserna är lägre. Varje inloggnings-ID tilldelas ett utgångsdatum.

Resurser som kan debiteras för inkluderar:

  • CPU-tid – laddas i sekunder av CPU-tid
  • Minnesanvändning – laddas som CPU-VM-integral ... t.ex. 40 sidor virtuellt minne som används i 10 sekunder debiteras som 400 sidsekunder
  • Skrivaranvändning—debiteras som papperssidor och utdatarader (för linjeskrivare) eller sidor och ark (för sidskrivare)
  • Diskutrymme som används – debiteras i sidmånader (en sida=4096 byte)
  • Terminal eller nätverksanslutning tidsdebiterad i minuter
  • Kort läses och hålladdas av kortet
  • Papperstejp stansad-laddat av foten
  • Bandmonterade och bandstationsanvändning tidsdebiterad efter antal monterade band och användningsminuter
  • Programprodukttillägg (debiteras program för program för vissa licensierade programprodukter)
  • Andra resurser (t.ex. plottrar, fotosättare, etc.)

Observera att även om det tillkommer en avgift för använt virtuellt minne, så tillkommer ingen avgift för använt verkligt minne. Observera också att det inte finns någon ändring för page-in-operationer, även om de ingår i sessionssammanfattningsinformationen som rapporteras vid avloggning.

Olika priser kan ändras för olika klasser av projekt (interna, externa, kommersiella, ...) och för olika tider på dygnet eller veckodagarna. Beroende på policyer och praxis på olika webbplatser kan avgifter vara för "riktiga pengar" eller "mjuka pengar" (mjuka pengar kallas ibland "roliga pengar", men hur roligt det är beror vanligtvis på vem som betalar eller inte betalar räkningarna).

Användare kan visa kostnaden för en session med kommandot $DISPLAY COST , kan visa sina kontosaldon med kommandot $ACCOUNTING , och kostnaderna för en session och kontots återstående saldo visas när jobbet eller sessionen avslutas. Det finns också ett alternativ ( $SET COST=ON ) som gör att den inkrementella och kumulativa sessionskostnaden visas efter att varje MTS-kommando har utförts.

För att förhindra att en användare överdrar sitt konto kontrolleras pengagränsen när användaren försöker logga in. Om kontosaldot är noll eller negativt är inloggning inte tillåten. För batchjobb, om kontosaldot inte är tillräckligt för att täcka de beräknade avgifterna för jobbet, körs inte jobbet. För terminalsessioner, när ett kontos saldo faller under en dollar, skrivs en varning "Du har slut på pengar" följt av det aktuella saldot. Detta meddelande om att det inte finns några pengar upprepas med jämna mellanrum tills användaren loggar ut. Signon-ID:n kan ha ett negativt saldo, men vanligtvis inte stort eller av misstag. Beroende på den administrativa policyn på en viss plats måste projekt ofta betala för resurser som används även om de överstiger det tillåtna beloppet.

För att ge ytterligare skydd mot olyckor som snabbt kan använda mer resurser än önskat, kan användare också sätta globala och lokala gränser för CPU-tidanvändning. Globala tidsgränser ( $SIGNON ccid T= maxtime ) gäller för ett helt jobb eller en hel session. Lokala tidsgränser gäller för att köra individuella program ( $RUN program T= maxtime ). Globala och lokala gränser för antalet sidor som ska skrivas ut och antalet kort som ska stansas kan också ställas in ( $SIGNON ccid P= maxpages C= maxcards och $RUN -programmet P= maxpages C= maxcards ). En förinställd lokal CPU-tidsgräns kan fastställas med kommandot $SET TIME= maxtime .

Hämtad från " https://en.wikipedia.org/w/index.php?title=MTS_system_architecture&oldid=1135183085 "