CPF33E2 bei Aufruf API QSPCRTSP (nur im Batch)

[B.Hauser]

Hat sich vielleicht im SBMJOB-Aufruf irgendetwas geändert, d.h. der Job wird im Batch unter einem nicht berechtigten Benutzer ausgeführt?

Birgitta

[aku]

@Baldur: Recht hast Du. Man möchte halt den Grund wissen, damit es nicht wieder passiert.

@Birgitta: Nein, ist derselbe User.

Habe gestern 2 Batchjobs mit dem User gestartet, einmal mit der alten Umgebung, einmal mit der neuen. Unterschiede in den Pgms gibt es schon, aber eher inhaltlich (derart "x = 1" statt "x = 2"). Nichts, was die Berechtigungsstruktur betrifft.

Wie kann ein und derselbe User mal die Berechtigung für einen anderen User haben, mal nicht (und zwar denselben anderen User!)???!!! Kann doch nur an den adopted authorities liegen!
Läuft der Aufruf von QSPCRTSP in beiden Fällen eigentlich über denselben QPRTJOB? Könnte es vielleicht hier ein Problem geben?

[B.Hauser]

Es geht an dieser Stelle beim Vergleich der Submit Jobs nicht um den User, der den Job absetzt, sondern eher um Einstellungen wie Job-Description oder der User der im Submit Job angegeben wurde.

Birgitta

[Fuerchau]

Authorities and Locks

Special Authority*SPLCTL. This authority is needed if you are creating a spooled file for another user.
Output Queue Authority
*USEOutput Queue Library Authority*EXECUTE

Natürlich kann man hier noch weiter graben. An irgendeiner der obigen Bedingungen muss es scheitern.
Irgend eines der Programme im Callstack muss eine andere Berechtigung mitbringen.

Die JOBD hat übrigens keine Berechtingungseigenschaften.

[BenderD]

Die JOBD hat übrigens keine Berechtingungseigenschaften.

... es sein denn, sie bringt unter dem Parameter USER einen mit...

[Fuerchau]

Der ja laut Fehlerbeschreibung überschrieben, bzw. nicht verwendet wird.

[aku]

Genau. Der SBMJOB passiert in beiden Fällen gleich (gleiche JobD, gleicher User).

Der Spool soll aus beiden Versionen in dieselbe OUTQ kopiert werden. Also kann doch auch die Berechtigung der OUTQ nicht der Grund sein.

Es gibt in den PgmInfos (DSPPGM pgm DETAIL(*ALL)) einen Wert der bei den Pgms unterschiedlich ist:

Niedrigstes Release für Programmausführung . . : V5R4M0
Umsetzung erforderlich . . . . . . . . . . . . : *NO
Umsetzungsdetail . . . . . . . . . . . . . . . : *COMMON (wo Kopieren funktioniert)

Umsetzungsdetail . . . . . . . . . . . . . . . : *COMPAT (wo es nicht funktioniert)

Kann das vielleicht rein spielen? Obwohl "Umsetzung erforderlich" auf "*NO" steht?

[Fuerchau]

Das könnte ggf. was sein, wobei die Beschreibung sich nicht auf Berechtigungen bezieht:
*COMPAT
Das Objekt ist mit der aktuellen Maschinenimplementierung
kompatibel. Das Objekt ist mit der aktuellen
Maschinenimplementierung kompatibel, und alle Funktionen, die das
Objekt benutzt, werden durch die aktuelle Maschinenimplementierung
implementiert. Das Objekt verwendet jedoch mindestens eine Funktion,
die von der allgemeinen Stufe der Hardware (Version, Release und
Modifikationsstufe), für die das Objekt erstellt wurde, nicht
unterstützt wird.

Dies würde nur zur Laufzeit ein Problem, wenn das Programm an diesem Code vorbeikommt.
Wobei ich mich da frage, wie der Compiler sowas generieren kann.
Dies hat aber nichts mit dem Aufruf des API's zu tun sondern nur mit der Ausführung des Programmes selber.
Ich habe wirklich keine Idee, warum die Berechtigung nicht akzeptiert wird.