expertenaustausch > alt.* > alt.comp.sap-r3

Frank Brunske (02.09.2003, 00:16)
Hallo liebe SAP Gemeinde,

kennt jemand einen Weg, eifrige Berater am Wochenende auszusperren?
Jobs unter DDIC oder einem Batchuser sollten funtionieren.

Leider fällt mit da ausser "tp LOCKSYS SID" nicht ein. Gibt es bessere
Mechanismen? Habe leider auch im OSS nichts dazu gefunden.

Danke für Hinweise

Gruss Frank
Gerhard Fricke (02.09.2003, 07:33)
....
> kennt jemand einen Weg, eifrige Berater am Wochenende auszusperren?
> Jobs unter DDIC oder einem Batchuser sollten funtionieren.
> Leider fällt mit da ausser "tp LOCKSYS SID" nicht ein. Gibt es bessere
> Mechanismen? Habe leider auch im OSS nichts dazu gefunden. ....


Hallo Frank,

hast du dir mal die Transaktion EWZ5 angeschaut. Die ist von der
Euro-Umstellung übrig geblieben und erlaubt es, global eine beliebige
Anzahl User zu sperren und zu entsperren.

Eine zweite zu prüfende Variante wäre es, die Benutzerkonten im
NT-Netz für bestimmte auswärtige User zeitlich einzuschränken. In
wieweit dies bei deinem Problem hilfreich ist, sollte Eure PC-Truppe
sagen können.

Viel Erfolg

Gerd
muhch (02.09.2003, 07:50)
"Frank Brunske" <guppelguppel> wrote in message news:p031
> Hallo liebe SAP Gemeinde,
> kennt jemand einen Weg, eifrige Berater am Wochenende auszusperren?
> Jobs unter DDIC oder einem Batchuser sollten funtionieren.
> Leider fällt mit da ausser "tp LOCKSYS SID" nicht ein. Gibt es bessere
> Mechanismen? Habe leider auch im OSS nichts dazu gefunden.
> Danke für Hinweise
> Gruss Frank


Hallo Frank

Im Rahmen der Euro-Umstellung wurde ein sehr nützliches Tool
ausgeliefert, hier kann man einzelne Benutzer sperren bzw. wieder
freigeben. Die Transaktion dazu lautet "EWZ5". Wir haben ein 4.6C
System und dort ist diese Funktion auf alle Fälle vorhanden.

lG
Christian Mühlthaler
kolleter (02.09.2003, 08:37)
"Frank Brunske" <guppelguppel> wrote in message news:p031
> Hallo liebe SAP Gemeinde,
> kennt jemand einen Weg, eifrige Berater am Wochenende auszusperren?
> Jobs unter DDIC oder einem Batchuser sollten funtionieren.
> Leider fällt mit da ausser "tp LOCKSYS SID" nicht ein. Gibt es bessere
> Mechanismen? Habe leider auch im OSS nichts dazu gefunden.
> Danke für Hinweise
> Gruss Frank


Hallo Frank,

probier mal die Transaktion EWZ5 ( Euro Tools ). Mit dieser
Transaktion kannst Du alle User die nicht gesperrt werden sollen als
Euroadmin Deklarieren. Alle anderen User werden dann gesperrt.
Beim Entsperren bleiben die Sperren, die vorher bestanden (
Falschanmeldung, durch Systemadmin usw. ) erhalten.
Jens Hoetger (02.09.2003, 13:25)
On Tue, 2 Sep 2003 00:16:26 +0200, "Frank Brunske"
<guppelguppel> wrote:

<snip... Viele User sperren...>
Hallo,
neben dem hier oft genannten EWZ5 gibt es auch die "Massenpflege"
SU10.
Achim (02.09.2003, 14:38)
Hallo Frank,

versuchs doch mal mit folgendem ABAP:
REPORT ZMANDANTENSPERRE.
* Copyright by Achim Medenbach,
* 15.04.1995
TABLES: T000.
*-----------------------------------------------------
PARAMETERS:

LOCK_PAR LIKE T000-CCTEMPLOCK DEFAULT ' ',
LOCK_MAN LIKE T000-MANDT DEFAULT '099'.
*-------------------------------------------------------------
* Change for other user *
IF ( SYST-UNAME = 'SAP*'
OR SYST-UNAME = 'DDIC' )
* --------------------- *
AND ( SYST-MANDT = '000' AND
LOCK_MAN NE '000' ).
SELECT * FROM T000 WHERE MANDT NE '000'.
IF T000-MANDT EQ LOCK_MAN.
T000-CCTEMPLOCK = LOCK_PAR.
UPDATE T000.
ENDIF.
WRITE :/ T000-MANDT, T000-CCTEMPLOCK.
ENDSELECT.
ELSE.
WRITE:/ 'Junge, das darf doch nicht jeder!'.
ENDIF.

"Frank Brunske" <guppelguppel> wrote in message
news:p031
[..]
Matthias Schawe (03.09.2003, 16:44)
"Frank Brunske" <guppelguppel> wrote in news:bj0ghv$48p$03$1
@news.t-online.com:

> Hallo liebe SAP Gemeinde,
> kennt jemand einen Weg, eifrige Berater am Wochenende auszusperren?
> Jobs unter DDIC oder einem Batchuser sollten funtionieren.
> Leider fällt mit da ausser "tp LOCKSYS SID" nicht ein. Gibt es bessere
> Mechanismen? Habe leider auch im OSS nichts dazu gefunden.
> Danke für Hinweise
> Gruss Frank


Hallo Frank,

ich habe hier auch noch einen Programmvorschlag:

REPORT ZSUSER06.

TABLES: USR02,
T9USRNSPER.

PARAMETERS: SPERREN AS CHECKBOX,
ESPERREN AS CHECKBOX.

TYPES: BEGIN OF IUSER,
BNAME LIKE T9USRNSPER-BNAME,
END OF IUSER.
DATA: USER TYPE IUSER OCCURS 10 WITH HEADER LINE.

DATA: GEFUNDEN(01).

IF ( ESPERREN EQ 'X' ) AND ( SPERREN EQ 'X' ).
WRITE: / 'Nur eine Option angeben !!!!'.
EXIT.
ENDIF.

IF ( SPERREN EQ 'X' ).

SELECT * FROM T9USRNSPER.
MOVE T9USRNSPER-BNAME TO USER-BNAME.
APPEND USER.
ENDSELECT.

SELECT * FROM USR02 .
GEFUNDEN = 'N'.
LOOP AT USER WHERE BNAME EQ USR02-BNAME.
IF SY-SUBRC EQ 0.
GEFUNDEN = 'J'.
ENDIF.
ENDLOOP.
IF GEFUNDEN NE 'J'.
MOVE 64 TO USR02-UFLAG.
MODIFY USR02.
WRITE: / 'Benutzer ', USR02-BNAME, 'gesperrt.'.
ENDIF.
ENDSELECT.
ENDIF.

IF ( ESPERREN EQ 'X' ).
SELECT * FROM USR02 WHERE UFLAG EQ 64.
MOVE 0 TO USR02-UFLAG.
WRITE: / 'Benutzer ', USR02-BNAME, 'entsperrt.'.
MODIFY USR02.
ENDSELECT.
ENDIF.

Vergiss dabei aber nicht die Ausnahmetabelle zu füllen. Ansonsten kann
sich keiner mehr anmelden :-)

Matthias
Wolfgang Janzen (03.09.2003, 19:14)
Matthias Schawe wrote:

> Hallo Frank,
> ich habe hier auch noch einen Programmvorschlag:
> [...]
> IF ( ESPERREN EQ 'X' ).
> SELECT * FROM USR02 WHERE UFLAG EQ 64.
> MOVE 0 TO USR02-UFLAG.
> WRITE: / 'Benutzer ', USR02-BNAME, 'entsperrt.'.
> MODIFY USR02.
> ENDSELECT.
> ENDIF.


Schlechter Vorschlag:
diese Aktion ist nicht revisionssicher.
Gleiches gilt leider auch für die Transaktion EWZ5 (Euro Tools).

Falls hier wirklich (von mehreren Leuten) ein Bedarf gesehen wird, so
macht diesen bitte visibel: schreibt einen Entwicklungsantrag. Ohne
"Business Case" (= Bedarfsnachweis) wird es schwer sein,
Entwicklungsaufwände zu begründen.

Gruß, Wolfgang

------------------------------------------------------------------------------
DISCLAIMER:
The opinions stated above are my own and not necessarily those of my
employer.
------------------------------------------------------------------------------
Frank Brunske (03.09.2003, 22:57)
Vielen Dank erst mal an Euch!
Ich werde mir morgen mal die EWZ5 anschauen.

Schön wäre eine Lösung wie: Freitag ab 22 Uhr werden alle user bis auf
einige rausgeschmissen.
Batches dürfen weiterlaufen. Ab Montag 8 Uhr darf wieder jeder auf das
System.

Insofern scheint mir euer ABAP Vorschlag einsetzbar zu sein.
Ich schaue mir das auf jeden Fall an!

Danke und Gruss von Frank
Matthias Schawe (04.09.2003, 08:01)
"Frank Brunske" <guppelguppel> wrote in news:bj5km7$cfq$01$1
@news.t-online.com:

> Schön wäre eine Lösung wie: Freitag ab 22 Uhr werden alle user bis auf
> einige rausgeschmissen.
> Batches dürfen weiterlaufen. Ab Montag 8 Uhr darf wieder jeder auf das
> System.


Moin Frank,

warum möchtest du denn Batches weiterlaufen lassen? Wenn ich keine User
auf der Anlage haben möchte weil ich Systemarbeiten mache, dann kann ich
auch keine Batches gebrauchen. Insofern muß die Lösung schon rabiater
sein. So nach dem Motto: Von Samstag Mittag 14:00 Uhr bis Sonntag Abend !
8:00 Uhr ist ein Arbeiten im System _nicht_ möglich. Bitte
berücksichtigen Sie das bei der Einplanung ihrer Batch-Jobs.

Matthias
Matthias Schawe (04.09.2003, 08:06)
Wolfgang Janzen <Wolfgang.Janzen> wrote
> Schlechter Vorschlag:
> diese Aktion ist nicht revisionssicher.
> Gleiches gilt leider auch für die Transaktion EWZ5 (Euro Tools).


Das ist sicherlich richtig, da es aber keine andere Möglichkeit gibt sich
der User zu entledigen, wird es so praktiziert. Falls jemand duch
Falschanmeldung gesperrt ist, wird zu diesem Zwecke vorher kurz einmal
die Tabelle USR02 durchgesehen, wer da schon mit dem Code 64 drin steht.
Da wir im Normalfalle keine User sperren, sondern per Datum ungültig
machen, können eigentlich nur Fehlanmeldung in der Tabelle stehen.

> Falls hier wirklich (von mehreren Leuten) ein Bedarf gesehen wird, so
> macht diesen bitte visibel: schreibt einen Entwicklungsantrag. Ohne
> "Business Case" (= Bedarfsnachweis) wird es schwer sein,
> Entwicklungsaufwände zu begründen.


Warum ist das nicht Standard? Systemarbeiten müssen eigentlich immer ohne
User im System erledigt werden. Oder sehe ich da was falsch.

> Gruß, Wolfgang

Gruß zurück, Matthias
Jochen Diehl (04.09.2003, 14:18)
Wolfgang Janzen <Wolfgang.Janzen> wrote:

> Falls hier wirklich (von mehreren Leuten) ein Bedarf gesehen wird,
> so
> macht diesen bitte visibel: schreibt einen Entwicklungsantrag. Ohne
> "Business Case" (= Bedarfsnachweis) wird es schwer sein,
> Entwicklungsaufwände zu begründen.


Auch immer gern gesehen wäre die Möglichkeit, User nur auf bestimmten
App-Servern zu erlauben ("MLP-Syndrom"), z.B. weil man auf dem DB
Rechner nur eine kleine Instanz für administrative Zwecke installiert
hat. Natürlich kann man das auch selber programmieren, aber im
Standard wäre das auch sehr praktisch, da es doch ein tiefer Eingriff
in das System ist.

Andere Frage: Ab wann gilt denn der Bedarfsnachweis? Wenn mehr als n
(unterschiedliche) Kunden denselben Entwicklungsantrag gestellt haben?
Wie groß muß n sein?

Grüße
Jochen
Raphaela Corall (05.09.2003, 08:51)
"Jochen Diehl" <djspamsux> schrieb:
> Wolfgang Janzen <Wolfgang.Janzen> wrote:
> Auch immer gern gesehen wäre die Möglichkeit, User nur auf bestimmten
> App-Servern zu erlauben ("MLP-Syndrom"), z.B. weil man auf dem DB
> Rechner nur eine kleine Instanz für administrative Zwecke installiert
> hat. Natürlich kann man das auch selber programmieren, aber im
> Standard wäre das auch sehr praktisch, da es doch ein tiefer Eingriff
> in das System ist.


Läßt sich das nicht lösen, indem Anwender nur über Logon
Group aufs System kommen? So eine "Notinstanz" nimmt man in
die Logon Group nicht auf, die User kriegen die
SAPLogon-Version ohne Eingriffsmöglichkeit, die normalen
Appl.server werden runtergefahren, und Ruhe ist.

Eine andere Denkvariante wäre, auf den normalen Instanzen
auf Betriebsarten umzuschalten, die keine Dialogprozesse
haben. Dann kann sich keiner anmelden, und Admin hat
Batchprozesse satt zur Verfügung.

> Andere Frage: Ab wann gilt denn der Bedarfsnachweis? Wenn mehr als n
> (unterschiedliche) Kunden denselben Entwicklungsantrag gestellt haben?
> Wie groß muß n sein?


Die Transaktion aus der HWU hab ich schon ganz oft genutzt,
wenn wir Anwender für Sonderaktionen aus Testsystemen
aussperren wollten. Das reicht aber wohl nicht als Bedarf
für einen Entwicklungsantrag, weil da die von Wolfgang
erwähnte fehlende Revisionssicherheit keine Rolle spielt
(auch wenn ich es ziemlich dreist finde, daß die SAP für die
HWU ein nicht revisionssicheres Werkzeug gebaut hat).

Gruß
Raphaëla
Jochen Diehl (05.09.2003, 09:01)
Raphaela Corall <rc> wrote:
> Läßt sich das nicht lösen, indem Anwender nur über Logon
> Group aufs System kommen? So eine "Notinstanz" nimmt man in
> die Logon Group nicht auf, die User kriegen die
> SAPLogon-Version ohne Eingriffsmöglichkeit, die normalen
> Appl.server werden runtergefahren, und Ruhe ist.


Nee, das hilft nicht, weil es immer einige gibt, die Server Selection
im SAPLogon wählen. Und wir hatten schon den Fall, daß es auf der
Hauptinstanz auch Dialog-Prozesse geben mußte.

Jochen
Tobias Broeckelmann (05.09.2003, 10:39)
"Jochen Diehl" <djspamsux> schrieb
> Nee, das hilft nicht, weil es immer einige gibt, die Server Selection
> im SAPLogon wählen. Und wir hatten schon den Fall, daß es auf der
> Hauptinstanz auch Dialog-Prozesse geben mußte.


Warum nutzt ihr dann nicht den SAPLogon-Pad? Da kann man keine
Server-Selection durchführen.

Gruss
Tobias

Ähnliche Themen