Anaframe ve orta seviye modernizasyon projeleri sıklıkla miras yeşil ekran mantığını, IBM Rational Host Access Transformation Services (HATS), Rocket LegaSuite veya özel 5250 emülatör geçitleri gibi araçlar kullanarak web sargıları içinde kapsüller. Test ediciler sıklıkla web katmanının basit bir geçiş işlevi gördüğünü varsayar. Ancak, EBCDIC karakter kodlaması, 5250 alan özellikleri ve HTML5 widget'ları arasındaki çeviri, doğrulama mantığı, hata mesajları ve eşzamanlılık kontrollerinin kaynak sistemden sapma yaşayabileceği soyutlama katmanları getirir. Bu soru, adayın miras terminal emülasyonu ve modern web protokolleri arasındaki kesişimde yeni davranışları test etme yeteneğini sorgular.
Temel zorluk, 5250 terminal oturumlarının durum bilgisi gerektiren doğası ile durum bilgisi taşımayan HTTP istek-cevap döngüsü arasındaki uyuşmazlıktadır. Miras uygulamalar, alan düzeyindeki kısıtlamaları uygulamak için 5250 veri akışına güvenerek (imzalı sayısal alanlar, zorunlu dolum ve alan çıkış kontrolleri gibi) ve belirli kullanıcı eylemlerini belirtmek için AID kodlarını kullanır (ENTER, CLEAR, ROLL UP veya ROLL DOWN gibi). Birden fazla kullanıcı aynı DB2 for i kaydına web sargısı aracılığıyla eriştiğinde, temel 5250 oturum yönetimi, kayıt kilidi bekleme sürelerini, ölü kilit zaman aşımını ve CPF (Kontrol Programı Tesisatı) hata mesajlarını uygun tarayıcı örneğine zamanında iletmelidir; oturumları çapraz kirletmeden veya imleç pozisyonu bağlamını kaybetmeden.
Sistematik bir metodoloji, Protokol Sadakati Testi, Eşzamanlılık Stres Testi ve Görsel Parite Doğrulama içeren üç seviyeli bir yaklaşım gerektirir.
İlk olarak, alan özelliklerinin ve AID dizilerinin bir tabanını oluşturmak için Wireshark veya IBM i Access Client Solutions izlerini kullanarak ham 5250 veri akışlarını yakalayın. Her alan türünü (alfa, ondalıksız sayısal, MDY ayırıcılarıyla tarih alanları gibi) test eden test durumları oluşturun ve web sargısının istemci tarafında, ana bilgisayarın EDTCDE ve EDTWRD mantığını aynen uygulayarak aynı kısıtlamaları uyguladığını doğrulayın.
İkinci olarak, verilen veritabanı kaydını hedef alan denetimli Windows terminal oturumlarını ve tarayıcı örneklerini kullanarak çoklu kullanıcı senaryolarını düzenleyin. 5250 emülatörünün MSGWAIT durumunun, web katmanına engel olmayan AJAX sorgulaması veya WebSocket bildirimleri olarak doğru bir şekilde iletildiğini ve DASD kayıt kilitlerinin, tarayıcı oturumları zaman aşıma uğradığında veya başka bir yöne gittiğinde uygun şekilde serbest bırakıldığını doğrulayın.
Üçüncü olarak, alt dosya (kaydırılabilir ızgara) görüntülemesinin yeşil ekran satır/sütun hizalamasıyla eşleştiğini sağlamak için Applitools veya Sikuli gibi piksel başına karşılaştırma araçlarını kullanın. Kısmi sayfa güncellemelerinin __HTML tablo sanal kaydırma ile senkronize edilmesi gereken SFLSIZ ve SFLPAG kaydırma davranışlarına özel bir dikkat gösterin.
Bir dağıtım şirketinin IBM i tabanlı envanter sistemi için bir modernizasyon girişimi sırasında, QA ekibi, yeni HTML5 arayüzünü kullanan depo kullanıcılarının birbirlerinin stok ayarlamalarını yanlışlıkla geçersiz kıldıklarını keşfetti. Miras yeşil ekran uygulaması, eşzamanlı düzenlemeler gerçekleştiğinde doğru şekilde kayıt kilitlerini uygulamış ve "Kayıt Kullanıcı X tarafından kullanılıyor" şeklinde gösteriyordu. Ancak, web sargısı, her iki kullanıcının da aynı anda düzenleme moduna girmesine izin veriyordu; bu durum, sırasıyla ODBC katmanında tetiklenen "Güncelleme çakışması" veritabanı hatalarına ve kullanıcı dostu olmayan HTTP 500 hatalarına yol açarak veri bütünlüğü sorunları ve kullanıcı karmaşası yarattı.
Aynı DB2 kaydına yapılan tüm istekleri, eşzamanlı modifikasyonları tamamen önlemek için tek bir örnek adaptör desenine göre sıraya alan bir sunucu tarafı sırası uygulayın. Bu yaklaşım, veri bütünlüğünü garanti altına alırken yüksek hacimli depo vardiyalarında bir sıkışıklık yaratmakta ve kullanıcıların birleşme çakışması çözümü ile eşzamanlı düzenleme yeteneklerini beklediği modern web kullanıcı deneyiminden sapmaktadır.
Kullanıcılara verileri alma imkânı tanırken ikinci bir taahhüdü belirli bir çakışma mesajı ile reddetmek için DB2 RRN (Göreli Kayıt Numarası) veya zaman damgası sütunları kullanarak satır seviyesinde versiyonlama sağlamak. Bu yöntem sessizce geçersiz kılmaları önler ve okuma yoğun işlemler için daha iyi bir ölçeklenebilirlik sunar; aynı zamanda REST ilkelərinə uyum sağlar ve çakışma çözüm iş akışları için açık geri bildirim sağlar. Ancak, bu durum, teknik olarak IBM i sistemine ait miras fiziksel dosyaların şemasında değişiklikler gerektirdiğinden, eski programların versiyon sütunlarını otomatik olarak güncelleyememesi, yeşil ekran ve web kullanıcıları arasında senkronizasyon açıkları oluşturabilir.
IBM i'nin yerel kayıt kilidi durum mesajlarını (CPF5027, CPF5074) doğrudan web arayüzüne modallara geçirerek 5250 emülasyon katmanını yapılandırın, bu yolla yeşil ekran deneyimi ile tam davranış paritesini koruyun. Bu yaklaşım, mevcut iş mantığını değiştirmeden koruma sağlarken, web kullanıcılarının terminal kullanıcılarıyla aynı mesajları ve zamanlamaları görmesini sağlar; mevcut IBM i güvenlik ve denetim izlerini, orta katman müdahale olmadan kullanır. Dezavantajı, DSPSIZ ve INDARA niteliklerini doğru bir şekilde ayrıştırma ve çevirme konusunda derinlemesine anlamaya ihtiyaç duyulması ve kullanıcıların tarayıcıları yenilediklerinde veya bağlantıyı kaybettiklerinde oturum yönetiminin karmaşık hale gelmesidir; bu durum, kayıt kilitleri tutan 5250 oturumlarını yetim bırakarak çıkabilir.
Ekip, Çözüm C'yi seçti çünkü düzenleyici ortam (ilaç dağıtımı) eski ve yeni arayüzler arasında mutlak davranış paritesi gerektiriyordu; herhangi bir sapma, miras sistemin doğrulama belgelerinin geçersiz kılınmasına yol açabilirdi. Her tarayıcı sekmesi için sürekli bir terminal oturumu sürdürerek WebSocket tabanlı 5250 oturum köprüsü uygulayarak, sargı, kayıt kilidi beklemelerini ve MSGID görüntülerini gerçek zamanlı olarak doğru bir şekilde yansıtmak mümkündü.
Web arayüzü, yeşil ekranın "Kayıt kullanılıyor" davranışını başarıyla yansıtıyor ve CPF mesajlarının tam kopyalarını modern stilli modal arayüzlerde gösteriyordu. Sonraki yük testleri, 5250 oturum havuzunun, her tarayıcı sekmesinin ayrı bir QINTER alt sistem işini tükettiğinden, pik depo trafiğini ele almak için otomatik ölçeklendirme yapılandırmalarına ihtiyaç duyduğunu ortaya koymuştur. Proje, ana RPG programlarını yeniden yazmadan FDA onayını almış; ancak, istemci tarayıcı çöküşlerinin istenmeyen kilitleri tutabilecek yetim 5250 oturumlarını izlemek için izleme panelleri eklenmiştir.
Alt dosya kontrol kayıtlarının (SFLCTL) SFLINZ ve SFLRNA niteliklerinin, alt dosya sayfalarını dinamik olarak başlatırken web sargısı tarafından doğru bir şekilde yorumlandığını nasıl doğruluyorsunuz?
Adaylar genellikle yalnızca görünür veri satırlarına odaklanarak, 5250 alt dosyaların sayfa boyutu, alt dosya boyutu ve kaydırma göstergelerini tanımlayan kontrol kayıtı formatlarına dayandığını gözden kaçırırlar. SFLINZ (Alt dosyayı başlat) etkin olduğunda, ana bilgisayar, HTML5 içinde boş düzenlenebilir satırlar olarak işlenmesi gereken boş kayıtlar gönderir; ayrıca SFLRNA (Aktif Olmayan Alt Dosya Kayıtları), giriş kapsayıcı alanların veri alıp alamayacağını kontrol eder. Test edenlerin, sargının bu göstergeleri DOM öğesinin disabled niteliklerine ve input alanının varlığına doğru haritaladığını doğrulamaları gerekir; böylece kullanıcılar kaydırdıklarında AID kodlarının belirli SFLROLVAL (Kaydırma Değeri) göstergelerini tetiklemesini sağlamak için RPG programının sonraki veri sayfalarını alması gerekmektedir.
Web tarayıcıları, 5250 veri akışının tarayıcı görüntülemesi için UTF-8'e dönüşümü gerçekleştiğinde EBCDIC özel grafik karakterlerinin (örneğin, CCSID 37 kutu çizim karakterleri veya para birimi sembolleri) aktarım doğruluğunu nasıl doğruluyorsunuz?
Birçok testçi, standart karakter kodlama dönüşümünün tüm durumları ele aldığını varsayar. Ancak, 5250 terminalleri alternatif karakter setlerini ve COLOR/DSPATR niteliklerini destekler ki bunlar da Unicode birleştirme karakterlerine haritalanır. Metodoloji, CCSID 037 özel karakterlerinin (merkez işareti, boru sembolleri ve onaltılık FF alan belirteçleri gibi) bulunduğu tüm özel karakterleri içeren bir referans ekranı oluşturarak, görünüm çıktısını farklı tarayıcılar (Chrome, Edge, Safari, Firefox) arasında karşılaştırmayı gerektirir. İkili bayt karakter setleri için DBCS ortamları için Çin, Japon veya Kore dili desteğinin sağlanabilmesi adına, SO/SI (Shift-Out/Shift-In) karakterlerine özel dikkat gösterilmelidir; böylece FF (Alan Formatı) baytının konumlandırılmasının düzgün korunması, veri alanlarının kesilmesini ya da RNX0101 hatalarını önlemek içindir.
Tarayıcı kısayol tuşları veya işletim sistemi anahtar bağlamaları, miras 5250 fonksiyon tuşu beklentileri ile çeliştiğinde AID kodu işlemesini nasıl test edersiniz?
Adaylar, genellikle tarayıcıların belirli işlev tuşlarını (F1, F3, F5, F12) kendi kullanımına tahsis ettiğini ya da macOS'un F-tuşlarına Windows'tan farklı bir şekilde baktığını gözden kaçırır. Sistematik yaklaşım, her bir 5250 AID kodunu (F1-F24, CLEAR, HELP, HOME) haritalamak ve test durumlarından, tarayıcıdaki keydown olaylarının varsayılan davranışı önlemesine yönelik doğrulama yapmakta; böylece tarayıcı yenileme (F5) veya geliştirici araçları (F12) tetiklenmeden, AID kodlarının farklı POST parametreleri veya WebSocket mesajları olarak iletilebildiğini doğrulamakta; ayrıca CA (Komut Dikkati) ve CF (Komut Fonksiyonu) arasında ayrımın korunması sağlanarak, CA tuşlarının RPG programının INZSR alt yordamını tetiklemeden, değiştirilmiş alanları doğrulamadığı; CF anahtarlarının ise alan verilerini gönderdiği doğrulanmalıdır. Ayrıca, doğrulama, Windows, macOS ve Linux istemcileri arasında farklı klavye düzenleri (ABD, İngiltere, Alman) ile gerçekleştirilmelidir; böylece F13-F24 emülasyonu için kullanılan Alt ve Ctrl kombinasyonlarının Alt+F4 veya Ctrl+Shift+F gibi işletim sistemi düzeyindeki kısayolları tetiklemediğinden emin olunmalıdır.