COBOL'da dosya işlemleri yüzeysel olarak oldukça basittir. ENVIRONMENT DIVISION'da bir dosya tanımlarsınız, DATA DIVISION'da kayıt düzenini açıklarsınız ve PROCEDURE DIVISION'da OPEN, READ veya WRITE ve CLOSE komutlarını kullanırsınız. Dört fiil, tek bir yaşam döngüsü. Sorun şu ki, COBOL programları nadiren basit kalır; on yıllarca süren bakımda mantık, istisna yolları, koşullu dallanmalar ve PERFORM çağrıları biriktirirler. Temiz, tek açma, tek kapatma modeli olarak başlayan şey, sessizce daha karmaşık bir şeye dönüşür: tek bir yürütme yolunda iki kez açılan dosyalar, açık dosya olmadığında çalışan CLOSE ifadeleri, hatanın CLOSE'dan sonraki dalı tamamen terk etmesi.
Bu sorunların hiçbiri hemen görünür değil. Program derleniyor. Genellikle test ettiğiniz girdilerde hatasız çalışıyor. Hiç beklemediğiniz girdi kombinasyonlarında sessizce başarısız oluyor veya toplu işlem penceresi performansını o kadar kademeli olarak düşürüyor ki kimse neden-sonuç ilişkisini kuramıyor. Statik analiz, bunların hiçbiri gerçekleşmeden önce sorunları buluyor.
Her Dilde Sızıntı Tespiti
SMART TS XL Uzun ömürlü referans zincirlerini ve sınırsız veri yapılarını tüm kod tabanınıza eşler.
Daha fazla bilgiBulunmaya Değer Dört Dosya Devlet Hatası
Tespit mekaniğine geçmeden önce, aradığınız şeyin net bir sınıflandırmasını sunalım. Tüm COBOL dosyası sorunları aynı değildir.
| kusur | Çalışma Zamanında Neler Oluyor? | Şiddet |
|---|---|---|
| Çift AÇIK | Zaten açık olan bir dosyayı açmak → DOSYA DURUMU 41 veya dosyanın kapanması | Yüksek |
| Önceden açmadan KAPAT | Hiç açılmamış bir dosyayı kapat → Dosya durumu 42 veya sonlandırma hatası | Yüksek |
| Normal çıkışta KAPAT seçeneği eksik. | STOP RUN komutu açık bırakıldığında dosya kapanır → İşletim sistemi dosyayı kapatır, ancak boşaltılmamış tamponlar veri kaybı riskini taşır. | Orta |
| Hata çıkışında CLOSE eksik. | Dosya açılırken program sonlanıyor → VSAM dosyalarında olası kayıt bozulması | Yüksek |
| Döngü içinde gereksiz AÇMA/KAPATMA işlemi | Her yinelemede dosya açılıp kapatılıyor → ciddi G/Ç yükü | Orta Yüksek |
Özetle: En yüksek önem derecesine sahip hatalar, çift OPEN ve OPEN olmadan CLOSE işlemleri, anında çalışma zamanı hatalarına veya veri bütünlüğü risklerine yol açar. Performans hataları (döngü seviyesinde açma/kapama) ise hiçbir hata üretmez, sadece kimsenin nedenini bulamadığı yavaş toplu işlere neden olur.
Bunu manuel olarak bulmayı zorlaştıran nedir?
Buradaki zorluk, kalıbı belirlemek değil. Herhangi bir geliştirici, bir dosyayı iki kez açmaması gerektiğini bilir. Zorluk, COBOL kontrol akışının doğrusal olmayan yapısı nedeniyle manuel izlemenin güvenilmez olmasıdır.
Şu yapıya sahip bir programı ele alalım:
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.Her bir yürütme yolunu izlemeden hatayı tespit edebilir misiniz? WS-ERROR-FLAG İçerisi 1 olarak ayarlanmıştır. PROCESS-ONE-RECORD (belki de çağrılan bir alt program aracılığıyla), kontrol akışları şuraya yönelir: ERROR-EXITBu, dosyayı kapatır ve işlemi durdurur. Bu doğru. Ama eğer WS-ERROR-FLAG is değil Ayarlandığında, döngü tamamlanır. PROCESS-RECORDS geri döner ve TERMINATION koşuyor, bu da kapanıyor. CUSTOMER-FILEİki kapanış, bir açılış. Çalışma zamanı dosya durumu 42.
Bu, basit üç bölümlü bir program. Gerçek programlar yirmi bölüme, koşullu PERFORM çağrılarına, eski kodlardaki GO TO ifadelerine ve kendi içlerinde başka rutinleri çağıran istisna işleme rutinlerine sahiptir. Manuel izleme yalnızca hataya açık değil, aynı zamanda yönetilemez de.
Statik Analiz Dosya Durumunu Nasıl Modeller?
Statik analiz , programın kontrol akış grafiğini oluşturarak ve dosya durumunu her yol boyunca yayarak bu kusurları tespit eder .
Analiz, her dosyaya üç olası değere sahip bir durum değişkeni atar:
CLOSEDDosya açılmadı veya başarıyla kapatıldı.OPENDosya açıldı ancak henüz kapatılmadı.UNKNOWNDurum statik olarak belirlenemez (örneğin, tam olarak analiz edilmemiş bir dalda koşullu açma işlemi).
Her OPEN ifadesinde, analiz şu kontrolü yapar: Bu dosya zaten mevcut durumda mı? OPEN? Eğer evet ise → çift AÇIK hata.
Her CLOSE komutunda: bu dosya şu durumda mı? CLOSED or UNKNOWN? Eğer KAPALI ise → açık arıza olmadan kapatın.
STOP RUN veya EXIT PROGRAM'a giden her yolda, herhangi bir dosya hala bekleme durumunda mı? OPEN? Eğer evet ise → eksik kapatma hatası.
Döngüler için, analiz, bir OPEN veya CLOSE ifadesinin bir döngü başlığı tarafından domine edilip edilmediğini, yani her yinelemede yürütülüp yürütülmediğini kontrol eder.
Dikkat et: Herhangi bir analiz aracı için en zorlu durumlar, paylaşılan rutinlere yapılan PERFORM çağrılarıdır. Eğer
ERROR-HANDLERProgramda on iki farklı yerden çağrılan PERFORM fonksiyonu, çağrının yapıldığı noktadaki dosya durumunun, kapatma işleminin program içinde gerçekleştirilip gerçekleştirilmeyeceğini belirlediği bir fonksiyondur.ERROR-HANDLERDoğru veya hatalıdır. PERFORM zincirleri aracılığıyla durumu yaymayan bir analizör, yanlış negatifler (gerçek hataları gözden kaçırma) veya yanlış pozitifler (doğru kodu işaretleme) üretecektir.
Döngü Seviyesinde Açma/Kapatma: Hata Kodu Olmayan Bir Performans Kusuru
Bu model, çalışma zamanı hatası veya dosya durumu anormalliği üretmez. Sadece yavaş çalışır, gerekenden kat kat daha yavaş olabilir.
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.Dosya fiziksel olarak bölgeye göre bölümlenmediği sürece, bu yaklaşım gereksiz ek yüke neden olur. Pratikte, dosyayı bir kez açmak, tüm kayıtları okumak ve filtrelemeyi bellekte veya mantık yoluyla uygulamak daha iyi olacaktır.
VSAM dosyasında yapılan her OPEN işlemi, katalog araması, ACB başlatılması ve tampon havuzu tahsisini içerir. Her CLOSE işlemi ise tamponları boşaltır, kataloğu günceller ve ACB'yi serbest bırakır. On bölgeye sahip bir dosya için bu işlem bir kez yerine on kez gerçekleşir. 10,000 kayıt ve bin bölgeye sahip bir dosya için ise hesaplamalar oldukça karmaşık hale gelir.
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.Statik analiz, döngü baskınlığı gösteren OPEN ve CLOSE ifadelerini belirleyerek bunu tespit eder; yani, döngü gövdesinin her yürütülmesinde OPEN veya CLOSE ifadesi de yürütülür. Bu tespit, kontrol akış grafiğinin yalnızca ifade dizisini değil, döngü yapısını da temsil etmesini gerektirir.
DOSYA DURUMU: Programınızın Dosya Durumu Sinyali (İşaretlerseniz)
Her COBOL dosya işlemi, FILE-CONTROL girdisinde tanımlanan FILE STATUS alanını ayarlar. Her OPEN, READ, WRITE ve CLOSE işleminden sonra FILE STATUS'u kontrol eden bir program, çalışma zamanında her dosya durumu anormalliğini tespit edebilir ve bunlara yanıt verebilir. FILE STATUS'u göz ardı eden bir program ise kör uçuş yapar.
Kontrol Listesi: Her COBOL geliştiricisinin bilmesi gereken DOSYA DURUM kodları
00Başarılı tamamlanma10Dosyanın sonu (OKUMA: daha fazla kayıt yok)35Dosya bulunamadı (AÇIK GİRİŞ: dosya mevcut değil)41Dosya zaten açık (OPEN durumundaki bir dosyada OPEN işlemi yapılıyor)42Dosya açık değil (Kapalı durumdaki bir dosyada KAPAT veya OKU işlemi)47Dosyada okuma işlemi denendi ancak dosya açılmadı, giriş veya çıkış hatası oluştu.48Yazma işlemi, açılmamış dosyada denendi (ÇIKTI, G/Ç veya GENİŞLETME).97Dosya başarıyla açıldı (IBM'e özgü, bazı ortamlarda)
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.Dikkat et: Sık karşılaşılan bir bakım hatası, FILE-CONTROL girdisinde FILE STATUS'u belirtmek ancak hiçbir zaman buna atıfta bulunmamaktır.
WS-CUST-FILE-STATUSPROSEDÜR BÖLÜMÜ'nde. Bu alan her dosya işleminden sonra doldurulur, ancak hiçbir kod bunu kontrol etmezse, program hataları sessizce görmezden gelir. Statik analiz bu kalıbı işaretleyebilir: DOSYA DURUMU tanımlanmış ancak koşullu mantıkta asla referans alınmamış.
Gerçek Dünyada Hatalara Yol Açan Üç COBOL Örneği
Desen 1: Paylaşılan Hata-Çıkış Sorunu
Bir programın, her birinin kendi hata işleyicisine sahip birden fazla işlem bölümü vardır. Birkaç hata işleyici, geri dönmeden önce dosyayı kapatır. Normal sonlandırma rutini de dosyayı kapatır. Bir hata oluşursa ve kurtarma işlemi hata işleyicisini geçtikten sonra devam ederse, dosya iki kez kapatılır.
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.MKS GO TO TERMINATION kontrolü doğrudan devrediyor TERMINATIONkendi infazını gerçekleştiren CLOSE CUSTOMER-FILEDOSYA DURUMU 42.
Çözüm: Tek bir merkezi kapatma rutini kullanın. Her çıkış yolu aynı rutini çağırır ve bu rutin, kapatmadan önce dosyanın açık olup olmadığını kontrol eder.
Desen 2: Koşullu AÇIK
Bir dosya yalnızca belirli bir işlem modu etkin olduğunda koşullu olarak açılır. Ancak CLOSE işlemi koşulsuz olup, dosyanın hiç açılmadığı durumlar da dahil olmak üzere her yürütme yolunda gerçekleşir.
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.Bu hata, testler her zaman TAM modda çalıştırıldığında görünmez. Üretim ortamında ise ilk KISMI mod çalıştırmasında ortaya çıkar.
Desen 3: Derleme Birimleri Boyunca PERFORM ET
CALL komutuyla alt programları çağıran programlarda, ana programda açılan bir dosya, onu kapatan bir alt programa aktarılabilir, ardından ana program onu tekrar kapatır.
COBOL
*> Main program
CALL 'SUBPROG1' USING CUSTOMER-FILE-STATUS
*> SUBPROG1 closes CUSTOMER-FILE internally
CLOSE CUSTOMER-FILE *> double closeBu model , basit program içi analizle tespit edilemeyen, dosya durumunu CALL sınırından alt programın davranışına kadar izleyen, prosedürler arası analiz gerektirir .
Bir Statik Analiz Cihazının Bunu İyi Yapabilmesi İçin Nelere İhtiyaç Duyar?
Tüm statik analiz araçları COBOL dosya durum analizini aynı derinlikte gerçekleştiremez. İşte yetenek değerlendirmesi için bir karar kontrol listesi:
Bu araç PERFORM zincirlerini işliyor mu? COBOL programları, adlandırılmış paragrafları ve bölümleri çağırmak için PERFORM kullanır. PERFORM hedefi içindeki dosya işlemleri, çağıranın durum izleme mekanizması tarafından görülebilir olmalıdır.
Bu araç, satır içi DEĞİŞKEN PERFORM (döngüler) işlemlerini işleyebiliyor mu? Döngü ağırlıklı AÇMA/KAPATMA işlemlerini belirlemek için döngü tespiti gereklidir.
GO TO komutları arasında durumu takip ediyor mu? Eski COBOL programları GO TO komutlarını yoğun olarak kullanır. Kontrol akış grafiğindeki GO TO kenarlarını takip edemeyen bir analizör, tüm hata sınıflarını gözden kaçıracaktır.
COPY ve REPLACE işlemlerini destekliyor mu? Dosya işleme kodu genellikle COPY üyelerinde bulunur. Analiz öncesinde COPY üyelerini genişletmeyen bir analiz aracı, dahil edilen kodda tanımlanan işlemleri gözden kaçıracaktır.
Dosya durumu kullanımını kontrol ediyor mu? Tam bir analiz, yalnızca dosya durumunun belirtilip belirtilmediğini değil, her işlemden sonra gerçekten kontrol edilip edilmediğini de kontrol eder.
İşlemler arası analiz yapıyor mu? Dosya işlemleri gerçekleştiren çağrılan alt programlar, programlar arası durum bağımlılıkları oluşturur. Gerçek kapsam, çağrı zincirlerini takip etmeyi gerektirir.
Önemli çıkarım: Yalnızca tek bir paragraf veya bölüm içinde kontrol yapan bir araç, gerçek dünyadaki hataların çoğunu gözden kaçıracaktır. Üretimde önemli olan, ortaya çıkması yıllar süren ve teşhis edilmesi saatler alan hatalar, birden fazla bölümü, koşullu dallanmaları ve çağrılan rutinleri kapsayan hatalardır.
Sonuçlarla Ne Yapılmalı: Bir Önceliklendirme Çerçevesi
Statik analiz dosya kusurlarını ortaya çıkardığında, tüm bulgular aynı değildir. İşte bunları nasıl önceliklendireceğiniz:
Bir sonraki toplu işlemden önce hemen düzeltin:
- Dosya durumu 41'in hataya neden olacağı herhangi bir yürütme yolunda çift OPEN işlemi yapılması
- Üretim ortamında çalışan yollarda OPEN olmadan CLOSE işlemi gerçekleştirin.
- VSAM dosyaları için hata çıkış yollarında CLOSE komutunun eksik olması (yazma bütünlüğü riski)
Bir sonraki sprint için program:
- Ölçülebilir parti penceresi etkisine sahip, döngü odaklı AÇMA/KAPATMA
- Kritik dosyalarda (denetim, işlem, rapor) dosya durumu kontrolleri eksik.
- Çok modlu programlarda koşullu açma ve koşulsuz kapatma
Bir sonraki modernizasyon aşamasında izlenecek ve ele alınacak konular:
- Eksik DOSYA DURUMU bildirimleri
- Sadece normal çıkış yollarında KAPAT (İşletim sistemi bunu halleder, ancak kötü bir uygulamadır)
- Düzeltmenin birden fazla programda değişikliklerin koordine edilmesini gerektirdiği prosedürler arası hatalar
Ne kadar SMART TS XL COBOL Dosya Durumunu Analiz Eder
SMART TS XL'S statik kod analizi Ortamdaki her COBOL programının kontrol akışı modelini oluşturur; COPY üyelerini genişletir, PERFORM zincirlerini izler, GO TO kenarlarını takip eder ve dosya durumunu her koşulun her dalında yayar. Bu bir kalıp eşleştirme taraması değildir; programın yürütülmesinin her ulaşılabilir noktasında gerçekte ne yaptığının yapısal bir modelidir.
Uygulama bağımlılık eşleme özelliği bunu prosedürler arası boyuta genişletir: bir COBOL programı dosya işlemleri gerçekleştiren bir alt programı çağırdığında, bağımlılık haritası bu ilişkiyi temsil eder ve derleme birimi sınırlarını aşan analizlere olanak tanır. Ana programı ve çağrılan alt programı kapsayan çift OPEN hataları, program içi analizlerde görülemeyen bir şekilde yapısal modelde görünür hale gelir.
Kurumsal arama özelliği, sonuçları büyük ölçekte kullanılabilir hale getirir: Belirli bir veri kümesini açan portföydeki her programı, CLOSE ifadesi içeren her COPY üyesini, OPEN içeren bir PERFORM hedefi olan her programı, milyonlarca satır COBOL kodunda saniyeler içinde bulun. Toplu iş yükünü buluta taşımaya hazırlanan bir modernizasyon ekibi için bu arama özelliği, haftalarca süren manuel denetimi hedefli bir sorguya dönüştürür.
JCL genişletme özelliği, operasyonel bağlamı ekler: hangi JCL iş adımlarının her programı çağırdığı, her DD ifadesinin hangi veri kümelerine referans verdiği ve COBOL kodundaki dosya işlemenin JCL'de tanımlanan fiziksel veri kümelerine nasıl bağlandığı. JCL'nin kritik çıktı veri kümesi olarak tanımladığı bir dosyada oluşan CLOSE hatası, geçici bir çalışma dosyasındaki aynı hatadan daha yüksek önceliğe sahiptir ve bu önceliklendirme, her COBOL programının JCL bağlamını bilmeyi gerektirir.
Daha Geniş Kapsamlı Ders: Dosya Durumu Sadece Bir Boyuttur
Gereksiz dosya işlemleri, daha genel bir sorunun özel bir örneğidir: On yıllar boyunca evrimleşen COBOL programları, ancak tüm kontrol akış grafiği boyunca olası her yürütme yolunu izleyerek doğru şekilde anlaşılabilecek, duruma bağlı davranışlar, dosya durumu, switch durumları, sayaç durumları içerir.
Bu tür kodların insan tarafından incelenmesi yavaş, eksik ve tutarsızdır. Farklı geliştiriciler farklı hatalar bulur. Aynı geliştirici aynı programı iki kez incelediğinde de farklı hatalar bulur. Statik analiz ise sistematiktir: aynı kuralları her programdaki her yola, her seferinde, yorulmadan veya varsayımlarda bulunmadan uygular.
Sürekli bakım, eski sistemlerin modernizasyon programları veya uyumluluk denetimleri gibi nedenlerle büyük COBOL portföylerini yöneten ekipler için, sistematik dosya durumu analizinin getirisi sadece bulunan kusurlarla sınırlı değildir. Portföyün tamamen analiz edildiğine ve kalan kusurların gizlenmek yerine bilindiğine dair güven duygusu da bu getirinin bir parçasıdır.
