Estandares CICS

Estndares Para El Procesamiento
De Datos Central
Servicios de Procesamiento Amrica (SPA)
Gestin de la Calidad
1/33
Versin 2.0.3
Agosto 2013
ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

GESTIN DE LA CALIDAD
Tabla de Contenido
1
1.1
1.2
1.3
1.4
1.5
Introduccion ........................................................................................................................................ 3
Objetivos del documento ..................................................................................................................3
Objetivos de los estndares ..............................................................................................................3
Acerca de este documento ................................................................................................................3
A quin est dirigido este documento ...............................................................................................3
Cmo enviar sus comentarios ...........................................................................................................3
1.6 Registro y Control de Cambios al Documento ....................................................................................... 4

2
2.1
Convenciones ...................................................................................................................................... 5
Contenido no incluido ...................................................................................................................5
Estndares de nomenclatura de CICS .................................................................................................. 6
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.1.8
3.1.9
3.1.10
3.1.11
3.1.12
3.1.13
3.1.14
3.1.15
3.1.16
3.1.17
3.1.18
4
Tablas de CICS.................................................................................................................................. 30
4.1.1
5
5.1
Started Task de CICS ............................................................................................................... 6

Owner y usuario de default de un CICS ................................................................................ 6
Usuario de la tabla PLTPI de un CICS .................................................................................... 7
Otros usuarios relacionados con recursos de CICS.............................................................. 7
Temporary Storage en CF (Coupling Facility) ....................................................................... 8
CICSPlex/SM............................................................................................................................. 9
Transacciones ......................................................................................................................... 10
Componentes dentro de un CICSPLEX ................................................................................ 13
Consideraciones Tcnicas de CICS....................................................................................... 13
Relacin con RACF de los componentes de CICS ............................................................... 14
Configuraciones Aplicativas .................................................................................................. 16
Balanceo de Transacciones ................................................................................................... 16
Uso de Entornos...................................................................................................................... 16
Lineamientos Generales de uso............................................................................................ 17
Productos o Herramientas empleadas en CICS .................................................................. 18
Colas de Temporary Storage................................................................................................. 18
Definicin de recursos en CICS ............................................................................................ 21
Polticas generales ................................................................................................................. 22
Tabla de Identificador para regiones de CICS .................................................................... 30
Anexos .............................................................................................................................................. 31
Tablas Generales. .......................................................................................................................31

5.1.1 Tabla de pases cuando se utilizan dos caracteres ............................................................ 31
5.1.2 Tabla de pases cuando se utiliza un caractr .................................................................... 32
5.1.3 Tabla de negocios de dos caracteres ................................................................................... 32
5.1.4 Tabla de negocios cuando se utiliza un carcter................................................................ 33
5.1.5 Tabla de entornos................................................................................................................... 33
2/33
Versin 2.0.3
Agosto 2012

1 Introduccin
1.1 Objetivos del documento
El objetivo de este documento es oficializar y difundir un grupo de estndares que habrn de observarse
en las instalaciones de Informtica de Amrica del grupo BBVA.
1.2 Objetivos de los estndares

El objetivo del establecimiento de estndares en el grupo BBVA es homogeneizar los esquemas de
explotacin de la tecnologa en los entornos existentes en los diferentes pases del continente buscando
para estos fines capitalizar, en beneficio de cada uno de los bancos de Amrica y del grupo, las mejores
prcticas para lograr altos niveles de productividad y eficiencia de los recursos tecnolgicos 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 estndares de nomenclatura para almacenamiento, de la
plataforma central a los que debern apegarse los bancos del Centro Corporativo Regional Amrica.
1.4 A quin est dirigido este documento

Este documento est dirigido al personal tcnico encargado del diseo e implementacin de la
configuracin tcnica de los sistemas centrales de almacenamiento.
As mismo se dirige a los lderes de diseo y desarrollo que tiene bajo su responsabilidad el diseo e
instalacin de aplicaciones en la plataforma central y que hacen uso de las facilidades y herra mientas
propias de este entorno.
Cualquier modificacin y/o implementacin de componentes en produccin que difieran sobre la base de
este documento, la direccin responsable de gestionarlo y autorizarlo ser Calidad Informtica.
Solo sern considerados con el Vo. Bo. del Director de Medios del pas y con un compromiso de fecha de
regularizacin.
1.5 Cmo enviar sus comentarios

Sus comentarios sobre el contenido de este documento son importantes para el CCR, as mejoraremos la
calidad de la informacin que se difunde. Favor de dirigirlos a estandares.ccr@bbva.bancomer.com,
dnde con gusto los atenderemos.
3/33
Versin 2.0.3
Agosto 2012

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 optimizacin y el mejoramiento en el uso y
funcionalidad de los recursos en que viven nuestros sistemas.
Tipo de:
Modificacin
Versin
fecha
Junio 25 2008
Junio 2012
Agosto 2013
Descripcin de Modificacin
Aprobacin
Actualizacin al 100% de Estndares y facilidades para CICS

Si se utiliza el comando ENQ para controlar el acceso a algn
recurso y garantizar la integridad de la informacin, no se debe
usar el parmetro NOSUSPEND; y as mismo se deber emitir el
comando DEQ lo ms rpido posible, evitando retener el recurso
por tiempo innecesario a fin de aumentar la posibilidad de
concurrencia de transacciones. De esta forma, la serializacin la
realizan el CICS o el Sistema Operativo (GRS), y por lo tanto, no
se deben generar algoritmos alternos.
Aprobada
Se actualiza nomenclatura de Cola de iniciacin y orden de detalle

en descriptivos de Cola Local y Remota
Aprobada
Registro y Control de Cambios al Documento
4/33
Versin 2.0.3
Agosto 2012

2 Convenciones
Este documento utiliza las siguientes convenciones para describir los estndares de nomenclatura
Convencin
Letras maysculas
Descripcin
Representan literales constantes que debern utilizarse tal y como aparecen en este
documento o un estndar previamente descrito.
Ej. HSMppe.**
Las letras HSM debern utilizarse al principio del nombre para los archivos propios del
HSM
Letras minsculas
Representan caracteres que debern ser substituidos por alguna convencin como se
cita en el documento.
Para el ejemplo anterior, las letras pp debern substituirse por el cdigo de pas de
acuerdo a la tabla Tabla 2: Claves de pases con dos que se encuentra en la
seccin de Anexos de este documento.
Los caracteres < / > se utilizarn para indicar una lista de valores posibles a utilizar en
dicha posicin
</>
Ej. Dpe<nmero / letra / G>

La cuarta posicin de esta nomenclatura deber substituirse ya sea por un nmero,
una a letra o la literal G
Se utiliza para representar cualquier combinacin de caracteres posible
* **
Este documento utiliza algunos tipos especiales de texto como:

Nota: Notas que contienen informacin importante que usted deber de considerar.
Referencias: Referencias a otras secciones en este documento o informacin relacionada.
2.1 Contenido no incluido

Todo contenido no incluido en el presente documento deber ser consultado antes de utilizarlo a travs de
la Oficina de Certificacin de Aplicaciones CCR BFOCTCCR@bbva.bancomer.com, para su evaluacin con
las reas tcnicas del CCR.
5/33
Versin 2.0.3
Agosto 2012

3 Estndares de nomenclatura de CICS

3.1.1 Started Task de CICS
Nomenclatura:
CICpetca
En donde:
CIC
p
e
t
c
a
: Identificador fijo, para indicar CICS

: Identificador del pas (ver Tabla 3: Claves de pases con un solo )
: Identificador del entorno (ver Tabla 6: Tabla de entornos)
: Identificador del tipo de CICS (ver Tabla 1: Identificador para regiones de CIC )
: Nmero consecutivo de la regin: 1,2,...,9. A,B....Z empezando por el nmero uno (1)
: Nmero de particin del sysplex (1,2,3,...,9) cero (0) si puede levantarse en cualquier
particin o si se trata de un entorno monoplex puede emplearse el no. 1.
El nmero consecutivo de la regin se utilizar para nombrar a las regiones que se pertenecen a un 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 nmero de la particin se utilizar para especificar la particin de un sysplex en la que una regin deber
ser activada en condiciones normales. Si la regin puede levantarse en cualquier particin (Ej. Una regin
FOR) se utilizar el nmero cero. Si se trata de un ambiente monoplex utilizar igualmente el cero en todos
los casos.
Ejemplos:
El AOR1 para Medios de Pago Per Produccin en ambiente de test, configuracin monoplex
sera: CICPTM10.
El TOR3 de la particin 2 de un sysplex en Venezuela en entorno de produccin: CICVPT32.
Una regin 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
p
11 : Asignacin fija para identificar este tipo de usuarios
6/33
Versin 2.0.3
Agosto 2012

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 started task.
Ejemplo: 1) CICS nativo de AFPS Mxico desarrollo.
El nombre del CICS es CICMDP11 y de igual forma es su owner CICMDP11
2) CICS que pertenece a Altamira en Chile produccin
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
PL
p
e
t
c
: Identificador fijo, para indicar que es un usuario relacionado con CICS

: Identificador fijo, para indicar que es un usuario relacionado con la tabla PLT de CICS
: Identificador del tipo de CICS (ver Tabla 1: Identificador para regiones de CIC )
: Nmero consecutivo de la regin: 1,2,...,9. A,B....Z empezando por el nmero uno (1)
Esta nomenclatura aplica para CICS que actualmente no cuentan con este usuario, tambin 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 caractersticas de no tener password o nunca
poder ser revocados
Ejemplo: 1) CICS nativo de AFPS Mxico 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

Bsicamente siguen el mismo estndar que los usuarios de PLT descritos anteriormente y son usuarios
que deben de contar con caractersticas de no tener password o nunca poder ser revocados. Son
asociados a tablas o recursos de CICS y estn asociados a alguna aplicacin en particular.
Nomenclatura:
UCt*a*pe
En donde:
UC : Identificador fijo, para indicar que es un usuario relacionado con CICS
7/33
Versin 2.0.3
Agosto 2012

t*
a*
p
e
: 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 aplicacin de CICS BRIDGE
: Identificador de aplicacin dentro de host, es mximo de dos posiciones.
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 tendrn la siguiente nomenclatura:
Nomenclatura:
CICpTScn
En donde:
CIC: Identificador fijo, para indicar CICS
p : Identificador del pas (ver Tabla 3: Claves de pases con un solo )
TS : Identificador fijo, para indicar temporary storage
c : Nmero consecutivo
n : Nmero de particin del sysplex
Ejemplo:
El servidor 2 para la particin 1 de un sysplex en Venezuela sera: CICVTS21
El servidor 3 para la particin 2 en Mxico sera: CICMTS32
Identificador
El SYSIDNT para cada pool tendr la siguiente nomenclatura:
Nomenclatura:
TSpc
En donde:
TS : Identificador fijo, para indicar temporary storage
p : Particin
c : Nmero consecutivo
Ejemplo:
TS11 es la identificacin para la temporary storage 1 de la particin 1.
8/33
Versin 2.0.3
Agosto 2012

POOL
Nomenclatura:
POOLnn
En donde:
POOL
nn
: Identificador fijo, para indicar POOL

: Nmero 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 CAS (Coordinator Address Space)
Nota: Se maneja de nuevo el pas para que el SYSIDNT lo contenga
: Nmero de particin correspondiente
Nota: El identificador del pas 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 CMAS (CICSPlex Manager Address Space)
Nota: Se maneja de nuevo el pas para que el SYSIDNT lo contenga
: Nmero de particin correspondiente (1 para VEN1, 2 para MEX2, etc.)
Nota: El identificador del pas aparece dos veces dentro de la nomenclatura definida para CMAS.
Ejemplos:
El CMAS de la particin 3 de Mxico es: CICMCMM3.
El CMAS de la particin 2 de Venezuela es: CICVCMV2.
9/33
Versin 2.0.3
Agosto 2012

Context y Scope del Cicsplex

Para entonos previos se definir uno para los entornos previos de desarrollo, test y formacin
con terminacin D y otro para calidad con terminacin C
Para produccin se definirn solo uno con terminacin P.
Nomenclatura:
CICpPLXe
En donde:
CIC
p
PLX
: Identificador fijo, para indicar el Cicsplex (conjunto de CICS) donde se realizarn
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 debern llevar en los 2 primeros caracteres la clave de la aplicacin asignada, por
Gestin de Cambios.
Nomenclatura:
aacc
En donde:
aa : Los 2 primeros caracteres de la aplicacin
NINGUNA TRANSACCION DE APLICACIN 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
tambin estn restringidos, estas son:
SOCKETS:
EZAC
EZAO
EZAP
EZKL
(todas las EZ*)
CICS:
MENU
CICSPLEX:
BMLT
LCPP
10/33
Versin 2.0.3
Agosto 2012

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
11/33
Versin 2.0.3
Agosto 2012

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
12/33
Versin 2.0.3
Agosto 2012

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 trmino 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 convencin para escribir la palabra
relacionada con el programa producto y es emplear la combinacin de maysculas y minsculas de la
siguiente manera: CICSPLex. De igual forma existe una convencin fontica para distinguir stos dos
homnimos.
En el ambiente de BBVA, la filosofa para las aplicaciones lnea es estar bajo Altamira y con DB2 ya
que as se obtienen los beneficios de alta disponibilidad, operacin continua, recuperacin ante
contingencias, flexibilidad y facilidad de crecimiento; as mismo se facilita la exportacin / importacin
de aplicaciones entre los bancos del grupo.
3.1.9 Consideraciones Tcnicas de CICS

La Arquitectura propuesta por IBM para este producto CICS, clasifica a los CICS de acuerdo a una
especialidad o funcin especfica para dar servicio. La Arquitectura CICS cuenta con 3 estratos principales,
sin embargo de acuerdo a las necesidades del Cliente y el Diseo de las Aplicaciones es posible
combinarlos entre s. La clasificacin ideal es que los CICS cuenten solamente con una de estas funciones:
Control de acceso y terminales:
TOR - Terminal Owning Regin. Regin de CICS administradora de terminales e
impresoras y ruteadora de transacciones a uno o ms AOR's.
Control de programas:
AOR - Application Owning Region. Regin de CICS en donde la aplicacin es
ejecutada.
Control de datos:
DOR - Data Owning Region. Regin de CICS que controla los recursos para el acceso
de los datos . (FOR,QOR)
Como repositorio de datos existen tambin dos componentes ms diferentes a CICS, stos son servidores de
CICS al proporcionarle el dato y no permitir que ste realice la bsqueda sino que realice nicamente su peticin
y recepcin una vez que el componente lo obtuvo para continuar con la ejecucin de la transaccin 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
informacin 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 aplicacin cuenta con
requerimientos especiales que no son estndar para las dems aplicaciones y es conocido como CICS
nativo, este realiza las 3 funciones es un TOR, AOR y FOR a la vez.
13/33
Versin 2.0.3
Agosto 2012

En conclusin el modelo ideal de la Infraestructura CICS es bajo la filosofa MRO, es decir, bajo la
configuracin por Capas: para el control de terminales o enlaces TCP/IP (TOR), regiones para la
ejecucin del cdigo de la aplicacin (AOR) y regiones para las TSQs compartidas y en su caso
archivos (QOR/ FOR).
Para contar con esta configuracin es necesario realizar lo siguiente:
Toda comunicacin entre CICS debe ser a travs de los TORES.

En el TOR se definirn 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 va 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 debern autoinstalar, sin
embargo, podrn existir definiciones para aquellos programas que sern utilizados para DPL.
Las colas que requieran ser ledas desde ms de una regin debern ser definidas como
remotas en el QOR, salvo aquellas colas de TS que slo se utilizan de lectura como la +SWA
que puede definirse de manera local en todos los AOR asegurndose que sta sea borrada
despus del cambio de sesin en todas las regiones.
De existir archivos estos debern definirse como remotos al FOR que tambin puede ser el
QOR.
En caso de contar con CICSPlex SM, ste se deber utilizar para hacer la distribucin y balanceo de
transacciones en el TOR hacia los AORs correspondientes, de otro modo las transacciones debern
ser definidas en el TOR como remotas hacia un AOR especfico.
Hay algunas transacciones que podrn definirse como locales en el TOR, este puede ser el caso de las
asociadas al MQ Series, o de las que servirn como copia de la CSMI para identificar un DPL entre
aplicaciones en diferentes CICS.
3.1.10
Relacin con RACF de los componentes de CICS
La seguridad de CICS es administrada va RACF, dentro de l bsicamente 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), tambin 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 regin 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
(categora 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
14/33
Versin 2.0.3
Agosto 2012

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 administracin 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 ejecucin de alguna transaccin debe estar asociada a un usuario, an y
cuando este se encuentre en la etapa de arranque o cuando un usuario final ejecute transacciones
sin firmarse an con su usuario propio. El CICS se firma con el DEFAULT USERID durante la
inicializacin 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 transaccin 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 conexin con CICSPlex, con
Omegamon, o con MQSeries, tambin 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 regin 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. Podrn 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 Lgica 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 transaccin CEDA, CEDB o CEDC a ningn usuario de Diseo y
Desarrollo ya que estas transacciones son exclusivas para la administracin de los recursos
definidos en CICS.
El rea de Middleware CICS/MQ de CCR no da accesos ni VoBo del uso de transacciones
aplicativas.
15/33
Versin 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 bsicamente 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 automticos (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 conexin 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 comunicacin va MQ Series, tambin los Queue Managers
son clasificados de acuerdo a la criticidad de las aplicaciones y con base a los CICS que les
ofrecern los servicios aplicativos.
Todas ests agrupaciones de CICS y de Queue Managers se realizan de acuerdo a las necesidades de cada
cliente, tratando de contar con un balanceo o distribucin de cargas adecuada al volumen de
transacciones a operar. El rea de Middleware CICS/MQ de CCR es quien decide en donde ubicar una
aplicacin.
3.1.12
Balanceo de Transacciones
Las aplicaciones debern ser desarrolladas sin afinidades, a efecto de habilitar su ejecucin en
uno o ms AORs con balanceo dinmico, evitando la dependencia de ejecutarlas en un AOR
especfico envindolas desde cualquier TOR.
Las aplicaciones que requieran hacer uso del nombre del CICS (applid, sysid) debern hacerlo
mediante el uso de variables o a travs del comando ASSIGN, siempre y cuando el nombre
de ste coincida con el nombre de la conexin del CICS en cuestin. Si es completamente
necesario el uso del nombre de estos parmetros 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 parmetros propios del producto CICS que permiten
contar con disponibilidad y competir por los recursos del equipo de acuerdo a la necesidad del entorno. A
continuacin describiremos brevemente el uso de ellos:
Desarrollo
Es empleado para la ejecucin de pruebas unitarias. Validacin de mapas, que no generen
abends, etc.
16/33
Versin 2.0.3
Agosto 2012

Test
Es empleado para la ejecucin de pruebas integrales informticas. DyD es quien realiza la
validacin de estas pruebas con una mayor casustica de pruebas. Es posible realizar pruebas de
volumen.
Calidad
Es empleado para la ejecucin de pruebas funcionales. Organizacin es quien realiza la validacin
de estas pruebas y con base en sus conocimientos del negocio realiza pruebas de otras
aplicaciones relacionadas con las modificaciones.
Formacin
Es empleado para realizar la capacitacin de los usuarios finales, o bien para la ejecucin de
pruebas de certificacin por su estabilidad.
Produccin
Es empleado para ofrecer los servicios en lnea a los usuarios finales y en horarios de servicio
convenidos donde debemos asegurar su disponibilidad.
NOTA: Mxico es excepcin 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 informacin de forma
aleatoria. Excepcionalmente y con la autorizacin 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 debern adecuarse y utilizar el Software de Programas Producto Corporativo.
Las aplicaciones debern desarrollarse en lenguaje Cobol/390 y bajo CICS Comandos.
Se recomienda ampliamente evitar la utilizacin de comandos que causen interrupciones al
Sistema Operativo.
Ejemplo: Accept, Display, etc.
No se debern hacer llamados de un programa CICS a una rutina Batch.
Las aplicaciones que requieran interactuar con otras aplicaciones debern utilizar como
primera opcin link de programas, en caso de no ser posible se deber emplear el mecanismo
de intercomunicacin aplicativa vigente.
En caso de que las aplicaciones requieran intercomunicarse entre s va LINK de programas y
residan en AORs independientes, debern 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 algn recurso y garantizar la integridad
de la informacin, no se debe usar el parmetro NOSUSPEND; y as mismo se deber emitir el
comando DEQ lo ms rpido posible, evitando retener el recurso por tiempo innecesario a fin
de aumentar la posibilidad de concurrencia de transacciones. De esta forma, la serializacin la
realizan el CICS o el Sistema Operativo (GRS), y por lo tanto, no se deben generar algoritmos
alternos.
Siempre verificar el cdigo de retorno de las sentencias CICS para evitar ABENDs en las
transacciones.
Las aplicaciones debern utilizar las rutinas comunes de Altamira para el manejo de Mensajes,
Pantallas, validacin de Seguridad, etc.
No est permitido hacer uso de SEND TEXT.
17/33
Versin 2.0.3
Agosto 2012

3.1.15
Productos o Herramientas empleadas en CICS
De acuerdo a los productos estndares dentro de CCR, los CICS pueden tener dentro de su configuracin
los siguientes productos, sin embargo ser necesario evaluar de acuerdo al entorno y al uso a darle si es
factible o no realizar su instalacin.
PRODUCTO
DESCRIPCIN
AF/OPERATOR
OPS
AUTOMATIZA FUNCIONES DE MONITOREO
CEE
LANGUAGE ENVIRONEMENT
CICS SOCKETS
COMUNICACIN 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
COMUNICACIN CON TCP/IP O SNA CON ENTIDADES EXTERNAS
OMEGAMON
MAINVIEW
MONITOR DE CICS
QA
HIPERSTATION
CAPTURA Y REPRODUCE TRANSACCIONES CON VOLUMEN
STROBE
FREEZEFRAME
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 cmputo 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, sern 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 ejecucin de una transaccin con el mismo nombre o diferente
nombre y puede ser en el mismo CICS o en diferente regin de CICS, por este ultimo motivo los datos
deben de ubicarse de manera compartida.
18/33
Versin 2.0.3
Agosto 2012

Para que un cola de temporary storage sea compartida es necesario ubicarla en un rea comn 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 informacin y al concluir su uso la borre. Con esto es posible generar la cola de manera local en la
misma regin 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 depuracin una vez que se haga uso de ella
o de manera posterior programando una depuracin peridica en lnea.
El tamao de una cola de TS debe ser el mnimo posible de acuerdo a la necesidad de la aplicacin 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 especficos se recomienda utilizar mejor la COMMAREA.
Cuando la informacin 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 debe
asegurarse de borrarla.
Si la cola TS solo va a ser leda exclusivamente, se puede existir una rplica 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 informacin 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 informacin y al concluir su uso la borre. Con esto es posible generar la cola de
manera local en la misma regin de CICS.
Las aplicaciones NO debern 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 pequeas. El nmero
mximo de registros aconsejable es dependiente de la disponibilidad de memoria y el nmero de
accesos a estas tablas. Se deber consultar con el grupo de soporte tcnico para conocer estas
limitantes.
En el caso de utilizar colas de TS para colocar tablas DB2 pequeas 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 trmino del proceso.
La comunicacin entre BATCH y el CICS se realizar mediante la interfase de CICS conocida como
EXCI. Algunos ejemplos de interaccin pueden ser para abrir o cerrar un archivo VSAM alojado por
el CICS y que necesita ser manipulado por el proceso batch o la ejecucin de alguna transaccin
en CICS.
No deber utilizarse el operador automtico para la ejecucin de transacciones, borrado de colas
de temporary storage, cierre y apertura de archivos, etc.
3.1.16.2
Caractersticas de las colas de Temporary Storage
Permanencia
19/33
Versin 2.0.3
Agosto 2012

El tiempo de permanencia de las colas TS debe ser mnima. Si la cola TS solo es utilizada durante
la ejecucin de una transaccin, sta debe borrarse antes de terminar la transaccin.
Si la cola TS va a ser utilizada por varias transacciones, la ltima en utilizarla debe borrarla.
Adems la aplicacin deber tener mecanismos de control para borrar la cola en el caso que el
ciclo quede interrumpido.
La aplicacin deber contar con un mecanismo propio que de manera peridica durante el da
borre las colas de TS que ya no tengan utilidad
Contenido
Las aplicaciones NO debern utilizar reas de memoria de manera indiscriminada, ya que el

recurso donde se alojan es memoria y es muy costosa.
Las colas TS NO deben ser utilizadas para guardar informacin de la cual haya dependencia
aplicativa, utilizar medios de almacenamiento permanentes para este tipo de informacin.
Las colas TS no deben contener TRACES ni utilizarse para depuracin o despliegue de flujo de
programas.
Tamao
La informacin manejada en colas TS no debe exceder de 20 Kb por cola TS de manera ideal para
colas que se generarn con gran frecuencia y con mucho volumen de transacciones. Es posible
que existan mximo 100 colas simultneamente por aplicacin (por ejemplo, colas que se generan
por cada transaccin o terminal).
El tamao mximo es de 150 Kb por cola TS en cualquier otro caso. Para un tamao mayor a 150
Kb se requiere justificacin y la aprobacin por parte de Infraestructura CICS.
Nomenclatura
El nombre de la cola TS no debe contener espacios ni caracteres no visibles en cualquier posicin.

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 aplicacin en host, para
facilitar su identificacin durante la operacin.
El nombre NO debe iniciar con caracteres especiales (/, @, #, etc.).
20/33
Versin 2.0.3
Agosto 2012

3.1.17
Definicin de recursos en CICS
Con base a la Arquitectura ideal de CICS la definicin de recursos en CICS debe realizarse considerando
los siguientes puntos que se listan a continuacin para los recursos ms utilizados comnmente.
Del recurso: transacciones se valida que su nombre conste de dos letras como prefijo que
correspondan a la clave de la aplicacin 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 aplicacin,
siempre y cuando el nombre del plan se encuentre en estndares 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 genrica con el prefijo de las transacciones. La definicin 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 debern llevar en los 2 primeros caracteres la clave de la aplicacin asignada, por
Gestin de Cambios.
Nomenclatura:
aacc
En donde:
aa : Los 2 primeros caracteres de la aplicacin
cc : Numrico consecutivo o caracteres mnemotcnicos de la transaccin
El nombre de la transaccin 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
Del recurso: programas Los CICS deben contar con el autoinstall de programas locales, si es as no
exclusivamente cuando sea necesario compartir datos en colas (queues) entre unidades de trabajo
diferentes (transacciones con el mismo nombre ejecutndose en momentos diferentes) y que se tenga
cuidado en su creacin, uso y depuracin una vez concluido su uso para no saturar los recursos de
CICS asignados a estas colas. Deben emplear nombres genricos que sirvan de prefijos para
transacciones de la misma aplicacin. Su definicin 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 informacin para realizar su definicin en los
CICS adecuados ya sea TORES y/o AORES.
es necesario realizar esta definicin de programas locales a menos que requieran una especificacin
diferente al default, dentro de este concepto de autoinstall tambin se encuentran las rutinas y los
mapas.
Del recurso: programas remotos son una excepcin del recurso anterior y es necesario validar la
necesidad de sta definicin ya que la arquitectura Altamira est diseada 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 definicin, si es as se sugiere que por
programacin se identifique con parmetro o variables el nombre de conexin 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 conexin o a la definicin en CICS. Adems de emplear el
21/33
Versin 2.0.3
Agosto 2012

parmetro transid para ejecutar una transaccin mirror y as identificar su paso por el otro CICS, esta
transaccin es necesario definirla local en el CICS donde se ejecutar el archivo como copia de la
transaccin 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 ubicacin 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 Lgica que el owner del CICS
tenga acceso por lo menos de update para el cluster del archivo. La utilizacin de archivos VSAM en
CICS est restringida, deber utilizarse DB2. Los archivos VSAM solo podrn definirse en CICS previa
validacin y autorizacin del rea CICS/MQ.MQSeries
MQSeries es utilizado como el estndar dentro del grupo BBVA como Middleware de comunicacin
asncrono (o sncrono, ya que es posible simularlo) entre aplicaciones internas y externas
multiplataforma, por lo que es indispensable establecer los estndares de nomenclatura y uso de
facilidades del producto para:
Agilizar los desarrollos
Facilitar la administracin y soporte
Minimizar los problemas en produccin
3.1.18
Polticas generales
Todos los desarrollos corporativos que sean implementados en Clientes de CCR con MQSeries en
cualquier ambiente, deben apegarse a los estndares de nomenclatura publicados en este documento.
Los servicios aplicativos propios de comunicacin 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 aplicacin proponer las caractersticas de los objetos a definir en
MQSeries.
Los lderes de los servicios aplicativos junto con Arquitectura Aplicativa CDR deben de asegurarse que
los mensajes empleados cuenten con parmetros adecuados de expiracin y persistencia de acuerdo a
la necesidad y funcionalidad de la aplicacin realizando una depuracin de ellos de manera peridica
cuando stos ya no sean tiles. Estos parmetros debern ser asignados dentro de los programas de
la aplicacin, por excepcin solo se podr habilitar la persistencia va infraestructura.
Es responsabilidad del rea Infraestructura Middleware CCR Mxico 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 convencin todos los nombres de los objetos a definirse en MQSeries deben ser en
MAYSCULAS.
Cada objeto debe llevar una descripcin detallada en el parmetro DESCR, para facilitar su
documentacin, administracin y soporte.
Por ningn motivo deber existir conexin entre equipos productivos contra algn entorno otro equipo
de entornos desarrollo y viceversa. Esta poltica es necesaria para evitar fraudes y/o riesgos de
22/33
Versin 2.0.3
Agosto 2012

impacto al servicio productivo. Si es permisible la conexin de equipos que compartan varios entornos
previos entre s.
Los desarrollos que darn servicio a los diferentes Clientes CCR podrn emplear la nomenclatura de
objetos de acuerdo a sus necesidades, el rea de Middleware CICS/MQ en CCR ser el que decida.
Pero bsicamente podrn ajustarse de la siguiente manera:
1)
2)
Locales
Aplicaciones que darn servicio exclusivamente a un cliente de CCR. Uno de los equipos
puede ser administrado por CCR y el otro puede ser administrado en el pas que ofrecer
servicio de esta aplicacin de manera local.
Corporativas
Aplicaciones que darn servicio a ms 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 estndares como los locales de cada cliente CCR
y/o los emitidos en Espaa. Sin embargo los desarrollos nuevos debern apegarse a ste estndar
CCR. Mientras que los objetos existentes sern respetados y de manera paulatina y en coordinacin
con el lder de la aplicacin sern migrados a este estndar.
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 debern contar un calificador adicional al final de los objetos de dos posiciones
que identifique al pas que dar servicio. Este calificador solo ser empleado en los objetos colas
relacionados a la aplicacin o servicio.
Los servicios distribuidos debern tener una nombre de 3 a mximo 5 posiciones que ser empleado en la
generacin e identificacin 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 aplicacin o servicio distribuido de acuerdo a sus necesidades, puede contar con un nmero finito de
colas ya sean locales o remotas; y con un nmero tambin finito de canales. Estos objetos sern
identificadas como el set bsico necesario para la funcionalidad de la aplicacin, 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 produccin. El entorno que establece la letra a emplear es el entorno de HOST, de manera
prioritaria.
Es posible que por algn proyecto especial tal como una migracin de la aplicacin de uno de los equipos
del servicio, reubicacin de equipos, habilitacin de cifrado de informacin, pruebas de volumen, entre
otros. Ser necesario replicar las definiciones de los mismos objetos del set bsico de una aplicacin 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 trmino del proyecto debern solo existir los objetos con la nomenclatura del set
bsico que le corresponda al entorno. La manera de identificarlos ser aadir al final de los objetos
requeridos un calificador nuevo de mximo 8 caracteres (si lo permite la longitud el objeto), que haga
referencia al proyecto.
23/33
Versin 2.0.3
Agosto 2012

Qmanagers
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 conexin con los equipos administrados por CCR.
Qmanagers en entorno Main frame, 4 caracteres:
Nomenclatura:
Mpec
Longitud : 4 posiciones
donde:
M
p
e
c
: Identificador fijo, para indicar Queue Manager

: Nmero consecutivo del subsistema: 1,2,...,9. A,B....Z empezando por el nmero uno (1)
Qmanagers 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 de 3 posiciones de la aplicacin o servicio distribuido
: Nmero consecutivo del subsistema: 1,2,...,9. A,B....Z empezando por el nmero 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 Comunicacin Sender Receiver
Los canales de envo y recepcin se deben llamar igual en los equipos a ser interconectados, y su nombre
debe estar compuesto por el de los QMGRS involucrados.
Nomenclatura:
CHt.qmorigen.qmdestino
24/33
Versin 2.0.3
Agosto 2012

Longitud : Mximo 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 enva la informacin
qmdestino: Identificador del queue manager que recibe la informacin
Canales Comunicacin Server Conection Client Conection
Nomenclatura:
CHC.aaaaa.SRVCONN
donde:
CHC
aaaaa
SRVCONN
: Identificador fijo, para indicar Channel Server Conection

: Identificador de 4 o 5 posiciones asignado al servicio
distribuido y/o aplicacin
: Identificador fijo, para indicar Channel Server Conection
Colas relacionadas al funcionamiento de los subsistemas Qmanagers

Cola de mensajes rechazados
Esta cola se emplea para que el subsistema ubique los mensajes rechazados en su envo y se define una
por Qmanager
Nomenclatura:
qmlocal.DEAD.QUEUE
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 Transmisin
Una cola de transmisin esta asociada nicamente a un canal que puede ser de tipo sender o server, y un
canal debe ser asociado tambin solo a una cola de transmisin.
25/33
Versin 2.0.3
Agosto 2012

Nomenclatura:
qmdestino.XMIT.QUEUE
donde:
qmdestino
XMIT
QUEUE
: Identificador de 4 a mximo 8 posiciones referente al

queue manager destino donde se enviarn los mensajes
Colas Iniciacin para entornos Main Frame

Permiten asociar un proceso con una accin 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 lnea dentro de un CICS.
Nomenclatura:
cic*.INIT.QUEUE
donde:
cic*
INIT
QUEUE
: Identificador de la STC de CICS donde iniciar la ejecucin de

una transaccin lnea, si se trata de una sola regin de CICS, cuando sean
varias regiones se utilizar el prefijo cic*0
Colas Iniciacin para entornos Unix, NT, Digital, Tandem, AS/400

Permiten asociar un proceso con una accin determinada a una cola local que es aquella que cumplir las
condiciones para que el proceso inicie.
Nomenclatura:
QIe.aaaaa.ejecuta
26/33
Versin 2.0.3
Agosto 2012

donde:
Q
I
e
aaaaa
ejecuta
: Identificador
: Identificador
: Identificador
: Identificador
: Identificador
fijo, para indicar cola

fijo, para indicar tipo de cola, en este caso iniciacin
del entorno (ver Tabla 6: Tabla de entornos)
asignado al servicio distribuido y/o aplicacin
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 aplicacin.
Estos objetos tendrn 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 envo, o por donde llega la peticin del servicio o
aplicacin para ser atendida.
RESP, ser empleado en el objeto que hace envo, o por donde llega la contestacin para el
servicio o aplicacin una vez que ha sido atendida.
Por lo general los servicios bajo MQSeries requieren un par de colas, que pueden tipificarse con la
descripcin anterior de ENVIO y RESPuesta; sin embargo pueden existir aplicaciones o servicios que
requieran colas adicionales ya sea por par o individuales para estas tambin aplicarn estas constantes y
su identificacin variando el sufijo del calificador de la aplicacin mencionado de 4 o 5 posiciones.
Actualmente se emplean con ms 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 emplearn sesin aplicativa
Colas Locales
Nomenclatura:
QLe.aaa*.flujo.pp
donde:
Q
L
e
aaa*
: Identificador fijo, para indicar cola

: Identificador fijo, para indicar tipo de cola, en este caso local
: Identificador asignado al servicio distribuido y/o aplicacin
el asterisco * implica un sufijo para identificar los servicios,
actualmente se emplea:
27/33
Versin 2.0.3
Agosto 2012

flujo
pp

: Identificador fijo ENVIO o RESP, para indicar flujo del mensaje dentro
del contexto de la aplicacin o servicio distribuido.
: Solo aplica para aplicaciones corporativas.
Identificador del pas a quien dar servicio la aplicacin
(ver Tabla 2: Claves de pases con dos )
Colas Remotas
Nomenclatura:
QRe.aaa*.flujo.qmdestino.pp
donde:
Q
R
e
aaa*
: Identificador fijo, para indicar cola

: Identificador fijo, para indicar tipo de cola, en este caso remota
flujo
: Identificador fijo ENVIO o RESP, para indicar flujo del mensaje dentro
del contexto de la aplicacin o servicio distribuido.
qmdestino : Identificador del queue manager que recibir la informacin
pp
Procesos
Indican la accin 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 lnea dentro de un
CICS.
Nomenclatura:
PRe.aaa*.tranid.cics.pp
28/33
Versin 2.0.3
Agosto 2012

donde:
PR
e
aaa*
tranid
cics
pp
: Identificador fijo, para indicar proceso

: Identificador del nombre de la transaccin lnea a ser ejecutada
: Identificador de la stsrated task de CICS donde ejecutar la
transaccin
Procesos para entornos Unix, NT, Digital, Tandem, AS/400

Nomenclatura:
PRe.aaa*.ejecuta.pp
donde:
PR
e
aaa*
ejecuta
pp
: Identificador fijo, para indicar proceso

: Identificador del programa ejecutable o proceso a iniciar
29/33
Versin 2.0.3
Agosto 2012

4 Tablas de CICS.
4.1.1 Tabla de Identificador para regiones de CICS
Tipo de CICS
TOR
QOR
FOR
Aplicacin
Terminales
Colas TS
Archivos
Clave
T
Q
F
AOR
Altamira
NATIVO
AOR
AFP
FALCON
P
F
AOR
AOR
Medios de Pago
Canales
M
C
Tabla 1: Identificador para regiones de CIC
30/33
Versin 2.0.3
Agosto 2012

5 Anexos
5.1 Tablas Generales.
Aqu se muestran las tablas de uso comn, como son las tablas de pases, negocios, etc.
5.1.1 Tabla de pases cuando se utilizan dos caracteres

Pas
Clave
Argentina
Brasil
Bolivia
AR
BR
BO
Chile
Colombia
Ecuador
El Salvador
CL
CO
EC
SV
Mxico
Panam
Per
Puerto Rico
Rep. Dominicana
Venezuela
Latinoamrica
MX
PN
PE
PR
DO
VE
LT
Estados Unidos de
Norteamrica
US
Conversin Mxico
YY
Conversin Chile
XX
Neutro
ZZ
Tabla 2: Claves de pases con dos caracteres
31/33
Versin 2.0.3
Agosto 2012

5.1.2 Tabla de pases cuando se utiliza un caractr

Tomando como base la tabla de pases de dos caracteres se utiliza el primer caractr o el siguiente
disponible en caso de ya haber sido utilizado.
Pas
Clave
Argentina
Brasil
Bolivia
Chile
A
B
O
L
Colombia
Ecuador
C
E
El Salvador
Mxico
Panam
Per
Puerto Rico
M
N
P
R
Rep. Dominicana
Venezuela
Latinoamrica
D
V
T
Estados Unidos de
Norteamrica
Conversin Mxico
Conversin Chile
Neutro
Y
X
Tabla 3: Claves de pases con un solo caractr
5.1.3 Tabla de negocios de dos caracteres

Negocios
Fondos y Pensiones
Clave
FP
Banco
Casa de Bolsa
BO
CB
Centro de Desarrollo Regional

Multiempresas
Seguros
DR
ME
SO
Fianzas
FI
Tabla 4: Tabla de negocios con dos caracteres
32/33
Versin 2.0.3
Agosto 2012

5.1.4 Tabla de negocios cuando se utiliza un carcter

Tomando como base la tabla de negocios de dos caracteres se utiliza el primer carcter o el siguiente
disponible en caso de ya haber sido utilizado
Negocios
Clave
Fondos y Pensiones
Banco
Casa de Bolsa
F
B
C
Centro de Desarrollo Regional
Multiempresas
Seguros
Fianzas
M
S
I
Tabla 5: Tabla de negocios con un slo carcter
5.1.5 Tabla de entornos

Entornos
DESARROLLO
Clave
D
TEST
CALIDAD
T
C
FORMACIN
PRODUCCION
LABORATORIO
BRS
PREPRODUCCION
F
P
L
B
Q
ASTA
PRUEBAS STAND IN
(ENTORNOS
PREVIOS)
Tabla 6: Tabla de entornos
33/33
Versin 2.0.3
Agosto 2012

Estandares CICS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estandares CICS

Uploaded by

Copyright:

Available Formats

Estndares Para El Procesamiento

Servicios de Procesamiento Amrica (SPA)

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

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

Estndares de nomenclatura de CICS .................................................................................................. 6

Started Task de CICS ............................................................................................................... 6

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

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

1.2 Objetivos de los estndares

1.3 Acerca de este documento

1.4 A quin est dirigido este documento

1.5 Cmo enviar sus comentarios

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

1.6 Registro y Control de Cambios al Documento

Actualizacin al 100% de Estndares y facilidades para CICS

Se actualiza nomenclatura de Cola de iniciacin y orden de detalle

Registro y Control de Cambios al Documento

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

Ej. Dpe<nmero / letra / G>

Este documento utiliza algunos tipos especiales de texto como:

Referencias: Referencias a otras secciones en este documento o informacin relacionada.

2.1 Contenido no incluido

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

3 Estndares de nomenclatura de CICS

: Identificador fijo, para indicar CICS

3.1.2 Owner y usuario de default de un CICS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

3.1.3 Usuario de la tabla PLTPI de un CICS

: Identificador fijo, para indicar que es un usuario relacionado con CICS

3.1.4 Otros usuarios relacionados con recursos de CICS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

: Identificador de la tabla o recurso de CICS al que se le asignar el usuario,

3.1.5 Temporary Storage en CF (Coupling Facility)

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

: Identificador fijo, para indicar POOL

: Identificador fijo, para indicar CICS

: Identificador fijo, para indicar CICS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

Context y Scope del Cicsplex

(todas las EZ*)

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

(todas las XSP*)

BridgeMQ (para uso de Arquitectura):

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

3.1.8 Componentes dentro de un CICSPLEX

3.1.9 Consideraciones Tcnicas de CICS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

Toda comunicacin entre CICS debe ser a travs de los TORES.

Relacin con RACF de los componentes de CICS

La seguridad de CICS es administrada va RACF, dentro de l bsicamente se encuentran definidos 3

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

Lineamientos Generales de uso

ESTNDARES PARA EL PROCESAMIENTO CENTRAL DE DATOS

Productos o Herramientas empleadas en CICS

AUTOMATIZA FUNCIONES DE MONITOREO

COMUNICACIN CON TCP/IP CON ENTIDADES EXTERNAS

INTERFACE PARA EL SCHEDULER PROCESOS BATCH

BASE DE DATOS RELACIONAL

COMUNICACIN CON TCP/IP O SNA CON ENTIDADES EXTERNAS

CAPTURA Y REPRODUCE TRANSACCIONES CON VOLUMEN

MIDE EL CONSUMO DE RECURSOS DURANTE LA EJECUCION DE TRANS