Mundo Maiframe

1 - ENDEVOR

Endevor é uma ferramenta de controle de versão utilizado por muitas empresas para o controle de versão do aplicativo de mainframe.

Ele mantém um registro de todas as adições, exclusões e alterações feitas aos elementos do sistema.

É um conjunto integrado de ferramentas de gestão utilizadas para automatizar, controlar e monitorar o processo de desenvolvimento de aplicações.

Funciona sob MVS, dentro do ambiente TSO / ISPF, em lote.

VANTAGENS DA ENDEVOR

Garante que diferentes desenvolvedores não modificar simultaneamente o mesmo elemento.

História absoluta de todas as alterações da fonte

Processos de controle de traduzir fonte em executável

Ligação Auditavel entre código fonte e executáveis relacionados.

Controle e automação de circulação e distribuição de pacotes de software de libertação.

Componentes de Endevor

Endevor ajuda a gerenciar o ciclo de vida do software, fornecendo uma estrutura lógica consistente e flexível para a classificação de componentes de software. Há seis componentes para este estrutura de estoque são:

Meio Ambiente: É o termo endevor para as áreas funcionais de uma organização. Por exemplo, pode haver ambientes de desenvolvimento e produção separados. Não há nenhum limite para o número de ambientes que podem ser definidas.

Estágios: Termo endevor para um estágio no ciclo de vida do software. Por exemplo, um site pode ter fases de teste, QA, corrigir e PROD em seu ciclo de vida. Deve haver duas fases para cada ambiente. Estágios ter um nome, o que representa o seu lugar no ciclo de vida (exemplo TEST) e um ID (1 ou 2). Fases são referidos como fase 1, (a primeira etapa de um ambiente) e Fase 2 (a segunda fase num ambiente).

Sistema: Termo endevor para as aplicações em um site. Por exemplo, um site pode ter financeira (sistema: FINANCE) e manufatura (sistema: MFG) sistemas. Um sistema deve ser definido para cada ambiente de onde ele irá ser utilizado.

Subsistema: Termo endevor para uma aplicação específica dentro de um sistema. Exemplo, pode haver ordem de compra (subsistema: PO) Contas a pagar (subsistema: AP) aplicações dentro FINANCE sistema.

Deve haver pelo menos um subsistema por sistema.

Um subsistema deve ser definido para cada sistema no qual ele vai ser usado.

Tipo: Termo endevor para as categorias de código-fonte. Exemplo, você pode criar os seguintes tipos: COBOL (para código COBOL); COPYBOOK (por cadernos); JCL (para JCL córregos). Você deve definir um tipo para cada estágio em que você quiser usá-lo.

2 - VTAM - VIRTUAL TELECOMMUNICATIONS ACCESS METHOD

Comunicação de Dados, transferência de dados entre dois sistemas remotos. O sistema de redes da IBM usa o SNA (Systems Network Architeture) como protocolo.

É o Software para controlar a rede que o Mainframes IBM usa.

Além desse existem outros Software usado em SNA. Exemplo: São o NCP (Network Control Program) e o CM/2 (Communications Manager 2), a pouco tempo foi incorporado o protocolo APPN (Advanced Peer to Peer Networking) às redes do Mainframe.

A arquitetura de redes de ambiente Mainframe inclui os seguintes componentes:

Linhas de comunicação;

Hardware Devices (dispositivos físicos);

Terminais (incluindo PC's);

Impressoras;

Controladoras;

Modens;

Mainframes;

Token Rings (para uso nas LAN's);

SOFTWARES

VTAM (instalado no Mainframe);

NCP (controlador de comunicação);

Gerenciadores de Comunicação (para os periféricos IBM que usam OS/2);

Emuladores de software SNA;

Destes componentes citados, três deles são elementos de rede que compõem os Links de dados:

Dispositivo de controle de comunicação;

Modens;

Linhas de comunicação;

O VTAM é o responsável por enviar e receber dados e os gerenciadores de dados, como CICS e IMS, cuidam das informações recebidas e enviadas.

CONTROLADORES

Ajudam a controlar o roteamento das mensagens de dados pela rede. Dois deles são os exemplos:

Controladores de comunicação;

Controladores de terminais;

Os controladores de comunicação ou CCP (communications Control Processor), ou Front End Processors ou somente Front Ends. São os dispositivos que controlam o recebimento e envio de mensagens de dados, inclusive as mensagens de confirmação de transferência destas mensagens.

Neste processo de controle, o NCP é o Software, e o CCP é o Hardware, mas todo o dispositivo pode ser conhecido como NCP.

Os controladores de terminais estão conectados a Mainframes, NCP, impressoras e todos os dispositivos periféricos. Este controla o envio de mensagens, como para qual periférico vai à mensagem, etc.

Os terminais podem ser dispositivos definidos para estarem conectados aos controladores de terminais, tem seu próprio software chamado Microcode, que permite acesso à rede SNA, é chamado de 'terminal burro'. Os 'terminais inteligentes' são PC's com software SNA instalados neles. Os Pc's podem ser os de plataforma OS/2 ou ainda Microsoft.

REDE DE COMUNICAÇÃO

A rede Token Ring da IBM também pode se conectar ao ambiente Mainframe através de controladores de terminais ou até através de um dispositivo chamado 3172. A CISCO também tem seus dispositivos de acesso à rede Mainframe.

Os CCP's são usados para ligar a rede (através das linhas de comunicação) ao processador do usuário. Os CCP's são identificados no sistema como as unidades 3745, 3725 ou 3720. O software usado no CCP é o NCP (Network Control Program). O terminal controlador pode ser definido também como 3274 ou 3174, podem ser ainda 3174-63R (Remote) ou 3174-11L (Local).

Os dados enviados pelo computador do usuário são convertidos para binário quando enviados aos terminais, e desconvertidos quando chegam de volta ao mesmo. Esta conversão é feita pelo CCP. Neste processo de conversão é usado um MODEM. (MODulador/DEModulador).

TIPOS DE TRANSMISSÃO

As linhas de comunicação suportam 3 tipos de transferência:

Simplex - Pode só enviar ou só receber dados, mas não os dois;

Half Duplex - Pode enviar ou receber dados, mas não ao mesmo tempo;

Full Duplex - Envia e recebem dados simultaneamente.

As linhas de comunicação são duas:

Switched - Acesso discado, via linha telefônica;

Leased - Linha de conexão permanente, exemplo: banda larga.

Existem também dois modos de transmissão aceitos na rede SNA:

Synchronous (síncrono) - transmite ou recebe os dados via frames (pacotes). Este modo usa dois tipos de transmissão, BSC (BinarySinchronousCode) e SDLC (Synchronous Data Link Control).

Asynchronous (assíncrono) - transmite byte a byte usando um bite de controle a cada byte transmitido. Este modo é o usado pelos PC's.

Os códigos de transmissão usados são dois:

ASCII (American Standard Code for InformationInterchange) - usado nos PC's;

EBCDIC (ExtendedBinaryCoded Decimal InterchangeCode) - Usado na plataforma IBM OS/2 ou Mainframe.

COMPONENTES DO VTAM

O VTAM provê uma interface entre os aplicativos do Mainframe (CICS e IMS) e os usuários. O VTAM está habilitado para:

Enviar e receber mensagens;

Formatar respostas;

Detectar e corrigir erros;

Alertar operadores sobre erros que não pode corrigir por si só;

Manipular os recursos da rede através de comandos.

As aplicações que usam a rede de comunicações são variadas, tais como:

Programas de verificação de usuários, etc;

Programas de entrada de dados;

Programas para atualização de dados;

Entrada remota de Jobs (RJE), usado para submeter e imprimir Jobs de sistemas remotos.

ELEMENTOS DE UMA REDE SNA

NODE, Nó (node) é o nome dado a um ponto de rede definido com um nome simbólico. Um nó é um ponto final de um Link, ou a junção comum entre dois ou mais Links na rede.

Um nó pode ser processador, controlador, Workstation (PC) ou impressoras.

O VTAM usa suas próprias definições para endereçamento, e a partir de um nome de nó (node), o VTAM constrói endereço de rede.

O processo de endereçamento não fica visível ao operador, mas o VTAM dá a possibilidade o operador ver um nome de nó. Os comandos de endereços de VTAM são direcionados ao nome de nó e não ao endereçamento interno.

SSCP: É o componente do VTAM responsável por parar e inicializar a rede e estabelecer e terminar sessões. Também executa rotinas de recuperação.

LU: Uma unidade lógica é um dos números do NetworkAddressableUnits (NAU's) que reside em uma rede VTAM. As LU's são normalmente terminais ou impressoras, ou ainda PC's que emulam a LU via software.

3 - JCL - JOB CONTROL LANGUAGE

Linguagem usada para descrever os passos de um trabalho em lotes, arquivos a serem utilizados, programas a serem executados, etc. Um termo genérico, usado pela IBM para se referir às linguagens de controle de lote para seus sistemas operacionais system / 360. como, z / os e vse / esa JCL é um sistema, pesado, difícil de aprender, cheio de inconsistências. por essas razões geralmente tem sido substituído por sistemas mais adequados.

Linguagem interpretada usada em mainframes da IBM para instruir o sistema a inicializar um subsistema ou executar um programa de lote. A sigla JCL também pode ser usada genericamente para se referir a outra linguagem, que tenham mesmas funções, tais como um wfl, da empresa de burroughs, ou a ocl, da icl.

Existem 2 JCL da IBM: uma para linhagem de sistemas operacionais iniciada com o dos os / 360 e cujo último membro é oz / vse, Outra para linhagem que vai do os / 360 ao z / os. Ambas possuem em comum alguns conceitos e regras básicas de sintaxe, mas no geral são bem diferentes.

PONTOS COMUNS ENTRE JCL DO DOS, E DO OS

JOBS, STEPS E PROCEDURES

Em ambas as JCL's, a unidade básica de trabalho é o job. Um job consiste em um (ou vários) passos, cada qual sendo uma requisição para um programa específico.

Antes da existência dos bancos de dados relacionais, um típico job responsável por criar um relatório impresso consistiria nos seguintes passos:

Um programa escrito pelo usuário para selecionar os registros apropriados e copiá-los a um arquivo temporário;

Outro programa, geralmente para uso genérico, para organizar estes dados sob um determinado critério sub-totais.

A linguagem é uma ferramenta antiga nas instalações de grande porte. Sua sintaxe é caracterizada por um par de barras (//) que indicam o início de cada instrução. Apesar dessa notação existir desde o uso de cartões perfurados para o envio de código jcl, ela não foi alterada desde a década de 1960 por questões de compatibilidade. A função original das barras era assegurar que o cartão perfurado estava posicionado corretamente no leitor: Caso elas não fossem lidas logo no começo da instrução, todo o cartão era rejeitado. Outro conceito mantido é o tamanho dos comandos jcl, armazenados em registros de 80 bytes, o que equivale a um cartão.

4 - DB2

Sistema de Gerenciamento de Banco de Dados que a IBM lançou em 1983 baseado em SQL/DS para seu mainframe. A principio o produto foi chamado System R que fora iniciado em 1978.

O projeto DB2 começou no inicio dos anos 70 quando Edgar Frank Codd, trabalhando para IBM descreveu a teoria dos Banco de dados Relacionais e publicou sua teoria em Junho de 1970. Para aplicar o modelo, Codd criou uma linguagem de banco de dados relacionais que a chamou de Alpha. Entretanto, a IBM não acreditava no potencial das suas ideias, deixando-o fora da supervisão do grupo de programadores, que violaram diversas ideias fundamentais do modelo relacional de Codd. O resultado foi a linguagem SEQUEL, que depois foi mudado para seu acrônimo SQL porque SEQUEL já era uma marca registrada.

Por muitos anos, DB2 foi feito exclusivamente para rodar nos mainframes da IBM. Posteriormente a IBM permitiu que rodasse no sistema Windows e Linux de até 2 processadores e até 2GB de memória.

Historicamente, a primeira posição entre os SGDB do mercado foi marcado pela alternância entre DB2 e Oracle. Entretanto há outros SGDBs concorrentes como o Microsoft SQL (que é apenas disponível no Windows), além de sistemas de código aberto tais como o PostgreSQL, MySQL e Firebird.

O DB2 para z/OS tem poucos concorrentes diretos, mas a Oracle vem atraindo consumidores para o Linux da zSerie, embora não as custas do DB2.

Em 2006 a IBM entrou na competição pelo emergente mercado de armazenamento warehouse aplicado ao mercado financeiro, com o lançamento de uma linha de produtos com sistemas de hardware/software pré-configurados. Essa família de “aplicações warehouse” foi nomeada como IBM BalancedConfiguration Unit, ou BCU.

Na década de 1990 a IBM Introduziu o DB2 para outras plataformas de servidores, incluindo o Unix e o Windows, para então colocar no Linux e PDAs.

As inspirações para os detalhes de implementação do DB2 vieram da linguagem DL/1 da IBM assim como o Sistema de Gerenciamento de Informações. As novas versões já são avaliadas para OS/2 e é chamada DB2/2.

Em meados de 2006, a IBM anunciou o “Viper”, o codinome do DB2 9 para computação distribuídas e para DB2 9 no z/OS, a empresa diz que o novo DB2 será o primeiro banco de dados relacional que armazena o XML nativo.

Outros recursos incluem: Desenvolvimento baseado em OLTP para computação distribuídas, desenvolvimento baseado em Business intelligence e data warehousing para z\OS, mais recursos de auto configuração e auto gerenciamento, adição de recursos para a plataforma 64-bits (especialmente para z/OS), melhoria na performance do armazenamento estruturado para z/OS e a continuação da padronização do vocabulário da linguagem SQL entre z/OS e outras computação distribuídas.

DB2 é vendida em diversos tipos de “edições” ou licenças, do mais simples ao mais sofisticado. Alguns exemplos de edição são a Express, Workgroup e a Edição Enterprise. A edição mais sofisticada para Linux/UNIX/Windows é o DB2 Data WarehouseEntrepriseEdition, ou DB2 DWE.

DB2 para Z/OS é vendido em sua própria licença. Começando com a versão 8, a IBM vendeu o DB2 para z/OS e outros sistemas com característica muito próximas.DB2 para esse sistema tem algumas característica exclusivas: Segurança Multi-Level, tabelas de tamanhos extremamente grandes e compressão a nível de hardware. DB2 para z/OS foi sempre conhecido pela sua liderança de performance OLTP e é usado para suportar missões críticas nas operações de negócios, mas agora a versão z/OS está começando a adquirir característica Business intelligence.

Em 2006, a IBM lançou uma versão do DB2 chamada DB2 9 Express-C, para concorrer com as versões gratuitas do Oracle da Microsoft SQL Server. Express-C não terá limite no número de usuários e do tamanho do banco de dados. Foi desenvolvido para máquinas com DB2, pode ser administrado tanto em uma interface de comandos de linhas ou em um ambiente gráfico.

A interface de comando de linha requer mais conhecimento do produto, mas pode ser mais facilmente automatizado. O ambiente gráfico é uma multi-plataforma Java que contém uma grande variedade de wizards para usuários iniciantes.

5 - ADABAS DBMS - ADAPTABLE DATA BASE SYSTEM

Sistema de gerenciamento de banco de dados do Software AG DBMS ADABAS, organiza e acessa os dados de acordo com as relações entre os campos de dados, que são expressos por arquivos ADABAS, que consistem em campos de dados e registros lógicos.

Com o ADABAS DBMS, é possível usar linguagem natural de alto nível para operar em dados que são gerenciados pelo SGBD.

NATURAL é o quarto sistema de desenvolvimento de aplicações da geração de Software AG que permite criar, modificar, ler e proteger os dados que o DBMS gerencia. Todos os ADABAS arquivos e dados, referenciados em um programa natural devem ser definidos através de um módulo de definição de dados De (DDM).

ADABAS tem um único usuário e ambientes de execução multiusuário, os quais são suportados pela interface / ACCESS SAS para ADABAS.

ADABAS DATABASES

Um banco de dados ADABAS é uma coleção de dados organizados em arquivos ADABAS. Cada banco de dados tem um banco de dados associado, identificado, que é um valor numérico no intervalo de 1 a 255, e um nome de banco de dados, um valor de caractere com um máximo de 16 caracteres. Cada banco de dados pode ser composto por até 255 ADABAS ficheiros.

Um banco de dados ADABAS é composto por três arquivos: Armazenamento de Dados, arquivos associados e Armazenamento de Trabalho.

O sistema de armazenamento de dados contém os registros de dados reais para todos os arquivos ADABAS, em formato comprimido.

O sistema Associação de arquivos contém informações de armazenamento interno que gerencia os dados para todo o banco de dados.

O sistema de armazenamento mantém os arquivados e os trabalhos temporários.

Para usar a interface / ACCESS SAS para ADABAS, deve se considerar três componentes ADABAS: ADABAS files,DDMs NATURAL e descritores de ADABAS (arquivo de dados ADABAS que fornece um índice de seus valores).

ADABAS files e NATURAL DDMs, são os componentes a partir do qual se cria SAS / ACCESS para acessar e visualizar arquivos.

Um descritor ADABAS é um arquivo de dados ADABAS que fornece um índice de valores da ELD dados, SAS / ACCESS descritor files, são também os arquivos usados para estabelecer uma conexão entre o sistema SAS e ADABAS.

ARQUIVOS ADABAS, ARQUIVOS DDMS NATURAL E DESCRITORES DE ADABAS.

Arquivo ADABAS: É uma coleção de dados relacionados logicamente, organizados por campos de dados e registros lógicos.

Cada arquivo DABAS permite o máximo de 926 campos de dados e 16.777.215 registros lógicos.

6 - CONTROL M

CONTROL M - JOB MONITORING

O ControlM é uma ferramentas de scheduling usadas pelos sistemas de Mainframe.

BATCH MONITORING

O JES lê a 'sysout' do Job depois da execução do mesmo, dá o 'ok' no ControlM depois desta leitura. O output do job fica 6 meses na log do ControlM.

TELAS DE MONITORING DO CONTROLM

Tela 2 - Usada para acessar as bibliotecas de Jobs. Estas bibliotecas funcionam como um Datasets ou Bancos de Dados, são dividida em Datasets, os Datasets por sua vez são divididos em Tables, e estas Tables por sua vez divididas em membros, que esses sim são os Jobs a serem colocados para executar no ControlM.

Tela 3 - Usada para ver os jobs, configura-se esta tela digitando 'sh', entra-se no filtro e faz-se o que achar necessário para visualização na tela 3.

Filtro - pode-se configurar todo tipo de visualização para a tela 3 e para verificar um job específico. Neste caso, senta-se o filtro para tudo 'y' e coloca-se o jobname. É possivel checar mais de um job usando um tab depois do nome do primeiro job.

Lista de opção de comandos no rodapé da tela - Mostra os comandos básicos para o job, devem ser digitados na coluna ao lado do job. Para configurar a lista deve-se ir até o ispf e digitar 'pshow off', depois entrar no control m e digitar opt para options.

7 - CICS - CUSTOMER INFORMATION CONTROL SYSTEM

É um sistema de dados e de comunicação de dados desenvolvido pela IBM para rodar em equipamentos IBM e compatíveis. Este sistema permite que sejam transmitidos dados de um terminal para o computador, que estes dados sejam processados, acessem arquivos (bancos de dados) e sejam então transmitidos de volta ao terminal de origem, É composto de vários módulos/programas de gerenciamento.

Para este processamento, o sistema precisa usar um software de telecomunicações (ex: VTAM, TCAM ou BTAM) e um ou mais dos seguintes métodos de acesso: VSAM, BDAM, ISAM ou DL/I. Assim o CICS pode ser definido como é um sistema de banco de dados/comunicação de dados (DB/DC), O CICS, suporta: COBOL, Assembler, PL/I e RPG II.

O CICS pode ser executado sob os sistemas MVS, VSE, VM ou OS/2. Os programas podem ser transportados de um ambiente para outro com pouca ou mesmo nenhuma alteração.

CICS Possui dois níveis de codificação: Macro, que é similar ao assembler, e Command, que é similar ao COBOL. A forma semelhante ao Assembler é chamada de MACRO LEVEL e a outra forma de codificar instruções para o CICS em um programa é o COMMAND LEVEL.

Obs: O CICS roda sob o controle do sistema operacional.

PROCESSAMENTO ON-LINE

Para o CICS é o recebimento de informações (dados) do terminal, manipulação destas informações e o envio de uma mensagem de volta ao usuário. Tudo isto pode normalmente ser feito em questão de segundos em um sistema CICS.

Neste tipo de transação, cada vez que o operador pressiona a tecla ENTER, o software de comunicação verifica se o terminal é válido. Isso é possível graças a tabela de controle de terminal (TCT). As informações sobre o terminal, basicamente, seriam identificação do terminal, modelo, tamanho da tela e status.

Aplicações Batch são diferentes das aplicações On-line tendo em vista que cada uma trabalha em uma área específica. O CICS trabalha com várias aplicações simultaneamente, características multitarefas do CICS.

Para que esses recursos sejam utilizados de maneira satisfatória é preciso observar que um programa de aplicação não pode se comunicar diretamente com o sistema operacional. Para tanto, quando isso se fizer necessário, a aplicação deve recorrer ao CICS que então irá se comunicar com o sistema operacional.

O programa de aplicação não deve abrir ou fechar arquivos, pois, o CICS executará essas funções no momento apropriado. Quanto à um programa COBOL, o comando STOP RUN/GOBACK é preciso, porém quando um desses comandos é executado o programa encerra o CICS, fazendo com que toda a rede entre em OFF Line.

Para atender ao COBOL e ao CICS ao mesmo tempo, colocamos essas instruções em uma região do programa CICS a qual não será executada. Essa área será após o comando RETURN ou XTCL. Toda aplicação Online deve retornar o controle para o CICS.

MÓDULOS PRINCIPAIS

TCP (Terminal ControlProgram) - Controla o envio e recebimento de mensagens envolvendo terminais.

KCP (TaskControlProgram) - Controla as múltiplas task que estão sendo executadas concorrentemente. Para cada task, o KCP cria um bloco na DAS chamado TCA (TaskControl Área), que contém informações sobre a task (registradores do programa, endereço do terminal associado, número da task, etc.).

PCP (ProgramControlProgram) - Controla a execução de programas de aplicação; gerencia programas e tabelas.

FCP (File ControlProgram) - Controla e manipula datasets VSAM e BDAM.

SCP (StorageControlProgram) - Embora transparente ao programador, este módulo é muito importante, pois gerencia toda a memória utilizada na execução do CICS.

DAS (DynamicStorageArea) - É uma área de memória reservada pelo CICS em tempo de inicialização para armazenar principalmente dados de utilização temporária. Os programas de aplicação, áreas de trabalho de aplicações, algumas áreas de controle do CICS são armazenados nesta área. A DAS alocada acima da linha dos 16 Mb é chamada EDSA (Extended DSA).

TABELAS CICS

O CICS administra recursos do usuário que estão definidos em tabelas. Estas tabelas podem ser compiladas e serão carregadas na memória na fase de inicialização do CICS.

As quatro principais tabelas do CICS são :

TCT (Terminal ControlTable) - Contém a descrição dos terminais a serem reconhecidos pelo CICS. Para cada terminal deve ser criada uma entrada e informado o nome pelo qual o CICS reconhecerá este terminal e como ele é reconhecido pela rede, e também as características deste terminal (impressora ou vídeo, por exemplo).

PCT (ProgramControlTable) Contém os dados das transações que podem ser solicitadas, como nome do programa a ser acionado, prioridade , etc.

PPT (ProcessingProgramTable) - Descreve as características dos programas que podem ser executados. Devem ser informados nome do programa, linguagem, etc.

FCT (File ControlTable) - armazena as informações referentes às características dos arquivos que serão manipulados pelo CICS. Devem ser informado nome, método de acesso, operações permitidas (READ, UPDATE, INSERT, etc.).

O processamento de uma transação é iniciado quando o operador tecla o código no terminal. É possível executar uma mesma transação em dois ou mais terminais concorrentes, e o CICS atribui um número para cada task. As instruções do programa (Procedure Division no COBOL) são partilhadas por todas as tasks, mas a área de dados (Working-StorageSection, no COBOL) é copiada para cada task.

Os programas projetados com esta característica são chamados de semi-reentrantes. As áreas referentes a Procedure, a Working e as áreas criadas para gerenciamento da task estão localizados na DAS (DynamicStorageArea).

CONCEITOS DE PROGRAMAÇÃO

A interface de nível de comando é uma interface entre seus programas de aplicação e o CICS. Essa interface elimina a necessidade de se aprender a estrutura interna e operação do CICS. Permite ainda que se programe uma aplicação “ON LINE” da mesma forma que você faria em uma aplicação BATCH.

Uma aplicação onde a interface de nível de comando (COMMAND LEVEL) está sendo utilizada permite que sejam solicitados serviços ao CICS. Os comandos CICS são tratados pelo EXEC Interface Program, que aciona o módulo responsável pelo serviço solicitado.

Através do COMMAND LEVEL, o programa pode solicitar serviços de:

Terminais (Send, Receive, etc.)

Arquivos (Reads, Rewites, etc.)

Programas (Links, loads, etc.)

Durante a execução de uma aplicação CICS um programa pode manipular outra transação com a mesma identificação que é iniciada de outro terminal. Dentro desse conceito um programa de aplicação pode ser carregado apenas uma vez e múltiplas tarefas podem ser executadas. Todavia, somente a parte executável do programa é compartilhada.

O CICS proporciona uma cópia da memória de trabalho do programa para cada tarefa que executa o programa. Isto é possível tendo em vista que o conteúdo da memória de trabalho variará de uma tarefa para outra.

Toda memória adquirida e liberada dinamicamente durante a execução de uma tarefa é parte da área de memória dinâmica do CICS (DAS). Assim a cópia da tarefa de uma memória de trabalho do programa está colocada na DAS.

Quando imaginamos uma transação que recebe uma chave de registro a partir da tela, lê este registro e exibe-o na tela, temos uma solicitação de serviço ao CICS (Receive, Send, Read, etc.). A task então passa o controle ao CICS, o qual dará prosseguimento a outras transações de maior prioridade.

8 - IMS/VS - INFORMATION MANAGEMENT SYSTEM/VIRTUAL STORAGE

É um aplicativo de controle. Foi criado para facilitar acesso ao banco de dados através do processo Batch ou On-line.

COMPONENTES DO IMS

image copy - faz o backup dos bancos de dados do ims. durante o backup o ims continua ativo, mas o acesso é restrito.

production backup - faz o backup do resto do ims e não só dos data bases, e este geralmente é executado com o ims inativo.

pads (paperand accessories distribution service) - são os jobs de processo batch que geram os relatórios do ims. executam com o ims indisponível no sistema, fora do horário de uso do mesmo.

GERENCIAMENTO DO IMS:

IMS/DB - Database Management Services - Aplicativo para uso banco de dados

IMS/DC - Data Communications Services - Aplicativo para usuário

O IMS/DC - é a interface de usuário, onde pode ser usado o CICS também.

REGIONS

Uma Region de IMS é uma área da memória que é usada para o que os programas do aplicativo executem.

CONTROLREGION - Essa region tem o programa de controle do IMS, a de maior importância e que interage com todas as outras Regions. Controla, terminais, bancos de dados e a Log. Executa como uns StartedTask. Geralmente tem 'CTL' no nome, Interage com o VTAM através do VTAM ACB.

MESSAGEPROCESSINGREGIONS (MPR's) - A segunda Region, processa as transações on-line. Pode não estar instalada, pois o CICS pode ser usado para substituir esta Region também. Geralmente tem um 'MPXX' no nome da Region e o número dela, quando existem mais de uma para o IMS.

BATCH MESSAGEPROCESSINGREGION (BMP) - Usada para o trabalho de processamento Batch. Muitas podem estar ativas no sistema, mas isso demanda recurso do sistema, ou seja, quantas mais BMP's, mais lento fica o acesso ao IMS

DATABASE RECOVERY CONTROLREGION (DBRC) - Ajuda na recuperação os bancos de dados no caso de uma falha. Essa Region grava informações do estatus da Log do IMS no dataset RECON, mantem todas as Imagem Copies do banco de dados e automaticamente gera o JCL necessário para a inicialização do IMS após uma falha. A Region tem geralmente 'DBRC' no nome.

DATA LANGUAGE/I REGION (DL/i) - Provem os requerimentos de processamento para o database esse aplicativo é chamado de DL/i, que faz a interface entre o programa de aplicação e os dados. Também é usado para escrever programas.

DATABASE (BANCO DE DADOS) - Coleção de dados inter-relacionados que são mantidos em um formato que possam ser processados pelos programas da aplicação. O Database é hierárquico, significa que os dados são organizados como em uma pirâmide: Cada pedaço está relacionado com o anterior e posterior.

Uma seção do banco de dados é um seguimento, cada segmento é relacionado com o abaixo e com o acima. Esta situação é conhecida como relação PAI/FILHO, na qual o seguimento acima é sempre pai do segmento abaixo.

9 - MVS - MULTIPLE VIRTUAL STORAGE

O sistema MVS é uma Imagem virtual em uma memória física. É chamado de partição lógica ou LogicaPartition (LPAR). Algo como “particionar” o HD de um PC, e montar as partições lógicas de um HD físico.

TASK, 'tarefa', é um aplicativo que está no sistema por algum motivo específico. Exemplo: Acessar os dados que o Mainframe processa e armazena, controlar a entrada de usuários, ou para manter um Buffer da memória do sistema.

JES, é um aplicativo especial, pois cuida da entrada e saída de Jobs no sistema, controla o número de usuários que vão utilizar o sistema e até outras Tasks.

JOB Um Job é um aplicativo, temporário, não fica instalado no sistema como um programa. O Job funciona STEPS ou passos, sendo que cada passo executa um programa. Uma atividade pode conter vários Job's para que seja realizada.

Então para se entender melhor como o MVS gerencia seus aplicativos, é possível comparar a lista de entidades ativas no MVS ao Task Manager (gerenciador de tarefas) em um PC. Tudo o que estiver executando como aplicativo em um sistema, mesmo estando transparente ao usuário, estará na lista de ativos do MVS.

ARQUITETURA DO MVS

O Mainframe tem três partes distintas no processamento dos dados:

Entrada de dados, processamento de dados e armazenamento de dados.

Entrada de dados: Terminais de Mainframe para usuários e as conexões com servidores.

Processamento de dados: MVS, que tem TASKS e Jobs que acessam e processam dados.

Saídas e armazenamento: Bancos de dados e Datasets que são armazenados em discos (DASD) e fitas (TAPE), e também as impressoras, que imprimem relatórios de processos.

CONSOLE

A console de um sistema é uma das interfaces entre um operador e o sistema. A console ou Master Console é uma tela que mostra toda a Log do sistema passando por esta tela. Ela pode ser usada para se enviar comandos diretamente ao sistema ou aos aplicativos do sistema.

A tela da console lembra Matrix, uma tela preta com letras verdes.

Algumas mensagens podem vir em cores diferentes, o que pode indicar um problema, pode ser informativa somente, quando pode enviar um Reply, que é uma mensagem que pede ação do operador. Alguns comandos relacionados a console e seu funcionamento estarão no tópico de comandos.

O Mainframe tem ainda algumas subdivisões bem distintas do modo de tratar os dados que ele deve processar e armazenar. Aqui serão mostradas e comparadas estas subdivisões: batch e online, dataset e database, job e task.

O processo Batch de um sistema Mainframe tem como principais funções, ler, alterar, criar e apagar dados.

BATCH E ONLINE

O processo Batch, que é realizado através de Job, geralmente, faz alterações programadas.

O processo Online se utiliza de aplicativos como o IMS e CICS para manusear os dados em tempo real.

Um bom exemplo de Online é o acesso a uma conta bancária: Quando alguém está acessando uma conta bancária, este usuário tem toda autoridade para movimentar essa conta, esta ação está acontecendo em Tempo Real. Já quando um usuário tenta acessar a conta na madrugada e o sistema do banco se mostra indisponível, este é o momento de processamento Batch. O processamento Batch é usado para alterações programadas que podem ser cópia de segurança dos dados, ou uma transferência bancária exempla um DOC, que não é feita na hora, pois demanda mais trabalho e procedimentos mais complexos.

DATASET E DATABASE

Dataset é um pacote de dados que é usado para armazenar todo tipo de informação, seja ela interna do sistema, ou referente ao próprio sistema, ou ate informações para operadores e suportes técnico deste sistema. Se fôssemos comparar, um dataset se parece com o Word ou bloco de notas, estes mesmos que se usa para anotar textos, etc.

Database é um banco de dados, usado para arquivar informações que serão disponibilizadas a usuários, ou seja, toda informação, sigilosa ou não, que a empresa dona do sistema quiser que seja processa e armazenada em um sistema Mainframe estará em um banco de dados. O Database se utiliza de arquitetura de armazenamento de dados em tabelas, ou seja, se parece com o Excel.

JOB E TASK

TASK, aplicativo de sistema, ou seja, é igual aos aplicativos que se tem em um PC, que ficam instalados no sistema operacional, e podem servir para utilização dos usuários ou para o funcionamento do próprio sistema. Muitas Task's são transparentes aos usuários.

JOB, é uma espécie de sub rotina, O programador, um suporte técnico, cria um Job para uma tarefa específica. Exemplo atualizar dados, reorganizar dados, apagar dados, etc. Os Jobs se utilizam de programas para fazer aquilo para que foram criados.

XCF - COUPLING FACILITY

O XCF e um aplicativo usado para colocar dois ou mais sistemas em compartilhamento de recursos. Funciona em transparência para o usuário, mas ajuda muito quando se fala em recursos como fitas, discos, etc.

10 - Z/OS - ZONA DE SEPARAÇÃO

Z/OS é um sistema operacional de 64 bits para computadores mainframe, produzido pela IBM, deriva e é o sucessor do OS / 390, que por sua vez é a seqüência de uma série de versões MVS, [NB1] Como OS / 390, z / OS combina uma série de produtos relacionados, algumas das quais ainda são opcionais.

z / OS oferece os atributos dos sistemas operacionais modernos, mas também retém grande parte da funcionalidade de origem na década de 1960 e cada década subsequente, ainda se encontra em utilização diária (compatibilidade com versões anteriores é uma das filosofias centrais de design z / do OS). A versão mais recente é z / OS Versão 2 Release 1.

z / OS suporta os sistemas de mainframe estáveis e padrões como o CICS, IMS, DB2, RACF, SNA, WebSphere MQ, os métodos de acesso a dados orientados por registro, REXX, CLIST, SMP / E, JCL, TSO / E e ISPF, entre outros . No entanto, z / OS também suporta Java, C, C ++, e UNIX (Single UNIX Specification) 64-bit APIs e aplicações através de UNIX System Services. The Open Group certifica z / OS como sistema operacional compatível com UNIX - com UNIX / Linux- estilo hierárquico HFS [NB 2] e sistemas de arquivos ZFS. Como resultado, z / OS abriga uma ampla gama de software open source e comerciais de qualquer vintage. z / OS pode se comunicar diretamente via TCP / IP, incluindo IPv6, [3] e inclui servidores HTTP padrão (um de Lotus , o outro Apache derivados), juntamente com outros serviços comuns, tais como FTP, NFS, CIFS e / SMB. Outra filosofia de design central é o suporte para altíssima qualidade de serviço (QoS), mesmo dentro de uma única instância do sistema operacional, embora z / OS tem suporte embutido para ParallelSysplex agrupamento.

z / OS tem um Workload Manager (WLM) e despachante que gerencia automaticamente inúmeras unidades simultaneamente hospedadas de trabalho em execução em espaços de endereço principais protegidos separados de acordo com as metas dinamicamente ajustáveis. Esta capacidade inerentemente suporta multi-tenancy uma única imagem de sistema operacional.

Modernos mainframes IBM também oferecem dois níveis adicionais de virtualização: LPARs e (opcionalmente) z / VM. Essas novas funções dentro do hardware, z / OS ez / VM - apoio e Linux e OpenSolaris - têm incentivado o desenvolvimento de novas aplicações para mainframes, Muitos deles utilizam o WebSphereApplication Server para middleware z / OS.

Desde a sua criação z / OS opera em sistema tri-modal (24-bit, 31-bit e 64-bit). Através da versão 1.5, o próprio z / OS pode começar em qualquer ESA modo z / Architecture 31-bit / 390 ou 64 bits, para que ele pudesse funcionar em hardware mais antigo ainda que sem suporte a aplicativos de 64 bits nessas máquinas.

Obs: Apenas o hardware mais recente z / Architecture fabricados a partir do ano 2000 pode executar um código de 64 bits.

O Suporte da IBM para z / OS 1.5 foi encerrado em 31 de março de 2007, Agora z / OS é suportado apenas em mainframes z / Arquitetura e só é executado em modo de 64 bits.

11 - COBOL - LINGUAGEM COMUM ORIENTADA PARA OS NEGÓCIOS

Em 1959, foi tomada a decisão de criar uma fonte de linguagem apropriada para dados comerciais, em uma reunião no Pentágono em Washington, DC.

Os participantes desta reunião eram usuários de computadores, poder público, fábricas de computadores e outras partes interessadas.

O propósito da reunião era discutir a necessidade de uma linguagem geral, direcionadas para fins comerciais, Como resultado uma comissão foi nomeada com o nome de CODASYL (Conference On Data System Linguajes).

Uma subcomissão foi, diretamente, incumbida da tarefa de definir uma linguagem adaptada para administrar processamento de dados.

Em 1960, foi publicada a gramática, usualmente chamada Relatório COBOL-60. Em 1961 foi revisado e publicado o relatório COBOL-6, formando a base para os mais comuns compiladores, novamente revisada e publicada.

Em 1962, foi pulicado o relatório “COBOL-61 – Versão Estendida”, era na verdade uma revisão ampliada do cobol.

Em 1965, Foi publicado um relatório completamente novo, definido como COBOL-65. Ele continha praticamente todos os elementos de “Versão 4 Estendida”, porém numa forma totalmente revisada, junto com alguns elementos novos, projetados principalmente por causa do uso expressivo das memórias de acesso aleatório (RAM).

Embora o COBOL tenha sido desenvolvido e mantido pela CODASYL, ele foi também estabelecido como uma Linguagem Padrão pelo Instituto Americano de Padrões Nacionais (ANSI).

Os fornecedores dos compiladores COBOL geralmente se baseavam no COBOL Padrão Nacional Americano.

Um padrão inicial, noticiado em 1968, foi revisado em 1974 e novamente na metade dos anos 80.

NORMAS COBOL

As especificações aprovadas por todo o Comitê de Curto Prazo foram aprovadas pelo Comitê Executivo em 3 de janeiro de 1960, o COBOL 60.

O American National Standards Institute (ANSI) produziu várias revisões do padrão COBOL:

• COBOL-68

• COBOL-74

• COBOL-85

• Intrinsic Functions Amendment - 1989

• Corrections Amendment - 1991

Após as alterações de 1985 o padrão ANSI (que era adotado pela ISO), o desenvolvimento e a apropriação foi assumida pela ISO. As seguintes edições e TRs (Relatórios Técnicos) foram emitidas pelo padrão ISO (e adotados como ANSI):

• COBOL 2002

• Finalizer Technical Report - 2003

• Native XML syntax Technical Report - 2006

• Bibliotecas de coleção de classes orientadas a objeto - aprovação pendente

Desde 2002, o padrão ISO também está disponível para o público codificado como ISO / IEC 1989.

LEGADO

Programas em COBOL estão em uso globalmente em agências governamentais e militares além de empresas comerciais, e estão sendo executados em sistemas operacionais como o da IBM z/OS e z/VSE, as famílias POSIX (Unix / Linux, etc) e Windows da Microsoft, bem como Unisys OS 2200.

Em 1997, o Gartner Group relatou que 80% dos negócios do mundo rodavam em COBOL com mais de 200 bilhões de linhas de código existentes e cerca de 5 bilhões de linhas de código novo por ano.

12 - SNA - SYSTEMS NETWORK ARCHITETURE

No início de 1970, a IBM descobriu que os grandes clientes estavam relutantes em confiar em redes de comunicação não confiáveis para automatizar corretamente transações importantes. Para solucionar esse problema, a IBM desenvolveu Systems Network Architecture (SNA).

"Qualquer coisa que pode dar errado vai dar errado", e SNA pode ser única na tentativa de identificar literalmente tudo o que poderia dar errado, a fim de especificar a resposta adequada.

Certos tipos de erros esperados (como uma linha de telefone ou falha modem) são feitos automaticamente. Outros erros (problemas de software, tabelas de configuração, etc) são isolados, registrados e relatados ao pessoal técnico central para análise e resposta.

Este projeto SNA funcionou bem, desde que o equipamento de comunicações foi formalmente instalado por uma equipe profissional, Tornou-se menos útil em ambientes quando qualquer PC simplesmente se conecta e se une à LAN.

Duas formas de SNA desenvolvidos: Sub áreas (SNA clássicas), gerido pelo mainframes, e APPN (New SNA) baseados em redes de microcomputadores.

A partir de caros, minicomputadores de comutação dedicados geridos por um mainframe central. Os minicomputadores dedicados executar um sistema especial chamado NCP. Não há programas de usuário executar nessas máquinas. Cada NCP gerencia as comunicações em nome de todos os terminais, estações de trabalho e PCs conectados a ele. Em uma rede bancária, o PCN pode gerenciar todos os terminais e máquinas em escritórios em uma área metropolitana particular. O tráfego é roteado entre as máquinas PCN e, eventualmente, para o mainframe central.

O mainframe é executado um produto IBM chamado VTAM, que controla a rede. Embora as mensagens individuais vai fluir de um NCP para outro através de uma linha telefônica, VTAM mantém uma tabela de todas as máquinas e as ligações telefônicas na rede. Ele seleciona as rotas e os caminhos alternativos que as mensagens podem demorar entre diferentes nós NCP.

A subárea é a coleção de terminais, estações de trabalho e linhas telefônicas geridas por um PCN. Geralmente, o PCN é responsável pela gestão do fluxo de tráfego normal dentro da subárea e VTAM gerencia as conexões e ligações entre subáreas. Qualquer rede de sub área deve ter um mainframe.

O rápido crescimento dos minicomputadores, estações de trabalho e computadores pessoais forçaram a IBM a desenvolver um segundo tipo de SNA, Os clientes estavam construindo redes que usam AS / 400 minicomputadores que não tinham mainframe ou VTAM para fornecer controle.

O novo SNA é chamado APPN (Avançado PeertoPeer Networking). APPN e sub área SNA têm estratégias completamente diferentes para roteamento e gerenciamento de rede, Sua única característica comum é o suporte para aplicativos ou dispositivos que utilizam o APPC (LU 6.2) protocolo.

Embora a IBM continua a ficção de que SNA é uma arquitetura, um quadro mais preciso sustenta que é duas arquiteturas compatíveis que podem trocar dados.

SNA não é compatível com o protocolo TCP / IP, Isto aplica-se a todos os níveis no desenho das duas arquiteturas de rede. Sempre que os projetistas da IBM foram para a direita, os projetistas do TCP / IP foram para a esquerda.

Como resultado, os dois protocolos de rede são incompatível, e acabam por ser gratuito. Uma organização executando o SNA e TCP / IP provavelmente pode resolver qualquer tipo de problema de comunicação.

Em uma rota de rede IP pacotes individuais de dados, a rede proporciona cada um embalado com base em um número de endereço que identifica a máquina de destino. A rede não tem uma visão de uma "sessão". Quando PC Lube e Tune envia este documento através da rede para o seu computador, diferentes peças podem acabar roteado através de diferentes cidades. O TCP é responsável pela montagem dos pedaços, depois de terem sido recebidos.

Na rede SNA, um cliente e o servidor não pode trocar mensagens, a menos que primeiro estabelecer uma sessão. Em uma rede de subárea, o programa VTAM no mainframe se envolve na criação de cada sessão. Além disso, há blocos de controle que descrevem a sessão no NCP para que o cliente fala e do NCP para que as negociações de servidor Intermediário, PCNs não têm blocos de controle para a e sessão. Em APPN SNA, existem blocos de controle para a sessão de todos os nós intermédios, através do qual passa a mensagem.

Cada projeto tem suas vantagens e limitações. O design IP (sem sessões fixas) funciona bem em redes experimentais construídos com peças de reposição e computadores do laboratório. Ele também funciona bem para o seu patrocinador (Departamento de Defesa) quando os componentes de rede estão sendo explodido por fogo inimigo. Em troca, os erros na rede IP, muitas vezes não são notificados e não corrigido, porque o equipamento intermediário redireciona as mensagens subsequentes através de um caminho diferente. O projeto SNA funciona bem para construir redes comerciais confiáveis de dispositivos dedicados, gerenciados de forma centralizada. SNA, no entanto, requer uma equipe central, tecnicamente treinados prontos e capazes de responder a problemas como eles são relatados pelo equipamento de rede.

A rede de subárea conseguiu mainframe foi originalmente concebido para que todos os terminais, impressora, ou o programa aplicativo foi configurado pelo nome no mainframe antes que ele pudesse usar a rede. Isso funcionou quando 3.270 terminais foram instalados pela equipe profissional e foram telegrafou de volta para as unidades de controlo de gestão centralizada. Hoje, quando os usuários comuns comprar um PC e conectar através de uma rede local, esta configuração central tornou-se pesado. Uma solução é criar um "pool" de nomes de dispositivos fictícios gerenciados por um computador gateway. Então poder-se do PC e emprestar um nome não utilizado a partir da piscina. Os recentes lançamentos permitir VTAM para definir um "protótipo" PC e dinamicamente adicionar novos nomes para a configuração quando os dispositivos correspondentes ao protótipo apresentado na rede.

Uma solução mais formal, no entanto, é fornecido pela arquitetura APPN projetado originalmente para minicomputadores. APPN tem dois tipos de nós. Um nó final ( EN ) contém programas cliente e servidor. Os dados fluem dentro ou fora de um nó final, mas não passar por isso. Um nó da rede ( NN ) também contém clientes e servidores, mas também fornece roteamento e gerenciamento de rede. Quando um nó final é iniciado, ele se conecta a um nó de rede que irá proporcionar o seu acesso ao resto da rede. Ele transmite ao NN uma lista dos LUNAMES que o nó final contém. O NN termina com uma tabela de seus próprios LUNAMES e os de todo o PT do que ele gerencia.

Quando um cliente PT quer se conectar a um servidor em algum lugar da rede, o seu envia uma mensagem BIND com o LUNAME do servidor para o NN. O NN verifica sua própria tabela, e se o nome não é correspondido transmissões uma consulta que, em última análise passa por todos os NN na rede. Quando algum NN reconhece a LUNAME, ele envia de volta uma resposta que estabelece tanto uma sessão e uma rota através do NN de entre o programa cliente e o servidor.

A maioria dos APPN é o conjunto de consultas e respostas que gerem nomes, rotas e sessões. Como o resto do SNA, é um corpo bastante complicado e exaustivamente documentado de código.

Obviamente estações de trabalho não pode manter uma tabela dinâmica que abrange redes maciças ou longas distâncias. A solução para este problema é quebrar a rede APPN em unidades locais menores, cada um com um ID de rede (NETID). No uso comum, a NETID identifica um conjunto de estações de trabalho que estão próximos uns dos outros (em um edifício, em um campus, ou na mesma cidade). A troca dinâmica de LUNAMES não ocorre entre os clusters com diferentes netids. Em vez disso, o tráfego para uma rede remota é encaminhado com base no NETID, eo tráfego dentro do cluster local é encaminhado com base no LUNAME. A combinação de NETID e LUNAME identifica qualquer servidor do sistema, mas o mesmo LUNAME podem aparecer em diferentes grupos NETID associados com máquinas diferentes locais. Afinal de contas, a pessoa tem pouca dificuldade confundindo "CHICAGO.PRINTER" de "NEWYORK.PRINTER", mesmo que o LUNAME "impressora" é encontrado em cada cidade.

TCP / IP é um protocolo simples, em vez. O código fonte para os programas é amplamente disponível. SNA é surpreendente complexo, e só IBM tem o conjunto completo de programas. Ele é construído para o AS / 400. Outros produtos de estação de trabalho importantes incluem:

• NS / DOS para DOS e Windows

• Gerente de Comunicação para OS / 2

• Serviços SNA para AIX

• SNA Server para Windows NT [da Microsoft]

A interface de programação nativa para redes SNA modernas é a interface de programação comum para comunicações (CPIC). Isto fornece um conjunto comum de sub-rotinas, serviços e códigos de retorno para programas escritos em COBOL, C, ou REXX. Ele está documentado no SC26-4399 publicação papel IBM, mas também é amplamente disponível em cópia eletrônica em CD-ROM.

De acordo com o projeto da IBM Communications, SNA torna-se uma das várias opções intercambiáveis "transporte". É um ponto de TCP / IP. The Blueprint está sendo implementado em produtos que levam o título de "Anynet". Isso permite que programas CPIC a correr em TCP / IP, ou programas escritos para usar o "socket" interface de Unix podem ser executados através de redes SNA. Escolha de rede, então depende mais de características de gestão.

A tradicional rede SNA foi instalada e gerenciada por uma equipe técnica central de uma grande corporação. Se a rede cair, uma empresa como a Aetna Seguros está temporariamente fora do negócio. TCP / IP é projetado para ser casual sobre os erros e simplesmente descartar mensagens não entregues.

A Internet é formada por algumas dezenas de centrais de prestadores de serviços e 10.000 conectados redes privadas. As coisas mudam o tempo todo. Não é racional para tentar controlar centralmente todas as alterações ou imediatamente responder a todos os problemas. Não seria possível construir a Internet em todos utilizando SNA, mas IP oferece bastante bom serviço na maioria das vezes.

13 - TSO

O TSO permite a criação de uma sessão de usuário para interagir com o z/OS. Cria uma sessão de logon de usuário com o prompt de comando para o z/OS. A maioria dos usuários utiliza o TSO para acessar uma interface baseada em menus chamada ISPF (interactive System Productivity Facility). Estes menus e painéis oferecem uma ampla gama de funções para controlar e trabalhar com arquivos do sistema. O TSO e o ISPF funcionam como um tipo de IDE para desenvolvimento, no caso para auxiliar os desenvolvedores de programas.

Cada usuário recebe uma identificação e senha. Para logar no z/OS é necessário a utilização de uma emulador 3270 rodando no Windows ou Linux.

O z/OS é o sistema operacional largamente utilizado no mainframe, tendo como seus principais objetivos fornecer estabilidade, segurança e disponibilidade ininterrupta aos aplicativos rodando no mainframe.

O z/OS é resultado de anos de avanços tecnológicos. É a evolução de um sistema operacional que opera desde um simples programa até centenas de programas interagindo com usuários simultaneamente. Os sistemas operacionais anteriores ao z/OS executavam cada programa, um por vez assim que o anterior terminava. No mainframe ele divide o trabalho em várias partes e dando cada parte a um subsistema que funciona independente, com isso não sobrecarrega o processador principal. Conforme cada parte termina sua execução passa o controle para outro subsistema dando assim prosseguimento a diferentes jobs executando ao mesmo tempo.

O z/OS é ideal para processamento de Batch (jobs). Os batch rodam no mainframe praticamente sem interação humana nenhum ou pouca.

Na necessidade de uma interferência humana, temos no mainframe painéis, menus e ferramentas para nos auxiliar em determinadas tarefas. Uma dessas ferramentas chama-se TSO/E (Time Shareing Option/Extensions), que fornece uma série de comandos que utilizamos para interagir com os recursos do mainframe.

14 - Z LINUX

Linux on System z é o termo coletivo para o sistema operacional Linux compilado para rodar em mainframes IBM, especialmente zmachines sistema. Outros termos de mesmo significado incluem Linux no zEnterprise 196 de Linux no System z10, Linux no System z9, Linux on zSeries, Linux / 390, zLinux, z / Linux, etc.

Linux no System z originou-se de estudo separados para portar o Linux para maiores servidores da IBM. O primeiro estudo, o projeto "Bigfoot", desenvolvido pela Linas Vepstas no final de 1998 até o início de 1999, foi uma distribuição independente e desde então tem sido abandonado.

A IBM publicou uma coleção de correções e adições para o kernel Linux 2.2.13 em dezembro de 1999, para iniciar a linha principal de hoje Linux no System z. Em 2000, foi incluído o Integrated Facility para Linux (IFL) motores. Think Blue Linux foi uma distribuição de mainframe que consiste principalmente de pacotes da Red Hat adicionado ao kernel IBM.

Após o trabalho de Kernel as edições de mainframe foram acontecendo e tornando se disponíveis muito rapidamente.

No início do envolvimento da IBM, o Linux System z inclui um código objeto apenas (OCO) módulos, sem código fonte, ou seja, não era totalmente livre. No entanto, atualmente o Linux on System z é um software completamente livre sob licença da GNU General Public.

Em maio de 2006, de acordo com a IBM, mais de 1.700 clientes rodar o Linux em seus mainframes.

VIRTUALIZAÇÃO

editVirtualization é necessária por padrão no IBM System z; não há opção de rodar o Linux nativamente. Primeira camada de virtualização é fornecido pelo recurso do processador e System Manager (PR / SM) para implantar partições lógicas (LPARs). Uma variedade de sistemas operacionais podem ser iniciados em uma LPAR. Um hypervisor System z chamada z / VM também pode ser executado como a segunda camada de virtualização em LPARs.

Podem criadas, várias máquinas virtuais (VM), pois há recursos alocados para os LPARs para apoiá-los. Esta capacidade de virtualização multicamada permite System z implantar centenas ou milhares de máquinas virtuais dentro de um único sistema físico.

O PR System z / SM ganhou critério comum de avaliação da garantia Nível 5 (EAL), certificação, e z / VM ganhou critério comum EAL4, para sua capacidade de proteger máquinas virtuais em uma LPAR.

A primeira camada de virtualização z System (PR / SM) permite que uma máquina System z execute até 60 LPARs. Portanto, com PR / SM sozinho, um System z pode enviar até 60 instâncias do Linux, Estes podem ser considerados como 60 servidores Bare Metal virtuais porque PR / SM permite CPUs para ser dedicado a LPARs individuais.

Uma única System z com 60 z / VM LPARs pode implantar um grande número de máquinas virtuais, enquanto existirem adequada CPU, memória e I / O de recursos configurado com o sistema.

PR / SM e hardware atributos Sistema de z permitir que recursos de computação sejam alterado dinamicamente para atender às demandas de carga de trabalho, CPU e de memória assim como E / S, recursos como portas IP e SAN sem interrupção, os recursos podem ser adicionados e atribuído dinamicamente ao sistema reconhecida e utilizada pela LPAR.

Eles são virtualizados e compartilhados entre todos os LPARs. O componente do System z que fornece esse recurso de hardware é chamado de Canal do Subsistema. Cada LPAR pode ser configurado para "ver" ou "não ver" as portas virtuais de I / O para estabelecer "shareness" desejado ou isolamento. Capacidade de virtualização do sistema z permite redução significativa de recursos de E / S por causa de sua habilidade de compartilhá-los e dirigir-se a utilização.

Comunicação Inter-LPAR é facilitada pela PR / SM e hardware System z. Comunicação intra-LPAR é facilitada pelo z / VM que se origina o sistema definido pelo conceito de rede. A partir de uma comunicação significa ponto, com a primeira camada de virtualização PR / SM e a segunda camada de virtualização z / VM, casos Linux em um sistema z não tem a necessidade de comutadores top-of-rack IP e switches SAN. A capacidade de virtualização do sistema z também permite que esse sistema seja utilizado em 80%, 90%, ou até 100% e é muito produtivo.

Quando os aplicativos do Linux em um conjunto de dados de acesso LPAR e aplicações em outros LPARs como CICS, IBM DB2, IMS, Linux, e outros subsistemas de mainframe, em execução no mesmo mainframes física, eles podem utilizar HiperSockets: Memória rápida, só de conexões TCP / IP . Em comparação com o TCP / IP através de cartões de interface de rede padrão (NICs, no mundo do mainframe chamado Open System Adaptadores, SAOS), HiperSockets pode melhorar a capacidade de resposta do usuário final: segurança e confiabilidade.

Com o System z modelos EC12 e BC12, o Hipersocket se estende além do limite físico para facilitar a comunicação entre sistemas velocidade segura e de alta Aplicações em LPAR A no sistema A pode usar Hiperscocket para se comunicar com aplicações em LPAR B no sistema B para garantir os atributos de segurança e desempenho.

Linux on System z está disponível em ambas as versões 31-bit e 64-bit. O Linux designação arquitetura do kernel é "s390" para kernels de 31 bits e "s390x" para kernels de 64 bits, distribuições de 64 bits ainda pode executar aplicativos de 31 bits.

O kernel 2.6.x Linux adicionou suporte substancial para hardware de mainframe, como ESCON, FICON, dispositivos de armazenamento conectados à SCSI e System z aceleradores criptográficos.

Linux roda em PCs padrão de uso geral (processadores Central), bem como IFLs (Integrated Facility for Linux). IFLs são processadores de mainframe dedicados para executar Linux, quer nativamente ou sob z / VM. Microcódigo restringe a execução de cargas de trabalho IFLs "tradicionais", como z / OS; elas são idênticas a outros processadores System z. IFLs são geralmente menos mais em conta para licenciar da IBM de CPs. [10]

VANTAGENS

Linux no System z dá a flexibilidade de executar o Linux com as vantagens do hardware mainframe. Usando virtualização, inúmeros servidores menores podem ser combinados em uma única unidade central, ganhando alguns benefícios da centralização, mas permitindo servidores especializados, graças à virtualização de apoio, que pode reduzir os custos operacionais.

Mainframes da IBM permitem o uso transparente de etapas de execução do processador redundantes e verificação de integridade, que é necessário nas indústrias de serviços financeiros.

Mainframes geralmente permitem a ligação automática de hardware, como processadores e memória. Essa troca é normalmente transparente para o sistema operacional, permitindo reparos de rotina a ser executada sem desligar o sistema.

INVESTIMENTOS

Linux on System z não é apropriado para as pequenas empresas que têm menos de cerca de 10 servidores Linux distribuídos.

A maioria dos fornecedores de software, incluindo IBM, trata os IFLs altamente virtualizados como processadores não-virtualizados em outras plataformas para fins de licenciamento, Em outras palavras, uma única IFL executando dezenas de instâncias do Linux ainda conta como uma CPU "normal", com o mesmo preço da CPU, para o licenciamento de software. Teste, desenvolvimento, garantia de qualidade, treinamento e servidor de produção redundante casos pode rodar em um IFL, (ou mais IFLs, apenas se for necessário para a capacidade de desempenho da demanda de pico).

A equação de custo para Linux on System z nem sempre é bem compreendida e é controverso, e muitas empresas e governos têm dificuldade em medir, decisões muito menos baseando o software, mão de obra e outros custos (como os custos de interrupção e falhas de segurança) .

Os custos de aquisição são mais visível, a o passo que pequenos servidores, não escalonáveis são "barato". No entanto, os custos pós aquisição não são menos reais e são geralmente muito maior do que os preços de aquisição de hardware. Usuários individuais, departamentos de grandes empresas e governos às vezes têm dificuldade em compartilhar infraestrutura de computação (ou quaisquer outros recursos), caracterizando assim perdas de tempo e controle.

Centralização Server, como o Linux no System z fornece, pode recompensar a cooperação com melhor serviço e menor custo, “facilitando“ assim o entendimento dentro de uma burocracia corporativa.

Linux on System z, também suporta dispositivos de armazenamento em disco menos caro do que z / OS porque o Linux não exige FICON ou anexo ESCON, embora z / OS podem usar o espaço em disco de forma mais eficiente, devido à compressão do banco de dados assistida por hardware no z / OS.

Este efeito de compressão é um pouco variável e pode ser um pouco reduzida devido às exigências de alocação de espaço mínimo para conjuntos de dados z / OS (uma faixa do disco inteiro).

CARGAS DE TRABALHO ADEQUADAS

Mainframe, são projetados para grandes cargas de trabalho empresariais como o processamento de transações ou de gerenciamento de banco. Projeto Mainframe enfatiza o desempenho de entrada / saída, implementado através do canal de I / O. Historicamente, o princípio é o de descarregar atividades de I / O da CPU, tanto quanto possível, e o z / Architecture adicionalmente descarrega cálculos criptográficos. Mainframes podem escalar a inúmeros processadores em um único quadro, por exemplo, até 64 processadores no caso de o sistema CE z10 modelo E64, que dá tanto como 28.000 MIPS.

Por outro lado, em geral, computadores centrais, e Linux no Sistema z, em particular, não executam bem para computações de tarefas individuais: Exemplos incluem simulações mais científicas, previsão do tempo e modelagem molecular. Mainframes não fornecem elementos gráficos ou placas de som, e são, como tal, pouco adequado para edição de mídia digital ou projeto auxiliado por computador (CAD), exceto, talvez, em funções de apoio (por exemplo, o armazenamento de conteúdo, estoques de peças, etc)

SUPORTE

Como todas as outras versões do Linux, o Linux on System z é regido pela licença de software livre GPL. Linux no System z código-fonte completo está disponível a partir de inúmeros grupos em uma base livre e igual, e suporte arquitetural é agora parte do esforço principal do kernel Linux.

A IBM atribui vários de seus programadores para o esforço da comunidade, mas não é o único participante.

A IBM atualmente suporta duas distribuições Linux, Red Hat e SUSE e Linux no System z são notáveis Debian, Fedora, Slackware, e Gentoo.

Quase todos os pacotes de software livre ou de código aberto disponível para Linux em geral está disponível para Linux no System z, incluindo Apache HTTP Server, software Samba, JBoss, PostgreSQL, MySQL, PHP, linguagem de programação Python, Concurrent Versions System (CVS), o GNU Compiler coleção (GCC), e Perl, entre muitos outros.

Hat e SUSE oferta de apoio da linha principal para suas distribuições Red rodando Linux no System z. IBM Global Services também oferece contratos de suporte, incluindo a cobertura 24x7, vinte e quatro horas sete dias por semana, Alguns aplicativos de software padrão do Linux estão disponíveis pre compilados, incluindo pacotes de software corporativos de código fechado populares, como WebSphere, DB2 andOracle bases de dados e aplicações, SAP R / 3, SAP ERP, e Kit da IBM JDK (Java Developer), para citar apenas alguns.

RECURSOS PARA DESENVOLVEDORES

IBM oferece recursos para os desenvolvedores que desejam direcionar Linux para System z