Benzer büyüklükte COBOL portföylerine sahip iki kuruluş, farklı modernizasyon kararları alıyor. Birincisi, COBOL programlarını AWS Mainframe Modernization veya bir COBOL öykünme katmanı kullanarak bulut altyapısına taşıyarak, kodu korurken fiziksel ana bilgisayarı ortadan kaldırıyor. On sekiz ay içinde altyapı maliyetlerini %40 oranında azaltıyorlar ve program başarılı kabul ediliyor. Diğer kuruluş aynı yaklaşımı deniyor, on iki ay sonra duvara tosluyor ve en kritik programları Java mikroservisleri olarak yeniden inşa etmeye yöneliyor. Bu dönüşüm, orijinal bütçenin iki katına mal oluyor ve üç yıl daha sürüyor.
Başlangıç noktası aynı. Sonuçlar tamamen farklı. Fark, kullanılan araçlarda, tedarikçilerde veya ekiplerde değildi. Fark, ikinci kuruluşun, yeni platformun karşılayamayacağı mimari kısıtlamalara, CICS işlem bağımlılıklarına, VSAM dosya yapılarına ve yeniden platformlanan kodun temelden yeniden tasarlanmadan karşılayamayacağı gerçek zamanlı gereksinimlere sahip sistemler için yeniden platform oluşturmayı seçmiş olmasıydı. Karar, sistemleri doğru bir şekilde anlayacak kadar bilgi sahibi olmadan önce alınmıştı.
Yeniden mimari engelleyicileri erkenden bulun.
SMART TS XL COBOL portföyünüzün tamamında CICS bağlantı derinliğini, VSAM karmaşıklığını ve kullanılmayan kodları otomatik olarak belirler.
Daha fazla bilgiCOBOL için Her Bir Yolun Gerçek Anlamı Nedir?
Genel tanımlar iyi bilinmektedir. Önemli olan, mimarisi, yürütme modeli ve veri yapıları modern uygulamalardan farklılık gösteren ve hangi yolun uygulanabilir olduğunu doğrudan etkileyen COBOL programları için her bir yolun özel olarak ne anlama geldiğidir.
COBOL'un Yeniden Platforma Alınması
Yeniden platformlama, COBOL programlarını genellikle bulut altyapısı olmak üzere yeni bir işletim ortamına taşırken, kodu büyük ölçüde değiştirmeden korur. COBOL, yeni platformda ya yerel olarak (IBM'in Linux üzerindeki COBOL derleyicisini kullanarak) ya da ana bilgisayara özgü çağrıları (CICS, VSAM, JES) yakalayan ve bunları bulut tabanlı eşdeğerlerine çeviren bir öykünme katmanı aracılığıyla derlenir ve çalıştırılır.
Platform değiştirmenin koruduğu şeyler:
- COBOL kaynak kodu
- Programın mantığı, hesaplamaları ve iş kuralları
- Toplu işlem yürütme modeli (PERFORM döngüleri, sıralı dosya işleme)
- Veri yapıları (kayıt düzenleri, kopyalama defteri tanımları)
- JCL iş yapısı (yeni zamanlayıcıya göre yeniden yazıldı, ancak mantıksal olarak eşdeğer)
Platform değişikliğinin getirdiği değişiklikler:
- Fiziksel altyapı (z/OS → Bulutta Linux)
- G/Ç alt sistemi (VSAM → kullanılan araca bağlı olarak yönetilen dosya depolama veya veritabanı)
- İş zamanlayıcı (JES2/JES3 → AWS Batch, Azure Logic Apps veya eşdeğeri)
- Maliyet modeli (MIPS tabanlı faturalama → tüketim tabanlı bulut faturalama)
Özetle: Sorun platform, z/OS çalıştırma maliyeti, altyapı bağımlılığı veya MIPS faturalama modeliyle ilgiliyse, platform değiştirme doğru bir yaklaşımdır. Ancak sorun kod veya mimariyle ilgiliyse, yanlış bir yoldur.
COBOL'un Yeniden Mimarilendirilmesi
Yeniden mimarileştirme, sistemin temel tasarımını değiştirir. İş mantığı korunur veya COBOL kaynak kodundan yeniden türetilir, ancak yeni bir dilde, yeni bir yürütme modeliyle ve yeni bir veri katmanına karşı uygulanır. Sonuç olarak, COBOL'un yaptığı işi yapan ancak yapı olarak COBOL'a benzemeyen bir sistem elde edilir.
Yeniden mimarileştirmenin getirdiği değişiklikler:
- Programlama dili (COBOL → Java, Python, Go, C#)
- Yürütme modeli (toplu işlem → olay odaklı, akış tabanlı veya API tabanlı)
- Veri katmanı (VSAM dosyaları → ilişkisel veritabanı, NoSQL, bulut tabanlı depolama)
- İşlem modeli (CICS sözde-konuşma tabanlı → RESTful durumsuz hizmetler)
- Entegrasyon modeli (paylaşılan veri kümeleri → API sözleşmeleri, mesaj kuyrukları)
Yeniden mimarileştirmenin koruması gerekenler:
- COBOL'un uyguladığı her iş kuralı, belgelenmemiş uç durumlar da dahil.
- Paketlenmiş ondalık aritmetiğin sayısal hassasiyet özelliklerini de içeren her hesaplama.
- MOVE ifadelerindeki örtük dönüşümler de dahil olmak üzere her türlü veri dönüşümü
- Alt sistemlerin bağlı olabileceği belirli dosya durumu kodları ve sonlanma davranışları da dahil olmak üzere her hata durumu
Dikkat: Yeniden mimari oluşturma sürecinde en sık karşılaşılan başarısızlık nedeni, COBOL kodunun başka hiçbir yerde yazılı olmayan iş kuralları içerdiğinin keşfedilmesidir. Yeni sistem, belirli uç durumlarda eski sistemden farklı davranır; bu, uygulama hatasından değil, spesifikasyonun eksik olmasından kaynaklanır. Yeniden mimari oluşturma işlemine başlamadan önce, iş mantığı COBOL kaynak kodundan çıkarılmalı ve belgelenmelidir.
Bu Kararı Değiştiren COBOL'a Özgü Faktörler
Genel modernizasyon çerçeveleri, platform değiştirme ve yeniden mimarileştirme kararlarını öncelikle maliyet, zaman çizelgesi ve riskle ilgili kararlar olarak ele alır. COBOL için ise, dile ve çalışma ortamına özgü çeşitli teknik faktörler, kararı güçlü bir şekilde bir yöne veya diğerine doğru yönlendirir.
CICS İşlem Bağımlılıkları
CICS (Müşteri Bilgi Kontrol Sistemi), birçok COBOL programının etkileşimli iş yükleri için kullandığı işlem işleme ara yazılımıdır. EXEC CICS çağrıları yapan bir COBOL programı, ekran yönetimi, terminal iletişimi, görev dağıtımı ve program kontrolü için CICS işlem sunucusuna örtük bir bağımlılığa sahiptir.
Platform değişikliğinin sonuçları: Micro Focus CICS öykünmesi, OpenFrame ve bazı AWS Ana Bilgisayar Modernizasyon özellikleri gibi araçlar CICS semantiğini taklit eder. CICS kullanımı standart ve sorunsuz ise öykünme işe yarayabilir. Program CICS iç yapısına, virgül alanı manipülasyonuna, senkronizasyon noktası kontrolüne, görev düzeyinde depolamaya dayanıyorsa, öykünme doğruluğu düşer.
Yeniden mimarileştirme gerekliliği: Bir CICS programının REST API'ye dönüştürülmesi durumunda, sözde diyalogsal işlem modeli, durumsuz etkileşimler olarak yeniden tasarlanmalıdır. Bu bir kod çevirisi değil, mimari bir değişikliktir.
Yeniden mimariye doğru iten sinyal: Karmaşık virgül alanı yönetimi, arka uç işlem zincirleme veya senkronizasyon noktası mantığı içeren yoğun CICS kullanımı.
VSAM Dosya Mimarisi
VSAM (Sanal Depolama Erişim Yöntemi), çoğu COBOL üretim programı tarafından kullanılan indekslenmiş dosya sistemidir. VSAM dosyaları, bulut tabanlı depolamada doğrudan karşılığı olmayan belirli erişim kalıplarına sahiptir: KSDS anahtarlı sıralı, ESDS giriş sıralı, RRDS göreceli kayıt.
Platform değiştirmenin sonuçları: Öykünme katmanları, VSAM okuma ve yazma işlemlerini altta yatan dosya veya veritabanı işlemlerine çevirir. Basit sıralı veya anahtar tabanlı erişim için bu işe yarar. Karmaşık alternatif anahtar erişimi, birden fazla program arasında paylaşılan VSAM kümeleri veya performansa duyarlı rastgele erişim kalıpları için öykünme gecikme ve karmaşıklık ekler.
Yeniden mimarileştirme gerekliliği: VSAM'ı ilişkisel bir veritabanıyla değiştirmek, kayıt düzenlerini tablo şemalarına eşlemeyi, örtük veri türü dönüşümlerini ele almayı ve her dosya erişimini SQL veya bir ORM kullanacak şekilde yeniden yazmayı gerektirir.
Yeniden mimarileştirmeye yönelik sinyaller: Birçok programda paylaşılan VSAM dosyaları, alternatif dizin erişim kalıpları veya öykünmenin karşılayamayacağı gerçek zamanlı performans gereksinimleri.
Toplu İşlem ve Gerçek Zamanlı İşlem Gereksinimleri
COBOL toplu işlem programları, büyük miktarda kaydı zamanlanmış zaman aralıklarında ardışık olarak işlemek üzere tasarlanmıştır. Birçok bankacılık, sigorta ve devlet sistemi, milyonlarca işlemi işleyen, raporlar üreten ve ana dosyaları güncelleyen gece boyunca çalışan toplu işlemleri hala yürütmektedir.
Platform değişikliğinin sonuçları: Toplu işlem semantiği, bulut tabanlı toplu işlem yürütmeye (AWS Batch, Azure Batch) iyi bir şekilde uyarlanabilir. Sıralı işlem modeli, platform değişikliğinden etkilenmez. Gereksinim yalnızca aynı toplu işi daha ucuz bir altyapıda çalıştırmaksa, platform değişikliği bunu doğrudan ele alır.
Yeniden mimarileştirmenin sonuçları: İş gereksinimi değiştiyse, örneğin gecelik toplu işlemden neredeyse gerçek zamanlı işleme, dosya tabanlı veri alışverişinden API entegrasyonuna, monolitik toplu işlem çalıştırmalarından bireysel olarak tetiklenen mikro hizmetlere geçildiyse, platform değişikliği yeni gereksinimi karşılayamaz. Mimari mutlaka değişmelidir.
Yeniden mimariye doğru iten sinyal: Paydaşların gerçek zamanlı işlemeye, API tabanlı entegrasyona, olay odaklı mimariye veya toplu işlem semantiğinin sağlayamayacağı saniye altı yanıt sürelerine yönelik gereksinimleri.
Harici Spesifikasyon Gerektirmeyen Gömülü İş Mantığı
Bu, en az takdir edilen COBOL'a özgü faktördür. Başlıca riskler arasında, on yıllar öncesine ait kodlara gömülü kritik iş kurallarının kaybı ve sistem davranışının yetersiz dokümantasyonu yer almaktadır. COBOL programları genellikle bir iş kuralının hayatta kalan tek spesifikasyonunu içerir. Belirli bir hesaplamayı gerektiren düzenleme 1983'te yazılmıştır. Bunu anlayan iş analisti 2001'de emekli olmuştur. COBOL kodu sadece bir uygulama değil, aynı zamanda dokümantasyondur.
Platform değiştirmenin sonuçları: Kod korunduğu için iş kuralları olduğu gibi kalır. Bu, platform değiştirmenin en güçlü argümanlarından biridir.
Yeniden mimari uygulaması sonucu: İş kuralları, yeniden uygulanmadan önce COBOL kaynak kodundan çıkarılmalıdır. <cite index=”28-1″>Belgelenmemiş, sıkıca bağlı kod, her aşamada çabayı kat kat artırır.</cite> Bu çıkarma işlemi eksik yapılırsa, yeni sistem eski sistemden farklı bir spesifikasyona sahip olur ve bu farklılıklar üretimde ortaya çıkar.
Bir Karar Verme Çerçevesi: Sekiz Soru
Bir yol seçmeden önce, bu sekiz soru, varsayımlara değil, güvenle karar verebilmeniz için gereken kanıtları ortaya koyar.
1. Bu modernleşmenin temel itici gücü nedir?
- Altyapı maliyeti → yeniden platform oluşturma yeterli
- Platform bağımlılığı (z/OS) → platform değişikliği yeterlidir.
- Gerçek zamanlı gereksinimler → yeniden mimari tasarım gereklidir
- Entegrasyon gereksinimleri (API) → yeniden mimari tasarım gerekebilir.
- Sürdürülebilirlik / yetenek bulunabilirliği → yeniden mimarileştirme veya yeniden yapılandırma
2. CICS bağlantı düzeyi nedir? Her EXEC CICS çağrısını listeleyin. Yirmiden fazla farklı CICS komutu içeren programları sayın. Öykünme doğruluğu belirsizse, yüksek CICS bağlantısına sahip programlar yeniden platforma taşınmaya uygun değildir.
3. VSAM erişim kalıpları nelerdir? VSAM dosyalarına alternatif anahtarlar, paylaşımlı kümeler veya performansa duyarlı rastgele erişimle erişen programları belirleyin. Bunlar platform değiştirme risk göstergeleridir.
4. İş mantığı harici olarak belgelendi mi? Eğer COBOL kaynak kodu tek yetkili spesifikasyon ise, yeniden mimarileştirme, paralel bir iş yükü değil, ön koşul bir adım olarak iş mantığı çıkarımını gerektirir.
5. Parti penceresi toleransı nedir? İşletme aynı parti işleme modelini daha düşük maliyetle gerektiriyorsa, platformu yeniden yapılandırın. İşletme aynı işlemenin gerçek zamanlı olarak kullanılabilir olmasını gerektiriyorsa, mimariyi yeniden tasarlayın.
6. Bağımlılık karmaşıklığı nedir? Elli adet alt program, veri kümesi ve JCL çağırıcısı içeren bir program, bağımsız bir yardımcı programa göre daha yüksek yeniden mimarileştirme riski taşır. Bağımlılık yapısı, geçiş sıralamasını ve test kapsamını belirler.
7. Kodun yüzde kaçı ölü koddur? Herhangi bir dönüştürme işleminden önce kapsam dışında bırakılan ölü kod, her iki yol için de iş yükünü azaltır. Yeniden mimari oluşturulacak programlarda, kapsam dışında bırakılmayan ölü kod tam maliyetle dönüştürülür ve ardından atılır.
8. Karmaşıklık dağılımı nedir? Program başına 50'nin üzerinde döngüsel karmaşıklık veya yirmiden fazla dahil edilmiş kopyalama dosyası, yeniden mimarileştirme maliyeti yüksek ve platform değiştirme riski taşıyan programları gösterir. Bunlar, toplu yol ataması yerine bireysel ilgi gerektirir.
Çerçeveyi Uygulamak: Dört COBOL Sistem Profili
| Profil | özellikleri | Önerilen Yol | gerekçe |
|---|---|---|---|
| Kararlı parti yardımcı programı | Sıralı dosya G/Ç, CICS yok, iyi belgelenmiş mantık, düşük karmaşıklık | yeniden platform | Sorun platform maliyetidir; kod kısıtlama getirmez. |
| CICS ağırlıklı çevrimiçi işlem | Yoğun EXEC CICS kullanımı, virgül alanı bağımlılıkları, sözde konuşma modeli | yeniden mimar | CICS öykünmesi riski yüksektir; gerçek zamanlı gereksinimler muhtemeldir. |
| VSAM ana dosya işlemcisi | Karmaşık VSAM erişim kalıpları, birçok programda paylaşılıyor, yüksek okuma hacmi | Öncelikle öykünme doğruluğunu değerlendirin; öykünme doğruysa platformu değiştirin. | VSAM öykünmesi karar değişkenidir. |
| İş mantığı hazinesi | Belgelenmemiş kurallar, harici şartname yok, yüksek düzenleyici öneme sahip. | Önce mantığı çıkarın, sonra seçim yapın. | Önceden iş mantığı çıkarımı yapılmadan yeniden mimarileştirme riski kabul edilemez. |
Önemli çıkarım: <cite index=”30-1″>Uygulamada, büyük veri merkezleri yaklaşımları birleştirir: istikrarlı kısımları yeniden platforma taşır, bakımı zor olan kodu yeniden düzenler, yeni yetenek gerektiren birkaç sistemi yeniden yazar ve artık kullanılmayanları devre dışı bırakır.</cite> Karar portföy düzeyinde değil, iş yükü düzeyindedir ve kanıtlara dayanarak her programa veya program grubuna ayrı ayrı uygulanır.
Hibrit Yaklaşım: Önce Platformu Yeniden Oluşturun, Gerektiğinde Yeniden Mimari Oluşturun
Pratik bir kural: Kan kaybını hızlıca durdurmak için sunucuyu yeniden barındırın veya platformu değiştirin, ardından gerçek rekabet avantajı sağlayan sistemleri yeniden yapılandırın veya yeniden tasarlayın.
Büyük COBOL portföylerine sahip çoğu kuruluş için pratik sıralama şu şekildedir:
1. Aşama, Açık adayların yeniden platformlanması. CICS'i olmayan, basit sıralı G/Ç'ye sahip, belgelenmiş mantığa ve düşük karmaşıklığa sahip programlar, öngörülebilir çaba ve riskle yeniden platformlanabilir. Bu, altyapı maliyetlerinde hızlı bir azalma sağlar ve kurumsal güveni artırır.
2. Aşama, Karmaşık Programların Değerlendirilmesi. CICS bağlantısı, karmaşık VSAM kalıpları veya belgelenmemiş iş mantığı içeren programlar, bir yol seçilmeden önce bireysel analiz gerektirir. Bu aşamada, iş mantığı çıkarımı ve yapısal analiz, yeniden mimarileştirmenin gerekli olup olmadığını ve kapsamının ne olacağını belirler.
3. Aşama, Mimari engelleri olan programların yeniden yapılandırılması. Yeniden platformlanan altyapıda iş gereksinimlerini, gerçek zamanlı gereksinimleri, API entegrasyonunu, olay odaklı işlemeyi karşılayamayan programlar, Strangler Fig modeli kullanılarak yeniden yapılandırılır: yeni hizmet, yeniden platformlanan programın yanına kurulur, her bileşen doğrulandıkça trafik kademeli olarak yeni uygulamaya yönlendirilir ve tüm trafik taşındığında eski program devre dışı bırakılır.
4. Aşama, Ölü kodların devre dışı bırakılması. Yapısal analiz sırasında ölü olarak tanımlanan programlar her iki yoldan da çıkarılır ve hizmet dışı bırakılır; bu da herhangi bir dönüştürme çabası gerektirmeden devam eden bakım maliyetini azaltır.
Karar verilmeden önce analizin ortaya koyması gerekenler şunlardır:
Yukarıdaki karar çerçevesi, girdiler tahminlerden ziyade kanıtlar olduğunda daha iyi sonuçlar üretir. Bu girdileri sağlayan yapısal analiz, dokümantasyona veya geliştirici bilgisine güvenmek yerine, gerçek COBOL kaynak kodunun ayrıştırılmasını gerektirir.
Analizin her program için ortaya koyması gerekenler:
Dokümantasyonda yer almayan programlar da dahil olmak üzere eksiksiz bir program envanteri. Büyük COBOL ortamlarında, dokümanlanmamış program sayısı genellikle toplamın %20'sini aşmaktadır. Hangi programların hangilerini çağırdığını, hangi veri kümelerinin paylaşıldığını, hangi JCL işlerinin hangi programları çağırdığını gösteren bir bağımlılık grafiği. Her program için CICS komut envanteri, çağrıların sayısı, türleri ve karmaşıklığı. VSAM erişim kalıbı analizi, hangi erişim yöntemleri, hangi dosyaların programlar arasında paylaşıldığı, hangi dosyaların alternatif indekslere sahip olduğu. Döngüsel karmaşıklık dağılımı, hangi programların yapısal olarak basit olduğu ve hangilerinin herhangi bir dönüşüm için yüksek riskli adaylar olduğu. Ölü kod tanımlama, hangi programların ve paragrafların gelen yürütme yollarının olmadığı. İş mantığı çıkarımı, her programın hangi kuralları uyguladığı, her iki yolun çıktısını doğrulamak için kullanılabilecek bir biçimde.
Bu envanter olmadan, yol kararı eksik bilgilere dayanarak verilir. Programlar, planlama sırasında görünmeyen mimari kısıtlamaları ortaya çıkaran simülasyonlar sonucunda yanlış olduğu anlaşılan varsayımlara dayanarak yeniden platforma atanır.
Ne kadar SMART TS XL Karar Öncesi Kanıtları Üretir
SMART TS XL'S miras modernizasyonu Bu analiz, yukarıda açıklanan yapısal envanteri otomatikleştirir ve yol kararını kanıta dayalı hale getiren birleşik bağımlılık modelini oluşturmak için her COBOL programını, copybook'u, JCL işini ve VSAM dosya referansını eş zamanlı olarak ayrıştırır.
Uygulama bağımlılık eşlemesi, programlar arası çağrı grafiğini ve veri kümesi paylaşım haritasını oluşturarak bağımlılık karmaşıklığını belirler; bu faktör, hem platform değiştirme öykünme riskini hem de yeniden mimari kapsamını ve sıralamasını en doğrudan etkileyen unsurdur.
Statik kod analizi, portföydeki her program için karmaşıklık ölçütleri, CICS çağrı envanterleri ve ölü kod tanımlaması üretir. Döngüsel karmaşıklık eşiğinin üzerinde olan ve yoğun CICS bağımlılığına sahip programlar, toplu olarak yeniden platforma atanmak yerine otomatik olarak yeniden mimarileştirme veya değerlendirme adayı olarak belirlenir.
JCL genişletmesi, sembolik parametreleri çözümler ve hangi JCL işlerinin hangi programları, hangi sırayla, hangi veri kümeleriyle çağırdığını belirleyen eksiksiz toplu işlem bağımlılık zincirini oluşturur; bu da her iki yolun çıktısının toplu işlem planını karşılamak için nasıl davranması gerektiğini belirleyen operasyonel bağlamı sağlar.
Etki analizi özelliği, program başlamadan önce her yolun kapsamını somutlaştırır: yeniden mimarileştirilecek herhangi bir program için, etki analizi, güncellenmesi, yeniden test edilmesi veya yeniden mimarileştirilen bileşenle koordine edilmesi gereken her bağımlı programı listeler. Platform değiştirme adayları için, aynı analiz, tutarlı bir şekilde ele alınması gereken programlar arası bağımlılıklar oluşturan paylaşılan veri kümelerini ve paylaşılan alt programları belirler.
Kurumsal arama, program genelinde tüm envanterin sorgulanabilir olmasını sağlar: belirli bir CICS komutunu kullanan her programı, belirli bir VSAM kümesine erişen her programı, belirli bir veri yapısını tanımlayan her copybook'u, milyonlarca satır COBOL kodu arasında saniyeler içinde bulabilirsiniz.
Bu kararı doğru veren kuruluşlar, proje planı varsayımlarından ziyade yapısal kanıtlara dayanarak karar verenlerdir. Yapısal kanıt ise şudur: SMART TS XL üretir.
