APRESENTAÇÃO A Sun Software Comércio e Representações Ltda, cujo foco principal, ao longo dos 20 anos de atuação no mercado brasileiro, tem sido à busca de soluções para os principais problemas enfrentados pelos nossos clientes em particular e pelo mercado em geral. Um problema que tem, de forma crescente, preocupado os usuários de sistemas Mainframe é a redução da janela batch, problema este que tende, em função de diversos motivos, explicados ao longo deste trabalho, a se tornar cada vez mais crítico. A Sun Software ciente disto procurou, ao longo de vários meses, uma solução que melhor se adequasse e que menos impactasse o ambiente dos nossos clientes. Firmamos então uma parceria técnica e comercial com a empresa norte americana ATRI, que possui também uma larga experiência na resolução de problemas do ambiente mainframe, especialmente nos serviços de diminuição de janela batch de empresas com os mais variados tipos de atividade. A ATRI - Advanced Technological Research, Inc. está sediada no estado de Ohio. Desde 1980, quando tomou como principal desafio à diminuição da janela batch na área de TI, vem aperfeiçoando continuadamente este serviço, que tem sido prestado a várias empresas em todo o mundo nos mais diversos ramos da indústria. Para atingir o desafio de diminuir a janela batch, a ATRI criou, em 1994, uma metodologia de análise chamada BAS Batch Analysis Service, desenvolvendo para isso uma ferramenta denominada IBSAT Interactive Batch Systems Analysis Tool. Juntas, a Sun Software e a ATRI, disponibilizam ao mercado brasileiro o serviço de Batch Analysis System BAS. Temos certeza que o BAS será de muita utilidade para as empresas que possuem sistema operacional MVS / z-os, com problemas de dimensionamento na carga da janela batch. Atualmente, devido ao grande crescimento dos sistemas de aplicações online e demanda por disponibilidade, as empresas vêem suas janelas batches praticamente todas ocupadas e muitas vezes os sistemas de aplicações online entram no ar ou fora do horário especificado (SLA) e/ou sem alguns arquivos, o que faz com que determinadas aplicações online fiquem sem funcionar até que estes arquivos sejam totalmente processados no ambiente batch, para posteriormente ingressarem no ambiente online. Uma outra decorrência da janela batch estar praticamente toda ocupada é que se houver a necessidade de algum reprocessamento, certamente isto causará um atraso na entrada do sistema online. 2
A prática tem mostrado ser muito difícil e demorada, e com baixo grau de sucesso, a tentativa de se reduzir à janela batch pelos meios tradicionais, que as empresas até agora dispunham. Nesta apresentação, a Sun Software mostrará que o seu novo serviço: o BAS Batch Analysis Service o qual, já comprovado no mundo inteiro, ajudará efetivamente as empresas a reduzir suas janelas batches de uma forma rápida, automática, segura e com um significativo retorno financeiro. É mais uma contribuição da Sun Software ao mercado nacional, visando à economia e a competitividade das empresas. José Curcelli Presidente 3
Índice Geral O conceito de Otimização da Janela Batch...5 O que é o BAS?...6 As Fases do BAS...7 Principais benefícios...8 Ganhos de Desempenho por tipo de atividade...9 Lista dos principais clientes... 10 O que faz?... 11 Como faz?... 12 Principais etapas a serem executadas e o tempo de duração do processo BAS... 13 A análise dos dados... 14 Resultados fornecidos e processos de implementação... 20 Dados Coletados... 21 Exemplos de recomendações gerais... 22 Exemplos de problemas e soluções:... 26 Exemplo de um caso prático:... 33 Exemplo de roteiro para análise dos processos... 34 O Conceito Faturável:... 35 BAS - Pré-cotação Checklist de Informações... 36 4
O conceito de Otimização da Janela Batch Cada vez mais, a utilização do mainframe vem aumentando devida não só ao aumento dos volumes de dados, como também a oferta de novos serviços ao mercado. Os CIOS muitas vezes não têm outra saída a não ser o aumento da capacidade de seus computadores, o que normalmente é muito custoso. Certamente estes CIOs gostariam de absorver estes aumentos de serviços e estender a vida dos atuais equipamentos, adiando a contratação de upgrades de hardware e software. O Batch Analysis Service BAS, vem atender justamente esta necessidade, além de sanar as dificuldades operacionais, desperdício do uso de recursos e aumentar o throughput do batch. O Batch Analysis Service BAS é uma solução rápida e eficiente que atenderá as necessidades urgentes de redução da janela batch. 5
BAS - Batch Analysis Service O que é o BAS? O Batch Analysis Service-BAS é uma metodologia de análise desenvolvida pela ATRI e implementada em parceria com a Sun Software, que permite uma análise dos processos batch através de um extenso exame desses processos (JOBs) em execução no sistema operacional MVS do Mainframe, oferecendo recomendações que permitem a redução dos tempos de execução das janelas batch, o que implica em economia e posterga a necessidade de upgrades em equipamentos e software. O Batch Analysis Service BAS é uma metodologia que utiliza alta tecnologia, pessoal especializado e um grau muito elevado de automação na fase de coleta de dados, exigindo pouquíssima participação dos profissionais da empresa cliente. E como resultado, o BAS fornece recomendações específicas, em várias áreas, as quais, quando aplicadas, trarão benefícios que não somente reduzirão o tempo de ocupação da janela batch como cumprimento dos SLA batches. 6
As Fases do BAS 1. LEVANTAMENTO DA SITUAÇÃO E DETERMINAÇÃO DO ESCOPO DO TRABALHO Nesta fase inicial, a Sun Software e o cliente levantam toda a situação da janela batch e o cliente escolhe as aplicações que serão processadas e o cliente também determina qual será o Escopo deste trabalho. 2. INSTALAÇÃO Nesta fase a Sun Software instala os programas que coletam os dados para o BAS. 3. COLETA Conforme decidido no item 1, o BAS pode fazer a coleta: dos fluxos, dos System Image ou de todo o Data Center. Esta coleta é feita de forma automática sem praticamente nenhuma participação do cliente. As informações coletadas são enviadas a Sun Software e a ATRI para análise e formulação das recomendações, que serão exemplificadas neste trabalho. 4. ANÁLISE Esta fase analisará os dados coletados e definirá as recomendações que deverão ser implementadas para melhorar o desempenho das aplicações escolhidas no escopo. É nesta fase, que se aplica toda a tecnologia e a experiência dos especialistas que a Sun Software dispõe para o serviço BAS. Toda a analise será efetuada fora da instalação do cliente. 5. RESULTADOS Terminada a análise, a Sun Software apresentará ao cliente, os resultados obtidos na fase anterior. Este resultado consiste de 4 documentos a saber: Fluxo da aplicação antes da análise Fluxo da aplicação após a análise Gráfico PERT/CPM mostrando o caminho crítico dos JOBs que compõem o sistema de aplicação RECOMENDAÇÕES, ou seja, as alterações que o cliente deverá executar no sistema de aplicação para obter a redução do tempo sala deste sistema. Estas RECOMENDAÇÕES são, na prática, os resultados do BAS. Também, serão fornecidos, em meio eletrônico todos os documentos acima. 6. IMPLEMENTAÇÃO O cliente analisará as recomendações produzidas pelo BAS e decidirá quais RECOMENDAÇÕES serão implementadas, e se as implementará com recursos próprios, pela Sun Software por terceiros. Nesta fase, o cliente decidirá quais recomendações desejará implementar, podendo fazêlo com seus próprios recursos ou contratando terceiros. A Sun Software está plenamente capacitada e certificada para implementar estas recomendações. 7
Principais benefícios Definição das prioridades: onde e como atacar os principais problemas da janela batch. Economia de tempo: minimiza o envolvimento dos recursos humanos da estrutura de TI do Cliente. Redução dos custos: um rápido retorno do ROI e capacidade de atender mais facilmente aos acordos de SLA. Foco: ênfase na redução dos caminhos críticos dos fluxos das janelas batch. Recomendações detalhadas possibilitam aos técnicos focar seus esforços nas mudanças necessárias para a redução do ciclo batch. 8
Ganhos de Desempenho por tipo de atividade Tipo Projeto Recomendações Ganhos Mudança na Schedulagem; Aumento 3 System Image do paralelismo; Bufferização no IMS; 35% diário Manufatura diários e mensais, Eliminação dos Wait e dos Initiators e 26% mensal DB2 & ADABAS Redução dos Blocksizes Transporte Banco Financeiro Seguros Financeiro Banco Financeiro 1 System Image - diários e mensais DB2 & SAS Ciclos de Aplicação HOGAN ciclos de 11 dias Duas aplicações - ciclo diário Três aplicações ciclo diário; DB2, CICS & IMS System Image ciclo diário; Datacom, DB2 e IDMS Três aplicações ciclos diários e mensais 3 System Images diário, mensal e trimestral Mudanças no Schedule; Aumento do paralelismo; Bufferização nos VSAM; Uso do BSLR e Fitas para Disco Mudanças no Schedule; Aumento do paralelismo; Eliminação de Wait entre os JOBs e Controle das modificações de migração Mudanças no Schedule; Mudanças no JCL e Bufferização nos arquivos VSAM Mudanças no Schedule; Ajuste no Buffer Pool do IMS; Bufferização dos arquivos VSAM; Redução das montagens de fitas e Mudanças nos processos Mudanças no JCL e no Schedule; Bufferização nos arquivos VSAM e Redução dos Blocksizes de grandes arquivos seqüenciais em DASD Mudanças no Schedule; Mudanças nos processos; Bufferização de Arquivos; Eliminação de Waits e Reestruturação de JOB Mudanças no Schedule; Arquivos em Fitas passar para Discos; Bufferização dos arquivos VSAM e Ajuste nos parâmetros do Sort 53% diário 24% mensal 34% diário 39% diário 20% diário 28% diário 48% diário 65% mensal 31% diário 29% mensal 30% trimestral 9
Lista dos principais clientes BANCOS E FINANÇAS MELLON BANK AMERICAN EXPRESS FINANCIAL CORP. BANK OF NEW YORK NATIONAL CITY CORPORTATION NORWEST BANK ING NORTH AMERICA VISA INTERNATIONAL CHARLES SCHWAB & COMPANY NORTHERN TRUST THE VANGUARD GROUP MERCHANTILE BANK PHEAA BB&T BANCO BRADESCO FIRST CITIZENS BANK SCOTIABANK DISCOVER CARD TELECOMUNICAÇÕES SBC BELL SOUTH PACIFIC BELL CONVERGYS GOVERNO STATE OF MINNESOTA FRANCHISE TAX BOARD STATE OF CA SAÚDE CLEVELAND CLINIC FOUNDATION HUMANA, INC. SEGUROS AETNA INC HIGH MARK ANTARES STATE FARM INSURANCE COMPANIES TIG BLUE CROSS/BLUE SHIELD OF ALABAMA DELTANET BLUE CROSS/BLUE SHIELD OF MINNESOTA CHUBB & SON, INC. INDÚSTRIA DOW CHEMICAL RELIANCE ELECTRIC NEWELL / RUBBERMAID LABORATORY CORPORATION ARROW ELECTRONICS NISSAN NORTH AMERICA VAREJO (THE) GAP, INC. SUPERVALU DAYTON HUDSON (TARGET STORES) SERVIÇOS ACXIOM / MAY & SPEH TSYS TRANSPORTES NORTHWEST AIRLINES 10
O que faz? Através da ferramenta de análise Interactive Batch System Analysis Tool IBSAT, o BAS descobre as maneiras de melhorar o desempenho nos caminhos críticos dos processos executados na janela batch. A ferramenta identifica problemas e recomenda modificações específicas indicando, para cada uma delas, o ganho percentual na redução do tempo de execução do ciclo batch. Desta forma, a janela batch alcançará o maior desempenho no menor tempo possível. O processo de análise dar-se-à sobre três escopos diferentes: - Batch Flow: sobre uma única aplicação, onde se define o nome do JOB de início e de um ou mais JOBs de término do fluxo. - System Image: escopo que permite o empacotamento de múltiplos Batch Flow. - Data Center: escopo que analisa todo o serviço batch em todos os System Image. O IBSAT constrói um mapa PERT do ciclo batch, incluindo os tempos de cada tarefa (task), identificando os caminhos críticos. Cada etapa (step) do processo IBSAT aponta para os pontos de conclusão das aplicações que são examinadas em detalhe, determinando, desta forma, as ações que reduzirão o tempo do caminho crítico. As melhorias geradas sobre os caminhos críticos são modeladas no mapa PERT, permitindo, que o efeito resultante possa ser previsto com exatidão. O BAS auxiliará nos seguintes aspectos: Redução da janela batch Diminuição do elapsed time dos caminhos críticos das aplicações Prevenção do efeito das cargas batch combinadas entre si Documentação do sistema batch Melhoria e simplificação da gestão e controle operacional do ambiente batch Prevenção do efeito de novos hardwares no processo batch 11
Como faz? O Processo de Análise Com o objetivo de minimizar o impacto nas rotinas de TI do Cliente, todo o trabalho de análise é feito fora das instalações do Cliente. A Sun Software instala no Mainframe do Cliente o IBSAT Data Collector, que é o responsável pela coleta das informações. As principais fontes para esta análise são os dados do SMF. O Data Collector organiza os dados do SMF em construções logicamente conectadas, que permitem associações de JOBs batch com data sets e os devices que suportam estes data sets. Para cada JOB batch são linkadas estatísticas como os dados RMF e informações de tape mount, permitindo o isolamento rápido de recursos críticos usados por processo batch, e identificando as dependências dos JOBs BASeados no uso de datasets. Esse processo permite a validação de critérios de scheduling de processo batch e também identifica qualquer oportunidade de melhoria na estrutura do fluxo de processos batch. Podem ser identificadas dependências, mesmo se o sistema batch é executado em múltiplos System Images. Para isolar os pontos de interface do fluxo batch, são identificados todos os datasets transferidos entre os fluxos. 12
Principais etapas a serem executadas e o tempo de duração do processo BAS Definição das necessidades e os problemas a serem endereçados. Coleta de Dados: duração de 4 a 6 horas Trabalho de análise: realizado off-site Entrega e apresentação dos relatórios preliminares: revisão das recomendações sugeridas Entrega e apresentação dos relatórios finais Início de implementação Tempo Total: máximo de 6 semanas 13
A análise dos dados O IBSAT permite uma interpretação visual dos dados do SMF, o que torna fácil o entendimento do fluxo batch. O primeiro passo na análise dos dados é selecionar, de uma lista de JOBs, aqueles que são de interesse, sendo utilizadas todas as informações fornecidas que descrevem o processo batch. O IBSAT inicia o processo nos JOBs finalizadores do ciclo batch e retrocede no tempo para mapear as dependências entre os JOBs. Constroi-se assim, um mapa do fluxo batch, cujas informações são levadas e traduzidas em uma ferramenta de flowcharting. Neste caso, é utilizado para criar o fluxo gráfico do fluxo batch o VISITRAC da Lexonix, que mostrará o caminho crítico. O fluxo batch resultante é comparado ao critério de scheduling existente para validar o fluxo gráfico e qualquer oportunidade de mudanças de scheduling. 14
Com o fluxo batch entendido, as tasks que compõem o caminho crítico, são examinadas em detalhes. Iniciando com o JOB de maior oportunidade aparente, isto é: a task com maior tempo de execução. 15
A análise dos tempos de execução dos steps revela onde os tempos estão sendo gastos, de modo que as atividades de análise do IBSAT são dirigidas para os recursos críticos, objetivando melhorar o tempo de execução dos JOBs detectados. 16
Os tempos de I/O de datasets críticos são endereçados usando uma variedade de métodos. Isto inclui técnicas de buffering, eliminação de I/O, caching, redistribuição de datasets, balanceamento de carga de caminho e device.. O IBSAT fornece informações sobre os datasets críticos para determinar as ações corretivas apropriadas. 17
A análise do histórico dos acessos aos datasets pode mostrar qual JOB criou o dataset, determinando onde introduzir as mudanças de alocação, tais como: blocksize e localização de dataset. O IBSAT mostra se existe uma contenção no dataset em questão, pois pode haver outros datasets concorrentes em termos de I/O. 18
Um novo tempo de execução de task é estimado com BAS e em cada mudança a ser efetuada, sendo estabelecido um novo tempo no fluxo batch. Isto pode causar mudanças no caminho crítico e também assegura que o caminho crítico está sendo constantemente monitorado. Uma vez completada a análise, são apresentadas recomendações em conjunto com os benefícios projetados e o tempo estimado de implementação. As recomendações apresentadas não são genéricas, do tipo: balanceie o subsistema de I/O ou ajuste o cache. Elas são instruções específicas de implementação, completas o suficiente para permitir ao executor saber precisamente quais linhas de JCL, cartões de controle e outros devem ser modificados. Faz parte também das recomendações a transformação em JOBs paralelos que eram executados serialmente. 19
Resultados fornecidos e processos de implementação Os resultados serão apresentados em reunião da Sun Software com o cliente quando se analisará item a item todas as recomendações. As recomendações são categorizadas por tipo de recomendação, tais como: uso de CPU, bufferização, paralelismo de jobs, etc. As recomendações de mudanças específicas no fluxo batch, são fornecidas em meio eletrônico, papel e em hard copy. Isto inclui recomendações detalhadas juntamente com os resultados esperados. (como e porque) 1. Fluxo representando o caminho crítico. Isto consiste de um mapa do projeto, em hard copy, que percorre o fluxo batch durante cada ciclo de produção. Para cada ciclo há um gráfico de pré e pós-análise. 2. Sumário de recomendações de mudanças para facilitar o gerenciamento do projeto dos passos de implementação. 3. Versão eletrônica dos gráficos e a documentação do projeto. Para se obter o máximo proveito das mudanças sugeridas pelo BAS é recomendado um gerenciamento efetivo no projeto de implantação das sugestões. Veja o exemplo de um caso prático. 20
Dados Coletados Dados SMF, tipos de registros: 14, 15, 21, 30 (ou 4, 5, 34 e 35), 62, 64, 70, 71, 72, 74 e 78 RMF deve ser setado para registrar estatísticas de DASD e TAPE Listagem de JOB Scheduling mostrando as dependências de JOBs Listagem dos parâmetros de performance do sistema: OPT, IPS e ICS PARMLIB Informações de configuração de hardware do sistema, incluindo tipos de control units e configurações de cache Os dados do SMF são coletados via o IBSAT Data Collector Recomenda-se que sejam usados de 3 a 5 ciclos de execução 21
Exemplos de recomendações gerais A seguir são apresentados alguns exemplos de recomendações geradas em análises de casos reais. As recomendações de performance são descritas nos relatórios entregues e elas detalham as medidas que deverão ser implementadas para a redução, com sucesso, do tempo do ciclo batch. Alterações de buffer: Datasets VSAM têm várias centenas de milhares de EXCPs executados contra eles durante o ciclo batch. Técnicas de buffering nativas e BLSR (Batch Local Shared Resources) irão diminuir os contadores de EXCPs. Uma limitação de buffering do VSAM nativo é que ele permite somente o buffering de componentes de VSAM index para processamento randômico. Uma descrição completa do BLSR pode ser encontrada no manual IBM GC28-1059- 001. A implementação do BLSR para datasets específicos, dentro do caminho crítico, pode reduzir significativamente o ciclo batch. O BLSR pode ser implementado através de atualizações em bibliotecas de JCL. Transferência de arquivos de fita para DASD: Vários datasets seqüenciais usados em muitas aplicações, são alocados para fita. Estes datasets, mesmo que pequenos, podem ser lidos várias vezes durante o ciclo batch. Se datasets chaves forem alocados para DASD ao invés de fita, o tempo do caminho crítico para aplicações batch poderá ser reduzido. Separação de Datasets: Uma grande quantidade de datasets é alocada em um número limitado de volumes DASD. Isto causa um gargalo em arquivos de aplicações em determinadas DASD Control Units. Algumas vezes, durante o ciclo batch, Control Units podem estar sobrecarregadas. Se os arquivos forem alocados para várias DASD Control Units diferentes, o ciclo batch pode ser reduzido. 22
Reestruturação de JOBs: Alguns JOBs contêm vários jobsteps. Alguns dos JOBs podem ser quebrados em múltiplos JOBs. Isto poderá permitir que os steps possam ser executados com antecedência no ciclo batch, fora do caminho crítico. Um JOB poderá ser quebrado permitindo também o paralelismo de execução dos programas. Initiator Wait: Vários JOBs no caminho crítico esperam por Initiators do sistema para se tornarem disponíveis. Os JOBs do caminho crítico podem ser assinalados para uma classe de JOBs que têm mais Initiators disponíveis. Outra opção é fazer mais Initiators disponíveis para todos os JOBs batch. Alterações no Scheduling de JOBs: Existem oportunidades para executar mudanças no scheduling para JOBs dentro do caminho crítico. A verdadeira dependência é satisfeita antecipadamente no ciclo para os JOBs. Através da liberação desses JOBs nesse tempo, o ciclo batch poderá ser reduzido. Disponibilização de arquivos para Alocação: JOBs no caminho crítico algumas vezes esperam por drives de fitas ou datasets DASD. Uma vez que o tempo de alocação para esses arquivos impacta diretamente o tempo total do ciclo, podem ser reservados recursos para assegurar que as esperas sejam eliminadas. Isolamento de datasets: Podem ser identificados datasets chaves cuja performance de I/O afetam diretamente o tempo do ciclo para aplicações. Os datasets são alocados para pools de DASD gerais. As estatísticas de tempo de resposta para estes pools podem ser altas. Se os arquivos chaves forem alocados para devices DASD que forneçam uma melhor performance, então os ciclos batch podem ser reduzidos. 23
Redução do uso da CPU: Jobsteps podem ter um alto consumo de CPU, isto conta para um longo tempo de execução. Muito do tempo de CPU, pode ser eliminado através de alterações relativamente simples em códigos fonte. Pode ser identificada uma oportunidade máxima para redução do caminho crítico, via alterações em códigos fonte. Usando-se uma ferramenta de exame de perfil de utilização de CPU, como o STROBE ou o OMEGAMON / MVS INSPECT, pode-se determinar o potencial de ganho e um perfil de utilização de CPU dos Jobsteps identificados que estão rodando. Isso irá isolar seções de programas responsáveis por alta utilização de CPU. Este perfil encontrado e um Assembly ou compilador de códigos fontes podem fornecer uma listagem mostrando referências-cruzadas de offsets de programas. Com estas informações, pode-se recomendar alterações em programas. As melhorias no programa podem reduzir o consumo de CPU e recuperar tempo de execução para Jobsteps e o caminho crítico para as aplicações. Tuning de classificações: Vários steps de SORT que classificam arquivos grandes, demoram um tempo significativo no SORTWORK I/O. Para classificações no caminho crítico, o máximo possível de memória que se tornar disponível irá reduzir a atividade de SORTWORK. Forneça também mais memória 31- bit para a classificação. Se houver área particular suficiente, forneça aproximadamente 40Mb de memória. Aumente a memória 31-bit para no mínimo 10 Mb para classificações no caminho crítico. Para o produto SYNCSORT, isto é feito especificando-se VSCORET=10M no cartão de controle fornecido na entrada $ORTPARM. Também aumente o limite da região para REGION=8M para permitir o uso de toda a memória abaixo dos 16Mb. 24
Mudanças no processo: A recarga de vários datasets VSAM pode demorar longos períodos de tempo. As recargas executam milhões de EXCPs e o processo para carregar os arquivos é checado. Classificar os dados em seqüências chaves antes da carga nos arquivos VSAM pode ajudar a eliminar EXCPs e reduzir o tempo de execução. O IDCAMS LISTCAT pode também ser analisado para determinar se a estrutura do arquivo VSAM pode ser modificada. Isto é feito através de modificações nos cartões de controle DELETE/DEFINE. Alterações no tamanho de bloco de datasets: Vários datasets grandes em fita são usados no caminho crítico e não alocam o máximo fator de blocagem permitido. Alocar arquivos com um fator de blocagem grande e buffers adicionais ajudam a melhorar o processamento seqüencial. 25
Exemplos de problemas e soluções: Problema 01: Análise: Solução: Problema 02: Análise: Solução: Problema 03: Análise: Solução: Um JOB é atrasado pela Dependência de Schedule com outro JOB, porém os dois JOBs não compartilham nenhum arquivo de dados (ou não alteram nenhum arquivo de dados). O Batch Analysis Service usa ambos os scheduling do cliente e encadeamento de datasets para linkar os JOBs. Portanto, é possível ver se há alguma dependência de dataset que suporte uma dependência schedulada. Se não, a dependência schedulada pode ser removida permitindo o JOB sucessor iniciar com antecedência. Mudança no Scheduling. Remova a dependência no sistema de Scheduling e isto irá permitir o JOB sucessor iniciar mais cedo. Paralelismo de JOBs Uma grande parte do caminho crítico do tempo de execução de um JOB está dedicada em acessar um arquivo o qual tem pouca ou nenhuma bufferização. Como a velocidade de execução do caminho crítico de um JOB é a chave para aumentar a velocidade de término do ciclo batch, buffers adicionais deverão ser fornecidos para este JOB acessar este arquivo. Realmente este acesso bufferizado ao arquivo terá favorecimento com relação a outros JOBs e outros arquivos melhorando assim a execução do caminho crítico. Aumentar a alocação de buffers para este JOB e para o acesso aos arquivos. Para arquivos VSAM, o uso do parâmetro BLSR é altamente recomendável. Um JOB contém uma grande quantidade de steps que não estão relacionados e o JOB necessita ser completado por inteiro antes que qualquer JOB sucessor possa iniciar. A análise efetuada no JOB indica que os steps não têm uma relação serial com algum ou com todos os outros steps do mesmo JOB. Ainda mais, o JOB executa atualmente como uma seqüência em série todos os steps e o JOB sucessor (sucessores) não pode iniciar até que todo este JOB tenha terminado. Agrupar os steps de acordo com suas dependências seqüenciais ou não interdependências seqüenciais e dividir o JOB em múltiplos JOBs novos cada um contendo somente os steps serialmente relacionados. Desta forma, os novos JOBs estarão aptos a executar, tão logo um destes novos JOBs, termine. Dependendo das relações contidas no fluxo de dados. 26
Problema 04: Análise: Solução: O início de um JOB sucessor é atrasado pelo término de um JOB predecessor muito embora somente a última parte dos steps do sucessor requeira o término do predecessor. Um JOB sucessor consiste de 10 steps, mas somente os últimos 3 steps possuem uma dependência de término no fluxo. Ainda, todo o JOB sucessor espera pelo término completo do JOB predecessor. O JOB com 7 steps poderá agora iniciar sua execução sem esperar o término completo do JOB predecessor cujo enfileiramento de dados evita o início dos 3 últimos steps do JOB original consequentemente permitindo um alto nível de processamento paralelo. Dividir o JOB sucessor em 2 novos JOBs da seguinte maneira: o primeiro JOB conterá os 7 steps e o segundo JOB conterá os 3 últimos steps. Problema 05: Análise: Solução: Problema 06: Análise: Solução: Dois (ou mais) JOBs necessitam ser executados serialmente devido à serialização do acesso em um arquivo comum aos dois JOBs. A análise dos JOBs onde nenhum deles atualiza o arquivo comum a eles. Contudo, estes JOBs usam DISP=OLD como se eles fossem alterar o arquivo comum. Pela simples mudança da disposição dos arquivos para DISP=SHR todos os JOBs podem iniciar simultaneamente e executar em paralelo pois as dependências de schedulagem foram removidas (se elas existirem). O caminho crítico do tempo de execução de um JOB é muito grande apesar de que o tempo de CPU consumido é muito pequeno um JOB limitado por I/O. A análise do I/O mostra que a maior parte do tempo é consumida fazendo-se processamento com acesso seqüencial em um conjunto de arquivos SORTWORK residentes em DASD ou fita. Dada esta presença no caminho crítico do ciclo batch, um manuseio especial dos arquivos de SORT deste JOB reduzirá enormemente o tempo de execução do SORT deste JOB e reduzirá também todo o tempo do ciclo batch.o uso da memória principal ao invés de DASD ou fita para estes arquivos de trabalho do SORT será muito eficiente e requererá somente a mudança do parâmetro SORT para ser implementado. 27
Problema 07: A fim de suportar o processamento de Abend/Restart, todos os JOBs (com prioridades alta e normal) necessitam atualizar um catálogo específico com mudanças de entradas nestes arquivos quando na fase de alocação inicial pelos JOBs. Análise: A análise dos JOBs indica que os JOBs foram divididos apropriadamente pela análise do caminho crítico em classes de prioridades normal e alta. Mas dado que todos os JOBs devem atualizar igualmente o database e que contém o catálogo, ocorre freqüentemente que um JOB de alta prioridade necessite aguardar por um JOB de prioridade normal para enfileirar e liberar o Catálogo antes que o JOB de alta prioridade possa prosseguir fazendo a alocação. Foram feitas tentativas para aumentar o desempenho do I/O no catálogo, mas isto trouxe um pequeno benefício porque o problema não está associado com a velocidade do arquivo em responder. O obstáculo, pelo contrário, está na habilidade dos JOBs de prioridade baixa para acessar a CPU para completar o processamento de suas alocações devido às suas baixas prioridades de CPU.Enquanto isto, os JOBs com alta prioridade devem esperar em filas de alocação por JOBs com baixa prioridade de acesso à CPU até que estes completem o processamento de alocação. Solução: Um aumento da prioridade de dispatching no primeiro período para todas as classes de JOBs deverá ser implementado para permitir que os JOBs em todas as classes de prioridades completem rapidamente seus processamentos de alocação. Isto irá evitar que JOBs com baixa prioridade bloqueiem os JOBs de alta prioridade de acessar o enfileiramento do catálogo e prosseguimento do processamento atual. A mudança pode ser implementada no membro IEAIPSxx da PARMLIB. Problema 08: Análise: Solução: Múltiplos JOBs estão executando um alto número de acessos de I/O durante uma parte específica de um ciclo batch. Os JOBs em questão formam um conjunto de serviços com prioridades alta e normal. A análise dos JOBs mostra que eles compartilham arquivos que são co-alocados no mesmo volume DASD. Uma análise mais profunda indica que além do alto tempo de resposta dos JOBs, os mesmos foram implementados executando vários comandos reserve/release contra o mesmo volume. Se os arquivos são estáticos, a realocação dos arquivos para diferentes volumes e também possivelmente para outros subsistemas diferentes, um alto nível de acesso num único volume. Se os arquivos são freqüentemente realocados e o PAV está disponível, um aumento nos aliases dos PAVs fornecerá um manuseio dinâmico de processamento igualmente distribuído de reserve/release contra os arquivos que frequentemente mudam de posições. Onde uma alta atividade de I/O é também vista, o uso de múltiplos grupos storage SMS segregados deverá também ser utilizado para reduzir a concentração da atividade em qualquer dos subsistemas. 28