DataMuseum.dk

Presents historical artifacts from the history of:

RC4000/8000/9000

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about RC4000/8000/9000

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download

⟦053e8596e⟧ TextFile

    Length: 33024 (0x8100)
    Types: TextFile
    Names: »afsnit3«

Derivation

└─⟦667bb35d6⟧ Bits:30007480 RC8000 Dump tape fra HCØ.
    └─⟦4334b4c0b⟧ 
        └─⟦5f6008f5a⟧ »speciale« 
            └─⟦this⟧ 

TextFile

mode list.yes
vko2=set 50 disc3
afs3=set 50 disc3
scope user afs3
scope user vko2
vko11=set 20 disc3
afs3=typeset check.no hyphen.c.vko11  proof.vko2 machine.diablo
*se $* $pl ,30,235,,10$
$lw 160$$ld18$
$sb ^,6$
$pn 5,17$
$rh 1,SYSTEMBESKRIVELSE$
$ps 0$
$ns 1,4,_«bs»3_«bs»._«bs»S_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»b_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e_«bs».$
$np$
Nedenstående afsnit indeholder en beskrivelse af et oplysningssystem
(fremover forkortet OP-system) hos KTAS.
Systemet er udviklet af Jydsk Telefon. Det er grundlaget
for besvarelser af  spørgsmål,
 som  stilles til telefonnummeroplysningen.
$nl$
Spørgsmålene kan opdeles i 2 kategorier:
$nl$$lm15$
1.Hvilket tlfnr. har en given abonnent ?
(Betegnes fremover søgeforespørgsel)
$nl$
2.Hvilken abonnent har et givet tlfnr. ?
(Betegnes tlfnr.forespørgsel)
$nl$$lm 0$
$np15$
Disse spørgsmål (forespørgsler) kan bevirke, at der  skal stilles
supplerende spørgsmål for at  fremskaffe  den ønskede information.
De vigtigste typer af supplerende spørgsmål er en bladning og afdækning
af hemmeligt tlfnr.
Hvis en forespørgsel resulterer i mere end 21 forslag,  og dermed
fylder mere end et skærmbillede, er det muligt at bladre i skærmbillederne, og
dette betegnes en bladning.
 Hvis der spørges på en abonnent med hemmeligt tlfnr. vil
dette på skærmen blive 
skrevet som "HEMM.NR". Denne tekst kan afdækkes
( dvs. tlfnr. kommer frem på skærmen ) ved en speciel ordre.
$np 15$
OP-systemet er implementeret på maskinel fra Regnecentralen.
$np$
Konfigurationen for OP-systemet ændres efter tidspunktet i døgnet på
grund af en meget skiftende belastning. I en hårdt belastet
time findes der til systemet koblet 3 RC8000, 2 RC3500 af typen FP,
2 RC3500 af typen NP og omkring 15 RC3500 af typen TP. Det er antallet
af TP'er og RC8000 der formindskes, når belastningen af OP-systemet
er meget lille. Figur 3.1 viser, hvorledes principperne
i kommunikationen mellem disse maskiner foregår.
$ps0$
$sj$
                    figur 3.1
$rj$
$ps0$
 Forkortelser står
for følgende:
$sj$

        FP = Front-end Processor

        NP = Network Processor

        TP = Terminal Processor
$rj$$nl$
Terminalerne tilknyttet
 systemet er koblet til RC3500 betegnet TP.
Til hver TP maksimalt er koblet 23 terminaler. 
Til hele OP-systemet er maksimalt koblet ca. 130 terminaler.
Hver RC8000 har 3 associerede diske og hver RC8000 behandler 
 forespørgsler.
$np 15$
Når der ringes ind til tlfnr.oplysningen bliver en forespørgsel indtastet
på en skærm.
Når forespørgslen er afsendt fra skærmen modtages den af TP.
 Denne RC3500 omsætter den
til en repræsentation, som kan forstås af resten af systemet. RC3500 sender derefter
transaktionen videre ved hjælp af en kommunikationslinie på figuren markeret 1 eller 2.
$np 15$
Forespørgslen sendes  ad linie 1, hvis dette er muligt ellers
sendes den ad linie 2. Kommunikationslinien mellem TP'en og de
RC3500'er der på figuren er betegnet NP er en 48 K bps (bit pr. sekund)
datatransmissionslinie. Transaktionen modtages af en af de 2 RC3500
betegnet NP  afhængig af, hvilken linie den er sendt
af.  NP  modtager og videresender forespørgslen
ud fra en speciel strategi til en af de to RC3500 betegnet FP. (Front-end
Processor). Strategien for, hvordan forespørgslerne fordeles mellem
de to RC3500 betegnet FP afhænger dels af hvor mange RC8000 der er i
funktion og dels af deres belastning.
$np 15$
Transmissionslinien mellem NP og FP er en hurtig datatransmissionslinie. Skillelinien
mellem NP og FP udgør  et skel mellem hvilke former for
transmissionssystem, der benyttes. Transmissionssystemet der anvendes her til dette
skel er CATS35( Communication And Terminal System implementet on
RC3500. Findes beskrevet i RCSL.52-A188). Fra RC3500 på figuren betegnet FP benyttes
et specielt   udviklet system,
der kun anvendes ved OP-systemet.
 FP'ens opgave er at transformere
forespørgslen så den kan modtages af RC8000. Derefter videresendes
transaktionen  og modtages i RC8000 af en terminaldriver.
$np 15$
Hvordan hele OP-systemet er implementeret i de 3 typer RC3500 er
ikke beskrevet i denne opgave. Begrundelsen for dette findes i afsnit 6,
og er i korthed, at denne del af systemet anvender forholdsvis lidt tid til
at behandle en forespørgsel.
Derimod findes i nedenstående en beskrivelse af, hvordan OP-systemet
er implementeret i RC8000.
Normalt vil der i hårdt belastede timer være 3 RC8000 koblet til OP-systemet.
Som angivet sker fordelingen af forespørgsler mellem disse 3 maskiner
ved hjælp af de 2 RC3500 på figuren betegnet FP. Det er tilstræbt at foretage
denne fordeling så hver RC8000 modtager ligemange transaktioner. 
Da fordelingen sker ved hjælp af 2 RC3500 er det imidlertid ikke helt simpelt
at foretage en ligelig fordeling. 
$np$
Dette kan yderligere anskueliggøres ved følgende argument. Når en forespørgsel
afsendes fra en skærm modtages den af en RC3500. Denne sender transaktionen
videre af linie 1 i langt de fleste tilfælde.
Dvs. at antallet af transaktioner den ene NP modtager afhænger af,
hvor mange terminaler, der er koblet til de RC3500 der kommunikerer med denne.
Det er derfor ikke sikkert, at de to NP'er modtager lige mange forespørgsler.
I de to FP'er er det derfor ret vanskeligt at fordele transaktionerne
ligeligt  mellem 3 RC8000. Fra KTAS's side menes, at fordelingen 
sker i forholdet 40,30 og 30 % af transaktioner til hver RC8000.
På baggrund af denne ulige fordeling er det ved vurderingen nødvendigt
at betragte hver RC8000 for sig.

$np 15$
I nedenstående anvendes en del termer knyttet til en RC8000. Disse skal
kort forklares her. En dyberegående forklaring kan findes i Brin73.
$nl2$
_«bs»I_«bs»n_«bs»t_«bs»e_«bs»r_«bs»n__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s
$nl$
Defineres som udførelsen af et eller flere afbrydelige programmer i et 
givent lagerområde. Den er identificeret ved et entydigt navn.
$nl2$
_«bs»E_«bs»k_«bs»s_«bs»t_«bs»e_«bs»r_«bs»n__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s
$nl$
Refererer til input/output til en given enhed.
Dette betyder, at når en enhed er navngivet, kan en intern proces kommunikere
med enheden gennem en ekstern proces uden at vide specielle karakteristika
om enheden.
$nl2$
_«bs»M_«bs»o_«bs»n_«bs»i_«bs»t_«bs»o_«bs»r
$nl$
Et program der aktiveres ved interrupts. Monitoren befinder sig permanent i lageret.
Monitoren kan opfattes som en programudvidelse af maskinelstrukturen. Derved
gøres maskinen mere attraktiv til multiprogrammering.
Monitorens funktion er:
$lm20$$nl2$
1.at have en beskrivelse af alle processer.
$nl2$
2.at dele maskinen mellem interne og eksterne processer.
$nl$
3.at kunne oprette og nedlægge andre processer,
 
samt at kunne kommunikere mellem processer. Dette er implementeret ved,
at nogle procedure i monitoren kaldes.
$lm0$
$nl2$
_«bs»M_«bs»e_«bs»s_«bs»s_«bs»a_«bs»g_«bs»e__«bs»b_«bs»u_«bs»f_«bs»f_«bs»e_«bs»r
$nl$
En message buffer anvendes til at sende meddelelser fra en proces til en anden.
Det angives eksempelvis i bufferen, at et segment på pladelageret ønskes
overført. Bufferen er  8 ord, der  bruges til en meddelelse.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»R_«bs»C_«bs»8_«bs»0_«bs»0_«bs»0_«bs»'_«bs»d_«bs»e_«bs»l_«bs»e_«bs»n__«bs»a_«bs»f__«bs»O_«bs»P_«bs»-_«bs»s_«bs»y_«bs»s_«bs»t_«bs»e_«bs»m_«bs»e_«bs»t_«bs».$
$np 15$
Nedenstående figur viser, hvordan OP-systemet ser ud i RC8000.
Derefter  følger en  beskrivelse af de enkelte processer,
efterfulgt af en redegørelse for, hvordan de 5 processer kommunikerer
indbyrdes.
$ps0$

$ps0$
$np 15$
Figuren viser udover de 5 interne processer, nogle
eksterne processer, der fungerer som
drivere til ydre enheder såsom pladelagre og terminaler.
De sorte pile på figuren angiver, at der sker overførsel af data.
Data er information om abonnenter i en intern repræsentation i form af kommunikationsblokke.
Disse kommunikationsblokke udskrives, når forspørgslen er færdigbehandlet  i en fil
kaldet logfilen på systemdisken.
De 5 processer ligger fast i lageret. Overførslen af data foregår ved,
at en kommunikationsblok kopieres fra en proces til   en anden proces.
$np$
En hvid pil svarer til, at der sker overførsel af meddelelser.
En meddelelse er eksempelvis at bede monitoren om at kopiere data.
$np$
De 5 interne processer beskrives nu mere udførligt. Det skal her anføres,
at de vigtigste og mest lagerforbrugende er søge- og opslagsprocessen. Det er
i disse fremskaffelsen af information om telefonabonnenter sker.
De 5 processer er alle programmeret i ALGOL.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»1_«bs»._«bs»O_«bs»P_«bs»-_«bs»p_«bs»a_«bs»r_«bs»e_«bs»n_«bs»t_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».$
$np 15$
Processens formål er at oprette og 
nedlægge de øvrige RC8000 processer i forespørgselssystemet,
samt at styre disse.
$np 15$
OP-parent processen anvendes, når en operatør ønsker at starte de andre
 processer. Opstart af systemet i RC8000 foregår ved at operatøren
sender en meddelelse til parent-processen,
 og  denne proces starter så  processerne op.
Denne operation kaldes at opgradere systemet.
$np 15$
Udover at starte de øvrige processer benyttes parent-processen til at 
 degradere OP-systemet.
Ved en degradering af OP-systemet vil kun bladningsforespørgsler blive sendt
til inputprocessen.
Dette benyttes, når systemet skal lukkes ned. Her 
er det nødvendigt at degrade systemet, for derefter at vente
et vist stykke tid, så alle forespørgsler i systemet
er færdigbehandlet.
Først når alle forespørgsler er færdigbehandlet kan systemet stoppes.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»2_«bs»._«bs»I_«bs»n_«bs»p_«bs»u_«bs»t_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».$
$np 15$
Inputprocessen modtager inputlinier fra terminaldriveren i RC8000
kaldet "terminput". Hver inputlinie, som modtages, er forsynet med 
kontrolinformation fra RC3500.
Denne kontrolinformation kan eksempelvis angive, at forespørgslen er en bladning.
Inputlinien (indeholdende en forespørgsel) analyseres. Dette
resulterer i, at transaktionen videresendes til enten søge-,
opslags- eller outputprocessen.
$nl$
$nl$
_«bs»P_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs»s__«bs»f_«bs»o_«bs»r_«bs»l_«bs»ø_«bs»b__«bs»k_«bs»a_«bs»n__«bs»d_«bs»e_«bs»t_«bs»a_«bs»l_«bs»j_«bs»e_«bs»r_«bs»e_«bs»t__«bs»b_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»s__«bs»p_«bs»å__«bs»f_«bs»ø_«bs»l_«bs»g_«bs»e_«bs»n_«bs»d_«bs»e__«bs»m_«bs»å_«bs»d_«bs»e_«bs»:
$np$
Efter en analyse af  kontrolinformationen, gennemlæses linien tegn for
tegn. Derefter ændres inputlinien til en intern repræsentation, der
benyttes af de andre processer.
 En forespørgsel
 kan enten være en søge- eller
en tlfnr.forespørgsel. En søgeforespørgsel  indeholder
et eller flere felter efterfulgt af et feltindhold.
 De vigtigste felter (til hvert felt er angivet et eksempel på indholdet) er følgende:
$ps0$
$sj$
      _«bs»F_«bs»E_«bs»L_«bs»T_______«bs»I_«bs»N_«bs»D_«bs»H_«bs»O_«bs»L_«bs»D________«bs»B_«bs»E_«bs»T_«bs»Y_«bs»D_«bs»N_«bs»I_«bs»N_«bs»G


      *b        Hellerup      by

      *n        Petersen      efternavn
 
      *f        Peter         fornavn

      *g        Stolpevej     gade
 
      *s        Arkitekt      stilling

      *h        14            husnr
$rj$
$np15$
En søgeforespørgsel skal indeholde feltet *b svarende
til et bynavn.
 Dette er eneste
felt, der altid skal forefindes,
derudover 
 skal mindst et andet felt findes i søgeforespørgslen. Hvad der
her er betegnet felter sammenholdt med feltindholdet,
 vil i det følgende også betegnes et søgekriterie.
$np 15$
Den anden type   tlfnr.forespørgsler
indeholder følgende felt:
$nl$
$sj$
            *t1753029 (et tlfnr)

$rj$
$np$
Udover disse to forespørgselstyper kan det forekomme, at inputlinien
 henføres til en kategori, der betegnes ukendt linietype eller fejllinie.
$np 15$
Til disse forespørgselstyper bemærkes, at inputprocessen foretager følgende
afhængig af linietypen:
$nl$$nl$
_«bs»1_«bs»._«bs»S_«bs»ø_«bs»g_«bs»e_«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l_«bs»s_«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs».
$np$
Søgelinien kontrolleres , herunder registreres eventuelle
alvorlige
fejl f.eks. fornavn uden efternavn, husnr. uden gade.
En nøjere undersøgelse af en søgeforspørgsel sker først i søgeprocessen.
Hvis linien er korrekt, sættes et låsefelt i linien. Findes et låsefelt
allerede i inputlinien (dette indikerer f.eks. en bladning),
så sendes forespørgslen direkte til outputprocessen, ellers sendes den til
søgeprocessen.
Et låsefelt fremkommer i en inputlinie,  inden inputprocessen behandler forespørgslen,
  ved at der trykkes
på en speciel knap på terminalen.
$nl$$nl$
_«bs»2_«bs»._«bs»T_«bs»e_«bs»l_«bs»e_«bs»f_«bs»o_«bs»n_«bs»n_«bs»u_«bs»m_«bs»m_«bs»e_«bs»r_«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l_«bs».
$np$
I en sådan linie skal  *t (tlfnr.)
forekomme.
Linien kontroleres, herunder kan fejl registreres,
f.eks. antal cifre i et tlfnr. Hvis linien er korrekt
sendes inputlinien til opslagsprocessen.
$nl$$nl$
_«bs»3_«bs»._«bs»U_«bs»k_«bs»e_«bs»n_«bs»d_«bs»t__«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs»t_«bs»y_«bs»p_«bs»e__«bs»e_«bs»l_«bs»l_«bs»e_«bs»r__«bs»f_«bs»e_«bs»j_«bs»l_«bs»l_«bs»i_«bs»n_«bs»i_«bs»e_«bs».
$np$
Der dannes en fejludskrift svarende til registrerede fejl og denne sendes
til outputprocessen.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»3_«bs»._«bs»S_«bs»ø_«bs»g_«bs»e_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».$
$np 15$
Denne proces modtager forespørgsler fra inputprocessen. 
Ud fra en forespørgsel er dens opgave at levere de mulige "kandidater" til opslagsprocessen.
En "kandidat" til en forespørgsel er et muligt svar.
Til søgeprocessen er koblet et pladelager, hvorpå der findes en  indekssekventiel
fil. En forespørgsel skal som omtalt under inputprocessen altid indeholde et stednavn,
hvilket kan opfattes som første indeks. Ud fra dette
findes et vist antal "kandidater". Hvis der er andre søgekriterier svarer dette til at søgeprocessen
ved hjælp af disse (de kan opfattes som underindices) indskrænker
antallet af mulige "kandidater". En "kandidat" til en forespørgsel er fra
søgeprocessens synspunkt  en pointer til en fil, der kaldes "abonnent-filen".
Abonnentfilen indeholder information om de enkelte telefonabonnenter.
I opslagsprocessen fremfindes ud fra disse pointere den ønskede information om abonnenterne.
$np15$
Antallet af pladelagertilgange pr. søgeforespørgsel  i søgeprocessen afhænger af
antallet af søgekriterier.
$np15$
Hvis søgeprocessen ikke finder kandidater, sendes en fejludskrift til outputprocessen. 
Dette er også tilfældet, hvis der findes mere end 63 kandidater, hvilket
svarer til 3 skærmbilleder.
Da det ikke er muligt at måle, hvor mange pladelagertilgange
der anvendes i søgeprocessen, angives her ud fra en artikel i Data (se bilag 1),
hvorledes antallet af pladelagertilgange i søgeprocessen findes.
$np$
I en tilføjelse til artiklen er en formel angivet. Formlen angiver, hvilke
størrelser i en søgeforespørgsel der anvendes til at finde antallet
af pladelagertilgange. Formlen har følgende udseende:
$sj$
      A = antal pladelagertilgange pr. gennemført 
          søgeforespørgsel
      B = antal opslag i stednavnsfilen pr. kriterie
      C = antal opslag pr. kriterie
      D = antal kriterier pr. forespørgsel
      E = antal AB-områder pr. forespørgsel
Med disse betegnelse gælder:

      A = B + ( C * D * E )
$rj$
$nl$
De angivne størrelser betyder  følgende:
$nl$
Stednavnsfilen er opdelt således, at hyppigt anvendte stednavne er placeret
i lageret. Derfor afhænger antallet af pladelagertilgange af,
hvor stor sandsynligheden er for at stednavnet findes i området
for hyppigt anvendte stednavne. Denne sandsynlighed kan findes
fra en statistik som er beskrevet i afsnit 5.1 og betegnes OPSTAT.
Fra en OPSTAT findes B til 0.18.
$nl$
Et opslag til et andet kriterie end stednavnet er en access til
en fil, der findes på søgedisken. Dette vil altid være 2. (dvs. C = 2)
At det altid er 2 hænger sammen med den måde søgeprocessen er implementeret.
Antallet af kriterier pr. forespørgsel kan ligeledes findes fra en
OPSTAT. Den findes til 2.03 (= D). 
$nl$
Den sidste størrelse i formlen er antal AB-områder pr. forespørgsel.
Denne kan findes til 3.5 (= E). Et AB-område er en indikering
af de to første cifre i et tlfnr. Er eksempelvis stednavnet Østerbro,
så starter de to første cifre i tlfnr. i de fleste tilfælde
 med enten 26,29,32,38 eller 42.
38 er et AB-område.
$nl$
Fra den angivne formel findes så, at
$sj$
      A = 0.18+(2*2.03*3.5) = 14.39
$rj$
$nl$
Dette er pr. gennemført søgeforespørgsel. De eneste afviste søgeforespørgsel
som præcist kan angives at anvende et andet antal er en,
der afvises på grund af at stednavnet ikke findes. Disse vil kun anvende
1 pladelagertilgang.
$np$
Det angives nu, hvor mange pladelagertilgange der er for samtlige
søgeforespørgsler. Tallene er hentet fra en OPSTAT (fra d.25.04.81).
$sj$
   2753 afviste søgeforespørgsler, hvor stednavnet 
        ikke findes a 1 pladelagertilgang            =   2753
  79968 gennemførte søgeforespørgsler + afviste
        af anden grund a 14.39 pladelagertilgange    =1150739.5
 --------------------------------------------------------------
 82721 søgeforespørgsler med ialt antal plade.tilg. = 1153492.5

  Dermed 13.9 pr. søgeforespørgsel.

$rj$
$nl$
$np$
Da det ved vurderingen af OP-systemet viser sig, at
søgeprocessen er en meget vigtig proces, har det i afsnit 6.3 været
nødvendigt at beskrive denne nærmere.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»4_«bs»._«bs»O_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»s_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n_«bs».$
$np 15$
Denne proces foretager  opslaget i abonnentfilen.
Abonnentfilen indeholder data om samtlige abonnenter. Dvs.
filen indeholder eksempelvis navn, adresse, tlfnr. o.l.
$np 15$
Programmet, der foretager  opslaget er delt i to hovedafsnit, hvor
det ene foretager opslag til besvarelse af tlfnr. forespørgsler,
og det andet foretager opslag til besvarelse af søgningsforespørgsler.
Sagt på en anden måde behandler det første hovedafsnit meddelelser fra
inputprocessen, og det andet behandler kandidaterne, som eventuelt
modtages fra søgeprocessen.
$nl$$nl$
Svarende til de to dele udfører processen følgende:
$nl2$
_«bs»1_«bs»._«bs»T_«bs»l_«bs»f_«bs»n_«bs»r_«bs»._«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l_«bs».
$np$
En tlfnr.forespørgsel bevirker, at opslagsprocessen ud fra et tlfnr. finder
abonnenten i abonnentfilen. Det er en simpel operation, som normalt
kun benytter to pladelagertilgange.
$np 15$
Svaret på en tlfnr. forespørgsel fylder aldrig mere end et skærmbillede, og
det sendes til outputprocessen påsat betegnelsen "ABONNENT INFORMATION
SVARBILLEDE", hvis den forespurgte forespørgsel findes og 
typen "SIMPELT OUTPUT", hvis forespørgslen afvises.
$nl$$nl$
_«bs»2_«bs»._«bs»S_«bs»ø_«bs»g_«bs»e_«bs»f_«bs»o_«bs»r_«bs»e_«bs»s_«bs»p_«bs»ø_«bs»r_«bs»g_«bs»s_«bs»e_«bs»l_«bs».
$np$
Denne programdel aktiveres, når der modtages en meddelelse fra søgeprocessen af 
typen "KANDIDAT STAK".
$np 15$
Der opbygges en række tabeller til styring af opslagene i abonnentfilen og
opbygning af svarlinier. Derefter dannes
en svarlinie for hver kandidat modtaget fra søgeprocessen.
 Når alle svarlinier er dannet, sorteres de
og indsættes enkeltvis i en outputbuffer.
I denne outputbuffer dannes der færdige skærmbilleder med den oprindelige
inputlinie, som første linie. Hvis antallet af svarlinier fylder
mere end et skærmbillede anføres dette i outputbufferen.
 Derefter sendes denne til outputprocessen.
$np$
Antal pladelagertilgange i opslagsprocessen afhænger af
forespørgselstypen. For en tlfnr.forespørgsel anvendes 2. For en
søgeforespørgsel anvendes 1 for hver kandidat. Dermed fås
$ps$
$sj$

   48140 søgeforespørgsler a 7.5 kandidater     361050

   27070 tlfnr.forespørgsler a 2                 54140
  -----------------------------------------------------
   75210 forespørgsler med ialt antal plade.tilg.415190
$rj$$nl$

   Dermed pr. forespørgsel i opslagsprocessen 5.5 pladelagertilgange.
$ns 1,4,_«bs»3_«bs»._«bs»1_«bs»._«bs»5_«bs»._«bs»O_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t_«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs».$
$np 15$
Output processen modtager meddelelser  fra de andre processer.
Den modtager fejludskrifter fra input- og søgeprocessen. Fra opslagsprocessen
ankommer en outputbuffer og fra inputprocessen kommer bladningsforespørgsler 
og forespørgsler om afdækning af hemmeligt tlfnr. 
Dens eneste formål er at videresende meddelelserne til OP-skærmene og
at udskive kommunikationsblokke i en fil kaldet LOGFILEN.(beskrevet i afsnit 3.4)

$np 15$
Alle af outputprocessen modtagne meddelser udskrives i en fil kaldet
LOGFILEN (beskrevet i afsnit 3.4). Efter at forespørgslen er udskrevet i logfilen bestemmes ud fra
typen, hvilken aktion der herefter skal tages.
$ns 1,4,_«bs»3_«bs»._«bs»2_«bs»._«bs»K_«bs»o_«bs»m_«bs»m_«bs»u_«bs»n_«bs»i_«bs»k_«bs»a_«bs»t_«bs»i_«bs»o_«bs»n__«bs»m_«bs»e_«bs»l_«bs»l_«bs»e_«bs»m__«bs»d_«bs»e__«bs»5__«bs»p_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»r_«bs».$
$np 15$
Da det for forståelsen af OP-systemet er særdeles vigtigt at vide, hvordan forespørgsler
passerer gennem de 5 processer vil dette 
blive opsummeret i det nedenstående.
$np 15$
Processen OP-parent benyttes, som før omtalt kun ved opstart og lukning af systemet,
så den vil ikke nøjere blive medtaget her.
$np 15$
Nedenstående figur viser en simplificeret udgave af OP-systemets RC8000-del.
$fg 110$
$np 15$
Alle forespørgsler går gennem inputprocessen og outputprocessen. Det interessante
er, hvordan de derudover passerer gennem systemet. Nedenfor er angivet
de mulige veje.
$nl$$nl$
_«bs»i_«bs»n_«bs»p_«bs»u_«bs»t__«bs»-_«bs»>__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t__«bs»:
$nl$
Forespørgsler med fejl i inputlinien, bladningsforespørgsler og
afdækning af hemmeligt tlfnr.
$nl$$nl$
_«bs»i_«bs»n_«bs»p_«bs»u_«bs»t__«bs»-_«bs»>__«bs»s_«bs»ø_«bs»g_«bs»e__«bs»-_«bs»>__«bs»o_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»s__«bs»-_«bs»>__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t__«bs»:
$nl$
En søgeforespørgsel, hvor der er mellem 1 og 63 kandidater.
$nl$$nl$
_«bs»i_«bs»n_«bs»p_«bs»u_«bs»t__«bs»-_«bs»>__«bs»s_«bs»ø_«bs»g_«bs»e__«bs»-_«bs»>__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t__«bs»:
$nl$
En søgeforespørgsel, hvor der enten ikke findes kandidater eller
der findes mere end 63.
$nl$$nl$
_«bs»i_«bs»n_«bs»p_«bs»u_«bs»t__«bs»-_«bs»>__«bs»o_«bs»p_«bs»s_«bs»l_«bs»a_«bs»g_«bs»s__«bs»-_«bs»>__«bs»o_«bs»u_«bs»t_«bs»p_«bs»u_«bs»t__«bs»:
$nl$
En tlfnr.forespørgsel.
$ns 1,4,_«bs»3_«bs»._«bs»3_«bs»._«bs»S_«bs»c_«bs»h_«bs»e_«bs»d_«bs»u_«bs»l_«bs»e_«bs»r_«bs»i_«bs»n_«bs»g_«bs»s_«bs»s_«bs»t_«bs»r_«bs»a_«bs»t_«bs»e_«bs»g_«bs»i_«bs»e_«bs»n_«bs».$
$np 15$
Scheduleringsstrategien, som benyttes på en RC8000, er en modificeret
form for ROUND-ROBIN.(se Brin73 s255). Den vil blive uddybet i følgende
afsnit.
$nl$
En proces kan være i 3 forskellige tilstande:
$lm20$
$nl$
1.Kørende
$nl$
2.Ventende (på at blive kørende)
$nl$
3.Passiv
$lm0$
$nl$
Processen der benytter CPU-en betegnes kørende. En ventende
proces skal benytte CPU-en, men da der er en anden proces, der
anvender CPU-en, må den vente på dens tur. En passiv
proces venter på en ydre hændelse som eksempelvis kan være at
pladelageret er færdigt med en overførsel.
$np$
Til disse 3 tilstande svarer kun een kø, hvori ventende processer og
den kørende proces findes. Køen er en dobbelthægtet liste og har for
de i OP-systemet indgående processer eksempelvis følgende udseende:
(Den betegnes fremover aktivkøen.)
$ps$
$sj$
_«bs»A_«bs»K_«bs»T_«bs»I_«bs»V_«bs»K_«bs»Ø_«bs»E_«bs»N_«bs»:


   ----------     ----------    ----------
   !        !     !        !    !        !
   ! INPUT  !     ! SØGE   !    ! OUTPUT !
   ! PROCES !--->-! PROCES !-->-! PROCES !
   !        !---<-!        !--<-!        !
   ! KØRENDE!     !VENTENDE!    !VENTENDE!
   !        !     !        !    !        !
   ----------     ----------    ----------
_«bs»P_«bs»A_«bs»S_«bs»S_«bs»I_«bs»V_«bs»E__«bs»P_«bs»R_«bs»O_«bs»C_«bs»E_«bs»S_«bs»S_«bs»E_«bs»R_«bs»:

                  
                  -----------    -----------
                  !         !    !         !
                  ! OPSLAGS !    ! OP-PA-  !
                  ! PROCES  !    ! RENT    !
                  !         !    ! PROCES  !
                  ! PASSIV  !    ! PASSIV  !
                  !         !    !         !
                  -----------    -----------
                Figur 3.4

$rj$
$np$
At forklare, hvordan scheduleringsstrategien på en RC8000 virker,
er det samme som at forklare, hvordan en proces indsættes i aktivkøen. Dette
skyldes, at det altid er første proces i aktivkøen, der er kørende. 
En proces indsættes i aktivkøen afhængig af værdien af en variabel
i procesbeskrivelsen, der betegnes TIMEQUANTUM. Denne størrelse må
absolut ikke forveksles med en tidsskive, der altid er 25.6 ms.
$nl$
Nedenstående er de 3 tilfælde, som opstår, når en proces afbrydes, og
der derved skal ændres i rækkefølgen i aktivkøen.
$nl2$
_«bs»1_«bs»._«bs»P_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n__«bs»a_«bs»f_«bs»b_«bs»r_«bs»y_«bs»d_«bs»e_«bs»s__«bs»a_«bs»f__«bs»k_«bs»l_«bs»o_«bs»k_«bs»k_«bs»e_«bs»n_«bs».
$nl$
Dette sker for hver 25.6 ms. Når processen
afbrydes bliver sat til TIMEQUANTUM := den kørte tid + TIMEQUANTUM. Den
kørte tid angiver, den tid processen har været kørende uden afbrydelse.
Hvis TIMEQUANTUM derved bliver større eller lig 25.6 ms bliver
processen taget ud af aktivkøen og placeres bagest i køen.
TIMEQUANTUM bliver derefter sat til 0.
$nl2$
_«bs»2_«bs»._«bs»P_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n__«bs»a_«bs»f_«bs»b_«bs»r_«bs»y_«bs»d_«bs»e_«bs»s__«bs»a_«bs»f__«bs»e_«bs»t__«bs»i_«bs»n_«bs»t_«bs»e_«bs»r_«bs»r_«bs»u_«bs»p_«bs»t__«bs»f_«bs»r_«bs»a__«bs»e_«bs»n__«bs»y_«bs»d_«bs»r_«bs»e__«bs»e_«bs»n_«bs»h_«bs»e_«bs»d_«bs».
$np$
Interruptet vil her altid være beregnet til en proces, der er ventende.
Denne ventende proces indsættes i aktivkøen foran den kørende
proces, hvis TIMEQUANTUM er mindre eller lig 25.6 ms ellers
indsættes den bagest i aktivkøen.
$nl2$
_«bs»3_«bs»._«bs»P_«bs»r_«bs»o_«bs»c_«bs»e_«bs»s_«bs»s_«bs»e_«bs»n__«bs»ø_«bs»n_«bs»s_«bs»k_«bs»e_«bs»r__«bs»e_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l_«bs»v_«bs»i_«bs»s__«bs»e_«bs»n__«bs»p_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»t_«bs»i_«bs»l_«bs»g_«bs»a_«bs»n_«bs»g 
_«bs»e_«bs»l_«bs»l_«bs»e_«bs»r__«bs»e_«bs»r__«bs»f_«bs»æ_«bs»r_«bs»d_«bs»i_«bs»g_«bs».

$nl$
TIMEQUANTUM sættes til tiden processen har været kørende uden
afbrydelser + TIMEQUANTUM. Processen tages derefter ud af køen og bliver ventende.
$nl2$
Formålet med denne ret komplicerede scheduleringsstrategi er, at hindre
at en proces monopoliserer en ydre enhed, og at sikre en hurtig
kommunikation med ydre enheder.

$nl2$
_«bs»E_«bs»k_«bs»s_«bs»e_«bs»m_«bs»p_«bs»e_«bs»l__«bs»:
$nl$
Antag at der  i RC8000 findes 3 processer  fremover betegnet A,B og  C.
Til tiden 0 bliver proces A,B og C oprettet og startet. Dette bevirker,
at processerne bliver indsat i aktivkøen i rækkefølgen A,B,C. Da
 proces A er den første proces, bliver den kørende og
den får tildelt 25.6 ms (betegnes i det følgende også med en tidsskive)
 Imidlertid skal proces A efter 15 ms benytte
et segment fra pladelageret.
(Det antages, at denne pladelagertilgang tager 38.3 ms.)
 Dette bevirker, at proces A bliver passiv og B ( som er
ventende ) bliver kørende.
(Aktivkø: B,C) Størrelsen TIMEQUANTUM bliver for A 
sat til 15 ms. B bliver nu kørende i 25.6-15 ( = 10.6 ) ms, og
B bliver derefter afbrudt af klokken. TIMEQUANTUM for B bliver sat til
10.6 ms. Idet dette er mindre end en tidsskive, kommer B atter forrest i
aktivkøen. Den får nu tildelt en hel tidsskive. Da den ikke under denne
tidsskive kan nå at blive færdig, er den kørende under hele tidsskiven.
Når den har kørt en hel tidsskive, bliver B igen afbrudt af klokken.
TIMEQUANTUM for B bliver nu sat til 
$nl$
10.6+25.6 = 36.2 ms. Da dette er 
større end en tidsskive bliver B indsat bagest i aktivkøen, og TIMEQUANTUM
bliver derefter sat til 0. 
$np$
Proces C bliver nu kørende, og den får tildelt 25.6 ms. Når der er gået 2.1 ms
af denne tidsskive,
 vil pladelagertilgangen for proces A være færdig. Proces
C bliver så afbrudt.
$fg 70$
Da A's tidskvant er mindre end 25.6 ms, vil denne  blive 
indplaceret forrest i aktivkøen.
(Aktivkø: A,C,B)
$np$
A får nu tildelt 25.6-2.1 ms, som er den tid der er tilbage af
en tidsskive.
Efter at proces A har kørt 25.6-2.1 = 23.5 ms bliver A afbrudt af klokken. 
A's TIMEQUANTUM bliver sat til 15.0+23.5= 38.5 ms. Dette er større end
en tidsskive og A bliver derfor sat bagest i køen. TIMEQUANTUM for A bliver
sat til 0.(Aktivkø: C,B,A) C kører så 25.6 ms og TIMEQUANTUM for C
bliver 25.6+2.1 = 27.7. Den tages derfor ud af aktivkøen og indsættes
bagest. (Aktivkø: B,A,C) TIMEQUANTUM for C bliver igen sat til 0.
Dette fortsættes på ækvivalent vis.
$nl$
På figur 3.5 er på tidslinier angivet, hvordan de 3 processer kører.
En skravering af tidslinien angiver, at processen er kørende.
$np$
$np$
Ovenstående eksempel forudsætter, at processerne alle har
samme prioritet. Dette er tilfældet ved OP-systemet. Hvis
ikke alle processer har samme prioritet, kan man betragte det som om,
at der findes en aktivkø for hvert prioritetsniveau. En proces vil
så blive indplaceret i køen svarende til den prioritetskø, der har samme
prioritet som processen.
$ns 1,4,_«bs»3_«bs»._«bs»4_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»L_«bs»O_«bs»G_«bs»F_«bs»I_«bs»L_«bs»E_«bs»N_«bs».$
$np 15$
Når en forespørgsel passerer gennem OP-systemet, foregår dette ved,
at en vis mængde data i form af kommunikationsblokke
 transporteres mellem de i systemet indgående processer.
Disse kommunikationsblokke udskives i en fil på systemdisken kaldet logfilen.
 Dette foregår som tidligere beskrevet i outputprocessen.
$np 15$
Hver kommunikationsblok indeholder et blokhoved. Dette blokhoved
indeholder følgende information:
$sj$
      bloklængde
      bloktype
      løbenr.
      terminal identifikation
      fra A-omr.  til A-omr.
      abs. ankomsttid   input proces
      rel. afgangstid   input proces
      cpu tid           input proces
      rel. ankomsttid   søge proces
      rel. afgangstid   søge proces
      cpu tid           søge proces
      rel. ankomsttid   opslags proces
      rel. afgangstid   opslags proces
      cpu tid           opslags proces
      rel. ankomstid    output proces
      rel. afgangstid   output proces
      cpu tid           output proces
$rj$
$np 15$
Alle rel. tider er relative i forhold til den absolutte ankomsttid til
inputprocessen, og alle tider er udtrykt i millisekunder.
$np$
Det er indholdet af dette blokhoved, der ved denne opgave læses i logfilen
og derved anvendes til at finde de i afsnit 4 beskrevne præstationsindices.
Den ud over blokhovedet eksisterende information i logfilen vil ikke blive beskrevet
her, men vedlægges som bilag 2. Grunden til at beskrivelsen ikke er
medtaget her, er for det første, at den indeholder en del intern
information, som det vil være for uoverskueligt at beskrive. For
det andet  anvendes kun ovenfor nævnte information. Det
kan dog nævnes, at den ekstra information i logfilen eksempelvis
normalt
anvendes til at undersøge kriteriesammensætningen for forespørgsler og f.eks. hvor
hyppigt et stednavn anvendes.
$ns 1,4,_«bs»3_«bs»._«bs»5_«bs»._«bs»P_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»k_«bs»a_«bs»n_«bs»a_«bs»l_«bs».$
$np$
De 3 processer søge-, opslag- og outputprocessen kommunikerer med de tilkoblede
pladelagre gennem en "discdriver" og en pladelagerkanal. Det vil ikke
her blive beskrevet, hvordan "discdriveren" fungerer. Dette skyldes, at
den er indbygget i, hvad der betegnes monitoren på RC8000.
Det er derimod særdeles vigtigt at
forstå, hvordan pladelagerkanalen fungerer.
Dette skyldes, at
 der er tre processer om at kommunikere gennem samme datakanal,
og det kan derfor tænkes,
 at den begrænser systemetsydeevne.
$np$
Pladelagerkanalen (eng. "disccontroler") er en selvstændig enhed. Dvs. at den indeholder en
logisk enhed, og den kan køre parallelt med CPU-en på RC8000.
For at forstå hvordan pladelagerkanalen overfører data, er det nødvendigt at gøre sig klart
hvordan en pladelagertilgang helt nøjagtigt foregår.
$np$
Når en proces i RC8000 ønsker at benytte nogle data, der er lagret på pladelageret,
sendes en meddelelse om dette til pladelagerkanalen.
Pladelagerkanalen sørger derefter for at 
 positionere selve diskhovedet
hen til det spor, hvor data findes. Når hovedet
befinder sig over sporet, bliver diskkanalen reserveret(dette umuliggør at
andre kan benytte den). Når hovedet befinder sig over det ønskede data,
overføres datamængden.
$np$
Det vigtigste at gøre sig klart er, at når hovedet befinder sig over det ønskede
spor er diskkanalen reserveret, og den kan ikke foretage sig andet før overførslen af data er færdig.
Derimod kan diskkanalen under en positionering af et diskhoved godt starte
en positionering på en anden disk.
En nøjere beskrivelse af pladelagerkanalen findes i afsnit 3 i simulatoropgaven.
$ns 1,4,_«bs»3_«bs»._«bs»6_«bs»._«bs»B_«bs»e_«bs»s_«bs»k_«bs»r_«bs»i_«bs»v_«bs»e_«bs»l_«bs»s_«bs»e__«bs»a_«bs»f__«bs»e_«bs»n__«bs»p_«bs»l_«bs»a_«bs»d_«bs»e_«bs»l_«bs»a_«bs»g_«bs»e_«bs»r_«bs»t_«bs»i_«bs»l_«bs»g_«bs»a_«bs»n_«bs»g_«bs».$
$np$
I forbindelse med vurderingen af OP-systemet er det vigtigt præcist at vide,
hvor lang tid en pladelagertilgang tager.
$np$
Fra RCSL no. 30-M43: DSC801 Disc Storage Controller Reference Manual (P.K.Anderson)
kan følegende anføres:
En pladelagertilgang består af en positionering af diskhovedet og overførslen
af data. Pladelageret roterer med 3600 omdrejninger pr. minut. Dette betyder,
at en omdrejning tager 16.6 ms. Når diskhovedet befinder sig over det ønskede spor,
vil det  i gennemsnit tage 1/2 omgang (8.3 ms) inden hovedet befinder
sig over det ønskede data.
I de 8.3 ms (de betegnes i det følgende overførselstiden) vil pladelagerkanalen
være reserveret(se forrige afsnit).
$np$
Positioneringen af diskhovedet hen til det ønskede spor tager i følge
ovenstående manual i gennemsnit 30 ms. Den maksimale tid det tager at flytte hovedet
eet spor er 7 ms. De indekssekventielle filer på de til OP-systemet hørende pladelagre er
organiseret på en måde, der minimere antallet af hovedflytninger. Ved
OP-systemets pladelagre vil den gennemsnitlige positioneringstid således ikke være 30 ms, men kan ud fra målinger i logfilen findes til ca. 8 ms.
$np$
Dette gøres ved at betragte en time, hvor belastningen er på 1247 forespørgsler pr.
time. Her anvendes ved søgeprocessen 405.4 ms til behandling af en forespørgsel,
hvoraf de 182.1 ms anvendes til CPU-behandling. Dvs. der er 223.3 ms til
13.9 pladelagertilgange. Dette giver 16.3 ms til hver pladelagertilgang. Af de
16.3 benyttes de 8.3 ms til overførsel af data, og dermed er positioneringstiden på 8.0 ms.
$np$
Disse beregninger er foretaget for at kunne angive en værdi på positioneringstiden.
Simulationskørsler har vist, at hvis positioneringstiden er en eksponentialfordeling
med 8 ms som middelværdi, så opnås de nøjagtigste resultater. På denne baggrund
bygger samtlige de i afsnit 6 udførte beregninger om udnyttelsesgraden af de indgående
pladelagre på, at positioneringstiden er gennemsnitlig 8 ms.
$ef$
scope user afs3 vko2
finis
▶EOF◀