Mange installationer kører stadig IMS, fordi IMS ved restart efter et nedbrud kan positionere den næste skrivning til et dataset korrekt. Problemstillingen er typisk, at man læser og opdaterer i DB2 og samtidig skriver til et dataset. Stort set alle installationer sørger for, at deres opdaterende DB2 programmer foretager COMMIT med jævne mellemrum. Desværre har MVS ikke nogen indbygget facilitet til at foretage COMMIT af datasets. Det er her IMS kommer ind i billedet på mange installationer. IBM har udviklet et ikke særlig kendt produkt til at klare situationen i stedet for IMS, men jeg kan ikke huske dets navn. Nogen få installationer har valgt selv at kode noget, så man slipper for IMS og lignende.

Jeg havde længe grublet over, hvor svært det kan være at lave en simpel restart til flade filer i stedet for at anvende diverse typisk dyre produkter. Mit behov var at lave et job, som hvis det gik ned skulle kunne restartes på præcis samme JCL som det oprindeligt blev submittet med. Det giver som regel færrest problemer i en driftsituation. Mit job kom til at bestå af følgende komponenter:

1. Læsning af DB2 restart tabel med information om, dels hvor langt behandlingen var kommet rent DB2-mæssigt, men især om hvor mange records der var skrevet til output datasettet.
2. Hvis der ikke var skrevet nogen records eller restart tabellen ikke indeholdt informationer om nogen nedbrudt kørsel, så antog jeg, at behandlingen startede fra "toppen". I denne situation slettede jeg et eventuelt gammelt output dataset og allokerede et nyt.
3. Hvis der til gengæld var tale om en restart situation, så foretog jeg følgende:
   1. RENAME af output dataset
   2. ALLOC af nyt output dataset med samme attributter som det oprindelige
   3. Kopiering af det antal records, som restart tabellen angav fra det renamede dataset over i det nye.
   4. DELETE af det renamede dataset
4. Kørsel af selve programmet, der altid allokerede output datasettet med DISP=MOD. Hver gang programmet foretog en COMMIT, så opdaterede det lige før COMMIT'en restart tabellen med antallet af skrevne records. Når programmet kørte færdigt uden nedbrud, så sørgede det for at fjerne restart oplysningerne fra restart tabellen.

Ovenstående fremgangsmåde virkede strålende i praksis. Det irriterende ved løsningen er, at man er nødt til at foretage en kopiering, som man oven i købet skal lave et program til at håndtere på den ene eller anden måde. Hvordan du vil implementere fremgangsmåden er helt op til dig. Det kan gøres på et utal af måder.

Der er dog en vigtig detalje, du skal være opmærksom på. Når selve programmet bryder ned, så skal du helst selv få kontrollen, så du pænt kan lukke output datasettet. Hvis du ikke får det, så er der risiko for, at MVS ikke får skrevet alle records ud på disk og dermed kan dit output dataset ende med at indeholde færre records end din restart tabel angiver. Derfor er det vigtigt, at dit kopieringsprogram kan opdage en sådan situation og stoppe videre afvikling.

Fremgangsmåden kan også anvendes til løsninger helt uden DB2. Så skal du bare finde en anden måde at gemme informationen om hvor langt, du er nået.