MVS

O MVS (Multiple Virtual Storage - Armazenamento Virtual Múltiplo) foi o sistema operacional mais utilizado nos mainframes IBM System/370 e System/390. Foi desenvolvido pela IBM, porém não possui vínculo com outros sistemas operacionais da empresa, como o VSE e VM.

Lançado inicialmente em 1974, o MVS passou por diversos novos lançamentos através de outros nomes, primeiramente como MVS/SE (System Extension - Extensão de Sistema), em seguida MVS/SP (System Product - Produto de Sistema) Versão 1, e então MVS/XA (eXtended Architecture - Arquitetura Estendida), MVS/ESA (Enterprise Systems Architecture - Arquitetura de Sistemas para Negócios), OS/390 e finalmente como z/OS (quando o suporte a 64-bits foi incluído nos modelos de servidores zSeries). No sistema MVS/SP V4.3 foi acrescentado suporte a Unix (originalmente nomeado OPEN EDITION), o qual rendeu à IBM as certificações Unix e POSIX em diversos níveis. No núcleo do MVS permanece essencialmente o mesmo sistema operacional. Devido ao seu projeto, os programas escritos para o MVS executam normalmente no z/OS, sem a necessidade de serem modificados.

A princípio a IBM descreveu o MVS como uma simples atualização para o OS/VS2, porém tornou-se de fato uma versão com muitas modificações. O sistema OS/VS2 release 1 foi uma atualização para o OS/360 MVT que preservou muito do código original e, como o MVT, foi escrito em sua maior parte em Assembly. O núcleo do MVS foi praticamente todo escrito em Assembly XF, apesar de alguns módulos terem sido escritos em PL/S, exceto os relacionados à performance do sistema, em particular o Supervisor de Entrada/Saída (IOS). A IBM ressaltou com o uso do OS/VS2 a compatibilidade ascendente: programas que executavam sob o MVT não necessitavam sequer de recompilação para serem executados também sob o MVS. Os mesmos arquivos JCL poderiam ser utilizados sem quaisquer modificações, e utilitários e outros recursos não relacionados ao núcleo do sistema como o TSO também poderiam ser utilizados sem alteração alguma. A IBM e os usuários quase que unanimamente denominaram o novo sistema como MVS desde o começo, e a IBM prosseguiu com o termo em seus novos lançamentos, como foi o caso do MVS/XA.

Evolução do MVS

O sistema OS/360 MFT (Multitasking with a Fixed number of Tasks - Multitarefa com um número Fixo de Tarefas) proporcionou, como o nome sugere, multitarefa: diversas partições de memória, cada uma com um tamanho fixo, eram definidas quando o sistema operacional era instalado e quando o operador as configurava. Por exemplo, poderia haver uma partição pequena, duas medianas e uma extensa. Se houvesse dois programas extensos prontos para execução, um deles deveria aguardar até o término do outro para que a partição extensa fosse liberada.

O OS/360 MVT (Multitasking with a Variable number of Tasks - Multitarefa com um número variável de tarefas) foi um aperfeiçoamento que redefiniu profundamente o uso da memória. Ao invés de utilizar partições de memória de tamanho fixo, o MVT alocava memória em regiões para utilização dos job steps conforme necessário, provendo memória física contígua suficiente. Essa foi uma melhora bastante significativa em relação ao gerenciamento de memória do MFT, mas possuía algumas desvantagens: se um job alocasse memória dinamicamente (como grande parte dos programas e sistemas de gerenciamento de bancos de dados fazem) os programadores precisavam estimar a necessidade máxima de memória que o job iria utilizar e definí-la previamente para o MVT. Um job step que combinasse programas pequenos e extensos desperdiçaria memória enquanto os programas pequenos fossem executados. Um problema maior, a memória poderia se fragmentar como, por exemplo, na situação em que a memória não utilizada pelos jobs em um dado momento poderia se dividir, de modo que formasse pequenos intervalos entre as áreas dos jobs. A única solução seria aguardar até que um dos jobs finalizasse para se iniciar um outro.

No início da década de 70, a IBM procurou suavizar estes problemas adicionando o recurso de memória virtual (denominada pela IBM como Virtual Storage - Armazenamento Virtual), a qual permitiu que os programas solicitassem espaços de endereçamento maiores que a memória física disponível. As implementações originais possuíam um único espaço de endereçamento virtual, compartilhado por todos os jobs. Os sistemas OS/VS1 e OS/VS2 foram lançados com esse recurso e, apesar de apresentarem o mesmo problema que o OS/360 MVT, os impactos foram menores, pois os jobs agora poderiam exigir muito mais espaço de endereçamento, mesmo que o armazenamento físico fosse menor.

Espaços de endereçamento do MVS - visão geral MVS (parte compartilhada de todos os espaços de endereçamento) Aplicação 1 Aplicação 2 Aplicação 3 Área virtual compartilhada (controlada pelo MVS)

Visão de uma aplicação MVS Aplicação 1 Área virtual compartilhada

Em meados de 1970, a IBM apresentou o MVS, que não apenas incluía suporte a armazenamento virtual maior que o armazenamento físico como o SVS, mas também permitiu que um número indefinido de aplicações fossem executadas em diferentes espaços de memória. Dois programas concorrentes podem tentar solicitar o mesmo endereço de memória virtual, porém o sistema de memória virtual irá redirecionar estas solicitações a espaços de memória física distintos. Cada um destes espaços de endereçamento consistem em três áreas: uma para o sistema operacional (uma instância compartilhada por todos os jobs), uma área de aplicação única para cada aplicação e uma área virtual compartilhada utilizada para diversos fins, incluindo a comunicação entre jobs. A IBM informou que cada área de aplicação sempre teria ao menos 8MB de espaço. Isso tornou o MVS a solução perfeita para problemas empresariais que resultaram da necessidade de se executar mais aplicações.

O MVS maximizou o potencial de processamento ao proporcionar capacidades de multiprogramação e multiprocessamento. Como seus predecessores MVT e OS/VS2 SVS, o MVS possuía suporte à multiprogramação: instruções de programa e os dados associados são agendados por um programa de controle e dados ciclos de processamento. Diferente de um sistema operacional monoprogramado, estes sistemas maximizam o potencial de processamento dividindo os ciclos de processamento entre as instruções associadas a diversos programas executando concorrentemente. Desta forma, o programa de controle não precisa aguardar a operação de E/S ser finalizada para proceder. Executando as instruções para múltiplos programas, o computador se torna apto a retomar e avançar entre programas ativos e inativos.

As primeiras versões do MVS (meados de 1970) estiveram entre as primeiras séries de sistemas operacionais da IBM com suporte à configurações de multiprocessamento, apesar de a variante M65MP do OS/360 executando sob os modelos 65 e 67 do System/360 possuir suporte limitado a este recurso. O System/360 modelo 67 também possuía suporte aos sistemas operacionais com suporte à multiprocessamento TSS/360, MTS e CP-67. Pelo fato destes tipos de sistemas conseguirem executar várias instruções simultaneamente, oferecem um poder de processamento maior que um sistema de monoprocessamento. Como resultado, o MVS poderia tratar os problemas das empresas trazidos pela necessidade de se processar grandes quantidades de dados.

Sistemas de multiprocessamento são tanto fracamente acoplados (cada computador possui acesso a uma workload comum) como fortemente acoplados (os computadores compartilham o mesmo armazenamento real e são controlados por uma única cópia do sistema operacional). O MVS manteve o multiprocessamento fracamente acoplado do Attached Support Processor (ASP) e também o multiprocessamento fortemente acoplado do OS/360 Modelo 65 Multiprocessing. Em sistemas fortemente acoplados, duas CPUs concorrentemente compartilhadas acessam a mesma memória (e a mesma cópia do sistema operacional) e periféricos, provendo um maior poder de processamento e grau de tolerância a falhas caso uma CPU falhasse. Em configurações fracamente acopladas, cada grupo de processadores (simples e/ou fortemente acoplados) possuem sua própria memória e seu próprio sistema operacional, mas periféricos compartilhados e o componente do sistema operacional JES3 permitia o gerenciamento de todo o grupo através de um único console. Isso proporcionou maior resiliência e permitiu que os operadores decidissem quais processadores deveriam executar cada job através de uma central de listagem de jobs. O MVS JES3 deu aos seus usuários a oportunidade de conectar em rede dois ou mais sistemas de processamento de dados via discos compartilhados e adaptadores Channel-to-Channel (CTCA's). Este recurso eventualmente se tornou disponível aos usuários do JES2 como um Spool de Multi-Acesso (MAS).

Originalmente o MVS suportava endereçamento de 24 bits (até 16MB). Com o progresso da tecnologia de hardware, o suporte passou para 31 bits (XA e ESA, até 2GB), e agora para endereçamento de 64 bits (z/OS). Os motivos mais significativos para a rápida atualização para 31 bits foram o crescimento das grandes redes de processamento de transações que executavam em único espaço de endereçamento, a maioria controlada por CICS, e o fato de o sistema de gerenciamento de bancos de dados relacional DB2 precisar de mais que 8 MB de espaço de endereçamento de aplicação para executar de forma eficiente (as versões iniciais eram configuradas em dois espaços de memória que se comunicavam por uma área virtual compartilhada, mas isto demandava um espaço significativo para a área de código do programa pois todas estas comunicações precisavam ser transmitidas através do sistema operacional).

As interfaces do usuário principal para o MVS são: Job Control Language (JCL), que foi originalmente desenvolvido para processamento em batch mas, a partir da década de 70, também passou a ser utilizado para iniciar e alocar recursos para jobs interativos de longa execução como o CICS; e o TSO (Time Sharing Option - Opção de Tempo Compartilhado), que foi principalmente utilizado para executar ferramentas de desenvolvimento e alguns sistemas de informação para usuários finais. O ISPF é uma aplicação do TSO para usuários de terminais das famílias 3270 (ou superiores, assim como para VM) que permitia ao usuário realizar as mesmas tarefas que poderiam ser executadas através da linha de comando do TSO, porém em uma interface orientada a menus e campos, e com um editor em tela cheia e navegador de arquivos. A interface básica do TSO é uma linha de comando, porém algumas facilidades foram sendo adicionadas posteriormente para melhor suporte às interfaces orientadas à formulários).

O MVS deu um passo além em relação à tolerância a falhas, construído a partir do inicial utilitário STAE, que a IBM denominou software recovery - recuperação do software. A IBM resolveu dar este passo após anos de experiência com o MVT no real mundo dos negócios. Falhas de sistema estavam agora gerando maiores impactos nos negócios dos clientes, e a IBM decidiu dar um pulo maior em relação ao projeto pois, apesar das melhores técnicas de desenvolvimento e teste de softwares, problemas IRIAM acontecer. Essa posição foi primordial para o desenvolvimento de uma grande quantidade de código com o objetivo de aumentar a tolerância a falhas do sistema. Informações estatísticas são difíceis de provar a eficiência destes recursos (como mensurar problemas prevenidos ou resolvidos?), porém a IBM, em várias dimensões, aperfeiçoou estes recursos de tolerância a falhas e recuperação de software.

Esse projeto especificou uma hierarquia de programas de tratamento de erros no kernel do sistema, chamada Functional Recovery Routines - Rotinas de Recuperação Funcional, e também no modo usuário, chamado "ESTAE" (Extended Specified Task Abnormal Exit routines - rotinas extendidads de Saída Anormal de Tarefas Especificadas) que era acionada quando o sistema detectava algum erro (na verdade, erros no processador, no armazenamento ou no software). Cada rotina de recuperação fazia com que a função principal se tornasse reacionável, coletava os dados de diagnóstico do erro e reacionava a função principal para tentar resolver o problema ou escalava o processamento do erro para a próxima rotina de tratamento de erro da hierarquia.

Assim, com cada erro o sistema coleta dados de diagnóstico para tentar realizar reparos e manter o sistema em funcionamento. A pior situação possível seria desalocar o espaço de endereçamento de um usuário no caso de um erro não reparado. Porém, tratava-se apenas de um ponto de um projeto inicial, pois a mais recente versão do MVS (z/OS), além de possuir uma rotina de recuperação para cada programa de recuperação, também possui uma rotina de recuperação para cada rotina de recuperação. Essa estrutura de recuperação foi implantada no programa de controle básico do MVS, e utilitários de programação são disponibilizados e utilizados por desenvolvedores de programas e por terceiros.

O programa de recuperação do MVS praticamente tornou a depuração dos programas tanto mais fácil como mais difícil. O software de recuperação requer que os programas registrem "rastros" de onde estão e o que estão fazendo, facilitando assim a depuração, porém o processamento de progressos pode sobrescrever tais rastros. A captura do erro no momento em que ele ocorre maximiza a depuração, e existem utilitários para as rotinas de recuperação para realizarem tal tarefa.

Foi incluso um critério para o caso de um problema maior que demandasse uma manutenção pela IBM. Caso um componente principal falhasse ao iniciar o software de recuperação, isto seria considerado uma falha válida para ser reportada. Ainda, se uma rotina de recuperação falhasse ao coletar dados significativos de diagnóstico como os que são necessários solucionar o problema, isto é considerado uma falha reportável pelos padrões IBM e que requer reparação. Assim, os padrões IBM, quando rigorosamente aplicados, favoreciam uma melhoria contínua.

A IBM apresentou, no lançamento da primeira versão do MVS, um hipervisor sob demanda, uma ferramenta de serviços chamada Dynamic Support System - Sistema de Suporte Dinâmico (DSS). Este recurso poderia ser acionado para iniciar uma sessão que permitisse a criação de processos de diagnóstico ou a execução de um já criado. Os processos aguardavam a ocorrência de algum evento especial, como o carregamento de um programa, dispositivo E/S e chamadas de procedimentos do sistema e permitiam serem acionados nesse instante. Esses procedimentos, que poderiam ser acionadas recursivamente, concediam a leitura e escrita de dados e também alteração do fluxo das instruções. O hardware Program Event Recording - Gravação de Eventos de Programa (PER) era utilizado. Devido à sobrecarga que esta ferramenta causava ao sistema, ela foi removida dos sistemas MVS disponíveis aos clientes. O uso do Program Event Recording passou a ocorrer através de um aperfeiçoamento no comando de diagnóstico SLIP, que incluiu o suporte a PER (SLIP/Per) no SU 64/65 (1978).

Múltiplas cópias do MVS (e outros sistemas operacionais da IBM) poderiam compartilhar a mesma máquina caso essa máquina fosse controlada pela VM/370. Neste caso, o software VM/370 era o verdadeiro sistema operacional que disponibilizava altos privilégios aos seus sistemas operacionais convidados. Como resultado dos aprimoramentos de hardware que vieram a ocorrer, uma instância de um sistema operacional (MVS, VM com sistemas convidados ou outro) poderia ocupar uma Partição Lógica (LPAR) ao invés de um sistema físico inteiro.

Múltiplas instâncias do MVS podem ser organizadas e administradas coletivamente em uma estrutura denominada Systems Complex - Complexo de Sistemas ou Sysplex, apresentado em setembro de 1990. As instâncias interoperam através de um componente de software chamado Cross-System Coupling Facility (XCF) e um componente de hardware chamado Hardware Coupling Facility (CF), ou Integrated Coupling Facility (ICF) caso estejam locados no mesmo hardware de mainframe. Múltiplos sysplex podem ser interligados via um padrão de protocolo de redes, como a Systems Network Architecture - Arquitetura de Rede de Sistemas (SNA) da IBM, ou como recentemente, via TCP/IP. O sistema operacional z/OS (mais recente lançamento do MVS) também possui suporte nativo para executar aplicações POSIX.

Os arquivos no MVS são adequadamente denominados como datasets. Os nomes destes arquivos são organizados em catálogos, que são de fato arquivos VSAM.

O schema de codificação nativo do MVS e de seus periféricos é o Big Endian EBCDIC, mas com o tempo a IBM adicionou serviços acelerados por hardware para traduzir e dar suporte também à ASCII, Little Endian e Unicode.

Sistema de arquivo do MVS

Os nomes dos datasets (Data set name - DSN, termo para designar nomes de arquivos) são organizados em uma hierarquia na qual seus níveis são separados por pontos, como por exemplo "DEPT01.SIS01.PROJ01.ARQ01". Cada nível hierárquico pode conter até 8 caracteres. O tamanho máximo para o nome do dataset é de 44 caracteres incluindo os pontos. Por convenção, os componentes separados por pontos são usados para organizar os datasets similares em diretórios de outros sistemas operacionais. Por exemplo, existem programas que possuem funcionalidades semelhantes às do Windows Explorer (porém sem a GUI e geralmente em modo de processamento batch): criar, renomear ou excluir elementos e adicionar-lhes conteúdo. Porém, diferente de muitos outros sistemas, estes níveis hierárquicos não são de fato diretórios, mas apenas uma convenção de nomenclatura (como o sistema de arquivo inicial do Macintosh, onde a hierarquia de pastas é uma ilusão provocada pelo Finder). O TSO provê suporte a um prefixo padrão para arquivos (semelhante a "diretório atual"), e o RACF permite a configuração de controle de acesso baseado em padrões de nomenclatura, análogo aos controles de acesso de diretórios de outras plataformas.

Assim como os outros sistemas da família, os datasets do MVS são record-oriented - orientado à registros. O MVS herdou três principais características de seus predecessores:

• Datasets sequenciais são normalmente lidos como um registro por vez, do início ao fim.
• Em datasets BDAM (acesso direto), o programa aplicativo deve especificar a localização física do dado a ser acessado (geralmente especificando o deslocamento a partir do início do dataset).
• Em datasets ISAM, uma seção específica de cada registro é definida como uma chave que pode ser utilizada para obter registros específicos. A chave muitas vezes consiste de múltiplos campos, estes que devem ser necessariamente contíguos e na ordem correta, e os valores dessas chaves devem ser únicos (unique). Por isso um dataset IBM VSAM pode possuir apenas uma chave, equivalente ao conceito de chave primária de uma tabela de banco de dados relacional, apesar de não haver alguma equivalência de chave estrangeira.

Datasets sequencias e ISAM podem armazenar tanto registros de tamanho fixo quanto variável, e todos os registros podem ocupar mais que um volume de disco.

Todas estas características são baseadas na estrutura de disco VTOC.

Os primeiros sistemas de gerenciamento de bancos de dados da IBM utilizavam várias combinações de datasets ISAM e BDAM, sendo o uso de BDAM mais comum para o armazenamento de dados e ISAM para índices.

No início dos anos 70, os sistemas operacionais da IBM com suporte à memória virtual apresentaram um novo componente de gerenciamento de arquivos, VSAM, que proporcionava recursos similares:

• Entry-Sequenced Datasets - Datasets Sequenciados por Registro (ESDS) proveem recursos similares aos oferecidos tanto pelos datasets sequenciais como BDAM, uma vez que eles podem ser lidos tanto do início como do fim ou ainda especificando o deslocamento desejado a partir do início.
• Key-Sequenced Datasets - Datasets Sequenciados por Chaves (KSDS) são uma atualização do ISAM: permitem chaves secundárias com valores não únicos (non-unique) e que podem ser formadas por campos não contíguos e em qualquer ordem. Estes datasets diminuíram em muito os problemas de performance causados pelo estouro de registros no ISAM, e também reduziram o risco de uma falha de software ou hardware durante uma atualização de índice corromper todo o índice.

Estes formatos VSAM tornaram-se a base dos sistemas de gerenciamento de bancos de dados da IBM, IMS/VS e DB2, sendo o uso de ESDS mais comum para o armazenamento de dados e KSDS para índices.

O VSAM também incluiu um componente de catálogo utilizado pelo catálogo mestre do MVS.

Datasets particionados - Partitioned Datasets (PDS) eram datasets sequenciais subdivididos em membros que poderiam ser processados individualmente como datasets sequenciais. O uso mais importante dos PDS foram para bibliotecas de programas, os administradores do sistema usavam um PDS principal como uma forma de alocar espaço em disco para um determinado projeto, e o time criava e editava membros conforme suas necessidades.

Grupos de Geração de Dados - Generation Data Groups (GDGs) foram originalmente projetados para dar suporte à procedimentos de backups grandfather-father-son: se um dataset fosse modificado, a versão alterada se tornava o filho, o filho anterior se tornava o pai, o pai anterior se tornava o avô e o avô anterior era excluído. Mas era possível configurar os GDGs para lidarem com muito mais que três gerações, de tal forma que algumas aplicações utilizavam os GDGs para coletarem dados de diversas fontes para alimentarem um programa, sendo que cada programa de coleta criava uma nova geração de um arquivo e o programa final lia todo o grupo como um simples arquivo sequencial (não especificando a geração pelo JCL).

As versões modernas do MVS, como o z/OS, também suportam sistemas de arquivo compatíveis com POSIX, fornecendo ainda recursos para integrar os dois sistemas de arquivo. Isto é, o sistema operacional consegue fazer com que um dataset do MVS apareça como um arquivo para um programa ou subsistema POSIX. Estes novos sistemas de arquivo incluem Hierarchical File System - Sistema de Arquivo Hierárquico (HFS) (não confundir com o sistema de arquivo HFS da Apple) e zFS (não confundir com o sistema de arquivo ZFS da Sun).

História e modernidade

Hoje o MVS é parte do z/OS, versões antigas do MVS não são mais suportadas pela IBM e, desde 2007, somente as versões 64-bit do z/OS são suportadas. O z/OS possui suporte para execução de programas para MVS antigos de 24-bit e 31-bit juntamente com aplicações 64-bit.

MVS/370

MVS/370 é um termo genérico para todas as versões do sistema operacional MVS anteriores à MVS/XA. A arquitetura System/370, à época de lançamento do MVS, suportava apenas endereços virtuais de 24-bits, logo a arquitetura do sistema operacional MVS/370 é baseada em endereços de 24-bits. Devido a este tamanho de endereço, os programas executados sob o MVS/370 possuem, cada um, 16MB de armazenamento virtual contíguo à sua disposição.

MVS/XA

O MVS/XA ou Multiple Virtual Storage/Extended Architecture - Armazenamento Virtual Múltiplo/Arquitetura Estendida foi uma versão do MVS que possuía suporte à arquitetura 370-XA, a qual expandia o espaço de endereços de 24 bits para 31 bits, provendo 2GB de área endereçável de memória. Também possuía um modo de suporte à endereçamento legado de 24 bits para aplicações antigas, sendo que os primeiros 24 bits na memória eram utilizados por tais aplicações e os 8 bits restantes para outros propósitos.

MVS/ESA

O MVS/ESA ou MVS/Enterprise System Architecture - MVS Arquitetura de Sistemas para Negócios foi uma versão inicialmente denominada como MVS/SP Versão 3 lançada em fevereiro de 1988. Foi substituída pelo OS/390 em 1995 e, mais tarde, pelo z/OS.

O MVS/ESA Open Edition foi uma atualização à versão 4 release 3 do MVS/ESA anunciada em fevereiro de 1993 com suporte a POSIX e outros padrões. Enquanto a primeira versão possuía somente a certificação de conformidade do National Institute of Standards and Technology - Instituto Nacional de Padrões e Tecnologia (NIST) para o Federal Information Processing Standard - Padrão Federal de Processamento de Informações(FIPS) 151, as versões seguintes foram certificadas em níveis maiores e por outras organizações, como X/Open e sua sucessora, The Open Group. Essa versão incluiu por volta de 1 milhão de novas linhas de código, que proveram um shell API, utilitários e uma interface de usuário estendida. Lidava com um sistema de arquivo hierárquico proveniente do DFSMS (Data Facility System Managed Storage). O shell e os utilitários são baseados nos produtos InterOpen da Mortice Kerns. Especialistas independentes reconheceram que o sistema estava em conformidade com mais de 80% dos sistemas abertos, mais que muitos sistemas Unix. O suporte a DCE2 foi anunciado em fevereiro de 1994, e muitas ferramentas de desenvolvimento de aplicações em março de 1995. Em meados de 1995, a IBM passou a parar de se referir à OpenEdition como uma entidade à parte, porquanto todos os recursos abertos se tornaram parte padrão do sistema MVS/ESA SP versão 5 release 1. No projeto do OS/390 surgiram os UNIX System Services - Serviços de Sistema UNIX, que permaneceram inclusive no recente sistema z/OS.

Sistemas operacionais intimamente relacionados

As fabricantes japoneses de mainframes Fujitsu e Hitachi diversas vezes obtiveram ilegalmente o código fonte e a documentação interna do MVS em um dos maiores casos de espionagem industrial do século 20. Ambas empresas se basearam fortemente nos códigos da IBM para o desenvolvimento do MSP e do VOS3, sistemas da Fujitsu e Hitachi respectivamente, estes que foram amplamente divulgados em seu país e conquistaram um pedaço substancial da base de mainframes instalada, não só no Japão mas também em certos graus em outros países, notavelmente na Austrália. Até mesmo bugs e erros de ortografia da documentação da IBM foram fielmente copiados. A IBM cooperou com o Federal Bureau of Investigation (FBI) em uma operação para descobrir a aquisição ilegal de tecnologias de hardware de mainframe e do MVS por parte destas empresas, investigações estas que datam do início da década de 80 e que implicaram gerentes seniores de companhias e até alguns oficiais japoneses do governo. A empresa Amdahl, porém, não estava envolvida com a Fujitsu no roubo de propriedade intelectual da IBM: todas as formas de comunicação da Amdahl para a Fujitsu foram através das especificações da Amdahl somente (Amdahl Only Specifications), as quais foram escrupulosamente expurgadas de qualquer IP IBM ou quaisquer referências a este.

Subsequente às investigações, a IBM obteve pagamentos multimilionários das empresas Fujitsu e Hitachi, coletando frações substancias dos lucros de ambas durante muitos anos. Relatos confiáveis indicaram que tais pagamentos excederam o valor de US$500.000.000,00. Com o tempo, as três empresas concordaram em se unir em diversos empreendimentos. Por exemplo, em 2002 a Hitachi colaborou no desenvolvimento do modelo de mainframe z800 da IBM.

Devido a este histórico, os sistemas MSP e VOS3 são propriamente classificadas como derivações do MVS, e muitos fabricantes terceiros que desenvolviam softwares compatíveis com MVS também poderiam produzir versões compatíveis com MSP e VOS3 com pouca ou, até mesmo, nenhuma modificação.

Quando a IBM apresentou a sua linha de mainframes de 64 bits z/Architecture em 2000, apresentou também o sistema operacional de 64 bits z/OS, o sucessor direto do OS/390 e do MVS. A Fujitsu e a Hitachi optaram por não licenciar a arquitetura nova da IBM para seus sistemas operacionais baseados no MVS e hardware de seus mainframes, logo, apesar de ainda receberem suporte de seus fabricantes, seus mainframes ainda permanecem em grande parte com as limitações de arquitetura da época. Uma vez que o z/OS ainda suporta aplicações e tecnologias da era MVS - de fato o z/OS contém grande parte dos códigos do MVS, embora tenha recebido grandes aperfeiçoamentos e melhorias sob décadas de evolução - as aplicações e procedimentos operacionais executados no MSP ou no VOS3 podem migrar facilmente para o z/OS muito mais facilmente do que para qualquer outro sistema operacional.

Comandos básicos de MVS

• D ASM: Display do percentual de paginação.
• D A,ALL: Display dos jobs, stc e monitores ativos, mostrando os addr space de cada um.
• D A,L: Display dos jobs, stc e monitore ativos.
• D C,*: Display somente da console que esta usando.
• D C: Display de todas as consoles.
• D C,CN=xx: Display de uma determinada console.
• D D: Display da área de dump.
• D D,E: Display da área de dump mostrando erro.
• D D,T: Display da área de dump mostrando o título.
• D GRS,C: Display para verificação se não existe contenção no sistema.
• D M: Display dos status dos paths e das cpus.
• D M=DEV(xxx): Display do device xxx.
• D M=CHP(xx): Display do chipd xx.
• D MPF: Display de todas as mensagens suprimidas pelo sistema.
• D PFK: Display das PFKS definidas no sistemas.
• D R,L: Display dos replays pendentes.
• D R,U: Display das unidades de fitas pendentes.
• D SMF: Display das áreas de SMF (Contabilização do sistema).
• D T: Data Juliana e horário.
• D TS,L: Display de quem esta usando o tso.
• D U,xxx,ONLINE: Display de um endereço online.
• D U,xxx,ONLINE,,9999: Display dos endereços online atá 9999.
• D U,xxx,ALLOC,,99: Display do que esta allocando o end. xxx.
• DS P,xxx,yy: Display do cache, serve para saber se o end. esta pinado.
• DD CLEAR,DSN=ALL: Limpar área de dump cheia.
• D TCPIP,,T,CONN IPADDR: (endereço do micro do cliente).
• LUNAME: endereço VTAM: associado com a sessao de telnet.
• APPLID: aplicação em sessão com o micro.
• D TCPIP,,T,PROF,PROF=ALL TOTAL USERS: número de sessões ativas de telnet.
• D M=CPU: Display de qual CPU sistema está sendo processada.
• K: Limpa toda a tela da console.
• K A,NONE: Display de normal de uma tela.
• K A,4,6: Cria mais duas áreas de dysplay na console.
• K C,A,ID=xxx: Cancela mensagem de ação no 'D R,L' de id=xxx.
• K C,E,ID=xxx: Cancela mensagem eventual no 'D R,L' de id=xxx.
• K C,I,ID=xxx: Cancela mensagem imediata do 'D R,L' de id=xx.
• K E,D: Deleta área de display criada.
• K S,DEL=R/N/RDx: Define a rolagem da tela, R= lib. todas as msg da tela, N= prende as msg da tela, RD= prende somente as msg em Highlight e as não highlight sobem.
• K N,PFL=(XX,CMD='msg'): Define comando para ser executado em PFK's.
• K Q: Deleta todas as msg que estão paradas no buffer da console.
• K Q,L=xx: Deleta todas as msg que estão paradas no buffer da console indicada xx.
• K V,USE=FC,LEVEL=(R,I,CE,E,IN) [/color]: Comando para fazer definições das mensagens da console.

Referências

• Bob DuCharme: "The Operating Systems Handbook, Part 06: MVS" (disponível online aqui)
• IBM (June, 1978), OS/VS2 MVS Overview, First Edition, GC28-0984-0.