Failide haldamine COBOLis on pealtnäha petlikult lihtne. Fail deklareeritakse ENVIRONMENT DIVISIONis, selle kirjete paigutus kirjeldatakse DATA DIVISIONis ning PROCEDURE DIVISIONis kasutatakse OPEN, READ või WRITE ja CLOSE käske. Neli tegusõna, üks elutsükkel. Probleem on selles, et COBOLi programmid jäävad harva lihtsaks, nad koguvad aastakümnete pikkuse hoolduse käigus loogikat, eranditeid, tingimuslikke harusid ja PERFORM-kõnesid. See, mis algab puhta ühekordse avamise ja ühekordse sulgemisena, muteerub vaikselt millekski keerukamaks: failid avatakse kaks korda ühes täitmistees, CLOSE-laused käivituvad siis, kui ühtegi faili pole avatud, viga väljub sellest harust täielikult pärast CLOSE-käsku.
Ükski neist probleemidest pole kohe nähtav. Programm kompileerub. See töötab testitud sisendite puhul sageli vigadeta. See ebaõnnestub vaikselt sisendkombinatsioonide korral, mida te pole kunagi ette näinud, või halvendab partiiakna jõudlust nii järk-järgult, et keegi ei seosta põhjust tagajärjega. Staatiline analüüs leiab need enne, kui midagi sellist juhtub.
Lekketuvastus igas keeles
SMART TS XL kaardistab pikaealised viiteahelad ja piiramatud andmestruktuurid kogu teie koodibaasis.
Rohkem infotNeli faili oleku defekti, mida tasub leida
Enne tuvastusmehaanika juurde asumist on siin selge taksonoomia selle kohta, mida otsite. Kõik COBOL-failiprobleemid ei ole võrdsed.
| Defekt | Mis juhtub käitusajal | Tõsidus |
|---|---|---|
| Topelt AVATUD | AVA juba avatud failil → FAILI OLEK 41 või katkestus | Kõrge |
| SULGE ilma eelneva AVAMISETA | SULGE fail, mida pole kunagi avatud → FAILI OLEK 42 või katkestus | Kõrge |
| Tavalisel väljumisel puudub CLOSE | Fail jäeti lahti STOP RUN-i ajal → OS sulgeb selle, kuid tühjendamata puhvrid riskivad andmete kadumiseni. | Keskmine |
| Vea väljumisel puudub CLOSE | Programmi abend faili avamisel → võimalik kirjete rikkumine VSAM-failides | Kõrge |
| Varustatud AVAMINE/SULGEMINE tsüklis | Fail avatakse ja suletakse igal iteratsioonil → suur sisend-/väljundkulu | Keskmisel kõrgusel |
Peamine järeldus: Kõige tõsisemad vead, topelt AVAMINE ja SULGEMINE ilma AVAMISETA, põhjustavad koheseid käitusaja tõrkeid või andmete terviklikkuse riske. Jõudlusdefektid (tsükli tasemel avamine/sulgemine) ei tekita üldse vigu, vaid aeglaseid partiitöid, mille põhjust keegi pole kindlaks teinud.
Mis teeb selle käsitsi leidmise raskeks
Väljakutse ei ole mustri tuvastamine. Iga arendaja teab, et faili ei tohiks kaks korda avada. Väljakutse seisneb selles, et COBOL-i juhtimisvoog on mittelineaarne, mis muudab käsitsi jälgimise ebausaldusväärseks.
Vaatleme programmi, millel on selline struktuur:
kobol
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.Kas saate defekti märgata ilma iga teostusrada jälgimata? Kui WS-ERROR-FLAG on seespool seatud väärtusele 1 PROCESS-ONE-RECORD (võib-olla kutsutud alamprogrammi abil) suunatakse juhtimine ERROR-EXIT, mis sulgeb faili ja peatub. See on õige. Aga kui WS-ERROR-FLAG is mitte komplekt, tsükkel lõpeb, PROCESS-RECORDS tagasitulekud ja TERMINATION jookseb, mis ka suletakse CUSTOMER-FILEKaks sulgemist, üks avamine. Käitusaja FAILI OLEK 42.
See on lihtne kolmeosaline programm. Pärisprogrammides on kakskümmend osa, tingimuslikud PERFORM-käsud, pärandkoodis GO TO-laused ja erandite käsitlemise rutiinid, mis ise kutsuvad välja teisi rutiine. Käsitsi jälgimine pole mitte ainult veaohtlik, vaid ka raskesti jälgitav.
Kuidas staatilise analüüsi mudelid failide olekut näitavad
Staatiline analüüs tuvastab need defektid, koostades programmi juhtimisvoo graafiku ja levitades faili olekut mööda iga teed.
Analüüs määrab igale failile olekumuutuja, millel on kolm võimalikku väärtust:
CLOSED, faili pole avatud või see suleti edukaltOPEN, fail on avatud ja pole veel suletudUNKNOWN, olekut ei saa staatiliselt määrata (nt tingimuslikult avatud harus, mida pole täielikult analüüsitud)
Iga OPEN-lause puhul kontrollib analüüs järgmist: kas see fail on juba olekus OPENKui jah → topelt AVATUD defekt.
Iga CLOSE-lause korral: kas see fail on olekus CLOSED or UNKNOWN? Kui SULETUD → sulgub ilma avamisdefektita.
Iga STOP RUN või EXIT PROGRAMi teel: kas mõni fail on endiselt olekus OPEN? Kui jah → puudub lähedalolev defekt.
Tsüklite puhul kontrollib analüüs, kas OPEN- või CLOSE-lause domineerib tsükli päises, mis tähendab, et see käivitab iga iteratsiooni.
Vaata ette: Kõige keerulisemad juhtumid iga analüsaatori jaoks on PERFORM-kõned jagatud rutiinidesse. Kui
ERROR-HANDLERkutsutakse programmi kaheteistkümnest erinevast kohast, siis faili olek PERFORM-kutse hetkel määrab, kas seespool sulgemineERROR-HANDLERKas see on õige või vale. Analüsaator, mis ei levita olekut PERFORM-ahelate kaudu, annab vale-negatiivseid (puuduvad tegelikud defektid) või vale-positiivseid (märgistavad õiget koodi).
Silmuse tasemel AVAMINE/SULGEMINE: jõudlusdefekt ilma veakoodita
See muster ei tekita käitusaja vigu ega faili oleku anomaaliat. See lihtsalt töötab aeglaselt, potentsiaalselt suurusjärke aeglasemalt kui vaja.
kobol
*> 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.Kui fail pole füüsiliselt regioonide kaupa jaotatud, põhjustab see lähenemisviis tarbetut lisakoormust. Praktikas oleks parem fail üks kord avada, kõik kirjed läbi lugeda ja filtreerimist rakendada mälus või loogika abil.
Iga AVAMINE (OPEN) VSAM-faili puhul hõlmab kataloogiotsingut, ACB initsialiseerimist ja puhvervaru eraldamist. Iga CLOSE tühjendab puhvrid, värskendab kataloogi ja vabastab ACB. Kümne piirkonnaga faili puhul juhtub see kümme korda ühe asemel. 10 000 kirje ja tuhande piirkonnaga faili puhul muutub matemaatika keeruliseks.
kobol
*> 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.Staatiline analüüs tuvastab selle, tuvastades tsüklipõhised OPEN ja CLOSE laused, st iga tsükli sisu täitmine käivitab OPEN või CLOSE käsu. Tuvastamiseks on vaja, et juhtimisvoo graafik esindaks tsükli struktuuri, mitte ainult lausejada.
FAILI OLEK: Teie programmi faili oleku signaal, kui te seda kontrollite
Iga COBOL-failitoiming määrab FILE-CONTROL kirjes määratletud FILE STATUS välja. Programm, mis kontrollib FILE STATUS välja pärast iga OPEN, READ, WRITE ja CLOSE toimingut, suudab tuvastada ja reageerida igale faili oleku anomaaliale käitusajal. Programm, mis ignoreerib FILE STATUS välja, on eksiteel.
Kontrollnimekiri: faili staatuse koodid, mida iga COBOL-i arendaja peaks teadma
00Edukas lõpetamine10, Faili lõpp (LOETUD: rohkem kirjeid pole)35, Faili ei leitud (AVATUD SISEND: faili pole olemas)41, Fail on juba avatud (AVATUD faili puhul, mis on AVATUD olekus)42Fail pole avatud (SULETUD või LUETUD faili puhul, mis on SULETUD olekus)47, READ prooviti faililt, mida pole avatud INPUT või IO48, KIRJUTAMISE katse failile, mida pole avatud OUTPUT, IO või EXTEND97, Fail avati edukalt (IBM-spetsiifiline, mõned keskkonnad)
kobol
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.Vaata ette: Levinud hooldusviga on FILE STATUS'i deklareerimine FILE-CONTROL kirjes, kuid mitte viitamine sellele
WS-CUST-FILE-STATUSPROTSEDUURI JAGUSES. See väli täidetakse pärast iga failitoimingut, aga kui koodi pole, siis programm möödub vigadest vaikselt. Staatiline analüüs saab märkida selle mustri: FAILI OLEK on deklareeritud, aga tingimusloogikas sellele pole kunagi viidatud.
Kolm reaalse maailma COBOL-mustrit, mis põhjustavad defekte
Muster 1: Jagatud vea-väljumisprobleem
Programmil on mitu töötlussektsiooni, millest igaühel on oma veakäitleja. Mitu veakäitlejat sulgevad faili enne naasmist. Tavaline lõpetamisrutiin sulgeb faili samuti. Kui ilmneb tõrge ja taastamine jätkub veakäitlejast mööda minnes, suletakse fail kaks korda.
kobol
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.. GO TO TERMINATION annab kontrolli otse üle TERMINATION, mis täidab oma CLOSE CUSTOMER-FILE. FAILIDE STAATUS 42.
Parandus: Kasutage ühte tsentraliseeritud sulgemisrutiini. Iga väljumistee kutsub välja sama rutiini, mis kontrollib enne sulgemist, kas fail on avatud.
Muster 2: Tingimuslik AVAMINE
Fail avatakse tingimuslikult ainult siis, kui teatud töötlusrežiim on aktiivne. Kuid SULGEMINE on tingimusteta ja toimub igal täitmisteel, sealhulgas neil, kus faili kunagi ei avatud.
kobol
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.See defekt on testimisel nähtamatu, kui testid töötavad alati TÄISrežiimis. Tootmises ilmneb see esimesel OSALISE režiimi käivitamisel.
Muster 3: PERFORM kõigis kompileerimisüksustes
Programmides, mis kasutavad alamprogrammide kutsumiseks CALL-i, võidakse põhiprogrammis avatud fail edastada alamprogrammile, mis selle sulgeb, seejärel sulgeb põhiprogramm selle uuesti.
kobol
*> Main program
CALL 'SUBPROG1' USING CUSTOMER-FILE-STATUS
*> SUBPROG1 closes CUSTOMER-FILE internally
CLOSE CUSTOMER-FILE *> double closeSee muster nõuab protseduuridevahelist analüüsi , faili oleku jälgimist üle CALL-piiri alamprogrammi käitumiseni, mida lihtne programmisisene analüüs ei suuda tuvastada.
Mida staatiline analüsaator vajab, et seda hästi teha
Kõik staatilise analüüsi tööriistad ei suuda COBOL-faili oleku analüüsiga võrdse sügavusega hakkama saada. Siin on otsustusloend võimekuse hindamiseks:
Kas tööriist käsitleb PERFORM-ahelaid? COBOL-programmid kasutavad PERFORM-i nimega lõikude ja sektsioonide kutsumiseks. PERFORM-i sihtmärgi sees olevad failioperatsioonid peavad olema kutsuja oleku jälgimisele nähtavad.
Kas tööriist käsitleb reasiseseid PERFORM VARYING (tsükleid)? Tsüklite tuvastamine on vajalik tsüklite domineerivate AVAMIS-/SULGEMIStoimingute tuvastamiseks.
Kas see jälgib olekut GO TO piires? Vanad COBOL-programmid kasutavad GO TO-d laialdaselt. Analüsaator, mis ei suuda juhtimisvoo graafikul GO TO servi jälgida, jätab terved defektide klassid kahe silma vahele.
Kas see toetab COPY ja REPLACE toiminguid? Failihalduskood on sageli COPY liikmete hulgas. Analüsaator, mis ei laienda COPY liikmeid enne analüüsi, jätab vahele kaasatud koodis määratletud toimingud.
Kas see kontrollib faili staatuse (FILE STATUS) kasutamist? Täielik analüüs kontrollib mitte ainult seda, kas faili staatus on deklareeritud, vaid ka seda, kas seda tegelikult pärast iga toimingut kontrollitakse.
Kas see teostab protseduuridevahelist analüüsi? Failioperatsioone teostavad CALL-alamprogrammid loovad programmidevahelisi oleku sõltuvusi. Tõeline katvus nõuab järgnevaid CALL-ahelaid.
Peamine järeldus: Tööriist, mis kontrollib ainult ühte lõiku või sektsiooni, jätab enamiku reaalsetest defektidest märkamata. Tootmises olulised defektid, mille ilmnemine võttis aastaid ja diagnoosimine tunde, on need, mis hõlmavad mitut sektsiooni, tingimuslikke harusid ja nn rutiine.
Mida tulemustega peale hakata: prioriseerimise raamistik
Kui staatiline analüüs toob välja failivigu, ei ole kõik leiud võrdsed. Siin on, kuidas neid triaažida:
Paranda kohe (enne järgmist partii käivitamist):
- Topelt OPEN mis tahes täitmisteel, kus FILE STATUS 41 põhjustaks abendi
- CLOSE ilma OPENita tootmiskeskkonnas käivitatavates radades
- VSAM-failide vea väljumisteedel puudub CLOSE (kirjutamise terviklikkuse risk)
Järgmise sprindi ajakava:
- Tsüklipõhine AVAMINE/SULGEMINE mõõdetava partiiakna mõjuga
- Kriitiliste failide (audit, tehing, aruanne) FAILIDE STAATUSE kontrollid puuduvad
- Tingimuslik AVAMINE koos tingimusteta SULGEMISEGA mitme režiimiga programmides
Jälgimine ja aadress järgmise moderniseerimispassi ajal:
- Puuduvad FILE STATUS deklaratsioonid
- CLOSE ainult tavalistel väljumisteedel (operatsioonisüsteem tegeleb sellega, aga halb tava)
- Protseduuridevahelised defektid, mille parandamiseks on vaja muudatuste koordineerimist mitme programmi vahel
Kuidas SMART TS XL Analüüsib COBOL-faili olekut
SMART TS XL'S staatilise koodi analüüs loob iga keskkonnas oleva COBOL-programmi juhtimisvoo mudeli, laiendades COPY liikmeid, järgides PERFORM-ahelaid, jälgides GO TO servi ja levitades faili olekut iga tingimusliku käsu iga haru kaudu. See ei ole mustrite sobitamise skaneerimine; see on struktuurimudel sellest, mida programm tegelikult igas oma täitmise saavutatavas punktis teeb.
Rakenduse sõltuvuste kaardistamise võimalus laiendab seda interprotseduurilisele dimensioonile: kui COBOL-programm kutsub välja alamprogrammi, mis teostab failitoiminguid, esindab sõltuvuskaart seda suhet, võimaldades analüüsi, mis ületab kompileerimisüksuste piire. Topelt OPEN-vead, mis ulatuvad põhiprogrammi ja kutsutud alamprogrammi vahel, on struktuurimudelis nähtavad viisil, mida nad ei ole üheski programmisiseses analüüsis.
Ettevõtte otsinguvõimalus muudab tulemused ulatuslikult rakendatavaks: leia sekunditega iga portfelli programm, mis avab konkreetse andmestiku, iga COPY liige, mis sisaldab CLOSE-lauset, iga programm, mille PERFORM-sihtmärk sisaldab OPEN-lauset, miljonite COBOL-ridade kaudu. Moderniseerimismeeskonna jaoks, kes valmistub partiitöökoormust pilve migreerima, muudab see otsinguvõimalus nädalatepikkuse käsitsi auditi sihipäraseks päringuks.
JCL -i laiendusvõimalus lisab operatiivse konteksti: millised JCL-i tööetapid iga programmi käivitavad, millistele andmekogumitele iga DD-lause viitab ja kuidas failide käsitlemine COBOL-koodis ühendub JCL-is määratletud füüsiliste andmekogumitega. CLOSE-defekt failis, mille JCL määratleb kriitilise väljundandmekogumina, on kõrgema prioriteediga kui sama defekt ajutises tööfailis ning see prioriseerimine nõuab iga COBOL-programmi JCL-konteksti tundmist.
Laiem õppetund: faili olek on vaid üks dimensioon
Üleliigsed failioperatsioonid on spetsiifiline näide üldisemast probleemist: aastakümnete jooksul arenenud COBOL-programmid sisaldavad olekust sõltuvaid käitumisviise, faili olekut, lüliti olekuid, loenduri olekuid, mida saab õigesti mõista ainult siis, kui jälgida kõiki võimalikke täitmisteid läbi kogu juhtimisvoo graafiku.
Sellise koodi inimese poolt läbivaatamine on aeglane, mittetäielik ja ebajärjekindel. Erinevad arendajad leiavad erinevaid defekte. Sama arendaja, kes vaatab sama programmi kaks korda üle, leiab erinevaid defekte. Staatiline analüüs on süstemaatiline: see rakendab samu reegleid igale teele igas programmis, iga kord, ilma väsimise või eeldusteta.
Suuri COBOL-portfelle haldavate meeskondade jaoks – olgu selleks siis pidev hooldus, päranduseks mõeldud moderniseerimisprogrammid või vastavusauditid – ei ole süstemaatilise failide oleku analüüsi tasuvus mitte ainult leitud defektid. See on kindlustunne, et portfelli on täielikult analüüsitud ja et allesjäänud defektid on teada, mitte varjatud.
