Migrar desde ACU/COBOL & RM/COBOL

La migración desde RM/COBOL o ACU/COBOL presenta amenudo la dificultad de que suelen ser aplicaciones en modo crácter que suelen resolver la interfaz gráfica a base de ACCEPT o de DISPLAY o que contienen algún producto propietario para resolver la GUI como pueden ser las extensiones WOW.

Sea cual sea el entorno origen, se añadiran dificultades inherentes a la estructura de programación. Deberemos de ser capaces de indentificar los problemas y si cada programa trata por ejemplo el tema de informes de una manera, será muy dificíl aportar una solución global al tema de informes. La presencia de inumerables GO TO también nos impedirá seriamente la lectura del código.

Tanto la interfaz gráfica como muy probablemente la obtención de informes deberán de ser reprogramados desde cero o prácticamente. Podremos salvar quizás las validaciones de los campos en el caso de la interfaz gráfica siempre y cuando todos los programas sean homogéneos. Puestos tener que desarrollar estas partes desde cero, debemos de saber muy bien hacia que tipo de entorno nos queremos dirigir y hacernos preguntas como:

  • ¿Queremos cambiar de sistema operativo? a LINUX ¿por ejemplo?
  • ¿Estamos realmente seguros de que es importante conservar COBOL?
  • ¿Hemos hecho los deberes a lo largo de los años en cuanto a formación? ¿Sabemos que es la programación orientada a objetos?

Si, como la mayoría de los clientes, quieren conservar COBOL y el cambio de sistema no es una opción viable y queremos conservar Windows, tenemos dos grandes alternativas:

Veamos las ventajas e inconvenientes de cada una de estas alternativas. Adamed siempre recomienda la segunda e ir hacia NetCOBOL para .NET:

Ventajas:

  • Podríamos elegir el tipo de interfáz gráfica (Web, Escritorio, Distribuida etc.)
  • Aprovecharíamos todas las nuevas tecnologías. Si no es inmediatamente al migrar, en un futuro estaríamos dispuestos a enviar emails, informes en PDF, etc.
  • Trabajaríamos con Microsoft Visual Studio como otros programadores y podríamos compartir proyectos con otros lenguajes de programación
  • La calidad final del producto migrado es muy superior y los programas quedarán inmunes al paso del tiempo y al cambio en las tecnologías. NetCOBOL para .NET avanza al mismo ritmo que Microsoft
  • La interfáz gráfica de usuario podrá ser muy rica en controles. Los mismos que se usan en VB.Net o C#
  • Podemos utilizar Bases de datos con ODBC, ADO.NET LINQ Etc. o ficheros estándar de COBOL

Inconvenientes:

  • La curva de aprendizaje de la programación orientada a objetos es lenta para los neófitos. Necesitamos autoformación y debemos de estar dispuestos a ello
  • Debemos de estar dispustos a invertir quizás más tiempo en la migración

Ventajas:

  • La curva de aprendizaje es muy rápida
  • Nuestra migración podría ser más fácil y rápida
  • Podemos utilizar ficheros COBOL o Base de datos con ODBC
  • Podemos dotar a nuestros programas de una interfáz de usuario rica

Inconvenientes:

  • Nuestra programación será orientada a eventos (NO a objetos)
  • Tendremos que conformarnos con código de 32 bits para siemrpe. PowerCOBOL nunca será para 64 bits.
  • Los clientes de PowerCOBOL ya esstán pensando en cambiar. Desarrollar de nuevo en este entorno no parece buena idea.

 

 

Adamed recomienda NetCOBOL para .NET