R3AR3 and SMOFRSTAT

[Former Member]

Hi folks,

I try to do an initial load on the country master to sync systems but the load remains waiting in r3am1 with info "No processes, see note 429423". This has been discussed here and in SAP notes as well.

Now, with regular monitoring tools I fail to identify any processes running and exceeding the total number set in MAX_PARALLEL_PROCESSES (default 5).

Especially, when I look into transaction R3AR3 I do not see any process running. But when I check table SMOFRSTAT I find 5 records with status 'R'.

I guess those entries, while not shown in R3AR3, are responsible for the excess of 'processes'.

Does someone of you maybe have an idea how such bad records get into the system and if there's a standard way to visualize and later get rid of them?

(Or maybe, that my assumption is wrong at all?).

cheers, anton

[rohit_sharma2 · Accepted solution]

Hello Anton,

The maximum number of loads and requests that can be processed simultaneously is defined in the table SMOFPARSFA under  the MAX_PARALLEL_PROCESSES..The hierarchy in order of preference is initial load, request load, and then SDIMA.

There's no harm in updating the MAX_PARALLEL_PROCESSES from 5 to 10(or even 15 if your settings allow it).

For the rogue entries you see in SMOFRSTAT, just check the date these request loads were initiated.

If they're very old and there's no associated queue you can find for them in CRM/ECC you might as well set their status to DONE(after editing the table manually).

Regards,

Rohit

[Former Member · Accepted solution]

Hi Rohit,

thx for your input.

I already increased MAX_PARALLEL_PROCESSES which resulted in more waiting rogue SMOFRSTAT-requests to pick processes and exhaust the maximum and keep running as well.

I checked the dated those entries were initiated and they are all older. Interesting about them is the fact that their REQNAME cannot be found in the definition table SMOFRQHD, and I assume that is the reason why they do not show up in tx. R3AR3 and therefore cannot be cancelled in a regular way.

Remains the question where they are originating from ...

anton

[rohit_sharma2 · Accepted solution]

Hello Anton,

That's strange. Unless the requests were hard-deleted(via code or manually) from the header table I don't see a reason as to how this could have happened.

Now for the solution to your problem, you might have to remove all R3AR* queues in SMQ1 and SMQ2 transactions on both CRM and ERP side. But exercise due caution before deleting these R3AR* queues and check if some of these have been initiated lately.

Then reset their statuses in SMOFRSTAT manually.

Then retry.

BR,

Rohit

[Former Member · Accepted solution]

Hi Rohit,

thx again for your valuable input.

From the bad requests' respectiv start times I assume they were created by a job thoug I didn't find one in the system for that times. So I assume it must be initiated by solution manager or something, Got to clear that out still.

Anyway, as you suggested, I set the runnin and waiting requests in SMOFRSTAT to DONE and started my download again - worked like a charm.

regards, anton

[former_member189549]

Hello Anton,

Please check  the maximum number of parallel initial loads using the
MAX_PARALLEL_PROCESSES parameter in the SMOFPARSFA table. The standard
value in the 'Param. Value' field is 5.

Also check note  1794220.

thanks

Willie