altamira
DESCRIPTION
altamiraTRANSCRIPT
CAPITULO I
ARQUITECTURA ALTAMIRA V-4.3 MANUAL DE USUARIO
___________________________________________________________________________________________________
INDICE
5CAPITULO I : INTRODUCCION
5I.1. DEFINICION Y OBJETIVOS DEL SISTEMA.
5I.2. DEFINICION DE CONCEPTOS BASICOS.
7I.3. ESQUEMA DE MODULOS DIRECTORES DE ARQUITECTURA.
10CAPITULO II : COMUNICACION DE APLICACIONES CON ARQUITECTURA
10II.1. REA DE COMUNICACION CON LA ARQUITECTURA (CAA).
11II.1.1. DATOS GENERALES.
12II.1.2. DATOS DEL MENSAJE.
13II.1.3. AUTORIZACIONES.
13II.1.4. DATOS CONVERSACION ENTRADA/SALIDA.
14II.1.5. DATOS DE SIGUIENTE TRANSACCION.
16II.1.6. DATOS DEL MENSAJE DE SALIDA.
18II.1.7. DATOS PARA GESTION DE PAGINACION.
19II.1.8. DATOS PARA ANALITICA Y ESTADISTICAS.
20II.1.9. DATOS DE ERROR INESPERADO.
21II.2. ESQUEMA DE UNA CONVERSACION.
24II.2.1 COMIENZO DE UNA CONVERSACION.
25II.2.2. SELECCION DE UNA OPCION DEL MENU.
26II.2.3. REALIZACION DE UNA CONSULTA.
28II.2.4. REALIZACION DE UNA BAJA.
29II.2.5. ACCESO A OTRO PANEL DESDE EL DE CONSULTA/BAJA.
30II.2.6. VUELTA A LA TRANSACCION DE CONSULTA/BAJA.
33II.2.7. ACCESO AL MENU DESDE CUALQUIER PUNTO DE LA CONVERSACION.
34II.3. PARAMETRIZACION.
34II.3.1. PARAMETRIZACION DE LA ARQUITECTURA.
36II.3.2. PARAMETRIZACION DE UNA APLICACION.
37II.4. FUNCIONAMIENTO DE LA PAGINACION.
41II.5. SALIDAS NO ESTANDAR.
43II.5.1. SALIDA NO ESTANDAR SIN FORMATO ASOCIADO.
44II.5.2. SALIDA NO ESTANDAR CON FORMATO ASOCIADO.
45II.5.3. IMPRESION DESDE TERMINALES 3270.
46II.5.4. EJEMPLOS.
50II.6. ACTUALIZACION DE JOURNAL Y TOTALES.
52II.7 FUNCIONAMIENTO DE LAS AUTORIZACIONES.
53II.7.1. AUTORIZACIONES DESDE EL PUNTO DE VISTA DEL TERMINALISTA.
58II.7.2. AUTORIZACIONES DESDE EL PUNTO DE VISTA DE LOS PROGRAMAS DE APLICACION.
63II.7.3. AUTORIZACIONES DESDE EL PUNTO DE VISTA DE LOS PROGRAMAS ALTAMIRA.
66II.7.4. AUTORIZACION EN CONVERSACIONES.
66II.8. FUNCIONAMIENTO DE LA AYUDA ON-LINE.
67II.9. FUNCIONAMIENTO DE LA AYUDA ACTIVA.
68II.10.UTILIZACION DEL TELEDISCO.
70II.10.1. CARGA DE LA TABLA DE INFORMACION DE TELEDISCO EN EL BATCH.
71II.10.2. PROCESO ON-LINE DEL TELEDISCO.
72II.10.3. DESCARGA Y EXPLOTACION DE INFORMACION DEL TELEDISCO.
73II.10.4. ESTRUCTURA DEL FICHERO DE ENTRADA PARA LA CARGA DE TELEDISCOS.
75II.11. LOG DEL SISTEMA. IMPRESORAS DE SEGUIMIENTO.
76II.12. SUSPENDER / REANUDAR UNA CONVERSACION.
77II.13. EDICION DE CAMPOS NUMERICOS EN TERMINALES 3270.
81II.14. CONTROL DE TECLAS DE FUNCION.
83II.15. LISTADO DINAMICO DE TABLAS.
87II.16. CAMBIO DE SESION.
90II.16.1. CAMBIO DE SESION DE ARQUITECTURA.
93II.17. ESQUEMA Y RECURSOS DE SEGURIDAD.
94II.17.1. SEGURIDAD EXTERNA PARA LA VERSION EXTENDIDA.
96II.17.2. SEGURIDAD INTERNA PARA LA VERSION EXTENDIDA.
98II.17.3. SEGURIDAD (EXTERNA O INTERNA) PARA LA VERSION ESTANDAR.
CAPITULO I : INTRODUCCIONI.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.
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:
la informacin de la parte variable del mensaje queda recogida en el formato asociado al mensaje.
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:
Se cambia la fecha contable del da y se obtiene la siguiente.
Se inicializan las tablas para la siguiente sesin del on-line.
Se hace el proceso flip-flop de las tablas que tienen varias versiones.
Se cambia el estado de las aplicaciones que as lo deseen.
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.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:
PS/2 (LU 0)
3270 (LU 2)
Medios de Pago Electrnicos
4700
5935
Teledisco
Recepcin y anlisis del mensaje:
Mensaje de teledisco o autorizacin.
Formato de PS/2 (LU 0).
Mensaje de los distintos protocolos de medios de pago electrnicos.
Formato 4700.
Formato 5935.
Entrada libre.
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.
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.
CAPITULO II : COMUNICACION DE APLICACIONES CON ARQUITECTURAII.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.
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).
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.
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.
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:
'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.
'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:
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'
+----+
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 DATOS-CAD, 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.
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:
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:
'P'pantalla
'D' documento impreso
Hescritura en un fichero del disco duro (slo para terminales PS/2 del tipo 18).
Jescritura 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.
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:
FKEY-NUM: Cdigo de tecla permitido.
FKEY-LIT: Literal asociado a la tecla que debe aparecer por pantalla.
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 continuarhasta 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).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.
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.
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.
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
Arquitectura
AplicacinTecleo del cdigo
Cede control al
Proceso en estado
de transaccin del ----> programa asociado con ----> inicio. Inicializa
men
la transaccin
el contenido de la
pantalla de salida.
Sale en pantalla el
Enva panel de salida Evala la opcin y la tecla
una tecla de funcinla transaccin de menpulsada y decide cul es la
prxima transaccin,poniendo
Evala la accin 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 realizar la consulta.
Intro
saccin que consultaInforma la pantalla de sa-
lida con los datos de la
consulta. Pone accin=ter-
Sale en pantalla el Evala la accin
minal, cdigo de transaccin
mismo panel con los Entra en estado=continua-
de baja
programa de aplica-
cin. Valida la baja, e
cin asociado a la
informa el campo
transaccin
COD-AVISO1 con el cdigo
de aviso de "Confirme baja
con tecla PFx". Pone estado=
Sale por pantalla
Entra en estado=confirmacin.
cla indicada en
programa de aplica- Evala la tecla pulsada,
el mensaje de avi-
cin asociado a la
validando que es la correcta.
so anterior
transaccin
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
Sale en pantalla
Cede el control al --->Entra en estado=continua-
de funcin
programa de apli-
cin. Evala la tecla pul-
cacin de consulta/
sada y decide cul es la
baja
prxima transaccin, po-
niendo accin=programa y
Evala la accin Entra en estado=inicio el
siguiente programa. Ini-
cializa su pantalla de
salida. Pone accin=terminal,
estado=continuacin y
Sale en pantalla
Entra en estado=continua-
'PF3'
programa de apli-
cin y evala la tecla
cacin asociado a
pulsada. Al ser la tecla
la transaccin QMAB
'Borra' pone estado=inicio
accin=programa y en el
Evala la accin Entra en estado=inicio el
programa de aplicacin.
Inicializa la pantalla de
salida y pone accin=ter-
minal, estado=continuacin
y cdigo de transaccin
Sale en pantalla
Entra en estado=continua-
'PF9'
programa de apli-
cin y evala la tecla
cacin asociado a
pulsada. Al ser la tecla
la transaccin
'PF9' pone estado=inicio
accin=programa y en el
Evala la accin Entra en estado=inicio el
programa de aplicacin.
Inicializa la pantalla de
salida y pone accin=ter-
minal, estado=continuacin
Sale en pantalla 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:
VALOR DEL CAMPOATRIBUTO DE OPCIONATRIB. 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. 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.
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:
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:
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:
El campo de la seleccin.
El campo de contenido de las lneas.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 -CAA- llamado 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).
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.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)
= '+PF1'(Debe ser '+PFn')
IND-PANDOC(1) = 'D'
(Puede ser 'P': a pantalla o 'D': a documento)
NUM-DOCUM(1) = '1'
(Nmero de documento de un folio)
PRILIN-DOCUM(1) ='05'
(Nmero de lnea donde se comenzar a
escribir si la salida es a papel).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)
= '+DC1' (Debe ser '+DCn')
IND-PANDOC(1)= 'D'
(Puede ser 'P': a pantalla o 'D': a documento)
NUM-DOCUM(1) = '1'
(Nmero de documento, si procede)
PRILIN-DOCUM(1)= '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)
IDIOMA(1)
= 'E'
(Cdigo de idioma del preformato).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).
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:
XXXX
CONSULTA: XX
CLIENTE:
XXXXXXXX
2.- 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) =
'+PF1'
IND-PANDOC(1) = '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.
Si despus de hacer las consultas convenientes, los campos contienen:
* clave de cliente: ABCDEFGH
* nmero de cuenta: 1234567890
* saldo:
100.000
El programa escribir la cola TS de nombre '+DC1tttt', conteniendo:
AARMSALABCDEFGH12345678900000100000
4000000000000000000FFFFFFFFFF000FFFFFFFFFF
000000000000000000012345678900000000100000
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'
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: NUMAUT
- Cdigo de terminal
: CODTERM
- Cdigo de error
: CODERR
- Importe
: IMPORTE
El formato AARMLIN tendr un preformato asociado para documento (campo PREF_DOCUM) llamado, por ejemplo, AALIN, y que tendr una lnea:
@@@@@@@ @@@@@@@@ @@@@@@@ @@@@@@@
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:
AARMCABP99909/09/1990
400000000000000000
000000000000000000
y cada una de las dos siguientes conteniendo:
AARMLIN0000001P999QGE00330001000
4000000000000000000000000
0000000000000000000000000
y la ltima:
AARMLIN0000002P999QGE00440445640
4000000000000000000000000
0000000000000000000000000
en los campos de la commarea CAA:
DESTINO(1) =
'+DC1'
IND-PANDOC(1) = 'D'
NUM-DOCUM(1) = (Si tiene documento asociado)
PRILIN-DOCUM(1) = (Si no debe comenzar a escribir en la lnea 1)
IDIOMA(1) =
(Si se desea distinto del asignado al terminal).
II.6. ACTUALIZACION DE JOURNAL Y TOTALES.
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: 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.
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 Arquitectura Progr. Aplicacin Lanza una transaccin -----> ------------> La operacin que se
desea realizar nece-
sita autorizacin,
con un perfil de
usuario determinado.
La Arquitectura Enva mensaje de
da de alta un El programa de
aplicacin realiza
la operacin.
Cuando llega a la va-
lidacin que la vez
anterior provoc la
autorizacin, se per-
cata de que ya est
autorizada, y sigue
con el proceso. Si no
existen ms motivos de
autorizacin, finaliza
normalmente la opera-
cin, y manda la sa-
lida al terminal indi-
cando que se ha termi-
nado el proceso con
Recibe mensaje de