Trasporte en demora, no pasa se queda en cola. Unix/Oracle

[IvanUrquieta]

Que tal tengo 2 sistemas DEV y PRD acabo de hacer un upgrade en de sistema de 4.7 a ecc6 unix/db oracle a 10, aqui en detalle entre sistemas las ordenes pasan bien sin problema se visualizan perfecto, pero las ordenes de trasporte en PRD se quedan ahy no pasan, hasta que corro este reporte RDDIMPDP en el trx se38 en el mdt 000 con ddic varias veces. Despues de eso la orden pasa. Ya cheque permisos de rutas, usuarios ddic y el tmsadm en ambos como server´´s y encontre varias notas.

Note 449270 - Job RDDIMPDP is not triggered by sapevt
Note 374379 - Triggering SAPEVT from a remote host
Note 11661 - Event-driven call of background jobs does not work

Dentro de la sm64 si existen estos job
SAP_TRIGGER_RDDIMPDP
SAP_TRIGGER_RDDIMPDP_CLIENT
y estan activados.

Ya cambie el kernel al mas actual que a liberado sap
pero no he tenido exito.

Ahora me di cuenta dentro del sistema operativo al listar los servicios tp que se quedan vivos despues de pasar la orden tengo q matarlos manualmente.
Segun se que despues de pasar una orden no debe haber ningun servicio tp.

Mi Log es este:>
****************************************
NiBufSend starting
NiHsLGetHostName: found address 10.1.5.3 in cache
NiIGetHostName: addr 10.1.5.3 = hostname 'productivo'
NiHsLGetServName: found port number 0E.10/3600 in cache
NiIGetServName: port 0E.10/3600 = servicename 'sapmsPMP'
***LOG Q0I=> NiIWrite: writev (32: Broken pipe) [nixxi.cpp 3948]
*** ERROR => NiIWrite: SiSendV failed for hdl 0 / sock 9
(SI_ECONN_BROKEN/32; UD; ST; 10.1.5.3:3600) [nixxi.cpp 3948]
*** ERROR => MsINiWrite: NiBufSend (rc=NIECONN_BROKEN) [msxxi.c 2476]
*** ERROR => MsIDetach: MsINiWrite (rc=NIECONN_BROKEN) [msxxi.c 1145]
MsIDetach: send logout to msg_server
NiICloseHandle: shutdown and close hdl 0 / sock 9
NiBufIClose: clear extension for hdl 0
MsIDetach: detach MS-system
MsDetach, rc = 0
***************************************

Fri May 8 16:24:14 2009
Trace File of External Event Raiser (Level=0, Append=1)
EventID: SAP_TRIGGER_RDDIMPDP
SAP message server host: productivo
SAP message server service (old): sapmsPMP
*** ERROR ***: MsSndTypeOnce, rc = -20
*** ERROR ***: Event raise failed
***************************************

Espero alguien me pueda ayudar. Llevo algunos dias con el problema.

SLDS

[gogua]

el job RDDIMPDP se replanifica con el programa RDDNEWPP.

Ejecutalo en el mandante 000 con el ddic.

saludos

[IvanUrquieta]

Hola Amigo mil gracias por la respuesta, de hecho hice en el mtd 000 con el ddic, corri este reporte que borra todos los job viejos o que estan de sobra RSBTCDEL, despues corri RDDNEWPP este que me indicas y le di alta prioridad al job RDDIMPDP. Aqui el detalle es que al hacer un trasporte este job no se ejecuta automaticamente a pesar de que en la sm64 esta activado estos 2 eventos SAP_TRIGGER_RDDIMPDP, SAP_TRIGGER_RDDIMPDP_CLIENT que son los referentes a ejecutar el trasporte cuando uno lo lanza desde la stms. Pero no lo hace hasta q lo hago manual. De hecho reconfigure la ruta de trasporte y ambos server´´s se ven las ordenes, sin problema.

Aun no funciona.

[IvanUrquieta]

Fue un logro, muchos dias sin dormir quedo listo.

SLDS

[jmaciel]

Yo tube el mismo problema y fue porque en service no estaba definido el puerto sapmsSID nro/tcp

Lo habilite y en las propiedades de la cola agregue ese mismo valor.

[IvanUrquieta]

Aqui el detalle fue la redireccionar unos parametros que apuntaban a la vieja base. Desde El OS

SLDS

[jmera]

yo aun sigo con el mismo problema, por favor indicame que mas hiciste.
saludos

[jprosalia]

Cuando os encontréis con este tipo de problemas "transport hangs", además de lo que ya han indicado de ejecutar el report RRDIMPNEW en el mndt 000, hay que analizar las trazas que la herramienta TP deja a nivel de filesystem:

/usr/sap/trans/log --> mirar los últimos por fecha de modificación.
/usr/sap/trans/tmp --> también mirar aquí si existe algún log adicional.

Problemas que me he encontrado en esta situación:

1- Tuve que ejecutar realmente el report RDDIMPNEW.
2- El kernel estaba mal actualizado (descomprimido con root), y daba acceso denegado al ejecutar el sapevt.
3- En alguna ocasión se ha quedado algún archivo "pillado" dentro de /usr/sap/trans/tmp... en esos casos el log de TP te dirá cual es el fichero al que está re-intentando acceder. En tal caso lo borras, y vuelves a lanzar el transporte.

Un saludo.