Este artigo discute problemas que podem ocorrer ao migrar aplicativos XL C/C++ da plataforma IBM® AIX® para a plataforma IBM® z/OS®. Também discute ideias e sugestões para obter melhor desempenho do aplicativo na plataforma z/OS, após a operação de migração estar completa.

Migrar aplicativos de uma plataforma para outra nem sempre é uma operação fácil ou sem erros. Várias questões podem trazer problemas ao processo de migração. Entretanto, é possível reduzir e minimizar esses problemas, e tornar o processo mais fácil e com menos erros, especialmente com planejamento.

Após mover o aplicativo de uma plataforma para outra, ele deve ser ajustado para obter o máximo desempenho na nova plataforma. Geralmente, a nova plataforma tem recursos e restrições que a velha não tinha. O ajuste para ela pode trazer benefícios que não estavam presentes na plataforma original e aproveitar o novo hardware.

Rajan Bhakta, Staff Software Developer, IBM

Photo of Rajan BhaktaRajan Bhakta trabalha para a IBM. Ele tem quatro anos de experiência trabalhando com a equipe de teste de C/C++ do IBM z/OS, bem como quatro anos de desenvolvimento em z/OS e IBM AIX C. Atualmente, ele é o representante do Padrão ISO C para o Canadá, e representante dos Padrões C da IBM no INCITS. Ele também é o Arquiteto Técnico dos Compiladores XL C/C++ do z/OS.



Zach Zylawy, Staff Software Developer, IBM

Photo of Zach ZylawyZach Zylawy trabalha para a IBM. Ele tem quatro anos de experiência trabalhando para a equipe de teste de C/C++ do IBM z/OS, e cinco anos de desenvolvimento em z/OS e IBM AIX C++.



03/Set/2010

Visão Geral

Este artigo apresenta sugestões sobre como resolver alguns problemas comuns que podem ocorrer ao migrar um aplicativo C ou C++ da plataforma IBM® AIX® para IBM® z/OS®. Também discute maneiras de melhorar o desempenho do aplicativo no z/OS, após a migração ser concluída.

Os tópicos cobertos na seção de migração são:

  • Dependências externas
  • Código específico do hardware
  • Dependências de alinhamento
  • Formatos de ponto flutuante
  • Codificações de caractere
  • Extensões de linguagem
  • DLLs
  • Níveis de linguagem
  • Ambiente de programação

Os tópicos cobertos na seção de desempenho são:

  • Quando otimizar
  • Tempo de compilação comparado com tempo de execução
  • Modificadores do tempo de compilação
  • Ambiente do tempo de execução
    • Interoperabilidade entre linguagens
    • Responsabilidades do tempo de execução
  • Modificadores do tempo de execução baseados no compilador
  • Modificadores do tempo de compilação baseados no sistema
  • Uso de memória
  • Auxílios de desempenho e exatidão no nível da origem
    • Funções integradas
    • Formatos de ponto flutuante
  • Tempo de carregamento
    • DLPA (dynamic link pack area)
    • VLF/LLA (virtual look-aside facility/library lookaside)
  • Opções de tempo de execução
  • Desempenho de E/S

Migração

Antes de iniciar o processo de migração

Migrar um aplicativo não trivial de uma plataforma para outra envolve bastante trabalho. Entretanto, alguns preparativos antes de iniciar a migração de AIX para z/OS tornam o projeto mais fácil, e minimizam erros do compilador no z/OS.

Nota: A maioria dessas sugestões pode ser aplicada a migrações entre quaisquer plataformas, e não são exclusivas da migração de AIX para z/OS.

Lidar com mensagens do compilador

A primeira e mais importante etapa a ser tomada ao migrar aplicativos do AIX para o z/OS, é lidar com todas as mensagens de diagnósticos produzidas pelo compilador no AIX. Embora o comportamento do programa possa ser correto mesmo com esses avisos, sua presença indica um problema em potencial, que pode ocorrer quando o aplicativo for compilado no z/OS. Responder aos avisos antes da migração pode prevenir potenciais problemas no z/OS, e economizar horas de tempo de depuração tentando encontrá-los.

Dependências externas

Ao fazer a migração, é necessário identificar se o aplicativo chama ou usa arquivos de cabeçalho ou programas externos que não estão disponíveis no z/OS, e modificar o seu código de origem se for o caso.

Tipos de código

A próxima etapa é localizar e identificar quaisquer áreas no programa de origem que usem os seguintes tipos de código:

  • Código específico de hardware: qualquer porção de código que lide com aspectos de hardware que sejam diferentes entre as plataformas. Por exemplo, qualquer instrução ASM (Assembly) deve ser modificada para corresponder à linguagem e sintaxe ASM do destino.
    • A ordem do byte ("Extremidade") é a mesma entre o AIX e o z/OS, portanto não é necessária mudança alguma em relação a isso.
  • Código específico de alinhamento: o AIX e o z/OS podem ter layouts de estrutura diferentes. Por exemplo, um campo de bit de tamanho zero como primeiro membro no AIX resulta em tamanho e alinhamento diferentes em relação ao z/OS. A estrutura C mostrada na Listagem 1 tem um alinhamento de quatro e tamanho de 4 no AIX, mas um alinhamento de um e tamanho de um no z/OS.
    • Isso geralmente não é um problema, porque a maioria dos códigos bem-escritos não depende muito de tamanhos de estrutura e alinhamento.
    • A opção AGGR (aggregate) mostra o mapa agregado, que exibe o layout da estrutura.
Listagem 1. Código com tamanho e alinhamento diferentes no AIX e no z/OS
struct A {
   int :0;
   char a;
};
  • Intervalos de ponto flutuante: No AIX e no z/OS, os intervalos de alguns tipos de pontos flutuantes são diferentes. Por exemplo, o tipo duplo longo pode ter intervalos diferentes, dependendo do formato de ponto flutuante usado. Os formatos de ponto flutuante disponíveis também são diferentes, e serão discutidos mais adiante neste artigo.
    • Isso geralmente não representa um problema, a menos que precisão e resultados específicos sejam necessários.

Esses tipos de construções que dependem do hardware são a parte mais difícil do processo de migração, porque geralmente implicam em ter que escrever código novo. Entretanto, o compilador IBM® oferece recursos para facilitar esse processo, tais como a opção do compilador FLOAT(IEEE|HEX), bem como vários #pragma's que permitem modificar o alinhamento e embalagem das estruturas.

Codificações de caractere

O conjunto de caracteres usado por padrão também é diferente entre o AIX e o z/OS. O AIX usa codificação ASCII, enquanto o z/OS usa EBCDIC (Extended Binary Coded Decimal Interchange Code). É possível usar a opção ASCII|NOASCII no z/OS para codificar caracteres em ASCII. Entretanto, deve-se prestar muita atenção a esta parte da migração, pois codificações de caractere podem ser uma fonte de erros muito sensível e difícil de diagnosticar.

A principal questão com diferentes codificações de conjunto de caracteres é procurar por código que dependa de valores numéricos, ou de padrões de valores numéricos, para os caracteres. Por exemplo, o fragmento de código mostrado na Listagem 2 retorna verdadeiro para ASCII, mas falso para EBCDIC se a variável contiver a letra "A".

Listagem 2. Código que verifica se existe um caractere ASCII
if (is_this_char_variable_the_capital_letter_A == 65) {

Uma modificação adequada desse código é mostrada na Listagem 3.

Listagem 3. Código que verifica se existe um caractere EBCDIC
if (is_this_char_variable_the_capital_letter_A == ‘A’) {

Outros padrões comuns que dependem de codificações de caractere ASCII são cadeias de maiúsculas e varredura por letras (em vez de números ou caracteres especiais) examinando os intervalos.

Extensões de linguagem

É preciso estar ciente de que nem todas as extensões de linguagem disponíveis no AIX estão disponíveis atualmente no z/OS (e vice-versa), embora a IBM esteja continuamente diminuindo a diferença de disponibilidade entre as duas plataformas. Recursos tais como OMP/SMP (Open Multi-Processing support/Symmetric Multiprocessing) e AltiVec (um conjunto de instruções SIMD [single instruction, multiple data] de ponto flutuante e números inteiros) não estão disponíveis no z/OS, assim como algumas das extensões de compatibilidade do GCC (GNU Compiler Collection). Para verificar quais recursos estão disponíveis no z/OS, consulte z/OS XL C/C++ Language Reference, cujo link está na seção Recursos.

DLLs

A criação de dynamic link libraries (DLL) também é diferente nas duas plataformas. DLLs no z/OS se apoiam em um arquivo de texto gerado pelo compilador, chamado Definition Sidedeck, que, por convenção, tem a extensão do arquivo .x. Definition Sidedecks são exclusividade do z/OS, e um deles deve ser gerado para cada DLL criada naquela plataforma. Eles são incluídos na etapa de vinculação de qualquer aplicativo que use um ou mais símbolos da DLL.

Para mais informações sobre DLLs, consulte a seção "Build and use a DLL" no capítulo "Binding z/OS XL C/C++ Programs" do z/OS XL C/C++ User’s Guide , cujo link está na seção Recursos.

Níveis de linguagem

Por fim, os níveis de linguagem disponíveis durante a compilação no XL C/C++ para AIX também estão disponíveis no XL C/C++ para z/OS. No entanto, para C, o AIX usa sub-rotinas xlC para configurar o nível de linguagem, enquanto o z/OS usa uma opção do compilador (se estiver sendo usado o utilitário c89/cxx em vez do utilitário xlC, que foi introduzido no z/OS V1R7).

Para tornar a migração mais simples para o pessoal do projeto, mantenedores e desenvolvedores que estão familiarizados com o UNIX®, use USS (UNIX System Services) em vez de MVS (Multiple Virtual Storage). A migração é possível em ambos os ambientes, mas o USS está mais próximo de um ambiente UNIX tradicional, e é familiar aos desenvolvedores com experiência no AIX. O ambiente POSIX (Portable Operating System Interface for UNIX) é configurado usando USS.


Aprimoramentos de desempenho

Depois de migrar o aplicativo, é necessário fazer alguns ajustes para aproveitar os benefícios que o z/OS oferece, além de sua confiabilidade e robustez. Alguns dos aprimoramentos de desempenho listados nesta seção estão também disponíveis e são aplicáveis nos compiladores XL C/C++ em todas as plataformas.

Entretanto, o ajuste de desempenho deveria ser a etapa final no processo de migração. A parte mais importante da migração é fazer com que o aplicativo funcione corretamente. Muito tempo pode ser perdido localizando erros em código otimizado prematuramente. Por isso, é melhor fazer os ajustes de otimização depois da migração bem-sucedida.

"Otimização prematura é a raiz de todos os males" -- C.A.R. Hoare

Melhorar desempenho é um assunto complexo, e existem muitas técnicas para fazê-lo. Abaixo estão algumas dicas para melhorar o desempenho dos aplicativos adaptados, e opções mais detalhadas serão apresentadas em seções posteriores.

Os recursos no final do texto podem dar mais informações detalhadas sobre essas e outras técnicas de desempenho que estão fora do escopo deste artigo.

É possível obter a maior parte dos aprimoramentos de desempenho através das configurações de otimização do compilador no z/OS, assim como no AIX. Assim como em outras plataformas e compiladores, há uma relação de dependência entre tempo de compilação e tempo de execução.

Tempo de compilação comparado com tempo de execução

Há um balanço relativo entre o tempo gasto para compilar um programa e o tempo que leva para executar o programa compilado resultante. Em geral, quanto mais tempo levar para compilar um programa (usando otimização), mais rápido ele irá ser executado. Observe que essa relação NÃO é linear, e que nem sempre um tempo de compilação maior resulta em execuções mais rápidas. Por exemplo, há certos programas nos quais um nível menor de otimização pode resultar em execução mais rápida.

Como desenvolvedor, você pode fazer alguns experimentos de desempenho, e obter um equilíbrio adequado entre tempos de compilação e execução. Experimentando com opções de compilador, você pode descobrir qual conjunto de otimizações é melhor para seu programa em particular. Ferramentas IBM como o Performance Analyzer podem ajudar a monitorar, analisar e criar relatórios sobre desempenho de aplicativos.

Em geral, durante o desenvolvimento, recomenda-se não usar otimização, ou usar otimização baixa, para facilitar a diminuição do tempo de construção e o suporte para depuração. Mas todas as compilações para teste ou produção devem ser feitas com o nível de otimização com o qual o produto final deverá ser enviado.

A maioria das opções de otimização do compilador disponíveis no XL C/C++ para AIX também estão disponíveis no XL C/C++ para z/OS, tais como:

  • O2, O3, O4e O5
  • IPA, HOT, PDF1e PDF2
  • INLINE, ARCHITECTUREe TUNE

Entretanto, é geralmente recomendável passar algum tempo ajustando essas opções na nova plataforma, pois diferenças de arquitetura podem fazer com que um conjunto diferente de opções seja melhor no z/OS. Para proporcionar mais benefícios para o desempenho após a migração, não basta usar as mesmas configurações de otimização usadas no AIX. Isso se deve às diferenças de hardware entre as plataformas, e às oportunidades de otimização criadas por essas diferenças para o otimizador.

Desempenho do tempo de compilação

O desempenho do tempo de compilação pode ser melhorado usando as seguintes diretrizes:

  • Verifique se o aplicativo tem um caminho de procura bem ordenado para os arquivos de cabeçalho. Por exemplo, o arquivo de cabeçalho de cada usuário está no primeiro diretório do seu caminho de procura de arquivos de cabeçalho.
  • Especifique a opção OE correta para localizar os arquivos certos em conjuntos de dados ou no sistema de arquivos USS. Por exemplo, se você estiver no USS e usando arquivos, especifique OE. Se estiver no ambiente MVS e usando conjuntos de dados, especifique NOOE. Para mais informações sobre a opção OE, consulte o z/OS XL C/C++ User’s Guide , cujo link está na seção Recursos.
    • Use os arquivos de cabeçalho do USS do z/OS (em vez de conjuntos de dados particionados) para melhorar o tempo de compilação.
  • Ao trabalhar no USS, dê a cada usuário um arquivo de sistema montável separado, para evitar disputa de E/S.
  • Use o componente de ligação para permitir religar módulos para pequenas alterações.

Nota: O componente de ligação tem um limite maior para comprimento de nomes que o vinculador.

Ao fazer ajustes no programa, lembre-se que o z/OS é otimizado, principalmente, para rendimento de E/S, de modo que os maiores ganhos de desempenho podem ser obtidos focando nesse aspecto forte da plataforma.

Desempenho no tempo de execução

Ao contrário do AIX, o z/OS usa um tempo de execução gerenciado chamado de Language Environment (LE). O Language Environment (ou ambiente de linguagem) cria um único ambiente de tempo de execução para várias linguagens de alto nível, incluindo:

  • C/C++
  • COBOL
  • PL/I
  • Programas de assembler ativados pelo ambiente de linguagem

Com um único ambiente de tempo de execução, incompatibilidades entre ambientes específicos das linguagens são eliminadas. Isso que significa, por exemplo, que aplicativos COBOL e C podem se comunicar eficiente e facilmente, dadas as configurações corretas. Além disso, é possível criar aplicativos com programas componentes escritos em várias linguagens. O resultado final é código que é executado mais rápido, é menos suscetível a erros e é mais fácil de manter.

Algumas funções do ambiente de linguagem incluem:

  • Carregamento de DLL
  • Inicialização estática para programas reentrantes
  • Manipular chamadas de biblioteca, tais como printf() e malloc()

Entretanto, o fato de que o ambiente de linguagem foi usado será, geralmente, transparente para os programadores, e apresenta poucas diferenças para desenvolvedores com experiência no AIX. Mais informações sobre LE podem ser encontradas em z/OS Language Environment Concepts Guide , cujo link está na seção Recursos.

É possível melhorar o desempenho do tempo de execução seguindo as diretrizes a seguir:

  • Geralmente, se várias pequenas funções são chamadas com frequência (como os métodos get e set em objetos C++), use o recurso XPLink para usar um tipo de vinculação diferente, que deve melhorar o desempenho deste aplicativo no tempo de execução. As bibliotecas de tempo de execução das linguagens têm versões XPLink de funções, para obter todos os benefícios que esse recurso proporciona.
  • Use a opção -qinfo=als no AIX antes de migrar para o z/OS para ajudar a garantir que o código está seguindo as regras de alias do ANSI. Essa opção está disponível em XL C/C++ V10.1 e posteriores. Ela lista potenciais violações de alias (segundo ANSI) no código de origem, e os locais prováveis dessas violações.
    • Se não houver violações de alias, o compilador terá mais oportunidades de otimização em níveis de otimização mais altos.
    • Se você tiver problemas funcionais ao usar as otimizações do compilador, experimente usar NOANSIALIAS para verificar se o código não está seguindo as regras de alias do ANSI em casos nos quais a opção -qinfo=als não encontrou problemas (pois essa opção não pode -qinfo=als encontrar todos os casos). Se o desempenho for importante, essa opção não deve ser usada em compilações de produção; pelo contrário, todas as violações de alias segundo o ANSI devem ser corrigidas.
  • Use níveis mais altos de otimização e feedback direcionado pelo perfil. Níveis mais altos de otimização fazem com que o compilador realize mais análises do aplicativo, proporcionando mais oportunidades para melhorias do desempenho no tempo de execução. Feedback direcionado por perfil resulta em ajustes para cargas de trabalho representativas, para maiores benefícios no desempenho no tempo de execução.
  • Coloque o conjunto de dados de carregamento em DLPA, e a consulta de cache em VLF/LLA. Esses conceitos do z/OS permitem carregamento e consultas mais rápidos. Eles são discutidos em mais detalhes mais à frente neste artigo. O Programador de Sistema do z/OS pode lhe ajudar a implementar isso.
  • Se o programa C não tem dependência no ambiente de linguagem, use a opção METAL do compilador para C (Metal C). Metal C permite código independente do ambiente de linguagem que pode evitar o código em excesso ao passar pelo tempo de execução gerenciado.
    • Observe que nem todas as funções de biblioteca C estão disponíveis no Metal C. Consulte z/OS Metal C Programming Guide and Reference, cujo link está na seção Recursos.
  • Use o nível máximo em comum da opção ARCH/TUNE que é suportado pelo hardware no qual o aplicativo será executado. Isso permite instruções adicionais, e explora melhor o hardware. Por exemplo, ao implementar um aplicativo em três máquinas que suportam ARCH 6, 9 e 8, respectivamente, compile os aplicativos com ARCH(6), o nível ARCH máximo suportado pelas três máquinas.

Uso de memória pelo aplicativo

O uso de memória também é, geralmente, algo a ser considerado. Há várias opções disponíveis para reduzir os tamanhos dos módulos e objetos. O aplicativo pode usar reentrada e DLLs para reduzir a área de cobertura da memória de várias chamadas de um aplicativo e as partes compartilhadas de vários aplicativos. Em um nível menor, a opção COMPRESS pode reduzir o tamanho dos objetos gerados. Verifique também se as constantes são de fato constantes, e use as opções ROCONST e ROSTRING do compilador para colocar as constantes na memória de somente leitura. Isso facilita a depuração de problemas, e a liberação de seções estáticas graváveis para outros fins.

Melhorias no desempenho do tempo de execução no nível da origem

Algumas técnicas que envolvem modificar o código de origem do aplicativo podem ser usadas para melhorias de desempenho. Para a maior melhoria, como mencionado antes neste artigo, verifique se o código de origem segue as regras apresentadas na opção ANSIALIAS do compilador para obter os benefícios máximos das otimizações de alto nível.

Funções integradas

Integrações de hardware permitem que o compilador use código assembly para realizar operações comuns que, de outra forma, exigiriam uma chamada de função. O benefício de usar recursos integrados é que os acréscimos de prólogos e epílogos, que podem acrescentar muito código extra, são eliminados. Isso pode aumentar consideravelmente a velocidade de execução do aplicativo, se, por exemplo, as integrações forem usadas em um loop que é chamado várias vezes. Além de remover os prólogos e epílogos de funções, o compilador pode otimizar melhor códigos que utilizam integrações.

Não é estritamente necessário usar as integrações de hardware diretamente: a IBM fornece funções integradas para permitir que usuários chamem funções comuns.

Essas funções integradas são fornecidas através de cabeçalhos de biblioteca padrão, como:

  • abs()
  • floor()
  • strcpy()

Essas funções são mapeadas diretamente para integrações de hardware, proporcionando assim oportunidades de desempenho sem intervenção explícita do usuário.

Essas funções integradas são fornecidas através de cabeçalhos de biblioteca padrão, como:

  • stdlib.h
  • math.h
  • decimal.h

O z/OS XL C/C++ Programming Guide (cujo link está na seção Recursos) tem mais informações sobre funções integradas e suas integrações de hardware subjacentes.

O compilador usa a opção ARCH para determinar quais integrações estão disponíveis no hardware. Valores mais altos de ARCH utilizam um número maior de integrações. Ou seja, quanto mais novo for seu hardware z/OS, maior será o número de integrações disponíveis para você.

Embora a maioria das funções integradas usadas pelo compilador XL C seja compartilhada entre o AIX e o z/OS, há diferenças nas funções do XL C++ para cada plataforma. Uso explícito de funções integradas em código de origem no AIX pode causar erros de "símbolo indefinido" ao compilá-lo no z/OS.

O z/OS XL C/C++ Programming Guide (cujo link está na seção Recursos) contém uma lista de funções integradas disponíveis no z/OS (para C e C++).

Existem integrações para várias operações de programação comuns, e também para manipular vários tipos de dados comuns ou específicos da IBM, como tipos de dados de ponto flutuante.

Os tipos de dados de ponto flutuante suportados pelo z/OS são:

  • Decimal: permite até 31 dígitos, e representa números decimais exatamente.
  • Ponto flutuante decimal: representa números decimais de forma exata e compacta.
    • Por exemplo, long long __d64_to_long_long(_Decimal64);
  • Ponto Flutuante Hexadecimal: Base 16. Diferentes intervalos de precisão, mas os mesmos intervalos de expoente para tipos de ponto flutuante.
  • Ponto Flutuante Binário: Segue a especificação IEEE-754.

O livro z/OS Principles of Operation(cujo link se encontra na seção Recursos) tem informações bem detalhadas sobre todas as integrações de hardware.

Algumas integrações apenas realizam conversões de tipos no hardware em vez do software (o que acelera significativamente o tempo de execução), como mostrado na Listagem 4.

Listagem 4. Conversões integradas de tipos
int __srstu(unsigned short *op1, unsigned short *op2, unsigned short pattern, 
   unsigned short **found_char);

Essa integração procura por um padrão de caracteres dentro de subcadeias. Geralmente isso seria implementado em uma função, a qual, se chamada milhares de vezes, atrapalharia o desempenho devido ao grande número de chamadas extras. Em vez disso, o compilador IBM procura oportunidades de usar essa integração, eliminando o excesso de prólogos e epílogos de função e permitindo movimento do código e outras otimizações, que poderiam não estar disponíveis sem a integração.

Otimização do Sistema/OS

O ambiente no qual o aplicativo é executado também pode ser usado para melhorar o seu desempenho. Vários aspectos do ambiente no z/OS podem ajudar a acelerar o carregamento de programas, procurando por bibliotecas e executando o programa em si.

LPA/DLPA

O Link Pack Area (e Dynamic LPA) é, em essência, uma área da memória dos sistemas z/OS na qual o programador do sistema pode carregar bibliotecas e módulos, para torná-los residentes na memória para todos os usuários. Isso aumenta bastante o desempenho dessas bibliotecas no carregamento e inicialização para todos os usuários do sistema. O administrador do sistema z/OS pode configurar isso para seu aplicativo.

Usando LPA e DLPA, as bibliotecas e módulos são eficazmente pré-carregadas para quem precisar usá-los. Normalmente, cada chamada para uma biblioteca ou módulo requer que o sistema os encontre e carregue, o que pode levar a muitas repetições para qualquer coisa usada comumente por um grande número de usuários ou aplicativos, de modo que o DLPA pode resultar em ganhos significativos de desempenho.

Programas que devem residir na LPA/DLPA devem ser compilados com a opção RENT do compilador para tornar o programa reentrante, se não o for naturalmente.

LLA/VLF

Junto com LPA/DLPA, é possível usar library lookaside (LLA) e virtual lookaside facility (VLF) para acelerar significativamente o desempenho geral no sistema.

Índices e tabelas usados comumente são armazenados e otimizados na memória, reduzindo bastante a atividade de E/S do OS, acelerando o sistema em geral.

Em suma, LLA e VLF são usados para acelerar a consulta de arquivos e conjuntos de dados em um sistema, enquanto LPA e DLPA são usados para acelerar o carregamento de bibliotecas e módulos em um sistema.

Quando LLA/VLF e LPA/DLPA são usados juntos, o processo de encontrar e carregar módulos e bibliotecas se torna bastante simplificado.

É possível ajustar várias opções do tempo de execução e testar o desempenho do aplicativo para tentar melhorá-lo. Por exemplo:

  • HEAP
  • STACK
  • STORAGE

O z/OS Language Environment Programming Guide (cujo link está na seção Recursos) contém informações de referência detalhadas sobre essas variáveis do tempo de execução. Também contém sugestões sobre quais variáveis usar, dependendo do tipo de aplicativo.

A maioria dessas opções do tempo de execução aumenta o desempenho sacrificando espaço de Dispositivo de Armazenamento de Acesso Direto (DASD), o que é desejável hoje em dia, pois espaço de armazenamento é relativamente barato.

Nota: DASD é o termo do z/OS para algo que é, basicamente, uma unidade de disco rígido.

Desempenho de E/S

O z/OS já é considerado topo de linha no que diz respeito a desempenho de E/S e rendimento de carga de trabalho. Isso não significa que não seja possível extrair mais desempenho das operações de E/S. O capítulo "I/O Performance Considerations" do z/OS XL C/C++ Programming Guide (cujo link está na seção Recursos) tem várias dicas sobre como otimizar operações de E/S em conjuntos de dados e arquivos USS/HFS (ou seja, UNIX) no z/OS. Observe que um número significativo dessas dicas é válido para C/C++ em geral (ou qualquer linguagem), não apenas para XL C/C++ para z/OS.

O z/OS oferece a você, como desenvolvedor, a capacidade de usar arquivos de memória. Trata-se de arquivos que residem na memória enquanto estão em uso, eliminando assim a necessidade de leitura e gravação mais lentas do armazenamento DASD. Arquivos de memória no z/OS são, de certa forma, equivalentes aos mapas de memória e mapas de memória compartilhados do AIX.

Arquivos de hiperespaço são outro tipo de arquivo de memória que pode ser usado. Eles residem em um tipo especial de memória que não usa o espaço de endereço de um aplicativo. Isso significa que é possível ter arquivos de memória muito grandes em aplicativos de 32 bits sem reduzir a quantidade de memória disponível para o programa. Observe que arquivos de hiperespaço não estão disponíveis em aplicativos de 64 bits.


O que você aprendeu

A migração de aplicativos C e C++ do AIX para o z/OS pode ser fácil, e, com ajustes cuidadosos, pode resultar em desempenho comparável capturando, ao mesmo tempo, os benefícios exclusivos do hardware e pilha de software z/OS.

Há alguns métodos para melhorar o desempenho do aplicativo no z/OS. Isso inclui melhorar o desempenho do aplicativo no carregamento, procura e execução, e reduzir o tempo e o volume de repetição das suas operações de E/S.

Recursos

Aprender

  • Obtenha ótimas informações na Biblioteca z/OS na Internet. Aprenda funcionalidades mais detalhadas com esses importantes manuais para desenvolvedores e programadores do z/OS:
    • z/OS C/C++ User’s Guide
    • z/OS C/C++ Programming Guide
    • z/OS C/C++ Language Reference
    • z/OS C/C++ Runtime Library Reference
    • z/OS Principles of Operations
    • z/OS Language Environment Programming Guide
  • Saiba mais sobre o z/OS:
  • Saiba mais sobre o AIX:
  • Saiba mais sobre outros aplicativos na Plataforma de Distribuição de Software IBM Rational, incluindo ferramentas de colaboração para desenvolvimento paralelo e equipes dispersas geograficamente, e mais software especializado para gerenciamento de arquitetura, de ativos, de mudanças e release, de requisitos integrados, de processo e portfólio e de qualidade. Manuais de produto, guias de instalação e outras documentações podem ser encontrados no Centro de Documentação On-line do IBM Rational.
  • Visite a área do software Rational no developerWorks para recursos técnicos e boas práticas de produtos Rational Software Delivery Platform.
  • Explore cursos on-line sobre Rational baseados em computador, na Web e conduzidos por instrutor. Aperfeiçoe suas habilidades e saiba mais sobre ferramentas Rational com esses cursos, que vão do introdutório ao avançado. Os cursos nesse catálogo estão disponíveis para compra para treinamento baseado em computador ou baseado na Web. Alguns dos cursos de "Introdução" estão disponíveis gratuitamente.
  • Assine a newsletter IBM developerWorks, uma atualização semanal sobre o melhor dos tutoriais, artigos, downloads, atividades comunitárias, webcasts e eventos do developerWorks.

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=516803
ArticleTitle=Como migrar do IBM AIX para IBM z/OS
publish-date=09032010