Mainframe and .NET compatablility

Curious I have 30+ years of mainframe experience and about 9 years of VB and C# in the .NET environment. I find the 2 can go together quite nicely. I would no longer consider writing a report in Easytrieve as I could do the same thing in VB.net in a fraction of the time creating EXCEL spreadsheets or simple text files. Throw in SSIS to move VSAM to SQL Server, Oracle or DB2 and there is a lot that can be done. Anyone else finding this to be the case.

Hi Ron, welcome to the community. I’ve heard of a few people interested in .Net and the mainframe, and everyone has a little different view of what compatibility/interoperability means. So if you had access to Z as a data source for .Net reporting applications, that would be what you’re looking for?

Hi and thanks for the welcome. What I did a lot of in my last contract was to use VB.net running it against Oracle or SQL server to create adhoc reports and web pages. Obviously the same can be done against DB2. Having over 30 years of MF experience I was literally amazed at just how quickly one could create Excel reports using this. If I were in a big shop I would definitely work with management to help Cobol programmers come up to speed in VB to create reports rather than using Cobol via JCL. SSIS is even faster than that because you mostly develop complex SQL queries to gather the data and you avoid cursor operations. I rewrote a program that ran for an hour changing it into SSIS and it ran in a minute as there were no cursor operations. So many neat things that can be done. I still love Cobol and the Mainframe but having these other tools are a big plus. Regards Ron

Prezado ronbl,

A questão do uso do MAINFRAME esta relacionada a onde se localiza o repositório dos dados, isto é, se no MAINFRAME ou não, bem como, as Regras de Negócio existentes, uma vez que, o seu “serviço” ou “sistema” pode vir a utilizar informações de Outros Sistemas, para um mesmo fim.
Com o advento da internet, da utilização de celulares, entendemos que uma solução tecnológica tem 3 camadas básicas: Apresentação, Processo e Acesso à Dados.
O COBOL, como outras linguagens, esta na camada de Processo, que ao estar em MAINFRAME pode ser reaproveitada por qualquer outra camada de Apresentação.
Igualmente, se a camada de acesso for bem organizada, terá acessos simples e específicos, que poderão ser reaproveitados em outros processos, principalmente, por outros Sistemas além do Sistema Nativo.
Quando colocamos estas questões estamos apenas abrindo as possibilidades de utilização de todas as ferramentas, contudo, com um Compilador mais eficiente que permita a utilização de toda a potencialidades dos HARDWARES já desenvolvidos, continuo, a acreditar que as Regras de Negócio, bem como, os dados negociais devem estar em uma única plataforma, de tal forma, que seja mas simples e, com a adequada precisão, desenvolver qualquer modificação/evolução necessária, ressaltando que qualquer pessoa é capaz de Ler e Entender um Programa COBOL, o que não é tão simples em outras linguagens.
Já convivi com Gestores/Representantes que de tanto acompanharem a leitura de programas COBOL, em pouco tempo, já o poderiam fazer sozinhos.
Logo, a questão deve estar relacionada a Melhor Solução Arquitetônica possível, utilizando TODOS os elementos necessários e adequados.

Dear Sir

I agree with a lot of your points. COBOL is indeed easy to read and the PC world is out of its mind with the latest how to do something. As soon as you learn something it is obsolete. That being said, as I have solid experience in both worlds I would use COBOL for the batch environment but neve CICS for online. Then it should be done on the PC. CICS is an old ugly to code with terrible presentation. in .NET I have nested drop down lists with even sub lists. I mean how could you even hope to do that in CICS

Prezado ronbl,

         A resposta a sua pergunta esta na certeza de que qualquer solução tecnológica possui 3 camadas: Apresentação, Processamento e Acesso à Banco de Dados.
         O COBOL sempre deverá estar na camada de Processamento, aquela que prepara os Dados a serem apresentados, muitas vezes acessando a camada de Acesso à Banco de Dados, uma vez que, o COBOL, embora seja a linguagem mais antiga "Orientada a Objetos", nunca será adequada para a Micro Informática, tendo em vista, a natural limitação de seu espectro ambiental.
         Quando propusemos a questão o fizemos relacionado a importância de termos os dados CORPORATIVOS em ambiente MAINFRAME utilizando o COBOL, contudo, abrimos espaços para as várias tecnologias relacionadas à camada de Apresentação, uma vez que, uma consulta na Intranet, pode ter apresentação e preocupações diferenciadas na Internet, no celular, no CICS e em outra Máquina MAINFRAME.
          Logo, estando os dados no MAINFRAME, utilizando código COBOL para as funcionalidades relacionada ao Negócio, qualquer alteração será Simples e feita com precisão, uma vez que, o código, por mais "enrolado" que seja, poderá ser lido e entendido por qualquer um.
          Enquanto que nas demais linguagens existem dificuldades significativas para a leitura e o entendimento do processo, que ultrapassam a simplicidade de uma leitura de código.
           Nunca, em momento algum, questionei a necessidade da utilização das camadas de Apresentação não serem em COBOL, pelo contrário, entendo que a camada de processamento em COBOL pode ser utilizada por qualquer tecnologia de Apresentação (inclusa todas as formas de preparo da imagem a ser apresentada com os dados obtidos da camada de processamento).
           O CICS não é um código bonito, mas é com certeza, um código eficiente, principalmente quando temos, hoje em dia, o conceito de roteamento entre CICS, conhecido como CICSPLEX.
           Os equipamentos MAINFRAME estão cada vez mais rápidos, e sua utilização, permite que os Sistemas Corporativos, tenham, naturalmente, 2 níveis de segurança, um correspondente à camada de apresentação e outro correspondente à camada de Processamento, sem falar na possibilidade de outro na camada de acesso à Banco de Dados.
            Tenho certeza de que compactuamos com os mesmos conceitos e valores, percebendo, portanto, que deve ter havido uma pequena "falha de comunicação".
            Manter os Códigos Fontes do Negócio, e seus respectivos dados, em uma única plataforma, reduz desgastes e incertezas, pois, mantém centralizada TODAS as Regras de Negócio, e por isto, a camada de Processamento, e a camada de Acesso à Banco de Dados devem estar numa mesma plataforma.
            Afinal, é muito mais fácil, e barato, formar um Profissional de Informática MAINFRAME para a Empresa quando ele detém cultura (incluso princípios e valores) do Negócio da Empresa, do que Acrescentar a um Profissional de Informática Experiente a cultura (incluso princípios e valores) do Negócio da Empresa.