BLIS/COBOL: Um sistema operacional escrito em COBOL
Sistemas operacionais normalmente são escritos em C e Assembler. Mas o que acontece quando alguém desenvolve um sistema operacional usando uma linguagem de alto nível, voltada para aplicações comerciais? Esse sistema operacional existiu.
E eu trabalhei com ele.
Efeitos da reserva de mercado
Aquela que ficou conhecida como Reserva do Mercado da Informática foi instituída por uma lei federal a partir da criação da SEI (Secretaria Especial de Informática) em 1979 e consolidada pela consolidada pela Lei nº 7.232, de 1984, conhecida como Lei da Informática. Seu objetivo declarado era estratégico: desenvolver uma indústria nacional de computação, reduzir a dependência tecnológica externa e formar mão de obra especializada em um setor considerado vital para a soberania do país.
Na prática, a política restringiu a importação de computadores de médio e grande porte de fabricantes como IBM e DEC, obrigando empresas brasileiras a recorrer a fornecedores nacionais. Isso deu origem a uma indústria que produzia máquinas “similares”, muitas vezes baseadas em engenharia reversa ou no licenciamento de tecnologias já obsoletas em seus países de origem.
A SISCO Sistemas e Computadores era uma dessas empresas. Ela produzia e comercializava no Brasil minis e superminis licenciados de uma empresa americana chamada Data General. Alguns desses equipamentos rodavam um sistema operacional chamado BLIS/COBOL, desenvolvido por uma empresa da Flórida chamada Information Processing Inc. (IPI).
O BLIS/COBOL era vendido como um “sistema operacional customizado para o COBOL”, mas era também o nome do compilador. A SISCO informava que o BLIS/COBOL era aderente ao padrão ANS 74. Na verdade, porém, alguns recursos disponíveis no COBOL desde 1968 simplesmente não existiam nesse compilador.
Quase não existe informação na internet sobre o SISCO MB-8000, seus sucessores MB-10000, MB-12000 e o BLIS/COBOL. Por isso o que vou comentar nesse artigo minha experiência direta com esses sistemas — e na memória possível de quem conviveu com eles no dia a dia.
O hardware
A máquina que eu usei era o SISCO MB-10000 (esse aí da foto). E a empresa tinha duas CPUs: A (produção) e B (desenvolvimento).
A configuração contava com quatro unidades de disco removível de 80MB. Como os sistemas eram grandes (pelo menos assim eu acreditava naquela época), nem todas as rotinas podiam ser executadas a qualquer hora do dia. Era preciso trocar os “pratos” para que os dados estivessem disponíveis para os programas que rodavam na janela noturna.
De vez em quando as cabeças de leitura e gravação aterrissavam nos pratos. Em muitos casos dava para salvar o disco (não o conteúdo), mandando para retífica, como qualquer motor de Chevette.
Os backups e a troca de informação com outras empresas era realizada por fita magnética. A unidade de fita do SISCO aceitava carretéis de 800, 1200 e 2400 pés, e a gente tinha que montá-los com a mão, tocando na parte magnetizável, o que fazia com que o carretel não durasse muito tempo. A fitoteca era enorme (pelo menos era assim que eu via).
Os sistemas eram predominantemente batch e quase tudo precisava ser impresso numa impressora de linha e entregue para usuários finais e para a equipe de desenvolvimento. Essa impressora usava uma cinta de aço que gostava de arrebentar no meio das impressões da madrugada, o que fazia com que o CPD tivesse que manter estoque de cintas de backup.
O Software
Era aqui que a coisa começava a ficar divertida.
O BLIS/COBOL tinha poucos utilitários:
- SUTIL: Apesar do nome servia para quase tudo: formatar disco, fazer backup, alterar configuração do sistema etc.
- SRTRUN: Usado para classificar arquivos. Um arquivo pequeno levava minutos; um arquivo grande levava horas.
- FILMOV: Usado para copiar arquivos em disco, de disco para fita ou de fita para disco.
- EDITOR: Acho que o nome era esse. Era um editor de linha que faz o VIM parecer a coisa mais amigável do mundo.
- COBOL: O compilador. Vou falar sobre ele mais adiante neste artigo.
Todos os utilitários tinham que ser usados com precisão de neurocirurgião. Qualquer descuido e parte do dia podia ser perdida. Por toda a empresa. Se o SRTRUN fosse cancelado por engano, ou por falha, um IPL teria que ser dado na máquina. Dependendo da hora, não era possível interromper a máquina com os usuários no ar. Então era manter o atendimento aos clientes ou abrir mão da classificação de arquivos (e, consequentemente, dos jobs) até que o IPL pudesse ser executado.
Job, inclusive, é uma força de expressão. Tudo no sistema era programa COBOL. Não havia linguagem para scripts. Logo, as tarefas eram detalhadas em um manual de produção que indicava a periodicidade da tarefa, a ordem de execução dos programas, os parâmetros que deveriam ser fornecidos, se precisava de fazer backup ou não após cada passo, o que fazer em caso de abend etc. E quem executava tudo isso eram os operadores, que se revezavam em turnos de 8 horas, 7 dias por semana, 24 horas por dia.
O compilador consumia CPU a ponto da queda de performance ser sentida pelos usuários. Por esse motivo, programadores não podiam compilar. Eles colocavam o nome do programa em uma fila de compilação, que era atendida pelo operador de plantão.
Algumas vezes, quando a fila estava grande, a gente colocava um programa na fila de compilação de manhã e pegava o resultado depois do almoço. Eventuais erros de compilação podiam fazer com que o dia fosse perdido. Para evitar que isso acontecesse, além do programador se apegar aos santos de sua devoção, era preciso imprimir o fonte em formulário contínuo (mesmo porque não havia outro), alterar o fonte a lápis, testar “na mesa” (o famoso teste chinês) e só então alterar o programa no terminal.
O COBOL
O BLIS/COBOL não tinha SORT, não tinha MERGE, não tinha SEARCH, não tinha COMPUTE, não tinha STRING nem UNSTRING. Qualquer coisa tinha que ser codificada com MOVEs, ADDs e PERFORMs.
Além disso, por conta da memória escassa, havia limitações sérias tanto em espaço ocupado pela DATA DIVISION quanto na quantidade de data names que o programa podia criar: o máximo – contando nomes de arquivos, registros, itens de grupo, itens elementares e parágrafos – era de 512; mais do que isso, dava erro de compilação. FILLER acho que era liberado, desde que não estourasse de espaço de memória permitido.
Lembro que a compilação podia levar horas, literalmente. E consumia tantos recursos que o programador não podia compilar seu próprio programa. A gente tinha que abrir uma “ordem de serviço” para que o operador de plantão compilasse para nós. Como a fila de compilação era única, era muito comum botar um programa para compilar de manhã e receber o resultado só depois do almoço, rezando para que não houvesse nenhum erro de compilação.
Os programas podiam processar arquivos sequenciais e indexados, que precisavam ter sido previamente criados no catálogo do disco por alguém autorizado.
Havia um banco de dados, chamado SABIÁ, que não era nem relacional nem hierárquico. SQL nem pensar: era possível acessar tabelas, inclusive selecionando campos, através de utilitários que, na verdade, eram programas escritos em COBOL fornecidos pela SISCO: DELET, READN, READR, UPDAT eram os nomes desses utilitários chamados via CALL para realizar as operações no banco de dados.
Se você tivesse a última versão impressa ao seu lado, era possível debugar o programa no terminal. Havia comandos para suspender a execução na linha cujo número você precisava conhecer e a partir daí verificar o conteúdo das variáveis.
Conclusão
Olhando em retrospecto, é tentador reduzir tudo isso a um conjunto de limitações técnicas impostas por uma fracassada tentativa de reserva de mercado. Mas a verdade é que ambientes como o BLIS/COBOL obrigavam o programador a pensar antes de digitar. Não tinha “roda aí pra ver se resolveu”.
Sem recompilação rápida, sem debugger gráfico, sem camadas de abstração confortáveis, cada linha escrita precisava ter propósito, e o programador deveria ser capaz de defender esse propósito até o dia do juízo final.
Paradoxalmente, foi nesse ambiente hostil que muitos aprenderam disciplina, leitura cuidadosa, responsabilidade sobre o que se coloca em produção e respeito pelo sistema como um todo. Talvez nem toda limitação técnica forme bons programadores — mas algumas, definitivamente, deixam marcas que nenhuma IDE moderna consegue apagar.
Se quiser ler mais um pouco sobre a época da programação a vapor, clique aqui.
