2000'de Neler Olacak?

2000 Yılı: COBOL yok, mainframe'ler yok, problem de yok. Doğru mu? Yanlış. 2000 yılıyla ilgili tahminlerinizi doğru yapmalısınız.

Joe Celko ve Jackie Celko

Bu tarih bazıları için dünyanın sonu olabilir. En azından 2000 yılı yaklaşırken, bilgisayar kıyameti konusunda uyaran pek çok kişi var. Bu felaket tellallarının bazıları, bilgisayarlarınızı ve sizi bu dijital felaketten kurtaracağını iddia ettikleri şeyler satmaya çalışan yazılım üreticileri ve danışmanlar. Cevaplamanız gereken pek çok soru var. Bunlara para vermeli misiniz? 2000 yılı problemi aslında ne kadar büyük? Bu, kimleri etkileyecek? PC kullanıcıları bu problemden etkilenecek mi?

2000 yılı problemi, bilgisayar kullanılan devlet kurumlarını, firmaları ve kullanıcıları etkileyecek. Bilgisayar kullanmasanız da, bu problemden etkilenenler yüzünden, siz de dolaylı olarak etkileneceksiniz. Sigortanız varsa, uçak bileti veya sezonluk maç bileti satın alacaksanız, problem yaşayabilirsiniz. Binanızın ısınmasını kontrol eden sistemler veya tasarruflarınızı yatırdığınız ATM gibi otomatik sistemler çalışmayabilir.

2000 yılına uygun şekilde hazırlanmayan işyerleri bunu atlatamayacaktır. Bilgisayar sistemleri, 2000 uyumlu olmayan işyerleri, iş sigortası yaptıramayacaklar. Faiz veya ödeme vadelerinde, otomatik çeklerde, prim ödemelerinde ortaya çıkacak hatalar şirketleri büyük kanuni risklerle karşı karşıya bırakabilir. Hiçbir şey de kanuni yaptırım kadar zorlayıcı olamaz.

Firmalar, bilgisayarları 1999’dan sonraki siparişleri tanımayacağı için gelir kaybedebilir. Diğer firmalar da, bilgisayarlarınız 2000’li tarihleri standart şekilde işleyemediğinden sizden siparişte bulunmayı veya ortak girişimde bulunmayı reddedebilir. 2000 yılı problemi olmasa da, farklı tarih formatı kullanımları kafa karıştırıcıdır. “On altı aralık bin dokuz yüz doksan yedi” farklı şekillerde yazılabilir. Boston’da 12/16/97, Londra’da 16/12/97, Berlin’de 16.12.97, Stockholm’de 97-12-16 şeklinde yazılmaktadır. Ülkelerdeki farklı endüstriler içinde de kabuller farklılık gösterir. Örneğin, ABD ordusunda bu tarih 1997-Dec-16 şeklinde yazılır.

Yazılım paketleri, gösterim için tarihleri formatlamakta genel bir yol kullanır. Geleneksel araçlar, iki veya dört rakamlı yıl, üç harfli veya iki rakamlı ay, iki rakamlı gün sunar. Bölü işaretleri, tireler, noktalar veya boşluklar bu üç alanı birbirinden ayırır.

ISO Tarihleri

Ancak gerçekte bir tek uluslararası standart vardır: ISO 8601:1988 “Veri elemanları ve değişim formatları-Veri aktarımı-Tarih ve zamanın gösterimi.” Bu, tümüyle sayısal yyyy-mm-dd (yıl-ay-gün) formatını tanımlar.

Ulusal Standartlar ve Teknolojiler Enstitüsü (National Institute of Standards and Technology - NIST) eski ABD formatını koruyarak, ABD içinde tire yerine bölü işaretleri kullanılmasını onayladı. (Bu arada, özellikle Microsoft gibi bazı üreticilerin, 2000 yılıyla uyumlu olmaya çalıştıklarını iddia ederken, ISO 8601 tarih formatını kullanamayan ürünler satması da son derece ilginç.)

2000 yılıyla ilgili muhtemel problemlerinizi iki sınıfa ayırabilirsiniz: Yazılım ve donanım. Bu iki kategoriden, yazılım en problemli olandır.

Karşılaşacağınız donanım problemlerinin çoğunun bir tek genel çözümü olacaktır. Ancak, birbiriyle etkileşen farklı yazılım paketlerinin, dillerin ve firma içi uygulamaların farklı şekillerde bir araya gelmesi, firmaların her yazılım sistemi için ayrı bir çözüm geliştirmesini gerektirecektir.

Takometre Problemi

Bir sistem 1999’dan büyük yılları kabul etmediğinde donanım problemleri ortaya çıkar. Biz buna takometre problemi diyoruz; çünkü problem donanımdadır, uygulamanın kodunda değil. Bu, tarih gösterimlerinin ve aritmetik işlemlerin hatalı olduğu bin yıl problemiyle aynı şey değildir. Bir arabadaki üst sınırına ulaşarak sayacını sıfırlayan bir takometreyi düşünün.

Buna verilebilecek bir örnek 40 yıllık özel dokuma makineleri kullanarak fiberglas elbiseler dokuyan bir üretici olabilir. Her kumaş topuna dokuma makineleri tarafından tarih basılır. Tarihte iki basamaklı sene kodu kullanılır ve bunlar da transistörlü baskı devreleri tarafından kontrol edilir. Bu, donanım problemine verilebilecek son derece uç bir örnek.

Takometre problemi hem PC’ler, hem de ana bilgisayarlar için söz konusu. Örneğin, Unisys 2200 sistemi 1996’nın ilk gününde, sene alanının sekizinci bit’i (işaretli bir tamsayı) bire dönüşeceğinden başarısız olacaktı. Üretici firma, bu problemi çözmeyi başardı.

Diğer dahili tarih sistemlerinin başarısız olacakları tarihler değişik, ancak bunları pek çoğu sonraki bin yılın ilk yüzyılında başarısız olacak. Ana bilgisayar üreticileri donanımlarının 21. yüzyılda da çalışmaya devam etmesini sağlayacak çözümler üzerinde çalışıyor. Yine de, dokuma tezgahları örneğinde olduğu gibi çok eski makinelere sahip kullanıcılar, üreticiler bu makineleri desteklemekte yetersiz kalırsa veya bunu yapmayı reddederse kendi başlarına kalacaklar.

Intel tabanlı PC’lerin de takometre problemleri var. Sistem saatinin nasıl davranacağı BIOS çipinize bağlı, ancak resetleneceği en genel tarihler, 1900, 1980, ve 1984. Bilgisayarınızı test edebilirsiniz. Tarihi 1999-12-31 (bunu makinenizin istediği formatta girin), saati 23:59:51’e ayarlayın. Bırakın makineniz on saniye daha çalışsın. Bundan sonra olanlar BIOS çipinize ve DOS sürümünüze bağlı.

Sonuç, 01/01/00 olarak görünen bir tarih olabilir ve problem olmadığını düşünebilirsiniz. Gösterilen tarihin doğru görünmesine rağmen, saatin içeride okuduğu 1980-01-01 veya 1900-01-01 olabilir. Yeni oluşturduğunuz dosyaların da 20. yüzyıla ait olduğunu görebilirsiniz, çünkü işletim sistemi saate doğrudan ulaşmış ve yanlış tarihi almıştır.

Bu problem uygulamalara da yansır, ancak tam olarak sizin düşündüğünüz şekilde değil. Buna DOS 6 üzerinde çalışan Quicken 3’ü örnek olarak gösterebiliriz. Tahmin edeceğiniz gibi, 2000-01-01 tarihini doğrudan girmenin sonucu yılın 1980 veya 1984’e gelmesine sebep olacaktır. Yine tuhaf bir biçimde, 1999-12-31 tarihinden 2000’e geçerken, Quicken değişikliği, 1900 olarak değil, 1901-01-01 olarak yorumladı. Bu, Quicken’ın bazen dahili saate başvurduğunu, bazen de kullanıcının girdiği tarihi kullandığını gösteriyor. Saatten alınan tarih de, sisteme elle girilen tarih de hatalı ve birbirinden farklı.

PC’lerde 2000 yılı testlerini yapan çok sayıda freeware program mevcut. Bunların arasında Bob Stammers’ın DOSCHK’i, Dan Goodell’in 2000Test ve 2000Fix’i, Tom Becker’in (Air System Technologies) Year2000’i sayılabilir.

2000 yılında zorlanan diğer PC uygulamaları arasında Microsoft Access, FoxPro, ve Visual Basic; CA Clipper; Borland Delphi; Gupta SQLbase; ve Oracle da var. Bunların çoğu için düzeltici küçük programlar freeware olarak pek çok yerde bulunabilir.

2000 yılının iki buçuk yıl ötede olduğu, ve bazı ortamlardaki PC’lerin ömrü daha da kısa olduğundan, bazı yöneticiler problemin o kadar büyük olmayacağına inanıyor. Ancak, bunun haricinde pek çok yerde eski makineler kullanımda. Şirket ortamında, eski makineler kullanılmaya devam eder, ancak daha az kritik bir görevi üstlenirler ve daha yeni modeller bunların yerini alır.

Bir diğer çözüm de çipi değiştirmek. Bu çözüm, çok sayıda makineniz varsa zaman alıcı ve masraflı olacaktır. Yazılım yamaları (patch), program saatini doğrudan okuyorsa veya yama, mevcut programlarla çalışmıyorsa işe yaramaz.

Bazı üreticiler belirli bir tarihten sonra ürettikleri makinelerin problemsiz olacağını söylüyor. Bu üreticiler arasında Temmuz 1996’dan sonra ürettiği makinelerin problemsiz olduğunu söyleyen AST Computer da var.

Bazı Pentium işlemcili makinelerin BIOS’u, doğrudan terfi ettirebileceğiniz bir flash EPROM’da saklı. Ağustos 1995’ten sonra üretilmiş Award veya AMI markalı bir BIOS çipine sahipseniz, üreticinin Web sitesinden çekeceğiniz bir yamayla terfi edebilirsiniz.

Daha eski bazı makineler de terfi edilebilir, bunların dokümanlarına bakmalısınız. Çok sayıda başka üretici de kullanıcıların terfi ettirebileceği sistemler sunuyor veya bunun hazırlığı içinde. Bir kez daha dokümanlara bakın. Üreticilerin hiçbiri, yamaların donanımla ilgili tüm tarih problemlerini çözeceği konusunda garanti vermiyor. Ancak 2000 yılı yaklaştıkça, üreticiler daha gelişmiş yamalar sunma konusunda çalışmalara devam edecektir.

Pek çok anakart, kullanıcının terfi işlemini yapmasına imkân sağlar. Ancak bazen terfi işlemini uygun sırayla yapmanız gerekebilir. Bazı anakartlarda sistem terfisinden önce ayarlamanız gereken jumper’lar vardır. Eğer doğru işlemleri yapmazsanız, sistem bir hata mesajı verir. Daha da kötüsü, terfi işe yaramış görünürken, aslında hiçbir şey yapmayacaktır.

Harekâtı Planlayın

Global Software’den David Eddy şunları söylüyor: “Şu ana kadar yazılanların yüzde 99’una bakacak olursak, 2000 yılı problemi ana bilgisayarlardaki bir COBOL problemiymiş gibi anlatılıyor. Ancak aslında durum hiç de böyle değil. Yazılım, yazılımdır. Bildiğim kadarıyla, kendisinin doğru şekilde kullanılmasını sağlayan hiçbir programlama dili mevcut değil (buna ABD Savunma Bakanlığının Ada’sı da dahil).”

Software Productivity Consortium’dan (Yazılım Verimliliği Konsorsiyumu) Capers Jones’a göre, 2000 yılının yol açacağı yazılım problemleri yaygın, karmaşık ve düzeltilmesi pahalı olacak. 2000 yılına hazır yazılımlar satın almanın maliyeti, dil ve endüstriye göre değişecek. Örneğin, COBOL’da yazılmış programlar fonksiyon başına 28 dolar civarında tutacak. Makine dilinde yazılmış programlar, fonksiyon başına 75 dolardan daha fazlaya mal olacak. Nesne yönelimli dillerle yazılmış programlarsa fonksiyon başına 18 dolardan daha az tutacak.

Firma içinde hazırlanmış eskiden kalma sistemlerin tamiri en pahalı olacaktır. Pek çok durumda kaynak kodu ve hatta programın özellikleri dahi bulunamayabilir. Eski paketlerin üreticileri hâlâ pazarda olsalar bile, destek sağlamayabilirler.

2000 yılına hazır olduğunu iddia eden bazı paketler de bazı açılardan eksik kalıyor. Bunlara PC’ler için hazırlanmış yazılımlar da dahil. Tablolama programları, dahili tarih kullanımının çalışma şekline bağlı olarak en büyük suçlular. Ancak bir takvim veya planlama fonksiyonu kullanan herhangi bir paket de risk içerir, buna veritabanları da dahildir. Bu paketler veriyi bir ağ bilgisayarına beslediklerinde, hatalı veri tüm sisteminize bulaşır.

Kendi sisteminizi tam uyumlu bir hale getirmek bile, diğer sistemlerle ilişkiniz varsa hatalı veriler sisteminize gireceğinden yeterli olmayabilir. 2000 yılı uyumluluğunun gerektirdiği tarih formatlarında, standart olmayışı problem teşkil etmeye devam edecektir.

Seçenekleriniz

2000 yılıyla uğraşmak için dört metot vardır:

1. Hiçbir şey yapmamak. Neyin bozulacağını görmeyi bekleyerek, bozulduğunda düzeltmek. Bu, şaşırtıcı sayıda orta ve küçük ölçekli firmanın seçimi. Bu devekuşu yaklaşımı 2000 yılında emekli olmayı planlıyorsanız size cazip gelebilir. Ancak şunu da unutmayın: Emekli maaşınızın doğru hesaplanabilmesi için firmanın bilgisayarına ihtiyacınız olacak.

2. Her şeyi değiştirmek. Küçük firmalar yıllanmış veritabanları olmadığından, kullandıkları yazılımları sık sık değiştirebilir. Uygulama programlarını değiştirmemeyi seçerlerse, sık sık terfi işlemi yapabilirler ve üreticiler de hataları gideren programcıklar gönderebilir.

3. Basit düzeltmeler yapın. Pek çok ürün var olan yazılımlar için basit bir düzeltme yolu sağlar. Veriyi değiştirmeniz gerekmeyebilir, ya da sadece küçük değişiklikler yapmanız gerekir.

4. Tam düzeltme için eksiksiz analiz yapmak. Potansiyel tarih problemleri için sistemi test ve analiz etmeyi, 2000 yılını doğru işleyebilmesi için sistemde değişiklikler yapmayı içerir. Sistemin dört basamaklı yılı işleyebileceği şekilde dahili bir değişiklikten geçirilmesi ve girdi noktalarının da kullanıcıların dört basamaklı tarihler gireceği şekilde değiştirilmesi gerekir.

Basit düzeltme, bir referans noktasını (pivot point) gerektirir. (bkz. “İki Basamaklı Tarihlerde Referans Noktalarının Etkileri” isimli şekil). Bu yaklaşım, zaman dilimi veya dönem ayarı olarak da bilinir. Bu yaklaşımda, veriyi değiştirmeden iki basamaklı tarihin ait olduğu yüzyıl hakkında bir tahmin yapılarak uygulamalar düzeltilir. Özel bir yıl referans noktası olarak kullanılarak, sistem iki basamaklı yıla 1000 veya 2000 ekleyerek onu dört basamaklı bir yıla çevirir. Meselâ, program bir PC yazılımına bakıyorsa, 70’lerin ve üstünün 1900’lere ait olduğu tahmini sağlıklı olacaktır, burada 70 referans noktasıdır. Program, anaokulu çocuklarıyla ilgiliyse, referans noktası olarak 90 uygun olacaktır.

Bu yeni bir fikir değildir. Kişisel çekler gibi basılı formlara dikkat edin. Pek çok formda tarih ________19__, şeklinde önceden basılı olarak bulunmaktadır. Bunlardan yüzyılın 20. yüzyıl olduğu varsayımı geçerlidir.

Paketlerin çoğu, en popüler diller ve platformlar için bir referans noktası kullanır ve fiyatları da çok çeşitlidir. 2000 yılı probleminizi çözmek için bir referans noktası kullanan paketleri kullanmanın avantajları vardır. Bu, tüm sistemin analiz ve tamirinden daha az masraflıdır; kullanıcının eğitilmesini ve işin içine katılmasını daha az gerektirir. Pek çok durumda, kullanıcı iki basamaklı tarihler girmeye devam eder, tüm iş perde arkasında görülür.

Bu metodun bir dezavantajı, 00 – 99 arasında bir referans noktası almanızın gerekmesi. Bundan sonra bir referans noktasını diğerine tercih edemezsiniz. Microsoft’un yaklaşımı genel standart olursa, 00 ve 29 arasındaki iki basamaklı yıllar 2000 – 2029 arasına dönüştürülecek; 30 - 99 arası ise 1930 – 1999’a dönüşecek. Bu, 1920’de doğmuş birinin doğum gününü hatalı işleyecektir. Quicken, 00 ile 50 arasındaki iki basamaklı yılları, 2000 – 2050 arasındaki yıllarla eşler. Bu da, 1949’da satın aldığınızın bir stokun getirisinin yanlış hesaplanması sonucunu doğuracaktır. Kısacası, belirli bir uygulama için mükemmel bir referans noktası yoktur.

Bu çözüm sınıfında, tarihleri iki veya dört basamaklı olarak depolayabilirsiniz. Bunların dört basamaklı olarak depolanması, kullanıcılar veya veri girişi operatörleri için iki basamaklı sene formatını kullanacağınız anlamına gelir. Bunu yaparsanız, tüm raporlarda tarihi doğru formatta gösterebilmeniz gerekir.

Seneyi, dahili olarak iki basamaklı depolarsanız, problem yaşayabilirsiniz. Uygulamalarınızdan ikisi referans noktası konusunda uyuşmadığında, her tarih kendi kullanıcı-tanımlı veri tipine sahip olur. Her iki tarih tipini aynı hesaplamada kullanabilmek için dönüştürme rutinleri yazmanız gerekir. Programlarınızdan birisi sisteminize göre hariciyse ve bu yüzden her iki program üzerinde birden kontrol sağlayamazsanız, tespiti güç dahili hesap hatalarıyla karşılaşabilirsiniz. Örneğin, faiz oranlarını hesaplamakta kullanılan tarihlerin çok az bir kısmı hatalı olursa, hatalı tarihlerin tespiti zor olur. Ancak hesap hatalarının etkileri çok büyük olabilir.

Bu tip bir düzeltmeyi sadece sisteminizin küçük bir kısmına uygulayabilirsiniz. Bu hızlı ve faydalı bir düzeltmedir, ancak sadece küçük zaman dilimleriyle işlem yapan veya yakında değiştirilmesi gereken sistemler için geçerlidir.

Büyük Sistemler, Büyük Değişiklikler

Büyük ve orta ölçekli sistemleri 2000 yılına uyumlu kılmak için, bir bütün olarak analiz etmeniz gerekir. 2000 yılı meselesi pek çok firma için, şu ana kadar karşı karşılaşılan en büyük veri işleme projesi olacak.

Data Integrity, farklı endüstriler tarafından üretilmiş 1,000,000 COBOL satırından oluşan bir testi çalıştırdığında, COBOL modüllerinin yüzde 13’den daha düşük bir kısmının etkilendiğini ve tüm kodun yüzde 0.5’lik kısmından daha azının değiştirilmesinin gerektiğini keşfetti. (Bkz. “Samanlıkta İğne Aramak” isimli şekil). Bu test problemli alanların ve etkilerinin tespiti için iyi bir ön plan analizinin çok önemli olduğunu gösteriyor. COBOL-yönelimli analiz ürünleri arasında Allegiant Legacy Solutions’ın Adapt/2000’i gösterilebilir.

Projenin analiz safhası bir yıl kadar sürebilir. Uzun bir ön analiz, projenin tüm süresi üzerinde para ve zaman tasarrufu yapmanızı sağlayabilir. Isogon’un pazarlama müdiresi Anne White, projenin büyük kısmının ölü kodların tespit ve ayıklanması olacağına inanıyor. Çoğu zaman, büyük ana bilgisayar sistemlerindeki kodun yüzde 20 ilâ 30’luk bir kısmı atıl durumdadır.

Teksas’taki bir petrol firmasının analizleri, kullandıkları kodun yüzde 40’ının ölü olduğunu ve silinebileceğini ortaya koymuş. Isogon, bir sistemin 2000 yılıyla uyumlu kılınmasının maliyetinin kod satırı başına 1.50 dolar civarında olacağını hesaplıyor. Sözü geçen firma kodunun yüzde kırkını silerek dönüşüm masraflarını yüzde 40 oranında azaltmış.

Ölü kodu belirlemek için yapacağınız çalışmalarda Isogon’un Audit 2000 gibi ürünleri en önemli iş-öncelikli, aktif kodları tespit etmenizde size yardımcı olabilir. Daha sonra gereken değişiklikler üzerinde çalışmaya başlayabilirsiniz. Global Software’den Graham Thompson, bir programı sistemin tümünden yalıtarak analiz edemeyeceğiniz üzerinde duruyor. Verileri toplayan program, verileri kullanan programdan çok farklı olabilir. Parametreleri sıralamak için kılavuzlara ve yardımcı programlara bakmak ve bağımsız programların yanı sıra veriyi sistemin içinde takip etmek de önemlidir.

Projenizin bütçesinin yaklaşık yüzde ellisi testlere harcanacaktır. Bazı firmalar sistemi test etmek için ilk test verilerini kullanmayı benimsediler, ancak test verilerinin ve senaryoların çoğu 2000 yılı problemi ciddi olarak ele alınmadan önce geliştirilmişti. QES Software’in QES/EZ’si, son kullanıcının model geliştirmesini ve bunları kullanarak 2000 yılının neden olabileceği problem sahalarını tespit etmesini sağlıyor. Problem halledildikten sonra, aynı model sistemin testinde de kullanılabilir. Bu ürün PC üzerinde ve dilden veya işletim sisteminden bağımsız olarak çalışıyor.

Tuhaf Tarihler

2000 yılı projenize bir an önce başlamanız çok önemli. Büyük firmalarda projeler bir yıldan daha uzun sürebilir. Bazı uzmanlar, projeyi 1 Haziran 1999’dan önce tamamlamanız gerektiğini söylese de, pek çok firma için bu tarih 1 Ocak 1999 olacaktır. Bunun sebebi, pek çok programda (özellikle de firma içinde geliştirilenlerde) 99 sayısının belirsiz veya bilinmeyen bilgiyi temsil etmesi. Bu, “tuhaf tarihlere” sadece bir örnek.

Sisteminizi analiz ederken karşılaşacağınız bazı genel problemler, bu tipte tuhaf tarihlerin sonucu olabilir. Tuhaf tarihler, dahili olarak tarih veri tipine sahip olmayan programlama dillerinin sonuçlarıdır. Bu, uygulama geliştiricileri kendi tarih rutinlerini yazmaya mecbur etti. Geliştiriciler yüzyıldaki-yıl formatını kullanarak bununla ilişkili tüm problemleri de keşfettiler. Aynı zamanda, bu alanlarda gerçekte tarih olmayan geçici veri değerleri de kullandılar.

Birçok alt türe sahip olan iki temel tuhaf tarih türü vardır. Daha iyi isimler konmadığı için ben bunlara, tarih olmayan tarihler ve gerçekten tarih olanlara da tarih-değil (nondate) isimlerini vereceğim.

Tarih olmayan tarihler: Buna verilecek en temel örnekler, eski COBOL sistemlerinde karakter alanlarını kullanarak iki farklı türde kullanılan sonsuzluk kodlarıdır. Belirsiz gelecek 9999-99-99 veya 99-99-99 şeklinde gösterilir. Bunun anlamı, olayın henüz meydana gelmediği ve belki de asla meydana gelmeyeceği. Benzer şekilde, belirsiz geçmiş de 0000-00-00 veya 00-00-00 şeklinde gösteriliyordu. Bunun anlamı da olayın meydana geldiği,fakat bizim kesin tarihini bilmediğimizdir. Örneğin, bir çalışanın emeklilik tarihini bilmezsiniz, bu durumda belirsiz gelecek kodunu kullanırsınız. Bir çalışanın doğum günün bilmediğinizde de, belirsiz geçmiş kodunu kullanırsınız.

Bu kodlama metodunun en büyük avantajı, bu değerlerin sıralamalarda geçerli tarih temsillerinden hemen önce veya hemen sonra bir arada gösterilmesi. Bunlar, aynı zamanda dosya boylarının da bir parça kısalmasını sağladılar, bu eskiden önemliydi.

Bu metod asla standartlaşmadı ve kodlama sistemi de yeni kodlar eklendiğinde giderek büyüdü. Örneğin, bir eyaletteki hapishane sistemindeki kayıtlarda “beklenen serbest bırakılma tarihi” alanında tüm 9’ları mahkumiyet, tüm 8’leri de idam kararları için kullanıldı. Ticari kullanıcılar da ömür boyu garantilerin bitiş tarihlerinin de bu biçimde kodlanabileceğini keşfetti. Daha sonra da bu garantileri, garantili parçalar ve işçilik, sadece parçalar, sadece işçilik gibi sınıflara ayırdılar. Eski verileri SQL veritabanlarına aktarmaya çalışan otomatik çevrim araçları, bu tip kodları doğru şekilde kullanamaz. Bunlar, ya bu kayıtları reddedilenlerin kaydedildiği bir dosyaya yazar ya da tüm özel kodları sıfırlara dönüştürürler. Bununla başa çıkmanın doğru yolu, tarihin eksik olduğu durumlarda bir kodun ayrı olarak depolanacağı ikinci bir sütunu tabloya ilave etmektir.

Tüm sonsuzluk kodları planlanmış değildir. Bir veri ambarı kurduğunuzda, verilerinizi elden geçirirken, veri girişi operatörlerinin belirsiz geçmiş veya gelecek değeri gereken yerlerde kendi uydurdukları kodları kullandıklarını görebilirsiniz. Alanların düzenlenmesi çok zahmetli değilse, teoride her şey bir veritabanına alınabilir.

Eski verilerde bulunan ilgi çekici bir tarih örneği de 1111-11-11. Bu, bir form ekranında kodlayabileceğiniz veya bir delikli kart (punch-card) alanında 1 tuşunu basılı tutup tekrarlatarak girebileceğiniz geçerli bir tarihtir. Boşluklar ve tekrarlanan harfler, alan formatının düzenlenmesi zayıf olduğunda sık başvurulan diğer seçeneklerdir.

Tarih-değil aslında tarihtir: Tuhaf tarihlerin diğer alt türleri kendi başına tarih olmayan, ancak tarihten türetilen veya tarih içeren alanları kapsar. Bunlara verilebilecek çok bilinen örnekle, yüzyıldaki yılla başlayan hesap numaraları ve seri numaralarıdır. Meselâ, bu tipte bir uygulama tarafından 1997 yılında verilen ilk hesap numarası 97-0001 olabilir, ikinci numara 97-0002 olacak ve bu böyle devam edecektir. Bu, sigorta endüstrisinde kullanılan genel numaralama şeklidir.

İlk tuhaf tarihler alt sınıfında olduğu gibi, pek çok etken bu alana fazlasıyla yüklenmiştir ve bu alandaki veri standart bir formda değildir. Numaralama şeklini bilen programcılar, seri numarası ve bunların arasındaki ilişkiye göre kod yazmışlardır. Eğer kurallı gidiş devam ederse, 2000 yılında oluşturulacak ilk kayıt 00-0001 olacak ve dolayısıyla tüm bu programlar başarısız olacaktır.

Buna en yaygın ve tehlikeli örnek olarakIBM’in manyetik şerit etiketleme tarzını gösterebiliriz. Yıllardır, manyetik şerit kütüphanesi sistemleri manyetik şerit bobinlerine otomatik olarak yüzyıldaki yılı ve yıldaki günü (001’den 366’ya) yazmışlardı. Bu etiket numarası, “eskimiş” şeritlerin geri dönüşüm, imha veya silinmesi kararını etkiler. 00-001 etiketinin, 99-365 etiketinden küçük olduğunu ve bu yüzden daha erken silinmeye aday olduğuna dikkatinizi çekelim.

Bu kategorideki problemlerin daha küçükleri, sistem saatini veya diğer tarihleri parametre olarak kullanarak, tarihle ilgili olmayabilen sonuçlar üreten algoritmalarda da mevcuttur.

Artık Yıl

Okulda size bir yılda 365,25 gün olduğunun ve bu çeyrek günlerin her dört yılda bir tam gün oluşturduğunun öğretildiğini mutlaka hatırlarsınız. Gerçekte, bir yılda 365,2422 gün vardır ve her 400 yılda bir, “normal” artık yıllardan geri kalan ondalıklı kısım da toplanır.

Evet, 2000 yılı da bir artık yıl. İnsanlar 400 yıl yaşamadıklarından dolayı, bu kuralın uygulanmasını şu ana kadar görmedik. Elbette ki, bilgisayarlar da buna şahit olmadı. Artık yıllar için doğru test kodu Pascal’da aşağıda görüldüğü şekildedir:

FUNCTION isleapyear (year:

INTEGER): BOOLEAN;

BEGIN

IF ((year MOD 400) = 0)

THEN isleapyear := TRUE

ELSE IF ((year MOD 100) = 0)

THEN isleapyear := FALSE

ELSE IF ((year MOD 4) = 0)

THEN isleapyear := TRUE

ELSE isleapyear := FALSE;

END;

Programların çoğu bu algoritmayı kullanmaz, bunun eksik versiyonlarını uygular. Bu türden bir fiyaskoyu, Wacovia Bank, 29 Şubat 1996’da hesap durumlarının otomatik postalanmasında yaşamıştı; program “dörde bölme” testini yapmamıştı.

Bu problem sadece firma içinde üretilmiş uygulamalarda görülmez. Pek çok paket program da aynı dertten muzdarip. Tablolama programlarındaki tarih fonksiyonları bunların en zararlıları olabilir, ancak tarih fonksiyonu olan herhangi bir program da hatalı olabilir. Denemek için 2000-02-29 tarihini girin, tarih aritmetiğiyle bazı işlemler yapın ve ne olduğuna bakın.

2000 yılına üç yıldan az zaman kaldı. Test ve dönüştürme projenize başlamadıysanız, bu işin zamanı çoktan geldi. IBM gibi büyük ana bilgisayar üreticilerinin çoğu 2000 yılı girişimlerine başladı ve müşterilerinin hazır olmasına çalışıyor. Bu alanda çalışan danışmanların ve üreticilerin sundukları ürünlerin sayısı da giderek artıyor. Zaman en kısıtlı kaynaktır.

2000 yılı probleminin kaynağı, yüzyılın sonunu öngöremeyen ve bu konuda plan yapmayan yazılım ve donanım geliştiricileri. Bu öngörü eksikliği bilgisayarlarda ve programlarda takvim 1999’dan 2000’e dönerken ölümsüzleşecek. Günümüzün tasarımcıları bundan hangi dersi mi çıkaracak? 2100 yılında görürsünüz.

Joe Celko, Northern Lights Software, Ltd’in Atlanta’da yaşayan bir danışmanıdır. 1987’den beri ANSI X3H2 Veritabanı Standartları Komitesinin (Database Standards Committee) üyesidir. ANSI/ISO SQL-89 ve SQL-92 standartlarının hazırlanmasına katkıda bulunmuştur. Dört SQL kitabının yazarıdır. Kendisine [email protected] adresinden ulaşabilirsiniz. Jackie Celko ise Atlanta’da yaşayan bir teknik yazardır.

Çeviren: Ali Halaç

©McGraw-Hill Inc. / BYTE