OS 2200 - OS 2200

OS 2200

Udvikler	Unisys
OS-familie	OS 2200
Arbejdsstat	Nuværende
Kildemodel	Lukket kilde . De fleste kilder er tilgængelige for kunder under licens.
Første udgivelse	1967 ; For 53 år siden som Exec 8 ( 1967 )
Seneste udgivelse	18.0 / 18. juli 2018 ; 2 år siden ( 2018-07-18 )
Markedsføringsmål	Enterprise / Mainframes
Opdateringsmetode	Exec og nogle andre komponenter: Linjenummerbaserede pakkede ændringer. De fleste komponenter: Midlertidige korrektioner (IC'er)
Pakkeleder	PRIMUS (intern), COMUS og SOLAR (klient og intern)
Platforme	UNIVAC 1100/2200-serien og Unisys ClearPath Dorado-systemer
kernel typen	Monolitisk kerne (unik hardware-assisteret)
Standard brugergrænseflade	Kommandolinjegrænseflade
Licens	Proprietær . Term licens eller betaling for brug (målte) licenser
Officiel hjemmeside	OS 2200-websted

OS 2200 er operativsystemet til Unisys ClearPath Dorado-familien af ​​mainframesystemer. Operativsystemets kerne af OS 2200 er en lineal efterkommer af Exec 8 til UNIVAC 1108. Dokumentation og anden information om nuværende og tidligere Unisys-systemer kan findes på Unisys offentlige supportwebsted.

Se systemarkitektur i Unisys 2200-serien for en beskrivelse af maskinarkitekturen og dens forhold til OS 2200-operativsystemet.

Historie

Der var tidligere 1100 systemer, der gik tilbage til 1101 i 1951, men 1108 var den første 1100-serie computer designet til effektiv understøttelse af multiprogrammering og multiprocessing. Sammen med denne nye hardware kom operativsystemet Exec 8 (Executive System til 1108).

Den UNIVAC 1108 computer blev annonceret i 1964 og leveret i slutningen af 1965. De første 1108 computere, som anvendes Exec I og Exec II , som var blevet udviklet til UNIVAC 1107 . Men UNIVAC planlagt at tilbyde symmetriske multiprocessor versioner af 1108 med op til 4 processorer og de tidligere operativsystemer (virkelig grundlæggende monitor programmer) blev ikke designet til, at selv om de støttede begrænset multiprogrammering.

Da UNIVAC 1110 blev introduceret i 1972, blev operativsystemets navn ændret til OS 1100 for at afspejle dets understøttelse af en bredere vifte af systemer. Navnet OS 1100 blev bevaret indtil 1988 med introduktionen af ​​Sperry 2200-serien som en opfølgning på 1100-serien, da navnet blev ændret til OS 2200. Siden da blev 2200-serien Unisys ClearPath IX-serien og derefter Unisys ClearPath Dorado Series, men operativsystemet bevarede navnet på OS 2200.

Firmanavnet og dets produktnavne ændrede sig også over tid. Engineering Research Associates (ERA) fra Saint Paul blev erhvervet af Remington Rand Corporation . Remington Rand købte også Eckert – Mauchly Computer Corporation i Philadelphia, som derefter byggede UNIVAC- computeren. De to blev kombineret i UNIVAC-divisionen af ​​Remington Rand under ledelse af William Norris. William Norris havde været en af ​​grundlæggerne af ERA og forlod senere Remington Rand for at starte Control Data Corporation . UNIVAC-divisionen i Remington Rand Corporation blev UNIVAC-divisionen i Sperry Rand Corporation, efter at Remington Rand fusionerede med Sperry Corporation . I 1970'erne startede Sperry Rand et virksomhedsidentitetsprogram, der skiftede navn til Sperry Corporation og alle divisionsnavne til at begynde med Sperry, så computersystemer blev Sperry UNIVAC. Senere blev divisionens navne droppet, og alt blev simpelthen Sperry.

Operativsystemets kerne kaldes stadig "Exec" af de fleste Unisys og kundepersonale. Da Unisys begyndte at frigive produkter af produkter, der blev testet sammen som systembaserede udgivelser, senere kaldet "ClearPath OS 2200 Release n ", blev udtrykket OS 2200 ændret til at henvise til hele produktpakken i systemudgivelsen og andre, såsom BIS , frigivet asynkront til Dorado-hardwareplatforme.

I 1986 fusionerede Burroughs og Sperry-selskaber til Unisys (som nogle længe 2200-seriens kunder siger står for "UNIVAC er stadig din leverandør"). Begge virksomheders store mainframe-produktlinjer er fortsat under udvikling, herunder MCP-operativsystemet fra Burroughs og OS 2200 fra Sperry.

I 2016 stillede Unisys en virtuel Microsoft Windows- version af OS2200 til rådighed uden beregning til uddannelses- og fritidsformål.

Eks. 8

EXEC 8 (undertiden benævnt EXEC VIII) var UNIVACs operativsystem udviklet til UNIVAC 1108 i 1964. Det kombinerede de bedste funktioner i de tidligere operativsystemer, EXEC I og EXEC II , som blev brugt på UNIVAC 1107 . EXEC 8 var et af de første kommercielt succesrige multiprocessing- operativsystemer. Det understøttede samtidige blandede arbejdsbelastninger omfattende batch , tidsdeling og realtid . Dens ene filsystem havde en flad navngivningsstruktur på tværs af mange trommer og spindler. Det understøttede også et godt modtaget transaktionsbehandlingssystem .

Tidligere systemer var alle real-mode-systemer uden hardwaresupport til beskyttelse og adskillelse af programmer og operativsystemet. Mens der havde været støtte til multiprogrammering i tidligere systemer, var det begrænset til at køre én bruger jobbet sideløbende med flere støttefunktioner kendt for at være velopdragen, såsom kortlæseren, printer, og kort Punch spoolere .

Operativsystemet Exec 8 blev designet fra starten til at være et multiprogrammerings- og multiprocesseringsoperativsystem, fordi 1108 var designet til at have op til fire CPU'er. Hukommelse og masselagring var de primære systembegrænsninger. Mens 1100-serien blev tænkt som målrettet mod et mere generelt marked, var ekstrem realtidsbehandling et primært krav.

Specifikationerne for Exec 8 blev udarbejdet i december 1964 som en foreløbig programmers referencehåndbog (brugervejledning), og arbejdet begyndte i maj 1965.

Exec 8 startede som et realtids- operativsystem med tidlig brug for det meste i almindeligt videnskabeligt og teknisk arbejde, men det blev også brugt til meddelelseskift, proceskontrol, simulering og missilskydningskontrol. Det blev designet til at køre på systemer, der ofte kun havde 128K ord (576 K byte - mindre end den maksimale hukommelsesstørrelse for IBM PC XT ) og var fokuseret på realtids- og batchbehandling. Mens de tidligste frigivelsesniveauer fungerede i 128KW, øgede funktionaliteten i senere udgivelser det uholdbart, da det ikke efterlod nok plads til programmer af nyttig størrelse. Den maksimale hukommelseskapacitet på en 1108 var 256KW (1.148 KB), så effektiv brug af hukommelse var den vigtigste begrænsning, da kernehukommelse var den dyreste del af systemet.

Masselagring bestod af 6 fod lange roterende tromler, der holdt 256 kW (i FH-432) til 2 MW (i FH-1782). Den største kapacitet til masselagring var FASTRAND- tromlen, der indeholdt 22 MW (99 MB). Filfragmentering blev håndteret af en proces kaldet en "fil gemme", som normalt blev udført en gang om dagen om natten. Det involverede at rulle alle filer ud til tape, geninitialisere trommefilsystemet og derefter læse filerne ind igen.

Med alvorlige hukommelsesbegrænsninger og brug i realtid var det kun et krav at opbevare en enkelt kopi af kode indlæst i kernen. Da 1108 var designet til multitasking, var systemet fuldt "reentrant" ( trådsikkert ). Hvert reentrant-modul fik adgang til programdata gennem en enkelt "base-adresse" i hukommelsen, som var forskellig for hver forekomst af kørte data. Skift af eksekveringskontekster kunne udføres i en enkelt instruktion blot ved at indstille en anden basisadresse i et enkelt register. Systemet brugte finkornet låsning for at beskytte delte datastrukturer. Den udøvende, kompilatorer, hjælpeprogrammer og endda sofistikerede brugerapplikationer, der muligvis har flere kopier, der kører samtidigt, blev skrevet, så deres kode kunne deles. Dette krævede, at der kun blev lagt en kopi i hukommelsen, hvilket både sparer plads og den tid, det tog at indlæse koden.

En anden grund til at adskille kode og data i forskellige belastningsenheder var, at hukommelsen blev implementeret som to uafhængige banker (separate fysiske kabinetter) kaldet IBANK og DBANK (instruktion og data). Hver havde sin egen adgangssti, så CPU'en kunne læse begge banker samtidigt. Ved at indlæse eksekverbar kode i den ene hukommelsesbank og data i den anden kunne mange programmer næsten halveres.

Reentrant-kode skulle være trådsikker (kun udføre); selvmodificerende kode var ikke tilladt. For andre programmer var ændring af eksekverbar kode under kørsel stadig en acceptabel programmeringsteknik inden for computere i 1100-serien, men brugerne blev opfordret til ikke at gøre det på grund af præstationshit. Sikkerhedsfordele blev udråbt, men ikke højt værdsat, fordi hacking af de fleste applikationer i 1100-serien ikke ville give nogen fordel for nogen, og fordi få hackere da var ondsindede.

Exec 8 var primært et batchbehandlingssystem , der gav applikationer (kaldet "opgaver") meget fin kontrol over CPU-planlægningsprioritet for sine tråde (kaldet "aktiviteter"). Processorkobling var forebyggende, hvor tråde med højere prioritet fik kontrol over processoren, der i øjeblikket kører den laveste prioritets tråd i ethvert program. Bortset fra i realtidssystemer fik selv de lavest prioriterede opgaver noget processortid. Det var et multiprogrammerings- og multiprocessing-operativsystem med fuldt symmetrisk processorstyring. En test-og-sæt-instruktion indbygget i hardwaren tillod meget effektiv og finkornet låsning både inden for operativsystemet og inden for multitrådede applikationer.

I Exec 8 er arbejde organiseret i job, kaldet "kører", som er planlagt ud fra deres prioritet og behov for låsbare ressourcer såsom Uniservo bånddrev eller Fastrand trommefiler. Kontrolsprogssyntaks bruger symbolet "@" (som Univac kaldte "masterrummet") som symbol for kontrolerkendelsesgenkendelse. Det blev straks efterfulgt af kommandoen eller programnavnet, derefter skiftes et komma og enhver indstilling. Efter et mellemrum tegn adskiller sig resten af ​​udsagnet for bestemte kommandoer. En kommando til at kompilere et FORTRAN-program vil se ud som "@FOR [, optioner] sourcefile, objectfile". Inputdata til en applikation kan læses fra en fil (generelt kortbilleder) eller straks følge kommandoen @ i kørestrømmen. Alle linjer indtil sentinel-kommandoen "@END" blev antaget at være inputdata, så at glemme at indsætte det førte til, at compileren fortolker efterfølgende kommandoer som programdata. Af denne grund var det at foretrække at behandle data i filer i stedet for at indtaste dem i kørestrømmen.

I 1968 begyndte arbejdet med at tilføje tidsdelingsfunktion til Exec 8. Den blev leveret med niveau 23 af den udøvende i 1969. Tidsdeling (kaldet efterspørgselstilstand ) havde de samme muligheder som batch- og realtidsprocesser. Alt, hvad der kunne gøres i batch, kunne gøres fra en ASCII-terminal. I efterspørgselstilstand blev jobstream I / O knyttet til en terminalhåndterer snarere end kortbillede (input) og spool (output) filer. Det samme kørekontrolsprog blev brugt til begge. Et par år senere blev der tilføjet mere specifikke tidsdelingskommandoer, og nogle kontrolerklæringer kunne udstedes asynkront til øjeblikkelig behandling, selv når hverken den udøvende eller det igangværende program forventede data. Disse kommandoer, som kun kunne indtastes fra en terminal, begyndte med "@@". Fordi de kunne udføres uden at stoppe andet igangværende arbejde fra den samme terminal, blev de kaldt gennemsigtige kommandoer. Først var dette kun udsagn om at dræbe det aktuelle program eller omdirigere terminaloutput til en fil, men til sidst fik næsten alle kontroludtalelser lov til at være "øjeblikkelige".

Både batch- og demand-kørsler afsluttes med en @FIN-sætning, og hvis en efterspørgselsbruger afslutter sin session, mens hans kørsel er aktiv, afslutter Exec automatisk kørslen uden at kræve @FIN.

Kommunikationssoftware

En transaktionsbehandlingsfunktion blev udviklet i slutningen af ​​1960'erne som et fælles projekt med United Airlines og senere raffineret i et andet fælles projekt med Air Canada. Denne kapacitet blev fuldt integreret i operativsystemet i 1972 og blev grundlaget for meget af den fremtidige vækst i 1100-serien. Tidlige brugere kontrollerede kommunikationslinjer direkte fra deres realtidsprogrammer. En del af udviklingen af ​​transaktionsbehandling omfattede et kommunikationsmeddelelsessystem, der styrede kommunikationslinjerne og præsenterede meddelelser til Exec 8, der skulle planlægges som transaktioner. Dette flyttede al den fysiske linjestyring og protokoller på lavt niveau ud af applikationerne og ind i CMS 1100-applikationen.

CMS 1100 selv kørte som et realtids multitrådet program med privilegiet at erhverve kontrol over kommunikationslinjer og indsende transaktionsmeddelelser til planlægning. Dette førte til forestillingerne i Exec 8, at applikationer af enhver art skulle kontrolleres omhyggeligt for at sikre, at de ikke kunne forårsage integritetsproblemer. Sikkerhed var bestemt et problem, men i de tidlige dage var systemets pålidelighed og integritet meget større problemer. Systemet var stadig primært batch- og transaktionsbehandling, og der var ringe chance for, at nogen kunne installere uautoriseret kode på systemet. CMS 1100 tilføjede senere muligheden for at være grænsefladen for efterspørgselsterminaler såvel som transaktionsterminaler, så terminaler kunne bruges til begge, og de tidlige terminaldrivere kunne fjernes fra Exec. CMS 1100 blev senere erstattet af en kombination af CPComm (ClearPath Enterprise Servers Communications Platform) og SILAS (System Interface for Legacy Application Systems). For de Intel-baserede Dorado-servermodeller blev kommunikationen på lavere niveau flyttet til firmware, hvor de øverste niveauer blev håndteret af SILAS og CPCommOS (ClearPath Enterprise Servers Communications Platform for Open Systems).

Exec

Exec indeholder al den kode i systemet, der får lov til at køre på de højeste privilegieniveauer. Der er ingen mekanismer til at promovere anden kode til disse privilegieniveauer.

Exec er ansvarlig for styring af systemhardwaren, planlægning og styring af arbejde og kommunikation med operatører og administratorer.

I frigivelse 16.0 er Exec niveau 49R2 (49.70.5). De interne systemniveauer bruger et tredelt nummer såsom 21.92.42 (som var det første meget anvendte produktionssystem, selvom tidligere udgivelser blev brugt til produktion på en række steder). Den første nummerdel er hovedniveauet og indikerer en ny version af Exec med alle tidligere opdateringer integreret i en ny baseversion. Dette er en sjælden proces og forekommer med intervaller på år. Den anden nummerdel angiver versioner af opdateringer til hovedniveau og forekommer ofte flere gange om ugen. Når der træffes en beslutning om at fryse funktionsindholdet og forberede sig på frigivelse, kommer den tredje del i spil og indikerer versioner af pre-release-niveauet, da rettelser og mindre funktionsopdateringer anvendes. Samtidig med at forberede et niveau til frigivelse fortsætter opdateringer til "hovedlinjen", da ingeniører integrerer ændringer som forberedelse til en fremtidig frigivelse. I mange år var det officielle frigivelsesniveau det fulde tredelt nummer. Senere udgivelser blev simpelthen navngivet 44R1, 44R2, 49R2 og så videre, selvom nummeret i tre dele stadig bruges internt.

Udfører arbejde

Exec er kernen i et realtidsbatch-behandlingssystem med flere tråde. Alt er bygget omkring den model. Selve Exec er stort set struktureret som et realtidsprogram. Funktioner, der udføres som Services i Windows eller Daemons i Linux og UNIX, implementeres enten som aktiviteter i Exec eller som batchprogrammer, der altid kører i baggrunden.

Tidsdeling (kendt som efterspørgselstilstand ) og transaktionsbehandling implementeres som særlige batch-tilfælde. Et resultat er, at der er få begrænsninger for, hvad en tidsdelingsbruger eller et transaktionsprogram kan gøre. Der er mange advarsler til forfattere af transaktionsprogrammer om, at de ikke vil være tilfredse med ydeevnen, hvis de f.eks. Kræver et båndbeslag, men det er tilladt.

Den største enhed er "Run". Dette er taget fra fabrikken "produktionskørsel" terminologi og svarer generelt til job eller session på andre systemer. En kørsel er defineret af dens "kør stream". En kørestrøm er en sekvens af kontrolerklæringer, der repræsenterer de trin, der skal tages. De kan omfatte filhåndtering, programudførelse og grene af kontrol. En batchkørsel lagres typisk som en fil og planlægges af en "Start" -kommando fra en anden kørsel eller af operatøren. En tidsdelingskørsel startes ved at logge ind fra en tidsdelingsterminal og indtaste kommandoen @RUN. Ofte genereres @RUN-sætningen og den anden kontrolerklæring (ofte @ADD eller en programudførelse) baseret på brugerprofilen. Sikkerhedsgodkendelser er valideret baseret på det godkendte bruger-id og andre oplysninger, der er angivet i Run-kontrolerklæringen.

Transaktioner er et specielt tilfælde. Der er faktisk ingen kontrolerklæringer, men de interne datastrukturer i en kørsel oprettes. Dette gør det muligt for Exec at knytte de samme mekanismer til sikkerhed, regnskab, fejlretning osv. Til transaktionsprogrammer. Generelt caches en sikkerhedsprofil i hukommelsen på det tidspunkt, hvor transaktionsbrugeren godkendes og kopieres fra brugerens sessionsdata til transaktionskørstilstanden, når transaktionen er planlagt. Da hver transaktionsforekomst i det væsentlige er en kørsel, er bogføring, logføring og fejlhåndtering indkapslet af køremekanismen.

Parti

Batchjobs (Kørsler) er kendetegnet ved at have en runstream (jobkontrolsprogsætninger) gemt i en fil. Et batchjob indeholder altid en @RUN-sætning som den første post i filen. Denne erklæring giver kørslen et navn (runid), definerer prioriteter og definerer det maksimale antal SUPS (standardenheder til behandling), som jobbet forventes at bruge. Jobbet startes fra et andet job med en @START kontrolerklæring eller af operatøren via en ST keyin. Systemet kan konfigureres til automatisk at udsende @START-erklæringer for et vilkårligt antal job, når det starter. Disse job tjener formålet med at udføre initialiserings-, gendannelses- og baggrundsfunktioner.

Alle felterne i @RUN-sætningen kan tilsidesættes af tilsvarende felter i @START-sætningen. Bortset fra når @START udføres af en privilegeret bruger, tages altid bruger-id og anden sikkerhedstilstand fra kørslen ved at gøre @START.

Der er to prioritetsfelter på @RUN-erklæringen. Den ene bruges til at specificere backlogprioriteten. Der er 26 prioritetsniveauer for efterslæb (A - Z). Exec har et konfigureret maksimalt antal åbne batch-kørsler. Når dette niveau er nået, vælges job derefter fra backlog-køerne i prioriteret rækkefølge. Inden for et prioriteret valg er normalt FIFO. Exec scanner dog jobkontroludtalelserne op til den første programudførelse på udkig efter filnavne og hjulnumre. Hvis jobbet straks stopper, fordi nogle ressourcer, det har brug for, ikke er tilgængelige, kan det blive omgået for at starte andre job på samme prioritetsniveau.

Det andet prioritetsniveau definerer en ressourcegruppe til udførelsesprocessor. Generelt får højere udførelsesgruppeprioriteter typisk mere processortid.

Mens OS 2200 jobkontrolsprog ikke understøtter fuld programmerbarhed, tillader det dynamiske tilføjelser af sekvenser af kontrolsprog gennem en @ADD kontrolerklæring. Filen, der skal tilføjes, kan være oprettet af det samme job umiddelbart før tilføjelsen. @ADD og de fleste andre kontrolerklæringer kan også indsendes fra et kørende program via en API. Yderligere programmerbarhed er tilgængelig indirekte gennem brug af Symbolic Stream Generator (SSG). SSG er et programmeringssprog til manipulation og oprettelse af tekstfiler fra inputparametre og systeminformation. Det bruges stærkt til konfigurationsstyring ( make ) -behandling og andre funktioner, hvor tekstbilleder skal oprettes programmatisk. Den resulterende output kan "@ADD" redigeres i samme kørsel, hvilket giver den indirekte programmerbare runstream.

Operatorkommandoer er tilgængelige for at ændre både efterslæb og udførelsesprioriteter for kørsler. Da alle operatørkommandoer er tilgængelige af API for passende privilegerede brugere, kan dette automatiseres eller styres af en fjernadministrator.

Deadline er et specielt tilfælde af batch. En deadline-kørsel ser ud som enhver anden batch-run, bortset fra at en deadline-tid er specificeret i @RUN- eller @START-kontrolerklæringen. Deadline-tiden bruges sammen med den maksimale SUPS (tidsestimat) på kontrolerklæringen. Et deadline-job kører ved normale batchprioriteter, medmindre eller indtil det ser ud til, at det kan gå glip af deadline-tiden. Så jo mere uoverensstemmelsen mellem tid indtil deadline og resterende SUPS, jo højere prioritet. Mens deadline ikke helt kan lukke transaktioner og ikke har nogen indvirkning på realtid, kan den effektivt lukke de fleste andre processer i systemet, hvis det er nødvendigt for at nå sit mål.

Efterspørgsel

OS 2200-tidsdelingssessioner kaldes efterspørgsel (fra "on demand") kører. De bruger det samme kontrolsprog som batchkørsler med et par tilføjelser kendt som "øjeblikkelige" kontrolerklæringer. Øjeblikkelige kontrolerklæringer bruger sentinel "@@", som indikerer, at de skal udføres med det samme, selvom et program kører. Selvom de kan bruges til at oprette eller tildele filer, tillader de vigtigste dem, at en bruger efterspørger fejl ved at afslutte et kørende program eller endda sende det et signal.

Transaktioner

Transaktioner udføres som kørsler, men uden nogen lagrede eller indsendte kontrolerklæringer. I stedet når en meddelelse modtages fra en session defineret som en transaktionssession, scannes den for at bestemme transaktionskøen, som den skal placeres på. Dette bestemmes normalt af meddelelsens første tegn, men brugerskrevne scannere kan tilføjes.

Kommunikationsadministratoren, der er i stand til at håndtere op til 250.000 aktive sessioner, tager indgående transaktionsmeddelelser og sender dem til meddelelseskø-softwaren. Det kan håndtere et ubegrænset antal købeskeder ved hjælp af meddelelseskøarkitekturen. Der kaldes til TIP-API'erne ( Transaction Interface Package ) i operativsystemet for at sætte køen i kø på det relevante køpunkt. Hvert køpunkt identificerer prioritets- og samtidighedsniveauet for arbejdet og det tilknyttede transaktionsprogram, der skal udføres.

Et planlægningstræ for et transaktionsprogram tillader klienten at etablere relativ brug for grupper af transaktionsprogrammer. Samtidige grænser undgår en type arbejde, der dominerer systemet med undtagelse af andet arbejde, og undgår at skabe et for stort engagement af ressourcer. Op til 4094 noder kan oprettes i træet.

• Maksimal samtidighed angivet for hver node i træet
• Samtidighed med højere node begrænser den samlede samtidighed af afhængige noder
• Samtidighed med højeste knudepunkt begrænser systemets samtidighed

Prioritet (0 til 63) og samtidighedsniveau (1 til 2047) kan specificeres for hvert transaktionsprogram.

Transaktionen med den højeste prioritet vælges til planlægning undtagen som begrænset af de samtidige politikker, der gælder for dens node og højere noder.

Realtid

Realtid er ikke en anden type kørsel. Det er snarere et sæt prioritetsniveauer, som enhver aktivitet kan anmode om. Realtid bruges mest af langvarige batchprogrammer, som f.eks. OS 2200 kommunikationschef CPComm, men er ikke begrænset til sådanne.

Der er 36 realtids prioritetsniveauer tilgængelige af API, som applikationer kan bruge. Brugeren og kontoen skal have privilegiet at bruge realtidsprioriteter. Det er op til webstedet at kontrollere, hvordan deres applikationer bruger prioritetsniveauerne. Realtidsprioriteter dominerer totalt alle lavere prioriteter, så det er meget muligt for et dårligt opført realtidsprogram at binde en eller flere processorer.

Realtidsprioriteten gælder for en individuel aktivitet (tråd), så et program kan have både realtids- og ikke-realtidstråde, der udføres på samme tid.

CPU-forsendelse

Når en kørsel er startet, styrer adgangen til processoren dens hastighed. Hjertet i Exec er Dispatcher, der administrerer alle processorer.

Exec understøtter op til 4095 forsendelsesprioriteter, selvom de fleste websteder kun definerer en lille delmængde af dem. De to højeste "prioriteter" kan ikke skiftes. De er anerkendelse af visse typer behandlinger, der skal have lov til at fortsætte på den processor, som de startede på, indtil de frivilligt opgiver kontrol. Interrupt lockout opstår, når der kommer en afbrydelse, eller i nogle få specielle tilfælde, når anden Exec-kode forhindrer alle afbrydelser (for at ændre nogle data, som en interrupthandler også kan få adgang til).

Interlock bruges af interrupt post-behandlingsrutiner, der enten skal køre på den samme fysiske processor eller simpelthen ikke bør afbrydes. Dispatcher, I / O-kompletteringer og I / O-initiering er nogle eksempler. Alle låse, der bruges af begge disse prioriteter, er spin-låse, da den eneste måde, de kan indstilles af en anden på, er på en anden processor, og designet kræver, at de kun er indstillet til meget korte instruktionssekvenser.

Høj Exec-prioritet bruges af operatørens kommandobehandler og nogle andre funktioner, der muligvis skal køre, selv når et realtidsprogram har kontrol. De forventes kun at bruge meget korte tidsrum. Hvis de har brug for mere tid, skal de sætte det arbejde, der skal behandles af en Low Exec-aktivitet i kø.

Realtidsaktiviteter har et ubegrænset processorkvantum og kører uden at skifte, medmindre de afbrydes af en realtidsaktivitet med højere prioritet eller High Exec-aktivitet. Realtidsaktiviteter får kontrol over enhver tilgængelig processor, der kører noget med lavere prioritet. Afbrydelser sendes mellem processorer, når det er nødvendigt for at sikre øjeblikkelig tilgængelighed. Realtid bruges af kunder til at flyve missiler, køre simulatorer og andre funktioner, der kræver øjeblikkelig reaktion.

Transaktionsprioriteter kan håndteres på to måder som defineret af webstedet. De kan være en slags lavere prioritet i realtid, idet kun prioriteten betyder noget, og kvantestørrelsen i det væsentlige er uendelig. Dette er passende for meget kortvarige transaktioner såsom flyreservationer; hvis man sløjfer på grund af en programmeringsfejl, vil Exec afslutte den, når den når sin meget lille konfigurerede maksimale tid. Den anden form giver Exec mulighed for at variere prioriteten inden for et interval for at optimere systemressourceforbruget. Metoden giver højere prioritet og kortere tidsskiver til programmer, der er I / O-begrænsede og gradvis lavere prioriteter, men længere tidsskiver til dem, der beregner. Exec tilpasser dynamisk disse prioriteter baseret på adfærd, da programmer ofte opfører sig begge veje på forskellige tidspunkter. Denne tilgang er passende for længerevarende transaktioner som databaseforespørgsler eller flyselskabspristilbud.

Batch og efterspørgsel bruger altid dynamisk justerede prioriteter. Programmer, der er I / O-begrænsede eller er i en samtale med en tidsdelingsbruger, får højere prioriteter, men korte tidsskiver. Flere beregningsorienterede programmer får lavere prioriteter og længere tidsskiver.

Exec har to yderligere mekanismer til optimering af forsendelse. Den ene er affinitetsbaseret afsendelse. Når det er muligt, kører Exec en aktivitet på den samme processor, som den var sidste gang for at få størst mulig fordel af resterende cacheindhold. Hvis det ikke er muligt, forsøger det at holde aktiviteten på den "nærmeste" processor set fra cache- og hukommelsesadgangstidspunktet. Det andet er en "retfærdighed" -politisk mekanisme. Webstedet kan definere den relative procentdel af ressourcer, der skal tildeles til hver af transaktioner, efterspørgsel og batch. Inden for transaktioner og batch er der prioritetsgrupper, der yderligere kan angive, hvor stor en procentdel af deres gruppes tid, der skal tildeles prioriteten. Dette sikrer, at transaktioner ikke kan dominere systemet så, at der ikke udføres batcharbejde. Inden for de forskellige prioriterede grupperinger sikrer det, at der kan sikres nogle fremskridt for hver gruppe (medmindre gruppeprocenten er nul). Disse "fairness" -algoritmer kommer kun til spil, når processorer er meget travle, men OS 2200-systemer kører ofte med alle processorer næsten 100% brugt.

Måling

OS 2200 understøtter flere modeller til styring af systemets ydeevne. Kunder kan købe et bestemt fast ydelsesniveau, og Exec overvåger processorbrug for at sikre, at ydelsen ikke overstiger dette niveau. Kunder kan også købe ekstra ydelse enten midlertidigt eller permanent op til systemets fulde kapacitet, hvis deres arbejdsbyrde øges, eller hvis en nødsituation kræver det.

For nylig har systemet tilføjet en målt anvendelsesfunktion. I denne tilstand er systemets fulde effekt altid tilgængelig for kunden (selvom de administrativt kan begrænse det). Brugen akkumuleres over en måned, og derefter rapporteres den rapporterede brug til Unisys-fakturering. Afhængigt af de specifikke kontraktbetingelser modtager klienten muligvis en regning for overskydende forbrug over en aftalt basislinje for måneden eller blot en erklæring, der viser, at den samlede kontraktforbrug er blevet reduceret. Den første form er som en mobiltelefonregning med potentiale for opladning i overskydende minutter. Sidstnævnte er som at købe et forudbetalt telefonkort.

Filsystem

OS 2200 har ikke et hierarkisk filsystem som de fleste andre operativsystemer. Det har snarere en struktureret navngivningskonvention og begrebet containerfiler kaldet programfiler.

Filer i OS 2200 er simpelthen containere, der kan adresseres enten ved ordforskydning i filen eller efter sektor (28-ords enhed) forskudt i filen. De 28 ord er en historisk enhed fra en tidlig masselagringsenhed (FASTRAND-tromlen), der kunne rumme 64 sådanne enheder pr. Fysisk spor. Ikke desto mindre er det en heldig historisk ulykke. Fire sådanne enheder på 28 ord eller 112 ord optager 504 bytes. Med nutidens masselagerenheder, der alle bruger 512-byte fysiske poster, har OS 2200-klienter næsten alle brugt nogle multiple af 112 ord som deres fysiske rekordstørrelse og databasesidestørrelse. I / O-processorer justerer automatisk for 504 <-> 512 byte-kortlægning, der tilføjer 8 bytes nuller ved skrivning og fjerner dem ved læsning af hver fysisk post. OS 2200 håndterer applikationer, der bruger andre størrelser end multipla på 112 ord ved uadskilleligt at læse de indeholdende fysiske poster og skrive de uændrede og ændrede dele tilbage med datakæde. Specielle låsefunktioner garanterer udelelighed, selv når der er enhedsfejl og på tværs af flere systemer i en klynge.

Filformater og andre interne datastrukturer er beskrevet i referencemanualen til programmering af datastrukturer .

Filnavne

Lige siden Exec-8 har filnavne antaget form: Kvalifikator * Filnavn (f-cyklus) (f.eks. "PERSONALE * MEDARBEJDERE (+1)"). Kvalifikator og filnavn er simpelthen tolv tegnstrenge, der bruges til at skabe den navngivningsstruktur, klienten ønsker. F-cyklus er et tal fra 0 til 999, der tillader flere generationer af en fil. Disse kan refereres til med relative tal: (+1) næste eller nye cyklus, (-1) forrige cyklus, (+0) nuværende cyklus. At lade cyklus være slået fra er som standard den aktuelle cyklus. Batchproduktionskørsler, der skaber nye generationer af filer, bruger denne tilgang. Tallene ombrydes efter 999. Kun 32 på hinanden følgende relative cyklusnumre kan eksistere ad gangen. Oprettelse af en (+1) slettes (-31).

Enhver fil kan bruges som en programfil. En programfil indeholder elementer, der generelt fungerer som filer. Elementnavngivning er Qualifier * Filnavn (f-cyklus). Element / version (e-cyklus) (f.eks. "PERSONAL * PROGRAMS.TAXCALC / 2008"). Element og version er tolv tegnnavne, der bruges på enhver måde, som en bruger ønsker. E-cyklus svarer til f-cyklus, idet den repræsenterer et generationstal, men uden begrænsning til 32 samtidige cyklusser, og grænsen er 256K cykler. E-cyklus gælder dog kun for tekstelementer, og hver linje i et tekstelement er markeret med de cyklusnumre, hvormed den blev indsat og slettet. Elementerne har også en type og undertype. De mest anvendte typer er "tekst" og "objekt". Hvis standardtypen ikke er egnet, skal du vælge den passende type. Tekstelementer har også undertyper, der typisk repræsenterer programmeringssproget (f.eks. "ASM", "C", "COB", "FOR"). Standardelementnavnet på en objektfil er det samme som tekstfilen, hvorfra den blev oprettet.

Et objektelement kan udføres, hvis det er et hovedprogram eller linket til andre objektelementer inklusive et hovedprogram. Forbindelsen kan være statisk eller dynamisk. Et hovedprogram kan udføres uden forlinkning, forudsat at alle krævede underprogrammer er i den samme programfil, er systembiblioteker eller på anden måde er kendt. Regler kan være inkluderet i en programfil for at lede den dynamiske linkers søgning efter uopfyldte referencer. Linkeren kan også bruges til statisk at linke flere objektmoduler sammen for at danne et nyt objektmodul, der indeholder alle instruktioner, data og anden information i de originale objektmoduler.

Omnibus-elementer kan bruges som data af applikationer eller kan tjene til at indeholde struktureret information til applikationer og systemværktøjer. Der er ingen antaget struktur til et omnibus-element.

For kompatibilitet med tidligere (grundlæggende tilstand) programmeringsmodeller er der flytbare og absolutte elementtyper. Flytbare elementer er output fra kompilatorer til grundtilstand. De kan kombineres af den statiske basiske linker (@MAP - samleren) for at danne et "absolut" element, der er eksekverbart.

Filhåndtering

OS 2200 implementerer et fuldt virtuelt filsystem. Filer kan allokeres overalt på tværs af alle masselagerenheder. Masselagring behandles som en stor pladspool svarende til den måde, hvorpå virtuel hukommelse styres. Mens tilstødende plads tildeles, hvis det er muligt, behandles masselagring som et sæt sider med 8 KB størrelse, og en fil kan placeres i så mange områder af de samme eller forskellige enheder, som det kræves. Dynamisk udvidelse af filer forsøger at tildele plads ved siden af ​​den tidligere tildeling, men finder plads, uanset hvor den er tilgængelig. Faktisk behøver filer ikke engang at være til stede på masselagring, der skal bruges. Exec og system til sikkerhedskopiering af filer er fuldt integreret. Når der foretages sikkerhedskopier af filer, registreres båndspolens nummer (numre) i filmappen. Hvis pladsen mangler på masselagring, markeres nogle filer simpelthen som "uindlæst", hvis de har en aktuel sikkerhedskopi, og deres plads er tilgængelig til brug. Hvis der ikke findes nok plads på den måde, startes en sikkerhedskopi.

Enhver henvisning til en ulastet fil vil blive sat i kø, mens filen kopieres tilbage til masselagring. Hele systemet er automatisk og generelt gennemsigtigt for brugerne.

Adgangsmetoder

Generelt giver Exec ikke adgangsmetoder . Filer er simpelthen containere. Adgangsmetoder leveres af sprogkørselstidssystemerne og databasesystemet. Den ene undtagelse er en fastblokadgangsmetode, der er beregnet til behandling af store mængder transaktioner. Det har meget mindre omkostninger end databasesystemet, men deltager dog i alle låse-, klyngemekanismer og gendannelsesmekanismer.

Aftagelige pakker

Når klienter ønsker mere eksplicit kontrol over placeringen af ​​filer, kan de bruge konceptet "flytbar pakke". På et tidspunkt repræsenterede disse virkelig fysisk aftagelige diskpakker, og operativsystemet genererer automatisk pakmonteringsanmodninger til operatører efter behov.

I dag bruges de stadig til at placere filer, normalt databasefiler eller transaktionsfiler, på en eller flere diskvolumener. Filer spænder muligvis stadig over flere diskvolumener, og nu vises listen over lydnavne, når filen oprettes. Filer, der er i sådanne volumengrupper, er stadig sikkerhedskopieret, men er ikke underlagt automatisk virtuel rumadministration.

CIFS

OS 2200 giver også en fuld implementering af Common Internet File System ( CIFS ). CIFS implementerer SMB-protokollen, der bruges af Microsoft-servere og UNIX / Linux Samba- softwaren. CIFS til ClearPath OS 2200 er både en filserver og filklient til andre CIFS-kompatible systemer. Dette inkluderer stationære pc'er, der kører Windows. CIFS understøtter SMB-meddelelsessignering.

For at opretholde OS 2200-sikkerhed giver CIFS til ClearPath OS 2200 to beskyttelsesniveauer. For det første er OS 2200-filer ikke synlige for netværket, før de er blevet erklæret som "delte" med en CIFS-kommando. Der findes et specifikt privilegium til at kontrollere, hvem der kan erklære en andel. Det andet kontrolniveau er, at al adgang stadig er beskyttet af OS 2200-sikkerhed. Kunder, der har adgang til OS 2200 via CIFS, skal enten identificeres automatisk via NTLM eller Kerberos, eller de får en forespørgsel om deres OS 2200 bruger-id og adgangskode.

CIFS gør det muligt at præsentere OS 2200-filer i en hierarkisk visning. Typisk vises kvalifikatoren som det højeste niveau i træet efterfulgt af filnavn, elementnavn og version. Derudover kan filer muligvis gemmes på OS 2200-servere ved hjælp af det fulde Windows-filnavnformat. Windows-applikationer ser OS 2200 som en anden filserver. OS 2200-applikationer har API'er tilgængelige til at læse og skrive filer, der findes på andre CIFS-kompatible servere, såsom Windows-filservere, i netværket. Tekstfiler konverteres automatisk til og fra OS 2200 interne formater. Binære filer skal forstås af applikationsprogrammet.

CIFSUT-værktøjet, der kører under OS 2200, kan udveksle krypterede komprimerede filer med anden software, såsom WinZip.

Delsystemer

Begrebet delsystemer og beskyttede delsystemer er centrale for designet af OS 2200. Et delsystem er mest analogt med en .dll i Windows. Det er kode og data, der kan deles mellem alle programmer, der kører i systemet. I OS 2200 har hvert subsystem sit eget sæt banker, der er bosat i en separat del af adresseområdet, som intet brugerprogram kan få direkte adgang til. I stedet leverer hardware og operativsystemet en "gate", der kan være målet for en opkaldsinstruktion. Se systemarkitektur i Unisys 2200-serien for at få flere oplysninger.

Databasestyrerne, kørselsbibliotekerne, meddelelsessystemet og mange andre systemfunktioner er implementeret som undersystemer. Nogle delsystemer, der normalt består af ren kode, såsom kørselstidsbiblioteker, kan være det direkte mål for en opkaldsinstruktion uden at kræve en gate. Disse undersystemer kører i brugerprogrammets beskyttelsesmiljø. Andre undersystemer, såsom databasesystemer, består af kode og data eller privilegeret kode og kan kun kaldes via en gate. Disse delsystemer kan også have tilknyttet adgangskontrolister til at kontrollere, hvem der kan kalde dem. Mere vigtigt er det, at porten styrer de specifikke indgangspunkter, der er synlige, det beskyttelsesmiljø, hvor delsystemet kører, og ofte en brugerspecifik parameter, der giver yderligere sikker information om den, der ringer op.

Sikkerhed

B1 sikkerhed

OS 2200-sikkerhedssystemet er designet til at beskytte data mod uautoriseret adgang, ændring eller eksponering. Det inkluderer en implementering af DoD Orange Book B1- niveau-specifikationen. OS 2200 opnåede først en vellykket B1-evaluering i september 1989. Denne evaluering blev opretholdt indtil 1994. Efter dette punkt fortsatte OS 2200-udviklere med at følge udviklings- og dokumentationspraksis, der kræves i B1-evalueringen.

Centralt i et B1-system er begreberne brugere og objekter. Brugere har identiteter, clearance niveauer, rum og privilegier. Objekter kræver visse kombinationer af dem til forskellige typer adgang. Objekter i OS 2200 består af filer, beskyttede undersystemer, enheder og båndruller.

Sikkerhedsprofilen for en brugersession inkluderer brugeridentitet, clearingsniveau (0-63), rumsæt og sæt tilladte privilegier. OS 2200 implementerer både obligatorisk adgangskontrol (MAC) og diskretionær adgangskontrol (DAC) baseret på Bell-La Padula-modellen for fortrolighed (ingen læsning, ingen nedskrivning) og Biba-integritetsmodellen (ingen læsning, ingen opskrivning) . For at en kørsel kan læse eller udføre en fil, skal kørens eksekveringsklaringsniveau være større end eller lig med filens clearingsniveau, og filens clearingsniveau skal være 0 eller inden for clearance-niveauet for løbet; derudover skal kørens eksekverende rumsæt indeholde filens rumsæt. Da OS 2200 kombinerer Bell-La Padula og Biba-modelkravene, skal en kørsels udførelsesklaringsniveau og rumsæt nøjagtigt matche kravene i en fil for at tillade skrivning til filen eller sletning af den.

DAC forbinder en adgangskontroliste med et objekt; listen identificerer brugere og brugergrupper, der har adgang og definerer den type adgang, som bruger eller gruppe har tilladelse (læs, skriv, udfør eller slet).

Da det fulde sæt af B1-kontroller er for begrænsende for de fleste miljøer, kan systemadministratorer konfigurere servere ved at vælge, hvilke kontroller der skal anvendes. Et sæt sikkerhedsniveauer fra grundlæggende sikkerhed gennem sikkerhedsniveau 3 tjener som udgangspunkt.

Sikkerhedsofficer

Hvert OS 2200-system har en bruger, der er udpeget som sikkerhedsofficer. På systemer, der er konfigureret med grundlæggende sikkerhed, er det kun sikkerhedsofficeren, der har lov til at udføre bestemte opgaver. På systemer, der er konfigureret med højere sikkerhedsniveauer, kan andre pålidelige brugere muligvis udføre nogle af disse opgaver.

OS 2200 giver en finkornet sikkerhedsmekanisme baseret på princippet om mindst privilegium . Dette princip kræver, at kun det mindste privilegium gives, der er nødvendigt for at udføre den krævede opgave. Således har OS 2200 intet koncept for en "superbruger" -rolle, som enhver bruger kan antage. Snarere bruger den et stort sæt specifikke privilegier, som kan tildeles hver bruger hver for sig. Hvert privilegium er knyttet til en bestemt autoritet.

Filsikkerhed

På systemer konfigureret med sikkerhedsniveau 1 eller højere er den bruger, der opretter et objekt, objektets ejer. Standard er, at objektet er privat for den oprettende bruger, men det kan også være offentligt eller styret af en adgangskontroliste. Ejeren eller sikkerhedsofficeren kan oprette en adgangskontrolliste for det pågældende objekt.

På system konfigureret med grundlæggende sikkerhed har filer ikke ejere. I stedet oprettes de private for en konto eller et projekt, eller de er offentlige. Adgang til dem kan styres med læse- og skrivetaster.

Godkendelse

Når brugerne logger på systemet, identificerer de sig selv og vælger eventuelt det niveau for rum og rum, de vil bruge til denne session.

OS 2200 tilbyder et fleksibelt godkendelsessystem. Flere godkendelsesmekanismer understøttes samtidigt. Klient- eller tredjepartsskrevet godkendelsessoftware kan også bruges. Standard godkendelsesfunktioner inkluderer:

• Bruger-id og adgangskode vedligeholdt i en krypteret fil af OS 2200
• Godkendelse udført af et eksternt system såsom Microsoft Windows ved hjælp af dets bruger-id og adgangskodemekanisme
• NTLM
• Kerberos
• LDAP

De sidste to tillader brug af biometri, smartkort og enhver anden godkendelsesmekanisme, der understøttes af disse teknologier.

Kryptering

OS 2200 giver kryptering af data i hvile gennem Cipher API, et softwaresubsystem, der krypterer og dekrypterer opkaldsdata. Cipher API understøtter også brugen af ​​et hardwareaccelerator-kort til bulk-datakryptering.

For CMOS-baserede Dorado-servere leverer CPComm SSL / TLS- kryptering til data under transport . For Intel-baserede Dorado-servere leveres SSL og TLS af openSSL , som er inkluderet i Dorado-firmwaren. Alle Dorado-servere understøtter TLS-niveauer 1.0 til 1.2 samt SSLv3, men SSL er som standard deaktiveret på grund af sårbarheder i protokollen.

Både CPComm og Cipher API bruger krypteringstjenesterne i CryptoLib, et FIPS- certificeret softwarekrypteringsmodul. De AES og Triple DES algoritmer er blandt de algoritmer implementeret i CryptoLib.

OS 2200 understøtter også kryptering af bånddrev, som giver kryptering til arkivdata.

Klyngedannelse

OS 2200-systemer kan grupperes for at opnå større ydeevne og tilgængelighed end et enkelt system. Op til 4 systemer kan kombineres i en klynge, der deler databaser og filer via delte diske. En hardwareenhed, XPC-L, sørger for koordinering mellem systemerne ved at tilvejebringe en højhastighedslåsemanager til database- og filadgang.

Et klynget miljø giver hvert system mulighed for at have sine egne lokale filer, databaser og applikationsgrupper sammen med delte filer og en eller flere delte applikationsgrupper. Lokale filer og databaser er kun tilgængelige via et enkelt system. Delte filer og databaser skal være på diske, der er tilgængelige samtidigt fra alle systemer i klyngen.

XPC-L giver en kommunikationssti mellem systemerne til koordinering af handlinger. Det giver også en meget hurtig låsemotor. Forbindelse til XPC-L sker via en speciel I / O-processor, der fungerer med ekstremt lave latenstider. Låsemanageren i XPC-L indeholder alle de nødvendige funktioner til både fil- og databaselåse. Dette inkluderer blokering af blokering og muligheden for at frigøre låse af mislykkede applikationer.

XPC-L er implementeret med to fysiske servere for at skabe en fuldstændig overflødig konfiguration. Vedligeholdelse, inklusive indlæsning af nye versioner af XPC-L- firmwaren , kan udføres på en af ​​serverne, mens den anden fortsætter med at køre. Fejl, herunder fysisk skade på en server, stopper ikke klyngen, da al information opbevares på begge servere.

Drift og administration

Operationer

OS 2200-operationer er bygget op omkring aktive operatører og en eller flere konsoller. Hver konsol er et terminalvindue, hvoraf en del er reserveret til en fast skærm, der ofte opdateres med resuméoplysninger om aktivitet i systemet.

Resten af ​​konsollen bruges som en rullende visning af begivenheder. Når en meddelelse udsendes, der kræver et operatørsvar, får den et tal fra 0 til 9 og forbliver på displayet, indtil den besvares. Meddelelser om båndmontering ruller med andre meddelelser, men gentages hvert andet minut, indtil båndet er monteret.

Operationer Sentinel bruges til alle OS 2200-operationer. OS 2200-konsoller er simpelthen vinduer i en Operations Sentinel-skærm. Der kan være så mange skærm-pc'er som ønsket. Fjernbetjening er typisk. Operationer Sentinel understøtter et hvilket som helst antal ClearPath-, Windows-, Linux- og UNIX-systemer.

En automatisk handling-meddelelsesdatabase frigives med produktet. Denne database tillader Operations Sentinel at genkende meddelelser. Scripts kan skrives til automatisk at svare på meddelelser, der kræver et svar, skjule uønskede meddelelser, oversætte dem til andre sprog, oprette begivenheder osv. Fuld mørkt rum bruges af nogle klienter. De vil højst have Operations Sentinel-skærme på fjerntliggende steder, der overvåger systemet og opretter alarmer, når bestemte begivenheder opstår.

Administration

Administration af OS 2200-systemer udføres ved hjælp af en lang række værktøjer, der hver især er specialiseret til et bestemt område af systemet. For eksempel er der et værktøj, der bruges til at administrere transaktionsmiljøet, der gør det muligt at installere nye transaktionsprogrammer, specificerer alle de nødvendige oplysninger om dem, ændrer køstrukturen, prioriteter og samtidighedsniveauer osv.

Andre værktøjer er specifikke for sikkerhedsofficeren og tillader oprettelse af brugere, ændring af tilladte privilegier, ændring af systemsikkerhedsindstillinger osv ^{. ,}

De fleste af værktøjerne har en grafisk grænseflade, selvom nogle ikke har det. Alle giver en batch-lagret filgrænseflade, hvor alle handlinger er specificeret i kontrolstrømmen. Dette tillader scripting af alle administrative grænseflader fra enten lokale websteder, måske baseret på tidspunktet på dagen eller andre begivenheder eller fra eksterne websteder. Der kræves unikke privilegier for hvert administrativt område.

Ansøgningsgrupper

Applikationsgrupper er en logisk konstruktion, der består af en forekomst af Universal Data System (UDS), en forekomst af meddelelseskø-undersystemet og nogle sæt transaktioner. Hver ansøgningsgruppe har sit eget revisionsspor. OS 2200 understøtter maksimalt 16 applikationsgrupper i et system.

Begrebet applikationsgruppe svarer til det, der ofte kaldes "en applikation." Det vil sige et sæt programmer og data, der repræsenterer en større enhed af tilsluttet behandling. For eksempel kan en ansøgningsgruppe repræsentere et flyselskabssystem. En anden applikationsgruppe kan repræsentere virksomhedsfinansieringssystemet. Eller applikationsgrupper repræsenterer muligvis forekomster af samme applikations- og datamodeller som i bankfilialer. Det vigtige er, at hver applikationsgruppe har sit eget miljø, sessioner, opsving osv.

Applikationsgrupper kan startes, stoppes og gendannes uafhængigt.

Ansøgningsgrupper har ikke deres egne regnskabs- og planlægningsregler. Transaktioner i flere applikationsgrupper kan dele de samme prioriteter og have sammenflettede prioriteter. Dette gør det muligt for webstedet at kontrollere de relative prioriteter for transaktioner på tværs af hele systemet.

Se også

• Unisys 2200-serie systemarkitektur for information om hardware-arkitekturen.
• Unisys OS 2200 programmeringssprog for information om OS 2200 compilere og linkere.
• Unisys OS 2200-databaser for information om OS 2200-databaser og databasesystem.
• Unisys OS 2200-kommunikation for information om OS 2200-kommunikation.
• Unisys OS 2200 distribueret behandling for information om OS 2200 distribueret behandling.

Andre placeringer af kildemateriale

Den Unisys Historie Nyhedsbrev indeholder artikler om Unisys historie og computere. Ud over alle Unisys historie nyhedsbreve er der links til andre websteder.

De fleste af Unisys historiske arkiver er på Charles Babbage Institute ved University of Minnesota og på Hagley Museum and Library i Delaware. Charles Babbage Institute har arkiverne fra ERA, nogle tidlige Remington Rand arkiver fra Saint Paul, MN og Burroughs arkiverne. Hagley Museum and Library rummer størstedelen af ​​Sperry-arkiverne.

Referencer

Fodnoter