Mudanza

 Hola amigas y amigos del Consultorio Cobol.

Me mudo.

Me llevo todos los posts que no son de COBOL a mi nuevo blog elconsultorio.es

Aquí dejaré toda la info del Consultorio Cobol que seguirá estando disponible.

Mi camino me lleva al mundo del management humanista y del mentoring en carrera profesional, y he pensado que no tenía sentido mezclarlo con mi pasado como experta en programación COBOL.

Así que ha llegado el momento de separarnos :-)

Gracias por estar ahí todos estos años 💚

#thisistheway

Cobol VS Java: vuelve el debate

Hola amigas y amigos del Consultorio Cobol.

Como sabéis, hace tiempo que no escribo artículos de COBOL porque hace ya un tiempo que no programo. Pero es que ahora ni siquiera trabajo en un proyecto COBOL. Me he cambiado de bando...

Últimamente estoy trabajando con equipos Scrum que programan en java (o algo parecido), con su control de versiones con Bitbucket, sus branchs y demás.

El caso es que cada vez que digo: 

"recordad que lo prioritario es completar el sprint goal. Si terminamos lo nuestro, vemos de ayudar a los demás para asegurar que cumplimos el sprint goal."

Me responden: "es que no podemos trabajar más de una persona en un ticket."

Y si digo: "vale, pero hay 2 tickets." 

Entonces me dicen: "no, es que todos afectan a la misma clase. Solo puede tocar uno."

Y claro, yo que no estoy metida en la parte técnica, y que además soy de cobol-mainframe, no lo entiendo del todo.

Porque en cobol, recuerdo perfectamente repartirnos los programas (y rutinas) que había q tocar/crear. Incluso una persona podía hacer el JCL (en la versión Java el equivalente imagino que será un script) y otro el programa. O si había que tocar alguna tabla para añadir datos (parametría por ejemplo) lo podía hacer otra persona. 

Y sí, claro que para implantar/testear teníamos que ponernos de acuerdo si eran cosas enlazadas, pero podíamos trabajar varios en la misma funcionalidad. Digamos que el código estaba lo bastante troceado como para poder trabajar varios a la vez.

Eso ayudaba mucho a trabajar conjuntamente en el objetivo del sprint (cuando alguien terminaba, podía ponerse a ayudar al resto).

Entonces yo me pregunto, ¿esto es una cosa de la aplicación en cuestión con la que trabaja mi actual equipo? ¿Es que el código no está bien hecho y por eso todo está metido en el mismo "archivo"?

¿Es porque no estamos dividiendo bien las features? ¿O soy yo que no me entero?

Otra cosa que me dicen es que claro, que si cada uno se crea una branch, luego hay conflictos. Y yo me pregunto, ¿y eso es un problema? Te detecta los conflictos a la hora de hacer el merge y los "resuelves", ¿no?

¿Tan complicado es o es que buscamos la comodidad?

Por favor java developers, arrojad algo de luz... Mi objetivo sólo es terminar las cosas en curso antes de empezar otras nuevas...

#thisistheway

Grace Hopper Celebration

 La semana pasada tuve la oportunidad de participar en nuestra "Grace Hopper Celebration" particular, con una presentación sobre el Cobol en la era digital junto a varias compañeras de GFT para todas las personas de GFT España.

Hacía tiempo que no me ponía el gorro de cobolera en el trabajo y la verdad es que me hizo ilusión.

En mi parte empecé dando un dato muy importante: Grace y yo nacimos ambas un 9 de diciembre 💜

Y también hablé, ¡cómo no!, del Consultorio Cobol. Puse algunas estadísticas del blog para mostrar que la gente sigue buscando información sobre cobol en internet, nos siguen llegando visitas, el cobol sigue vivo en la red por todo el mundo.

Este mapa es de los últimos 6 meses. En total ha habido más de 85000 consultas. Podrían parecer estadísticas de hace 20 años, pero no, esto está pasando ahora.

También me hizo mucha ilusión conocer a algunos de los lectores del blog, gente que nos tiene en favoritos o que nos conocen desde hace años. ¡Hacía tiempo que no era "la del Consultorio Cobol"! xD

Mis compis contaron sus experiencias recientes con cobol que incluyen JSON y XML con cobol, cobol en Bitbucket, test automation... lo que viene a ser COBOL in the Digital Era, como bien anunciaba el título de nuestra presentación :-)

Les mando un enorme gracias a las cuatro por pensar en mí para participar en este día de Grace. Susana, Marian, Tamara, Cristina: ¡el mundo entero sigue programando en COBOL!

#thisistheway

Curiosidades COBOL: los límites del compilador.

DEPRECATED!

Con las nuevas versiones de COBOL, como COBOL 6, las cosas han cambiado!

Mira las novedades en la web de IBM

----------------------------------------------------------------------------------------------------------------------

Normalmente un programa no suele alcanzar los límites del compilador (a no ser que seamos muy bestias^^), pero existir, existen.

Alguna vez os habéis preguntado cual es el máxino número de OCCURS que puede tener una tabla interna??? Vamos a ver algunos números curiosos : )

Líneas de un programa:
El nº máximo de líneas que puede tener un programa son 999.999 líneas. Sinceramente, encontrarse un programa así de largo haría que nos acordásemos de toda la familia del que tuvo la idea...

En dos palabras, in-mantenible^^

Ficheros:
El nº máximo de ficheros por programa es de 65.535 ficheros.
Y si tal que haya que cruzarlos!!!

Longitud de fichero:
La longitud máxima que puede tener un fichero en su RECORD es de 1.048.575 posiciones.
Total na.

Variables de working:
La suma de las variables definidas en la WORKING-STORAGE, no podrá pasar de 134.217.727. Lo mismo para la LINKAGE-SECTION.

EVALUATE:
El nº máximo de cláusulas WHEN en un EVALUATE será de 256.
Si que son posibilidades!

PERFORM:
A lo largo del programa sólo podremos utilizar 4.194.303.
Debe ser por si queremos codifcar el programa de 999.999 líneas...

OCCURS:
El número máximo de occurs que podrá tener una tabla interna será de 16.777.215.

USING en la procedure:
Cuando tengamos un programa con LINKAGE SECTION, el máximo de variables que podremos incluir en la PROCEDURE DIVISION USING ... será de 32.767.

Cláusula VALUE:
El total de las longitudes de los valorse incluidos en las cláusulas VALUE no podrá superar los 16.777.215.


Todo esto y mucho más lo podéis encontrar en el apéndice B del manual de IBM
Enterprise COBOL for z/OS and OS/390 IBM
Language Reference