VS/9

VS/9
Sperry Univac logo.jpg
Utvecklare Univac
OS-familjen TSOS
Arbetstillstånd Avvecklad
Källmodell Okänd
Initial release sent 1960-tal
Plattformar UNIVAC Series 90 stordatorer

Standardanvändargränssnitt _
Kommandoradsgränssnitt
Licens Proprietär

VS/9 är ett datoroperativsystem för UNIVAC Series 90 stordatorer (90/60, 90/70 och 90/80), som användes under slutet av 1960-talet till 1980-talet . 90/60 och 90/70 var ompaketerade Univac 9700-datorer. Efter RCA- förvärvet av Sperry fastställdes det att RCA TSOS -operativsystemet var mycket mer avancerat än Univac -motsvaret, så företaget valde att slå samman Univac-hårdvaran med RCA-mjukvaran och introducerade 90/70. 90/60 introducerades kort därefter som en långsammare, billigare 90/70. Det var inte förrän introduktionen av 90/80 som VS/9 äntligen hade en hårdvaruplattform optimerad för att dra full nytta av dess förmåga att tillåta både interaktiva och batchoperationer på samma dator.

Bakgrund

I september 1971 beslutade RCA att lämna stordatorbranschen efter att ha förlorat omkring en halv miljard dollar på att försöka (och misslyckas) att konkurrera mot IBM . Merparten av datadivisionens tillgångar såldes till dåvarande Univac . Detta inkluderade RCAs Spectra -serie av datorer, olika externa hårdvarudesigner (som videoterminaler, bandenheter och hålkortsläsare ) och dess operativsystem, Time Sharing Operating System (TSOS).

TSOS kan ha varit ett bättre operativsystem ur användarsynpunkt än något av IBMs, men på den tiden ansågs operativsystem inte vara något som säljs separat från datorn, tillverkaren inkluderade det gratis som en del av köpeskillingen. Univac introducerade ytterligare några nya funktioner till TSOS och döpte om det till VS/9. Namnet 'TSOS' förblev dock som användarnamnet för det primära privilegierade (System Manager) kontot, som på Unix -typsystem kallas 'root'. RCA sålde också TSOS till det som skulle bli Fujitsu , och det är grunden för Fujitsus operativsystem BS2000 på dess stordatorer med samma namn.

Använda sig av

Interaktiv användning

Interaktiv användning av VS/9 gjordes genom terminaler kopplade till en terminalkoncentratorenhet, som skickade styrsignaler till och från terminalerna, på ett sätt som liknar det sätt som IBM skulle tillhandahålla med sina terminaler av IBM 3270- stil . Detta tillhandahöll i allmänhet att indata till terminalen skulle skickas som svar på en enter-nyckel, i motsats till praxis på PC:er att ta in ett tecken i taget. Koncentratorenheten var ursprungligen känd som Communications Control Module, eller CCM. RCA hade dock sålt patenten och designen för sin CCM-terminalkontroller till Singer Corporation , så Univac utvecklade en emulatorenhet för CCM som var känd som Multiterminal Connection Controller modell 16, eller MCC-16.

MCC-16 stödde både Univac-standardterminalen (från RCA) omdöpt till Uniscope Video Display Terminal eller VDT, såväl som vanliga ASCII- dumma terminaler . Univacs Uniscope VDT gav sofistikerad (för tiden) redigeringskapacitet inklusive möjligheten att redigera text på skärmen och göra ändringar en rad i taget eller en sida i taget, och sedan överföra texten tillbaka till datorn. VDT stödde också direkt markörpositionering och inmatningsskydd genom en markör som indikerade att endast text efter markören skulle kännas igen. Det stödde också speciellt rullningsläge i en delmängd av skärmen, eller "fönster" där det, istället för att hela skärmen rullade uppåt när den sista raden visas, var möjligt att göra rullningsområdet endast till den nedre halvan av skärmen.

En skillnad gjordes mellan interaktiva (timesharing) terminaler och transaktionsterminaler. Där interaktiva terminaler styrdes direkt av operativsystemet, styrdes transaktionsterminaler från ett batchprogram. Ursprungligen utvecklades detta batchprogram, känt som MCP for Multichannel Communications Program, för de batchorienterade operativsystemen RCA och Sperry, TDOS (Tape-Disk Operating System) och DOS (Disk Operating System). När det stod klart att de skulle fasas ut till förmån för det mycket mer robusta interaktiva operativsystemet, VMOS, portades MCP för att köras på VMOS. VMOS (Virtual Memory Operating System) blev den nya monikern för TSOS på RCA Spectra 70-modellerna 46, 61, 3 och 7-datorer, och sedan initialt på Univac Series 70-datorer (tidigare RCA).

Så småningom förbättrades MCP för att stödja Sperry Univac-terminaler och dess namn ändrades till COS (Communication Operating System). Portar i CCM och senare i MCC som körs i emuleringsläge kan vara antingen interaktiva eller transaktionella, men inte båda. Om en port betecknades som en interaktiv port, styrdes den av tidsdelningstjänsterna integrerade i operativsystemet VMOS eller VS/9. Transaktionsportar, å andra sidan, kontrollerades av COS. Alla terminaler kopplade till dessa portar blev "egenskapen" för respektive kontrollerande värdprogramvara. Tidsdelning användes för programutveckling vilket möjliggjorde mycket snabbare programutveckling än den traditionella batchprocessen som var toppmodern vid den tiden. Varje tidsdelningsanvändare var en uppgift för sig och kunde köra program, skapa filer och begära systemresurser efter behov. Det som gjorde mycket av detta möjligt var operativsystemets förmåga att hantera "virtuellt minne", eller tillfälligt spara sidor med minne (inklusive körning av program) till disk eller trumma medan det inte används och sedan hämta dem senare vid behov. Virtuellt minnes sidstorlek fastställdes till 4096 byte. Detta gjorde att många fler uppgifter kunde köras samtidigt än vad som annars skulle begränsas av begränsat och dyrt huvudminnesutrymme. Transaktionsanvändare, å andra sidan, styrdes alla av ett enda program och deras syn på miljön var begränsad till den som presenterades för dem. De identifierades inte som enskilda uppgifter och hade inte förmågan att köra program eller begära systemresurser.

CCM och MCC som kördes i emuleringsläge var "dumma" hårdvarugränssnitt. Det vill säga, all nätverksprotokollintelligens, inklusive terminalpolling, felåterställning och meddelandekonstruktion fanns i stordatorn, medan CCM och MCC helt enkelt fungerade som ledningar mellan stordatorn och telefonlinjerna. Det var inte förrän MCC användes som en äkta front-end-processor som mycket av denna overhead (som polling och felåterställning) avlastades från stordatorn, vilket frigjorde datortid för att köra applikationsprogram. Detta inträffade inte förrän VS/9-eran.

Batchanvändning

VS/9 stödde en eller flera kortläsare, som kopplades till datorn och aktiverades genom att användaren placerade en kortlek i magasinet och tryckte på "Start"-knappen. Förmodligen skulle datorn läsa källkortet och placera alla kort som lästs i utmatningsmagasinet. Om kortleken bestod av en giltig inloggning skulle den behandla kortleken som ett jobb att utföra.

Webbplatsdrift

VS/9 kontrollerades av en datoroperatör på den centrala platsen. Datoroperatörer interagerade med systemet via en systemkonsol. Från början var denna konsol en teletypenhet, men uppgraderades senare till en videodisplayenhet med en ansluten systemkonsolskrivare. Alla systemkonsolmeddelanden loggades på systemkonsolskrivaren. Oönskade meddelanden med ursprung i operativsystemet loggades också till systemkonsolens skrivare. Datoroperatörer hade ett antal ansvarsområden:

  • Initiera systemet genom en startprocess.
  • Starta batchprogramprocesser.
  • Ladda kommunikationskontrollprogrammet (MCP eller COS) om platsen hade transaktionsterminaler.
  • Tillför indata via hålkort eller magnetband.
  • Montera/demontera flyttbara diskar och band efter behov för batch- och/eller interaktiva uppgifter.
  • Prioritera jobb som körs eller i inmatningsköerna.
  • Justera batch- och interaktiva terminalgränser för att optimera systemets prestanda.
  • Tillför papper till lokalt anslutna skrivare på plats.
  • Rapportera systemfel till leverantörens underhållspersonal.
  • Utför andra uppgifter som specificeras av kundledningsgruppen.

Funktioner

Volymgrupper

En av de mer användbara förbättringarna sent i livet för VS/9 var volymgrupper. Diskteknik vid den tiden gav begränsat lagringsutrymme på varje disk. Eftersom diskenheter var jämförelsevis stora och ganska dyra, gav tillverkare av diskenheter möjlighet att fysiskt ta bort den faktiska disken från enheten och ersätta den med en annan. Kunderna hade alltså möjligheten att lagra många gånger kapaciteten på sina hårddiskar, även om de inte nödvändigtvis kunde användas samtidigt om det inte fanns tillräckligt med lediga hårddiskar. Begränsat disklagringsutrymme gav också användarna ett annat problem. Mycket ofta är filerna större än vad som kan finnas på en disk. Volymgrupper hjälpte till att lindra detta tekniska problem genom att låta filer sträcka sig över flera diskar. Volymer (skivor) som måste monteras samtidigt betecknades som en "volymgrupp". Ägare skulle kunna definieras för att begränsa åtkomsten till känsliga uppgifter. När den väl hade monterats och kopplats till en aktiv uppgift, kunde inte hela volymgruppen demonteras förrän alla kopplade uppgifter antingen släppte den eller avslutades. Varje disk som var tillgänglig för systemet var en del av en volymgrupp, även om det bara fanns en volym i gruppen. Volymgrupper kan betecknas som borttagbara eller fasta. Grupper med fast volym kunde inte tas bort när som helst. Detta var nödvändigt för diskar som inhyste operativsystemet och filerna som stödde transaktionsterminalerna.

Fjärrbatchbearbetning

Remote Batch Processing (RBP) var en funktion som fanns i VS/9, även om den aldrig utnyttjades helt, förmodligen på grund av begränsad efterfrågan. RBP gjorde det möjligt för fjärranvändare att skicka in batchjobb för exekvering på stordatorn och få tillbaka resultaten på sin externa skrivare. Vanligtvis bestod en fjärransluten batchenhet av en kortläsare och en skrivare ansluten till en kommunikationslinje som samverkar med fjärrbatchtjänsterna i operativsystemet. Liksom ett lokalt batchjobb kan operatörer ta emot förfrågningar om band- eller diskmontering/demontering och programuppmaningar om svar på frågor.

Uppgiftstyper

VS/9 hanterade uppgifter efter uppgiftstyp. Uppgiftstyper kan vara antingen körande program eller köer med väntande uppgifter. Följande var uppgiftstyperna som användes av VS/9:

  1. Batchinmatningskö
  2. Kör batchprogram
  3. Aktiva tidsdelningsanvändare
  4. Utskriftskö för utskrift och stansning
  5. Skriva ut och stansa enheter utskrift eller stansning
  6. RBP-utgångskö
  7. Inte använd
  8. RBP-enheter utskrift

MCP och COS var alltid typ 2-uppgifter. Datoroperatören skulle se en räkning av antalet uppgifter inom varje kö på systemkonsolen. En komplett lista över uppgiftsköerna var tillgänglig från alla interaktiva terminaler med administratörsåtkomst via ett fältskrivet program känt som "Stat200". Detta program skulle skanna uppgiftsköerna med några sekunders mellanrum och visa en rullande lista med uppgifter på terminalskärmen tills den avbröts eller avslutades. Även om det inte var en officiellt släppt produkt, blev den de facto-standarden för uppgiftsövervakning.

Kontoåtkomst

VS/9 kontrollerade åtkomst genom användning av ett kontonamn och ett användarnamn. Kontonamnet var en identifierare på 1 till 7 tecken, och användarnamnet var också en identifierare på 1 till 8 tecken. Identifierare för kontonamn och användarnamn kan bara vara bokstäver och siffror. Kontonamnet motsvarade ett katalognamn under användarkonton i Unix-stil, med noteringen att användarnamnet angav vilken person som delade kontot som var den som använde det. Således, till exempel, om det fanns ett kontonamn för S0103, om det fanns två användare, vars namn var Pat och Leslie på det kontot, skulle de ha en fullständig identifierare av S0103 ,PAT och S0103, LESLIE. Alla deras filer skulle lagras i katalogen S0103 och därför kunde de inte skapa filer med samma namn. Observera att om det fanns ett kontonamn för, säg, PA5, om det fanns en användare som heter Pat, skulle deras identifierare vara PA5, PAT och skulle vara helt orelaterade till någon annan användare som heter Pat.

Konton kan ges begränsningar som att kräva ett lösenord för att använda, gränser för antal filer, användningsmängd, tid för tillåten användning (som att endast tillåta inloggningar efter 17.00 eller före 8.00) och CPU-gränser. En användare kan också utfärda kommandon för att få systemet att avbryta ett program om den aktuella sessionen använde mer än en viss mängd väggklocka eller cpu-tid.

En användare på en terminal som inte var inloggad, som ville starta en session, skulle trycka på den röda sändningsknappen på en Univac VDT, eller använda Control + C på en ASCII-terminal. VS/9 skulle ge följande svar:

Välkommen till terminalsystemet VS/9. Vänligen logga in.

Följt av ett snedstreck ("/"), och i fallet med Univac VDT, prompttecknet, som såg ut som en omvänd färg större än tecknet (">"). Användaren skulle logga in genom att skriva ordet ' inloggning följt av sin identifierare, t.ex. sitt kontonamn, ett kommatecken och sitt användarnamn. Om de hade ett lösenord på sitt konto skulle de skriva ett kommatecken följt av deras lösenord, som kan vara mellan 1 och 4 tecken. Om det innehöll ett eller flera mellanslag (andra än efterföljande mellanslag, som kunde utelämnas), måste det skrivas med enstaka citattecken. Om den innehöll icke-utskrivbara eller binära tecken, måste den skrivas in genom att använda bokstaven X följt av ett citattecken och 8-teckens hexadecimala värde för lösenordet. Så om kontot S0103 hade lösenordet (i hexadecimalt) A0B0C0 och ett mellanslag, skulle användaren LESLIE logga in på systemet genom att skriva

/LOGON S0103,LESLIE,X'A0B0C0'

Om deras autentiseringsuppgifter var felaktiga, antingen för att kontonamnet, användarnamnet eller lösenordet var felaktigt, skulle de få meddelandet,

Ogiltig inloggning, försök igen.

och skulle få en / uppmaning att logga in igen.

Om deras autentiseringsuppgifter var korrekta, om systemhanteraren (ägaren till kontot $TSOS ) hade postat ett systemmeddelande, skulle det visas vid denna tidpunkt. Användaren skulle vara i kommandoläge, och en standard / prompt skulle visas där de kunde skriva olika kommandon. Användaren skulle avsluta sin session genom att skriva LOGGA AV och trycka på sänd på Univac VDT eller Control + C på en ascii-terminal.

Terminalfunktioner

Univacs VDT-terminal hade fyra funktionstangenter överst, och VS/9 kände igen dem specifikt.

  • F1 var motsvarigheten till break-nyckeln på en Ascii-terminal. Om ett program kördes skulle det avbrytas och användaren gick in i pausläge, där de kunde utfärda ett kommando. De kunde skriva R eller INTR för att återuppta körningen av programmet där pausen hade gjorts.
  • F2 och F3 kunde ställas in för att kännas igen av ett program för olika funktioner, men användes inte av VS/9.
  • F4 utförde en omedelbar påtvingad utloggning av användaren om han blev påkörd, av misstag eller med avsikt. Detta skulle vara motsvarande i MS-DOS att trycka på CTRL-ALT-DEL, vilket tvingar omstart av maskinen omedelbart.

Systemkommandon

VS/9 accepterade kommandon genom att skriva kommandot och eventuella alternativ. Kommandon utfärdade i en batchström antingen som kort eller som en batchfil krävde att de föregås av ett snedstreck; kommandon som angavs på en terminal krävde inte användning av snedstrecket. Kommandon inkluderade följande:

  • EXEC för att ladda och köra ett program
  • LOAD för att ladda ett program i minnet och bryta till kommandoläge utan att köra, för att tillåta felsökningskommandon
  • GÖR för att köra en batchfil i den aktuella sessionen
  • ENTER för att köra en batchfil som om den hade skickats till kortläsaren
  • SYSFILE för att ange dispositionen för utskriven utskrift
  • LOGGA AV för att avsluta sin session. Om någon skulle använda terminalen, eller om de ville byta konto, kunde de också skriva LOGGA AV MEN för att ge en omedelbar begäran om en ny inloggning. Alla utskrivna utdata som användaren hade genererat under sin session skulle spoolas till linjeskrivaren och skrivas ut vid denna tidpunkt. Alternativet 'TAPE' kan användas, som i LOGOFF TEJP , LOGOFF MEN, TAPE eller LOGOFF TAPE, MEN för att indikera att väntande utskrifter ska spoolas till magnetband istället för att skrivas ut. En begäran skulle skickas till systemoperatören.

Om man hade utfärdat en paus till ett pågående program (genom Break-tangenten på en ASCII-terminal eller F1-tangenten på en Univac VDT) eller hade använt kommandot LOAD istället för EXEC, skulle man vara i "break mode" där programmet avstängdes för att låta användaren vara i kommandoläge. De kan utfärda ovanstående kommandon också följande:

  • R för att återuppta ett program som avbrutits av break-tangenten
  • INTR för att utfärda ett avbrotts-CV till ett program som stöder INTR
  • Felsökningskommandon
VS/9 inkluderade Interactive Debugging Aid (IDA) som gav kommandon för att visa minne och register, fånga programfel och lagra minne på platser. Till skillnad från andra system där en interaktiv debugger krävde att du antingen kör ett program för att använda det eller länkar en modul till ett program, var IDA en del av operativsystemet och dess kommandon var tillgängliga från break-läge.
En annan mycket användbar, men ostödd produkt för felsökning av operativsystemproblem var ett program som heter "CareCity". Operativsystemet VS/9 levererades som förmonterade moduler på magnetband. Under installationen länkades utvalda moduler samman baserat på de konfigurationsparametrar som tillhandahölls för att bilda det fungerande operativsystemet och sedan sparades på disken. Varje modul hade ett avsett ledigt utrymme i slutet, som användes för att korrigera befintlig kod i händelse av ett fel, utan att återmontera hela modulen. CareCity gjorde det möjligt för administratören att se innehållet i operativsystemets minne med hjälp av adresser i förhållande till starten av varje operativsystemmodul . Patchkod kan sedan infogas i de designade patchområdena efter behov och sedan kan grenar från befintlig kod till den nyinstallerade koden infogas. Allt detta kunde göras medan operativsystemet användes .

Filnamnskonventioner

Filnamn kan vara upp till 56 tecken långa. En fil kan bestå av bokstäver, siffror, bindestreck och siffror. Ett filnamn med alla siffror var tillåtet, men en fil kunde inte ha två på varandra följande punkter. För att komma åt en fil på ett annat konto var det nödvändigt för en användare på det kontot att göra filen offentlig. Om filen var offentlig, kunde den nås av en annan användare genom att prefixet filnamnet med indikatorn att en fil som refereras finns på ett annat konto, vilket var dollartecknet ("$"), följt av kontonamnet, följt av en period.

Om det fanns en fil med namnet "A" på konto S0103, och en användare på konto PA5 ville komma åt filen på konto S0103, måste filen först markeras som offentlig och för det andra måste den refereras av kontonamn och namnet på filen. Så en användare på konto PA5 som ville komma åt fil A på konto S0103, om filen var offentlig, skulle referera till den som $S0103.A . Observera att en användare i konto S0103 kan referera filen helt enkelt som "A" eller kan referera till den med ett fullständigt kvalificerat filnamn genom att inkludera ett dollartecken och sitt eget kontonamn, följt av en punkt och namnet.

Offentliga filer i specialkontot TSOS kunde nås genom att endast använda $ som det första tecknet i filen, såvida inte filen började med ett namn som var identiskt med ett kontonummer, i vilket fall den explicita kontoreferensen $ TSOS . skulle krävas. Dessutom $TSOS . var det som skulle kallas sökvägsnamnet för saknade filer som refereras till med namn som inte hittades i användarens konto. Till exempel, om det fanns en fil som heter S0103.XYZZY på kontot $TSOS , och det fanns ett konto på det systemet som heter S0103, skulle alla användare som vill komma åt den behöva komma åt den som $TSOS.S0103.XYZZY .

TSOS var också "standard"-kontot för en fil som refererades till som inte fanns lokalt. Till exempel, för att köra EDT-redigeringsprogrammet , skulle man utfärda kommandot att köra ett program, EXEC, följt av namnet på filen, som kallades EDT. Så, om användaren inte hade skapat en fil med namnet EDT, kunde de köra EDT-redigeraren genom att skriva

/EXEC EDT

och tryck på sändningsknappen. Om de av någon anledning hade skapat ett program med samma namn för att använda systemredigeraren skulle de behöva skriva

/EXEC $EDT

eller så kan de uttryckligen skriva in systemkontot

/EXEC $TSOS.EDT

När Unisys avbröt försäljningen av stordatorerna i 9000-serien till förmån för datorerna i EXEC 8- serien (troligen för att de inte längre var kostnadseffektiva och marknaden för stordatorer hade krympt) övergavs VS/9 i praktiken av företaget.

Se även