II.

Programación Online bajo Altamira

1. DEFINICION DE CONCEPTOS BASICOS.

 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 diálogo transaccional,
caracterizado por una única petición 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 básica mediante la cual

se comunican las aplicaciones con la Arquitectura transmitiéndose recíprocamente información y
peticiones.

 MENSAJE:

Es el bloque de información que viaja entre los terminales y el Host a través de las líneas telefónicas
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 estándar (formato tipo BMS)
de forma que a éstas les es transparente el tipo de terminal con el que están interactuando. Para
terminales 3270 la Arquitectura permite trabajar con BMS de entrada en distintos idiomas, según se
haya prefijado el terminal.

En salida, la Arquitectura ha de codificar de nuevo el mensaje en función de qué tipo de terminal es

el destinatario, evitando el transmitir campos innecesarios por no haber sido modificados, líneas en
blanco, espacios repetidos, etc.

 FORMATO:

Se denomina formato al conjunto de características de cada uno de los mensajes que viajan entre el
Host y los dispositivos locales en oficinas (terminal, impresora, dispensador, etc).

Las características son: campos asociados, preformatos a utilizar, validaciones a realizar, etc.

Cada transacción puede tener asociado un formato de:

136 Systemcorp S.A

 - 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 conversación. 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 aplicación.

De esta forma, la Arquitectura guardará la información completa de un mensaje en dos niveles:

- la información de la parte variable del mensaje queda recogida en el formato

asociado al mensaje.

- la información de la parte de literales del mensaje (parte fija) queda recogida en el

preformato.

 ERRORES Y AVISOS:

Son dos tipos de mensajes a pantalla que informan al terminalista sobre algún tipo de incidencia que
se haya producido durante el proceso.

Los avisos son mensajes puramente informativos sobre el proceso, mientras que los errores indican
algún problema que ha impedido que el proceso se desarrolle con normalidad.

Estos tipos de mensajes son susceptibles de mostrar la información 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 información que contienen es un bloque de datos para cada terminal, tipo de total y divisa de la operación,
así como el usuario que la ha realizado.

236 Systemcorp S.A

 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
información con destino a Contabilidad General.

 TECLEOS:

Conjunto de operaciones que se efectúan desde los terminales y telediscos, donde quedan registradas
todas las características de cada transacción que se ejecuta a través de la Arquitectura (terminal,
transacción, fecha y hora, datos de la operación, etc.).

 TELEDISCO:

Proceso mediante el cual se ejecutan automáticamente a través del Teleproceso un conjunto de

transacciones originadas por una aplicación batch.

 CAMBIO DE SESIÓN:

Proceso que se produce al cierre del día contable, y en el que:

- Se cambia la fecha contable del día y se obtiene la siguiente.

- Se inicializan las tablas para la siguiente sesión 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 AUTORIZACIÓN:

Permite realizar una serie de operaciones especiales previa identificación de un usuario que las
"autorice" y que quedará registrado como sujeto responsable de dicha operación.

La autorización en sí se realizará en el programa de aplicación en combinación con recursos de seguridad

(interna o externa).

 COMPATIBILIDAD CON APLICACIONES ESTÁNDARES:

La Arquitectura Extendida permitirá ejecutar aplicaciones Estándares mediante un módulo que

convierte la commarea y los mensajes de entrada y salida de la Arquitectura Extendida al formato
manejado por los programas de aplicación Estándares (y viceversa), de manera que dichas
aplicaciones se puedan incorporar a esta Arquitectura sin excesiva dificultad.

336 Systemcorp S.A

436 Systemcorp S.A
 ESQUEMA DE SEGURIDAD:

Protección 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 según el
nivel de autorización que tenga el usuario que las efectúe.

La Arquitectura proporciona un esquema de seguridad mediante tablas internas, aunque se

recomienda dejar delegada esta gestión al RACF (seguridad externa).

536 Systemcorp S.A

2. Commarea de Arquitectura

Los programas de aplicación "hablarán" con la Arquitectura fundamentalmente a través de un área de

comunicación (Comunicación de Aplicaciones con la Arquitectura: CAA), que recibirán siempre como
primera parte de su Commarea.

También las aplicaciones podrán utilizar la Arquitectura para desarrollar conversaciones (que siempre estarán
en modo pseudoconversacional).

A
R Informa los parámetros A
Q necesarios para el P
U desarrollo de sus L
I procesos Online I
T C
E A
C T
T Realiza peticiones de I
U salida de mensajes e V
informa el resultado de los
R porrcesos
O
A

El contenido de la CAA se divide en información de entrada, de salida y de entrada/salida de la aplicación.

Info rmac ió n de Datos Generales

Entrada Datos del Mensaje (Copy BMS)

Info rmac ió n de Autorizaciones

Entrada//S alida
Entrada Datos de Conversación

Datos de Siguiente Transacción

Datos del Mensaje (Copy BMS)

Info rmac ió n de Datos Salida no Estandar

S alida Datos Gestión de Paginación
Datos Analítica y Estadísticas
Datos Error

636 Systemcorp S.A

1.1. Información de Entrada. DATOS GENERALES.

Los programas de aplicación podrán utilizar los campos de este segmento para recoger cualquier
información general del sistema y en ningún caso podrán modificar su contenido.

Los campos de que consta son:

* ENTIDAD: Código de la entidad contable y del terminal que realiza la operación.

* CENTRO-CONT: Código de oficina contable del terminal que realiza la operación.

* NETNAME-CONT: El Netname es un código único para una red, mientras que el

código de terminal puede, para un mismo terminal físico, ser diferente para cada
CICS en el que trabaje (MRO).

* TERMINAL-CONT: Código del terminal contable que realiza la operación.

* FECHA-CONT: Fecha contable asociada a la operación en formato AAAAMMDD.

* FECHA-CONT2: Fecha contable asociada a la operación en formato AAAA-MM-

DD.

* FECHA-CONTED: Fecha contable asociada a la operación en el formato

DD/MM/AAAA.

* FECHA-OPER: Fecha de operación. Será la fecha de operación del proceso, a

menos que el terminal tenga asociada una fecha de operación distinta, en cuyo caso
será ésta la que figure. El formato es AAAAMMDD.

* FECHA-OPER2: Fecha de operación en formato AAAA-MM-DD.

* FECHA-OPERED: Fecha de operación en formato DD/MM/AAAA.

* FECHA-TRANS: Fecha de transmisión. Es la fecha natural en que se realiza el

proceso, en formato AAAAMMDD.

* FECHA-TRANS2: Fecha de transmisión en formato AAAA-MM-DD.

* FECHA-TRANSED: Fecha de transmisión en formato DD/MM/AAAA.

736 Systemcorp S.A

* HORA-TRANS: Hora de transmisión. Es la hora en que se realiza el proceso en
formato HHMMSS.

* HORA-TRANSED: Hora de transmisión anterior en formato HH:MM:SS.

* NETNAME: Código del terminal en red físico que realiza la operación.

* TERMINAL: Código del terminal que realiza la operación. Coincide con el

EIBTRMID de CICS.

* USERID: Usuario identificado en CICS.

* SESION: Indicador de sesión de mañana ('M') o tarde ('T').

* TIPO-TERM: Tipo de terminal que realiza la operación. Los tipos de terminal

válidos son:

'11': tipo 4700

'12': tipo 5935
'13': tipo PS/2 Estándar
'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 emulación (tipo 3270)
'29': 4700 en emulación (tipo 3270)
'51': impresoras
y otros numerosos (a partir del tipo '40' para la aplicación de Centro
Autorizador (CECA, SEMP, 4B, ATM´s y TPV´s).

* CICS: Identificador de la sesión CICS (SYSID).

* CODTRAN: Código de transacción que se ejecuta según 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 estaría ejecutando siempre la misma transacción, y sin embargo
para la Arquitectura se estaría ejecutando en cada momento la transacción asociada
a cada uno de los programas (dos distintas).

* TIPO-PROCESO: Tipo de proceso que se está ejecutando. Puede ser:

'O': on-line

836 Systemcorp S.A

 'A': autorización
'T': teledisco
'F': off-line

* ESTADO-APLIC: Estado en que se encuentra la aplicación a que pertenece la

transacción para la Entidad del terminal. Puede ser:

'A': Activa
'D': Desactiva
'C': En cambio de sesión
'R': En recuperación (no utilizado en la actualidad).

* IDIOMA-TERM: Código del idioma de trabajo del terminal. Toda la información de

salida de pantallas y documentos se gestiona a través de idioma asignado a cada
terminal.

1.2. Información de Entrada. DATOS DEL MENSAJE.

Contiene toda la información necesaria sobre el mensaje de entrada en los campos:

* TECLA: Código de la tecla pulsada. Este código 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

Existen varias teclas con significado estándar para la Arquitectura y todas las
aplicaciones que la utilicen:

* PF1: Tecla de ayuda en conversaciones. Si la transacción que se está ejecutando

en la conversación tiene ayuda asociada, al pulsar PF1 se mostrará la ayuda
por pantalla.

* Borra: Ir a la pantalla anterior en una conversación.

* PF9: Ir al menú inicial en conversaciones.

* PF11 o Shft-PF1: Suspender la conversación en curso.

* PF12 o Shft-PF2: Autorización en una conversación.

* CAJERO: Código de cajero pulsado, que será:

936 Systemcorp S.A

 '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 función sin modificar datos ('N'). Este concepto es, por tanto,
relevante para procesos conversacionales.

* PTR-COPYIN: Dirección 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 aplicación encontrarán en este área la información de la
pantalla de entrada, y deberán modificar los campos pertinentes para construir la
nueva pantalla de salida.

1.3. Información de Entrada-Salida. AUTORIZACIONES.

En este segmento se recoge la información sobre el proceso de autorizaciones. Los programas de

aplicación reconocen en este segmento las operaciones que ya han sido autorizadas por el
terminalista para no volver a producir una solicitud de autorización por el mismo. Asimismo, en este
segmento se recogen los campos que debe informar un programa de aplicación cuando necesita una
autorización.

Este bloque consta en primer lugar de 10 ocurrencias (una por cada uno de los "motivos" por los que
se necesita autorizar). Estos campos vendrán sin informar la primera vez que se realice la operación,
y tendrán que ser informados con los valores correspondientes de código de error y situación cuando
se pida la autorización. Cuando el terminalista realice la autorización, estos campos llegarán al
programa de aplicación con los valores que se informaron cuando se pidió dicha autorización. Estos
campos son:

* CODERR-AUT: Código de error identificativo del motivo de la autorización.

* SITUACION-AUT: Situación por la que se está autorizando la operación.

Los siguientes campos de este segmento deben ser informados por el programa de aplicación cuando
se produce la necesidad de autorizar una operación:

* IND-AUTO: Indicador de pendiente de autorización:

'S': operación pendiente de autorizar

'N', ' ': operación no pendiente de autorizar

* IMPORTE-AUTO: Importe total de la operación pendiente de autorización.

1036 Systemcorp S.A

 * REFER-AUTO: Referencia de la operación según la aplicación.

1.4. Información de Entrada-Salida. DATOS DE CONVERSACION.

Información utilizada en los programas conversacionales. Sirve para controlar el flujo de la

conversación. Consta de los campos:

* ESTADO: Indicador del estado en que se encuentra la transacción en curso. Puede

tomar los siguientes valores:

'I': Estado INICIO. Indica que se entra a ejecutar la transacción por primera
vez, estando en el terminal una pantalla distinta a la correspondiente a
dicha transacción. En consecuencia, la única información de entrada al
programa válida en estado inicio es la de la commarea entre los programas
aplicación (no hay pantalla de entrada a "leer").

'C': Estado CONTINUACION. Indica que se entra a ejecutar la transacción

estando en el terminal la pantalla propia de dicha transacción, por lo tanto
son válidos los datos de entrada tecleados desde el terminal como entrada
a la transacción. Dichos datos entran en formato BMS en la dirección de
memoria indicada en el campo PTR-COPYIN.

'X': Estado CONFIRMACION. Estado especial dentro de una continuación

para permitir la confirmación de una operación en curso. Se puede
considerar un caso especial del estado continuación, donde se espera, en
primer lugar que no se modifique ningún dato de la pantalla, y en
segundo lugar que se pulse una tecla determinada que signifique la
confirmación de la operación.

* CASO: Indicador utilizado cuando un programa de aplicación 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 código si le ha cedido el control un programa de consulta
de cuenta por pantalla, o por el código de cliente si le ha cedido el control un
programa de la aplicación de clientes.

* DATOS: Campo que pueden utilizar los programas de aplicación para pasar datos
entre ellos. Es una commarea entre programas de aplicación de 30 caracteres de
longitud. Si la commarea entre programas de aplicación es mayor de 30 caracteres,
o no se desea utilizar este campo, se pueden guardar dichos datos en la dirección
de memoria indicada en el campo PTRDATA.

1136 Systemcorp S.A

 * LONDATA: Este campo es gestionado por la Arquitectura. No se debe modificar.

* PTRDATA: Dirección de memoria que contiene la commarea entre los programas

de aplicación.

1.5. Información de Salida. 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 aplicación. En éste se encuentra la información sobre la siguiente transacción que debe
ejecutarse. Consta de los campos:

* CODTRAN-SIG: Código de la siguiente transacción que se debe ejecutar. Cuando

se rellena a espacios querrá decir que no debe entrar ninguna transacción a
continuación (este es el caso de un programa transaccional, o de la salida de una
conversación).

Existen varios valores que no son códigos de transacción y que la Arquitectura

interpreta de manera especial:

- 'SAME': Cuando debe entrar a continuación la transacción 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 transacción, que no se
corresponde con la de la transacción en curso, y al darse un error, no debería
aparecer la nueva pantalla, sino la que figura en el terminal enviando el
mensaje de error correspondiente, por lo que la siguiente transacción que se
debe ejecutar es la que mandó la pantalla al terminal.

- 'ULTI': Cuando debe entrar a continuación la última transacción que se

añadió en la cadena (ver campo CADENA).

- 'MENU': Cuando debe entrar a continuación la primera transacción de la

cadena, que en general será el menú principal (ver campo CADENA).

* AUTOMATICA: Indica (S/N) si la siguiente transacción debe ejecutarse

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

1236 Systemcorp S.A

* ACCION: Indica si la Arquitectura debe ceder el control directamente a otro
programa de aplicación sin enviar ningún tipo de mensaje de salida al terminal
(acción programa: 'PRG'), o si debe enviar algún mensaje de salida al terminal
(acción terminal: 'TER').

* CADENA: La Arquitectura mantiene una relación de las transacciones sucesivas

que van tomando control en una conversación, empezando por la que inicia la
conversación (que normalmente será el menú principal), y que constituyen la
cadena de transacciones.

De esta manera, en cualquier punto de la conversación, el terminalista puede

realizar la petición de volver a la transacción inmediatamente anterior (con la tecla
Borra en nuestro caso), o bien de volver a la transacción inicial que realizó (con la
tecla PF9 en nuestro caso).

1336 Systemcorp S.A

Gráfico 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'

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 aplicación deben controlar la construcción de la cadena haciendo

peticiones a la Arquitectura, bien de iniciarla, bien de añadirse a ella, o bien de
volver a alguno de los pasos anteriores.

El momento en que un programa de aplicación debe realizar alguna petición de

modificar la cadena es cuando va a ceder control a otra transacción distinta a ella
(es decir, cuando CODTRAN-SIG lo informa con un código de transacción distinto
al suyo y distinto de 'ULTI' o 'MENU', y ACCION con el valor 'PRG'). Este es el
momento de realizar la petición de añadirse a sí mismo en la cadena. Esta petición
se realiza informando el campo CADENA con el valor 'A' (de Añadir).

Si el programa que quiere añadirse en cadena es el que inicia la conversación (por

ejemplo, el menú), la cadena todavía 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 transacción que realiza esta petición como primera de la cadena.

Si el terminalista realiza la petición de volver a la transacción inmediatamente

anterior, el programa de aplicación no tendría más que indicar a la Arquitectura
que la siguiente transacción a ejecutarse es la última en cadena informando el valor
'ULTI' en el campo CODTRAN-SIG, y la Arquitectura cedería el control a la última
transacción almacenada en la cadena.

1436 Systemcorp S.A

 Asimismo, si el terminalista realiza la petición de volver a la transacción inicial de
la cadena, el programa de aplicación debería informar el campo CODTRAN-SIG
con el valor 'MENU', con lo que la Arquitectura cedería el control a la primera
transacción almacenada en la cadena.

* CASO-CAD: En la cadena de transacciones, la Arquitectura guarda, junto al código

de transacción, 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 pasarán a la transacción
cuando se vuelva a ella por retroceder en la cadena (y que le llegarán en los campos
CASO Y DATOS respectivamente).

Se deben informar (si es necesario) cuando se realiza una petición de añadirse o de

iniciar la cadena (es decir, cuando se informa el campo CADENA).

* DATOS-CAD: Datos propios de entrada al retroceder en cadena.

1.6. Información de Salida. DATOS DEL MENSAJE DE SALIDA.

En este segmento, los programas de aplicación proporcionan a la Arquitectura toda la información

sobre las distintas salidas al terminal. Solamente se tendrá en cuenta cuando la acción sea terminal
(ACCION='TER').

Consta de los campos:

* COD-ERROR: Código del error producido.

* COD-AVISO1: Código del primer aviso. Hay posibilidad de mandar hasta dos
avisos al terminal, que saldrán en la línea 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: Código del segundo aviso.

* VAR1-ERROR: Variable primera del mensaje de error. Se puede informar con una
variable válida como literal de error multi-idioma. Esto es válido 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.

1536 Systemcorp S.A

* VAR2-AVISO2: Variable segunda del segundo aviso.

* IMPORTE-DISP: Importe que debe proporcionar el dispensador.

* DIARIO-LOCAL: Campo a actualizar en el diario electrónico 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 paginación 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 aplicación

se trate de un listado, en cuyo caso dicho programa debe poner este campo con
valor 'P' (paginación). En otro caso, la Arquitectura gestiona este valor con sus
valores por defecto (Valor 'S' en Estado Inicio y valor 'E' en estado
Continuación o Confirmación).

* 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 aplicación 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 aplicación no debe informarlo.

* DESTINOS: (Ver.Salidas no estándar).

Las transacciones pueden tener dos tipos de salidas: la salida estándar, y la salida
no estándar.

La salida estándar siempre va dirigida a pantalla y está constituida por el contenido

de la dirección de memoria indicada en el campo PTR-COPYIN (es decir, el
contenido de la pantalla estándar de salida en formato BMS) y por los mensajes de
error / aviso.

La salida no estándar está constituida por cualquier otro tipo de salida, y puede
estar dirigida a pantalla o a documento. Los programas de aplicación deben pasar
el contenido de estas salidas no estándares en una serie de colas TS que pueden ser:

1636 Systemcorp S.A

 - 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 estándares) y XXXX es el código del
terminal (campo TERMINAL). Se utilizan estas colas cuando la salida está en
modo "preformato", es decir, no tiene ningún 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 estándares) y XXXX es el
código 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 estándar y después el contenido del mensaje en forma
BMS.

La Arquitectura permite hasta cinco salidas diferentes no estándares. 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
- ‘H’ escritura en un fichero del disco duro (sólo para terminales PS/2 del
tipo 18).
- ‘J’ escritura de documento con formato JetForms (sólo para terminales
PS/2 del tipo 19 - FFS/Altamira).

1736 Systemcorp S.A

 * NUM-DOCUM: Número de documento si la salida es a documento y éste
tiene uno asociado. Puede tomar los valores:

* '1': DIN A-4 Impresión normal.

* '2': DIN A-4 Impresión comprimida.
* '3': Cuartilla
* '5','6','7','8': Libretas
* '9': DIN A-4 en Impresora LASER.
* 'C': Cheque
* 'B': Banda
* 'I': Importe
* 'J': Diario magnético
* 'R': Documento preimpreso

* PRILIN-DOCUM: Posición de la primera línea que se debe escribir en el

documento (si la salida es a documento).

* IMPRESO: Código del impreso a introducir en la impresora financiera.

* IDIOMA: Código del idioma en el que se van a imprimir los datos de la

salida no estándar.

1.7. Información de Salida. DATOS PARA LA GESTION DE PAGINACION.

Este segmento es utilizado por los programas de listado para permitir la gestión de paginación por la
Arquitectura. Los campos de este segmento deben ser rellenados cuando el programa de listado
informe el campo TIPO-SALIDA con valor 'P'. Los campos son:

* CONTENID: Contenido genérico del listado, que puede indicar el tipo de selección
por el que se ha accedido al programa de listado.

* SELEC-PERMIT: Contiene 10 ocurrencias de 1 carácter de longitud que contienen

los caracteres permitidos para seleccionar las líneas del listado.

* IND-VARSEL: Indicador de si se permite marcar como seleccionadas mas de una

línea ('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.

1836 Systemcorp S.A

* FKEY: Grupo de 8 ocurrencias, donde se indica al programa de gestión de listados
hasta 8 teclas válidas que se pueden teclear, aparte de las propias del listado (PF4:
izquierda, PF5: derecha, PF7: arriba, PF8: abajo). El programa de gestión de
paginación de la Arquitectura devolverá el control al programa de aplicación de
listado cuando se haya pulsado una de estas teclas, y las selecciones efectuadas
sean válidas. Cada una de las ocurrencias consta de:

* FKEY-NUM: Código de tecla permitido.

* FKEY-LIT: Literal asociado a la tecla que debe aparecer por pantalla.

* FKEY-SEL: Se le indica al programa de gestión de listados si con la tecla

pulsada debe haber una selección ('S'), no se permite ninguna selección ('N') o
es indiferente que se haya seleccionado alguna línea del listado o no (' ').

* IND-AVPAG: Indicador (valores S/N) para el programa de gestión de listados, que

indica si se desea que se devuelva control al programa de aplicación cuando se
teclee la tecla PF8 (Scroll abajo) y no existan mas líneas 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 gestión de paginación de la Arquitectura le
devolverá control al programa de listado en estado "continuación". En ese caso el
programa de listado deberá llenar la cola TS del listado con un grupo mas de líneas.
Este proceso se continuará hasta que el programa de listado no tenga mas líneas
que recuperar, en cuyo caso informará este indicador con el valor 'N'.

* IND-MOD-DATO: Indicador (valores S/N) para el programa de gestión de

listados, con el que un programa de aplicación puede pedirle que refresque el
contenido de la cola TS que contiene las líneas de listado cada vez que tome el
control dicho programa de gestión de listados.

En realidad solamente tiene sentido cuando las líneas de listado están

desprotegidas, para permitir teclear su contenido desde el terminal, y en ese caso se
debe actualizar la información de dichas líneas de listado en la cola TS cada vez que
se cambien por pantalla.

* LÍNEA-PANT: Este campo lo utiliza exclusivamente el programa de gestión de

listados, y los programas de aplicación no deben modificarlo.

* COLUM-PANT: Este campo lo utiliza exclusivamente el programa de gestión de

listados, y los programas de aplicación no deben modificarlo.

1936 Systemcorp S.A

 * NUM-LIN-CAB: Número de líneas fijas para la cabecera del listado. Si no se
informa este campo, se considerará siempre al menos 1 línea por defecto. Las líneas
de cabecera permanecerán brillantes y protegidas, y no se moverán 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 líneas 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 paginación 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: Número de item seleccionado (en el caso de selección única).

En el caso selección múltiple, el primer seleccionado.

* IDTABLA: Nombre de la tabla para el listado dinámico de tablas. También puede

contener los 10 primeros caracteres del item seleccionado en un listado dinámico
de tablas.

1.8. Información de Salida. DATOS PARA ANALITICA Y ESTADISTICAS.

En este segmento los programas de aplicación proporcionan a la Arquitectura información para ser
explotada por alguna aplicación de contabilidad analítica y para recoger estadísticas gestionadas por
la propia Arquitectura. Consta de los campos:

* ENTIDAD-ANA: Entidad destino para analítica.

* CENTRO-ANA: Centro destino para analítica.

* PRODUCTO-ANA: Clave del producto asociado para analítica.

* CLIENTE-ANA: Cliente para analítica.

* IMPORTE-ANA: Importe para analítica.

* SUBPROD-ANA: Subproducto para analítica.

* FINALID-ANA: Finalidad para analítica.

* GARANTIA-ANA: Garantía para analítica.

* SUB-CLASIF: Subclasificación de la transacción para analítica.

* TIOPER: Tipo de operación realizada. Puede tomar los valores:

2036 Systemcorp S.A

 'A': Alta
'B': Baja
'M': Modificación
'C': Consulta
'E': Edición
'P': Petición al batch
'O': Operación de entrada / salida
' ': Ninguna de las anteriores

 CONTABLE: Indicador de si la operación realizada es contable ('S') o no ('N').

* DATOS-APLIC: Datos de libre uso para la aplicación.

1.9. Información de Salida. DATOS DE ERROR INESPERADO.

Información 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 función 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: Código de respuesta de CICS. Es el contenido de la variable

EIBRCODE del grupo DFHEIBLK.

* EIBRESP1: Condición producida por la función CICS que produjo el error. Es el

contenido de la variable EIBRESP del grupo DFHEIBLK.

* EIBRESP2: Información adicional a EIBRESP1. Es el contenido de la variable

EIBRESP2 del grupo DFHEIBLK.

2136 Systemcorp S.A

2236 Systemcorp S.A
3. Conversacionales Vs. Transaccionales

Altamira opera con dos modalidades Online, los dialogos Conversacionales y los Transaccionales.
En los transaccionales el terminalista realiza una petición al sistema sin poder acruar sobre la respuesta de
este, existe un flujo único de datos.

ENTRADA Recepción de TR Envío de SALIDA

Datos Datos
Flujo único – transaccional -

Un dialogo conversacional es un conjunto de pantallas entrelazadas entre sí de modo que el terminalista tiene
la oportunidad de actuar sobre cualquiera de las respuestas que recibe. Como resultado de esto se obitiene
programas más complejos, pudiendo manejar distintos orígenes (CASO) y secuencias (ESTADO) de entrada.
Se controlará quíen les ha cedido el control ellos u otros programas , si es la primera vez que se ejecuta dentro
de la secuencia de llamada, etc.

2336 Systemcorp S.A

4. Conversacional

La Arquitectura mantiene una relación de transacciones sucesivas que van tomando control en una
conversación, empezando por la que inicia la conversación (que normalmente será el menú principal), y que
constituyen la Cadena de la conversación.

De esta manera el terminalista puede realizar la petición de volver a la transacción inmediatamente anterior en
cualquier punto de la conversación, o bien volver a la transacción inicial que realizó.

Un código de transacción lleva asociado un sólo programa y éste a su vez una única pantalla.

4.1. Detalle de la COMMAREA

Los campos que intervienen en la commarea para la gestión de la conversación, son:

* CAA-TECLA: Código de tecla

‘00’ Intro
‘01’ PF1
...........
‘10’ PF10
‘99’ Borra

* CAA-MOD-TAG: Valor (s/n). Indica si se han modificado datos de pantalla.

* CAA-PTR-COPYIN: Dirección de memoria de la pantalla de entrada (siempre en forma BMS).

* CAA-ESTADO: Estado en que se encuentra la transacción conversacional.

Puede ser:
‘I’ Inicio: Es la primera vez que entra el programa de aplicación, y en el terminal se
encuentra la pantalla de la transacción anterior.
El programa deberá rellenar su pantalla para enviarla al terminal.
’C’ Continuación: La pantalla de la transacción ya se encuentra en el terminal, y se han leído
sus datos. El programa de aplicación deberá actuar dependiendo de estos
datos y de la tecla de función pulsada (CAA-TECLA).
‘X’ Confirmación: En la ejecución anterior se pidió confirmación de una operación. Se deberá
actuar según los criterios del diseño (por ejemplo, según la tecla pulsada).

* CAA-CASO: Contiene un indicador de quién le cedió el control al programa la primera

vez que se ejecuta. Deberá estudiarse su valor en “estado inicio” (CAA-
ESTADO = ‘I’ ).

* CAA-DATOS: Especie de commarea de la aplicación en ciertos casos (según se verá en

los campos CAA-CADENA).

2436 Systemcorp S.A

* CAA-PTRDATA: Dirección de memoria de la commarea de la aplicación. La longitud de
esta commarea se encuentra en la tabla de transacciones.

* CAA-CODTRAN-SIG: Código de transacción que se ejecuta a continuación. Puede ser la misma

transacción (CAA-CODTRAN) u otra distinta (ir a otra pantalla). También
posibles valores ‘ULTI’, ‘MENU’ y ‘SAME’.

* CAA-ACCION: Indica a la arquitectura si el programa de aplicación ha generado un

mensaje de salida al terminal (CAA-88-ACCION-TERMINAL), o bien, si
se va a dar control a otro programa de aplicación (CAA-88-ACCION-
PROGRAMA).

* CAA-CADENA: Campo utilizado para construir la cadena de transacciones que guarde la

arquitectura. Se debe informar con CAA-88-CADENA-ANADIR cuando
se va a dar control a otra transacción (CAA-88-ACCION-PROGRAMA).

* CAA-CASO-CAD: Caso con que entrará de nuevo la transacción (CAA-CASO) cuando la

arquitectura le de control por haber pulsado la tecla estándar de ir a la
pantalla anterior (BORRA).

* CAA-DATOS-CAD: Datos que le llegarán en el campo CAA-DATOS en la misma situación

que el campo anterior.

2536 Systemcorp S.A

4.2. Esquema de una conversacion

TERMINAL ARQUITECTURA APLICATIVO

Te c le o de l c ó dig o de Ce de c o ntro l al Pg m.
Trn. de Me nú as o c iado c o n la
trans ac c ió n Pro c e s o e n Es tado ‘I’.
Inic ializa e l c o nte nido
de la pantalla de s alida,
Envía a pantalla de po ne Ac c ió n ‘TER’,
S alida as o c iado a la c o dig o de trn. e lla
trans ac c ió n de me nú mis ma y Es tado ‘C’.
de s pué s de e valuar la
ac c ió n TER
S ale e n pantalla e l
me nú, s e e lig e una
o pc ió n y s e puls a Pro c e s o e n Es tado ’C’.
ENTER Ce de c o ntro l al Pg m.
as o c iado c o n la Evalúa la Opc ió n y la
trans ac c ió n Me nú te c la puls ada y de c ide
c ual e s la pró xima trn.
Po ne Ac c ió n ‘PRG’ y
Es tado ‘I’
Evalúa la Ac c ió n =
‘PRG’ y da c o ntro l al
pg m. as o c iado a la
s ig uie nte trn. que ha
s ido invo c ada
Entra e l prg . de
aplic ac ió n e n Es tado ‘I’.
Inic ializa e l c o nte nido
S ale e n pantalla e l Evalúa la Ac c ió n = de la pantalla de s alida,
me nú, s e e lig e una ‘TER’ y e nvía la po ne Ac c ió n ‘TER’,
o pc ió n y s e puls a pantalla as o c iada a c ó dig o de Trn. e lla
ENTER la nue va trans ac c ió n mis ma y Es tado ‘C’

2636 Systemcorp S.A

4.3. Esquema de un programa Transaccional

Direccionar pantalla de entrada (CAA-PTR-COPYIN), normalmente en formato BMS

(Basic Papping Support).
Direccionar commarea de conversación (CAA-PTRDATA)
INICIO Acción terminal y CAA-CODTRAN-SIG = CAA-CODTRAN
Inicializar Workas, Tablas, Spad, Commarea CAA suceptibles de ser modificadas en la
ejecución del programa.
Declarar cursores y abrirlos

Acceso a tablas, validaciones, etc. propias del

proceso del programa.
PROCESO Información de incidencias detectadas:
códogos de error, aviso, abend, Petición de
Autorizaciones requeridas.

FINAL Completar información de totales si la

transacción es contable y no hubo errores.
Los campos ESTADO, CASO Y
ACCION tendrán siempre los mismos
valores ‘I’, ‘N’ y ‘TER’.
Cerrar Cursores
Return

2736 Systemcorp S.A

4.4. Esquema de un programa conversacional

Direccionar pantalla de entrada (CAA-PTR-COPYIN)

Direccionar commarea de conversación (CAA-PTRDATA)
INICIO Acción terminal y CAA-CODTRAN-SIG = CAA-CODTRAN
Inicializar Workas, Tablas, Spad, Commarea
Declarar cursores y abrirlos dependiendo del caso (si fuera necesario)

Chequear caso (CAA-CASO)

Rellenar pantalla
CAA-ESTADO=CONTINUACION
Si CAA-88-ESTADO-INICIO
Si ERROR [CAA-CODTRAN-
SIG=‘SAME’]

Chequear tecla pulsada (CAA-TECLA)

Si necesita confirmación:(CAA-
ESTADO=‘X’)
Si no necesita confirmación: (CAA-
PROCESO ESTADO=‘C’)
Si se va a dar control a otra conversación:
Si CAA-88-ESTADO-CONTINUACION CAA-88-ACCION-PROGRAMA
CAA-CODTRAN-SIG=‘XXXX’
CAA-88-ESTADO-INICIO
CAA-88-CADENA-ANADIR
CAA-CASO-CAD=‘.’
CAA-DATOS-CAD=‘........’

Si CAA-88-ESTADO-CONFIRMACION Chequear tecla pulsada (CAA-TECLA)

CAA-ESTADO=CONTINUACION

FINAL Return

2836 Systemcorp S.A

El programa de aplicación realizará:

 Direccionamiento de la pantalla de entrada

 (CAA-PTR-COPYIN).
 Direccionamiento de la commarea propia de la Aplicación
 (CAA-PTRDATA).

Evalúa el estado en que se encuentra la transacción:

 En estado INICIO (CAA-88-ESTADO-INICIO):

 Informará datos por defecto en la pantalla de entrada (este estado se puede obviar en el programa si
la pantalla inicial debe aparecer vacía).
 Informará:
CAA-88-ESTADO-CONTIN
CAA-88-ACCION-TERMINAL
CAA-CODTRAN-SIG = CAA-CODTRAN

 En estado CONTINUACION (CAA-88-ESTADO-CONTIN):

 Evaluará tecla de función pulsada.
 Actuará según la tecla.
 Para seguir en la misma transacción:
CAA-88-ACCION-TERMINAL
CAA-88-ESTADO-CONTIN o CAA-88-ESTADO-CONFIR (en este caso, el programa de
aplicación deberá tratar el estado confirmación, además de los estados inicio y continuación)
CAA-CODTRAN-SIG = CAA-CODTRAN
 Para ir a otra transacción:
CAA-88-ACCION-PROGRAMA
CAA-88-ESTADO-INICIO
CAA-CODTRAN-SIG= Código de la siguiente transacción.

 En estado CONFIRMACION (CAA-88-ESTADO-CONFIR):

 Evaluará tecla de función pulsada.
 Actuará según la tecla.
 Para seguir en la misma transacción:
CAA-88-ACCION-TERMINAL
CAA-88-ESTADO-CONTIN
CAA-CODTRAN-SIG = CAA-CODTRAN

2936 Systemcorp S.A

5. Paginación

5.1. Funcionamiento

La arquitectura proporciona a las aplicaciones la posibilidad de gestionar la paginación en forma automática.

Se entiende por paginación la posibilidad de mostrar información repetitiva por pantalla de forma que el
usuario pueda desplazarse dentro del conjunto de datos en cuatro direcciones.

Todos los programas que empleen el módulo de paginación utilizan un mapa común y único (QCRMGTS) en
el cual el cuerpo de datos consta de:
 Una parte fija compuesta por los siguientes campos:
 Salto.
 Contenido.
 Línea .
 Columna .
 Cabecera de listado (de 1 a 5 líneas).
 Un caracter de selección por cada línea.
 Los datos a paginar almacenados en un único campo de 77 posiciones.

El programa de aplicación escribe las líneas a paginar en una cola TS, y al ceder el control a la Arquitectura,
ésta gestiona todas las funciones de paginación (hacia arriba, abajo, izquierda y derecha) de forma automática.

La arquitectura volverá a dar el control a la aplicación cuando se haya pulsado una tecla que no sea una de las
estándares de paginación.

Los datos pueden estar o no protegidos.

La parte fija aparece protegida y brillante y no se moverá al hacer scroll arriba y abajo.

Las transacciones en la tabla de transacciones (QGDTCCT) llevan asociado el panel QCRMGTS que es el
mapa común a todas las paginaciones.

5.2. Detalle de la COMMAREA

Los campos que intervienen en la commarea, además de los propios para la gestión de la conversación, son:

* CAA-TIPO-SALIDA: Se utiliza para indicar a la arquitectura que se trata de un listado (valor P).

* CAA-CONTENID: Título del listado, en la línea y de pantalla.

* CAA-SELEC-PERMIT: Se informan hasta 10 caracteres válidos para seleccionar.

* CAA-IND-VARSEL: Se indica si se permite selección múltiple.

3036 Systemcorp S.A

* CAA-MARGEN-FIJO: Nº de carecteres que permanecerán fijos a la izquierda al hacer scroll
lateral.
* CAA-FKEY: Grupo de 8 ocurrencias con información sobre teclas de función válidas
para el listado. Cada grupo tiene:
* CAA-FKEY-NUM: nº de tecla
* CAA-FKEY-LIT: literal que aparecerá en pantalla
* CAA-FKEY-SEL: Si se permite seleccionar con la tecla.

* CAA-IND-AVPAG: Indicador de que existen más filas para listar. En caso de ponerlo con valor
‘S’, la arquitectura devolverá el control al programa de listado cuando se
llegue al final y se haya pulsado la tecla de “scroll” hacia abajo. El
programa de aplicación rellenará el listado con más líneas.

* CAA-IND-MOD-DATO: Indica si la arquitectura debe modificar el contenido de la cola TS del

listado al modificar la pantalla. Solo tiene sentido si se desprotege la línea
de datos.
* CAA-LINEA-PANT: Línea del listado que se desea aparezca como primera línea la primera vez
que se visualiza el listado.

* CAA-COLUM-PANT: Igual que el anterior, con la columna.

* CAA-NUM-LIN-CAB: Número de líneas que se dejarán fijas en el listado al paginar arriba y

abajo. Su valor mínimo es 1.

* CAA-IND-SCROLL-LAT: Indica si se desea que se pueda realizar “scroll”, a pesar de que las lineas
del listado ocupen más de una pantalla de anchura.

* CAA-NUM-ITEM-SELEC: Número de item seleccionado en cola TS.

5.3. Esquema de la Paginación

Se arranca la transacción asociada al programa de paginación.

El programa aplicativo entra en estado inicio y borra la cola donde va a escribir las líneas de listado
(+GTSXXXX donde XXXX es la terminal).

A continuación accede a sus tablas y arma el listado como si se tratara de un listado en papel y escribiendolo
en la cola TS +GTSXXXX. La estructura del programa es similar al de un listado. Cada línea del TS
contendrá:

Opción Atributo de línea Contenido de línea

El atributo puede tomar diferentes valores que inciden sobre el campo opción y sobre la línea. Estos valores
son los siguientes:

Valor del campo Atributo de opción Atributo de línea

'' Desprot.+ Normal Protegido+ Normal
'B' Desprot.+ Normal Protegido+ Brillante

3136 Systemcorp S.A

 Valor del campo Atributo de opción Atributo de línea
'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 aplicativo devuelve el control a la arquitectura informando los campos de la commarea CAA:

 TIPO-SALIDA=‘P’ Indica que debe entrar al proceso de paginación.

 Cabecera descriptiva de los datos a paginar.
 Caracteres con los que se permite selección (X, S) hasta 10 diferentes.
 Si se permite multiselección o no.
 Margen fijo a mantener en desplazamientos laterales.
 Teclas de función permitidas al terminalista, excepto las estándar (avanzar: PF8, retroceder: PF7,
izquierda: PF4, derecha: PF5). Si el programa de paginación QC1CGTS no gestiona el scroll lateral (bien
porque la anchura de las líneas en la cola TS sea menor o igual que la anchura de la pantalla, o bien
porque se le haya indicado al programa de paginación que no se desea utilizar dicho scroll
expresamente), el programa QC1CGTS permitirá que las teclas PF4 y PF5 las pueda gestionar el
programa de aplicación de listado.
 Si el módulo de paginación debe dar control al aplicativo cuando no hay más datos a paginar hacia abajo
y se presiona PF8.
 Si se debe refrescar el contenido de las líneas de listado que se han escrito en la cola TS cada vez que el
módulo paginador tome control.
 Número de líneas de cabecera que permanecerán fijas en el scroll arriba y abajo.
 Si se desea que el programa de paginación gestione el scroll lateral.
 Número del primer item seleccionado - salida del programa de paginación al aplicativo.

El módulo de Arquitectura es en adelante el que realiza todo el trabajo y cumple las siguientes funciones:

 Desplazamiento en 4 direcciones:
 ‘n’ caracteres (según el campo SALTO/SCROLL del panel de listado)
 ‘P’ Página completa
 ‘H’ Media Página
 ‘M’ Máximo a izda , derecha, etc.
 Mantenimiento de un márgen fijo.
 Valida que las teclas de función pulsadas sean las correctas.
 Verifica que las teclas de función pulsadas son válidas y que no se haya informado más que uno cuando
no se permite multiselección.
 Ilumina y/o protege las líneas que correspondan si procede.

Una vez que el usuario presiona una tecla que no es de paginación el módulo cede el control al aplicativo en
estado continuación y éste, si espera selección, lee la cola TS y actúa en consecuencia.

5.4. Campos del panel de Listado

Los campos del panel de listado (QCRMGTS) comunes a cualquier listado son los siguientes:

3236 Systemcorp S.A

 Salto/Scroll: Indica que se desea cuando se pulsa una tecla de paginación. Es modificable.
 Selección: Indica el criterio de selección por el que se accedió al listado o un titulo. No es modificable
por pantalla. Muesta el campo CAA-CONTENID de la commarea informado por el aplicativo.
 Línea: Tiene la forma L ZZ9:ZZ9 Indica el número relativo de la primer línea del listado respecto del
total (ej: L 1:87)
 Columna: Tiene la forma C ZZ9:ZZ9 similar al anterior pero para columnas. Sólo aparece si hay
paginado a izquierda y derecha.
 Líneas de cabecera del listado: Es la cabecera del listado.
 Líneas de detalle del listado: Campo opción y el resto del contenido.

3336 Systemcorp S.A

6. Salida no Estándar

6.1. Funcionamiento

Se denomina salida de una transacción a toda respuesta que el terminalista recibe cuando una transacción
finaliza.

Existen dos tipos de salida: Estándar y No Estándar

 La salida estándar es el contenido de la pantalla estándar de entrada / salida (indicado en PTR-COPYIN

en la CAA) y por los mensajes de error/aviso. La salida estándar siempre va dirigida a pantalla.
 La salida no estándar es cualquier otro tipo de salida (hasta 5 distintas) y pueden estar dirigidas a
documento o pantalla.

Para gestionar una salida no estándar (por ejemplo la impresión de un documento) un aplicativo debe:

Escribir el contenido de dicha salida en una cola TS, comunicar a la Arquitectura a través de la commarea
CAA que existe una salida no estándar, dónde se encuentra el contenido del mensaje (la cola TS) y si la salida
es a pantalla o papel (grupo DESTINOS de la CAA).

Las salidas no estándar pueden a su vez tener o no un formato asociado y su tratamiento es diferente en cada
caso.

6.2. Detalle de la COMMAREA

Los campos que intervienen en la commarea, además de los propios para la gestión de la conversación, son:

*CAA-DESTINOS OCCURS 5 TIMES

CAA-DESTINO
CAA-IND-PANDOC
CAA-NUM-DOCUM
CAA-PRILIN-DOCUM
* CAA-DESTINO: Nombre de la cola TS donde se encuentra la salida.

* CAA-IND-PANDOC: Indicador de salida a pantalla (P), documento (D) o disco local (H).

* CAA-NUM-DOCUM: Nº de documento, si la salida es a impresora

* CAA-PRILIN-DOCUM: Línea donde comienza el documento.

* CAA-IMPRESO: Nombre de pre-impreso en local.

* CAA-IDIOMA: Idioma de la salida del documento.

3436 Systemcorp S.A

6.3. Salida no estándar sin formato asociado

Se recomienda a las aplicaciones no usar éste tipo de formato con el objeto de que al Middleware le sea más
fácil reconstruir el mensaje de salida.

En este caso la aplicación escribe la salida en una cola TS llamada :

+PFnXXXX siendo N 1,2,3,4,5 por cada salida y XXXX el código de terminal.

Al no tener el formato asociado se escribe la salida en la cola TS tal como se desea que aparezca en pantalla o
documento.

Para comunicar a la arquitectura la existencia de este tipo de salida se llenan los siguientes campos de la
commarea:

DESTINO(1) = ‘+PF1’ (Debe ser ‘+PFn´)

IND-PANDOC(1) = ‘D’ (Puede ser P pantalla o D documento)
NUM-DOCUM(1 = ‘1’ (Número de documento, si procede)
PRILIN-DOCUM(1) = ‘05’ (Número de línea donde se comenzará a
escribir si la salida es a papel).

6.4. Salida no estándar con formato asociado

En este caso, la aplicación escribirá la salida en una cola TS llamada:

+DCnXXXX: Siendo n: 1,2,3,4,5 (hasta 5 salidas) y XXXX el código del terminal.

En la cola TS se escribirá, en las 8 primeras posiciones el nombre del formato asociado al mensaje de salida.
Debe existir en la tabla de formatos y a continuación el contenido de los campos variables del mensaje en
formato BMS.

El contenido de la cola TS será entonces:

AARMXXXX 12x L A CCC...CCC L A CCC...CCC L A CCC...CCC

Conternido del campo 1

Atributo del campo 1
Longitud del campo 1
Nombre del formato

La cola +DCnXXXX puede tener más de una línea, ya que una única salida puede tener varios formatos
asociados que definen partes de un mismo mensaje.

Para comunicar a la arquitectura la existencia de este tipo de salida se llenan los siguientes campos de la
commarea:

3536 Systemcorp S.A

DESTINO(1) = ‘+DC1’ (Debe ser ‘+DCn´)
IND-PANDOC(1) = ‘D’ (Puede ser P pantalla o D documento)
NUM-DOCUM(1 = ‘1’ (Número de documento, si procede)
PRILIN-DOCUM(1) = ‘05’ (Número de línea donde se comenzará a
escribir si la salida es a papel).
IDIOMA(1) = ‘E’ (Código de idioma del preformato)

3636 Systemcorp S.A