CICS

Language Environment® usa mais armazenamento de transações do que VS COBOL II. Isso é especialmente perceptível quando mais de uma unidade de execução (enclave) é usada, pois o armazenamento é gerenciado no nível da unidade de execução com LE. Isso significa que HEAP, STACK, ANYHEAP, etc., são alocados para cada unidade de execução sob LE. Com o VS COBOL II, o armazenamento em pilha (SRA) e heap é gerenciado no nível da transação. Além disso, há alguns blocos de controle de LE que precisam ser alocados

Para minimizar a quantidade abaixo do armazenamento de linha usado pelo LE em CICS®, você deve executar com ALL31(ON) e STACK (, ANYWHERE) o máximo possível. Para fazer isso, você precisa identificar todos os seus programas AMODE(24) COBOL que não são COBOL do OS/VS. Em seguida, você pode fazer as alterações de codificação necessárias para torná-las AMODE(31) ou pode editar o link de um CEEUOPT com ALL31(OFF e) e STACK(,,BELOW), conforme necessário para as unidades de execução que precisam disso. É possível descobrir quanto armazenamento uma transação específica está usando consultando os dados de rastreio auxiliar para essa transação. Você não precisa se preocupar com os programas OS/VS COBOL, pois as opções de tempo de execução LE não afetam os programas OS/VS COBOL em execução no CICS. Além disso, se a transação for definida com TASKDATALOC(ANY) e ALL31(ON ) estiver sendo usado e os programas forem compilados com DATA(31), então o LE não usará nenhum armazenamento abaixo da linha para a transação em CICS, resultando em alguma economia adicional de armazenamento abaixo da linha.

Há duas opções de SIT do CICS que podem ser usadas para reduzir a quantia de atividade GETMAIN e FREEMAIN, que ajudarão o tempo de resposta O primeiro é a opção RUWAPOOL SIT. É possível configurar RUWAPOOL como YES para reduzir a atividade de GETMAIN e FREEMAIN O segundo é a opção AUTODST SIT. Se você estiver usando o CICS Transaction Server versão 1 release 3 ou posterior, também poderá definir AUTODST como YES para fazer com que o Language Environment ajuste automaticamente o armazenamento para a região CICS. Isso deve resultar em menos solicitações GETMAIN e FREEMAIN na região CICS. Além disso, ao usar AUTODST=YES, também é possível usar o user exit do ajuste de armazenamento (consulte User exit do ajuste de armazenamento ) para modificar o comportamento padrão desse ajuste automático de armazenamento.

Para obter detalhes, consulte Usando Language Environment em CICS na personalização z/OS® Language Environment.

A opção do compilador RENT é necessária para um aplicativo em execução no CICS.. Além disso, se o programa for executado por meio do conversor ou coprocessador do CICS (ou seja, ele possui comandos EXEC CICS nele), ele também deverá usar a opção do compilador NODYNAM. CICS O Transaction Server 1.3 ou posterior é necessário para o Enterprise COBOL.

Para obter detalhes, consulte RENT no Enterprise COBOL for z/OS Guia de programação.

Enterprise COBOL suporta chamadas estáticas e dinâmicas para subprogramas Enterprise COBOL e VS COBOL II (com a opção RES) que contenham comandos ou dependências CICS. Observe que o Enterprise COBOL 4.2 e versões anteriores também suportam chamadas para VS COBOL II com a opção NORES. As chamadas estáticas são feitas com a instrução literal CALL e as chamadas dinâmicas com a instrução do identificador CALL. Converter EXEC CICS LINKs em COBOL CALLs pode melhorar o tempo de resposta das transações e reduzir o uso do armazenamento virtual. Enterprise COBOL não suporta chamadas para ou de programas OS/VS COBOL em um ambiente CICS. Nesse caso, deve-se usar EXEC CICS LINK.

Observação: Ao usar EXEC CICS LINK em Language Environment, uma nova unidade de execução (enclave) será criada para cada EXEC CICS LINK. Isso significa que novos blocos de controle serão alocados e subsequentemente liberados para cada LINKed para o programa. Isso resultará em um aumento no número de solicitações de armazenamento Se o ajuste de gerenciamento de armazenamento não tiver sido feito, você poderá ter mais solicitações por enclave. Como resultado da criação de um novo enclave para cada EXEC CICS LINK, o desempenho do tempo da CPU também será prejudicado quando comparado com VS COBOL II. Se o seu aplicativo usa muitos EXEC CICS LINKs, você pode evitar essa sobrecarga extra usando COBOL CALLs sempre que possível.

Se você estiver usando a instrução CALL COBOL para chamar um programa que foi traduzido com o tradutor CICS ou compilado com o coprocessador CICS, você deve passar DFHEIBLK e DFHCOMMAREA como os dois primeiros parâmetros na instrução CALL. No entanto, se você estiver chamando um programa que não foi convertido, não deverá passar DFHEIBLK e DFHCOMMAREA na instrução CALL. Além disso, se o subprograma chamado não usar nenhum dos comandos de tratamento de condições EXEC CICS, você pode usar a opção de tempo de execução CBLPSHPOP(OFF) para eliminar a sobrecarga de executar um EXEC CICS PUSH HANDLE e um EXEC CICS POP HANDLE, que é feito para cada chamada pelo tempo de execução LE. A configuração de CBLPSHPOP pode ser alterada dinamicamente usando a transação CLER

Contanto que seu uso de todos os itens de dados binários (COMP) no aplicativo esteja em conformidade com as especificações PICTURE e USAGE, é possível usar TRUNC (OPT) para melhorar o tempo de resposta da transação... Isso é recomendado em aplicativos CICS sensíveis ao desempenho Se o uso de qualquer item de dados binários não estiver em conformidade com as especificações PICTURE e USAGE, será possível usar um tipo de dados COMP-5 ou aumentar a precisão na cláusula PICTURE em vez de usar a opção do compilador TRUNC (BIN). Observe que o conversor CICS não gera código que causará truncamento e o coprocessador CICS usa tipos de dados COMP-5 que não causam truncamento. Se você estava usando NOTRUNC com seus programas OS/VS COBOL sem problemas, TRUNC(OPT) em IBM® Enterprise COBOL se comporta de maneira semelhante. Para obter informações adicionais sobre a opção do compilador TRUNC, consulte TRUNC no Guia de Programação do Enterprise COBOL for z/OS.