PC Toledo

Enviado: **17 Nov 2013 19:22**

Bom, estamos aqui em um fórum de uma linguagem que fez e ainda faz historio, que é as linguagens baseadas em xBase, Clipper, Harbour, VFP e etc...
mas pq não falar de uma outra linguagem que fez e ainda faz sua historio ?
Cobol, uma linguagem que muitos aqui devem ter programado, e provavelmente se lembrem ainda, mas enfim... o cobol é uma linguagem que está em uso scalar positivo, pois, os bancos e todo o sistema de manejamento financeiro das empresas de porte gigante, são escritos em cobol, a IBM faz o processamento de alguns arquivos para bancos e etc... mas enfim, Cobol, ainda está mais vivo do que vocês pensam, veja o Micro Focus Visual Cobol, você é capaz de criar aplicativos em .net, windows forms, e até sites em Cobol, vejá um pequeno exemplo, de como verificar as informações do CEP em Cobol.NET

Código: Selecionar todos

       program-id. Program1 as "CepBusca.Program1".
       
       repository.
           class sConsole as "System.Console".

       working-storage section.
       01 xmlConn      string.
       01 dt           type System.Data.DataTable.
       procedure division.
           declare ds = new System.Data.DataSet.
           
           move ("http://cep.republicavirtual.com.br/web_cep.php?cep=@cep&formato=xml")::Replace("@cep", "87300000") to xmlConn.
           invoke ds::ReadXml(xmlConn).
           
           move ds::Tables[0] to dt.
           invoke sConsole::WriteLine("Logradouro: {0} {1}" dt::Rows[0][5]::ToString()::Trim() dt::Rows[0][6]::ToString()).
           invoke sConsole::WriteLine("Bairro: {0}" dt::Rows[0][4]::ToString()).
           invoke sConsole::WriteLine("Cidade: {0}" dt::Rows[0][3]::ToString()).
           invoke sConsole::WriteLine("UF: {0}" dt::Rows[0][2]::ToString()).
           
           goback.
           
       end program Program1.

E junto com as funções .net somos capaz de utilizar as funções normais do Cobol, como "PRINT", "PERFORM" e etc...

https://www.microfocus.com/product-down ... index.aspx

Bom, falando um pouco sobre a minha pessoa, sou especializado em Cobol pela IBM, mas o cobol que trabalhamos la, é o cobol procedural, padrão IBM z/OS, considero uma linguagem muito podereosa, e interessante, para grande porte é claro....

E ae, quais são suas experiencias com Cobol ?

Enviado: **19 Nov 2013 04:57**

Olá!

bencz escreveu:(...) o cobol é uma linguagem que está em uso scalar positivo (...)

Bem, creio que a demanda por profissionais COBOL esteja estagnada e confinada aos setores financeiros (bancos e suas financeiras, leia-se operadoras de cartões), seguradoras, companhias de telefonia, energia elétrica e água, entre outras poucas. Sobre o Microfocus COBOL, não tenho informações.

O tal "uso escalar positivo" talvez seja só aparência, devido a anúncios de cursos de COBOL, que cresceram ultimamente. Creio que estes cursos visam apenas incentivar os mais jovens a se capacitarem nesta tecnologia (tentando ocultar o estigma de "uma linguagem morta" do COBOL), para suprir a demanda existente. Afinal, muitos programadores COBOL já se aposentaram e até mesmo faleceram. Penso que podemos igualar o Clipper ao COBOL nos seguintes aspectos: recolocação difícil e a média salarial caiu muito. Quando aparece uma vaga, a concorrência é enorme e, dependendo do caso, consegue-se até uma boa negociação, baseada na experiência. Normalmente o quesito Clipper ou COBOL, é um dos últimos na série de requisitos para um processo seletivo. Essa é a realidade que os recém formados em cursos de COBOL enfrentam ao concluí-lo.

bencz escreveu:E ae, quais são suas experiencias com Cobol ?

Bem, pessoalmente, fiz meu curso de COBOL em 1976/1977. Trabalhei com ele até 1986 (Grupo Ultra). Mas, isso não vem ao caso...

A ideia que eu gostaria de suscitar é a seguinte:

que tal nos conhecermos melhor?

O que acham de fazermos um censo através deste, que é o maior fórum de xBase do Brasil e, quem sabe, do mundo? Montarmos um questionário ou banco de dados onde pudéssemos saber quantos somos, que perfis temos (quantos são empregados, quantos trabalham por conta própria), se frequentamos o fórum porque ainda trabalhamos com xBase ou frequentamos por interesse em apenas colaborar e nesse caso, para qual ferramenta migramos, etc... Analisar os cenários oferecidos pelo Harbour, xHarbour, bibliotecas gráficas. Analisarmos as tendências do mercado, criarmos uma lista de conhecimentos das metodologias, técnicas de desenvolvimento, conhecimentos de legislação, fiscal, trabalhista, enfim, as especialidades de cada um. Divulgar os produtos que cada um tem para vender e a exemplo do Projeto NFe do Atayde, mostrarmos o que podemos desenvolver, etc...

Sei que ficou uma mistureba danada mas, foi apenas um brain storm, a ser analisado, refinado...

O que acham?

Enviado: **21 Nov 2013 11:38**

Olá Bencz e Alexandre !

Bom encontrar vocês em área bem diferente onde às vezes trocamos ideias, ou seja, no Clipper.
Apesar de como falou o Alexandre a maioria de programadores COBOL estar aposentada ou quase, devemos ter muita gente
ainda trabalhando com a linguagem.
Também já varei noites resolvendo/escrevendo rotinas imensas em COBOL Cobra 305 e 540, nos anos 80.
Para a troca de experiências, acho que tenho algo a oferecer e já coloco-me à disposição.

Mas, enquanto isso, tenho um pedido.

Se vocês tiverem um tempinho, informem-me o que devo mudar em programas escritos em COBOL Interativo da COBRA, que
rodo com a ajuda do ISAM.

Nas telas, apesar de "horrendas" como diriam alguns, tudo OK.
Na época, usávamos impressora GLOBUS, 600 LPM.

O problema está no uso de impressoras, agora em USB, pois nos programas em .COB e depois convertidos para .INT a mesma era assim referida:

Código: Selecionar todos

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER. COBRA-500.
       OBJECT-COMPUTER. COBRA-500.
       SPECIAL-NAMES. DECIMAL-POINT IS COMMA.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT DISCO-ITENS ASSIGN TO DISK
               ORGANIZATION IS INDEXED
               RECORD KEY IT-CHAVE
               ACCESS MODE IS RANDOM.
               SELECT BTNS ASSIGN TO DISK
               ORGANIZATION IS INDEXED
               ACCESS MODE IS SEQUENTIAL
              RECORD KEY IS B-DATA.
           SELECT RESUMO ASSIGN TO DISK
               ORGANIZATION IS LINE SEQUENTIAL.
           SELECT IMPRESSORA ASSIGN TO PRINTER.

.....

       FD IMPRESSORA LABEL RECORD IS OMITTED.
       01 SAIDA.
           02 FILLER           PIC X.
           02 LINHA            PIC X(131).
...

Tem como utilizar impressoras padrão USB nesse tipo de programa ?
Já tentei desviar a impressão para arquivo em .PDF mas não tive exito.

Enviado: **22 Nov 2013 00:20**

Nossa, desconheço totalmente como fazer isto utilizando Cobol Cobra...
mas, se você utilizar o OpenCobol, tem varias formas, veja alguma delas: http://www.opencobol.org/archive/304.txt
http://opencobol.add1tocobol.com/#how-d ... -opencobol

MicroFocus: http://supportline.microfocus.com/examp ... p#Printing

Enviado: **22 Nov 2013 10:09**

Acho interessante vocês falarem:
A 20 anos atraz, 30 anos atraz eu escrevi muitos códigos cobol e etc...
ai eu penso, a 20 anos atraz, considerando hoje ( 22/11/2013 ) eu tinha apenas 11 meses e 7 dias de vida.

Enviado: **22 Nov 2013 11:48**

Oi, Bencz, "Você é incrível !" (É o seu lema, não é ?)

Obrigado pelas dicas de onde achar material de COBOL acessível (Open source)

Eu baixei o OpenCobol e vou dar um estudo nele para ver o que se dá para fazer com os fontes do COBOL Cobra Interativo, que
era muito melhor que o COBOL ANS da época.

Nos anos 80, o que sofríamos com a falta de equipamento você nem imagina, e, então, poder contar com o COBOL ao invés do
Assembler (que eu escrevia diretamente em hexadecimal dada a reduzida memória em disco) já foi um grande avanço.

Ele tinha um conjunto de 25 comandos, nenhuma função, "burrinho" ao extremo no tratamento de datas, igual ao DataFlex.

Mas gerava executáveis rápidos e nunca falhava, não havia corrupção de índice (pudera, só tinha UM).

A maior parte do processamento era consumida pelo utilitário ORDENA para gerar arquivos temporários a partir do arquivo mestre, com a técnica do "balance line".

E olha que nós já podíamos contar com discos rígidos de inacreditáveis 16MB removíveis (disco panela) !
Haviam birôs que trabalhavam com a fita magnética !

Realmente, Bencz, nos divertimos muito !

Enviado: **22 Nov 2013 14:02**

realmente, maravilhoso, o primeiro programa q escrevi em minha vida, eu tinha apenas 9 anos de idade, e foi em um CP 200, uma simples calculadora, que escrevi em Assembly, ainda tenho a fita K7 guardada, com esse meu primeiro programa...

escrever codigos de maquina, direto em hexa decimal, eu faço isso com frequencia, nos vompiladores que eu escrevo

sobre o OpenCobol, existem suas versoes para o Windows, que utiliza o compilador de C/C++ do visual studio, o OpenCobol é um FrontEnd do gcc, tal qual o harbour, primeiro ele compila p/ c e depois ele chama um compilador de c e assim gera o executavel

Enviado: **22 Nov 2013 15:47**

primeiro ele compila p/ c

Na verdade o [x]Harbour não compila para C. Ele apenas traduz os comandos da linguagem XBase para uma série de opCodes que são "empilhados" através de funções de empilhamento. Ao final, há uma chamada de função para invocar o executor da máquina virtual. Terminado esse processo tem-se um código fonte C. Ele então é compilado pelo compilador C de sua escolha, são ligadas as bibliotecas e daí vem o arquivo executável.

Aliás, essa é a razão pela qual ainda não existe (e provavelmente nunca existirá) uma versão do [x]Harbour para dotNet. Seria uma VM dentro de outra.

Enviado: **22 Nov 2013 16:45**

Provavelmente não existirá, mas não por isso, e sim porque o NET é da Microsoft, e é algo proprietário.
Tempos atrás postei aqui que dá pra configurar o Visual Studio pra qualquer linguagem, incluindo o próprio Harbour.
Até hoje nem isso não existiu.

Mas voltando ao Cobol, só usei no primeiro curso de programação, na época eram cartões perfurados, e não era acessível pra "brincar", então só deu pra usar no teste final do curso.
Eu gostava do estilo do cobol.
Mas pra esse Brasil de hoje, que altera as regras todo dia, acho que seria mais complicado ainda pra se usar Cobol.
Talvez isto é que o tenha derrubado: não era do tipo pra alterar toda hora.

Enviado: **22 Nov 2013 18:53**

o .net não é tão proprietario assim...
http://www.microsoft.com/en-us/download ... px?id=4917

A propria microsoft liberou o fonte do .net
alem disso, existe o Mono, que é o .net 100 open soure...

Enviado: **25 Nov 2013 09:15**

JoséQuintas escreveu:Provavelmente não existirá, mas não por isso, e sim porque o NET é da Microsoft

Não tem nada a ver. O fato é que seria uma VM dentro de outra VM. Se com uma tudo já é mais lento em função dessa natureza, imagine-a rodando dentro de outra. Aliás, esse é o argumento do Marcelo Lombardo, com quem conversei a esse respeito há alguns anos no falecido newsgroup do UOL. E ele trabalhou de perto com o pessoal do [x]Harbour (Ron Pinkas & Cia).

PS: Sei que vão dizer que o [x]Harbour é rápido, mas é certo que seria muito mais rápido se fosse código objeto. Nada que rode interpretado por uma VM será mais rápido que um código objeto que vai direto pro processador. Claro que, nos dias de hoje, essa preocupação já não faz mais tanto sentido. O hardware atual já atingiu um nível de velocidade muito bom. Hoje até BASICA fica rápido.

Enviado: **30 Nov 2013 17:22**

Bom, infelizmente estive internado des de qurta-feira, mas, durante este periodo, estive pensando sobre o desenvolvimento de um compilador de xbase para código objeto nativo de maquina, para ficar mais rapido..., bom, existe VARIAS E VARIAS formas para se fazer isso, e sim, é possivel, extremamente possivel...
https://drive.google.com/folderview?id= ... sp=sharing

Neste link, disponibilizei UMA SÉRIE de compiladores escritos nas mais diversas linguagens, e nele, existem alguns exemplos, onde a livraria da linguagem é escrita simplesmente em assembly, o compilador não gera um código objeto nativo diretamente, me refiro a OPCODES de maquina nativamente, ele apenas gera um código ASSEMBLY e depois chama um copmilador de assembly para compilar seu código, então, vendo essas coisas, é possivel sim escrever um compilador xbase para código nativo, algumas coisas seriam realmente complicadas de se criar, tipo variaveis sem tipo ou declaração de variaveis em run-time, isso iria necessitar de varios passos de verificação do código, mas é possivel sim

billy1943, acho que encontrei a solução de seu problema.
Já experimentou imprimir para um arquivo .txt e depois, fazer um call de um programa p/ imprimir seu arquivo ?
é relativamente simples fazer isso, veja meu exemplo:

Código: Selecionar todos

       select arq-list assign to ws-device
             file status is estado
             organization is line sequential.


       fd arq-list label record omitted
              linage is 90 lines
              with footing at 90 lines
              at top 0 lines at bottom 3.
       01 linha                       pic x(132).

E no Working:

01 ws-device pic x(100) value "CAMINHODAIMPRESSORA".

Mas de começo coloque "C:\TEMP\IMPRESSAO.TXT"

PC Toledo

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?

E o Cobol ?