outq ändern

[kuempi von stein]

Moin,

ein eher simple Frage, die einen Neuling im Feld der AS/400 vor Probleme stellt: wie kann ich die outq ändern?
Szenario: Mitarbeiter 1 drucken auf Drucker A und Mitarbeiter 2 drucken auf Drucker B. Nun fällt Drucker A aus (technischer defekt) und alle Druckaufträge der Mitarbeiter 1 sollen nun ab sofort, automatisch an Drucker B gehen. Wie kann man dies bewerkstelligen?

Danke vielmals.

einfache frage , schwere antwort...
es gibt sooo viele möglichkeiten, warum ein druck dort und nicht da raus kommt....
userprofile, jobbeschreibung, printerfile, override, programmgesteuert...
je danach wie eine umgebung gewachsen ist, wurde evtl. irgendwo an sowas rumgeschraubt...

kuempi

[aaaaa]

Moin.

einfache frage , schwere antwort...
es gibt sooo viele möglichkeiten, warum ein druck dort und nicht da raus kommt....
userprofile, jobbeschreibung, printerfile, override, programmgesteuert...
je danach wie eine umgebung gewachsen ist, wurde evtl. irgendwo an sowas rumgeschraubt...

Nene, da wurde nichts rumgeschraubt, naja, wurde doch ;-). Drucker A ist defekt. Der ist in Reparatur. Nun möchte ich das Du User die bisher auf Drucker A gedruckt hatten, auf Drucker B drucken, dazu muss ich ja die outq ändern. Also PRT01 ist defekt, PRT02 geht, User die bisher auf PRT01 zugewiesen waren, sollen nun auf PRT02 zugewiesen werden. Und da ist die Frage wie man dies anstellt.

[Fuerchau]

Das ist ganz von deiner Anwendung abhängig, Druckerzuordnungen stehen:

- Im Userprofil
- In der Displaybeschreibung
- Im Systemwert
- in der Printerfile
- Können in der Anwendung verwaltet sein (Druckerüberschreibung in z.B. DCW/Brain)
- Können in CLP's fest verdrahtet sein

Dies alles ist ggf. zu kontrollieren und anzupassen.

[Rincewind]

Was der Ersthelfer dir sagen wollte:

Es ist nicht so einfach dass global zu sagen.

Je nach Anwendung gibt es eigene Ebenen der Überschreibung.

1. Es kann im Userprofile hängen, dann isses leicht
2. Es kann an einer Jobbeschreibung des Benutzers hängen, auch noch relativ einfach
3. Es kann im Programm hart verdrahtet sein.. dann muss man das ändern
4. Es kann in der Anwendung definiert sein wer wo was druckt.. dann muss man mit Fachwissen gucken
5.-999. 994 andere möglichkeiten.

Wichtig ist herauszufinden wo das in eurem System eingestellt ist wer wo druckt.

Gruss

Rince

[areichelt]

Hallo,

natürlich wurde "rumgeschraubt". Irgendwo muss dem System ja gesagt werden, wo User XY hindrucken soll. Das weiß das arme System ja nicht von alleine .

Und genau da liegt das Problem - da gibt es zig Möglichkeiten. Drucken die aus nur einer Anwendung, aus mehreren, auch Hardcopies und und und?

Wenn aus Anwendungen, dann werden irgendwo Überschreibungstabellen pro User oder evtl. Bildschirm hinterlegt sein, wo das ganze abgebildet ist. Kann aber auch sein, dass Usern oder Bildschirmen Drucker oder Printerfiles fest zugeordnet sind. Wenn Du nicht weißt wie die Drucksteuerung aufgebaut ist, hast Du für eine Automatik keine Chance.

Da bleibt nur die "Hand am Arm Methode" - d.h. die Spools von Hand in die andere OUTQ schieben, oder sporadisch den Drucker mal an die eine, mal an die andere OUTQ anzuhängen.

Gruß
A.R.

[Fuerchau]

Oder so:

Erstellen einer DTAQ mit
CRTDTAQ DTAQ(QGPL/MYPRT) MAXLEN(128)

Ändern der OUTQ mit
CHGOUTQ OUTQ(MYLIB/MYOUTQ) DTAQ(QGPL/MYPRT)

Ab nun erscheint in der DTAQ immer ein Eintrag, wenn eine Spoolfile RDY wird (also gedruckt werden soll).

Nun noch ein kleines CLP fürs Batch (z.B. als Prestartjob oder Autostartjob):

PGM
/* FELDER FÜR DTAQ */
DCL VAR(&DNAME) TYPE(*CHAR) LEN(10) +
VALUE('MYPRT')
DCL VAR(&DLIB) TYPE(*CHAR) LEN(10) +
VALUE('QGPL')
DCL VAR(&DLEN) TYPE(*DEC) LEN(5)
DCL VAR(&DATA) TYPE(*CHAR) LEN(128)
DCL VAR(&WAIT) TYPE(*DEC) LEN(5) VALUE(-1)

LOOPDTAQ:
CHGVAR VAR(&DLEN) VALUE(128)
CHGVAR VAR(&DATA) VALUE(' ')
CALL PGM(QRCVDTAQ) PARM(&DNAME &DLIB &DLEN &DATA +
&WAIT)
MONMSG MSGID(CPF0000) EXEC(DO)
DLYJOB DLY(5)
GOTO CMDLBL(LOOPDTAQ)

/* DATEN VORHANDEN ? */
IF COND(&DLEN > 0) THEN(DO)
CHGSPLFA FILE(%SST(&DATA 39 10))
JOB(%SST(&DATA 33 6)/%SST(&DATA 23 10)/%SST(&DATA 13 0)) SPLNBR(%BIN(&DATA 49 4))
OUTQ(QGPL/MYNEWOUTQ)
ENDDO
GOTO CMDLBL(LOOPDTAQ)
ENDPGM

Zum Aufbau des DTAQ-Eintrages siehe:
http://www.rlpforen.de/showthread.ph...ight=dtaq+outq

[kuempi von stein]

Oder so:

Erstellen einer DTAQ mit
CRTDTAQ DTAQ(QGPL/MYPRT) MAXLEN(128)

Ändern der OUTQ mit
CHGOUTQ OUTQ(MYLIB/MYOUTQ) DTAQ(QGPL/MYPRT)

Ab nun erscheint in der DTAQ immer ein Eintrag, wenn eine Spoolfile RDY wird (also gedruckt werden soll).

Nun noch ein kleines CLP fürs Batch (z.B. als Prestartjob oder Autostartjob):


Zum Aufbau des DTAQ-Eintrages siehe:
http://www.rlpforen.de/showthread.ph...ight=dtaq+outq

ich stehe staunend davor und frage mich, warum ich das nicht wusste...
boh ej...
und das gibts schon seit jahren?
ich fass es nicht...

kuempi

der sich freiwillig in die ecke stellt...

[areichelt]

kuempi

der sich freiwillig in die ecke stellt...

Hallo,

stelle mich mal dazu .

[Fuerchau]

Naja, das gibts schon ca. seit V2. Ich habe sowas schon verwendet um Remote-OUTQ's in V2 zu realisieren, SNDNETSPLF über SNADS gabs schon damals und nix war billiger als auf diesem Weg Spools an andere User auch auf anderen Systemen zu versenden.
Viele Spool-Archiviertools arbeiten auch so (Archiv on demand).

[cbe]

[QUOTE=Fuerchau]Oder so:

Erstellen einer DTAQ mit
CRTDTAQ DTAQ(QGPL/MYPRT) MAXLEN(128)

Ändern der OUTQ mit
CHGOUTQ OUTQ(MYLIB/MYOUTQ) DTAQ(QGPL/MYPRT)

Ab nun erscheint in der DTAQ immer ein Eintrag, wenn eine Spoolfile RDY wird (also gedruckt werden soll).

Nun noch ein kleines CLP fürs Batch (z.B. als Prestartjob oder Autostartjob):

 
PGM
/* FELDER FÜR DTAQ */ 
DCL VAR(&DNAME) TYPE(*CHAR) LEN(10) + 
VALUE('MYPRT') 
DCL VAR(&DLIB) TYPE(*CHAR) LEN(10) + 
VALUE('QGPL') 
DCL VAR(&DLEN) TYPE(*DEC) LEN(5) 
DCL VAR(&DATA) TYPE(*CHAR) LEN(128) 
DCL VAR(&WAIT) TYPE(*DEC) LEN(5) VALUE(-1) 
 
LOOPDTAQ: 
CHGVAR VAR(&DLEN) VALUE(128) 
CHGVAR VAR(&DATA) VALUE(' ') 
CALL PGM(QRCVDTAQ) PARM(&DNAME &DLIB &DLEN &DATA + 
&WAIT) 
MONMSG MSGID(CPF0000) EXEC(DO) 
DLYJOB DLY(5) 
GOTO CMDLBL(LOOPDTAQ) 
 
/* DATEN VORHANDEN ? */ 
IF COND(&DLEN > 0) THEN(DO) 
CHGSPLFA FILE(%SST(&DATA 39 10)) 
JOB(%SST(&DATA 33 6)/%SST(&DATA 23 10)/%SST(&DATA 13 0)) SPLNBR(%BIN(&DATA 49 4)) 
OUTQ(QGPL/MYNEWOUTQ) 
ENDDO
GOTO CMDLBL(LOOPDTAQ) 
ENDPGM

Zum Aufbau des DTAQ-Eintrages siehe:
http://www.rlpforen.de/showthread.php?t=833&highlight=dtaq+outq[/QUOTE]


Hallo,

der Beitrag ist schon etwas her, aber immer wieder aktuell...

Jetzt nehmen wir mal an, es geht um eine OUTQ, aus der ganz normal gedruckt wird, die Spools ohne SAVE(*YES) also nach dem Druck verschwinden.
Kann man irgendwie sicherstellen, dass ein Spool zwecks Archivierung noch kopiert werden kann, bevor er weg ist?
Mir schwirren verschiedene Ideen im Kopf rum: Dummy-Outq, Exit-Programme, vielleicht gehts ja aber auch viel einfacher.

Gruß,
Christian

[Fuerchau]

Nein, da gibt es keine Sicherheit.
Der Spool sollte auf SAVE(*YES) stehen, damit er garantiert verarbeitet wird.

Wenn man Sicherheit haben möchte, geht das nur über ein eigenes Programm:
a) Spool 2x ausgeben
b) Spool auf HOLD(*YES) setzen, nach Druck z.B. SNDSPLF an den Archiv-User und per RLSSPLF zum Drucken freigeben. Dann kann SAVE(*YES) entfallen.

[cbe]

schade, habe ich schon befürchtet.

Spool mit HOLD in die OUTQ stellen, reicht das? Gibt es dann schon einen Eintrag in die DTAQ oder erst bei RDY-Status?

Aber sonst könnte ich den Spool
1. mit SAVE(*YES) in die OUTQ stellen,
2. archivieren,
3. SAVE(*NO) einstellen
4. Status prüfen: Wenn er im Status SAV ist, löschen (könnte ja noch ungedruckt sein)

Das müsste gehen - danke für die Idee!

Gruß,
Christian