Thanks,
Will check it out, thanks for all the responses.
Justin.
On Tue, 31 Mar 2009, Darren Richardson wrote:
> Please read the warning at the end of this email
> ________________________________________________
>
> Justin,
> Have a look at the white paper by Alex Davies on "Implementing
> Highly Available Data Protection with Veritas Netbackup".
>
> There is an interesting section on media to master promotion.
> I have tested it in a mini environment (1 master, 1 media server) on hp-ux
> and it appeared to work.
> You will have to contact your account manager / support to get your hands on
> the full-blown procedure.
>
>
> Regards
>
> * Darren Richardson
>
> * Team Leader
>
> * Production Services
>
> * Yorkshire Building Society
>
> * Tel:01274 472655
>
> * Email: dzrichardson AT ybs.co DOT uk
>
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
> veritas-bu-request AT mailman.eng.auburn DOT edu
> Sent: 30 March 2009 18:00
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Veritas-bu Digest, Vol 35, Issue 56
>
> Send Veritas-bu mailing list submissions to
> veritas-bu AT mailman.eng.auburn DOT edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> or, via email, send a message with subject or body 'help' to
> veritas-bu-request AT mailman.eng.auburn DOT edu
>
> You can reach the person managing the list at
> veritas-bu-owner AT mailman.eng.auburn DOT edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Veritas-bu digest..."
>
>
> Today's Topics:
>
> 1. Veritas-bu] Unable to find image in Restore/Catalog (NBU)
> 2. Unable to find image in Restore/Catalog (NBU)
> 3. AUTO: Philippe Fouillet ist au?er Haus. (R?ckkehr am
> 03.04.2009) (Philippe Fouillet)
> 4. Windows 2003 SP2 NBU 6.5.3 hung bpbkar (Marianne Van Den Berg)
> 5. Re: Not all drives appear to be used (WEAVER, Simon (external))
> 6. Moving the NetBackup Master Server from host A to B.
> (Justin Piszcz)
> 7. Robotic Path error (McDonald II, James F.)
> 8. Re: Robotic Path error (Justin Piszcz)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 30 Mar 2009 02:54:22 -0400
> From: NBU <netbackup-forum AT backupcentral DOT com>
> Subject: [Veritas-bu] Veritas-bu] Unable to find image in
> Restore/Catalog
> To: VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU
> Message-ID: <1238396062.m2f.302494 AT www.backupcentral DOT com>
>
>
> Thanks for the enlightening suggestion.
>
> +----------------------------------------------------------------------
> |This was sent by qureshiumar AT rediffmail DOT com via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 30 Mar 2009 03:34:27 -0400
> From: NBU <netbackup-forum AT backupcentral DOT com>
> Subject: [Veritas-bu] Unable to find image in Restore/Catalog
> To: VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU
> Message-ID: <1238398467.m2f.302497 AT www.backupcentral DOT com>
>
>
> Pls. find the contents of EKMS_1234601889_FULL
>
> ---------------------------------------------------------------------------------
> PROTOCOL_VERSION 2
> START_TIME 0
> END_TIME 0
> SNAP_TIME 0
> KBYTES 70320468
> NUM_FRAGMENTS 18
> COPIES 1
> VERSION 7
> CLIENT_TYPE 13
> RETENTION_LEVEL 3
> SCHEDULE_TYPE 0
> COMPRESSION 0
> ENCRYPTION 0
> FILES_FILE_COMPRESSED 0
> MPX 1
> TIR_INFO 0
> TIR_EXPIRATION 0
> PRIMARY_COPY 2
> IMAGE_TYPE 0
> ELAPSED 12928
> EXPIRATION 1239958689
> NUM_FILES 30
> EXTENDED_SECURITY_INFO 0
> REQUEST_PID 0
> IND_FILE_RESTORE_FROM_RAW 0
> IMAGE_DUMP_LEVEL 0
> FILE_SYSTEM_ONLY 0
> PREV_BLOCK_INCR_TIME 0
> BLOCK_INCR_FULL_TIME 0
> STREAM_NUMBER 0
> CATARC 0
> BACKUP_COPY 0
> BACKUP_STATUS 0
> JOB_ID 34111
> NUM_RESUMES 0
> RESUME_EXPIRATION 0
> PFI_TYPE 0
> IMAGE_ATTRIBUTE 0
> NUM_DR_MEDIAS 0
> # FRAG: c# f# K rem mt den fn id/path host bs off md dwo f_flags f_unused1
> exp mpx rl chkpt rsm_nbr seq_no media_subtype i_un
> used3 i_unused2 i_unused1
> FRAGMENT 2 1 6909888 0 2 20 76 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 1239958689 1 65540 1 0 0 1 0 0 0
> FRAGMENT 2 2 1983168 0 2 20 77 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 3 1889600 0 2 20 78 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 1 0 0 1 0 0 0
> FRAGMENT 2 4 12081728 0 2 20 79 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 1 0 0 1 0 0 0
> FRAGMENT 2 5 4149696 0 2 20 80 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 6 2213824 0 2 20 81 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 1 0 0 1 0 0 0
> FRAGMENT 2 7 14357056 0 2 20 82 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 1 0 0 1 0 0 0
> FRAGMENT 2 8 979584 0 2 20 83 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL* 0
> 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 9 86656 0 2 20 84 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL* 0
> 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 10 5003072 0 2 20 85 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 11 5414016 0 2 20 86 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 12 4460032 0 2 20 87 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 1 0 0 1 0 0 0
> FRAGMENT 2 13 523264 0 2 20 88 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 14 5003904 0 2 20 89 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 15 4507136 0 2 20 90 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 1 0 0 1 0 0 0
> FRAGMENT 2 16 239424 0 2 20 91 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> FRAGMENT 2 17 128 0 2 20 92 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL* 0 0
> 0 1 0 0 1 0 0 0
> FRAGMENT 2 18 518292 0 2 20 93 LTO064 ROMNETBK 65536 0 1233996031 4 0 *NULL*
> 0 0 0 0 0 0 1 0 0 0
> BACKUP_ID EKMS_1234601889
> CREATOR NetBackup
> SCHED_LABEL Weekly
> FILES_FILE EKMS_1234601889_FULL.f
> FILES_FILE_SIZE 4040
> HISTO_INFO -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
> -------------------------------------------------------------------------------------
>
> +----------------------------------------------------------------------
> |This was sent by qureshiumar AT rediffmail DOT com via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 30 Mar 2009 10:00:52 +0200
> From: Philippe Fouillet <philippe.fouillet AT ch.sauter-bc DOT com>
> Subject: [Veritas-bu] AUTO: Philippe Fouillet ist au?er Haus.
> (R?ckkehr am 03.04.2009)
> To: VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU
> Message-ID:
> <OFDE1BBFD0.6BD06D72-ONC1257589.002C0675-C1257589.002C0675 AT
> ae.sauter-bc DOT com>
>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> Ich bin bis 03.04.2009 abwesend
>
> Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten.
>
>
> Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "
> [Veritas-bu] Veritas-bu] Unable to find image in Restore/Catalog" gesendet
> am 30.03.2009 08:54:22.
>
> Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend
> diese Person abwesend ist.
>
> ------------------------------
>
> Message: 4
> Date: Mon, 30 Mar 2009 10:29:22 +0200
> From: "Marianne Van Den Berg" <mvdberg AT stortech.co DOT za>
> Subject: [Veritas-bu] Windows 2003 SP2 NBU 6.5.3 hung bpbkar
> To: <VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU>
> Message-ID:
> <AF98230F3E66704A8392DCAAAE38BF274F4059 AT sts2.stortech.co DOT za>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi All
>
>
>
> One particular client hangs at end of backup - bpbkar log reports exist
> status 0, but job remains active in Activity Monitor. Job does not
> timeout/fail, even long after Client_Read timeout exceeded.
>
>
>
> Task Manager shows running bpbkar processes and 'netstat -a' shows lots
> of bpcd and vnetd connections in CLOSE_WAIT state.
>
> Stopping NBU Client service and killing bpbkar's make CLOSE_WAIT's go
> away, but same thing happens all over again at next backup. Normal File
> system backup, backing up ALL_LOCAL_DRIVES. No TIR selected in policy
> attributes.
>
> Other clients in same policy complete successfully.
>
>
>
> Master, media and client all on 6.5.3.
>
>
>
> Any ideas?
>
>
>
> Kind regards
>
>
>
> Marianne
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20090330/8bbe0df3/attachment-0001.htm
>
> ------------------------------
>
> Message: 5
> Date: Mon, 30 Mar 2009 09:33:57 +0100
> From: "WEAVER, Simon \(external\)" <simon.weaver AT astrium.eads DOT net>
> Subject: Re: [Veritas-bu] Not all drives appear to be used
> To: "Hudson, Steve" <Steve.Hudson AT ironmountain DOT com>,
> <VERITAS-BU AT mailman.eng.auburn DOT edu>
> Message-ID:
> <7421086474A3DB4989F94A88D2F7F19801C387E8 AT VSMAIL1.uk.astrium DOT
> corp>
> Content-Type: text/plain; charset="us-ascii"
>
> Cheers Steve. I just thought that a Stop / Restart of the Services or
> even a (last restore) reboot may well have helped.
>
> But at least the root problem has been cured :-)
>
> -----Original Message-----
> From: Hudson, Steve [mailto:Steve.Hudson AT ironmountain DOT com]
> Sent: Friday, March 27, 2009 2:12 PM
> To: WEAVER, Simon (external); VERITAS-BU AT mailman.eng.auburn DOT edu
> Subject: RE: [Veritas-bu] Not all drives appear to be used
>
> Not in my experience..It releases the holds immediately. Having said
> that we have been having to do this kind of thing way to often. Methinks
> 6.5.3.1 is still broke when it comes to Resource Allocations....My 2
> cents
>
>
> Steve Hudson
> Enterprise Storage
> Iron Mountain
> 745 Atlantic Ave
> Boston, MA 02111
> Phone: (617) 535-2849
>
> steve.hudson AT ironmountain DOT com
>
>
> Visit the new www.ironmountain.com
> Tour Iron Mountain
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of WEAVER,
> Simon (external)
> Sent: Friday, March 27, 2009 7:59 AM
> To: VERITAS-BU AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Not all drives appear to be used
>
> Just one question on this....
>
> Doesnt "nbrbutil" release the locks when the Server is rebooted?
>
> Simon
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
> mcw012765
> Sent: Friday, March 27, 2009 10:52 AM
> To: VERITAS-BU AT mailman.eng.auburn DOT edu
> Subject: [Veritas-bu] Not all drives appear to be used
>
>
> I tried all of the suggestions and still had the problem. I contacted
> Symantec and we got it fixed. Here is a summary:
>
> ISSUE REPORTED: Not all 10 drives are in use at any given time backups
> will use only 8 drives randomly. But it will always be any 2 drives out
> of the 10 that won't be used.
>
> INITIAL INVESTIGATION:
> -Max jobs per client is set to 99 under Host Properties >> Master Server
>>> Global Attributes -Max concurrent drives is set to 10 under Storage
> Units >> Problem Storage Unit.
>
> TROUBLESHOOTING:
> -Ran robtest (s d) to check if the two drives already had a tape stuck
> in them. No.
> -Guessing that it is an nbrb allocation issue.
> -We ran <Install Drive>:\Veritas\netbackup\bin\admincmd\nbrbutil -dump
> to check the point in time MDS Allocations within EMM.
> -Saw two orphaned allocations without any attributes matching current
> allocations.
>
> MdsAllocation allocationKey=7191130 jobType=16 mediaKey=4002098
> mediaId=002033 driveKey=0 driveName= drivePath= stuName=
> masterServerName=mfbback01 mediaServerName=mfbback01 ndmpTapeServerName=
> diskVolumeKey=0 mountKey=0 linkKey=0 fatPipeKey=0 scsiResType=0
> serverStateFlags=0
>
> MdsAllocation allocationKey=7191132 jobType=16 mediaKey=4000992
> mediaId=002016 driveKey=0 driveName= drivePath= stuName=
> masterServerName=mfbback01 mediaServerName=mfbback01 ndmpTapeServerName=
> diskVolumeKey=0 mountKey=0 linkKey=0 fatPipeKey=0 scsiResType=0
> serverStateFlags=0
>
> -Looks like nbrb is holding up further resource allocation due to these
> orphaned alloc holds.
>
> -Released the holds by running nbrbutil -releasemds <allocation key as
> underline above> -Verified last written date on one of the media by
> running nbemmcmd -listmedia -mediaid 002033. It was dating back to 30th
> January 2009.
> -This is roughly the time frame when the issue started.
> -After releasing the holds we are now able to fire up jobs on them
> drives.
>
>
> Thanks to everyone for your suggestions. I think I am seeing
> improvement from setting the max jobs higher.
>
> +----------------------------------------------------------------------
> |This was sent by mweathe AT fbinsmi DOT com via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from
> disclosure. If you are not the intended recipient, please notify the
> sender immediately, do not copy this message or any attachments and do
> not use it for any purpose or disclose its content to any person, but
> delete this message and any attachments from your system. Astrium
> disclaims any and all liability if this email transmission was virus
> corrupted, altered or falsified.
> -o-
> Astrium Limited, Registered in England and Wales No. 2449259 Registered
> Office:
> Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> The information contained in this email message and its attachments is
> intended only for the private and confidential use of the recipient(s)
> named above, unless the sender expressly agrees otherwise. Transmission
> of email over the Internet is not a secure communications medium. If
> you are requesting or have requested the transmittal of personal data,
> as defined in applicable privacy laws by means of email or in an
> attachment to email you must select a more secure alternate means of
> transmittal that supports your obligations to protect such personal
> data. If the reader of this message is not the intended recipient and/or
> you have received this email in error, you must take no action based on
> the information in this email and you are hereby notified that any
> dissemination, misuse, copying, or disclosure of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify us immediately by email and delete the original message.
>
> This email (including any attachments) may contain confidential
> and/or privileged information or information otherwise protected
> from disclosure. If you are not the intended recipient, please
> notify the sender immediately, do not copy this message or any
> attachments and do not use it for any purpose or disclose its
> content to any person, but delete this message and any attachments
> from your system. Astrium disclaims any and all liability if this
> email transmission was virus corrupted, altered or falsified.
> -o-
> Astrium Limited, Registered in England and Wales No. 2449259
> Registered Office:
> Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 30 Mar 2009 07:38:50 -0400 (EDT)
> From: Justin Piszcz <jpiszcz AT lucidpixels DOT com>
> Subject: [Veritas-bu] Moving the NetBackup Master Server from host A
> to B.
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Message-ID: <alpine.DEB.2.00.0903300720010.32152 AT p34.internal DOT lan>
> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>
> Hello all,
>
> I have been using NetBackup for several years now, and, we all know
> you cannot officially change the master server hostname and then
> perform a catalog restore onto a new host and then expect everything
> to work just fine.
>
> I have a few questions/was wondering, is there anyway to work-around
> this, here are my thoughts/ideas, I am looking for any suggestions that
> may help to facilitate moving the master from one host to another as
> time progresses, you want to move your master onto new hardware to
> keep up with the times, now, for the questions:
>
> 1. During an initial NetBackup 6.5.x installation, it asks you for the
> name of the server and for the name of the EMM server. Has anyone
> tried using a generic name here, rather than using the hostname of
> the box?
>
> For example, say my master server hostname is: widget.mycompany.com
>
> Now, during the installation process, I *presume* if I enter in some
> random name, it will not work unless its in the /etc/hosts file,
> therefore, add this to /etc/hosts:
>
> 127.0.0.1 nbkupsvr1
>
> Now, is it possible to install NetBackup specifying the server name
> as nbkupsvr1 and the EMM server name as the same thing?
>
> The idea here, would then be, on the second server where you plan on
> "migrating" NetBackup to, you add that same entry into /etc/hosts and
> then perform a catalog restore, would this bring back the environment
> exactly as it was onto the new host?
>
> Why am I asking this? If such a method were possible, then one
> would not need to import tapes or do anything special other than a
> regular catalog backup, scp it to the second machine and perform a
> catalog restore.
>
> I know the name of the master is hardcoded into all of the backup
> images, but if you define it in the beginning, can it be a generic
> name as long as that name is added to /etc/hosts?
>
> --
>
> If this idea will not work, what other options are available to
> move from host A to host B without getting rid of host A first (or
> disconnecting it from the network etc) because host B has to have
> the same hostname as host A?
>
> I look forward towards any and all ideas ang suggestions, thank you.
>
> --
>
> Note, I am aware of the -dpath option to another server but was told this
> is not recommended.
>
> Justin.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 30 Mar 2009 09:25:09 -0400
> From: "McDonald II, James F." <JAMES.F.MCDONALD.II AT saic DOT com>
> Subject: [Veritas-bu] Robotic Path error
> To: <veritas-bu AT mailman.eng.auburn DOT edu>
> Message-ID:
> <40624AE38EC69E4D9F986F401541F8C913E63B59 AT 0905-B043-EXMB1.iisbu.saic
> DOT com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> All,
>
>
>
> I started getting error code 201, "unable to open robotic path." I am
> unable to inventory the robot or run diagnostics, and I haven't been
> able to execute my policies. As far as I can tell, everything is
> configured correctly within NBU. I replaced the SCSI cable and I have
> run the "configure robot" portion of the wizard, as a safe measure. I
> used the driver included with the NBU software to connect my Quantum
> Superloader3 and it was working fine. This error started popping up out
> of the blue a few days ago and I have been unable to resolve it.
>
>
>
> Also, I downloaded and installed the Linux client. Do you need xinetd
> installed/running for the Linux NBU client and NBU master to see each
> other?
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20090330/d822222e/attachment-0001.htm
>
> ------------------------------
>
> Message: 8
> Date: Mon, 30 Mar 2009 09:51:32 -0400 (EDT)
> From: Justin Piszcz <jpiszcz AT lucidpixels DOT com>
> Subject: Re: [Veritas-bu] Robotic Path error
> To: "McDonald II, James F." <JAMES.F.MCDONALD.II AT saic DOT com>
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Message-ID: <alpine.DEB.2.00.0903300951110.32152 AT p34.internal DOT lan>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
>
> On Mon, 30 Mar 2009, McDonald II, James F. wrote:
>
>> All,
>>
>>
>>
>> I started getting error code 201, "unable to open robotic path." I am
>> unable to inventory the robot or run diagnostics, and I haven't been
>> able to execute my policies. As far as I can tell, everything is
>> configured correctly within NBU. I replaced the SCSI cable and I have
>> run the "configure robot" portion of the wizard, as a safe measure. I
>> used the driver included with the NBU software to connect my Quantum
>> Superloader3 and it was working fine. This error started popping up out
>> of the blue a few days ago and I have been unable to resolve it.
>>
>>
>>
>> Also, I downloaded and installed the Linux client. Do you need xinetd
>> installed/running for the Linux NBU client and NBU master to see each
>> other?
>>
>>
>
> If you run robtest locally on the robotic controller host, can you type "s
> d" or "s s" to see the tape drives and tapes respectively?
>
> Justin.
>
>
> ------------------------------
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
> End of Veritas-bu Digest, Vol 35, Issue 56
> ******************************************
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
>
>
> ________________________________________________
> This email and any attachments are confidential and may contain privileged
> information.
> If you are not the person for whom they are intended please return the email
> and then delete all material from any computer. You must not use the email or
> attachments for any purpose, nor disclose its contents to anyone other than
> the intended recipient.
> Any statements made by an individual in this email do not necessarily reflect
> the views of the Yorkshire Building Society Group.
> ________________________________________________
>
> Yorkshire Building Society, which is authorised and regulated by the
> Financial Services Authority, chooses to introduce its customers to:
>
> -Legal & General for the purposes of advising on and arranging life assurance
> and investment products bearing Legal & General's name;
> and
> -Homeowners Friendly Society for the purpose of arranging stakeholder Child
> Trust Funds.
>
> We are entered in the FSA Register and our FSA registration number is 106085
> http://www.fsa.gov.uk/register
>
> Head Office: Yorkshire Building Society, Yorkshire House, Yorkshire Drive,
> Bradford, BD5 8LJ
> Tel: 0845 1 200 100
>
> Visit Our Website
> http://www.ybs.co.uk
>
> All communications with us may be monitored/recorded to improve the quality
> of our service and for your protection and security.
>
>
>
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
