www.gienini.com

Juan M.Gienini

artic0

COBOL: el gran malo?

por: Jason Bloomberg | 6 mayo 2020
Origen: Compuware

COBOL no tiene la culpa de los recientes y tan sonados fallos de los sistemas informáticos. Sigue siendo relevante luego de 60 años de uso, éste lenguaje maneja grandes volúmenes de datos y transacciones para gobiernos y empresas de todo el mundo. A pesar de ser culpado por los problemas causados por los administradores que no han mantenido y modernizado sus plataformas mainframe, la vuelta al punto de mira del lenguaje COBOL debería concienciarnos de su importancia y alentar a las organizaciones a mantener actualizados sus sistemas.
Cuando Grace Lee Hopper (y otros) desarrollaron el COBOL (common business oriented language) en 1959, nunca podrían imaginar que estaría en las noticias en 2020.
"De repente, un antiguo lenguaje de programación está demandado", dice Salon. "COBOL regresó de la muerte ... otra vez", según Scoop. "El software obsoleto complica los esfuerzos para mantener en funcionamiento los sistemas estatales de desempleo" lamenta WNYC Studios.
Es cierto que COBOL recientemente cumplió 60 años. Pero los rumores de su desaparición, sin duda, han sido muy exagerados. Según todas las medidas, COBOL es tan relevante e importante hoy como lo fue hace seis décadas, tal vez más. Entonces, ¿por qué tanta consternación?
COBOL como chivo expiatorio
COBOL es, de hecho, un lenguaje totalmente moderno, porque fue diseñado para mantenerse actualizado.
La palabra "común" en su nombre en realidad refleja el deseo de los clientes de mainframe de un idioma portátil. Antes del COBOL, cada plataforma informática requería su propio lenguaje propietario. Por el contrario, COBOL funciona en diferentes plataformas, y quizás lo más importante, continúa trabajando a medida que los proveedores actualizan sus plataformas de una generación a la siguiente.
Además, la parte "orientada a los negocios" de su historia significa que las líneas de COBOL se parecen mucho al inglés, común en los lenguajes de programación actuales, pero revolucionario en su día.
COBOL, y las plataformas en que se ejecuta, aún logran en lo que siempre han sido excepcionalmente buenos.
Los programas en COBOL siempre se han destacado en manejar grandes volumenes de datos y procesar transacciones interactivas y la enorme cantidad de cifras que los bancos y las agencias gubernamentales tienen que procesar diariamente.
COBOL fue, por lo tanto, comprensiblemente el idioma elegido para tal procesamiento en la década de 1960, y sigue siendo en gran medida el idioma preferido para las mismas tareas en la década de 2020.
Encontrar a los verdaderos culpables
Si los programas COBOL no están a la altura de los desafíos de una organización moderna impulsada por una pandemia, el problema a menudo se debe a la apatía hacia el mantenimiento de las aplicaciones heredadas, de la modernización del entorno de desarrollo o de la actualización del hardware. La causa raíz es por tanto más de presupuestos insuficientes y falta de voluntad corporativa, en lugar de una limitación tecnologica.
Después de todo, IBM, el único vendedor de todo el abanico de mainframes que sobrevive, continúa innovando sus mainframes IBM Z. La línea de productos z15 de hoy contiene algunas máquinas increíblemente rápidas que simplemente nunca fallan.
Además, IBM ha actualizado su compilador COBOL junto con el hardware para permitir que sus clientes aceleren notablemente sus antiguos programas simplemente recompilándolos, a menudo sin cambiar una sola línea de código. Esos clientes también pueden ejecutar Linux, realizar todas las tareas de un servidor en la nube y los programas de soporte están escritos en todos los idiomas modernos, incluido COBOL. Sin embargo, incluso si una organización que ejecuta COBOL actualiza su hardware a la última y mejor versión, aún puede tener problemas para mantener sus programas COBOL actualizados.
Una vez más, el problema no está en el lenguaje en sí, sino, quizás en las herramientas que los desarrolladores usan para actualizar esos programas o los procesos que siguen para realizar las actualizaciones.
En algunos casos, seguir metodologías en cascada de desarrollo - en gran parte obsoleta - puede ser en parte el culpable. Con los métodos en cascada, los equipos reúnen todos los requisitos antes de tocar una línea de código y luego esperan hasta que se completen todas las actualizaciones de código antes de probar. Este enfoque es lento y no responde bien a los requisitos cambiantes, dos situaciones que probablemente sean el caso en tiempos de crisis.
En otras situaciones, las herramientas de desarrollo y prueba están desactualizadas. Cuando los desarrolladores de COBOL en el personal han estado utilizando tales herramientas de "pantalla verde" durante años, entonces las herramientas más antiguas pueden no ser un gran problema. Pero si una organización trata de atraer a los desarrolladores de la próxima generación, esperarán herramientas modernas de desarrollo y prueba similares a las que podrían usar para el desarrollo moderno centrado en la nube.
El culpable: prueba
De todas las razones por las cuales los antiguos programas COBOL luchan por satisfacer las necesidades actuales de las organizaciones modernas, especialmente en tiempos de crisis, el verdadero culpable a menudo son las pruebas. Recuerde, el desafío central aquí es actualizar los programas existentes, algunos de los cuales han existido durante años. Y nadie quiere burlarse de algo tan viejo sin saber si ese cambio mejorará las cosas, o las empeorará. Hay muchas cosas que pueden salir mal al realizar tales actualizaciones. La nueva funcionalidad podría no funcionar correctamente. Quizás el nuevo código funciona bien, pero hace que se rompa algún otro código anterior. Un tercer escenario común: la nueva funcionalidad funciona bien con volúmenes de transacción bajos, pero hace que el sistema se desacelere de manera inaceptable o se caiga por completo cuando esos volúmenes aumentan. Si el equipo de desarrollo no tiene visibilidad de estos problemas, es comprensible que se muestren reacios a realizar los cambios en primer lugar. La solución: herramientas de prueba modernas como las herramientas de prueba de mainframe de Compuware.
Compuware Topaz for Total Test automatiza las pruebas unitarias, las pruebas funcionales y las pruebas de integración y regresión, brindando a los desarrolladores la visibilidad que necesitan sobre el funcionamiento de cualquier cambio que puedan introducir en una aplicación COBOL, así como los efectos que esos cambios tienen en el resto de la programación.
Y Topaz for Total Test, al igual que con el conjunto completo de productos Topaz de Compuware, proporciona a los desarrolladores y evaluadores una experiencia de desarrollador moderna y familiar que hace que sea mucho más fácil para un desarrollador de "próxima generación" ser competente.
Compuware también ha agregado recientemente una nueva API REST y la integración de Jenkins a su solución de gestión de rendimiento de aplicaciones Strobe, incorporando la gestión de rendimiento de mainframe con otras herramientas DevOps modernas en toda la organización appdev. Ahora, los desarrolladores de mainframe jóvenes y mayores pueden determinar el impacto en el rendimiento de cualquier actualización de código que puedan crear.
La toma de Intellyx
Los expertos en mainframe ciertamente han estado poniendo los ojos en blanco en el reciente giro poco halagador de COBOL en las noticias. Sin embargo, a pesar de la mala prensa, este breve regreso al centro de atención es en gran medida una ventaja para todas las partes involucradas.
Las habilidades de COBOL tienen más demanda que nunca, mejorando las perspectivas laborales de los expertos y novatos de COBOL por igual. Es probable que las organizaciones dependientes de COBOL con hardware, procesos o herramientas obsoletos obtengan los presupuestos y el soporte que necesitan para realizar los cambios que tanto tiempo necesitan. Y quizás lo más importante, los miembros del público que dependen del funcionamiento eficiente de los mainframes en la infraestructura financiera global, tanto dentro del sector público como privado, pueden estar seguros de que toda la comunidad mainframe está haciendo horas extras para asegurarse de que todo continúe funcionando. trabajar durante este tiempo de crisis.
Esta publicación apareció originalmente en Intellyx.com.
Derechos de autor © Intellyx LLC. Compuware e IBM son clientes de Intellyx. Intellyx retiene el control editorial final de este artículo.

Contacto: