Räkna nyckeldata - Count key data

Räkna nyckeldata ( CKD ) är en direktåtkomstminnesanordning (DASD) dataregistrering format infördes 1964, av IBM med dess IBM System / 360 och fortfarande som emuleras på IBM stordatorer. Det är ett självdefinierande format med varje datapost som representeras av ett räkneområde som identifierar posten och tillhandahåller antalet byte i ett valfritt nyckelområde och ett valfritt dataområde. Detta står i kontrast till enheter som använder fast sektorstorlek eller ett separat formatspår.

CKD (Count key data) hänvisar också till uppsättningen kanalkommandon (kollektivt Channel Command Words, CCWs) som genereras av en IBM-mainframe för körning av ett DASD-undersystem som använder CKD-inspelningsformatet. Den ursprungliga uppsättningen CKD CCW, som introducerades 1964, förbättrades avsevärt och förbättrades till 1990-talet.

CKD-spårformat

Blockdiagram över antalet spårformat för antal nycklar som används på IBM-huvuddatorer som börjar med S / 360-leverans 1965

"Början på ett spår signaleras när indexmarkören (indexpunkten) detekteras. ... Markören känns igen automatiskt av en speciell avkänningsenhet." Efter indexmarkören följer hemadressen , som anger platsen för detta spår på skivan, och innehåller annan styrinformation intern till styrenheten. En lucka med fast längd följer hemadressen. Därefter innehåller varje spår en post 0 (R0), spårbeskrivarens post, som är "utformad för att möjliggöra att hela innehållet i ett spår kan flyttas till alternativa spår om en del av det primära spåret blir defekt." Efter R0 är datablocken åtskilda av luckor.

Principen för CKD-poster är att eftersom datablocklängder kan variera, har varje block ett tillhörande räknefält som identifierar blocket och anger storleken på nyckeln, om den används (användardefinierad upp till 255 byte), och storleken på dataområdet, om det används. Räkningsfältet har identifieringen av posten i cylinderhuvud-postformat, nyckelns längd och datalängden. Nyckeln kan utelämnas eller bestå av en rad tecken.

Varje CKD-post består av ett räknefält, ett valfritt nyckelfält och ett valfritt "användar" -datafält med felkorrigering / detekteringsinformation bifogad till varje fält och luckor som separerar varje fält. På grund av luckorna och annan information är det inspelade utrymmet större än det som krävs för bara räkningsdata, nyckeldata eller användardata. IBM tillhandahåller ett "referenskort" för varje enhet, som kan användas för att beräkna antalet block per spår för olika blockstorlekar och för att optimera blockstorleken för enheten. Senare skrevs program för att göra dessa beräkningar. Eftersom block normalt inte delas mellan spår kan specifikation av fel blockstorlek slösa upp till hälften av varje spår.

Oftast utelämnas nyckeln och posten lokaliseras sekventiellt eller genom direkt adressering av cylinderhuvudet. Om den är närvarande är nyckeln typiskt en kopia av de första n bytes av dataposten (för "oblockerade" poster, eller en kopia av den högsta nyckeln i blocket, för "blockerade" poster), men kan vara vilken data som helst som kommer att användas för att hitta posten, vanligtvis med hjälp av Sök nyckel lika eller Sök nyckel hög eller lika CCW. Nyckeln (och därmed posten) kan lokaliseras via hårdvarukommandon. Sedan introduktionen av IBMs System / 360 1964 har nästan alla IBM DASD: er för stora och mellanliggande system använt datapostformatet för räkningsnyckel.

Fördelarna med count key data record format är:

• Rekordstorleken kan matchas exakt med applikationsstorleken
• CPU- och minneskrav kan minskas genom att använda söknyckelkommandon.
• IBM CKD-delsystem drivs initialt synkront med systemkanalen och kan bearbeta information i luckorna mellan de olika fälten och därigenom uppnå högre prestanda genom att undvika överflödig överföring av information till värden. Både synkrona och asynkrona funktioner stöds i senare delsystem.

Reducerade CPU- och minnespriser och högre enhets- och gränssnittshastigheter har något upphävt fördelarna med CKD, och det bibehålls bara för att IBMs flaggskeppsoperativsystem z / OS inte stöder sektororienterade gränssnitt.

Ursprungligen hade CKD-poster en en-till-en-korrespondens med ett fysiskt spår av en DASD-enhet; emellertid över tid har posterna blivit mer och mer virtualiserade så att det i moderna IBM-mainframes inte längre finns någon direkt överensstämmelse mellan ett CKD-post-ID och en fysisk layout för ett spår.

IBM: s CKD DASD-delsystem

IBM S / 360 & S / 370 In- / utdata för CKD DASD som visar kanal, lagringsstyrenhet och DASD-enhet

Programmering

Åtkomst till specifika klasser av I / O-enheter via en IBM-stordator är under kontroll av Channel Command Words (CCW), varav några är generiska (t.ex. Ingen operation) men många av dem är specifika för typen av I / O-enhet ( Läs t.ex. bakåt för en bandenhet). Gruppen CCW definierad av IBM för DASD faller i fem breda kategorier:

• Kontroll  - kontroll av DASD inklusive sökvägen till den
• Sense  - känsla status för DASD inklusive sökvägen dit; vissa sinnekommandon påverkar styrenhetens och DASD: s status på ett sätt som överensstämmer med ett kontrollkommando, t.ex. RESERVER, RELEASE
• Skriv  - skriv information till styrenheten eller DASD (som kan buffras eller cachas i sökvägen)
• Sök  - jämför information från CPU: n med information lagrad i DASD; kanalen fungerar i skrivläget medan lagringsenheten arbetar i läsläget.
• Läs  - läs information från DASD (som kan buffras eller cachas i sökvägen)

CKD CCW är den specifika uppsättningen CCW som används för att komma åt CKD DASD-delsystem. Detta står i kontrast till fasta blockarkitektur (FBA) CCW: er som används för att komma åt FBA DASD-delsystem.

CKD DASD adresseras som andra in- / utmatningsenheter; för System / 360 och System / 370 DASD adresseras direkt, via kanaler och tillhörande styrenheter (SCU eller Storage Control Unit), initialt med tre hexadecimala siffror, en för kanal och två för styrenhet och enhet, vilket ger adressering för upp till 16 kanaler, för upp till 256 DASD-åtkomstmekanismer / kanal och 4096 DASD-adresser totalt. Moderna IBM-mainframes använder fyra hexidecimala siffror som ett godtyckligt underkanalnummer i en kanalsubsystems undergrupp, vars definition inkluderar de faktiska kanalerna, styrenheterna och anordningen, vilket ger adressering för upp till 65 536 DASD per subsystem för kanalsubsystem. I praktiken begränsade fysiska begränsningar och designbegränsningar för kanalen och styrenheterna det maximala antalet anslutna DASD som kan kopplas till ett system till en mindre mängd än det antal som kan adresseras.

Förpackning

Ursprungligen var det en hög grad av överensstämmelse mellan den logiska synen på DASD-åtkomst och den faktiska hårdvaran, som visas i illustrationen ovan. Tresiffriga etiketter fästes vanligtvis för att identifiera adressen till kanal, styrenhet och enhet.

På lågsystem var kanalen och kontrollenheten ofta fysiskt integrerade men förblev logiskt separata. IBMs New Attachment Strategy som började med 3830 Model 2 1972 separerade fysiskt SCU i två fysiska enheter, en regissör och en controller samtidigt som de logiskt sett var desamma. Styrenheten hanterar CKD-spårformateringen och är förpackad med den första enheten eller enheterna i en enhet av enheter och har ett modellnummer med bokstaven "A" som ett prefix, en "A-enhet" (eller "A-Box") som i 3350 modell A2 som innehåller en styrenhet och två DASD: er. DASD utan styrenhet, det vill säga B-enheter, har ett "B" -prefix i sitt modellnummer.

CKD-delsystem och regissörer erbjöds av IBM och plug-kompatibla konkurrenter fram till minst 1996 (2301 till 3390 modell 9); totalt 22 unika DASD som erbjuds av IBM konfigurerade i minst 35 olika delsystemkonfigurationer . Plug-kompatibel erbjöd många av samma DASD inklusive 4 CKD-delsystem med unika DASD.

Initial CKD-funktionssats

Den ursprungliga funktionsuppsättningen som tillhandahölls av IBM med dess introduktion från 1964 av CKD - ​​spårformat och tillhörande CCW: er inkluderade:.

• Defekt / alternativt spår  - gör det möjligt för ett alternativt spår att ersätta ett defekt spår som är transparent för åtkomstmetoden som används.
• Record overflow  - poster kan överstiga den maximala spellängden för en DASD
• Multitrack-operationer  - specifika CCW kan fortsätta till nästa sekventiella huvud
• Kommandokedjning  - CCW kan kedjas samman för att konstruera komplexa kanalprogram. Mellanrummen i ett CKD-spårformat gav tillräcklig tid mellan kommandona så att all kanal- och SCU-aktivitet som är nödvändig för att slutföra ett kommando kan utföras i mellanrummet mellan lämpliga fält. Sådana program kan söka i en stor mängd information som lagras på en DASD, efter fullbordad återlämnande av endast önskad data och därigenom frigöra CPU-resurser för annan aktivitet. Detta driftsätt synkront till gapet förbättrades senare av ytterligare CCW som möjliggör ett icke-synkront driftsätt .
• Kanalväxling  - en SCU kan delas mellan kanaler - initialt tillhandahölls två kanalbyten och den utvidgades till upp till åtta kanaler i senare SCU. Kanalerna kan vara på samma eller olika CPUS.

En skanningsuppsättning tillhandahölls också men fortsatte inte i framtida CKD-delsystem efter 2314.

Fyrtio CCW: er implementerade funktionssatsen:

Anmärkningar:

O = valfri funktion

S = standardfunktion

MT = multitrack: när stöds fortsätter CCW att fungera på nästa huvuden i följd till slutet av cylindern

‡ = TIC (Transfer In Channel) och andra standardkommandon visas inte.

† = kod samma som MT Off utom som anges

1. Filsökningsfunktion (9 CCW) endast tillgänglig på 2841 för 2302, 2311 och 2321; de var inte tillgängliga på efterföljande DASD-regulatorer för DASD senare än 2314.

2. Antal är antalet byte i sökargumentet, inklusive maskbyte

CCW: erna kördes ursprungligen av två typer av SCU kopplade till systemets snabba väljarkanaler . Den 2820 SCU kontrollerade 2301 Drum medan 2841 SCU-kontrollerade kombinationer av 2302 Disk Storage , 2311 Disk Drive, 2321 Data Cell och / eller 7320 Drum Lagring. IBM ersatte snabbt 7320 med den snabbare och större 2303.

Därefter implementerades uppsättningen på 2314-familjen av lagringskontroller och en integrerad bilaga till System 370 Model 25 .

Följande exempel på ett kanalprogram läser en skivpost identifierad av ett nyckelfält. Spåret som innehåller posten och önskat nyckelvärde är känt. SCU kommer att söka i spåret för att hitta den begärda posten. I detta exempel <> anger att kanalprogrammet innehåller lagringsadressen för det angivna fältet.

  SEEK             <cylinder/head number>
  SEARCH KEY EQUAL <key value>
  TIC              *-8 Back to search if not equal
  READ DATA        <buffer> 

TIC (överföring i kanal) kommer att få kanalprogrammet att förgrena sig till SEARCH-kommandot tills en post med en matchande tangent (eller slutet av spåret) påträffas. När en post med en matchande nyckel hittas kommer SCU att inkludera Status Modifier i kanalstatus, vilket får kanalen att hoppa över TIC CCW; sålunda kommer inte kanalprogrammet att förgrenas och kanalen kommer att utföra READ-kommandot.

Blockera Multiplexer Channel Enhancements

Den blocket multiplexorn kanal infördes med början i 1971 på någon hög slutet System / 360-system tillsammans med 2835 Styrenhet och tillhörande 2305 DASD, denna kanal var sedan standard på IBM System / 370 och efterföljande behandlingar; i motsats till den tidigare väljarkanalen erbjöd den prestandaförbättringar för höghastighetsenheter som DASD, inklusive:

Flera begäranden

Tillåtna flera kanalprogram att vara aktiva samtidigt i anläggningen i motsats till endast ett med en väljarkanal. Det faktiska antalet underkanaler som tillhandahålls beror på systemmodellen och dess konfiguration. Ibland beskrivs som frånkopplad kommandokedjning, kunde styrenheten kopplas bort vid olika tidpunkter under en kedjig uppsättning CCW, till exempel frånkoppling för en Seek CCW, vilket frigör kanalen för en annan underkanal.

Kommando försök igen

Kanalen och lagringskontrollen under vissa förhållanden kan samverka för att få en CCW att försökas igen utan ett I / O-avbrott. Denna procedur initieras av lagringskontrollen och används för att återställa från korrigerbara fel.

Rotationspositionssensor

Rotationspositionssensing (RPS) implementerades med två nya CCW: er, SET SECTOR och READ SECTOR gjorde det möjligt för kanalen att fördröja kommandokedjning tills skivan roterade till en angiven vinklad spårposition. RPS tillåter kanalfrånkoppling under större delen av rotationsfördröjningsperioden och bidrar således till ökat kanalutnyttjande. Styrenheten implementerar RPS genom att dela upp varje spår i lika vinkelsegment.

Exempel på kanalprogram

Följande exempel på kanalprogram formaterar ett spår med en R0 och tre CKD-poster.

  SEEK             <cylinder/head number>
  SET FILE MASK    <allow write operations>
  SET SECTOR       <sector number=0>
  WRITE R0         <cylinder/head/R0, key length=0, data length=6>
  WRITE CKD        <cylinder/head/R1, key length, data length>
  WRITE CKD        <cylinder/head/R2, key length, data length>
  WRITE CKD        <cylinder/head/R3, key length, data length>  

I detta exempel överensstämmer Record 0 med IBMs programmeringsstandarder. Med en blockmultiplexerkanal är kanalen ledig under den tid som DASD söker och igen medan skivan roterar till början av spåret. En väljarkanal skulle vara upptagen under hela detta samplingsprogram.

Hopp över defekter

Med defekthoppning kan data skrivas före och efter en av fler ytdefekter som gör att hela spåret kan användas förutom den del som har defekten. Detta eliminerar också den tid som tidigare krävdes för att söka efter ett alternativt spår. Endast ett begränsat antal defekter kunde hoppas över så alternativa spår förblev stödda för de spår med överdrivna defekter.

Hoppning av defekter infördes 1974 med 3340 ansluten via 3830 Model 2 Storage Control Unit eller integrerade tillbehör på små system. Defekthoppning var i huvudsak en enda fabriksfunktion fram till 1981 när CCW för hantering tillsammans med tillhörande verktyg släpptes.

Dynamiska stigar

Först introducerad med 3380 DASD på 3880 Storage Control Unit 1981 inkluderades funktionen i de senare CKD DASD-delsystemen. Funktionen för val av dynamisk väg styr driften av de två styrenheterna, inklusive samtidig dataöverföring över de två banorna. När det stöds av operativsystemet kan varje styrenhet fungera som en alternativ sökväg om den andra styrenheten inte är tillgänglig.

Ytterligare tre kommandon, Set Path Group ID, Sense Path Group ID och Suspend Multipath Reconnection, används för att stödja bifogning av 3380-modellerna med två styrenheter i strängens huvud.

Kommandot Set Path Group ID, med funktionen DPS (Dynamic Path Selection) ger större flexibilitet i operationer på reserverade enheter. När en väggrupp för en enhet har upprättats kan den nås över vilken sökväg som helst som är medlem i gruppen som den är reserverad till. Dessutom kommer 370-XA-system som ställer in flervägsmodbiten i funktionsstyrbiten (byte 0) till en 1, blockmultiplexåteranslutningar kommer att inträffa på den första tillgängliga sökvägen som är medlem i gruppen över vilken kanalprogrammet var initierad (oavsett enhetens bokningstillstånd).

Om den styrenhet som anges i I / O-adressen är upptagen eller inaktiverad tillåter det dynamiska sökvalet att en alternativ väg till enheten kan upprättas via en annan lagringsdirektör och den andra styrenheten i modellen AA.

Icke-synkron drift

Före 1981-introduktionen av 3880-regissören var CKD-poster synkroniserade, alla aktiviteter krävde att en CCW avslutades och nästa initierades i luckorna mellan CKD-fälten. Gapstorleken satte begränsningar på kabellängden men gav mycket höga prestanda eftersom komplexa kedjor av CCW kunde utföras av delsystemet i realtid utan användning av CPU-minne eller cykler.

Icke-synkron operation som tillhandahålls av den utvidgade CKD ("ECKD") uppsättningen CCW: er avlägsnade tidsbegränsningen för gap. De ytterligare fem ECKD-CCW: erna är Definiera omfattning, lokalisera post, skriva uppdateringsdata, skriva uppdateringsnyckel och data och skriv CKD nästa spår.

Vid icke-synkron drift synkroniseras inte överföringen av data mellan kanalen och lagringskontrollen med överföringen av data mellan lagringskontrollen och enheten. Kanalprogram kan exekveras så att kanal- och lagringskontrollaktiviteter som krävs för att avsluta exekvering av ett kommando och gå vidare till nästa inte behöver inträffa under mellanregistreringsgapet mellan två intilliggande fält. En mellanbuffert i lagringskontrollen möjliggör oberoende operationer mellan kanalen och enheten. En stor fördel med ECKD är långa kablar; beroende på applikation kan det förbättra prestandan.

ECKD CCW stöds i alla efterföljande CKD-delsystem.

I det här exemplet läses det icke-synkrona kanalprogrammet poster R1 och R2 från spår X'0E 'i cylinder X'007F'. Båda posterna har en nyckellängd på 8 och en datalängd på X'64 '(100 ₁₀ ) byte.

  Define Extent       <extent= X'007F 0000' through track X'0081 000E'>
  Locate Record       <cylinder = X'007F', head = X'000E'
  Read Key and Data   <key record = X'001038'>
  Read Data           <record = X'001108'>

Cachning

Caching introducerades först i DASD CKD-delsystem av Memorex (1978) och StorageTek (1981) introducerades senare i slutet av 1981 av IBM på 3880 Model 13 för modeller av 3380 med dynamisk pathing.

Cachen hanteras dynamiskt av en algoritm. högaktivitetsdata nås från högpresterande cache och data med låg aktivitet nås från billigare DASD-lagring. Ett stort minne i regissören, cachen, är uppdelad i spårplatser som lagrar data från 3380 spår. Ett mindre område är en katalog som innehåller poster som gör att data kan lokaliseras i cachen.

Cacher tillhandahölls också på senare införda lagringskontroller.

Andra tillägg

Med tiden implementerades ett antal sökvägskontroll, diagnostik och / eller felåterställning CCW på en eller flera lagringskontroller. Till exempel:

• Ovillkorlig reserv tillät släppa en enhet reserverad till en annan kanal och reservera enheten till kanalen som utfärdar kommandot.
• Läs flera nyckeldata kan mer effektivt läsa hela spår och möjliggöra effektivare säkerhetskopior.

Beyond System / 370

Minskade CPU- och minnespriser och högre enhets- och gränssnittshastigheter har något upphävt fördelarna med CKD, och supporten fortsätter av IBM till detta datum eftersom dess flaggskeppsoperativsystem z / OS fortsätter att använda CKD CCW för många funktioner.

Ursprungligen hade CKD-poster en en-till-en-korrespondens med ett fysiskt spår av en DASD-enhet; men med tiden har posterna blivit mer och mer virtualiserade så att det i en modern IBM-mainframe inte längre finns en direkt överensstämmelse mellan ett CKD-post-ID och en fysisk layout för ett spår. En IBM-mainframe konstruerar CKD-spårbilder i minnet och kör ECKD- och CKD-kanalprogrammen mot bilden. För att överbrygga mellan de ursprungliga skivorna med fast blockstorlek och ECKD / CKD-inspelningsformatet med variabel längd mappas CKD-spårbilderna i minnet på en serie fasta block som är lämpliga för överföring till och från ett FBA-diskundersystem.

Av de 83 CKD-CCW: erna som är implementerade för System / 360 och System / 370-kanalerna emuleras 56 på System / 390 och senare system.

Se även

• Blockera (datalagring)
• Datauppsättning (IBM mainframe)
• FBA (fixed -block architecture )
• Record (datavetenskap)
• Spår (hårddisk)
• Volym Innehållsförteckning (VTOC)

Anteckningar

Referenser

Vidare läsning

• IBM Data Processing Division (februari 1974). Introduktion till IBM Direct-Access Storage Devices and Organization Methods (PDF) (tionde upplagan). White Plains: Internationella affärsmaskiner. OCLC   8063006 . GC20-1649-9 . Hämtad 6 augusti 2014 .
• Utveckling av 360/370 arkitektur - A Plain Man's View PJ Gribbin, 10 februari 1989, kapitel 8–10.