PRD: Sending import queue PRD (block 10 from 12) - STMS

[Former Member]

Hello.

For some time now when I refresh the Import queue (STMS) from a productive system this notification occurs: "PRD: Sending import queue PRD (block 10 from 12)" as it cycles through "block 1 to block 12", as if it were trying to read something. This doesn't occur in DEV nor QAS when transporting...

I've seen this [topic|] here with similar issue, however I'm not able to understand the "answer" provided.

If anyone could give a little bit of insight about this I would appreciate. Thanks.

[former_member182034 · Accepted solution]

hi Ruben,

you can solve your problem with following steps

1. First check at OS level that any tp process are running and if running then kill all tp processess

exp: Task Manager

2. Delete all the .LOC and .LOB files from the directory /usr/sap/trans/tmp.

or

Delete all the existing instances of RDDIMPDP job in the system.

3. Delete all the entries from TRBAT, TRJOB tables and save

SM30 --> TRBAT

click on Maintain

select entries and delete

save

if tp process are running in Task Manager then save function vl not work

5. Login to 000 client with user id DDIC and execute the report RDDNEWPP to schedule the job.

SE38 --> RDDNEWPP --> F8

please tell me if you get issue..

Regards,

majamil

[Former Member · Accepted solution]

Hi, thanks for your reply.

I've followed your steps, however problem persists since I have no LOC or LOB files in /usr/sap/trans/tmp

And my entries from TRBAT, TRJOB are clean. Therefore I haven't cancelled the job RDDIMPDP.

More suggestions are welcome...

[former_member182034 · Accepted solution]

hi ruben,

did you try following method.

STMS

add the request to PRD buffer by :

stms -> systems -> double clik on PRD

Extras -> Other request -> Add : put the change request OK

refresh and select the request and import it.

but my last post had resolved this issue?

regards,

[Former Member · Accepted solution]

I can import requests just fine.

The issue comes when I refresh STMS import list. It just takes like 7 minutes with the message "Sending import queue PRD (block 10 from 12)" from block 1 to 12. The "block" 10,11,12 are the slowest to "read".

I believe its some requests that are bugged/stuck perhaps, I just wanted to know which ones and I would remove them from the import list (since I have over 2000 records).

[former_member182034 · Accepted solution]

hi Ruben,

sometime we get this issue when the size of folders in usr/sap/trans overflow the default limit, So you have to cut past some file from Log/Buffer/Cofile/Datafile folders and try again.

Regards,

[Former Member · Accepted solution]

Hi.

How to check /usr/sap/trans default limit?

So you just remove some datafiles/cofiles and move to another directory outside /usr/sap/trans and that should solve it?

[Former Member · Accepted solution]

This issue has been solved.

The problem was several requests in import queue were not automatically adjusted. Since DEV and QAS share the same /usr/sap/trans but PRD doesnt, when transfering some request due to networks erros or glitches some requests needed to be manually adjusted.

Moreover after a Queue -> Check -> consistency some old requests (2007 request - yes import queue hasnt been cleaned a lot) didn't exit,neither data or cofiles, because of some hardware migration, although teh request had been imported. These had to be removed one by one using -> tp delfrombuffer SID (paramsettings path) <- at OS level or by selecting the request in the import queue and selecting delete.

However this solution, strangely enough only could remove request by request and not a sequence of requests. For example:

When deleting 3 request by selection block and afterwards a refresh of the import queue was made, only the 1st request selected had been deleted from buffer, the other 2 reappear ( these requests were only in buffer and were inconsistent so no data or cofile). the same happened at OS level using tp delfrombuffer, after executed 3 tp delfrombuffer with 3 different request, after a refresh in STMS queue the last 2 reappeared. Meaning the solution was tp delfrombuffer -> refresh import -> tp delfrombuffer -> refresh and so on... Of course a script was the better solution in this case.

A tp cleanbuffer DID NOT resolved this because of the inconsistent requests!