NO311056B1 - Fremgangsmate og system i et fordelt driftssystem - Google Patents

Description

Teknisk område for oppfinnelsen

Den foreliggende oppfinnelse vedrører generelt håndterings-prosesser og relaterte ressurser i et distribuert driftssystem.

Med en prosess, som i foreliggende sammenheng også er betegnet kontekst, skal det her menes en ressurs i et driftssystem som trenger å benyttes av en jobb for at denne kan utføre programkode i prosessen. Prosessen fremskaffer jobben med en flerhet av ressurser som er nødvendige, f.eks. dens egen datamaskinteller, dens egen lagerplass, samt dens eget sett av prosessorregisteret. Prosessen synkroniserer jobber ved bare å tillate at én jobb om gangen utføres.

Med uttrykket jobb skal det her forstås, mer generelt, et fenomen som er rettet mot en prosess, slik at en fremgangsmåte eller metode i et objekt som eies av prosessen, blir utført. En jobb kan opprette nye jobber som er rettet mot andre prosesser eller mot sin egen prosess.

Beskrivelse av relatert art

US 3.905.023 viser og beskriver et system innbefattende et multippelnivå-driftssystem. Dette system er kjennetegnet som meget stort og spesielt komplisert. Påliteligheten ved systemmaskinvaren sikres ved kapasiteten for multippelnivå-drif tssystemet til å rekonfigurere systemmodulene dynamisk og automatisk på en passende måte. I alle hovedmodulene foreligger det feildetekterings- og feilrapporteringskretser som forsyner driftssystemet med informasjon for å utføre feilanalyser og dynamisk rekonfigurasjon av systemressursene. Lagermodulene er forsynt med "single bit" feildetekte-ringsmulighet uavhengig av driftssystemet. Driftssystemet kan betraktes som å innbefatte et basisnivå og N konsekuti-ve nivåer. Basisnivået er definert som kjernen av driftssystemet. En prosess i hvert nivå av driftssystemet er an-svarlig for at prosessen foretar opprettelser på det nær-meste høyere nivå og ikke for noen andre. Driftssystemet styrer systemressursene dynamisk og planlegger jobber eller oppgaver i en multippel programblanding. Den gjenfordeler ressurser, starter jobber og overvåker deres utførelse.

GB 2.079.997 vedrører et distribuert datamaskinsystem med en flerhet av systemer forbundet med hverandre. Hvert av systemene har en flerhet av innbyrdes forbundne elementer. Systemet innbefatter redundante elementer med et distribuert driftssystem for drift, feilovervåkning og rekonfigurasjon av funksjoner samtidig som den bruker vertikal adressering. Når en feil blir detektert, blir feilen verifisert, det feilbeheftede element blir isolert og dennes oppgave blir tildelt til et annet ikke-opptatt element. Dersom in-tet annet skulle være tilgjengelig vil systemet bli rekon-figurert for å muliggjøre forringet operasjon under bruk av de tilgjengelige elementer.

I US 4.933.936 er det beskrevet et distribuert datamaskinsystem som fremskaffer fleksibel feiltoleranse. Et distribuert driftssystem befinner seg i alle datamaskiner. Hver datamaskin blir styrt av en innbyggerkopi for et felles driftssystem.

Sammenfatning av oppfinnelsen

I en datamaskin er det ønsket at kommunikasjonrfeil, eller feil bevirket av feilbeheftede programmer, skal være i

stand til å kunne håndteres av drifts- eller operativsystemet i datamaskinen på en slik måte at den holdes intakt og at andre programmer og anrop ikke vil bli påvirket av feilen. En feil skal i verste fall innbefatte styrt utkobling av lenken av tilkoblede prosesser, eller anrop, der feilen har opptrådt. Virkningene av feilen skal være fullstendig isolert med hensyn til dette anrop. Med andre ord vil gjenvinning av en oppstått feil ikke kunne innbefatte større konsekvenser for systemet enn dem som ble bevirket av selve feilen.

En første hensikt med oppfinnelsen er å muliggjøre, i et distribuert driftssystem, å demontere en kjede av sammenkoblede prosesser samtidig som det returneres så mange la-ger- og maskinvareressurser som mulig til systemet.

En andre hensikt med oppfinnelsen er å muliggjøre isolasjon av feil og begrense deres konsekvenser, innbefattende de konsekvenser som vedrører gjenvinningsforholdsregler, bare til den aktuelle transaksjon/anrop, og således om mulig unngå datamaskingjenstart og påvirkning på andre anrop.

En tredje hensikt går ut på å muliggjøre oppsporing av feil, uavhengig av hvor disse opptrer i systemet.

En fjerde hensikt er å muliggjøre, i forbindelse med systemoppdatering, typemarkering av visse aktiviteter for å kunne styre utførelsen av disse mot den ønskede programva-reversj on.

Generelt i henhold til oppfinnelsen, for etablering av to-veis kommunikasjonslinker mellom prosesser i et distribuert driftssystem, er prosessene forsynt med porter, gjennom hvilke kommunikasjon mellom prosessene blir utført. Prosessene og portene gjør det mulig for operativsystemet å holde kontroll over prosessene med linker og å bruke disse linker også dersom prosessen i og for seg er terminert, og for å avdekke en feil i prosessen og avslutte denne. For å mulig-gjøre for operativsystemet å være i stand til å oversende via linker informasjon vedrørende prosess- eller data-maskinutfall og således være i stand til å videreføre denne informasjon gjennom hele kjeden av sammenkoblede prosesser, og for også å rapportere denne informasjon til applikasjoner som er utført i de sammenkoblede prosesser for å kunne gjøre det mulig for disse å foreta applikasjonspesifikke forholdsregler, blir det benyttet en kode som blir anropt eller oppkalt ved linkabortering og kommunikasjonsfeil. Funksjonen for denne kode innbefatter terminering av en feilbeheftet prosess og rapportering av feilen til en feilhåndteringskode. Den førstnevnte kode vil alltid foreta ut-førelse i en prosess til hvilken en prosess er blitt rapportert .

Mer spesielt vil en fremgangsmåte i henhold til oppfinnelsen, for håndtering av ressurser i et distribuert driftssystem omfattet følgende trinn: - å fremskaffe toveis kommunikasjonslinker mellom nevnte prosesser og å bruke nevnte driftssystem - til å fortsette med prosesser med linker, og å bruke nevnte linker også dersom en prosess med linker blir terminert , - å detektere en feil i en prosess og å terminere nevnte, - å overføre informasjon via nevnte linker vedrørende prosess- eller datamaskinfeil, og å videreføre denne informasjon gjennom en hel kjede av linkede prosesser, og - å rapportere denne informasjon til applikasjoner som er utført i nevnte linkede prosesser for å muliggjøre at disse utfører applikasjonsspesifikke gjenvinninger.

Et system i henhold til oppfinnelsen omfatter kodeorganer innbefattende: - første organer for å fremskaffe toveis kommunikasjonslinker mellom prosesser, - andre organer for å muliggjøre at nevnte operativsystem kan fortsette med prosesser med linker, og å bruke nevnte linker også dersom en prosess blir terminert, - tredje organer for å muliggjøre at operativsystemet, eller i visse tilfeller en prosess i seg selv, å detektere en feil i en prosess og å terminere nevnte, - fjerde organer for å muliggjøre at nevnte operativsystem kan overføre feilinformasjon via nevnte linker vedrørende prosess- eller datamaskinfeil, og å videreføre denne feilinformasjon gjennom en hel kjede av linkede prosesser, og - femte organer for å muliggjøre at operativsystemet kan rapportere nevnte feilinformasjon til applikasjoner som er utført i de linkede prosesser for å muliggjøre at disse ut-fører applikasjonsspesifikke gjenvinninger.

Kort omtale av te<g>nin<g>sfi<g>urene

Oppfinnelsen vil nå bli beskrevet i ytterligere detalj under henvisning til utførelsesformer som er vist skjematisk på de vedlagte tegningsfigurer. Figur 1 viser et eksempel på en aktivitet i form av en kjede av jobber i et distribuert driftssystem. Figur 2 viser eksempler på en aktivitetsgruppe tildannet av flere slike aktiviteter. Figur 3 illustrerer hvordan ressurser kan tilhøre en aktivitet for en kortere eller lenger tid. Figur 4 viser et linkrepresentasjonsriss av en aktivitet. Figur 5 er ment å illustrere at konsekvenser av en feil i en aktivitet kan isoleres til selve aktiviteten. Figurene 6a-6d illustrerer hvordan frakobling av en aktivitet kan utføres når en feil har kommet til syne i en prosess .

Figur 7 illustrerer systemoppgradering.

Figur 8 illustrerer konstruksjonen av et feilettersøkings-system i aktiviteten i henhold til figur 1. Figur 9 viser aktører som opptrer ved tilsynekomsten av en feilsituasjon i en prosess. Figurene 10-13 illustrerer håndteringen av prosesslokale feil. Figurene 14-16 illustrerer håndteringen av kommunikasjonsfeil. Figurene 17-19 illustrerer håndteringen av feil i andre prosesser. Figur 20 er en tabell som oppsummerer feiltilfeller omtalt i forbindelse med figurene 6-19.

Detaljert beskrivelse av foretrukne utførelsesformer

På de forskjellige tegningsfigurer vil de samme referanse-betegnelser bli brukt for å illustrere de samme eller lignende elementer.

Ved den følgende beskrivelse og på tegningene vil uttrykk som er kjente for fagmannen på området, vedrørende meldinger og kommunikasjon bli benyttet, såvel som pseudo-syntaks-uttrykk av en viss type. I den grad disse ikke blir forklart i det følgende, vil det antas at fagmannen på området ikke trenger noen ytterligere forklaring eller oversettelse av henholdsvis disse uttrykk og syntakser.

Konseptet vedrørende aktivitet som benyttes i det følgende, knytter seg å definere en kjede av jobber som opprettes i et drifts- eller operativsystem som et resultat av en uavhengig ytre eller indre hendelse, pluss summen av de ressurser som brukes av kjeden under dennes utførelse.

Figur 1 viser en "log" over en slik jobbkjede idet denne som et eksempel er vist som å opptre på grunn av hendelser i en telefonsentral mellom to telefonabonnenter A og B. Mer spesielt viser figuren en aktivitet i form av en kjede av jobber, og tre av de typer av ressurser som en aktivitet kan vedhefte seg selv, respektive prosesser, porter og abonnentutstyr. Mer spesielt er prosesser betegnet med henvisningssymbol 2, jobber med 4.n, porter med 6, og abonnentutstyr med 8 på figuren.

Pilene refererer seg til forskjellige meldinger i jobbkjeden, f.eks. en asynkron kommunikasjonsmelding 10, også betegnet "cast"-melding, og synkrone meldinger i form av anrop og svarmeldinger 12 og 14. Mer spesielt er det med asynkrone meldinger her å forstå slike meldinger som en prosess sender og kan fortsette sin utførelse uten å vente på respons, mens i tilfelle av synkrone meldinger blir prosessen låst inntil et svar har ankommet. En ny "cast"-melding resulterer i en ny jobb, f.eks. 4.2, som deretter meget vel kan eksistere samtidig med jobb 4.1, som har opprettet den. Anropet 12 resulterer også i en ny jobb 4.6, mens anropsjobben 4.5 blir temporært opphevet. Ikke før den nye jobb 4.6 har stoppet sin utførelse og har sendt en svarmelding 14, kan den opphevde jobb 4.5 fortsette.

Med en "uavhengig" ekstern hendelse skal det menes en hendelse som ikke er rettet mot noen aktivitet i systemet. Dersom A-abonnenten løfter telefonrøret er dette en uavhengig hendelse som starter en ny aktivitet. Dersom B-abonnenten løfter mottageren er det ikke en uavhengig hendelse, fordi den er rettet mot et anrop under opprettelse og derved mot en eksisterende aktivitet. Dersom A eller B-abonnenten legger på telefonrøret, vil det samme være tilfelle.

De fleste interne hendelser er ikke uavhengige. Dersom

f.eks. en debiterende puls blir mottatt, vil dette være et resultat av det forhold at en aktivitet har beordret en pe-riodisk tidsovervåkning, og har således opprettet en tempo-rær hvilende "timeout" jobb. Dette er innlemmet i aktiviteten. Visse interne hendelser bør imidlertid betraktes som

uavhengige. Dette kan gjelde f.eks. starten av testaktivi-teter fra en testgenerator eller utløste absolutte tidsovervåkninger (av typen oppvåkning, start av rutinetester).

Det er ikke nødvendigvis slik at en jobb i kjeden direkte må ha opptrådt i en annen jobb eller et anrop via kommuni-kas j onsmekanismene i operativsystemet. Det kan f.eks. skje at under en viss tidsperiode foreligger det ikke noen jobb i aktiviteten, enten dette skyldes utførelse eller venting i en eller annen kø. I slike tilfeller vil det bare være linkbildet som vil bli beskrevet ytterligere i det følgen-de, og som definerer aktiviteten. Dersom nå en ny jobb blir startet fra en av kildene som eksklusivt tilhører aktiviteten, f.eks. linjekretsen for B-abonnenten, vil også denne jobb 4.10 tilhøre aktiviteten.

Det skal vises til figur 2, hvorfra det fremgår at dersom en operatør eller tredje part C ønsker å bli forbundet inn i samtalen, vil distinksjonen mellom "uavhengig" og "av-hengig" bli noe mere vanskelig. Riktignok er det slik at hendelsen er rettet mot en eksisterende aktivitet 20, men det resulterer først i opprettelsen av en ny aktivitet 22. Disse to aktiviteter vil deretter danne en "aktivitetsgruppe", vist skjematisk på figur 2, ved at jobbkjedene "møtes" i den samme ressurs, dvs. i den halve anropsprosess 24 for A. Det skal imidlertid observeres at det forhold at to aktiviteter deler en ressurs, ikke er et tilstrekkelig kriterium til å tillate at de skal danne en aktivitetsgruppe. Mange aktiviteter (anrop) skal selvsagt dele aksessproses-sene uten å være innlemmet i det samme gjenvinningsdomene av denne grunn.

Et godt nok kriterium er sannsynligvis at aktiviteter som deler dynamiske prosesser, danner en aktivitetsgruppe, mens de som deler statiske prosesser ikke gjør det. Statiske prosesser er å betrakte som nok robuste til å motstå at en aktivitet blir gjenvunnet uten at dette påvirker de andre som deler prosessen.

Slik det er vist skjematisk på figur 3, vil aktiviteten under sin levetid tilslutte seg forskjellige ressurser for kortere eller lengre tid. En jobb 25 som begynner å utføre, tilslutter seg f.eks. alltid en ressurs 26 av typen prosess. I mange tilfeller, f.eks. statiske startprosesser, vil prosessen bli frigjort direkte når jobben termineres, men den kan også tilsluttes aktiviteten for en lengre peri-ode, f.eks. ved at det opprettes en port 28 til prosessen, slik at nye anrop fra den samme aktivitet kan ankomme ved et senere tidspunkt, slik dette er angitt ved 30 og 32, og som f.eks. kan innebære at en ny prosess 34 blir henholdsvis tilsluttet eller frakoblet.

En viktig type ressurs som aktiviteten vanligvis tilslutter seg, er kommunikasjonsporter som tilhører kommunikasjonsmekanismene for operativsystemet. Alle porter tilhører en prosess og hver port har en referanse til en motsatt port. Ved sammenlinking av porter vil aktiviteten således kunne opprette et linkbilde i henhold til figur 4, som holder sammen "eier"-prosessene for portene 6. På denne måte vil aktivitetene kunne tilslutte seg en prosess også under det tidsforløp der den ikke har noen jobb som skal utføres i nevnte. Det skal imidlertid observeres at denne "tilslut-ning" ikke innebærer noen eksklusiv aksess til prosessen.

Det er viktig å notere at et linkbilde bare er noe som eksisterer i form av sine noder og linker. Således foreligger det ingen sentral eller til og med distribuert-koordineren-de funksjon som har kjennskap til utvidelse og forekomst av linkbildene. Den eneste kjennskap til et linkbilde som eksisterer i systemet, er den begrensede informasjon som foreligger i hver port (en node kjenner sine umiddelbare na-boer i linkbildet).

Portene 6 kan også brukes for indirekte å tilslutte seg slike ressurser som blir administrert i en prosess til en aktivitet. I det program som utføres i prosessen "Access A" på figur 4, eksisterer det en intern referanse mellom porten 6, som har kontakt med maskinvaren for abonnent A, og porten 6 som direkte tilhører linkbildet. Slike "interne" forbindelser kan være påkrevet når det ikke er ønsket å terminere den aktuelle prosess sammen med resten av linkbildet. Typisk vil statiske prosesser kunne forventes å overleve frakobling av linkbildet (se figur 6).

Selvsagt foreligger det en flerhet av andre typer av ressurser som kan tilsluttes en aktivitet under disses eksis-tens, men det er alltid portene og linkbildet som gjør det mulig å holde sammen alle disse ressurser.

På grunn av det forhold at ressurser og jobber tilhørende en aktivitet blir holdt sammen, blir det dannet en ny type av "domener" i systemet. Som vist på figur 5, vil denne domene 40 "krysse" alle datamaskinene 42, 44, 46 og 48 involvert i anropet, men er på den annen side vel avgrenset i hver datamaskin. Med støtte av den rette type av mekanisme vil denne domene 40, dvs. aktiviteten, kunne med stor for-delaktighet benyttes som en gjenvinningsdomene.

Dersom det er mulig å begrense konsekvensene og utstrekningen av en feil for å holde seg innenfor aktiviteten, og samtidig fullføre at alle opptatte ressurser blir frigjort, så vil det da være mulig, i verste tilfelle, å frakoble det anrop som er styrt av aktiviteten, mens alle andre anrop forblir uberørt.

Dette er stor motsetning til fremgangsmåter i henhold til teknikkens stilling, der den minste gjenvinningsdomene er

en separat datamaskin. I tilfelle av mer seriøse feil i et anrop vil standardforholdsregelen være å gjenstarte datamaskinen, med den konsekvens at alle anrop som tilhører denne datamaskin, må bli frakoblet.

I tilfelle av at en alvorlig feil opptrer i en av prosessene i linkbildet, vil den normale forholdsregel være å frakoble hele anropet, dvs. aktiviteten, på en måte slik at ingen "anropsrester" gjenstår. Dersom ambisjonen bare er denne, er det mulig å utføre dette ved hjelp av selve ope-rativsystemer. Frigjøring av opptatte ressurser kan imidlertid være mere fleksibelt og raskere dersom applikasjonen inneholder kode som kan håndtere frigjøringen. Figurene 6a-6d illustrerer den typiske oversikt når et anrop blir frakoblet på grunn av feil. På disse figurer er den feilbeheftede prosess betegnet 50, statiske prosesser 52, og dynamiske prosesser 54. Ved det viste eksempel strekker kjeden med hendelser seg gjennom tre trinn, vist henholdsvis på figurene 6a, 6b og 6c, og resulterer i den tilstand som er vist på figur 6d, der bare de statiske prosesser 52 gjenstår. Mer spesielt, hver prosess vil alltid først sende en avbruddsmelding 56, betegnet "ConnectionAbort" ut over sine linker før den selv avslutter i henhold til piler 58. For det sistnevnte trinn vil betegnelsen "ContextTerminate" bli brukt.

En aktivitet kan også operere som en klient for systemoppdatering. Hele, eller deler, av aktiviteten kan diri-geres mot utførelse av en spesiell versjon av programvare. Dersom f.eks. en ny versjon av et program er blitt instal-lert, er det mulig å opprette under en tidsperiode "testak-tiviteter" som bruker denne programversjon, mens "normale" aktiviteter fortsatt blir styrt mot den gamle versjon. Senere er det mulig å velge også å styre nye "normale" aktiviteter mot den nye programvare.

Dette krever at aktiviteten får tilknytning til en "aktivi-tetsattributt". Attributten kan innbefatte et felt med informasjon om typen av aktivitet. Denne attributt må følge i alle meldinger, jobber, tidsovervåkninger og jobboppret-tingsressurser innbefattet i aktiviteten.

"Interesseområdet" for systemoppdateringen i aktiviteten er jobbkjeden og jobbopprettelseskildene (f.eks. aksessproses-ser og porter) dvs. deler av aktiviteten som kan inneholde en systemoppdateringsattributt. Linkbildet er ikke av in-

teresse eller synlig ut i fra den synsvinkel som gjelder systemoppdatering.

Figur 7 viser i ytterligere detalj utførelsen av systemoppdatering. På denne figur er det vist kontekstene A, B, C, D, E, E', F, F', G. I hver av disse kontekster kan programmer utføres, hvilket av enkelhetsgrunner kan antas å ha samme designasjon som den tilsvarende kontekst. Det foreligger bare en programversjon i kontekstene A-D og G, idet

det antas at programmene A, D og G er av en gammel versjon, mens programmene B og C er av ny versjon. Hvert av programmene E og F eksisterer i to forskjellige versjoner, som ut-øver i E og E' og F og F<1>, respektive.

Under en viss fase av systemoppdateringen kan f.eks. all "normal" trafikk bringes mot en "gammel" programversjon, dvs. kontekster E og F, og all "testtrafikk" mot "ny" programversjon, dvs. kontekstene E' og F<1>. Skiftingen mellom de to versjoner i henhold til dette system er anskuelig-gjort ved hjelp av piler E'' og F'', som er vist som beve-gelige. Kjøring av testtrafikk er således vist på figuren. Dersom bare en programversjon eksisterer, vil all trafikk nødvendigvis bli styrt mot denne, hvilket således vil være tilfelle for kontekstene A-D og G. Rektanglene UA med teks-ten "TEST" vist på figuren, indikerer at nevnte system opp-daterer attributt innlemmet i aktiviteten.

Kommunikasjonstjenesten for driftssystemet eller operativsystemet kjenner de programversjoner som er tilgjengelige og styrer anropene i henhold til eksisterende "diri-gerende regler". Det skal understrekes at de "regler" som blir brukt i henhold til figur 7, bare er et forenklet eksempel .

Når det er nødvendig å ettersøke feil kan aktiviteten også brukes som bærer av søkeinformasjon. Aktivitetsattributten vil derfor innbefatte et felt som indikerer hvorvidt oppsporingen blir aktivisert eller ikke, og noen "visibilitetsattributter", for indikering av hvilken type av hendelser (f.eks. hver melding som sender) som skal "besiktiges" ved oppsporingen. En oppsporingsidentitet blir også innlemmet. Attributt og oppsporingsidentitet kan indirekte, etter ordre fra en operatør, endres hvor som helst og når som helst under utførelsen av aktiviteten. Dersom oppsporing foregår vil aktiviteten tilslutte seg en kilde i form av en oppsporings-informasjonsbuffer. Dette vil også følge aktiviteten og være tilgjengelig i alle datamaskiner der aktivitet utføres.

På figur 8 er en oppstartet oppsporing i aktiviteten i henhold til figur 1, markert med en tykkere linje 60. Den tidligere nevnte oppsporingsattributt er anmerket med rektang-ler SA, som er tekstet henholdsvis "off" og "on", hvilket indikerer at attributten er henholdsvis "av" og "på". Be-skuelsen av oppsporingssystemet for aktiviteten er enda mer begrenset enn det som gjelder for systemoppdatering. Inter-essen er bare rettet mot deler av jobbkjeden, respektive de deler som følger etter at oppsporingsattributten er blitt

"slått på" ved 82 og opptil det punkt (punkter) 64 der den på nytt slås av. Denne del 60 av jobbkjeden kan betegnes som en utførelsestråd. Innenfor utførelsestråden er det

dessuten bare visse hendelser som er av interesse å bli be-skuet. Oppsporingsattributten endrer sin størrelse ved det tidspunkt den blir endret. Ved posisjonen "på", som opptrer i fem tilfeller ved SA', vil attributten inneholde en buffer B med oppsporingsinformasjon. Ved posisjonen "av" vil ingen buffer være påkrevet.

Oppsporingsattributtene kan leses og endres i visse "opp-sporingspunkter" som er plassert i veldefinerte punkter langs utstrekningen av jobbkjeden. Noen av disse oppspo-ringspunkter er blitt markert som et eksempel på figur 8 som triangler SP. Et oppsporingspunkt er en kode som alltid blir oppkalt i tilfelle hendelser i aktiviteten. Oppsporingspunktet er i stand til å lese, under denne oppkalling, innholdet i oppsporingsbufferen og ut i fra sin "visibili-tetsattributt" bestemme om hendelsen skal rapporteres, dvs. bli synlig for oppsporingsoperatøren, eller ikke.

Eksempler på visibilitetsattributter som kan eksistere, er: "rapporter innholdet i hver melding som er blitt sendt", hvoretter oppsporingspunktet plassert i hver port tar vare på at dette blir gjort, eller "rapporter identiteten for hver jobb som blir opprettet" hvilket resulterer i at et oppsporingspunkt i hver prosess oppretter en slik rapport.

For at oppsporingspunktene skal være i stand til både å rapportere hendelser og også endre oppsporingsattributter er det påkrevet at de har grensesnitt mot en operatør, f.eks. en person. Hvordan denne kommunikasjon blir utført, utgjør ikke noen del av denne oppfinnelse, men det kan være til opplysning å se hvilken type informasjon som passerer grensesnittet.

En typisk ordre som blir gitt av en operatør til et oppsporingspunkt er "slå på oppsporingsattributtene i alle ut-førte tråder som passerer og putt inn en visibilitetsattri-butt med meningen 'rapporter meldingssendinger' i bufferen for oppsporingsattributtene".

En typisk rapport som skal avgis av et oppsporingspunkt til operatøren, er "en melding med identiteten XX og innhold xyz ble nettopp sendt fra port nummer ABC til port nummer

DEX".

Linkbildet eller ytterligere ressurser er ikke av interesse ut ifra et oppsporingssynspunkt.

Den foreliggende oppfinnelse basert på følgende betingel-ser': - Alle datamaskiner som er direkte involvert i aktiviteten, må arbeide med et driftssystem som understøtter de mekanismer som er nødvendige for utførelse av oppfinnelsen. Datamaskiner som ikke har et slikt driftssystem, må bare eksistere som brukelige "ressurser" styrt fra aktiviteten. - Kommunikasjonsmekanismene for driftssystemet er forventet å ha avanserte organer for feildetektering, og mulighet for å rapportere feil til brukerne, noe som i og for seg er kj ent. - Den påkrevde utvidelse av kommunikasjonsmekanismene for driftssystemet må ikke påvirke utførelsen og sendekapasi-teten mer enn overflødig. - Systemet og dets maskinvarekomponenter antas å være så robuste at gjenvinningsforholdsregler blir forholdsvis sjeldne. Hyppige og massive gjenvinninger kan i alvorlig grad påvirke tilgjengeligheten av systemet.

Den foreliggende oppfinnelse har ikke noe å gjøre med

- hvordan statiske prosesser gjenvinnes etter kontekstfeil, - støtte, om noen, for gjenvinning av feil eller delvis feilbeheftede aktiviteter - all gjenvinning, som går ut over funksjonaliteten for å frakoble aktiviteten og returnere utførelsesressursene, må utføres av selve applikasjonen, - noen mekanismer får returnering av brukte ressurser med unntak av utførelsesressurser av typen porter og kontekster .

I det følgende vil det bli gitt en beskrivelse av den arki-tektur og de prinsipper som den foreliggende oppfinnelse bygger på. På sin side vil aktører i tilfelle av feilsituasjoner, håndtering av prosesslokale feil, håndtering av kommunikasjonsfeil og feil i andre prosesser bli behandlet.

Aktører i tilfelle feilsituasjoner

Disse blir kodet i et maskintolkbart språk som kan være i og for seg kjent, f.eks. kompilert fra programmeringssprå-ket C++, og som kan utføres i tilfelle opptreden av forskjellige typer feilsituasjoner. Ved de i det følgende brukte navn på de aktuelle aktører vil det i noen tilfeller opptre stavelsen "unntagelse". Denne stavelse blir innlemmet for spesielt å indikerer at den aktuelle aktør blir ut-ført i forbindelse med en eller annen type unormal hendelse, dvs. en eksepsjonell hendelse.

- "ErrorHandler"

Dette er en feilhåndterer for driftssystemet. På figur 9 betegner henvisningssymbol 66 en feilbeheftet prosess og 68 en tilhørende eksekutivkjerne. En naboprosess og den asso-sierte utførte kjerne er betegnet henholdsvis 70 og 72. Prosessene 66 og 70 kommuniserer, hvilket er vist ved 74, med hverandre via porter henholdsvis 7 6 og 78.

"ErrorHandler" som er vist ved henvisningssymbolene henholdsvis 80 og 82, har som oppgave å motta feilindikeringer fra prosessmaskinvaren og eksekutivkjernen, samt fra selve applikasjonene, som er vist ved henholdsvis 84 og 86 på figur 9. I tilfelle av slike indikasjoner kan "ErrorHandler" noen ganger aktivt komme inn og styre gjenvinningen, og noen ganger bare føre statistikk over antallet-av feil. "ErrorHandler" blir nådd bare ved hjelp av to anrop: via anropet "UserException" 88 fra applikasjonen 84, og anropet "reportError" 90 fra de deler av kjernefunksjonene som ut-fører i overvåkermodus. De indikerte feil blir deretter startet i parametre som følger de respektive anrop. "UserException" er et anrop som kan benyttes når en feil skal rapporteres. Som en parameter i forbindelse med dette anrop, blir det angitt en feilkode og en tekstfeilinforma-sjon, om nødvendig.

Alle feilkoder til "ErrorHandler" som følger av anropet "UserException" og "reportError", vil bli supplementert med tilgjengelig feilinformasjon, dvs. normalt en feilkode og en kort tekstbeskrivelse av feilen.

- "PortExceptionHandler" 92

Dette er en spesialisert unntagelseshåndterer for kommuni-kas jonsmekanismene i driftssystemet, som blir oppropt i tilfelle av linkabort og kommunikasjonsfeil. Dens umiddelbare gjenvinningsforholdsregei er å avslutte den aktuelle prosess og rapportere feilen til "ErrorHandler". Håndtere-ren kan imidlertid skrives på nytt og bli ytterligere spesialisert ved applikasjonskonstruktøren for derved å mulig-gjøre en mer kvalifisert gjenvinning. Denne unntagelseshåndterer utfører alltid i den prosess som feilen er blitt rapportert til.

Med hensyn til feilanrop til "PortExceptionHandler", så er det navnet på koden som blir utført i tilfelle av unntagel-sesanropet "handleException" i en funksjon "port" og dennes spesialiseringer, noe som vil bli forklart ytterligere i det følgende.

- "ApplicationExceptionHandler" 94

Dette er den spesialiserte unntagelseshåndterer for den

applikasjon som blir anropt i de tilfeller der-applikasjonen blir tillatt å få tilbake styringen etter detekteringen av en feil. Standardgjenvinningsforholdsregei er å returnere alle ressurser og terminere den aktuelle prosess. Hånd-tereren kan imidlertid bli ytterligere spesialisert av app-likas j onskonstruktøren, slik at det utføres en mer kvalifisert gjenvinning. Denne unntagelseshåndterer vil alltid ut-føres i den prosess der feilen har opptrådt.

"ApplicationExceptionHandler" er navnet på den kode som ut-føres etter anropet "UserException".

"ApplicationExceptionHandler" vil ikke håndtere kommunikasjonsfeil, men bare prosesslokale utførelsesfeil.

- "Context" = prosess

Blant andre ting vil "Context" også føre en kontroll med hvilke porter som er forbundet med seg. Når en prosess får instruksjoner om å terminere, enten det er en normal eller unormal terminering, vil den raskt kunne peke mot de porter som vil være uten en eier og beordrer disse til å avslutte seg selv og deres linker.

Et anrop til "Context" er "terminateProcess". Denne tar vekk den aktuelle prosess og involvert deri er også det at disse gjenværende porter skal tas vekk.

- "Port"

I forbindelse med feilhåndtering vil en port ha flere oppgaver : 1) Å motta "delete" og under utførelsen av dette sende ut "ConnectionAbort", pil 96, til porten, om noen, 78, til hvilken den er linket. 2) Å motta feilindikeringer fra andre porter eller fra "MainGate" 98 og anrop "PortExceptionHandler" 92, pil 100, med informasjon vedrørende feilen.

Vedrørende feilindikeringer til "Port" vil følgende gjelde: 1) Send en melding av typen "ReturnedMessage" innbefattende tilgjengelig feilinformasjon til porten. Porten vil deretter anrope "PortExceptionHandler" med en feilkode. 2) Send en melding av typen "connectionAbort" innbefattende tilgjengelig feilinformasjon til porten. Porten vil deretter anrope "PortExceptionHandler" med feilkoden "connectio-

nError".

3) Anropet "conncetionAbort" gir informasjon til porten om at den port til hvilken den er linket, ikke lenger eksisterer. Dette har samme betydning og virkning som meldingen "connectionAbort".

- "MainGate" 98

Denne "port" håndterer noen spesielle feil som må håndteres av kommunikasjonsmekanismene i driftssystemet. Blant andre ting må den være i stand til å motta og håndtere feiladres-serte meldinger, idet det ikke foreligger noen destina-sjonsport som kan håndtere dette. Når en slik melding ankommer, vil den generere en melding av typen "ReturnedMessage" mot sendeporten. "MainGate" blir ikke tilkoblet noen prosess.

- "Computer Excecution Capability Control" - "COECC" 102

"COECC" har som oppgave å kjenne status for alle andre datamaskiner som tilhører subnettet. I tilfelle av feilhåndtering har den bare en oppgave, nemlig å finne porter med linker mot porter i en feilbeheftet datamaskin og deretter anrope disse med "connectionAbort". En melding "state-Change" gir informasjonen om at en datamaskin i subnettet har endret sin status.

- "Application" 84 = 86

Uttrykket "Application" blir brukt i en vid forstand, dvs. alle brukere av kommunikasjonsmekanismene som er beskrevet her. I mange tilfeller kan den avdekke feil selv, og rapportere og til og med håndtere disse.

- "Kernel" 104 = 68 = 72

Med "Kernel" skal forstås eksekutivkjernen. Den rapporterer feil "ErrorHandler". "Kernel" vil blant andre ting innbefatte visse deler av kommunikasjonsmekanismene for driftssystemet, nemlig "NameGate" og "Port", fordi feilhåndte-ringen av disse innbefatter utførelse på brukerprosessene og rapportering av feil derfra. "COECC" er også en del av "Kernel", men blir trukket separat fordi dennes funksjona-litet har en spesifikk relevans i tilfelle av en feildetektering.

Det eksisterer ikke noen spesifikke feilanrop til "Kernel". I tilfelle der "Kernel" virker i feilsituasjoner vil den bare ha en aktiv rolle.

I det følgende vil en flerhet av feilhåndteringssituasjoner nå bli beskrevet under henvisning til figurene 11-19. Med hensyn til deres generelle innhold vil disse figurer svare til figur 9 og omfatte samme henvisningssymboler som på denne figur for å betegne lignende funksjoner og fenomener. De tall som opptrer i parenteser ved de aktuelle tegningsfigurer indikerer nummerorden for de funksjonelle trinn som opptrer på de respektive figurer.

Håndterin<g> av <p>rosesaorlokale feil

- Utførelsesfeil i applikasjonen, detektering ved en kompo-nent eller eksekutivkjerne. Det skal henvises til figur 10.

Feil av denne type kan være f.eks. adressering-ut over et tillatt område, divisjon med null, overflyt, sløyfer etc.

Feilen resulterer i et (ofte maskinvare) avbrudd som bevir-ker at den aktuelle kjernefunksjon 104 sender via "reportError" (1) en feilindikasjon 90 til "ErrorHandler" 80 i driftssystemet. I tilfelle slike feil vil prosessen alltid bli bedømt som upålitelig, og "ErrorHandler" vil derfor sende "terminateProcess" (2) til prosessen som på sin side sender "delete" (3) til de porter som er igjen. Disse vil på sin side sende "ConnectionAbort" (4) via deres linker. Dersom det er spørsmål om en statisk prosess vil deretter "ErrorHandler" opprette en ny prosess av den samme type og anrope startrutinen for samme. - Utførelsesfeil i applikasjonen detektert av selve applikasjonen 84. Det henvises til figur 11.

Dersom applikasjonsprogrammet 84 detekterer at det har opptrådt en eller annen alvorlig feil under utførelsen, vil den selv ta initiativet til å anrope (1) "ErrorHandler" 90, som vanlig via "UserException" 88. Denne gang blir prosessen bedømt som "pålitelig" fordi den er i stand til å detektere og selv rapportere seg. "Kernel" 104 vil derfor ha muligheten til å la styringen returnere til den spesialiserte "ApplicationExceptionHandler" 94 for applikasjonen. Standardmål for dette bør likevel omfatte terminering av prosessen med "terminateProcess" (2), hvoretter alt føres videre som i foreliggende tilfelle med "delete" (3) og "ConnectionAbort" (4). - Feil i tilfelle av systemanrop. Det vises til figurene 12 og 13.

Dersom en alvorlig feil blir detektert ved hjelp av kjernen 68 under et systemanrop 105, så vil returverdien fra kjernen indikere dette (1) i henhold til figur 12. En "Excep-tion" 106 blir overlevert (2) til applikasjonen, slik at selve "ApplicationExceptionHandler" 94 for applikasjonsprogrammet kan ta seg av feilen (3) . Etter dette kommer tilfellet til det som nettopp er beskrevet under henvisning til figur 11, med "terminateProcess" (4), "delete" (5) og "ConnectionAbort" (6) med terminering, om så, (8) av prosessen.

I tilfelle av visse feil kan imidlertid kjerne 104 direkte trekke den konklusjon at prosessen er upålitelig. I slike tilfeller vil kjernen i stedet rapportere (1) direkte til "ErrorHandler" 80, i henhold til figur 13, og dette vil deretter terminere prosessen (2). Fortsettelsen er den samme som i figur 12.

Håndtering av kommunikasionsfeil

- Tapt melding

Dersom en melding av typen "anrop" eller "svar" har gått tapt vil dette bli detektert ved en tidsovervåkning av at den originale anropsdel blir frigjort. I tilfellet "anrop-svar" vil det være anropsporten som beordrer tidsovervåkning, og når dette blir frigjort vil den relevante feilkode bli returnert som et svar til anropet "anrop". Fortsettelsen vil være nøyaktig den samme som for feilbeheftede systemanrop, slik dette er blitt beskrevet tidligere under henvisning til figurene 12 og 13.

Dersom den tapte melding er en "Cast" vil det i stedet være anropsapplikasjonen selv som beordrer tidsovervåkningen. Når denne blir frigjort vil anropsdelen være i samme situa-sjon som i det tilfelle som allerede er beskrevet under henvisning til figur 11.

Av figur 14 fremgår det at tapte meldinger også kan detekteres ved sekvensnummerering. For f.eks. "Cali", "Cast" og "Reply" vil følgende opptre. I tilfelle av toveislink vil alle meldinger sendt over denne bli sekvensnummerert, slik at mottakeren kan detektere gap i nummereringen. Følgende kan finne sted. Den anropende del sender en sekvensnummerert melding, som går tapt på sin vei (1). Den anropende part sender sin neste melding (2), idet sekvensnummeret for denne er øket med en. Den mottagende port 7 6 detekterer ga-pet i nummereringen og sender en melding til den anropende part 78 av typen "ReturnMessage" (3) med informasjon vedrø-rende det manglende nummer. Porten 7 8 vil først anrope "Errorhandler" 82 (4) og deretter "PortExceptionHandler" 92 med en feilkode (LostMessage" (5), hvoretter "PortExceptionHandler" utfører en eller annen form for gjenvinning.

- Feiladressert melding. Det skal vises til figur 15.

En melding 130 (1) som av en eller annen grunn innbefatter en feilbeheftet destinasjonsadresse (et portnavn som ikke er publisert, en gammel portreferanse eller lignende) vil opptre i "MainGate" 98. Denne vil deretter sende en melding (2) av typen "ReturnedMessage" til porten 78 for senderen. Porten 78 vil først anrope "ErrorHandler" 82 (3) og deretter "PortExceptionHandler" 92 (4) med feilkoden "PortNotA-vailable". Deretter kan tilfellet bli brakt tilbake til det som er tidligere omtalt.

- Frakoblet kontakt.

Dersom kontakten 74 til en annen datamaskin blir brutt, kan dette detekteres på to måter: 1) Det vises til figur 16. En utsendt melding vil ikke ankomme. I stedet vil den opptre i "MainGate" 98 for datamaskinen til hvilken den er ankommet (1) . Som i det foregående tilfelle, vil den sende en "ReturnedMessage" til senderporten 78 (2), hvoretter tilfellet kan bringes tilbake til den som ble tidligere omtalt under henvisning til figur 15, enn skjønt med en annen feilkode, nemlig "ComputerNotAvailable". 2) Linkovervåkningen for senderporten detekterer at desti-nasjonen ikke lenger kan nås, og anroper med "reportError" til "ExceptionHandler" (ikke vist). Deretter vil tilfellet være det samme som tilfellet (1).

Feil i andre prosesser

- Feilbeheftet prosess i egen eller annen datamaskin. Det vises til figur 17.

Når en prosess 66 går galt (dvs. blir terminert med "ErrorHandler"), men datamaskinen på hvilken den bedrev utøvelse fortsatt er intakt, vil alle dens linkede porter, f.eks. 76, sende ut "ConnectionAbort" (1) over sine linker. Dette resulterer i et anrop med en feilkode (2), først til "ErrorHandler" og deretter til "PortExceptionHandler" 92 i mottagerprosessen 70, som utfører standard oppretting eller en spesifisert gjenvinning. - Feilbeheftet datamaskin i eget subnett. Det vises til figur 18.

Dersom en datamaskin i sitt eget subnett får en feil, vil "COECC" 102 meget raskt bli informert om dette med "State-Change" (1) . "COECC" vil deretter finne ut de porter som har linker direkte mot denne datamaskin, og anroper disse med "ComputerNotAvailable" (N) . Hver port vil deretter anrope "ErrorHandler" og dens egen "PortExceptionHandler" med "ComputerNotAvailable". Deretter vil hendelsesforløpet skride frem analogt med andre feil av samme type. - Feilbeheftet datamaskin i et annet subnett. Det vises til figur 19.

Dersom en datamaskin i et annet subnett får en feil, vil "COECC" ikke bli informert. Forsvinningen av datamaskinen vil bli detektert enten ved at ingen melding ankommer eller ved linkovervåkningen av operativsystemet. Tilfellet vil derfor i praksis være det samme som tilfellet beskrevet tidligere med henvisning til figur 16, og blir"detektert og behandlet på samme måte.

- Sløyfer i andre prosesser.

Uendelige programsløyfer blir detektert på to måter:

1) "Kernel" detekterer sløyfen og frigjør den samme kjede av hendelser som beskrevet under henvisning til figur 10. 2) Tidsovervåkningen i den anropende prosess frigjør. Til-feilet vil deretter bli ført inn i tilfellet "Lost messa-ges" som beskrevet ovenfor, se figur 14.

De nevnte feiltilfeller, dvs. med henvisning til figurene 11-19, er også oppsummert på figur 20. Tabellen inneholder forkortelsen IPC som refererer seg til kommunikasjonsmeka-nismen i driftssystemet.

Ved den fremsatte beskrivelse over forskjellige feiltilfeller med henvisning til tegningsfigurene er det ikke gitt noen nærmere detaljert beskrivelse over programvare og maskinvare som skal brukes, eller om hvordan de beskrevne funksjoner og prosesser blir utført i praksis, fordi det forutsettes å være klart for fagmannnen på området hvordan oppfinnelsen skal bringes til utøvelse med veiledning i den foreliggende beskrivelse og tegningsfigurer. Denne oppfinnelse kan også brukes i forbindelse med kjente operativ-eller driftssystemer og vil derfor ikke forhåndsforeslå no-en spesiell maskinvare.

Claims (14)

1. Fremgangsmåte ved et distribuert driftssystem for å muliggjøre demontering av en kjede av linkede prosesser, idet det - med en prosess er ment en ressurs i nevnte driftssystem hvori applikasjoner kan utføres, og som må bli brukt av en jobb for å muliggjøre utførelse av programkode i prosessen, - med nevnte jobb er å forstå et fenomen som er rettet mot nevnte prosess for at en fremgangsmåte i et objekt som eies av prosessen skal kunne utføres, idet en jobb også er i stand til å opprette nye jobber rettet mot andre prosesser eller mot en egen prosess, og idet - nevnte prosess fremskaffer jobben med ressurser og synkroniserer jobber ved bare å tillate en jobb om gangen til å utføres, idet fremgangsmåten omfatter følgende trinn: - å fremskaffe toveis kommunikasjonslinker mellom nevnte prosesser og å bruke nevnte driftssystem - til å fortsette med prosesser med linker, og å bruke nevnte linker også dersom en prosess med linker blir terminert, - å detektere en feil i en prosess og å terminere nevnte, - å overføre informasjon via nevnte linker vedrørende prosess- eller datamaskinfeil, og å videreføre denne informasjon gjennom en hel kjede av linkede prosesser, og - å rapportere denne informasjon til applikasjoner som er utført i nevnte linkede prosesser for å muliggjøre at disse utfører applikasjonsspesifikke gjenvinninger.

2. Fremgangsmåte som angitt i krav 1, karakterisert ved at den omfatter det ytterligere trekk å bruke feiloppsporingsattributter som kan sendes fra jobb til jobb i en kjede i linkede prosesser.

3. Fremgangsmåte som angitt i krav 2, karakterisert ved at den omfatter det å tillate endring av verdi av nevnte attributter ved et hvilket som helst tidspunkt under utførelsen av en jobbkjede.

4. Fremgangsmåte som angitt i krav 2 eller 3, omfattende - å forsyne nevnte oppsporingsattributt med en oppsporingsbuffer som er i stand til å lagre informasjon vedrørende hendelser i nevnte system oppsport av nevnte attributt, og - å opprette ved hjelp av nevnte informasjon en logg over nevnte hendelser.

5. Fremgangsmåte som angitt i et av de foregående krav, omfattende -å fremskaffe i nevnte system en systemoppdateringsfunksjon, - å fremskaffe systemoppdateringsinformasjonsattributter som er i stand til å bære informasjon internt til nevnte oppdateringsfunksjon vedrørende type av trafikk som finner sted i systemet, - å overføre nevnte informasjonsattributter i en kjede av jobber for å muliggjøre bestemmelse av versjon av et spesifikt program som utføres når en utførelse finner sted.

6. System for i et distribuert driftssystem å muliggjøre demontering av en kjede av linkede prosesser, idet det - med en prosess er ment en ressurs i nevnte driftssystem-hvori applikasjoner kan utføres, og som må bli brukt av en jobb for å muliggjøre utførelse av programkode i prosessen, - med nevnte jobb er å forstå et fenomen som er rettet mot nevnte prosess for at en fremgangsmåte i et objekt som eies av prosessen skal kunne utføres, idet en jobb også er i stand til å opprette nye jobber rettet mot andre prosesser eller mot en egen prosess, og idet - nevnte prosess fremskaffer jobben med ressurser og syn-kronisere jobber ved bare å tillate en jobb om gangen til å utføres, karakterisert ved at prosessen omfatter kodeorganer innbefattende: - første organer for å fremskaffe toveis kommunikasjonslinker mellom prosesser, - andre organer for å muliggjøre at nevnte operativsystem kan fortsette med prosesser med linker, og å bruke nevnte linker også dersom en prosess blir terminert, - tredje organer for å muliggjøre at operativsystemet, eller i visse tilfeller en prosess i seg selv, å detektere en feil i en prosess og å terminere nevnte, - fjerde organer for å muliggjøre at nevnte operativsystem kan overføre feilinformasjon via nevnte linker- vedrørende prosess- eller datamaskinfeil, og å videreføre denne feilinformasjon gjennom en hel kjede av linkede prosesser, og - femte organer for å muliggjøre at operativsystemet kan rapportere nevnte feilinformasjon til applikasjoner som er utført i de linkede prosesser for å muliggjøre at disse ut-fører applikasjonsspesifikke gjenvinninger.

7. System som angitt i krav 6, karakterisert ved at det omfatter - kommunikasjonsmekanismer, - prosessporter som er innlemmet i nevnte første organer, via hvilke kommunikasjoner mellom prosesser kan utføres, - kommunikasjonsporter som ikke er forbundet med en prosess for håndtering av spesifikke feil som må håndteres ved hjelp av nevnte kommunikasjonsmekanismer i driftssystemet, - idet nevnte prosessporter har i forbindelse med feilhåndtering den oppgave å - motta en "delete" instruksjon som relaterer seg til dennes egen prosess, og samtidig med utførelsen av denne instruksjon å sende en link frakoblingsmelding, til en hvilken som helst port, til hvilken den er linket, - å motta feilindikeringer fra andre prosessporter og fra en hvilken som helst kommunikasjonsport, og å anrope kode i nevnte kommunikasjonsmekanismer for overføring av informasjon dertil vedrørende feilen i en slik feilindikasjon.

8. System som angitt i krav 7, karakterisert ved at nevnte andre organer innbefatter prosessporter.

9. System som angitt i krav 7 eller 8, karakterisert ved at nevnte tredje organer innbefatter driftssystemet og prosesser.

10. System som angitt i et av kravene 7-9, karakterisert ved at koden er en unntagel-ses-håndteringskode innbefattet i nevnte fjerde organ og alltid utøvende i en prosess, til hvilken en feil blir rapportert, og har den funksjon - å bli anropt i tilfelle av linkabort og kommunikasjonsfeil, - å avslutte en feilbeheftet prosess, og - å rapportere feilen til en feilhåndteringskode.

11. System som angitt i et av kravene 7-9, karakterisert ved at systemet omfatter feiloppsøkingsattributter som skal sendes fra jobb til jobb i en kjede av linkede prosesser.

12. System som angitt i krav 11, karakterisert ved at det omfatter organer for å tillate endring av verdi av nevnte oppsporingsattributter ved et hvilket som helst tidspunkt under utførelsen av en jobbkjede.

13. System som angitt i krav 10 eller 11, karakterisert ved at oppsporingsattributten har tilknytning til en oppsporingsbuffer for lagring av informasjon vedrørende hendelser i nevnte system ved oppsporing ved nevnte attributt,, idet systemet omfatter organer for å opprette ved hjelp av nevnte informasjon en logg over nevnte hendelser.

14. System som angitt i et av kravene 6-13, karakterisert ved at systemet" omfatter - en systemoppdateringsfunksjon, - systemoppdateringsinformasjonsattributter for å bære informasjon internt til nevnte oppdateringsfunksjon vedrøren-de type trafikk som utføres i systemet, - organer for overføring av nevnte informasjonsattributter i én kjede av jobber for å muliggjøre bestemmelse av ver-sjonen av et spesifikt program som skal utføres ved et tilfelle av utførelse.