DTAQ oder gibt es eine bessere Variante? --> Berechtigungsproblem

[votch]

Hallo fuerchau,

leider sieht man im Joblog gar nichts, hab ihn auch leider nicht mehr da bzw. kann auch keinen neuen erzeugen, da ich dafür einen AU abschliessen müßte. Wenn ich mich richtig daran erinnere, stand dort nur, dass ein CL(jedoch nicht dass, in dem der SBMJOB läuft) abbrach, aber keine Begründung warum, auch nicht bei den Details mit F1. Auch bei den Meldungen vorher im Joblog stand nichts, habe sie alle 2-3 Mal durchgesehen, weil ja normalerweise immer irgendetwas zum fehler darin steht...

Ich könnte mir vorstellen, dass irgendwie im Vorsystem alle Fehlermeldungen irgendwie abgefangen werden(so in der Art CPF0000) und deshalb auch meine Fehlermeldungen nicht im Joblog erscheinen.

Mein Programm habe ich auch einmal zum Test mit *user und einmal mit *owner umgewandelt, da ich aus der Beschreibung bei dem Parameter nicht wirklich schlau werde, ob bei owner beide die Berechtigung haben müssen oder es reicht wenn der owner die hat. Aber in beiden Fällen die ich testen ließ, lief es nicht und es kam keine meldung. Mir wäre es natürlich auch am liebsten, ich müßte da jetzt nicht noch irgendwas neues einbauen um die daten zu übertragen, da es erstens mal mehr aufwand ist, 2. zu mehr fehlern führen kann(wenn z.B. was in der DTAQ hängen bleibt oder ein SBS nicht läuft oder... und 3. es durch die zusätzliche DTAQ wahrscheinlich auch noch länger dauert...

[Fuerchau]

Beim SBMJOB mit USER benötigt der Aufrufer, das Gruppenprofil oder der Eigner des Programmes die Berechtigung am USER, sonst wird der SBMJOB eben abgewiesen.

Wenn das CLP, dass den SBMJOB aufruft diesen mit MONMSG abfängt, merkts natürlich niemand.
Solche Fehler werden aber in jedem Fall im Joblog protokolliert.

Je nach Sicherheit eures Systems kann das Programm, dass den SBMJOB durchführt per CHGOBJOWN auf den User unter dem der neue Job laufen soll geändert werden.
Per CHGPGM ... USRPRF(*OWNER) übernimmt das Programm die Rechte und kann dann auch mit USER submitten.

[votch]

Hallo fuerchau,

danke, gut zu wissen. mich wundert das Ganze auch etwas, dass ich nichts gesehen habe im Joblog. naja, nichts gesehen ist gut gesagt, das Vorsystem an sich produziert ja schon 30-40 Seiten Einträge. Naja, vielleicht hab ich es ja auch übersehen und es stand irgendwo dazwischen eine Nachricht, war ja schon spät gestern Abend. Ich selbst fange keine Fehler mit CPF0000 ab, aber dass einige Systeme das prinzipiell machen, damit keine Fehler beim user auftreten hab ich schön öfter gesehn.

Sicherhheitsstufe ist 40.

[Fuerchau]

Ich meine nicht die Sicherheitsstufe sondern euer Sicherheitsregelwerk.

Ein Joblog kann man auch in den Spool stellen und dann per WRKSPLF durchsuchen.

Bei jeder Meldung steht auch das Empfängerprogramm, du brauchst also nur deinen Programmnamen suchen um die Meldungen zu finden.

Ansonsten probier das halt mit CHGOBJOWN und CHGPGM, allerdings benötigst du dazu auch die Berechtigung am USER.

[votch]

Danke, das werde ich mal versuchen.

Könnte es sein, dass die umwandlung des Programms mit *owner überhaupt nicht wirksam war, falls das programm vorab schon einmal unter *user erstellt wurde unter V6R1 und deshalb das Programm trotz neuer Umwandlung unter *user lief obwohl nachträglich noch einmal mit *owner erstellt?

Bei der Umwandlung steht ja folgendes bei Parm USRPRF:
...Dieser Parameter wird nicht aktualisiert, wenn das Programm bereits vorhanden ist. Um den Wert für USRPRF zu ändern, das Programm löschen und unter Verwendung des korrekten Werts erneut umwandeln...

Naja, ich werde jetzt mal alle Objekte löschen und mit *owner neu erstellen. Dann werde ich das im programm mit chgobjown und chgpgm einbauen.

Mein Gruppenprofil und das des SBMJOB-Users sind fast identisch, beide QPGMR, Eigner ist *grpprf, Gruppenberechtigung *none, Art der gruppenberechtigung *private, Unterstützungsstufe bei mir ist advanced statt sysval bei sbmjob-user. Die Sachbearbeiter sind alle *user.

[Fuerchau]

Den CHGOBJOWN/CHGPGM brauchst du nicht einbauen, das ist eine einmalige Aktion wenn das Programm erstellt ist!

Du musst auch nur das Programm ändern, dass den SBMJOB durchführt.

[votch]

Hallo,

ich hab jetzt mal alle betroffenen Programme neu kompiliert mit *owner. Das mit dem chgobjown hat mich auf folgende Idee gebracht, falls das so jetzt noch nicht funktionieren sollte:

Das Programm wird ja von vielen Sachbearbeitern benutzt(evtl. auch gleichzeitig), leider nicht nur von einem und es müßte doch eigentlich funktionieren, wenn ich im ILE vor dem SBMJOB einen rtvjoba(oder einen rtvpgma) aufsetze, mir den aktuellen user ermittle und den Objekteigner mit diesem überschreibe oder funktioniert das nicht?

Gruß,
votch

[Fuerchau]

Tut mir Leid, aber dann hast du das Ganze nicht verstanden:

Du willst einen "SBMJOB ... USER(MYUSER)" machen.
Hierzu benötigst du die Berechtigung an MYUSER.

Das einfachste ist:
Mittels CHGOBJOWN nach der Programmerstellung den User MYUSER zuzuordnen.
Anschliessend mit CHGPGM ... USER(*OWNER) das Programm anpassen.

Nun hat das Programm, da es ja MYUSER gehört auch die Berechtigung von MYUSER geerbt.
Es darf daher den User MYUSER verwenden und unter diesem Namen submitten.

D.h., dein Programm submittet unter dem User MYUSER alle Anforderungen der Sachbearbeiter.
Über die JOBQ werden diese dann der Reihe nach abgearbeitet.

Wenn das gar nicht die Aufgabenstellung ist, solltest du dies noch mal klarstellen, denn ein SBMJOB ohne USER(XXX) ist immer erlaubt.

Das Problem liegt wohl in deiner Anwendung, die wohl den User irgendwo blockiert.

Ein CHGOBJOWN / CHGPGM ist zur Laufzeit des aktiven Programmes auf sich selbst nicht möglich!

[BenderD]

... die einfachste Lösung ist immer die Beste. Im beschriebenen Fall soll ein Programm aus einer Applikation von einem berechtigten Benutzer diese Apllikation im Hintergrund ausgeführt werden, damit dessen Bildschirm nicht blockiert wird. Ein klassischer Fall für einen SBMJOB, der eigentlich ohne alle Schnörkel funktionieren sollte. Also ist erst mal zu klären, warum das nicht geht und da gibt es das Joblog des interaktiven Jobs und gegebenen Falls ein Joblog für den submitteten Job - und genau dort steht drin, warum das nicht geht.

D*B

[votch]

Danke fuerchau für die genaue Erklärung, jetzt hab ich es verstanden. Sorry, stand gestern etwas auf dem Schlauch, zu lange gearbeitet...

Das sehe ich auch so, dass die einfachste Lösung die beste ist. Verstehe auch nicht, warum nichts im Joblog stand. Hab aber auch unter Zeitdruck da reingeschaut. Zwar 2 oder 3 Mal durchgesehen was im Joblog des Users stand aber nichts gefunden. Hatte auch mit wrksbmjob nachgeschaut, da stand auch nichts beim User. Hab auch geprüft, ob nicht noch irgendwo ein doppeltes Objekt stand, auf das evtl. zuggriffen wurde, aber nichts gefunden. Wenn ich mir das heute so überlege, müßte normalerweise dort was drin gestanden haben. Vielleicht sollte ich mal zum Augenarzt ;-).

Fakt ist nur, dass er bei mir als QPGMR ohne Sonderberechtigung die Daten richtig ermittelt wurden und in der Datei standen und auch auf dem Win-Server ankamen und bei dem User(Berechtigung weiß ich jetzt nicht, aber wahrscheinlich *user) wurde das Programm, welches submittet werden sollte nicht benutzt(hatte es vorher neu erstellt und Anzahl der verwendeten Tage war 0).

Mir drängt sich da jetzt aber auch noch ein ganz anderer Gedanke auf und zwar, dass dort evtl. irgendetwas ganz anderes gemacht wurde, so dass das Programm überhaupt nicht lief, oder dass bei dem User evtl. ganz andere Programme laufen als bei mir. Wäre ja nicht das erste Mal...

Das ist das Blöde, wenn man seine eigenen Programme nicht selbst testen kann und nicht einmal dem User dabei über den Rücken schauen kann, weil der irgendwo anders sitzt. Dann soll man noch was programmieren, was zwischen irgendwelchen Fremd-Anwendungen Daten austauschen soll, für die man selbst nicht berechtigt ist...

Am Anfang war in einem CL-Programm nur ein SBMJOB, ohne User, aber nichts passierte. Dann hab ich gedacht ich baue einen User ein, dann lief es nicht einmal mehr bei meiner Kollegin mit QPGMR-Berechtigung und ich hab nirgendwo was gefunden im Joblog. Da meine Kollegin das aber mit irgendeinem User gemacht hat, könnte es auch sein, dass dieser überhaupt nicht berechtigt war, den Auftrag abzuschliessen, bloß keine Felermeldung vom Vorsystem kam...

Danke an Alle, ich werde das am Montag noch einmal durchtesten und dabei mal ganz genau kontrollieren, was genau gemacht wird und was passiert.

Schönes Wochenende,
votch(der seine Berechtigungen am liebsten direkt über Menüs steuert und dafür sorgt, dass dadurch kein User an Stellen kommt, wo er nichts zu suchen hat...)

[votch]

Guten Morgen,

ich habe gerade nochmals einen Testlauf gemacht. Scheinbar habe ich die Fehlermeldung letzte Woche übersehen. Heute kam ein CPF1338 - Fehler im Befehl SBMJOB.

Wobei diese Meldung aber nicht aus meinem Programm kommt, sondern aus einem vorherigen Programm, welches ebenfalls einen SBMJOB macht. Dort scheinen 2 Objekte und eine OutQ zu fehlen, die es aber auf dem Echtsystem gibt...