SNDNETSPLF - Messages unterdrücken

[beeblebrox]

Hallo,

ich möchte mit SNDNETSPLF Spools in eine OUTQ für ein DMS kopieren. Das klappt testweise bereits einwandfrei, nur die Nachrichten stören etwas.
Gibt es eine Möglichkeit, diese für den Absender erst gar nicht generieren zu lassen?
Ein Blick auf die Optionen des Kommandos und Lesen der Beschreibung im CL-Manual haben mich nicht wirklich schlauer gemacht.
Schon mal vielen Dank für Tips.

Zaphod

PS: Evtl. könnte ich die Nachrichtenwarteschlange des Benutzers einfach auf *HOLD stellen und die Nachricht mit RMVMSG entfernen. Nur müsste ich anschließend wieder *BREAK setzen, falls das vorher so war. Wie kann ich den aktuellen Zustand rausfinden? Bei den Kommandos, die GO CMDMSG anbietet, habe ich nichts passendes gefunden.
Sorry, das waren jetzt gleich zwei Fragen auf einmal. ;-)

[kuempi von stein]

Hallo,

ich möchte mit SNDNETSPLF Spools in eine OUTQ für ein DMS kopieren. Das klappt testweise bereits einwandfrei, nur die Nachrichten stören etwas.
Gibt es eine Möglichkeit, diese für den Absender erst gar nicht generieren zu lassen?
Ein Blick auf die Optionen des Kommandos und Lesen der Beschreibung im CL-Manual haben mich nicht wirklich schlauer gemacht.
Schon mal vielen Dank für Tips.

Zaphod

PS: Evtl. könnte ich die Nachrichtenwarteschlange des Benutzers einfach auf *HOLD stellen und die Nachricht mit RMVMSG entfernen. Nur müsste ich anschließend wieder *BREAK setzen, falls das vorher so war. Wie kann ich den aktuellen Zustand rausfinden? Bei den Kommandos, die GO CMDMSG anbietet, habe ich nichts passendes gefunden.
Sorry, das waren jetzt gleich zwei Fragen auf einmal. ;-)

mhh...
zu 1) würde ich mal mit CHGJOB rumprobieren. da gibt es so parameter wie LOG/BRKMSG/STSMSG usw.
und 2) würde dann ja eh entfallen.

have fun

k.

[Fuerchau]

Da die SNDNET-Befehle asynchron über SNADS abgewickelt werden hilft das kurzfristige Ändern des Breakmodus überhaupt nicht. Dein CLP ist nämlich schneller fertig mit dem CHGJOB/SNDNETSPLF/CHGJOB als QSNADS mit dem tatsächlichen Senden.

Ansonsten kannst du den aktuellen Status mit RTVJOBA abfragen und per CHGJOB zurückändern.

[beeblebrox]

Vielen Dank an Kuempi und Fuerchau,

ich habe noch ein bisserl geforscht, was es noch für Möglichkeiten gibt, Spoolfiles zu duplizieren und auf www.iseriesnetwork.com das Tool CHGDUPSPLF (als CL-Sourcecode) gefunden. Hatte noch keine Zeit, die Compiler anzuwerfen, aber ich werde das die Tage mal ausprobieren.

Grüße
Beeblebrox

[cbe]

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

[Fuerchau]

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.

[cbe]

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!

[Fuerchau]

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

[cbe]

klappt wunderbar, vielen Dank! Die Anwender werden sich freuen.

Wen es interessiert, hier der 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