Estandares CICS

7/17/2019 Estandares CICS

http://slidepdf.com/reader/full/estandares-cics 1/33

Gestión de la Calidad 1/33 Versión 2.0.3 Agosto 2013

Estándares Para El Procesamiento

De Datos Central

Servicios de Procesamiento América (SPA)




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ándares ..............................................................................................................3

1.3 Acerca de este documento ................................................................................................................3

1.4 A quién está dirigido este documento ...............................................................................................3

1.5 Cómo enviar sus comentarios ...........................................................................................................3

1.6 Registro y Control de Cambios al Documento ....................................................................................... 4

2 Convenciones ...................................................................................................................................... 5

2.1 Contenido no incluido ...................................................................................................................5

3 Estándares de nomenclatura de CICS .................................................................................................. 6

3.1.1

Started Task de CICS ............................................................................................................... 6 3.1.2 Owner y usuario de default de un CICS ................................................................................ 6

3.1.3 Usuario de la tabla PLTPI de un CICS .................................................................................... 7

3.1.4 Otros usuarios relacionados con recursos de CICS.............................................................. 7

3.1.5 Temporary Storage en CF (Coupling Facility) ....................................................................... 8

3.1.6 CICSPlex/SM ............................................................................................................................. 9

3.1.7 Transacciones ......................................................................................................................... 10

3.1.8 Componentes dentro de un CICSPLEX ................................................................................ 13

3.1.9 Consideraciones Técnicas de CICS ....................................................................................... 13

3.1.10 Relación con RACF de los componentes de CICS ............................................................... 14

3.1.11 Configuraciones Aplicativas .................................................................................................. 16

3.1.12 Balanceo de Transacciones ................................................................................................... 16

3.1.13 Uso de Entornos...................................................................................................................... 16

3.1.14

Lineamientos Generales de uso ............................................................................................ 17

3.1.15

Productos o Herramientas empleadas en CICS .................................................................. 18

3.1.16 Colas de Temporary Storage ................................................................................................. 18

3.1.17 Definición de recursos en CICS ............................................................................................ 21

3.1.18 Políticas generales ................................................................................................................. 22

4 Tablas de CICS. ................................................................................................................................. 30

4.1.1 Tabla de Identificador para regiones de CICS .................................................................... 30

5 Anexos .............................................................................................................................................. 31

5.1 Tablas Generales. ....................................................................................................................... 31

5.1.1 Tabla de países cuando se utilizan dos caracteres ............................................................ 31

5.1.2

Tabla de países cuando se utiliza un caractér .................................................................... 32 5.1.3

Tabla de negocios de dos caracteres ................................................................................... 32

5.1.4 Tabla de negocios cuando se utiliza un carácter................................................................ 33

5.1.5 Tabla de entornos................................................................................................................... 33






1 Introducción

1.1 Objetivos del documentoEl objetivo de este documento es oficializar y difundir un grupo de estándares que habrán de observarseen 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 deexplotación de la tecnología en los entornos existentes en los diferentes países del continente buscandopara estos fines capitalizar, en beneficio de cada uno de los bancos de América y del grupo, las mejoresprá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 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 laplataforma 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 laconfiguració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 einstalación de aplicaciones en la plataforma central y que hacen uso de las facilidades y herramientaspropias de este entorno.

Cualquier modificación y/o implementación de componentes en producción que difieran sobre la base deeste documento, la dirección responsable de gestionarlo y autorizarlo 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 deregularización.

1.5 Cómo enviar sus comentarios

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

mailto:[email protected]







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 elregistro 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

Versiónfecha

Descripción de Modificación Aprobación

Junio 25 2008 Actualización al 100% de Estándares y facilidades para CICS

Junio 2012 Si se utiliza el comando ENQ para controlar el acceso a algúnrecurso y garantizar la integridad de la información, no se debeusar el parámetro NOSUSPEND; y así mismo se deberá emitir elcomando DEQ lo más rápido posible, evitando retener el recursopor tiempo innecesario a fin de aumentar la posibilidad deconcurrencia de transacciones. De esta forma, la serialización larealizan el CICS o el Sistema Operativo (GRS), y por lo tanto, nose deben generar algoritmos alternos.

Aprobada

Agosto 2013 Se actualiza nomenclatura de Cola de iniciación y orden de detalleen descriptivos de Cola Local y Remota Aprobada

Registro y Control de Cambios al Documento






2 Convenciones

Este documento utiliza las siguientes convenciones para describir los estándares de nomenclatura

Convención DescripciónLetras mayúsculas 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 delHSM

Letras minúsculas 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 deacuerdo a la tabla Tabla 2: Claves de países con dos que se encuentra en lasección de Anexos de este documento.

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

Ej. Dpe<número / letra / G>

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 dela Oficina de Certificación de Aplicaciones CCR [email protected], para su evaluación con

las áreas técnicas del CCR.








3 Estándares de nomenclatura de CICS

3.1.1 Started Task de CICS

Nomenclatura:CICpetca

En donde:

CIC : Identificador fijo, para indicar CICSp : 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 un mismogrupo aplicativo de transacciones o aplicaciones y que cuentan con un balanceo de transacciones entreellas.

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 deberser activada en condiciones normales. Si la región puede levantarse en cualquier partición (Ej. Una regiónFOR) se utilizará el número cero. Si se trata de un ambiente monoplex utilizar igualmente el cero en todoslos casos.

Ejemplos:

El AOR1 para Medios de Pago Perú Producción en ambiente de test, configuración monoplexserí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 CICSe : 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






Esta nomenclatura aplica para CICS que se encuentran dentro de un CICSPLEX (conjunto de CICS). LosCICS nativos emplean como owner el mismo nombre de sus started 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ónEL 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 CICSPL : Identificador fijo, para indicar que es un usuario relacionado con la tabla PLT de CICSp : 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 conocidocomo 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 nuncapoder 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 calidadEl 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 usuariosque 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






t* : Identificador de la tabla o recurso de CICS al que se le asignará el usuario,pudiendo ser:

CO, conexionesTR, terminalesSK, sockets tcp/ipQG, 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 aplicacionesque 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 CICSp : Identificador del país (ver Tabla 3: Claves de países con un solo ) TS : Identificador fijo, para indicar temporary storagec : Número consecutivon : 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 storagep : Particiónc : Número consecutivo

Ejemplo:

TS11 es la identificación para la temporary storage 1 de la partición 1.






POOL

Nomenclatura:

POOLnn

En donde:

POOL : Identificador fijo, para indicar POOLnn : 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 : Identificador fijo, para indicar CICS p : Identificador del país (ver Tabla 3: Claves de países con un solo ) CA : Identificador fijo, para indicar CAS (Coordinator Address Space)p : 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 contengaa : 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 : Identificador fijo, para indicar CICS p : Identificador del país (ver Tabla 3: Claves de países con un solo ) CM : Identificador fijo, para indicar CMAS (CICSPlex Manager Address Space)p : 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

a : 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.






Context y Scope del Cicsplex

Para entonos previos se definirá uno para los entornos previos de desarrollo, test y formacióncon 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ánlas definiciones

e : Identificador del entorno (ver Tabla 6: Tabla de entornos, solo aplica lasletras: ‘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, porGestión de Cambios.

Nomenclatura:

aacc

En donde:

aa : Los 2 primeros caracteres de la aplicaciónNINGUNA TRANSACCION DE APLICACIÓN PUEDE INICIAR CON LA LETRA “C” , pues esta letraestá reservada para el uso de transacciones del propio CICS.

Existen otros nombres de transacciones las cuales pertenecen a programas producto cuyos nombrestambién están restringidos, estas son:

SOCKETS:

EZACEZAO

EZAPEZKL (todas las EZ*)

CICS:MENU

CICSPLEX: BMLTLCPP






LECILECRLECSLEEILEERLEMILEMSLENSLMIRLNCILNCSLNMILNMSLPDGLPLKLPLTLPRT

LPSCLPSMLRLTLSRTLWTMMCCMMCTKMMEIMMISMMSTPEADPELTPMLT

PNLTPPLTPRLTPRPRPSLTTICTTIRTTISTTSMHTSPDTSSCTSSJWMCCWMGRWMLAWMQBWMQMWMQSWMSCWMWCWMWTWSCL






WSLWXDBMXDNCXDNDXDNEXDNRXDNSXDSRXLECXLEVXLNXXLSTXQST

MEMO:MAPI

OMEGAMONOMEG

Uso Interno CICS:PONG

CONTROL-M:CTM* (incluidas en las C*)

MQseries:CK* (incluidas en las C*)

CONTRL-D:

DOLVTMAN

CSP:XSPEXSPPXSPSXSPZ (todas las XSP*)

BridgeMQ (para uso de Arquitectura):**QG

MAINVIEW:FCD2FIC2FCM1JNL2SMN2MVRT






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 puedenexistir TORES, AORES y FORES, éste término puede confundirse con la palabra CICSPLex ésta últimahace 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 palabrarelacionada con el programa producto y es emplear la combinación de mayúsculas y minúsculas de lasiguiente manera: CICSPLex. De igual forma existe una convención fonética para distinguir éstos doshomónimos.

En el ambiente de BBVA, la filosofía para las aplicaciones línea es estar bajo Altamira y con DB2 yaque 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ónde 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 unaespecialidad 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 posiblecombinarlos 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 eimpresoras 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 esejecutada.

Control de datos:DOR - Data Owning Region. Región de CICS que controla los recursos para el accesode los datos . (FOR,QOR)

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

DB2.- En este caso el control de los datos ya no lo tiene CICS sino el subsistemamanejador de la base de datos, por lo que la responsabilidad de la integridad de losdatos la toma este subsistema.Coupling Facility.- Se encuentra disponible únicamente en sistemas con ParallelSysplex y es memoria de alta referencia y por lo tanto muy costosa, en este caso lainformación reside en este componente y este es el que se encarga de administrar susaccesos.

Adicional a estos 3 tipos de CICS, existe uno que es recomendable cuando una aplicación cuenta conrequerimientos especiales que no son estándar para las demás aplicaciones y es conocido como CICSnativo, este realiza las 3 funciones es un TOR, AOR y FOR a la vez.






En conclusión el modelo ideal de la Infraestructura CICS es bajo la filosofía MRO, es decir, bajo laconfiguración por Capas: para el control de terminales o enlaces TCP/IP (TOR ), regiones para laejecución del código de la aplicación ( AOR ) y regiones para las TSQs compartidas y en su casoarchivos (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 terminalesse deberá utilizar el concepto de AUTOINSTALL, tanto para 3270 como para TerminalFinanciero. En el caso de conexiones hacia entidades externas éstas pueden ser LU6.2 o bienconexiones 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, sinembargo, 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 +SWAque puede definirse de manera local en todos los AOR asegurándose que ésta sea borradadespué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 elQOR.

En caso de contar con CICSPlex SM, éste se deberá utilizar para hacer la distribución y balanceo detransacciones en el TOR hacia los AORs correspondientes, de otro modo las transacciones deberánser 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 lasasociadas al MQ Series, o de las que servirán como copia de la CSMI para identificar un DPL entreaplicaciones 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 3usuarios 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 suacceso y finalmente la lista de transacciones a ser ejecutadas.

OWNEREl 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 serllamadas por terminal, y usuarios auxiliares, como son el PLTPIUSER, DEFAULT USERID y el






usuario para disparo de transacciones (TRIGGERS). El OWNER, por lo tanto, debe tener accesotanto a los recursos externos como internos.

En un ambiente CICSPLEX, se utiliza el mismo OWNER para facilitar la administración de losperfiles ya que cada uno de los CICS del CICSPLEX son clones, es decir, tienen definidos losmismos recursos..

USUARIO DE DEFAULT

Dentro de CICS toda ejecución de alguna transacción debe estar asociada a un usuario, aún ycuando este se encuentre en la etapa de arranque o cuando un usuario final ejecute transaccionessin firmarse aún con su usuario propio. El CICS se firma con el DEFAULT USERID durante lainicialización del propio CICS y utiliza este usuario para aquellas transacciones que no requierenfirma. Cuando un usuario entra al CICS y trata de ejecutar una transacción sin haberse firmado elusuario 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 duranteel arranque del CICS que no son asociadas directamente al arranque del propio de la tarea delCICS, por ejemplo ejecuta las transacciones que permiten la conexión con CICSPlex, conOmegamon, o con MQSeries, también puede ejecutar transacciones aplicativas que de igual formase 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. Elacceso debe darse a los TORES, o bien, al VTAM GENERIC RESOURCES, de esta manera se obligaa 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 uopere al CICS.

TRANSACCIONES

La Arquitectura de IBM realiza recomendaciones para el agrupamiento de transacciones en RACFpara 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 deasignar 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 dondeson requeridas.

Las únicas consideraciones que Middleware CICS/MQ tiene relacionadas a los accesos para DyD enlos 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 yDesarrollo ya que estas transacciones son exclusivas para la administración de los recursosdefinidos en CICS.

El área de Middleware CICS/MQ de CCR no da accesos ni VoBo del uso de transaccionesaplicativas.






3.1.11 Configuraciones Aplicativas

Las aplicaciones deben ser agrupadas en CICS de acuerdo al tipo de funcionalidad a ofrecer y a lacriticidad 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 dePago, 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 Managersson clasificados de acuerdo a la criticidad de las aplicaciones y con base a los CICS que lesofrecerán los servicios aplicativos.

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

3.1.12 Balanceo de Transacciones

Las aplicaciones deberán ser desarrolladas sin afinidades, a efecto de habilitar su ejecución enuno 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 hacerlomediante el uso de variables o a través del comando ASSIGN, siempre y cuando el nombrede éste coincida con el nombre de la conexión del CICS en cuestión. Si es completamentenecesario el uso del nombre de estos parámetros de CICS es posible emplear las colas de TSempleadas 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 deuso diferente y de acuerdo a ellos son configurados parámetros propios del producto CICS que permitencontar con disponibilidad y competir por los recursos del equipo de acuerdo a la necesidad del entorno. Acontinuación describiremos brevemente el uso de ellos:

DesarrolloEs empleado para la ejecución de pruebas unitarias. Validación de mapas, que no generen

abends, etc.






TestEs empleado para la ejecución de pruebas integrales informáticas. DyD es quien realiza lavalidación de estas pruebas con una mayor casuística de pruebas. Es posible realizar pruebas devolumen.

CalidadEs empleado para la ejecución de pruebas funcionales. Organización es quien realiza la validaciónde estas pruebas y con base en sus conocimientos del negocio realiza pruebas de otrasaplicaciones relacionadas con las modificaciones.

FormaciónEs empleado para realizar la capacitación de los usuarios finales, o bien para la ejecución depruebas de certificación por su estabilidad.

ProducciónEs empleado para ofrecer los servicios en línea a los usuarios finales y en horarios de servicioconvenidos 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 serconveniente utilizar archivos VSAM que no sea necesario recuperarlos en caso de contingenciao 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 mecanismode intercomunicación aplicativa vigente.

En caso de que las aplicaciones requieran intercomunicarse entre sí vía LINK de programas yresidan en AORs independientes, deberán hacer uso de un TOR como paso asignando unaTRANSID para identificar las aplicaciones involucradas, está última deberá ser una copia de laCSMI.

Se deberá utilizar MQSeries para realizar la interfase con aplicaciones no HOST (servidoresinternos).

Si se utiliza el comando ENQ para controlar el acceso a algún recurso y garantizar la integridadde la información, no se debe usar el parámetro NOSUSPEND; y así mismo se deberá emitir elcomando 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 larealizan el CICS o el Sistema Operativo (GRS), y por lo tanto, no se deben generar algoritmosalternos.

Siempre verificar el código de retorno de las sentencias CICS para evitar ABENDs en lastransacciones.

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.






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ónlos siguientes productos, sin embargo será necesario evaluar de acuerdo al entorno y al uso a darle si esfactible o no realizar su instalación.

PRODUCTO DESCRIPCIÓN

AF/OPERATOROPS 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 BATCHDB2 BASE DE DATOS RELACIONAL

MQ SERIES COMUNICACIÓN CON TCP/IP O SNA CON ENTIDADES EXTERNAS

OMEGAMONMAINVIEW MONITOR DE CICS

QAHIPERSTATION CAPTURA Y REPRODUCE TRANSACCIONES CON VOLUMEN

STROBEFREEZEFRAME 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 endisco 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 disponibilidadde 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 mismasaplicaciones 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 diferentenombre y puede ser en el mismo CICS o en diferente región de CICS, por este ultimo motivo los datosdeben de ubicarse de manera compartida.






Para que un cola de temporary storage sea compartida es necesario ubicarla en un área común para losdiferentes CICS que hagan referencia de ella, estas áreas comunes son los CICS QOR (Queue OwningRegion) 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, usela información y al concluir su uso la borre. Con esto es posible generar la cola de manera local en lamisma región de CICS.

Si el dato debe ser compartido por diferentes unidades de trabajo que se ejecutan en diferentes regionesde CICS, es necesario asegurar en el flujo aplicativo diario su depuración una vez que se haga uso de ellao 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 yvolumen 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 comandosXCTL o LINK. Para estos casos específicos se recomienda utilizar mejor la COMMAREA. Cuando la información debe ser compartida entre programas que se ejecutan en diferentes CICS,

es necesario utilizar colas TS compartidas o shared. Sin embargo el último en emplearla debeasegurarse de borrarla.

Si la cola TS solo va a ser leída exclusivamente, se puede existir una réplica en cada CICS dondese 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 debecompartirse 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 lagenera, use la información y al concluir su uso la borre. Con esto es posible generar la cola demanera 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 deaccesos a estas tablas. Se deberá consultar con el grupo de soporte técnico para conocer estaslimitantes.

En el caso de utilizar colas de TS para colocar tablas DB2 pequeñas en memoria, se recomiendautilizar la llave de acceso dentro del nombre de la cola de TS para tener un acceso directo al datoque 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ónen CICS.

No deberá utilizarse el operador automático para la ejecución de transacciones, borrado de colasde temporary storage, cierre y apertura de archivos, etc.

3.1.16.2 Características de las colas de Temporary Storage

Permanencia






El tiempo de permanencia de las colas TS debe ser mínima. Si la cola TS solo es utilizada durantela 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 elciclo quede interrumpido.

La aplicación deberá contar con un mecanismo propio que de manera periódica durante el díaborre 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 elrecurso donde se alojan es memoria y es muy costosa.

Las colas TS NO deben ser utilizadas para guardar información de la cual haya dependenciaaplicativa, 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 deprogramas.

Tamaño

La información manejada en colas TS no debe exceder de 20 Kb por cola TS de manera ideal paracolas que se generarán con gran frecuencia y con mucho volumen de transacciones. Es posibleque existan máximo 100 colas simultáneamente por aplicación (por ejemplo, colas que se generanpor 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 150Kb 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, parafacilitar su identificación durante la operación.

El nombre NO debe iniciar con caracteres especiales (/, @, #, etc.).






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 considerandolos 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 quecorrespondan 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 maneraque exista redundancia en ellas, si emplean Altamira deben ser asociadas al programa QC1CENT y alplan 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 deDB2 asignado de manera genérica con el prefijo de las transacciones. La definición de transaccionesque inicien con la letra ”C” está restringido ya que se encuentran reservadas para el uso exclusivo detransacciones 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óncc : 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á reservadapara l as transacciones propias de CICS.

Del recurso: ts models (temporary storage models) se valida y sugiere que se definanexclusivamente cuando sea necesario compartir datos en colas (queues) entre unidades de trabajodiferentes (transacciones con el mismo nombre ejecutándose en momentos diferentes) y que se tengacuidado en su creación, uso y depuración una vez concluido su uso para no saturar los recursos deCICS asignados a estas colas. Deben emplear nombres genéricos que sirvan de prefijos paratransacciones de la misma aplicación. Su definición para sistemas sin Parallel Sysplex debe ser remotaa 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 losCICS adecuados ya sea TORES y/o AORES.

Del recurso: programas Los CICS deben contar con el autoinstall de programas locales, si es así noes necesario realizar esta definición de programas locales a menos que requieran una especificacióndiferente al default, dentro de este concepto de autoinstall también se encuentran las rutinas y losmapas.

Del recurso: programas remotos son una excepción del recurso anterior y es necesario validar lanecesidad de ésta definición ya que la arquitectura Altamira está diseñada para ir llamando programasde diferentes aplicaciones para dar un servicio únicamente haciendo un LINK de los programas deotras aplicaciones. Sin embargo es posible que se justifique su definición, si es así se sugiere que porprogramación se identifique con parámetro o variables el nombre de conexión del CICS donde sequiere ejecutar el programa y lo mande llamar con el comando link y sysid de tal forma que no segenere una afinidad al nombre de conexión o a la definición en CICS. Además de emplear el






parámetro transid para ejecutar una transacción mirror y así identificar su paso por el otro CICS, estatransacción es necesario definirla local en el CICS donde se ejecutará el archivo como copia de latransacción de CICS CSMI.

Del recurso: archivos se valida que el DDNname del CICS sea el mismo que el último calificador delcluster (de preferencia), si es un archivo KSDS deben de ser incluida la longitud de la llave. Se sugiereque 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 CICStenga acceso por lo menos de update para el cluster del archivo. La utilización de archivos VSAM enCICS está restringida, deberá utilizarse DB2. Los archivos VSAM solo podrán definirse en CICS previavalidación y autorización del área CICS/MQ.MQSeries

MQSeries es utilizado como el estándar dentro del grupo BBVA como Middleware de comunicaciónasíncrono (o síncrono, ya que es posible simularlo) entre aplicaciones internas y externasmultiplataforma, por lo que es indispensable establecer los estándares de nomenclatura y uso defacilidades 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 encualquier 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 serproporcionados por los desarrollos del área de Arquitectura Aplicativa de CDR, es responsabilidad deellos en base a las necesidades de la aplicación proponer las características de los objetos a definir enMQSeries.

Los líderes de los servicios aplicativos junto con Arquitectura Aplicativa CDR deben de asegurarse quelos mensajes empleados cuenten con parámetros adecuados de expiración y persistencia de acuerdo ala necesidad y funcionalidad de la aplicación realizando una depuración de ellos de manera periódicacuando éstos ya no sean útiles. Estos parámetros deberán ser asignados dentro de los programas dela 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 losnombres de los objetos a definir en MQSeries para aplicaciones CCR, así como ofrecer el soporte sobrela infraestructura del producto únicamente.

Como convención todos los nombres de los objetos a definirse en MQSeries deben ser enMAYÚ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






impacto al servicio productivo. Si es permisible la conexión de equipos que compartan varios entornosprevios 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) Locales Aplicaciones que darán servicio exclusivamente a un cliente de CCR. Uno de los equipospuede ser administrado por CCR y el otro puede ser administrado en el país que ofreceráservicio de esta aplicación de manera local.

2) Corporativas Aplicaciones que darán servicio a más de un cliente de CCR. Ambos equipos a serinterconectados pueden ser administrados por CCR.

Los objetos que actualmente se encuentran definidos en cualquier entorno de desarrollo o productivopueden 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ándarCCR. Mientras que los objetos existentes serán respetados y de manera paulatina y en coordinacióncon 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 lasaplicaciones corporativas deberán contar un calificador adicional al final de los objetos de dos posicionesque identifique al país que dará servicio. Este calificador solo será empleado en los objetos colasrelacionados 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 lageneració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 lanomenclatura será referenciado con los caracteres ‘aaaaa’ dependiendo de la longitud permitida dentro delobjeto listado.

Cada aplicación o servicio distribuido de acuerdo a sus necesidades, puede contar con un número finito decolas ya sean locales o remotas; y con un número también finito de canales. Estos objetos seránidentificadas como el set básico necesario para la funcionalidad de la aplicación, y cada uno de éstos setsdeberá ser definido en cada entorno reconocidos por el grupo BBVA (D, T, C, F) donde se desee probar yobviamente en producción. El entorno que establece la letra a emplear es el entorno de HOST, de maneraprioritaria.

Es posible que por algún proyecto especial tal como una migración de la aplicación de uno de los equiposdel servicio, reubicación de equipos, habilitación de cifrado de información, pruebas de volumen, entreotros. Será necesario replicar las definiciones de los mismos objetos del set básico de una aplicación enalguno de los entornos reconocidos por el grupo BBVA.

Estas definiciones deben ser temporales y deben ser generados en entornos de desarrollopreferentemente. Al término del proyecto deberán solo existir los objetos con la nomenclatura del setbásico que le corresponda al entorno. La manera de identificarlos será añadir al final de los objetosrequeridos un calificador nuevo de máximo 8 caracteres (si lo permite la longitud el objeto), que hagareferencia al proyecto.






Qmanager’s

El nombre del Qmanager debe hacer referencia al ambiente donde vive y al tipo de servicio que ofrece. Sunombre 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 : Identificador fijo, para indicar Queue Managerp : Identificador del país (ver Tabla 3: Claves de países con un solo ) e : Identificador del entorno (ver Tabla 6: Tabla de entornos ) c : 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 : Identificador fijo, para indicar Queue Managerp : Identificador del país (ver Tabla 3: Claves de países con un solo ) e : Identificador del entorno (ver Tabla 6: Tabla de entornos ) aaa : Identificador de 3 posiciones de la aplicación o servicio distribuidoc : 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 canalesServer – 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 nombredebe estar compuesto por el de los QMGR´S involucrados.

Nomenclatura:

CHt.qmorigen.qmdestino






Longitud : Máximo 20 posicionesdonde:

CH : Identificador fijo, para indicar Channelt : Identificador del tipo de canal (T para TCP/IP, S para SNA)

qmorigen : Identificador del queue manager que envía la informaciónqmdestino: 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 : Identificador fijo, para indicar Channel Server Conectionaaaaa : Identificador de 4 o 5 posiciones asignado al servicio

distribuido y/o aplicaciónSRVCONN : 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 unapor Qmanager

Nomenclatura:

qmlocal.DEAD.QUEUE


donde:

qmlocal : Identificador de 4 o 8 posiciones referente alqueue manager al que se asignará esta cola

DEAD : Identificador fijo, para indicar tipo de colaQUEUE : 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 uncanal debe ser asociado también solo a una cola de transmisión.






Nomenclatura:

qmdestino.XMIT.QUEUE


donde:

qmdestino : Identificador de 4 a máximo 8 posiciones referente alqueue manager destino donde se enviarán los mensajes

XMIT : Identificador fijo, para indicar tipo de colaQUEUE : 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á lascondiciones para que el proceso inicie. Para los entornos Main Frame hasta el momento solo se tieneestablecido como procesos el arranque de transacciones línea dentro de un CICS.

Nomenclatura:

cic*.INIT.QUEUE


donde:

cic* : Identificador de la STC de CICS donde iniciará la ejecución deuna transacción línea, si se trata de una sola región de CICS, cuando seanvarias regiones se utilizará el prefijo cic*0

INIT : Identificador fijo, para indicar tipo de colaQUEUE : 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á lascondiciones para que el proceso inicie.

Nomenclatura:

QIe.aaaaa.ejecuta







donde:

Q : Identificador fijo, para indicar colaI : Identificador fijo, para indicar tipo de cola, en este caso iniciacióne : Identificador del entorno (ver Tabla 6: Tabla de entornos ) aaaaa : Identificador asignado al servicio distribuido y/o aplicaciónejecuta : 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 noimporta 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 elservicio 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 ladescripción anterior de ENVIO y RESPuesta; sin embargo pueden existir aplicaciones o servicios querequieran colas adicionales ya sea por par o individuales para estas también aplicarán estas constantes ysu 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 IntranetIE, para aplicaciones de InternetEX, para aplicaciones de ExtranetS, para colas que emplearán sesión aplicativa

Colas Locales

Nomenclatura:

QLe.aaa*.flujo.pp


donde:

Q : Identificador fijo, para indicar colaL : Identificador fijo, para indicar tipo de cola, en este caso locale : Identificador del entorno (ver Tabla 6: Tabla de entornos ) aaa* : 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 IntranetIE, para aplicaciones de Internet






EX, para aplicaciones de ExtranetS, para colas que emplearán sesión aplicativa

flujo : Identificador fijo ENVIO o RESP, para indicar flujo del mensaje dentrodel contexto de la aplicación o servicio distribuido.

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 )

Colas Remotas

Nomenclatura:

QRe.aaa*.flujo.qmdestino.pp


donde:Q : Identificador fijo, para indicar colaR : Identificador fijo, para indicar tipo de cola, en este caso remotae : Identificador del entorno (ver Tabla 6: Tabla de entornos ) aaa* : 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 IntranetIE, para aplicaciones de InternetEX, para aplicaciones de ExtranetS, 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ónpp : 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 unCICS.

Nomenclatura:

PRe.aaa*.tranid.cics.pp







donde:

PR : Identificador fijo, para indicar procesoe : Identificador del entorno (ver Tabla 6: Tabla de entornos ) aaa* : Identificador asignado al servicio distribuido y/o aplicación


tranid : Identificador del nombre de la transacción línea a ser ejecutadacics : Identificador de la stsrated task de CICS donde ejecutará la

transacciónpp : Solo aplica para aplicaciones corporativas.


Procesos para entornos Unix, NT, Digital, Tandem, AS/400

Nomenclatura:

PRe.aaa*.ejecuta.pp


donde:

PR : Identificador fijo, para indicar procesoe : Identificador del entorno (ver Tabla 6: Tabla de entornos ) aaa* : Identificador asignado al servicio distribuido y/o aplicación


ejecuta : Identificador del programa ejecutable o proceso a iniciarpp : Solo aplica para aplicaciones corporativas.







4 Tablas de CICS.

4.1.1 Tabla de Identificador para regiones de CICS

Tipo de CICS Aplicación ClaveTOR Terminales TQOR Colas TS QFOR Archivos F AOR Altamira ANATIVO AFP P AOR FALCON F AOR Medios de Pago M

AOR Canales CTabla 1: Identificador para regiones de CIC






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 Clave Argentina ARBrasil BRBolivia BOChile CLColombia COEcuador ECEl Salvador SVMéxico MXPanamá PNPerú PEPuerto Rico PRRep. Dominicana DO Venezuela VELatinoamérica LTEstados Unidos de

Norteamérica

US

Conversión México YYConversión Chile XXNeutro ZZ

Tabla 2: Claves de países con dos caracteres






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 siguientedisponible en caso de ya haber sido utilizado.

País Clave Argentina ABrasil BBolivia OChile LColombia CEcuador EEl Salvador SMéxico MPanamá NPerú PPuerto Rico RRep. Dominicana D Venezuela VLatinoamérica TEstados Unidos deNorteamérica

W

Conversión México YConversión Chile XNeutro Z

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

5.1.3 Tabla de negocios de dos caracteres

Negocios ClaveFondos y Pensiones FPBanco BOCasa de Bolsa CBCentro de Desarrollo Regional DR

Multiempresas MESeguros SOFianzas FI

Tabla 4: Tabla de negocios con dos caracteres





5.1.4 Tabla de negocios cuando se utiliza un carácter

Tomando como base la tabla de negocios de dos caracteres se utiliza el primer carácter o el siguientedisponible en caso de ya haber sido utilizado

Negocios ClaveFondos y Pensiones FBanco BCasa de Bolsa CCentro de Desarrollo Regional DMultiempresas MSeguros SFianzas I

Tabla 5: Tabla de negocios con un sólo carácter

5.1.5 Tabla de entornos

Entornos ClaveDESARROLLO DTEST TCALIDAD CFORMACIÓN FPRODUCCION PLABORATORIO LBRS BPREPRODUCCION Q ASTA APRUEBAS STAND IN(ENTORNOSPREVIOS)

S

Tabla 6: Tabla de entornos

Estandares CICS

Documents

Transcript of Estandares CICS