tinycobol/tutorials/CBL2COB/todo.txt

223 lines
10 KiB
Plaintext

# 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 <arquivo> - Abertura.
(7)* Copybook <arquivo> - Fechamento.
- Onde:
(7). Col 7.
<arquivo>. 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.