Práce se soubory v COBOLu je na první pohled zdánlivě jednoduchá. Soubor deklarujete v větvi ENVIRONMENT DIVISION, v větvi DATA DIVISION popíšete rozvržení jeho záznamů a v větvi PROCEDURE DIVISION použijete příkazy OPEN, READ nebo WRITE a CLOSE. Čtyři slovesa, jeden životní cyklus. Problém je v tom, že programy v COBOLu zřídka zůstávají jednoduché, během desetiletí údržby hromadí logiku, cesty k výjimkám, podmíněné větvení a volání PERFORM. Co začíná jako čistý vzorec jednoduchého otevření a zavření, se tiše mění v něco složitějšího: soubory otevřené dvakrát v jedné spouštěcí cestě, příkazy CLOSE, které se spouštějí, když není otevřen žádný soubor, chyba opustí tuto větev za větví CLOSE.
Žádný z těchto problémů není okamžitě viditelný. Program se kompiluje. Často běží bez chyby na vstupech, které testujete. Tiše selhává na vstupních kombinacích, které jste nikdy nepředpokládali, nebo snižuje výkon dávkového okna tak postupně, že nikdo nespojí příčinu s následkem. Statická analýza je najde dříve, než k něčemu z toho dojde.
Detekce úniků napříč všemi jazyky
SMART TS XL mapuje dlouhodobé referenční řetězce a neohraničené datové struktury v celé vaší kódové základně.
Více informacíČtyři vady stavu souborů, které stojí za to najít
Než se pustíme do detekčních mechanismů, zde je jasný přehled toho, co hledáte. Ne všechny problémy se soubory COBOL jsou stejné.
| Přeběhnout | Co se děje za běhu | Přísnost |
|---|---|---|
| Dvojité otevření | OTEVŘÍT u již otevřeného souboru → STAV SOUBORU 41 nebo ukončit | Vysoký |
| ZAVŘÍT bez předchozího OTEVŘÍT | ZAVŘENÍ souboru, který nebyl nikdy otevřen → STAV SOUBORU 42 nebo ukončení | Vysoký |
| Chybí tlačítko ZAVŘÍT na normálním výjezdu | Soubor ponechaný otevřený při STOP RUN → OS jej zavře, ale nevyprázdněné vyrovnávací paměti riskují ztrátu dat | Střední |
| Chybí CLOSE při chybném ukončení | Program se zastaví při otevření souboru → možné poškození záznamů v souborech VSAM | Vysoký |
| Redundantní OTEVŘÍT/ZAVŘÍT ve smyčce | Soubor se otevíral a zavíral při každé iteraci → vysoká režie I/O | Středně vysoká |
Klíčové ponaučení: Nejzávažnější chyby, dvojité OPEN a CLOSE bez OPEN, způsobují okamžité selhání za běhu nebo rizika pro integritu dat. Chyby výkonu (otevírání/zavírání na úrovni smyčky) nezpůsobují žádnou chybu, pouze pomalé dávkové úlohy, u kterých nikdo nezjistil příčinu.
Co ztěžuje ruční nalezení
Problém nespočívá v identifikaci vzoru. Každý vývojář ví, že by se soubor neměl otevírat dvakrát. Problém je v tom, že tok řízení COBOLu je nelineární v tom smyslu, že ruční trasování je nespolehlivé.
Uvažujme program s touto strukturou:
cobol
PROCEDURE DIVISION.
MAIN-LOGIC.
PERFORM INITIALIZATION
PERFORM PROCESS-RECORDS
PERFORM TERMINATION
STOP RUN.
INITIALIZATION.
OPEN INPUT CUSTOMER-FILE
OPEN OUTPUT REPORT-FILE
MOVE 0 TO WS-ERROR-FLAG.
PROCESS-RECORDS.
READ CUSTOMER-FILE INTO WS-CUSTOMER-REC
AT END MOVE 1 TO WS-EOF-FLAG
END-READ
IF WS-ERROR-FLAG = 1
PERFORM ERROR-EXIT
END-IF
PERFORM UNTIL WS-EOF-FLAG = 1
PERFORM PROCESS-ONE-RECORD
READ CUSTOMER-FILE INTO WS-CUSTOMER-REC
AT END MOVE 1 TO WS-EOF-FLAG
END-EXEC
END-PERFORM.
ERROR-EXIT.
DISPLAY 'Error in processing'
CLOSE CUSTOMER-FILE *> CLOSE here...
STOP RUN.
TERMINATION.
CLOSE CUSTOMER-FILE *> ...and CLOSE here too
CLOSE REPORT-FILE
STOP RUN.Dokážete odhalit vadu bez sledování všech cest provádění? Pokud WS-ERROR-FLAG je uvnitř nastaveno na 1 PROCESS-ONE-RECORD (možná volaným podprogramem), řízení pokračuje do ERROR-EXIT, který zavře soubor a zastaví se. To je správně. Ale pokud WS-ERROR-FLAG is ne nastaveno, smyčka se dokončí, PROCESS-RECORDS výnosy a TERMINATION běží, což se také zavírá CUSTOMER-FILEDva zavření, jeden otevření. STAV SOUBORU ZA RUNTÁŽE 42.
Toto je jednoduchý program se třemi částmi. Skutečné programy mají dvacet částí, podmíněná volání PERFORM, příkazy GO TO ve starším kódu a rutiny pro ošetření výjimek, které samy volají jiné rutiny. Ruční trasování je nejen náchylné k chybám, ale také není zvládnutelné.
Jak statická analýza modeluje stav souborů
Statická analýza detekuje tyto vady konstrukcí grafu toku řízení programu a šířením stavu souboru podél každé cesty.
Analýza přiřadí každému souboru stavovou proměnnou se třemi možnými hodnotami:
CLOSED, soubor nebyl otevřen nebo byl úspěšně uzavřenOPEN, soubor byl otevřen, ale ještě nebyl uzavřenUNKNOWN, stav nelze určit staticky (např. podmíněné otevření ve větvi, která není plně analyzována)
Při každém příkazu OPEN analýza kontroluje: zda je tento soubor již ve stavu OPENPokud ano → dvojitá závada OTEVŘENO.
Při každém příkazu CLOSE: je tento soubor ve stavu CLOSED or UNKNOWNPokud ZAVŘENO → zavřeno bez závady otevření.
Na každé cestě k STOP RUN nebo EXIT PROGRAM: je nějaký soubor stále ve stavu OPENPokud ano → chybí blízká vada.
U smyček analýza kontroluje, zda je příkaz OPEN nebo CLOSE ovládán hlavičkou smyčky, což znamená, že se provede v každé iteraci.
Dávej si pozor: Nejtěžšími případy pro jakýkoli analyzátor jsou volání PERFORM do sdílených rutin. Pokud
ERROR-HANDLERje volána z dvanácti různých míst v programu, stav souboru v okamžiku volání PERFORM určuje, zda se má zavřít uvnitřERROR-HANDLERje správný nebo chybný. Analyzátor, který nešíří stav prostřednictvím řetězců PERFORM, bude produkovat falešně negativní (chybějící skutečné defekty) nebo falešně pozitivní výsledky (označení správného kódu).
OTEVŘENÍ/ZAVŘENÍ na úrovni smyčky: Výkonnostní vada bez chybového kódu
Tento vzorec neprodukuje žádnou chybu za běhu ani anomálii STAVU SOUBORU. Běží jednoduše pomalu, potenciálně o řády pomaleji, než je nutné.
cobol
*> PROBLEMATIC: file opened and closed on every iteration
PROCESS-ALL-REGIONS.
PERFORM VARYING WS-REGION-ID FROM 1 BY 1
UNTIL WS-REGION-ID > 10
OPEN INPUT CUSTOMER-FILE
PERFORM PROCESS-REGION-RECORDS
CLOSE CUSTOMER-FILE
END-PERFORM.Pokud není soubor fyzicky rozdělen podle oblastí, způsobuje tento přístup zbytečné režijní náklady. V praxi by bylo lepší soubor otevřít jednou, přečíst všechny záznamy a filtrovat v paměti nebo pomocí logiky.
Každé OPEN u souboru VSAM zahrnuje vyhledávání v katalogu, inicializaci ACB a alokaci bufferového fondu. Každé CLOSE vyprázdní buffery, aktualizuje katalog a uvolní ACB. U souboru s deseti regiony se to stane desetkrát místo jednou. U souboru s 10 000 záznamy a tisícem regionů se matematika stává složitou.
cobol
*> CORRECT: open once, filter inside the loop
PROCESS-ALL-REGIONS.
OPEN INPUT CUSTOMER-FILE
PERFORM VARYING WS-REGION-ID FROM 1 BY 1
UNTIL WS-REGION-ID > 10
PERFORM PROCESS-REGION-RECORDS
END-PERFORM
CLOSE CUSTOMER-FILE.Statická analýza to detekuje identifikací příkazů OPEN a CLOSE, které jsou dominovány smyčkou, tj. každé provedení těla smyčky provede příkaz OPEN nebo CLOSE. Detekce vyžaduje, aby graf toku řízení reprezentoval strukturu smyčky, nikoli pouze posloupnost příkazů.
STAV SOUBORU: Signál stavu souboru vašeho programu, pokud ho zaškrtnete
Každá operace se souborem v COBOLu nastaví pole FILE STATUS definované v položce FILE-CONTROL. Program, který kontroluje FILE STATUS po každém OPEN, READ, WRITE a CLOSE, dokáže za běhu detekovat a reagovat na každou anomálii stavu souboru. Program, který FILE STATUS ignoruje, letí naslepo.
Kontrolní seznam: Kódy stavu souborů, které by měl znát každý vývojář v COBOLu
00Úspěšné dokončení10, Konec souboru (ČTENÍ: žádné další záznamy)35, Soubor nenalezen (OPEN INPUT: soubor neexistuje)41, Soubor je již otevřený (OPEN u souboru ve stavu OPEN)42, Soubor se neotevřel (CLOSE nebo READ u souboru v CLOSED stavu)47, Pokus o ČTENÍ souboru nebyl otevřen VSTUP nebo IO48, Pokus o zápis do souboru nebyl otevřen. OUTPUT, IO nebo EXTEND97, Soubor byl úspěšně otevřen (specifické pro IBM, některá prostředí)
cobol
FILE-CONTROL.
SELECT CUSTOMER-FILE
ASSIGN TO CUSTFILE
FILE STATUS IS WS-CUST-FILE-STATUS.
WORKING-STORAGE SECTION.
01 WS-CUST-FILE-STATUS PIC XX.
PROCEDURE DIVISION.
OPEN INPUT CUSTOMER-FILE
IF WS-CUST-FILE-STATUS NOT = '00'
DISPLAY 'OPEN failed: ' WS-CUST-FILE-STATUS
PERFORM ABEND-ROUTINE
END-IF.Dávej si pozor: Častou chybou údržby je deklarace stavu souboru (FILE STATUS) v položce FILE-CONTROL, ale nikdy se na něj neodkazuje.
WS-CUST-FILE-STATUSv PROCEDURE DIVISION. Pole se vyplní po každé operaci se souborem, ale pokud jej žádný kód nekontroluje, program tiše proběhne přes chyby. Statická analýza může označit tento vzorec: STAV SOUBORU deklarovaný, ale nikdy neodkazovaný v podmíněné logice.
Tři reálné vzory v COBOLu, které způsobují vady
Vzor 1: Problém sdíleného chybového ukončení
Program má více sekcí pro zpracování, z nichž každá má svůj vlastní obslužný rutinu chyb. Několik obslužných rutin chyb soubor před návratem zavře. Normální rutina pro ukončení také soubor zavře. Pokud dojde k chybě a obnova pokračuje přes obslužnou rutinu chyb, soubor se zavře dvakrát.
cobol
VALIDATE-RECORDS.
READ CUSTOMER-FILE INTO WS-REC
AT END MOVE 1 TO WS-EOF
END-READ
IF WS-CUST-FILE-STATUS NOT = '00' AND '10'
CLOSE CUSTOMER-FILE *> closes here on read error
PERFORM WRITE-ERROR-LOG
GO TO TERMINATION *> skips to close in TERMINATION?
END-IF.
TERMINATION.
CLOSE CUSTOMER-FILE *> double close if GO TO reached here
CLOSE REPORT-FILE
STOP RUN.Jedno GO TO TERMINATION přenáší kontrolu přímo do TERMINATION, který provádí vlastní CLOSE CUSTOMER-FILESTAV SOUBORU 42.
Oprava: Použijte jednu centralizovanou zavírací rutinu. Každá ukončovací cesta volá stejnou rutinu, která před zavřením kontroluje, zda je soubor otevřený.
Vzor 2: Podmíněný OPEN
Soubor se otevírá podmíněně, pouze když je aktivní určitý režim zpracování. Zavření je však bezpodmínečné a probíhá v každé cestě provádění, včetně těch, kde soubor nebyl nikdy otevřen.
cobol
INITIALIZATION.
IF WS-PROCESSING-MODE = 'FULL'
OPEN OUTPUT AUDIT-FILE *> only opened in FULL mode
END-IF.
TERMINATION.
CLOSE AUDIT-FILE *> ALWAYS closes -- FILE STATUS 42 in PARTIAL mode
STOP RUN.Tato vada je v testování neviditelná, pokud testy vždy běží v PLNÉM režimu. V produkčním prostředí se objeví při prvním spuštění v ČÁSTEČNÉM režimu.
Vzor 3: PERFORM napříč kompilačními jednotkami
V programech, které používají CALL k vyvolání podprogramů, může být soubor otevřený v hlavním programu předán podprogramu, který jej zavře, a poté jej hlavní program znovu zavře.
cobol
*> Main program
CALL 'SUBPROG1' USING CUSTOMER-FILE-STATUS
*> SUBPROG1 closes CUSTOMER-FILE internally
CLOSE CUSTOMER-FILE *> double closeTento vzorec vyžaduje interprocedurální analýzu , která sleduje stav souboru přes hranici CALL do chování podprogramu, což jednoduchá vnitroprogramová analýza nedokáže detekovat.
Co potřebuje statický analyzátor, aby to zvládl dobře
Ne všechny nástroje pro statickou analýzu zvládají analýzu stavu souborů v COBOLu se stejnou hloubkou. Zde je kontrolní seznam pro vyhodnocení kapacity:
Zvládá nástroj řetězce PERFORM? Programy v COBOLu používají PERFORM k volání pojmenovaných odstavců a sekcí. Operace se soubory uvnitř cíle PERFORM musí být viditelné pro sledování stavu volajícího.
Zpracovává nástroj inline operace PERFORM VARYING (smyčky)? Detekce smyček je nutná k identifikaci operací OPEN/CLOSE s dominantními smyčkami.
Sleduje stav napříč okny GO TO? Starší programy v COBOLu hojně používají oknu GO TO. Analyzátor, který nedokáže sledovat hrany okny GO TO v grafu toku řízení, přehlédne celé třídy defektů.
Zpracovává COPY a REPLACE? Kód pro práci se soubory je často v členech COPY. Analyzátor, který před analýzou nerozšiřuje členy COPY, přehlédne operace definované v přiloženém kódu.
Kontroluje se využití STAVU SOUBORU? Kompletní analýza kontroluje nejen to, zda je STAV SOUBORU deklarován, ale i to, zda je po každé operaci skutečně ověřen.
Provádí interprocedurální analýzu? Volané podprogramy, které provádějí operace se soubory, vytvářejí závislosti na stavech mezi programy. Skutečné pokrytí vyžaduje dodržování řetězců volání.
Klíčové ponaučení: Nástroj, který kontroluje pouze jeden odstavec nebo sekci, přehlédne většinu reálných vad. Vady, které jsou důležité v produkčním prostředí, ty, jejichž objevení trvalo roky a jejich diagnostika hodiny, jsou ty, které se rozprostírají přes více sekcí, podmíněných větví a nazývaných rutin.
Co dělat s výsledky: Rámec pro stanovení priorit
Když statická analýza odhalí vady, ne všechny nálezy jsou stejné. Zde je návod, jak je třídit:
Okamžitě opravte (před dalším dávkovým spuštěním):
- Dvojité OPEN v jakékoli cestě spuštění, kde by stav souboru 41 způsobil ukončení.
- CLOSE bez OPEN v cestách, které se spouštějí v produkčním prostředí
- Chybí CLOSE u chybových výstupních cest pro soubory VSAM (riziko integrity zápisu)
Harmonogram pro další sprint:
- OTEVŘENÍ/ZAVŘENÍ s dominancí smyčky s měřitelným dopadem na dávkové okno
- Chybějící kontroly STAVU SOUBORU u kritických souborů (audit, transakce, zpráva)
- Podmíněné OTEVŘENÍ s bezpodmínečným ZAVŘENÍm v multirežimových programech
Sledování a adresa během další modernizační jízdy:
- Chybějící deklarace FILE STATUS
- ZAVŘÍT pouze na normálních výstupních cestách (OS to zvládá, ale je to špatný postup)
- Meziprocedurální vady, kde oprava vyžaduje koordinaci změn napříč více programy
Jak SMART TS XL Analyzuje stav souboru COBOL
SMART TS XLJe statická analýza kódu vytváří model toku řízení každého programu v COBOLu v daném prostředí, rozšiřuje členy COPY, sleduje řetězce PERFORM, trasuje hrany GO TO a šíří stav souboru každou větví každého podmíněného příkazu. Nejedná se o porovnávání vzorů; jedná se o strukturální model toho, co program skutečně dělá v každém dosažitelném bodě svého provádění.
Schopnost mapování závislostí aplikací rozšiřuje tuto funkci i na interprocedurální dimenzi: když program v COBOLu volá podprogram, který provádí operace se soubory, mapa závislostí představuje tento vztah, což umožňuje analýzu, která překračuje hranice kompilačních jednotek. Defekty dvojitého OPEN, které se rozprostírají v hlavním programu a volaném podprogramu, jsou ve strukturálním modelu viditelné způsobem, jakým nejsou viditelné v žádné intraprogramové analýze.
Díky podpůrnému vyhledávání lze výsledky aplikovat ve velkém měřítku: během několika sekund lze nalézt každý program v portfoliu, který otevírá konkrétní datovou sadu, každý člen COPY obsahující příkaz CLOSE, každý program, jehož cíl PERFORM obsahuje příkaz OPEN, napříč miliony řádků jazyka COBOL. Pro modernizační tým, který se připravuje na migraci dávkové úlohy do cloudu, tato vyhledávací funkce promění týdenní manuální audit v cílený dotaz.
Možnost rozšíření JCL přidává operační kontext: které kroky úlohy JCL vyvolávají každý program, na které datové sady se odkazuje každý příkaz DD a jak se zpracování souborů v kódu COBOL připojuje k fyzickým datovým sadám definovaným v JCL. Defekt CLOSE v souboru, který JCL definuje jako kritickou výstupní datovou sadu, má vyšší prioritu než stejný defekt v dočasném pracovním souboru a toto stanovení priorit vyžaduje znalost kontextu JCL každého programu COBOL.
Širší ponaučení: Stav souboru je jen jeden rozměr
Redundantní operace se soubory jsou specifickým příkladem obecnějšího problému: programy v COBOLu, které se vyvíjely po celá desetiletí, obsahují chování závislé na stavu, stav souboru, stavy přepínačů, stavy čítačů, které lze správně pochopit pouze sledováním všech možných cest provádění v celém grafu toku řízení.
Lidská kontrola tohoto druhu kódu je pomalá, neúplná a nekonzistentní. Různí vývojáři nacházejí různé chyby. Stejný vývojář, který kontroluje stejný program dvakrát, najde různé chyby. Statická analýza je systematická: aplikuje stejná pravidla na každou cestu v každém programu, pokaždé, bez únavy nebo předpokladů.
Pro týmy spravující rozsáhlá portfolia v COBOLu, ať už se jedná o průběžnou údržbu, programy modernizace starších systémů nebo audity shody s předpisy, není odměnou systematické analýzy stavu souborů pouze nalezené vady. Je to jistota, že portfolio bylo kompletně analyzováno a že zbývající vady jsou známé, nikoli skryté.
