-
Hallo allerseits,
ist schon etwas älter dieses Problem, aber ich habe noch keine schöne Lösung dafür gefunden.
Kann man diese Nachricht mittlerweile unterdrücken, ohne den sendenden Job ändern zu müssen?
(Oder kann man einen Spool auf andere Weise kopieren mit *ALLDTA und gleichzeitig den Eigner ändern? Das macht SNDNETSPLF ja sehr schön, und genau das brauchen wir - nur die Nachricht nervt etwas.)
Wär klasse, wenn mir da jemand helfen könnte.
Gruß,
Christian
-
Der Trick hier ist, einen anderen User zu nehmen, der normalerweise nicht anmeldefähig ist.
Per API QSYGETPH/QSYSETPH kannst du den User umschalten, deinen SNDNETSPLF ausführen und den aktuellen User zurückschalten.
Die Nachrichten gehen ja an den sendenen User.
Alternativ:
An die OUTQ eine DTAQ hängen, mit einem Batchjob als anderer User diese DTAQ überwachen und von diesem dann SNDNETSPLF ausführen.
Es gibt allerdings 2 Probleme:
1. Die DTAQ empfängt nur RDY-Einträge und zwar jedesmal beim Wechsel in RDY.
2. Der SNDNETSPLF könnte etwas dauern, so dass RDY-Spools ggf. verschwinden (RDY und gedruckt) bevor du zur nächsten Überwachung kommst.
Hier hilft ggf. Parallelisierung, d.h., Überwachung mit mehreren Job's.
-
den User umschalten, das ist ja eine nette Idee!
Mal schauen, ob das in unser Berechtigungskonzept passt, nicht dass ich dadurch ein kleines Sicherheitsloch aufmache, aber das klingt gut...
Schonmal Danke für den Tip!
-
Die Betonung liegt ja auf "nicht anmeldefähig".
Man kann hierzu auch den "Application-User" verwenden, das ist der User, dem die Anwendung standardmäßig gehört und unter dessen Berechtigung die Anwendung läuft (per *OWNER-Programmen) .
-
klappt wunderbar, vielen Dank! Die Anwender werden sich freuen.
Wen es interessiert, hier der Code
Code:
DCL VAR(&HNDLORGUSR) TYPE(*CHAR) LEN(12)
DCL VAR(&USER0) TYPE(*CHAR) LEN(10)
DCL VAR(&USER1) TYPE(*CHAR) LEN(10)
DCL VAR(&HNDLSNDUSR) TYPE(*CHAR) LEN(12)
DCL VAR(&MSG) TYPE(*CHAR) LEN(160)
...
/* Aktuellen Benutzer ermitteln */
RTVJOBA USER(&USER0)
/* Handle für aktuellen Benutzer ermitteln */
CALL PGM(QSYGETPH) PARM(&USER0 '*NOPWD' &HNDLORGUSR)
/* Switchen auf den User */
CALL PGM(QSYGETPH) PARM(&USER1 '*NOPWD' +
&HNDLSNDUSR)
CALL PGM(QWTSETP) PARM(&HNDLSNDUSR)
CALL PGM(QSYRLSPH) PARM(&HNDLSNDUSR)
SNDNETSPLF FILE(&SPLF) TOUSRID((&USER1 &SYS)) +
JOB(&JOBNR/&JOBUSR/&JOB) SPLNBR(*LAST) +
DTAFMT(*ALLDATA)
/* Zurück switchen auf ursprünglichen User */
CALL PGM(QWTSETP) PARM(&HNDLORGUSR)
CALL PGM(QSYRLSPH) PARM(&HNDLORGUSR)
Berechtigungsbedenken habe ich auch keine mehr: Der &USER1 hat *SPLCTL-Rechte, und darf nur verwendet werden, weil das Programm als *OWNER eben diesen &USER1 hat.
Prima, nochmals danke!
Gruß, Christian
Similar Threads
-
By Squall in forum IBM i Hauptforum
Antworten: 0
Letzter Beitrag: 14-09-06, 09:20
-
By Freezer in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 13-01-06, 11:07
-
By SL in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 25-05-05, 07:44
-
By opeker in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 02-09-04, 08:37
-
By TARASIK in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 05-08-03, 08:33
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks