View Full Version : CPF33E2 bei Aufruf API QSPCRTSP (nur im Batch)
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
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.
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 ;-) )
Manchmal macht man sich einfach zu viele Gedanken, es läuft doch;-).
Hat sich vielleicht im SBMJOB-Aufruf irgendetwas geändert, d.h. der Job wird im Batch unter einem nicht berechtigten Benutzer ausgeführt?
Birgitta
@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?
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
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.
Die JOBD hat übrigens keine Berechtingungseigenschaften.
... es sein denn, sie bringt unter dem Parameter USER einen mit...
Der ja laut Fehlerbeschreibung überschrieben, bzw. nicht verwendet wird.