Estandares CICS

Estándares Para El Proces Procesamien amiento to De Datos Central

Servicios de Procesamiento América (SPA)

Gestión de la Calidad

1/33

Versión 2.0.3 Agosto 2013

ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD

Tabla de Contenido 1

Introduccion ........................................................................................................................................ 3

1.1 Objetivos del documento ..................................................................................................................3 1.2 Objetivos de los estánda estándares res ........ ................ ............... ............... ................ ................ ................ ................ ................ ................ ............... ............... ................ ................ ........33 1.3 Acerca de este documento ................................................................................................................3 1.4 A quién está dirigido este documen documento to .................... ............................ ................ ................ ................ ................ ................ ............... ............... ................ ............3 ....3 1.5 Cómo enviar sus comentario comentarioss ........ ............... ............... ................ ................ ................ ................ ............... ............... ................ ................ ................ ................ .............3 .....3 1.6 Registro y Control de Cambios al Documen Documento to .............. ...................... ................ ................ ................ ................ ................ ................ ............... ............... ............ 4 2 Convenciones ...................................................................................................................................... 5 2.1 Contenido no incluido ...................................................................................................................5 3 Estánda Estándares res de nomencla nomenclatura tura de CICS ................ ........................ ................ ................ ................ ................ ............... ............... ................ ................ ................ ........... ... 6 3.1.1 Started Task de CICS CICS ............................................................................................................... ............................................................................................................... 6 3.1.2 Owner y usuario de default de un CICS ................................................................................ CICS ................................................................................ 6 3.1.3 Usuario de la tabla PLTPI de un CICS........................ CICS .................................................. ................................................... .................................. ......... 7 3.1.4 Otros usuarios relacionados con recursos de CICS.............................................................. CICS.............................................................. 7 3.1.5 Temporary Storage en CF (Couplin (C oupling g Facility)......................... Facility) ................................................. .............................................. ...................... 8 3.1.6 CICSPlex/SM CICSPlex/SM ............................................................................................................................. ............................................................................................................................. 9 3.1.7 Transacciones Transacciones ......................................................................................................................... ......................................................................................................................... 10 3.1.8 Componentes dentro de un CICSPLEX ................................................................................ CICSPLEX ................................................................................ 13 3.1.9 Consideraciones Técnicas de CICS ....................................................................................... CICS ....................................................................................... 13 3.1.10 Relación con RACF de los componentes de CICS CICS ............................................................... ............................................................... 14 3.1.11 Configuraciones Aplicativas .................................................................................................. Aplicativas .................................................................................................. 16 3.1.12 Balanceo de Transaccion Transacciones es ................................................................................................... ................................................................................................... 16 3.1.13 Uso de Entornos...................................................................................................................... Entornos...................................................................................................................... 16 3.1.14 Lineamientos Generales de uso ............................................................................................ uso ............................................................................................ 17 3.1.15 Productos o Herramientas empleadas en CICS .................................................................. CICS .................................................................. 18 3.1.16 Colas de Temporary Storage ................................................................................................. Storage ................................................................................................. 18 3.1.17 Definición de recursos en CICS CICS ............................................................................................ ............................................................................................ 21 3.1.18 Políticas generales ................................................................................................................. generales ................................................................................................................. 22 4 Tablas de CICS. ................................................................................................................................. 30 4.1.1 Tabla de Identificador para regiones de CICS....................... CICS ................................................ ............................................. .................... 30 5 Anexos .... ....... ....... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....... ....... ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ........ ....... ....... ........ ........ ........ ........ ........ ........ ........ ...... 31 5.1 Tabla Tablass Generales Gener ales............................ ................................................... .................................................. ................................................... ........................................... ................. 31 5.1.1 Tabla de países cuando se utilizan dos caracteres caracteres ............................................................ ............................................................ 31 5.1.2 Tabla de países cuando se utiliza un caractér caractér .................................................................... .................................................................... 32 5.1.3 Tabla de negocios de dos d os caracteres ................................................................................... caracteres ................................................................................... 32 5.1.4 Tabla de negocios cuando se utiliza un carácter carácter................................................................ ................................................................ 33 5.1.5 Tabla de entornos e ntornos................................................................................................................... ................................................................................................................... 33


2/33



1 Introducción 1.1 Objetivos del documento El objetivo de este documento es oficializar y difundir un grupo de estándares que habrán de observarse en las instalaciones de Informática de América del grupo BBVA.

1.2 Objetivos de los estándares El objetivo del establecimiento de estándares en el grupo BBVA es homogeneizar los esquemas de explotación de la tecnología en los entornos existentes en los diferentes países del continente buscando para estos fines capitalizar, en beneficio de cada uno de los bancos de América y del grupo, las mejores prácticas para lograr altos niveles de productividad y eficiencia de los recursos tecnológicos y humanos, reduciendo el esfuerzo requerido para integrar sistemas aplicativos e infraestructura, en balance con los niveles de servicio y seguridad s eguridad que los negocios demandan.

1.3 Acerca de este documento El objetivo de este documento es difundir los estándares de nomenclatura para almacenamiento, de la plataforma central a los que deberán apegarse los bancos del Centro Corporativo Regional América.

1.4 A quién está dirigido este documento Este documento está dirigido al personal técnico encargado del diseño e implementación de la configuración técnica de los sistemas centrales de almacenamiento. Así mismo se dirige a los líderes de diseño y desarrollo que tiene bajo su responsabilidad el diseño e instalación de aplicaciones en la plataforma central y que hacen uso de las facilidades y herramientas propias de este entorno. Cualquier modificación y/o implementación implementación de componentes componentes en producción que difieran sobre la base de este documento, la dirección responsable de gestionarlo y au torizarlo será Calidad Informática. Solo serán considerados con el Vo. Bo. del Director de Medios del país y con un compromiso de fecha de regularización.

1.5 Cómo enviar sus comentarios Sus comentarios sobre el contenido de este documento son importantes para el CCR, así mejoraremos la calidad de de la información información que se difunde. Favor de dirigi dirigirlos rlos a [email protected], dónde con gusto los atenderemos.


3/33



1.6 Registro y Control de Cambios al Documento Con el fin de llevar el control de movimientos y modificaciones se generara una tabla que integre el registro y control de todos los cambios necesarios para la optimización y el mejoramiento en el uso y funcionalidad de los recursos en que viven nuestros sistemas. Tipo de: Modificación Descripción de Modificación Versión fecha Junio 25 2008 Actualización al 100% de Estándares y facilidades para CICS Junio 2012

Agosto 2013

Si se utiliza el comando ENQ para controlar el acceso a algún recurso y garantizar la integridad de la información, no se debe usar el parámetro NOSUSPEND; y así mismo se deberá emitir el comando DEQ lo más rápido posible, evitando retener el recurso por tiempo innecesario a fin de aumentar la posibilidad de concurrencia de transacciones. De esta forma, la serialización la realizan el CICS o el Sistema Operativo (GRS), y por lo tanto, no se deben generar algoritmos alternos. Se actualiza nomenclatura de Cola de iniciación y orden de detalle en descriptivos de Cola Local y Remota

Aprobación

Aprobada

Aprobada

Registro y Control de Cambios al Documento


4/33



2 Convenciones Este documento utiliza las siguientes convenciones para describir los e stándares de nomenclatura Convención Letras mayúsculas

Descripción Representan literales constantes que deberán utilizarse tal y como aparecen en este documento o un estándar previamente descrito. Ej. HSMppe.** Las letras “HSM” deberán utilizarse al principio del nombre para los archivos propios del

Letras minúsculas

HSM Representan caracteres que deberán ser substituidos por alguna convención como se cita en el documento. Para el ejemplo anterior, las letras “pp” deberán substituirse por el código de país de acuerdo a la tabla Tabla 2: Claves de países con dos que se encuentra en la

sección de Anexos de este documento.

Los caracteres ‘< / >’ se utilizarán para indicar una lista de valores posibles a utilizar en

dicha posición

Ej. Dpe La cuarta posición de esta nomenclatura deberá substituirse ya sea por un número, una a letra o la literal ‘G’

* ó **

Se utiliza para representar cualquier combinación de caracteres posible

Este documento utiliza algunos tipos especiales de texto como: Nota: Notas que contienen información importante que usted deberá de considerar. Referencias: Referencias a otras secciones en este documento o información relacionada.

2.1 Contenido no incluido Todo contenido no incluido en el presente documento deberá ser consultado antes de utilizarlo a través de la Oficina de Certificación de Aplicaciones CCR [email protected], para su evaluación con las áreas técnicas del CCR.


5/33



3 Estándares de nomenclatura de CICS 3.1.1 Started Task de CICS Nomenclatura: CICpetca En donde: CIC : Identificador fijo, para indicar CICS p : Identificador del país (ver Tabla 3: Claves de países con un solo ) e : Identificador del entorno (ver Tabla 6: Tabla de entornos ) t : Identificador del tipo de CICS (ver Tabla 1: Identificador para regiones de CIC ) c : Número consecutivo de la región: 1,2,...,9. A,B....Z empezando por el número uno (1) a : Número de partición del sysplex (1,2,3,...,9) cero (0) si puede levantarse en cualquier partición o si se trata de un entorno monoplex puede emplearse el no. 1. El número consecutivo de la región se utilizará para nombrar a las regiones que se pertenecen a u n mismo grupo aplicativo de transacciones o aplicaciones y que cuentan con un balanceo de transacciones entre ellas. Ejemplo: Todas las regiones que dan servicio a sucursal. El número de la partición se utilizará para especificar la partición de un sysplex en la que una región deber ser activada en condiciones normales. Si la región puede levantarse en cualquier partición (Ej. Una región FOR) se utilizará el número cero. Si se trata de un ambiente monoplex utilizar igualmente el cero en todos los casos. Ejemplos: El AOR1 para Medios de Pago Perú Producción en ambiente de test, configuración monoplex sería: CICPTM10. El TOR3 de la partición 2 de un sysplex en Venezuela en entorno de producción: CICVPT32. Una región FOR en Chile para ambiente de calidad se llamará: CICLCF11.

3.1.2 Owner y usuario de default de un CICS Nomenclatura: CICSep11 En donde: CICS : Identificador fijo, para indicar CICS e : Identificador del entorno (ver Tabla 6: Tabla de entornos ) p : Identificador del país (ver Tabla 3: Claves de países con un solo ) 11 : Asignación fija para identificar este tipo de usuarios


6/33



Esta nomenclatura aplica para CICS que se encuentran dentro de un CICSPLEX (conjunto de CICS). Los CICS nativos emplean como owner el mismo nombre de sus s tarted task. Ejemplo: 1) CICS nativo de AFPS México desarrollo. El nombre del CICS es CICMDP11 y de igual forma es su owner CICMDP11 2) CICS que pertenece a Altamira en Chile producción EL nombre del CICS es CICLCA11 y su owner y usuario default es CICSCL11

3.1.3 Usuario de la tabla PLTPI de un CICS Nomenclatura: UCPLpetc En donde: UC : Identificador fijo, para indicar que es un usuario relacionado con CICS PL : Identificador fijo, para indicar que es un usuario relacionado con la tabla PLT de CICS p : Identificador del país (ver Tabla 3: Claves de países con un solo ) e : Identificador del entorno (ver Tabla 6: Tabla de entornos ) t : Identificador del tipo de CICS (ver Tabla 1: Identificador para regiones de CIC ) c : Número consecutivo de la región: 1,2,...,9. A,B....Z empezando por el número uno (1) Esta nomenclatura aplica para CICS que actualmente no cuentan con este usuario, también es conocido como PLTPIUSER, los CICS que actualmente cuentan con este usuario y no cuenta con este nombre será posible conservarlo. Son usuarios que deben de contar con características de no tener password o nunca poder ser revocados Ejemplo: 1) CICS nativo de AFPS México desarrollo. El nombre del CICS es CICMDP11 y de igual forma es su owner CICMDP11 Y su usuario de la tabla PLTPI es el UCPLMDP1 2) CICS que pertenece al TOR de Altamira Sucursales en Chile calidad El nombre del CICS es CICLCT11 y su owner y usuario default es CICSCL11 Y su usuario de la tabla PLTPI es el UCPLLCT1

3.1.4 Otros usuarios relacionados con recursos de CICS Básicamente siguen el mismo estándar que los usuarios de PLT descritos anteriormente y son usuarios que deben de contar con características de no tener password o nunca poder ser revocados. Son asociados a tablas o recursos de CICS y están asociados a alguna aplicación en particular. Nomenclatura: UCt*a*pe En donde: UC : Identificador fijo, para indicar que es un usuario relacionado con CICS Gestión de la Calidad 7/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD t*

: Identificador de la tabla o recurso de CICS al que se le asignará el usuario, pudiendo ser: CO, conexiones TR, terminales SK, sockets tcp/ip QG, clave de aplicación de CICS BRIDGE a* : Identificador de aplicación dentro de host, es máximo de dos posiciones. p : Identificador del país (ver Tabla 3: Claves de países con un solo ) e : Identificador del entorno (ver Tabla 6: Tabla de entornos ) Esta nomenclatura aplica para aplicaciones que actualmente no cuentan con este usuario las aplicaciones que actualmente cuentan con este usuario y no cuenta con este nombre será posible conservarlo.

3.1.5 Temporary Storage en CF (Coupling Facility) Servidores de Temporary Storage Las tareas de los servidores para Temporary Storage tendrán la siguiente nomenclatura: Nomenclatura: CICpTScn En donde: CIC: Identificador fijo, para indicar CICS p : Identificador del país (ver Tabla 3: Claves de países con un solo ) TS : Identificador fijo, para indicar temporary storage c : Número consecutivo n : Número de partición del sysplex Ejemplo: El servidor 2 para la partición 1 de un sysplex en Venezuela sería: CICVTS21 El servidor 3 para la partición 2 en México sería: CICMTS32 Identificador El SYSIDNT para cada pool tendrá la siguiente nomenclatura: Nomenclatura: TSpc En donde: TS : Identificador fijo, para indicar temporary storage p : Partición c : Número consecutivo Ejemplo: TS11 es la identificación para la temporary storage 1 de la partición 1. Gestión de la Calidad

8/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD POOL Nomenclatura: POOLnn En donde: POOL nn

: Identificador fijo, para indicar POOL : Número consecutivo empezando por 01

3.1.6 CICSPlex/SM CAS (Coordinator Address Space) Started Task, Owner y Applid Nomenclatura: CICpCApa En donde: CIC p CA p a

: Identificador fijo, para indicar CICS : Identificador del país (ver Tabla 3: Claves de países con un solo ) : Identificador fijo, para indicar CAS (Coordinator Address Space) : Identificador del país (ver Tabla 3: Claves de países con un solo ) Nota: Se maneja de nuevo el país para que el SYSIDNT lo contenga : Número de partición correspondiente

Nota: El identificador del país aparece dos veces dentro de la nomenclatura definida para CAS. CMAS (CICSPlex Manager Address Space) Started Task, Owner y Applid Nomenclatura: CICpCMpa En donde: CIC p CM p a

: Identificador fijo, para indicar CICS : Identificador del país (ver Tabla 3: Claves de países con un solo ) : Identificador fijo, para indicar CMAS (CICSPlex Manager Address Space) : Identificador del país (ver Tabla 3: Claves de países con un solo ) Nota: Se maneja de nuevo el país para que el SYSIDNT lo contenga : Número de partición correspondiente (1 para VEN1, 2 para MEX2, etc.)

Nota: El identificador del país aparece dos veces dentro de la nomenclatura definida para CMAS. Ejemplos: El CMAS de la partición 3 de México es: CICMCMM3. El CMAS de la partición 2 de Venezuela es: CICVCMV2. Gestión de la Calidad 9/33



Context y Scope del Cicsplex Para entonos previos se definirá uno para los entornos previos de desarrollo, test y formación con terminación ‘D’ y otro para calidad con terminación ‘C’ Para producción se definirán solo uno con terminación ‘P’.

Nomenclatura: CICpPLXe En donde: CIC : Identificador fijo, para indicar CICS p : Identificador del país (ver Tabla 3: Claves de países con un solo ) PLX : Identificador fijo, para indicar el Cicsplex (conjunto de CICS) donde se realizarán las definiciones e : Identificador del entorno (ver Tabla 6: Tabla de entornos, solo aplica las letras: ‘D’ , ’C’ y ‘P’ ‘ )

3.1.7 Transacciones Las transacciones deberán llevar en los 2 primeros caracteres la clave de la aplicación asignada, por Gestión de Cambios. Nomenclatura: aacc En donde: aa : Los 2 primeros caracteres de la aplicación NINGUNA TRANSACCION DE APLICACIÓN PUEDE INICIAR CON LA LETRA “C” , pues esta letra está reservada para el uso de transacciones del propio CICS. Existen otros nombres de transacciones las cuales pertenecen a programas producto cuyos nombres también están restringidos, estas son: SOCKETS: EZAC EZAO EZAP EZKL (todas las EZ*) CICS: MENU CICSPLEX: BMLT LCPP Gestión de la Calidad

10/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD LECI LECR LECS LEEI LEER LEMI LEMS LENS LMIR LNCI LNCS LNMI LNMS LPDG LPLK LPLT LPRT LPSC LPSM LRLT LSRT LWTM MCCM MCTK MMEI MMIS MMST PEAD PELT PMLT PNLT PPLT PRLT PRPR PSLT TICT TIRT TIST TSMH TSPD TSSC TSSJ WMCC WMGR WMLA WMQB WMQM WMQS WMSC WMWC WMWT WSCL Gestión de la Calidad

11/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD WSLW XDBM XDNC XDND XDNE XDNR XDNS XDSR XLEC XLEV XLNX XLST XQST MEMO: MAPI OMEGAMON OMEG Uso Interno CICS: PONG CONTROL-M: CTM* (incluidas en las C*) MQseries: CK* (incluidas en las C*) CONTRL-D: DOLV TMAN CSP: XSPE XSPP XSPS XSPZ

(todas las XSP*)

BridgeMQ (para uso de Arquitectura): **QG

MAINVIEW: FCD2 FIC2 FCM1 JNL2 SMN2 MVRT Gestión de la Calidad

12/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD VIASOFT: VIAR VIAC

3.1.8 Componentes dentro de un CICSPLEX La palabra CICSPLEX es empleada para denominar a un conjunto de CICS entre los cuales pueden existir TORES, AORES y FORES, éste término puede confundirse con la palabra CICSPLex ésta última hace referencia a un programa producto que realiza el balanceo de cargas entre los CICS AORES. Para apreciar una diferencia entre estas dos palabras existe una convención para escribir la palabra relacionada con el programa producto y es emplear la combinación de mayúsculas y minúsculas de la siguiente manera: CICSPLex. De igual forma existe una convención fonética para distinguir éstos dos homónimos. En el ambiente de BBVA, la filosofía para las aplicaciones línea es estar bajo Altamira y con DB2 ya que así se obtienen los beneficios de alta disponibilidad, operación continua, recuperación ante contingencias, flexibilidad y facilidad de crecimiento; así mismo se facilita la exportación / importación de aplicaciones entre los bancos del grupo.

3.1.9 Consideraciones Técnicas de CICS La Arquitectura propuesta por IBM para este producto CICS, clasifica a los CICS de acuerdo a una especialidad o función específica para dar servicio. La Arquitectura CICS cuenta con 3 estratos principales, sin embargo de acuerdo a las necesidades del Cliente y el Diseño de las Aplicaciones es posible combinarlos entre sí. La clasificación ideal es que los CICS cuenten solamente con una de estas funciones: Control de acceso y terminales: TOR - Terminal Owning Región. Región de CICS administradora de terminales e impresoras y ruteadora de transacciones a uno o más AOR's. Control de programas: AOR - Application Owning Region. Región de CICS en donde la aplicación es ejecutada. Control de datos: DOR - Data Owning Region. Región de CICS que controla los recursos para el acceso de los datos . (FOR,QOR) 





Como repositorio de datos existen también dos componentes más diferentes a CICS, éstos son servidores de CICS al proporcionarle el dato y no permitir que éste realice la búsqueda sino que realice únicamente su petición y recepción una vez que el componente lo obtuvo para continuar con la ejecución de la transacción estos componentes son el DB2 y el Copling Facility.

DB2.- En este caso el control de los datos ya no lo tiene CICS sino el subsistema manejador de la base de datos, por lo que la responsabilidad de la integridad de los datos la toma este subsistema. Coupling Facility.- Se encuentra disponible únicamente en sistemas con Parallel Sysplex y es memoria de alta referencia y por lo tanto muy costosa, en este caso la información reside en este componente y este es el que se encarga de administrar sus accesos. Adicional a estos 3 tipos de CICS, existe uno que es recomendable cuando una aplicación cuenta con requerimientos especiales que no son estándar para las demás aplicaciones y es conocido como CICS nativo, este realiza las 3 funciones es un TOR, AOR y FOR a la vez. Gestión de la Calidad 13/33 Versión 2.0.3 Agosto 2012


En conclusión el modelo ideal de la Infraestructura CICS es bajo la filosofía MRO, es decir, bajo la configuración por Capas: para el control de terminales o enlaces TCP/IP (TOR ), regiones para la ejecución del código de la aplicación ( AOR ) y regiones para las TSQs compartidas y en su caso archivos (QOR/ FOR ). Para contar con esta configuración es necesario realizar lo siguiente:  

 







Toda comunicación entre CICS debe ser a través de los TORES. En el TOR se definirán las terminales o conexiones de acceso. Para el caso de las terminales se deberá utilizar el concepto de AUTOINSTALL, tanto para 3270 como para Terminal Financiero. En el caso de conexiones hacia entidades externas éstas pueden ser LU6.2 o bien conexiones vía TCP/IP. Así mismo, en el TOR se definirá el acceso del MQ en caso de ser utilizado. En los AORs se deben definir las transacciones como locales, asociadas generalmente al programa de Altamira QC1CENT. Para el caso de programas y mapas, éstos no se definen ya que se deberán autoinstalar, sin embargo, podrán existir definiciones para aquellos programas que serán utilizados para DPL. Las colas que requieran ser leídas desde más de una región deberán ser definidas como remotas en el QOR, salvo aquellas colas de TS que sólo se utilizan de lectura como la +SWA que puede definirse de manera local en todos los AOR asegurándose que ésta sea borrada después del cambio de sesión en todas las regiones. De existir archivos estos deberán definirse como remotos al FOR que también puede ser el QOR.

En caso de contar con CICSPlex SM, éste se deberá utilizar para hacer la distribución y balanceo de transacciones en el TOR hacia los AORs correspondientes, de otro modo las transacciones deberán ser definidas en el TOR como remotas hacia un AOR específico. Hay algunas transacciones que podrán definirse como locales en el TOR , este puede ser el caso de las asociadas al MQ Series, o de las que servirán como copia de la CSMI para identificar un DPL entre aplicaciones en diferentes CICS.

3.1.10

Relación con RACF de los componentes de CICS

La seguridad de CICS es administrada vía RACF, dentro de él básicamente se encuentran definidos 3 usuarios que son el OWNER del CICS, el usuario de default de CICS y el usuario de la tabla PLTPI (Program List Table Post Initialization), también es dado de alta el APPLID del CICS para controlar su acceso y finalmente la lista de transacciones a ser ejecutadas. OWNER El OWNER es el usuario de la región de CICS, y sirve para poder iniciar el CICS como tarea (STARTED TASK) o como JOB. Con este usuario se verifica la seguridad de recursos externos protegidos, por ejemplo bibliotecas, archivos, LOGGERS, servidores, etc. y recursos internos, como son transacciones internas (categoría 1), que son transacciones para uso interno del propio CICS y que no pueden ser llamadas por terminal, y usuarios auxiliares, como son el PLTPIUSER, DEFAULT USERID y el Gestión de la Calidad

14/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD usuario para disparo de transacciones (TRIGGERS). El OWNER, por lo tanto, debe tener acceso tanto a los recursos externos como internos. En un ambiente CICSPLEX, se utiliza el mismo OWNER para facilitar la administración de los perfiles ya que cada uno de los CICS del CICSPLEX son clones, es decir, tienen definidos los mismos recursos . .

USUARIO DE DEFAULT Dentro de CICS toda ejecución de alguna transacción debe estar asociada a un usuario, aún y cuando este se encuentre en la etapa de arranque o cuando un usuario final ejecute transacciones sin firmarse aún con su usuario propio. El CICS se firma con el DEFAULT USERID durante la inicialización del propio CICS y utiliza este usuario para aquellas transacciones que no requieren firma. Cuando un usuario entra al CICS y trata de ejecutar una transacción sin haberse firmado el usuario que tomará es el usuario de DEFAULT. Por lo general el usuario Owner del CICS y el usuario de default es el mismo. USUARIO DE LA TABLA PLTPI Es conocido como PLTPIUSER y es empleado para ejecutar programas y/o transacciones durante el arranque del CICS que no son asociadas directamente al arranque del propio de la tarea del CICS, por ejemplo ejecuta las transacciones que permiten la conexión con CICSPlex, con Omegamon, o con MQSeries, también puede ejecutar transacciones aplicativas que de igual forma se requiera al inicio del CICS. APPLID Sirve para autorizar a los usuarios la entrada a la región CICS, es decir, al APPLID del CICS. El acceso debe darse a los TORES, o bien, al VTAM GENERIC RESOURCES, de esta manera se obliga a los usuarios a entrar por el TOR. Podrán existir excepciones de entrada directa a los AORES, FORES y QORES, pero este acceso debe proporcionarse únicamente al personal que administre u opere al CICS. TRANSACCIONES La Arquitectura de IBM realiza recomendaciones para el agrupamiento de transacciones en RACF para permitir su acceso a usuarios del Sistema tales como el Owner del CICS y/o usuarios finales. Estos grupos son administrados por RACF y el área de Seguridad Lógica es el encargado de asignar los accesos a todas las transacciones ya sean aplicativas o de infraestructura. Las transacciones deben ser definidas en RACF empleando como prefijo el owner del CICS donde son requeridas. Las únicas consideraciones que Middleware CICS/MQ tiene relacionadas a los accesos para DyD en los entornos de desarrollo son las siguientes:  NO debe permitirse el uso de la transacción CEDA, CEDB o CEDC a ningún usuario de Diseño y Desarrollo ya que estas transacciones son exclusivas para la administración de los recursos definidos en CICS.

El área de Middleware CICS/MQ de CCR no da accesos ni VoBo del uso de transacciones aplicativas. Gestión de la Calidad 15/33 Versión 2.0.3 Agosto 2012 


3.1.11

Configuraciones Aplicativas

Las aplicaciones deben ser agrupadas en CICS de acuerdo al tipo de funcionalidad a ofrecer y a la criticidad de sus servicios, con esto básicamente los CICS son agrupados 

para aplicaciones de servicio de oficinas con alta criticidad casi siempre denominados como CICS de Altamira,



para aplicaciones de servicios de cajeros automáticos (ATMs) , denominados CICS de Medios de Pago, y



para aplicaciones de servicios de Internet o Banca a Distancia, denominados CICS de Canales





Adicionalmente existen otros CICS que de acuerdo a los medios de conexión de acceso a HOST son clasificados como CICS de Terminales Financieros, CICS con MQ Series y/o CICS / Sockets, CICS con ATMs, CICS para interoperatividad con otras entidades, etc. Para las aplicaciones que requieren comunicación vía MQ Series, también los Queue Managers son clasificados de acuerdo a la criticidad de las aplicaciones y c on base a los CICS que les ofrecerán los servicios aplicativos.

Todas estás agrupaciones de CICS y de Queue Managers se realizan de acuerdo a las necesidades de cada cliente, tratando de contar con un balanceo o distribución de cargas adecuada al volumen de transacciones a operar. El área de Middleware CICS/MQ de CCR es quien decide en donde ubicar una aplicación.

3.1.12 



Balanceo de Transacciones

Las aplicaciones deberán ser desarrolladas sin afinidades, a efecto de habilitar su ejecución en uno o más AORs con balanceo dinámico, evitando la dependencia de ejecutarlas en un AOR específico enviándolas desde cualquier TOR . Las aplicaciones que requieran hacer uso del nombre del CICS (applid, sysid) deberán hacerlo mediante el uso de variables o a través del comando ASSIGN, siempre y cuando el nombre de éste coincida con el nombre de la conexión del CICS en cuestión . Si es completamente necesario el uso del nombre de estos parámetros de CICS es posible emplear las colas de TS empleadas por Arquitectura Altamira en sistema.

3.1.13

Uso de Entornos

Cada uno de los entornos creados dentro de los sistemas de los Clientes CCR cuenta con un objetivo de uso diferente y de acuerdo a ellos son configurados parámetros propios del producto CICS que permiten contar con disponibilidad y competir por los recursos del equipo de acuerdo a la necesidad del entorno. A continuación describiremos brevemente el uso de ellos: 

Desarrollo Es empleado para la ejecución de pruebas unitarias. Validación de mapas, que no generen abends, etc.


16/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD 







Test Es empleado para la ejecución de pruebas integrales informáticas. DyD es quien realiza la validación de estas pruebas con una mayor casuística de pruebas. Es posible realizar pruebas de volumen. Calidad Es empleado para la ejecución de pruebas funcionales. Organización es quien realiza la validación de estas pruebas y con base en sus conocimientos del negocio realiza pruebas de otras aplicaciones relacionadas con las modificaciones. Formación Es empleado para realizar la capacitación de los usuarios finales, o bien para la ejecución de pruebas de certificación por su estabilidad. Producción Es empleado para ofrecer los servicios en línea a los usuarios finales y en horarios de servicio convenidos donde debemos asegurar su disponibilidad. NOTA: México es excepción maneja Calidad y Test de manera inversa.

3.1.14 

  



 













Lineamientos Generales de uso

En general deben utilizarse tablas DB2 cuando se deba acceder a la información de forma aleatoria. Excepcionalmente y con la autorización del grupo de Base de Datos puede ser conveniente utilizar archivos VSAM que no sea necesario recuperarlos en caso de contingencia o que puedan ser reconstruidos en el sitio alterno. Las aplicaciones deberán adecuarse y utilizar el Software de Programas Producto Corporativo. Las aplicaciones deberán desarrollarse en lenguaje Cobol/390 y bajo CICS Comandos. Se recomienda ampliamente evitar la utilización de comandos que causen interrupciones al Sistema Operativo. Ejemplo: Accept, Display, etc. No se deberán hacer llamados de un programa CICS a una rutina Batch. Las aplicaciones que requieran interactuar con otras aplicaciones deberán utilizar como primera opción link de programas, en caso de no ser posible se deberá emplear el mecanismo de intercomunicación aplicativa vigente. En caso de que las aplicaciones requieran intercomunicarse entre sí vía LINK de programas y residan en AORs independientes, deberán hacer uso de un TOR como paso asignando una TRANSID para identificar las aplicaciones involucradas, está última deberá ser una copia de la CSMI. Se deberá utilizar MQSeries para realizar la interfase con aplicaciones no HOST (servidores internos). Si se utiliza el comando ENQ para controlar el acceso a algún recurso y garantizar la integridad de la información, no se debe usar el parámetro NOSUSPEND; y así mismo se deberá emitir el comando DEQ lo más rápido posible, evitando retener el recurso por tiempo innecesario a fin de aumentar la posibilidad de concurrencia de transacciones. De esta forma, la serialización la realizan el CICS o el Sistema Operativo (GRS), y por lo tanto, no se deben generar algoritmos alternos. Siempre verificar el código de retorno de las sentencias CICS para evitar ABENDs en las transacciones. Las aplicaciones deberán utilizar las rutinas comunes de Altamira para el manejo de Mensajes, Pantallas, validación de Seguridad, etc. No está permitido hacer uso de SEND TEXT.


17/33



3.1.15

Productos o Herramientas empleadas en CICS

De acuerdo a los productos estándares dentro de CCR, los CICS pueden tener dentro de su configuración los siguientes productos, sin embargo será necesario evaluar de acuerdo al entorno y al uso a darle si es factible o no realizar su instalación. PRODUCTO

DESCRIPCIÓN

AF/OPERATOR OPS

AUTOMATIZA FUNCIONES DE MONITOREO

CEE

LANGUAGE ENVIRONEMENT

CICS SOCKETS

COMUNICACIÓN CON TCP/IP CON ENTIDADES EXTERNAS

CICSPLEX

BALANCEADOR DE TRANSACCIONES

CONTROL M

INTERFACE PARA EL SCHEDULER PROCESOS BATCH

DB2

BASE DE DATOS RELACIONAL

MQ SERIES OMEGAMON MAINVIEW QA HIPERSTATION STROBE FREEZEFRAME

COMUNICACIÓN CON TCP/IP O SNA CON ENTIDADES EXTERNAS MONITOR DE CICS CAPTURA Y REPRODUCE TRANSACCIONES CON VOLUMEN MIDE EL CONSUMO DE RECURSOS DURANTE LA EJECUCION DE TRANS

VALIDATE

SIMULA FECHAS FUTURAS O ANTERIORES PARA PRUEBAS

SMART TEST

REALIZA EL DEBUGGER DE LAS TRANSACCIONES APLICATIVAS

3.1.16

Colas de Temporary Storage

El temporary storage es un recurso de CICS llamado cola (queue) que puede ubicarse en su memoria o en disco dentro de un archivo propio de la infraestructura de CICS, el default es memoria propia del CICS. (Recurso por naturaleza excesivamente costoso dentro de un equipo de cómputo por su alta disponibilidad de acceso) Es utilizado por los programas de aplicaciones para guardar datos aplicativos temporales y/o pueden ser utilizados por unidades de trabajo diferentes en algunos casos. Una vez que se generaron los datos en los temporary storage, serán empleados por las mismas aplicaciones y éstas deben asegurarse de borrarlos ya que su objetivo es alojar datos temporales. Una unidad de trabajo se refiera a la ejecución de una transacción con el mismo nombre o diferente nombre y puede ser en el mismo CICS o en diferente región de CICS, por este ultimo motivo los datos deben de ubicarse de manera compartida. Gestión de la Calidad

18/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD Para que un cola de temporary storage sea compartida es necesario ubicarla en un área común para los diferentes CICS que hagan referencia de ella, estas áreas comunes son los CICS QOR (Queue Owning Region) y los servidores de Temporary Storage en Coupling Facilty El uso ideal de las colas de temporary storage debe ser que la misma unidad de trabajo que la genera, use la información y al concluir su uso la borre. Con esto es posible generar la cola de manera local en la misma región de CICS. Si el dato debe ser compartido por diferentes unidades de trabajo que se ejecutan en diferentes regiones de CICS, es necesario asegurar en el flujo aplicativo diario su depuración una vez que se haga uso de ella o de manera posterior programando una depuración periódica en línea. El tamaño de una cola de TS debe ser el mínimo posible de acuerdo a la necesidad de la aplicación y volumen de transacciones a emplearla.

3.1.16.1 















 



Uso de Colas de Temporary Storage

En algunos casos las colas TS se utilizan para pasar datos entre programas utilizando comandos XCTL o LINK. Para estos casos específicos se recomienda utilizar mejor la COMMAREA. Cuando la información debe ser compartida entre programas que se eje cutan en diferentes CICS, es necesario utilizar colas TS compartidas o shared. Sin embargo el último en emplearla debe asegurarse de borrarla. Si la cola TS solo va a ser leída exclusivamente, se puede existir una réplica en cada CICS donde se va a consultar. Un ejemplo es la cola TS +SWA. Si la cola TS se va a utilizar para pasar información entre transacciones, entonces debe compartirse para que todos los CICS puedan accederla. Esto se logra definiendo un CICS de Colas (QOR) o compartirlas en las estructuras del CF. El uso ideal de las colas de temporary storage debe ser que la misma unidad de trabajo que la genera, use la información y al concluir su uso la borre. Con esto es posible generar la cola de manera local en la misma región de CICS. Las aplicaciones NO deberán utilizar áreas de memoria de manera indiscriminada, por ejemplo el empleo de colas TS para hacer debug de programas o para almacenar logs de transacciones. Se podrá aprovechar el uso de colas TS para cargar en memoria tablas DB2 pequeñas. El número máximo de registros aconsejable es dependiente de la disponibilidad de memoria y el número de accesos a estas tablas. Se deberá consultar con el grupo de soporte técnico para conocer estas limitantes. En el caso de utilizar colas de TS para colocar tablas DB2 pequeñas en memoria, se recomienda utilizar la llave de acceso dentro del nombre de la cola de TS para tener un acceso directo al dato que se requiere. Cualquier programa que cree una cola de TS deberá borrarla al término del proceso. La comunicación entre BATCH y el CICS se realizará mediante la interfase de CICS conocida como EXCI. Algunos ejemplos de interacción pueden ser para abrir o cerrar un archivo VSAM alojado por el CICS y que necesita ser manipulado por el proceso batch o la ejecución de alguna transacción en CICS. No deberá utilizarse el operador automático para la ejecución de transacciones, borrado de colas de temporary storage, cierre y apertura de archivos, etc.

3.1.16.2

Características de las colas de Temporary Storage

Permanencia Gestión de la Calidad

19/33









El tiempo de permanencia de las colas TS debe ser mínima. Si la cola TS solo es utilizada durante la ejecución de una transacción, ésta debe borrarse antes de terminar la transacción. Si la cola TS va a ser utilizada por varias transacciones, la última en utilizarla debe borrarla. Además la aplicación deberá tener mecanismos de control para borrar la cola en el caso que el ciclo quede interrumpido. La aplicación deberá contar con un mecanismo propio que de manera periódica durante el día borre las colas de TS que ya no tengan utilidad

Contenido 





Las aplicaciones NO deberán utilizar áreas de memoria de manera indiscr iminada, ya que el recurso donde se alojan es memoria y es muy costosa. Las colas TS NO deben ser utilizadas para guardar información de la cual haya dependencia aplicativa, utilizar medios de almacenamiento permanentes para este tipo de información. Las colas TS no deben contener TRACES ni utilizarse para depuración o despliegue de flujo de programas.

Tamaño 



La información manejada en colas TS no debe exceder de 20 Kb por cola TS de manera ideal para colas que se generarán con gran frecuencia y con mucho volumen de transacciones. Es posible que existan máximo 100 colas simultáneamente por aplicación (por ejemplo, colas que se generan por cada transacción o terminal). El tamaño máximo es de 150 Kb por cola TS en cualquier otro caso. Para un tamaño mayor a 150 Kb se requiere justificación y la aprobación por parte de Infraestructura CICS.

Nomenclatura 





El nombre de la cola TS no debe contener espacios ni caracteres no visibles en cualquier posición. Se recomienda no utilizar sufijos como por ejemplo, xxxxLBMR, xxxxEXTS. El nombre ideal de ellas debe iniciar con las letras de la clave de la aplicación en host, para facilitar su identificación durante la operación. El nombre NO debe iniciar con caracteres especiales (/, @, #, etc.).


20/33



3.1.17

Definición de recursos en CICS

Con base a la Arquitectura ideal de CICS la definición de recursos en CICS debe realizarse considerando los siguientes puntos que se listan a continuación para los recursos más utilizados comúnmente. 

Del recurso:

transacciones se valida que su nombre conste de dos letras como prefijo que

correspondan a la clave de la aplicación administrada por ChangeMan y dentro de las tablas de Altamira. Se sugiere que deban ser ejecutadas en los CICS AORES preferentemente de tal manera que exista redundancia en ellas, si emplean Altamira deben ser asociadas al programa QC1CENT y al plan de DB2 con nombre BV&**PO (donde & corresponde al entorno y ** a la clave de la aplicación, siempre y cuando el nombre del plan se encuentre en estándares dentro del entorno a ser definido). Las transacciones que no emplean Altamira van asociadas a cualquier otro programa. Con el plan de DB2 asignado de manera genérica con el prefijo de las transacciones. La definición de transacciones que inicien con la letra ”C” está restringido ya que se encuentran reservadas para el uso exclusivo de transacciones propias del producto CICS. Las transacciones deberán llevar en los 2 primeros caracteres la clave de la aplicación asignada, por Gestión de Cambios. Nomenclatura: aacc En donde: aa : Los 2 primeros caracteres de la aplicación cc : Numérico consecutivo o caracteres mnemotécnicos de la transacción El nombre de la transacción no debe iniciar con la letra “C” ya que esta letra está reservada para l as transacciones propias de CICS.



Del recurso:

ts models (temporary storage models) se valida y sugiere que se definan

exclusivamente cuando sea necesario compartir datos en colas (queues) entre unidades de trabajo diferentes (transacciones con el mismo nombre ejecutándose en momentos diferentes) y que se tenga cuidado en su creación, uso y depuración una vez concluido su uso para no saturar los recursos de CICS asignados a estas colas. Deben emplear nombres genéricos que sirvan de prefijos para transacciones de la misma aplicación. Su definición para sistemas sin Parallel Sysplex debe ser remota a un CICS FOR/QOR y en sistemas con Parallel Sysyplex se deben asignar a Servidores de Coupling, DyD debe identificar los CICS que requieren acceder la información para realizar su definición en los CICS adecuados ya sea TORES y/o AORES. Los CICS deben contar con el autoinstall de programas locales, si es así no es necesario realizar esta definición de programas locales a menos que requieran una especificación diferente al default, dentro de este concepto de autoinstall también se encuentran las rutinas y los mapas.



Del recurso: programas



Del recurso: programas

remotos son una excepción del recurso anterior y es necesario validar la

necesidad de ésta definición ya que la arquitectura Altamira está diseñada para ir llamando programas de diferentes aplicaciones para dar un servicio únicamente haciendo un LINK de los programas de otras aplicaciones. Sin embargo es posible que se justifique su definición, si es así se sugiere que por programación se identifique con parámetro o variables el nombre de conexión del CICS donde se quiere ejecutar el programa y lo mande llamar con el comando link y sysid de tal forma que no se genere una afinidad al nombre de conexión o a la definición en CICS. Además de emplear el Gestión de la Calidad 21/33 Versión 2.0.3 Agosto 2012

ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD parámetro transid para ejecutar una transacción mirror y así identificar su paso por el otro CICS, esta transacción es necesario definirla local en el CICS donde se ejecutará el archivo como copia de la transacción de CICS CSMI. 

Del recurso:

archivos se valida que el DDNname del CICS sea el mismo que el último calificador del

cluster (de preferencia), si es un archivo KSDS deben de ser incluida la longitud de la llave. Se sugiere que la ubicación de los archivos sea remota a los CICS QOR o FOR de tal forma que todos los CICS AORES y TORES los puedan acceder. Es necesario solicitar a Seguridad Lógica que el owner del CICS tenga acceso por lo menos de update para el cluster del archivo. La utilización de archivos VSAM en CICS está restringida, deberá utilizarse DB2. Los archivos VSAM solo podrán definirse en CICS previa validación y autorización del área CICS/MQ.MQSeries MQSeries es utilizado como el estándar dentro del grupo BBVA como Middleware de comunicación asíncrono (o síncrono, ya que es posible simularlo) entre aplicaciones internas y externas multiplataforma, por lo que es indispensable establecer los estándares de nomenclatura y uso de facilidades del producto para: 

Agilizar los desarrollos



Facilitar la administración y soporte



Minimizar los problemas en producción

3.1.18

Políticas generales



Todos los desarrollos corporativos que sean implementados en Clientes de CCR con MQSeries en cualquier ambiente, deben apegarse a los estándares de nomenclatura publicados en este documento.



Los servicios aplicativos propios de comunicación con éste producto MQSeries deben ser proporcionados por los desarrollos del área de Arquitectura Aplicativa de CDR, es responsabilidad de ellos en base a las necesidades de la aplicación proponer las características de los objetos a definir en MQSeries.



Los líderes de los servicios aplicativos junto con Arquitectura Aplicativa CDR deben de asegurarse que los mensajes empleados cuenten con parámetros adecuados de expiración y persistencia de acuerdo a la necesidad y funcionalidad de la aplicación realizando una depuración de ellos de manera periódica cuando éstos ya no sean útiles. Estos parámetros deberán ser asignados dentro de los programas de la aplicación, por excepción solo se podrá habilitar la persistencia vía infraestructura.



Es responsabilidad del área Infraestructura Middleware CCR México revisar, validar y asignar los nombres de los objetos a definir en MQSeries para aplicaciones CCR, así como ofrecer el soporte sobre la infraestructura del producto únicamente.



Como convención todos los nombres de los objetos a definirse en MQSeries deben ser en MAYÚSCULAS.



Cada objeto debe llevar una descripción detallada en el parámetro DESCR, para facilitar su documentación, administración y soporte.



Por ningún motivo deberá existir conexión entre equipos productivos contra algún entorno otro equipo de entornos desarrollo y viceversa. Esta política es necesaria para evitar fraudes y/o riesgos de


22/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD impacto al servicio productivo. Si es permisible la conexión de equipos que compartan varios entornos previos entre sí. 

Los desarrollos que darán servicio a los diferentes Clientes CCR podrán emplear la nomenclatura de objetos de acuerdo a sus necesidades, el área de Middleware CICS/MQ en CCR será el que decida. Pero básicamente podrán ajustarse de la siguiente manera: 1)

2)



Locales Aplicaciones que darán servicio exclusivamente a un cliente de CCR. Uno de los equipos puede ser administrado por CCR y el otro puede ser administrado en el país que ofrecerá servicio de esta aplicación de manera local. Corporativas Aplicaciones que darán servicio a más de un cliente de CCR. Ambos equipos a ser interconectados pueden ser administrados por CCR.

Los objetos que actualmente se encuentran definidos en cualquier entorno de desarrollo o productivo pueden tener nomenclatura que corresponda a otros estándares como los locales de cada cliente CCR y/o los emitidos en España. Sin embargo los desarrollos nuevos deberán apegarse a éste estándar CCR. Mientras que los objetos existentes serán respetados y de manera paulatina y en coordinación con el líder de la aplicación serán migrados a este estándar.

Nomenclatura para Aplicaciones Locales y Corporativas La diferencia de la nomenclatura para los dos tipos de aplicaciones: locales y corporativas, será para las aplicaciones corporativas deberán contar un calificador adicional al final de los objetos de dos posiciones que identifique al país que dará servicio. Este calificador solo será empleado en los objetos colas relacionados a la aplicación o servicio. Los servicios distribuidos deberán tener una nombre de 3 a máximo 5 posiciones que será empleado en la generación e identificación de los objetos de MQ Series para cada uno de los servicios. Este nombre debe ser único para las aplicaciones locales y para las aplicaciones corporativas debe ser el mismo. Dentro de la nomenclatura será referenciado con los caracteres ‘aaaaa’ dependiendo de la longitud permitida dentro del

objeto listado.

Cada aplicación o servicio distribuido de acuerdo a sus necesidades, puede contar con un número finito de colas ya sean locales o remotas; y con un número también finito de canales. Estos objetos serán identificadas como el set básico necesario para la funcionalidad de la aplicación, y cada uno de éstos sets deberá ser definido en cada entorno reconocidos por el grupo BBVA (D, T, C, F) donde se desee probar y obviamente en producción. El entorno que establece la letra a emplear es el entorno de HOST, de manera prioritaria. Es posible que por algún proyecto especial tal como una migración de la aplicación de uno de los equipos del servicio, reubicación de equipos, habilitación de cifrado de información, pruebas de volumen, entre otros. Será necesario replicar las definiciones de los mismos objetos del set básico de una aplicación en alguno de los entornos reconocidos por el grupo BBVA. Estas definiciones deben ser temporales y deben ser generados en entornos de desarrollo preferentemente. Al término del proyecto deberán solo existir los objetos con la nomenclatura del set básico que le corresponda al entorno. La manera de identificarlos será añadir al final de los objetos requeridos un calificador nuevo de máximo 8 caracteres (si lo permite la longitud el objeto), que haga referencia al proyecto. Gestión de la Calidad

23/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD Qmanager’s

El nombre del Qmanager debe hacer referencia al ambiente donde vive y al tipo de servicio que ofrece. Su nombre debe ser único para cualquier servicio que tenga conexión con los equipos administrados por CCR. Qmanager’s en entorno Main frame, 4 caracteres:

Nomenclatura: Mpec Longitud : 4 posiciones donde: M p e c

: Identificador fijo, para indicar Queue Manager : Identificador del país (ver Tabla 3: Claves de países con un solo ) : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Número consecutivo del subsistema: 1,2,...,9. A,B....Z empezando por el número uno (1)

Qmanager’s en entornos Unix, NT, Digital, Tandem, AS/400

Nomenclatura: QMpeaaac Longitud : 8 posiciones donde: QM p e aaa c

: Identificador fijo, para indicar Queue Manager : Identificador del país (ver Tabla 3: Claves de países con un solo ) : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Identificador de 3 posiciones de la aplicación o servicio distribuido : Número consecutivo del subsistema: 1,2,...,9. A,B....Z empezando por el número uno (1)

Canales Preferentemente se emplean canales de este tipo Sender – Receiver, sin embargo de requerirse canales Server – Requester puede emplearse esta misma nomenclatura para ellos. Canales Comunicación Sender – Receiver Los canales de envío y recepción se deben llamar igual en los equipos a ser interconectados, y su nombre debe estar compuesto por el de los QMGR´S involucrados. Nomenclatura: CHt.qmorigen.qmdestino Gestión de la Calidad

24/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD Longitud : Máximo 20 posiciones donde: CH : Identificador fijo, para indicar Channel t : Identificador del tipo de canal (T para TCP/IP, S para SNA) qmorigen : Identificador del queue manager que envía la información qmdestino: Identificador del queue manager que recibe la información Canales Comunicación Server Conection – Client Conection Nomenclatura: CHC.aaaaa.SRVCONN Longitud : Máximo 20 posiciones donde: CHC aaaaa SRVCONN

: Identificador fijo, para indicar Channel Server Conection : Identificador de 4 o 5 posiciones asignado al servicio distribuido y/o aplicación : Identificador fijo, para indicar Channel Server Conection

Colas relacionadas al funcionamiento de los subsistemas Qmanager’s

Cola de mensajes rechazados Esta cola se emplea para que el subsistema ubique los mensajes rechazados en su envío y se define una por Qmanager Nomenclatura: qmlocal.DEAD.QUEUE Longitud : Máximo 48 posiciones donde: qmlocal DEAD QUEUE

: Identificador de 4 o 8 posiciones referente al queue manager al que se asignará esta cola : Identificador fijo, para indicar tipo de cola : Identificador fijo, para indicar que el objeto es una cola

Colas de Transmisión Una cola de transmisión esta asociada únicamente a un canal que puede ser de tipo sender o server, y un canal debe ser asociado también solo a una cola de transmisión.


25/33



Nomenclatura: qmdestino.XMIT.QUEUE Longitud : Máximo 48 posiciones donde: qmdestino XMIT QUEUE

: Identificador de 4 a máximo 8 posiciones referente al queue manager destino donde se enviarán los mensajes : Identificador fijo, para indicar tipo de cola : Identificador fijo, para indicar que el objeto es una cola

Colas Iniciación para entornos Main Frame Permiten asociar un proceso con una acción determinada a una cola local que es aquella que cumplirá las condiciones para que el proceso inicie. Para los entornos Main Frame hasta el momento solo se tiene establecido como procesos el arranque de transacciones línea dentro de un CICS. Nomenclatura: cic*.INIT.QUEUE Longitud : Máximo 48 posiciones donde: cic* INIT QUEUE

: Identificador de la STC de CICS donde iniciará la ejecución de una transacción línea, si se trata de una sola región de CICS, cuando sean varias regiones se utilizará el prefijo cic*0 : Identificador fijo, para indicar tipo de cola : Identificador fijo, para indicar que el objeto es una cola

Colas Iniciación para entornos Unix, NT, Digital, Tandem, AS/400 Permiten asociar un proceso con una acción determinada a una cola local que es aquella que cumplirá las condiciones para que el proceso inicie. Nomenclatura: QIe.aaaaa.ejecuta Longitud : Máximo 48 posiciones


26/33



donde: Q I e aaaaa ejecuta

: Identificador fijo, para indicar cola : Identificador fijo, para indicar tipo de cola, en este caso iniciación : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Identificador asignado al servicio distribuido y/o aplicación : Identificador del programa ejecutable a iniciar

Colas relacionadas al funcionamiento de los servicios aplicativos a ofrecer El nombre de estos objetos se encuentra directamente ligado al identificador del servicio distribuido así como del flujo de la aplicación. Estos objetos tendrán 2 palabras como constantes en el 3er. Calificador. Solo empleará una a la vez y no importa si son colas locales o remotas. Estas constantes son:  ENVIO, será empleado en el objeto que hace envío, o por donde llega la petición del servicio o aplicación para ser atendida. RESP, será empleado en el objeto que hace envío, o por donde llega la contestación para el  servicio o aplicación una vez que ha sido atendida. Por lo general los servicios bajo MQSeries requieren un par de colas, que pueden tipificarse con la descripción anterior de ENVIO y RESPuesta; sin embargo pueden existir aplicaciones o servicios que requieran colas adicionales ya sea por par o individuales para estas también aplicarán estas constantes y su identificación variando el sufijo del calificador de la aplicación mencionado de 4 o 5 posiciones. Actualmente se emplean con más frecuencia los siguientes sufijos del 3er. Calificador (aaa*): IA, para aplicaciones de Intranet IE, para aplicaciones de Internet EX, para aplicaciones de Extranet S, para colas que emplearán sesión aplicativa Colas Locales Nomenclatura: QLe.aaa*.flujo.pp Longitud : Máximo 48 posiciones donde: Q L e aaa*


: Identificador fijo, para indicar cola : Identificador fijo, para indicar tipo de cola, en este caso local : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Identificador asignado al servicio distribuido y/o aplicación el asterisco * implica un sufijo para identificar los servicios, actualmente se emplea: IA, para aplicaciones de Intranet IE, para aplicaciones de Internet 27/33



flujo pp

EX, para aplicaciones de Extranet S, para colas que emplearán sesión aplicativa : Identificador fijo ENVIO o RESP, para indicar flujo del mensaje dentro del contexto de la aplicación o servicio distribuido. : Solo aplica para aplicaciones corporativas. Identificador del país a quien dará servicio la aplicación (ver Tabla 2: Claves de países con dos )

Colas Remotas Nomenclatura: QRe.aaa*.flujo.qmdestino.pp Longitud : Máximo 48 posiciones donde: Q R e aaa*

: Identificador fijo, para indicar cola : Identificador fijo, para indicar tipo de cola, en este caso remota : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Identificador asignado al servicio distribuido y/o aplicación el asterisco * implica un sufijo para identificar los servicios, actualmente se emplea: IA, para aplicaciones de Intranet IE, para aplicaciones de Internet EX, para aplicaciones de Extranet S, para colas que emplearán sesión aplicativa flujo : Identificador fijo ENVIO o RESP, para indicar flujo del mensaje dentro del contexto de la aplicación o servicio distribuido. qmdestino : Identificador del queue manager que recibirá la información pp : Solo aplica para aplicaciones corporativas. Identificador del país a quien dará servicio la aplicación (ver Tabla 2: Claves de países con dos )

Procesos Indican la acción a realizar cuando una cola local cumple ciertas condiciones o eventos. Procesos para entornos Main Frame

Hasta este momento solamente se tiene implementado el arranque de transacciones línea dentro de un CICS. Nomenclatura: PRe.aaa*.tranid.cics.pp Longitud : Máximo 48 posiciones Gestión de la Calidad

28/33


ESTÁNDARES P ARA EL PROCESAMIENTO CENTRAL DE D ATOS GESTIÓN DE LA CALIDAD donde: PR e aaa*

tranid cics pp

: Identificador fijo, para indicar proceso : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Identificador asignado al servicio distribuido y/o aplicación el asterisco * implica un sufijo para identificar los servicios, actualmente se emplea: IA, para aplicaciones de Intranet IE, para aplicaciones de Internet EX, para aplicaciones de Extranet S, para colas que emplearán sesión aplicativa : Identificador del nombre de la transacción línea a ser ejecutada : Identificador de la stsrated task de CICS donde ejecutará la transacción : Solo aplica para aplicaciones corporativas. Identificador del país a quien dará servicio la aplicación (ver Tabla 2: Claves de países con dos )

Procesos para entornos Unix, NT, Digital, Tandem, AS/400 Nomenclatura: PRe.aaa*.ejecuta.pp Longitud : Máximo 48 posiciones donde: PR e aaa*

ejecuta pp


: Identificador fijo, para indicar proceso : Identificador del entorno (ver Tabla 6: Tabla de entornos ) : Identificador asignado al servicio distribuido y/o aplicación el asterisco * implica un sufijo para identificar los servicios, actualmente se emplea: IA, para aplicaciones de Intranet IE, para aplicaciones de Internet EX, para aplicaciones de Extranet S, para colas que emplearán sesión aplicativa : Identificador del programa ejecutable o proceso a iniciar : Solo aplica para aplicaciones corporativas. Identificador del país a quien dará servicio la aplicación (ver Tabla 2: Claves de países con dos )

29/33



4 Tablas de CICS. 4.1.1 Tabla de Identificador para regiones de CICS Tipo de CICS TOR QOR FOR AOR NATIVO AOR AOR AOR

Aplicación Terminales Colas TS Archivos Altamira AFP FALCON Medios de Pago Canales

Clave T Q F A P F M C

Tabla 1: Identificador para regiones de CIC


30/33



5 Anexos 5.1 Tablas Generales. Aquí se muestran las tablas de uso común, como son las tablas de países, negocios, etc.

5.1.1 Tabla de países cuando se utilizan dos caracteres País Argentina Brasil Bolivia Chile Colombia Ecuador El Salvador México Panamá Perú Puerto Rico Rep. Dominicana Venezuela Latinoamérica Estados Unidos de Norteamérica Conversión México Conversión Chile Neutro

Clave AR BR BO CL CO EC SV MX PN PE PR DO VE LT US YY XX ZZ

Tabla 2: Claves de países con dos caracteres


31/33



5.1.2 Tabla de países cuando se utiliza un caractér Tomando como base la tabla de países de dos caracteres se utiliza el primer caractér o el siguiente disponible en caso de ya haber sido utilizado. País Argentina Brasil Bolivia Chile Colombia Ecuador El Salvador México Panamá Perú Puerto Rico Rep. Dominicana Venezuela Latinoamérica Estados Unidos de Norteamérica Conversión México Conversión Chile Neutro

Clave A B O L C E S M N P R D V T W Y X Z

Tabla 3: Claves de países con un solo caractér

5.1.3 Tabla de negocios de dos caracteres Negocios Fondos y Pensiones Banco Casa de Bolsa Centro de Desarrollo Regional Multiempresas Seguros Fianzas

Clave FP BO CB DR ME SO FI

Tabla 4: Tabla de negocios con dos caracteres


32/33


Estandares CICS

Recommend Documents