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

[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...

[Fuerchau]

Was soll uns das nun sagen ?
Wird dein Programm denn dann überhaupt aufgerufen ?

Beim SBMJOB kannst du gezielt einen Jobnamen vergeben SBMJOB JOB(MYJOB) ...
Wenn du dann in deinem CLP einen DSPJOBLOG OUTPUT(*PRINT) einbaust, kannst du den Job per WRKJOB MYJOB schnell finden, da er auf Grund des Spools im System bleibt.

[votch]

Leider nicht, da es wegen fehlender Berechtigung schon bei einem anderen SBMJOB zum Abbruch kommt(evtl. werden noch weitere SBMJOB's gemacht, was ich nicht einschätzen kann). Auf den Echtsystemen läuft es jedoch, da es leider unterschiedliche Programmstände innerhalb des Vorsystems zwischen Echt- und Testsystem gibt. Dort läuft kein SBMJOB, sondern eine Verarbeitung per DTAQ und SBS.

D.h. für mich, es hat nicht viel Sinn, momentan in meinem Programm etwas zu ändern, bevor ich nicht wieder den gleichen Stand auf beiden Systemen habe...

[votch]

Hallo,

ich habe nun wieder den gleichen Stand auf Test- und Echtsystemen. Mein Programm hat auch funktioniert, nach den gemachten Änderungen wie von fuerchau vorgeschlagen.

Leider mußte ich aber doch wieder alles umschreiben. Es wird aus "Sicherheitsgründen" gewünscht, dass die Verarbeitung in 2 Schritten mit 2 Benutzern durchgeführt wird.

D.h., statt dem SBMJOB befülle ich nun aus dem Programm eine neu angelegte DtaQ. Dann habe ich ein Subsystem angelegt, in welchem ein Autojob läuft, der die DtaQ ausliest und das entsprechende Programm(welches vorher beim SBMJOB aufgerufen wurde) aufruft.

Vielen Dank noch mal an Alle für die Tipps,
votch