CC 2 Reason Code 2219 en MQOPEN - Ambiente CICS-COBOL

[riloama]

Estimados especialistas y usuarios de MQ,

estoy teniendo un problema en un programa COBOL ejecutado bajo CICS que lee y graba mensajes MQ.

Desde el punto de vista de MQ este programa tiene en su inicio un MQOPEN que se ejecuta una unica vez ( no hay loop ) que habitualmente funciona correctamente. De vez en cuando, y no puedo observar a simple vista las causas, falla con RC 2219 cuyo significado es el siguiente:

2219 (08AB) (RC2219): MQRC_CALL_IN_PROGRESS
The application issued an MQI call whilst another MQI call was already being processed for that connection. Only one call per application connection can be processed at a time.

Habitualmente funciona correctamente pero con cierta frecuencia obtengo este 2219. Reitero que el MQOPEN se ejecuta una unica vez, por lo que no veo que esta peticion pueda solaparse con otra para dar un MQRC_CALL_IN_PROGRESS .

No soy experto en MQ por lo que queria consultarlos acerca de cuales son los parametros que debo observar para poder intentar identificar las causas del error ( definicion de la cola, conexion, CICS, programa, etc ).

Saludos

[LuisFer]

Realmente es extraño que te suceda este error, cuando generalmente las APIs MQ son síncronas (no devuelven control al programa hasta que no han finalizado). Solo la MQGET con "señal" (disponible solo en z/OS y Tandem) permite la "asincronía".
Dado que el programa se ejecuta bajo CICS entiendo que no hay una llamada previa a una MQCONN , ¿es así?

Saludos

Código: Seleccionar todo

CICS® Transaction Server for z/OS and CICS for MVS/ESA
CICS programs do not need to do any work to connect to a queue manager because the CICS system itself is connected. This connection is typically made automatically at initialization, but you can also use the CKQC transaction, which is supplied with WebSphere MQ for z/OS. For more information about CKQC see the Administering z/OS.
CICS tasks can connect only to the queue manager to which the CICS region, itself, is connected.

Note: CICS programs can also use the MQI connect and disconnect calls (MQCONN and MQDISC). You might want to do this so that you can port these applications to non-CICS environments with a minimum of recoding. However, these calls always complete successfully in a CICS environment. This means that the return code might not reflect the true state of the connection to the queue manager.

[riloama]

Hola LuisFer,

efectivamente el programa no tiene MQCONN, seguramente porque la conexion esta establecida entre CICS y MQ; al ejecutar un CEMT I MQCONN obtengo los datos de conexion CICS-MQ.

[LuisFer]

Hola Riloama:
Aunque no sé que versión de MQ tienes creo que este APAR tiene similitudes,
http://www-304.ibm.com/support/docview. ... lang=en+en

Espero que te ayude, en cualquier caso, buscaré algo más

Saludos

[riloama]

LuisFer,

por lo que vi en la descripcion del APAR pareciera tener relacion. Estuve buscando en listas de APARs de IBM pero no encontre este.

Muchisimas gracias

[riloama]

LuisFer,

hemos detectado la causa del CC 2 - RC 2219; se ha debido a que desde una aplicacion web se agregaba un MQ Header a los mensajes que no correspondia.

Queria consultarte, debido a que no me queda clara la definicion que da el MQ Series Primer de IBM, que diferencia existe entre Trigger Type Every y First y si en funcion de este tipo de trigger debo realizar cambios en la logica de un programa de aplicacion COBOL, en especial si este corre bajo CICS, que recibe un mensaje de una cola request y emite un mensaje sobre una cola de reply.

[LuisFer]

Para que se "dispare" una TX tiene que existir una tarea Monitor (un Trigger Monitor).
Es común este método para "colocar" Tx en el Monitor transaccional (ya sea IMS o CICS) aunque desde mi óptica desaconsejable por rendimiento (cada mensaje obliga a realizar 3 MQI, la OPEN, la PUT y la CLOSE).
Para el tipo EVERY por cada mensaje que llega a la cola el "trigger" dispara una Tx "predefinida" en las opciones de la propia cola, luego, es de suponer, que esa Tx recoge el mensaje para obtener los datos de ejecución (no necesariamente tiene que ser así), realiza la lógica de negocio y devuelve una contestación(la "reply") donde espera el cliente.
Para el tipo FIRST solo se dispara con el primer mensaje, con lo que si llega un segundo mensaje en el pequeño intervalo que va desde la recepción hasta que la Tx va a por el mensaje "request" , esta segunda Tx NO se arrancará y puede llegar a darse el caso de que la Tx "en vuelo" recoja el segundo mensaje (esto depende de como esté organizada la cola).
Existe un tercer trigger que es por profundidad de la cola, en este caso se dispara un proceso o Tx, cuando la cola alcanza un numero de mensajes, tiene la desventaja que el trigger queda deshabilitado por lo que es necesario habilitarlo posteriormente.
Resumiendo, para disparar Tx CICS la cola como EVERY.
En mi caso (para IMS) utilizamos el "bridge MQ" via OTMA para "colocar" la Tx al IMS, es infinitamente mas efectivo.

Saludos

[riloama]

LuisFer, me queda clara tu explicacion, pero aun no me queda claro la necesidad de tener transacciones con trigger First.

Para el tipo FIRST solo se dispara con el primer mensaje, con lo que si llega un segundo mensaje en el pequeño intervalo que va desde la recepción hasta que la Tx va a por el mensaje "request" , esta segunda Tx NO se arrancará y puede llegar a darse el caso de que la Tx "en vuelo" recoja el segundo mensaje (esto depende de como esté organizada la cola)

Tengo la sensacion que el trigger Every resuelve la mayoria de los casos tipicos; que tipo de aplicacion utilizaria transacciones First en las cuales se puede recibir uno o mas mensajes pero dependientes de ese breve intervalo que describes ? O es un tema de performance ?

[LuisFer]

FIRT y DEPTH nosotros lo usamos básicamente para disparar BATCH, nunca para Tx.
No es un problema de redimiento ya que las APIs llamadas (OPEN,GET,CLOSE) son las mismas.

Saludos

[riloama]

LuisFer

Gracias

[coa14561]

Para que se "dispare" una TX tiene que existir una tarea Monitor (un Trigger Monitor).
Es común este método para "colocar" Tx en el Monitor transaccional (ya sea IMS o CICS) aunque desde mi óptica desaconsejable por rendimiento (cada mensaje obliga a realizar 3 MQI, la OPEN, la PUT y la CLOSE).
Para el tipo EVERY por cada mensaje que llega a la cola el "trigger" dispara una Tx "predefinida" en las opciones de la propia cola, luego, es de suponer, que esa Tx recoge el mensaje para obtener los datos de ejecución (no necesariamente tiene que ser así), realiza la lógica de negocio y devuelve una contestación(la "reply") donde espera el cliente.
Para el tipo FIRST solo se dispara con el primer mensaje, con lo que si llega un segundo mensaje en el pequeño intervalo que va desde la recepción hasta que la Tx va a por el mensaje "request" , esta segunda Tx NO se arrancará y puede llegar a darse el caso de que la Tx "en vuelo" recoja el segundo mensaje (esto depende de como esté organizada la cola).
Existe un tercer trigger que es por profundidad de la cola, en este caso se dispara un proceso o Tx, cuando la cola alcanza un numero de mensajes, tiene la desventaja que el trigger queda deshabilitado por lo que es necesario habilitarlo posteriormente.
Resumiendo, para disparar Tx CICS la cola como EVERY.
En mi caso (para IMS) utilizamos el "bridge MQ" via OTMA para "colocar" la Tx al IMS, es infinitamente mas efectivo.

Saludos

Cola MQ indexada por GROUP-ID, TRIGGER con opción EVERY, transacción cics con GET lógico y loop de lectura hasta finalizar los mensajes (Codigo 2033).
¿ Cuando el trigger dispara la transacción y la misma se esta ejecutando al ingresar un nuevo mensaje se dispara una segunda transacción ?

Desde ya gracias, LuisFer

[LuisFer]

Cola MQ indexada por GROUP-ID, TRIGGER con opción EVERY, transacción cics con GET lógico y loop de lectura hasta finalizar los mensajes (Codigo 2033).
¿ Cuando el trigger dispara la transacción y la misma se esta ejecutando al ingresar un nuevo mensaje se dispara una segunda transacción ?

Desde ya gracias, LuisFer

Así debería ser ...