29/08/2017: Y ... COBOL sigue procesando cerca del 100% de las transacciones contables/financieras en el mundo, por Alfredo Pérez y otros Dinos.

Alfredo Pérez 25/08/2017

Y ... COBOL sigue procesando cerca del 100% de las transacciones contables/financieras en el mundo.






Jorge Hofmann 26/08/2017

Bueno por fin tenemos una verdadera discusión, debate, polémica o dialéctica sobre un tema que nos toca de lleno.

Me gustaría incluir alguna opinión o comentario o como quieran llamarlo

Recuerdo que en los años 90´s se decía, como si fuera totalmente cierto, "el COBOL no existe mas" a causa de el surgimiento de los servidores y algunos lenguajes de procesamiento, pero como el ave FENIX resurgió este lenguaje y adaptando no solo a nuevas tecnologías (procesamiento on-line) sino a nuevas formas de programación. Encima aparece The most famous of Data Base THE DB2 también se incluye el lenguaje para poder administrar, actualizar datos que es el SQL. 

Y aparece el terrorifico año 2000 (Gracias Bill Gates por promover esa idea) donde hasta IBM se encuentra obligada a modificar sus sistemas operativos por esos 2 malditos dígitos del año por 4 digitos con lo cual tuvimos que modificar todos los programas COBOL (junto con todo lo que tenía que ver con fechas en los programas). En esta época recuerdo que se buscaban con desesperación expertos en Mainframe y COBOL CICS DB2 pagando suculentos emolumentos al que poseia dichos atributos / cualidades / conocimientos / experiencia.

Junto a esto comenzó la mala onda de que los MAINFRAME se mueren NOTICIA DE ULTIMO MOMENTO los mainframe NO murieron ni fueron reemplazados es mas redujeron su volumen aparatoso y hoy en día muchas mas empresas pueden tener un mainframe de mayores prestaciones, consecuencia de esta mala onda se abandonó la capacitación de personal en la administración de estos sistemas y en programación con COBOL.

También en esa época se prendió la luz que nos guía en el camino de la buena programación ¡¡¡¡¡Quality¡¡¡  haciendo que muchos sistemas se adapten a ciertas normas de calidad en programación, aunque todavía subsisten o sobreviven (vivitos y coleando) muchos programas de la década de los 80´s que funcionan pero no se tocan porque funcionan (Esta es una de las reglas de ¿IBM? "si un sistema funciona no se toca").

Así hemos llegado a pleno al nuevo milenio como dice Alfredo "COBOL sigue procesando cerca del 100% de las transacciones contables/financieras en el mundo." 


La noticia es "Los muertos que vos matais gozan de buena salud" (dicho popular castellano).

Cris Vélez 26/08/2017

COBOL... qué recuerdos!!!! Yo programé en COBOL tantos años de mi vida que hasta el castellano lo hablaba con acento cobolense. Nunca pensé que aún se procesaban programas COBOL y menos en esa proporción. Qué bueno, no estoy tan obsoleta aunque confieso que tuve que migrar a nuevos lenguajes a partir de C+.
También fui fan de WordPerfect pero empecé con Multimate...
Y aquí me callo para no seguir delatando mi antigüedad!


Gracias a todos por este intercambio de ideas y conocimientos. Me enseñaron muchísimo!

Claudio Di Véroli 26/08/2017

Bueno, bueno. Será práctico, pero se pueden decir MUCHAS cosas. 

En cuanto al aspecto didáctico de  aprender a usar una computadora mediante el lenguaje COBOL, recordemos lo publicado por varios grandes de la computación:

·         KNUTH: Recuerdo perfectamente que el gran tratado The Art of Computer Programming, de Knuth (1ª edición, cuyo ultimo volumen se publicó en 1973), declaraba algo así como que "Toda persona que aprenda, domine y practique la programación en COBOL queda arruinada de por vida".
·         DIJKSTRA: Poco después, otro grande de la historia informática, Dijkstra: (1975), afirmaba que "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." 

Sin llegar a opiniones como las de arriba que, si bien muy autorizadas, son algo extremas, estas fueron mis experiencias personales:

·         Allá por 1972 hice un experimento en una empresa: programamos el mismo mini-sistema en COBOL y en FORTRAN.
·         La elección de la aplicación NO fue realizada por el programador en FORTRAN: fue algo relativamente objetivo.
·         La programación en COBOL llevó una semana.
·         La programación en FORTRAN llevó un día.
·         Se corría en una computadora comercial, supuestamente con software optimizado para correr COBOL, no FORTRAN.
·         Y sin embargo el programa en FORTRAN corría 5 veces más rápido.
·         Repetí el experimento años más tarde en otra empresa con resultado similar. 

Todos sabemos porqué. En este caso (e imagino que en muchos otros) el análisis mostró que no sólo COBOL compilaba código menos eficiente, sino que los programadores tendían a utilizar archivos como áreas temporarias de trabajo cuando las mucho más eficientes tablas en memoria (preferidas por los programadores en FORTRAN) daban el mismo resultado con menos programación y menos procesamiento.

Está bien, solamente dos experimentos no prueban demasiado, pero en fin ... 

Me parece que estamos de acuerdo en que se mantienen los programas en COBOL porque es conveniente, porque reprogramar es costoso y riesgoso, y porque como bien se citò en este intercambio, es mejor "no tocar" algo plenamente probado y que funciona bien. Dos programas míos que funcionaron muy bien, en dos empresas diferentes, se mantuvieron en uso por respectivamente 17 y 20 años. Es evidente que hacia el final de su vida estaban realmente obsoletos, pero como no fallaban (así me dijeron los responsables, yo ya no estaba en esas empresas), nadie quería cambiar nada.


Volviendo a COBOL, claro, hoy en día lo de la eficiencia en procesamiento de datos contables no es tan importante. Tras una vida de haber programado por años en una decena de lenguajes, permítaseme la opinión personal de que no es bueno que el contacto del estudiante con la computación y la programación tenga a COBOL como componente importante.

Alfredo Pérez 26/08/2017

Estimado Claudio.

Me permito disentir en varios puntos.

A - el objetivo de COBOL nunca fue "enseñar programación" sino proveer a los usuarios que empleaban computadoras para procesamiento de datos una aproximación al "lenguaje común" tal que un usuario con poco entrenamiento pudiera informatizar sus procesos.

B - el órgano gubernamental de USA que establecía las normas y los tests mínimos para aprobar compiladores era Codasyl - Commitee on data processing symbolic languages.  
Los acrónimos de los nombres dicen todo:
COBOL = COmmon Bussiness Oriented Language
FORTRAN - FORmulae TRANslator  (no quiero hacer hincapie en el plural latino para no calentar el ambiente)
ALGOL - ALGorithmic Oriented Language

C - Además, (Dinas aplaudan) Cobol fue definido bajo la dirección de la Doctora en Matemáticas Almirante Grace Hopper, a partir de su desarrollo previo de Flow-Matic un sistema de conversión de diagramas de flujo a programa objeto para las UNIVAC-

D - Si queremos opinar sobre barbaridades que no enseñan a realizar buenos programas, no dejemos de lado todos los RPG y similares (todas las marcas tuvieron algo similar) RPG - Report Program Generator

E - En cualquier administración, tanto sea bancaria, comercial o industrial (en este caso me refiero a la administración de inventarios, órdenes de proceso, etc.) se requiere una continua adaptación a factores externos.
El caso más común es el rediseño de un formulario para agregar o suprimir datos, fechas, etc. A menos que la instrucción FORMAT de Fortran haya cambiado notablemente, en el área de generación de informes impresos o por pantalla, COBOL es superior. 
Por las mismas razones, no veo como un programa puede permanecer 15 a 20 años sin tocarse, en un contexto inflacionario, con impuestos que varían mes a mes su base o alícuotas, números de teléfono que pasan de 6 a 7 y lueho a 10 dígitos, etc, etc. Me interesaría conocer la descripción y funcionalidades de tal programa-

F - Claudio, acuerdo contigo en un tema, "en el entorno de una minicomputadora de los 80" es muy factible que un programa FORTRAN se escriba y ejecute más rápido que uno COBOL.
Pero estamos hablando de mantener un sistema de varias decenas de programas, que intercambian archivos, durante varios años
La capacidad en punto fijo de Fortran fue creciendo, pero siempre fue menor que los 99 dígitos de COBOL.
FORTRAN no tiene capacidad de comparar "cadebnas de caracteres".

F - Last but not least diría un lord, ya puede decirse públicamente que 3 de cada 4 compañías actuantes en la Argentina entre 1960 y 1980 tenían políticas comerciales específicas para desalentar el uso de COBOL por temor a que sus clientes quisieran "migrar de compañía" e independizarse de su proveedor habitual.
No puedo probar que esta política incluyera "ralentizar" los compiladores COBOL, pero sí que incluían "opciones específicas" que se separaban del Standar Codasyl para hacer más compleja la migración.

Claudio Di Véroli 27/08/2017


Alfredo: 

Interesantísimos tus detalles.

Sigo sin ver en qué manera lo que contás se contradice con mis comentarios, que van más bien a que la manera en que se enseñaba y se trabajaba en COBOL era muy "mecánica" y poco "científica".

Por supuesto que se podía hacer "buena programación COBOL"; pero no era frecuente.


Y aquí va otra "aneda". En los 1970 trabajaba yo en un gran centro de cómputos. Casi todo COBOL. La mayoría de los programadores venían de cursos. Uno o dos tenían un diploma de Contador Público, uno era Ingeniero Industrial. (No existían todavía títulos en Ingeniería de Sistemas). No eran demasiado buenos. Un día me hicieron caso y reclutaron una chica recién recibida de Computadora Científica en Exactas. No tenía idea de COBOL, pero la chica tenía la excelente formación científica de la que carecían los otros, y era muy rápida. Al mes me vino a ver el Jefe de Programación: "Claudio, ¡tenías razón! En tan poco tiempo, ya es nuestra mejor programadora COBOL!".

Alfredo Pérez 27/08/2017


Claudio

Creo que la elección del lenguaje y la persona dependen más del tipo de problema que de la preparación previa.
Como yo tampoco dispongo de información estadística, ni de criterios sobre qué cosa entendemos por "buen programa", respondo (como los payadores) con dos contra-anécdotas.

Oigame bien compañeroooo (talán,talan)

Una de mis tareas en la década de los 60 a los 70 era, precisamente entrenar a los nuevos programadores y asistirlos en sus primeros pasos, lo que implicaba concurrir diariamente a la empresa cliente (multinacional, en GBA con mi Renault Gordini). El jefe de proyecto era el auditor interno, quien periódicamente me invitaba a almorzar en el comedor de gerentes, para luego, caminata mediante, extraerme información sobre la marcha del proyecto.
En una de esos paseos me dice "No le parece que ocupar 15 de nuestros mejores personas durante dos meses (de curso) es demasiado tiempo? ¿No deberíamos contratar programadores ya entrenados?" Nota importante, los alumnos no provenían del equipo convencional que estábamos reemplazando, sino que eran jefes de sección, profesionales, muchos de los cuales iban a reemplazar, en su momento, a los gerentes.
Mi respuesta fue. "Señor, entiendo que usted me considera una persona medianamente inteligente y que domino el tema. Puedo asegurarle que dentro de seis meses (antes de la llegada del nuevo equipo) la mayoría de los alumnos serán programadores de primer nivel.
Ahora bien, suponiendo que ingresen 15 personas ya programadores, a las que Ud. y los demás gerentes deberán enseñarle los métodos, procedimientos, políticas explícitas o implícitas de la compañía y de cada departamento al nivel que tienen hoy los alumnos ¿cuánto tiempo les demandaría?"
Me concedió la razón.
Nota: por lo menos dos de esos alumnos ocuparon el cargo de Gerentes de Sistemas en la misma empresa.

Otra, que tiene que ver con el tipo de formación.
Fines de los 90, empresa multinacional y multiindustrial, entrevista al gerente de sistemas, ya desde la óptica del MinEduc - INET para inquirir sobre competencias esperadas de egresados de la educación técnica. 
La conversación derivó hacia la formación universitaria. Su postura era algo así:
"Tomamos egresados o alumnos avanzados de carreras de ingeniería, de sistemas o afines.
Los que vienen de XX o YY, ya saben hacer la mayor parte de los problemas comunes, a los dos años los pasamos a proyectos, donde hay que diseñar nuevos esquemas y se te quedan mirando y piden que los acerquemos a la solución.
A los de la UBA, los primeros años hay que "ajustarlos al molde", cuando los pasamos a proyectos y les tiramos algo nuevo te dicen -dejámelo mirar un poco- y a las pocas semanas te plantean variantes que son iguales o mejores que las de los profesionales del área"

Esto es, no todos los problemas son iguales, cada persona lleva un bagaje o mochila educativa distinta y sigue siendo muy complicado opinar sobre el "programa/sistema" más adecuado.

Miguel Ángel Simoes 27/08/2017


Estimados:

Con todo el respeto que siento por los programadores que hace cincuenta años estrenaban uno de los primeros títulos universitarios referentes a nuestra disciplina, no coincido con “la necesidad de excelente formación científica” para hacer “buena programación COBOL”.

En 1969 yo trabajaba en Alpargatas con el inolvidable Raúl Salgado en Análisis de Sistemas Comerciales y me enviaron a hacer uno de los primeros cursos formales de Cobol que dictaba Escuelas IBM.

Se quería evaluar su performance con respecto al RPG que utilizábamos y como se adaptarían nuestros programadores, la mayoría de ellos provenientes de la anterior instalación de UR y sin cursos formales de Computación.

Por eso eligieron para ir a este curso a un “no programador”. 

La performance de Cobol en la 370/145 superó a la de RPG y la productividad de los programadores se incrementó con el cambio de lenguaje de programación.

Claro que no todo fue mérito de COBOL: Debieron agregarse normas de organización del trabajo, entre ellas la utilización de una Source para mantener en forma centralizada las estructuras de archivos para generar las Data Division y también mantener en ella los programas, y se comenzaron a implementar herramientas de productividad, la más importantes de las cuales y que cambió radicalmente el método de trabajo de los programadores fue la implementación de SPMOL (Source Program Maintenance On Line) ya avanzada la década del 70. Les debo la historia de SPMOL , las terminales 3278 modelo 5 y las impresoras para los programadores.

Los artículos de IBM alertando sobre el rechazo de los programadores (en USA) a estas nuevas modalidades de trabajo, de que me proveían los dinos Gustavo Pontnau y no recuerdo si era la época de Eduardo Vila Echague o la de Benito González,(con la buena intención que “no me queme” implantando estas novedades), no resultaron aplicables para nuestra instalación.

Siempre he creido firmemente en aquello de “Lo que natura non da, Salamanca non presta”, Si alguien fué capaz de armar un tablero de 405, bien podía ser un excelente programador Cobol.

Además, nuestros programas eran rutinas administrativas, comerciales e industriales, no el análisis de la incidencia de las fases lunares en las mareas de los océanos …

Un abrazo a dinos y dinas, y especialmente a los dinos que fueron mis jefes en mis años de Tecnologia Informatica y siempre  impulsaron mis innovaciones.

Miguel Angel Simoes


PD: Comparo Cobol con RPG (en sus varias versiones). No tengo antecedentes que me permitan compararlo con Fortran. Tampoco sé si el ”skill” necesario para programar en Cobol es menor o mayor que el necesario para hacerlo en Fortran.

Jorge Hofmann 26/08/2017


Bien gente tenemos un tema para el querido DINO Solanas, ya sabemos que los programas de los 80´s se programaban como en los 70´s pero de lo que hablé era de los MAINFRAME en los 80´s empezaron con ese tema de procesamiento distribuido incorporando la novedad del on - line en el lenguaje COBOL por medio del CICS y de la famosa COMMAREA (¿remember?) y despues en los finales introdujeron la utilización de la mejor BD relacional (ojo para mí y no es discutible) por medio del lenguaje SQL ¡¡¡una exquisitez¡¡¡ tambien en los 80´s tuvimos la incorporación de unos equipos para procesamiento distribuido que eran los 8100 de IBM, que traian un lenguaje DPPX/DMS totalmente modular estructurado para la programación de procesos on-line el cual fué adaptado al MAINFRAME 380n con el nombre de CSP (Cross System Programming o algo así lenguaje totalmente modular estructurado y con directorio central de etiquetas, nombres de campos y catalogo de registros y pantallas).

Respecto del lenguaje APL igual que el PL I me da la sensación que no le dieron impulso comercial por alguna razón de IBM pero los dos eran buenísimos........

Recuerden que los DINOS y DINAS no solo viven del COBOL.......

Para David y Alfredo gracias por compartir este cacho de cultura........

Cris Vélez 28/08/2017


Coincido bastante con lo expresado por Alfredo.
A mi me tocó programar en gran cantidad de lenguajes por la variedad de rubros de las empresas que requirieron mis servicios. Conocí el ALGOL, FORTRAN, COBOL, ASSEMBLY, RPG, BASIC, VISUAL BASIC, C, C++, SQL, PHP y JAVA.  Pasé por equipos con muy limitados recursos de almacenamiento que nos obligaban a limitarnos en espacio sin perder calidad de resolución. Tuve que "desestructurarme" cuando apareció la programación estructurada, la modulada y la orientada a objetos. 
Por todo esto, me atrevo a considerar que un buen programador debe tener la habilidad de programar en cualquier lenguaje y adaptarse a todo tipo de problema a resolver. Debe partir de un conocimiento pleno de los comandos ofrecidos por ese lenguaje, leyendo manuales, asistiendo a cursos, etc, pero, sobre todo aplicando lo aprendido a problemas reales. Cuánto mas se programa en un lenguaje particular, mejor programador se vuelve.  La experiencia es fundamental para ser considerado un experto. 
A mi la universidad no me enseñó ningún lenguaje en particular pero me dió las herramientas para crear algoritmos que puedan expresarse en el lenguaje mas adecuado para resolver necesidades de diferentes índoles. Para mí no fue superior un lenguaje de otro (sacando RPG, que odié... jajaja), sí, mas adecuado uno que otro.
Tampoco existe una única formación del programador científico o comercial, universitaria o terciaria o autodidacta, inclusive. Es bastante personal y hay personas mas creativas que otras para programar, que minimizan recursos y producen mejores resultados. Yo he conocido programadores extraordinarios y no todos tenían la misma formación. Tampoco he tenido lenguajes preferidos sino proyectos que me interesaron mas que otros. El lenguaje es el lienzo y los pinceles... el programa funcionando adecuadamente para resolver el problema es la obra, el cuadro.
Cerrando mi participación en este debate saludo a Claudio, Miguel y Alfredo por sus interesantes puntos de vista.

Claudio Di Véroli 28/08/2017


> Miguel Ángel Simoes escribió: Estimados:  Con todo el respeto que siento por los programadores que hace cincuenta años estrenaban uno de los primeros títulos universitarios referentes a nuestra disciplina, no coincido con “la necesidad de excelente formación científica” para hacer “buena programación COBOL”.

Estimado Miguel Ángel: esto parece el juego del teléfono descompuesto, y como yo inicié esta parte de la discusión, te observo que jamás afirmé semejante cosa.

Sí dije que allá por 1972 (no había otras carreras con título universitario de computación en los años 1960 que yo recuerde) tener formación como Computador Científico AYUDABA a ser mejor programador COBOL que quien provienía de algunas otras carreras, o de ninguna.

En ningún momento sugerí la implicación inversa, y todos estamos de acuerdo en que se puede ser excelente programador COBOL SIN haber pisado Exactas.

Ida Bianchi 29/08/2017

Ir a Ida Bianchi: Cuando me inicié en COBOL tuve la suerte...