275 replies to this topic

[ArmiSael]

Como "nota" respecto a eso de la lentitud de Java, Esto igual os interesa ^^U

[kujaku]

Una cuestión técnica sobre COBOL:

Cuando lo di por primera vez, no se creaban binarios ejecutables propiamente dichos (.EXE), sino un fichero de no recuerdo que extensión que sólo el interprete de COBOL podía ejecutar.

¿Ahora sigue funcionando igual? Porque vamos, no se puede comparar la velocidad de proceso de un programa (bien) hecho en C con uno similar pero escrito en lenguajes interpretados como Python, Perl, Java, etc...

En entorno PC no te puedo decir, algo me suena que se generaban ficheros .COB, pero que si que se podian compilar en un EXE. En el entorno que me muevo yo, primero escribes el fuente, y con un JCL lo compilas para generar un binario que se carga en una libreria LOAD. En mi caso concreto, que trabajo contra CICS, esa libreria LOAD depende en gran medida de los miembros del CICS, si que se hace referencia a ello en el JCL para añadir el codigo compilado dentro de esa libreria y asi poder hacer referencia a ese programa dentro del CICS.

Lo siguiente es un tipico JCL que uso yo para compilar un programita Cobol:

//COMPICOB JOB  CLASS=A,NOTIFY=&SYSUID,MSGCLASS=X,MSGLEVEL=(1,1)	 
//*			COMPILA CICS-COBOL
//*================================================================  
//* HACER:	C  (NOMBRE FUENTE)						   
//*		   Y SALIR CON:  CAN						  
//*================================================================  
//CICS01   EXEC PGM=DFHECP1$,REGION=8M,					  
//		 PARM=(COBOL3,NOSOURCE,SP)				 
//STEPLIB  DD DISP=SHR,DSN=CICSTS22.CICS.SDFHLOAD				
//SYSPRINT DD SYSOUT=*							   
//SYSUDUMP DD SYSOUT=*							
//SYSPUNCH DD DISP=(NEW,PASS),DSN=&&CICSOUT0,UNIT=SYSDA,			 
//			SPACE=(800,(500,500)),DCB=BLKSIZE=400		  
//SYSIN	DD  DSN=MI.DATASET.FUENTE(PEPITO),DISP=SHR			
//*									  
//COMCOB	EXEC PGM=IGYCRCTL,REGION=8M,					   
//	  PARM=(APOST,LIB,XREF,MAP,RENT,BUF(32760),				
//			SSRANGE,OFFSET,TRUNC(OPT))				 
//STEPLIB  DD  DSN=IGY310.SIGYCOMP,DISP=SHR					  
//SYSIN	DD  DSN=&&CICSOUT0,DISP=(OLD,DELETE)				  
//SYSLIB   DD  DSN=CICSTS22.CICS.SDFHCOB,DISP=SHR				
//SYSLIN   DD  DSN=&&LOADSET,DISP=(NEW,PASS),UNIT=SYSDA,		 
//			 SPACE=(800,(500,500))				 
//SYSPRINT DD  SYSOUT=*							  
//SYSUDUMP DD  SYSOUT=*							  
//SYSUT1   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//SYSUT2   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//SYSUT3   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//SYSUT4   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//SYSUT5   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//SYSUT6   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//SYSUT7   DD  SPACE=(800,(500,500),,,ROUND),UNIT=SYSDA		  
//*									  
//LKEDITA EXEC PGM=IEWL,PARM='LIST,XREF,CALL,AMODE=31,RMODE=ANY',
//			 COND=((4,LT,COB3),(4,LT,CICS)),REGION=8M		  
//SYSLIB   DD  DSN=CEE.SCEELKED,DISP=SHR					 
//		 DD  DSN=CICSTS22.CICS.SDFHLOAD,DISP=SHR		   
//		 DD  DSN=CICSTS22.CICS.SDFHEXCI,DISP=SHR		   
//		 DD  DSN=SYS1.LINKLIB,DISP=SHR				 
//		 DD  DSN=TCPIP.SEZATCP,DISP=SHR				
//SYSLIN   DD  DSN=CICSTS22.CICS.SDFHCOB(DFHEILIC),DISP=SHR  
//		 DD  DSN=&&LOADSET,DISP=(OLD,DELETE)			   
//		 DD  DDNAME=SYSIN						  
//SYSLMOD  DD  DISP=SHR,DSN=CICSTS22.CICS.SDFHLOAD(PEPITO)			
//SYSPRINT DD  SYSOUT=*							  
//SYSUDUMP DD  SYSOUT=*							  
//SYSUT1   DD  SPACE=(1024,(500,500)),UNIT=SYSDA			 
//*														  

Lo vereis como chino, pero bueno, este JCL tiene 3 pasos:
1.- CICS01: Prepara el entorno de compilacion y llama a las librerias LOAD del CICS, a la vez que usa mi fuente en la libreria MI.DATASET.FUENTE con el miembro PEPITO (es mi ficheo de cobol).
2.- COMCOB: Añade todas las librerias del CICS y utilities de Cobol y llama al programa IGYCRCTL que es quien compila de codigo fuente a codigo objeto. Ojo a la STEPLIB IGY310.SIGYCOMP, si se te olvida ponerla no podras hacer nada, ya que el compilador Cobol reside en ella.
3.- LKEDITA: El paso este Link-Edita el codigo objeto generado para crear un miembro LOAD, como si fuera un EXE de mainframe, vamos. Ese miembro LOAD que es al final el que ejecutara CICS para que funcione mi programa, y lo he dejado en CICSTS22.CICS.SDFHLOAD(PEPITO). Como lo he metido dentro de la libreria maestra de LOAD del CICS, me lo encontrara siempre (aunque no es correcto hacerlo asi, lo suyo es hacerme mi propia liberia y meter mis LOADs en ella y luego decirle al CICS que me la concatene cuando se inicie, pero vamos, para el ejemplo me vale).

Este ultimo paso de linkeditacion viene a ser cuando tienes en JAVA un .class y luego ese .class lo transformarias en un EXE para que el PC te lo ejecute si maquina virtual ni leches. O mejor ejemplo, cuando programas en ensablador, que compilas con el ASM y te deja un OBJ, y luego con un link haces de ese OBJ un EXE o un COM...

Este tema ha sido editado por kujaku: 03 July 2006 - 01:59 PM

[kebrantador]

Como "nota" respecto a eso de la lentitud de Java, Esto igual os interesa ^^U

interesante lectura.

[Anime-boy]

A mi también me parece más sorprendente que un crío de 8 años esté currando.

Me uno a la mocion de q un niño de 8 años este trabajando ya. joder.. ese niño hara dinero XDD

[kujaku]

interesante lectura.

Ya, por eso el Azureus se caracteriza por ir tan rapido xDDDD

Edit: Miraos tambien esta web. Vereis como IBM ha tenido que desarrollar un procesador especializado solo para JAVA por el overhead increible que produce hasta el punto de que hasta la llegada de este procesador, nadie queria ver ni en pintura a JAVA bajo z/Series (y por lo tanto Websphere, y todo lo relacionado) porque la maquina se consumia.

Este tema ha sido editado por kujaku: 04 July 2006 - 09:48 AM

[ArmiSael]

kujaku, el link que he puesto no es la única comparativa que existe con el mismo resultado. Habla con Google y culturizate un poco sobre Java que como tú mismo dices estas muy pez. Lo que no se puede es negar lo evidente y de los datos que te dan, si lo haces, básicamente, es polemizar a la ligera.

PD: Has pensado el motivo por el cual, según dices tú, IBM invierte y desarrolla un procesador especializado "xD" para Java?? Total si no querian ni verlo en pintura, para que gastar recursos y pasta no?? Vamos si sudo pestes de una tecnología para que gastar recursos y pasta en ella?? Curioso no te parece.

Este tema ha sido editado por ArmiSael: 04 July 2006 - 10:26 AM

[kujaku]

PD: Has pensado el motivo por el cual, según dices tú, IBM invierte y desarrolla un procesador especializado "xD" para Java?? Total si no querian ni verlo en pintura, para que gastar recursos y pasta no?? Vamos si sudo pestes de una tecnología para que gastar recursos y pasta en ella?? Curioso no te parece.

Y segun tu parrafo, parece que no sabes leer entre lineas. Para empezar, IBM es de las empresas que mas esta investigando en ese area para hacer sus sistemas mas "abiertos", en cuanto a programacion y demas, como JAVA, o C++, por contar unos cuantos lenguajes. Lo que IBM invierte en ese procesador es una cantidad irrisoria comparada con las perdidas que le supone no instalar un Websphere Application Server en z/OS, ahora mismo, su producto estrella.

Para que tengas una culturilla general, este tipo de sistemas se cobra por potencia de maquina. Puedes tener el mismo software instalado, pero si tienes mas MSUs que yo tu vas a pagar muchisimo mas por lo mismo que tengo yo. Con la llegada del WAS y su JAVA, se dieron cuenta que a igualdad de proceso, WAS se cepillaba toda la CPU y eso les obligaba a upgradear con mas MSUs su maquina original para obtener el rendimeinto original, y eso monetariamente hablando suponia un gasto adicional de medio millon de euros mas al año al cliente. Cual era la solucion? Pues que el cliente le decia a IBM que se metiera por el culo su WAS o, que preferia poner el WAS en una plataforma Intel (con los problemas de disponibilidad que eso pudiera generar). Como eso a IBM no le parecio procedente porque ahora, en plena epoca On-Demand y SOA, que digan un NO rotundo a Websphere seria un suicidio profesional por su parte, sobre todo en estos sistemas que son los que les da de comer, los laboratoros de IBM en Rochester idearon un procesador IGUAL que cualquier otra PU dentro del z/Series, pero lo puso con un dispatcher para cuando encuentre codigo JAVA lo ejecute solo el, a un precio mucho mas asequible que lo que supondria upgradar en potencia a un z/Series con una PU tradicional.

De esa forma, los clientes con la adquisicion de un zAAP podrian ejecutar JAVA (usease, WAS) bajo z/OS a un precio interesante.

Ahora, hazte esta pregunta: Por que el USS del z/OS (Unix System Services) que está enteramente programado en C y es en esencia un completo System V Unix dentro del z/OS, NO necesita un "procesador especial para ejecutar C"? El Unix lleva toda la pila TCP/IP, servidores de MQseries, conectores de bases de datos DB2, todo lo relacionado con servidores web y XML, servicios de Middleware diverso, e-mail, impresion, en definitiva, todo el Communications Server del z/OS que sin el la comunicación seria imposible. Y claro, como eso no consume nada de CPU (LOL) a pesar de estar sempre on-line y como pieza estrategica, pues no necesita procesador, no?

Bueno, resumiendo, que paso ya de discutir contigo. Desde mi experiencia JAVA no es optimo y otros lenguajes si lo son. Y me remito a un ejemplo tan simple como el Azureus que es un ejemplo de un programa libre con muchos desarrolladores por detras que han ido optimizando codigo pero que apesar de ello es una carraca de programa y en PC, en mainframe es que ni siquiera es aplicable tu comparacio JAVA vs lo que sea.

PD: Y aplicate el cuento de polemizar a la ligera, ya que tu de cobol tampoco parece que seas el rey y hay que ver como lo has puesto a parir en tu pleno desconocimiento...

[Petrus]

Como "nota" respecto a eso de la lentitud de Java, Esto igual os interesa ^^U

Creo que aquí no se ha hablado de C++, sino de C puro y duro. El lenguaje en el que se compila el kernel, sus módulos, bash, libc6 y la mayoría de paquetes básicos de un sistema operativo. No compares C con Java, porque no hay color.

C++ se usa más en software orientado a aplicaciones gráficas (y en el BNBT tracker, pero ese es tema aparte )

[ArmiSael]

PD: Y aplicate el cuento de polemizar a la ligera, ya que tu de cobol tampoco parece que seas el rey y hay que ver como lo has puesto a parir en tu pleno desconocimiento...

No he puesto a parir a Cobol, solo he dicho que para cada necesidad se ha de aplicar el lenguaje que sea más óptimo, a ver si es que no me estas leyendo x'D Sigo diciendo lo mismo, no se gastarían recursos para adaptar algo a una tecnología que es deficitaria según tú y que no aporta nada, algo tendrá para que quieran implantar WAS.

Creo que aquí no se ha hablado de C++

Lo de "nota" iba por eso, ya se que no se hablaba de C++ pero es un apunte sobre la lentitud de Java.

[jal]

a resucitar toca, leo en microsiervos que el cobol es el futuro, así que todo el mundo a aprenderlo xD

COBOL: un lenguaje que está lejos de estar muerto

Por: Alvy el Ordenadores

Según cuentan en ComputerWorld, más del sesenta por ciento de los directores de informática de empresas estadounidenses dijeron en una reciente encuesta que todavía usan activamente el lenguaje COBOL en algunos de sus sistemas, y, lo cual es todavía más asombroso, también casi un sesenta por ciento dijeron estar creando nuevos programas en COBOL. Este lenguaje se inventó en los años 60, era muy común en bancos y grandes empresas, sobre todo las que necesitaban «procesamiento por lotes» de muchísimos datos. Luego sufrió un estancamiento hacia 1985 (versión COBOL-85) y se renovió desde las cenizas cual ave Fénix como COBOL-2002, que es el estándar actual. Según la Wikipedia, se espera una nueva versión de COBOL y herramientas hacia 2008 y además:

Según un informe de 1997 estima que el 80% de los 300.000 millones de líneas de código existentes [en el mundo] están creadas en COBOL, escribiéndose 5.000 millones de líneas nuevas de COBOL cada año. Con todo eso, hoy por hoy, la programación en COBOL es uno de los negocios más rentables del mundo de la informática.

P.D. y aprovechando el hilo, larga gloria al baneo de haibara xDDD

[kujaku]

Tambien los costes de mainframe en 10 años se han reducido a la mitad, por lo que empieza a ser interesante la implantacion de uno de ellos ahora... asi que no me extraña que el COBOL cada vez se use mas... Deberian sacar un COBOL web o algo asi para desterrar de una vez la inmundicia que es JAVA

[thexsam]

Deberian sacar un COBOL web o algo asi para desterrar de una vez la inmundicia que es JAVA

Eres un enfermo

Hombre, no se, lo de que tengo un % tan elevado de la facturacion para mi que tambien influye que por la mierda programas que hacen para los bancos les cobran una puta salvajada. Luego pillan el mismo programa, le meten algunas letrillas más para que no tenga el mismo tamaño y se lo venden a otro banco (a un colega le metieron una bronca de cojones porque cuando le dijeron que hiciese eso va y pone un smilie en el nombre del programa . xDDDD)

P.D. y aprovechando el hilo, larga gloria al baneo de haibara xDDD

no hables muy alto...

[kujaku]

Eres un enfermo

Hombreeeee, eso se sobreentiende

Justo el otro dia estabamos hablando de la salvajada de millones que se gasta el Grupo Eroski para sus sistemas informaticos con RedHat/Itanium/Oracle/JAVA que se caen uno detras de otro, parcheando una ñapa con otra mayor y demas, con la comparativa de la cadena El Corte Ingles, puramente mainframe. ECI se gasto la pasta gansa una vez, pero les debe ir de vicio (Dubli lo sabra mejor que yo, que seguro que ha tenido que consultar movidas en terminales tontos marca Memorex Telex), sobre todo el sistema de aprovisionamiento por flotacion que maneja el mainframe automaticamente, suprimiendo almacenes inmensos que gastan la de dios de pasta como los de Eroski.

Pero vamos, todo depende de la competencia del departamento de desarrollo y la sub-sub-sub-subcontratacion que se tenga, porque ojo, hacer guiñapos en COBOL es muy facil, solo que por fortuna el mainframe no deja ejecutar algo susceptible de ser colgado, y tradicionalmente se le tenia tanto respeto al mainframe que la peña para ponerse a programar algo, ya lo hacia bien robusto todo, con toda su ingenieria del software por detras, cosa que muchas empresas que desarrollan lineas de codigo a saco parecen olvidar...

Este tema ha sido editado por kujaku: 18 October 2006 - 04:27 PM

[Bad_CRC]

Hombreeeee, eso se sobreentiende

Justo el otro dia estabamos hablando de la salvajada de millones que se gasta el Grupo Eroski para sus sistemas informaticos con RedHat/Itanium/Oracle/JAVA que se caen uno detras de otro, parcheando una ñapa con otra mayor y demas, con la comparativa de la cadena El Corte Ingles, puramente mainframe. ECI se gasto la pasta gansa una vez, pero les debe ir de vicio (Dubli lo sabra mejor que yo, que seguro que ha tenido que consultar movidas en terminales tontos marca Memorex Telex), sobre todo el sistema de aprovisionamiento por flotacion que maneja el mainframe automaticamente, suprimiendo almacenes inmensos que gastan la de dios de pasta como los de Eroski.

nosotros estamos haciendo algun desarollo con eroski (te suena el projecto abaco?) como SOLO saben java lo usan para TODO.

que necesito hacer un script que se conecte por ftp y recoja unos logs: hago un script QUE LLAMA A UN CLIENTE FTP EN JAVA.

luego normal xD

[ArkhanVoid]

nosotros estamos haciendo algun desarollo con eroski (te suena el projecto abaco?) como SOLO saben java lo usan para TODO.

que necesito hacer un script que se conecte por ftp y recoja unos logs: hago un script QUE LLAMA A UN CLIENTE FTP EN JAVA.

luego normal xD

¿Pero a quién te refieres con "SOLO saben"? ¿ El grupo eroski tiene contratada a gente para el desarrollo de software o encarga proyectos a otras empresas? Lo que no me puedo imaginar es que una empresa de software tenga a gente que sólo sabe java.

En fin, la tecnología está para solucionar problemas, no para crearlos. JAVA es un medio, no un fin. ¿Ni si quiera te dejan hacer los scripts en bash? xD

[jal]

En fin, la tecnología está para solucionar problemas, no para crearlos. JAVA es un medio, no un fin. ¿Ni si quiera te dejan hacer los scripts en bash? xD

¿de que manga de shirow has copiado esto? xDDD

[Yentin]

donde curro yo usan Cobol para todo, si es lo ke tiene la banca, ke como cobol funciona desde hace más de 30 años y va bien pos es fiable y pasan de cambiar XD

[kebrantador]

dios Power Ranger Rojo como te odio por resucitar estos hilos xDDD

Bueno a mi me quedan los días contados donde tendré que trabajar con cobol -edit: no directamente yo... pero por debajo de la capa web... en serio, no se lo deseo a nadie xDD- , que me cambio de curro y ahí desarrollan su propio producto, q no tiene nada q ver con cobol ni banca!!! aleluuuuyaaaaa!!!

El tema de los lenguajes es un poco tambien como dice bad... llegan a una empresa, le piden un producto, y la mayoria de las veces no miran que sería el lenguaje más apropiado cogen el que más controlan aunque podría hacerse mucho mejor en otros... si no de que sobrevive cobol... de que los q llegan a analistas/jefes en los bancos hoy en dia casi todos vienen del mundo cobol y no ven más alla. Les dices de hacerlo con Oracle y dicen "quita quita" sin realmente tener ningun dato objetivo ni de rendimiento ni de coste ni de nada, solo q no saben XDDD

Y si, lo mismo pasa por ej con java, q mucha gente es lo único de lo q tiene idea y cuentale tu que se ponga a hacer scripting de unix... lo flipa... y es normal.

Es como un tio que trabaje con pl/sql... desde ahí se puede hacer el 99% de las aplicaciones, enviar mails, genrar xml, por supuesto trabajar con la base de datos...

Y tambien claro, pq si ya el 90% de algo esta hecho en cobol, o en java o en lo que sea, pues para que vas a cambiar?

Ala, por dar por culo un poco.

just my 2 cents.

Este tema ha sido editado por kebrantador: 19 October 2006 - 11:47 PM

[Bad_CRC]

acabo de ver esto en meneame:
http://www.codinghor...ves/000517.html

xD

[Wendigo]

En esa tabla falta el "Hello World" de ADA y sus miticos 300 y pico Kb de ejecutable... XDDDD

Edit: Ishhhh... Miento, si que esta (gnat), aunque se ve que se tomaron la molestia de quitar la basura que te mete por defecto... XD

Este tema ha sido editado por Wendigo: 20 October 2006 - 09:48 AM

[ArkhanVoid]

El tema de los lenguajes es un poco tambien como dice bad... llegan a una empresa, le piden un producto, y la mayoria de las veces no miran que sería el lenguaje más apropiado cogen el que más controlan aunque podría hacerse mucho mejor en otros... si no de que sobrevive cobol... de que los q llegan a analistas/jefes en los bancos hoy en dia casi todos vienen del mundo cobol y no ven más alla. Les dices de hacerlo con Oracle y dicen "quita quita" sin realmente tener ningun dato objetivo ni de rendimiento ni de coste ni de nada, solo q no saben XDDD
Y si, lo mismo pasa por ej con java, q mucha gente es lo único de lo q tiene idea y cuentale tu que se ponga a hacer scripting de unix... lo flipa... y es normal.

Sí, yo creo que lenguajes como cobol y fortran sobreviven por dos razones: porque hay mucho trabajo de mantenimiento de sistemas software programados en esos lenguajes y porque son los lenguajes con los que está familiarizada la gente en los sectores de la banca (cobol) y el cálculo científico (fortran). Y no me parece mal, porque suele haber más razones. Por ejemplo, cobol (según tengo entendido) tiene una sintaxis fácil de aprender y los compiladores de fortran están super optimizados y estudiados para rendir al máximo en mainframes con gran capacidad de cálculo.

Pero a mí el ejemplo del script me parece ya el colmo. Además, yo creo que programación shell se da en todas partes, desde módulos hasta ingenierías (en CEAC ya no lo sé). Y si no, tiras de man y en menos de media hora te sabes hacer un script que llame a un ftp.

Por cierto, ya no tengo ni idea de qué va exactamente este hilo xD