CPF33E2 bei Aufruf API QSPCRTSP (nur im Batch)

[aku]

Hallo,

wir haben ein Programm zum Duplizieren eines Spools.

Ein Spool von User ABC soll in eine andere OUTQ kopiert werden.

Im Batchfall (aufgerufen von User XYZ) bekomme ich die Fehlermeldung CPF33E2: "Wert ABC für Spool-Dateiattribute in der relativen Position 58 ungültig".
Ergebnis: Spool nicht kopiert!

Interaktiv aufgerufen (unter User XYZ), läuft alles ordnungsgemäß durch und der Spool ist kopiert. In der Ziel-OUTQ steht er auch mit User ABC.

Wenn ich per Debug im obigen Batchaufruf den Zieluser für die Kopie von ABC auf XYZ ändere, klappt es auch im Batch.

Woran kann das liegen?

Bin für jede Idee dankbar.
Aku

[Fuerchau]

Ggf. könnte es an der aktuellen Aufrufhierarchie liegen, dass im Dialog ein Programm im Stack liegt, dass ggf. unter Eignerberechtigung läuft und somit Zugriff auf ABC hat.
Im Submitfall fehlt dieses Programm und somit auch die Berechtigung.

Du könntest dein Kopierprogramm unter einem User (Eigner) laufen lassen der die nötige Berechtigung mitbringt.

[aku]

Vielen Dank für die super schnelle Antwort!

Das Kopierpgm hatte bereits Eigner QSECOFR aber "nur" UseAdpAut(*YES) für USRPRF(*USER). Das habe ich in *OWNER geändert. Jetzt funktioniert es. Lösung des Problems habe ich ersteinmal!

Aber die ganze Situation leuchtet mir nicht ein:

LibAlterPgmStand : funktioniert im Batch (MIT USRPRF(*USER)!)
LibNeuerPgmStand : funktioniert nicht im Batch bei USRPRF(*USER).

Testweise habe ich das PgmObjekt von alt nach neu kopiert. Bekomme aber denselben Fehler wie im neuen Pgm. Das deutet ja auf den Pgm-Stack hin.

Pgm-Stack ist aber "derselbe" für alt/neu. Habe alle Pgms des Stacks in beiden Libs geprüft. Keine Unterschiede in punkto AdoptedAuthority/User. Alt kopiert anstandslos.

Kann ein Pgm, das nicht mehr im Stack zu sehen ist, die Berechtigungsweitergabe stören? (ja, ich weiß, wir arbeiten auf der AS400 und nicht auf einem PC ;-) )

[Fuerchau]

Manchmal macht man sich einfach zu viele Gedanken, es läuft doch;-).

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