NO325251B1 - Fremgangsmate for automatisk tilvirkning av aktuelle fordelingsrekkefolgedata - Google Patents

Description

Oppfinnelsen vedrører en fremgangsmåte for automatisk tilvirkning av aktuelle fordelingsrekkefølgedata ved å trekke inn sentrale adresselister som er lagret i databaser og som er oversendt ved dataoverføring.

Moderne postorganisasjoner har en sentral elektronisk adresseliste (på tysk zentralez elektroniscb.es Adressverzeichnis, ZAV), hvor alle adressene hvor man skal levere (oversendelses- eller utleveringspunkter) er notert. Adresselisten ZAV vil utgjøre informasjonsgrunnlaget for flere postmessige anvendelser, og vil aktualiseres med jevne mellomrom, f.eks. månedlig. Endringene vil typisk utføres på anmodning fra brukeren av de postmessige anvendelser som er avhengige av adresselisten ZAV, f.eks. postoversenderen. ZAV-dataene er ofte hierarkisk inndelt: oversendelses- eller utleveringsområder, oversendelses- eller utleveringssektorer (grupper av oversendelsespunkter) og oversendelsespunkter.

Innføring av nye tjenester og spesielt av nye trinn i automatiseringen, f.eks. fordelingsrekkefølgesortering, fører til nye utfordringer i et adresseliste(ZAV)-system. Ytterligere anvendelsesspesifikke data må lagres. For å unngå endringer i ZAV-systemet, installeres nye anvendelsessystemer, hvor man kan lagre og bearbeide anvendelsesspesifikke data. Som regel vil et slikt anvendelsessystem lagre en kopi av ZAV internt, som overføres over et eksisterende, dataorientert grensesnitt. Endringer i den sentrale ZAV-databeholdning krever en replikatdannelse av den nye databeholdning i anvendelsessystemene.

Et slikt anvendelsessystem, et fordelingsrekkefølgehåndteringssystem (tysk: Verteilreihenfolgenmanager, VFM), er nødvendig for å utføre en fordelingsrekkefølgesortering. Ved dette automatiseringstrinn vil sendingene sorteres maskinelt i rekkefølgen som hvor sendingene var oversendt fra oversenderen. Derved vil man spare en tidskrevende manuell sortering av sendingene utøvet av oversenderen. Ved hjelp av VFM vil man tilveiebringe sorteringsplaner, hvor rekkefølgen for brevsendingene er angitt, og som vil kjøres av fordelingsrekkefølgesorteringsanlegget. VFM må også lagre tjenestekvalitet-(Quality of Service, QoS)-merknadér som f.eks. " fordeles bare på tirsdager" sammen med adressedataene. Disse tjenestekvalitets-(QoS)-merknadene vil vurderes av VFM for å kunne holde sorteringsplanene aktuelle daglig.

Et problem ved bearbeidelse av ZAV-data i VFM er feilbeheftede eller ufullstendige datasett. ZAV inneholder enten ingen eller bare unøyaktige sekvensangivelser for å oppgi fordelingsrekkefølgen. De oversendelsesrekkefølgene som er anvendt av oversenderen kan også av andre grunner, f.eks. sykdom endres daglig. Disse endringene må være umiddelbart gjennomførbare, for ikke å forringe effektiviteten til fordelingsrekkefølgesorteringen. Av denne grunn og også for å gjøre tjenestekvalitets-(QoS)informasjonen ajourførbar på stedet, installeres VFM-systemene fortrinnsvis på spesielle datamaskiner på samme sted som sorteringsanlegget.

Hver VFM er her som regel ansvarlig for et adskilt postområde og databestanden må ikke sammenlignes med dataene i de andre VFM. Nye versjoner av ZAV må ifølge denne arkitekturen gjentas eller dannes replikk av ved flere VFM-er og der må disse integreres med lokale endringer i den tidligere versjonen. Denne replikkdannelse hadde vært enkel å realisere, hvis ZAV-systemet kunne stille til disposisjon en loggfil for endringene (som vanlig ved Merge-Replikation mellom databanksystemer (Microsoft SQL Server 200 Reference Library (ISBN 0-7356-1280-3))) eller hvis VFM-systemet ikke tillot endringer i dataene (read only snapshots (Buretta, Marie «Data Replication: Tools and Techniques for Managing Distributed Information», (ISBN 0-471-15754-6))). Hvis VFM var implementert med en industristandard databasehåndteringssystem (Database Management System, DBMS), og replikasjonstjeneste, kunne man kompensere den feilaktige endringshistorien (Log-File). VFM bør også kunne betjenes av flere endeapparater, noe som, sammen med antall fordelte VFM-datamaskiner vil bety betraktelige lisenskostnader for et DBMS. ZAV-dataene bør også tjene som masterversjon, mens fordelingsrekkefølgedata er en replikk (asymmetrisk replikkdannelse (Buretta, Marie «Data Replication: Tools and Techniques for Managing Distributed Information», (ISBN 0-471-15754-6))). En realisering uten DBMS eller loggfiler for ZAV-endringene vil gjøre den automatiske konfliktløsningen vanskelig.

Oppfinnelsen har som oppgave å tilveiebringe en enkel fremgangsmåte for automatisk tilvirkning av aktuelle fordelingsrekkefølgedata med replikkdannelse av ZAV-databestand eller -beholdning og med lokale endringer uten et databasehåndteringssystem.

Oppfinnelsen muliggjør også integrering av sentralt ajourført tjenestekvalitet-merknader, f.eks. ettersendelsesanmodninger, lettvint integrering av parallelt utførte endringer og også erstatning og rettelse av forhåndseksisterende adressedata ved inkrementelle endringer.

Ifølge oppfinnelsen løses oppgaven ved hjelp av trekkene i krav 1.

Ved hjelp av trinnene:

- lokalt å kopiere de aktuelle sentrale adressedata eller de delene som vedrører det relevante området, - å overføre fra lokalt lagrede endringsordre vedrørende relative posisjonsendringer for oversendelsespunkter i fordelingsrekkefølgen for den tidligere versjonen av den sentrale adresselisten eller relevante deler av den, hvorved oversendelsespunktene identifiseres ved hjelp av identifikasjonsdata, som inneholder i det minste en sorteringskode, til den lokale kopien av den aktuelle sentrale adressedata eller relevante deler av den, - å kontrollere om endringsordre i kopierte aktuelle adressedata allerede er realisert eller om det skal utføres, - å lagre endringsordrene som skal utføres, og som er gyldige i en Audit-File

og å utføre endringsordren,

er det ikke lenger nødvendig å håndtere og å utføre endringene ved hjelp av et databasehåndteringssystem (Database Management System).

Hvis ved et senere tidspunkt frigir man en nyere versjon av den sentrale adressedataliste, vil den nye databestand eller det nye datainnhold importeres fra VFM på enkel måte som en ny versjon av fordelingsrekkefølgedataene. Deretter kan endringsordrene som er lagret i audit-filen til den tidligere versjon anvendes på den nye versjonen automatisk ved hjelp av et redigeringsprogram. Herved vil endringene også skrives i den neste ledige audit-fil i den nye versjonen og også videreføres fra versjon til versjon.

Ifølge fremgangsmåten vil kontekstinformasjon for identifikasjonsdataene anordnes i audit-filen, for å muliggjøre en semantisk overprøving av gyldigheten til audit-fil-anmerkningene under deres anvendelse. Herved vil bare de gyldige endringene overføres fra én versjon til neste versjon. Et viktig grunnlag for denne fremgangsmåten er også at audit-anmerkningene er anordnet slik at de ikke bare muliggjør en enkel overføring av dataendringene, men også en samtidig overprøving av gyldigheten til endringsanvisningene.

Hver gang etter en ny replikkdannelse av en ny versjon av ZAV-dataene oppstår en ny versjon av fordelingsrekkefølgedataene for hver VFM. Hver VFM vil bearbeide bare ZAV-dataene for sitt eget tilstandsområde, noe som betyr en fordeling og parallellisering av arbeidet. En komplisert sammenføyning av ZAV- og fordelingsrekkefølgedatabestanden vil falle bort ved denne herre/slave (engelsk: Master/Slave) fremgangsmåten. Ved å danne en ny versjon av fordelingsrekkefølgedata vil automatisk for sikkerheten den gamle databestand være tilgjengelig. Ved generering av sorteringsplanene for et sorteringsanlegg vil bare én, den aktuelle versjon av fordelingsrekkefølgedataene anvendes.

Ved anvendelse av flere audit-filer kan flere operatører foreta endringer på den samme versjon av fordelingsrekkefølgedataene samtidig. Etter at en operatør er ferdig med arbeidet, vil innholdet av hans audit-filer automatisk anvendes på den aktuelle databestand som beskrevet ovenfor. Ved hjelp av dette vil hans endringer først bli gyldige. Hvis det finnes endringer som imidlertid på grunn av en annen operatørs endringer ikke kan gjennomføres, vil operatøren bli informert om dette og da vil den endrede fordelingsrekkefølgedata bearbeides på nytt. Strukturen til audit-filene tillater at man tilvirker en audit-fil ved hjelp av endringer i en versjon av fordelingsrekkefølgedata, og at disse anvendes deretter på en i mellomtiden endret versjon av fordelingsrekkefølgedata.

Fordelaktige utførelser av oppfinnelsen er satt frem i underkravene.

Det er fordelaktig at identifikasjonsdataene i tillegg inneholder husnummerdata.

Det er også fordelaktig at identifikasjonsdataene i tillegg inneholder kjennetegnende bemerkninger, f.eks. "ingen oversendelse på tirsdag", eller "fra en bestemt dato oversendes til ny adresse".

For opptak av denne videreføring- eller fordelingshenvisning i den kopierte adresseliste er det fordelaktig for det første å overprøve, for hver videreføring-og/eller fordelingshenvisning om oversendelsespunktet eksisterer i den kopierte aktuelle adresseliste for fordelingsrekkefølgedata. Når dette stemmer, vil det foregå en innlemming av de nye videreføring- og/eller fordelingshenvisning i den kopierte adresseliste, hvor nye henvisninger erstatter herved likeledes gamle henvisninger, og de fullstendige endringsdataene for videreføring- og/eller fordelingshenvisning vil overtas i audit-filen.

Sentralt ajourført tjenestekvalitetsmerknader vil også integreres i en kopi av den aktuelle fordelingsrekkefølgedata i adresselisten, hvor de eksisterende merknadene

vil erstattes av nye merknader eller tilsvarende korrigert. På annen måte enn ved ZAV-data vil også en fullstendig ny innlemmelse i audit-filen som hører til den nyé

versjonen skrives for hver merknadsendring. Herved vil lokalt og sentralt vedlikehold merknader i fremtiden overføres til de nye databestander. Denne fremgangsmåten vil bare virke, fordi audit-innmatingene for merknader alene lagres ikke som endringsanvisninger, men som endrede datasetninger i audit-filen. Derved kan merknadsdataene fullstendig og uten store kostnader overføres fra en versjon av fordelingsrekkefølgedataene til den neste. Denne kombinerte logg av

endringsanvisninger og datasetninger karakteriserer metoden ifølge denne oppfinnelsen.

I en ytterligere fordelaktig utførelse vil man for å aktualisere den sentrale adresseliste eller deler av den sentrale adresselisten bare overføre inkrementelle endringer ved dataoverføring. Disse inkrementelle endringene vil føres sammen med de kopierte, hittil aktuelle adresselister eller adresselistedeler, hvor man ved hjelp av identifikasjonsdataene for hvert oversendelsestidspunkt i den hittil aktuelle adresseliste eller adresselistedel vil overprøve, om hvert oversendelsespunkt i den inkrementelle endring allerede er tilstede. Hvis dette ikke er tilfelle vil det tas opp i den overførte posisjon av fordelingsrekkefølgen i den kopierte adresselisten eller adresselistedel. Hvis oversendelsespunktet i den inkrementelle endringen i adresselisten eller adresselistedelen allerede er tilgjengelig, vil det forslyves i den endrede posisjonen i adresselisten. Forskyvningsprosessen foregår med fordel, slik at oversendelsespunktet i sin stilling i adresselisten hittil slettes ut og det tas inn igjen i den endrede posisjonen eller stillingen.

Herved vil flertallet av endringer som kommer med de nye ZAV-dataene, ikke blandes med de lokale endringene. Det vil si at de lokale endringene endrer databestanden, men de er også adskilt i den nye audit-fil logg de er logget adskilt. Imidlertid kan man på denne måten fjerne overflødige lokale rettelser på lett måte. Denne fremgangsmåten virker bare på grunn av den i praksis begrensede type og omfang av endringene i ZAV-dataene og vil bare være brukbar for anvendelsene i postale områder, dvs. hvor adresser heller er tilføyd eller forskjøvet, og relativt sjeldent slettet.

Til slutt vil oppfinnelsen forklares nærmere i et utførelseseksempel ved hjelp av tegningene.

Det vises i:

Fig. 1 et strukturdiagram for fordelingsrekkefølgesorteringssystemer; Fig. 2 et flytdiagram for korrektur/erstatning av fordelingsrekkefølgedata ved en operatør; Fig. 3 et flytdiagram for import av nye fordelingsrekkefølgedata; Fig. 4 et flytdiagram for import av inkrementelt endrede fordelingsrekkefølgedata; . Fig. 5 et flytdiagram for import av merknads-data;

Fig. 6 et flytskjema for import av audit-data.

En fordelingsrekkefølgehåndteringsanordning (VFM) vil tilvirkes i registeret ved hjelp av i det minste de for postområdet relevante sentrale adresseliste (ZAV)-data ved dataoverføring. Fig. 1 viser de anvendte systemer for bearbeidelse av adressedata og for fordelingsrekkefølgesortering i en postorganisasjon. VFM 100 mottar ZAV-dataene fra systemet 101, hvor ZAV-dataene vil vedlikeholdes, og tilbereder ut fra disse, sorteringsplanene ved hjelp av et generatorprogram 106 for fordelingsrekkefølgesorteringsanlegget 104. Likeledes finnes det et andre anvendelsessystem 102 som også tar imot ZAV-dataene, som vil forvaltes av ettersendelsesordre. Andre anvendelsessystemer, som forvalter videre nødvendige informasjoner for fordelingsrekkefølgesorterings er også mulige. Ettersendelsesdataene vil tilstilles også ved VFM ved dataoverføring, f.eks. ftp. De fullstendige ZAV-dataene vil overtas fullstendig av VFM og de vil lagres lokalt som fordelingsrekkefølgedata på en harddisk 103. Hver gang, når det foreligger en ny versjon av ZAV-dataene, vil en ny versjon av den kopierte lokale fordelingsrekkefølgedata tilvirkes. På denne måte og vis dannes en replika eller kopi av ZAV-dataene i Master/Slave modus.

Tjenestekvalitets- (Quality of Service (QoS))merknadene er ikke inneholdt i ZAV-dataene, fordi disse vil vedlikeholdes lokalt på VFM av operatøren, og de vil lagres med den passende versjon av fordelingsrekkefølgedata. Operatøren kan også rette fordelingsrekkefølgedataene med et redigeringsprogram 105 eller erstatte dem, for å ta hensyn til endringer i gatebildet, f.eks. nye hus, som ikke er kjent ennå i ZAV-systemet, i fordelingsrekkefølgesorteringen.

Fig. 2 viser behandlingen av fordelingsrekkefølgedataene gjort av en operatør med et redigeringsprogram 105 i form av et flytskjema. Først blir versjonen som skal bearbeides av fordelingsrekkefølgedataene lest fira harddisken 201. Deretter vil redigeringsprogrammet reagere fra brukerinnmatinger, og foreta endringer i dataene 202. Endringene i adressedataene vil kunne utføres av forskjellige planer i hierarkiet, for å forskyve 203 /slette 204 eller tilføye 205 én/flere oversendelsesområder, én/flere senderaysnitt eller enkelte/flere oversendelsespunkter. Disse operasjoner vil endre dataene og samtidig vil hver enkelt logges som audit-innføringer av type MO VE (forflytte) 207, DELETE (slette) 208 og ADD (tilføye) 209. Hvis operatøren har tatt inn, slettet eller forskjøvet tjenestekvalitets merknader for et overseldelsespunkt/-avsnitt/-område, vil alle endringene logges med en SET (sett)-merknad innføring i audit-filen 210. Hvis operatøren etter editeringen vil lagre de endrede dataene 211, vil fordelingsrekkefølgedataene lagres og de nye audit-innføringene tas inn på slutten av audit-filen 212.

Utlegning av audit-innføringene er et vesentlig grunnlag for denne fremgangsmåten og vil kommenteres i tabell 1.

Ved ADD (tilføy) og DELETE (slett) innføringer vil det aktuelle oversendelsespunkt, -avsnitt eller -område angis som en parameter i innføringen.

Alle detaljene for oversendelsespunkter, avsnitt eller områder vil alltid lagres med, dvs.

for oversendelsespunkter:

område-ID, avsnitt-ID, sorteringskode, postnummer, gatenummer, husnummer, husnummerutvidelse, kommentar;

for oversendelsesavsnitt:

område-ID, avsnitt-ID, avsnittsnavn;

for oversendelsesområder:

område-ID, områdenavn.

Ved ADD (tilføy) innføringer vil også stillingen i fordelingsrekkefølge, hvor oversendelsespunkt/-avsnitt/-område vil innføres kjennetegnes. Istedenfor et posisjonsnummer vil den tilsvarende stillingen notert ved hjelp av det tidligere/senere kommende oversendelsespunkt/-avsnitt/-område. En MOVE (forflytning) innføring vil også gi som parameter tidligere/senere/kommende oversendelsespunkter/-avsnitt/-områder. Fordi en MOVE (forflytning) innføring vil kunne forskyve flere enn ett oversendelsespunkt/-avsnitt/-område samtidig som et sammenhengende område, vil området med det første og det siste oversendelsespunkt/-avsnitt/-område angis.

Anvendelse av tidligere eller senere innføring på steder av et posisjonsnummer gjør at målposisjonen i en forskyvning ikke er avhengig av den absolutte, men av den relative rekkefølgen av oversendelsespunkter. Avsnittsendringer vil logges relativt til et avsnitt og områdeendringer relativt til et område. Disse relative angivelsene sammen med det faktum at den virkelige geografien til oversendelsespunktene forblir statisk, betyr en veldig effektiv overføring av audit-innføringene.

Tjenestekvalitetsmerknader vil mates inn ved hjelp av redigeringsprogrammet og lagres som "sett" (SET) audit-innføringer. En vesentlig andel av audit-ifler består av SET(sett)-anvisninger. Fordi hvert oversendelsespunkt/-avsnitt/-område som regel vil ha få tjenestekvalitets(QoS)-trekk, vil vurdering av audit-filene derved holdes enkel, slik at man alltid angir alle de trekkene som er for hånd for et oversendelsespunkt/-avsnitt/-område i hvert SET-innføring. Derved må bare den siste SET-innføring for hvert oversendelsespunkt/-avsnitt/-område vurderes. Ved lading av fordelingsrekkefølgedata 201 vil overflødige SET-innføringer på enkel måte ignoreres, noe som ved den videre lagring vil fortette audit-filen.

Innlesing av en ny, fullstendig versjon av ZAV-dataene og anlegg av en ny versjon av fordelingsrekkefølgedataene, vil begynne som vist i fig. 3, med overføring av nye ZAV-data ved 400. En syntaktisk overprøving av ZAV-dataene, for å sikre riktighet og fullstendighet av datasetningene, vil først utføres 401. For overføring av mellomliggende gjennomførte lokale endringer på den nye versjonen av dataene er det å anbefale, at datasetningene skal kunne identifiseres fra en versjon til den neste. Områder og avsnitt er i ZAV-dataene bare definert som en mengde oversendelsespunktdatasetninger, og vil ved behov genereres i fordelingsrekkefølgedata. For å identifisere oversendelsespunkt-datasetninger, vil identiflkasjonsdata dannes ut fra sorteringskode + husnummerdata + merknad. Sorteringskodene vil vise målet for sorteringen og vil ofte trykkes som strekkode ved brevsendinger ved den automatiserte brevfordelingen. Sorteringskoden må ikke nødvendigvis bestå av postnummer, gatekarakteristikker og husnummer. Fremgangsmåten vil bli dog mer effektiv, når man anvender entydige abstrakte sorteringskoder. Siden som regel ikke alle oversendelsespunkter vil gi en entydig sorteringskode, må husnummerdataene (ofte alfabetisk) og merknadene (f.eks. slakteri), som er tilstede tas hensyn til. Områder og avsnitt har som regel en kjennetegn, som er passende for identifikasjonen. Man må også sikre 402 om den anvendte identifikasjon og identifikasjonsdataene er entydige, alle entydige datasetninger vil lagres i den nye fordelingsrekkefølgedata-versjon, sammen med en ledig audit-fil 402.

Deretter kan innføringene til en eksisterende audit-fil, f.eks. fra den tidligere aktuelle versjon av data, anvendes på de nye dataene 403, for å overføre alle de lokale endringene. Derved må man for det første overprøve hver innføring med hensyn på gyldighet 404. Innføringen er ikke lenger gyldig, f.eks., hvis oversendelsespunktet som skal forskyves allerede ligger på riktig sted. Alle gyldige innføringene vil anvendes 405 av redigeringsprogrammet. Ved bearbeidelse av audit-innføringene i den hittil aktuelle versjon vil audit-innføringer for den nye versjonen av fordelingsrekkefølgedata tilvirkes. Disse audit-innføringene i den nye versjonen vil lagres imellom 406. Alle de ikke-lenger gyldige audit-innføringene vil lagres i en loggfil 407 og de kan ses av operatøren etter behov. Etter at alle audit-innføringene er bearbeidet 408, kan en ny versjon av fordelingsrekkefølgedataene med en som regel mindre audig-fil lagres 409. Hvis den aktualiserte versjonen av ZAV-dataene bare stilles til disposisjon som inkrementell databestand, vil hver databestand i den hittil aktuelle versjonen av fordelingsrekkefølgedataene kombineres til en ny, fullversjon av fordelingsrekkefølgedata. Som vist i fig. 4, vil deretter den aktuelle versjon av fordelingsrekkefølgedataene leses fra harddisken plate 500, derved vil typisk en Hash-tabell ifølge den vanlige programmeringsteknikk bygges i minnet 501, for hurtig å finne oversendelsespunkter for å muliggjøre dette. Som nøkkel i Hash-tabellen tjener de allerede kjente identifikasjonsdataene, som er dannet ut fra sorteringskode + husnummereringsdata + merknader for et oversendelsespunkt. Mange sett av databestander har ingen sorteringskode, i dette tilfellet vil man under importeringen generere den riktige sorteringskoden.

Alle nye oversendelsespunkter vil bearbeides 502 etter hverandre, og først vil man overprøve om oversendelsespunktet allerede eksisterer 503. Hvis det nye oversendelsespunktet allerede eksisterer, vil den relative stillingen sammenlignes med den hittil relative stillingen 504. Hvis stillingene er like, er det ikke nødvendig med ytterligere handlinger. Hvis stillingene er forskjellige, vil oversendelsespunktet tas inn i en liste av oversendelsespunkter som skal slettes 505. Disse oversendelsespunkter som skal forskyves vil også tas inn som nye oversendelsespunkter i en liste av de nye oversendelsespunktene 506. Etter at alle oversendelsespunktene er bearbeidet 507, vil alle oversendelsespunktene som skal slettes fjernes fra databestanden 508. Derved vil alle nye eller forskjøvne oversendelsespunkter tas inn 509. Til slutt kan den nye versjonen av fordelingsrekkefølgedata lagres 510. Derved vil tomme avsnitt og også tomme områder tas bort.

Tjenestekvalitetsmerknadene for et annet sentralt anvendelsessystem vil også forberedes som fil. En merknadsfil kan kombineres med den aktuelle versjonen av fordelingsrekkefølgedata til en ny versjon. Som vist i fig. 5, vil herved først leses den aktuelle versjonen av fordelingsrekkefølgedata fra harddisken 600. Derved vil en Hash-tabell ifølge den kjente programmeringsteknikk som ovenfor beskrevet bygges i minnet 601. Alle merknadene i filen vil bearbeides etter hverandre 602, hvorved for det første vil man overprøve om det aktuelle oversendelsespunkt i det hele tatt eksisterer 603. Hvis oversendelsespunktet eksisterer, vil de hittil anførte merknadene kombineres med de nye merknadene, hvorved de nye merknadene har prioritet 602. Den fullstendige datasetning vil lagres i fordelingsrekkefølgedataene og også som fullstendig SET-innføring i audit-filen 606. Hvis det aktuelle oversendelsespunkt ikke er for hånd, vil en innføring logges i en feil-fil 604. Etter dette vil alle oversendelsespunktene bearbeides 607, og en ny versjon av fordelingsrekkefølgene lagres.

Enkelte audit-filer kan kombineres med den aktuelle versjonen av fordelingsrekkefølgedata til en ny fullstendig versjon. Denne funksjonalitet muliggjør den parallelle bearbeidelse av fordelingsrekkefølgedataene gjennom flere operatører. Som vist i fig. 6, vil man herved for det første lese den aktuelle versjon av fordelingsrekkefølgedataene fra harddisken 700. Derved vil man tilveiebringe en Hash-tabell ifølge den kjente programmeringsteknikk i minnet som ovenfor beskrevet 701. Alle audit-innføringene fra audit-filen vil bearbeides 702, og først vil man overprøve, om hver innføring allerede er gyldig 703. Hvis en innføring ikke kan anvendes, fordi f.eks. oversendelsespunktet ikke er der, vil innføringen lagres i audit-loggfilen 706. Hvis innføringene kan anvendes, vil endringene utføres 704, og en ny innføring vil lagres i audit-filen 706. Etter at alle audit-innføringene er bearbeidet, vil den nye versjonen av fordelingsrekkefølgedata lagres 708.

Claims (6)

1. Fremgangsmåte for automatisk tilvirkning av aktuelle fordelingsrekkefølgedata ved å trekke inn i databanker lagrede og ved elektronisk dataoverføringsoversendte, sentrale adresselister som fordelingsrekkefølgedata, karakterisert ved følgende trinn: - å kopiere lokalt den aktuelle sentrale adresselisten eller de delene som vedrører det relevante området, - å overføre fra lokalt lagrede endringsordre med hensyn til relative posisjonsendringer av oversendelsespunkter i fordelingsrekkefølge for den tidligere versjon av den sentrale adresseliste eller de relevante delene, hvorved oversendelsespunktene identifiseres ved hjelp av identifikasjonsdata, som inneholder i det minste en sorteringskode, til den lokale kopi av den aktuelle adresseliste eller den relevante delen derav, - å overprøve om endringsordrene i den kopierte aktuelle adresselisten allerede er realisert eller om de skal realiseres, - å lagre endringsordrene som skal utføres, og de gyldige endringsordre i en audit-fil og å utføre endringsordrene.

2. Fremgangsmåte ifølge krav 1, karakterisert ved at det lokalt i identifikasjonsdataene i tillegg tas inn husnummerdata.

3. Fremgangsmåte ifølge krav 1 eller 2, karakterisert ved at det lokalt i identifikasjonsdataene i tillegg tas inn karakteriserende merknader.

4. Fremgangsmåte ifølge krav 3,karakterisert ved at det for opptak av ytterligere videreførings- og/eller fordelingsdata i den kopierte adresseliste utføres følgende trinn: - å overprøve om oversendelsespunktet for hver videreførings-, og/eller fordelingshenvisning eksisterer i den kopierte aktuelle adresseliste for fordelingsrekkefølgene eksisterer, hvis ja, - å ta inn den nye videreførings- og/eller fordelingshenvisning i den kopierte adresseliste, hvorved den nye har prioritet i forhold til den gamle tilsvarende videreførings- og/eller fordelingshenvisning og - å ta opp de fullstendige endringsdataene for videreførings- og/eller fordelingshenvisning i audit-filen.

5. Fremgangsmåte ifølge et av kravene 1-4, karakterisert ved at det for aktualisering av den sentrale adresseliste eller adresselistedelen overføres bare inkrementelle endringer ved dataoverføring, som føres sammen med de hittil aktuelle og kopierte adresselister eller adresselistedeler, hvor man ved hjelp av identifikasjonsdataene for hvert oversendelsespunkt i den hittil aktuelle adresseliste eller adresselistedel overprøver om hvert oversendelsespunkt til den inkrementelle endringen allerede er tilstede, og hvis ikke dette er tilfelle, tas det opp med den overførte stilling i fordelingsrekkefølge i den kopierte adresselisten eller adresselistedelen, og hvis ja forskyves oversendelsespunktet i den endrede stillingen i adresselisten.

6. Fremgangsmåte ifølge krav 5, karakterisert ved at det for realisering av forskyvning av et oversendelsespunkt slettes denne i den hittil stillingen i adresselisten slettes og tas inn på nytt i den endrede posisjonen.