clroutq mit der 14

[Robi]

Hi *all

Frage
Ein Kunde hat die 'wichtigen' Befehle in eine eigene Lib kopiert und dort allen die Berechtigung entzogen.
Diese Lib steht im Systemteil der Libl ganz vorne.

Z.B. ein CLROUTQ kann niemand aufrufen (cmd-line)

Nun hat versehentlich ein Anwender vor einer outq eine 14 gemacht und ... die outq leergefegt

1. Frage: Greift da die Liblist nicht?

Da bei Rel.Wechsel sich ja die Befehle ändern können, also die seperate Lib neu erstellt werden muß (dafür gibt es cl's)
frage ich mich, was dagegen spricht die 'orginal' Befehle zu schützen, also keine Kopieen zu machen.

Zugegebenermaßen war o.a. Vorgehen auch immer meine Empfehlung, ich hab's halt mal so gelernt.

2.Frage : Warum geschützte Kopien vordrängeln und nicht die Orginale schützen?

Besten Dank, schönes WE
Robi

[Fuerchau]

Ich denke mal, da WRKOUTQ mittles PNLGRP arbeitet, gibts 2 Möglichkeiten:
a) es wird das Kommando CLROUTQ qualifiziert aus der QSYS aufgerufen
b) es wird direkt der API-Aufruf zum Löschen der Spools aufgerufen

Berechtigungskonzepte sind immer so eine Sache.
Spätestens wenn ein User oder sein Gruppenprofil oder eine übergeordnete Aufrufebene mittels Vererbung *ALLOBJ hat, ist sowieso alles vergebens.

Im USRPRF kann man per LMTCPB die Kommandozeilenaufrufe sowieso beschränken.
Werden spezielle Aufrufe benötigt, kann man das schnell per SDA-Menü o.ä. auch regeln.

An der QSYS rumzudrehen ist immer mit Vorsicht zu genießen.

[Robi]

Hi, danke
Das Prinzip ist klar, der löschende User MUß ein cmdline haben
(Testabteilung)
Ich war nur so überrascht, das er das darf.

An der QSYS rumzudrehen ist immer mit Vorsicht zu genießen.

Kenn ich auch so, deshalb die Frage.

Scheint ein bischen so zu sein wie
"Nach dem Essen mindestens eine halbe Stunde nicht schwimmen gehen"
Kennt jeder, lernt jeder, kann niemand begründen und ist Lt. DLRG (die das so Unterrichten) völliger quatsch.

Noch ne Meinung?

[Fuerchau]

Prüfe den User ob nicht doch irgendwo *ALLOBJ vorliegt, das ist am häufigsten der Grund.

Und was das Schwimmen angeht gilt auch fürs Autofahren, Maschine steuern usw.:
Der Magen braucht zum Verdauen so viel Blut, dass dem Gehirn zuwenig Sauerstoff zugeführt wird so dass Müdigkeit und eingeschränkte Reaktionsfähigkeit vorliegt.

[Robi]

nein, das ist definitiv nicht so.
Er darf (fast) nix und war selber überrascht.

Außerdem ist das nachvollziehbar
Robi

[Fuerchau]

Fast nix heißt in diesem Fall *SPLCTL, sonst darf man nur seine eigenen Spools löschen (Eigenschaften der OUTQ).

[KingofKning]

Wobei ich ja immer wieder aufs Neue enttäuscht bin wie lange der zum Löschen einer Outqueue braucht.

Wenn ich mit 14 den Ganzen Inhalt löschen will könnte der doch eigentlich nach einer Sekunde wieder kommen und das eigentliche Löschen brav im Hintergrund machen. Villeicht was für Release V9R9..


GG

[Fuerchau]

Das hängt einfach nur von der Menge ab.
Du könntest an Stelle der 14 dann ja selber einen SBMJOB ... CLROUTQ starten, dann passiert das im Hintergrund, wieso dann erst auf V9 warten ?

[KingofKning]

Weil die 14 schneller eingetippt ist. Und selbst das mache ich nur wenn Jobs bockig sind und ich schnell ans Joblog will weil man die im Greenscreen nicht sortieren kann.
Also doch auf V9R9 warten. Und nein ich will dann nicht erst den Navigator starten.... Auch wenn der ja besser ist als sein Ruf....

GG

[holgerscherer]

Ein Kunde hat die 'wichtigen' Befehle in eine eigene Lib kopiert und dort allen die Berechtigung entzogen.
Diese Lib steht im Systemteil der Libl ganz vorne.

Ich wollte hier schon mit dem Lesen aufhören. Das tut ja weh... und da wundert man sich dann später, dass es bei Releasewechseln oder dem Umzug auf eine andere Maschine knallt.

Zumindest ein Doku-CL, das man aufrufen kann, sollte drin sein. Und nicht an Kopien arbeiten.

Gewisse Befehle, die mit Panelgroups oder anderen Methoden arbeiten, fühlen sich direkt in der QSYS wohl, egal, was man sonst so gesetzt hat. Das ist auch ganz gut so, damit man sich keine eigenen Sicherheitslücken ins Bein schnitzt.

Warum ein CLROUTQ so lange brauchen kann? Schon mal in die QSPL und deren Files geschaut, wenn Du 100.000 Spools auf der Maschine hast? Da sind viele kleine Teildateien drin, und Löschen auf der AS400 ist hier aus Gründen der Sicherheit und Speicherverwaltung etwas aufwändiger als das einfache entsorgen eines Filepointers.

-h

[Robi]

Ich wollte hier schon mit dem Lesen aufhören. Das tut ja weh... und da wundert man sich dann später, dass es bei Releasewechseln oder dem Umzug auf eine andere Maschine knallt.

Zumindest ein Doku-CL, das man aufrufen kann, sollte drin sein. Und nicht an Kopien arbeiten.

@Holger
auch wenn du weiter gelesen hast, hat die Konzentration da wohl nachgelassen

Es gibt (selbstverständlich) CL's die sowohl das kopieren und das schützen durchführen. Zum einen für die interne Doku, zum anderen um beim Releaswechsel nicht das Rad neu zu erfinden

Baldur meint hier

An der QSYS rumzudrehen ist immer mit Vorsicht zu genießen.

und so kenne ich das auch.

Du meinst also es ist besser direkt die Befehle der qsys zu schützen?

Kann ich (jetzt) auch nachvollziehen!

Etwas unsicherheit was 'richtig' ist bleibt.

@Baldur
k.a. ob die SPLCTL haben, muß ich Montag mal nachsehen.
Tatsache ist, das Sie keine (auch nicht die eigenen) Spools löschen dürfen.


Robi

[holgerscherer]

@Holger
auch wenn du weiter gelesen hast, hat die Konzentration da wohl nachgelassen

Das dürfte doch verständlich sein ;-)
Die CLs müsstest Du nach jedem PTF laufen lassen, da dort immer wieder was in der QSYS und co. geändert werden kann. Notfalls auch die Sicherheits-Einstellungen.
Und wenn man mit einer alten Kopie aus der QSYS arbeitet, kann das gewisse API-Aufrufe einfach an die Wand fahren. Ist also nicht beste Praxis.

-h