Las lentejas del COBOL* dan de comer porque los miles de bancos que lo usan pasan hasta el culo de migrar a un sistema de verdad, con bases de datos, consultas y tal (y tienes mogollón de otros lenguajes para crear frontends). Fuera de este ámbito laboral, un programador de COBOL se come los mocos.
* Frase favorita del profe, se nos quedó grabada a fuego en el coco.
Que va un toooochoooo-poooost:
Petrus, me encanta realmente que pienses eso, eso es precisamente la diferencia que hace que gente como tu no de ni un año al COBOL de vida y que a pesar de ello, lleve mas de 50 años dando candela. Asi, mientras que vosotros creeis que es un lenguaje del pleistoceno y que es una mierda en la que no programa ni Dios, me dais la oportunidad de que se quede sin profesionales este area por la inexistente vision de futuro que vosotros mismos le dais, lo que me permitira que gracias a vosotros gane increibles sumas de dinero por conocer ese lenguaje con el que se escribieron los 10 mandamientos de Charlton Heston en el Informal.
De hecho, y te digo que de esto se un rato, NINGUN BANCO (yo cononozco unos 25, y eso sin contar con hacienda, seguridad social, etc) ni siquiera se ha molestado en migrar sus programas hechos en COBOL por lo ineficaz que resulta una migracion a igualdad de condiciones a un lenguaje de programacion que ofrezca lo mismo en potencia y rendimiento que COBOL. Esto tiene dos vertientes:
1.- La MONETARIA: Migrar sus aplicativos implica un desarrollo de la de Dios y por consiguiente, una burrada de millones de euros para contratar una legion de programadores que migren todo eso a otro lenguaje (independientemente que se gastaria otra burrada en hacer el analisis de requisistos profundisimo de una entidad de ese tipo). Dentro del tema monetario, hay otro tema que debo explicar que tiene mucho que ver: La plataforma final en la que todo sera implantado. Si, ahora salgo que el mainframe patatin patatan, el rollo que suelta el Kujaku como de costumbre, pero decidme que lenguaje de programacion soporta concurrentemente a 115.000 tios sin que tengas que usar un Mare Nostrum. Si montas un super-blade-center con miles de nodos, tienes que currarte una infraestructura desde cero para balancear cargas y eso no es nada facil, ademas del overhead que supone eso desde el punto de vista de rendimiento. Y luego entra la importancia de los datos, que si, que la peli del Titanic se hizo en nosecuantas alpha con linux, pero que no veras jamas un banco o una agencia de viajes de renombre con linux y java, que no. A ver si os caeis del burro de una vez.
2.- La EXPERIENCIA: COBOL lleva mas de 50 años de desarrollo por detras, lo que significa que es un lenguaje que le da miles y miles de vueltas a C, java o "ponga aqui su lenguaje mas chupiguay", y por lo tanto, su eficacia, rendimiento, practicidad, etc, esta fuera de toda duda. Y si, a algunos les puede parecer un coñazo programarlo (a mi mismo me parece un verdadero coñazo) pero es el unico lenguaje que si sabes ingles, y pillas un programa, lo lees como si fuera un libro y se entiende de puta madre, estilo "SI <valor> EXCEDE DE "2" ENTOCES LLENAR CON BLANCOS LA <Variable> A NO SER QUE YA TENGA UN "6" POR LO QUE EN TAL CASO EJECUTAR <procedimiento> SI NO, ENVIAR MENSAJE A <procedimiento2> CON EL VALOR "9" EL EL PARAMETRO <parametro>..."
En otro orden de cosas, JAVA tiene una comunidad de desarrollo importante, en la que cada dia crean nuevas clases y metodos para enriquecerlo. Pero es que COBOL tiene una comunidad desarrolladora mas curtida y mucho mas elevada, hasta el punto de que XML, funciones nuevas, comunicaciones TCP/IP, etc, sean tambien vistas con COBOL y con una eficiencia sin precedentes. Ademas, esta muy refinado a nivel de programacion, viene a ser como la Demoscene en la Euskal, que en 64KB de codigo hacen efectos 3D y la pera, y son demos de 5 o 10 minutos dale que te pego con colores, textos animados y demas. Valga como ejemplo lo que se lleva ahora, que es la e-administracion. Antes, tu ibas a hacienda a pedir un papelito y la persona que tenias delante, tenia una emulacion 3270 (fijaos, TODAS la tienen, tipica pantalla negra dentro del windows estilo Putty con letras verdes, blancas, rojas, etc) , lanza una tranaccion CICS con tus datos y el resultado lo imprime en la impresoa de al lado suyo y te lo da con el sello. Ahora, tu vas desde internet, pides los datos y te lo genera en una pagina que tu mismo puedes imprimir. Claro, todo ese interfaz esta hecho en JAVA, concretamente tienen un Websphere con portlets hechos en JAVA que al final, via sockets o via MQSeries, tu al darle a "Enviar Formulario" en ese JAVA, el Websphere se pone en contacto con la cola MQ o ia sockets con el CICS del Host con los parametros pedidos, arranca la transaccion y el resultado lo devuelve a la cola o al socket y el websphere con el JAVA te lo presenta en el navegador. Pero esto tiene un problema: El Websphere y por consiguiente, JAVA y su VM, tiene un overhead o carga de la maquina de la de Dios, por lo que consumen mucha mas CPU.
Claro, que es CPU en un mainframe? Bah, si puede con todo. Si, claro que puede. El problema es que como la maquina es cara de mantener, y te cobran por potencia, si tienes una maquina con poca CPU y que puedas dar servicio a 115.000 tios en un tiempo de respuesta de un segundo, es mas que aceptable. Entonces dimensionas la maquina para que la tengas al 90-100% de CPU para que siempre este trabajando y des una buena calidad de servicio. Y existen unas tablas que te indican que tipos de rendimientos puedes dar en cada caso, por la noche das prioridad al BATCH, pr el dia al CICS para la peña, y cosas asi. Pero al tema. Ahora quitamos todo el cobol y el CICS y ponenos Websphere y JAVA. Pues pasa que te cavas tu propia tumba: ademas de que los costes de desarrollo e implantacion serian la pera, montar eso en el mainframe no te aguanta ni mil tios a la ez porque el JAVA es un lenguaje de mierda (con perdon, Keb) que es superineficaz y que consume la hostia de CPU. Bueno, pues quitamos el mainframe y ponemos un HP Superdome con 64 procesadores y HP-UX. Brutal, te cuesta una barbaridad y entonces solo puedes dar servicio a 500 tios. Vaaale, pues vamos a comprar otros 10 Superdomes y los clusterizamos. Bien, puedes dar soporte a 4000 tios pero ya tienes un desarrollo adicional de colas y balanceos con el que no contabas y anivel de programacion ya tienes que parchear cosas. Mas luego lo que te cueste cada maquina. Ah, claro, que la base de datos de juguete como Oracle cobra por cada procesador. Uhmmm, 64 x 10... x cientos mil euros mas. Espera, Websphere tambien se pone muy muy caro... pues nada, a Tomcat que sale mas barato. Y luego, vaya con 3000 tos el tomcat se me cae. Jodeeeeer, ahora, hay que solucionar el problema. A ver, hay que contratar mas personal a turnos para velar que tengamos calidad de servicio aceptable. Y la seguridad? Como sincronizamos todo el sistema de seguridad? Y suma y sigue...
Al final, lo "caro" que te salia el mainframe, resulta que era una mierda lo que pagabas despues de este desarrollo. Mas luego la evidente falta de servicio con lo que los clientes empiezan a sentirse insatisfechos. Total, ya conozco a 5 empresas que quitaron el mainframe, y despues de 5 años, arrepentidos, lo volvieron a poner. Por algo seria.
En fin, vaya tochopost que ha salido. Puff, en la Euskal puedo hablar de mil ejemplos mas como este que me ha tocado vivirlos, de hecho ando ahora en un desarrollo para conectar un CICS via sockets a Internet, porque poner un Apache o un Websphere es implanteable -y es increible la de nuevas funciones que tiene el CICS hacia Internet, no tenia ni puta idea y es una pasada, con un pequeño desarrollo este foro se podria poner bajo CICS y DB2

-.
Resumiendo Petrus, ese profesor tuyo que tan alegremente ha hecho esa afirmacion, le dices que no tiene NI PUTA IDEA de lo que habla.
EDIT: Releyendo su "cita", dile de verdad que entiende el por un programa COBOL, porque consultas, acceso a Bases de datos, etc, es el principal pilar de todos los programas escritos en COBOL para mainframe -si no, que sentido tiene programar en COBOL si no vas a acceder a datos? Si es precisamente lo que despunta a COBOL de otros lenguajes, su sencillez en el manejo de los datos.
Este tema ha sido editado por kujaku: 25 June 2006 - 03:55 PM