Konverteringsanlæg
Lige siden begyndelsen har IT-verdenen været velsignet med (eller : været plaget af) et utal af medietyper, hver med et større antal variationer. For ikke at tabe data på gulvet, er det derfor nødvendigt med at kunne flytte data mellem maskiner / medier : d.v.s. mediekonvertering.
Når der tales om ”medietyper”, tænkes der her på fysiske medier, dvs papirbånd, disketter, CDROM, USB stik, magnetkort, magnetbånd, osv. Indenfor hver medietype er der igen variationer : f.eks. 8”, 5.25” og 3.5” disketter, ½”, 1/4”, 8 og 4 mm magnetbånd osv.
Her kan vi igen gå dybere ned ved at kigge på kapacitet/tætheder. F.eks. findes 1/4” magnetbånd med et varierende antal spor, som gør at der på 1 kassette kan være plads til fra 32 MB op til (lige nu) 1.000 GB.
Ud over de fysiske formater som beskrevet ovenfor, findes der et utal af logiske formater. For at tage et eksempel : på 5.25” disketter findes diverse former for DOS, CP/M, Unix, Norsk Data, Philips tekstbehandling, osv.
Så kan vi gå endnu et skridt videre : de logiske formaters interne organisation. Eksempel : en diskettes indhold kan tit bestemmes ved at kigge på filnavnets endelse, f.eks. .DOC eller .JPG. Når denne "interne organisation" ikke er ren tekst, skal der et program til at dekode det
For at kunne håndtere disse medier / filtyper, er der altså 3 krav der skal opfyldes : 1) man skal kunne håndtere mediet fysisk 2) man skal kunne afkode operativsystemet 3) man skal have oplysninger om filernes indhold.
Samme problematik gør sig gældende når man skal skrive et medie, med den tilføjelse at man der skal kunne formattere outputmediet, og skrive data på en sådan måde at det ikke er til at skelne fra hvis man havde skrevet mediet på den oprindelige maskine. Dette er mildt sagt en udfordring, da dokumentationen af de forskellige filtyper ofte er mangelfuld / ikke tilgængelig.
Et ideelt konverteringssystem skal derfor kunne læse og skrive hvad som helst.
Systemet i samlingen kan en hel del, men desværre ikke alt.
Det kan håndtere de ca. 2-3.000 mest almindelige (!) disketteformater, spredt ud over 8”, 5.25” og 3.5” disketter, og det håndterer et større antal SCSI-baserede enheder : DAT, Exabyte, magnetbånd, QIC 3480/3490 og DLT.
Når man endelig har fået indlæst sine data, er det tit nødvendigt at foretage en logisk konvertering. En oplagt opgave er konvertering mellem tegnset, f.eks. EBCDIC til ASCII, konvertering af nationale tegn eller konvertering mellem CodePages (DOS). En anden opgave er konvertering af specielle sekvenser indlejret i teksten. Her tænkes på escapesekvenser, koder for skift af fonttype, og meget andet.
Dette klares på 3 forskellige måder : 1) tegnkonvertering : 1 tegn ind – 0-n tegn ud 2) stringkonvertering : 1-n tegn ind – 0-n tegn ud 3) protocoller : her sker der en decideret databehandling "bag ryggen" på en.
Et eksempel på 3) var en opgave for Skat. Virksomheder kunne indberette mange oplysninger maskinelt, f.eks. import- og listeposteringer, sygedagpenge, og meget andet. Protocollen skulle sikre at angiveren var godkendt (dvs at der var foretaget en prøvekørsel), at han ikke var blacklistet, at de indrapporterede data var korrekt formatteret, at SE-nr var validt, m.v. Som resultat skulle der skrives logliste, evtl. fejlliste, etiketter til returnering af mediet, en statistik for periodens kørsler, og til slut skulle de godkendte data sendes videre til mainframen.
Alt dette skulle principielt kunne programmeres af kunden. For at gøre det så generelt som muligt, blev det besluttet at programmeringen skulle foregå i RPG/II, idet der allerede var RPG viden i organisationen. Denne sourcetekst blev så interpreteret af protocollen (en Windows DLL), der var skrevet i Turbo Pascal for Windows 1.50 (sammenlignelig med Delphi). For at gøre det komplet, skulle der også laves en TPW 1.50 baseret editor til RPG sourceteksten.