Profile Parameter - Lock for Login (System Copy)

[Private_Member_19084]

Hi experts,

is there a profile parameter which protects the system for login and only allows DDIC to login? Or a specified user?

I want to have this for system-copy.

I already know the report RDDITLCK, but I want to have a profile parameter.
Because we will copy prod to qual system.

And durring the copy-progress the system will automatically startup already.
Therefore I want to have a profile-parameter, which I can set in target system already before copy-process.

And the report I can only execute when the system is up.

And so I am not 100% avoiding, that a user is already logged in.

(for sure, I can not execute the report in prod system before starting the copy).

[Reagan · Accepted solution]

You can consider locking the users from the database level.

You can also make use of the TP command.

tp locksys <sapsid>

[former_member185954 · Accepted solution]

I am a slow typist

[Private_Member_19084]

as tp (un)locksys didn't work 100% I will do the copy as 1st suggested way.

Stop before starting and after starting login directly and log with Report RDDITLCK.

[Former Member]

Hi Christian,

Some SAP system has t-code EWZ5, you can set-up the t-code with DDIC, SAP*, system user IDs and any other IDS that you don't want to lock, as "euro administrator". Once the system is up, you can login immediately and lock quickly in seconds.

Thanks,

Kavitha Rajan.

[Private_Member_19084]

I am a bit confused now.
I tried it with 2 systems.

For one it did work for not.

I've executed from /trans/bin directory

tp syslock <SID> pf=<TP .PFL>

And I got return

This is tp version 380.18.95 (release 721, unicode enabled)

tp finished with return code: 0

meaning:

  Everything OK

However, the system isn't locked. Any ideas why?

[Reagan]

>>tp syslock <SID> pf=<TP .PFL><<

The command is wrong. It should be locksys and not syslock.

[Private_Member_19084]

Oh sorry, however I used "locksys".

[former_member185954]

Hello Christian,

Have a look at :

209652 - Buffer synchronization - tp locksys or tp unlocksys

As I mentioned earlier, not enough documentation is available as to how ti works, so maybe you have an issue that is documented in the note above(although this note is pretty old).

Regards,

Siddhesh

[Private_Member_19084]

But does anybody know where tp locksys is locking the users?

Because I really would prefer if I can execute the copy process without interrupting before startup.

So the DB statistics refresh a.s.o. can also be finished durring night (e.g.).

[Reagan]

It depends on how you are doing the system copy. The TP lock system is a kernel functionality and it doesn't lock the users at the database level by modifying the USR02 table. (as far as I know). If you are doing a system copy using the backup and restore method then you should be able to lock the users at the DB level or use the tp command to lock the system after the database restore. If you are doing the system copy using the export and import method then you can make use of the sapinst parameter SAPINST_SET_STEPSTATE and set a breakpoint and have the system locked in the way you want.

Cheers

RB

[Private_Member_19084]

Hello Reagan,

so it sounds pretty good.
I will try this weekend and give feedback next week.

Thx a lot to everybody.

[Private_Member_19084]

Thx, so I try tp locksys.

But when can it be used?

Already before system is copied?
In other words, where will it be marked, that the user is not allowed to login?

Because if it is in SAP-Instance or SAP-DB itself it does not help, as this will be overwritten durring copy-process and so it will be gone.

kind regards

[Matt_Fraser]

I haven't tried tp locksys during a system copy myself, but in the modern SWPM-based system copy there is an option to "interrupt for manual activities before system start" or something like that. I have used this in the past to modify the instance profile to set rdisp/wp_no_btc to 0, for instance, so that all the released jobs from production won't run immediately on startup (I set it back as soon as I get a chance to login and deschedule all those jobs). I don't know if tp locksys would work at this point, or what effect it would have on the copy, but what's the worst that could happen? You have to repeat the copy? You have a good source file (backup or export), so you don't have to repeat that part, so it shouldn't take very long to repeat if this turns out not to work. So, I think you can experiment here fairly safely.

[former_member185954]

Hello Christian,

That's a good question, as Matt mentioned its an OLD option and newer tools present better options(perhaps), you could do it as Matt suggested, setup the batch to zero and run tp locksys.

to stop all batches as additional belts & braces you could also execute the report BTCTRNS1 in SE38 to suspend all batches in source, shut it down, take export/copy etc, start the target with exported content, do all your post process and then finally when you are ready execute the report BTCTRNS2 in se38

Regards,

Siddhesh

[Matt_Fraser]

Yes, that's the recommended procedure, to deschedule the jobs in the source system before export. However, in many "refresh" scenarios where PRD data is used to overwrite a QAS system, there isn't a reasonable option to stop all the jobs in production. This is especially true if you're trying to get a point-in-time snapshot in the past (using the backup/restore method), say for a payroll exit or something like that. So, you need a way to stop the jobs from executing in the target without having been able to affect the source.

[Private_Member_19084]

Hello Matt,

I am doing the same.

However, I already rdisp/wp_no_btc to 0 when target system is still running (old version).

So I can use RZ10 for changing the parameter.

And as for the copy (DB REFRESH/MOVE option in SWPM) the old profile files will be used the change is also valid for the new target system.

So you don't have to set the "interrupt" parameter.

BTW, I do exactly the same to delete jobs like "EMail sending jobs, EDI_Jobs".

Which brings me to the next item.
You now there are also RFCs and EDI which I have to clean first.

Therefore it is important to avoid that users get logged on.

[Private_Member_19084]

Hello Siddesh,

yes you are right. But as mentioned, EMail job is running every 5 minutes.
And therefore the risk is to high that it sends mail out of the system.
Therefore I prefer the system-parameter.

[former_member185954]

Hello Christian,

tp locksys and unlocksys commands are still used implicitly by SUM tool during upgrades to lock system while its being upgraded, so its quite useful command.

While everyone knows you can use it, why nobody is able to tell you with confidence is because its poorly documented on what impact it has, what it will stop and what it will not stop.

I would leave that to trial and error.

If you are not comfortable, doing trial and error.

You could do the following roughly

- Disable Email Node in SCOT

- Disable/clear queues

- Execute BTCTRNS1 in SE38

- Double check all jobs in SM37 to ensure all of them are in suspended state.

- Lock all users except DDIC

- import/restore the source onto target

- setup batch params to zero

- start target sap system

- carry out post processing after system copy (unlocking key system users as necessary)

- Carry out checks

- Unlock all users

- Execute BTCTRNS2 in se38

- Enable Email Node in Scot

- Enable queues

Regards,

Siddhesh

[Matt_Fraser]

If the main concern is that the the SAPCONNECT job not send emails before you have a chance to manage it in the target system, that will be handled by setting rdisp/wp_no_btc to 0 before the first system start. The job won't run, because there won't be any available background work processes. The first time you login after system start, you'll get a short dump saying to check tcode SICK, but this is just because the system will complain that it needs at least 1 BTC work process to operate properly. Then you go into SM37 and deschedule (either with BTCTRNS1 as Siddhesh suggests, which is a fine method, or manually by selecting the jobs and selecting Job... Released->Scheduled) the jobs you don't want to run (in fact, initially select and "unrelease" all of them). Then you import and edit the system profiles and set the number of batch processes back to a normal number and restart the system.

[Private_Member_19084]

Hello Matt,

I already use this way.

But it is not just this.

Also RFCs which might be executed by Users, Content-Server Connections, EDI-Conntections, ...

Therefore I want to avoid it till every connection is changed/clean.

[former_member185954]

I think in this thread we have explored all options of locking users, in my opinion, the easiest one is tp locksys , its now time to implement some of them in a planned manner.

Sometimes a non-technical method such as informing users that

'please don't login as you may corrupt your data if you login'  can be very effective

Good Luck !

Regards,

Siddhesh

[Matt_Fraser]

SM02 system message is usually effective for this.

[former_member185954]

Hello Christian,

You can lock the system against dialog logons using a command at operating system level with <sapsid>adm user where executing the locksys allows only sap* and ddic to logon.

• tp locksys <sapsid>

• tp unlocksys <sapsid>

You can also use transaction SU10 to lock all users except DDIC in all clients manually.

But it requires a bit more planning as you will need to maintain lists of already locked users before executing SU10 Mass lock changes so that you don't unlock them by mistake.

Regards,

Siddhesh

[Matt_Fraser]

Siddhesh,

Heh, don't you just hate that, type out a good response, hit 'Post', and then you see someone else got in there just ahead of you?

Anyway, we use something like your SU10 method in our refreshed QA systems, mainly because we've had problems in the past with end-users accidentally getting into this system and thinking it is production, then weeks later complaining that they don't see the same data as their colleagues, and their updates don't seem to take effect for anyone beside themselves. So now we maintain a list of 'approved' QA users, and after the refresh we lock all dialog users except for the approved list. We also put up a permanent system message stating that it's QA and what the timestamp of the last refresh was, because don't you know, I get asked that a lot.

Regards,

Matt

[former_member185954]

Hello Matt,

No I don't hate it, infact I feel a bit embarrassed to post the same solution, when someone has already answered, I hate the fact that it took me so long to type

I would almost deleted my comment earlier

One of my colleague told me about another brilliant option to lock users using abap program or using database tools.

Lets say the DB is oracle, then I would login at OS level as ora<sid>

And do the following before system copy in the source system:

sqlplus "/ as sysdba"

update usr02.sap<sid> set ulfag=61 where uflag=0 and bname <>'DDIC' ;

commit;

And then do the following after system copy in the source and target:

sqlplus "/ as sysdba"

update usr02.sap<sid> set ulfag=0 where uflag=61 and bname <>'DDIC' ;

commit;

Since, sap routines are programmed to recognise any non zero positive integer in uflag as a locked record, it works like a charm and you don't have the hassle to remember who was unlocked or locked.

Regards,

Siddhesh

[Private_Member_19084]

Thx for this.

But this means, I also lock the prod system.
Therefoer I can also use the report RDDITLCK, but I don't want to lock the productive system