RFC gateway trace keeps activating

Question

Hi experts!
We are having a problem in our Live XI environment. The issue is the following:
We have an unique communication user and an unique RFC for all the interfaces that uses an RFC channel. The problem is that the gateway trace is being activated every time an RFC connection is done. This is creating big .trc files as we do over 5000 rfc connections every day with this user.
Our Basis team has disabled the trace but, when a new connection is done, the trace is being activated again.
Could you please help us to find where can be this trace activated? Could it be a parameter in the XI system?
Thanks in advance!!
Message was edited by:
        Jose Luis C.S.

Answer 1

I update this with a trace... hope it helps:
Mon Nov 19 23:46:58 2007
found trace flag (2) in appc header ***
IN:
ReqType     : CPIC         SysIdx  : 607    ReqLen  : 1610   ReqId   : 4799
CommIdx     : -1           ConnIdx : 16     ReqVer  : 6      Trace   : 2
conn        : 16           wp_no   : -1     ReqBlk  : -1
RqType      : SAP_SEND     Prot    : INT    UID     : -1     Mode    : 0
User        :              SapRc   : 0      AppcRc  : 0      ConvId  : 37909116
Vector      : F_V_SEND_DATA F_V_RECEIVE
Info        : SYNC_CPIC_FUNCTION WITH_GW_SAP_PARAMS_HDR
Send Length : 1530
Req Length  : 16000
Address
Offset
CPIC-Data
x00831550
000000
01010008 01020101 01010000 01010103
x00831560
000016
00040000 020b0103 0106000b 04010002
x00831570
000032
01000200 00002301 06000700 0e31302e
......#......10.
x00831580
000048
3131322e 3234362e 31333900 07001100
112.246.139.....
GwSearchConn3: found conn 16 without search
GwIHandleRq: own_index: 0
GwIHandleRq: set act rq type SAP_SEND
R3SEND(37909116, cpic_vector=1, ..)
I am the client (0)
GwBufInsert: insert data/status for conn/target 16/1, req_block_no: -1
GwBufInsert: insert data
GwBufInsert: use_req_block_addr (8000000100831490, len=1806)
GwBufInsert: (after insert): no/old/new: 1/26/26, conn/target: 16/1
R3RCV(37909116, cpic_vector=1, ..)
R3ISaveRcv: wait for 16000 bytes
R3ISaveRcv: data for partner buffered
R3ISendData: send saved data to conn/target 16/1, async_rfc=0
R3ISendData: Data (1530 bytes) can be send completely
GwSetCPICState: state of conn/index 16/1: SEND
GwSetCPICState: state of conn/index 16/0: RECEIVE
GwSendToClient: send data to conn/target/client 16/1/0
OUT:
ReqType     : CPIC         SysIdx  : 0      ReqLen  : 1610   ReqId   : 4799
CommIdx     : 142          ConnIdx : 16     ReqVer  : 6      Trace   : 2
conn        : 16           wp_no   : -1     ReqBlk  : -1
RqType      : SAP_SEND     Prot    : INT    UID     : 24025  Mode    : 0
User        :              SapRc   : 0      AppcRc  : 0      ConvId  : 37909116
Vector      : F_V_SEND_DATA F_V_RECEIVE
Info        : SYNC_CPIC_FUNCTION WITH_GW_SAP_PARAMS_HDR
Info3       : GW_WITH_CODE_PAGE
Data rec    : 2            Rec Leng: 1530     Stat rec: 1        ReqToSnd: 0
Address
Offset
CPIC-Data
x00831550
000000
01010008 01020101 01010000 01010103
x00831560
000016
00040000 020b0103 0106000b 04010002
x00831570
000032
01000200 00002301 06000700 0e31302e
......#......10.
x00831580
000048
3131322e 3234362e 31333900 07001100
112.246.139.....
GwRqDpSendTo (gw_id=0, appc_ca_blk=-1, len=1610, comm_index=-1)
LOCK APPC ca_blk 57
ThGetCommIdx: found index 142 via appc_hdr
found entry 142 (tid/uid/mode/conv_id/a_r: 101/24025/0/37909116/0)
make DISP owner of appc_ca_blk 57
DpRqPutIntoQueue: put request into queue (reqtype 0, prio LOW, rq_id 60586)
GwDispWakeUp: send wakeup with ni handle 5
NiIWrite: write 1, 1 packs, MESG_IO, hdl 5, data complete
-OUT- sender_id APPC_SERVER       tid  101   wp_ca_blk   -1      wp_id -1
-OUT- action    SEND_TO_WP        uid  24025   appc_ca_blk 57      type  NOWP
-OUT- new_stat  NO_CHANGE         mode 0     len         1610    rq_id 60586
GwFreeMemory: free 8000000100831490 (len=1806)
GwFreeMemory: act_overflow_size = 0 (- 1806)
R3ISendData (after release): no/old/new: 0/27/26
R3RCV: state of conn/index 16/0: RECEIVE_WAIT_FOR_DATA
trace switched off ***