AWS 메인프레임용 변환 FAQ

메인프레임 리팩터링 기능을 위한 AWS 변환의 주요 목적은 무엇입니까?

리팩터링 기능은 자동화된 리팩터링 패턴에 따라 최신 언어 및 프레임워크를 사용하는 현대적 분산 애플리케이션을 사용하여 레거시 모놀리식 코드를 자바로 리팩터링합니다. 이 패턴에는 비즈니스 로직을 유지하면서 레거시 코드를 자동으로 분석하고, 기능을 이해하고, 동등한 최신 코드로 변환하는 작업이 포함됩니다. 프로세스에는 코드뿐만 아니라 자동화된 도구 및 프로세스를 사용하여 전체 애플리케이션 스택, 종속성 및 인프라를 현대화하는 것이 포함됩니다. 이 솔루션은 기능적 동등성과 성능을 유지하면서 현대화 속도를 높이는 것을 목표로 합니다. 여기에는 클라우드 모범 사례 및 설계 패턴을 구현하는 동시에 애플리케이션 코드와 관련 데이터베이스 및 데이터 스토어를 모두 변환하는 작업이 포함됩니다.

메인프레임용 AWS 변환에서 지원하는 메인프레임 애플리케이션은 무엇입니까?

AWS 메인프레임용 변환은 현재 COBOL, PL/I, JCL(작업 제어 언어)로 작성되고 CICS(고객 정보 제어 시스템) 트랜잭션 관리자, BMS(기본 매핑 지원) 화면, IMS MFS 화면, DB2 데이터베이스, IMS 데이터베이스, 플랫 파일, GDG(생성 데이터 그룹) 및 VSAM(가상 스토리지 액세스 방법) 데이터 파일에 의존하는 IBM z/OS 메인프레임 애플리케이션의 현대화를 지원합니다.

메인프레임 현대화를 위해 AWS 변환할 수 있는 메인프레임 언어는 무엇입니까?

AWS 메인프레임용 변환은 COBOL 및 PL/I 코드를 Java로, JCLs Groovy로, 화면(BMS 또는 MFS)을 HTML(Sass 사용)로, JavaScript(각형 애플리케이션 - React는 현재 지원되지 않음)로 변환하여 레거시 메인프레임 애플리케이션을 클라우드 네이티브 아키텍처로 현대화할 수 있습니다. 이러한 기술은 광범위한 채택, 강력한 에코시스템 및 클라우드 네이티브 기능을 위해 선택됩니다. Angular는 레거시 그린 스크린 인터페이스를 대체하는 현대적이고 응답성이 뛰어난 사용자 인터페이스 계층을 제공합니다. 이를 통해 다양한 디바이스와 플랫폼에서 액세스할 수 있는 동적이고 사용자 친화적인 웹 애플리케이션을 생성할 수 있습니다. 구성 요소 기반 아키텍처는 유지 관리 가능하고 확장 가능한 프런트 엔드 개발을 지원합니다. 변환을 통해 최신 아키텍처 패턴과 모범 사례를 따르는 분산 애플리케이션이 생성됩니다.

메인프레임용 AWS 변환은 레거시 제약 조건과 클라우드 이점의 균형을 어떻게 맞추나요?

AWS 메인프레임의 변환은 클라우드 네이티브 기능을 도입하는 동시에 중요한 비즈니스 로직과 기능을 보존하여 균형을 달성합니다. 이를 통해 현대화된 애플리케이션이 클라우드 확장성, 민첩성 및 최신 운영 관행을 활용하면서 필요한 레거시 비즈니스 로직을 유지할 수 있습니다. 이 접근 방식은 조직이 비즈니스 연속성을 유지하면서 클라우드 인프라의 이점을 얻는 데 도움이 됩니다.

현대화된 애플리케이션에서 서비스 지향 아키텍처는 어떤 역할을 합니까?

서비스 지향 아키텍처는 모놀리식 애플리케이션을 보다 관리 가능한 모듈식 구성 요소로 분류하는 데 있어 기본적인 역할을 합니다. 메인프레임용 AWS 트랜스포메이션은 더 나은 유지 관리성과 확장성을 지원하는 서비스 지향 및 객체 지향 애플리케이션을 생성합니다. 이러한 아키텍처 접근 방식을 통해 조직은 비즈니스 효율성을 높이고 잠재적인 향후 마이크로서비스 채택에 대비할 수 있습니다.

리팩터링 프로세스에는 애플리케이션 스택의 어떤 측면이 포함되나요?

리팩터링 프로세스에는 애플리케이션 코드, 종속성, 데이터베이스 및 인프라(예: 캐싱 옵션, 메시징 지원 등)와 같은 전체 소프트웨어 스택이 포함됩니다. 레거시 프로그래밍 언어, 데이터베이스 시스템, 데이터 파일 및 관련 인프라 구성 요소의 변환을 다룹니다. 이 포괄적인 접근 방식을 사용하면 애플리케이션의 모든 측면을 일관되게 현대화하여 완전히 변환된 최신 애플리케이션 스택을 만들 수 있습니다.

메인프레임 현대화를 위한 AWS 변환 프로세스로 인해 현대화된 Java 애플리케이션에 대한 테스트 또는 품질 보증 검사가 필요하지 않나요?

아니요, 메인프레임 현대화를 위한 AWS 변환 프로세스는 현대화된 Java 애플리케이션에 대한 테스트 또는 품질 보증 검사가 필요하지 않습니다.

메인프레임 JAC용 AWS 변환은 무엇을 의미하나요?

JAC는 JICS 관리 콘솔을 의미합니다.

메인프레임용 AWS 변환 도구에 액세스하려면 어떻게 해야 합니까?

AWS 메인프레임 도구 변환은 인증 수준에 따른 기능 액세스로 AWS 메인프레임 현대화(M2) 리팩터링을 통해 AWS 콘솔을 통해 액세스할 수 있습니다. 변환 센터에서 시작하여 소스 코드의 자동 Java 리팩터링을 평가합니다. 자세한 지침은 AWS Transform for mainframe리팩터링 설명서를 참조하세요. 현대화 후에는 런타임을 사용하여 애플리케이션을 배포할 수 있습니다. 자세한 내용은 AWS Mainframe Modernization 설명서를 참조하세요.

프로젝트의 크기를 조정(워크로드 및 타임라인)하려면 어떻게 해야 하나요?

이에 대한 자세한 내용은 메인프레임 리팩터 추정치에 대한 AWS 변환을 참조하거나 계정 관리자와 협력하세요.

메인프레임 마이그레이션 솔루션을 위한 Java AWS 변환을 유지하기 위한 특정 요구 사항이 있나요?

아니요. 메인프레임 마이그레이션된 솔루션의 Java AWS 변환을 유지하기 위한 특정 요구 사항은 없습니다.

메인프레임 생성 코드에 대한 AWS 변환의 기술 사양 및 호환성은 무엇입니까?

AWS 메인프레임 생성 코드에 대한 변환은 특정 기술적 특성과 광범위한 호환성으로 설계되었습니다. JPA는 지원하지 않지만 외부화된 쿼리와 함께 직접 SQL 실행을 사용합니다. 이 코드는 기능적 동등성, 웹 서비스 생성 및 MQ 구현을 위해 런타임별 라이브러리를 사용합니다. 생성된 코드는 개발, 테스트, 구축 및 배포를 위해 Java IDE로 가져올 수 있지만 필요한 라이브러리는 그에 따라 가져와야 합니다. Maven은 기본적으로 빌드 프로세스를 위한 AWS Mainframe Modernization 서비스와 통합되지만, 변환 후 패키징 형식을 수정하여 Gradle과 같은 대체 도구를 사용할 수 있습니다. 플랫폼은 코드를 관리하는 개발 팀이 훈련을 사용할 수 있도록 개발 도구 및 소스 제어 측면에서 유연성을 제공합니다. 자세한 내용은 AWS 메인프레임 런타임 상위 수준 아키텍처의 변환을 참조하세요.

메인프레임 런타임의 AWS 변환에 대한 정보는 어디에서 찾을 수 있습니까?

설정 프로세스 온보딩, 아티팩트 검색, 배포 등을 자세히 설명하는 AWS Transform for mainframe 런타임 설정 설명서 런타임을 참조하세요.

메인프레임 JAR 종속성에 대한 AWS 변환이 로컬 개발을 위해 클라이언트의 Maven 리포지토리에 업로드됩니까?

개발, 테스트 및 프로덕션 환경을 구성하는 데 사용할 수 있는 AMI를 사용하여 라이브러리를 EC2로 가져올 수 있습니다. 생성된 애플리케이션 코드를 유지 관리/개선하기 위해 팀에 훈련 및 활성화가 제공됩니다. 자세한 내용은 AWS 메인프레임 런타임 상위 수준 아키텍처의 변환을 참조하세요.

메인프레임 런타임 jar의 분산 AWS 변환에서 “Gapwalk”라는 용어는 무엇을 의미하나요?

Gapwalk에 대한 자세한 내용은 AWS 메인프레임 런타임 아티팩트 변환을 참조하세요.

메인프레임 런타임용 AWS 변환에 대한 액세스를 요청하려면 어떻게 해야 합니까?

런타임은의 AWS Transform for mainframe 도구 상자를 통해 액세스할 수 있습니다AWS Transform for mainframe refactor.

메인프레임 리팩터링된 애플리케이션에 지원되는 AWS 변환 런타임은 무엇입니까?

AWS Transform for mainframe는 현대화 여정 및 운영 요구 사항의 다양한 단계에 맞는 단일 런타임을 제공합니다. AWS Transform for mainframe 런타임을 참조하세요.

메인프레임 런타임의 AWS 변환은 언제 사용되나요?

메인프레임 리팩터링된 애플리케이션의 AWS 변환 실행을 지원하려면 메인프레임 런타임에 대한 AWS 변환이 필요합니다. 리팩터링된 애플리케이션을 테스트하기 위해 메인프레임 기반 리팩터링 프로젝트를 AWS 변환하는 동안 런타임이 필요합니다. 리팩터링 프로젝트가 끝나면 프로덕션 환경에서 메인프레임 리팩터링된 애플리케이션의 AWS 변환을 유지 관리, 테스트 및 실행하는 데 런타임도 필요합니다.

는 메인프레임 런타임용 AWS 변환에 대한 새 릴리스를 어떻게 AWS 배포하나요?

런타임 릴리스는 AWS Transform for mainframe AWS Transform for mainframe 도구 상자를 통해 액세스할 수 있습니다. AWS Transform for mainframe 릴리스 정보를 참조하세요.

AWS Transform for mainframe 런타임의 새 메이저 및 마이너 버전은 얼마나 자주 릴리스되나요?

자세한 내용은 AWS Mainframe Modernization 구성 요소 수명 주기를 참조하세요.

AWS 는 메인프레임 런타임에 대한 AWS 변환을 어떻게 지원하나요?

에서 실행되는 워크로드에 AWS Support 대한 지원은를 통해 제공되며 AWS, 티켓을 발행하여 문제를 해결하고 표준 SLA를 적용합니다. 자세한 내용은 AWS 메인프레임 현대화 구성 요소 수명 주기를 참조하세요.

AWS 메인프레임 런타임의 메인프레임 현대화 AWS 변환에는 무엇이 수반되나요?

메인프레임 런타임을 위한 AWS 변환에는 현대화 가속화, 클라우드 통합 촉진, 코드 품질 및 유지 관리 용이성 개선을 위한 도구 상자 라이브러리가 포함되어 있습니다. 또한 레거시 아키텍처와 클라우드 아키텍처 간의 전환을 촉진하여 현대화 자동화를 강화할 수 있습니다. 런타임은 java 관용구를 사용하여 레거시 동사 및 데이터 구조 메모리 표현을 처리할 수 있도록 지원합니다. 이를 통해 객체 지향 프로그래밍 기술을 기반으로 현대화된 애플리케이션을 구축하고 레거시 제어 흐름을 재현할 수 있습니다. Amazon Aurora와 같은 관계형 데이터베이스를 사용하여 레거시 VSAM 데이터 세트 또는 IMS 계층적 데이터베이스 지원을 현대화합니다. 레거시 시스템 유틸리티(IDCAMS, IEBGENER, DFSORT 등) 및 레거시 트랜잭션 관리 시스템(CICS, IMS)에 대한 Java 대체를 제공합니다. Amazon ElastiCache의 캐싱과 클라우드 통합을 촉진하고 AWS 메시징 솔루션(SQS, Kinesis)을 지원합니다.

메인프레임 런타임에 대한 AWS 변환은 x86이 아닌 컴퓨터 아키텍처를 지원하나요?

현재 메인프레임 런타임용 AWS 변환은 x86 기반 컴퓨터 아키텍처 및 컴퓨팅만 지원합니다. 메인프레임 런타임용 AWS 변환은 ARM 기반 및 Graviton 기반 컴퓨팅을 지원하지 않습니다.

고객은 새 릴리스 알림, 버전 기록 및 릴리스 정보에 대한 액세스를 포함하여 메인프레임 런타임 버전의 AWS 변환에 대한 정보를 어떻게 얻을 수 있습니까?

메인프레임 런타임용 AWS 변환의 새 버전은 공식 릴리스 페이지에 업로드됩니다. 최신 버전 및 업데이트는이 페이지를 정기적으로, 이상적으로는 3개월마다 확인하는 것이 좋습니다. 버전 기록 및 릴리스 정보에 대한 액세스와 관련하여 가용성은 각 메이저 버전의 end-of-life(EOL) 날짜에 따라 달라집니다. EOL 날짜, 버전 업그레이드 계획 및 기록 정보에 대한 액세스에 대한 자세한 내용은 AWS 메인프레임 수명 주기 변환을 참조하세요.

메인프레임 런타임 상위 수준 아키텍처를 위한 AWS 변환의 주요 구성 요소는 무엇입니까?

메인프레임 런타임 아키텍처의 AWS 변환은 두 가지 주요 구성 요소 유형으로 구성됩니다. 먼저 레거시 구문 및 문 지원을 제공하는 공유 폴더(애플리케이션 서버 클래스로더에 액세스 가능)에 저장된 Java 라이브러리(jar 파일)입니다. 두 번째는 현대화된 프로그램에 프레임워크와 서비스를 제공하는 Spring 기반 애플리케이션을 포함하는 웹 애플리케이션(전투 파일)입니다. 런타임에는 호출 및 교차 프로그램 호출을 위해 모든 프로그램을 수집하는 프로그램 레지스트리와 현대화된 모든 작업 스크립트를 수집하는 스크립트 레지스트리도 포함됩니다. 이러한 구성 요소는 함께 작동하여 현대화된 애플리케이션을 위한 통합 REST 기반 진입점 및 실행 프레임워크를 제공합니다. 런타임과 현대화된 애플리케이션은 애플리케이션 서버(예: Tomcat)에 함께 배포됩니다.

메인프레임 런타임 아티팩트에 대한 AWS 변환을 포함하는 공유 폴더를 구성하려면 어떻게 해야 합니까?

메인프레임 런타임 아티팩트(jar)에 대한 AWS 변환은 애플리케이션 서버 클래스로더가 액세스할 수 있는 공유 폴더에 수집되어야 합니다. tomcat 서버의 경우 catalina.properties라는 일반 구성 파일을 수정하여 구성합니다. 예를 들어 공유 폴더를 "shared"라는 폴더로 생성한 경우 tomcat 폴더에서 catalina.properties의 common.loader 항목을 수정하여 공유 폴더에 tomcat 클래스로더에 액세스할 수 있도록 해야 합니다.

common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.home}/shared","${catalina.home}/shared/*.jar"

메인프레임 런타임의 AWS 변환은 상태 비저장 및 세션 관리를 어떻게 처리하나요?

AWS 메인프레임 런타임을 위한 변환은 여러 메커니즘을 통해 상태 비저장 및 세션 관리를 구현합니다. HTTP 세션의 경우 사용자 컨텍스트를 위해 외부 캐시 스토리지와 함께 쿠키 기반 식별을 사용합니다. 세션은 Amazon ElastiCache, Redis 클러스터 또는 인 메모리 맵을 비롯한 다양한 데이터 스토어에 저장할 수 있습니다. 상태 비저장성 설계는 대부분의 비일시적 상태가 일반적인 '단일 정보 소스'에 외부적으로 저장되도록 하여 고가용성과 수평적 조정을 가능하게 합니다. 로드 밸런싱 및 공유 세션과 결합된이 접근 방식을 사용하면 여러 노드에 사용자 대면 대화 상자를 배포할 수 있습니다.

메인프레임 런타임 환경의 AWS 변환에서 웹 애플리케이션은 어떤 역할을 합니까?

메인프레임 런타임용 AWS 변환의 웹 애플리케이션은 여러 주요 함수를 제공합니다. 레거시 환경 및 트랜잭션 모니터(예: JCL 배치, CICS, IMS)를 재현하는 실행 프레임워크를 제공합니다. 트랜잭션, 프로그램 및 배치를 트리거하고 제어하기 gapwalk-application.war 위해를 통해 REST 기반 진입점을 제공합니다. 또한 레거시 애플리케이션이 MFS를 통해 IMS DB 또는 사용자 대화 상자와 같은 서비스에 액세스하기 위해 의존하는 OS 제공 프로그램과 특수 '드라이버' 프로그램을 에뮬레이션합니다.

메인프레임 런타임용 AWS 변환에서 프로그램은 어떻게 등록되고 관리되나요?

메인프레임 런타임을 위한 AWS 변환의 프로그램은 서버 시작 중에 채워지는 ProgramRegistry 시스템을 통해 등록됩니다. 각 프로그램은 프로그램 인터페이스를 구현하고 Spring 구성 요소로 표시됩니다. 프로그램은 식별자를 사용하여 등록되며, 프로그램에 여러 식별자가 있는 경우 여러 항목이 있을 수 있습니다. 등록 프로세스는 자동으로 이루어지며 Tomcat 로그에 기록됩니다. ProgramRegistry를 사용하면 다른 프로그램과 스크립트가 등록된 프로그램을 찾고 호출하여 현대화된 시스템의 모듈성과 상호 연결을 유지할 수 있습니다.

메인프레임 런타임 애플리케이션의 AWS 변환에서 구성은 어떻게 관리되나요?

메인프레임 런타임에 대한 AWS 변환의 구성은 Spring Boot 프레임워크 기능을 사용하여 YAML 파일을 통해 관리됩니다. 프레임워크 구성과 application-profile.yml 클라이언트별 옵션에는 application-main.yml이라는 두 가지 기본 구성 파일이 사용됩니다. 시스템은 Spring의 우선 순위 로직을 따르므로 다양한 수단을 통해 구성을 재정의할 수 있습니다. 데이터베이스 및 명령줄 파라미터에 대해 JNDI를 통해 추가 구성을 제공하여 구성 관리에 유연성을 제공할 수 있습니다. 로거 구성은 로그백 xml 구성 파일을 사용하여 수행됩니다.

메인프레임 런타임용 AWS 변환 구성에서 보안 암호 관리자는 어떤 역할을 합니까?

메인프레임 런타임용 AWS 변환의 보안 암호 관리자는 데이터베이스 자격 증명 및 Redis 캐시 암호와 같은 민감한 구성 데이터를 보호합니다. 이를 통해 중요한 데이터를 AWS 보안 암호에 저장하고 YAML 구성 파일에서 참조할 수 있습니다. 시스템은 모든 관련 필드를 자동으로 채우는 데이터베이스 보안 암호와 암호로 보호되는 리소스에 대한 단일 암호 보안 암호를 포함하여 다양한 유형의 보안 암호를 지원합니다. 이 접근 방식은 민감한 데이터를 애플리케이션 구성과 분리하여 보안을 강화합니다.

개발자는 메인프레임 런타임용 AWS 변환과 호환되는 자체 프로그램을 어떻게 작성할 수 있습니까?

개발자는 프로그램 인터페이스를 구현하고 특정 패턴을 따라 메인프레임 런타임 호환 프로그램에 대한 AWS 변환을 생성할 수 있습니다. https://docs.aws.amazon.com/m2/latest/userguide/ba-shared-structure.html 프로그램은 Spring 구성 요소로 선언되고, 필요한 방법을 구현하고, ProgramRegistry에 올바르게 등록되어야 합니다. 개발자는 컴패니언 컨텍스트 및 구성 클래스를 생성하고, 프로그램 식별자를 처리하고, Spring 프레임워크와의 적절한 통합을 보장해야 합니다. 구현은 프로그램 구조 및 실행을 위한 메인프레임 런타임 규칙에 대한 AWS 변환을 따라야 합니다.

메인프레임 런타임에 대한 AWS 변환은 프로그램 실행 오류를 어떻게 처리하나요?

AWS 메인프레임 런타임에 대한 변환은 여러 메커니즘을 통해 프로그램 실행 오류를 처리합니다. 배치 작업의 경우 작업 실행 세부 정보에서 실행 상태, 종료 코드 및 자세한 오류 정보를 캡처합니다. 오류 처리에는 특정 종료 코드(기술 오류의 경우 -1, 서비스 프로그램 장애의 경우 -2)와 Tomcat 로그의 세부 로깅이 포함됩니다. 런타임 예외 시 트랜잭션을 롤백하도록 시스템을 구성할 수 있으며 오류 알림 및 복구 옵션을 제공합니다. 오류 세부 정보는 모니터링 및 문제 해결을 위해 REST 엔드포인트를 통해 액세스할 수 있습니다.

배치 작업에 사용할 수 있는 메인프레임 런타임 모니터링 기능의 AWS 변환은 무엇입니까?

AWS 메인프레임 런타임에 대한 변환은 다양한 엔드포인트를 통해 배치 작업에 대한 모니터링 기능을 제공합니다. 작업 실행 상태, 시작/종료 시간, 실행 모드 및 세부 결과를 추적합니다. 시스템은 트리거된 스크립트를 나열하고, 작업 실행 세부 정보를 검색하고, 현재 실행 중인 작업을 모니터링하기 위한 엔드포인트를 제공합니다. 지표의 엔드포인트는 JVM 통계, 세션 수 및 세부 배치 실행 지표를 제공합니다. 또한 플랫폼은 모니터링 데이터의 페이지 매김 및 시간 기반 필터링을 지원합니다.

메인프레임 런타임 작업 실행 상태에 대한 AWS 변환은 어떻게 추적되고 관리되나요?

작업 실행 상태는 DONE, TRIGGERED, RUNNING, KILLED, FAILED와 같은 상태를 포함하는 포괄적인 상태 시스템을 통해 추적됩니다. 각 작업 실행은 추적을 위한 고유 식별자를 수신하고 시작 시간, 종료 시간, 호출자 정보 및 실행 결과를 포함한 자세한 실행 정보를 유지합니다. 시스템은 작업 상태 쿼리, 실행 중인 작업 관리 및 실행 기록 검색을 위한 REST 엔드포인트를 제공합니다. 상태 정보는 서버 메모리에 유지되며 리소스 관리를 위해 수명에 따라 제거할 수 있습니다.

메인프레임 런타임에 대한 AWS 변환은 외부 시스템 상호 작용을 어떻게 처리하나요?

런타임은 서비스 통합을 위한 REST 엔드포인트, 메시지 대기열(SQS, RabbitMQ, IBM MQ) 지원, 데이터베이스 연결 옵션 등 다양한 메커니즘을 통해 외부 시스템 상호 작용을 처리합니다. 특수 구성 요소를 통해 레거시 시스템 상호 작용을 에뮬레이션하고, 보안 통신을 위해 SSL/TLS를 지원하며, 외부 파일 시스템을 처리하기 위한 기능을 포함합니다. 또한이 시스템은 외부 인증 공급자와의 통합을 지원하며 다양한 타사 서비스와 상호 작용하도록 구성할 수 있습니다.

메인프레임 런타임의 AWS 변환에서 인증은 어떻게 처리되나요?

AWS 메인프레임 런타임에 대한 변환은 OAuth2가 기본 메커니즘인 여러 인증 방법을 지원합니다. Amazon Cognito 또는 Keycloak과 같은 자격 증명 공급자와 통합할 수 있습니다. 인증 구성은 보안 설정, 자격 증명 공급자 및 인증 방법을 정의할 수 있는 application-main.yml이라는 기본 구성 파일을 통해 관리됩니다. 시스템은 XSS 보호, CORS, CSRF와 같은 기능을 지원하며 글로벌 보안과 특정 엔드포인트 보안 모두에 대해 구성할 수 있습니다. 개발을 위해 기본 슈퍼 관리자 자격 증명이 있는 로컬 인증 시스템도 사용할 수 있습니다.

메인프레임 런타임의 AWS 변환은 어떻게 고가용성을 보장하나요?

AWS 메인프레임 런타임의 변환은 여러 메커니즘을 통해 고가용성을 보장합니다. 비일시적 상태를 외부 공유 스토리지에 저장하여 상태 비저장을 구현하므로 여러 애플리케이션 인스턴스가 함께 작동할 수 있습니다. 시스템은 로드 밸런싱 및 공유 세션을 지원하므로 요청을 여러 노드에 배포할 수 있습니다. 데이터 스토리지의 경우 가용성이 높은 데이터베이스와 캐싱 시스템을 활용할 수 있습니다. 아키텍처는 자동 장애 조치를 지원하며 신뢰성 향상을 위해 여러 가용 영역에 배포할 수 있습니다.

메인프레임 애플리케이션용 AWS 변환을 사용하여 CICS 분산 트랜잭션을 재현하는 데 사용되는 구성 요소는 무엇입니까?

메인프레임 런타임용 AWS 변환은 기존 JICS 트랜잭션을 글로벌 트랜잭션의 일부로 호출할 수 있는 전용 엔드포인트를 제공합니다(XA 지원). 기본 두 단계 커밋 지원은 Atomikos 소프트웨어 구성 요소에 의존합니다.

특정 프로그램 동작을 정의하는 데 사용되는 클래스의 AWS 메인프레임 이름 변환은 무엇입니까?

각 프로그램은가 프로그램별 동작을 지정할 수 있는 전용 구성 클래스에 바인딩됩니다. 이름 지정 및 위치 규칙에 대한 자세한 내용은 AWS 현대화된 애플리케이션의 메인프레임 구조 변환을 참조하세요.

공백, 소문자, 대문자, 숫자와 같은 문자 시퀀스 순서가 있는 인코딩은 무엇입니까?

EBCDIC 변형 패밀리에 속하는 샤셋(예: CP1047, CP297 등).

메인프레임 런타임 AWS 변환의 요금 차원은 무엇입니까?

AWS Mainframe Modernization-core-hours(AWS Mainframe Modernization 요금 참조).

HTTP를 통해 원시 데이터를 프로그램 엔드포인트로 전달하는 데 사용되는 메커니즘은 무엇입니까?

Base64 인코딩 문자열입니다.

사용자는 배치 작업 실행을 어떻게 시작하나요?

전용 배치 엔드포인트 중 하나에 대한 HTTP 호출 사용(배치 엔드포인트 설명서 페이지 참조).

메인프레임 런타임 엔드포인트의 AWS 변환은 메인 웹 프런트 엔드 애플리케이션의 주요 진입점입니까?

/transaction

메인프레임 JICS용 AWS 변환은 무엇을 의미하나요?

메인프레임 JICS용 AWS 변환은 CICS 리소스의 현대화를 지원하는 데 사용되는 런타임 구성 요소입니다. 리소스 정의는 전용 데이터 스토어에 저장됩니다. 이를 관리하려면 REST API 또는 JICS 애플리케이션 콘솔을 사용합니다. 자세한 내용은 메인프레임용 AWS 변환의 JICS 애플리케이션 콘솔 관리를 참조하세요.

메인프레임 런타임 캐싱 메커니즘에 사용할 수 있는 AWS 변환은 무엇입니까?

AWS 메인프레임 런타임에 대한 변환은 Redis 및 EhCache를 비롯한 여러 캐싱 메커니즘을 지원합니다. Redis는 프로덕션 환경에 권장되며 여러 노드에서 공유 영구 캐싱을 제공합니다. EhCache는 휘발성 로컬 캐싱이 내장된 독립 실행형 배포에 사용할 수 있습니다. 시스템은 Blusam 데이터, 세션 정보, JICS 리소스, 임시 스토리지 대기열 등 다양한 구성 요소에 대한 캐싱을 지원합니다. 캐시 구성은 다양한 사용 사례 및 성능 요구 사항에 맞게 사용자 지정할 수 있습니다.

AWS 메인프레임 런타임 배포를 위한 메인프레임 현대화 AWS 변환의 가격을 어떻게 추정하나요?

AWS 는 요구 사항 및 대상 아키텍처를 기반으로 고객에게 견적을 제공합니다.

AWS 메인프레임 런타임 가격을 위한 메인프레임 현대화 AWS 변환이란 무엇입니까?

AWS 메인프레임 현대화는 메인프레임용 AWS 변환을 위한 두 가지 요금 모델을 제공합니다. 하나는 런타임, 컴퓨팅 리소스, 내부 스토리지 및 자동화를 포함하는 관리형 런타임 옵션이고, 다른 하나는 AWS 런타임 자체만 포함하는 비관리형 Transform for mainframe 런타임 옵션입니다. AWS 배포의 경우 둘 다 pay-as-you-go 요금 구조를 사용합니다. up-to-date 자세한 요금 정보는 공식 AWS Mainframe Modernization 요금 페이지를 참조하는 것이 좋습니다.

지원되는 런타임에 나열되지 않은 인프라에 메인프레임 리팩터링 애플리케이션을 위한 AWS 변환을 배포해야 하는 경우 어떻게 해야 합니까?

지원되는 런타임에 나열되지 않은 인프라에 메인프레임 리팩터링 애플리케이션을 위한 AWS 변환을 배포해야 하는 경우 여러 옵션을 사용할 수 있습니다. 먼저 인프라가 Amazon EKS Anywhere 또는 기타 컨테이너 오케스트레이션 플랫폼과 같은 기존 배포 옵션과 호환되는지 확인합니다. 그렇다면 메인프레임 런타임에 AWS 변환을 사용할 수 있습니다. 호환되지 않는 인프라의 경우 메인프레임 전문가와 상의 AWS 하여 사용자 지정 솔루션 또는 잠재적 적응을 탐색하는 것이 좋습니다. AWS 는 비AWS 인프라에서 배포되거나 실행되는 워크로드에 대한 지원을 제공하지 않습니다. 확장된 인프라 지원을 위해 제품 기능 요청(PFR)을 제출할 수도 있습니다. AWS 담당자에게 문의하여 특정 요구 사항과 환경에 가장 적합한 접근 방식을 논의합니다.

메인프레임 런타임에 대한 AWS 변환은 어떻게 라이선스가 부여되나요? 오픈 소스입니까?

AWS 메인프레임 런타임에 대한 변환은 오픈 소스가 아닙니다. IP는 클라우드 네이티브 서비스로 AWS 배포됩니다. 두 가지 배포 옵션이 있습니다.

메인프레임 프레임워크 및 라이브러리용 AWS 변환에 대한 변경 및 업그레이드는 어떻게 관리되나요?

AWS 메인프레임 프레임워크 및 라이브러리에 대한 변환은 정기적인 코드 생성 및 배포 프로세스를 통해 업데이트됩니다. 이러한 업데이트는 버전 업그레이드 및 AWS Transform for mainframe 팀 또는 인증된 파트너의 지원을 포함하는 AWS 메인프레임 현대화 수명 주기의 일부로 관리됩니다. 버전 관리, 업그레이드 프로세스 및 지원 타임라인에 대한 자세한 내용은 AWS Mainframe Modernization 수명 주기 설명서를 참조하세요.

메인프레임 런타임용 AWS 변환에서 사용하는 도구(Tomcat, Postgres, MQ 등) 및 종속성(Spring, Angular 등)의 지원되는 버전은 무엇입니까?

릴리스 정보에서 세부 정보를 참조하세요.

BAC 및 JAC의 맥락에서 '독립 실행형'은 무엇을 의미하나요?

독립 실행형은 이러한 웹 애플리케이션이 현대화된 애플리케이션과 별도로 자체 Tomcat 서버에서 독립적으로 실행되도록 허용하는 BAC(Blusam 관리 콘솔) 및 JAC(JICS 관리 콘솔)용 특수 패키징 및 배포 모드를 나타냅니다. BAC 및 JAC 독립 실행형 버전은에서 사용할 수 있습니다aws-bluage-webapps-x.y.z.zip. BAC 및 JAC 비독립 실행형 버전은 webapps-consoles 폴더gapwalk-x.y.z.zip의에서 사용할 수 있습니다. AWS 메인프레임 런타임 아티팩트의 변환을 참조하세요.

레거시 데이터베이스의 현대화와 관련하여 현대화된 애플리케이션에 사용할 수 있는 데이터베이스 옵션은 무엇입니까?

현대화된 애플리케이션은 PostgreSQL, Amazon Aurora, RDS for PostgreSQL, Oracle 데이터베이스, MS-SQL 및 IBM Db2를 비롯한 여러 최신 데이터베이스 옵션을 사용할 수 있습니다. 이러한 옵션은 최신 데이터베이스 관리 시스템과 클라우드 네이티브 기능의 이점을 활용하면서 특정 요구 사항에 따라 가장 적합한 데이터베이스 시스템을 유연하게 선택할 수 있습니다.

에서 Postgres DDL로 IBM Db2의 변환 적용 범위는 어떻게 됩니까? z/OS

전체 변환(데이터베이스 제약 포함).

메인프레임용 AWS 변환은 그룹 데이터 생성(GDG)을 지원하나요?

예, 상대 및 절대 생성과 자동 정리 전략을 지원하여 GDG를 배치로 사용할 수 있습니다.

메인프레임용 AWS 변환은 연결된 데이터 세트를 지원하나요?

예, 연결된 데이터 세트를 배치로 사용하는 것이 지원됩니다. 연결 기능을 사용하면 여러 데이터 세트를 단일 데이터 세트로 읽을 수 있습니다. Blusam 데이터 세트는 연결의 일부가 될 수 없습니다.

SQL 쿼리에는 어떤 프로세스가 적용되나요?

대상 데이터베이스에 따라 코드 변환 중에 조정됩니다.

애플리케이션에 여러 데이터베이스가 있는 경우 어떤 옵션이 적용되나요?

각 쿼리에 대한 대상 데이터베이스를 구성하고 애플리케이션 및 Apache Tomcat의 모든 데이터베이스를 정의합니다.

비활성화Blusam할 수 있습니까?

예, 기본 구성 파일에서 데이터베이스가 필요하지 않습니다(자세한 내용은 Blusam 구성 설명서 페이지 참조).

IMS DB와 같은 데이터베이스를 대체하는 데 사용되는 메인프레임 API용 AWS 변환은 무엇입니까?

JHDB(Java 계층적 DataBase) API입니다. 자세한 내용은 IMS DB/DL/I 에뮬레이션(JHDB)을 참조하세요.

레거시 데이터 및 데이터베이스를 최신 관계형 데이터베이스 관리 시스템(RDBMS)으로 마이그레이션하는 데 사용할 수 있는 메인프레임 제품의 AWS 변환은 무엇입니까?

AWS 메인프레임 DB 현대화 도구(데이터 마이그레이션 도구)를 위한 변환입니다.

메인프레임 데이터 간소화자를 위한 AWS 변환이란 무엇이며 현대화에서 어떤 문제를 해결하나요?

Data Simplifier는 메인프레임용 AWS 변환의 코어 라이브러리로, Java에서 레거시 메모리 액세스 패턴을 처리하는 문제를 해결합니다. 메인프레임 애플리케이션에서는 일반적이지만 Java에서는 기본적으로 사용할 수 없는 하위 수준 메모리 액세스, 레거시 데이터 유형(예: 영역화, 압축, 영숫자) 및 혼합 구조화/원시 메모리 액세스를 지원하는 구문을 제공합니다. 라이브러리는 getter/setter 및 클래스 기반 APIs와 같은 친숙한 Java 패턴을 통해 이러한 기능을 노출하므로 레거시 기능을 유지하면서 Java 개발자가 액세스할 수 있습니다.

메인프레임용 AWS 변환은 레거시 메모리 레이아웃과 데이터 구조를 어떻게 처리하나요?

AWS 메인프레임용 변환은 레코드 인터페이스를 통해 레거시 메모리 레이아웃을 처리합니다.이 인터페이스는 크기가 고정된 바이트 배열의 추상화를 제공합니다. COBOL '01 데이터 항목'과 같은 구조화된 데이터의 경우 현대화 중에 자동으로 생성되는 RecordEntity 하위 클래스를 사용합니다. 이러한 클래스는 레거시 데이터의 계층 구조를 유지하며 각 요소는 상위-하위 관계를 갖습니다. 시스템은 원시 메모리 액세스와 구조화된 액세스 패턴을 모두 지원하여 레거시 시스템의 유연성을 유지하면서 최신 프로그래밍 인터페이스를 제공합니다.

메인프레임용 AWS 변환은 VSAM 데이터 세트 현대화를 어떻게 처리하나요?

Blusam 구성 요소는 전용 API, 엔드포인트 및 관리 웹 애플리케이션(BAC: Blusam 관리 콘솔)을 사용하여 VSAM 데이터 세트의 현대화를 지원합니다. Blusam은 관계형 데이터베이스를 백엔드로 사용합니다(RDS 또는 Aurora를 사용하는 PostgreSQL).

상위-하위 세그먼트 계층 구조는 어떻게 매핑되고 DL/I 현재 위치(GN/GNP 커서)는 어떻게 재현되나요?

계층 구조 매핑. 각 세그먼트 유형은 라는 PostgreSQL 테이블이 되며 <DBDName>_<SegmentName>각 세그먼트 발생은 한 행입니다. 상위-하위 관계는 연결된 키 열(_concatkey)에 의해 전달됩니다. 하위의 _concatkey는 상위의와 _concatkey 하위의 자체 키이므로 모든 하위의 키는 상위의 키로 시작됩니다. 따라서 상위의 모든 하위 항목을 검색하는 것은 키 접두사 일치입니다. (이전_parent/_logicalparentid 열은 이전 버전과의 호환성을 위해 여전히 존재하지만 사용되는 메커니즘_concatkey입니다.)

예 - 2단계 데이터베이스(계정 요약에서 세부 정보):

DBD PADB
  PAUTSUM0 (root, key ACCNTID)          -> table PADB_PAUTSUM0
    PAUTDTL1 (child, key PAUT9CTS)      -> table PADB_PAUTDTL1

계정 아래의 세부 정보 행은 0000012345를 가져오_concatkey = <ACCNTID key> + <detail key>므로 요약 행의 키로 "시작"합니다. 이렇게 하면 런타임이 해당 요약의 하위 항목임을 알 수 있습니다.

논리적 관계 및 논리적 세그먼트도 지원됩니다. 논리적 세그먼트는 데이터베이스 보기로 노출되고 논리적 하위 키는 논리적 상위 키()로 시작됩니다lp_concatkey.

DL/I 현재 위치입니다. 예 - GN/GNP 커서는 생성된 코드가 아닌 런타임에 의해 재현됩니다. 런타임은 현재 위치(및 GNP가 탐색하는 “설정된 상위”)를 기억하고, 성공한 각 GU/GN/GNP에서 이를 진행시키고, IMS와 마찬가지로 작업 단위가 끝날 때 이를 지웁니다. 프로그램은 위치를 관리하지 않고 다음 GN/GNP만 실행합니다.

키 읽기(GU), 순차 찾아보기(GN) 및 get-(hold)-next-within-parent(GNP/GHNP)가 재현되나요?

예, 보류 변형(GHU/GHN/GHNP)이 있는 세 가지 모두 가능합니다.

예 - 모든 요약을 검색하고 각 요약에 대해 세부 정보(클래식 언로드 패턴)를 검색합니다.

      * Get next summary (root) in sequence
       CALL 'CBLTDLI' USING FUNC-GN  PCB-MASK PENDING-AUTH-SUMMARY ROOT-SSA.
      * Get next detail under that summary
       CALL 'CBLTDLI' USING FUNC-GNP PCB-MASK PENDING-AUTH-DETAILS  CHILD-SSA.

생성된 Java(호출은 함수 코드, PCB, I/O 영역, SSA 등 모양을 유지하고 런타임으로 라우팅됨):

// GN: get next summary
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncGn().getFuncGnReference())
    .byReference(ctx.getPautbpcb())            // PCB mask
    .byReference(ctx.getPendingAuthSummary())  // I/O area
    .byReference(ctx.getRootSsa())
    .getArguments(), ctx);

// GNP: get next detail under the established parent
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncGnp().getFuncGnpReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getPendingAuthDetails())
    .byReference(ctx.getChildSsa())
    .getArguments(), ctx);

이렇게 하면 IMS 순회가 정확히 생성됩니다. GN은 키 순서로 루트를 순회합니다. 요약에 GN을 추가하면 GNP는 GE (더 이상 하위 항목 없음)까지 해당 요약의 세부 정보를 하나씩 반환합니다.

범위/비교 조건(GT/GE/LT/LE)이 있는 정규화된 읽기가 지원되나요?

예. 관계형 연산자가 있는 정규화된 SSA는 세그먼트와 동등한 조건이 되므로 범위 및 비교 읽기는 IMS에서와 같이 동작합니다. 지원되는 연산자는 =, >, >=, <, !=, <=및 조건 OR 간 부울입니다.

예 - 타임스탬프 필드가 값보다 큰 첫 번째 세부 정보를 읽습니다.

       01 DTL-SSA.
          05 FILLER PIC X(08) VALUE 'PAUTDTL1'.
          05 FILLER PIC X(01) VALUE '('.
          05 FILLER PIC X(08) VALUE 'PAUT9CTS'.
          05 FILLER PIC X(02) VALUE 'GT'.          *> greater-than
          05 SSA-VAL PIC X(08).
          05 FILLER PIC X(01) VALUE ')'.

       CALL 'CBLTDLI' USING FUNC-GN PCB-MASK PENDING-AUTH-DETAILS DTL-SSA.

생성된 Java - 정규화된 SSA는 연산자와 값을 포함하는 검색 인수가 됩니다(CICS에서 생성된 형식). EXEC DLI GN ... WHERE(field > value)

ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncGn().getFuncGnReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getPendingAuthDetails())
    .byReference(SSABuilder.newInstance()
        .segmentName("PAUTDTL1")
        .addWhereClause("PAUT9CTS", ">", ctx.getSsaVal().getSsaValReference())  // GT condition
        .build())
    .getArguments(), ctx);

런타임은 계층적 순서로 또는 없는 GE 경우 첫 번째 적격 세그먼트를 반환합니다. 다중 수준 정규화된 SSAs(상위 수준의 조건과 하위 수준의 조건) 및 OR 조합은 동일한 방식으로 처리됩니다. 각는 동일한 호출에서 추가 addWhereClause(...) / 세그먼트가 됩니다.

ISRT/DLET/REPL은 어떻게 표현되나요?

동일한 함수 코드, 동일한 SSAs 등 IMS에서와 동일하게 발급되며 런타임은 계층적 insert/delete/replace 수행합니다.

ISRT(삽입). 종속 세그먼트의 경우 이전 호출에는 상위 세그먼트에 설정된 위치가 있어야 합니다. 또한 논리적 하위 항목의 삽입은 DBD에 필요할 때 논리적 상위 및 페어링된 세그먼트를 생성/연결합니다.

      * Establish the parent, then insert the child under it
       CALL 'CBLTDLI' USING FUNC-GU   PCB-MASK PENDING-AUTH-SUMMARY ROOT-SSA.
       CALL 'CBLTDLI' USING FUNC-ISRT PCB-MASK PENDING-AUTH-DETAILS CHILD-SSA.

ISRT용 Java 생성(실제로 현대화된 프로그램에 표시됨):

ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncIsrt().getFuncIsrtReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getPendingAuthDetails())
    .byReference(ctx.getChildSsa())
    .getArguments(), ctx);

Dlet(삭제). 이전 대기 호출(GHU/GHN 또는 EXEC DLILOCKED)이 필요합니다. 종속 항목에 대한 세그먼트 캐스케이드 삭제 및 IMS 삭제 규칙이 적용됩니다(예: 여전히 논리적 하위 항목이 있는 논리적 상위 삭제는 거부됨).

       CALL 'CBLTDLI' USING FUNC-GHU  PCB-MASK PENDING-AUTH-DETAILS CHILD-SSA.  *> hold
       CALL 'CBLTDLI' USING FUNC-DLET PCB-MASK PENDING-AUTH-DETAILS.           *> delete

REPL(교체). 또한 이전 보류가 필요합니다. 변경된 필드만 업데이트되고 페어링된 세그먼트는 함께 업데이트됩니다.

       CALL 'CBLTDLI' USING FUNC-GHU  PCB-MASK PENDING-AUTH-SUMMARY ROOT-SSA.  *> hold
       MOVE NEW-VALUES TO PENDING-AUTH-SUMMARY.
       CALL 'CBLTDLI' USING FUNC-REPL PCB-MASK PENDING-AUTH-SUMMARY.           *> replace

hold-then-delete 페어에 대해 Java를 생성했습니다(Dlet은 SSA를 사용하지 않으며 보류된 세그먼트를 삭제합니다).

// GHU: hold
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncGhu().getFuncGhuReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getPendingAuthDetails())
    .byReference(ctx.getChildSsa())
    .getArguments(), ctx);

// DLET: delete the held segment
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncDlet().getFuncDletReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getPendingAuthDetails())
    .getArguments(), ctx);

Dlet/REPL이 이전 보류 없이 발급된 경우 런타임은 IMSDJ와 마찬가지로 상태를 반환합니다.

트랜잭션 경계(DB-INIT/DB-TERM)는 어떻게 관리되며 배치(BMP)와 온라인(MPP)은 어떻게 다릅니까?

런타임은 커밋 및 롤백을 관리합니다.

예 - 배치 프로그램의 체크포인트:

       EXEC DLI CHKP ID(WK-CHKPT-ID) END-EXEC.

실제 차이점: 배치 프로그램은 자체 커밋/체크포인트 주기를 제어하는 반면 온라인 트랜잭션은 메시지당 한 번 커밋합니다. 두 경우 모두 실패는 현재 작업 단위를 마지막 커밋 지점으로 롤백합니다.

어떤 잠금/격리가 적용되고 비관적 "업데이트 보류"를 획득할 수 있습니까?

예, hold-for-update를 사용할 수 있습니다. 즉, GHU/GHN(보류) 호출이 수행하는 작업이며 Dlet/REPL 전에 필요합니다. 보류 호출을 실행하면 후속 업데이트/삭제가 안전하도록 런타임이 세그먼트를 보류하고, 위치가 이동하거나 작업 단위가 종료되면 보류가 해제됩니다.

동시성 평가에 유의해야 할 중요한 특성: 보류는 JHDB 런타임에 의해 관리되며, 격리는 런타임과 둘러싸는 데이터베이스 트랜잭션에 의해 제공됩니다. 이는 원시 SQL SELECT ... FOR UPDATE 행 잠금이 아닙니다. 기능적으로 프로그램에서 기대하는 DL/I hold-then-update 동작을 제공하지만(세그먼트를 가져올 수 없는 BA 경우 "데이터 사용 불가"를 반환), 경합이 많은 동시성/처리량 프로파일은 IMS/IRLM과 정확히 일치하는 것으로 가정하는 대신 워크로드에 대해 검증되어야 합니다.

예제:

       CALL 'CBLTDLI' USING FUNC-GHU  PCB-MASK PENDING-AUTH-SUMMARY ROOT-SSA.  *> hold for update
      *  ... modify PENDING-AUTH-SUMMARY ...
       CALL 'CBLTDLI' USING FUNC-REPL PCB-MASK PENDING-AUTH-SUMMARY.           *> update the held segment

고속 대량 순차(HSSR)에 상응하는 것이 있으며 어떤 캐싱이 적용되나요?

"HSSR" API라는 별도의 이름은 없지만 순차 읽기 경로는 대량 스캔에 최적화되어 있습니다. GN/GNP로 탐색하면 런타임은 세그먼트당 1회 왕복이 아닌 배치(선독 캐시)로 형제 세그먼트를 미리 가져오므로 전체 데이터베이스 순차 패스가 효율적입니다.

예 - 모든 루트에 대한 직선 GN 루프는 커버 아래의 효율적인 배치로 읽습니다.

       PERFORM UNTIL END-OF-DB
           CALL 'CBLTDLI' USING FUNC-GN PCB-MASK PENDING-AUTH-SUMMARY ROOT-SSA
           EVALUATE PCB-STATUS
               WHEN '  '  PERFORM PROCESS-SUMMARY
               WHEN 'GB'  SET END-OF-DB TO TRUE
           END-EVALUATE
       END-PERFORM.

데이터베이스 크기에 대한 특정 HSSR 처리량 목표를 충족하는지 여부는 성능 문제입니다. 현대화된 프로젝트에서 대표적인 대량 작업을 측정하여 검증하는 것이 좋습니다. 추상화에는 처리량 보장을 인용하지 않습니다.

JHDB는 IMS 보조 인덱스(non-primary-key 액세스 경로)를 지원하나요?

예. DBD에 정의된 보조 인덱스(XDFLD/ 인덱싱됨LCHILD)는 데이터베이스 인덱스와 순서 지정 보기로 현대화되며, 해당 인덱싱을 처리 시퀀스(PROCSEQ)로 인덱싱하는 PCB는 프라이머리 키 순서 대신 인덱싱된 순서로 세그먼트를 탐색할 수 있습니다. 프로그램은 IMS와 정확히 동일하게 SSA의 인덱싱된 필드를 사용합니다.

예 - CardDEMO 권한 부여 데이터베이스는 이미 계정 ID(ACCNTID)에 보조 인덱스를 정의합니다. 인덱스에 대해 예약된 프로그램은 동일한 GU/GN 호출로 ACCNTID 순서대로 요약을 읽을 수 있으며 런타임은 보조 인덱스 내에 별도의 위치를 유지합니다.

따라서 보조 인덱스가 DBD에 있고 DBD에서 참조하는 경우 생성된 코드에서 기본이 아닌 액세스 경로를 사용할 수 있습니다.

Success/Failure/"not found"는 어떤 형식으로 표시되며 비즈니스 로직은 이를 어떻게 평가해야 합니까?

IMS와 정확히 동일: 모든 호출은 표준 2자 DL/I 상태 코드를 (의 경우) 또는 DIB(의 경우CALL 'CBLTDLI')에 반환합니다EXEC DLI. 비즈니스 로직은 각 호출 후 새로운 학습 메커니즘 없이 이를 테스트합니다. 전체 IMS 상태 코드 세트가 재현됩니다. 일반적인 사항은 다음과 같습니다.

예 - 키로 표시된 읽기 후 상태를 평가합니다.

       CALL 'CBLTDLI' USING FUNC-GU PCB-MASK PENDING-AUTH-SUMMARY ROOT-SSA.
       EVALUATE PCB-STATUS
           WHEN '  '  PERFORM SEGMENT-FOUND
           WHEN 'GE'  PERFORM SEGMENT-NOT-FOUND
           WHEN OTHER PERFORM HANDLE-ERROR
       END-EVALUATE.

생성된 Java - 호출 후 프로그램은 동일한 2바이트 상태 필드를 읽고 해당 필드를 브랜치하여(공백 = 성공, "GE" = 찾을 수 없음) COBOL을 정확히 미러링합니다.

ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getFuncGu().getFuncGuReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getPendingAuthSummary())
    .byReference(ctx.getRootSsa())
    .getArguments(), ctx);

if (DataUtils.isBlank(ctx.getPautbpcb().getPautPcbStatusReference())) {
    // success
} else if (DataUtils.compare(ctx.getPautbpcb().getPautPcbStatusReference(), "GE") == 0) {
    // segment not found
} else {
    // handle other status
}

실제 인프라 장애(예: 기본 데이터베이스 오류/타임아웃)만 JHDB별 코드로 표시됩니다. 모든 정상 DL/I 조건은 프로그램이 이미 검사한 표준 IMS 상태 코드를 사용합니다.

CBLTDLI CHKP 및 ROLB는 있는 그대로 지원됩니까(런타임에서 가로채고 실행)?

예 - 둘 다 있는 그대로 지원됩니다. 현대화된 프로그램은 원본을 유지하고 CALL 'CBLTDLI' USING <func> ... 런타임은 함수 코드를 가로채서 실행합니다. 이러한 호출은 다시 작성하지 않으며 "지원되지 않음"으로 내보내거나 자동으로 무시되지 않습니다.

예 - 체크포인트를 가져와 오류 경로에서 롤백하는 배치 프로그램:

       01 CHKP-FUNCT   PIC X(4) VALUE 'CHKP'.
       01 ROLB-FUNCT   PIC X(4) VALUE 'ROLB'.
       01 CHKP-ID      PIC X(8) VALUE 'RMAD0001'.
      *...
      * Commit work so far and take a checkpoint
       CALL 'CBLTDLI' USING CHKP-FUNCT PCB-MASK CHKP-ID.
      *...
      * On an application error, undo everything since the last commit
       CALL 'CBLTDLI' USING ROLB-FUNCT PCB-MASK.

두 호출 모두 GU/GN/ISRT 호출과 마찬가지로 생성된 Java에서 동일한 CBLTDLI 진입점을 통해 실행됩니다. 런타임은 체크포인트 또는 롤백을 수행하고 제어를 반환합니다.

// CALL 'CBLTDLI' USING CHKP-FUNCT PCB-MASK CHKP-ID
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getChkpFunct().getChkpFunctReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getChkpId())
    .getArguments(), ctx);

배치는 동일한 형태로 CALL 'CBLTDLI' USING ROLB-FUNCT PCB-MASK 나타납니다.

// CALL 'CBLTDLI' USING ROLB-FUNCT PCB-MASK
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getRolbFunct().getRolbFunctReference())
    .byReference(ctx.getPautbpcb())
    .getArguments(), ctx);

심볼 체크포인트 및 재시작(XRST) - 체크포인트 ID + 사용자 영역이 저장/복원되고 재시작이 데이터베이스의 위치를 바꾸나요?

예, 세 가지 모두에 해당합니다. 체크포인트 양식과 XRST동등한 재시작이 모두 지원됩니다.

예 - 하나의 작업 영역을 저장한 다음 복원을 다시 시작하는 심볼 체크포인트:

       01 CHKP-FUNCT  PIC X(4) VALUE 'CHKP'.
       01 XRST-FUNCT  PIC X(4) VALUE 'XRST'.
       01 CHKP-ID     PIC X(8) VALUE 'RMAD0001'.
       01 SAVE-LEN    PIC S9(4) COMP VALUE 200.
       01 SAVE-AREA   PIC X(200).
      *...
      * At program start, restore any saved areas + reposition after a restart
       CALL 'CBLTDLI' USING XRST-FUNCT PCB-MASK CHKP-ID SAVE-LEN SAVE-AREA.
      *...
      * Periodically: commit + save the work area with the checkpoint
       CALL 'CBLTDLI' USING CHKP-FUNCT PCB-MASK CHKP-ID SAVE-LEN SAVE-AREA.

생성된 Java - 심볼 CHKP와 XRST는 ID와 (길이, 영역) 피연산자를 동일한 CBLTDLI 호출에 유지하므로 저장/복원된 영역이 변경되지 않고 흐릅니다.

// XRST at start: restore saved areas + reposition after a restart
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getXrstFunct().getXrstFunctReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getChkpId())
    .byReference(ctx.getSaveLen())
    .byReference(ctx.getSaveArea())      // restored on restart
    .getArguments(), ctx);

// Symbolic CHKP: commit + save the work area with the checkpoint
ctrl.callSubProgram("CBLTDLI", CallBuilder.newInstance()
    .byReference(ctx.getChkpFunct().getChkpFunctReference())
    .byReference(ctx.getPautbpcb())
    .byReference(ctx.getChkpId())
    .byReference(ctx.getSaveLen())
    .byReference(ctx.getSaveArea())      // saved with the checkpoint
    .getArguments(), ctx);

지속 체크포인트 페이로드(체크포인트 ID, 데이터베이스 위치 및 저장된 영역)는 문서화된 jhdb.checkpointPersistence 메커니즘이 저장하는 것과 같습니다.

CHKP의 정확한 커밋 범위 및 ROLB의 롤백 범위.

CHKP는 전체 실행 단위 트랜잭션을 커밋하고 ROLB는 JHDB/IMS 부분뿐만 아니라 전체 실행 단위 트랜잭션을 롤백합니다. 실행 단위의 모든 영구 작업(JHDB 계층적 데이터, DB2/SQL 작업 및 Blusam/VSAM 업데이트)은 동일한 데이터베이스 연결에 대해 하나의 런타임 관리형 트랜잭션에서 수행되므로 CHKP 커밋 또는 ROLB 롤백은이 모든 것을 함께 다룹니다.

예제:

      * Insert an IMS segment AND a DB2 row in the same unit of work
       CALL 'CBLTDLI' USING ISRT-FUNCT PCB-MASK SEG-IO CHILD-SSA.
       EXEC SQL INSERT INTO AUTHFRDS (...) VALUES (...) END-EXEC.
      *...
       IF SOME-ERROR
      *   Undo BOTH the IMS insert and the DB2 insert together
          CALL 'CBLTDLI' USING ROLB-FUNCT PCB-MASK
       ELSE
      *   Commit BOTH together and checkpoint
          CALL 'CBLTDLI' USING CHKP-FUNCT PCB-MASK CHKP-ID
       END-IF.

이 single-unit-of-work 동작은 CHKP/ROLB가 IMS DB 호출뿐만 아니라 전체 복구 가능 단위를 구분한다는 메인프레임 기대치와 일치합니다.

ABEND는 동일한 자동 롤백을 트리거합니까?

예. ABEND는 성공적인 end-of-unit-of-work 커밋에 도달하지 않고 실행 단위를 종료하므로 암시적 실행 단위 트랜잭션이 커밋되지 않고 마지막 커밋/체크포인트 이후 수행된 작업이 지속되지 않습니다. ABEND가 런타임 예외로 표시되는 경우 자동 롤백(rollbackOnRTE)도 적용됩니다. 어느 쪽이든 순 효과는 메인프레임 기대치입니다. ABEND 후 커밋되지 않은 변경 사항이 마지막 커밋 지점으로 백업됩니다.

CHKP/ROLB 이후에 반환되는 상태 코드는 무엇이며 비즈니스 로직은 이를 어떻게 평가해야 합니까?

상태는 다른 DL/I 호출과 똑같이 읽히는 표준 장소인 PCB 상태 필드에 반환됩니다.

예 - 체크포인트 이후의 상태를 확인합니다.

       CALL 'CBLTDLI' USING CHKP-FUNCT PCB-MASK CHKP-ID.
       IF PCB-STATUS = SPACES
           CONTINUE
       ELSE
           DISPLAY 'CHKP FAILED, STATUS: ' PCB-STATUS
           PERFORM ABEND-ROUTINE
       END-IF.

생성된 Java - 상태 확인은 COBOL을 미러링하여 다시 PCB 상태 필드를 읽습니다(공백 = 성공, 그렇지 않으면 실패).

// after the CHKP callSubProgram
if (DataUtils.isBlank(ctx.getPautbpcb().getPautPcbStatusReference())) {
    // CHKP success
} else {
    // CHKP failed — log the status and abend
    abend(ctx, ctrl);
}

이 두 통화의 배치와 온라인 비교 - CHKP는 온라인에서 의미가 있으며 제한이 있습니까?

수기 Java 프로그램에 권장되는 패턴입니다.

수기 Java 프로그램에서 CHKP/ROLB에 동일한 CBLTDLI 진입점을 사용합니다. 별도의 하위 수준 트랜잭션 API에 도달하지 마십시오. CBLTDLI 호출을 통해 CHKP/ROLB(및 GU/GN/ISRT/...)를 실행하면 수기 프로그램이 변환된 것과 동일하게 작동합니다. 런타임은 위에서 설명한 것과 동일한 실행 단위 커밋/롤백, 체크포인트 저장/복원, 데이터베이스 위치 처리 및 Blusam/VSAM/SQL 조정을 적용합니다. 또한 수기 미들웨어와 생성된 프로그램이 하나의 일관된 트랜잭션 모델을 공유한다는 의미입니다.

수기 Java 프로그램에서 호출의 개념적 형태(COBOL 호출과 동일한 인수 - 함수 코드, PCB, 심볼 체크포인트의 경우 ID 및 저장 영역):

// checkpoint (commit + establish restart point)
callSubProgram("CBLTDLI", chkpFunc, pcbMask, chkpId);              // basic
callSubProgram("CBLTDLI", chkpFunc, pcbMask, chkpId, len, area);   // symbolic (saves 'area')

// rollback (undo the current unit of work)
callSubProgram("CBLTDLI", rolbFunc, pcbMask);

// restart at program start (restore saved areas + reposition)
callSubProgram("CBLTDLI", xrstFunc, pcbMask, chkpId, len, area);

정상 경로에 대한 암시적 실행 단위 트랜잭션(성공한 작업 단위가 끝날 때 명시적 커밋 필요 없음)을 사용하고 레거시 프로그램이 이를 사용한 경우에만 CHKP/ROLB를 사용합니다. 수기 프로그램에 DL/I 모델 외부에서 커밋/롤백을 추진해야 하는 경우 올바른 런타임 후크를 권장할 수 있도록 해야 할 설계 지점입니다.

변환 프로세스에 대한 세부 정보는 어디에서 찾을 수 있습니까?

메인프레임 리팩터링 설명서는 AWS 변환을 참조하세요.

메인프레임 생성 모듈의 AWS 변환 이름은 무엇입니까?

서비스, 엔터티, 웹 및 도구.

Java/Spring이 메인프레임용 AWS 변환의 대상 기술 중 하나로 선택된 이유는 무엇입니까?

Java/Spring은 광범위한 채택, 대규모 인재 풀, 강력한 엔터프라이즈 기능으로 인해 대상 기술로 선택되었습니다. Java 에코시스템은 최신 애플리케이션 개발을 지원하는 광범위한 라이브러리, 프레임워크 및 도구를 제공합니다. Spring 프레임워크는 엔터프라이즈급 기능과 클라우드 네이티브 기능을 제공하고 업계 모범 사례를 따르므로 현대화된 애플리케이션에 적합합니다.

메인프레임 생성 모듈의 AWS 변환이 포함된 상위 프로젝트의 이름은 무엇입니까?

상위 프로젝트의 이름은 “-pom”으로 접미사로 지정되며 프로젝트라는 변환 속성을 사용하여 변환 센터에서 정의할 수 있습니다.

메인프레임용 AWS 변환은 제공된 경우 레거시 스케줄러 현대화를 어떻게 관리하나요?

레거시 스케줄러 자산은 메인프레임용 AWS 변환을 통해 현대화되지 않습니다. 평가 단계에서 누락된 아티팩트를 식별하는 데 도움이 되도록 고려되고 있습니다.

메인프레임용 AWS 변환을 사용하여 생성된 코드를 디버깅하기 위한 요구 사항은 무엇입니까?

Eclipse, JetBrain 또는 VisualCode와 같이 Java를 지원하는 모든 통합 개발 환경(IDE)입니다.

메인프레임용 AWS 변환을 사용하여 현대화된 애플리케이션을 배포할 수 있는 환경은 무엇입니까?

Windows Server, Linux 서버 및 Docker Linux 컨테이너.

메인프레임 리팩터링된 애플리케이션의 AWS 변환을 모든 인프라에서 실행할 수 있나요?

메인프레임 리팩터링된 애플리케이션의 AWS 변환은 어떤 인프라에서도 실행되도록 설계되지 않았지만 배포 옵션에서 상당한 유연성을 제공합니다. 이러한 애플리케이션은 클라우드 관리형 서비스, 서버리스 컴퓨팅, 온프레미스 인프라를 비롯한 다양한 컴퓨팅 플랫폼에 배포할 수 있습니다.

메인프레임용 AWS 변환은 어떤 MQ 구성을 지원하나요?

SQS, IBM WebSphere MQ.

사용자가 AWS Mainframe Modernization 런타임을 사용하여 Java 비즈니스 애플리케이션 로직을 배포할 수 있는 애플리케이션 서버는 무엇입니까?

Apache Tomcat. 지원되는 버전은 릴리스 정보를 참조하세요.

리팩터링된 애플리케이션은 Amazon Aurora와 AWS 서비스 같은 다른 애플리케이션과 어떻게 통합되나요?

현대화된 애플리케이션은 Amazon Aurora 및 RDS for PostgreSQL과 같은 클라우드 네이티브 데이터베이스 솔루션으로의 변환을 지원 AWS 서비스 하여와 통합됩니다. 메인프레임용 AWS 변환은 현대화된 애플리케이션과 간의 통합을 보장하여 조직이 클라우드 기능을 사용할 AWS 서비스수 있도록 합니다. 이 통합은 AWS 에코시스템 내의 데이터 스토리지 및 애플리케이션 서비스 모두에 적용됩니다. 데이터베이스 스토리지 외에도 메인프레임 런타임용 AWS 변환은 구성 관리를 위한 Amazon ElastiCache for Redis 캐싱, 배포 AWS Secrets Manager 를 위한 AWS 메인프레임 현대화를 AWS 서비스 비롯한 다양한와 통합됩니다. 컨테이너 배포를 위해 Fargate에서 관리하는 Amazon EC2, Amazon EKS, ECS를 지원합니다. 시스템은 인증 AWS Identity and Access Management 에를, 스토리지에 Amazon Simple Storage Service를 사용할 수 있으며 구성 및 서비스 커넥터를 AWS 서비스 통해 다른 와의 통합을 지원합니다.

리팩터링된 애플리케이션은 확장성 요구 사항을 어떻게 충족합니까?

이 솔루션은 애플리케이션을 AWS 탄력적 인프라를 사용할 수 있는 클라우드 네이티브 아키텍처로 변환하여 확장성을 보장합니다. 수평 및 수직 조정을 지원하는 최신 설계 패턴과 모범 사례를 구현합니다. 서비스 지향 접근 방식을 사용하면 구성 요소를 독립적으로 조정할 수 있습니다. 현대화된 애플리케이션은 클라우드 서비스의 고유한 확장성 기능을 활용할 수 있습니다.

소스 코드 리팩터링이 완료되면 어떻게 되나요?

소스 코드 리팩터링 후 두 가지 주요 단계가 수행됩니다. 먼저 리팩터링된 애플리케이션이 빌드됩니다. 둘째, 애플리케이션이 배포됩니다. 배포는 고객이 자체 인프라를 관리하고 Amazon EC2, ECS on EC2 또는 Fargate, EKS on EC2를 비롯한 다양한 플랫폼에 배포하는 AWS 계정 (AWS 메인프레임 현대화 AWS Transform for mainframe 런타임)에서 수행됩니다EC2.

사용자 지정 Amazon Linux AMI에서 메인프레임용 AWS 변환으로 현대화된 애플리케이션을 배포하고 실행하려면 어떻게 해야 하나요?

이는 Amazon EC2의 메인프레임 런타임용 AWS 변환을 사용하여 애플리케이션을 배포하여 달성할 수 있습니다. 이 프로세스에는 메인프레임 런타임 라이브러리용 AWS 변환에 종속된 Java/Spring 애플리케이션을 생성하고 사용자 지정 Amazon Linux AMI에 배포하는 작업이 포함됩니다. 이 접근 방식에 대한 자세한 지침은 Amazon EC2에서 AWS Transform for mainframe 런타임 설정을 참조하세요.

사용 가능한 Amazon Machine Image(AMI)가 있나요? 사용 가능한 도커 이미지가 있나요?

고객이 메인프레임 애플리케이션용 AWS 변환을 Docker 컨테이너로 패키징하고 실행할 수 있나요?

예, 컨테이너에서 메인프레임 런타임에 대한 AWS 변환 설정을 참조하세요.

작업 예약은 배치에서 어떻게 작동하나요?

Control-M/Stone 브랜치 또는 다른 분산 스케줄러와 통합됩니다.

애플리케이션은 SQL 주입 공격으로부터 어떻게 보호하나요?

애플리케이션은 전체적으로 SQL 모범 사례를 구현합니다. 모든 데이터베이스 쿼리는 준비된 문을 사용하므로 SQL 코드를 사용자가 제공한 데이터와 분리하여 SQL 주입 공격을 효과적으로 방지할 수 있습니다. 이렇게 하면 사용자 입력이 항상 실행 코드 대신 데이터로 처리됩니다.

OS 명령 삽입 취약성을 방지하기 위해 어떤 조치가 마련되어 있습니까?

AWS 보안 팀은 메인프레임 런타임을 위한 AWS 변환에 대한 정기적인 보안 검토를 수행합니다. 팀이 OS 명령 주입을 잠재적으로 허용할 수 있는 코드와 같은 이상을 감지하면 AWS 즉시 해결합니다. 이러한 지속적인 모니터링을 통해 런타임이 명령 주입 위협으로부터 안전하게 유지됩니다.

애플리케이션이 디렉터리 순회 공격에 취약합니까?

아니요.이 취약성은 프런트 엔드 Angular 애플리케이션에 적용되지 않습니다. 백엔드의 경우 애플리케이션은 "경로" 또는 "디렉터리" 정보를 포함하지 않는 인터페이스 계약이 제한된 엔드포인트를 하나만 사용합니다. 이 설계는 디렉터리 순회 공격의 위험을 제거합니다.

애플리케이션은 XSS 공격으로부터 어떻게 보호하나요?

애플리케이션은 공식 Angular 보안 설명서에 설명된 Angular 보안 모범 사례를 따릅니다. 애플리케이션은 레거시 메인프레임 애플리케이션에 해당하므로 UI 측면에서 본질적으로 제한됩니다. 애플리케이션은 백엔드에서 생성된 URLs, 동적 스크립트 또는 HTML을 처리하지 않습니다. 이 제한된 공격 표면은 XSS 위험을 크게 줄입니다.

CSRF 공격에 대해 구현되는 보호 기능은 무엇입니까?

애플리케이션은 Spring의 네이티브 CSRF 지원을 활용하며, 이를 통해 즉시 교차 사이트 요청 위조 공격에 대한 강력한 보호를 제공합니다.

사용자 입력으로 인해 HTTP 헤더 삽입이 발생할 수 있습니까?

아니요. 사용자 입력의 길이는 레거시 메인프레임 애플리케이션 형식과 일치하도록 엄격하게 제한됩니다. 백엔드는 요청을 수신하면 사전 정의된 형식에 따라 입력의 형식을 즉시 지정하여 주입된 콘텐츠를 자릅니다. 또한 애플리케이션은 애플리케이션에서 사용하는 단일 엔드포인트의 사용자 입력을 기반으로 HTTP 헤더를 구성하지 않으므로 HTTP 헤더 삽입이 불가능합니다.

애플리케이션은 클릭재킹 공격으로부터 어떻게 보호되나요?

애플리케이션은 마우스 클릭 대신 키 입력을 사용하여 대부분의 작업을 수행하므로 클릭재킹 공격에 본질적으로 강합니다. 이 설계 선택은 이러한 유형의 취약성에 대한 공격 표면을 크게 줄입니다.

버퍼 오버플로 공격이 애플리케이션에서 발생할 수 있나요?

아니요. 사용자 입력의 길이는 레거시 메인프레임 애플리케이션 형식에 맞게 엄격하게 제한됩니다. 백엔드가 요청을 수신하면 해당 형식에 따라 입력의 형식을 즉시 지정하여 버퍼 오버플로 조건이 발생하지 않도록 합니다.

액세스 제어 및 권한 부여는 어떻게 관리되나요?

액세스 제어는 사용자에게 고유한 백엔드 엔드포인트에 액세스할 수 있는 권한이 있는지 여부를 전역적으로 결정합니다. 인증되면 애플리케이션 코드와 데이터가 권한 부여 제어를 처리합니다. 이렇게 하면 문제를 적절하게 분리하고 액세스를 안전하게 관리할 수 있습니다.

세션 하이재킹을 방지하는 조치는 무엇입니까?

세션 관리 및 XSS 방지를 위해 Spring 및 Angular 네이티브 기능을 프레임워크 모범 사례와 함께 함께 사용하면 세션 하이재킹이 방지됩니다. 애플리케이션은 다음을 통해 보호를 더욱 강화할 수 있습니다.

이러한 계층화된 보안 조치는 세션 하이재킹 시도에 대한 포괄적인 보호를 제공합니다.