Minimizar RNI ambiente CICS por Milton Ferraraccio (Eccox Technology)

Ambiente CICS - Minimizar a
RNI (Relative Nest Intensity)
do IBM z Mainframe.
Milton Ferraraccio
Eccox Technology

2
Agenda
Proibida cópia ou divulgação sem
permissão escrita do CMG Brasil.
 Evolução dos Mainframes IBM z
 Performance dos Mainframes IBM z
 Memória cache dos Mainframes IBM z
 Conceitos da RNI - Relative Nest Intensity
 Conceitos do HiperDispatch
 Minimizando a RNI no Ambiente CICS
 Conclusão

3
Evolução dos Mainframes IBM z
Os processadores IBM z System cada vez estão mais complexos. A cada melhoria
na arquitetura, eles ganham mais circuitos lógicos para possibilitar o maior
rendimento das instruções.
Os processadores foram projetados para incluir todos os tipos de paralelismo e
otimização para executar instruções no menor número de ciclos possível.
A z10 executava até 3 Instruções no mesmo Cycle, a z196 aumentou para até 5,
a zEC12 para até 7, a z13 para até 10.
Na z14 continua sendo até 10, ou, no máximo 10, então porque é mais
“performante” que a z13?
Porque a z14, com mais Lines (6.1 billion transistors versus 3.99 billion on z13),
consegue terminar Instruções em Cycles em que a z13 não conseguia, portanto, o
maior paralelismo lhe dá maior Throughput!
0.77 1.2
1.7
4.4
5.2 5.5
5 5.2
0
1
2
3
4
5
6
7
Z900 Z990 Z9 Z10 Z196 ZEC12 Z13 Z14
z System GHz

4
Durante muito tempo, os aumentos na vazão do processador (MIPS)
estavam ligados ao aumento da velocidade do chip.
Começando com a z10, vemos uma divergência entre as mudanças de
velocidade do chip e as mudanças na vazão do processador.
Por exemplo, a z13 tem uma capacidade nominal 10% maior que uma
zEC12, embora sua velocidade do clock (GHz) tenha diminuído em quase 10%.
Em particular, na z13, a velocidade do chip diminuiu, mas o Throughput da
CPU ainda é maior do que a geração anterior.
A z13 faz mais devagar que a zEC12, entretanto, faz mais ‘coisas’ por vez!
A z13 e a z14 têm quase o dobro dos Circuitos da zEC12.
0.77 1.2
1.7
4.4
5.2 5.5
5 5.2
0
1
2
3
4
5
6
7
Z900 Z990 Z9 Z10 Z196 ZEC12 Z13 Z14
z System GHz
GHz
zEC12 x z13
GHz
zEC12 x z13

5
Crescimento do PCI - (Processor Capacity Index)
Com o aumento na Frequência (GHz), o processador tem menos tempo
para fazer suas funções em um único ciclo de clock. Quando se reduz a
Frequência, o Cycle Time é maior, portanto, é necessário fazer mais coisas
em paralelo para poder produzir mais.
Embora com o mesmo Cycle Time da z196, a z14 é 1850/1250=48% mais
capaz, devido à maior quantidade de circuitos em paralelo.
250
450
550
950
1,250
1,500
1,650
1,850
0.77
1.2
1.7
4.4
5.2
5.5
5
5.2
0
1
2
3
4
5
6
0
200
400
600
800
1,000
1,200
1,400
1,600
1,800
2,000
Z900 Z990 Z9 Z10 Z196 ZEC12 Z13 Z14
PCI e GHz
MIPS GHz
PCI GHz
GHz
zEC12 x z13
Mesmo
Cycle Time
z14 x z196
GHz
zEC12 x z13
Z14 48%
mais capaz
z14 x z196

6
Lei de Moore
Em 1965, o co-fundador da Intel, Gordon Moore, observou que "o
número de transistores por polegada quadrada dobra aproximadamente a
cada 12 meses". Ele foi posteriormente modificado para ser a cada 18
meses, em vez de cada 12.
Entretanto, esta é uma equação exponencial, por isso não pode
continuar indefinidamente. Se não estamos no final desse período,
estamos muito próximos.
O aumento da vazão dos processadores dos atuais Mainframes z está
chegando no limite físico (GHz), devido aos limites Técnicos (Lei de
Moore), Refrigeração e ao Custo.
Este obstáculo (limite físico GHz), a Física explica: É que, para ser
mais “rápido”, são necessários mais circuitos, e cada vez menores,
portanto, estamos no limite da nossa capacidade de remover o calor
gerado, em áreas/volumes cada vez menores!
Nada impede que tenhamos um Oscilador de 16, 32, 64GHz, mas
como nos “livramos” do “baita” calor que será gerado nos Chips?!?

7
Então por que devemos nos preocupar com a Performance?
No passado, a vazão ou desempenho de um Mainframe era medido em
milhões de instruções por segundo (MIPS). No entanto, MIPS já não é muito
usado para medir o uso de CPU.
Muitos apelidaram o MIPS como: "Misleading Indicator of Processing
Speed! ".
Segundos de CPU ainda é frequentemente usado para medir
performance.
Todos os mainframes possuem instruções simples e complexas. Um
programa de 5 milhões de instruções complexas leva muito mais tempo do
que um programa de 5 milhões de instruções simples. As instruções
complexas gastam mais ciclos de CPU.
Antes da z10 era lógico, prático e fácil fazer Análise de Performance e
Planejamento de Capacidade.
Sem
preocupação,
tudo sob
controle
Performance dos Mainframes IBM z

Para contornar a limitação de (GHz) dos processadores e aumentar
seu desempenho foram criados níveis de cache de memória em todos os
books(agora drawers).
Os níveis de cache de memória foram projetados da seguinte maneira
em cada drawer:
 Cache L1 dentro da própria PU/core
 Cache L2 encostado na L1
 Cache L3 distante do processador
 Cache L4 o mais distante do processador e mais próximo da
Memória
8
A cada novo lançamento de Mainframe IBM z, as camadas de memória
cache são melhor dimensionadas e as Tecnologias de interconexão entre
todos os books(agora drawers) são otimizadas.
Xi!
começou,
a enrolar

Com esta nova forma do processador ter que acessar os dados nos níveis de
cache de memória dos drawers, o processador poderá ficar mais tempo ocupado
(busy) dependendo de onde estejam os dados.
Exemplo:
Se os dados estão em uma mesma drawer, podemos ter a seguinte
situação:
1. O overhead de ir buscar os dados no cache L2 em relação a encontrar
os dados no cache L1 é pequena;
2. Mas o overhead de ir buscar os dados no cache L4 em relação a
encontrar os dados no cache L1 é bem maior.
Se os dados estiverem em diferentes drawers, o overhead será muito
maior.
À medida que a vazão dos processadores (GHz) aumenta, o número de
ciclos que o processador deve esperar para obter informações dos dados da
memória ou em cache não local aumenta.
A espera indica que a PU está busy e não pode ir adiante enquanto não
vier a ‘resposta’ do Cache L1, o que significa que um workload pode sofrer
aumentos de tempo de CPU e Resposta devido à busca de dados nos caches.
Opa!
Começou a
complicar

10
Em diversos estudos, os ciclos improdutivos gastos para armazenar
dados no cache L1 normalmente representam entre 33% a 50% da CPU geral,
ficando muito mais difícil fazer Planejamento de Capacidade e Análise de
Performance prevendo o futuro.
Em um momento a LPAR está com ótimo desempenho, e do nada, no
momento seguinte a LPAR está com péssimo desempenho enfileirando
diversos workloads.
O maior problema é descobrir como medir a localidade de referência da
memória e dos cache.
E agora? Como iremos saber o comportamento da LPAR?
1. Com a introdução de um novo termo RNI - Relative Nest Intensity
podemos medir nos workloads o nível de atividade dessa parte da
hierarquia de memória, isto é, o consumo dos ciclos improdutivos.
2. Com um novo modo de dispatch chamado HiperDispatch (HD) que busca
de reduzir a RNI. (vistos adiante)

11
Então por que devemos nos preocupar com a Performance?
Após a z10, com a introdução desta nova técnica, do processador ter
que acessar os dados nos níveis de cache de memória dos drawers, ficou
mais complexo, trabalhoso e díficil fazer Análise de Performance e
Planejamento de Capacidade.
O fator RNI sempre existiu, mas sua sensibilidade é maior com os
processadores de alta frequência (GHz).
Para diminuir os ciclos improdutivos gastos para armazenar dados no
cache L1 devemos Fazer Performance Tuning do modo = “Antigo”.
Éramos
felizes e não
sabíamos
Garimpar os Softwares

12
O custo da inovação ..........

13
Comparação das tecnologias de interconexão book/drawer para os
processadores z.
Os caches L1 e L2 estão mais próximos do processador acesso mais rápido;
Os caches L3 e L4 estão mais longe do processador acesso mais lento.
Os caches L1 e L1.5 estão mais próximos do processador acesso mais rápido;
O cache L2 está mais longe do processador acesso mais lento.
Memória cache dos Mainframes IBM z

14
processadores z.

15
 z14 (3906)
CPU
5.2 GHz (1832 PCI*)
Cache
L1 private 128k i, 128k d
L2 private 2 MB i, 4 MB d
L3 shared 128 MB / chip
L4 shared 672 MB / drawer
*PCI = Processor Capacity Index
processadores z.

Exemplo na z13 e z14 do Design que impulsiona o desempenho
16
Na z13 o caminho de acesso aos caches é mais sinuoso e complexo.
Na z14 o caminho de acesso aos caches foi melhorado.

17
A cada nova geração dos mainframes IBM z os tamanhos dos caches
estão aumentando.
Porém os tamanhos para instruções e dados do cache L1, o mais importante
ainda são pequenos.
Os maiores aumentos foram nos caches L3 e L4 que estão mais distantes do
cache L1. Isto melhora um pouco a RNI do workload.
Uma
calculadora
HP tem mais
memória.
Para poder rodar a 5,5GHz,
a zEC12 teve que reduzir
seu cache L1 de Dados

18
A área mais sensível ao desempenho da hierarquia de memória é a
atividade para o memory Nest, ou seja, a distribuição de atividade para os
caches compartilhados e a memória.
A Introdução do conceito “Relative Nest Intensity (RNI)”, é para indicar
o nível de atividade dessa parte da hierarquia de memória.
Quanto maior o valor da RNI, mais profunda será a hierarquia de
memória que o processador deve percorrer para recuperar as instruções e os
dados de um workload.
Conceitos da RNI - Relative Nest Intensity
 z14 (3906)
CPU
5.2 GHz (1832 PCI*)
Cache
L1 private 128k i, 128k d
L2 private 2 MB i, 4 MB d
L3 shared 128 MB / chip
L4 shared 672 MB / drawer
*PCI = Processor Capacity Index

19
Muitos fatores influenciam o desempenho de um workload. No entanto,
na maior parte, o que esses fatores estão influenciando é a RNI do workload.
Os fatores tradicionais usados para categorizar os workloads são
listados junto com a tendência de RNI.
O conjunto de todos esses fatores resultam em um valor da RNI para o
workload, afetando diretamente o seu desempenho.
A utilização do HIPERDISPATCH=YES, ajuda a reduzir a RNI do workload.
Reduzir a RNI melhora a eficiência do processador.

20
Calculando o valor da RNI para a z13 e z14
A fórmula para a z13 é:
z13 RNI=2.3x(0.4xL3P+1.6xL4LP+3.5xL4RP+7.5xMEMP)/100
A fórmula para a z14 é:
z14 RNI=2.4x(0.4xL3P+1.5xL4LP+3.2xL4RP+7.0xMEMP)/100
OBS.: A fórmula da RNI é diferente para cada modelo de processador de
mainframe.
Com o valor calculado podemos categorizar os workloads, sendo:
Categorizando um workload
L1MP - Significa misses no L1 por 100 instruções.
Legal!
Muito fáceis
estes
cálculos.

21
Como medir a RNI?
Selecionando registros do SMF e elaborando relatórios, sendo:
1. Relatórios do RMF
 SMF Type 70 - Descreve as LPARs.
 Pesos e Definições do Processador Lógico.
 Hiperdispatch: Parking e Unparking.
 SMF Type 72 - Descreve os Workloads.
 Inclui as proporções de CPU usadas por cada Service Class.
 SMF Type 74-2 - XCF Tráfico entre DB2 IRLMs, MQ, CICS Regions.
 Informações sobre Datasharing e Queue Sharing groups.
2. Relatórios do Tivoli Decision Support (TDS) ou outro programa
 SMF 30 - Address Space descreve o uso dos recursos.
 CICS regions, DB2 subsystems, MQ queue managers, Batch, etc.

22
Como medir a RNI?
3. Relatórios da CPU Measurement Facility (CPU MF).
 SMF 113 - Hardware Instrumentation Services (HIS),que fornece
a melhor seleção do LSPR workload, para calcular a RNI do
workload.
Dados de planejamento
de capacidade
Categoria do
LSPR Workload

23
RMF - Exemplo de relatório por Processor Types

24
CPU MF - Exemplo de relatório Report - # 0

25
Conceitos do HiperDispatch
Em busca de reduzir a RNI, um novo modo de dispatch chamado
HiperDispatch (HD) fornece eficiências de processamento adicionais.
O HD foi introduzido em 2008 com processadores z10, mas desempenha
um papel ainda mais importante nos modelos z13 e z14, onde o desempenho
do cache tem um impacto tão grande.
Os modelos recentes dos processadores IBM z System dependem muito
dos níveis dos cache para alimentar o pipeline de instruções.
Para remediar a situação, o Mainframe explorou a ideia de polarização
vertical, que visa manter as LPARs no mesmo processador físico e gastar
menos tempo carregando e limpando o cache.
Com o HiperDispatch, a intenção é alinhar o trabalho a um subconjunto
menor de processadores, a fim de maximizar os benefícios das estruturas
de cache do processador e, assim, reduzir o tempo de CPU necessário para
executar o trabalho.

26
Dispatching: z/OS e PR/SM com HIPERDISPATCH=NO/YES
As características do HIPERDISPATCH

27
Quando o HiperDispatch está ativado, o PR/SM e z/OS dispatchers
interface interagem para estabelecer afinidades entre units of work e
logical CPs e entre logical CPs e physical CPs.
O peso da LPAR define a importância relativa de uma partição e o
compartilhamento de CPU quando um processador fica ocupado (busy).
Isso é importante porque:
1. Aumenta a probabilidade das units of work serem reenviadas de
volta no mesmo logical CP e executando no mesmo physical CP (ou
próximo).
2. Otimiza a eficácia do cache do processador em todos os níveis,
reduzindo a frequência de cache misses do processador e
reduzindo a distância (no Nest) necessária para buscar dados.
Dispatching: z/OS e PR/SM com HIPERDISPATCH=YES

Em geral, o PR/SM atribui a polaridade vertical com base no peso e no
número de logical CPs e physical CPs de uma LPAR.
Os logical CPs para uma LPAR com HiperDispatch se encaixarão em uma das
seguintes categorias:
• Vertical High (VH) – PR/SM quasi-dedicates Logical CPs para Physical CPs;
(Logical CPs poderá receber até 100% de compartilhamento de um
Physical CP).
• Vertical Medium (VM) - Physical CPs que podem ser compartilhados entre
LPARs;
(O PR/SM reserva pelo menos 50% de compartilhamento de Physical CP).
• Vertical Low (VL) - CPs são parked, até que sejam necessários.
(< 50% de compartilhamento de Physical CP)
Ei!
O que estão
fazendo com
os processadores?Atribuições logical CPs verticais
Aonde
fomos amarrar
nosso BURRO?

29
O PR/SM atribui logical CPs como VH/VM/VL com base nos pesos da LPAR
e no número de physical CPs.
Metodologia para atribuições dos logical CPs Share como: VHs, VMs, e VLs
para cada LPAR, utilizam as seguintes fórmulas:
• % Share = LPAR Weight / Sum of LPAR Weights.
• CP Share = % Share * Physical CPs.
Se o resultado do valor do CP Share for:
 Acima de 100  O(s) logical CPs Share serão atribuídos como VHs
 Entre >50 e <100  O(s) logical CPs Share serão atribuídos como VMs
 Abaixo de 50  O(s) logical CPs Share serão atribuídos como VLs
Atribuições logical CPs verticais

30
Questão: Em que situação estes tipos de processadores irão “acordar” para
trabalhar?
Resposta:
 Ficam Unpark quando:
 CP: MVS busy > 95%
 zIIP > 80%
 Ficam Park se ocorrer qualquer uma das seguintes situações:
 CP: MVS busy < 85%
 zIIP < 66%
Unpark ou Park Vertical Low Processors

31
Maximizando o trabalho em VHs - LPAR Pesos
 Aumentar os pesos para LPARs com alto uso de CPU;
 Personalizar pesos para maximizar a atribuição de VHs;
 Personalizar pesos por turno para refletir as alterações no workload;
 Configurar poucas e maiores Partições Lógicas.
OBSERVAÇÃO: Para LPAR com pouco Peso (Weight) não use HIPERDISPATCH=YES,
pois dificilmente esta LPAR irá conseguir “ganhar” um Physical CP.
Com pequenos ajustes nos pesos das LPARs podemos aumentar o trabalho
executando em VHs (e assim reduzir a RNI). Veja exemplos.

32
Exemplo 01 - Maximizando o trabalho em VHs - LPAR Pesos
Com o aumento de 1% na %Shr, conseguimos transformar:
1 Logical CP VMs para 1 Logical CP VHs
aumentando o desempenho da LPAR e diminuindo a RNI.

33
Exemplo 02 - Maximizando o trabalho em VHs - LPAR Pesos
Configurações de peso de LPAR “comuns” podem resultar em 0 Logical CP VHs.
Antes
Depois
Com pequenas alterações de peso, 33% do workload pode ser executado
em 2 Logical CP VHs.

O desempenho nos processadores está cada vez mais dependente da
utilização efetiva dos caches do processador, pois o conjunto de instruções
e de dados de cada address space aumenta a concorrência pelos caches do
processador.
Para minimizar a RNI do Ambiente CICS devemos fazer um
ajuste fino (tuning) nos parâmetros e nas aplicações do CICS visando
diminuir os ciclos improdutivos gastos para armazenar dados no cache L1.
34
Minimizando a RNI no Ambiente CICS
A seguir exemplos de alguns ajustes finos (tuning) que podemos fazer
no CICS.
Por que fazer um ajuste fino (tuning) ?
O que é fazer um ajuste fino ?
Cada CICS em execução é diferente de outros CICS, sendo em seus:
Objetivos, Workloads, Conexões, Acessos ao (DB2,MQ,IMS), etc....
Portanto, os parâmetros definidos não devem ser iguais para todos os
CICS. (Normalmente o que ocorre entre os CICS é uma cópia dos parâmetros,
salvo em algumas definições especificas).
Então, fazer um ajuste fino é analisar e adequar os parâmetros
definidos para cada CICS, principalmente os parâmetros de tuning.
Então
Suporte CICS
ao trabalho

35
Alguns exemplos dos ajustes finos (tuning) que podemos fazer no CICS:
1. Se possível, reduzir a quantidade de CICS (CICS AORs) diminuindo a RNI.
 Menos address space para serem gerenciados.
2. Transações que utilizam FS - FUNCTION SHIPPING.
 Alterar o comando de:
EXEC CICS START CHECK (default) para EXEC CICS START NOCHECK
diminui a “conversa” com o z/OS Communication Server.
Metodologia que foi utilizada:
Em 5 amostras foram executadas 1000 Transações por amostra.
Os seguintes resultados foram obtidos:
1. O ganho no uso de CPU foi em média de 7,5%;
2. O ganho no Tempo de Resposta foi em média de 9,25%.
3. Definir os programas de aplicação CICS com o atributo CONCURRENCY(REQUIRED)
 Diminui o switch TCB (cada switch 2.000 instruções), diminuindo o uso de
CPU do CICS.
4. Desativar o Internal Trace do CICS.
 Diminui o uso de CPU (entre 5% a 12%) para cada CICS.

36
5. Colocar a Temporary Storage (TS) em Memória (TS MAIN).
 Elimina os I/O’s;
 Diminui o Tempo de Resposta das transações, eliminando as contenções
(Waits) no arquivo VSAM.
6. Nos programas de aplicação eliminar os Comandos:
ENTER FROM TRACEID, ENTER TRACENUM e outros comandos de TRACE...
 Diminui as instruções executadas e o Internal Trace pode ser desligado.
7. Alterar nas Transações SOCKET os parâmetros (default):
de TRACE=YES e OTE=NO para TRACE=NO e OTE=YES
 Diminui o switch TCB, e as instruções do TRACE, resultando em menor
uso de CPU e menor Tempo de Resposta das transações.
8. Definir no parâmetro MXT, dependendo do workload, um valor ideal para
cada CICS.
Existe um Performance Block (PB) por MXT, que são varridos de tempos
em tempos pelo WLM, sendo:
o A cada 250 ms para controles de transação (Goal Mode)
o A cada 2,5 segundos para controles de região (Velocity)
 Atribuição excessiva MXT no parâmetro MXT pode resultar em alto uso
da CPU.

37
9. Alterar o parâmetro ICVR=5000 ms (default) para ICVR=2000 ms ou menor.
 Controla as transações em Loop;
 Com a tecnologia atual 5 segundos é muito tempo.
10. Alterar na definição dos programas o parâmetro DATALOCATION(BELOW)
(default) para DATALOCATION(ANY).
 Eliminando a necessidade de que os dados sejam copiados abaixo da linha
de 16 MB antes de passar seu endereço para o programa aplicativo.
 Diminui a quantidade de instruções executadas.
11. Alterar na definição das transações o parâmetro TASKDATALOC(BELOW)
(default) para TASKDATALOC(ANY).
• Diminuindo a possibilidade de ocorrer o SOS (Short-on-Storage) no CICS
abaixo da linha de 16MB.
12. Alterar as conexões APPC, MRO e LUTYPE6.1 para conexões IPIC.
• Exploração de conectividade OSA de alta largura de banda (QDIO).
• Menor uso total da CPU.
13. Utilizar o COBOL V6.x nas aplicações CICS.
• Otimiza os Programas COBOL com uso intensivo de campos decimais e de
ponto flutuante, reduzindo o uso total da CPU.

38
14. Alterar o parâmetro MROLRM=NO (default) para MROLRM=YES.
 Transações que utilizam FS - FUNCTION SHIPPING permanece anexada à
sessão MRO até a transação emitir um syncpoint;
 Elimina o overhead de alocar e desalocar para cada FS.
15. Alterar o parâmetro MROFSE=NO (default) para MROFSE=YES.
 A mirror task permanece disponível até o final da tarefa do aplicativo;
 Elimina o overhead de reconectar a mirror task após um syncpoint do
usuário.
OBS. Não especifique esse valor na região front-end (TOR).
16. Evitar condições de Limitações no CICS, como:
 Max Tasks, Class Max Tasks, TCBs, Threads, Buffers, VSAM, SOS e outros;
 Eliminando delay e limite do desempenho;
OBS. Selecionar do SMF os registros de estatística 110(2) do CICS para
acompanhar os limites atingidos.
17. Definir como CICS User Data Table os arquivos VSAM e/ou CICS Data Table que
são utilizados como área de trabalho.
• Após a CICS User Data Table ser carregada, todos os I/Os em disco são
eliminados para todas as operações da tabela diminuindo o uso de CPU.

39
Segundo o Manual LSPR SC28-1187-20:
Processor #CP PCI MSU Low Avg High AVG%
3906-701 1 1832 227 3.37 3.27 3.04
2817-701 1 1202 150 2.14 2.15 2.06
%Throughput: 52,4 51,3 57,5 52,1 47,6 52,2
Comparando uma PU da z14 com uma PU da z196:
#1=PCI [‘vulgo MIPS’] aumentou 52,4%
#2=M$U aumentou 51,3% [desconta 1% em M$U/h]
#3=Para Cargas “Boas”, aumentou 57,5% [são 10% “Melhores” do que os “Médios”]
#4=Para Cargas “Médias”, aumentou 52,1%
#5=Para Cargas “Ruins”, aumentou 47,6% só! [são 17% “Piores” do que os “Bons”]
#6=A “Média Geral dos Ganhos” é 52,2% [=Avg]
Conclusões:
#1=De Setembro/2.010 até Setembro/2.017, a Tecnologia de Mainframes ‘melhorou’52,2%.
#2=A comparação de RNI Low, Avg e High é em relação à PU z9-701: a Tecnologia “dobrou” a
capacidade na PU z196 e “triplicou” na z14.
#3=A IBM ‘trunca=arredonda para baixo’, para que o fator M$U/h seja um pouco menor que o fator
PCI [chamamos de “Generosity Factor”].
#4=A Tecnologia faz com que Programas:
 “Bons”, de baixa RNI, melhorem mais;
 “Médios”, de média RNI, melhorem na média;
 “Ruins”, de alta RNI, melhorem menos: são os ‘Cache UnFriendly’, os mal feitos e os
que não seguem as recomendações de otimização. . .
Conclusão
Portanto,
Vamos otimizar
os Programas,
gente!!!

Minimizar RNI ambiente CICS por Milton Ferraraccio (Eccox Technology)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Minimizar RNI ambiente CICS por Milton Ferraraccio (Eccox Technology)

Semelhante a Minimizar RNI ambiente CICS por Milton Ferraraccio (Eccox Technology) (20)

Mais de Joao Galdino Mello de Souza

Mais de Joao Galdino Mello de Souza (20)

Minimizar RNI ambiente CICS por Milton Ferraraccio (Eccox Technology)