Enhetskontrollblock
I IBMs stordatoroperativsystem OS/360 och dess efterföljare är ett enhetskontrollblock ( UCB ) en minnesstruktur , eller ett kontrollblock , som beskriver varje enskild ingångs-/utgångsenhet ( enhet ) eller en exponering (alias) för operativsystemet. Vissa data inom UCB instruerar också Input/Output Supervisor ( IOS ) att använda vissa slutna subrutiner utöver normal IOS-behandling för ytterligare fysisk enhetskontroll.
Vissa andra operativsystem har liknande strukturer.
Översikt
Under initial programladdning (IPL) av nuvarande MVS- system läser Nucleus Initialization Program (NIP) nödvändig information från I/O Definition File (IODF) och använder den för att bygga UCB:erna. UCB:erna lagras i systemägt minne, i Extended System Queue Area ( ESQA ). När IPL har slutförts ägs UCB:er av Input/Output Support. Några av de data som lagras i UCB är: enhetstyp (t.ex. disk, band, skrivare, terminal), enhetens adress (t.ex. 1002), underkanalidentifierare och enhetsnummer, kanalsökvägs-ID (CHPID) som definierar vägen till enheten, för vissa enheter volymens serienummer (VOLSER) och en stor mängd annan information, inklusive OS Job Management-data.
Även om innehållet i UCB har förändrats i takt med att MVS utvecklades, har konceptet inte gjort det. Det är en representation till operativsystemet för en extern enhet. Inuti varje UCB finns UCBIOQ-pekaren till det aktuella IOS Queue Element (IOQ), UCBIOQF och UCBIOQL-pekare till en kö av IOQ:er (IOQs) och ett underkanalnummer för underkanalsidentifieringsordet som används i startunderkanalsinstruktionen (SSCH) för att starta ett kanalprogram (kedja av kanalkommandoord (CCW)).
UCB utvecklades till att vara ett ankare för att hålla information och stater om enheten. UCB har för närvarande fem områden som används för ett externt gränssnitt: Device Class Extension, UCB Common Extension, UCB Prefix Stub, UCB Common Segment och UCB Device Dependent Segment. Övriga områden är endast för internt bruk. Denna information kan läsas och användas för att fastställa information om enheten.
I de tidigaste implementeringarna av OS/360 sattes UCB:erna (fundament och tillägg) samman under SYSGEN och var placerade inom de första 64 KB av systemområdet, eftersom I/O-enhetsuppslagstabellen bestod av 16-bitars adresser. Efterföljande förbättringar gjorde det möjligt för tilläggen att ligga över 64-kilobyte (65 536 byte) linjen, vilket sparade utrymme för ytterligare UCB-fundament under 64-kilobyte-linjen och även därigenom bevara arkitekturen för UCB-uppslagstabellen (konvertera en CUu till en UCB-fundament adress). Så småningom kunde en installation välja att placera UCB:er ovanför 16 MiB-linjen, även om operativsystemet i en process som kallas shadowing UCB skapar en tillfällig lokal kopia av UCB:n när en fil allokeras utan XTIOT -alternativet.
Hantera parallella I/O-operationer
UCB introducerades på 1960-talet med OS/360. Då var en enhet som adresserades av UCB vanligtvis en hårddisk med rörligt huvud eller en bandenhet , utan intern cache . Utan den överträffades enheten vanligtvis kraftigt av stordatorns kanalprocessor . Därför fanns det ingen anledning att utföra flera in-/utgångsoperationer till den samtidigt, eftersom dessa skulle vara omöjliga för en enhet att fysiskt hantera. 1968 IBM skivorna 2305-1 och 2305-2 med fast huvud, som hade rotationspositionsavkänning (RPS) och åtta exponeringar (aliasadresser) per disk; OS/360-stödet gav en UCB per exponering för att tillåta flera samtidiga kanalprogram. På liknande sätt krävde senare system härledda från OS/360 en extra UCB för varje tilldelad virtuell volym i ett IBM 3850 Mass Storage System (MSS), och för varje exponering på en 3880-11 och dess efterföljare.
Parallella åtkomstvolymer (PAV)
Eftersom endast en uppsättning kanalkommandon eller I/O kunde köras på en gång. Detta var bra på 1960-talet när processorerna var långsamma och I/O bara kunde bearbetas så snabbt som processorerna kunde bearbeta det. När systemen mognade och CPU-hastigheten avsevärt överträffade I/O-ingångskapaciteten, blev åtkomsten till enheten som serialiserades på UCB-nivå en allvarlig flaskhals.
Parallel Access Volume ( PAV ) tillåter UCB:er att klona sig själva för att tillåta flera I/O att köras samtidigt. Med lämpligt stöd av DASD-hårdvaran ger PAV stöd för mer än en I/O till en enda enhet åt gången. För att upprätthålla bakåtkompatibilitet serialiseras verksamheten fortfarande under UCB-nivån. Men PAV tillåter definitionen av ytterligare UCB:er till samma logiska enhet, var och en med en extra aliasadress . Till exempel kan en DASD-enhet vid basadress 1000 ha aliasadresser 1001, 1002 och 1003. Var och en av dessa aliasadresser skulle ha sin egen UCB. Eftersom det nu finns fyra UCB till en enda enhet, är fyra samtidiga I/O möjliga. Skrivningar i samma utsträckning, ett område på disken som är tilldelat ett angränsande område av en fil, serialiseras fortfarande, men andra läsningar och skrivningar sker samtidigt. Den första versionen av PAV tilldelar diskstyrenheten en PAV till en UCB. I den andra versionen av PAV-bearbetning Workload Manager (WLM) en PAV till nya UCB:er då och då. I den tredje versionen av PAV-bearbetning, med IBM DS8000-serien , använder varje I/O vilken tillgänglig PAV som helst med den UCB den behöver.
Nettoeffekten av PAV är att minska IOSQ-tidskomponenten av diskens svarstid, ofta till noll. Från och med 2007 är de enda begränsningarna för PAV antalet aliasadresser, 255 per basadress och totalt antal enheter per logisk styrenhet, 256 räknande bas plus alias.
Statiska kontra dynamiska PAV
Det finns två typer av PAV-aliasadresser, statiska och dynamiska. En statisk aliasadress definieras, i både DASD-hårdvara och z/OS, för att referera till en specifik enkel basadress. Dynamisk innebär att antalet aliasadresser som tilldelats en specifik basadress fluktuerar beroende på behov. Hanteringen av dessa dynamiska alias överlåts till WLM, som körs i målläge (vilket alltid är fallet med stödda nivåer av z/OS ). På de flesta system som implementerar PAV finns det vanligtvis en blandning av båda PAV-typerna. Ett, kanske två, statiska alias definieras för varje bas-UCB och ett gäng dynamiska alias definieras för WLM att hantera som den vill.
När WLM övervakar I/O-aktiviteten i systemet avgör WLM om en högviktig arbetsbelastning är försenad på grund av hög konflikt för en specifik PAV-aktiverad enhet. Specifikt för en diskenhet måste bas och alias UCB:er vara otillräckliga för att eliminera IOS-kötid. Om det finns hög konflikt, och WLM uppskattar att det skulle hjälpa arbetsbelastningen att nå sina mål lättare, kommer den att försöka flytta alias från en annan basadress till den här enheten.
Ett annat problem kan vara att vissa prestationsmål inte uppfylls, vilket specificeras av WLM-serviceklasser. WLM kommer sedan att leta efter alias UCB:er som bearbetar arbete för mindre viktiga uppgifter (serviceklass), och vid behov kommer WLM att återassociera alias till basadresserna som är associerade med det viktigare arbetet.
HyperPAVs
WLM:s åtgärder för att flytta alias från en diskenhet till en annan tar några sekunder innan effekterna syns. För många situationer är detta inte tillräckligt snabbt. HyperPAV: er är betydligt mer lyhörda eftersom de skaffar en UCB från en pool under varaktigheten av en enda I/O-operation, innan den returneras till poolen. Således krävs ett mindre antal UCB:er för att betjäna samma arbetsbelastning, jämfört med Dynamic PAVs. Det finns ingen fördröjning att vänta på att WLM ska reagera.
I andra operativsystem
Digitals VMS- operativsystem använder en identiskt namngiven struktur, UCB, för liknande ändamål. En UCB skapas för varje I/O-enhet. Data i UCB inkluderar enhetens enhetsnummer (en del av enhetsnamnet) och en listhead till vilken väntande I/O-förfrågningar kan ställas i kö. UCB:n kan ha en enhetsdrivrutindefinierad tillägg där föraren kan behålla förardefinierade data som instansieras för varje enhet.