firma electrónica de ficheros mvs z/os (enlace con...

EDItran/FF-EDItran/CD 5.1 Firma Electrónica de Ficheros MVS

z/OS (enlace con máquinas externas)

Firma electróncia por NFS

Indra. Septiembre de 2011 EF51USUA.doc.

Indra . La información aquí contenida puede ser objeto de cambios sin previo aviso. Las distintas versiones del producto pueden dar lugar a cambios, adiciones o supresiones de información en este manual. La correspondencia acerca de este manual debe realizarse en la hoja de comentarios aquí incluida y debe ser dirigida a Indra, Producto EDItran, Avda. de Bruselas 35 (Edificio VIO-1), 28108 - Arroyo de la Vega - Alcobendas, Madrid.

Comentarios de usuario sobre esta documentación. Exprese, y háganos llegar, su opinión y comentarios acerca de la documentación entregada y así podremos corregirla en las posteriores versiones de este documento.

Indra. Producto : EDItran/FF-EDItran/CD 5.1 z/OS (enlace con máquinas externas)

Firma electróncia por NFS

Referencia: EF51USUA.doc

Avda. de Bruselas 35 - Arroyo de la Vega - Alcobendas.

28108 MADRID.

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

_______________________________________________________________________________________________________

Empresa : ____________________________________________________________________________________

Departamento: ____________________________________________________________________________________

Contacto : ____________________________________________________________________________________

Dirección : ____________________________________________________________________________________

EDItran/FF-EDItran/CD 5.1. z/OS (enlace con máquinas externas). Firma electróncia por NFS. Indice

Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. i.1

1. INTRODUCCION. .................................................................................................... 1-1

2. FUNCIONALIDAD DE EDITRAN/FF-CD. ................... ............................................. 2-1

3. REQUISITOS PARA LA UTILIZACION DE EDITRAN/FF-CD. .. ............................. 3-1

3.1. NFS SERVER (HOST). ............................................................................................................................. 3-3

3.2. NFS CLIENTE. .......................................................................................................................................... 3-3

4. MODO DE FUNCIONAMIENTO. ............................................................................. 4-1

4.1. Cambios dependiendo de la versión EDItran. ......................................................................................... 4-2

5. FUNCIONES INVOCADAS DESDE JCL DE APLICACIÓN. ...... ............................. 5-1

5.1. Definición del tipo de funcionamiento. ..................................................................................................... 5-1

5.2. Verificación de habilitaciones y carga de emisión (Modo automático). ................................................ 5-2 5.2.1. Firma manual de la sesión de presentación. ............................................................................................ 5-3

5.2.2. Firma automática de la sesión de presentación. ...................................................................................... 5-3

5.2.3. Firma automática de n ficheros de una presentación. .............................................................................. 5-4

5.3. Verificación de habilitaciones y carga de emisión (Modo no automático). ........................................... 5-6

5.4. Proceso de adaptación del fichero de aplicación de recepción. ............................................................ 5-11

6. EJEMPLO DE PROCEDIMIENTO DE FIRMA. ................ ....................................... 6-1

6.1. Emisión (modo automático utilizando ZTBGFITS). ............................................................................... 6-1

6.2. Emisión (modo no automático utilizando ENTRADA). .......................................................................... 6-1

6.3. Recepción.................................................................................................................................................... 6-3

7. PARAMETRIZACIONES EDITRAN/G. ...................... .............................................. 7-1

7.1. ZOS como emisor y receptor. ................................................................................................................... 7-1

7.1.1. ZOS como emisor y otro entorno como receptor. ................................................................................... 7-2

7.2. ZOS como receptor y otro entorno como emisor. ................................................................................... 7-3

EDItran/FF-EDItran/CD 5.1. z/OS (enlace con máquinas externas). Firma electróncia por NFS.

Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 1-1

1. INTRODUCCION.

Existen varias formas de funcionamiento en EDItran/FF y EDItran/CD.

• EDItran/FF es una aplicación integramente z/os. EDItran/CD se realiza en z/os, parte USS (UNIX SYSTEM SERVICES). Para ver esta opción, vea manuales ECD51USUA Y ED51USUC.

• Los certificados y la interfaz gráfica residen en máquinas WINDOWS-UNIX. Es necesario NFS (network file system). EDItran/CD y la interfaz gráfica EDItran/FF residen en dichas máquinas. Dentro de esta opción, podemos encontrar 2 subopciones de funcionamiento.

o Modo automático. Desde cualquier procedimiento MVS, se enlaza vía IP con EDItran/CD de la máquina correspondiente, el cual certifica en ese momento, on-line lo que hay que enviar. Llamaremos a este modo Certificados externos en modo automático.

o Modo no automático. Es el propio EDItran/CD el que ya colocado los ficheros necesarios por NFS, no se establece una conexión ip en cargas-descargas. Llamaremos a este modo Certificados externos en modo no automático.

En este documento se describen los distintos modos de operación y requisitos para la firma de ficheros MVS mediante certificados digitales EXTERNOS (EDItran/CD + EDItran/FF en entornos WINDOWS-UNIX) .

En este manual se han tratado los siguientes aspectos:

� Breve descripción de la funcionalidad de EDItran/FF - CD

� Requisitos para la utilización de EDItran/FF - CD

� Modo de funcionamiento

� Descripción de jcl de adaptación de ficheros de aplicación emitidos o recibidos

� Evolución del procedimiento completo de firma, transmisión y verificación de firma de un fichero del MVS.

� Parametrización en EDItran/G del MVS.

EDItran/FF-EDItran/CD 5.1. z/OS (enlace con máquinas externas). Firma electróncia por NFS


2. FUNCIONALIDAD DE EDItran/FF-CD.

EDItran/FF – EDItran/CD son componentes de la plataforma EDItran que permite la firma de ficheros mediante certificados digitales (personales o de servidor) emitidos por autoridades de certificación (CA).

Cada uno de los ficheros de datos (de aplicación). puede firmarse por uno o más firmantes (cada uno con su certificado) generándose un fichero de firma (PKCS#7) por cada uno de ellos (en modo attach, se genera un único fichero que contiene aplic+firmas)

Una vez generadas las firmas, EDItran/FF da la posibilidad al responsable de la aplicación, de habilitar el envío del fichero y sus firmas asociadas. EDItran/G, puede verificar que se ha concedido el permiso para enviar dicha presentación antes de realizar la carga.

Una vez recibido/s el/los fichero/s de aplicación, con sus respectivos ficheros de firma asociados, el EDItran/FF del extremo receptor permite verificar cada una de las firmas asociadas al/los fichero/s.



3. REQUISITOS PARA LA UTILIZACION DE EDItran/FF-CD.

• En caso de Certificados externos, EDItran/FF-CD es un software disponible en entornos UNIX y WINDOWS. Para que el entorno MVS pueda acceder a dichos servicios es necesario:

o Disponer del propio EDItran/FF-CD en entorno WINDOWS (o UNIX)

o Adecuar el servidor NFS de ficheros MVS de los servicios UNIX del ZOS para que den servicio a un cliente NFS

o Disponer de un cliente NFS en la plataforma Windows (o UNIX).

o Los ficheros no deben sufrir transformaciones de formato, alfabeto, etc, en el proceso de carga, transmisión y descarga.



WINDOWS

CLIENTE NFS

EDItran/FF

MVS

Servidor NFS EDItran/G EDItran/P

F. Firma

F. Datos



3.1. NFS SERVER (HOST).

Es necesario configurar el host como NFS server en el ZOS (soporte NFS para ficheros MVS) para poder funcionar con EDItran/FF. Se definirá por razones de seguridad, un puntero,(por ejemplo, PUNTERO.LOCAL.NFS) desde el cual se habilitará el acceso a NFS cliente. Se debe autorizar a usuarios, a través de RACF a la utilización de dicho servicio. La transferencia de datos se realizará en formato binario.

3.2. NFS CLIENTE.

Debe instalarse una herramienta NFS cliente (las definiciones que siguen corresponden al Camaleón). Se recomienda no codificar en la misma el usuario RACF, puesto que si se hace doble clic en la conexión, se reenvía N veces el usuario codificado con pasword a blancos de forma que el RACF acaba denegando el acceso a dicho usuario e inhabilitándolo para futuras entradas. En el momento de conectarse con dicha herramienta se recomienda máxima atención con la pasword por los intentos incontrolados de conexión que hace el NFS cliente. Los parámetros NFS cliente con los que se han realizado las pruebas han sido:

� Username: <System logon name> (ninguno)

� Authenticator: (ninguno)

� Read size (8192, 512, etc).

� Write size (8192, 512, etc). Se observa que los ficheros creados en el host, son de record format VB, organization PS, con una longitud de registro de 8196 y un block size de 27998. Según lo que se indique en write size, así creará el NFS los registros del fichero variable (de firma), de forma que se recomienda codificar 8192, para mejor aprovechamiento del espacio.

� Opción CD Jukebox / WAN Server: ACTIVA.

� Permisos de creación de directorios: Todos los permisos (lectura, escritura y ejecución) para el usuario, para el grupo y para el resto (todos los permisos a 777).

� Permisos de creación de ficheros: Todos los permisos (lectura, escritura y ejecución) para el usuario, para el grupo y para el resto (todos los permisos a 777).

� Ficheros y pathnames con Character Set: Default.

� Ficheros y pathnames con Case on Create: Uppercase (Mayúsculas).

� Opción Enable Symlinks: ACTIVA.



4. MODO DE FUNCIONAMIENTO.

Utilizando el NFS, EDItran/FF genera el fichero de firma en un fichero MVS a partir del fichero de datos firmados que también reside en MVS. Al mismo tiempo genera un fichero de habilitación de la aplicación.

El EDItran CICS/IMS podrá transmitir tanto el fichero de datos, el de habilitación, el de firma o todos ellos, al extremo remoto que podrá ser otro entorno MVS o una plataforma UNIX o Windows.

De igual forma, El EDItran/FF de un extremo receptor puede comprobar las firmas recibidas en el sistema de ficheros del MVS. Para poder validar la firma de los ficheros, éstos no pueden ser transformados (por EDItran) en el transcurso de la transmisión, y por tanto las transformaciones de alfabeto y formato, si son necesarias, han de realizarse en un proceso posterior a la verificación de la firma.

Las particularidades de su funcionamiento con EDItran/G son las siguientes:

� Los ficheros de firma tendrán el puntero *.P7B

� EDItran/G puede validar si desde EDItran/FF se ha habilitado el envío de ficheros y firmas asociadas, pudiendo interrumpir el proceso en caso de no existir dicho permiso.

� La transmisión de ficheros firmados electrónicamente, hace que sea conveniente que no se modifiquen las características del fichero origen (formato de fichero, traducción, conversión, etc), puesto que de otra forma el extremo receptor tendría errores de firma (en su EDItran/FF), al verificar la firma comparando cada fichero de aplicación recibido con cada fichero PKCS#7. Además, los entornos UNIX y WINDOWS, que generan saltos de carro en el fichero que les llega, no lo podrían hacer por la misma razón. La solución a éste proceso pasa por emitir ficheros binarios, siempre que el entorno sea no homogéneo (formato de fichero M (Modificado)), y en recepción, una vez pasado el proceso de verificación de EDItran/FF, se adaptará el fichero de aplicación al lenguaje y formatos conocidos, incluso eliminando posibles saltos de carro (todo ello asincronamente).

� La descarga debe hacerse indicando que los ficheros binarios recibidos se descarguen como fichero variable y no especificando un fichero único para la descarga (al menos, van a llegar dos ficheros). Es posible que en el remoto dichos datos estén en ASCII (a pesar de que el mismo, haya indicado formato binario) y además es posible que dichos datos pertenezcan a un fichero de texto de tipo fijo (los entornos UNIX-WINDOWS incluyen saltos de carro al final de cada línea). Cuando un fichero no se transmite como binario, dicho entorno, adapta el formato a fijo y hace traducción. Al no poder tocar los datos ni en emisión, ni en recepción, puesto que de otra forma la firma quedaría invalidada, se ha optado por la solución de que se adapte, una vez validadas las firmas, el fichero recibido a la situación en la que se recibía normalmente.

� Posteriormente a la descarga y a la verificación de la firma, si fuese necesario, se lanzará un jcl, al que se le pasan una serie de parámetros, para adaptar lenguaje, tablas de conversión, formato de fichero y saltos de carro.



4.1. Cambios dependiendo de la versión EDItran.

Los cambios más significativos son:

1. Hasta la versión 4.1 fase 0, los ficheros de firmas se llamaban P7. A partir de esta versión se llaman P7B. Para cambiar busque en los distintos ficheros ENTRADA el string ‘.p7 ‘ y sustituya por ‘.p7b ‘.

2. Hasta la versión 4.1 fase 0, el modo de funcionamiento era NO AUTOMATICO. Se utilizaba el fichero ENTRADA (procedimiento ZTBGP1CF, que contiene un paso previo y el paso de A1P). A partir de esta versión, se puede utilizar el modo AUTOMATICO, que utiliza el procedimiento normal de EDItran (ZTBGP1C, el paso A1P), añadiendo el fichero ZTBGFITS (contiene datos de la conexión al servidor CD). En el caso de funcionar con ZTBGFITS (MODO AUTOMATICO), el programa establece una conexión con un programa servidor, el cual indica si la sesión está habilitada y tiene el número de firmas suficiente. En el caso de ENTRADA (MODO NO AUTOMATICO), es EDItran el que hace dicha validación alocando los ficheros correspondientes.

Deberá cambiar el procedimiento previo a emisión, poniendo el adecuado.



5. FUNCIONES INVOCADAS DESDE JCL DE APLICACIÓN.

5.1. Definición del tipo de funcionamiento.

En EDItran/G, sesión de presentación aparecen los siguientes parámetros:

| CARGA EDItran/FF (N,A,T) ......: X VERIF.EDItr an/FF (N,H,F)...: X |

Su significado es el siguiente:

1. Carga EDItran/FF es la forma de funcionamiento de EDItran/FF. Sus valores posibles son:

1.1. ‘N’- Indica que se actúa en modo “no automático” ó sin EDItran/FF

1.2. ‘A’- Indica que se actúa con EDItran/FF en modo “automático” y que se cargarán en el fichero tampón sólo los ficheros de aplicación (no se cargarán los de firmas ni habilitación).

1.3. ‘T’- Indica que se actúa con EDItran/FF en modo “automático” y que se cargarán en el fichero tampón todos los ficheros (aplicación, habilitación y firmas).

2. Verificación EDItran/FF es la forma de “verificar” que se puede proceder a cargar” en EDItran/FF. Sus valores posibles son:

2.1. ‘N’- Indica que se actúa en modo “no automático” ó sin EDItran/FF

2.2. ‘H’- Indica que se actúa con EDItran/FF en modo “automático” y que para poder cargar, el servidor EDItran/FF windows nos debe comunicar que la sesión ha sido habilitada, ya sea normalmente o en modo forzado.

2.3. ‘F’- Indica que se actúa con EDItran/FF en modo “automático” y que para poder cargar, el servidor EDItran/FF windows nos debe indicar que esté ó no habilitada la sesión, se cumplen los requisitos de disponer de las firmas necesarias para la carga.



5.2. Verificación de habilitaciones y carga de emis ión (Modo automático).

Utilizar el procedimiento ZTBGP1C. Este modo de funcionamiento “automático” es el más recomendado. Si se opta por esta opción, se realiza una conexión ip contra un programa que atiende sobre puerto server y que nos confirmará si para la aplicación EDItran/FF descrita, tenemos habilitado el envío y en su caso que ficheros hay que cargar.

ZTBGFITS es un fichero creado por el usuario cuyo formato es fijo, de longitud 80 y con los siguientes registros: Nivel Nombre Long. Tipo Descripción

1 Registro-fich-ZTBGFITS

80

2 Identificador de registro de control

2 Alfn. C1

2 Guión 1 Alfn. Guión de separación 2 Dirección-ip donde

está el prog. EDI/FF 56 Alfn. Dirección ip del server donde está el prog.

2 Guión 1 Alfn. Guión de separación 2 Puerto donde está el

programa EDItran/FF 5 Num 1-65535

2 Guión 1 Alfn. Guión de separación 2 Segundos activ server 3 Num 1-300 Segundos de activación máxima 2 Guión 1 Alfn. Guión de separación 2 TCPNAME 8 Alfn. TCPIPJOBNAME 2 Filler 3 Alfn. SPACES

Nivel Nombre Long. Tipo Descripción


80

2 Identificador de registro de control

2 Alfn. C2

2 Guión 1 Alfn. Guión de separación 2 Puntero NFS 44 Alfn. Puntero NFS 2 Filler 33 Alfn. RESERVA

El siguiente / siguientes tipos de registro solo es válido para firma automática. Nivel Nombre Long. Tipo Descripción


80 1-n registros

2 Identificador de Firma Automática

2 Alfn. C3

2 Guión 1 Alfn. Guión de separación 2 Origen Presentacion 9 Alfn. Origen de la presentación. Si su valor es zeros,

indica que es válido para todos los origenes. 2 Guión 1 Alfn. Guión de separación 2 Remoto Presentacion 9 Alfn. Remoto de la presentación. Si su valor es zeros,

indica que es válido para todos los remotos. 2 Guión 1 Alfn. Guión de separación 2 Aplicación

Presentacion 6 Alfn. Aplicación de la presentación. Si su valor es zeros,

indica que es válido para todos las aplicaciones. 2 Guión 1 Alfn. Guión de separación



2 Nombre de usuario. 25 Alfn. Nombre de usuario permitido para firma automática. Su DN debe estar en el servidor para firma automática.

2 Guión 1 Alfn. Guión de separación 2 Habilitación en la firma

automática 1 Alfn. S/N, indica si además de firmar automáticamente

se quiere permitir el habilitar o no. 2 Guión 1 Alfn. Guión de separación 2 Filler 9 Alfn. Area de reserva

Ejemplo: C1-172.127.1.20 -8300-030-TCPIPB C2-KI.EITC.NFS

En el caso anterior, si queremos cargar para la sesión de presentación 000099940000099980PRUEBA, se hace un connect contra la dirección 172.127.1.20 puerto 8300, con un máximo de 30 segundos, siendo el puntero nfs el KI.EITC.NFS. El programa server verifica si la sesión está habilitada y devuelve los ficheros a cargar (en este caso todos: habilitación, aplicación y firmas), en el tampón. Se ha validado que exista fisicamente que exista el de habilitación y los de firmas correspondientes.

Existen 3 formas de firmar los ficheros:

5.2.1. Firma manual de la sesión de presentación.

Con esta opción, cada vez que se genera un fichero de aplicación, los usuarios firmantes, lo ven y firman su fichero. Este proceso, está plenamente integrado con lo anteriormente expuesto. En el previo a emisión, se llama al servidor FF, el cual es consciente de los ficheros firmados, habilitación, etc.

5.2.2. Firma automática de la sesión de presentación.

Con esta opción, los usuarios no firman manualmente los ficheros de la presentación. En un paso previo a la carga, se llama al servidor FF, y se le proporciona el usuario firmante (cuyo certificado reside en el servidor). El servidor EDItran/FF, conoce los ficheros de la aplicación para la que se le llama, de forma que firma todos los ficheros de la misma (incluso puede habilitar la presentación). Al utilizar esta opción, se incluye un paso previo a la carga (ya sea un paso previo en el procedimiento ó un jcl por fuera).

Se utiliza el jcl ZTBGJFF0 (funcion 01), que tira del programa ZTBGBFF0, pasando vía parm la sesión de presentación para la que se quiere firma automática, por ejemplo. //FIRMAU ZTBGBFF0 EXEC PGM=ZTBGBFF0,PARM='01-000999 4000099990EDIFF1' //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS) ,DISP=SHR

No obstante, este proceso, se puede encadenar en un paso previo al paso de carga en el procedimiento previo a emisión: //FIRMAUT EXEC PGM=ZTBGBFF0, // PARM='01-&L1&L2&R1&R2&AP&LF/CBLQDA(ON)', // REGION=0M,TIME=25 //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS) ,DISP=SHR



Según el ejemplo anterior, con la sesión 0009994000099990EDIFF1, imaginemos que el fichero KI.EGTC.ZTBP.FICHEROS(ZTBGFITS), contiene lo siguiente: ********************************* Top of Data ***** ***************************** C1-172.22.71.88 -08300-060-TCPIPB C2-KI.EITC.NFS C3-000099940-000000000-APLI01-frodriguez -S- C3-000000000-000099990-APLI02-fgutierrez -N- C3-000099940-000099990-APLI03-fgarcia -S- C3-000099940-000099990-APLI04-fgarcia -N- C3-000000000-000000000-EDIFF1-fjaraba -S- ******************************** Bottom of Data *** *****************************

El paso FIRMAU, detecta que la última ficha C3 es la que contiene datos de la sesión, (el resto de ellas no son válidas para la sesión referenciada), de forma que llama al servidor FF, indicando que se use el user “fjaraba” para firmar, e indicando que se habilite el envío.

Si se usa la función 01, no es necesario el fichero ZTBGFCAR. El servidor EDItran/FF conoce los ficheros de la presentación y los firma automáticamente con el usuario descrito. Además se puede indicar si se quiere o no habilitar el envío.

5.2.3. Firma automática de n ficheros de una presentación.

Esta opción es parecida a la anterior (firma automática de la sesión de presentación). La diferencia es que el servidor FF no conoce que ficheros están asociados a una presentación (normalmente porque la aplicación genera ficheros con nombres distintos, por ejemplo con la fecha de sistema). Con esta opción, los usuarios no firman manualmente los ficheros de la presentación. En un paso previo a la carga, se llama al servidor FF, y se le proporciona el usuario firmante (cuyo certificado reside en el servidor), y el fichero a firmar. El servidor EDItran/FF, firma dicho fichero y lo asocia a su aplicación. Al utilizar esta opción, se incluye un paso previo a la carga (ya sea un paso previo en el procedimiento ó un jcl por fuera).

Se utiliza el jcl ZTBGJFF0 (funcion 02, 03 ó 04).

• Función 02- Firmar automáticmante el / los ficheros indicados en ZTBGFCAR, sin habilitar

• Función 03- Firmar automáticmante el / los ficheros indicados en ZTBGFCAR, pidiendo en el último que se habilite el envío.

• Función 04- Habilitar el envío.

Este jcl tira del programa ZTBGBFF0, pasando vía parm la sesión de presentación para la que se quiere firma automática y los ficheros a firmar, por ejemplo. //FIRMAU EXEC PGM=ZTBGBFF0,PARM='03-00099940000999 90EDIFF1' //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS) ,DISP=SHR //ZTBGFCAR DD DSN=KI.EGDC.ZTBP.FICHEROS(LISTFICH) ,DISP=SHR

No obstante, este proceso, se puede encadenar en un paso previo al paso de carga en el procedimiento previo a emisión:



//FIRMAUT EXEC PGM=ZTBGBFF0, // PARM='03-&L1&L2&R1&R2&AP&LF/CBLQDA(ON)', // REGION=0M,TIME=25 //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS) ,DISP=SHR //ZTBGFCAR DD DSN=KI.EGDC.ZTBP.FICHEROS(LISTFICH) ,DISP=SHR

Según el ejemplo anterior, con la sesión 0009994000099990EDIFF1, imaginemos que el fichero KI.EGTC.ZTBP.FICHEROS(ZTBGFITS), contiene lo siguiente: ********************************* Top of Data ***** ***************************** C1-172.22.71.88 -08300-060-TCPIPB C2-KI.EITC.NFS C3-000099940-000000000-APLI01-frodriguez -S- C3-000000000-000099990-APLI02-fgutierrez -N- C3-000099940-000099990-APLI03-fgarcia -S- C3-000099940-000099990-APLI04-fgarcia -N- C3-000000000-000000000-EDIFF1-fjaraba -S- ******************************** Bottom of Data *** *****************************

El paso FIRMAU, detecta que la última ficha C3 es la que contiene datos de la sesión, (el resto de ellas no son válidas para la sesión referenciada), de forma que llama al servidor FF, indicando que se use el user “fjaraba” para firmar el-los ficheros contenidos en la lista ZTBGFCAR (puede ver el formato ZTBGFCAR en .

Suponiendo una aplicación, que genere ficheros de aplicación con nombres distintos cada día, y además quiera firmar automáticamente, puede hacer de 3 formas:

• Cada vez que la aplicación genera un fichero, grabar el nombre del mismo en ZTBGFCAR, y arrancar el jcl descrito (función 02). El último jcl generarlo con función 03. Cuando están todos, arrancar el previo a emisión standard.

• Cada vez que la aplicación genera un fichero, añade el nombre del mismo a ZTBGFCAR. Cuando se graba el último, se lanza un previo a emisión, cuyo primer paso es el descrito (función 03).

• Cada vez que la aplicación genera un fichero, grabar el nombre del mismo en ZTBGFCAR, y arrancar el jcl descrito (función 02). En el previo a emisión, poner un paso previo con función 04 (habilitar).

En ambos casos, cuando se arranque el paso de carga del previo a emisión, se utilizará editran ff en modo automático (se llamará de nuevo al servidor, el cual nos dirá los ficheros que debemos cargar).



5.3. Verificación de habilitaciones y carga de emis ión (Modo no automático).

Utilizar el procedimiento ZTBGP1CF. Requiere más pasos que el caso automático.

El modo de funcionamiento en modo “no automático es el siguiente”:

TAMPON

ZTBGFCAR (new,catlg) (jcl)

ZTBGFFIR (new,pass) (jcl)

PASO 1 ZTBGBFF1 CALL ZTBGBF11

PROC ZTBGP1CF, LF=S

PASO 2 ZTBGB110 LF=S

PASO 3 ZTBGBFF2 (DELETE’s)

PASO 4 IEBFR14 (DELETE)

ENTRADA

Habilitación Firma 1 Firma n



Se ha implementado la posibilidad de que una vez que se hayan generado los ficheros de firma, sólo se puedan cargar y emitir, si se ha habilitado la sesión para ello. Así, se ha desarrollado un jcl, que en un primer paso, valida si existe tal habilitación y crea un fichero con la lista de ficheros a cargar-emitir. En un segundo paso, lanza el previo a emisión. Dichos procesos se desarrollan en el jcl ZTBGJFF1, el cual consta de lo siguiente:

1. PASO1, PARM. Se le pasan 3 parámetros distintos; origen, función y sesión de presentación. El origen, en caso de lanzarlo desde jcl, es A(aplicación). La función admite los valores: 00(sólo validar habilitación), 01(validar habilitación y cargar), 03(validar habilitación, cargar y pedir la emisión). Con función 00, el jcl acaba en su paso1 con return code 04, de forma que impide ejecutar el paso2. La sesión de presentación consta de origen-destino y aplicación.


1 Origen 01 Alfn. A- (Aplicación). En caso de lanzarlo desde jcl. O- (Operador). En caso de lanzamiento de procedimiento desde EDItran/G. E- (Editran). En caso de lanzamiento de procedimiento desde EDItran/P.

1 Función 02 Num. 00- Validar habilitación (función sólo disponible si se ejecuta desde jcl)

01- Validar habilitación y cargar. 03- Validar habilitación, cargar y pedir la emisión.

1 Sesión de presentación

24 Alfn. Sesión de presentación

2 Origen 9 Alfn. Nif origen de la sesión de presentación. En caso de lanzarse procedimiento, este campo se forma con las variables &L1&L2.

2 Destino 9 Alfn. Nif destino de la sesión de presentación. En caso de lanzarse desde procedimiento, este campo se forma con las variables &R1&R2.

2 Aplicación 6 Alfn. Aplicación de la sesión de presentación. En caso de lanzarse desde procedimiento, este campo se forma con la variable &AP.

2 Modo verificación (Recoger ficheros)

1 Alfn. Indica si queremos conexión tcp/ip a un server para que nos devuelva el resultado de la habilitación y el nombre de ficheros a cargar o que saque los ficheros de una lista (ENTRADA). 1-Tira del fichero ENTRADA 2- Llama a programa server, en función de datos recogidos en fichero ZTBGFITS

ZTBGFCAR del PASO1 es el nombre del fichero de salida, que contiene los ficheros a cargar y el formato de los mismos, para que el paso 2 los cargue.

ZTBGFFIR del PASO1, es un fichero que se borra al acabar el jcl, en el que se grabará la lista de ficheros que se quieren borrar en el paso3.

ZTBGFLIS del PASO1, es un informe de lo que ha ocurrido con los ficheros tratados en el PASO1.



INFORME CARGA FICHEROS EDITRAN/FF --------------------------------- SESION PRESENTACION : 200 099940100099940GENERI TIPO HABILITACION : FIC HEROS DE FIRMAS NRO FICH. FIRMAS A VERIFICAR : 02 TIPO DE GRABACION EN TAMPON : FIC H.DATOS,FICH.FIRMA Y APLIC. FICHEROS TRATADOS --------------------------------- KI.EIDC.ZTBG.APLIC KI.EGDC.ZTBP.JCLS(ZTBPJITR) KI.EIDC.ZTBG.FIRM A1 KI.EIDC.ZTBG.FIRM A2 KI.EIDC.ZTBG.JCLS(ZTBGJILO) KI.EIDC.ZTBG.FIRM A21 KI.EIDC.ZTBG.FIRM A22 KI.EIDC.ZTBG.FIRM A23 VERIFICACION PARA LA CARGA FINALIZA CORRECTAMENTE

FICHEROS CARGADOS --------------------------------- KI.EGDC.ZTBP.JCLS(ZTBPJITR) KI.EIDC.ZTBG.FIRMA1 KI.EIDC.ZTBG.FIRMA2 KI.EIDC.ZTBG.JCLS(ZTBGJILO) KI.EIDC.ZTBG.FIRMA11 KI.EIDC.ZTBG.FIRMA12 KI.EIDC.ZTBG.FIRMA13

ENTRADA del paso 1 es un fichero creado por el usuario cuyo formato es fijo, de longitud 80 y con los siguientes registros:

1nombre-fichero-habilitación abbc

2nombre-fichero1-emisión

3nombre-fichero1-firma-emisión

El último puntero del primer fichero (habilitación), debe de coincidir con la aplicación de EDItran/FF asociada a los ficheros a firmar.


1 Registro-fich-entrada 80 2 Tipo de fichero 1 Alfn. Tipo de fichero de entrada:

1-Fichero de habilitación. 2-Fichero de aplicación para emitir. 3-Fichero de firmas PCKS#7

2 Dsname de fichero 44 Alfn. Dsname del fichero de entrada 2 Resto de datos 35 Alfn. Espacios en caso de ficheros de tipo registro 2-3 3 Tipo-habilitación (sólo

en tipo registro 1) 1 Num. 0-Verificar que existe fisicamente fichero

habilitación (dsname del tipo registro 1). 1-Verificar que exiten fisicamente los nn ficheros de firmas (tipo de registro 3), por cada tipo de fichero de datos (tipo de registro 2), indicado en su campo correspondiente (número de ficheros de firma a verificar). 2-Ambos



3 Número de ficheros de firma a verificar (sólo en tipo registro 1)

2 Num. 00-99 Especifica el número de ficheros de firmas (tipo de registro de 3), por cada tipo de fichero de datos (tipo de registro 2), que se desea verificar que realmente existen.

3 Tipo de grabación en fichero tampón (sólo en tipo registro 1)

1 Num. 0- No se graba nada. 1- Se graban sólo los ficheros de datos (tipo de

registro 2). 2- Se graban todos los ficheros de datos (tipo de

registro 2) y todos los ficheros de firma que existan (tipo de registro 3).

3- Se graban todos los ficheros de datos (tipo de registro 2) y del resto, todos los que existan (tipo de registro 1 y 3, de forma que se incluye el de habilitación).

4- Se graban todos los ficheros de datos (tipo de registro 2) y el de habilitación, si existe (tipo de registro 0).

3 Número de ficheros de aplicación a verificar que existen y a enviar (sólo en tipo registro 1)

2 Num. 00- Deben de existir todos los ficheros de aplicación.

01-99- Deben existir, AL MENOS, nn ficheros de aplicación y se enviarán, de ellos, los que existan (puede que nn sea 01 y existan 2, de forma que se cargarían 2 y se enviarían 2(tipo de registro 2), siempre y cuando todos ellos cumplieran el resto de parametrizaciones (número de registros de tipo 3 a validar, etc).

3 Filler 30 Alfn. Area de reserva a espacios.

Así, por ejemplo, si tenemos creado un fichero ENTRADA con las siguientes características: 1KI.FICHERO.HABILITACION 203200 2KI.FICHERO1.APLICACION 3KI.FICHERO1.APLICACION.FIRMA1.PKCS7 3KI.FICHERO1.APLICACION.FIRMA2.PKCS7 3KI.FICHERO1.APLICACION.FIRMA3.PKCS7 3KI.FICHERO1.APLICACION.FIRMA4.PKCS7 3KI.FICHERO1.APLICACION.FIRMA5.PKCS7 2KI.FICHERO2.APLICACION 3KI.FICHERO2.APLICACION.FIRMA1.PKCS7 3KI.FICHERO2.APLICACION.FIRMA2.PKCS7 3KI.FICHERO2.APLICACION.FIRMA3.PKCS7 3KI.FICHERO2.APLICACION.FIRMA4.PKCS7 3KI.FICHERO1.APLICACION.FIRMA5.PKCS7

En el host, sólo existen fisicamente los siguientes ficheros: KI.FICHERO.HABILITACION KI.FICHERO1.APLICACION KI.FICHERO2.APLICACION KI.FICHERO1.APLICACION.FIRMA1.PKCS7 KI.FICHERO1.APLICACION.FIRMA2.PKCS7 KI.FICHERO1.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA2.PKCS7 KI.FICHERO2.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA4.PKCS7 KI.FICHERO2.APLICACION.FIRMA5.PKCS7

El programa de carga-validación, en el primer grupo de registros de tipo 1,2 y 3, verificará que el primer registro de ENTRADA, el que contiene el dsname del fichero de habilitación (comienza por 1):



Tiene un 2 en la posición 46, lo que indica que verifique que existen fisicamente el fichero cuyo tipo comienza por 1 y que verifique que existen fisicamente, al menos, 03 ficheros de tipo 3, por cada fichero de tipo 2. Es correcto, puesto que existen:

KI.FICHERO.HABILITACION Para fichero de tipo 2, KI.FICHERO1.APLICACION, exi sten: KI.FICHERO1.APLICACION.FIRMA1.PKCS7 KI.FICHERO1.APLICACION.FIRMA2.PKCS7 KI.FICHERO1.APLICACION.FIRMA3.PKCS7 Para fichero de tipo 2, KI.FICHERO2.APLICACION, exi sten: KI.FICHERO2.APLICACION.FIRMA2.PKCS7 KI.FICHERO2.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA4.PKCS7

Tiene un 03 en las posiciones 47-48, de forma que ya se explicó su significado con el campo anterior (verificar que existen fisicamente, al menos, 03 ficheros de firmas, de tipo 3, por cada fichero de tipo 2).

Tiene un 2 en la posición 49 , lo que le indica, que cargue todos los de aplicación, de tipo 2, y todos los de firma que existan, de tipo 3 (al menos, existían 03 por cada uno de los de tipo 2, por la validación anterior).

Tiene un 00 en las posición 50-51 , lo que le indica, que deben existir fisicamente todos los ficheros de aplicación especificados y además debe de cargarlos todos (registros de tipo 2).

Con ello, se cargarán los siguientes ficheros: KI.FICHERO1.APLICACION KI.FICHERO1.APLICACION.FIRMA1.PKCS7 KI.FICHERO1.APLICACION.FIRMA2.PKCS7 KI.FICHERO1.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION KI.FICHERO2.APLICACION.FIRMA2.PKCS7 KI.FICHERO2.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA4.PKCS7 KI.FICHERO2.APLICACION.FIRMA5.PKCS7

Si alguno de criterios de verificación o carga no se cumple, el proceso se detendrá sin cargar nada. Así, si en el ejemplo anterior, no existiese KI.FICHERO.HABILITACION, como el fichero de tipo 1, tiene un 2 en la posición 46, (lo cual indica que verifique que existen fisicamente el fichero de tipo 1 y que verifique que existen fisicamente, al menos, 03 ficheros de tipo 3, por cada fichero de tipo 2). Al no existir el de tipo 1, el proceso falla.

Se recomienda la utilización de criterios coherentes en cuanto a la verificación y a la carga, por ejemplo, si no existe KI.FICHERO.HABILITACION, e indicamos la ficha: 1KI.FICHERO.HABILITACION 103400

A pesar de que el proceso funcionaría sin problemas, le estamos indicando, que verifique que existen unicamente 3 ficheros de tipo 3 por cada fichero de tipo 2, y que cargue ficheros de tipo 2 y fichero de tipo 1 (éste último no existe, por lo que es incoherente).

No se permiten procesos que conlleven más de 99 ficheros a cargar.



5.4. Proceso de adaptación del fichero de aplicació n de recepción.

Se ha implementado la posibilidad de que una vez descargado el fichero de presentación correctamente, se pueda adaptar a otro formato, realizar una traducción y/o conversión, así como eliminar saltos de carro en los ficheros recibidos de los entornos que los utilizan. Esta posibilidad se extiende a los ficheros de aplicación de emisión, antes de cargarlos (adaptarlos, traducirlos y convertirlos por fuera de EDItran/FF). Dicho proceso se realiza a través del jcl ZTBGJFF4. Este consta de lo siguiente:

2. PARM. Se le pasan 3 parámetros distintos, separados por comas:

2.1. Separadores en hexadecimal a eliminar. Normalmente los UNIX envían 2 caracteres x0A-x0D al final de cada línea. Se pueden dar 3 casos:

2.1.1. No hay separadores. Se indican 4 octetos a espacios

2.1.2. Hay un separador x’YZ’. En el octeto 1 se indica Y, en el octeto 2 se indica Z, y en los 2 últimos octetos se indican espacios.

2.1.3. Hay dos separadores x’AB’ x’CD’. En el octeto 1 se indica A, en el octeto 2 se indica B, en el octeto 3 se indica C y en el octeto 4 se indica D.

2.2. Traducción. Admite los valores: E (traducir de ASCII a EBCDIC), A (traducir de EBCDIC a ASCII) y N(no traducir).

2.3. Tabla de conversión. Nombre de la tabla del fichero de tablas de conversión. Si no se quiere convertir se indicarán espacios.

3. Entrada. Es el nombre del fichero de aplicación, tal y como lo dejó EDItran/FF al pasar el posterior a recepción.

4. Salida. Es el nombre del fichero de aplicación de salida una vez realizados los cambios. El formato del mismo, dependerá de cómo se defina.

5. ZTBGFTCO. Es el nombre del fichero de tablas de conversión.

6. PASO002. Optativo. Borraría el fichero de aplicación origen si la adaptación del mismo es correcta.

//KI0F6AEA JOB (EGDC,KIT,,99),'EDITRAN-V51',MSGCLAS S=H,CLASS=A, // NOTIFY=&SYSUID //************************************************* ******************** //* ADAPTACION DE FICHEROS EDITRAN. TRADUCCION Y C ONVERSION INCLUIDOS. //* NOTA PARA FICHEROS FIJOS DE SALIDA: SI LRECL E S MAYOR QUE REGISTRO //* A GRABAR, SE RELLENA A ESPACIOS POR LA DE RECHA. //* NOTA PARA FIJOS DE ENTRADA Y VBLES DE SALIDA. PROBABLEMENTE, EL //* VBLE DEBE SER DEFINIDO 4 OCTETOS MAYOR QU E LRECL DE FIJO. //************************************************* ******************** //* VALORES DE PARM:(XXXX,Y,ZZZZZZZZ) SEPARADOS PO R COMAS: //* XX = CARACTERES HEXADECIMALES A ELIMINAR (SA LTO DE CARRO): //* - CUATRO OCTETOS A ESPACIOS: NO HAY CAR ACTERES A ELIMINAR //* - DOS OCTETOS INDICANDO UN CARACTER HEX ADECIMAL Y OTROS DOS //* A ESPACIOS. ELIMINA EL CARACTER DETER MINADO EN HEXA //* - CUATRO OCTETOS INDICANDO DOS CARACTER ES HEXADECIMALES. //* POR EJEMPLO 0D0A): ELIMINA LOS DOS HE XADECIMALES X0D-X0A //* Y = 1 OCTETO INDICANDO SI SE VA A TRADUCIR LENGUAJE DE FICHERO //* ORIGEN. VALORES POSIBLES: //* A(ASCII), E(EBCDIC), N(NO TRADUCIR) //* ZZ = 9 OCTETOS INDICANDO NOMBRE DE LA TABLA DE CONVERSION (QUE //* SE APLICA TRAS TRADUCIR).CON ESPACIOS N O HAY TABLA CONVERSION //* SI OCTETO 9 ES ‘A’ SE CONVIERTE A ASCII . //* SI OCTETO 9 ES ‘E’ SE CONVIERTE A EBCDI C.



//************************************************* ******************** //PASO001 EXEC PGM=ZTBGBFF4,PARM='0D0A,E,TABCVXNCE ' //STEPLIB DD DSN=KI.EIDC.ZTBG.LOAD,DISP=SHR //ZTBGFTCO DD DSN=KI.PMED.CZTB.ZTBGFTCO,DISP=SHR //ENTRADA DD DSN=PUNTERO.FICHERO.ORIGEN,DISP=SHR //SALIDA DD DSN=PUNTERO.FICHERO.FIJO244.DESTINO, // DCB=(RECFM=FB,LRECL=256,BLKSIZE=0,DSORG= PS), //* DCB=(RECFM=VB,LRECL=260,BLKSIZE=0,DSORG= PS) //* DCB=(RECFM=VS,LRECL=260,BLKSIZE=0,DSORG= PS) // DISP=(NEW,CATLG,DELETE), // SPACE=(TRK,(500,50),RLSE) //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSDBOUT DD SYSOUT=* //ABENDAID DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSABOUT DD SYSOUT=* //* //PASO002 EXEC PGM=IDCAMS,COND=(0,NE,PASO001) //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE (PUNTERO.FICHERO.ORIGEN) PURGE

//

El programa ZTBGBFF4, llamado desde el jcl anterior realiza los siguientes tratamientos:

1. Verifica que entrada y salida sean compatibles (recfm y lrecl). Si no lo son, genera un error y finaliza el proceso. Por ejemplo, que entrada y salida sean ficheros fijos y que ENTRADA tenga LRECL mayor a salida en más octetos que el número de separadores a eliminar.

2. Si hay tabla de conversión, leer la misma del fichero ZTBGFTCO. Si se le ha indicado traducir = ‘A’ y la tabla no tiene el carácter noveno = ‘A’, se dará un informativo (RETURN CODE 04) y continua el proceso. Si se le ha indicado traducir = ‘E’ y la tabla no tiene el carácter noveno = ‘E’, se dará un informativo (RETURN CODE 04) y continua el proceso. Si carácter noveno de la tabla es distinto de A o E, o no existe la tabla en el fichero se finaliza el proceso.

3. Por cada cada registro del fichero de ENTRADA, coge la parte de registro que tenga que grabar en salida sin los separadores, lo traduce y lo convierte. Si detecta que hay algún problema, por longitud, por formato de salida, etc finaliza el proceso con error.

Adapta el registro a SALIDA. Si salida es fijo, rellena con blancos por la derecha hasta alcanzar Lrecl de salida (saca un informativo en este caso).



6. EJEMPLO DE PROCEDIMIENTO DE FIRMA.

6.1. Emisión (modo automático utilizando ZTBGFITS).

Se habilita el NFS server del host para el puntero KI.EGDC.ZTBP.*

En EDItran/G, hemos especificado las características que queremamos.

En pleno proceso de carga, nos conectamos vía ip a EDItran/CD, que nos dice on-line si están todos los datos necesarios y nos devuelve los nombres de ficheros a cargar.

6.2. Emisión (modo no automático utilizando ENTRADA ).

Se habilita el NFS server del host para el puntero KI.EGDC.ZTBP.*

Por una sesión de presentación se van a emitir 2 ficheros de aplicación: KI.EGDC.ZTBP.FICHERO1 KI.EGDC.ZTBP.FICHERO2

A través del NFS, se pasan los ficheros anteriores al proceso de EDItran/FF, para su firma. El resultado es el de 2 ficheros de firma:

KI.EGDC.ZTBP.FICHERO1.P7B KI.EGDC.ZTBP.FICHERO2.P7B

A través del EDItran/FF, se habilita la emisión de los ficheros anteriores. Dicho proceso de habilitación, genera a su vez, un fichero, por ejemplo, fichero.aplicación, el cual es transmitido desde el NFS cliente y acaba siendo visto en el Host (por ejemplo KI.EGDC.ZTBP.APLIC). En éste momento, en el Host aparecen 5 ficheros:

KI.EGDC.ZTBP.FICHERO1 KI.EGDC.ZTBP.FICHERO2 KI.EGDC.ZTBP.FICHERO1.P7B KI.EGDC.ZTBP.FICHERO2.P7B KI.EGDC.ZTBP.APLIC

En el Host, se prepara un fichero fijo de longitud 80 (ENTRADA), por ejemplo, PUNTERO.LISTAFICH, cuyo contenido, son 5 registros distribuidos de la siguiente forma:

1KI.EGDC.ZTBP.APLIC 201201 2KI.EGDC.ZTBP.FICHERO2 3KI.EGDC.ZTBP.FICHERO1.P7B 2KI.EGDC.ZTBP.FICHERO2 3KI.EGDC.ZTBP.FICHERO2.P7B

Se pasa el jcl ZTBGJFF1, con PARM=A03 (si se quiere cargar y emitir) y la sesión de presentación. El paso1, como ENTRADA tiene el PUNTERO.LISTAFICH y como SALIDA (ZTBGFCAR), un fichero con la lista de ficheros a cargar-emitir y las características de los mismos a la hora de efectuar la carga. Dicho jcl, en su paso1, además, valida que exista el fichero de tipo 1 del PUNTERO.LSITAFICH, en el Host, de forma que se ha producido en efecto, la habilitación de envío. El fichero SALIDA tiene el siguiente formato:



KI.EGDC.ZTBP.FICHERO1 -A-B-C-D KI.EGDC.ZTBP.FICHERO1.P7B -A-B-C-D KI.EGDC.ZTBP.FICHERO2 -A-B-C-D KI.EGDC.ZTBP.FICHERO2.P7B -A-B-C-D


1 Registro-fich-entrada 80 2 Dsname de fichero 44 Alfn. Dsname del fichero de aplicación 2 Filler 1 Alf. Separador 2 Formato de fichero 1 Alfn. Formato de fichero de aplicación:

‘R’: Registro, ‘M’: Modificado 2 Filler 1 Alf. Separador 2 Lenguaje datos origen 1 Alfn. Lenguaje original de los datos:

‘B’ Binario ‘E’ Ebcdic ‘A’ ASCII

2 Filler 1 Alf. Separador 2 Traducir en emisión 1 Alfn. Traducir en emisión:

‘N’: Sin traducción ‘E’ Traducir a EBCDIC ‘A’ Traducir a ASCII

2 Filler 1 Alf. Separador 2 Compresión 1 Alfn. Compresión:

‘F’ Comprimido, ‘N’ Sin compresión 2 resto registro 28 Alfn. Area de reserva

Donde:

A=Tipo de fichero. (R)egistro o (M)odificado. En caso de que la sesión de presentación tenga el campo ASCI-EBCDIC=’A’, se pone M(modificado), puesto que el entorno remoto es ASCII. En caso contrario se asume R(registro).

B=Lenguaje original de los datos. Se asume el valor que tenga la sesión de presentación (en caso de fichero de datos) y se asume por defecto B(binario) para los ficheros de firma y de habilitación. Es importante recalcar que en caso de que se codifique ‘E’(EBCDIC), y el extremo remoto adapte automáticamente a ASCII, el contenido del fichero de datos sufrirá variaciones, por lo que no coincidirá con la firma aplicada.

C=Traducir en emisión. Se asume el valor que tenga la sesión de presentación (en caso de fichero de datos) y se asume por defecto N (no), para los ficheros de firma y de habilitación. Es importante recalcar que en caso de que se codifique algún valor que suponga realizar traducción y por tanto modificar el contenido del fichero original, supondrá que en el extremo remoto no coincidirá la firma recibida con el fichero de aplicación.

D=Compresión. Admite los valores F(con compresión) y N (sin compresión). Se asume lo que tenga el perfil de la sesión de presentación.

En el segundo paso, se coge dicha lista (ZTBGFCAR) y se cargan los ficheros allí descritos sobre el tampón (es necesario que en el registro de fichero de emisión, de la sesión de presentación no se haya codificado ninguno, para que pase a leer el ZTBGFCAR).



En el tercer paso, se borra fisicamente el fichero KI.EGDC.ZTBP.APLIC, de forma que si se inicia una nueva carga que no ha sido firmada (no existe tal fichero), ésta no se ejecuta por fallar el PASO1.

6.3. Recepción.

Se habilita el NFS Server del Host para el puntero KI.EGDC.ZTBP.*

Por una sesión de presentación se reciben y se descargan 4 ficheros de aplicación:

KI.EGDC.ZTBP.FICHERO1

KI.EGDC.ZTBP.FICHERO1.P7B

KI.EGDC.ZTBP.FICHERO2

KI.EGDC.ZTBP.FICHERO2.P7B

A través del NFS cliente, se pasan los ficheros anteriores al proceso de EDItran/FF. El resultado es que se valida que FICHERO1.P7B, se corresponde con la firma de FICHERO1 y que con FICHERO2.P7B sucede lo mismo.

Si fuera necesario se pasa el jcl ZTBGJFF4, para adaptar los ficheros de aplicación recibidos a un formato o lenguaje conocidos (adaptación del tipo de fichero, eliminación de saltos de carro, traducción y conversión de los datos). El resultado es el siguiente:

KI.EGDC.ZTBP.FICHERO1.NEW

KI.EGDC.ZTBP.FICHERO2.NEW



7. PARAMETRIZACIONES EDItran/G. Para modo de funcionamiento automático ó no automático revise en otra parte de este documento.

7.1. ZOS como emisor y receptor.

PARAMETRIZACION EDITRAN/G ENTRE ENTORNOS HOMOGENEOS

(POR EJEMPLO, 2 ZOS)

EMISOR RECEPTOR

PARAMETROS SESION FICHERO SESION

Vers. EDI/G remota

5.1 - 5.1

Conversor prev. Emi

ZTBGBG10 - -

Conversor post. Rec.

- - ZTBGBG40

Tab. Conversión emi

Espacios - -

Tab.Conversión Rec

- - Espacios

Leng.original datos

- - -

Traducir en emisión

- N -

Traducir en recepc.

- - N (Si se quisiera traducir habría que crear un proceso nuevo tras la verificación de la firma)

Formato Fich emi. - R (Se puede codificar M en uno de ellos, siempre y cuando los formatos de descarga sean correctos). (Se puede codificar M en ambos siempre que los formatos de ambos sean iguales y los de descarga sean adecuados).

-

Formato Fich Desc.

- - Depende de la opción con la que cargó el emisor (verifique formato fich emi). Todos los ficheros recibidos como M deben tener el mismo formato y además debe adecuarse a éste valor.

Fich.único recep. - - N

Nombre fichero recepción

- - *.%O ( * debe ser el puntero habilitado al NFS. Se descarga como se llaman en origen, adaptando a mayúsculas).



7.1.1. ZOS como emisor y otro entorno como receptor.

PARAMETRIZACION EDITRAN/G ENTRE ENTORNOS HETEROGENE OS

EMISOR ZOS RECEPTOR WINDOWS


Vers. EDI/G remota

5.1 - 5.1

Conversor prev. Emi

ZTBGBG10 - -


Espacios - -

Tab.Conversión Rec

- - Espacios

Leng.original datos

- B -


- N -

Traducir en recepc.

- - N (Si se quisiera traducir habría que crear un proceso nuevo tras la verificación de la firma, pe. a ASCII).

Formato Fich emi. - M -

Formato Fich Desc.

- - V (Si se quisiera adaptar el fichero de aplicación a formato fijo, debe pasarse un proceso nuevo, posterior a la verificación de firma. No es posible la recepción de ficheros variables).



- - *.%O ( * debe ser el puntero habilitado al NFS. Se descarga como se llaman en origen).



7.2. ZOS como receptor y otro entorno como emisor.

PARAMETRIZACION EDITRAN/G ENTRE ENTORNOS HETEROGENE OS

EMISOR WINDOWS RECEPTOR ZOS


Vers. EDI/G remota

5.1 - 5.1

Conversor post. Rec.

- - ZTBGBG40


Espacios - -

Tab.Conversión Rec

- - Espacios

Leng.original datos

- B -


- N -

Traducir en recepc.

- - N (Si se quisiera traducir habría que crear un proceso nuevo tras la verificación de la firma, pe. a EBCDIC).

Formato Fich emi. - B -

Formato Fich Desc.

- - V- E (Si se quisiera adaptar el fichero de aplicación a formato fijo, debe pasarse un proceso nuevo, posterior a la verificación de firma. No es posible la recepción de ficheros variables, pues HOST no sabría como reconstruirlos).



- - *.%O ( * debe ser el puntero habilitado al NFS. Se descarga como se llaman en origen, adaptando a mayúsculas el nombre).

firma electrónica de ficheros mvs z/os (enlace con...

Documents