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

[votch]

Hallo,

wenn im Vorsystem ein Auftrag abgeschlossen wird, rufe ich per SBMJOB ein Programm auf, welches anhand der AU-Nr. und ein paar weiteren Feldern zusätzliche Daten ermittelt und diese im Endprinzip auf einem Win-Server ablegt. Die Verarbeitung steht und mit meinem Benutzer werden die Daten auch korrekt und zum richtigen Zeitpunkt aus allen möglichen Umgebungen ermittelt.

Wenn ich dies aber jetzt mit der Berechtigung eines Sachbearbeiters mache, funktioniert das nicht. Da wird nicht einmal der SBMJOB ausgeführt(auch nicht wenn ich dort einen Benutzer mit entsprechender Berechtigung hinterlege). Deshalb muss ich die Verarbeitung irgendwie splitten.

Mein erster Gedanke jetzt ist, dass ich statt dem SBMJOB nun die Felder in eine Datei oder DTAQ schreibe und nebenbei ein Programm läuft(unter einem berechtigten User, evtl. über JOBSCDE oder SBS), dass die DTAQ(Datei) ausliest und den Rest der Verarbeitung(Erstellen Datei, FTP usw...) macht.

Gibt es für das Problem evtl. eine elegantere/einfachere Lösung? Hintergrund ist der, dass ich die programme irgendwann vom Testsystem auf mehrere Echtsysteme übertragen muss und so viele zusätzlichen Fehlerquellen und unnötigen Ballast wie möglich(z.B. Vergessen/Unterschiede bei SBS/DTAQ usw...) ausschliessen möchte.

Vorab schon mal vielen Dank für alle Tipps.

votch

[cbe]

Hallo votch,

warum wird der SBMJOB nicht ausgeführt? Was sagt denn das Joblog?

Ich könnte mir vorstellen, dass das UsrPrf xy, welches Du beim SBMJOB angibst, von den Sachbearbeitern nicht verwendet werden darf?
(EDTOBJAUT xy *USRPRF)


Eine DTAQ finde ich persönlich etwas unhandlich. Ich finde ein Statusfeld in einer Verarbeitungsdatei praktischer, vor allem in der Test- und Überwachungsphase.

Aber den SBMJOB sollte man doch auch ans laufen bekommen...

Gruß, Christian

[Fuerchau]

Da würde ich doch mal eher sehen, warum der SBMJOB nicht startet bevor man da was umständliches macht.
Das Joblog gibt hierzu nähere Hinweise.

Ggf. muss dein Programm nur mit USRPRF(*OWNER) erstellt werden.

[votch]

hallo cbe,

das problem ist, dass ich selbst keine Berechtigung habe um Aufträge abzuschliessen, deshalb konnte ich dass nur bei einem Kollegen(qpgmr) prüfen. Der SBMJOB ohne User funktionierte aber der mit leider nicht. Bei den Sachbearbeitern funktionierte beides nicht. Ich denke mal, dass das aber irgendwie vom System abgefangen wird mit dem user beim sbmjob, sonst könnte ja jeder irgendwie die berechtigungen umgehen, wenn er da einfach einen user mit berechtigung angibt(man braucht ja nicht einmal ein Paßwort).

Im joblog der Sachbearbeiter fand ich nur eine fehlermeldung für ein programm, dass viel weiter vorne in der verarbeitung läuft, aber keine näheren Details zum eigentlichen Problem. Ich hab den Joblog auch ein paar Mal durchforstet, aber weder eine Fehlermeldung gefunden, noch lief irgendetwas auf MSGW oder ähnliches. Es wurde scheinbar einfach nur nichts gemacht. Das habe ich rausgefunden, da das Prg welches im SBMJOB laufen sollte noch nicht benutzt wurde seit der Umwandlung von mir, aber das in dem der sbmjob steht schon. Naja, ich hab leider auch keine Berechtigung, um was an dem User oder dessen Berechtigung für den SBMJOB zu ändern. Der steht auf *disabled(?was aber gem. einem kollegen normal wäre und trotzdem funktionieren würde?).

Kurz gesagt, ich muss entweder beantragen, dass dort was geändert wird an den berechtigungen(was länger dauern könnte) oder selbst das Ganze aufsplitten dass es läuft...

Naja, ich weiß halt nur nicht, was ich dort am besten und einfachsten machen kann. Vor allem gibt es ein paar Kollegen, die evtl. mal danach schauen/ändern müssen und ich weiß, dass die noch nie etwas mit SBS's bzw. DTAQ's gemacht haben.

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