miércoles, 13 de septiembre de 2023

Curiosidades COBOL: los límites del compilador.

DEPRECATED!

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


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

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

martes, 31 de enero de 2023

Confianza y Seguridad - Personal Maps de Management 3.0 (agilecobol)

Hace un tiempo me propusieron dar unos talleres sobre algunas prácticas de Management 3.0 ya que es algo que utilizo con mis equipos.

El primero que hice fue sobre, como dice el título, mapas personales.

Para la presentación me basé en el artículo que podéis encontrar en su web "We Trust Who We Know" que me pareció que tenía una frase muy potente.

Empezaremos por la CONFIANZA.

Hacer software es una actividad de grupo. Esto es un hecho.

Podemos tomar el EQUIPO como la unidad básica en una empresa de software. Obviamente ese equipo está formado por PERSONAS. Pero hay que tener claro que: personas trabajando juntas no es lo mismo que equipo.

¿Y por qué no es lo mismo?

Bueno, para que el grupo se convierta en equipo tienen que darse una serie de características. Y muchas veces estas características no se dan y es lo que Patrick Lencioni llama "las 5 disfunciones de un equipo".

Os recomiendo leer el libro porque está muy bien y se lee súper fácil. Presenta la información en forma de novela, contando una historia de un equipo, en este caso un equipo de directivos.

Las 5 disfunciones se presentan en una pirámide y en la base de la pirámide está la primera y la que si no se soluciona, todo lo demás fallará: la ausencia de confianza.


Ausencia o falta de confianza entre los miembros del equipo.

Y esto se da principalmente porque no aceptan sentirse vulnerables delante del grupo. No mostrar ni errores ni debilidades (strike first, strike hard, no mercy!). Es decir, Invulnerabilidad. 

Y si esto no se soluciona empiezan a aparecer las otras disfunciones.

El que está directamente relacionado, el segundo piso de la pirámide, es el TEMOR AL CONFLICTO. Porque los equipos que no tienen confianza no discuten. Entendiendo discutir como intercambiar opiniones sobre un tema sin "controlarse".

¿A quién le pides ayuda? Al compañer@ con el que tienes más confianza. No te importa mostrarte vulnerable ante él/ella porque "estás en confianza", no te va a juzgar.

En el libro, Lencioni define confianza como la seguridad que tienen los miembros del equipo sobre que las intenciones de sus compañeros son buenas y sobre que no hay razón para ser ni protector ni cauteloso en el seno del grupo.

Pero, ¿qué ocurre? Que EL SOFTWARE ES UNA ACTIVIDAD DE GRUPO así que tenemos que ser capaces de generar ese ambiente de confianza.


Y pasamos a la segunda parte del título: la SEGURIDAD.

Es 2012. Google arranca una Investigación de 5 años y nosecuantos millones de dólares para crear equipos altamente efectivos.

Al principio las preguntas clave en la investigación fueron: ¿qué clase de personas forman los equipos más efectivos?, ¿con qué frecuencia se relacionan fuera de la empresa?, ¿tienen los mismos hobbies?, ¿comparten formación académica? Enfocándose en las personas que componían el equipo. 

Fue un poco desastre. No había un patrón.

Así que, para obtener un resultado diferente, hicieron algo distinto: cambiar de perspectiva en la investigación enfocándose en lo que se conoce como «normas de grupo»: aquellos comportamientos, tradiciones y reglas no escritas que se comparten en un grupo. Y entonces encontraron algo:

  1. Todos participaban. Esto lo denominaron como el fenómeno «igualdad de la distribución de turnos de conversación». Esto quiere decir que, en el grupo, todos hablaron en mayor o menor medida.
  2. Tenían sensibilidad social alta. Es decir, podían intuir cómo se sentían los demás.

En el Proyecto Aristóteles esto se definió como «seguridad colectiva».

En psicología sería "seguridad psicológica".

Lo que viene a decir que hay un sentimiento de confianza. Confianza en que en el equipo nadie te va a avergonzar, o rechazar o castigar por hablar. Hay confianza y hay respeto mutuo y puedes ser tú mismo.

En el estudio se demostró que, a pesar de que existen distintos comportamientos que ayudan al éxito de un equipo, la seguridad psicológica es la más importante.

El Proyecto Aristóteles había encontrado la clave para crear equipos de alto rendimiento.

Todo lo anterior para decir que "confiamos en quién conocemos". Y puesto que hemos visto que la CONFIANZA es la base para construir equipos, ya solo falta CONOCERSE. 

Y para eso están los mapas personales :-)

#thisistheway

miércoles, 22 de junio de 2022

La beca COBOL (agilecobol)

 La famosa beca COBOL.

¿Qué cobolero no la ha vivido? Alguno hay, pero seguro que a muchos os suena esa famosa formación inicial de semanas o meses, antes de sumergirte en el mundo de la programación cobol.

El año pasado tuve mi primer contacto como formadora en una beca cobol. Me tocó la "parte 2" con COBOL y DB2.

Era mi primera vez y como el covid aún andaba por ahí me tocó dar toda la formación en remoto, sin más herramientas que una reunión de Teams.

Al segundo día supe que aquello no marchaba bien. En una llamada con 8 personas, los alumnos perdían el "preguntarle al compañero". Perdían el ayudarse entre ellos. Y tenían que escuchar cómo yo iba resolviendo los problemas de cada uno. Era un caos.

Pero no hay nada mejor que la necesidad. Si los que llevan tiempo en esto no hacían más que decir que lo mejor para aprender a programar era hacer Pair Programming, pues había que intentarlo.
Preparé una pequeña presentación para explicar en qué consistía y elegí las parejas (fuimos haciendo cambios de pareja a lo largo de la semana).

Et voilà! El ánimo subió, los ejercicios salían más rápido, yo seguía pasándome por sus reuniones a dos cuando me necesitaban y todo el mundo le pilló el punto en un instante.
Formación salvada.

Este año he tenido otra oportunidad de participar como formadora en una beca cobol, pero esta vez en presencial.
Qué diferencia. Echaba taaaanto de menos la pizarra y los rotuladores... xd Y ver la cara a la gente. No hay nada como verle la cara a alguien para saber si está en dificultades sin que diga nada.

En la anterior beca había aprovechado para hacer una retrospectiva sobre la formación y así detectar puntos de mejora para la siguiente. Y en ésta me apliqué el cuento. Por ejemplo "mucha teoría seguida sin ver nada de práctica al principio", pues nos hacemos un "Hola mundo" el primer día y desde ahí avanzamos.

Esta vez no hubo pair programming así que pude comparar las dos situaciones y sacar conclusiones:

1. Enseñar en presencial gana de calle a enseñar en remoto.
Poder pintar en la pizarra, poder señalar con el dedo (en la pizarra o en el proyector), poder ver la cara de la gente que no consigue que su programa compile... Podría dar 1000 razones.

2. Se puede enseñar sin Pair Programming (obvio), pero.
- Trabajando por pares consigues que todo el grupo avance a la vez (o casi xd). El que lo pilla más rápido arrastra al que lo pilla más despacio, y al revés, se frena a los "demasiado rápidos" para mantener un ritmo sostenible.
- Trabajando de manera individual, tienes al que va al doble de velocidad que el otro. Y lo tienes que entretener con otra cosa mientras los que van más despacio terminan.
- Aunque siempre se preguntan entre ellos, no aprenden tanto unos de otros.
- Los que terminan rápido se ponen a hacer "otras cosas" y dejan de estar centrados en la formación.

3. Hay que adaptar las formaciones a los tiempos que corren.
Lo que aprendí en la primera beca me sirvió para esta última. Mucha práctica, teoría después de la práctica y no antes, deja que fallen y corrige después...

¿Qué os hubiese gustado encontraros en vuestra beca COBOL? ¡Os leo en comentarios!

#thisistheway

martes, 4 de mayo de 2021

Utilidades REXX V: modificar todos los miembros de una librería.

 Pues mira tú por dónde que una piensa que ya nadie necesita de sus conocimientos técnicos y de repente surge la oportunidad de hacer algo interesante :-)

La necesidad es lo que tiene.

Hoy os traigo un programa rexx que se recorre todos los miembros de una librería y le añade unas líneas de código. En mi caso una cabecera con comentarios, pero puedes usarlo para lo que necesites, o para hacer reemplazos de código modificándolo un poco.

Vamos al lío:

/* REXX** PGM POUR AJOUTER UNE ENTETE A TOUS LES MEMBRES D'UN PDS*/            
ADDRESS "ISPEXEC"                                       
/*INDIQUER LE PDS D'ORIGIN:*/
PDSORI="NOM.DU.PDS"
/*INDIQUER LE PDS DESTINATEUR:*/
PDSDES="NOM.DU.PDS"
"LMINIT DATAID(LMID) DATASET('"PDSORI"')"
"LMOPEN DATAID("LMID")"  
/*BOUCLE POUR TRATIER TOUS LES MEMBRES DU PDS ORI*/
DO FOREVER = 1                                       
    ADDRESS "ISPEXEC"
    "LMMLIST DATAID("LMID") MEMBER(LMMEM) STATS(YES)"   
    
    IF RC > 0 THEN LEAVE       
    
    /*NOM DU PGM A TRAITER:*/
    SAY "MEMBRE=" LMMEM
    
    FICHIERIN=PDSORI'('LMMEM')'
    ADDRESS TSO
    /*ALOCATION FICHIER ORIGIN*/
    "ALLOC FI(INDD) DA('"FICHIERIN"')"
    /*LECTURE DU FICHIER COMPLET*/
    "EXECIO * DISKR INDD (STEM INDD. FINIS"  
    "FREE FI(INDD)"
    
    FICHIEROUT=PDSDES'('LMMEM')'
    ADDRES TSO 
    "ALLOC FI(OUTDD) DA('"FICHIEROUT"') SHR REUSE"
    
    /*PREPARATION DE L'ENTETE*/
/*AQUI PONED TANTOS OUTDD. COMO OS HAGAN FALTA*/
    OUTDD.=''
    OUTDD.1 = "***************"
    OUTDD.2 = "*CABECERA*"
    OUTDD.3 = "***************"
    
/*AQUI CAMBIAD EL 4 POR EL SIGUIENTE NUMERO AL ULTIMO OUTDD. ANTERIOR*/
    J=4
    DO I=1 TO INDD.0
       OUTDD.J = INDD.I
       J=J+1
    END
    
    /*ECRITURE DU PGM AVEC L'ENTETE*/
    "EXECIO * DISKW OUTDD (STEM OUTDD. FINIS"  
    "FREE FI(OUTDD)"
END                                                     
"LMFREE DATAID("LMID")" 

Disculpad el francés pero es que creé este código para usarlo en el curro, y trabajo en francés xd Pero creo que se entiende bien.

Lo primero que hacemos lo tenéis también en el artículo Utilidades Rexx IV: listar miembros que es precisamente eso, recuperar la lista de miembros que hay en una librería.

El nombre de la librería podríamos pasarla como un parámetro desde el job, pero me dio pereza. Se trata de recorrerse la librería origen, y crear en la librería destino una copia de cada miembro con el código modificado. Lo he hecho así porque no quería "cargarme" el código original pero lo podéis personalizar al gusto.

El JCL para ejecutarlo:

//REXXJCL  JOB (OPC0,001),'CONSU',REGION=0M,NOTIFY=&SYSUID,
//            CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),COND=(4,LT)
//REXXPGM  EXEC PGM=IKJEFT01                              
//SYSEXEC   DD DSN=librería donde tengo el programa rexx,DISP=SHR               
//ISPPROF   DD DSN=&&PROF,UNIT=SYSDA,SPACE=(TRK,(5,5,5)), 
//             RECFM=FB,LRECL=80                          
//ISPSLIB   DD DISP=SHR,DSN=ISP.SISPSLIB                  
//ISPPLIB   DD DISP=SHR,DSN=ISP.SISPPENU                  
//ISPMLIB   DD DISP=SHR,DSN=ISP.SISPMENU                  
//ISPTLIB   DD DISP=SHR,DSN=ISP.SISPTENU                  
//ISPLOG    DD SYSOUT=*,DCB=(LRECL=125,RECFM=VBA)         
//SYSTSPRT DD  SYSOUT=*,DCB=LRECL=125                     
//SYSPRINT DD  SYSOUT=*                                   
//SYSTSIN  DD  *                                          
  ISPSTART CMD(REXXENT)                                   
/*                               

Espero que os sea útil. Cualquier duda, os leo comentarios :-)

lunes, 26 de abril de 2021

El daily "del revés" (agilecobol)

Hola amigas y amigos del Consultorio Cobol.

En año nuevo tuve una revelación. Esta me sobrevino cuando intenté clasificar su especie... digo...

Bueno, digamos más bien el 2 de enero, porque el 1 no estaba yo en condiciones de revelar nada xd

Estaba preparando una presentación sobre los daily meetings para mis equipos, porque estamos en época de cambios y las dailys no se estaban haciendo bien. Y hacía tiempo que lo sabía pero para cambiar el formato no me valía con decir "ahora lo vamos a hacer así porque lo digo yo". Que es muy de manager viejuno pero ya sabéis que yo soy una moderna.

Así que preparé una especie de taller sobre el daily meeting (porque no somos ágiles, pero hacemos daily desde hace mucho) para compartir mis reflexiones con el equipo y también para que ellas y ellos reflexionasen sobre el tema.

Primero, para desmentir algunos mitos, preparé un kahoot con preguntas sobre el daily meeting, a ver cuánto sabía realmente el equipo sobre lo que era y para qué servía. Si os interesa os lo paso.

Luego preparé una ppt de apoyo para soltar la chapa sobre la daily. 

Y estaba yo en esas cuando iba a empezar a explicar que ya no vamos a ir uno por uno soltando el rollo de las 3 preguntas (que ni Jeff Sutherland lo entiende) sino a hablar de los objetivos de la semana y de las tareas en curso, cuando lo supe: íbamos a hacer el daily "del revés".

A lo Stranger Things. 

Con esto lo iba a petar seguro.


#thisistheway