Buscar este blog

viernes, 7 de agosto de 2009

AR

No siga leyendo. Esto es una entrada egoísta, que me escribo solo para mí, por lo que lo más probable es que no entienda nada de nada. Estamos en verano, con muy altas temperaturas, con mucho calor que calienta las neuronas cerebrales y hacen a las personas escribir cosas como esta, que no se entienden. Bueno, algunas personas si lo entenderán.
Empecemos por el título, AR es un acrónimo que podría significar muchas cosas, por ejemplo “Armando Rodríguez” o “Adelante Rocinante”. Pero no es el caso ya que está en inglés y significa “Access Registers” y es el título del capítulo cinco de un manual en inglés titulado z/OS MVS Extendeded Addressability Guide. Yo mismo me pregunto qué hago yo leyendo estas treinta y ocho páginas, en perfecto inglés americano que cuentan cómo se puede acceder desde un espacio de direcciones ejecutándose bajo un sistema operativo z/OS de IBM a otro espacio de direcciones para ver o modificar datos.
No le quedará ninguna duda a nadie de que estamos hablando de informática, esa cosa tan de moda hoy en día. Pero pocas personas saben o entienden que hay muchas clases de informática. Desde que tenemos PC en casa la informática se entiende algo más, por las personas corrientes, pero al mismo tiempo se le aplica al concepto un reduccionismo exagerado que deja el término en casi una insignificancia.
Cuando digo que mi profesión es de informático todo el mundo cree saber de que hablo, pero en pocas ocasiones aciertan. Les tengo que decir, haciendo un ejemplo gráfico y significativo que soy “mecánico de aviones” pero que no sé arreglar una simple bicicleta. Con esto quedan más desconcertados si cabe.
Corría noviembre de 1972 cuando accedí por oposición a una plaza de programador informático en el Servicio Electrónico de una Entidad Bancaria. Por aquellos años, el PC “casero” todavía no había visto la luz, ya que lo hizo en 1980. Sin embargo la informática a gran nivel existía sobre todo en entidades financieras, comerciales o de seguros. Había que especializarse y en la universidad todavía no se cursaban este tipo de estudios, por lo que la formación era impartida y ofrecida por las casas comerciales, en este caso IBM y los propios compañeros de trabajo, que por aquella época todavía no temían por sus puestos de trabajo y enseñaban y se retroalimentaban con los recién llegados. Tuve muchos profesores, pero sin olvidarme de nadie quiero dejar plasmado aquí un emocionado recuerdo a Antonio, que mucho sabía y mucho me enseñó. Conservo uno de sus programas de aquellos años que sigue funcionando a la perfección 37 años después. Mérito de Antonio y mérito de IBM que presenta en la actualidad unos sistemas operativos compatibles con programas realizados hace una montonera de años.
Como programador debía aprender un lenguaje para hacer los programas y el elegido fue el denominado PL/I. Pero yo era una mente inquieta y no quería limitar a un solo lenguaje de los existentes, por lo que por mi cuenta y fuera de trabajo hice mis pinitos con COBOL, RPG-III, un poco de FORTRAN y un mucho de ASSEMBLER. El lenguaje más parecido a escribirlo en un código ininteligible muy aproximado a como la máquina ejecuta luego las instrucciones. Un lenguaje maravilloso en el que se podía hacer de todo, rápido, con mucha efectividad y en el que, ayudado por Víctor, Rafa y Alejandro, además del ya mencionado Antonio, disfrutaba de lo lindo, haciendo los mismos programas en PL/I y en assembler y echando carreras entre ellos. Siempre eran como la liebre (el assembler) y la tortuga (el PL/I), en los diferentes aspectos de velocidad, rendimiento, consumo y rapidez. Lo único era que se tardaba mucho más en hacer el programa y ponerlo a punto en assembler que en PL/I, además los programas en assembler son muy personales y más difíciles de mantener y modificar por una persona diferente a la que lo ha hecho. Mis pinitos con el assembler me hicieron dejar mi puesto de programador de aplicaciones y pasarme al de programador de sistemas. Ahí sí que se usaba el assembler a tope, se codificaba muy cercano al sistema operativo, rutinas muy especiales que mejoraban el rendimiento general de la máquina o que incorporaban nuevas funcionalidades que complementaban los diferentes programas estándar suministrados por IBM y otras casas comerciales.
Han pasado más de treinta años de mis primeros contactos con el assembler. He hecho muchos programas a lo largo de mi vida laboral, pero el assembler ha progresado mucho y en una rutina que tengo que desarrollar en estos días me encontré con que se tenía que ejecutar en un modo denominado “AR”. ¿Y esto que narices es? Para aprender, cuando ya no se dispone de personas al lado que te enseñen, están los manuales como el que hemos comentado que cuenta con pelos y señales que es lo que hay que saber para hacer programas, por supuesto en mi querido assembler, en modo AR. Nunca es tarde para ampliar los conocimientos.
Dejo como documento el fragmento del programa que lidia con el dichoso modo AR.
L R15,XPBWORD <> DIRECC. SALVADA PAARAM LAM R9,R9,KF1 <> SET AR9 TO ALET 1 SAC 512 SYSSTATE ASCENV=AR L R9,00(R15) <> PARAMETRO 1 - RETURN-CODE MVC @WORKP1,0(R9) L R9,04(R15) <> PARAMETRO 2 - REASON CODE SAC 0 SYSSTATE ASCENV=P