preparação é muito importante porque um dado recebido de forma inadequada pode comprometer todo o restante do processo. Se um valor monetário for lido incorretamente, o cálculo poderá sair errado. Se um nome for cortado porque o campo tem tamanho insuficiente, o cadastro poderá ficar incompleto. Se um código for tratado como número quando deveria ser apenas uma identificação, a lógica do sistema poderá gerar confusão.

Depois da entrada, vem o processamento. O processamento é o momento em que o programa realiza ações sobre os dados recebidos. Essas ações podem ser cálculos, comparações, movimentações de valores, verificações, classificações ou qualquer operação necessária para transformar as informações iniciais em um resultado útil.

Em um programa de folha de pagamento, o processamento pode calcular descontos, somar benefícios e chegar ao salário líquido. Em um sistema de cobrança, pode verificar se uma parcela está atrasada e calcular juros. Em um controle de estoque, pode subtrair a quantidade vendida da quantidade disponível. Em um cadastro de clientes, pode organizar os dados recebidos e preparar uma mensagem de confirmação.

O processamento é, portanto, a parte em que a lógica do programa aparece de maneira mais evidente. É nesse momento que as regras do mundo real são transformadas em instruções. Uma regra administrativa como “aplicar desconto de 6% para quem utiliza vale-transporte” precisa ser convertida em cálculo. Uma regra como “bloquear cliente com saldo negativo acima do limite permitido” precisa ser convertida em comparação e decisão.

No COBOL, esse processamento acontece principalmente na Procedure Division. É ali que o programa executa as instruções necessárias. A Procedure Division pode movimentar dados de um campo para outro, realizar operações matemáticas, tomar decisões, repetir processos e organizar a sequência das ações. Enquanto a Data Division prepara os dados, a Procedure Division coloca esses dados em movimento.

Por fim, temos a saída de dados. A saída é o resultado produzido pelo programa após o processamento. Esse resultado pode aparecer na tela, ser impresso em um relatório, gravado em um arquivo, enviado para outro sistema ou armazenado para uso posterior. A saída é aquilo que torna visível o trabalho realizado pelo programa.

Em um sistema de folha de pagamento, a saída pode ser o salário líquido do funcionário. Em um sistema bancário, pode ser o saldo atualizado da conta. Em um sistema de estoque, pode ser um aviso de

que, pode ser um aviso de que determinado produto está abaixo da quantidade mínima. Em uma rotina de cobrança, pode ser o valor total da parcela com multa e juros.

É importante perceber que a saída precisa ser clara e útil. Um programa pode fazer o cálculo corretamente, mas se apresentar o resultado de forma confusa, o usuário ainda terá dificuldade para compreender a informação. Em sistemas empresariais, relatórios, mensagens e arquivos de saída precisam ser organizados, pois muitas decisões dependem deles.

A lógica de entrada, processamento e saída pode parecer simples, mas ela está presente em sistemas muito grandes e complexos. Mesmo programas usados por bancos, seguradoras, órgãos públicos ou grandes empresas seguem essa estrutura básica. A diferença é que, nesses ambientes, a quantidade de dados é muito maior e as regras de processamento são mais detalhadas.

Pense, por exemplo, no fechamento mensal de uma empresa. O sistema pode receber dados de vendas, pagamentos, despesas, impostos, folha de pagamento e movimentações bancárias. Depois, processa essas informações de acordo com regras contábeis e administrativas. Ao final, gera relatórios, demonstrativos e arquivos para outros departamentos. Embora o processo seja grande, ele continua seguindo a mesma lógica: entrada, processamento e saída.

Essa ideia ajuda o aluno iniciante a organizar o raciocínio. Antes de escrever um programa, é útil fazer três perguntas: quais dados o programa precisa receber? O que ele deve fazer com esses dados? Qual resultado ele deve apresentar? Essas perguntas simples ajudam a planejar melhor a lógica e evitam que o programador comece a escrever comandos sem entender o problema.

Em COBOL, esse planejamento é ainda mais importante porque a linguagem valoriza a organização. Como os dados são declarados de forma estruturada e os procedimentos ficam em uma parte específica do programa, o aluno precisa aprender a pensar antes de escrever. Um bom programa começa com a compreensão do problema, passa pela definição dos dados e só depois chega às instruções de processamento.

Um exemplo simples pode tornar essa lógica mais clara. Imagine um pequeno programa para calcular o valor final de uma compra com desconto. A entrada seria o valor original da compra e o percentual de desconto. O processamento seria calcular o valor do desconto e subtrair esse valor do total. A saída seria o valor final a pagar. Mesmo sem entrar em detalhes técnicos, já é possível entender o funcionamento

do desconto e subtrair esse valor do total. A saída seria o valor final a pagar. Mesmo sem entrar em detalhes técnicos, já é possível entender o funcionamento do programa.

Outro exemplo pode envolver uma rotina de aprovação de crédito. A entrada seria a renda do cliente, o valor solicitado e talvez informações sobre seu histórico. O processamento verificaria se os dados atendem aos critérios definidos pela empresa. A saída poderia ser uma mensagem informando se o crédito foi aprovado, recusado ou encaminhado para análise. Nesse caso, além de cálculos, o processamento envolveria decisões.

Em sistemas administrativos, é muito comum que a entrada venha de arquivos. Um arquivo pode conter centenas ou milhares de registros. Cada registro representa uma informação organizada, como um funcionário, um cliente, uma conta ou uma movimentação. O programa lê esses registros, processa cada um deles e gera uma saída. Esse tipo de rotina é bastante associado ao uso tradicional do COBOL.

Por exemplo, uma empresa pode ter um arquivo com todos os funcionários e seus salários. O programa COBOL pode ler cada registro, calcular descontos e benefícios, atualizar os valores e gerar um relatório final. Esse tipo de processamento é conhecido como processamento em lote, pois trabalha com um conjunto de dados, geralmente em grande quantidade, de forma organizada.

Mesmo quando o aluno ainda está estudando exemplos simples, é importante entender que esses exercícios representam situações maiores. Um cálculo com um funcionário pode se transformar em uma rotina para milhares de funcionários. Um cadastro de um cliente pode se transformar em um sistema de cadastro completo. Uma mensagem exibida na tela pode se transformar em um relatório empresarial. Por isso, os fundamentos precisam ser bem compreendidos desde o início.

A entrada de dados também exige responsabilidade. O programa deve estar preparado para receber informações compatíveis com aquilo que foi definido. Quando um campo espera um valor numérico, é necessário cuidado para que a informação recebida possa ser usada em cálculos. Quando um campo recebe texto, é preciso observar o tamanho e a finalidade desse dado. A qualidade da entrada influencia diretamente a qualidade da saída.

Existe uma expressão muito conhecida na área de tecnologia que resume essa ideia: se os dados de entrada forem ruins, os resultados também tendem a ser ruins. Um programa bem escrito não consegue produzir um resultado correto se as informações

recebidas estiverem erradas, incompletas ou mal formatadas. Por isso, a atenção à entrada de dados é parte fundamental do desenvolvimento.

O processamento também precisa ser coerente com as regras do negócio. Não basta que o programa execute comandos corretamente do ponto de vista técnico. Ele precisa representar de forma fiel a regra que a empresa deseja aplicar. Se a regra determina que o desconto seja calculado sobre o salário-base, o programa não pode calcular sobre outro valor. Se a multa deve ser aplicada apenas após o vencimento, o programa precisa respeitar essa condição.

Essa relação entre programação e regra de negócio é muito importante no COBOL. Como a linguagem é muito usada em sistemas corporativos, o programador precisa entender não apenas a linguagem, mas também o processo que está sendo automatizado. Um erro de interpretação pode gerar consequências práticas, como cobrança incorreta, pagamento errado ou relatório inconsistente.

A saída, por sua vez, deve ser pensada de acordo com quem irá utilizá-la. Um relatório para o setor financeiro pode precisar de valores detalhados. Uma mensagem para o usuário pode precisar ser simples e objetiva. Um arquivo enviado para outro sistema pode precisar seguir um formato específico. Assim, a saída não é apenas o fim do programa; ela é a forma como o resultado será comunicado.

Ao estudar entrada, processamento e saída, o aluno também começa a compreender a importância da sequência lógica. Um programa não pode apresentar um resultado antes de receber os dados necessários. Também não pode processar informações que não foram definidas. A ordem das etapas precisa fazer sentido. Primeiro, prepara-se a estrutura dos dados. Depois, recebem-se as informações. Em seguida, realiza-se o processamento. Por fim, apresenta-se o resultado.

Essa sequência ajuda a evitar erros comuns de iniciantes. Um erro frequente é tentar realizar um cálculo usando campos que ainda não receberam valores. Outro erro é exibir uma saída antes de finalizar o processamento. Também é comum esquecer de armazenar um resultado intermediário necessário para a etapa seguinte. Pensar em entrada, processamento e saída ajuda a organizar melhor cada passo.

Em um programa COBOL, a clareza desse fluxo facilita tanto o desenvolvimento quanto a manutenção. Quando outro profissional precisa entender o programa, ele pode procurar quais dados entram, o que é feito com eles e quais resultados são gerados. Essa análise é muito útil em sistemas legados,

nos quais a documentação pode estar incompleta ou desatualizada.

Para o iniciante, a melhor forma de praticar esse conteúdo é observar situações do cotidiano e tentar descrevê-las nesse formato. Uma compra no supermercado envolve entrada, como produtos e preços; processamento, como soma e aplicação de descontos; e saída, como o valor final da compra. Um boletim escolar envolve entrada, como notas e frequência; processamento, como cálculo de média; e saída, como aprovação ou reprovação. Uma conta bancária envolve entrada, como depósitos e saques; processamento, como atualização de saldo; e saída, como extrato ou saldo final.

Esse exercício mostra que a lógica da programação está presente em muitas atividades comuns. O COBOL apenas transforma essas etapas em uma linguagem organizada para o computador executar. Quando o aluno entende a lógica por trás do processo, os comandos passam a fazer mais sentido.

Nesta aula, o mais importante é compreender que um programa não deve ser pensado como um conjunto solto de instruções. Ele deve ser visto como um fluxo. Os dados entram, passam por uma transformação e geram um resultado. Essa visão simples é a base para conteúdos mais avançados, como decisões, repetições, leitura de arquivos e geração de relatórios.

Ao final desta aula, o aluno deve ser capaz de identificar, em um problema simples, quais são os dados de entrada, qual processamento precisa ser realizado e qual saída deve ser apresentada. Essa habilidade será fundamental para avançar nas próximas aulas do módulo, especialmente no estudo das estruturas de decisão e repetição.

A programação em COBOL, apesar de sua aparência formal, segue uma lógica muito humana: receber informações, analisá-las, aplicar regras e comunicar resultados. É exatamente isso que empresas fazem diariamente em seus processos administrativos. Por isso, aprender entrada, processamento e saída não é apenas aprender uma teoria de programação. É aprender a transformar atividades reais em sistemas organizados, confiáveis e úteis.

Referências bibliográficas

ASCENCIO, Ana Fernanda Gomes; CAMPOS, Edilene Aparecida Veneruchi de. Fundamentos da programação de computadores. São Paulo: Pearson.

MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para desenvolvimento de programação de computadores. São Paulo: Érica.

SEBESTA, Robert W. Conceitos de linguagens de programação. Porto Alegre: Bookman.

TANENBAUM, Andrew S. Organização estruturada de computadores. São

Paulo: Pearson.

DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Elsevier.

WILSON, Leslie B. COBOL estruturado. São Paulo: McGraw-Hill.

SAMMET, Jean E. Linguagens de programação: história e fundamentos. São Paulo: McGraw-Hill.

Aula 2 — Estruturas de decisão

Em programação, nem sempre um sistema segue um único caminho do começo ao fim. Muitas vezes, ele precisa analisar uma situação antes de escolher o que fazer. É nesse ponto que entram as estruturas de decisão. Elas permitem que um programa avalie uma condição e execute uma ação de acordo com o resultado encontrado. Em outras palavras, o programa deixa de ser apenas uma sequência fixa de instruções e passa a responder de forma lógica às situações apresentadas pelos dados.

No COBOL, as estruturas de decisão são especialmente importantes porque a linguagem é muito utilizada em sistemas administrativos, financeiros, bancários e empresariais. Esses sistemas trabalham com regras o tempo todo. Um cliente pode ter crédito aprovado ou negado. Uma conta pode estar ativa ou bloqueada. Um funcionário pode ter direito ou não a determinado benefício. Uma parcela pode estar em dia ou em atraso. Um produto pode estar disponível ou sem estoque. Todas essas situações exigem decisões.

Para compreender esse conceito, basta observar atividades comuns do cotidiano. Quando uma pessoa vai fazer uma compra e verifica se tem saldo suficiente, ela está tomando uma decisão. Se o saldo for suficiente, a compra pode ser realizada. Se não for, ela precisa escolher outra forma de pagamento ou desistir da compra. Um sistema computacional trabalha de modo semelhante, mas precisa que essa lógica esteja escrita de maneira clara e precisa.

A estrutura de decisão parte sempre de uma condição. Uma condição é uma pergunta que pode ser respondida como verdadeira ou falsa. Por exemplo: o salário é maior que determinado valor? A idade do cliente é igual ou superior a 18 anos? O saldo da conta é suficiente para o saque? A parcela está vencida? O produto está disponível em estoque? O programa avalia essa condição e, conforme o resultado, executa uma ação.

Essa ideia é simples, mas muito poderosa. Ela permite transformar regras de negócio em instruções computacionais. Quando uma empresa diz “se o pagamento estiver atrasado, aplicar multa”, essa frase precisa ser convertida em lógica de programação. O programa deve comparar a data de vencimento com a data de pagamento e, a partir dessa comparação, decidir se a

multa”, essa frase precisa ser convertida em lógica de programação. O programa deve comparar a data de vencimento com a data de pagamento e, a partir dessa comparação, decidir se a multa será aplicada ou não.

No COBOL, as decisões geralmente aparecem na Procedure Division, pois é nessa parte do programa que ficam as instruções executáveis. A Data Division prepara os campos necessários, como valores, datas, códigos e indicadores. Depois, a Procedure Division utiliza esses campos para comparar informações, aplicar regras e produzir resultados. Assim, os dados declarados anteriormente ganham movimento dentro da lógica do programa.

Uma estrutura de decisão simples acontece quando existe apenas uma condição principal e uma ação correspondente. Por exemplo, se o saldo do cliente for menor que o valor do saque, o sistema deve informar que a operação não pode ser realizada. Nesse caso, a decisão é direta: o programa verifica uma condição e executa uma ação se ela for verdadeira.

Já uma decisão composta ocorre quando há mais de um caminho possível. Em vez de apenas fazer algo quando a condição é verdadeira, o programa também precisa fazer outra coisa quando ela é falsa. Por exemplo, se o aluno atingiu a média mínima, será considerado aprovado; caso contrário, será considerado reprovado. Nesse tipo de situação, o sistema precisa tratar os dois resultados possíveis.

As decisões compostas são muito comuns em sistemas administrativos. Em uma rotina de concessão de desconto, por exemplo, o programa pode verificar se o cliente tem direito ao benefício. Se tiver, aplica o desconto. Se não tiver, mantém o valor original. Em uma rotina de estoque, pode verificar se a quantidade disponível atende à venda solicitada. Se atender, libera a venda. Se não atender, informa a falta do produto.

Também existem decisões com várias possibilidades. Em alguns casos, o programa precisa avaliar mais de uma condição antes de chegar ao resultado. Imagine um sistema de classificação de clientes. Um cliente pode ser classificado como comum, preferencial ou especial, dependendo do histórico de compras, do tempo de relacionamento e do valor médio movimentado. Nessa situação, o programa precisa analisar diferentes critérios para definir a categoria correta.

Esse tipo de decisão exige muito cuidado. Quanto maior o número de condições, maior a possibilidade de erro na lógica. O programador precisa pensar com calma sobre a ordem das verificações, os critérios usados e os possíveis resultados.

Uma condição mal colocada pode fazer com que o programa escolha um caminho errado, mesmo que os dados estejam corretos.

Um erro comum entre iniciantes é escrever condições confusas ou incompletas. Às vezes, o programador pensa apenas no caso mais evidente e se esquece das exceções. Por exemplo, ao criar uma regra para aprovar um saque, ele pode verificar apenas se o saldo é maior que o valor solicitado, mas esquecer de considerar se a conta está bloqueada. Nesse caso, o sistema poderia permitir uma operação que deveria ser impedida.

Outro erro frequente é não definir claramente o que deve acontecer quando a condição não é atendida. Um programa precisa tratar tanto o caminho positivo quanto o caminho negativo de uma decisão. Se uma pessoa não tem direito a determinado benefício, o que o sistema deve fazer? Apenas ignorar? Informar uma mensagem? Registrar o motivo? Manter o valor original? Essas respostas precisam estar claras na lógica.

Em sistemas empresariais, uma decisão mal formulada pode causar consequências sérias. Um desconto aplicado indevidamente pode gerar prejuízo. Uma cobrança feita de forma errada pode causar reclamações. Uma aprovação indevida de crédito pode criar risco financeiro. Um bloqueio incorreto de cadastro pode prejudicar o atendimento ao cliente. Por isso, estruturas de decisão não devem ser tratadas como detalhes técnicos, mas como partes essenciais da regra de negócio.

O programador precisa lembrar que toda decisão no sistema representa uma escolha feita pela organização. Quando o programa decide aplicar uma multa, conceder um desconto, aprovar um cadastro ou negar uma operação, ele está executando uma regra definida por alguém. Assim, antes de programar, é necessário entender bem a regra. Uma lógica correta depende de uma interpretação correta do processo.

Por exemplo, imagine uma empresa que oferece desconto para pagamentos antecipados. A regra pode parecer simples: se o cliente pagar antes do vencimento, recebe desconto. Mas algumas perguntas precisam ser respondidas. Quantos dias antes do vencimento? O desconto vale para qualquer cliente? Existe valor mínimo de compra? O desconto é percentual ou fixo? Pode ser acumulado com outras promoções? Sem essas respostas, a decisão no programa pode ficar incompleta.

Esse cuidado mostra que a programação não depende apenas de conhecer comandos. O profissional precisa saber conversar com as regras do negócio, interpretar situações e transformar informações em lógica. No COBOL, isso

é muito evidente porque muitos sistemas lidam com rotinas financeiras, fiscais, cadastrais e administrativas, áreas em que pequenas diferenças nas regras podem alterar bastante o resultado.

As comparações são fundamentais dentro das decisões. O programa pode comparar valores numéricos, textos, códigos, datas ou indicadores. Pode verificar se um valor é maior, menor, igual ou diferente de outro. Pode também combinar condições, como exigir que duas situações sejam verdadeiras ao mesmo tempo. Por exemplo, um benefício pode ser concedido apenas se o funcionário tiver mais de um ano de empresa e estiver com cadastro ativo.

Quando várias condições são combinadas, o programador deve ter ainda mais atenção. A diferença entre “e” e “ou” pode mudar completamente o resultado. Se a regra diz que o cliente precisa ter renda suficiente e cadastro aprovado, as duas condições devem ser atendidas. Mas se a regra diz que o cliente pode apresentar comprovante de renda ou declaração alternativa, basta uma das condições ser atendida. Confundir essas relações pode gerar decisões incorretas.

Outro ponto importante é a clareza dos dados usados na decisão. Uma condição só será confiável se os campos envolvidos estiverem bem definidos. Se o campo que guarda o status de um cadastro aceita valores mal padronizados, a decisão pode falhar. Por exemplo, se um cadastro ativo aparece como “A”, “ATIVO”, “Ativo” ou “1” em diferentes situações, o programa pode ter dificuldade para interpretar corretamente. Por isso, decisões dependem também de dados organizados.

A padronização ajuda muito. Quando uma empresa define que determinado campo usará sempre os mesmos códigos ou valores, o programa consegue tomar decisões com mais segurança. Um campo de situação do cliente, por exemplo, pode utilizar códigos fixos para ativo, bloqueado, cancelado ou em análise. Dessa forma, a lógica se torna mais previsível e menos sujeita a interpretações ambíguas.

As estruturas de decisão também são importantes para evitar erros de processamento. Um programa pode verificar se um valor é válido antes de fazer um cálculo, se um campo está preenchido antes de gerar um relatório ou se uma quantidade é suficiente antes de atualizar o estoque. Essas verificações funcionam como pontos de controle dentro do sistema.

Imagine um programa que calcula comissão de vendas. Antes de calcular a comissão, ele pode verificar se o valor da venda é maior que zero. Se o valor estiver zerado ou negativo, o sistema pode impedir o

cálculo e sinalizar que há um problema nos dados. Essa decisão evita que o programa produza um resultado sem sentido. Assim, as estruturas de decisão também contribuem para a segurança e a qualidade do processamento.

No aprendizado do COBOL, é útil pensar nas decisões como perguntas feitas pelo programa durante a execução. O programa pergunta: esta condição foi atendida? Este valor está dentro do limite? Este cadastro está ativo? Este pagamento está atrasado? Conforme a resposta, ele escolhe o próximo passo. Essa forma de pensar ajuda o aluno a construir a lógica de maneira mais natural.

Uma boa prática é escrever a regra em linguagem comum antes de transformá-la em programação. Por exemplo: “Se o salário-base for maior que determinado limite, calcular desconto; caso contrário, não aplicar desconto.” Depois disso, o aluno pode identificar quais campos serão usados, qual comparação será feita e qual resultado deverá ser produzido. Esse processo reduz a chance de erro porque organiza o raciocínio antes da escrita técnica.

As decisões também devem ser testadas. Não basta verificar apenas o caso em que tudo dá certo. É preciso testar diferentes possibilidades. Se uma regra envolve idade mínima de 18 anos, por exemplo, é importante testar uma idade menor que 18, exatamente 18 e maior que 18. Esses testes ajudam a verificar se a condição foi construída corretamente, especialmente nos limites da regra.

Os chamados casos de limite merecem atenção especial. Muitas falhas acontecem quando a condição está quase no ponto de mudança. Se um desconto vale para compras acima de R$ 500,00, o que acontece com uma compra exatamente de R$ 500,00? Ela recebe desconto ou não? A regra precisa deixar isso claro, e o programa precisa representar essa decisão corretamente. Pequenas diferenças entre “maior que” e “maior ou igual a” podem mudar o resultado.

Em sistemas financeiros, esse cuidado é ainda mais importante. Um cálculo de juros, uma cobrança de multa ou a liberação de crédito pode depender de comparações precisas. Se o programa considerar uma condição de forma errada, pode gerar valores incorretos para muitos clientes ao mesmo tempo. Por isso, decisões devem ser escritas, revisadas e testadas com responsabilidade.

Outro aspecto relevante é a legibilidade. Uma decisão pode até funcionar, mas se estiver escrita de maneira confusa, dificultará a manutenção. Em sistemas COBOL, que muitas vezes permanecem em uso por muitos anos, a clareza é essencial. Um profissional que

precisar revisar o programa no futuro deve conseguir entender por que determinada decisão foi tomada e qual regra ela representa.

Nomes claros para campos ajudam muito nesse processo. Uma condição envolvendo campos como SALARIO-BASE, VALOR-DESCONTO e SITUACAO-FUNCIONARIO é mais compreensível do que uma condição com nomes abreviados e pouco informativos. A escolha de bons nomes não é apenas uma questão estética; ela facilita a leitura, a revisão e a manutenção do sistema.

Também é importante evitar decisões desnecessariamente complexas. Quando uma regra é muito grande, pode ser melhor dividi-la em partes menores, organizando o raciocínio passo a passo. Essa prática facilita a identificação de erros e torna o programa mais didático. Em programação, clareza quase sempre é melhor do que excesso de compactação.

Ao estudar estruturas de decisão, o aluno deve perceber que elas estão presentes em praticamente todos os sistemas. Sem decisões, um programa apenas executaria sempre as mesmas ações, independentemente dos dados recebidos. Com decisões, ele passa a responder às diferentes situações que aparecem na prática. Isso torna o sistema mais útil, mais inteligente e mais próximo das necessidades reais da organização.

No contexto do COBOL, as decisões ajudam a transformar rotinas administrativas em programas confiáveis. Uma regra de aprovação, uma verificação de saldo, uma análise de atraso ou uma classificação de cadastro são exemplos de situações comuns que dependem desse recurso. Por isso, dominar as estruturas de decisão é um passo fundamental para avançar no estudo da linguagem.

Ao final desta aula, o aluno deve ser capaz de compreender o que é uma condição, reconhecer decisões simples e compostas, identificar comparações entre valores e perceber a relação entre decisões e regras de negócio. Também deve compreender que uma boa decisão depende de dados bem definidos, critérios claros e testes cuidadosos.

Mais do que aprender um recurso técnico, estudar estruturas de decisão é aprender a pensar como um sistema precisa pensar. O programa analisa informações, compara dados, verifica regras e escolhe caminhos. Quando essa lógica é bem construída, o resultado é um sistema mais seguro, mais coerente e mais alinhado às necessidades da empresa.

Portanto, as estruturas de decisão representam um dos pontos centrais da programação em COBOL. Elas permitem que o programa deixe de ser uma sequência rígida de comandos e passe a agir conforme as condições encontradas.

Para o iniciante, compreender esse funcionamento é essencial, pois praticamente toda aplicação real envolve escolhas. E programar bem essas escolhas é uma das habilidades mais importantes para criar sistemas confiáveis.

Referências bibliográficas

ASCENCIO, Ana Fernanda Gomes; CAMPOS, Edilene Aparecida Veneruchi de. Fundamentos da programação de computadores. São Paulo: Pearson.

MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para desenvolvimento de programação de computadores. São Paulo: Érica.

SEBESTA, Robert W. Conceitos de linguagens de programação. Porto Alegre: Bookman.

TANENBAUM, Andrew S. Organização estruturada de computadores. São Paulo: Pearson.

DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Elsevier.

WILSON, Leslie B. COBOL estruturado. São Paulo: McGraw-Hill.

SAMMET, Jean E. Linguagens de programação: história e fundamentos. São Paulo: McGraw-Hill.

Aula 3 — Estruturas de repetição e rotinas de cálculo

Em programação, existem situações em que uma ação precisa ser executada apenas uma vez. Por exemplo, exibir uma mensagem, calcular o valor final de uma compra ou verificar se um cliente possui saldo suficiente. No entanto, em muitos sistemas reais, especialmente nos sistemas administrativos, financeiros e empresariais, as tarefas precisam ser repetidas várias vezes. É nesse contexto que entram as estruturas de repetição.

As estruturas de repetição permitem que um programa execute o mesmo conjunto de instruções enquanto determinada condição for atendida ou até que uma situação específica aconteça. Elas são fundamentais porque os sistemas raramente trabalham com apenas um dado isolado. Uma empresa não calcula o salário de apenas um funcionário. Um banco não processa apenas uma conta. Um sistema de cobrança não verifica apenas uma parcela. Na prática, os programas precisam lidar com listas, registros, arquivos e grandes volumes de informações.

No COBOL, essa ideia é muito importante porque a linguagem foi amplamente utilizada em sistemas que processam dados em grande escala. Muitas rotinas feitas em COBOL envolvem leitura de arquivos, processamento de registros e geração de relatórios. Isso significa que o programa pode executar a mesma lógica para cada registro encontrado, repetindo cálculos, verificações e atualizações até que todos os dados tenham sido tratados.

Para compreender melhor, imagine uma empresa que possui mil funcionários e precisa calcular a folha de pagamento do

mês. Seria inviável escrever uma instrução separada para cada funcionário. O correto é criar uma lógica que leia os dados de um funcionário, calcule seus vencimentos e descontos, registre o resultado e depois repita o mesmo processo para o próximo funcionário. Essa repetição continua até que todos os registros tenham sido processados.

Essa lógica é simples de entender quando pensamos em tarefas do cotidiano. Uma pessoa que confere uma pilha de documentos faz algo parecido: pega o primeiro documento, verifica as informações, faz uma anotação, separa o documento e passa para o próximo. Ela repete a mesma sequência até terminar a pilha. O programa faz o mesmo, mas com dados organizados em campos, registros e arquivos.

As estruturas de repetição são muito úteis porque reduzem a repetição manual de comandos no código. Em vez de escrever várias vezes a mesma lógica, o programador escreve uma estrutura capaz de repetir as instruções de forma controlada. Isso torna o programa mais organizado, mais curto, mais fácil de entender e menos sujeito a erros.

No COBOL, uma das ideias mais associadas à repetição é o processamento de registros. Um registro pode representar um cliente, um funcionário, uma conta, uma parcela, um produto ou qualquer conjunto de informações relacionadas. O programa lê um registro, processa suas informações e depois passa para o próximo. Esse ciclo se repete até que não existam mais registros a serem tratados.

Esse tipo de processamento é bastante comum em rotinas chamadas de processamento em lote. No processamento em lote, um conjunto de dados é tratado de uma vez, geralmente sem a necessidade de interação constante do usuário. Um exemplo é o fechamento mensal de uma folha de pagamento. O sistema recebe os dados dos funcionários, processa todos eles e gera arquivos ou relatórios finais. Outro exemplo é a atualização de saldos bancários após um conjunto de movimentações.

Para que uma repetição funcione corretamente, é necessário definir com clareza quando ela começa, o que será repetido e quando deve terminar. Um dos erros mais comuns de iniciantes é criar uma repetição sem uma condição adequada de parada. Quando isso acontece, o programa pode continuar executando indefinidamente, gerando o chamado laço infinito. Em sistemas reais, esse tipo de erro pode travar uma rotina, atrasar processamentos e causar problemas operacionais.

Por isso, toda estrutura de repetição precisa ter controle. O programa deve saber exatamente qual condição

permite a continuidade e qual condição encerra o processo. Em uma rotina de leitura de arquivo, por exemplo, a repetição pode continuar enquanto houver registros disponíveis. Quando o fim do arquivo for encontrado, o programa deve parar a leitura e seguir para a próxima etapa, como emitir um relatório final ou apresentar totais acumulados.

Além da condição de parada, outro elemento muito usado em repetições é o contador. Um contador é um campo numérico usado para contar quantas vezes determinada ação aconteceu. Em uma rotina de cadastro, ele pode contar quantos clientes foram processados. Em uma folha de pagamento, pode contar quantos funcionários tiveram salário calculado. Em um relatório de estoque, pode contar quantos produtos foram analisados.

O contador geralmente começa com valor zero e aumenta a cada repetição. Essa prática ajuda o sistema a acompanhar o andamento do processamento. Ao final, o programa pode informar, por exemplo, que foram processados 500 registros, 40 clientes estavam inadimplentes ou 25 produtos estavam abaixo do estoque mínimo. Essas informações são úteis para conferência e controle.

Outro conceito importante é o acumulador. Enquanto o contador registra quantidades, o acumulador soma valores. Em um sistema de vendas, o acumulador pode guardar o total vendido no dia. Em uma folha de pagamento, pode somar o total bruto, o total de descontos e o total líquido. Em uma rotina de cobrança, pode acumular o valor total das parcelas em atraso.

A diferença entre contador e acumulador é simples, mas essencial. O contador normalmente aumenta de um em um, registrando ocorrências. O acumulador soma valores que podem variar. Se um programa processa várias vendas, o contador pode indicar quantas vendas foram realizadas, enquanto o acumulador indica o valor total dessas vendas. Os dois recursos costumam trabalhar juntos em relatórios e fechamentos.

As rotinas de cálculo, por sua vez, são trechos do programa responsáveis por realizar operações matemáticas ou financeiras. Elas podem calcular descontos, impostos, juros, totais, médias, saldos, comissões, multas ou qualquer outro valor necessário ao sistema. Em COBOL, essas rotinas são muito presentes porque a linguagem foi criada para resolver problemas de negócios, nos quais os cálculos administrativos são constantes.

Um exemplo simples é o cálculo de salário líquido. O programa pode receber o salário-base, somar adicionais, subtrair descontos e chegar ao valor final. Se essa lógica for

aplicada a vários funcionários, ela será executada repetidamente. Assim, as estruturas de repetição e as rotinas de cálculo se complementam: a repetição percorre os registros, e a rotina de cálculo transforma os dados de cada registro em resultado.

Outro exemplo é o cálculo de estoque. Para cada produto, o programa pode verificar a quantidade atual, subtrair as vendas realizadas, somar entradas de mercadoria e calcular a nova quantidade disponível. Se a quantidade final ficar abaixo de um limite mínimo, o sistema pode sinalizar a necessidade de reposição. Nesse caso, a rotina envolve repetição, cálculo e decisão.

É importante notar que uma rotina de cálculo deve ser clara e bem-organizada. Em sistemas empresariais, muitos cálculos representam regras importantes. Um desconto aplicado incorretamente, uma comissão calculada de forma errada ou um saldo atualizado sem precisão pode causar prejuízos e retrabalho. Por isso, o programador precisa compreender a regra antes de transformá-la em instrução.

Antes de criar uma rotina de cálculo, é recomendável escrever a regra em linguagem comum. Por exemplo: “calcular o desconto multiplicando o salário-base pelo percentual definido”. Depois disso, o programador identifica quais campos serão usados, onde o resultado será armazenado e em que momento o cálculo será executado. Essa preparação reduz erros e torna a lógica mais compreensível.

Em COBOL, os campos numéricos precisam ser definidos corretamente para que os cálculos funcionem de maneira adequada. Valores financeiros, por exemplo, exigem atenção às casas decimais. Uma rotina de cálculo que trabalha com salários, juros ou parcelas não pode ignorar centavos. Pequenas falhas na definição dos campos podem gerar resultados incorretos, principalmente quando o processamento envolve muitos registros.

Imagine uma empresa que calcula o desconto de R$ 0,10 a menos para cada funcionário por erro de arredondamento. Em um único caso, o valor pode parecer pequeno. Mas, se a empresa tiver milhares de funcionários e o erro se repetir todos os meses, o problema se torna significativo. Esse exemplo mostra por que cálculos em sistemas corporativos exigem precisão e cuidado.

Outro erro comum em rotinas de cálculo é não inicializar corretamente os campos usados como contadores e acumuladores. Inicializar significa definir um valor inicial antes do processamento. Se um acumulador começa com um valor antigo ou indefinido, o total final pode sair errado. Por isso, antes de iniciar

uma repetição, o programa deve preparar os campos que serão usados ao longo do processo.

Por exemplo, se um programa vai somar o valor total de vendas do dia, o campo de total deve começar em zero. A cada venda processada, o valor da venda é somado ao acumulador. Ao final, o acumulador conterá o total correto. Se ele não for zerado no início, poderá trazer lixo de memória, valor anterior ou resultado indevido, comprometendo toda a saída do programa.

As estruturas de repetição também exigem atenção à ordem das instruções. Em uma rotina que lê registros, processa dados e depois lê o próximo registro, a sequência precisa estar bem-organizada. Se o programa esquecer de avançar para o próximo registro, poderá processar sempre a mesma informação. Se avançar antes de processar, poderá pular dados. Se encerrar a repetição cedo demais, deixará registros sem tratamento.

Essa organização mostra que repetir não significa simplesmente fazer a mesma coisa várias vezes. Significa controlar cuidadosamente o fluxo do programa. O programador precisa saber onde a repetição começa, quais ações pertencem ao ciclo, quais campos são alterados a cada passagem e qual condição determina o fim do processo.

Em sistemas COBOL, a repetição costuma estar relacionada à geração de relatórios. Um relatório pode listar todos os funcionários de uma empresa, todos os clientes inadimplentes, todos os produtos em estoque ou todas as movimentações de um período. Para gerar esse tipo de saída, o programa precisa percorrer os registros, selecionar as informações relevantes, calcular totais e organizar a apresentação.

Um relatório bem construído depende de dados corretos e de processamento adequado. Se a repetição não percorrer todos os registros, o relatório ficará incompleto. Se o acumulador não somar corretamente, o total ficará errado. Se uma condição for mal aplicada, registros indevidos poderão aparecer ou registros importantes poderão ser omitidos. Por isso, repetição, cálculo e decisão trabalham juntos em muitas rotinas.

Outro ponto importante é evitar duplicação desnecessária de lógica. Quando uma mesma operação precisa ser realizada várias vezes, é melhor organizá-la de forma reutilizável dentro do programa. Isso facilita a manutenção. Se uma regra de cálculo mudar, o programador poderá ajustar a lógica em um ponto mais claro, em vez de procurar várias cópias espalhadas pelo código.

A manutenção é uma preocupação constante em sistemas COBOL. Muitos programas permanecem em uso por

anos e são alterados por diferentes profissionais. Se uma rotina de repetição ou cálculo estiver confusa, a chance de erro em futuras mudanças aumenta. Por isso, escrever de forma clara é uma atitude de responsabilidade profissional.

Nomes bem escolhidos ajudam muito nesse processo. Campos como TOTAL-VENDAS, QUANTIDADE-REGISTROS, VALOR-DESCONTO e SALARIO-LIQUIDO tornam a lógica mais compreensível. Quando o nome do campo indica sua finalidade, o programa se torna mais fácil de ler. Isso é especialmente importante em repetições, nas quais vários campos podem ser atualizados a cada ciclo.

Também é importante testar as repetições com diferentes quantidades de dados. Um programa deve funcionar corretamente quando houver muitos registros, poucos registros ou até nenhum registro a processar. Esse último caso é frequentemente esquecido. Se um arquivo estiver vazio, o programa deve saber lidar com a situação sem gerar erro, total incorreto ou mensagem confusa.

Os testes ajudam a verificar se a repetição inicia corretamente, se processa todos os dados esperados e se encerra no momento certo. Também permitem conferir se contadores e acumuladores estão apresentando valores coerentes. Em sistemas administrativos, essa conferência é indispensável, pois relatórios e cálculos podem influenciar decisões gerenciais e financeiras.

Para o aluno iniciante, uma boa forma de praticar é criar pequenos exemplos. Um exercício pode pedir o cálculo da média de notas de vários alunos. Outro pode simular a soma de vendas de uma loja. Outro pode processar uma lista de produtos e identificar quais estão abaixo do estoque mínimo. Esses exemplos ajudam a desenvolver o raciocínio sem exigir, inicialmente, sistemas complexos.

Com o tempo, o estudante percebe que a repetição é uma das ferramentas mais importantes da programação. Ela permite que o computador faça justamente aquilo em que ele é muito eficiente: executar tarefas repetitivas com velocidade e precisão. Porém, essa eficiência depende de uma lógica bem construída. Um erro repetido muitas vezes pode causar um grande problema. Por isso, o controle da repetição é tão importante quanto a repetição em si.

No contexto do COBOL, esse aprendizado tem ainda mais valor porque muitos sistemas escritos nessa linguagem trabalham com grandes massas de dados. Folhas de pagamento, arquivos bancários, relatórios de clientes, controle de parcelas, fechamento de estoque e movimentações financeiras são exemplos de rotinas em que a repetição

aparece de forma natural.

Ao final desta aula, o aluno deve compreender que estruturas de repetição permitem processar vários dados de forma organizada. Deve também reconhecer a função de contadores, acumuladores e rotinas de cálculo. Além disso, precisa perceber que uma repetição segura depende de inicialização correta, condição de parada bem definida, sequência lógica adequada e testes cuidadosos.

Mais do que aprender uma técnica, estudar repetição é aprender a pensar em escala. Um programa não deve funcionar apenas para um caso isolado. Ele deve ser capaz de lidar com conjuntos de dados e aplicar a mesma regra de forma consistente. Essa capacidade é essencial em sistemas empresariais, nos quais o volume de informações costuma ser grande e a precisão dos resultados é indispensável.

Portanto, as estruturas de repetição e as rotinas de cálculo formam uma base essencial para o desenvolvimento em COBOL. Elas permitem transformar dados repetidos em resultados organizados, cálculos confiáveis e relatórios úteis. Para o iniciante, dominar esses conceitos é um passo importante para compreender como sistemas reais processam informações de maneira contínua, segura e eficiente.

Referências bibliográficas

ASCENCIO, Ana Fernanda Gomes; CAMPOS, Edilene Aparecida Veneruchi de. Fundamentos da programação de computadores. São Paulo: Pearson.

MANZANO, José Augusto N. G.; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para desenvolvimento de programação de computadores. São Paulo: Érica.

SEBESTA, Robert W. Conceitos de linguagens de programação. Porto Alegre: Bookman.

TANENBAUM, Andrew S. Organização estruturada de computadores. São Paulo: Pearson.

DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Elsevier.

WILSON, Leslie B. COBOL estruturado. São Paulo: McGraw-Hill.

SAMMET, Jean E. Linguagens de programação: história e fundamentos. São Paulo: McGraw-Hill.

Estudo de caso — A folha de pagamento que quase fechou com erros

Na empresa fictícia Aliança Serviços Administrativos, o setor de tecnologia recebeu uma demanda urgente: criar uma rotina simples em COBOL para calcular alguns descontos da folha de pagamento. A regra parecia tranquila. O programa deveria ler os dados dos funcionários, verificar se cada um utilizava vale-transporte, calcular o desconto quando necessário e, ao final, apresentar um resumo com a quantidade de funcionários processados e o total de descontos aplicados.

A tarefa parecia pequena, mas envolvia três pontos

fundamentais estudados no módulo 2: entrada, processamento e saída de dados, estruturas de decisão e estruturas de repetição com rotinas de cálculo. Como acontece em muitos sistemas administrativos, um erro aparentemente simples poderia afetar vários registros de uma só vez.

A equipe iniciou o trabalho com os seguintes dados para cada funcionário: nome, salário-base e indicação de uso do vale-transporte. A regra era: se o funcionário utiliza vale-transporte, o sistema deve calcular um desconto de 6% sobre o salário-base; caso contrário, o desconto deve ser zero. Depois de processar todos os funcionários, o programa deveria mostrar quantos registros foram analisados e qual foi o valor total dos descontos.

O primeiro erro apareceu ainda na etapa de entrada de dados. O programador iniciante criou os campos necessários, mas não conferiu se todas as informações recebidas estavam completas. Em alguns registros, a indicação de uso do vale-transporte estava vazia. Em outros, aparecia escrita de formas diferentes, como “S”, “SIM”, “Sim” ou “sim”. O programa esperava apenas uma forma específica e, por isso, alguns funcionários foram tratados como se não utilizassem o benefício.

Esse erro mostra que a entrada de dados precisa ser pensada com cuidado. Não basta receber informações; é necessário garantir que elas estejam organizadas, padronizadas e compatíveis com o que o programa espera. Quando um campo aceita valores variados sem controle, a decisão pode falhar. Para evitar esse problema, a equipe definiu um padrão único: o campo de vale-transporte deveria aceitar apenas “S” para sim e “N” para não. Além disso, os registros incompletos passaram a ser sinalizados para conferência antes do cálculo.

O segundo erro ocorreu no processamento. O programa calculava corretamente o desconto de 6%, mas fazia isso para todos os funcionários, mesmo para aqueles que não utilizavam vale-transporte. O programador havia criado a fórmula do cálculo, mas esqueceu de aplicar a condição antes dela. Assim, a rotina tratava todos os registros da mesma forma, sem respeitar a regra de negócio.

Esse é um erro comum em programação: calcular antes de decidir. Em sistemas administrativos, nem toda regra deve ser aplicada a todos os casos. O programa precisa primeiro verificar a condição e só depois executar a ação adequada. Para corrigir a falha, a equipe reorganizou a lógica: primeiro o sistema analisaria se o funcionário utilizava vale-transporte; somente se a resposta fosse positiva o

desconto seria calculado. Caso contrário, o desconto receberia valor zero.

O terceiro erro surgiu na estrutura de decisão. A regra dizia que o desconto deveria ser de 6% sobre o salário-base, mas alguns membros da equipe levantaram uma dúvida: e se o salário-base estivesse zerado ou negativo por erro no cadastro? O programa não fazia nenhuma verificação e poderia gerar um resultado sem sentido. Embora esse caso não fosse esperado em uma folha correta, ele poderia acontecer por falha de digitação, importação incorreta de arquivo ou cadastro incompleto.

A equipe percebeu, então, que uma boa decisão não serve apenas para aplicar regras principais, mas também para evitar processamentos inválidos. Foi acrescentada uma verificação antes do cálculo: se o salário-base fosse menor ou igual a zero, o registro deveria ser marcado para revisão e não deveria entrar no total final. Essa mudança tornou a rotina mais segura e evitou que dados incorretos contaminassem o resultado.

O quarto erro apareceu na repetição. O programa deveria processar vários funcionários, um por vez, até terminar a lista. Porém, durante os testes, percebeu-se que o mesmo funcionário era processado repetidamente. O problema estava no controle da leitura dos registros: o sistema não avançava corretamente para o próximo funcionário. Com isso, a repetição poderia se tornar infinita ou gerar totais duplicados.

Esse erro mostra a importância de controlar bem o ciclo de repetição. Toda repetição precisa ter início, sequência e fim. O programa deve saber quando ler o primeiro registro, quando passar para o próximo e quando parar. Para evitar esse tipo de falha, a equipe revisou o fluxo: ler registro, verificar dados, aplicar decisão, calcular se necessário, acumular resultado e somente então avançar para o próximo registro.

O quinto erro envolveu o contador de funcionários processados. O programa contava todos os registros lidos, inclusive aqueles com erro de cadastro. No relatório final, aparecia a quantidade total de registros, mas não ficava claro quantos haviam sido calculados corretamente e quantos precisavam de revisão. O setor de Recursos Humanos, ao receber o relatório, ficou confuso, pois não sabia se todos os funcionários estavam realmente prontos para pagamento.

Para corrigir isso, a equipe criou dois controles separados: um contador para funcionários lidos e outro para funcionários processados com sucesso. Também foi criado um contador para registros com erro. Assim, a saída ficou mais

corrigir isso, a equipe criou dois controles separados: um contador para funcionários lidos e outro para funcionários processados com sucesso. Também foi criado um contador para registros com erro. Assim, a saída ficou mais transparente. O relatório passou a informar quantos registros foram encontrados, quantos foram calculados e quantos precisavam de conferência.

O sexto erro apareceu no acumulador. O campo responsável por guardar o total de descontos não foi inicializado corretamente. Em alguns testes, o total final aparecia maior do que deveria, porque o acumulador parecia carregar um valor anterior. Esse é um erro clássico em rotinas de cálculo: usar um campo de soma sem garantir que ele comece em zero.

Para evitar esse problema, a equipe definiu que todos os contadores e acumuladores deveriam ser inicializados antes do início da repetição. O total de descontos começaria em zero. A quantidade de funcionários processados começaria em zero. A quantidade de registros com erro também começaria em zero. Somente depois dessa preparação o programa iniciaria a leitura dos dados.

Outro problema importante surgiu na saída de dados. O sistema calculava as informações, mas apresentava apenas o valor total dos descontos. Não informava quantos funcionários haviam utilizado vale-transporte, quantos não utilizaram e quantos registros tinham inconsistência. O relatório era tecnicamente correto em parte, mas pouco útil para a equipe administrativa.

Esse erro mostra que a saída precisa ser pensada conforme a necessidade de quem usará a informação. Um programa não deve apenas produzir resultados; ele deve comunicar esses resultados de forma clara. Depois da revisão, o relatório passou a apresentar o total de funcionários lidos, o total de funcionários com desconto, o total de funcionários sem desconto, o total de registros com erro e o valor total dos descontos aplicados.

Durante a revisão, a equipe também percebeu um risco relacionado às casas decimais. Como o desconto era calculado sobre salário, era necessário tratar valores monetários com cuidado. Um campo mal definido poderia cortar centavos, arredondar indevidamente ou apresentar valores incorretos. Em uma única folha, o erro poderia parecer pequeno, mas, repetido em muitos funcionários, causaria diferença no fechamento.

Para evitar esse problema, os campos financeiros foram revisados. O salário-base, o valor do desconto e o total acumulado passaram a ser tratados como valores numéricos adequados para

cálculos monetários. A equipe também incluiu testes com salários de diferentes valores, inclusive com centavos, para conferir se o resultado permanecia correto.

Ao final do processo, a rotina ficou muito mais segura. O programa passou a seguir uma sequência lógica: receber os dados do funcionário, verificar se as informações estavam válidas, decidir se o desconto deveria ser aplicado, calcular o valor quando necessário, atualizar contadores e acumuladores, repetir o processo para o próximo registro e apresentar um relatório final claro.

O estudo de caso da Aliança Serviços Administrativos mostra que os erros mais comuns do módulo 2 não estão apenas na escrita dos comandos. Eles aparecem principalmente na falta de planejamento do fluxo. Receber dados sem padronização, aplicar cálculo sem decisão, repetir sem controle, acumular sem inicializar e apresentar saída incompleta são falhas que podem comprometer o funcionamento de uma rotina simples.

Para evitar esses erros, o programador iniciante deve pensar sempre em três perguntas: quais dados entram no sistema? O que deve ser feito com eles? Que resultado precisa ser apresentado? Depois, deve verificar quais decisões são necessárias, quais cálculos serão realizados e como a repetição será controlada.

Também é importante testar situações diferentes. Não basta testar apenas o funcionário que utiliza vale-transporte e possui salário correto. É preciso testar quem não utiliza o benefício, quem tem campo incompleto, quem possui salário inválido, quem aparece no primeiro registro, quem aparece no último e até o caso em que não há funcionários a processar. Esses testes ajudam a encontrar falhas antes que o sistema seja usado em uma situação real.

Esse caso também ensina que o COBOL, por ser muito usado em rotinas administrativas e financeiras, exige responsabilidade no tratamento das informações. Uma regra simples, como calcular 6% de desconto, pode afetar muitas pessoas quando aplicada em lote. Por isso, o programa precisa ser claro, controlado e confiável.

Ao concluir o módulo 2, o aluno deve perceber que entrada, processamento, saída, decisão e repetição não são conteúdos isolados. Eles trabalham juntos. A entrada fornece os dados. A decisão escolhe o caminho. O cálculo transforma valores. A repetição permite processar vários registros. A saída apresenta o resultado de forma útil.

No caso da folha de pagamento, a equipe aprendeu que um sistema bem construído não é aquele que apenas “roda”, mas aquele que

trata os dados com cuidado, aplica as regras corretamente e permite conferência dos resultados. Essa é uma das principais lições para quem está começando a programar em COBOL: a lógica precisa ser tão organizada quanto os dados que ela processa.

Parte superior do formulário

Parte inferior do formulário