Lock DDIC user but keep the RDD* jobs working.

[Former Member]

A audit report have suggested that we lock user DDIC, and re-schedule

the jobs running under this user -

RDDDICL3

RDDEXECL

RDDFDBCK

RDDIMPDP

RDDMNTAB

RDDVERSL

However Im unable to find information on how to do this, these jobs are

usually triggered and not scheduled to run at specific times.

SAPHELP also suggest to lock the DDIC user and reschedule the jobs

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/3e/cdaccbedc411d3a6510000e835363f/content.htm

but dosent mention how to actually reskedule the jobs under another user. SM37 is of no use here, since the jobs are triggered.

RDDIMPDP as a example, is scheduled by RDDNEWPP program, but according to all

information this should be done using DDIC in client 000, which will

then reschedule the RDDIMPDP to run as user DDIC.

Is the procedure simply to run rddnewpp as another user with sap_all

and sap_new ?? would this reskedule all the RDD* jobs to run under this

new "SAPBATCH" user ?

[Former Member]

I am also trying to solve this same "issue". How do we change the background user for all RDD* jobs that are currently run under DDIC,

so according to SAP's recommendation, we can lock the account?

John

[Former Member]

I would think that you can change the step users and leave the scheduler as DDIC (this does not prevent you from locking the ID),

or just delete the whole job and run it in each client where you want transports released from or imported into as the "to-be" import user,

and then change it to a SYSTEM user afterwards.

Note that there still are sy-uname = u2018DDICu2019 checks present in the RDD* programs, however these relate to upgrades and special u201Cclean-upu201D

programs such as RDDCLTAF or repair programs like RDDENQAC.

Also take note that the documentation is from release 7.00 Enhancement Package 1 .

In lower releases it is different.

Cheers,

Julius

[Former Member]

well

RDDIMPDP can easily be changed since this found in sm37 as a event triggered job, but as to the rest of the listed jobs all with RDD*, these are not there, and I believe that these are triggered by the system in certain events , like when importing a transport, og applying a support package or similar...

I guess these jobs cannot be changed ?. but DDIC must be re-activated in such cases ?

[Former Member]

Hi Kim,

I don't see any reason why the reports you have mentioned above have to run under DDIC. If they are being submitted by other programs, then those programs may or may not determine whether the current user or a fixed user is used (to open a step in a job), but I don't see any evidence of the latter for DDIC.

> but DDIC must be re-activated in such cases ?

Sorry, I don't understand this. Perhaps you meant to ask whether during upgrades, the user DDIC should be unlocked and it's authority to perform the upgrade restored? Yes.

Basically, just because you see DDIC running import or collector jobs in SM37, does not mean that it has to be DDIC.

Cheers,

Julius