Ordner im IFS leeren - wie machbar?

[Fuerchau]

Das ist natürlich korrekt.
Der Unterschied ist lediglich, dass QSH einen eigenen Job startet, der Direktbefehl über API's geht.

Ich nehme halt noch oft QSH, da ich das schon seit V4 mache und ich mir die vielen neuen Befehle einfach nicht merken kann. Im Ursprung kam ich ja aus der Unix-Welt.

[Dominic K.]

OK dann weis ich bescheid! Danke für die Hilfe : )
Auch ich tendiere dann zur QSH Lösung, da bin ich fit und muss mich nicht in neue System i Eigenarten einarbeiten ; D

[hel400]

Sorry falsch ausgedrückt. Mir war klar das ich mit deinem Beispiel nur die Dateien in dem Ordner lösche. Was mich interessiert ist wenn man ausversehen beim DEL OBJLNK nur z.B. "/" angibt ob man dann auch wie mit "rm" einfach ohne Nachfrage das IFS leerräumt. Falls dem so ist gibt es dann ja keinen Unterschied zu "rm" außer dass das eine eine über QSH passiert und das andere über CL

Ok, dann haben wir hier den Unterschied vom CMD zum QSH.
Beim DEL werden nämlich nur die Files im angegebenen Directory-, aber keine Subdirectories gelöscht

[BenderD]

Kurze Frage dazu, ist die Gefahr damit das "/" zu löschen genauso hoch wie mit qsh? Will das nicht einfach probieren.

... wer sowas mit QSECOFR/root Berechtigung macht, dem ist eh nicht mehr zu helfen.

D*B

[Dominic K.]

... wer sowas mit QSECOFR/root Berechtigung macht, dem ist eh nicht mehr zu helfen.

D*B

Wie kommst du auf die QSECOFR Berechtigung?
Ich habe keinen Zugang zum QSECOFR und selbst wenn würde ich einen Teufel tun und damit testen....

@hel400: Danke für dieAufklärung.

[Fuerchau]

QSECOFR-ähnlich reicht da auch schon.
Mit *ALLOBJ alleine schaffst du das auch. Und wenn ERP-Anwendungen angeblich ohne *ALLOBJ nicht auskommen und auch noch als Gruppenprofil herhalten, hat es letztendlich jeder.
Und wer dann weiß wie es geht, kann dann auch noch *SECADM verwenden auch wenn er das recht nicht hat.

[BenderD]

Wie kommst du auf die QSECOFR Berechtigung?
Ich habe keinen Zugang zum QSECOFR und selbst wenn würde ich einen Teufel tun und damit testen....

@hel400: Danke für dieAufklärung.

... Du hattest doch die Befürchtung, dass ein rm / die gesamten Daten aufrubbelt!!! Bei korrekter Berechtigungsvergabe und Vorgehensweise passiert da genau n i x !!!

[Fuerchau]

"Bei korrekter Berechtigungsvergabe..."
Hast du da ernsthaft schon mal produktive Systeme gesehen, die sich darum gekümmert haben?
Ich meine damit keine Systeme, die du schon mal unter deiner Fuchtel hattest.

[Fuerchau]

Ist zwar Off Topic, aber eine kleine Geschichte zum Thema Berechtigung:

Einer unserer BI-Kunden hatte in einer Abteilung das Problem, dass sein Benutzerprofil wegen falscher Anmeldung disabled war. Da sein IT-Leiter in Urlaub war, gab es niemanden in der Firma, der das Profil aktivieren konnte. Somit wurde ich dann gefragt, schließlich hätten wir ja wegen BI einen Zugang zum System.
Dieser Zugang beschränkte sich aber tatsächlich als *USER auf wesentliche Funktionen.
Der übliche Weg, mit *ALLOBJ schien sogar verbaut zu sein.
Allerdings gab es ja auch noch das Gruppenprofil (APP-Profil).
Zwar hatte das Gruppenprofil kein *ALLOBJ, allerdings fand sich innerhalb der Gruppe eine weiteres Profil, dass dann die nötige *ALLOBJ-Berechtigung hatte. Da ich über das Gruppenprofil auch an diesem Profil Verwendungsrechte hatte konnte ich letztendlich per QSECOFR das eigentliche Profil wieder verfügbar machen.

[BenderD]

@korrekter Berechtigungsvergabe: Die kritischen Bereiche im / existieren bereits und gehören QSQCOFR oder QSYS und sind korrekt eingestellt. Da bleibt nur die korrekte Vorgehensweise und auch das ist einfach: Keine Spielereien mit QSECOFR, root und äquivalenten Benutzern (deshalb mein Hinweis!).

@Off Topic: die größten Scheunentore findet man meist, wenn man mal nach Objekten sucht, die QSECOFR gehören, adopted Authority verwenden, Berechtigung weitergeben und was die dann so aufrufen...

D*B