ProcessLPDJob: No recipient address for document 1 in job data

[fenris]

Guten Morgen zusammen,
ich hab leider schon das nächste Problem mit unserem Ferrari.

Im Log vom msx2kgate0.0 taucht immer mal wieder folgender Eintrag auf:
ProcessLPDJob: No recipient address for document 1 in job data

Darunter, mit der gleichen Thread-ID, steht dann der entsprechende Benutzer.

Für mich bedeutet das, dass das System irgendwo noch einen Job hat, bei dem kein Empfänger hinterlegt ist.
Die Frage ist nun eigenltich: Wo find ich den Job?

In den Jobs in der Messaging Server Konfiguration steht nämlich keiner.
Auf auf Dateiebene find ich einfach nichts....

Wo soll "job data" sein?

Hoffe Ihr könnt mir helfen.

Gruß
matthias

[Marko Riebe]

ProcessLPDJob: No recipient address for document 1 in job data

Hallo,

grundsätzlich hat jede Komponente unter dem work-Verzeichnis eigene Arbeitsverzeichnisse in und out. Es kommt zuweilen vor, dass sich bei den Komponenten im in-Verzeichnis Aufträge sammeln, die nicht gelöscht werden können (Dateiprobleme, Virenscanner, etc.) In einem solchen Fall werden diese Aufträge nach Neustart der Komponente wieder neu abgearbeitet. Wenn sich bei allen Komponenten in in-Verzeichnis, sowie im CTRL\wait oder Split\Wait-Verzeichnis keine Daten finden, so wird der Auftrag von außen in das System gekippt.

Manchmal passiert dies auch, wenn sich Aufträge im conv0\work-Verzeichnis befinden. Diese Aufträge werden ebenfalls nach Neustart der Komponente conv0 neu bearbeitet.

Im Fall des LPD bedeutet dies tatsächlich, das ein Druckjob oder direkter PCL/PS Job zum LPD kam und dort keine Faxnummer gefunden wurde. Entweder dieser Auftrag liegt noch in irgendeiner Komponente in der Queue, oder es wird von außen ein Auftrag in das System gekippt.

Viele Grüße

Marko Riebe

[fenris]

Hallo,
weder in CTRL\wait + den anderen Ordner,
noch in Split\wait + andere Ordner,
oder conv0\work find ich irgendwelche Dateien.

Das der Job von außen kommt, mag sein....aber ich finde dummerw. in keiner Warteschlange über die Aufträge von außen an den Faxserver übergeben werden einen Eintrag.

Dann hängt das mit meinem anderen Problem von hier: http://forum.ferrari-electronic.de/s...=5296#post5296
zusammen.

Ich hab jetzt Dateien in omcums0\send gefunden.
Eine BFF davon entspricht einer Mail, die eine Kollegin immer wieder bekomm.
Was für einen Grund hat es, wenn Dateien dort hängen bleiben?
Kann man die einfach rauslöschen?

In omcums0\rec stehen auch alte Dateien rum.
Gruß
matthias

[Marko Riebe]

ProcessLPDJob: No recipient address for document 1 in job data

Hallo,

man kann das leider nicht pauschal beantworten.

Ich hab jetzt Dateien in omcums0\send gefunden. Eine BFF davon entspricht einer Mail, die eine Kollegin immer wieder bekomme.
Was für einen Grund hat es, wenn Dateien dort hängen bleiben? Kann man die einfach rauslöschen? In omcums0\rec stehen auch alte Dateien rum.

Natürlich sollten keine Dateien nach der Abarbeitung in den work-Verzeichnissen liegenbleiben, denn diese sind ja bereits verarbeitet. Wenn sich keine Jobs im Jobstatus befinden, können Sie den OMCUMS0 gern stoppen und das komplette omcums0-Verzeichnis löschen. Arbeitsverzeichnisse werden nach Komponentenstart automatisch neu angelegt.

Es gibt verschiedene Gründe, warum diese Dateien dort liegenbleiben könnten:

• Backup-Software sichert während der Abarbeitung und blockiert den Workflow.
• Virenscanner überwacht während der Abarbeitung und blockiert den Workflow.
• Der Dienst "OfficeMaster Messaging Server" wurde vielleicht nach der Installation unter einem Dienstkonto gestartet. Dies ist ein grober Schnitzer, und sorgt dafür, dass der "Besitzer" der Arbeitsverzeichnisse das Dienstkonto ist. Wenn nun das Dienstkonto wieder umgestellt wird, bleiben ggf. Dateien aus Rechtegründen in den Verzeichnissen liegen.

Man kann nicht pauschal beantworten, warum dies in diesem Fall geschehen ist. Es ist nicht vom Design her beabsichtigt, Aufträge mehrfach zuzustellen, wenn diese bereits verarbeitet wurden, insofern tippe ich auf einen Virenscanner. Ich persönlich kenne übrigens einen solchen Fall, wie er hier beschrieben wurde nicht, obwohl ich täglich mit dem Produkt zu tun habe. Meist betrifft das Verhalten andere Komponenten.

Viele Grüße

Marko Riebe