NOSEND in SMQ1

[Former Member]

Hello All,

In source system the SMQ1 shows huge number of entries for Queues like MCEX02, 03, 11 and 12. The total number of records in ARFCSSTATE is reaallly huge.

The destination for these queues is "NONE". What does this mean?

The Status of these queues is NOSEND. I tried to check many threads, but no one mentions how can we get rid of these records.

How can I make sure that I am not disturbing any READY/RECORDED queues?

Regards,

NIKEKAB

[Former Member]

All,

This simply implies that there is data in the delta queue & needs to be flushed out.

--

Ever wondered, why we still see the LUW entries in RSA7 even after the successful Delta Load in BW.

Or it takes Two Delta loads to make LUW entries in "0" in RSA7.

You can blame NOSEND status of "Queue Name" in SMQ1 for that. Once you repeat the Delta load, the Delta Queue from SMQ1 goes away until new transaction is recorded.

Cheers,

Deepak

[former_member182470]

Hi,

The destination for these queues is "NONE". What does this mean?

MCEX02 means if the User posts any data entries in this Application, these entries will come to MCEX02, as you can see in SMQ1/LBWQ.

After you run the V3 job, the the entries in LBWQ will be moving to RSA7 as LUWs.

Check this link for better understanding:----

---

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/90fddfcd-a956-2d10-19be-8f7bdd699a05

Regards,

Suman

[Former Member]

Hello Suman,

The destination for these queues is "NONE". What does this mean?

>>> If you go to smq1 you see 2-3 columns which are

Queue name -- destination -- entries. I am talking about this Destination.

MCEX02 means if the User posts any data entries in this Application, these entries will come to MCEX02, as you can see in SMQ1/LBWQ.

After you run the V3 job, the the entries in LBWQ will be moving to RSA7 as LUWs.

>>But in RSA7, I can see huge number of entries for a source which has no connection with this target system??

>> Does this mean that the deltas are being generated but no one actually needs these deltas and so they are piling up in ARFCSSTATE? The no. of entries in this table are 7368617. Which is huge and disturbing...

If I want to get rid of this - I will just have to deactivate the LO Data extraction in LBWE right?

Oh!! But 2LIS_02_SCL datasource is providing data to other valid BW systems as well..

What do I do?

Edited by: NIKEKAB on Aug 22, 2011 3:44 PM

[Former Member]

Hello Suman,

I just checked the article you provided. None is nothing to do with any destination. It is just the number of actual transaction entries.

So now the NONE destination issue is not bothering me.

Only issue left is...why are these Deltas being generated in LBWQ/SMQ1 for datasources like 2LIS_02_SCL, 2LIS_11_VAITM, VDITM etc with a destination that needs no data from this source system.

How can I stop it?

[former_member182470]

Hi NIKE,

NOSEND

LUWs of this queue are never sent but retrieved by a special application. These queues are only used internally at SAP (BW or CRM during communication with Mobile Clients). Even if a LUW has been read by the corresponding application (BW, CRM), this status does not change. This LUW is only deleted from the queue if this application confirms collection (collective confirmation possible). Under no circumstances should this status be reset using transaction SMQ1 and the queue activated.

One Quick Question

Since your mentioned datasources are activated in LBWE, if any User posts any entries, they come into SMQ1. If you really want to avoid it, please deactivate your Extract Structures in LBWE.

Regards,

Suman

[Former Member]

Hi

If you are not using any data source(which not supplying delta to any system) simply de-activate in LBWE

check the below link for queue status in SMQ1

http://help.sap.com/saphelp_nw04/helpdata/en/ad/7b623c6374a865e10000000a11402f/frameset.htm

Regards,

Venkatesh

[Former Member]

378903 - Queue status in SMQ1, SMQ2 and table ARFCRSTATE

1597364 - FAQ: BW-BCT: Extraction performance in source system. See point 3

375566 - Large number of entries in tRFC and qRFC tables

706478 - Preventing Basis tables from increasing considerably