AWS Perguntas frequentes sobre o Transform for mainframe

Qual é o objetivo principal do AWS Transform for mainframe Refactoring Capability?

A capacidade de refatoração refatora o código monolítico legado em java usando aplicativos distribuídos contemporâneos usando linguagens e estruturas modernas, seguindo um padrão de refatoração automatizado. Esse padrão envolve analisar automaticamente o código legado, entender sua funcionalidade e convertê-lo em código moderno equivalente, preservando a lógica de negócios. O processo inclui modernizar não apenas o código, mas também toda a pilha de aplicativos, dependências e infraestrutura usando ferramentas e processos automatizados. A solução visa acelerar a modernização e, ao mesmo tempo, manter a equivalência funcional e o desempenho. Isso inclui transformar o código do aplicativo e os bancos de dados e armazenamentos de dados associados, ao mesmo tempo em que implementa as melhores práticas e os padrões de design da nuvem.

Quais aplicativos de mainframe são compatíveis com o AWS Transform for mainframe?

AWS Atualmente, o Transform for mainframe suporta a modernização de aplicativos de z/OS mainframe IBM escritos em COBOL, PL/I JCL (Job Control Language) e conta com o gerenciador de transações CICS (Customer Information Control System), telas BMS (Basic Mapping Support), telas IMS MFS, bancos de dados DB2, bancos de dados IMS, arquivos simples, arquivos de dados GDG (Generation data groups) e VSAM (Virtual Storage Access Method).

Quais linguagens de mainframe podem ser AWS transformadas para modernizar o mainframe?

AWS O Transform for mainframe transforma COBOL e PL/I código em Java, JCLs em Groovy, telas (BMS ou MFS) em HTML (com Sass) e JavaScript (aplicativos angulares — o React não é suportado no momento), permitindo a modernização de aplicativos de mainframe antigos para arquiteturas nativas em nuvem. Essas tecnologias são escolhidas por sua ampla adoção, ecossistema robusto e recursos nativos da nuvem. O Angular fornece uma camada de interface de usuário moderna e responsiva que substitui as interfaces antigas de tela verde. Ele permite a criação de aplicativos web dinâmicos e fáceis de usar que podem ser acessados em diferentes dispositivos e plataformas. Sua arquitetura baseada em componentes oferece suporte ao desenvolvimento de front-end sustentável e escalável. A transformação resulta em aplicativos distribuídos que seguem os padrões arquitetônicos modernos e as melhores práticas.

Como o AWS Transform for mainframe equilibra as restrições antigas com os benefícios da nuvem?

AWS O Transform for mainframe alcança o equilíbrio preservando a lógica e a funcionalidade essenciais dos negócios e introduzindo recursos nativos da nuvem. Ele garante que os aplicativos modernizados mantenham a lógica comercial legada necessária enquanto aproveitam a escalabilidade, a agilidade e as práticas operacionais modernas da nuvem. Essa abordagem ajuda as organizações a manter a continuidade dos negócios e, ao mesmo tempo, obter os benefícios da infraestrutura em nuvem.

Qual o papel da arquitetura orientada a serviços no aplicativo modernizado?

Service-oriented a arquitetura desempenha um papel fundamental na divisão de aplicativos monolíticos em componentes modulares mais gerenciáveis. AWS O Transform for mainframe cria aplicativos orientados a serviços e a objetos que facilitam a manutenção e a escalabilidade. Essa abordagem arquitetônica permite que as organizações obtenham maior eficiência nos negócios e se preparem para a possível adoção futura de microsserviços.

Quais aspectos da pilha de aplicativos estão incluídos no processo de refatoração?

O processo de refatoração inclui a pilha de software completa: código do aplicativo, dependências, bancos de dados e infraestrutura (por exemplo, opções para armazenamento em cache, suporte a mensagens etc.). Ele abrange a transformação de linguagens de programação antigas, sistemas de banco de dados, arquivos de dados e componentes de infraestrutura associados. Essa abordagem abrangente garante que todos os aspectos do aplicativo sejam modernizados de forma coesa, resultando em uma pilha de aplicativos moderna totalmente transformada.

O processo de modernização do AWS Transform for mainframe elimina a necessidade de qualquer teste ou verificação de garantia de qualidade no aplicativo Java modernizado?

Não, o processo de modernização do AWS Transform for mainframe não elimina a necessidade de testes ou verificações de garantia de qualidade no aplicativo Java modernizado.

O que significa AWS Transform for mainframe JAC?

JAC significa JICS Administration Console

Como posso acessar o AWS Transform para ferramentas de mainframe?

AWS As ferramentas do Transform for mainframe podem ser acessadas por meio do console da AWS por meio do AWS Mainframe Modernization (M2) Refactor, com acesso a recursos com base no seu nível de credenciamento. Comece com o Centro de Transformação para avaliar a refatoração automática de Java do seu código-fonte. Para obter orientação detalhada, consulte a documentação da AWS Transform for mainframerefatoração. Após a modernização, você pode implantar aplicativos usando o tempo de execução. Para obter mais informações, consulte a documentação de modernização do AWS mainframe.

Como dimensionar (carga de trabalho e cronograma) um projeto?

Consulte as estimativas de refatoração do AWS Transform for mainframe para obter mais informações sobre isso ou trabalhar com seu gerente de contas.

Há requisitos específicos para manter o Java AWS Transform para soluções migradas de mainframe?

Não, não há requisitos específicos para manter o Java AWS Transform para soluções migradas de mainframe.

Quais são as especificações técnicas e a compatibilidade do AWS Transform para código gerado por mainframe?

AWS O código gerado pelo Transform for mainframe foi projetado com características técnicas específicas e ampla compatibilidade. Embora não ofereça suporte ao JPA, ele usa a execução direta de SQL com consultas externalizadas. O código depende de bibliotecas específicas de tempo de execução para equivalência funcional, geração de serviços web e implementações de MQ. O código gerado pode ser importado em qualquer IDE Java para desenvolvimento, teste, construção e implantação, embora as bibliotecas necessárias devam ser importadas adequadamente. Embora o Maven seja integrado por padrão ao serviço de modernização de AWS mainframe para processos de construção, ferramentas alternativas como o Gradle podem ser usadas modificando o formato da embalagem após a transformação. A plataforma oferece flexibilidade em termos de ferramentas de desenvolvimento e controle de origem, com treinamento disponível para equipes de desenvolvimento que gerenciam o código. Para obter mais informações, consulte AWS Transform for mainframe Runtime high level architecture.

Onde posso encontrar informações sobre o AWS Transform for mainframe Runtime?

Consulte o tempo de Transform for mainframeexecução da documentação Set up AWS Runtime que detalha a integração do processo de configuração, a recuperação de artefatos, a implantação etc.

As dependências AWS JAR do Transform for mainframe são carregadas no repositório Maven do cliente para desenvolvimento local?

As bibliotecas podem ser importadas para o EC2 usando uma AMI que pode ser usada para configurar o ambiente de desenvolvimento, teste e produção. O treinamento e a capacitação serão dados à equipe para o código maintain/enhance do aplicativo gerado. Para obter mais informações, consulte AWS Transform for mainframe Runtime high level architecture.

A que o termo “Gapwalk” se refere nos jars distribuídos do AWS Transform for mainframe Runtime?

Para obter informações sobre o Gapwalk, consulte AWS Transform for mainframe Runtime artefacts.

Como solicito acesso ao AWS Transform for mainframe Runtime?

O Runtime pode ser acessado por meio da AWS Transform for mainframecaixa de ferramentas ativada. AWS Transform for mainframe refactor

Quais são os tempos de execução suportados pelo AWS Transform para aplicativos refatorados de mainframe?

AWS Transform for mainframeoferece um único Runtime para atender aos diferentes estágios de sua jornada de modernização e às necessidades operacionais, consulte AWSTransform for mainframe Runtime.

Quando o AWS Transform for mainframe Runtime é usado?

Um AWS Transform for mainframe Runtime é necessário para dar suporte à execução do AWS Transform para aplicativos refatorados de mainframe. É necessário um tempo de execução durante o AWS Transform para projetos de refatoração baseados em mainframe para testar os aplicativos refatorados. Depois que o projeto de refatoração termina, também é necessário um tempo de execução para manter, testar e executar o AWS Transform para aplicativos refatorados de mainframe em produção.

Como AWS distribui novas versões do AWS Transform for mainframe Runtime?

As versões do AWS Transform for mainframe Runtime podem ser acessadas por meio da AWS Transform for mainframecaixa de ferramentas. Veja as notas AWSTransform for mainframe de lançamento.

Com que frequência novas versões principais e secundárias do AWS Transform for mainframe Runtime são lançadas?

Para obter mais informações, consulte Ciclo de vida dos componentes AWS da modernização do mainframe.

Como AWS fornece suporte para o AWS Transform for mainframe Runtime?

Support é fornecido AWS Support para cargas de trabalho em execução AWS, nas quais os problemas são resolvidos por meio da geração de um ticket, e o SLA padrão se aplica. Para obter mais informações, consulte Ciclo de vida dos componentes AWS da modernização do mainframe.

O que a AWS transformação da modernização do AWS mainframe para o tempo de execução do mainframe envolve?

O AWS Transform for mainframe Runtime inclui bibliotecas de caixas de ferramentas para acelerar a modernização, facilitar as integrações na nuvem e melhorar a qualidade e a capacidade de manutenção do código. Ele também permite uma maior automação de modernização, facilitando as transições entre arquiteturas legadas e arquiteturas de nuvem. O tempo de execução fornece suporte para lidar com verbos legados e representações de memória de estruturas de dados usando expressões idiomáticas java. Ele permite criar aplicativos modernizados com base em técnicas de programação orientada a objetos e capazes de reproduzir fluxos de controle legados. Ele moderniza conjuntos de dados VSAM legados ou suporte a bancos de dados hierárquicos IMS usando um banco de dados relacional, como o Amazon Aurora. Ele fornece substitutos de java para utilitários de sistema antigos (IDCAMS, IEBGENER, DFSORT etc.) e sistemas antigos de gerenciamento de transações (CICS, IMS). Ele facilita as integrações na nuvem com armazenamento em cache na Amazon ElastiCache e suporte para soluções de AWS mensagens (SQS, Kinesis).

O AWS Transform for mainframe Runtime oferece suporte a arquiteturas de computador não x86?

Atualmente, o AWS Transform for mainframe Runtime suporta somente arquiteturas de computador e computação baseadas em x86. AWS O Transform for mainframe Runtime não oferece suporte ARM-based e Graviton-based computação.

Como os clientes podem se manter informados sobre as versões do AWS Transform for mainframe Runtime, incluindo notificações de novos lançamentos e acesso ao histórico de versões e às notas de lançamento?

Novas versões do AWS Transform for mainframe Runtime são enviadas para nossa página oficial de lançamento. Recomendamos verificar esta página regularmente, de preferência a cada 3 meses, para ver as versões e atualizações mais recentes. Com relação ao acesso ao histórico de versões e às notas de lançamento, a disponibilidade depende da data de fim da vida útil (EOL) de cada versão principal. Para obter informações detalhadas sobre datas de EOL, planejamento de atualização de versão e acesso a informações históricas, consulte AWS Transform for mainframe lifecycle.

Quais são os principais componentes da arquitetura de alto nível do AWS Transform for mainframe Runtime?

A arquitetura AWS Transform for mainframe Runtime compreende dois tipos principais de componentes. Primeiro, estão as bibliotecas Java (arquivos jar) armazenadas em uma pasta compartilhada (acessível ao carregador de classes do servidor de aplicativos) que fornecem suporte a construções e declarações legadas. Em segundo lugar, estão os aplicativos web (arquivos war) contendo Spring-based aplicativos que fornecem estruturas e serviços para programas modernizados. O tempo de execução também inclui: um Registro de Programas que coleta todos os programas para invocação e chamadas entre programas e um Registro de Scripts que coleta todos os scripts de tarefas modernizados. Esses componentes trabalham juntos para fornecer um ponto de REST-based entrada e uma estrutura de execução unificados para aplicativos modernizados. O Runtime e o aplicativo modernizado são implantados juntos em um servidor de aplicativos (por exemplo, Tomcat).

Como configurar a pasta compartilhada contendo artefatos do AWS Transform for mainframe Runtime?

Os artefatos (jars) do AWS Transform for mainframe Runtime devem ser reunidos em uma pasta compartilhada, acessível ao carregador de classes do servidor de aplicativos. Para um servidor tomcat, a configuração é feita modificando o arquivo de configuração normal chamado catalina.properties. Por exemplo, se você criou a pasta compartilhada como uma pasta chamada “compartilhada”, na pasta tomcat, você precisará modificar a entrada common.loader em catalina.properties para tornar a pasta compartilhada acessível ao carregador de classe tomcat, da seguinte forma:

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

Como o AWS Transform for mainframe Runtime lida com a apatridia e o gerenciamento de sessões?

AWS O Transform for mainframe Runtime implementa a apatridia e o gerenciamento de sessões por meio de vários mecanismos. Para sessões HTTP, ele usa identificação baseada em cookies com armazenamento em cache externo para o contexto do usuário. As sessões podem ser armazenadas em vários datastores, incluindo Amazon ElastiCache, cluster Redis ou mapas na memória. O design de apatridia garante que a maioria dos estados não transitórios sejam armazenados externamente em uma “fonte única de verdade” comum, permitindo alta disponibilidade e escalabilidade horizontal. Essa abordagem, combinada com balanceamento de carga e sessões compartilhadas, permite a distribuição do diálogo voltado para o usuário em vários nós.

Qual o papel dos aplicativos web no ambiente AWS Transform for mainframe Runtime?

Os aplicativos Web no AWS Transform for mainframe Runtime têm várias funções principais. Eles fornecem estruturas de execução que reproduzem ambientes legados e monitores de transações (como lotes JCL, CICS, IMS). Eles oferecem pontos de REST-based entrada gapwalk-application.war para acionar e controlar transações, programas e lotes. Além disso, eles fornecem emulação de OS-provided programas e programas de “driver” especializados dos quais os aplicativos antigos dependem para acessar serviços como o IMS DB ou diálogos do usuário por meio do MFS.

Como os programas são registrados e gerenciados no AWS Transform for mainframe Runtime?

Os programas no AWS Transform for mainframe Runtime são registrados por meio de um ProgramRegistry sistema que é preenchido durante a inicialização do servidor. Cada programa implementa a interface do programa e é marcado como um componente Spring. Os programas são registrados usando seus identificadores, com várias entradas possíveis se um programa tiver vários identificadores. O processo de registro é automático e registrado nos registros do Tomcat. ProgramRegistryIsso permite que outros programas e scripts localizem e chamem programas registrados, mantendo a modularidade e a interconectividade do sistema modernizado.

Como a configuração é gerenciada no AWS Transform para aplicativos Runtime de mainframe?

A configuração no AWS Transform for mainframe Runtime é gerenciada por meio de arquivos YAML usando os recursos da estrutura Spring Boot. Dois arquivos de configuração principais são usados: application-main.yml para configuração da estrutura e para opções específicas do cliente. application-profile.yml O sistema segue a lógica de precedência do Spring, permitindo substituições de configuração por vários meios. Configuração adicional pode ser fornecida por meio do JNDI para bancos de dados e parâmetros de linha de comando, oferecendo flexibilidade no gerenciamento de configurações. A configuração dos registradores é feita usando arquivos de configuração xml logback.

Que papel os gerenciadores de segredos desempenham na configuração do AWS Transform for mainframe Runtime?

Os gerenciadores de segredos no AWS Transform for mainframe Runtime protegem dados de configuração confidenciais, como credenciais de banco de dados e senhas de cache do Redis. Eles permitem o armazenamento de dados críticos em AWS segredos e os referenciam nos arquivos de configuração YAML. O sistema suporta diferentes tipos de segredos, incluindo segredos de banco de dados que preenchem automaticamente todos os campos relevantes e segredos de senha única para recursos protegidos por senha. Essa abordagem aprimora a segurança ao manter os dados confidenciais separados da configuração do aplicativo.

Como os desenvolvedores podem escrever seus próprios programas compatíveis com o AWS Transform for mainframe Runtime?

Os desenvolvedores podem criar o AWS Transform para Runtime-compatible programas de mainframe implementando a interface do programa e seguindo padrões específicos. O programa deve ser declarado como um componente Spring, implementar os métodos necessários e estar devidamente registrado no ProgramRegistry. Os desenvolvedores precisam criar classes complementares de contexto e configuração, lidar com identificadores de programas e garantir a integração adequada com a estrutura Spring. A implementação deve seguir as convenções do AWS Transform for mainframe Runtime para estrutura e execução do programa.

Como o AWS Transform for mainframe Runtime lida com erros de execução do programa?

AWS O Transform for mainframe Runtime lida com erros de execução do programa por meio de vários mecanismos. Para trabalhos em lotes, ele captura o status da execução, os códigos de saída e as informações detalhadas de erro nos detalhes da execução do trabalho. O tratamento de erros inclui códigos de saída específicos (-1 para erros técnicos, -2 para falhas no programa de serviço) e registro detalhado nos registros do Tomcat. O sistema pode ser configurado para reverter transações em exceções de tempo de execução e fornece opções para notificação e recuperação de erros. Os detalhes do erro podem ser acessados por meio de endpoints REST para monitoramento e solução de problemas.

Quais recursos de monitoramento do AWS Transform for mainframe Runtime estão disponíveis para trabalhos em lotes?

AWS O Transform for mainframe Runtime fornece recursos de monitoramento para trabalhos em lotes por meio de vários endpoints. Ele rastreia o status da execução do trabalho, start/end os horários, o modo de execução e os resultados detalhados. O sistema oferece endpoints para listar scripts acionados, recuperar detalhes da execução do trabalho e monitorar os trabalhos em execução no momento. Os endpoints do Metrics fornecem estatísticas da JVM, contagens de sessões e métricas detalhadas de execução em lote. A plataforma também suporta paginação e filtragem baseada em tempo dos dados de monitoramento.

Como os status de execução de tarefas do AWS Transform for mainframe Runtime são rastreados e gerenciados?

Os status de execução do trabalho são monitorados por meio de um sistema de status abrangente que inclui estados como CONCLUÍDO, TRIGGERED, RUNNING, KILLED e FAILED. Cada execução de trabalho recebe um identificador exclusivo para rastrear e manter informações detalhadas de execução, incluindo hora de início, hora de término, informações do chamador e resultados da execução. O sistema fornece endpoints REST para consultar o status do trabalho, gerenciar trabalhos em execução e recuperar o histórico de execução. As informações de status persistem na memória do servidor e podem ser removidas com base na idade do gerenciamento de recursos.

Como o AWS Transform for mainframe Runtime lida com as interações externas do sistema?

O tempo de execução lida com interações externas do sistema por meio de vários mecanismos, incluindo endpoints REST para integração de serviços, suporte para filas de mensagens (SQS, RabbitMQ, IBM MQ) e opções de conectividade de banco de dados. Ele emula as interações do sistema legado por meio de componentes especializados, oferece suporte SSL/TLS para comunicações seguras e inclui recursos para lidar com sistemas de arquivos externos. O sistema também oferece suporte à integração com provedores de autenticação externos e pode ser configurado para interagir com vários serviços de terceiros.

Como a autenticação é tratada no AWS Transform for mainframe Runtime?

AWS O Transform for mainframe Runtime oferece suporte a vários métodos de autenticação, com o OAuth2 sendo o mecanismo principal. Ele pode se integrar com provedores de identidade como Amazon Cognito ou Keycloak. A configuração de autenticação é gerenciada por meio do arquivo de configuração principal chamado application-main.yml, no qual configurações de segurança, provedores de identidade e métodos de autenticação podem ser definidos. O sistema oferece suporte a recursos como proteção XSS, CORS, CSRF e pode ser configurado tanto para segurança global quanto para segurança específica de terminais. Para desenvolvimento, um sistema de autenticação local com credenciais de superadministrador padrão também está disponível.

Como o AWS Transform for mainframe Runtime garante alta disponibilidade?

AWS O Transform for mainframe Runtime garante alta disponibilidade por meio de vários mecanismos. Ele implementa a apatridia armazenando estados não transitórios em armazenamento compartilhado externo, permitindo que várias instâncias do aplicativo trabalhem juntas. O sistema suporta balanceamento de carga e sessões compartilhadas, permitindo que as solicitações sejam distribuídas em vários nós. Para armazenamento de dados, ele pode utilizar bancos de dados e sistemas de cache altamente disponíveis. A arquitetura suporta failover automático e pode ser implantada em várias zonas de disponibilidade para aumentar a confiabilidade.

Qual componente é usado para reproduzir transações distribuídas do CICS com o AWS Transform para aplicativos de mainframe?

O AWS Transform for mainframe Runtime fornece um endpoint dedicado para permitir que transações JICS existentes sejam invocadas como parte de uma transação global (suporte XA). O suporte subjacente de confirmação de duas fases depende do componente de software Atomikos.

Qual é o nome AWS Transform for mainframe das classes usadas para definir o comportamento específico do programa?

Cada programa está vinculado a uma classe de configuração dedicada que permite especificar os comportamentos específicos do programa. Para obter mais informações sobre convenções de nomenclatura e localização, consulte AWS Transformar a estrutura de mainframe de um aplicativo modernizado

Qual codificação tem a seguinte ordem de sequência de caracteres: espaço, caracteres minúsculos, caracteres maiúsculos, numerais?

Conjuntos de caracteres pertencentes à família de variantes EBCDIC (como CP1047, CP297, etc).

Quais são as dimensões de preço do AWS Transform for mainframe Runtime?

AWS Mainframe Modernization-core-hours (consulte os preços da modernização do AWS mainframe).

Qual é o mecanismo usado para passar dados brutos por meio de HTTP para os endpoints do programa?

Cadeias codificadas em Base64.

Como um usuário inicia a execução de um trabalho em lotes?

Usando uma chamada HTTP para um dos endpoints de lote dedicados (consulte a página de documentação dos endpoints de lote).

Qual endpoint do AWS Transform for mainframe Runtime é o principal ponto de entrada do aplicativo principal de front-end da web?

/transaction

O que significa AWS Transform for mainframe JICS?

O AWS Transform for mainframe JICS é o componente de tempo de execução usado para dar suporte à modernização dos recursos do CICS. As definições dos recursos são armazenadas em um armazenamento de dados dedicado. Para administrá-los, use a API REST ou o console do aplicativo JICS. Para obter informações, consulte Gerenciar o console do aplicativo JICS em AWS Transform for mainframe.

Quais mecanismos de armazenamento em cache do AWS Transform for mainframe Runtime estão disponíveis?

AWS O Transform for mainframe Runtime oferece suporte a vários mecanismos de cache, incluindo Redis e. EhCache O Redis é recomendado para ambientes de produção, fornecendo cache persistente compartilhado em vários nós. EhCache está disponível para implantações autônomas com cache local volátil incorporado. O sistema suporta o armazenamento em cache de vários componentes, incluindo Blusam dados, informações da sessão, recursos do JICS e filas de armazenamento temporário. A configuração do cache pode ser personalizada para diferentes casos de uso e requisitos de desempenho.

Como estimamos o preço de uma AWS transformação de modernização de AWS mainframe para implantação do mainframe Runtime?

AWS fornece estimativas aos clientes com base em seus requisitos e na arquitetura de destino.

Qual é o preço do AWS Mainframe Modernization AWS Transform for mainframe Runtime?

AWS A modernização do mainframe oferece dois modelos de preços para o AWS Transform for mainframe: uma opção de tempo de execução gerenciado que inclui tempo de execução, recursos computacionais, armazenamento interno e automação, e uma opção de tempo de execução que cobre somente o Non-managed tempo de execução da AWS Transform for mainframe em si. Para AWS implantações, ambos usam uma estrutura de preços pré-paga. Para obter as informações de preços mais atualizadas e detalhadas, é recomendável consultar a página oficial de preços de modernização de mainframe da AWS.

E se precisarmos implantar um aplicativo refatorado AWS Transform for mainframe em uma infraestrutura não listada no tempo de execução compatível?

Se você precisar implantar um aplicativo refatorado AWS Transform for mainframe em uma infraestrutura não listada no tempo de execução compatível, várias opções estarão disponíveis. Primeiro, verifique se sua infraestrutura é compatível com as opções de implantação existentes, como o Amazon EKS Anywhere ou outras plataformas de orquestração de contêineres. Nesse caso, talvez você possa usar o AWS Transform for mainframe Runtime. Para infraestruturas não compatíveis, recomendamos consultar um especialista em AWS mainframe para explorar soluções personalizadas ou possíveis adaptações. Observe que AWS não fornece suporte para cargas de trabalho implantadas ou executadas sem infraestrutura.AWS Você também pode enviar uma Solicitação de Funcionalidade do Produto (PFR) para suporte de infraestrutura expandida. Entre em contato com seu AWS representante para discutir suas necessidades específicas e a melhor abordagem para seu ambiente.

Como o AWS Transform for mainframe Runtime é licenciado? É de código aberto?

AWS O Transform for mainframe Runtime não é de código aberto. É AWS IP distribuído como um serviço nativo da nuvem. Há duas opções de implantação:

Como as mudanças e atualizações do AWS Transform for mainframe frameworks e bibliotecas são gerenciadas?

AWS As estruturas e bibliotecas do Transform for mainframe são atualizadas por meio de processos regulares de geração e implantação de código. Essas atualizações são gerenciadas como parte do ciclo de vida da modernização do AWS mainframe, que inclui atualizações de versão e suporte da equipe da AWS Transform for mainframe ou de parceiros certificados. Para obter informações detalhadas sobre controle de versão, processos de upgrade e cronogramas de suporte, consulte a documentação do ciclo de vida da modernização do AWS mainframe.

Quais são as versões suportadas das ferramentas (Tomcat, Postgres, MQ etc.) e dependências (Spring, Angular etc.) que o Transform for mainframe Runtime usa? AWS

Veja os detalhes nas notas de lançamento.

O que significa 'Autônomo' no contexto do BAC e do JAC?

Autônomo se refere a um modo especial de empacotamento e implantação para BAC (Console Blusam Administrativo) e JAC (Console Administrativo JICS) que permite que esses aplicativos web sejam executados de forma independente em seu próprio servidor Tomcat, separado do seu aplicativo modernizado. As versões autônomas BAC e JAC estão disponíveis em. aws-bluage-webapps-x.y.z.zip As versões não autônomas do BAC e do JAC estão disponíveis na pasta abaixo. gapwalk-x.y.z.zip webapps-consoles Consulte AWS Transform para obter artefatos do mainframe Runtime.

Quais opções de banco de dados estão disponíveis para os aplicativos modernizados em relação à modernização do banco de dados legado?

Os aplicativos modernizados podem usar várias opções modernas de banco de dados, incluindo: PostgreSQL, Amazon Aurora, RDS for PostgreSQL, banco de dados Oracle e IBM Db2. MS-SQL Essas opções oferecem flexibilidade na escolha do sistema de banco de dados mais adequado com base em requisitos específicos, ao mesmo tempo em que aproveitam os benefícios dos sistemas modernos de gerenciamento de banco de dados e dos recursos nativos da nuvem.

Qual é a cobertura de transformação do IBM Db2 z/OS para Postgres DDL?

Transformação completa (incluindo restrições de banco de dados).

O AWS Transform for mainframe oferece suporte à geração de dados em grupo (GDG)?

Sim, o uso do GDG em lotes é suportado, com o apoio de gerações relativas e absolutas e estratégias de limpeza automática.

O AWS Transform for mainframe oferece suporte a conjuntos de dados concatenados?

Sim, há suporte para o uso de conjuntos de dados concatenados em lotes. Com a concatenação em ação, vários conjuntos de dados podem ser lidos como um único conjunto de dados. Observe que os conjuntos de Blusam dados não podem fazer parte de uma concatenação.

Qual é o processo aplicado às consultas SQL?

Ajustado durante a transformação do código, dependendo do banco de dados de destino.

Quais opções se aplicam se houver vários bancos de dados para um aplicativo?

Configure o banco de dados de destino para cada consulta e defina todos os bancos de dados no aplicativo e no Apache Tomcat.

Pode Blusam ser desativado?

Sim, no arquivo de configuração principal, e nenhum banco de dados é necessário (para obter mais informações, consulte a página de documentação de Blusam configuração).

Qual API AWS Transform for mainframe é usada para substituir bancos de dados como o IMS DB?

A API JHDB (Java Hierarchical DataBase). Para obter mais informações, consulte DB/DL/I Emulação IMS (JHDB).

Qual produto AWS Transform for mainframe pode ser usado para migrar dados e bancos de dados legados para um sistema moderno de gerenciamento de banco de dados relacional (RDBMS)?

AWS Transforme para a ferramenta de modernização do banco de dados de mainframe (Data Migrator).

O que é o AWS Transform for mainframe Data Simplifier e qual problema ele resolve na modernização?

O Data Simplifier é uma biblioteca central do AWS Transform for mainframe que aborda o desafio de lidar com padrões de acesso à memória legados em Java. Ele fornece construções para suportar acesso à memória de baixo nível, tipos de dados legados (como zoneados, compactados, alfanuméricos) e acesso misto à structured/raw memória, que são comuns em aplicativos de mainframe, mas não estão disponíveis nativamente em Java. A biblioteca expõe esses recursos por meio de padrões Java familiares, como getters/setters APIs baseadas em classes, tornando-os acessíveis aos desenvolvedores de Java, mantendo a funcionalidade legada.

Como o AWS Transform for mainframe lida com layouts de memória e estruturas de dados legados?

AWS O Transform for mainframe lida com layouts de memória legados por meio da interface Record, que fornece uma abstração de matrizes de bytes com tamanho fixo. Para dados estruturados como “01 itens de dados” do COBOL, ele usa RecordEntitysubclasses que são geradas automaticamente durante a modernização. Essas classes mantêm a estrutura hierárquica dos dados legados, com cada elemento tendo uma relação pai-filho. O sistema suporta acesso à memória bruta e padrões de acesso estruturado, preservando a flexibilidade dos sistemas legados e fornecendo uma interface de programação moderna.

Como o AWS Transform for mainframe lida com a modernização dos conjuntos de dados do VSAM?

O componente Blusam está fornecendo suporte para a modernização dos conjuntos de dados do VSAM, com uma API dedicada, endpoints e um aplicativo web de administração (BAC: Blusam Administration Console). O Blusam usa um banco de dados relacional como back-end (PostgreSQL, usando RDS ou Aurora).

Como a hierarquia do segmento pai-filho é mapeada e a posição DL/I atual (o GN/GNP cursor) é reproduzida?

Mapeamento hierárquico. Cada tipo de segmento se torna uma tabela PostgreSQL <DBDName>_<SegmentName> chamada, e cada ocorrência de segmento é uma linha. A relação pai-filho é sustentada por uma coluna-chave concatenada (_concatkey): a de um filho _concatkey é a de seu pai _concatkey seguida pela chave do próprio filho, então a chave de cada descendente começa com a chave de seu ancestral. Recuperar todos os filhos de um dos pais é, portanto, uma correspondência de prefixo de chave. (Colunas_parent/_logicalparentid mais antigas ainda existem para compatibilidade com versões anteriores, mas _concatkey é o mecanismo usado.)

Exemplo — um banco de dados de dois níveis (resumo da conta em detalhes):

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

Uma linha de detalhes em conta 0000012345 é _concatkey = <ACCNTID key> + <detail key> obtida, então ela “começa com” a chave da linha de resumo. É assim que o tempo de execução sabe que é filho desse resumo.

Relações lógicas e segmentos lógicos também são suportados: um segmento lógico é exposto como uma visualização do banco de dados e a chave lógica secundária começa com a chave lógica do pai (lp_concatkey).

DL/I posição atual. Sim — o GN/GNP cursor é reproduzido pelo tempo de execução, não pelo código gerado. O tempo de execução lembra a posição atual (e o “pai estabelecido” em que o GNP navega) por PCB, a avança em cada PCB bem-sucedida e a limpa no final da unidade de trabalho GU/GN/GNP, exatamente como o IMS. Seu programa não gerencia a posição; ele apenas emite a próxima GN/GNP.

A leitura codificada (GU), a navegação sequencial (GN) e o get- (hold) -next-within-parent () são reproduzidos? GNP/GHNP

Sim, todos os três, com as variantes de espera (GHU/GHN/GHNP).

Exemplo — procure todos os resumos e, para cada um, veja seus detalhes (o padrão clássico de descarga):

      * 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 gerado (a chamada mantém sua forma — código de função, PCB, I/O área, SSA — e é roteada para o tempo de execução):

// 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);

Isso produz exatamente a travessia do IMS: GN traça raízes em ordem chave; depois de um GN no resumo, o GNP retorna os detalhes desse resumo um por um até GE (não há mais filhos).

As leituras qualificadas com range/comparison condições (GT/GE/LT/LE) são suportadas?

Sim. Um SSA qualificado com um operador relacional se torna uma condição equivalente em relação ao segmento, portanto, as leituras de intervalo e comparação se comportam como no IMS. Os operadores suportados são=,>,,>=,<, <=!=, mais booleanos OR entre as condições.

Exemplo — leia o primeiro detalhe cujo campo de carimbo de data/hora é maior que um valor:

       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 gerado — o SSA qualificado se torna um argumento de pesquisa contendo o operador e o valor (esse é o formulário produzido a partir de um CICSEXEC 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);

O tempo de execução retorna o primeiro segmento qualificado em ordem hierárquica, ou se nenhum. GE Multi-level SSAs qualificados (uma condição no nível dos pais e outra no nível do filho) e OR as combinações são tratadas da mesma forma — cada uma se torna um segmentoaddWhereClause(...)/adicional na mesma chamada.

Como são ISRT/DLET/REPL expressos?

Eles são emitidos exatamente como no IMS — mesmo código de função, mesmos SSAs — e o tempo de execução executa o /replace. hierárquico insert/delete

ISRT (inserir). Para um segmento dependente, uma chamada anterior deve ter estabelecido uma posição sobre o pai. Inserir de um filho lógico também creates/links seu pai lógico e segmento emparelhado quando o DBD o exigir.

      * 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.

Java gerado para o ISRT (como ele realmente aparece no programa modernizado):

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

DLET (excluir). Requer uma chamada de espera anterior (GHU/GHNou LOCKED sob EXEC DLI). A exclusão de um segmento ocorre em cascata entre seus dependentes, e as regras de exclusão do IMS são respeitadas (por exemplo, a exclusão de um pai lógico que ainda tem filhos lógicos é rejeitada).

       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 (substituir). Também requer uma retenção anterior. Somente os campos alterados são atualizados; os segmentos emparelhados são atualizados juntos.

       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

Java gerado para o par de retenção e exclusão (o DLET não usa SSA — ele exclui o segmento retido):

// 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);

Se DLET/REPL for emitido sem uma retenção anterior, o tempo de execução retornará o statusDJ, assim como o IMS.

Como os limites das transações (DB-INIT/DB-TERM) são gerenciados e como os lotes (BMP) e on-line (MPP) diferem?

O tempo de execução gerencia a confirmação e a reversão para você:

Exemplo — um ponto de verificação em um programa em lotes:

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

A diferença prática: um programa em lote controla sua própria commit/checkpoint cadência, enquanto uma transação on-line é confirmada uma vez por mensagem. Em ambos os casos, uma falha reverte a unidade de trabalho atual para o último ponto de confirmação.

O que locking/isolation se aplica? Uma “espera por atualização” pessimista pode ser adquirida?

Sim, uma espera para atualização está disponível — é exatamente isso que as chamadas GHU/GHN (de espera) fazem e isso é necessário antes. DLET/REPL Quando você emite uma chamada de espera, o tempo de execução retém o segmento para que o subsequente update/delete esteja seguro; a espera é liberada quando sua posição se move ou a unidade de trabalho termina.

Característica importante a ser observada em uma avaliação de simultaneidade: a retenção é gerenciada pelo tempo de execução do JHDB e o isolamento é fornecido pelo tempo de execução mais a transação do banco de dados anexa — não é um bloqueio de linha SQL bruto. SELECT ... FOR UPDATE Funcionalmente, ele fornece o comportamento de DL/I segurar e atualizar que seus programas esperam (e retorna “dados indisponíveis” BA se um segmento não puder ser obtido), mas o concurrency/throughput perfil sob forte contenção deve ser validado em relação à sua carga de trabalho, em vez de se presumir que corresponda exatamente. IMS/IRLM

Exemplo:

       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

Existe um equivalente sequencial em massa de alta velocidade (HSSR) e qual cache se aplica?

Não há uma API “HSSR” chamada separadamente, mas o caminho de leitura sequencial é otimizado para digitalização em massa: quando você navega com GN/GNP, o tempo de execução pré-busca segmentos irmãos em lotes (um cache antecipado) em vez de uma viagem de ida e volta por segmento, o que torna eficientes as passagens sequenciais completas do banco de dados.

Exemplo — um loop GN direto sobre cada raiz as lê em lotes eficientes sob as tampas:

       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.

Se isso atende a uma meta específica de taxa de transferência de HSSR para o tamanho do seu banco de dados é uma questão de desempenho. Recomendamos validá-lo medindo um trabalho em massa representativo em seu projeto modernizado; não citamos uma garantia de produtividade no resumo.

O JHDB oferece suporte a índices secundários do IMS (caminhos de acesso sem chave primária)?

Sim. Um índice secundário definido no DBD (um indexadoXDFLD/LCHILD) é modernizado em um índice de banco de dados mais uma visualização de ordenação, e um PCB que nomeia esse índice como sua sequência de processamento (PROCSEQ) pode navegar pelo segmento na ordem indexada em vez da ordem da chave primária. Seu programa usa o campo indexado em seu SSA exatamente como no IMS.

Exemplo — o banco de dados de autorização CARDDEMO já define um índice secundário no id da conta (ACCNTID); um programa programado com base no índice PCB pode ler resumos em ACCNTID ordem com as mesmas GU/GN chamadas, e o tempo de execução mantém uma posição separada dentro do índice secundário.

Portanto, caminhos de acesso não primários estão disponíveis no código gerado, desde que o índice secundário esteja presente no DBD e referenciado pelo PCB.

De que forma success/failure /"not found” aparecem e como a lógica de negócios deve avaliá-los?

Exatamente como no IMS: cada chamada retorna o código de DL/I status padrão de 2 caracteres no PCB (paraCALL 'CBLTDLI') ou no DIB (para). EXEC DLI Sua lógica de negócios o testa após cada chamada, sem nenhum novo mecanismo para aprender. O conjunto completo de códigos de status do IMS é reproduzido. Os mais comuns:

Exemplo — avalie o status após uma leitura digitada:

       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 gerado — após a chamada, o programa lê o mesmo campo de status de 2 bytes do PCB e se ramifica nele (em branco = sucesso, "GE" = não encontrado), espelhando exatamente o 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
}

Somente falhas genuínas de infraestrutura (por exemplo, um banco de dados subjacente error/timeout) aparecem como um JHDB-specific código; todas as DL/I condições normais usam os códigos de status padrão do IMS que seus programas já verificam.

O CBLTDLI CHKP e o ROLB são suportados no estado em que se encontram (interceptados e executados pelo tempo de execução)?

Sim, ambos são suportados no estado em que se encontram. O programa modernizado mantém o original CALL 'CBLTDLI' USING <func> ... e o tempo de execução intercepta o código da função e o executa. Você não reescreve essas chamadas e elas não são emitidas como “sem suporte” ou ignoradas silenciosamente.

Exemplo — um programa em lote fazendo um ponto de verificação e, em um caminho de erro, revertendo:

       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.

Ambas as chamadas são executadas pelo mesmo ponto de CBLTDLI entrada no Java gerado, exatamente como qualquer GU/GN/ISRT chamada; o tempo de execução executa o ponto de verificação ou a reversão e retorna o controle.

// 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);

Um lote CALL 'CBLTDLI' USING ROLB-FUNCT PCB-MASK sai no mesmo formato:

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

Ponto de verificação simbólico e reinicialização (XRST) — o ID do ponto de verificação é a área do usuário e a reinicialização saved/restored reposiciona o banco de dados?

Sim para todos os três. Tanto os formulários de ponto de verificação quanto uma reinicialização XRST equivalente são compatíveis:

Exemplo — ponto de verificação simbólico salvando uma área de trabalho e reiniciando a restauração:

       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 gerado — o CHKP e o XRST simbólicos mantêm seu id e seus operandos (comprimento, área) na mesma CBLTDLI chamada, para que as áreas fluam inalteradas saved/restored :

// 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);

A carga útil persistente do ponto de verificação (ID do ponto de verificação, posições do banco de dados e áreas salvas) é exatamente o que o mecanismo documentado armazena. jhdb.checkpointPersistence

Escopo exato de confirmação do CHKP e escopo de reversão do ROLB.

O CHKP confirma toda a transação da unidade de execução e o ROLB reverte toda a transação da unidade de execução — não apenas a parte. JHDB/IMS Como todo o trabalho persistente em uma unidade de execução (dados hierárquicos do JHDB, DB2/SQL trabalho e atualizações Blusam /VSAM) é executado em uma transação gerenciada em tempo de execução nas mesmas conexões de banco de dados, uma confirmação de CHKP ou uma reversão de ROLB abrange tudo isso junto.

Exemplo:

      * 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.

Esse comportamento de unidade de trabalho única corresponde à expectativa do mainframe que CHKP/ROLB delimita toda a unidade recuperável, não apenas as chamadas do IMS DB.

Um ABEND aciona a mesma reversão automática?

Sim. Um ABEND encerra a unidade de execução sem atingir a confirmação bem-sucedida do final da unidade de trabalho, portanto, a transação implícita da unidade de execução não é confirmada e nenhum trabalho realizado desde a última não persiste. commit/checkpoint Quando o ABEND aparece como uma exceção de tempo de execução, a reversão automática (rollbackOnRTE) também se aplica. De qualquer forma, o efeito líquido é a expectativa do mainframe: após um ABEND, as alterações não confirmadas são transferidas para o último ponto de confirmação.

Qual código de status é retornado depois CHKP/ROLB e como a lógica de negócios deve avaliá-lo?

O status é retornado no local padrão — o campo de status do PCB — lido exatamente como qualquer outra DL/I chamada.

Exemplo — verifique o status após um ponto de verificação:

       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 gerado — a verificação de status lê o campo de status do PCB de volta (em branco = sucesso, senão falha), espelhando o COBOL:

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

Batch versus online para essas duas chamadas — o CHKP é significativo on-line e existem restrições?

Padrão recomendado para programas Java escritos à mão.

Use o mesmo ponto de CBLTDLI entrada para CHKP/ROLB programas Java escritos à mão — não use uma API de transação de baixo nível separada. A emissão CHKP/ROLB (e GU/GN/ISRT/...) por meio da CBLTDLI chamada mantém um programa escrito à mão se comportando de forma idêntica a um transformado: o tempo de execução aplica a mesma unidade de execução, ponto de verificação commit/rollback, tratamento da posição do banco de dados e coordenação/ save/restoredescritos acima. Blusam VSAM/SQL Isso também significa que o middleware escrito à mão e os programas gerados compartilham um modelo de transação consistente.

Forma conceitual das chamadas em um programa Java escrito à mão (mesmos argumentos das chamadas COBOL — código da função, PCB e, para ponto de verificação simbólico, o id e as áreas salvas):

// 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);

Confie na transação implícita da unidade de execução para o caminho normal (nenhuma confirmação explícita é necessária no final de uma unidade de trabalho bem-sucedida) e use CHKP/ROLB somente onde o programa antigo a usou. Se um programa escrito à mão tem uma necessidade genuína de dirigir commit/rollback fora do DL/I modelo, esse é um ponto de design a ser levantado conosco para que possamos recomendar o gancho de tempo de execução correto.

Onde posso encontrar detalhes sobre o processo de transformação?

Consulte o AWS Transform para ver a documentação de refatoração de mainframe.

Quais são os nomes dos módulos gerados pelo AWS Transform for mainframe?

Serviço, entidades, web e ferramentas.

Por que foi Java/Spring escolhida como uma das tecnologias-alvo do AWS Transform for mainframe?

Java/Spring foi escolhida como tecnologia-alvo por causa de sua ampla adoção, grande pool de talentos e recursos corporativos robustos. O ecossistema Java oferece bibliotecas, estruturas e ferramentas abrangentes que oferecem suporte ao desenvolvimento de aplicativos modernos. O Spring framework fornece recursos de nível corporativo, recursos nativos da nuvem e segue as melhores práticas do setor, tornando-o ideal para aplicativos modernizados.

Qual é o nome do projeto principal que contém os módulos gerados pelo AWS Transform for mainframe?

O nome do projeto principal tem o sufixo “-pom” e pode ser definido no Centro de Transformação usando a propriedade Transform chamada project.

Como o AWS Transform for mainframe gerencia a modernização do agendador legado, se fornecido?

Os ativos antigos do agendador não estão sendo modernizados pelo AWS Transform for mainframe. Eles estão sendo levados em consideração durante a fase de avaliação, para ajudar a identificar possíveis artefatos perdidos.

Qual é o requisito para depurar o código gerado com o AWS Transform for mainframe?

Qualquer ambiente de desenvolvimento integrado (IDE) compatível com Java, como Eclipse JetBrain, ou VisualCode.

Quais ambientes estão disponíveis para implantar o aplicativo modernizado com o AWS Transform for mainframe?

Windows Server, servidor Linux e contêiner Docker Linux.

O AWS Transform para aplicativos refatorados de mainframe pode ser executado em qualquer infraestrutura?

Embora os aplicativos refatorados do AWS Transform for mainframe não tenham sido projetados para serem executados em nenhuma infraestrutura, eles oferecem flexibilidade significativa nas opções de implantação. Esses aplicativos podem ser implantados em várias plataformas de computação, incluindo serviços gerenciados em nuvem, computação sem servidor e infraestrutura local.

Qual configuração de MQ é compatível com o AWS Transform for mainframe?

SQS, IBM WebSphere MQ.

Em quais servidores de aplicativos um usuário pode implantar a lógica de aplicativos comerciais Java com o tempo de execução da modernização do AWS mainframe?

Apache Tomcat. Consulte as notas de lançamento para ver a versão compatível.

Como o aplicativo refatorado se integra a outros, como o Amazon Serviços da AWS Aurora?

O aplicativo modernizado se integra ao apoiar a transformação para Serviços da AWS soluções de banco de dados nativas em nuvem, como Amazon Aurora e RDS for PostgreSQL. AWS O Transform for mainframe garante a integração entre aplicativos modernizados e Serviços da AWS permite que as organizações usem os recursos de nuvem. Essa integração se estende tanto ao armazenamento de dados quanto aos serviços de aplicativos dentro do AWS ecossistema. Além do armazenamento de banco de dados, o AWS Transform for mainframe Runtime se integra a vários, incluindo armazenamento em cache do Serviços da AWS Amazon ElastiCache for Redis, AWS Secrets Manager para gerenciamento de configuração e modernização de AWS mainframe para implantação. Ele suporta Amazon EC2, Amazon EKS e ECS gerenciados pela Fargate para implantação de contêineres. O sistema pode ser utilizado AWS Identity and Access Management para autenticação, o Amazon Simple Storage Service para armazenamento e oferece suporte à integração com outros Serviços da AWS por meio de conectores de configuração e serviço.

Como o aplicativo refatorado garante que os requisitos de escalabilidade sejam atendidos?

A solução garante escalabilidade ao transformar aplicativos em arquiteturas nativas da nuvem que podem usar a infraestrutura elástica. AWS Ele implementa padrões de design modernos e melhores práticas que permitem o dimensionamento horizontal e vertical. A abordagem orientada a serviços permite o dimensionamento independente dos componentes. Os aplicativos modernizados podem aproveitar os recursos de escalabilidade inerentes aos serviços em nuvem.

O que acontece depois que a refatoração do código-fonte é concluída?

Após a refatoração do código-fonte, duas etapas principais ocorrem. Primeiro, o aplicativo refatorado é criado. Em segundo lugar, o aplicativo é implantado. A implantação é feita em seu Conta da AWS (AWS Mainframe Modernization AWSTransform for mainframe Runtime), onde os clientes gerenciam sua própria infraestrutura e implantam em várias plataformas, incluindo Amazon EC2, ECS no EC2 ou no Fargate, EKS no EC2.

Como posso implantar e executar um aplicativo modernizado com o AWS Transform for mainframe em uma Amazon Linux AMI personalizada?

Isso pode ser feito implantando o aplicativo usando o AWS Transform for mainframe Runtime no Amazon EC2. O processo envolve criar um Java/Spring aplicativo com uma dependência da biblioteca AWS Transform for mainframe Runtime e implantá-lo em uma Amazon Linux AMI personalizada. Para obter instruções detalhadas sobre essa abordagem, consulte Configurar o AWS Transform for mainframe Runtime no Amazon EC2.

Há uma Amazon Machine Image (AMI) disponível? Há uma imagem do Docker disponível?

O cliente pode empacotar e executar um aplicativo AWS Transform for mainframe como um contêiner Docker?

Sim, consulte Configurar o AWS Transform for mainframe Runtime no contêiner.

Como o agendamento de trabalhos funciona com lote?

É integrado com a ramificação Control-M /Stone ou com qualquer outro agendador distribuído.

Como o aplicativo se protege contra ataques de injeção de SQL?

O aplicativo implementa as melhores práticas de SQL por toda parte. Todas as consultas ao banco de dados usam instruções preparadas, que efetivamente evitam ataques de injeção de SQL ao separar o código SQL dos dados fornecidos pelo usuário. Isso garante que a entrada do usuário seja sempre tratada como dados em vez de código executável.

Quais medidas estão em vigor para evitar vulnerabilidades de injeção de comandos do sistema operacional?

AWS as equipes de segurança conduzem análises regulares de segurança do AWS Transform for mainframe Runtime. Se as equipes detectarem alguma anomalia, como código, que poderia potencialmente permitir a injeção de comandos do sistema operacional, trabalhará AWS imediatamente para resolvê-la. Esse monitoramento contínuo garante que o tempo de execução permaneça seguro contra ameaças de injeção de comando.

O aplicativo está vulnerável a ataques de travessia de diretório?

Não. Essa vulnerabilidade não se aplica ao aplicativo Angular front-end. Para o back-end, o aplicativo usa apenas um endpoint com um contrato de interface limitado que nunca contém informações de “caminho” ou “diretório”. Esse design elimina o risco de ataques de travessia de diretório.

Como o aplicativo se protege contra ataques XSS?

O aplicativo segue as melhores práticas de segurança do Angular, conforme descrito na documentação oficial de segurança do Angular. A natureza do aplicativo é inerentemente limitada em termos de interface do usuário, pois corresponde ao aplicativo de mainframe legado. O aplicativo não manipula URLs, scripts dinâmicos ou HTML gerados pelo back-end. Essa superfície de ataque limitada reduz significativamente os riscos de XSS.

Qual proteção é implementada contra ataques de CSRF?

O aplicativo utiliza o suporte CSRF nativo da Spring, que fornece proteção robusta contra ataques de falsificação de solicitações entre sites prontos para uso.

A entrada do usuário pode levar à injeção de cabeçalho HTTP?

Não. As entradas do usuário são estritamente limitadas em tamanho para corresponder ao formato antigo do aplicativo de mainframe. Quando o back-end recebe uma solicitação, ele formata imediatamente a entrada de acordo com formatos predefinidos, o que truncaria qualquer conteúdo injetado. Além disso, o aplicativo nunca constrói cabeçalhos HTTP com base nas entradas do usuário no único endpoint usado pelo aplicativo, impossibilitando a injeção do cabeçalho HTTP.

Como o aplicativo é protegido contra ataques de clickjacking?

O aplicativo executa a maioria das ações usando pressionamentos de teclas em vez de cliques do mouse, tornando-o inerentemente resistente a ataques de clickjacking. Essa opção de design reduz significativamente a superfície de ataque desse tipo de vulnerabilidade.

Os ataques de estouro de buffer podem ocorrer no aplicativo?

Não. As entradas do usuário são estritamente limitadas em tamanho para corresponder ao formato antigo do aplicativo de mainframe. Quando o back-end recebe uma solicitação, ele formata imediatamente a entrada de acordo com os formatos correspondentes, evitando que ocorram condições de estouro de buffer.

Como o controle de acesso e a autorização são gerenciados?

O controle de acesso determina globalmente se os usuários têm direitos de acessar o endpoint de back-end exclusivo. Depois de autenticados, o código e os dados do aplicativo gerenciam os controles de autorização. Isso garante a separação adequada das preocupações e o gerenciamento seguro do acesso.

Quais medidas evitam o sequestro de sessões?

O uso combinado dos recursos nativos do Spring e do Angular para gerenciamento de sessões e prevenção de XSS, juntamente com a adesão às melhores práticas da estrutura, evita o sequestro de sessões. O aplicativo pode aprimorar ainda mais a proteção por meio de:

Essas medidas de segurança em camadas fornecem proteção abrangente contra tentativas de sequestro de sessão.