Reescribiendo el ensamblador de IBM + COBOL en C ++

Trabajo como agente / gerente de alquiler para una compañía de alquiler de autos que se ejecuta en un sistema de alquiler que fue escrito en 1972. Decidí que tal vez era hora de una actualización. Para un poco de antecedentes, aquí hay un breve ejemplo de la locura con la que tenemos que lidiar diariamente con este programa:

Un agente de alquiler debe recordar que la impresión en una pantalla usa "MXC" en el campo ACT (todo se basa en códigos cortos), que significa "pantalla MaXimum en un contrato", mientras que en otra requiere PR (para IMPRIMIR) en el campo ACCIÓN, pero varias pantallas usan una Y en el campo PT (para PrinT), otra pantalla usa Y en el campo PRT (para PRinT), y otra pantalla requiere que el usuario presione enter (pero no la entrada al lado del letras, como se trata de un nuevo carácter de línea, debe ser el ingreso en el teclado numérico) y luego F8, una pantalla diferente pero relacionada requiere simplemente F8, algunas pantallas tienen un campo etiquetado PRT, que debería ser para PRinT, pero el campo en realidad no hace nada y la impresión se realiza automáticamente después de pasar por varias indicaciones, y aún más pantallas tienen un campo etiquetado IMPRIMIR S / N,que por defecto es Y para operaciones en las que otra ubicación ya está entregando documentación, y N para operaciones en las que otro distribuidor necesitará documentación.

Decidí que podía hacer un mejor trabajo que esto, así que me puse en contacto con la persona de la compañía que tomaría la decisión de actualizar esto. Finalmente me comunico con el vicepresidente de TI, quien está a cargo de este programa. Recibo un poco de información de él, y me doy cuenta de que mi compañía de alquiler de autos tiene su programa de alquiler escrito en el ensamblador de mainframe de IBM con un poco de COBOL mezclado. Dice que no hay puestos disponibles en este momento, pero que debería envíele un correo electrónico mi currículum de todos modos (en caso de que algo se abra).

Esto me lleva a mis preguntas.

El primero es técnico. Con la idea de mejorar la capacidad de mantenimiento en el futuro, mi pensamiento es reescribirlo en un lenguaje de nivel superior al lenguaje ensamblador. Mi área de experiencia es en C ++, así que esa es la opción obvia para mí. La compañía necesita urgentemente una forma más fácil de actualizar el programa, ya que recientemente leí un artículo en el que se cita al hombre con el que hablé diciendo que el equipo trabajó duro, y están orgullosos de anunciar que el programa ahora tiene soporte para 5 de códigos de ubicación de dígitos (en lugar de 4) y números de automóviles de 8 dígitos (en lugar de 7). Mi filosofía sobre las actualizaciones, incluso en situaciones tan graves, está en línea con la de Joel: http://www.joelonsoftware.com/articles/fog0000000069.html en resumen, las reescrituras deberían ser incrementales, en lugar de tirar todo lo que había antes y comenzando de nuevo.

¿Existe una manera fácil de integrar el ensamblaje de IBM con C ++ y, de ser así, cómo debo hacerlo? Soy vagamente consciente de la palabra clave asm, pero no sé si es mejor usar eso o hacer otra cosa. ¿Se desaconseja este plan? Hago la mayor parte de mi trabajo en Linux usando g ++ y GNU make, por lo que las respuestas específicas son bienvenidas, pero definitivamente no son necesarias (ya que no tengo idea de qué tipo de sistema de compilación no tienen, pero sospecho que casi ninguna).

La segunda pregunta es más política. ¿Cómo debo convencer a esta empresa de que necesitan hacer el cambio? Los ahorros de costos teóricos son enormes (según mis estimaciones, la compañía está desperdiciando un millón de dólares extra por año, solo en el aumento de los costos de capacitación para aprender a interactuar con el programa), pero mis cambios propuestos probablemente pondrían todo el los programadores actuales no tienen trabajo, en caso de que se promulguen, por lo que existe una gran resistencia estructural al cambio.

editar: Debo explicar por qué modificar lo que la compañía ya tiene me parece la mejor solución. Todavía estoy abierto a otras sugerencias, porque este es un monstruo de un programa, sin embargo. Nunca he tenido un trabajo de programación antes, así que corrígeme en cualquier análisis incorrecto que pueda dar.

En primer lugar, está la solución estándar.

De mis conversaciones con algunos gerentes de nivel medio sobre este tipo de cosas, una de las principales preocupaciones con el cambio a un nuevo sistema es la gran cantidad de empleados leales que han estado con la compañía durante décadas y que ahora se sienten cómodos con el sistema. . Si tengo la capacidad de modificar lo que tenemos, podría mantener la interfaz actual en una especie de 'modo de compatibilidad'. Los usuarios ya tienen que iniciar sesión para usar el sistema actual, por lo que podría agregar la posibilidad de activar una configuración cuando los usuarios inicien sesión por primera vez (después de hacer este cambio), donde se les da la opción de usar interfaz 'clásica' o la interfaz 'nueva'. No hay forma de que encuentre una solución estándar que permita eso,

Mi empresa también posee el software que utilizamos; No lo licenciamos. Esto significa que la gerencia con la que estoy hablando actualmente son las mismas personas que realmente podrían autorizarme a hacer un cambio. Con una solución de terceros, tendría que obtener la aprobación de mi compañía además de asegurar los derechos que serían necesarios de la compañía que desarrolló el producto que utilizamos, lo que agrega un obstáculo adicional. Esto también requeriría convencer a la compañía de que renuncie a "su" producto y tome otro producto, lo que parece un obstáculo mayor que intentar actualizar lo que tenemos, pero podría estar equivocado sobre este tema.

Finalmente, mirando hacia el futuro, no solo quiero mejorar la interfaz de usuario y corregir algunos errores. Después de actualizar esos problemas 'urgentes', esperaba actualizar la forma fundamental en que la empresa funciona en relación con la tecnología. Después de pasar 1-2 años en este tipo de problemas, mi plan era volver a la gerencia y proponer cambios más dramáticos. Hay muchas formas en que la empresa funciona que podrían mejorarse fundamentalmente con tecnología que simplemente no están utilizando en este momento. Por ejemplo, cada región funciona de la misma manera. El principal aeropuerto local es el centro de distribución de automóviles. Se envían principalmente según sea necesario. Sin embargo, el aeropuerto se utiliza como base de operaciones para todas las operaciones. Enviarán a dos personas en un automóvil a mi ubicación para que nos recojan un automóvil que no necesitamos, luego regrese al aeropuerto con el automóvil en el que vinieron, más lo que están llevando (estamos a 32 millas del aeropuerto). Luego vendrán a la ubicación a 5 millas de nosotros en dos autos para dejar uno de ellos, luego regresarán en su otro auto al aeropuerto. Lo hacen incluso si el automóvil que enviamos es el mismo tipo de automóvil que necesitan cerca de nosotros. He estado con la compañía durante aproximadamente dos años, y solo parece que se han desviado de esto en las emergencias más extremas de escasez de automóviles (unas tres veces). Reemplazaría a las 4 personas que trabajan en cada región con un sistema de programación automatizado que determina qué automóviles van a dónde y tratan de encontrar el camino que requiere la menor cantidad de tiempo + millas + conductores para entregar todos los automóviles donde deben estar, como un ejemplo de las correcciones de nivel superior que espero agregar algún día.

Sin embargo, antes de sentirme cómodo proponiendo todo esto, creo que sería útil establecer un punto de apoyo en la empresa y la base del código haciendo las tareas más pequeñas, como actualizar la interfaz. Soluciones como la subcontratación o de otro modo eliminarían esta posibilidad.

Confinándome al frente técnico ...

Le sugiero que comience determinando el entorno en el que se ejecuta la aplicación. "Mainframe" podría significar un par de cosas diferentes, dada la edad de la aplicación, podría ser CICS o IMS . También es posible que los autores originales escribieran su propia tarea iniciada.

Dependiendo de dónde se ejecute la aplicación, es probable que haga uso de API para ese entorno, CICS ahora usa una interfaz muy diferente de sus primeros días, no puedo hablar por IMS. Si la aplicación es su propia tarea iniciada, es muy posible que tenga su propia API interna: me paso unos siete años apoyando a esa bestia, escrita en la misma época.

Otra cosa a tener en cuenta, dada la antigüedad de la aplicación, es que el ensamblador con el que desea integrar C ++ es anterior a la existencia de Language Environment (LE). Como tal, a menos que el ensamblador se haya actualizado para que sea conforme con LE, tendrá algunas dificultades ya que C y C ++ cumplen con LE y requieren que sus llamadores y llamadas también se ajusten.

Otro punto a considerar, si esta aplicación se ejecuta en un mainframe moribundo, es posible que esté tratando de integrarse con una aplicación que se ejecuta en hardware y software no admitidos. Esto no sería diferente a tratar de integrarse con una aplicación escrita en 1989 que se ejecuta en DOS 4.01 en su hardware original.

Estás saltando el arma. Según su descripción, parece que no ha entendido completamente el entorno técnico actual (qué sistema operativo exactamente, dónde y cómo se almacenan los datos, existen interfaces con otros sistemas, etc.). Pero aún más importante: un plan serio debería considerar alternativas a una reescritura interna parcial o completa del software, es decir, software comercial, externalización de la reescritura, software como servicio, etc.

Independientemente de cómo vaya la empresa, primero necesita un análisis sólido de lo que hace el software hoy y cuáles son los requisitos para la nueva solución.

Entonces, ¿por qué no ofreces hacer este análisis?

¡Me sorprende que hayas recibido una respuesta tan amable!

Veamos esto desde su punto de vista.

Manejaron exitosamente un sistema de treinta años con probablemente cientos de miles de líneas de código, interfaces con quizás otros veinte sistemas que encarnan procesos de negocios que evolucionaron a lo largo de cuarenta años.

Probablemente sean expertos en su campo y, como tal, considerarían a C ++ como un paso hacia abajo del "lenguaje de ensamblador de alto nivel" de IBM para darle su título completo. El lenguaje ensamblador de IBM es extremadamente poderoso y el lenguaje "MACRO" es la mejor implementación de un lenguaje de preprocesamiento / plantilla.

Habrá una propuesta para reemplazar su sistema cada cinco años desde que se implementó por primera vez. Algunos habrían sido rechazados después de un estudio de factibilidad, algunos habrían llegado a la etapa de diseño antes de perder su presupuesto, algunos incluso podrían haber entrado en el código y tal vez en la etapa de prueba antes de que se toparan con problemas de rendimiento y quedaran en lata.

C ++ simplemente no ayudaría. No hay una biblioteca de gráficos en el entorno donde se ejecuta la aplicación. (Hay una biblioteca de gráficos 3270, pero es poco probable que sea compatible con C ++, ya que nadie la usa, y hay una biblioteca de cliente "X" completa, pero debe estar en un entorno diferente para usarla).

Tienen una interfaz de usuario que dista mucho de ser perfecta pero que es bien conocida y rápida. Un operador experimentado completará un formulario aproximadamente tres veces más rápido utilizando una pantalla verde en lugar de una GUI equivalente. Además, pueden prestar atención al cliente mientras tocan la letra.

Los operadores de pantalla necesitarán capacitación, sea cual sea la interfaz que utilicen, volver a capacitar a todos sus empleados para que utilicen una GUI nueva y desconocida sería una partida presupuestaria masiva en comparación con solo capacitar a los nuevos empleados en el viejo sistema mundial.

Tuve un problema similar hace algunos años en BellSouth. Simplemente escribí el código COBOL para escanear los programas de lenguaje ensamblador byte a byte, separar los códigos de operación y los operandos, convertir las instrucciones de ramificación para ir a tos y convertir las instrucciones de comparación en IF. Este programa convirtió las instrucciones de DC al código COBOL Data Division equivalente, y convirtió movimientos, zaps, etc., según corresponda.

Una vez hecho eso, escribí un segundo programa para convertir IFs y GOTOs en IF-THENs, con movimientos y cosas así en las líneas entre estos grupos (esto no fue realmente tan difícil de hacer; el secreto es insertar los IFs y ELSEs mientras relees el cobol "pidgin" de primera fase de atrás hacia adelante).

IF-THEN-ELSER buscó situaciones en las que encontró una referencia GOTO cerca de una etiqueta, que podría eliminarse de forma segura (disminuyendo su número de referencias en 1). Ejecuta este programa IF-THEN-ELSER de forma iterativa (es decir, lo ejecuta una y otra vez, deteniéndose solo cuando su último pase no puede encontrar la manera de hacer más cambios). La mayor parte del trabajo crítico lo realiza este if-then-elser, cuyo producto COBOL debe ser cuidadosamente revisado y examinado por un programador experto y competente en lenguaje ensamblador (es decir, yo). En mi experiencia, mi "if-then-elser" pudo eliminar más del 90 por ciento de los GO TO que resultaron de las instrucciones de la rama original.

Supongo que es posible avanzar desde este punto con una conversión directa a C (o C ++), lenguajes con los que también estoy familiarizado. Sin embargo, en BellSouth, nuestro idioma de elección fue COBOL / II. Siempre hay un poco de complejidad que surge de situaciones en las que una etiqueta restante tiene múltiples referencias IR A (muchas veces, estas situaciones son manejadas por COBOL PERFORMs, pero a veces pueden representarse simplemente mediante construcciones OR y AND).

Creo que es bueno producir código en COBOL / II elegantemente estructurado en bloques, con EVALUADOS (construcciones de casos) y 88 nombres de condición de nivel. Agregar estos toques finales condujo a otro par de programas, que resultaron útiles en los programas COBOL que no se originan en programas convertidos de ensamblador.

No sé si esto ayuda.

Como han comentado otras personas, debe llevar a cabo este proceso con cuidado. Ayuda tener 10-12 años de experiencia en codificación de ensambladores informando sus procesos de toma de decisiones. Los que tenemos esa experiencia son difíciles de encontrar más.

Como nota final: solo escribimos en ensamblador en ese entonces porque los compiladores para los lenguajes de alto nivel producían código de objeto engorroso e ineficiente. Los compiladores COBOL "optimizadores" de hoy no tienen esos mismos malos hábitos. ----------

El consejo de Joel es generalmente sólido, pero en este caso una reescritura completa está atrasada. Idealmente, una reescritura con un hacha de batalla, ya que lo que estás tratando aquí es un monstruo.

No estoy seguro de qué agregar exactamente, ya que ya has hecho un buen argumento para que lo reescribas tú mismo. Mi única recomendación sería omitir C ++ por completo e ir directamente a una interfaz web para el sistema de alquiler, ya que probablemente será aún más fácil capacitar a los trabajadores y le ahorrará mucho trabajo en la interfaz de usuario (además de hacer es mucho más fácil obtener sangre nueva en el proyecto, o incluso simplemente externalizar todo).

En cuanto a los programadores COBOL existentes, tal vez puedan ayudar a documentar el sistema existente y al proceso de migración.

En cuanto al aspecto técnico, mucho dependerá de la calidad, la modularidad, del código del ensamblador. Algunos programadores entendieron la importancia de crear módulos con funciones específicas y limitadas y una interfaz parametrizada clara y simple, utilizando convenciones de enlace de subrutinas estándar de IBM. La gran mayoría, sin embargo, tendió a crear monstruosidades monolíticas.

Con el primero, la reutilización es posible, y no debería ser tan difícil resolver el "pegamento" entre C ++ y el ensamblador, suponiendo que los módulos del ensamblador usen secuencias de llamada estándar (o al menos consistentes). Sin embargo, con toda probabilidad, el código del ensamblador será un desastre. Aunque era posible escribir ensamblador estructurado, muy pocas personas lo hicieron, y será casi imposible discernir cualquier "diseño" desde el cual comenzar a reescribir.

Por otro lado, el ensamblador 360/370 tiene un nivel bastante alto en comparación con los microprocesadores actuales, y es mucho más simple, y C a veces se considera "ensamblador de alto nivel". Trabajé para una compañía de DBMS cuyo producto era un ensamblador completamente 370, y nuestro arquitecto principal creía que sería posible traducir a máquina el código del ensamblador en C (para una futura portabilidad). Soy escéptico, pero el punto es que la distancia no es tan grande como podrías pensar.

No sé si algo de esto es útil. Como digo, creo que depende en gran medida de la calidad y el tamaño del código original.

No puedo decir si esto es una broma o no: ¿su empresa está ejecutando en serio el código originalmente escrito hace 39 años? Si se ejecuta en un sistema / 360, tendrá que compilar g ++ desde la fuente ...

Honestamente, ni siquiera pensaría en usar ninguno de los viejos códigos; debe adoptar un enfoque nuevo, sentarse y pensar en lo que debe incluirse en el diseño, y hacerlo desde cero. Sí, implicará un poco de planificación, pero no creo que incluso Joel diga que este es un caso de cambios incrementales.

En cuanto a persuadir a la empresa de que necesita cambiar, debe señalar razones específicas que mejorarán la eficiencia, reducirán los costos y / o mostrarán que lo que está utilizando ahora está perjudicando los resultados en este momento.

Otro comentario: me imagino que otras compañías de alquiler de automóviles se han unido al resto de nosotros en el siglo XXI; Haría un poco de reconocimiento para ver cómo lo están haciendo (basado en la web, imagino), y posiblemente modelarlo después de uno de esos sistemas (es decir, no reinventar la rueda).

¡Buena suerte!

En teoría, no debería ser difícil convencer a la alta gerencia para que reemplace el sistema anterior si puede mostrarles que les ahorrará megabucks. Y lo hará. Va a ser cada vez más difícil encontrar programadores para mantener este sistema, y ​​esos programadores serán cada vez más caros. No se trata de "si", se trata de "cuándo". Realmente tiene que ser actualizado.

Sin embargo, la pregunta es si puede convencerlos no solo de que necesita actualizarse (y probablemente lo sepan de todos modos), sino de que debería ser un proyecto interno. Especialmente si el equipo eres solo tú. Muy a menudo, un reemplazo tan importante se subcontrata. Incluso puede haber algún software disponible para su consideración. Estas opciones deben investigarse y sus gerentes insistirán en que eso suceda si son razonables.

En cuanto a la tarea, si fuera a hacerlo, realmente creo que una reescritura de bulldoze puede ser apropiada en este caso. El argumento de Joel no se aplica en todos los casos. Sin embargo, no podría saberlo sin verlo.

1. Un cambio incremental está fuera de la cuestión.

2. Es probable que haya una solución comercial disponible. Hay muchos negocios de alquiler de autos.

3. Si, como último recurso, necesita reescribirlo, primero pase un tiempo pensando en cómo funcionará el nuevo sistema.
   Después de haber identificado la funcionalidad y las interfaces, puede elegir las herramientas de desarrollo que mejor se adapten a las necesidades (y sus habilidades).

Una estrategia para minimizar el estrés para los usuarios finales es comenzar emulando la vieja interfaz fea que los usuarios conocen, con algunas sutilezas como listas desplegables para mnemónicos feos, luego agregar gradualmente la funcionalidad de la interfaz de usuario y destetarla en una interfaz de usuario moderna.

Probablemente no desee mantener el mismo formato de archivo de datos, por lo que no habrá vuelta atrás una vez que cambien.