메인프레임 및 중간 범위 현대화 프로젝트는 종종 IBM Rational Host Access Transformation Services (HATS), Rocket LegaSuite 또는 맞춤형 5250 에뮬레이션 게이트웨이와 같은 도구를 사용하여 전통적인 녹색 화면 논리를 웹 래퍼 내에 캡슐화합니다. 테스트 수행자는 종종 웹 레이어가 단순한 통과 역할을 한다고 가정하지만, EBCDIC 문자 인코딩, 5250 필드 속성 및 HTML5 위젯 간의 번역은 검증 논리, 오류 메시지 및 동시성 제어가 소스 시스템과 다를 수 있는 추상화 계층을 도입합니다. 이 질문은 후보자가 전통적인 터미널 에뮬레이션과 현대 웹 프로토콜의 교차점에서 발생하는 행동을 테스트할 수 있는 능력을 조사합니다.
핵심 도전은 5250 터미널 세션의 상태 저장 특성과 비상태 HTTP 요청-응답 주기 사이에 있습니다. 전통적인 애플리케이션은 필드 수준 제약(서명된 숫자 영역, 필수 입력, 필드 종료 체크와 같은)을 시행하기 위해 5250 데이터 스트림에 의존하며, AID 코드를 사용하여 ENTER, CLEAR, ROLL UP 또는 ROLL DOWN과 같은 특정 사용자 행동을 신호합니다. 여러 사용자가 웹 래퍼를 통해 동일한 DB2 for i 레코스에 접근할 때, 기저의 5250 세션 관리는 레코드 잠금 대기, 교착 상태 시간 초과 및 CPF(제어 프로그램 시설) 오류 메시지를 적절한 브라우저 인스턴스로 정확하게 프록시하여 세션 간의 교차 오염이나 커서 위치 컨텍스트 손실 없이 처리해야 합니다.
체계적인 방법론은 세 가지 단계의 접근 방식을 필요로 합니다: 프로토콜 충실도 테스트, 동시성 스트레스 테스트, 시각적 동등성 검증.
첫째, Wireshark 또는 IBM i Access Client Solutions 추적을 사용하여 원시 5250 데이터 스트림을 캡처하여 필드 속성 및 AID 시퀀스의 기준선을 수립합니다. 각 필드 유형(알파, 소수점이 포함된 숫자, MDY 구분 기호가 있는 날짜 필드)을 테스트하는 경우를 작성하고 웹 래퍼가 호스트의 EDTCDE 및 EDTWRD 논리를 반영하는 클라이언트 측 JavaScript 검증을 통해 동일한 제약을 시행하는지 확인합니다.
둘째, 통제된 Windows 터미널 세션과 브라우저 인스턴스를 사용하여 다중 사용자 시나리오를 조정하고 동일한 데이터베이스 레코드를 목표로 합니다. 5250 에뮬레이터의 MSGWAIT 상태가 웹 레이어에 비차단 AJAX 폴링 또는 WebSocket 알림으로 올바르게 전파되고 브라우저 세션이 시간 초과되거나 탐색할 때 DASD 레코드 잠금이 적절히 해제되는지 확인합니다.
셋째, Applitools 또는 Sikuli와 같은 픽셀 완벽 비교 도구를 사용하여 서브파일(스크롤 가능한 그리드) 렌더링이 녹색 화면 행/열 정렬과 일치하는지 확인합니다. 부분 페이지 업데이트가 HTML 테이블 가상 스크롤과 동기화되어야 하는 SFLSIZ 및 SFLPAG 롤 동작에 특별한 주의를 기울입니다.
유통 회사의 IBM i 기반 재고 시스템 현대화 이니셔티브에서 QA 팀은 새로운 HTML5 인터페이스를 사용하는 창고 사용자들이 서로 자신의 재고 조정을 잘못 덮어쓰고 있다는 것을 발견했습니다. 레거시 녹색 스크린 애플리케이션은 동시에 편집이 발생할 때 "레코드가 사용자 X에 의해 사용 중"이라고 표시하면서 레코드 잠금을 정확하게 시행했습니다. 그러나 웹 래퍼는 두 사용자가 동시에 편집 모드에 들어갈 수 있도록 허용하는 것처럼 보였으며, 그 결과 ODBC 레이어에서 일반적인 HTTP 500 오류로 표시되는 "업데이트 충돌" 데이터베이스 오류가 발생했습니다. 이는 데이터 무결성 문제와 사용자 혼란을 초래했습니다.
서버 측 큐를 구현하여 모든 요청을 동일한 DB2 레코드로 직렬화하여 단일 인스턴스 어댑터 패턴을 통해 웹 래퍼가 단일 5250 워크스테이션의 차단 행동을 모방하도록 강제합니다. 이 방법은 사용자의 동시 수정을 완전히 방지하여 데이터 무결성을 보장하지만, 높은 볼륨의 창고 근무 시간 동안 성능 저하의 병목 현상을 발생시키고 사용자들이 병합 충돌 해결 없이 동시 편집 가능성을 기대하는 현대 웹 UX 기대와 다릅니다.
DB2 RRN(상대 레코드 번호) 또는 타임스탬프 열을 사용하여 행 수준 버전 관리를 활용하고 두 사용자가 데이터를 검색할 수 있지만 두 번째 커밋은 특정 충돌 메시지로 거부합니다. 이 방법은 침묵하는 덮어쓰기를 방지하고 읽기 집중 작업에 더 잘 확장되며, RESTful 관행에 부합하여 충돌 해결 워크플로우에 대한 명확한 피드백을 제공합니다. 그러나 기술적으로 IBM i 시스템 소유인 레거시 물리적 파일에 스키마 수정을 요구하며, 레거시 프로그램은 자동으로 버전 열을 업데이트하지 않을 수 있어 녹색 스크린 및 웹 사용자 간의 동기화 간격을 초래할 수 있습니다.
5250 에뮬레이션 레이어를 구성하여 IBM i의 원주율 잠금 상태 메시지(CPF5027, CPF5074)를 웹 인터페이스로 직접 모달 대화 상자로 투명하게 프록시하여 녹색 화면 경험과 행동 동등성을 유지합니다. 이 방법은 기존 비즈니스 논리를 수정 없이 보존하고 웹 사용자가 터미널 사용자와 동일한 메시징 및 타이밍을 볼 수 있게 하여 기존 IBM i 보안 및 감사 추적을 활용합니다. 단점은 5250 프로토콜의 미세한 차이를 올바르게 구문 분석하고 변환하려면 깊은 이해가 필요하며, 사용자가 브라우저를 새로 고치거나 연결이 끊길 경우 세션 관리가 복잡해질 수 있으며, 이로 인해 레코드 잠금을 보유한 5250 세션을 고아 상태로 만들 수 있습니다.
팀은 규제 환경(제약 유통)이 구형 및 신규 인터페이스 간의 절대 행동 동등성을 요구했기 때문에 해결책 C를 선택했습니다. 레코드 경합을 처리하는 방식의 편차는 레거시 시스템의 검증 문서를 무효화할 수 있습니다. 웹 소켓 기반 5250 세션 다리기를 구현하여 브라우저 탭당 영속적인 터미널 세션을 유지함으로써 래퍼는 레코드 잠금 대기 및 MSGID 표시를 실시간으로 정확하게 반영할 수 있었습니다.
웹 인터페이스는 녹색 화면의 "레코드 사용 중" 행동을 성공적으로 복제하여 CPF 메시지의 정확한 복제본을 현대적인 스타일 모달로 표시했습니다. 후속 부하 테스트에서 5250 세션 풀이 피크 창고 트래픽 처리 능력을 위해 자동 확장 구성을 필요로 한다는 것이 밝혀졌습니다. 각 브라우저 탭은 전용 QINTER 서브시스템 작업을 소모했습니다. 이 프로젝트는 핵심 RPG 프로그램을 다시 작성하지 않고도 FDA 검증을 달성했지만 고아 상태의 5250 세션을 추적할 수 있는 모니터링 대시보드가 추가되었습니다.
서브파일 제어 레코드(SFLCTL)가 SFLINZ 및 SFLRNA 키워드가 웹 래퍼에 의해 올바르게 해석되는지를 어떻게 검증할 것인가?
후보자들은 종종 보이는 데이터 행만 집중하여 5250 서브파일이 페이지 크기, 서브파일 크기 및 스크롤 지시기를 정의하는 제어 레코드 형식에 의존한다는 점을 놓칩니다. SFLINZ(서브파일 초기화)가 활성화된 경우 호스트는 빈 레코드를 보내며, 이 레코드는 HTML5에서 빈 편집 가능한 행으로 렌더링되어야 합니다. 반면, SFLRNA(비활성 서브파일 레코드)는 입력 가능 필드가 데이터를 수용하는지 여부를 제어합니다. 테스트자는 래퍼가 이러한 지표를 DOM 요소의 disabled 속성과 input 필드 존재에 올바르게 매핑하는지 확인해야 하며, SFLROLVAL(스크롤 값) 지표가 사용자가 HTML 컨테이너를 스크롤할 때 특정 AID 코드를 트리거하도록 보장하여 RPG 프로그램이 후속 데이터 페이지를 가져오는 올바른 제어 흐름을 받을 수 있도록 해야 합니다.
EBCDIC 특별 그래픽 문자(예: CCSID 37 박스 드로잉 문자 또는 통화 기호)의 전사 정확성을 검증하기 위한 방법론은 무엇인가?
많은 테스트 수행자들은 표준 문자 인코딩 변환이 모든 경우를 처리한다고 가정하지만 5250 터미널은 대체 문자 집합 및 필드 수준 COLOR/DSPATR 속성을 지원하고 이는 유니코드 결합 문자의 매핑에 해당합니다. 이 방법론은 모든 CCSID 037 특별 문자가 포함된 참조 화면을 제작한 후 브라우저 간의 렌더링 출력을 비교해야 합니다(Chrome, Edge, Safari, Firefox). SO/SI(Shift-Out/Shift-In) 문자가 DBCS 환경의 단일 바이트 및 이중 바이트 문자 집합 간 전환을 토글하는 데 특별한 주의를 기울여야 하며, DB2 데이터 흐름 내에서 FF(필드 포맷) 바이트 위치가 보존되어 입력 필드의 잘못된 정렬을 방지해야 합니다. 결코 RPG 프로그램이 잘린 데이터를 읽거나 RNX0101 오류를 발생시키지 않도록 해야 합니다.
브라우저 단축키 또는 운영 체제 키 바인딩이 레거시 5250 기능 키 기대와 충돌할 때 AID 코드 처리를 어떻게 테스트할 것인가?
후보자들은 종종 브라우저가 특정 기능 키(F1, F3, F5, F12)를 자신을 위해 예약하거나 macOS가 F-key를 Windows와 다르게 처리한다는 점을 간과합니다. 체계적인 접근 방식은 각 5250 AID 코드를 매핑하여 테스트 사례를 확인하여 브라우저 keydown 이벤트가 기본 동작을 방지하여 브라우저 새로 고침(F5) 또는 개발자 도구(F12)의 발생을 방지하고 AID 코드가 일반 버튼 클릭이 아닌 별도의 POST 매개변수로 전송되도록 확인합니다. 또한 CA(명령 주의)와 CF(명령 기능) 구분이 보존되어 CA 키가 RPG 프로그램의 INZSR 서브루틴을 트리거하도록 하며 수정된 필드를 검증하지 않으면서 CF 키는 필드 데이터를 제출하도록 해야 합니다. 또한 검증은 Windows, macOS 및 Linux 클라이언트에서 여러 차이 키보드 레이아웃(US, UK, German)을 고려하여 AID 키 조합으로 Os 수준 단축키가 겹치지 않도록 해야 합니다(일반적으로 Shift+F1부터 Shift+F12까지는 F13-F24 에뮬레이션을 위해 Alt+F4 또는 Ctrl+Shift+F와 같은 단축키를 트리거하지 않도록).