Consulta de mensajes
A continuación se listan los códigos de retorno de las
funciones CPI-C que aparecen con más frecuencia. En esta lista NO
aparecen todos los códigos de retorno. El número entre paréntesis
indica el número definido correspondiente al código de retorno.
- CM_ALLOCATE_FAILURE_NO_RETRY (1): La asignación ha fallado debido a
una condición no temporal. Por ejemplo, la sesión no puede activarse
porque se ha producido un error de definición del sistema o un error de
protocolo de activación de sesión. Este código de retorno también se
devuelve cuando la sesión se desactiva debido a un error de protocolo de
sesión antes de poder asignar la conversación.
- CM_ALLOCATE_FAILURE_RETRY (2): La asignación ha fallado debido a una
condición temporal. Por ejemplo, la sesión no puede activarse porque
temporalmente faltan recursos en el sistema local o remoto.
- CM_CONVERSATION_TYPE_MISMATCH (3): La asignación ha fallado porque
el programa remoto no ofrece soporte para el tipo de conversación en la
solicitud de asignación. Es probable que se trate de un problema con el
TP en el servidor. Asegúrese de que el TP en el servidor se haya
configurado para dar soporte a un tipo de conversión basic.
- CM_TPN_NOT_RECOGNIZED (9): Este error aparece cuando la solicitud de
asignación se envía al sistema remoto. Significa que el sistema remoto
no da soporte al nombre del programa de transacción que se especifica en la
solicitud. Si no está utilizando servicios de directorio global,
asegúrese de que el nombre TP especificado en el perfil de información CPI-C
en el cliente coincida con el nombre TP especificado en el servidor. Si
está utilizando los servicios de directorio global, solicite ayuda al
administrador de la base de datos para garantizar que el nombre TP
especificado en la entrada de directorio global coincida con el nombre TP
especificado en el servidor.
- CM_TP_NOT_AVAILABLE_NO_RETRY (10): Este error aparece cuando la
solicitud de asignación se envía al sistema remoto. Significa que la LU
remota reconoce el nombre TP que se ha enviado, pero no puede iniciar el
programa. Asimismo, compruebe que el id de usuario especificado en el
perfil TPN en el servidor sea válido.
- CM_TP_NOT_AVAILABLE_RETRY (11): Este error aparece cuando la
solicitud de asignación se envía al sistema remoto. Significa que la LU
remota reconoce el nombre TP que se ha enviado pero, por algún motivo que
puede ser transitorio, no puede iniciar el programa. Asegúrese de que
el gestor de bases de datos y el soporte de protocolo APPC en el servidor se
hayan inicado satisfactoriamente.
- CM_DEALLOCATED_ABEND (17): Este error aparece cuando el programa
remoto desasigna la conversación. Esta situación pueden producirse si
el programa remoto finaliza anormalmente o se detecta una condición de error
muy grave. Si intenta conectarse al DB2 para AIX, compruebe que el
gestor de la base de datos y el soporte de protocolo APPC en el servidor se
hayan iniciado satisfactoriamente. Para un servidor AIX, este error
puede provocarlo alguna de las situaciones siguientes:
- El administrador del sistema ha forzado la desconexión del agente de la
base de datos.
- El agente de una base de datos no ha podido iniciarse en el servidor
porque se ha sobrepasado el parámetro maxagents de la configuración del gestor de bases de datos. Consulte el registro
First Failure Service (DB2DIAG.LOG) en el servidor para ver si ha
quedado anotado algún mensaje de error.
- El agente de la base de datos se ha interrumpido debido a la terminación
anómala de un proceso importante del gestor de bases de datos.
- CM_PRODUCT_SPECIFIC_ERROR (20): Se ha detectado un error específico
del producto y una descripción del error se ha almacenado en la anotación
cronológica de errores del sistema del producto. Asegúrese de que el
subsistema APPC local se haya iniciado satisfactoriamente. En
Communication Server para AIX, para obtener más información sobre un error
específico del producto, es necesario que compruebe el valor de la variable
global errno. Consulte el apartado siguiente para ver más
información sobre los posibles errnos que se pueden
devolver. Communication Server para OS/2 registra los errores en la
anotación cronológica de errores del sistema OS/2.
- CM_RESOURCE_FAILURE_NO_RETRY (26): Este error aparece cuando la
conversación finaliza prematuramente (en el sistema remoto o local) debido a
un error relacionado con los recursos (sesiones o enlaces, por
ejemplo). Para un servidor OS/2, este error puede provocarlo alguna de
las situaciones siguientes:
- El administrador del sistema ha forzado la desconexión del agente de la
base de datos.
- El agente de una base de datos no ha podido iniciarse en el servidor
porque se ha sobrepasado el parámetro maxagents de la configuración del gestor de bases de datos. Consulte el registro
First Failure Service (DB2DIAG.LOG) en el servidor para ver si ha
quedado anotado algún mensaje de error.
- El agente de la base de datos se ha interrumpido debido a la terminación
anómala de un proceso importante del gestor de bases de datos.
- CM_RESOURCE_FAILURE_RETRY (27): Este error aparece cuando la
conversación finaliza prematuramente (en el sistema remoto o local) por el
mismo motivo que la condición NO_RETRY que se acaba de describir. La
única diferencia estriba en que es posible que el error no sea
permanente.
En gran medida, los códigos de retorno de las comunicaciones CPI
constituyen una fuente de información suficiente para poder averiguar la causa
de un error. Pero si se devuelve CM_PRODUCT_SPECIFIC_ERROR, se
suministra información adicional.
Para Communication Server para AIX, el errno facilita
información adicional. A continuación se listan algunos de los
errnos más habituales. No es una lista completa. Los
errnos listados con los números 101 y posteriores pueden hallarse
en el archivo /usr/include/luxsna.h, que contiene los
errnos específicos para Communication Server para AIX. La
mayoría de dichos errnos se convierten en códigos de retorno de
CPI-C. Los errnos de numeración más baja están relacionados
con problemas de AIX y se encuentran en el archivo
/usr/include/sys/errno.h. El número errno
está entre paréntesis.
- EBADF (9): Se trata de un error de "descriptor de archivo
erróneo". Si este error se produce al intentar conectarse a la base de
datos, normalmente significa que el subsistema SNA en el servidor no se ha
iniciado o que hay algún problema con los perfiles de configuración
SNA. Asegúrese de que el subsistema SNA se haya iniciado y que la
estación de enlace con el nodo del servidor pueda activarse.
- EACCESS (13): Se trata de un error de "permiso denegado". Si
este error se produce al intentar conectarse a la base de datos, normalmente
significa que hay algún problema con los perfiles de configuración SNA.
En HP-UX, para SNAPlus2, consulte el archivo
/usr/include/sys/errno.h para obtener una descripción del error.
Para OS/2, cuando las comunicaciones CPI devuelven
CM_PRODUCT_SPECIFIC_ERROR, se crea una entrada en la anotación cronológica de
errores. La información de la anotación cronológica de errores indica
que CPIC es el originador. Si Communications Server/2
(CS/2) se encuentra instalado, CS/2 registra el error en el
archivo de anotaciones cronológicas de errores del sistema
OS/2.Consulte la guía de determinación de problemas del producto
en cuestión para ver una descripción completa del error y la acción que se
recomienda efectuar.
Para obtener más información sobre los errores de comunicaciones CPI,
consulte la publicación Systems Application Architecture Common
Programming Interface Communications Reference.
[ Principio de página | Página anterior | Página siguiente | Contenido | Índice ]