Fri, 14 Nov 2003 11:43:59
LISTSERV AT VM.MARIST DOT EDU has just received the enclosed delivery error as a
result of a probe sent to your ADSM-LIST AT ADSM DOT ORG account for the ADSM-L
list. If you are reading this message, it means that your mail system is
successfully delivering mail to your mailbox, while at the same time
reporting that an error has occurred (or, alternatively, the error could
be due to a system problem which has since then been fixed). At any rate,
LISTSERV has no way to know that you have actually received the present
message, and is operating on the assumption that your e-mail address is
no longer valid. Typically, LISTSERV will send you one or more additional
probe messages, on a daily basis, to determine whether the failure
persists, and if so you will be removed from the list eventually. Some
lists are configured to remove users on the first failure.
Assuming you have not been removed from the list yet, you can stop this
process by sending the following command to LISTSERV AT VM.MARIST DOT EDU as
soon as possible:
CONFIRM ADSM-L
This will tell LISTSERV that your account actually does work and that you
still want to receive mail from the ADSM-L list.
While the CONFIRM command will solve your immediate problem, it is only a
matter of time until you find yourself in the same situation again.
Please take a look at the enclosed error report and try to determine
whether it is a genuine error, or just an informational message. Bear in
mind that this error report was processed by a computer that cannot tell
"User JAIME24 does not exist" from "Please note that the Department of
Microbiology will be closed from December 19 to January 2" or "Attempts
to deliver your message have been unsuccessful for 300 seconds; will keep
trying for another 431700 seconds." These informational messages, while
possibly useful to a human reader, should not be sent in answer to a
message coming from a mailing list (it is very easy for the mail program
to determine whether a message is coming from a mailing list). Genuine
errors should be reported to your computer/network support staff as soon
as possible so that they can be corrected.
------------------------- Delivery error report -------------------------
Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
V1.2b/1.8b) with BSMTP id 5411; Fri, 14 Nov 2003 11:43:59 -0500
Received: from neodymium.btinternet.com [194.73.73.83] by VM.MARIST.EDU (IBM VM
SMTP Level 430) via TCP with SMTP ; Fri, 14 Nov 2003 11:43:58 EST
Received: from mail by neodymium.btinternet.com with local (Exim 3.22 #23)
id 1AKh2f-00063i-00
for owner-adsm-l*adsm-list**adsm*-org AT vm.marist DOT edu; Fri, 14 Nov
2003 16:43:29 +0000
X-Failed-Recipients: phil.shafer AT btopenworld DOT com
From: Mail Delivery System <Mailer-Daemon AT btinternet DOT com>
To: owner-adsm-l*adsm-list**adsm*-org AT vm.marist DOT edu
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1AKh2f-00063i-00 AT neodymium.btinternet DOT com>
Date: Fri, 14 Nov 2003 16:43:29 +0000
This message was created automatically by mail delivery software (Exim).
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
phil.shafer AT btopenworld DOT com
Sorry, this email address can not receive any more email as the mailbox is
full:
retry timeout exceeded
------ This is a copy of the message, including all the headers. ------
Return-path: <owner-adsm-l*adsm-list**adsm*-org AT vm.marist DOT edu>
Received: from mta805.mail.ukl.yahoo.com ([217.12.12.149])
by neodymium.btinternet.com with smtp (Exim 3.22 #25)
id 1AKh2e-00062x-00
for phil.shafer AT btopenworld DOT com; Fri, 14 Nov 2003 16:43:28 +0000
X-Yahoo-Relayed: phil.shafer AT btopenworld DOT com
X-Originating-IP: [65.246.59.154]
Received: from 65.246.59.154 (HELO securepoint.com) (65.246.59.154)
by mta805.mail.ukl.yahoo.com with SMTP; Fri, 14 Nov 2003 16:43:26 +0000
Received: (qmail 28303 invoked by uid 603); 14 Nov 2003 16:43:24 -0000
Delivered-To: adsm-list AT ADSM DOT ORG
Received: (qmail 28292 invoked from network); 14 Nov 2003 16:43:18 -0000
Received: from mailer390.marist.edu (148.100.80.47)
by 0 with SMTP; 14 Nov 2003 16:43:18 -0000
Received: from VM.MARIST.EDU (vm.marist.edu [148.100.80.40])
by mailer390.marist.edu (Postfix) with ESMTP id 6400112C33
for <adsm-list AT ADSM DOT ORG>; Fri, 14 Nov 2003 11:43:00 -0500 (EST)
Received: by VM.MARIST.EDU (IBM VM SMTP Level 430) via spool with SMTP id 9818
; Fri, 14 Nov 2003 11:43:08 EDT
Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU
(LMail V1.2b/1.8b) with BSMTP id 5300; Fri, 14 Nov 2003 11:43:07 -0500
Received: from VM.MARIST.EDU by VM.MARIST.EDU (LISTSERV release 1.8e) with NJE
id 0677 for ADSM-L AT VM.MARIST DOT EDU; Fri, 14 Nov 2003 11:43:05
-0500
Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
V1.2b/1.8b) with BSMTP id 5234; Fri, 14 Nov 2003 11:43:05 -0500
Received: from zeus.itg.uiuc.edu [130.126.126.162] by VM.MARIST.EDU (IBM VM
SMTP Level 430) via TCP with SMTP ; Fri, 14 Nov 2003 11:43:05 EST
Received: from localhost (alazarev@localhost) by zeus.itg.uiuc.edu
(8.11.6/8.11.6) with ESMTP id hAEGgao25100 for
<ADSM-L AT VM.MARIST DOT EDU>; Fri, 14 Nov 2003 10:42:36 -0600
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.44.0311141039490.24133-100000 AT zeus.itg.uiuc DOT edu>
Date: Fri, 14 Nov 2003 10:42:36 -0600
Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
From: Alexander Lazarevich <alazarev AT ITG.UIUC DOT EDU>
Subject: Re: different backup policy on single node?
To: ADSM-L AT VM.MARIST DOT EDU
In-Reply-To: <T65e763d40cc407b73dac8 AT dtcseuvig6.reuters DOT com>
Precedence: list
Well, the select statement returned nothing. Which is correct, because
currently there is nothing in that management class, and if those OS X
filespace didn't get moved to it (backup went by real fast, no volume
rebounds), then a return of zippo is corrent.
Do you think I need to delete the filespace first? And then back it up
again?
I'll keep trying.
Thanks for the help though.
Alex
On Fri, 14 Nov 2003, David McClelland wrote:
> Hmmm, interesting. The 'backups' table in TSM tells us which management
> class an object is bound to. For example, a 'select * from backups'
> gives us useful things which include:
>
> NODE_NAME, FILESPACE_NAME, BACKUP_DATE and most importantly for you,
> CLASS_NAME
>
> You could put together a select query and check that the CLASS_NAME is
> correct - for example, if you've just implemented this, the simplest
> test would be:
>
> select * from backups where class_name='<your OS X mgmtclass name>'
>
> Very crude - you might want to modify this to satisfy yourself that it's
> working properly.
>
> Rgds,
>
> David McClelland
> Global Management Systems, Reuters Ltd., London
>
>
> -----Original Message-----
> From: Alexander Lazarevich [mailto:alazarev AT ITG.UIUC DOT EDU]
> Sent: 14 November 2003 15:54
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: different backup policy on single node?
>
>
> Cool, thanks. made the change, backed up the filespace. But how can I
> verify that the include statement has put that filespace into a new
> management class? Nothing in the actlog about management class. A 'q
> file xxx xxx format=detail' doesn't tell me either.
>
> I could verify by deleting temp files on the filespace and see if they
> get blown away from the server according to the new management class,
> but there's got to be a better way to tell?
>
> Thanks!
>
> Alex
>
> On Fri, 14 Nov 2003, David McClelland wrote:
>
> > Alexander,
> >
> > How about using the include exclude list on the Linux client to
> > specify a different management class for the filespec in which the OSX
>
> > clients have their filespaces mounted?
> >
> > e.g. include /mnt/macclientmount/.../* MAC_MGMTCLASS
> >
> > Where MAC_MGMTCLASS as defined on the server might have the policy
> > that you wish for your Mac files.
> >
> > Rgds,
> >
> > David McClelland
> > Global Management Systems, Reuters Ltd., London
> >
> > -----Original Message-----
> > From: Alexander Lazarevich [mailto:alazarev AT ITG.UIUC DOT EDU]
> > Sent: 14 November 2003 15:04
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: different backup policy on single node?
> >
> >
> > TSM 5.1 on Windows 2K server with Overland Neo 4100 LTO2. Windows,
> > unix, mac clients.
> >
> > We nfs mount OS X workspaces onto our Linux fileserver, and back them
> > up from there. We do that because, frankly, the TSM OS X scheduler is
> > terrible. And since there is no command line for the TSM OS X client,
> > we can't run the scheduler on OS X with cron. (what is IBM thinking?)
> >
> > Anyway, we now want different policies for the OS X nfs mounts and the
>
> > other filesystems on the linux client. But I don't see any way of
> > getting this done in TSM, it just wasn't designed that way.
> >
> > But is there any backdoor way to accomplish that? I just need a way to
>
> > have different filespaces on a single client belong to different
> > policies?
> >
> > Or is there any version of the OS X TSM client that actually can run
> > via command line?
> >
> > Thanks in advance,
> >
> > Alex
> >
> >
> > -----------------------------------------------------------------
> > Visit our Internet site at http://www.reuters.com
> >
> > Get closer to the financial markets with Reuters Messaging - for more
> > information and to register, visit http://www.reuters.com/messaging
> >
> > Any views expressed in this message are those of the individual
> > sender, except where the sender specifically states them to be the
> > views of Reuters Ltd.
> >
>
>
> -----------------------------------------------------------------
> Visit our Internet site at http://www.reuters.com
>
> Get closer to the financial markets with Reuters Messaging - for more
> information and to register, visit http://www.reuters.com/messaging
>
> Any views expressed in this message are those of the individual
> sender, except where the sender specifically states them to be
> the views of Reuters Ltd.
>
|
