I understand the concern, the point I was trying to make was that in some cases it's difficult to determine if particular return codes merit something being written to the errorlog.
In the case of a named pipe error (on either the journal daemon or the backup client) it isn't easy to determine if the error occurs because the other process has terminated (or timed out) either normally or abnormally. All that having been said, the error messages in question really provide diagnostic information that probably isn't all that useful to the end user and is really is only useful to development or support when attempting to track down problems in the field. So I agree that the messages should either be more meaningful or shouldn't be in the errorlog at all (probably more appropriate for the client tracing facility). By the way, I tracked down the specific message in this thread ( return code 121 \\.\pipe\jnl). There are two types of named pipes used to communicate between the two processes (journal daemin and b/a client). One named pipe (\\.\pipe\jnl) name is created by the journal daemon during startup and is used to receive inbound requests from the b/a client. The b/a client determines if the journal daemon is running by attempting to connect to this pipe. Return code 121 indicates that the b/a client timed out attempting to connect to the pipe, which most likely means that the journal daemon isn't running. I think a more accurate message in the errorlog would be something like "Connection to Journal Daemon timed out" (and the specific return code could be documented with tracing on). The other type(s) of named pipes are created by the b/a client and used to receive responses from the journal daemon. There is at least one response pipe created by the b/a client for each backup session (and with multi-threaded backup possible more since there can be multiple backup sessions). Any request sent to the journal daemon which requires a response includes this response pipe name. When the journal daemon processes the response, it connects to the supplied response pipe and sends response data on it as needed. The b/a client backup session waits for data to arrive on the response pipe and the reads it. An example of this would be a request from the b/a client to query all of the objects in the journal for a particular file system. The b/a client creates a pipe for the journal daemon to send the list of matching objects on, and supplies the name of this pipe to the journal daemon in the query request. The journal daemon processes the query request, connects to the supplied pipe, performs the query, and sends the responses on the pipe.. The b/a client expects to look (peeks) at the request pipe to determine if there is any response data to read and continues to read until it is empty. Usually data will be available on the response pipe as soon as the b/a client requests it, but in some cases (as with very long running queries) the journal daemon doesn't post the data on the response pipe in time and the b/a client must continue to look (peek) at the pipe until it arrives. I believe the above condition is the source of the "NpPeek: No data" message in the errorlog. Since the b/a client will eventually timeout the session if the data isn't received on the response pipe in a reasonable amount of time, I don't see any use of logging the above message, so I will remove it in a future release/ptf. Anyway, I hope this helps ..... Pete Tanenhaus Tivoli Storage Solutions Software Development email: [EMAIL PROTECTED] tieline: 320.8778, external: 607.754.4213 "Those who refuse to challenge authority are condemned to conform to it" ---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 02/11/2003 11:58 AM --------------------------- "Magura, Curtis" <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 02/11/2003 11:32:26 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: journal errors - return code 121 \\.\pipe\jnl Pete, think you said it all with the statement below! Very confusing in the current state to decide if there is a problem or not. "That being said, I think development (myself) needs to look at the np error logging on both sides and try to eliminate logging messages which aren't really errors, but in some situations it's difficult to determine if an error condition is legitimate and should be logged or if it is innocuous and can be ignored." Curt Magura Lockheed Martin EIS Orlando, Fla. 321-235-1203 -----Original Message----- From: Pete Tanenhaus [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 11, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: journal errors - return code 121 \\.\pipe\jnl Np errors in the backup client errorlog indicate the opposite condition, that is the backup client is trying to read a response sent from the journal daemon which isn't available at the moment the read is being done. This error can happen if the journal daemon ends (obviously a problem) or (I believe) if the response the backup client is looking for from the journal daemon is still in progress, meaning that the journal daemon hasn't finished processing/sending it. In most cases the response is ready when the backup client goes to read it, but if it isn't the backup client will keep trying to read the response until it either arrives or a timeout occurs (don't know the exact wait time of the top of my head). That being said, I think development (myself) needs to look at the np error logging on both sides and try to eliminate logging messages which aren't really errors, but in some situations it's difficult to determine if an error condition is legitimate and should be logged or if it is innocuous and can be ignored. Hope this helps ...... Pete Tanenhaus Tivoli Storage Solutions Software Development email: [EMAIL PROTECTED] tieline: 320.8778, external: 607.754.4213