# Projeto Infocont ================== # Legenda deste TODO file ------------------------- #: Tópico finalizado. o: Tópico em aberto p/ discussão. -: Tópico em desenvolvimento. 1. Se um tópico inicial tiver o sustenido(#), ele está finalizado para mim, Hudson, entretanto, aberto para opiniões de outras pessoas. # cbl2cob.cob ------------- - Estudar como fazer o parsing da linha de comando. - Usar verbo "unstring" ou "inspect" para fazer o parsing dos verbos com o inspect, mais trabalho de vetores, porém mais testes(embora generalizados). Com o unstring, menos trabalho de vetores, porém menos testes generalizados e mais código. Sugestão por ora é usar unstring. - Como converter um fonte? - Como quebrar as frases? - Unstring de uma variável indexando esta variável a uma matriz. ex: unstring ws77-var delimited by ' ' into ws02-index(1) ws02-index(2) ws02-index(3)... end-unstring - O limite de indices é 65(Conforme desenvolvido pelo Daniel Mengarda - InfoCont Sistemas Integrados Ltda). - Como determinar o que modificar, vai ser apenas gerador, ou vai ser conversor? - Conversor: Converte(Modifica) frases já existentes. - Gerador: Gera novas frases a partir de frases existentes. - Acho que o cbl2cob terá as duas partes. - como traduzir uma frase? - Inspecionar a frase, para verificar se é necessário conversão ou geração, a partir de testes condicionais(verbo inspect). - Quebrar a frase, indexando os "pedaços" desta frase, para que possa ser lida ao ser feito um laço de repetição. (verbo unstring) - aonde pegar possíveis extensões do cobol? - qual verbo usar? inspect ou unstring, e quando? Inspect: Inspeção de frases. Unstring: Quebra de frases. - há mais verbos interessantes do que estes? Até o momento, não. - Distribuição. - Apenas um binário com várias bibliotecas embutidas dentro do binário. - Verificação dos arquivos - se existe arquivo de entrada ou não. - se pode criar arquivo de saída ou não. - Por último: Re-escrever o fonte. - comentar os itens. - otimizar os fontes, com procedures definidas. - definir ainda. É tudo imperativo, infinitivo ou o que? o Características do front-end. o Verifica se há switches erradas. o Verificação se há duplicação de arquivos(entrada e saída). o Verificação se há arquivo de entrada. o Pega variáveis com caminho absoluto ou caminho relativo o Tem a característica de separar o nome do arquivo do diretório (basename e path), sofistificação no front-end o As variáveis podem ser em qualquer tabulação o Tem características fixas: cbl2cob [opcoes] [-i arquivo de entrada] [-o arquivo de saida] o Switches de uso: o d: dialeto. o i: arquivo de entrada. o o: arquivo de saida. o v: saída verbosa. o V: versão. o h: ajuda. o Prepara switches para chamar o pré-processador. o Chama o pré-processador via call "system". o É chamado via call "system" para que o usuário possa escolher entre usar o pré-processador ou usar o front-end(que irá chamá-lo do mesmo jeito). o Há duas chamadas, uma para abrir os copybooks e outra para fechar os copy books. - Chama um scanner mediante o dialeto escolhido(dialeto+scanner.cob). (ex: mfscanner.cob) (Não implementado). - Chama um parser mediante o dialeto escolhido(dialeto+parser.cob) (ex: mfparser.cob) (Não implementado). # cbl2cobpp.cob --------------- - Pré-processador para processar os fontes. - Motivo: O verbo COPY permite que você insira um arquivo externo dentro de um programa fonte COBOL. Então, qual seria a melhor maneira de se converter um fonte desta maneira? - Idéias: Atualmente as possíveis idéias que me vieram, foram as seguintes: - Processar os copybooks individualmente, ou seja, o usuário os pré-processaria manualmente. Então quando o parser encontrasse uma linha com o verbo COPY, ele iria pular essa linha. - Quando o parser encontrasse uma linha com o verbo COPY, ele chamava um pré-processador, que abria o fonte, lia e o convertia. Seria chamada uma programa que faria isso, só iria ler e processar dados, mas seria um subprograma, então os dados iriam ser passados via linkage. - Seria criado um programa específico que iria criar um novo arquivo fonte COBOL, a partir de um arquivo fonte COBOL já existente, com algumas opções determinadas, como abertura ou fechamento de copybooks. Este programa seria separado e poderia ser chamado, ou via linha de comando ou pelo programa principal, através de uma chamada de sistema(Ou seja, os dados não seriam passados via linkage, mas por arquivos). A medida que fosse lendo o arquivo de entrada, ele iria gravando um arquivo de saída. Para os copybooks pré-processados, poderiam ser criados copybooks com o nome modificado, derivado do nome original. Acho esta a melhor decisão. - Poderia ser criado o programa fonte e seus copybooks, com um sufixo semelhante ao dialeto selecionado. ex: # fonte (arquivo de entrada e saida diferente) teste.cbl -> entrada teste.cob.mf -> intermediário teste.cob -> Saida # copybook (mesmo arquivo de entrada e saída) header.cpy -> entrada header.cpy.mf -> intermediario header.cpy -> saida - Particularidades do COPY. - Armazenamentos - Diretório local/remoto e/ou diretório de variável de ambiente. - Características. - entre aspas: COPY "workfile.cpy". (Suporta apenas este por enquanto) - sem aspas: COPY workfile.cpy. - sem extensão: COPY workfile. - Pré-processamento. - Como processar os fontes, traduzir o código sempre para minusculo ou dar a oportunidade do usuário escolher? - Não haverá escolha de case. O programa fonte será modificado apenas aonde houver geração ou conversão de frases. - Ao encontrar um verbo COPY. - Descobrir que tipo de característica e armazenamento ele tem. - No arquivo de saída, criar uma linha comentada, desta maneira: (7)* Copybook - Abertura. (7)* Copybook - Fechamento. - Onde: (7). Col 7. . Nome do arquivo. Deve ser mantidos as características. Nesta etapa, o objetivo é só pré-processar mesmo. - Novos Copybooks. (Não suportado ainda, talvez não seja necessário). - Devem ter um sufixo que diga que o arquivo é convertido, talvez seja até interessante usar uma extensão. Ou então eles poderiam ter o mesmo nome do copybook inicial, mas apenas com uma letra ou item diferenciando. # cblm2m -------- o Conversor de case. o Motivo: Esta rotina, poderia ser um pequeno programa apenas. Entretanto, se um usuário quiser apenas mudar a case do seus fontes, ele teria que re-adaptar o programa. Então achei melhor criar um pequeno programa, com um pequeno front-end, que facilite a vida do usuário. Isso não mudaria em nada o conversor, uma vez que eu poderia chamar o programa via call "system" e o usuário nem notaria que isso aconteceu. o Idéias: Estava pensando nas seguintes idéias: o O conversor não deve mudar o valor da cláusula PROGRAM-ID ou END-PROGRAM. o O conversor não deve mudar os ítens entre aspas. o Conclusão: Após ter desenvolvido o aplicativo, concluí que a melhor maneira para se mudar a case de um arquivo seria, durante o processo de pré-processamento, criar uma variável intermediária, e nesta variável intermediária, mudá-la para uma case(maiúscula, por exemplo) a a nível de testes de condição. Se houver tempo, talvez melhore este conversor, entretanto não será minha prioridade por agora. # Disclaimer o Criar disclaimer para o COBOL traduzido para o português. o Pegar no site da FSF ou conectiva o COPIA.pt_BR(COPYING) e a licença traduzida. o Seguir recomendações de Jorge Godoy e usar o disclaimer e o COPYING em inglês, devido a FSF não ter direitos legais no Brasil. # Padronização # Identification division. o Não vou colocar date-compiled, installation e security pois não vejo necessidade. Seria interessante o uso do remarks, porém ele não faz parte do COBOL 85. Então irei colocar um comentário sobre isso depois do date-written. o Achei viável a criação do nome cob2tc. Pensei primeiro em mf2tc, mas achei melhor generalizar, pois assim poderíamos criar uma switch para determinar qual tipo de dialeto será o arquivo de entrada. (t=[ARG]). Depois pensei em cob2tc, o COB seria para o fonte COBOL de qualquer dialeto e o TC, seria para o TC. Inicialmente soa como se fosse só do TC, mas como o TC seguiria os standards, provavelmente não haveria problema em colocá-lo. Também poderiámos colocar o nome como cbl2cob, pois assim seria bem genérico. O CBL representaria o fonte COBOL em diversos dialetos e o COB representaria o fonte COBOL regido pelo standard. Entretanto isso seria apenas para colocar um nome intuitivo, mas o usuário poderá colocar o fonte com qualquer extensão. Acho melhor o cbl2cob. o O fonte será desenvolvido em formato fixo, pois quero que ele fique bem intuitivo. Então, irei usar comentários fixos (*) na coluna 7 e comentários inline(*>) nas colunas posteriores a coluna 7. Será necessário então o uso da switch "-F" ao compilá-lo. # File section. o O tamanho do registro será de 256 posições. Estou seguindo como base a partir do gscreen e do scanner do TC(scan.c). Ou seria melhor colocar isso como uma switch do conversor? (s=[ARG]). Não concordo com a criação de uma switch, pois isso acarretaria a criação de uma série de perform's para fazer a leitura byte a byte do registro e poderia aumentar o tempo de conversão. # Prefixo para variáveis. o Prefixo inicial, o ws: working-storage section. o ss: screen section. o ls: linkage section. o Prefixo adicional, o Nivel da variável. o Nivel da variável, o Consecutivo: 01, 02, 03... # Verbos. o Indentação de 3 posicoes no perform. o Indentação de 4(ou 2) posicoes no evaluate. o Indentacao de 6 posicoes no when. o Indentacao de 2 posicoes no if.