ARQUITECTURA ALTAMIRA V-4.

3
MANUAL DE USUARIO
___________________________________________________________________________________________________

INDICE
__________________________________________________________________________________________________
_
Pg. 1

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

CAPITULO I : INTRODUCCION

I.1. DEFINICION Y OBJETIVOS DEL SISTEMA.

I.2. DEFINICION DE CONCEPTOS BASICOS.

I.3. ESQUEMA DE MODULOS DIRECTORES DE ARQUITECTURA.

CAPITULO II : COMUNICACION DE APLICACIONES CON ARQUITECTURA

10

II.1. REA DE COMUNICACION CON LA ARQUITECTURA (CAA).

II.1.1. DATOS GENERALES.
II.1.2. DATOS DEL MENSAJE.
II.1.3. AUTORIZACIONES.
II.1.4. DATOS CONVERSACION ENTRADA/SALIDA.
II.1.5. DATOS DE SIGUIENTE TRANSACCION.
II.1.6. DATOS DEL MENSAJE DE SALIDA.
II.1.7. DATOS PARA GESTION DE PAGINACION.
II.1.8. DATOS PARA ANALITICA Y ESTADISTICAS.
II.1.9. DATOS DE ERROR INESPERADO.

10
11
12
13
13
14
16
18
19
20

II.2. ESQUEMA DE UNA CONVERSACION.

II.2.1 COMIENZO DE UNA CONVERSACION.
II.2.2. SELECCION DE UNA OPCION DEL MENU.
II.2.3. REALIZACION DE UNA CONSULTA.
II.2.4. REALIZACION DE UNA BAJA.
II.2.5. ACCESO A OTRO PANEL DESDE EL DE CONSULTA/BAJA.
II.2.6. VUELTA A LA TRANSACCION DE CONSULTA/BAJA.
II.2.7. ACCESO AL MENU DESDE CUALQUIER PUNTO DE LA CONVERSACION.

21
24
25
26
28
29
30
33

II.3. PARAMETRIZACION.
II.3.1. PARAMETRIZACION DE LA ARQUITECTURA.
II.3.2. PARAMETRIZACION DE UNA APLICACION.

34
34
36

II.4. FUNCIONAMIENTO DE LA PAGINACION.

37

II.5. SALIDAS NO ESTANDAR.

II.5.1. SALIDA NO ESTANDAR SIN FORMATO ASOCIADO.
II.5.2. SALIDA NO ESTANDAR CON FORMATO ASOCIADO.
II.5.3. IMPRESION DESDE TERMINALES 3270.
II.5.4. EJEMPLOS.

41
43
44
45
46

II.6. ACTUALIZACION DE JOURNAL Y TOTALES.

50

II.7 FUNCIONAMIENTO DE LAS AUTORIZACIONES.

II.7.1. AUTORIZACIONES DESDE EL PUNTO DE VISTA DEL TERMINALISTA.
II.7.2. AUTORIZACIONES DESDE EL PUNTO DE VISTA DE LOS PROGRAMAS DE APLICACION.
II.7.3. AUTORIZACIONES DESDE EL PUNTO DE VISTA DE LOS PROGRAMAS ALTAMIRA.
II.7.4. AUTORIZACION EN CONVERSACIONES.

52
53
58
63
66

II.8. FUNCIONAMIENTO DE LA AYUDA ON-LINE.

66

II.9. FUNCIONAMIENTO DE LA AYUDA ACTIVA.

67

II.10.UTILIZACION DEL TELEDISCO.

II.10.1. CARGA DE LA TABLA DE INFORMACION DE TELEDISCO EN EL BATCH.
II.10.2. PROCESO ON-LINE DEL TELEDISCO.

68
70
71

__________________________________________________________________________________________________
_
Pg. 2

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.10.3. DESCARGA Y EXPLOTACION DE INFORMACION DEL TELEDISCO.

II.10.4. ESTRUCTURA DEL FICHERO DE ENTRADA PARA LA CARGA DE TELEDISCOS.

72
73

II.11. LOG DEL SISTEMA. IMPRESORAS DE SEGUIMIENTO.

75

II.12. SUSPENDER / REANUDAR UNA CONVERSACION.

76

II.13. EDICION DE CAMPOS NUMERICOS EN TERMINALES 3270.

77

II.14. CONTROL DE TECLAS DE FUNCION.

81

II.15. LISTADO DINAMICO DE TABLAS.

83

II.16. CAMBIO DE SESION.

II.16.1. CAMBIO DE SESION DE ARQUITECTURA.

87
90

II.17. ESQUEMA Y RECURSOS DE SEGURIDAD.

II.17.1. SEGURIDAD EXTERNA PARA LA VERSION EXTENDIDA.
II.17.2. SEGURIDAD INTERNA PARA LA VERSION EXTENDIDA.
II.17.3. SEGURIDAD (EXTERNA O INTERNA) PARA LA VERSION ESTANDAR.

93
94
96
98

__________________________________________________________________________________________________
_
Pg. 3

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

CAPITULO I : INTRODUCCION
I.1. DEFINICION Y OBJETIVOS DEL SISTEMA.
La Arquitectura de aplicaciones es un sistema netamente on-line, cuya misin es bsicamente
centralizar la actividad del teleproceso de la Entidad, cubriendo funciones tales como:
Simplificar diseos y desarrollos de otras aplicaciones on-line.
Independizar a las aplicaciones del tipo de terminal con el que est interactuando. Tratamiento de
mensajes especficos (formatos) de cada tipo de terminal.
Gestionar los preformatos de pantalla y documento con destino terminal no inteligente o con
software no actualizado.
Mantener un log del sistema y gestionar el tratamiento de errores producidos en los programas de
aplicacin.
Centralizar la gestin de la informacin de:
Journal contable en divisas.
Tecleos del sistema.
Totales de oficina.
Fechas contables actual y prxima.
Entornos de trabajo parametrizados para la entidad.
Posibilitar el desarrollo de la conversacin.
Tratamiento y control de telediscos.
Gestin de la autorizacin de operaciones.
Informacin en pantalla o documento en distintos idiomas.
Integracin con aplicaciones Estndares.
Adicionalmente a estas funcionalidades cubiertas por la Arquitectura central, existen una serie de
utilidades batch cuya misin es facilitar el desarrollo de aplicaciones.

I.2. DEFINICION DE CONCEPTOS BASICOS.

A continuacin se definen los conceptos bsicos manejados en el presente manual en relacin a la
Arquitectura, de forma que permitan una ms fcil comprensin del mismo. Para mayor nivel de detalle
y funcionamiento interno, consultar los manuales funcional y tcnico el sistema.
DIALOGO CONVERSACIONAL: Es un conjunto de pantallas enlazadas entre s de forma que
el terminalista tiene la oportunidad de actuar sobre cualquiera de las respuestas que recibe, a
diferencia del dilogo transaccional, caracterizado por una nica peticin del terminalista seguida
por una respuesta del Host sobre la cual no puede actuar el terminalista.
REA DE COMUNICACION CON LA ARQUITECTURA: Denominada CAA (Commarea
de Arquitectura de Aplicaciones), es el rea bsica mediante la cual se comunican las aplicaciones
con la Arquitectura transmitindose recprocamente informacin y peticiones.
MENSAJE: Es el bloque de informacin que viaja entre los terminales y el Host a travs de las
lneas telefnicas siendo la Arquitectura la encargada de decodificarlo en entrada y codificarlo en
salida. Cada tipo de terminal tiene uno o varios formatos de mensaje diferentes.
En entrada, la Arquitectura lo presenta a las aplicaciones en un formato estndar (formato tipo
BMS) de forma que a stas les es transparente el tipo de terminal con el que estn interactuando.
Para terminales 3270 la Arquitectura permite trabajar con BMS de entrada en distintos idiomas,
segn se haya prefijado el terminal.
__________________________________________________________________________________________________
_
Pg. 4

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

En salida, la Arquitectura ha de codificar de nuevo el mensaje en funcin de qu tipo de terminal es

el destinatario, evitando el transmitir campos innecesarios por no haber sido modificados, lneas en
blanco, espacios repetidos, etc.
FORMATO: Se denomina formato al conjunto de caractersticas de cada uno de los mensajes que
viajan entre el Host y los dispositivos locales en oficinas (terminal, impresora, dispensador, etc).
Las caractersticas son: campos asociados, preformatos a utilizar, validaciones a realizar, etc.
Cada transaccin puede tener asociado un formato de:
Pantalla de entrada. El que completa el terminalista. Es el formato asociado al mensaje de
entrada.
Pantalla de salida. El que le llega de vuelta al terminalista. Puede ser el mismo que el de
entrada y normalmente lo ser en una conversacin. Es el formato asociado al mensaje de
salida a pantalla.
Un formato por cada tipo de documento de salida producido. Es el formato asociado a cada
uno de los mensajes de salida a impresora.
PREFORMATO: Contiene la parte fija (literales fijos) de un mensaje. Se trabajar con los
literales en el idioma que se haya prefijado para el terminal o el elegido en la aplicacin.
De esta forma, la Arquitectura guardar la informacin completa de un mensaje en dos niveles:
o la informacin de la parte variable del mensaje queda recogida en el formato asociado al
mensaje.
o la informacin de la parte de literales del mensaje (parte fija) queda recogida en el
prefrmalo.
ERRORES Y AVISOS: Son dos tipos de mensajes a pantalla que informan al terminalista sobre
algn tipo de incidencia que se haya producido durante el proceso.
Los avisos son mensajes puramente informativos sobre el proceso, mientras que los errores indican
algn problema que ha impedido que el proceso se desarrolle con normalidad.
Estos tipos de mensajes son susceptibles de mostrar la informacin en el idioma de trabajo del
terminal, as como mostrar partes variables dentro del mensaje de aviso o error, en un idioma fijo o
en el idioma del terminal.
TOTALES: Son conceptos que se utilizan contablemente a nivel de terminal para sumarizar y
cuadrar el debe y el haber dentro y fuera de caja, tanto por terminal como por usuario.
La informacin que contienen es un bloque de datos para cada terminal, tipo de total y divisa de la
operacin, as como el usuario que la ha realizado.
JOURNAL: Centralizado en la Arquitectura, es el diario de los movimientos contables en cada
divisa que se producen en la entidad. Opcionalmente puede ser utilizado por las aplicaciones para
generar informacin con destino a Contabilidad General.
TECLEOS: Conjunto de operaciones que se efectan desde los terminales y telediscos, donde
quedan registradas todas las caractersticas de cada transaccin que se ejecuta a travs de la
Arquitectura (terminal, transaccin, fecha y hora, datos de la operacin, etc.).
TELEDISCO: Proceso mediante el cual se ejecutan automticamente a travs del Teleproceso un
conjunto de transacciones originadas por una aplicacin batch.
CAMBIO DE SESIN: Proceso que se produce al cierre del da contable, y en el que:
o Se cambia la fecha contable del da y se obtiene la siguiente.
o Se inicializan las tablas para la siguiente sesin del on-line.
o Se hace el proceso flip-flop de las tablas que tienen varias versiones.
o Se cambia el estado de las aplicaciones que as lo deseen.
__________________________________________________________________________________________________
_
Pg. 5

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

PROCESO DE AUTORIZACIN: Permite realizar una serie de operaciones especiales previa

identificacin de un usuario que las "autorice" y que quedar registrado como sujeto responsable
de dicha operacin.
La autorizacin en s se realizar en el programa de aplicacin en combinacin con recursos de
seguridad (interna o externa).
COMPATIBILIDAD CON APLICACIONES ESTNDARES: La Arquitectura Extendida
permitir ejecutar aplicaciones Estndares mediante un mdulo que convierte la commarea y los
mensajes de entrada y salida de la Arquitectura Extendida al formato manejado por los programas
de aplicacin Estndares (y viceversa), de manera que dichas aplicaciones se puedan incorporar a
esta Arquitectura sin excesiva dificultad.

ESQUEMA DE SEGURIDAD: Proteccin de los diferentes recursos manejados por la

Arquitectura, desde el acceso a las aplicaciones, transacciones, etc., a la posibilidad de realizar
diferentes tipos de operaciones segn el nivel de autorizacin que tenga el usuario que las efecte.
La Arquitectura proporciona un esquema de seguridad mediante tablas internas, aunque se
recomienda dejar delegada esta gestin al RACF (seguridad externa).

I.3. ESQUEMA DE MODULOS DIRECTORES DE ARQUITECTURA.

A continuacin se presentan los dos mdulos principales de la Arquitectura que son los denominados
Mdulos Directores de Entrada (todas las transacciones tienen que tener asociado este programa en su
definicin al CICS) y de Salida.
Las funciones cubiertas por estos dos mdulos son, en trminos generales, las siguientes:
Llevar el control del dilogo entre programas de aplicacin y el terminal.
El flujo de las conversaciones parte siempre del terminal, que arranca una transaccin CICS en
modo pseudoconversacional, cediendo control al Director de Entrada. Este invoca a los
programas de aplicacin (uno o varios) y finalmente al Director de Salida, el cual enva un
mensaje de respuesta al terminal y finaliza, liberando recursos.
El terminal, eventualmente, devuelve al host un mensaje de entrada, repitindose el proceso
anterior.
Cuando se produce un cambio de plan el Director de Entrada efecta un START TRANSID de
la nueva transaccin, que comienza arrancando de nuevo el Director de Entrada (switch de
plan). En este caso el Director de Salida nicamente devuelve al terminal un mensaje
indicativo del switch. El terminal consecuentemente esperar el nuevo mensaje que le enviar la
transaccin arrancada.
Realizar la operativa comn a todas las transacciones.
Formatear y reformatear los mensajes de salida y entrada (respectivamente) en funcin del
tipo de terminal con el que dialoga.
Ceder control a los programas de aplicacin, pasndoles datos de contexto.
Como funciones principales del Director de Entrada (QC1CENT), podemos destacar:
Acceso optimizado y centralizado a las tablas de la Arquitectura.
__________________________________________________________________________________________________
_
Pg. 6

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Cara a optimizar el acceso a sus tablas, soportadas bajo DB2, la Arquitectura mantiene en
memoria una copia de la informacin principal de cada una de las tablas ms accedidas.
Estas copias son cargadas desde la tabla la primera vez que son requeridas por el sistema en
una sesin, permitindose "refrescarlas" a travs del mantenimiento de tablas de la
Arquitectura.
Captura de informacin para la tabla de actividad del sistema (tabla de tecleos).
Identificacin del terminal que da origen a la transaccin:
o
o
o

PS/2 (LU 0)
3270 (LU 2)
Medios de Pago Electrnicos

o
o
o

4700
5935
Teledisco

Recepcin y anlisis del mensaje:

o Mensaje de teledisco o autorizacin.
o Formato de PS/2 (LU 0).
o Mensaje de los distintos protocolos de medios de pago electrnicos.
o Formato 4700.
o Formato 5935.
o Entrada libre.
o Formato 3270 (LU 2).
Cesin del control a mdulos de deformateo del mensaje, convirtindolo en un formato
nico estndar.
Verificacin de la informacin de entrada, presentndola en el idioma asignado al
terminal.
Formateo del rea de comunicacin con las aplicaciones.
Gestin de las ayudas de transaccin y de campo de pantalla.
Gestin de la paginacin en el caso de pantallas de scroll.
Cesin del control al programa de aplicacin, controlando opcionalmente las teclas de
funcin.
Gestin del proceso de teclas estndares.
Gestin de la conversacin.
Como funciones principales del Director de Salida (QC1CSAL), destacaremos:
Formateo del mensaje en formato BMS proporcionado por la aplicacin al esperado por el
terminal de destino.
Tratamiento de telediscos, si stos estn habilitados.
Tratamiento de salidas a dispensador, diario local, banda magntica e impresora normal y
de libreta.
__________________________________________________________________________________________________
_
Pg. 7

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Tratamiento de preformatos, envo de pantalla o documento completo (incluyendo literales

fijos) cuando el terminal destino no sea inteligente o no est preparado para ello.
Ahorro de envo de caracteres por lnea: campos que no cambian, lneas en blanco,
caracteres repetidos, etc.
Tratamiento de errores y mensajes detectados por la aplicacin.
Grabacin de la informacin de la transaccin en la tabla de auditora (tecleos) del
sistema.
Grabacin del journal contable en formato multi-divisa.
Grabacin de totales contables por terminal (y por usuario, si est habilitado).
Cesin del control al terminal o a otros programas de aplicacin.
Grabacin de la informacin de autorizaciones.
Envo de mensajes al terminal, segn el protocolo establecido para dicho terminal.

__________________________________________________________________________________________________
_
Pg. 8

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

CAPITULO II : COMUNICACION DE APLICACIONES CON

ARQUITECTURA
II.1. REA DE COMUNICACION CON LA ARQUITECTURA (CAA).
El rea de comunicacin con la Arquitectura (CAA) es utilizada para el dilogo entre los programas de
aplicacin y la Arquitectura.
Mediante esta commarea, la Arquitectura informa a las aplicaciones de los parmetros del sistema
necesarios para el desarrollo de sus procesos on-line.
Los programas de aplicacin, por su parte, utilizan la commarea para realizar peticiones de salida de
mensajes (tanto a pantalla como a documento), e informan del resultado de los procesos realizados.
El contenido de la CAA se divide en informacin de entrada, de salida y de entrada/salida de la
aplicacin.
La informacin de entrada a la aplicacin consta de los siguientes segmentos:
DATOS GENERALES: Es el conjunto de informacin general del sistema que la Arquitectura
proporciona como entrada al programa de aplicacin.
DATOS DEL MENSAJE: Contenido y conjunto de caractersticas del mensaje de entrada a la
aplicacin.
La informacin de entrada/salida consta de:
AUTORIZACIONES: Informacin sobre el proceso de autorizaciones.
DATOS DE CONVERSACION: Utilizados para el desarrollo de una conversacin. En la
entrada contienen la informacin de la transaccin en curso, y en la salida debern contener la
informacin de la siguiente transaccin.
La informacin de salida de la aplicacin consta de los siguientes segmentos:
DATOS DE SIGUIENTE TRANSACCION: Donde la aplicacin indica cul es la siguiente
transaccin que debe entrar en la conversacin.
DATOS DEL MENSAJE: Informacin y contenido de los distintos mensajes de salida.
DATOS PARA GESTION DE PAGINACION: Informacin para la gestin de paginacin
(slo para transacciones de listado).
DATOS PARA ANALITICA Y ESTADISTICAS: Informacin sobre las caractersticas del
proceso, que servirn como entrada para alguna aplicacin de contabilidad analtica o para
actualizacin de las estadsticas gestionadas por la misma Arquitectura.
DATOS ERROR INESPERADO: Informacin sobre un posible error CICS o DB2
inesperado.
A continuacin se explicar con detalle el contenido de cada campo de la CAA.

__________________________________________________________________________________________________
_
Pg. 9

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.1.1. DATOS GENERALES.

Los programas de aplicacin podrn utilizar los campos de este segmento para recoger cualquier
informacin general del sistema y en ningn caso podrn modificar su contenido.
Los campos de que consta son:
ENTIDAD: Cdigo de la entidad contable y del terminal que realiza la operacin.
CENTRO-CONT: Cdigo de oficina contable del terminal que realiza la operacin.
NETNAME-CONT: El Netname es un cdigo nico para una red, mientras que el cdigo de
terminal puede, para un mismo terminal fsico, ser diferente para cada CICS en el que trabaje
(MRO).
TERMINAL-CONT: Cdigo del terminal contable que realiza la operacin.
FECHA-CONT: Fecha contable asociada a la operacin en formato AAAAMMDD.
FECHA-CONT2: Fecha contable asociada a la operacin en formato AAAA-MM-DD.
FECHA-CONTED: Fecha contable asociada a la operacin en el formato DD/MM/AAAA.
FECHA-OPER: Fecha de operacin. Ser la fecha de operacin del proceso, a menos que el
terminal tenga asociada una fecha de operacin distinta, en cuyo caso ser sta la que figure. El
formato es AAAAMMDD.
FECHA-OPER2: Fecha de operacin en formato AAAA-MM-DD.
FECHA-OPERED: Fecha de operacin en formato DD/MM/AAAA.
FECHA-TRANS: Fecha de transmisin. Es la fecha natural en que se realiza el proceso, en
formato AAAAMMDD.
FECHA-TRANS2: Fecha de transmisin en formato AAAA-MM-DD.
FECHA-TRANSED: Fecha de transmisin en formato DD/MM/AAAA.
HORA-TRANS: Hora de transmisin. Es la hora en que se realiza el proceso en formato
HHMMSS.
HORA-TRANSED: Hora de transmisin anterior en formato HH:MM:SS.
NETNAME: Cdigo del terminal en red fsico que realiza la operacin.
TERMINAL: Cdigo del terminal que realiza la operacin. Coincide con el EIBTRMID de
CICS.
USERID: Usuario identificado en CICS.
SESION: Indicador de sesin de maana ('M') o tarde ('T').
TIPO-TERM: Tipo de terminal que realiza la operacin. Los tipos de terminal vlidos son:
'11': tipo 4700
'12': tipo 5935
'13': tipo PS/2 Estndar
'14': tipo PS/2 Tajo
'15': tipo PS/2 ICO
'16': tipo VIDEOTEX
'17': tipo PS/2 BCT
'18': tipo PS/2 CEC
'19': tipo PS/2 FFS (Foundation)
'20': pantalla 3270
'28': PS/2 en emulacin (tipo 3270)
'29': 4700 en emulacin (tipo 3270)
'51': impresoras
y otros numerosos (a partir del tipo '40' para la aplicacin de Centro Autorizador (CECA,
SEMP, 4B, ATMs y TPVs).

CICS: Identificador de la sesin CICS (SYSID).

__________________________________________________________________________________________________
_
Pg. 10

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

CODTRAN: Cdigo de transaccin que se ejecuta segn la Arquitectura. No tiene por qu

coincidir con la EIBTRNID de CICS, pues en una misma tarea CICS, la Arquitectura puede
ejecutar dos programas asociados a distintas transacciones: para el CICS se estara ejecutando
siempre la misma transaccin, y sin embargo para la Arquitectura se estara ejecutando en cada
momento la transaccin asociada a cada uno de los programas (dos distintas).
TIPO-PROCESO: Tipo de proceso que se est ejecutando. Puede ser:
'O': on-line
'A': autorizacin
'T': teledisco
'F': off-line

ESTADO-APLIC: Estado en que se encuentra la aplicacin a que pertenece la transaccin para

la Entidad del terminal. Puede ser:
'A': Activa
'D': Desactiva
'C': En cambio de sesin
'R': En recuperacin (no utilizado en la actualidad).

IDIOMA-TERM: Cdigo del idioma de trabajo del terminal. Toda la informacin de salida de
pantallas y documentos se gestiona a travs de idioma asignado a cada terminal.

II.1.2. DATOS DEL MENSAJE.

Contiene toda la informacin necesaria sobre el mensaje de entrada en los campos:
TECLA: Cdigo de la tecla pulsada. Este cdigo es:
'00': Intro
'01',...,'10','11','12': PF1,...,PF10,PF11,PF12
'11',...,'20','21','22': ShftF1,....,ShftF10
'21',...,'30': CtrlF1,....,CtrlF10
'99': Borra (CLEAR) o cualquier otra tecla que no sea una de las anteriores

CAJERO: Cdigo de cajero pulsado, que ser:

'A': si se ha pulsado la tecla de cajero A en un terminal 4700 o en 5935, o bien Intro o
PF8 en otro tipo de terminal.
'B': si se ha pulsado la tecla de cajero B en un terminal 4700 o en 5935, o bien PF5 en
otro tipo de terminal.

MOD-TAG: Indicador de si se han modificado datos en la pantalla ('S') o se ha pulsado una

tecla de funcin sin modificar datos ('N'). Este concepto es, por tanto, relevante para procesos
conversacionales.

PTR-COPYIN: Direccin de memoria donde se encuentra el mensaje de entrada en formato

BMS. Este rea se utiliza tanto como pantalla de entrada como de salida, es decir, los programas
de aplicacin encontrarn en este rea la informacin de la pantalla de entrada, y debern
modificar los campos pertinentes para construir la nueva pantalla de salida.

II.1.3. AUTORIZACIONES.
__________________________________________________________________________________________________
_
Pg. 11

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

En este segmento se recoge la informacin sobre el proceso de autorizaciones. Los programas de

aplicacin reconocen en este segmento las operaciones que ya han sido autorizadas por el terminalista
para no volver a producir una solicitud de autorizacin por el mismo motivo (Ver documento
II.7.Funcionamiento de las Autorizaciones). Asimismo, en este segmento se recogen los campos que
debe informar un programa de aplicacin cuando necesita una autorizacin.
Este bloque consta en primer lugar de 10 ocurrencias (una por cada uno de los "motivos" por los que se
necesita autorizar). Estos campos vendrn sin informar la primera vez que se realice la operacin, y
tendrn que ser informados con los valores correspondientes de cdigo de error y situacin cuando se
pida la autorizacin. Cuando el terminalista realice la autorizacin, estos campos llegarn al programa
de aplicacin con los valores que se informaron cuando se pidi dicha autorizacin. Estos campos son:
CODERR-AUT: Cdigo de error identificativo del motivo de la autorizacin.
SITUACION-AUT: Situacin por la que se est autorizando la operacin.
Los siguientes campos de este segmento deben ser informados por el programa de aplicacin cuando se
produce la necesidad de autorizar una operacin:

IND-AUTO: Indicador de pendiente de autorizacin:

'S': operacin pendiente de autorizar
'N', ' ': operacin no pendiente de autorizar
IMPORTE-AUTO: Importe total de la operacin pendiente de autorizacin.
REFER-AUTO: Referencia de la operacin segn la aplicacin.

II.1.4. DATOS CONVERSACION ENTRADA/SALIDA.

Informacin utilizada en los programas conversacionales. Sirve para controlar el flujo de la
conversacin. Consta de los campos:
ESTADO: Indicador del estado en que se encuentra la transaccin en curso. Puede tomar los
siguientes valores:
'I': Estado INICIO. Indica que se entra a ejecutar la transaccin por primera vez, estando en el
terminal una pantalla distinta a la correspondiente a dicha transaccin. En consecuencia, la
nica informacin de entrada al programa vlida en estado inicio es la de la commarea entre
los programas aplicacin (no hay pantalla de entrada a "leer").
'C': Estado CONTINUACION. Indica que se entra a ejecutar la transaccin estando en el
terminal la pantalla propia de dicha transaccin, por lo tanto son vlidos los datos de
entrada tecleados desde el terminal como entrada a la transaccin. Dichos datos entran en
formato BMS en la direccin de memoria indicada en el campo PTR-COPYIN.
'X': Estado CONFIRMACION. Estado especial dentro de una continuacin para permitir la
confirmacin de una operacin en curso. Se puede considerar un caso especial del estado
continuacin, donde se espera, en primer lugar que no se modifique ningn dato de la
pantalla, y en segundo lugar que se pulse una tecla determinada que signifique la
confirmacin de la operacin.

CASO: Indicador utilizado cuando un programa de aplicacin espera diferentes tipos de entrada
dependiendo de los diferentes programas o estados que puedan cederle el control.
Por ejemplo, un programa que consulte una cuenta de un cliente, puede que deba consultar la
cuenta por su cdigo si le ha cedido el control un programa de consulta de cuenta por pantalla, o
por el cdigo de cliente si le ha cedido el control un programa de la aplicacin de clientes.

__________________________________________________________________________________________________
_
Pg. 12

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

DATOS: Campo que pueden utilizar los programas de aplicacin para pasar datos entre ellos.
Es una commarea entre programas de aplicacin de 30 caracteres de longitud. Si la commarea
entre programas de aplicacin es mayor de 30 caracteres, o no se desea utilizar este campo, se
pueden guardar dichos datos en la direccin de memoria indicada en el campo PTRDATA.
LONDATA: Este campo es gestionado por la Arquitectura. No se debe modificar.
PTRDATA: Direccin de memoria que contiene la commarea entre los programas de aplicacin.

II.1.5. DATOS DE SIGUIENTE TRANSACCION.

Este es el primero de los segmentos de salida de la commarea CAA, que debe ser rellenado por los
programas de aplicacin. En ste se encuentra la informacin sobre la siguiente transaccin que debe
ejecutarse. Consta de los campos:

CODTRAN-SIG: Cdigo de la siguiente transaccin que se debe ejecutar. Cuando se rellena a

espacios querr decir que no debe entrar ninguna transaccin a continuacin (este es el caso de
un programa transaccional, o de la salida de una conversacin).
Existen varios valores que no son cdigos de transaccin y que la Arquitectura interpreta de
manera especial:
o 'SAME': Cuando debe entrar a continuacin la transaccin que mand la pantalla que se
encuentra en el terminal.
Ser necesario informar este valor cuando se produce un error en un programa
conversacional en estado inicio: por estar en estado inicio, la pantalla que se encuentra
en el terminal es la que envi la ltima transaccin, que no se corresponde con la de la
transaccin en curso, y al darse un error, no debera aparecer la nueva pantalla, sino la
que figura en el terminal enviando el mensaje de error correspondiente, por lo que la
siguiente transaccin que se debe ejecutar es la que mand la pantalla al terminal.
o
o

'ULTI': Cuando debe entrar a continuacin la ltima transaccin que se aadi en la

cadena (ver campo CADENA).
'MENU': Cuando debe entrar a continuacin la primera transaccin de la cadena, que en
general ser el men principal (ver campo CADENA).

AUTOMATICA: Indica (S/N) si la siguiente transaccin debe ejecutarse automticamente

(valor 'S') sin esperar que el terminalista introduzca datos por pantalla o no (valor 'N' o ' '). Lo
habitual en una conversacin es que este indicador se encuentre con valor 'N' (o ' '), para permitir
que se puedan introducir datos por pantalla como entrada de la siguiente transaccin. El valor 'S'
de este indicador es utilizado por la Arquitectura para realizar el "switch de transaccin" para
terminales PS con GAT (terminal Ronda).

ACCION: Indica si la Arquitectura debe ceder el control directamente a otro programa de

aplicacin sin enviar ningn tipo de mensaje de salida al terminal (accin programa: 'PRG'), o si
debe enviar algn mensaje de salida al terminal (accin terminal: 'TER').
CADENA: La Arquitectura mantiene una relacin de las transacciones sucesivas que van
tomando control en una conversacin, empezando por la que inicia la conversacin (que
normalmente ser el men principal), y que constituyen la cadena de transacciones.
De esta manera, en cualquier punto de la conversacin, el terminalista puede realizar la peticin
de volver a la transaccin inmediatamente anterior (con la tecla Borra en nuestro caso), o bien
de volver a la transaccin inicial que realiz (con la tecla PF9 en nuestro caso).

Grfico que indica la manera de construir la cadena:

__________________________________________________________________________________________________
_
Pg. 13

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

ACCION='PRG';
CODTRAN-SIG='MENU'
+------------------------------------------------+

ACCION='PRG' ACCION='PRG'
ACCION='PRG'
ACCION='PRG'
CODTRAN-SIG= CODTRAN-SIG=
CODTRAN-SIG=
CODTRAN-SIG=
'ULTI' \|/
'ULTI'
'ULTI'
'ULTI'

<--------------+<--------------+<--------------+<--------------+
MENU
TRN2
TRN3
TRN4
--------->+-------------->+-------------->+-------------->+----+
CADENA='I'
CADENA='A'
CADENA='A'
ACCION='PRG'
ACCION='PRG'
ACCION='PRG'
CODTRAN-SIG=
CODTRAN-SIG=
CODTRAN-SIG=
'TRN2'
'TRN3'
'TRN4'

Los programas de aplicacin deben controlar la construccin de la cadena haciendo peticiones a

la Arquitectura, bien de iniciarla, bien de aadirse a ella, o bien de volver a alguno de los pasos
anteriores.
El momento en que un programa de aplicacin debe realizar alguna peticin de modificar la
cadena es cuando va a ceder control a otra transaccin distinta a ella (es decir, cuando
CODTRAN-SIG lo informa con un cdigo de transaccin distinto al suyo y distinto de 'ULTI' o
'MENU', y ACCION con el valor 'PRG'). Este es el momento de realizar la peticin de aadirse
a s mismo en la cadena. Esta peticin se realiza informando el campo CADENA con el valor
'A' (de Aadir).
Si el programa que quiere aadirse en cadena es el que inicia la conversacin (por ejemplo, el
men), la cadena todava no se ha comenzado a construir, y se debe pedir a la Arquitectura que
inicie la cadena, informando el campo CADENA con el valor 'I' (de Iniciar). Con este valor en
el campo CADENA, la Arquitectura entiende que se va a iniciar una nueva cadena (por lo que
borrar la antigua si existiera), y pondr a la transaccin que realiza esta peticin como primera
de la cadena.
Si el terminalista realiza la peticin de volver a la transaccin inmediatamente anterior, el
programa de aplicacin no tendra ms que indicar a la Arquitectura que la siguiente
transaccin a ejecutarse es la ltima en cadena informando el valor 'ULTI' en el campo
CODTRAN-SIG, y la Arquitectura cedera el control a la ltima transaccin almacenada en la
cadena.
Asimismo, si el terminalista realiza la peticin de volver a la transaccin inicial de la cadena, el
programa de aplicacin debera informar el campo CODTRAN-SIG con el valor 'MENU', con
lo que la Arquitectura cedera el control a la primera transaccin almacenada en la cadena.

CASO-CAD: En la cadena de transacciones, la Arquitectura guarda, junto al cdigo de

transaccin, dos campos asociados a cada miembro de la cadena: el CASO-CAD y el DATOSCAD, que son el caso y los datos que se le pasarn a la transaccin cuando se vuelva a ella por
retroceder en la cadena (y que le llegarn en los campos CASO Y DATOS respectivamente).
Se deben informar (si es necesario) cuando se realiza una peticin de aadirse o de iniciar la
cadena (es decir, cuando se informa el campo CADENA).
DATOS-CAD: Datos propios de entrada al retroceder en cadena.

II.1.6. DATOS DEL MENSAJE DE SALIDA.

__________________________________________________________________________________________________
_
Pg. 14

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

En este segmento, los programas de aplicacin proporcionan a la Arquitectura toda la informacin

sobre las distintas salidas al terminal. Solamente se tendr en cuenta cuando la accin sea terminal
(ACCION='TER').
Consta de los campos:
COD-ERROR: Cdigo del error producido. (Ver III.6.Mantenimiento de errores y avisos).
COD-AVISO1: Cdigo del primer aviso. Hay posibilidad de mandar hasta dos avisos al
terminal, que saldrn en la lnea 3 de la pantalla. Si se mandan dos, se trunca su contenido a 40
caracteres, saliendo el primero de ellos a partir de la columna 1, y el segundo a partir de la
columna 41.
COD-AVISO2: Cdigo del segundo aviso.
VAR1-ERROR: Variable primera del mensaje de error. Se puede informar con una variable
vlida como literal de error multi-idioma. Esto es vlido para todos los campos variables de los
errores y avisos.
VAR2-ERROR: Variable segunda del mensaje de error.
VAR1-AVISO1: Variable primera del primer aviso.
VAR2-AVISO1: Variable segunda del primer aviso.
VAR1-AVISO2: Variable primera del segundo aviso.
VAR2-AVISO2: Variable segunda del segundo aviso.
IMPORTE-DISP: Importe que debe proporcionar el dispensador.
DIARIO-LOCAL: Campo a actualizar en el diario electrnico local.
TIPO-SALIDA: Indicativo de la pantalla a enviar al terminal. Sus valores pueden ser:
'E': la misma pantalla de entrada
'S': una pantalla distinta de la de entrada
'P': debe entrar la paginacin de Arquitectura. Este valor se utiliza en los programas de listado.
' ': Ninguna pantalla de salida.
Solamente es necesario informar este campo cuando el programa de aplicacin se trate de un
listado, en cuyo caso dicho programa debe poner este campo con valor 'P' (paginacin). En otro
caso, la Arquitectura gestiona este valor con sus valores por defecto (Valor 'S' en Estado Inicio y
valor 'E' en estado Continuacin o Confirmacin).

COPY-OUT: Nombre del formato de salida cuando el campo anterior TIPO-SALIDA tenga
valor 'S' y exista formato de salida. Lo informa la Arquitectura, por lo que el programa de
aplicacin no debe modificarlo.
PANEL-OUT: Nombre del panel de salida cuando el campo anterior TIPO-SALIDA tenga valor
'S' y exista panel de salida. Lo informa la Arquitectura, por lo que el programa de aplicacin no
debe informarlo.
DESTINOS: (Ver documento II.5.Salidas no estndar).
Las transacciones pueden tener dos tipos de salidas: la salida estndar, y la salida no estndar.

La salida estndar siempre va dirigida a pantalla y est constituida por el contenido de la direccin de
memoria indicada en el campo PTR-COPYIN (es decir, el contenido de la pantalla estndar de salida en
formato BMS) y por los mensajes de error / aviso.
La salida no estndar est constituida por cualquier otro tipo de salida, y puede estar dirigida a pantalla
o a documento. Los programas de aplicacin deben pasar el contenido de estas salidas no estndares en
una serie de colas TS que pueden ser:

__________________________________________________________________________________________________
_
Pg. 15

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Colas TS '+PFnXXXX', donde n es 1, 2, 3, 4 5 (se pueden utilizar cinco colas TS de tipo +PF
para las cinco salidas no estndares) y XXXX es el cdigo del terminal (campo TERMINAL). Se
utilizan estas colas cuando la salida est en modo "preformato", es decir, no tiene ningn formato
asociado dado de alta en las tablas de la Arquitectura, y su contenido es justamente el mensaje que
debe enviarse.
Colas TS '+DCnXXXX', donde n es 1, 2, 3, 4 5 (se pueden utilizar hasta cinco colas TS de tipo
+DC para las cinco salidas no estndares) y XXXX es el cdigo del terminal (campo
TERMINAL). Se utilizan cuando la salida tiene un formato asociado en las tablas de la
Arquitectura. Su contenido est constituido en primer lugar, por el nombre del formato de salida
asociado al mensaje de salida no estndar y despus el contenido del mensaje en forma BMS.

La Arquitectura permite hasta cinco salidas diferentes no estndares. Cada una de ellas va indicada en
una de las cinco ocurrencias de este grupo, que contiene los campos:

DESTINO: Prefijo del TS que contiene la salida (+PF1,+DC1,...).

IND-PANDOC: Indicador del tipo de salida. Los valores disponibles son:
o 'P'
pantalla
o 'D'
documento impreso
o H
escritura en un fichero del disco duro (slo para terminales PS/2 del tipo 18).
o J
escritura de documento con formato JetForms (slo para terminales PS/2 del
tipo 19 - FFS/Altamira).
NUM-DOCUM: Nmero de documento si la salida es a documento y ste tiene uno asociado.
Puede tomar los valores:
'1': DIN A-4 Impresin normal.
'2': DIN A-4 Impresin comprimida.
'3': Cuartilla
'5','6','7','8': Libretas
'9': DIN A-4 en Impresora LASER.
'C': Cheque
'B': Banda
'I': Importe
'J': Diario magntico
'R': Documento preimpreso

PRILIN-DOCUM: Posicin de la primera lnea que se debe escribir en el documento (si la

salida es a documento).

IMPRESO: Cdigo del impreso a introducir en la impresora financiera.

IDIOMA: Cdigo del idioma en el que se van a imprimir los datos de la salida no estndar.

II.1.7. DATOS PARA GESTION DE PAGINACION.

Este segmento es utilizado por los programas de listado para permitir la gestin de paginacin por la
Arquitectura. Los campos de este segmento deben ser rellenados cuando el programa de listado informe
el campo TIPO-SALIDA con valor 'P'. (Ver documento II.4.Funcionamiento de la paginacin). Los
campos son:

CONTENID: Contenido genrico del listado, que puede indicar el tipo de seleccin por el que se
ha accedido al programa de listado.
SELEC-PERMIT: Contiene 10 ocurrencias de 1 carcter de longitud que contienen los
caracteres permitidos para seleccionar las lneas del listado.

__________________________________________________________________________________________________
_
Pg. 16

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

IND-VARSEL: Indicador de si se permite marcar como seleccionadas mas de una lnea ('S') o
solamente una ('N') con los caracteres indicados en las ocurrencias de SELEC-PERMIT.
MARGEN-FIJO: Margen que se debe fijar a la izquierda del listado cuando se hace "scroll" a
derecha e izquierda.
FKEY: Grupo de 8 ocurrencias, donde se indica al programa de gestin de listados hasta 8 teclas
vlidas que se pueden teclear, aparte de las propias del listado (PF4: izquierda, PF5: derecha,
PF7: arriba, PF8: abajo). El programa de gestin de paginacin de la Arquitectura devolver el
control al programa de aplicacin de listado cuando se haya pulsado una de estas teclas, y las
selecciones efectuadas sean vlidas. Cada una de las ocurrencias consta de:
o FKEY-NUM: Cdigo de tecla permitido.
o FKEY-LIT: Literal asociado a la tecla que debe aparecer por pantalla.
o FKEY-SEL: Se le indica al programa de gestin de listados si con la tecla pulsada debe
haber una seleccin ('S'), no se permite ninguna seleccin ('N') o es indiferente que se haya
seleccionado alguna lnea del listado o no (' ').
IND-AVPAG: Indicador (valores S/N) para el programa de gestin de listados, que indica si se
desea que se devuelva control al programa de aplicacin cuando se teclee la tecla PF8 (Scroll
abajo) y no existan mas lneas en la cola TS del listado para mostrar por pantalla.
En caso de haber informado el programa de listado el valor 'S' y llegar a fin de datos con la
tecla PF8, el programa de gestin de paginacin de la Arquitectura le devolver control al
programa de listado en estado "continuacin". En ese caso el programa de listado deber llenar
la cola TS del listado con un grupo mas de lneas. Este proceso se continuar hasta que el
programa de listado no tenga mas lneas que recuperar, en cuyo caso informar este indicador
con el valor 'N'.
IND-MOD-DATO: Indicador (valores S/N) para el programa de gestin de listados, con el que
un programa de aplicacin puede pedirle que refresque el contenido de la cola TS que contiene
las lneas de listado cada vez que tome el control dicho programa de gestin de listados.
En realidad solamente tiene sentido cuando las lneas de listado estn desprotegidas, para
permitir teclear su contenido desde el terminal, y en ese caso se debe actualizar la informacin
de dichas lneas de listado en la cola TS cada vez que se cambien por pantalla.
LNEA-PANT: Este campo lo utiliza exclusivamente el programa de gestin de listados, y los
programas de aplicacin no deben modificarlo.
COLUM-PANT: Este campo lo utiliza exclusivamente el programa de gestin de listados, y los
programas de aplicacin no deben modificarlo.
NUM-LIN-CAB: Nmero de lneas fijas para la cabecera del listado. Si no se informa este
campo, se considerar siempre al menos 1 lnea por defecto. Las lneas de cabecera
permanecern brillantes y protegidas, y no se movern de la pantalla al realizar scroll arriba y
abajo.
IND-SCROLL-LAT: Indicador de scroll lateral (valores S/N). Indica a la Arquitectura si debe
gestionar el scroll lateral a pesar de que las lneas escritas en la cola TS del listado tengan su
anchura mayor que la de una pantalla. Si no se informa, se toma el valor 'S' por defecto (es decir,
la paginacin de la Arquitectura gestionar el scroll lateral siempre que la anchura de la cola TS
sea mayor que la que puede aparecer en una pantalla).
NUM-ITEM-SELEC: Nmero de item seleccionado (en el caso de seleccin nica). En el caso
seleccin mltiple, el primer seleccionado.
IDTABLA: Nombre de la tabla para el listado dinmico de tablas. Tambin puede contener los
10 primeros caracteres del item seleccionado en un listado dinmico de tablas (ver II.15.Listado
dinmico de tablas).

__________________________________________________________________________________________________
_
Pg. 17

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.1.8. DATOS PARA ANALITICA Y ESTADISTICAS.

En este segmento los programas de aplicacin proporcionan a la Arquitectura informacin para ser
explotada por alguna aplicacin de contabilidad analtica y para recoger estadsticas gestionadas por la
propia Arquitectura. Consta de los campos:
ENTIDAD-ANA: Entidad destino para analtica.
CENTRO-ANA: Centro destino para analtica.
PRODUCTO-ANA: Clave del producto asociado para analtica.
CLIENTE-ANA: Cliente para analtica.
IMPORTE-ANA: Importe para analtica.
SUBPROD-ANA: Subproducto para analtica.
FINALID-ANA: Finalidad para analtica.
GARANTIA-ANA: Garanta para analtica.
SUB-CLASIF: Subclasificacin de la transaccin para analtica.
TIOPER: Tipo de operacin realizada. Puede tomar los valores:
'A': Alta
'B': Baja
'M': Modificacin
'C': Consulta
'E': Edicin
'P': Peticin al batch
'O': Operacin de entrada / salida
' ': Ninguna de las anteriores
CONTABLE: Indicador de si la operacin realizada es contable ('S') o no ('N'). (Ver documento
II.6.Actualizacin de Journal y Totales).
DATOS-APLIC: Datos de libre uso para la aplicacin.

II.1.9. DATOS DE ERROR INESPERADO.

Informacin sobre un posible error CICS o DB2 inesperado. Contiene dos grupos de campos, que se
deben informar bien cuando se produzca un error DB2, bien cuando se produzca un error CICS.
Cuando el error sea de tipo DB2, los campos a informar son:
OBJETO-ERROR: Objeto DB2 (Tabla, ndice.) donde se produjo el error.
SQLCODE: Sqlcode devuelto por el DB2. Es el contenido del campo SQLCODE del grupo
SQLCA.
SQLERRM: Sqlerrm devuelto por el DB2. Es el contenido del campo SQLERRM del grupo
SQLCA.
Cuando el error sea de tipo CICS, los campos a informar son:
EIBFN: Ultima funcin CICS. Es el contenido de la variable EIBFN del grupo DFHEIBLK.
EIBRSRCE: Ultimo recurso CICS. Es el contenido de la variable EIBRSRCE del grupo
DFHEIBLK.
__________________________________________________________________________________________________
_
Pg. 18

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

EIBRCODE: Cdigo de respuesta de CICS. Es el contenido de la variable EIBRCODE del

grupo DFHEIBLK.
EIBRESP1: Condicin producida por la funcin CICS que produjo el error. Es el contenido de
la variable EIBRESP del grupo DFHEIBLK.
EIBRESP2: Informacin adicional a EIBRESP1. Es el contenido de la variable EIBRESP2 del
grupo DFHEIBLK.

II.2. ESQUEMA DE UNA CONVERSACION.

Un dilogo conversacional consiste en un conjunto de pantallas entrelazadas entre s de forma que el
terminalista tiene la oportunidad de actuar sobre cualquiera de las respuestas que recibe, a diferencia
del dilogo transaccional, caracterizado por una nica peticin del terminalista seguida por una
respuesta del Host sobre la cual no se puede actuar.
A continuacin se explicarn el conjunto de procesos que lleva a cabo la Arquitectura para mantener
este dilogo conversacional (pseudo conversacional), teniendo en cuenta en cada caso los valores que
tomaran los campos de la CAA (commarea de la Arquitectura con las aplicaciones) que sirven para
controlar el curso de la conversacin.
Es conveniente recordar aqu el concepto de CADENA de una conversacin. La Arquitectura mantiene
una relacin de transacciones sucesivas que van tomando control en una conversacin, empezando por
la que inicia la conversacin (que normalmente ser el men principal), y que constituyen la cadena de
la conversacin.
__________________________________________________________________________________________________
_
Pg. 19

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

De esta manera el terminalista puede realizar la peticin de volver a la transaccin inmediatamente

anterior en cualquier punto de la conversacin, o bien volver a la transaccin inicial que realiz.
Sealar como hiptesis de partida y estndar de la instalacin, que un cdigo de transaccin lleva
asociado un slo programa y ste a su vez una nica pantalla.

__________________________________________________________________________________________________
_
Pg. 20

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 21

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 22

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.1 COMIENZO DE UNA CONVERSACION.

Las conversaciones se inician arrancando la primera transaccin de la conversacin por el terminal,
normalmente un men.
Terminal
Tecleo del cdigo
de transaccin del
men

Arquitectura
Cede control al
----> programa asociado con
la transaccin

Aplicacin
---->

Sale en pantalla el
Enva panel de salida
<---panel asociado a la <---- asociado a la transaccin
transaccin de men
de men despus de evaluar
la accin terminal

Proceso en estado
inicio. Inicializa
el contenido de la
pantalla de salida.
Pone accin teminal,
cdigo de transaccin
siguiente=ella misma
y estado=continuacin

El programa de aplicacin tendra los siguientes valores en los campos de la CAA (los campos que no
aparecen tienen valor a espacios o ceros), suponiendo que la transaccin de men sea 'QM' Arquitectura:
En la entrada:
ESTADO= 'I'

En la salida:
ESTADO='C' (continuacin)
CODTRAN-SIG=CODTRAN (contiene 'QM')
ACCION='TER' (terminal)

__________________________________________________________________________________________________
_
Pg. 23

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.2. SELECCION DE UNA OPCION DEL MENU.

En el terminal se encuentra el panel del men, y el terminalista elige una opcin y pulsa una tecla. Los
procesos que se llevan a cabo para ejecutar la opcin elegida son los siguientes:
Terminal

Arquitectura

Aplicacin

Se elige una opcin

Cede el control al
Entra en estado=continuacin.
del men y se pulsa ---> programa asociado con --> Evala la opcin y la tecla
una tecla de funcin
la transaccin de men
pulsada y decide cul es la
prxima transaccin,poniendo
Evala la accin
<-- accin=prog. y estado=inicio
programa y da control
al programa asociado
a la siguiente transaccin que le ha
--> Entra el nuevo programa de
sido indicada
aplicacin en estado=inicio.
Inicializa el contenido de
la pantalla de salida.
Pone accin=terminal,
Sale en pantalla
<--- Evala la accin
<-- cdigo de transaccin
el panel asociado
terminal y enva el
siguiente=ella misma y
a la opcin elegida
panel asociado a la
estado=continuacin.
inicializado
nueva transaccin

En el primer programa de aplicacin se tendran los siguientes valores en los campos de la CAA
(suponemos que el cdigo de transaccin correspondiente a la opcin elegida es "QMSW"):
En la entrada:
ESTADO='C'

En la salida:
ESTADO='I'
(inicio)
CODTRAN-SIG='QMSW'
ACCION='PRG' (programa)
CADENA='I' (*)
CASO-CAD= (Si es necesario)
DATOS-CAD= (Si es necesario)

(*) Al dar control a otra transaccin, el men se debe aadir a la cadena. Como el men es el primero
que se aade, debe hacerlo con el valor 'I' en el campo CADENA.
En el segundo programa de aplicacin se tendran los siguientes valores:
En la entrada:
ESTADO='I'

En la salida:
ESTADO='C'
CODTRAN-SIG=CODTRAN (contiene 'QMSW')
ACCION='TER'

__________________________________________________________________________________________________
_
Pg. 24

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.3. REALIZACION DE UNA CONSULTA.

Con el panel que tenemos en pantalla, queremos realizar una consulta, por lo que tecleamos la clave
que queremos consultar y pulsamos tecla Intro:
Terminal
Se teclea una clave
para consulta y se
pulsa la tecla
Intro

Arquitectura
Cede el control al
programa de aplicacin
---> asociado a la tran-->
saccin que consulta

Sale en pantalla el
Evala la accin
mismo panel con los <--- terminal y enva el
datos consultados
panel asociado a la
transaccin

Aplicacin
Entra en estado=continuacin.
Accede a las tablas para
realizar la consulta.
Informa la pantalla de salida con los datos de la
consulta. Pone accin=terminal, cdigo de transaccin
<-- siguiente=ella misma y
estado=continuacin

En el programa de aplicacin se tendrn los siguientes valores en los campos de la CAA:

En entrada:
ESTADO='C'

En salida:
ESTADO='C'
CODTRAN-SIG=CODTRAN (contiene 'QMSW')
ACCION='TER'

__________________________________________________________________________________________________
_
Pg. 25

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 26

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.4. REALIZACION DE UNA BAJA.

Supongamos ahora que queremos realizar una baja con el panel que tenemos en pantalla, por lo que
pulsamos la tecla de baja:
Terminal

Arquitectura

Aplicacin
Entra en estado=continuacin. Valida la baja, e
informa el campo
COD-AVISO1 con el cdigo
de aviso de "Confirme baja
con tecla PFx". Pone estado=
confirmacin, accin=
terminal y siguiente transaccin=ella misma.

Se pulsa la tecla
de baja

--->

Cede el control al --->

programa de aplicacin asociado a la
transaccin

Sale por pantalla

el mensaje de aviso de confirmar
baja

<---

Evala la accin
<--terminal y enva el
mensaje de aviso a
pantalla

Se pulsa la tecla indicada en

el mensaje de aviso anterior

--->

Cede el control al
programa de aplicacin asociado a la
transaccin

Sale en pantalla
el mensaje: "Baja
realizada".

<---

---> Entra en estado=confirmacin.

Evala la tecla pulsada,
validando que es la correcta.
Se asegura de que no se han
modificado datos en la
pantalla. Realiza la baja.
Informa el campo COD-AVISO1
con el cdigo de aviso de
"Baja realizada". Pone
Evala la accin
<--- estado=continuacin, accin=
terminal y enva el
terminal y siguiente tranmensaje de aviso a
saccin=ella misma.
la pantalla

En el programa de aplicacin se tendrn los siguientes valores en los campos de la CAA la primera vez:
En la entrada:
ESTADO='C'

En la salida:
ESTADO='X' (confirmacin)
CODTRAN-SIG=CODTRAN (contiene QMSW)
ACCION='TER'

Y la segunda vez:
En la entrada:
ESTADO='X'

En la salida:
ESTADO='C' (continuacin)
CODTRAN-SIG=CODTRAN (contiene QMSW)
ACCION='TER'

__________________________________________________________________________________________________
_
Pg. 27

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.5. ACCESO A OTRO PANEL DESDE EL DE CONSULTA/BAJA.

Si desde el panel de consulta/baja queremos ir a otro panel, el terminalista pulsara la tecla de funcin
pertinente. Los procesos que se desarrollan son:
Terminal
Se pulsa la tecla
de funcin

Arquitectura
--->

Sale en pantalla
<--el panel asociado
a la nueva transaccin inicializado

Cede el control al
programa de aplicacin de consulta/
baja

Aplicacin
---> Entra en estado=continuacin. Evala la tecla pulsada y decide cul es la
prxima transaccin, poniendo accin=programa y
<--- estado=inicio

Evala la accin
programa y le da
control al programa
asociado a la siguiente transaccin que le
ha sido indicada.
---> Entra en estado=inicio el
siguiente programa. Inicializa su pantalla de
salida. Pone accin=terminal,
estado=continuacin y
Evala la accin
<--- transaccin siguiente=
terminal y enva
ella misma
el panel de la nueva
transaccin

En el primer programa de aplicacin se tendran los siguientes valores en los campos de la CAA
(suponemos que el cdigo de la transaccin elegida por la tecla de funcin es "QMAB"):
En la entrada:
ESTADO='C'

En la salida:
ESTADO='I'
CODTRAN-SIG='QMAB'
ACCION='PRG'
CADENA='A' (*)
CASO-CAD= (Si es necesario)
DATOS-CAD= (Si es necesario)

(*) Al dar control a otra transaccin, la transaccin de consulta/baja debe aadirse en cadena. Como la
cadena de transacciones ya ha sido inicializada por el men, debe pedir a la Arquitectura que le aada a
la cadena con el valor 'A' en el campo CADENA.
En este momento, la cadena de transacciones tendra dos miembros: el men (QM) en primer lugar y la
transaccin de consulta/baja (QMSW) en segundo lugar.
En el segundo programa de aplicacin se tendran los siguientes valores:
En la entrada:
En la salida:
ESTADO='I'
ESTADO='C'
CODTRAN-SIG= CODTRAN (contiene QMAB)
ACCION='TER'

__________________________________________________________________________________________________
_
Pg. 28

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.6. VUELTA A LA TRANSACCION DE CONSULTA/BAJA.

Ahora el terminalista desea volver de nuevo a la transaccin de consulta/baja. Para ello, pulsa la tecla
PF3 (tecla estndar de retroceso al panel anterior).
Terminal
Se pulsa la tecla
'PF3'

Sale en pantalla
el panel de la
nueva transaccin
inicializado

--->

<---

Arquitectura
Cede el control al
programa de aplicacin asociado a
la transaccin QMAB

Aplicacin
---> Entra en estado=continuacin y evala la tecla
pulsada. Al ser la tecla
'Borra' pone estado=inicio
accin=programa y en el
<--- campo CODTRAN-SIG el valor
'ULTI'.

Evala la accin
programa y al constatar que el cdigo
de transaccin siguiente es 'ULTI', da control a la transaccin
que se encuentra en
ltimo lugar en la
cadena (QMSW) ---> Entra en estado=inicio el
programa de aplicacin.
Inicializa la pantalla de
salida y pone accin=terminal, estado=continuacin
y cdigo de transaccin
Evala accin ter<--- siguiente=ella misma.
minal. Enva el
panel asociado a la
nueva transaccin

En el primer programa de aplicacin se tendran los siguientes valores en los campos de la CAA :
En la entrada:
ESTADO='C'

En la salida:
ESTADO='I'
CODTRAN-SIG='ULTI'
ACCION='PRG'

Aunque se est dando control a otra transaccin, no se debe aadir en cadena, puesto que el cdigo de
transaccin siguiente (ULTI) implica un retroceso en la cadena, y no un avance en ella (en cuyo caso s
se debera aadir).
Despus de este proceso, la cadena de transacciones tendra un nico miembro: el men (QM).
En el segundo programa de aplicacin se tendran los siguientes valores:
En la entrada:
ESTADO='I'

En la salida:
ESTADO='C'
CODTRAN-SIG=CODTRAN (contiene QMSW)
ACCION='TER'

__________________________________________________________________________________________________
_
Pg. 29

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 30

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 31

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.2.7. ACCESO AL MENU DESDE CUALQUIER PUNTO DE LA CONVERSACION.

El terminalista ha realizado una serie de operaciones yendo de un panel a otro de la conversacin, y
llegado el momento desea volver de nuevo al men inicial. Para ello, pulsa la tecla PF9 (estndar de
vuelta al men inicial).
Terminal
Se pulsa la tecla
'PF9'

Arquitectura
--->

Cede el control al
programa de aplicacin asociado a
la transaccin

Aplicacin
---> Entra en estado=continuacin y evala la tecla
pulsada. Al ser la tecla
'PF9' pone estado=inicio
accin=programa y en el
<--- campo CODTRAN-SIG el valor
'MENU'.

Evala la accin
programa y al constatar que el cdigo
de transaccin
siguiente es 'MENU',
da control a la transaccin que est en
primer lugar en la
cadena (QM)
--->

Sale en pantalla
el panel de la
nueva transaccin
inicializado

<---

Evala accin terminal. Enva el panel asociado a la

nueva transaccin

Entra en estado=inicio el
programa de aplicacin.
Inicializa la pantalla de
salida y pone accin=terminal, estado=continuacin
<--- y cdigo de transaccin
siguiente=ella misma.

En el primer programa de aplicacin se tendran los siguientes valores en los campos de la CAA :
En la entrada:
ESTADO='C'

En la salida:
ESTADO='I'
CODTRAN-SIG='MENU'
ACCION='PRG'

Aunque se est dando control a otra transaccin, no se debe aadir en cadena, puesto que el cdigo de
transaccin siguiente (MENU) implica un retroceso en la cadena, y no un avance en ella (en cuyo caso
s se debera aadir). Despus de este proceso, la cadena de transacciones no contendra ningn
miembro.
En el segundo programa de aplicacin se tendran los siguientes valores:
En la entrada:
ESTADO='I'

En la salida:
ESTADO='C'
(continuacin)
CODTRAN-SIG= CODTRAN (contiene 'QM ')
ACCION='TER'

Se debe sealar que las teclas Borra (Ir al panel anterior) y PF9 (Ir al primer men), son gestionadas
por la Arquitectura cuando la transaccin consta en la tabla de transacciones como que tiene PF's
estndares. En este caso, al pulsar las teclas PF9 o Borra, no se dara control al programa de
aplicacin, y por lo tanto ste no tendra que gestionar estas teclas.
Este caso est descrito aqu para dejar constancia del proceso que sera
necesario para gestionarlas.
__________________________________________________________________________________________________
_
Pg. 32

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.3. PARAMETRIZACION.

II.3.1. PARAMETRIZACION DE LA ARQUITECTURA.

La Arquitectura tiene una serie de controles y validaciones que se realizan en funcin del entorno de
trabajo (tanto on-line como en batch) y la entidad con la que se opera.
Esto hace que haya que definirse un control de operativa diaria (tabla de control QGDTSWA) y unas
tablas de entidades y parmetros relacionados con cada una de ellas (QGDTENA, QGDTPAB y
QGDTPAO). Para completar toda esta informacin veanse los documentos III.10.Mantenimiento
SWA-Tabla control del Sistema y III.22.Mantenimiento de la tabla de Entidades.
__________________________________________________________________________________________________
_
Pg. 33

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 34

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.3.2. PARAMETRIZACION DE UNA APLICACION.

A continuacin se relacionan los pasos necesarios para parametrizar una aplicacin que se desea
integrar en la Arquitectura.
Si se contempla una gestin multidivisa es imprescindible indicarlo a la hora de su definicin puesto
que existen nuevos tratamientos diferenciados.
Las tablas de la Arquitectura que se deben actualizar para dar de alta una nueva aplicacin son:
QGDTAPL: Tabla de aplicaciones.
QGDTCCT: Tabla de transacciones.
QGDTFDF: Tabla de formatos de transacciones.
QGDTPFK: Tabla de teclas de funcin admitidas para cada transaccin.
QGDTPFM: Tabla de preformatos de transacciones (implcitamente tambin se actualizar la
tabla QGDTPFL de lneas de preformatos).
QGDTERR: Tabla de cdigos de errores/avisos.
QGDTDTA: Tabla de descripciones multi-idioma. Se actualizar automticamente con
cualquier cambio en las tablas anteriores realizando las altas y modificaciones a travs de las
conversaciones de mantenimiento de la Arquitectura (ver III.Mantenimiento de tablas del
sistema).
Opcionalmente, ser necesario informar tambin las siguientes tablas:
QGDTRTO: Tabla de referencia de totales.
QGDTHLP: Tabla de ayudas on-line.
QGDTHLC: Tabla de ayudas activas.
QGDTTDD: Tabla de distribucin de telediscos.
QGDTTLI: Tabla de literales de error multi-idioma.
Los pasos a dar son los siguientes, por este orden:
1.- Dar de alta la aplicacin en la tabla de aplicaciones. Cambiar la descripcin para cada idioma de
la instalacin.
2.- Dar de alta los preformatos en la tabla de preformatos (si existen). Cambiar las descripciones de
los literales para cada idioma de la instalacin.
3.- Dar de alta los formatos en la tabla de formatos (si existen). No se permite dar de alta un
formato sin su correspondiente preformato en el caso de que exista.
4.- Dar de alta las ayudas de campos para aquellos que se desee.
5.- Dar de alta las pantallas de ayuda on-line para la transaccin, si esta fuera conversacional y se
deseara utilizar una ayuda. Cambiar las descripciones de los literales para cada idioma de la
instalacin.
6.- Dar de alta las transacciones en la tabla de transacciones. No se permite dar de alta una
transaccin sin su correspondiente formato de entrada (si lo tiene) dado de alta en la tabla de
formatos, ni su correspondiente cdigo de ayuda (si tuviera ayuda on-line asociada). Cambiar
las descripciones de los literales para cada idioma de la instalacin.
7.- Definir las teclas de funcin asociadas a cada transaccin, si se desea un control de las mismas
por parte de la Arquitectura. Cambiar las descripciones de los literales para cada idioma de la
instalacin.
8.- Dar de alta los cdigos de error/aviso manejados en los programas de aplicacin en la tabla de
errores/avisos. Cambiar las descripciones de los literales para cada idioma de la instalacin.
9.- Si la aplicacin necesita que la Arquitectura actualice totales contables, se deben dar de alta los
tipos de totales que utiliza la aplicacin en la tabla de referencia de totales. Cambiar las
descripciones de los literales para cada idioma de la instalacin.
10.- Dar de alta los cdigos de literales de error/aviso en los diferentes idiomas de la instalacin.
__________________________________________________________________________________________________
_
Pg. 35

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Si adems la aplicacin utiliza la utilidad del teledisco, se deber:

11.-

Dar de alta en la tabla de distribucin de telediscos los procesos batch que utilizan teledisco, con
el teledisco asociado.

Por otra parte, en todos los planes DB2 de las aplicaciones, deben figurar los siguientes DBRM's:
QC2CSQ1
QC2CSQ2
QC2CFTO
QC2CATL
(Si se utilizan literales de error/aviso multi-idioma)
QC2CHLP
(En conversaciones que utilicen la ayuda de transaccin)
QC2CHLC
(En conversaciones que utilicen la ayuda activa) (*)
QC2CREA
(En conversaciones, para suspender una conversacin)
QC2CAUT
(En conversaciones, cuando se pide autorizacin por Arquitectura Extendida)
QC2CAUS
(En conversaciones, cuando se pide autorizacin por Arquitectura Estndar)
QC2CSQ3
(Si alguna transaccin del plan es de tipo Estndar)
QG2CTLD
(Si se utiliza el teledisco)
QC2CLIS
(Si utiliza listados dinmicos de tablas)
QC2CIMP
(Si se requiere la utilidad de impresin desde 3270)
(*) Las tablas DB2 donde se encuentren los valores del campo al que se le ha asignado ayuda activa,
deben tener hecho GRANT TO PUBLIC para SELECT.

II.4. FUNCIONAMIENTO DE LA PAGINACION.

La Arquitectura proporciona a las aplicaciones, a travs de un mdulo al efecto, la posibilidad de
gestionar la paginacin por pantalla de forma completamente transparente al usuario.
Se entiende por paginacin la posibilidad de mostrar informacin repetitiva por pantalla, de forma que
el usuario pueda desplazarse dentro del conjunto de datos en cuatro direcciones: avanzar, retroceder,
izquierda y derecha.
Todos los programas que empleen este mdulo, utilizarn un mapa comn en el cual el cuerpo de datos
est compuesto por un carcter de seleccin por cada una de las lneas del listado, llamado el campo
OPCION y por los datos a paginar (tanto uno como otro podrn estar protegidos), as como una
cabecera del listado que puede ser de 1 a 15 lneas.

__________________________________________________________________________________________________
_
Pg. 36

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

La cabecera de listado constar de tantas lneas como informe el programa de aplicacin. Podrn ser un
mnimo de 1 y un mximo de 15; estas lneas aparecern brillantes y protegidas en primer lugar, y no se
movern al hacer scroll arriba o abajo.
Las transacciones de listado, pues, llevarn en la tabla de transacciones de la Arquitectura
(QGDTCCT) como formato y panel asociado el "QCRMGTS", que es el nombre del mapa comn a
todos los listados.
Este proceso, que normalmente implica una notable complejidad de programacin, es realizado
completamente por el mdulo de Arquitectura QC1CGTS.
El funcionamiento sigue el siguiente esquema:
o Se arranca la transaccin asociada al programa de paginacin, en adelante "de listado".
o El programa de listado entra en estado inicio y borra la cola donde va a escribir las lneas de
listado (llamada +GTSxxxx, donde xxxx es el contenido del campo CAA-TERMINAL de la
commarea CAA) por si existiera de una tarea anterior.
o A continuacin accede a sus tablas para capturar la informacin a listar, escribindola
formateada (como si se tratara de un listado a papel) en una cola TS llamada +GTSxxxx
(xxxx: contenido del campo CAA-TERMINAL de la commarea CAA). Cada lnea del TS
contendr:
|O|A|CONTENIDO DE LA LNEA ...|
| |
| --> Contenido de la lnea
|
---------> Atributo de la lnea (*)
---> Opcin

(*) Este atributo puede tomar los siguientes valores, y el programa de gestin de TS pondr los
atributos de los campos OPCION y CONTENIDO DE LA LNEA como se indica:

o
o
o

VALOR DEL CAMPOATRIBUTO DE OPCION

ATRIB. DE LA LNEA
''
Desprot.+ Normal
Protegido+ Normal
'B'
Desprot.+ Normal
Protegido+ Brillante
'A'
Desprot.+ Normal
Protegido+ Normal
'R'
Desprot.+ Normal
Desprot. + Brillante
'V'
Desprot.+ Normal
Desprot. + Normal
'*'
Proteg. + Normal
Desprot. + Normal
'+'
Proteg. + Brill.
Protegid.+ Brillante
'-'
Proteg. + Normal
Protegid.+ Normal
El programa de listado llama al mdulo de Arquitectura informando en la commarea de la
Arquitectura (CAA) los campos:
TIPO-SALIDA = 'P' (indica que debe entrar el proceso de Paginacin).
Segmento completo de datos para gestin de paginacin en la CAA (Ver II.1.rea de
Comunicacin con la Arquitectura (CAA)). En este segmento se encuentra la siguiente
informacin:

Cabecera descriptiva de los datos a paginar.

Caracteres con los que se permite seleccin de una lnea de listado, por ejemplo, 'X', 'S',
etc., hasta 10 caracteres diferentes.

Si se permite al terminalista multiseleccin o no, es decir, que el mdulo de Arquitectura

permita que se seleccione ms de una fila antes de devolver control al programa de
listado.

__________________________________________________________________________________________________
_
Pg. 37

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Margen fijo a mantener en desplazamientos laterales, es decir, cuando se pida

desplazamiento a derecha e izquierda, es el nmero de caracteres que se mantienen
siempre visibles a la izquierda de la informacin de pantalla; normalmente ser la
informacin clave de cada uno de los datos paginables.

Teclas de funcin permitidas al terminalista para el programa en curso, excepto las

estndar (avanzar: PF8, retroceder: PF7, izquierda: PF4, derecha: PF5). Si el programa
de paginacin QC1CGTS no gestiona el scroll lateral (bien porque la anchura de las
lneas en la cola TS sea menor o igual que la anchura de la pantalla, o bien porque se le
haya indicado al programa de paginacin que no se desea utilizar dicho scroll
expresamente), el programa QC1CGTS permitir que las teclas PF4 y PF5 las pueda
gestionar el programa de aplicacin de listado.

Si el modulo QC1CGTS debe dar control al programa de listado cuando se pulse la tecla
PF8 (Scroll abajo) y no existan ms datos en la cola TS.

Si se debe refrescar el contenido de las lneas de listado que se han escrito en la cola TS
cada vez que tome control en veces sucesivas el mdulo QC1CGTS.

Nmero de lneas de cabecera, que permanecern fijas en el scroll arriba y abajo.

Si se desea que el programa de paginacin gestione el scroll lateral o no, sea cual sea la
anchura de las lneas del listado.

Nmero del primer item seleccionado, lo que permite acceder a dicho item con una nica
lectura de la cola TS. Este es un campo de salida del programa de paginacin
QC1CGTS al de listado, el cual deber utilizarlo en estado Continuacin, cuando le sea
devuelto el control, despus de que el terminalista pulse una tecla de funcin vlida y
realice en su caso una seleccin.

El mdulo de Arquitectura es en adelante el que realiza todo el proceso de listado cubriendo las
siguientes funciones:
Desplazamiento en cuatro direcciones:
'n' caracteres (segn el campo SALTO del panel de listado).
'P' pgina completa ('').
'H' media pgina ('').
'M' Mximo a izda., derecha, etc. ( " ).

Mantenimiento de un margen fijo.

Valida que las teclas de funcin pulsadas sean correctas.
Verifica que los caracteres de seleccin utilizados son vlidos y que no se haya informado
ms que uno cuando no se permita multiseleccin.
Ilumina y/o protege las lneas que correspondan si procede.

Una vez que el terminalista pulsa una tecla de funcin vlida y no de paginacin (PF4, PF5, PF7 o
PF8), el mdulo cede control al programa de aplicacin (que entra en estado continuacin), el cual, si
espera alguna seleccin, leer la cola TS +GTSxxxx para verificar qu opcin/es ha/n sido
seleccionada/s, actuando en consecuencia.
__________________________________________________________________________________________________
_
Pg. 38

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Normalmente este se limitar a llamar a un programa de consulta o mantenimiento mostrando la

informacin completa del registro seleccionado.
Los campos del panel general de listados (QCRMGTS) comunes a todos ellos son:

LNEAS DE SELECCION Y SALTO: Esta primera lnea es comn a todos los listados, y
contiene los campos:
o

SALTO: Salto que se desea cuando se pulsa una de las teclas estndar del listado: PF4,
PF5, PF7 y PF8. Es un campo modificable y sus valores pueden ser:
'n' caracteres
'P' pgina completa
'H' media pgina
'M' mximo a izda., derecha, etc.

SELECCION: Indica el criterio de seleccin por el que se ha accedido al listado, o bien

un titulo especifico del listado. No es modificable por pantalla. En este campo aparecer
el contenido del campo CAA-CONTENID de la commarea CAA, que el programa de
listado ha informado.

LNEA: Tiene la forma:

L ZZ9:ZZ9
donde la L es indicativo de "Lnea" y el primer nmero indica el nmero relativo de la
primera lnea del listado dentro del total de lneas, que es indicado en el segundo
nmero. No es modificable por pantalla.
Por ejemplo, si un listado de 87 lneas se encuentra en el principio, aparecer:
L 1: 87.

En la segunda lnea puede aparecer el campo siguiente:

o

COLUMNA: Aparece justo debajo de la lnea, y solamente cuando se gestione el scroll

lateral. Tiene la forma:
C ZZ9:ZZ9
donde la C es indicativo de "Columna" y el primer nmero indica el nmero relativo
de la columna primera del listado dentro del total de anchura de la lnea, que es
indicado en el segundo nmero. No es modificable por pantalla.

LNEAS DE CABECERA DEL LISTADO:

Dependiendo de los valores informados por la aplicacin para el nmero de lneas de cabecera,
stas apareceran en modo protegido brillante, sin campo de opcin/seleccin.

LNEAS DE DETALLE DEL LISTADO:

A continuacin aparecen las lneas de detalle del listado, que variarn en contenido de un listado
a otro. Para cada lnea del listado existen dos campos:
o El campo de la seleccin.
o El campo de contenido de las lneas.

__________________________________________________________________________________________________
_
Pg. 39

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.5. SALIDAS NO ESTANDAR.

Se denomina salida de una transaccin a toda respuesta que el terminalista recibe como resultado de la
ejecucin de dicha transaccin.
Las transacciones pueden tener dos tipos de salidas al terminal: la estndar y la no estndar.
La salida estndar est constituida por el contenido de la pantalla estndar de entrada/salida
(indicado en la direccin de memoria del campo de la commarea con la Arquitectura -CAAllamado PTR-COPYIN) y por los mensajes de error/aviso. Esta salida estndar siempre va
dirigida a pantalla.

La salida no estndar est constituida por cualquier otro tipo de salida, y puede estar dirigida a
pantalla o a documento. La Arquitectura permite hasta 5 salidas no estndares diferentes.

En este captulo se describir cmo un programa de aplicacin gestiona las salidas no estndares,
comunicndole a la Arquitectura su existencia y donde se encuentra su contenido.
Cuando un programa de aplicacin requiere una salida de tipo no estndar (por ejemplo, necesita
imprimir un documento), debe:
1.- Escribir el contenido de dicha salida en una cola TS que se llamar de una manera especial (a
continuacin se ver esto con ms detalle).

__________________________________________________________________________________________________
_
Pg. 40

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

2.-

Comunicar a la Arquitectura a travs de su commarea (CAA) que existe una salida no estndar,
donde se encuentra el contenido del mensaje (la cola TS), y si la salida es a pantalla o a papel.
Esta informacin viene contenida en el grupo DESTINOS de la CAA (que tiene 5 ocurrencias,
una por salida).

Las salidas no estndar pueden, al igual que la estndar, tener o no un formato

asociado, y su tratamiento es diferente en cada caso.

__________________________________________________________________________________________________
_
Pg. 41

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.5.1. SALIDA NO ESTANDAR SIN FORMATO ASOCIADO.

En este caso, la aplicacin escribir la salida en una cola TS llamada:
'+PFnXXXX':

siendo n: 1, 2, 3, 4 5 (por la posibilidad de haber hasta 5 salidas) y XXXX el

cdigo del terminal (contenido en CAA-TERMINAL).

Al no tener formato asociado, se escribir en esta cola TS el contenido del mensaje tal y como debe
aparecer en el terminal o en el documento.
Por ejemplo, si queremos escribir por impresora una carta, y no tenemos formato asociado a esta
salida, se creara un TS llamado '+PF1XXXX', conteniendo, lnea a lnea, la carta que se quiere escribir
tal y como queremos que salga en papel.
Para comunicar a la Arquitectura la existencia de esta salida, se informarn los campos de la commarea
CAA:
DESTINO(1)
IND-PANDOC(1)
NUM-DOCUM(1)
PRILIN-DOCUM(1)

= '+PF1'
= 'D'
= '1'
='05'

(Debe ser '+PFn')

(Puede ser 'P': a pantalla o 'D': a documento)
(Nmero de documento de un folio)
(Nmero de lnea donde se comenzar a
escribir si la salida es a papel).

__________________________________________________________________________________________________
_
Pg. 42

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.5.2. SALIDA NO ESTANDAR CON FORMATO ASOCIADO.

En este caso, la aplicacin escribir la salida en una cola TS llamada:
'+DCnXXXX':

siendo n: 1, 2, 3, 4 5 (hasta 5 posibles salidas) y XXXX el cdigo del

terminal (contenido en el campo CAA-TERMINAL).

En la cola TS se escribir:
n las 8 primeras posiciones, el nombre del formato asociado al mensaje de salida. Ha de existir en
la tabla de formatos.
A continuacin se escribir el contenido de los campos variables del mensaje en forma BMS.
El contenido de la cola TS ser:
|AARMXXXX|12x|LL|A|CCC.....CCC|LL|A|CCC.....CCC|.......
|
|
|
----->Contenido del campo 1
|
|
-->Atributo del campo 1
|
-->Longitud del campo 1
--->Nombre del formato

La cola +DCnXXXX puede tener ms de una lnea, pues una nica salida puede tener varios formatos
asociados, que definen partes de un mismo mensaje. En este caso, la cola tendr una lnea por cada
formato de la salida (ver ejemplo 2 de salida no estndar).
Para comunicar a la Arquitectura la existencia de esta salida, se informarn:
DESTINO(1)
IND-PANDOC(1)
NUM-DOCUM(1)
PRILIN-DOCUM(1)
IDIOMA(1)

= '+DC1'
(Debe ser '+DCn')
= 'D'
(Puede ser 'P': a pantalla o 'D': a documento)
= '1'
(Nmero de documento, si procede)
= '05'
(Nmero de lnea donde se comenzar a
escribir la salida en el papel si es un documento
y no se debe comenzar a escribir en la lnea 1)
= 'E'
(Cdigo de idioma del preformato).

__________________________________________________________________________________________________
_
Pg. 43

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.5.3. IMPRESION DESDE TERMINALES 3270.

Debido al predominio de los terminales financieros en los centros de trabajo, se disponan de las
impresoras financieras que reciban las salidas impresas de stos. Sin embargo, los terminales 3270 no
tenan esa funcionalidad y deban contentarse con la salida a pantalla de la informacin requerida,
siempre que fueran transacciones.
Pero ahora existe la posibilidad de poder direccionar la salida a una impresora definida como terminal
de impresin para un terminal 3270. Por lo tanto, cada vez que se genere una salida no estndar de tipo
documento se direccionar esta salida a la impresora asociada, aunque se sigue manteniendo la salida
en la pantalla.
Para ello, es necesario definir un terminal de tipo '51' a la Arquitectura y asociarlo a un terminal 3270
mediante el campo TERMINAL IMPRESORA de la transaccin de Mantenimiento de Terminales de la
Arquitectura (ver documento III.9.3.Mantenimiento de Terminales).

__________________________________________________________________________________________________
_
Pg. 44

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.5.4. EJEMPLOS.
EJEMPLO 1 DE SALIDA NO ESTANDAR.
Supongamos que un programa de aplicacin quiere mandar al terminal dos salidas no estndar:
1.-

El resultado de una consulta del estado de un terminal. La salida ser por pantalla, y no
tiene formato asociado. El mensaje de salida tendr la forma:
USUARIO:
CONSULTA:
CLIENTE:

2.-

XXXX
XX
XXXXXXXX

Un documento, del que se tiene formato asociado. La salida ser a papel. El contenido
ser:
El cliente de clave XXXXXXXX tiene un saldo en su cuenta XXXXXXXXXX de
XXXXXXXXXX Ptas.

Para la salida a pantalla, el programa de aplicacin deber escribir una cola TS llamada '+PF1tttt',
(siendo tttt el contenido del campo de la CAA: TERMINAL), conteniendo tres lneas:
++++5++++0++++5++++0++++5++++0++++5++++0
USUARIO:
AGUAYO
CONSULTA:
SI
CLIENTE:
FHJ83947

que ser la salida tal y como debe verse en la pantalla. Asimismo rellenar los campos de la CAA:
DESTINO(1) =
IND-PANDOC(1) =

'+PF1'
'P'

Para la salida del documento, se deber haber dado de alta un formato asociado al mensaje, que
contendr tres campos:
* Clave de cliente: CLAVECL
* Nmero de cuenta:
NUMCUEN
* Saldo de la cuenta:
SALCUEN
supongamos que el formato dado de alta se llama AARMSAL. Para que se pueda escribir el
documento, el formato deber tener un preformato asociado (referenciado en la columna
PREF_DOCUM de la tabla de formatos en el formato AARMSAL), llammosle AASAL.
El preformato AASAL tendr dos lneas, la primera de ellas:
El cliente de clave @@@@@@@@ tiene un saldo en su cuenta @@@@@@@@@@
haciendo referencia al campo CLAVECL como la primera variable de la lnea, y al campo NUMCUEN
como la segunda variable. La segunda lnea del preformato AASAL ser:
de @@@@@@@@@@ Ptas.
haciendo referencia al campo SALCUEN como la variable de esta lnea.
__________________________________________________________________________________________________
_
Pg. 45

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Si despus de hacer las consultas convenientes, los campos contienen:

* clave de cliente:
* nmero de cuenta:
* saldo:

ABCDEFGH
1234567890
100.000

El programa escribir la cola TS de nombre '+DC1tttt', conteniendo:

AARMSAL
4
0

ABCDEFGH
000000000000
000000000000

00
00

0
0

00
00

0
0

1234567890
FFFFFFFFFF
1234567890

00
00

0
0

0000100000
FFFFFFFFFF
0000100000

y informar los campos de la CAA:

DESTINO(2) = '+DC1'
IND-PANDOC(2) = 'D'
NUM-DOCUM(2) ='1' (Si tiene como documento asociado el DIN A-4 normal)
PRILIN-DOCUM(2) ='05' (Si se desea comenzar a escribir en la lnea 5).
IDIOMA(2) = 'E'

__________________________________________________________________________________________________
_
Pg. 46

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

EJEMPLO 2 DE SALIDA NO ESTANDAR.

Queremos realizar una consulta para obtener un listado de las autorizaciones de un terminal. La salida
ser a papel, y se quiere utilizar preformato de salida. El listado que queremos obtener ser:
tttt

CONSULTA DE AUTORIZACIONES

DD/MM/AAAA

___NUM.AUT.___TERMINAL____COD.ERROR______IMPORTE_______
NNNNNNN XXXXXXXX XXXXXXX
NNNNNNN
NNNNNNN XXXXXXXX XXXXXXX
NNNNNNN
.
.
.
.
.
.
.
.
NNNNNNN XXXXXXXX XXXXXXX
NNNNNNN

Al tratarse de un listado, no se puede utilizar un nico preformato para la salida, pues sta ser
variable dependiendo del nmero de autorizaciones a listar, y en un preformato siempre hay un nmero
fijo de lneas.
Se debe jugar con las partes fijas del mensaje de salida que sern:
* La cabecera del listado
* Una lnea de detalle del listado
Para obtener esta salida, se deben dar dos preformatos de alta, con dos formatos asociados a su vez,
uno para la cabecera y otro para la lnea de detalle.
El formato asociado a la cabecera tendr dos campos (llammosle AARMCAB):
- Cdigo del terminal
: TERMIN
- Fecha en formato DD/MM/AAAA : FECHA
El formato AARMCAB tendr un preformato asociado para documento (campo PREF_DOCUM)
llamado, por ejemplo, AACAB, y que tendr tres lneas. La primera de ellas ser:
@@@@

CONSULTA DE AUTORIZACIONES

@@@@@@@@@@

donde la primera variable har referencia al campo TERMIN, y la segunda al campo FECHA. La
segunda lnea estar en blanco, y la tercera ser:
___NUM.AUT.___TERMINAL____COD.ERROR______IMPORTE_______

no haciendo referencia a ninguna variable.

Las lneas de detalle tendrn otro formato asociado (llammosle AARMLIN), con cuatro campos:
- Nmero de autorizacin
- Cdigo de terminal
- Cdigo de error
- Importe

: NUMAUT
: CODTERM
: CODERR
: IMPORTE

El formato AARMLIN tendr un preformato asociado para documento (campo PREF_DOCUM)

llamado, por ejemplo, AALIN, y que tendr una lnea:
@@@@@@@

@@@@@@@@

@@@@@@@

@@@@@@@

__________________________________________________________________________________________________
_
Pg. 47

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

donde la primera variable har referencia al campo NUMAUT, la segunda a CODTERM, la tercera a
CODERR y la cuarta a IMPORTE.
Una vez dados de alta estos formatos y preformatos de salida, el programa de aplicacin solamente
deber acceder a la informacin y escribir en la cola +DC1XXXX:
* un primer item con el nombre y el contenido del formato de cabecera (AARMCAB).
* un item por cada autorizacin a listar, con el nombre y el contenido del formato de lneas
(AARMLIN).
as como informar los campos correspondiente en CAA-DESTINO.
As, si existieran dos autorizaciones a listar, se escribiran tres tems en la cola TS +DC1tttt, la primera
de ellas conteniendo:
AARMCA
B
4
0

P999
00000000000
00000000000

00
00

09/09/1990

0
0

00
00

0
0

y cada una de las dos siguientes conteniendo:

AARMLIN
4
0

0000001
000000000000
000000000000

00
00

0
0

P999
00
00

0
0

QGE0033
00
00

0
0

0001000
00
00

0
0

00
00

0
0

y la ltima:
AARMLIN
4
0

0000002
000000000000
000000000000

00
00

0
0

P999
00
00

0
0

QGE0044
00
00

0
0

0445640

en los campos de la commarea CAA:

DESTINO(1) =
IND-PANDOC(1) =
NUM-DOCUM(1) =
PRILIN-DOCUM(1) =
IDIOMA(1) =

'+DC1'
'D'
(Si tiene documento asociado)
(Si no debe comenzar a escribir en la lnea 1)
(Si se desea distinto del asignado al terminal).

II.6. ACTUALIZACION DE JOURNAL Y TOTALES.

__________________________________________________________________________________________________
_
Pg. 48

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

La Arquitectura mantiene dos tablas que registran los movimientos contables que se producen en el
proceso on-line diario, tanto en la divisa que se establece por defecto para la entidad como en aquellas
otras con las que se opere en una sesin. Estas tablas son:
Tabla de Journal (QGDTJOU)
Tabla de Totales Contables (QGDTTOT).
Tabla de Operaciones Contables por Usuario (QGDTOCU).
Para que la Arquitectura grabe la correspondiente fila de Journal, el programa de aplicacin debe
escribir una cola TS llamada
'+TOTxxxx' (xxxx: cdigo de terminal, es decir, campo TERMINAL de la commarea de
la Arquitectura -CAA-)
con el siguiente contenido por fila (esta plantilla queda recogida en el manual tcnico de la Arquitectura
con el nombre D615.QGDTJUA {copy QGECJUA}):
ENTIDAD: Cdigo de la entidad contable en 4 caracteres.
CENTRO: Cdigo del centro contable en 4 caracteres.
NETNAME: Cdigo del terminal contable en red en 8 caracteres.
APLICACION: Cdigo de la aplicacin en 2 caracteres. (*)
SECUENCIA: Nmero de secuencia para cada aplicacin. (*)
IMPORTE: En formato numrico empaquetado de 7 caracteres de longitud.
INDICADOR DEBE O HABER: Indicador de si se debe acumular al debe o al haber del total.
INDICADOR CAJA O COMPENSACION: Indicador de si se debe acumular a caja o
compensacin del total.
INDICADOR DE ACUMULAR TOTALES: Con valor 'S' o 'N', si se quiere que se acumule
en totales las cantidades ('S') o slamente quiere que se escriba el journal ('N'). Tiene 1 carcter
de longitud.
PRODUCTO: Clave de producto asociado en 20 caracteres.
REFERENCIA: Referencia de la operacin en la aplicacin, en 20 caracteres.
MAS INFORMACION: Ms informacin adicional de la operacin en 20 caracteres. Para uso
posterior por parte de las aplicaciones.
SUBCLASIFICACION CONTABLE: En 3 caracteres.
FECHA CONTABLE: Fecha contable de la aplicacin en formato DB2 DD-MM-AAAA. La
Arquitectura validar que la fecha contable aqu informada coincide con la que est tratando la
Arquitectura.
DATOS PROPIOS DE LA APLICACION: Informacin propia para que le sea grabada en la
tabla de Journal por la Arquitectura. Puede tener entre 0 y 750 caracteres de longitud.
(*)La aplicacion + un nmero de secuencia constituye la clave del total contable. Si una aplicacin
desea que se acumulen totales, debe tener esta clave (aplicacin + secuencia) dada de alta en la tabla
de totales de referencia (QGDTRTO).
Para las aplicaciones que se definan como MULTIDIVISA, se debern informar los campos necesarios
de la siguiente manera:

IMPORTE: Se informar con un valor 0.

* DATOS PROPIOS DE LA APLICACION: Dentro de este rea de informacin propia de la
aplicacin se debern incluir los valores siguientes, utilizando la copy QGECJUAD a
continuacin de la estndar:

__________________________________________________________________________________________________
_
Pg. 49

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

o
o
o

DIVISA: Cdigo de la divisa en la que se ha hecho la operacin. Se debe informar

siempre aunque se haya realizado en la moneda por defecto de la entidad. Es de 3
posiciones alfanumricas.
IMPORTE-DIV: Valor numrico de la operacin en la divisa indicada. Es un campo
empaquetado que recoge un nmero de 15 enteros y 2 decimales con signo.
El resto de la longitud del campo de datos propios se utilizar para lo que requiera la
aplicacin. Con posterioridad, la Arquitectura se encargar de hacer las transformaciones
necesarias para grabar en la tabla del journal slo esta informacin dentro del campo de
datos propios, puesto que los otros valores utilizados (divisa e importe) se grabarn en los
campos disponibles a tal efecto.

Se pueden escribir en la cola TS +TOTXXXX tantos registros como se desee, resultando grabadas en
el journal tantas filas como registros haya en la cola TS.
La Arquitectura, antes de grabar el contenido de la cola TS en el Journal, valida que la operacin sea
contable (es decir, el indicador CONTABLE de la CAA tenga valor 'S'). Adems, si la aplicacin est
definida como NO multidivisa, tomar como divisa de la operacin la que se haya establecido por
defecto para cada entidad.
Si adems de grabar en el Journal, la aplicacin desea mantener sumarizados los totales, deber poner
el indicador de "acumular totales" de la cola TS con el valor 'S', y la Arquitectura acumular en el total
correspondiente de la tabla de Totales los importes y el nmero de operaciones, en la divisa de la
operacin.
Debido al nmero de totales que se deben generar para cada entidad y para evitar problemas de
bloqueos en las actualizaciones en cada operacin contable, la tabla diaria de totales se preformatea
para cada terminal y tipo de total en la cadena batch de Arquitectura, dejando preparados aquellos
totales considerados como de preformateo esttico en la divisa que se toma como defecto para la
entidad.
Durante la sesin contable se crearn aquellos totales que estn definidos como de creacin dinmica,
junto con todos los necesarios en las divisas distintas de la tomada por defecto con las que se vayan
realizando operaciones en cada terminal.
Asimismo, si se produce el alta de un nuevo terminal o un nuevo tipo de referencia de totales, los
totales contables se irn creando a medida que se necesiten, independientemente de la divisa de la
operacin a realizar.
Por ltimo indicar que, en dilogos conversacionales, la Arquitectura grabar Journal y Totales
solamente cuando la accin que devuelve el programa de aplicacin sea "Terminal".
Para el Terminal Financiero FFS/Altamira, se ha habilitado la nueva funcionalidad de Totalizacin por
Usuario, almacenndose los importes acumulados para cada uno de los cuatro diferentes usuarios que
se permiten en cada terminal y sesin. Para permitir las consultas por usuario se crean las tablas de
Operaciones Contables por Usuario con referencia a las operaciones contables generales (tabla
QGDTJOU).

II.7 FUNCIONAMIENTO DE LAS AUTORIZACIONES.

El proceso de autorizacin permite realizar una serie de operaciones especiales previa identificacin de
un usuario que las "autorice" y que queda registrado como sujeto responsable de dicha operacin.
__________________________________________________________________________________________________
_
Pg. 50

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 51

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.7.1. AUTORIZACIONES DESDE EL PUNTO DE VISTA DEL TERMINALISTA.

Desde el punto de vista del terminalista, el proceso de autorizacin es el siguiente:
1.- Se lanza una transaccin y se recibe un mensaje de error indicando que la operacin necesita
autorizacin con el motivo y nmero de secuencia que se muestran (el nmero de secuencia que
aparece para la autorizacin tiene sus dos ltimos dgitos coincidentes con el da contable, y a partir
del tercero, nmeros secuenciales para un mismo terminal; por ejemplo, para la fecha contable
24/09/1990, los nmeros de secuencia que aparecern sucesivamente en un terminal sern 124, 224,
324, 424, 524, etc.). Se debe recoger este nmero de secuencia y el cdigo de error asociado al
mensaje que aparece en pantalla, as como el importe asociado a la operacin.
2.- Si se desea que la operacin la autorice otro usuario, ste deber identificarse, y ejecutar la
transaccin QG34 desde cualquier terminal con los datos de la autorizacin (nmero de secuencia,
terminal donde se produjo, cdigo de error e importe asociados).
3.- Si el resultado de la autorizacin ha sido correcto ( o lo que es lo mismo, el usuario tena el perfil
requerido para autorizarla) se puede proceder ya a lanzar la autorizacin ejecutando la transaccin
QG00. Solamente se podr lanzar una autorizacin cuando la entidad del terminal desde la que se
lanza coincida con la entidad asociada a la operacin que origin la autorizacin.
El esquema que se sigue cuando se produce una autorizacin es el siguiente:
Terminal
Lanza una transaccin

Arquitectura
----->

Progr. Aplicacin
------------> La operacin que se
desea realizar necesita autorizacin,
con un perfil de
usuario determinado.

La Arquitectura
da de alta un <-----------registro en la
tabla de autorizaciones
para el terminal donde
se ejecuta la transaccin.
Pone el nmero de
secuencia de la
Aparece el mensaje
autorizacin en una
de error pidiendo <----- de las variables del menautorizacin, con
saje de salida.
el nmero de secuencia.

Enva mensaje de
error indicando la
necesidad de autorizacin y el perfil
requerido.
Informa los campos
correspondientes
en el rea CAA (si
es un programa diseado para la Arquitectura Extendida) o de la
CAE (en programas
Altamira).

El terminalista debe recoger el nmero de secuencia de la autorizacin (que junto a su cdigo de

terminal es la clave de la autorizacin), el cdigo de error del mensaje que aparece en pantalla, y el
importe asociado a la transaccin.
Desde el mismo terminal se puede ejecutar cualquier otra transaccin/es.
Si se desea que otro usuario conste como que autoriza la transaccin, se debe ejecutar la transaccin
QG34 (Autorizacin por otro usuario y terminal) desde cualquier terminal, con los campos de entrada:
__________________________________________________________________________________________________
_
Pg. 52

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

NMERO DE SECUENCIA: De la autorizacin que se quiere "firmar".

CODIGO DE TERMINAL: Terminal donde se produjo la autorizacin. Si no se teclea, es el
mismo en el que se est ejecutando la transaccin QG34.
CODIGO DE ERROR: Cdigo de error del mensaje asociado a la autorizacin.
IMPORTE: Importe asociado a la operacin que necesita autorizacin.

La Arquitectura recoge la "firma" del usuario que realiza esta transaccin QG34 como usuario que
realizar la autorizacin cuando sta se lance mediante la transaccin de lanzamiento de autorizaciones.
Si la transaccin QG34 no se realiza antes de la de Lanzamiento de autorizaciones (QG00), el usuario
que constar como que autoriza ser el identificado cuando se ejecute la transaccin QG00.
Esta transaccin de lanzamiento de autorizaciones (QG00) se ejecuta desde el propio terminal, y sus
campos de entrada son los siguientes: NMERO DE SECUENCIA, CODIGO DE ERROR e
IMPORTE).

El esquema cuando se lanza la autorizacin es:

Terminal
Lanzamiento de la
transaccin QG00.

Arquitectura
----->

Progr. Aplicacin

Se accede a la tabla
de autorizaciones.
Si la autorizacin ha
sido ya autorizada
mediante QG34 o QG61
se continuar con un
START pasando al programa
de aplicacin el o los
cdigos de error y los
importes asociados.

__________________________________________________________________________________________________
_
Pg. 53

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________
Si an no ha sido autorizada, se validar
que coincidan el
cdigo de error y el
importe con los de la
tabla de autorizaciones,
as como que la entidad
asociada al terminal
coincida con la asociada
a la autorizacin, y se
verificar que el perfil
del usuario que ejecuta la
QG00 es el necesario. Se
pasar el usuario a la tabla
de autoriz. como usuario
autorizador y a continuacin
se realiza un START de la
transaccin pasndole al
programa de aplicacin el o los
cdigos de error y los importes
asociados.
--------> El programa de
aplicacin realiza
la operacin.
Cuando llega a la validacin que la vez
anterior provoc la
autorizacin, se percata de que ya est
autorizada, y sigue
con el proceso. Si no
existen ms motivos de
autorizacin, finaliza
normalmente la operacin, y manda la salida al terminal indicando que se ha terminado el proceso con
Recibe mensaje de <-------------------------------- normalidad
AUTORIZACION LANZADA
y despus la salida
de la transaccin ejecutada despus de la autorizacin.

Se ver el siguiente ejemplo:

Se supone que en una transaccin de reintegro en una libreta, se pide autorizacin por los siguientes
motivos:
- cuando el reintegro sea por una cantidad superior a 1.000.000 Ptas.
- cuando el saldo resultante despus del reintegro sea negativo.
- cuando la libreta figure como perdida.
y se quiere realizar un reintegro de 2.000.000 en una libreta con saldo 1.999.000 Ptas. Al teclear la
transaccin de reintegro de libreta desde el terminal P999, aparecer un mensaje como este:
RAE0001 LA CANTIDAD 2.000.000,00 NECESITA AUTORIZACION 124
Se deben guardar el cdigo RAE0001, la cantidad 2.000.000 y el nmero de secuencia 124.
__________________________________________________________________________________________________
_
Pg. 54

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

El usuario que realiz la transaccin de reintegro desea que el usuario PACORA (que tiene el perfil
requerido para realizar la autorizacin) autorice la operacin. El usuario PACORA debe ejecutar la
transaccin QG34, dando los datos de la autorizacin siguientes:
NMERO DE SECUENCIA:
124
CODIGO DE ERROR:
RAE0001
IMPORTE:
2000000
TERMINAL:
P999
Ahora, ya puede el usuario inicial lanzar la autorizacin cuando desee, ejecutando la QG00 con los
campos de entrada:
NMERO DE SECUENCIA:
124
CODIGO DE ERROR:
RAE0001
IMPORTE:
2000000
Ahora ya est autorizado el reintegro de ms de 1.000.000. Pero ahora, se validar que el saldo
quedar negativo en la cuenta, y aparecer otro mensaje:
RAE0023 EL SALDO QUEDARA NEGATIVO EN 1.000,00 PTAS. AUTORIZACION
224
Se deben guardar el cdigo RAE0023, la cantidad 2.000.000 y el nmero de secuencia 224.
Si ahora no se desea que otro usuario "firme" la autorizacin, se puede lanzar directamente la
transaccin QG00 de lanzamiento de autorizaciones con los campos de entrada:
NMERO DE SECUENCIA:
224
CODIGO DE ERROR:
RAE0023
IMPORTE:
2000000
Este lanzamiento de la autorizacin acabar correctamente si el usuario que esta conectado al terminal
tiene el perfil necesario para autorizar la necesidad de autorizacin que se pretende autorizar.
Suponemos que el usuario tena el perfil requerido, y que por lo tanto no ser necesario que otro
usuario a travs de la QG34 le autorice esta necesidad de autorizacin.
Si el programa de aplicacin de la transaccin de reintegro en una libreta no encuentra ningn otro
error, se llevar a cabo la operacin, y aparecer por el terminal la salida normal de la transaccin de
reintegro, por ejemplo:
OPERACION REALIZADA
Sin embargo, si en el intervalo entre el comienzo de la operacin y el lanzamiento de la operacin, se ha
realizado un reintegro sobre la misma cuenta de 5.000 ptas, el saldo al lanzar la autorizacin sera de
1.994.000 Ptas., por lo que el descubierto por el que se pidi autorizacin (1.000 Ptas.) no seria el
mismo, y se debera volver a pedir autorizacin por el mismo motivo (descubierto) pero con un importe
diferente. En este caso, aparecera un mensaje:
RAE0023 EL SALDO QUEDARA NEGATIVO EN 6.000,00 PTAS. AUTORIZACION 324
A continuacin se recoge el proceso de autorizaciones desde el punto de vista de los dos tipos de
programas de aplicacin que pueden utilizar la Arquitectura:
Programas de aplicacin diseados para funcionar directamente en la Arquitectura Extendida
(apartado 2).
Programas de aplicacin que, habiendo sido diseados para funcionar bajo la Arquitectura
Estndar, son ejecutados en la Arquitectura Extendida (apartado 3).
__________________________________________________________________________________________________
_
Pg. 55

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 56

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.7.2. AUTORIZACIONES DESDE EL PUNTO DE VISTA DE LOS PROGRAMAS

DE APLICACION.
En este apartado se describe el proceso de autorizaciones, desde el punto de vista de los programas de
aplicacin diseados para funcionar directamente en la Arquitectura Extendida.
En este proceso, una misma operacin puede tener hasta un mximo de 10 motivos por los que se pida
autorizacin. Cada uno de ellos queda recogido en las 10 ocurrencias del grupo CAA-AUTORIZ dentro
de la commarea de la Arquitectura (CAA). Cada una de estas ocurrencias contiene dos campos:
CODERR-AUT: Cdigo de error que se autoriza. Cuando no se ha realizado la autorizacin
aparecer a espacios, mientras que la Arquitectura lo pondr con su correspondiente cdigo de
error cuando se haya autorizado la operacin. El cdigo de error, cuando venga informado,
estar en la misma ocurrencia en que se inform cuando se pidi la autorizacin.
SITUACION-AUT: Situacin en la que se produjo la necesidad de autorizacin. Contendr el
importe con el que se ha autorizado el cdigo de error asociado. Es de utilidad en aquellos casos
en los que, a pesar de haberse realizado la autorizacin de una operacin, esta situacin haya
cambiado, en cuyo caso quizs sea necesario pedir autorizacin de nuevo por la misma
operacin.
El programa de aplicacin que requiera autorizacin por varias causas, puede proceder de dos maneras:
2.1- Pedir distintas autorizaciones al terminalista por cada uno de los motivos que requieran
autorizacin. Este es el caso de las "autorizaciones simples".
2.2.- Pedir una nica autorizacin al terminalista por todos los motivos que requieren
autorizacin. Este es el caso de las "autorizaciones mltiples".

2.1- Autorizaciones simples.

Si se desea pedir autorizacin expresa para cada una de las causas por las que se requiere autorizacin,
el programa de aplicacin deber comprobar cada uno de los motivos de autorizacin, hasta que
encuentre el primero por el que necesita autorizacin y no se la han proporcionado todava (es decir que
el cdigo de error asociado a esta autorizacin no aparezca en ninguna de las 10 ocurrencias del campo
CODERR-AUT de la CAA, o bien que este cdigo de error aparezca, pero la situacin correspondiente
recogida en el campo SITUACION-AUT haya variado y se necesite de nuevo una autorizacin por el
mismo motivo).
En este caso, el programa debe terminar su proceso pidiendo una autorizacin. Para ello, ha de
informar los campos AUTORIZACION de la commarea CAA de la siguiente manera:
o
Informar la correspondiente ocurrencia del campo CODERR-AUT con el cdigo de
error asociado a la autorizacin.
o Si el cdigo de error aparece en alguna de las ocurrencias del campo CODERR-AUT, pero la
situacin ha variado, solamente ser necesario actualizar el nuevo valor en la ocurrencia
correspondiente del campo SITUACION-AUT.
o
Poner el indicador IND-AUTO de la CAA con valor 'S' (pendiente de autorizar).
o
Asignar el importe asociado a la operacin al campo IMPORTE-AUTO.
__________________________________________________________________________________________________
_
Pg. 57

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

o
o

Si se considera necesario, informar el campo REFER-AUTO con una referencia o

comentario de la operacin segn la aplicacin. Este campo es interesante puesto que aparece
cuando se consulta la autorizacin desde el terminal.
El programa tambin debe informar un cdigo de error en el campo COD-ERROR de
la CAA, que ser el correspondiente al mensaje de error que aparecer por pantalla, y que en
caso de pedir una autorizacin simple coincidir normalmente con el informado en el campo
CODERR-AUT.

Cabe sealar que los errores utilizados para pedir autorizacin en el campo COD-ERROR (los que
aparecern como mensaje de error por pantalla), deben tener al menos una parte variable libre que no
informar el programa de aplicacin, y que corresponder al nmero de autorizacin pendiente. Esta
variable ser informada por la Arquitectura y deber tener una longitud de 9 caracteres en el literal del
mensaje.
2.2- Autorizaciones mltiples.
Si se desea pedir una nica autorizacin por todos los motivos que requieren autorizacin en la
operacin, el programa deber continuar su proceso cada vez que encuentre un motivo sin autorizar
todava, informando en cada caso las ocurrencias correspondientes de los campos CODERR-AUT .
Si en alguno de los casos, se encuentra informado el campo CODERR-AUT y sin embargo la situacin
recogida en SITUACION-AUT ha variado, tambin se debera volver a pedir autorizacin.
Al final, el programa terminar su proceso pidiendo autorizacin a la Arquitectura, informando los
campos:
o Poner el indicador IND-AUTO de la CAA con valor 'S' (pendiente de autorizar).
o Asignar el importe asociado a la operacin al campo IMPORTE-AUTO.
o Si se considera necesario, informar el campo REFER-AUTO con una referencia o comentario
de la operacin segn la aplicacin. Este campo es interesante puesto que aparece cuando se
consulta la autorizacin desde el terminal.
o Tambin debe informar un cdigo de error en el campo COD-ERROR de la CAA, que en el
caso de autorizaciones mltiples deber corresponder a un literal indicativo de todos los errores
que se producen, por lo que podra no coincidir con ninguno de los cdigos de error
informados en los campos CODERR-AUT.
En este caso, el literal de este error tambin debe tener al menos una parte variable de 9 caracteres en la
que la Arquitectura informar el nmero de autorizacin pendiente, y que el programa de aplicacin no
debe informar.
Ejemplos:
Siguiendo con el ejemplo anterior, se ver a continuacin lo que debera hacer el programa asociado a
la transaccin de reintegro de una libreta.
En primer lugar, se supone que se tienen autorizaciones simples, y que se pedir autorizacin expresa
para cada uno de los dos motivos (reintegro de ms de 1.000.000 y saldo en nmeros rojos como
resultado), por lo que se producirn dos autorizaciones.
La primera vez que se ejecuta la transaccin de reintegro en libreta, todos las ocurrencias del grupo
AUTORIZ de la CAA apareceran a espacios. Cuando el programa de aplicacin verifica que el
reintegro es por una cantidad superior a 1.000.000, terminara su proceso informando los campos de la
commarea CAA siguientes:
__________________________________________________________________________________________________
_
Pg. 58

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

* CODERR-AUT(1)
* IND-AUTO
* IMPORTE-AUTO
* REFER-AUTO
* COD-ERROR
* VAR1-ERROR

= 'RAE0001'
= 'S'
= 2000000
= 'CANTIDAD MAYOR DE 1000000'
= 'RAE0001'
= 2000000

Donde, en la tabla de errores, el de cdigo RAE0001 tendr un literal asociado de la forma:

LA CANTIDAD @@@@@@@@@ NECESITA AUTORIZACION @@@@@@@@@
La segunda parte variable del error no la informa el programa de aplicacin, porque es la
correspondiente al nmero de autorizacin, que ser comunicado por la Arquitectura.
En el terminal aparecer el mensaje:
RAE0001 LA CANTIDAD 2.000.000,00 NECESITA AUTORIZACION 124
Cuando el terminalista lance la autorizacin 124, al programa de aplicacin le llegar el campo
CODERR-AUT(1) con el contenido 'RAE0001', por lo que cuando llegue a chequear el motivo de ser
un reintegro de ms de 1.000.000 Ptas, al tener ya informado su cdigo de error (RAE0001) en una
ocurrencia de CODERR-AUT, seguir su proceso.

Ms adelante, el programa de aplicacin comprueba que el saldo de la libreta quedar con un

descubierto de 1.000 Ptas., por lo que tiene que volver a pedir autorizacin por este motivo. Si el
cdigo de error asociado al motivo de saldo negativo es 'RAE0023', informar los campos de la
commarea CAA:
* CODERR-AUT(2)
= 'RAE0023'
* SITUACION-AUT(2)
= 1000
(descubierto que se va a autorizar)
* IND-AUTO
= 'S'
* IMPORTE-AUTO
= 2000000
* REFER-AUTO
= 'SALDO NEGATIVO DE 1000'
* COD-ERROR
= 'RAE0023'
* VAR1-ERROR
= 1000
Donde, en la tabla de errores, el de cdigo RAE0023 tendr un literal asociado de la forma:
EL SALDO QUEDARA NEGATIVO EN @@@@@@@ PTAS. AUTORIZACION
@@@@@@@@@
La segunda parte variable del error no la informa el programa de aplicacin, porque es la
correspondiente al nmero de autorizacin, que ser comunicado por la Arquitectura.
En el terminal aparecer el mensaje:
RAE0023 EL SALDO QUEDARA NEGATIVO EN 1.000,00 PTAS. AUTORIZACION
224
__________________________________________________________________________________________________
_
Pg. 59

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Cuando el terminalista lance la autorizacin 224, al programa de aplicacin le llegarn los campos con
los valores siguientes:
CODERR-AUT(1) = 'RAE0001'
CODERR-AUT(2) = 'RAE0023'
SITUACION-AUT(2)
= 1000
Cuando llegue a chequear los motivos de autorizacin, si la situacin de la autorizacin de descubierto
produce un nuevo descubierto de 1.000 ptas o menos, se seguir el proceso, y se realizar la operacin
de reintegro. Por el contrario, si el nuevo descubierto que se produce es superior a 1.000 ptas., se debe
volver a pedir autorizacin informando los campos:
* SITUACION-AUT(2)
* IND-AUTO
* IMPORTE-AUTO
* REFER-AUTO
* COD-ERROR
* VAR1-ERROR

= 6000
(descubierto que se va a autorizar)
= 'S'
= 2000000
= 'SALDO NEGATIVO DE 6000'
= 'RAE0023'
= 6000

En el terminal aparecer el mensaje:

RAE0023 EL SALDO QUEDARA NEGATIVO EN 6.000,00 PTAS. AUTORIZACION
324
Se ver ahora el ejemplo en el caso de autorizaciones mltiples, donde se pide una nica autorizacin
para los dos motivos. La primera vez que se ejecuta la transaccin de reintegro en libreta, todos las
ocurrencias del grupo AUTORIZ de la CAA apareceran a espacios. Cuando el programa de aplicacin
verifica que el reintegro es por una cantidad superior a 1.000.000, informara la primera ocurrencia del
campo CODERR-AUT que estuviera libre con el cdigo de error correspondiente, y continuara su
proceso:
* CODERR-AUT(1) = 'RAE0001'
Al llegar a la verificacin de saldo negativo, informara la primera ocurrencia del campo CODERRAUT que estuviera libre, y su situacin, y continuara su proceso:
* CODERR-AUT(2)
* SITUACION-AUT(2)

= 'RAE0023'
= 1000

Al final del programa, y antes de realizar la operacin de reintegro, se terminar el proceso pidiendo a
la Arquitectura autorizacin con los campos:
* IND-AUTO
= 'S'
* IMPORTE-AUTO
= 2000000
* REFER-AUTO
= 'AUTORIZACION MULTIPLE'
* COD-ERROR = 'RAE0099'
* VAR1-ERROR = 1000
Donde, en la tabla de errores, el de cdigo RAE0099 tendr un literal asociado de la forma:
CANTIDAD DE REINTEGRO Y DESCUBIERTO DE @@@@@@@ Pts. AUTORIZ:
@@@@@@@@@
__________________________________________________________________________________________________
_
Pg. 60

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

La segunda parte variable del error no la informa el programa de aplicacin, porque es la

correspondiente al nmero de autorizacin, que ser comunicado por la Arquitectura.
En el terminal aparecer el mensaje:
RAE0099 CANTIDAD DE REINTEGRO Y DESCUBIERTO DE 1.000,00 Pts.
AUTORIZ: 124
Cuando el terminalista lance la autorizacin 124, al programa de aplicacin le llegarn los campos:
CODERR-AUT(1)
CODERR-AUT(2)
SITUACION-AUT(2)

= 'RAE0001'
= 'RAE0023'
= 1000

Si al llegar al motivo del saldo negativo, el nuevo descubierto que se produce es de 1.000 Ptas. o
menor, continuara el proceso, realizando el reintegro.
Si, por el contrario, el nuevo descubierto es mayor de 1.000 Ptas., se debe volver a pedir autorizacin,
informando los campos:
SITUACION-AUT(2)
IND-AUTO
IMPORTE-AUTO
REFER-AUTO
COD-ERROR
VAR1-ERROR

= 6000
= 'S'
= 2000000
= 'DESCUBIERTO DE 6000 PTS'
= RAE0023
= 6000

En el terminal aparecer el mensaje:

RAE0023 EL SALDO QUEDARA NEGATIVO EN 6.000,00 PTAS.
AUTORIZACION 224

__________________________________________________________________________________________________
_
Pg. 61

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.7.3. AUTORIZACIONES DESDE EL PUNTO DE VISTA DE LOS PROGRAMAS

ALTAMIRA.
En este apartado se describe el proceso de autorizaciones, desde el punto de vista de los programas de
aplicacin diseados para la Arquitectura Estndar, que se ejecutan bajo la Arquitectura Extendida. El
esquema del proceso es el siguiente:
3.1) Si el programa de aplicacin detecta la necesidad de que una determinada operacin (por ej., un
cliente tiene saldo insuficiente a la hora de realizar un reintegro) sea autorizada, el programa
debe terminar su proceso pidiendo una autorizacin. Para ello, ha de completar los campos
AUTORIZACION-AREA de la commarea CAE (commarea para programas Estndar) de la
siguiente forma:
o Informar la(s) correspondiente(s) ocurrencias del campo TIPOS-AUTORIZACION con el
valor '1 '. Existen tipificados hasta 60 conceptos o cdigos de autorizacin diferentes (uno
en cada ocurrencia).
o Poner el indicador ST-AUTORIZACION de la CAE con valor '1' (pendiente de autorizar).
o Si se desea, activar el indicador ST-SUPERVISOR de la CAE con valor 'S', para que el
usuario que ejecute la transaccin de autorizacin tenga categora de Supervisor.
o Asignar el importe asociado a la operacin al campo IMPORTE.
o Tambin debe informar el campo ERROR-CODE (fuera del rea de autorizaciones de la
CAE) con el cdigo de error asociado al mensaje descriptivo de la autorizacin requerida,
que ser el correspondiente al mensaje de error que aparecer por pantalla.
o Cabe sealar que los errores utilizados para pedir autorizacin en el campo ERROR-CODE
(los que aparecern como mensaje de error por pantalla), deben tener una parte "variable"
libre en su texto asociado, que corresponder al nmero de autorizacin pendiente. Esta
variable ser informada por la Arquitectura y deber tener una longitud de 9 caracteres en el
literal del mensaje.
3.2) A continuacin, el programa Estndar cede control a la Arquitectura (que convertir la commarea
CAE a sus correspondientes valores de la CAA), y sta graba un registro en la Tabla de
Autorizaciones (QGDTAUT). La Arquitectura convierte la informacin relativa a
autorizaciones, suministrada en la CAE, de la siguiente forma:
o El indicador ST-AUTORIZACION de la CAE se traduce en el campo IND-AUTO de la
CAA, que indica a la Arquitectura que se trata de una autorizacin, por lo cual ha de grabar
el registro correspondiente en la Tabla de Autorizaciones.
o Cada ocurrencia de TIPOS-AUTORIZACION (de la CAE) que se haya informado con
valor '1 ' se traduce en una ocurrencia de AUTORIZ de la CAA (del registro a insertar en la
Tabla de Autorizaciones), en cuyos campos se informan los siguientes valores:
En CODERR-AUT (en la CAA y en la tabla) se pone el cdigo de error informado en
CAE-ERROR-CODE.
SITUACION-AUT (en la CAA y en la tabla) se deja a espacios.
El campo POSIC-ALTAMIRA (en la Tabla de Autorizaciones) se informa con el
nmero de orden que tiene la ocurrencia dentro del grupo TIPO-AUTORIZACION (de
la CAE), pudiendo tomar un valor comprendido entre 1 y 60.
Asimismo, la Arquitectura informa la correspondiente ocurrencia (1 a 10) de POSICALTAMIRA (en la CIA).
Como puede observarse, la Arquitectura Extendida permite tambin autorizaciones mltiples a
los programas Estndar que se ejecutan bajo la misma. La nica restriccin impuesta a los
mismos es que de las 60 ocurrencias de TIPOS-AUTORIZACION (en la CAE) posibles, no
pueden tener informadas ms de 10 ocurrencias al mismo tiempo.
o El indicador ST-SUPERVISOR de la CAE, se copia en el campo IND-SUPERV (de la
CIA) y en el campo IND-SUPERV (de la Tabla de Autorizaciones).
__________________________________________________________________________________________________
_
Pg. 62

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

El campo IMPORTE, del rea de autorizacin de la CAE, se copia en los campos

IMPORTE-AUTO (en la CAA) e IMPORTE-ULT de la tabla.
o El campo ERROR-CODE (de la CAE) se copia en el campo COD-ERROR de la
CAA.
3.3) Con la conversin antes realizada, la Arquitectura formatea el mensaje de autorizacin y lo
muestra por el terminal.
3.4) Cuando el terminalista decide autorizar la transaccin, arrancar la transaccin general QG00
(nica) de autorizacin. Dicha transaccin solicita al usuario la introduccin de los siguientes
datos:
o Nmero de la autorizacin pendiente.
o Cdigo de error que se desea autorizar.
o Importe asociado a la operacin a autorizar, en el caso de que exista.
o

Obsrvese que un primer nivel de seguridad en el proceso de autorizaciones, podra

consistir en restringir el acceso a la transaccin de autorizacin a unos ciertos usuarios del
sistema (a travs de RACF o, si ste no existe, a travs de la tabla DFHSNT de sign-on al
CICS). De esta forma, slo unos determinados usuarios podran realizar el proceso de
autorizacin.
3.5) La Arquitectura accede a la Tabla de Autorizaciones (QGDTAUT) para recuperar el registro de
autorizacin "dormido" (pendiente de ser lanzado).
Si el indicador IND-SUPERV del registro viene informado con 'S', la Arquitectura debe realizar
adicionalmente la verificacin del hecho de que el usuario tenga nivel de supervisor:
o Si la seguridad es INTERNA (ver II.17. Esquema y recursos de seguridad), el mdulo de
seguridad accede a la Tabla de Supervisores (QGDTSUP) y comprueba que el usuario que
ha realizado la autorizacin se encuentra en la Tabla de Supervisores. Si el usuario est en
la tabla y tiene nivel de supervisor se procede a aceptar la autorizacin realizada. En caso
contrario, se rechaza.
o Si la seguridad es EXTERNA, se accede a la verificacin del usuario y password a travs
del mdulo QC1CPAS. Si todo es correcto, la autorizacin es aceptada y en caso contrario
es rechazada.
3.6) En el caso de que la autorizacin sea aceptada por la Arquitectura (tras comparar el cdigo de
error, el importe y el nmero de secuencia tecleados en la transaccin de autorizacin, frente a
los datos almacenados en el registro de la Tabla de Autorizaciones) y antes de efectuar de nuevo
la llamada al programa de aplicacin, la Arquitectura convierte los datos relativos a
autorizaciones, extrados del registro de la Tabla de Autorizaciones, a la CAE:
o

Cada ocurrencia de AUTORIZ del registro (extrado de la Tabla de Autorizaciones) que

tenga informado el campo CODERR-AUT, se traduce en la ocurrencia TIPOSAUTORIZACION(nn) de la CAE, donde "nn" representa el valor numrico (entre 1 y 60)
almacenado en el campo POSIC-ALTAMIRA (de la ocurrencia AUTORIZ considerada). En
la ocurrencia TIPOS-AUTORIZACION(nn) se informa el valor del cdigo de usuario que
ha autorizado la operacin, almacenado en el campo USERID-AUT (de la ocurrencia
AUTORIZ considerada).

3.7) De esta forma, desde el punto de vista del programa Estndar, la Arquitectura ha sustituido la(s)
ocurrencia(s) que estaban identificadas por '1 ' por el cdigo de usuario que las ha autorizado,
cediendo a continuacin el control al programa de aplicacin.
3.8) El programa comienza de nuevo su proceso y, al detectar de nuevo la necesidad de autorizacin,
comprueba que la ocurrencia en cuestin ya est informada (con el cdigo de usuario), por lo que
reconoce que ha sido autorizada la operacin.
__________________________________________________________________________________________________
_
Pg. 63

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 64

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.7.4. AUTORIZACION EN CONVERSACIONES.

La Arquitectura extendida tambin provee la utilidad de autorizar una operacin dentro de una
conversacin.
Desde el punto de vista del programa de aplicacin, el proceso es exactamente igual que el de peticin
de una autorizacin en una transaccin (a travs del segmento CAA-AUTORIZACION de la
commarea QGECCAA).
Desde el punto de vista del terminalista, el proceso es el siguiente:
Desde una pantalla de una conversacin, y como resultado de una operacin, aparece un mensaje en
pantalla pidiendo autorizacin. El terminalista, si desea autorizar la operacin, deber hacerlo en el
mismo momento de la siguiente manera:
Pulsar la tecla estndar de autorizacin en conversacin (Shift F2).
Aparece una pantalla pidiendo usuario/password/importe de la autorizacin.
Al pulsar la tecla Intro, se realiza el proceso de autorizacin de la operacin, volviendo a
aparecer la pantalla original de la operacin que est autorizando.
La operacin que autoriza es la ltima pendiente en el terminal. Por lo tanto, no permite autorizaciones
diferidas ni remotas.

II.8. FUNCIONAMIENTO DE LA AYUDA ON-LINE.

La Arquitectura de Aplicaciones ofrece una utilidad de ayuda on-line en el idioma del terminal en las
conversaciones que gestiona.
Para acceder a la ayuda on-line desde una pantalla de una conversacin, se debe pulsar la tecla PF1
(tecla estndar de ayuda). Aparecer la pantalla inicial de ayuda asociada (si existe ayuda asociada en
el idioma requerido para la pantalla desde la que se pulsa PF1).
Con las teclas PF8 y PF7, se recorren las sucesivas pantallas de ayuda. Para volver a la pantalla
inicial, basta pulsar la tecla Borra. Aparecer la pantalla desde el que se accedi a la ayuda en el
mismo estado en el que se dej.
Para asociar una ayuda on-line a una pantalla, se deben seguir los siguientes procesos:
1.- Dar de alta la pantalla de ayuda mediante la OPCION 7 del men general de
mantenimiento de tablas de la Arquitectura. Cambiar las descripciones de los literales
para cada idioma de la instalacin.
2.-

Asociar el correspondiente cdigo de ayuda a la transaccin, en el

mantenimiento de transacciones (OPCION 2 del men general de
mantenimiento de tablas de la Arquitectura).

__________________________________________________________________________________________________
_
Pg. 65

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.9. FUNCIONAMIENTO DE LA AYUDA ACTIVA.

La Arquitectura de Aplicaciones ofrece una utilidad de ayuda activa en las conversaciones que gestiona.
Esta ayuda consiste en mostrar los posibles valores de un campo de la pantalla. El usuario podr
seleccionar uno de estos posibles valores, y la Arquitectura lo sustituir en el campo de la pantalla
original.
Para acceder a la ayuda activa desde una pantalla de una conversacin, se debe poner un carcter '?'
en el campo del que se desea la ayuda, y pulsar la tecla PF1 (tecla estndar de ayuda). Aparecer la
pantalla inicial de ayuda asociada, que consiste en una serie de lneas de descripcin del campo, y un
listado de posibles valores de este campo.
Con las teclas PF8 y PF7, se recorren las sucesivas pantallas de ayuda. Se podr:
1.- Seleccionar uno de los valores y pulsar la tecla Intro, con lo que aparecer la pantalla inicial
con el valor seleccionado sustituido en el campo.
2.- Pulsar la tecla Borra, con lo que aparecer la pantalla inicial.
Para asociar una ayuda activa a un campo de una pantalla, se deben seguir los siguientes pasos:
1.- Dar de alta la ayuda activa asocindola al campo de la siguiente forma:
Acceder al mantenimiento del formato al que pertenece el campo (opcin 3 del men).
Acceder al listado de los campos de este formato (PF5).
Seleccionar el campo del que se va a dar de alta la ayuda activa, y pulsar PF4.
__________________________________________________________________________________________________
_
Pg. 66

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

2.-

Dar de alta la ayuda activa de este campo, que consiste en un literal asociado de hasta
10 lneas, y la sentencia SELECT DB2 sobre la tabla de cdigos, que se ejecutar
mediante SQL dinmico en el momento de solicitar la ayuda. (Ver el documento
III.4.7.Mantenimiento de Ayuda Activa).
Acceder al mantenimiento de transacciones, para la transaccin que tiene asociado este
panel de entrada, y poner el indicador de ayuda activa activado. Tambin deber tener el
indicador de PF's estndares activado.

II.10.UTILIZACION DEL TELEDISCO.

El teledisco es un proceso mediante el cual se ejecutan automticamente a travs del teleproceso un
conjunto de transacciones originadas por una aplicacin batch. De esta forma, un proceso batch puede
mandar a un teledisco una transaccin para que se ejecute en el proceso on-line del dia siguiente.
Una aplicacin puede hacer uso de uno o varios telediscos, que deben estar dados de alta en la tabla de
control de telediscos (QGDTTDC).
Adems, por cada proceso batch que pueda mandar una transaccin para que se procese en un
teledisco, debe haber un registro en la tabla de distribucin de telediscos (QGDTTDD), donde se
asocia el proceso batch con el teledisco al que ste enva sus transacciones.
El proceso de teledisco consta de tres partes, que secuencialmente son:
1.- Las aplicaciones generan la carga de la tabla de informacin de telediscos (QGDTTDI) en
ficheros secuenciales.
A partir de los ficheros secuenciales, habr un proceso de carga de la tabla QGDTTDI gestionada
por la Arquitectura.
2.- Arranque del teledisco correspondiente durante el teleproceso. Este lanzar todas sus transacciones
almacenadas durante el proceso batch. Esta operacin es gestionada por la Arquitectura de
Aplicaciones.
3.- Descarga de las filas de un teledisco que se haya procesado y explotacin de informacin.
Inicializacin de las tablas de teledisco para el proceso batch siguiente. Esta operacin es
gestionada por la Arquitectura de Aplicaciones.
__________________________________________________________________________________________________
_
Pg. 67

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 68

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.10.1. CARGA DE LA TABLA DE INFORMACION DE TELEDISCO EN EL

BATCH.
Dentro del proceso de carga de la tabla de informacin de teledisco durante el proceso batch de la
aplicacin, se producen los siguientes operaciones:
1.- En un proceso batch se genera una operacin que est contemplada como una transaccin en la
aplicacin.
2.- El programa batch genera un registro con la plantilla indicada por la Arquitectura en un fichero
secuencial que se utilizar para cargar los telediscos en el proceso batch de la Arquitectura de
carga de telediscos. La estructura de este fichero de entrada queda recogida al final de este
captulo.
3.- Con los ficheros secuenciales generados por las aplicaciones, se procesa la cadena batch de carga
de telediscos. Esta cadena, distribuye cada fila a su correspondiente teledisco segn el proceso
batch y la entidad (clave de la tabla de distribucin de telediscos QGDTTDD).
Esta cadena batch de carga de teledisco validar que antes de comenzar la carga, el teledisco
correspondiente se encuentre en estado vaco (en la tabla de control de telediscos QGDTTDC).
Despus de realizada la carga, el teledisco se marcar como pendiente de
procesar en la tabla de control de telediscos QGDTTDC.

__________________________________________________________________________________________________
_
Pg. 69

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.10.2. PROCESO ON-LINE DEL TELEDISCO.

Las operaciones on-line del teledisco son gestionadas por la Arquitectura de Aplicaciones.
Durante el teleproceso, se arranca el teledisco correspondiente (desde el men general de la
Arquitectura -arrancado desde terminal con el cdigo de transaccin QM-, y con la OPCION 14 y en la
pantalla siguiente OPCION 2, se obtiene un listado de los telediscos que existen. Seleccionando el
teledisco que se quiere arrancar, y con PF2, se accede al panel de arranque/parada de telediscos).
El programa lanzador de transacciones de telediscos, lanzar todas las transacciones, hasta finalizar
todas las de la tabla, marcando:
Cuando se lanza la transaccin (va CICS START), se marcan como lanzadas
(TDI_IND_LANZADA='S').
Cuando se termina de procesar, se marca como procesada (TDI_IND_PROCESO='S').
Las columnas referentes a los mensajes de error/aviso de la tabla de informacin de teledisco
(QGDTTDI) sern actualizadas con los valores que devuelva la transaccin como salida, as como el
resto de las columnas de informacin de la tabla.
Se podr parar el teledisco durante el proceso, quedando en ese caso en estado inactivo, para luego
volver de nuevo a lanzarlo.
Si una fila devuelve un cdigo de error con el carcter B en la tercera posicin, ser la indicacin de la
Aplicacin de que paremos el teledisco.
Si una fila, despus de lanzar todas las transacciones, resulta como lanzada y no figura como
procesada, ser porque se ha terminado la tarea CICS anormalmente entre el momento de lanzar la
transaccin y antes de terminar, es decir, probablemente la propia transaccin pudo haber provocado un
ABEND de la tarea.
Cuando se terminan de lanzar todas las transacciones, el programa lanzador de transacciones de
telediscos marca el estado del teledisco como "finalizado" en la tabla de control de telediscos
(QGDTTDC).

__________________________________________________________________________________________________
_
Pg. 70

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.10.3. DESCARGA Y EXPLOTACION DE INFORMACION DEL TELEDISCO.

La descarga del teledisco se realizar mediante una cadena batch de la Arquitectura, mientras que la
explotacin de informacin del mismo estar cargo de la aplicacin responsable del mismo.
Despus de terminar de lanzar todas las transacciones, se proceder a descargar todos los registros de
la tabla de telediscos, dejando vaco el teledisco para el siguiente proceso batch (previamente a esta
descarga, se habr comprobado que el estado del teledisco en la tabla de control (QGDTTDC) est
como "finalizado").
Se marcar el teledisco en la tabla de control de telediscos (QGDTTDC) con estado "vaco" (en la
columna TDC_ESTADO). Tambin se inicializarn los timestamps y usuarios de lanzamiento inicial
(TDC_TIMEST_LAN, TDC_USERID_LAN), de ltima parada (TDC_TIMEST_STOP,
TDC_USERID_STOP) y ltimo relanzamiento (TDC_TIMEST_REL, TDC_USERID_REL) y el
timestamp de la ltima fila procesada (TDC_TIMEST_ULT) en la misma tabla QGDTTDC.
El fichero de descarga de las filas de la tabla QGDTTDI procesadas, se deber utilizar para obtener la
informacin sobre el resultado del dia del proceso de teledisco. Esta tarea es responsabilidad de la
aplicacin.

__________________________________________________________________________________________________
_
Pg. 71

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.10.4. ESTRUCTURA DEL FICHERO DE ENTRADA PARA LA CARGA DE

TELEDISCOS.
El fichero que las aplicaciones generan para la carga de los telediscos se deber ajustar a la plantilla
indicada en el documento {D610.QGDTTEL}.
Los campos que contiene esta plantilla son:
o PROCESO: Cdigo del proceso batch que ha generado el registro en el fichero. Este campo es
obligatorio y consta de:
APLICACION: Aplicacin a que pertenece el proceso
SECUENC: Cdigo secuencial que se asigna a cada proceso batch.
Esta clave de proceso batch debe estar dada de alta en la tabla de distribucin de telediscos de
la Arquitectura, asociando dicho proceso a un teledisco.
El mantenimiento de esta tabla de distribucin de telediscos se realiza mediante la opcin '12'
del men general de mantenimiento de la Arquitectura.
o

ORIGEN-CONT: Datos del origen contable de la operacin. Se compone de:

ENTIDAD: Entidad contable de la operacin. Es obligatorio.
CENTRO: Centro contable de la operacin. Es obligatorio. El proceso de carga de
telediscos validar que existe la Entidad/Centro en la tabla de centros.
NETNAME: Terminal contable del proceso. No es obligatorio. Si no se informa, el
proceso de carga de telediscos asignar el terminal asociado por defecto al proceso
batch de la tabla de distribucin de telediscos.
Tambin se debe tener en cuenta que si la Entidad/Centro contables asociados al terminal
de la operacin no coinciden con la Entidad/Centro contables asociados al terminal en la
tabla de terminales, no se acumularn totales cuando se ejecute la transaccin en el
teledisco. Todo esto quedar reflejado en el informe de incidencias del proceso batch de
carga de los telediscos.

AUTORIZ: Este grupo contiene 10 ocurrencias con el cdigo de error y la situacin que
entrarn informadas cuando se ejecute la transaccin en el teledisco.
De esta manera, cuando se ejecute la transaccin en el teledisco, lo har como si se
hubiera autorizado la operacin. Es decir, los datos que se encuentren en este grupo,
entrarn de la misma forma en el grupo CAA-AUTORIZ de la commarea de la
transaccin que se ejecute.

REFER-APLIC: Campo de referencia de la aplicacin. Este campo se encontrar tambin en el

fichero de descarga del teledisco procesado.

TIMEST-CREAC: Este campo tendr formato Timestamp de DB2, y es obligatorio. Debe

contener el timestamp de creacin del registro.

DATOS-MENSAJE. Este grupo contiene los datos del mensaje de entrada para la transaccin.
Todos sus campos son obligatorio, y son:

CODTRAN: Cdigo de la transaccin a ejecutar.

TECLA: Tecla pulsada que se tomar cuando se ejecute la transaccin en el teledisco.

__________________________________________________________________________________________________
_
Pg. 72

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

LONG-ENT: Longitud del mensaje de entrada, que se encuentra en el siguiente

campo.
MSG-ENT: Mensaje de entrada de la transaccin en forma BMS. Este campo entrar
tal y como se encuentra en el fichero como pantalla asociada a la transaccin.

II.11. LOG DEL SISTEMA. IMPRESORAS DE SEGUIMIENTO.

La Arquitectura de aplicaciones mantiene una tabla que recoge las incidencias durante el proceso online diario. Esta tabla es la de Log del Sistema. Posteriormente, esta tabla de incidencias se podr
consultar mediante una de las transacciones de la Arquitectura
__________________________________________________________________________________________________
_
Pg. 73

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Asimismo, si se desea, se puede enviar un mensaje a una impresora de seguimiento en el momento en

que se produce la incidencia.
Esta utilidad de la Arquitectura se puede invocar desde un programa de aplicacin realizando un CICS
LINK con el programa QG1CLOG, y pasndole una commarea que consta de los tres campos
siguientes:
o
o

ORIGEN: Campo alfanumrico de 8 caracteres de longitud, con el nombre del programa origen
de la incidencia.
DESTINO: Campo alfanumrico de 8 caracteres de longitud, con el nombre de la impresora de
seguimiento donde se desea enviar el mensaje. Si se informa a espacios, no se enviar el mensaje
a ninguna impresora, pero s se insertar la fila con las caractersticas de la incidencia en la tabla
de Log del Sistema.
MENSAJE: Campo alfanumrico de 150 caracteres de longitud, con el mensaje que quedar
grabado tanto en la impresora de seguimiento como en la tabla de Log del Sistema.

El programa QG1CLOG recoger los dems datos asociados con la incidencia, como el identificador
del CICS donde se produce, la fecha y hora, el usuario identificado, el cdigo de transaccin, etc., y
arrancar la transaccin QGLG (transaccin que se encargar de insertar la fila en la tabla de Log) en
el mismo terminal donde se produce la incidencia si el campo DESTINO se encuentra a espacios, o
bien la transaccin QGSI en el terminal definido como impresora de seguimiento si el campo
DESTINO estuviera informado.
Est a disposicin de las aplicaciones, otro programa denominado QG1CEIS, o bien la transaccin
QGEI, que realiza esta funcin de escritura sobre la impresora de seguimiento.
El propio programa QG1CLOG mantiene internamente una tabla de impresoras de seguimiento,
asociando los nombres (que le llegarn en el campo DESTINO) con el cdigo de terminal asociado a la
impresora.
(** Nota: Si se desea dar de alta una nueva impresora de seguimiento, ser necesario actualizar la tabla
de impresoras interna en cobol del programa QG1CLOG, que se encuentra en forma de COPY en la
librera de Copys, en el miembro QGECIMP, tras de lo cual se debern compilar los programas
QG1CLOG y QG1CEIS --programa ligado a la transaccin de envo de mensajes a impresoras de
seguimiento--).
Slo a efectos de prueba de una nueva impresora de seguimiento, no es necesario que el nombre de la
impresora est contenido en la tabla interna de impresoras del programa QG1CLOG, ya que si ste no
encuentra el nombre de la impresora en su tabla, intenta leer una cola TS llamada de la misma forma
que el nombre informado en el campo DESTINO, y considera que los primeros 4 caracteres del primer
item de esta cola contienen el cdigo de terminal asociado a la impresora.
Como prevencin a posibles interrupciones en la transaccin QGLG (que es la que efectivamente
graba en la tabla de Log), el programa QG1CLOG grabar en la cola TS llamada "QCLOG" (en el
CICS en que se est ejecutando la transaccin), el contenido de la fila que se va a insertar en la tabla de
Log.
En la tabla de Log del Sistema se recogen diversas caractersticas de la
incidencia, como son:
o Fecha en que se produjo la incidencia.
o Hora.
o Identificador del CICS donde se produjo.
o Nmero de la tarea CICS donde se produjo.
__________________________________________________________________________________________________
_
Pg. 74

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

o
o
o
o
o
o
o

Transaccin que se estaba ejecutando.

Cdigo del terminal en red donde se produjo.
Usuario identificado al CICS cuando se produjo la incidencia.
Origen de la incidencia (como puede ser el programa donde se produjo).
Impresora de seguimiento destino del mensaje.
Indicador de error en la escritura en la impresora de seguimiento (S/N).
Contenido del mensaje que se envi a la impresora de seguimiento.

II.12. SUSPENDER / REANUDAR UNA CONVERSACION.

La Arquitectura de Aplicaciones ofrece una utilidad para poder suspender una conversacin en curso.
Despus de suspender la conversacin, se puede realizar cualquier tipo de proceso, y a continuacin
reanudar de nuevo la conversacin en el mismo punto en que se suspendi.
Para suspender una conversacin, existe una tecla estndar que es Shift+F1 (o PF11). Al pulsarla, se
borra la pantalla y aparece un mensaje indicando que la conversacin est suspendida o finalizada.
Para reanudar de nuevo la conversacin, basta con ejecutar la transaccin de reanudar, de cdigo
QG99. Esta transaccin no tiene campos de entrada. Se reanuda la ltima conversacin suspendida, en
el mismo contexto en que se suspendi.

II.13. EDICION DE CAMPOS NUMERICOS EN TERMINALES 3270.

La Arquitectura de Aplicaciones ofrece una utilidad para el tratamiento de los campos numricos en
terminales 3270.
Cuando el terminal es de tipo PS o 4700, la edicin de los campos numricos (edicin de puntos y
comas) se realiza en local, de tal manera que los datos que se envan al Host solamente contiene los
dgitos numricos.
El terminal 3270 no tiene esta utilidad, por lo que los programas de aplicacin se veran en la
obligacin de tratar el formato de los campos de entrada de manera distinta segn el tipo de terminal.
__________________________________________________________________________________________________
_
Pg. 75

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Para evitar esta situacin, existe la posibilidad de definir un tipo de campo especial, de tal manera que
la Arquitectura, cuando se trata de un terminal 3270, depura los caracteres de edicin (puntos y
comas), de tal forma que el dato llega de igual al manera al programa de aplicacin sea cual sea el
terminal origen.
De igual manera, la Arquitectura edita este tipo especial de campo en la salida al terminal.
El tipo de un campo se define en el formato, desde la pantalla de mantenimiento de campos de un
formato. Existen varios tipos de campos:
. 'A':
. 'N':
. 'S':
. 'D':
. 'E':
. 'F':
. 'G':

Alfanumrico.
Numrico.
Numrico con signo.
Numrico sin signo, y comas de edicin.
Numrico sin signo y puntos y comas de edicin.
Numrico con signo y comas de edicin.
Numrico con signo y puntos y comas de edicin.

Los campos numricos de carcter editado (tipos D, E, F y G) llegarn al programa de aplicacin con
ceros a la izquierda. En el caso de los numricos con signo negativos, el signo llega como un carcter '-'
a la derecha del campo (de igual manera que en los otros terminales).
Para dimensionar correctamente un campo editado, hay que tener en cuenta que se deben dejar espacios
libres para los carcter de edicin, adems de los necesarios para los dgitos del campo.
La Arquitectura controla el nmero de dgitos correcto teniendo en cuenta los caracteres de edicin.
o

Para campos de tipo D:

No llevan signo, y solamente llevan editada la coma de los decimales, por lo que habr que
dejar un espacio libre para la coma, si tiene algn decimal.
Por ejemplo, si se desea un campo numrico con 1 decimal, y con tres dgitos a la
izquierda de la coma (999,9), se deber definir en la pantalla un campo de 5 posiciones.
Si se teclea:

1
-----

al programa de aplicacin le llega: 00010, y la Arquitectura en la salida lo editar de tal

manera que aparecer en pantalla:
1,0
----Si se tecla:

1,12
-----

la Arquitectura dar un error de nmero de decimales incorrecto (antes de llegar al

programa de aplicacin).
Si se teclea:
1234
__________________________________________________________________________________________________
_
Pg. 76

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

----la Arquitectura dar un error de nmero de enteros incorrecto (antes de llegar al programa
de aplicacin).
Si se teclea:

1,4
-----

al programa de aplicacin le llega: 00014, y la Arquitectura en la salida lo editar de tal

manera que aparecer en pantalla:
1,4
----Si el campo que se desea editar no tiene decimales, no aparecer la coma decimal en este
tipo de datos.
o

Para campos de tipo E:

No llevan signo, y llevan editada la coma de los decimales y el punto de los miles, por lo
que habr que dejar un espacio libre para la coma, y uno para cada posible millar.
Por ejemplo, si se desea un campo numrico con 2 decimales, y con cinco dgitos a la
izquierda de la coma (99.999,99), se deber definir en la pantalla un campo de 9
posiciones.
Si se teclea:

1
---------

al programa de aplicacin le llega: 000000100, y la Arquitectura en la salida lo editar de

tal manera que aparecer en pantalla:
1,00
---------

Si se teclea:

1234,1
---------

al programa de aplicacin le llega: 000123410, y la Arquitectura en la salida lo editar

para que aparezca por pantalla:
1.234,10
--------Si se tecla:

123123
---------

__________________________________________________________________________________________________
_
Pg. 77

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

la Arquitectura dar un error de nmero de enteros incorrecto (antes de llegar al programa

de aplicacin).
o

Para campos de tipo F:

Llevan signo, y solamente llevan editada la coma de los decimales, por lo que habr que
dejar un espacio libre para la coma, y otro para el signo.
Por ejemplo, si se desea un campo numrico con 2 decimales, y con cuatro dgitos a la
izquierda de la coma (9999,99-), se deber definir en la pantalla un campo de 8
posiciones.
Si se teclea:

1
--------

al programa de aplicacin le llega: 00000100, y la Arquitectura en la salida lo editar para

que aparezca por pantalla (el signo positivo se refleja en un espacio a la derecha):
1,00
-------Si se tecla:

-1
--------

al programa de aplicacin le llega: 0000100-, y la Arquitectura en la salida lo editar para

que aparezca por pantalla (el signo positivo se refleja en un espacio a la derecha):
1,00-------Si se teclea:

-1123
--------

al programa de aplicacin le llega: 0112300-, y la Arquitectura en la salida lo editar para

que aparezca por pantalla (el signo positivo se refleja en un espacio a la derecha):
1123,00-------Si se teclea:

-12345
-------la Arquitectura dar un error de nmero de enteros incorrecto (antes de llegar al programa
de aplicacin).
Para campos de tipo G:

__________________________________________________________________________________________________
_
Pg. 78

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Llevan signo, y llevan editada la coma de los decimales, el punto de los miles y el signo,
por lo que habr que dejar un espacio libre para la coma, otro para el signo y uno por cada
millar.
Por ejemplo, si se desea un campo numrico con 1 decimal, y con cinco dgitos a la
izquierda de la coma (99.999,9-), se deber definir en la pantalla un campo de 9
posiciones.
Si se teclea:

1
---------

al programa de aplicacin le llega: 000000010, y la Arquitectura en la salida lo editar

para que aparezca por pantalla (el signo positivo se refleja en un espacio a la derecha):
1,0
--------Si se teclea:

-1234
---------

al programa de aplicacin le llega: 00012340-, y la Arquitectura en la salida lo editar

para que aparezca por pantalla
1.234,0---------

II.14. CONTROL DE TECLAS DE FUNCION.

La Arquitectura de Aplicaciones posee una tabla que recoge la informacin sobre las teclas de funcin
asociadas a cada transaccin (QGDTPFK).
Esta funcionalidad slo puede ser utilizadas por transacciones de tipo CONVERSACIONAL.
Las aplicaciones pueden utilizar dicha tabla para obtener las distintas utilidades que la Arquitectura
provee si tiene dicha informacin recogida. La utilizacin de esta tabla y sus utilidades no es
obligatoria.
En primer lugar, se describirn las utilidades que permite la informacin de la tabla QGDTPFK, y
finalmente se apuntar cmo se mantiene esta informacin mediante la conversacin de mantenimiento
de tablas de la Arquitectura.
__________________________________________________________________________________________________
_
Pg. 79

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Las utilidades que se derivan de la informacin del control de teclas de funcin son:
1.-

Posibilidad de que la Arquitectura pinte la lnea 24 de las pantallas en 3270 (esta lnea
contiene las teclas asociadas a la transaccin).
De esta manera, los mapas de las aplicaciones solamente tendrn 19 lneas (desde la lnea
4 hasta la 22), o bien 18 lneas si la transaccin tiene fast-path (de la lnea 4 hasta la 21).

2.-

Posibilidad de que la tecla que la Arquitectura pase al programa de aplicacin otra tecla
distinta a la pulsada. Esto hace que el cambiar una tecla de funcin no requiera el cambio
en los correspondientes programas de aplicacin.

3.-

Posibilidad de que la Arquitectura ceda control a distintos programas de aplicacin segn

la tecla pulsada en una misma transaccin.
Esto puede ser interesante para modularizar las operaciones dentro de una misma
transaccin.

4.-

Posibilidad de desactivar una tecla de funcin en un momento determinado mediante la

Arquitectura.

5.-

Control de las teclas de funcin vlidas para una transaccin realizado por la
Arquitectura.

La tabla de teclas de funcin contiene las teclas asociadas a cada transaccin. En el momento en que se
asocian estas teclas a la transaccin, la Arquitectura detecta que una tecla pulsada no est entre las que
existen en la tabla para dicha transaccin, y manda un error al terminal. Esto hace posible el punto 5 de
las utilidades.
Ademas, para cada tecla, se guarda la siguiente informacin:
o

Literal asociado a la tecla: Es una descripcin de la tecla en 6 posiciones, que ser la que se
muestre en pantalla cuando se pinte la lnea 24 con las PF's. Es susceptible de tener multiidioma, y se mostrar en el idioma del terminal.

Indicador de pintar la tecla: Indica si la tecla se debe pintar en la lnea 24. Solamente se
pintaran en pantalla las teclas con el indicador activado. Si ninguna tecla tiene este indicador
activado, la Arquitectura no pintar la lnea 24.
Esto permite que la aplicacin pueda tener la lnea 24 definida en su panel como un literal, y
sin embargo utilizar todas las dems utilidades que proporciona la informacin de la tabla
QGDTPFK.
Se pueden pintar como mucho 8 teclas.

Indicador de activa: Indica si la tecla est activa. Si la Arquitectura tiene este indicador con
valor 'N', al pulsar esta tecla mandar un mensaje a pantalla indicando que la tecla se encuentra
inactiva.

Tecla Ficticia: Es el cdigo de tecla que recibir el programa de aplicacin.

Esto permite cambiar el valor de una tecla pulsada sin cambiar el programa de aplicacin.
Por ejemplo, si se quiere cambiar el estndar de tecla de baja de PF6 a PF8, se puede dar de
alta la tecla PF8, indicando que su tecla ficticia es PF6. De esta manera, al pulsar el
terminalista la tecla PF8, la Arquitectura le mandar al programa de aplicacin el cdigo de la
PF6, y realizar una baja.

__________________________________________________________________________________________________
_
Pg. 80

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Programa asociado: Si se informa un programa asociado a la tecla de funcin, se dar el

control a dicho programa cuando se pulse la tecla. Hay que tener especial cuidado con este
valor puesto que puede direccionar hacia otro programa provocando una inconsistencia en la
lgica de la conversacin o un error no controlado.
Si no se informa, se dar el control al programa asociado a la transaccin en la tabla de
transacciones.

Para que una transaccin utilice estas utilidades, se debe:

1.-

Dar de alta sus teclas de funcin asociadas.

Desde el panel de mantenimiento de transacciones, y pulsando la tecla PF8, se obtiene un
listado de las teclas de funcin asociadas a la transaccin. Si no existe ninguna, aparece
un listado sin ningn dato. Para dar de alta, se pulsa la tecla PF3 sin seleccin, y se
accede al panel de mantenimiento de teclas de funcin, donde se darn de alta todas las
teclas. Cambiar las descripciones de los literales para cada idioma de la instalacin.

2.-

Activar el indicador de PF's por Arquitectura para la transaccin, en el panel de

mantenimiento de transacciones.

II.15. LISTADO DINAMICO DE TABLAS.

Por medio de la tabla de Arquitectura QGDTLIS (Tabla de listado de tablas), se obtienen listados en
SQL dinmico, definiendo una serie de parmetros.
Con esto se consiguen listados de tablas DB2, sin tener que ejecutar programas propios de la
aplicacin. Por otra parte, dado el costo que supone la ejecucin de un programa en SQL dinmico, se
recomienda este sistema para tablas de parmetros que no sean de gran tamao.
La forma de obtener el listado deseado, es dar de alta una fila en la tabla de listados de tablas
(QGDTLIS), asociar una transaccin al programa QC2CLIS (Listado dinmico de tablas) e informar
la clave de la fila de la tabla QGDTLIS en el campo CAA-IDTABLA de la commarea QGECCAA.
Este campo, CAA-IDTABLA tiene dos usos:
o

Si desde una pantalla se desea pasar a un listado SQL dinmico, el programa de aplicacin
debe informar en el campo CAA-IDTABLA la clave de la tabla a listar (es decir la clave de la
fila de la tabla de listados de tablas, QGDTLIS).

__________________________________________________________________________________________________
_
Pg. 81

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Si desde un listado en SQL dinmico se quiere pasar a otra pantalla con un item seleccionado
(por ejemplo un mantenimiento) el programa encontrar en CAA-IDTABLA las diez primeras
posiciones del listado, del item seleccionado.

Por ejemplo, desde el men de tablas comunes, se pasa al listado de la tabla de productos/subproductos
(que utiliza el SQL dinmico y tiene la clave BGDTPRS en la tabla QGDTLIS), y seleccionando una
fila, se desea pasar a la pantalla de mantenimiento de productos/subproductos.
* El programa informa
BGDTPRS en el campo
CAA-IDTABLA

* El programa recibe
'001 003 ' en el
campo CAA-IDTABLA.

Por tanto, en el caso de disecar un listado en SQL dinmico, si existe un mantenimiento, habr que
tener en cuenta que la clave a pasar al mantenimiento debe encontrarse en las diez primeras posiciones.
Si la clave tuviera ms de 10 posiciones, el programa de mantenimiento deber acceder a la cola del
listado (+GTSXXXX) para leer el item seleccionado (informacin que se encuentra en el campo de la
commarea CAA-NUM-ITEM-SELEC).
Es importante sealar que si se disea una tabla con sentencias del tipo ORDER BY o GROUP BY, si
desde el programa de aplicacin se informa una sentencia con WHERE, las sentencias de ordenacin o
agrupacin se pierden. Por lo tanto, a la hora de disear la sentencia de condicin desde el programa de
aplicacin hay que incluir despus del WHERE el correspondiente ORDER BY o GROUP BY que se
haya definido en la tabla.

Existen dos formas en los que se puede editar un listado:

1.-

Con un preformato asociado.

Slo es vlido para listados de anchura menor o igual que 254. Se define un 'preformato'
en la tabla de listados, en el que se sustituir los valores '@' por campos. Si el campo tiene
longitud mayor que el nmero de '@', se truncar. Si la longitud del campo es menor,
aparecern '@' por la derecha. Por ejemplo, la sentencia select a ejecutar es:
'select trm_timestamp from dbcreator.qgdttrm '
- si el preformato es: timestamp..: @@@@ el resultado ser : timestamp..: 1996 (se ha
truncado)
- si el preformato es: timestamp..:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@ el resultado ser :
timestamp..: 1996-01-01.12.30.12.123456@@

2.-

Indicando el nmero de blancos de separacin entre los campos que se seleccionan en el

campo LIS-NUM-BLANSEP. Por ejemplo, si la sentencia select es:
' select subst(trm_timestamp,1,4),trm_netname from dbcreator.qgdttrm order by
trm_netname
y LIS_NUM_BLANSEP es 7, el resultado ser:

__________________________________________________________________________________________________
_
Pg. 82

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

'1996

P606'

Pasemos a analizar cada uno de los campos que se deben informar al dar de alta un registro en la tabla
de listados QGDTLIS.
- IDTABLA:

- DESAMP:
- DESRED:
- SENTENCIAS:

Referencia del listado. El nombre informado aqu debe ser informado en el

campo de la commarea QGECCAA CAA-IDTABLA (rea CAAPAGINACION). Es la clave del listado en la tabla de listados
QGDTLIS.
Descripcin ampliada del cdigo anterior.
Descripcin reducida.
Occurs de 80 en los que se encuentra el select a ejecutar en el listado
deseado.
Las tablas que aparezcan debern tener el prefijo DBCREATOR. El
programa que realiza el listado SQL dinmico sustituir este valor por el
campo DBCREATOR de la tabla de Parmetros On-line de la Entidad
para cada entorno de trabajo.
Si una sentencia tiene dos guiones por delante, se ignorar. Por ejemplo,
en el caso:
LIS-SENTENCIA1: --SELECT * FROM DBCREATOR.QGDTTRM
LIS-SENTENCIA2: --WHERE TRM_NETNAME LIKE 'P6%'
LIS-SENTENCIA3: SELECT * FROM DBCREATOR.QGDTCCT
slo se ejecutar la tercera sentencia.

- PREFORMATO:

Preformato para la edicin del listado. Slo es vlido para listado de

anchura menor o igual que 256.
- NUM-BLAN-SEP: Nmero de blancos de separacin en el caso de no utilizar un preformato
asociado. Es numrico de 0 a 9. En el caso de estar informado a 0, se
asumir 1 blanco de separacin.
- CABECERA1:
Primera cabecera que aparecer en el listado. No se paginar y aparecer
en brillante.
- CABECERA2:
Segunda cabecera que aparecer en el listado. No se paginar y aparecer
en brillante. En el caso de informarse, se deber informar el campo LISNUM-LIN-CAB con el valor '02'.
- COMENTARIOS: Occurs de 10. Son 10 posibles comentarios a pie de listado. Se listarn
con atributo normal con el campo de seleccin y de datos protegidos.
- ATRIBUTOS: Occurs de 3. Cada uno de ellos contiene los campos:
- ATR-NUMCOL:
Nm. de columna a comparar.
- ATR-VALOR: Valor con el que se compara.
- ATR-ATRIB:
Atributo con el que edita la lnea.
Por ejemplo, ejecutando la sentencia:
' select trm_netname, trm_entidad_cont, trm_tipo_term
from dbcreator.qgdttrm
order by trm_netname'
se desea editar en brillante (atributo 'B') aquellos con trm_entidad_cont =
'0209'.
Se conseguir informando
- ATR-NUMCOL(1) = 2
- ATR-VALOR (1) = 0209
__________________________________________________________________________________________________
_
Pg. 83

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

- ATR-ATRIB (1) = B
Hay que comentar que los occurs predominan de menor a mayor. Es decir,
en el caso de estar informado
- ATR-NUMCOL(1) = 2
- ATR-NUMCOL(1) = 3
- ATR-VALOR (1) = 0209
- ATR-VALOR (1) = 19
- ATR-ATRIB (1) = B
- ATR-ATRIB (1) = R
(es decir, listar en brillante los teminales con la entidad contable 0209, y
en rojo los que tengan tipo de terminal 19),
si una fila del listado cumple las dos condiciones, se listar en brillante
(B).
- MAX-LISTAR:
Nmero mximo a listar. En el caso de no estar informado, se asume un
mximo de 1000. En el caso de llegarse al nmero mximo de filas a
listar, aparecer en pantalla un aviso.
- TRAN-DEFECTO: Transaccin que se informar como siguiente, en el caso de que se pulse
una tecla de las informadas como propias del listado (LIS-FKEY) y no
tenga transaccin asociada.
En el caso de que todas las teclas de funcin den control a la misma
transaccin, informndola en este campo, no ser necesario especificar
tecla a tecla.
- CONTENID:
Primer campo informativo que aparece en los listados.
- SEL-PERMIT:
Occurs de 10, en los que se informa de los caracteres permitidos a la hora
de seleccionar una lnea del listado (en el caso de que exista seleccin).
- IND-VARSEL:
Indicador de si se permite o no varias selecciones. Valores posibles: 'N'
(no se permiten varias selecciones) 'S' (si se permiten varias selecciones).
- MARGEN-FIJO: Nmero de caracteres a mantener a la izquierda, en el caso de que haya
paginacin lateral.
- FKEY:
Occurs de 8. Se informa de las teclas propias del programa de listado.
FKEY-NUM:
Nmero de tecla permitida
FKEY-LIT: Literal tecla a mostrar en el panel
FKEY-SEL:
Indicador. Valores posibles:
'S' se exige seleccin
'N' no se permite seleccin
' ' no se validar la seleccin.
- FKEY-TRAN:
Siguiente transaccin a la que se dar control al pulsar la tecla de funcin.
- IND-MOD-DATO: Indicador de modificar o no los datos del listado. Valores posibles:
'S'
Se permite modificar la lnea de datos
'N'
No se permite modificar la lnea de datos.
- LNEA-PANT:
Lnea en la que se posicionar el listado en la primera pantalla.
- COLUM-PANT: Columna en la que se posicionar el listado en la primera pantalla.
- NUM-LIB-CAB: Nmero de lneas de cabecera.
- IND-SCROLL-LAT: Indicador de si se desea scroll lateral. Valores:
'S'
Se desea scroll lateral
'N'
No se desea scroll lateral.

__________________________________________________________________________________________________
_
Pg. 84

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.16. CAMBIO DE SESION.

Se denomina cambio de sesin al proceso en el que se realiza el cambio de fecha contable en una
Entidad.
El cambio de sesin en la Arquitectura se realiza de manera centralizada para todas las aplicaciones, y
se lleva a cabo mediante una transaccin de cambio de sesin (de cdigo QGCS).
En esta transaccin de cambio de sesin, se van llamando a todas las aplicaciones, para que se percaten
de que se est realizando el cambio de fecha contable, y puedan llevar a cabo cualquier tipo de procesos
que crean necesarios en dicha situacin. Tiene como campo de entrada la entidad en la que se quiere
realizar el cambio de sesin (que si no se informa se tomar la asociada al terminal desde el que se
ejecuta).
Para ello, la Arquitectura tiene una tabla llamada "de cambio de sesin" (QGDTCSE), que contiene la
informacin de todos los programas o transacciones a los que se debe llamar durante la transaccin
QGCS.
El cambio de sesin consta de dos fases:
o
o

FASE PRELIMINAR (1): En la cual se realiza cualquier tipo de verificacin para poder
continuar con el cambio de sesin.
FASE FINAL (2): En la cual se realiza el cambio de fecha, y todos los dem s cambios que
puedan venir asociados con este cambio de fecha.

Durante el cambio de sesin, la transaccin QGCS ir llamando a los procesos asociados a la fase 1
(preliminar), en el orden marcado en la tabla de cambio de sesin. Una vez llamados a todos ellos, y si
no ha habido ninguna incidencia, se procede a llamar a todos los procesos asociados a la fase 2 (final).
Si todo ha terminado correctamente, se da por terminado el cambio de sesin.
La informacin de los procesos a ser llamados en las distintas fases, se encuentra recogida en la tabla
de cambio de sesin. Esta tabla contiene:
o ENTIDAD: Entidad asociada al proceso. En el cambio de sesin solamente se llamar a los
procesos asociados a la entidad en que se est realizando el cambio. Si toma el valor '0000',
querr decir que el proceso debe ser llamado en cualquier entidad.
__________________________________________________________________________________________________
_
Pg. 85

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

FASE: Fase en que ser llamado el proceso (valor 1/2).

ORDEN: Orden en que ser llamado el proceso dentro de la fase.

CODIGO: Nombre del proceso. Puede ser:

Un programa, en cuyo caso ser llamado mediante CICS LINK con una commarea que
veremos a continuacin.
Una transaccin, en cuyo caso ser arrancada por CICS START.

INDICADOR PROGRAMA/TRANSACCION: Indica si el cdigo anterior es un programa

o una transaccin (valores P/T).

INDICADOR ACTIVO: Indica si el proceso est activo o no (valores S/N). Si el proceso no

se encuentra activo, no se le llamar en el cambio de sesin.

CICS: Nombre del Cics que se verificar que est activo antes de llamar al cdigo
correspondiente (transaccin o programa).

De esta manera, si el contenido de la tabla de cambio de sesin es el siguiente:

ENTIDAD
0000
2103
2103
2058
0000
2103
2103
2103
2103

FASE
1
1
1
1
2
2
2
2
2

ORDEN
01
02
03
04
01
02
03
04
05

CODIGO
QC2CCSS
BG2CCSS
GC2CCSS
XG2CCSS
QC2CCSS
BG2CCSS
MG74
IRCS
XGCS

PR/TR
P
P
P
P
P
P
T
T
T

ACTIVO
S
S
N
S
S
N
S
N
S

CICS

CC3A

Si se realiza el cambio de sesin de la entidad 2103, la transaccin de cambio de sesin:

a) Entrar en la fase 1 (preliminar), llamando a los procesos asociados a la fase 1, en el orden
indicado, que se encuentren activos, para la entidad en la que se est cambiando la sesin:
1. Llamar mediante CICS LINK al programa QC2CCSS, ya que est activo y est asociado
a la entidad '0000' (todas las entidades). Le pasar la commarea QGECCSS (que ms
adelante comentaremos). Si este programa no devuelve error:
2. Llamar mediante CICS LINK al programa BG2CCSS, ya que est asociado a la entidad
2103. Si este programa no devuelve error:
3. Dar por terminada la fase preliminar, ya que el proceso de orden 4 en la fase 1 no est
activo, y el de orden 5 no est asociado a la entidad 2103.
b) Entrar en la fase 2 (final), llamando a los procesos asociados a la fase 2, en el orden indicado,
que se encuentren activos, para la entidad en la que se est cambiando la sesin:
1. Llamar mediante CICS LINK al programa QC2CCSS, ya que est activo y est asociado
a la entidad '0000'. Si no le devuelve error, y ya que el proceso siguiente (programa
BG2CCSS) no esta activo:
__________________________________________________________________________________________________
_
Pg. 86

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

2. Se verificar que el cics CC3A est activo, ya que as lo indica el registro del siguiente
proceso. A continuacin, se realizar un START de la transaccin MG74.
3. Por ltimo, se realizar un START de la transaccin XGCS, con lo que se dar por
terminado el cambio de sesin.
Siempre que algn programa de los llamados devuelva un error, se realizar un ROLLBACK para
deshacer los posibles cambios que algn programa anterior hubiera hecho.
En el caso de que los procesos sean programas, se les pasar la commarea QGECCSS, que contiene los
campos:
FASE: Fase en la que se encuentra el cambio de sesin (puede se 1 2).
FECHA CONTABLE: Fecha contable actual (es decir, de antes del cambio de sesin).
FECHA CONTABLE SIGUIENTE: Fecha contable que va a entrar como actual despus del
cambio de sesin.
CODIGO DE ERROR: Cdigo de error que devolver el programa en caso de que haya
ocurrido alguna incidencia. Si algn programa devuelve un cdigo de error en este campo, se
terminar el proceso de cambio de sesin, mostrando este error por pantalla.
ENTIDAD ASOCIADA: Entidad en la que se est haciendo el cambio de sesin.
TIMESTAMP DE INICIO: Timestamp del inicio del cambio de sesin.
En el caso de que los procesos sean transacciones, se realizar un START de la transaccin
correspondiente, pasndole la siguiente informacin, que le llegar como pantalla de entrada. Por lo
tanto, la transaccin, si se ejecuta bajo la Arquitectura, deber tener el formato de entrada asociado
llamado QGRMDST. Los campos de esta pantalla son:
FASE: Si se encuentra en la fase 1 2 (preliminar o final).
FECHA CONTABLE: Fecha contable actual (es decir, de antes del cambio de sesin).
FECHA CONTABLE SIGUIENTE: Fecha contable que va a entrar como actual despus del
cambio de sesin.
ENTIDAD ASOCIADA: Entidad en la que se est haciendo el cambio de sesin.
Estos datos no contienen el cdigo de error, puesto que una vez arrancada la transaccin, ya no le
volver control al cambio de sesin. Por este motivo, es aconsejable que si se desea que se interrumpa
el cambio de sesin por algn error que se pueda producir, se asocie un programa, y no una
transaccin.

__________________________________________________________________________________________________
_
Pg. 87

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

__________________________________________________________________________________________________
_
Pg. 88

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.16.1. CAMBIO DE SESION DE ARQUITECTURA.

La Arquitectura, como cualquier otra aplicacin, realiza su propio cambio de sesin. Para ello, tiene un
programa, llamado QC2CCSS, que es llamado tanto en fase preliminar como en fase final.
Este proceso se debe llamar siempre como primero de la fase preliminar y como primero de la fase
final, siendo los dems procesos a llamar dependientes de la instalacin, y de las necesidades del
cliente, pudiendo llegar incluso a no haber ningn otro.
Los procesos que se llevan a cabo son:
o

Cambio de la fecha contable: Actualiza la fecha contable del dia y la del dia siguiente.

Cambio de las tablas Flip-Flop: Para las tablas que tienen varias versiones (Tecleos,
Autorizaciones, Journal y Totales), cambia la versin que figura como vaca despus de
verificar que efectivamente las tablas estn inicializadas.

El cambio de sesin de Arquitectura consiste en lo siguiente:

o

EN FASE PRELIMINAR se realizan las siguientes verificaciones:

La Arquitectura realiza las siguientes verificaciones para garantizar que se haga una y slo una
vez el cambio de sesin en el dia:
Si la fecha contable que figura en las tablas de la Arquitectura es inferior a la fecha de
dia, no se ejecuta ninguna transaccin: as se evita que no se realice el cambio de sesin
un dia. Esto es vlido slo para el entorno de produccin y se aplica a todas las
transacciones excepto las propias de cambio de sesin (QGCS y QGCF) para poder
ejecutar un cambio despus de las 12 de la noche si con anterioridad no hubiera sido
posible realizarlo.
Si la fecha contable es la misma que la del dia, y es antes de la hora puesta como
mnima (HORACS) a la hora de definir los parmetros on-line del entorno de cada
entidad, tampoco permite el cambio de sesin.
Si es despus de esta hora mnima indicada, y el TIMESTAMP del ltimo cambio es el
dia de hoy, no permite realizar el cambio de sesin en el entorno de produccin. Con
estas dos ltimas verificaciones, se impide que se cambie de sesin dos veces el mismo
dia.

Aparte de estas verificaciones, la Arquitectura comprobar, cuando actualice la tabla de Totales, que la
fecha contable que figura en dicha tabla como la del da coincida con la de la tabla de control del
sistema (QGDTSWA). Si no ocurre as, es que no se ha realizado el proceso de descarga de las tablas
diarias del dia anterior despus del cambio de sesin, y no se podr ejecutar ninguna transaccin que
actualice la tabla de Totales hasta que no se realice esta operacin (ejecucin completa correcta de la
cadena batch de Arquitectura del da anterior).
o

EN FASE FINAL se realiza:

__________________________________________________________________________________________________
_
Pg. 89

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Validaciones concretas que pudieron ser especificadas para esta fase (fase de ejecucin).

Cambio de la fecha contable y de la fecha contable siguiente en la tabla de control de

sesin (QGDTSWA).

Flip-flop de las tablas de tecleos, autorizaciones, journal y totales.

Actualizacin del estado de las aplicaciones sobre la tabla QGDTAPL y las colas TS
asociadas.

Borrado de colas TS de terminales.

Nueva copia a la cola TS de control del sistema en todos los CICS controlados por la
Arquitectura.

101
201
202
203

QC2CCSS
QC2CCSS
QG2CCSA
QC2CTRM

P
P
P
P
______
PRG/TR

N
N
N
N
______
START

S
S
S
S
_______
TERM-ACT

OPERACIONES CON LAS TABLAS DIARIAS DE ARQUITECTURA:

La Arquitectura ofrece una serie de utilidades contables y de seguridad basndose en la
informacin recogida en ciertas tablas.
Estas tablas tienen una vigencia de un da, por lo que el proceso de cambio de sesin contable
implica su preformateo. Los grupos de tablas que se encuentran en esta situacin son las de
Autorizaciones (A y B), Tecleos (A y B), totales (A,B y C) y Journal (A,B y C).
En cada momento existir una tabla por grupo activa (esta informacin est presente en la tabla
de control del sistema QGDTSWA y es consultable por la opcin 9 del men). Esta tabla
recibe el nombre de TABLA ACTIVA y todos los procesos que necesiten una tabla de su grupo
actuarn contra ella durante todo el dia contable.
La TABLA VACIA es una tabla preformateada, lista para pasar a ser la nueva tabla activa
cuando se ejecute con xito la transaccin QGCS.
Los grupos de tablas asociados al JOURNAL y a TOTALES tienen adems otra tabla mas: la
tabla de AYER, en la que aparecen los datos correspondientes a la fecha contable
inmediatamente anterior.
Supongamos que la situacin actual es:
FECHA CONTABLE:
12/07/95
FECHA CONTABLE SIG: 13/07/95

Mircoles
Jueves

__________________________________________________________________________________________________
_
Pg. 90

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

TECLEOS
TOTALES
JOURNAL
AUTORIZACIONES

ACTIVA
B
B
C
B

AYER
A
B

VACIA
A
C
A
A

Ejecutamos la transaccin QGCS y se efecta el FLIP/FLOP (intercambio) de tablas:

FECHA CONTABLE:
13/07/95
FECHA CONTABLE SIG: 14/07/95
TECLEOS
TOTALES
JOURNAL
AUTORIZACIONES

ACTIVA
A
C
A
A

Jueves
Viernes
AYER
B
C

VACIA
A
A
B
B

Donde:

La tabla activa pasa a ser la de Ayer o la Vaca (dependiendo del nmero de tablas asociado al
grupo).
La tabla vaca pasa a ser la tabla activa
La tabla de ayer pasa a ser la tabla vaca

Nota: La tabla marcada como vaca seguir teniendo datos hasta que pasen las cadenas de
cambio de sesin, que son las que realmente efectan el formateo.

II.17. ESQUEMA Y RECURSOS DE SEGURIDAD.

La gestin de la seguridad, por parte de la Arquitectura Extendida, contempla tres posibles casos:
__________________________________________________________________________________________________
_
Pg. 91

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

A) Seguridad externa para la versin Extendida.

B) Seguridad interna para la versin Extendida.
C) Seguridad (externa o interna) para la versin Estndar.
La seguridad EXTERNA (casos A y C) es la que utiliza la Arquitectura cuando existen productos de
control de seguridad (del tipo RACF) en la instalacin. Cuando no existen dichos productos, la
Arquitectura deber utilizar la seguridad INTERNA (casos B y C).
Es importante resaltar el hecho de que la Arquitectura hace transparente a los programas de aplicacin
el tipo de seguridad adoptado en la instalacin. De esta forma, los programas se comportan siempre
igual, independientemente del tipo de seguridad adoptado, no siendo necesario modificar nada en los
cdigos fuente de los programas.
La Arquitectura detecta el tipo de seguridad existente de la siguiente manera:
o Para detectar el tipo de seguridad (externa o interna) la Arquitectura lee el contenido del campo
SEGURIDAD-IE de la tabla de control del sistema (QGDTSWA) cuyo valor ser 'E' si la
seguridad es externa, o 'I' en el caso de que sea interna.
o Para detectar si el programa de aplicacin funciona bajo la versin Extendida o Estndar, la
Arquitectura lee el campo ST_ALTAMIRA en la tabla de control de Transacciones
(QGDTCCT), en donde se le indica si la transaccin es o no de tipo Estndar.

__________________________________________________________________________________________________
_
Pg. 92

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

II.17.1. SEGURIDAD EXTERNA PARA LA VERSION EXTENDIDA.

El esquema de seguridad de la Arquitectura, cuando existe un producto de control de seguridad externa
(del tipo RACF o similar), est estructurado en cuatro niveles, los cuales quedan reflejados en el
siguiente esquema:

NIVEL
BSICO

PRIMER
NIVEL

R.AC.F.

R.AC.F.
Control de acceso
( Recurso: transaccin)
ARQUITECTURA
APLICACION
SEGUNDO NIVEL

TERCER NIVEL

R.AC.F.
Proteccin de programas
( Recurso: programa )

R.AC.F.
Funciones especiales
( Recursos ficticios )

Como muestra el anterior diagrama, la Arquitectura transfiere sistematicamente el control de la

seguridad a R.A.C.F..
Para facilitar el manejo de la seguridad, un usuario debe pertenecer a uno o varios grupos de usuarios,
de esta manera si un grupo est autorizado, todos los usuarios que pertenecen a ese grupo tambin lo
estn.

NIVEL BSICO
El nivel bsico comprende las siguientes funciones:
Identificacin del usuario.
Verificar que la password corresponde con el usuario.
Desconexin del sistema.
La identificacin del usuario viaja a travs de una transaccin de logon especial hacia la
Arquitectura. Teniendo en cuenta que la sesin se cierra tecleando CSSF, transaccin
perteneciente al CICS, R.A.C.F. y CICS tienen control en todo momento de los usuarios
activos.
En la transaccin de logon, la Arquitectura recoge el usuario y lo enva a la aplicacin para su
posterior utilizacin por los programas que componen la misma.
__________________________________________________________________________________________________
_
Pg. 93

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

La verificacin de passwords, control de caducidad, unicidad, etc, ser gestionada directamente

por el RACF.
El cdigo de usuario es el USERID de ocho posiciones, por lo que desaparece el concepto de
OPID (de tres posiciones) que utilizaba la versin Estndar de Arquitectura.
La transaccin de LOGON a la Arquitectura presenta la disposicin siguiente:
USUARIO
PASSWORD

: uuuuuuuY
: ********

PRIMER NIVEL
En el primer nivel de seguridad el control del acceso es realizado por R.A.C.F. chequeando si
el usuario est autorizado a ejecutar cada una de las transacciones solicitadas al sistema. Por lo
tanto, la Arquitectura y los programas de aplicacin slo podrn realizar las operaciones ya
autorizadas por R.A.C.F.
En este nivel, la transaccin se define como un recurso protegido en R.A.C.F.
Todas las transacciones de cada aplicacin deben ser definidas en R.A.C.F., indicando qu
usuarios y qu grupos de usuarios estn autorizados para ejecutarlas.

SEGUNDO NIVEL
Los mdulos cuyo uso est restringido a ciertos usuarios, cuentan para ello con un segundo
nivel de seguridad. En este caso, el recurso protegido por R.A.C.F. es el programa.
El tpico caso del uso de este nivel lo presentan las transacciones que realizan varias funciones:
altas, bajas, modificaciones..., ejecutadas por distintos programas. Algunas de dichas
funciones, por ej. la baja, quedan restringidas a ciertos usuarios o grupos de usuarios.

TERCER NIVEL
El tercer nivel puede ser usado como una alternativa al segundo nivel, ya que es ms genrico y
no obliga a obtener ciertos recursos fuera del programa principal.
Este nivel consiste en definir una cola TS en R.A.C.F. como un recurso ficticio, autorizando
slo a ciertos usuarios o grupos de usuarios. Tal recurso es manejado por el mdulo de
interfase que proporciona la Arquitectura denominado QG1CSEG.
Cuando el programa de aplicacin necesita conocer qu usuarios estn autorizados para
acceder al recurso ficticio, llama al mencionado mdulo informandole de la FUNCIN, recurso
ficticio al que se desea acceder. La seguridad del mdulo deber mostrar un indicador con valor
"S", si el usuario tiene el nivel de seguridad requerido, o "N", si por el contrario no lo posee.
Un ejemplo, en el caso de que interese modificar el inters de una cuenta de crdito podemos
plantearnos la existencia de un cierto grupo de usuarios autorizados a realizar la modificacin
descrita pero dentro de un rango; sobrepasado cierto nivel solamente un usuario en particular
podra realizar dicha operacin.
En este caso, cada funcion de tipo y rango deben ser definidas al R.A.C.F. como recursos ficticios,
identificando qu usuarios estarn autorizados a realizarlo y pidiendo por programa la validacin de
autorizacin de unos u otros en funcin del rango deseado.
__________________________________________________________________________________________________
_
Pg. 94

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Cuando la aplicacin chequa que el usuario debe tener un nivel de autorizacin suficiente para ejecutar
la funcin especial como recurso ficticio, se transfiere el control al mdulo de seguridad de la
Arquitectura, el cual debe indicar si el usuario est autorizado no a ejecutar dicha funcin especial.
Por lo tanto, bajo este esquema de seguridad:
a) Existen una serie de funciones (o recursos ficticios) definidos al RACF.
b) El programa de aplicacin llama al objeto QG1CSEG, pasndole va commarea la
funcin (o recurso) al que desea acceder.
c) El programa de acceso QG1CSEG comprueba que la seguridad definida en el sistema sea
EXTERNA.
d) Si la seguridad es externa, el mdulo QG1CSEG pregunta al RACF sobre la autorizacin
que dispone el usuario sobre el recurso que se le indica, devolviendo al programa de
aplicacin el indicador IND-AUTORIZA, con los valores S si est autorizado y el
recurso existe como protegido, o bien, el recurso no existe como protegido y puede
utlizarlo cualquier usuario, o N si el recurso existe y no tiene autorizacin para
utilizarlo.
Existe un mdulo especial de acceso a funciones (recursos ficticios) denominado QC1CSEU, que es
bsicamente una versin del mdulo general QG1CSEG pero que accede a una tabla DB2
denominada KRDT010, que contiene los datos de usuario, transaccin y funcin (podra considerarse
como una versin distinta de la tabla de funciones de la seguridad interna) y que ser utilizada por los
programas de aplicacin cuando se quiera efectuar una autentificacin en proceso de autorizacin para
un usuario distinto del que ha realizado el logon de acceso.

II.17.2. SEGURIDAD INTERNA PARA LA VERSION EXTENDIDA.

El esquema de seguridad de la Arquitectura, cuando no existe un producto de control de seguridad
externa (del tipo RACF o similar), es el que se muestra a continuacin:
a) El acceso al sistema, en su nivel bsico, se realizar de forma independiente a la Arquitectura, a
travs de los medios que se tengan establecidos (alguna tabla con usuarios y passwords
habilitadas, identificacin a travs de recursos de la DFHSNT del CICS, etc.).
b) El acceso a la transaccin lo permite o deniega el CICS. Para ello, se necesitan definir en la
DFHSNT (Tabla de Sign-On del CICS) tantas entradas como usuarios se quieran tener dados de
alta para el uso de la Arquitectura. Por ejemplo:
DFHSNT TYPE
OPNAME
OPIDENT
PASSWRD
RSLKEY

=
=
=
=
=

ENTRY,
'JESUS MARTIN LOPEZ',
JML,
PEPE01,
(1,2,24),

__________________________________________________________________________________________________
_
Pg. 95

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

SCTYKEY
OPPRTY
USERID

= (1,2,64),
= 255,
= UAAN015

Como puede verse, se define una entrada para cada usuario que pueda conectarse (en el ejemplo
anterior, usuario UAAN015), dndole una serie de valores en el parmetro SCTYKEY. Se
pueden especificar hasta 64 diferentes valores en el operando SCTYKEY, cada uno de ellos de
valor comprendido en el rango de 1 a 64. Los valores de SCTYKEY del usuario se comparan
con el valor del parmetro TRANSEC de la definicin de la transaccin. Si el operando
SCTYKEY incluye el valor definido en el 64 parmetro TRANSEC, la ejecucin de la
transaccin es aceptada. En caso contrario, una violacin de seguridad es detectada y la
transaccin no se ejecuta.
Bajo este esquema, ser necesario adoptar unos estndares en la instalacin sobre el valor de
seguridad de cada transaccin (parmetro TRANSEC), para posteriormente asignar dicho valor
a cada uno de los usuarios que deban tener acceso a la misma (parmetro SCTYKEY).
c) La Arquitectura sabe que la seguridad es interna accediendo a la informacin correspondiente de
la tabla de control del sistema.
d) A continuacin, la Arquitectura acceder a la tabla de seguridad interna (QGDTSEG) para
conocer si el nivel de acceso asignado para el usuario que se ha identificado y para la transaccin
requerida (o bien, al grupo de transacciones que corresponden a una aplicacin determinada). Si
no encuentra este nivel de acceso para esta operacin, detectar un error en la seguridad y el
acceso ser rechazado.
e) A continuacin, la Arquitectura crea una cola TS, denominada +SEGxxxx (donde xxxx es el
identificador del terminal al CICS), que contiene un registro con los siguientes datos:
o
o
o

USUARIO identificado a la Arquitectura.

APLICACION a la que pertenece la transaccin a ejecutar.
TRANSACCION tecleada por el usuario.

La informacin de la cola TS +SEGxxxx ser utilizada por el mdulo de seguridad

(QG1CSEG) cuando sea llamado.
f) La Arquitectura cede control al programa de aplicacin, que funciona igual que si existiese
seguridad externa. Cuando el programa de aplicacin desea comprobar si el usuario que est
ejecutando la transaccin tiene acceso a una determinada FUNCION (o recurso ficticio), llama al
mdulo de seguridad pasndole va commarea la funcin o recurso al que desea acceder.
g) El mdulo de interfase de seguridad comprueba si la seguridad es externa o interna accediendo a
la tabla de control.
h) El mdulo de seguridad lee la cola +SEGxxxx (donde xxxx es el identificativo del terminal al
CICS) generada con anterioridad , extrayendo los datos de USUARIO, APLICACION y
TRANSACCION relativos al programa de aplicacin que se est ejecutando. Con esta
informacin, se deber comprobar de nuevo el nivel de acceso permitido para el usuario y
transaccin, accediendo a la tabla QGDTSEG.

__________________________________________________________________________________________________
_
Pg. 96

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Para esta transaccin y el valor de la FUNCION (o recurso ficticio) al que se desea acceder, el
mdulo de seguridad accede a la Tabla de Funciones (QGDTFUN) para encontrar el nivel
requerido para dicha transaccin o para el grupo genrico de transacciones de la aplicacin, si
ste est definido.
Si el registro buscado no existe en la tabla, no se autoriza la operacin. Si el registro existe, se
compara el nivel de la funcin con el nivel de acceso del usuario, autorizndose la operacin
siempre que dicho nivel sea menor o igual que el de acceso del usuario para esa transaccin.
i)

Por ltimo el mdulo de seguridad retorna el control al programa de aplicacin, con el indicador
de autorizacin informado.

II.17.3. SEGURIDAD (EXTERNA O INTERNA) PARA LA VERSION ESTANDAR.

El esquema de la Arquitectura, funcionando con seguridad externa (RACF) o interna, en la ejecucin de
programas diseados para la versin Estndar, es el siguiente:
a) La identificacin del usuario se realizar segn los procedimientos establecidos, bien sea por
seguridad externa o interna.
b) El acceso a la transaccin lo permite o deniega el CICS siguiendo los procedimientos
enumerados con anterioridad tanto para la seguridad externa como interna.
c) La arquitectura se encarga de obtener los valores de los niveles de acceso requeridos para las
transacciones y funciones de la Arquitectura Estndar. Estos son campos de la tabla de
transacciones QGDTCCT que contiene la siguiente informacin:
o
o
o
o

nivel de uso de la transaccin.

nivel de alta de datos en la transaccin.
nivel de baja de datos en la transaccin.
nivel de modificacin de datos en la transaccin.

d) En el programa de compatibilidad entre la Arquitectura Extendida y los programas de aplicacin

desarrollados con la Arquitectura Estndar, se acceder a la tabla de seguridad interna
QGDTSEG para obtener el valor definido para el nivel de acceso del usuario, dndo un error si
no se encuentra ninguna referencia para este usuario y transaccin a ejecutar.
e) A continuacin, la Arquitectura cede control al programa, pasndole en la commarea de
intercambio todos estos niveles de acceso, tanto de usuario como de funciones.
f) El programa de aplicacin realizar las comprobaciones correspondientes
entre los niveles requeridos y el de acceso del usuario.
II.18. TRATAMIENTO DE ERRORES.
La gestin de errores por parte de la Arquitectura se descompone en las siguientes tareas:
TRATAMIENTO DE ERRORES GENERALES.

__________________________________________________________________________________________________
_
Pg. 97

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

La Arquitectura realiza una serie de validaciones generales antes de ceder control a la aplicacin.
En el caso de que se produzca un error en alguna de ellas, el programa de la aplicacin no llega a
recibir control, sino que es la Arquitectura la que captura el mensaje de error envindolo al
terminal.
Alguna de estas validaciones son:
o Verificar que la aplicacin a la que pertenece la transaccin est disponible.
o Verificar que la transaccin est disponible.
o Verificar que el terminal est activo y con un idioma de operacin informado.
o En el caso de que una transaccin est restringida a un slo tipo de cajero ("A" o "B"),
verificar que es correcto.
o Realizar las validaciones que deberan haber sido realizadas por los aplicativos locales
sobre la informacin de entrada: campos numricos, excluyentes, dgitos, etc. y
aplicar rutinas de depuracin especficas cuando la aplicacin as lo indique.
No obstante, las rutinas de depuracin slo deberan ser utilizadas para dilogos con terminales
no inteligentes o en situaciones de urgencia.
DECODIFICAR ERRORES Y AVISOS DETECTADOS POR LA APLICACIN.
El segundo tipo de errores corresponde a aquellos detectados por el programa de aplicacin en su
proceso normal.
Cuando son detectados, la aplicacin se limita a informar a la Arquitectura del cdigo de error
que se ha producido, siendo sta la responsable de decodificarlo (capturar mensaje asociado) e
informar al terminal o teledisco del error en el idioma que corresponda a dicho terminal.
Los campos de commarea de la Arquitectura a completar en este caso son:
1. CAA. (Commarea de la Arquitectura Extendida).
o COD-ERROR
o COD-AVISO1
o COD-AVISO2
o VAR1-ERROR
o VAR1-AVISO1
o VAR1-AVISO2
o VAR2-ERROR
o VAR2-AVISO1
o VAR2-AVISO2
Se distingue entre errores de usuario (operacin errnea o abend controlado) y mensajes de
aviso (se pueden enviar hasta dos de este tipo). En total, por tanto, un terminal puede recibir
tres mensajes diferentes.
Existe la posibilidad de incluir en cualquier tipo de mensaje hasta dos literales variables.
Los pasos a seguir son:
o
Al dar de alta el cdigo de error, incluir una cadena de caracteres '@' en el
mensaje en el/los lugar/es donde aparecer la parte variable.
o
Cuando se produzca el error, informar en los campos VAR-ERROR, VAR1AVISO1, o VAR1-AVISO2, etc. la parte variable del mensaje.
o
La Arquitectura tomar el mensaje asociado y sustituir los caracteres '@' por
la parte variable en cada uno de los cdigos de error y aviso informados.
__________________________________________________________________________________________________
_
Pg. 98

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Estos mensajes variables tambin son susceptibles de ser informados en varios idiomas, en
funcin del asignado para el terminal. Para ello se debern realizar los siguientes pasos:
o
o

Dar de alta los distintos cdigos de las partes variables del mensaje de error en la tabla
QGDTTLI.
Informar desde el programa de aplicacin del cdigo de literal variable, que empezar
imprescindiblemente por una '@'.

De este modo, un mensaje (de aviso o error) cuyo contenido en la tabla es:
"EL CAMPO @@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@ "

ESTA MAL

INFORMADO.

VEA

y con los valores informados:

CAA-VAR1-ERROR=FECHA CONTABLE
CAA-VAR2-ERROR=MANUAL OPERATIVO

o @QM000001
o @TC123456

le aparecer al terminalista como:

"EL CAMPO FECHA CONTABLE ESTA MAL INFORMADO. VEA MANUAL OPERATIVO"

evitando con ello sucesivas consultas en este caso y haciendo cualquier mensaje ms
significativo.

2. CAE. (Commarea de la Arquitectura Estndar).

o ERROR-CODE
o AVISO-CODE-1
o AVISO-CODE-2
El sentido de estos cdigos es el mismo que el de los correspondientes COD-ERROR,
COD-AVISO1 y COD-AVISO2, respectivamente. No se admiten campos variables en los
mensajes.

TRATAMIENTO DE ERRORES GRAVES. CDIGOS DE RETORNO CICS Y DB2.

1. Programas desarrollados con la Arquitectura Extendida.
Cuando un programa de aplicacin on-line detecte un cdigo de retorno DB2 o CICS no
deseado, deber llamar mediante LINK al programa de gestin de errores de la Arquitectura
denominado QG1CABC. Este programa est encargado de gestionar el registro de la
incidencia en la tabla del log de errores, formatea el mensaje de error y llama al programa
QG1CLOG para la escritura en la impresora de seguimiento.

__________________________________________________________________________________________________
_
Pg. 99

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

Si el programa de aplicacin ha de deshacer las actualizaciones, es su responsabilidad emitir

un punto de sincronismo con opcin rollback. A continuacin, devolver control a la
Arquitectura.
Las exigencias desde el punto de vista del programa son:
o
o
o
o
o
o

Para el tratamiento de errores DB2:

Chequear el cdigo de retorno DB2, en cada instruccin SQL
Informar bloque de campos de CAA relativos a errores de aplicacin y devolver
control a la Arquitectura cuando se detecte un cdigo de retorno no esperado a travs
del programa de errores.
Para el tratamiento de resto de errores CICS:
Chequear EIBRESP despues de cada instruccin EXEC CICS
Pasar informacin de respuesta CICS (EIB) al bloque de errores de aplicacin del
area de comunicacin con Arquitectura y devolver control a sta.

Los campos de la commarea de Arquitectura de aplicaciones a completar por la aplicacin

para invocar al QG1CABC son:
o ABENDAR (S/N)
o PROGRAMA
o REFERENCIA
o OBJETO-ERRONEO
o SQLCODE
o SQLERRM
o EIBFN
o EIBRSRCE
o EIBRCODE
o EIBRESP1
o EIBRESP2
En caso de informarse ABENDAR a 'S', el programa QG1CABC abendar la tarea.
2. Programas desarrollados bajo Arquitectura Estndar que pasan por compatibilidad.
Cuando un programa de aplicaci on-line detecte un cdigo de retorno DB2 o CICS no
deseado, se completar la informacin de error en el rea de comunicacin entre
Arquitectura y aplicaciones estndares. Dicha informacin se compone de:
o ABEND-CODE
o SQLCODE
o SQLERRM
o TABLENAME
o EIBFN
o EIBRSRCE
o EIBRCODE
A continuacin devolver control a la Arquitectura, que tratar el cdigo de error e
informar al terminal de la forma ms completa posible.
En caso de que el programa de aplicacin haya informado el campo de abend, la
Arquitectura emitir un punto de sincronismo con opcin rollback (para deshacer los
cambios efectuados) y abendar.
__________________________________________________________________________________________________
_
Pg. 100

ARQUITECTURA ALTAMIRA V-4.3

MANUAL DE USUARIO
___________________________________________________________________________________________________

3. Informacin del error controlado.

La transaccin/conversacin al abendar presenta en pantalla al terminalista un tipo de error genrico
en el caso de errores registrados a travs del programa QG1CABC. El formato de este error es el
siguiente:
o
o
o

errores de DB2:
errores de CICS:
errores de APLICACION:

Qnnn, donde nnn es el SQLCODE (sin signo) del error.

QCnn, donde nn es el EIBRESP enviado por el CICS.
QCPG.

__________________________________________________________________________________________________
_
Pg. 101