Archlog copy from tape to disk

Dale PENROD

Archlog copy from tape to disk
I ran into this opportunity at our last Disaster Recovery exercise, can
anyone help me out?

After the operating system was restored and the DB2 system was restored
successfully, we started the forward recovery of the users data under DB2.
The recovery procedure called in the ARCHLOG which lived on tape. You can
already see the problem, single threaded recovery.

At one time, I was entertaining the idea of doing an IEBGENER of the ARCHLOG
to DASD, then do the forward recoveries as DISP=SHR against the DASD ARCHLOG
file. I was told this process would mess with DB2 timestamps, as DB2 would
view the IEBGENER copied date as the DB2 timestamp. I am not a DB2 guru,
but this doesn't sound completely right to me. I still believe copying the
ARCHLOG to DASD is the way to speed up the forward recovery process.

My question, can anyone share with me a way to get tape ARCHLOG data to DASD
so DB2 can do forward recovery more efficiently and without introducing any
timestamp issues?

Thanks,
Dale Penrod
[login to unmask email]

Alan Dishowitz

Re: Archlog copy from tape to disk
(in response to Dale PENROD)
Dale,

I've done this a couple of times, and I didn't run into any timestamp
issues. Just be sure to run DSNJU003 twice after using IEBGENER: once to
delete the old Archive Log from the BSDS, and again to define the DASD copy
of the Archive Log to the BSDS.

Hope this helps,

Alan Dishowitz, CSC FSG

-----Original Message-----
> From: PENROD, Dale [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 12:16 PM
> To: [login to unmask email]
> Subject: Archlog copy from tape to disk
>
> I ran into this opportunity at our last Disaster Recovery exercise, can
> anyone help me out?
>
> After the operating system was restored and the DB2 system was restored
> successfully, we started the forward recovery of the users data under DB2.
> The recovery procedure called in the ARCHLOG which lived on tape. You can
> already see the problem, single threaded recovery.
>
> At one time, I was entertaining the idea of doing an IEBGENER of the
> ARCHLOG
> to DASD, then do the forward recoveries as DISP=SHR against the DASD
> ARCHLOG
> file. I was told this process would mess with DB2 timestamps, as DB2
> would
> view the IEBGENER copied date as the DB2 timestamp. I am not a DB2 guru,
> but this doesn't sound completely right to me. I still believe copying
> the
> ARCHLOG to DASD is the way to speed up the forward recovery process.
>
> My question, can anyone share with me a way to get tape ARCHLOG data to
> DASD
> so DB2 can do forward recovery more efficiently and without introducing
> any
> timestamp issues?
>
> Thanks,
> Dale Penrod
> [login to unmask email]

Missy Case

Re: Archlog copy from tape to disk
(in response to Alan Dishowitz)
Dale,

We have used for the last 4 tests & one more next month the following JCL -
you were right and someone was mistaken:

It worked great for us - good luck!* One tip - make sure your sizes
match - this was set up to match our active/archive log sizes.


//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//* GENER ARCHIVE LOGS TO DISK.
//* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=DISASTER.BAD1.DB2A.ARCHLOGD.A???????,DISP=SHR
//SYSUT2 DD DSN=SYS2.DB2A.ARCHLOGD.A???????,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(200,20),RLSE),
// DCB=(RECFM=FB,LRECL=4096,BLKSIZE=28672)
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=DISASTER.BAD1.DB2A.ARCHLOGD.A???????,DISP=SHR
//SYSUT2 DD DSN=SYS2.DB2A.ARCHLOGD.A???????,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(200,20),RLSE),

Missy Case
North Dakota - Life in the VAST Lane!

PKS Computer IUnfrastructure Services, LLC
Omaha, NE
> -----Original Message-----
> From: PENROD, Dale [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 12:16 PM
> To: [login to unmask email]
> Subject: Archlog copy from tape to disk
>
> I ran into this opportunity at our last Disaster Recovery exercise, can
> anyone help me out?
>
> After the operating system was restored and the DB2 system was restored
> successfully, we started the forward recovery of the users data under DB2.
> The recovery procedure called in the ARCHLOG which lived on tape. You can
> already see the problem, single threaded recovery.
>
> At one time, I was entertaining the idea of doing an IEBGENER of the
> ARCHLOG
> to DASD, then do the forward recoveries as DISP=SHR against the DASD
> ARCHLOG
> file. I was told this process would mess with DB2 timestamps, as DB2
> would
> view the IEBGENER copied date as the DB2 timestamp. I am not a DB2 guru,
> but this doesn't sound completely right to me. I still believe copying
> the
> ARCHLOG to DASD is the way to speed up the forward recovery process.
>
> My question, can anyone share with me a way to get tape ARCHLOG data to
> DASD
> so DB2 can do forward recovery more efficiently and without introducing
> any
> timestamp issues?
>
> Thanks,
> Dale Penrod
> [login to unmask email]

Eric Harper st17

Re: Archlog copy from tape to disk
(in response to Missy Case)
I too have done this. No timestamp problems. But you have to let DB2
know that the device changed. Here's a sample of DSNJU003. I included
the delete and registration of the active logs, in case anyone was
interested.

//DB2UHOH JOB (98060),'DB2-DISASTER RCVY',CLASS=A,
// NOTIFY=HARPERE,MSGCLASS=X,TIME=1439,REGION=4M
//*
//* ========
//* ==== I N S T R U C T I O N S ====
//* ==== ====
//* ==== 1. CHG '*_*' 1 OR 2, FOR LOG COPY USED. ====
//* ==== 2. CHG DASDC? TO VOLUME FOR CURRENT ARCHLOG ====
//* ==== PLACEMENT. ====
//* ==== 3. CHG DASDP? TO VOLUME FOR PREVIOUS ARCHLOG ====
//* ==== PLACEMENT. ====
//* ==== 4. CHG 'C00????' TO GDG FOR CURRENT ARCHLOG. ====
//* ==== 5. CHG 'P00????' TO GDG FOR PREVIOUS ARCHLOG. ====
//* ==== 6. CHG 'C#####' TO VOLSER FOR CURRENT LOG TAPE====
//* ==== 7. CHG 'P1####' TO VOLSER FOR PREV LOG TAPE ====
//* ==== COPY 1. ====
//* ==== 8. CHG 'P2####' TO VOLSER FOR PREV LOG TAPE ====
//* ==== COPY 2. ====
//* ==== .9. CHG THE RBAS AS IN THE PROCEDURES. ====
//* ========
//*
//*
//*========
//ARCHLOG1 EXEC PGM=IEBGENER ====
//*========
//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AC00????,
// UNIT=TAPE,
// VOL=SER=C#####,
// LABEL=(2,SL,,,EXPDT=98000),
// DISP=SHR
//*
//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,
// UNIT=DISK,VOL=SER=DASDC?,
// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
// SPACE=(CYL,(200,50),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//*========
//ARCHLOG2 EXEC PGM=IEBGENER ====
//*========
//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AP00????,
// UNIT=TAPE,
// VOL=SER=P*_*####,
// LABEL=(2,SL,,,EXPDT=98000),
// DISP=SHR
//*
//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,
// UNIT=DISK,VOL=SER=DASDP?,
// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
// SPACE=(CYL,(200,50),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//*
//* .... USE CHANGE LOG INVENTORY TO 'ZAP' IN CRCR RECORD ....
//*
//*=============
//CHGLGINV EXEC PGM=DSNJU003 ====
//*=============
//*
//SYSUT1 DD DSN=DBA2PDB2.DB2P.BSDS01,DISP=SHR
//SYSUT2 DD DSN=DBA2PDB2.DB2P.BSDS02,DISP=SHR
//SYSIN DD *
DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG1.AP00????,COPY1VOL=P1####
DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG2.AP00????,COPY2VOL=P2####
NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,CATALOG=YES,
COPY1VOL=DASDP?,STARTRBA=PS???000,ENDRBA=PE???FFF,UNIT=WORK
NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,CATALOG=YES,
COPY1VOL=DASDC?,STARTRBA=CS???000,ENDRBA=CE???FFF,UNIT=WORK
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04,COPY2
CRESTART CREATE,ENDRBA=?????000
//SYSPRINT DD SYSOUT=*
//*

Later,
Eric Harper
Rose International
[login to unmask email] <mailto:[login to unmask email]>
(888) 430-7673 x17





-----Original Message-----
From: Alan Dishowitz [mailto:[login to unmask email]
Sent: Wednesday, October 06, 1999 11:44 AM
To: [login to unmask email]
Subject: Re: Archlog copy from tape to disk

Dale,

I've done this a couple of times, and I didn't run into any
timestamp
issues. Just be sure to run DSNJU003 twice after using
IEBGENER: once to
delete the old Archive Log from the BSDS, and again to
define the DASD copy
of the Archive Log to the BSDS.

Hope this helps,

Alan Dishowitz, CSC FSG

-----Original Message-----
> From: PENROD, Dale [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 12:16 PM
> To: [login to unmask email]
> Subject: Archlog copy from tape to disk
>
> I ran into this opportunity at our last Disaster Recovery
exercise, can
> anyone help me out?
>
> After the operating system was restored and the DB2 system
was restored
> successfully, we started the forward recovery of the users
data under DB2.
> The recovery procedure called in the ARCHLOG which lived
on tape. You can
> already see the problem, single threaded recovery.
>
> At one time, I was entertaining the idea of doing an
IEBGENER of the
> ARCHLOG
> to DASD, then do the forward recoveries as DISP=SHR
against the DASD
> ARCHLOG
> file. I was told this process would mess with DB2
timestamps, as DB2
> would
> view the IEBGENER copied date as the DB2 timestamp. I am
not a DB2 guru,
> but this doesn't sound completely right to me. I still
believe copying
> the
> ARCHLOG to DASD is the way to speed up the forward
recovery process.
>
> My question, can anyone share with me a way to get tape
ARCHLOG data to
> DASD
> so DB2 can do forward recovery more efficiently and
without introducing
> any
> timestamp issues?
>
> Thanks,
> Dale Penrod
> [login to unmask email]

Roy Brickley

Re: Archlog copy from tape to disk
(in response to Eric Harper st17)
Eric,

I've seen two posts that have the DCB with BLKSIZE=28672, and I
recall having to do that for DB V3 D/R test, so it would match the
tape blocksize. When I copy this to a 3393 RAID device, it used many
extents. When I copied it with no DCB on the SYSUT2 dataset, the
IEBGENER ran fine and I got a BLKSIZE=24576 on the DASD file and much
less DASD space (300 cylinders compared to 470+ cylinders for 28672).

I didn't get the chance to have the D/R test use these DASD archive
logs, as my RBA info was offset in the DSNJU003 and the only hours I
had to do this were between midnight and 6 AM - I just couldn't get
all those RBA's straight! I even used a REXX program to read the
DSNJU004 logmap output to set up the RBA's - I found out the hard way
that DSNJU004 output changes from DB2 V3 to DB2 V4 (and probably every
release!).

So, if I let IEBGENER determine the best blocksize for the DASD
copy, will DB2 be able to read the archive log? I ran DSN1LOGP against
both versions without problems.

Thanks,

Roy Brickley
Systems Programmer
ACS, Inc.


______________________________ Reply Separator _________________________________
Subject: Re: Archlog copy from tape to disk
Author: DB2 Data Base Discussion List <[login to unmask email]> at INTERNET-GATEWAY
Date: 10/06/1999 2:25 PM


I too have done this. No timestamp problems. But you have to let DB2
know that the device changed. Here's a sample of DSNJU003. I included
the delete and registration of the active logs, in case anyone was
interested.

//DB2UHOH JOB (98060),'DB2-DISASTER RCVY',CLASS=A,
// NOTIFY=HARPERE,MSGCLASS=X,TIME=1439,REGION=4M
//*
//* ========
//* ==== I N S T R U C T I O N S ====
//* ==== ====
//* ==== 1. CHG '*_*' 1 OR 2, FOR LOG COPY USED. ====
//* ==== 2. CHG DASDC? TO VOLUME FOR CURRENT ARCHLOG ====
//* ==== PLACEMENT. ====
//* ==== 3. CHG DASDP? TO VOLUME FOR PREVIOUS ARCHLOG ====
//* ==== PLACEMENT. ====
//* ==== 4. CHG 'C00????' TO GDG FOR CURRENT ARCHLOG. ====
//* ==== 5. CHG 'P00????' TO GDG FOR PREVIOUS ARCHLOG. ====
//* ==== 6. CHG 'C#####' TO VOLSER FOR CURRENT LOG TAPE====
//* ==== 7. CHG 'P1####' TO VOLSER FOR PREV LOG TAPE ====
//* ==== COPY 1. ====
//* ==== 8. CHG 'P2####' TO VOLSER FOR PREV LOG TAPE ====
//* ==== COPY 2. ====
//* ==== .9. CHG THE RBAS AS IN THE PROCEDURES. ====
//* ========
//*
//*
//*========
//ARCHLOG1 EXEC PGM=IEBGENER ====
//*========
//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AC00????,
// UNIT=TAPE,
// VOL=SER=C#####,
// LABEL=(2,SL,,,EXPDT=98000),
// DISP=SHR
//*
//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,
// UNIT=DISK,VOL=SER=DASDC?,
// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
// SPACE=(CYL,(200,50),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//*========
//ARCHLOG2 EXEC PGM=IEBGENER ====
//*========
//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AP00????,
// UNIT=TAPE,
// VOL=SER=P*_*####,
// LABEL=(2,SL,,,EXPDT=98000),
// DISP=SHR
//*
//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,
// UNIT=DISK,VOL=SER=DASDP?,
// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
// SPACE=(CYL,(200,50),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//*
//* .... USE CHANGE LOG INVENTORY TO 'ZAP' IN CRCR RECORD ....
//*
//*=============
//CHGLGINV EXEC PGM=DSNJU003 ====
//*=============
//*
//SYSUT1 DD DSN=DBA2PDB2.DB2P.BSDS01,DISP=SHR
//SYSUT2 DD DSN=DBA2PDB2.DB2P.BSDS02,DISP=SHR
//SYSIN DD *
DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG1.AP00????,COPY1VOL=P1####
DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG2.AP00????,COPY2VOL=P2####
NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,CATALOG=YES,
COPY1VOL=DASDP?,STARTRBA=PS???000,ENDRBA=PE???FFF,UNIT=WORK
NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,CATALOG=YES,
COPY1VOL=DASDC?,STARTRBA=CS???000,ENDRBA=CE???FFF,UNIT=WORK
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04,COPY2
CRESTART CREATE,ENDRBA=?????000
//SYSPRINT DD SYSOUT=*
//*

Later,
Eric Harper
Rose International
[login to unmask email] <mailto:[login to unmask email]>
(888) 430-7673 x17





-----Original Message-----
From: Alan Dishowitz [mailto:[login to unmask email]
Sent: Wednesday, October 06, 1999 11:44 AM
To: [login to unmask email]
Subject: Re: Archlog copy from tape to disk

Dale,

I've done this a couple of times, and I didn't run into any
timestamp
issues. Just be sure to run DSNJU003 twice after using
IEBGENER: once to
delete the old Archive Log from the BSDS, and again to
define the DASD copy
of the Archive Log to the BSDS.

Hope this helps,

Alan Dishowitz, CSC FSG

-----Original Message-----
> From: PENROD, Dale [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 12:16 PM
> To: [login to unmask email]
> Subject: Archlog copy from tape to disk
>
> I ran into this opportunity at our last Disaster Recovery
exercise, can
> anyone help me out?
>
> After the operating system was restored and the DB2 system
was restored
> successfully, we started the forward recovery of the users
data under DB2.
> The recovery procedure called in the ARCHLOG which lived
on tape. You can
> already see the problem, single threaded recovery.
>
> At one time, I was entertaining the idea of doing an
IEBGENER of the
> ARCHLOG
> to DASD, then do the forward recoveries as DISP=SHR
against the DASD
> ARCHLOG
> file. I was told this process would mess with DB2
timestamps, as DB2
> would
> view the IEBGENER copied date as the DB2 timestamp. I am
not a DB2 guru,
> but this doesn't sound completely right to me. I still
believe copying
> the
> ARCHLOG to DASD is the way to speed up the forward
recovery process.
>
> My question, can anyone share with me a way to get tape
ARCHLOG data to
> DASD
> so DB2 can do forward recovery more efficiently and
without introducing
> any
> timestamp issues?
>
> Thanks,
> Dale Penrod
> [login to unmask email]

Leslie Pendlebury-Bowe

Re: Archlog copy from tape to disk
(in response to Roy Brickley)
I agree with this .. we do this every time at our DR tests.

Leslie
Fastrack Information Systems


______________________________ Reply Separator _________________________________
Subject: Re: Archlog copy from tape to disk
Author: Alan Dishowitz <[login to unmask email]> at Internet
Date: 10/6/99 12:43 PM


Dale,

I've done this a couple of times, and I didn't run into any timestamp
issues. Just be sure to run DSNJU003 twice after using IEBGENER: once to
delete the old Archive Log from the BSDS, and again to define the DASD copy
of the Archive Log to the BSDS.

Hope this helps,

Alan Dishowitz, CSC FSG

-----Original Message-----
> From: PENROD, Dale [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 12:16 PM
> To: [login to unmask email]
> Subject: Archlog copy from tape to disk
>
> I ran into this opportunity at our last Disaster Recovery exercise, can
> anyone help me out?
>
> After the operating system was restored and the DB2 system was restored
> successfully, we started the forward recovery of the users data under DB2.
> The recovery procedure called in the ARCHLOG which lived on tape. You can
> already see the problem, single threaded recovery.
>
> At one time, I was entertaining the idea of doing an IEBGENER of the
> ARCHLOG
> to DASD, then do the forward recoveries as DISP=SHR against the DASD
> ARCHLOG
> file. I was told this process would mess with DB2 timestamps, as DB2
> would
> view the IEBGENER copied date as the DB2 timestamp. I am not a DB2 guru,
> but this doesn't sound completely right to me. I still believe copying
> the
> ARCHLOG to DASD is the way to speed up the forward recovery process.
>
> My question, can anyone share with me a way to get tape ARCHLOG data to
> DASD
> so DB2 can do forward recovery more efficiently and without introducing
> any
> timestamp issues?
>
> Thanks,
> Dale Penrod
> [login to unmask email]

Piontkowski Michael ML

Re: Archlog copy from tape to disk
(in response to Leslie Pendlebury-Bowe)
We also copy the current and 2nd current ARCHLOG from tape to
disk using IEBGENER and the same data set name. We update
the BSDS (both of them) using DSNJU003 - remove tape ARCHLOG
entry and add DASD ARCHLOG entry. We also alter the ICF catalog
entries for the ARCHLOG data sets - helps keep things consistent.

When removing and adding the BSDS ARCHLOG entries be careful
to ensure the RBA range of an ARCHLOG entry is correct.


Mike Piontkowski
Voice/Fax: 302.886.4612
mailto:[login to unmask email]

> ----------
> From: Leslie
> Pendlebury-Bowe[SMTP:[login to unmask email]
> Sent: Thursday, October 07, 1999 2:46 AM
> To: [login to unmask email]
> Subject: Re: [DB2-L] Archlog copy from tape to disk
>
> I agree with this .. we do this every time at our DR tests.
>
> Leslie
> Fastrack Information Systems
>
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Re: Archlog copy from tape to disk
> Author: Alan Dishowitz <[login to unmask email]> at Internet
> Date: 10/6/99 12:43 PM
>
>
> Dale,
>
> I've done this a couple of times, and I didn't run into any timestamp
> issues. Just be sure to run DSNJU003 twice after using IEBGENER: once to
> delete the old Archive Log from the BSDS, and again to define the DASD
> copy
> of the Archive Log to the BSDS.
>
> Hope this helps,
>
> Alan Dishowitz, CSC FSG
>
> -----Original Message-----
> > From: PENROD, Dale [SMTP:[login to unmask email]
> > Sent: Wednesday, October 06, 1999 12:16 PM
> > To: [login to unmask email]
> > Subject: Archlog copy from tape to disk
> >
> > I ran into this opportunity at our last Disaster Recovery exercise, can
> > anyone help me out?
> >
> > After the operating system was restored and the DB2 system was restored
> > successfully, we started the forward recovery of the users data under
> DB2.
> > The recovery procedure called in the ARCHLOG which lived on tape. You
> can
> > already see the problem, single threaded recovery.
> >
> > At one time, I was entertaining the idea of doing an IEBGENER of the
> > ARCHLOG
> > to DASD, then do the forward recoveries as DISP=SHR against the DASD
> > ARCHLOG
> > file. I was told this process would mess with DB2 timestamps, as DB2
> > would
> > view the IEBGENER copied date as the DB2 timestamp. I am not a DB2
> guru,
> > but this doesn't sound completely right to me. I still believe copying
> > the
> > ARCHLOG to DASD is the way to speed up the forward recovery process.
> >
> > My question, can anyone share with me a way to get tape ARCHLOG data to
> > DASD
> > so DB2 can do forward recovery more efficiently and without introducing
> > any
> > timestamp issues?
> >
> > Thanks,
> > Dale Penrod
> > [login to unmask email]
>

[login to unmask email]

Re: Archlog copy from tape to disk
(in response to Piontkowski Michael ML)
Roy/Eric,

You have to have the same BLKSIZE. If they are different, DB2 will
have difficulty finding some (but not all!) log records. We had
problems with this ages ago in a DR test. DB2 kept giving an error
message along the lines of "can't find log/archlog blah blah..."
and would not complete the recover. But only for one or two logs
in one or two jobs....very odd.

We recopied them from tape to disk with the DCB override, and
everything was fine. I did find an entry in IBMLINK regarding
the logs & blksize - unfortunately, I no longer have that entry
number to give you.

This may have changed in newer versions of DB2 (that was V3 or V4
when we had problems) but I wouldn't count on it....


Greg Palgrave
Database Administration Group
Bank of Western Australia



Roy Brickley <[login to unmask email]> on 07/10/99 05:58:14

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

To: [login to unmask email]
cc: (bcc: Greg Palgrave/SDG/SS/BankWest)

Subject: Re: Archlog copy from tape to disk




Eric,

I've seen two posts that have the DCB with BLKSIZE=28672, and I
recall having to do that for DB V3 D/R test, so it would match the
tape blocksize. When I copy this to a 3393 RAID device, it used many
extents. When I copied it with no DCB on the SYSUT2 dataset, the
IEBGENER ran fine and I got a BLKSIZE=24576 on the DASD file and much
less DASD space (300 cylinders compared to 470+ cylinders for 28672).

I didn't get the chance to have the D/R test use these DASD archive
logs, as my RBA info was offset in the DSNJU003 and the only hours I
had to do this were between midnight and 6 AM - I just couldn't get
all those RBA's straight! I even used a REXX program to read the
DSNJU004 logmap output to set up the RBA's - I found out the hard way
that DSNJU004 output changes from DB2 V3 to DB2 V4 (and probably every
release!).

So, if I let IEBGENER determine the best blocksize for the DASD
copy, will DB2 be able to read the archive log? I ran DSN1LOGP against
both versions without problems.

Thanks,

Roy Brickley
Systems Programmer
ACS, Inc.


______________________________ Reply Separator
_________________________________
Subject: Re: Archlog copy from tape to disk
Author: DB2 Data Base Discussion List <[login to unmask email]> at INTERNET-GATEWAY
Date: 10/06/1999 2:25 PM


I too have done this. No timestamp problems. But you have to let DB2
know that the device changed. Here's a sample of DSNJU003. I included
the delete and registration of the active logs, in case anyone was
interested.

//DB2UHOH JOB (98060),'DB2-DISASTER RCVY',CLASS=A,
// NOTIFY=HARPERE,MSGCLASS=X,TIME=1439,REGION=4M
//*
//* ========
//* ==== I N S T R U C T I O N S ====
//* ==== ====
//* ==== 1. CHG '*_*' 1 OR 2, FOR LOG COPY USED. ====
//* ==== 2. CHG DASDC? TO VOLUME FOR CURRENT ARCHLOG ====
//* ==== PLACEMENT. ====
//* ==== 3. CHG DASDP? TO VOLUME FOR PREVIOUS ARCHLOG ====
//* ==== PLACEMENT. ====
//* ==== 4. CHG 'C00????' TO GDG FOR CURRENT ARCHLOG. ====
//* ==== 5. CHG 'P00????' TO GDG FOR PREVIOUS ARCHLOG. ====
//* ==== 6. CHG 'C#####' TO VOLSER FOR CURRENT LOG TAPE====
//* ==== 7. CHG 'P1####' TO VOLSER FOR PREV LOG TAPE ====
//* ==== COPY 1. ====
//* ==== 8. CHG 'P2####' TO VOLSER FOR PREV LOG TAPE ====
//* ==== COPY 2. ====
//* ==== .9. CHG THE RBAS AS IN THE PROCEDURES. ====
//* ========
//*
//*
//*========
//ARCHLOG1 EXEC PGM=IEBGENER ====
//*========
//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AC00????,
// UNIT=TAPE,
// VOL=SER=C#####,
// LABEL=(2,SL,,,EXPDT=98000),
// DISP=SHR
//*
//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,
// UNIT=DISK,VOL=SER=DASDC?,
// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
// SPACE=(CYL,(200,50),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//*========
//ARCHLOG2 EXEC PGM=IEBGENER ====
//*========
//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AP00????,
// UNIT=TAPE,
// VOL=SER=P*_*####,
// LABEL=(2,SL,,,EXPDT=98000),
// DISP=SHR
//*
//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,
// UNIT=DISK,VOL=SER=DASDP?,
// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
// SPACE=(CYL,(200,50),RLSE),
// DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//*
//* .... USE CHANGE LOG INVENTORY TO 'ZAP' IN CRCR RECORD ....
//*
//*=============
//CHGLGINV EXEC PGM=DSNJU003 ====
//*=============
//*
//SYSUT1 DD DSN=DBA2PDB2.DB2P.BSDS01,DISP=SHR
//SYSUT2 DD DSN=DBA2PDB2.DB2P.BSDS02,DISP=SHR
//SYSIN DD *
DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG1.AP00????,COPY1VOL=P1####
DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG2.AP00????,COPY2VOL=P2####
NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,CATALOG=YES,
COPY1VOL=DASDP?,STARTRBA=PS???000,ENDRBA=PE???FFF,UNIT=WORK
NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,CATALOG=YES,
COPY1VOL=DASDC?,STARTRBA=CS???000,ENDRBA=CE???FFF,UNIT=WORK
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03
DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04,COPY1
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03,COPY2
NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04,COPY2
CRESTART CREATE,ENDRBA=?????000
//SYSPRINT DD SYSOUT=*
//*

Later,
Eric Harper
Rose International
[login to unmask email] <mailto:[login to unmask email]>
(888) 430-7673 x17





-----Original Message-----
From: Alan Dishowitz [mailto:[login to unmask email]
Sent: Wednesday, October 06, 1999 11:44 AM
To: [login to unmask email]
Subject: Re: Archlog copy from tape to disk

Dale,

I've done this a couple of times, and I didn't run into any
timestamp
issues. Just be sure to run DSNJU003 twice after using
IEBGENER: once to
delete the old Archive Log from the BSDS, and again to
define the DASD copy
of the Archive Log to the BSDS.

Hope this helps,

Alan Dishowitz, CSC FSG

-----Original Message-----
> From: PENROD, Dale [SMTP:[login to unmask email]
> Sent: Wednesday, October 06, 1999 12:16 PM
> To: [login to unmask email]
> Subject: Archlog copy from tape to disk
>
> I ran into this opportunity at our last Disaster Recovery
exercise, can
> anyone help me out?
>
> After the operating system was restored and the DB2
system
was restored
> successfully, we started the forward recovery of the
users
data under DB2.
> The recovery procedure called in the ARCHLOG which lived
on tape. You can
> already see the problem, single threaded recovery.
>
> At one time, I was entertaining the idea of doing an
IEBGENER of the
> ARCHLOG
> to DASD, then do the forward recoveries as DISP=SHR
against the DASD
> ARCHLOG
> file. I was told this process would mess with DB2
timestamps, as DB2
> would
> view the IEBGENER copied date as the DB2 timestamp. I am
not a DB2 guru,
> but this doesn't sound completely right to me. I still
believe copying
> the
> ARCHLOG to DASD is the way to speed up the forward
recovery process.
>
> My question, can anyone share with me a way to get tape
ARCHLOG data to
> DASD
> so DB2 can do forward recovery more efficiently and
without introducing
> any
> timestamp issues?
>
> Thanks,
> Dale Penrod
> [login to unmask email]





_______________________________________________________________________________
Unencrypted electronic mail is not secure and may not be authentic.
If you have any doubts as to the contents please telephone to confirm.

This electronic transmission is intended only for those to whom it is
addressed. It may contain information that is confidential, privileged
or exempt from disclosure by law. Any claim to privilege is not waived
or lost by reason of mistaken transmission of this information.
If you are not the intended recipient you must not distribute or copy this
transmission and should please notify the sender. Your costs for doing
this will be reimbursed by the sender.
_______________________________________________________________________________

Rick Creech

Re: Archlog copy from tape to disk
(in response to Greg.Palgrave@BANKWEST.COM.AU)
Another issue to be aware of with the logs: To avoid problems copying a tape
archive log to the active log, there is an very good description of the
issues and how to determine the correct blksize in the DB2 ADMIN GUIDE under
the heading "Determining the Size of the Active logs". Quoting: "We
recommend that the number of records for the active log be divisible by the
blocking factor of the archive log." etc.

Rick Creech
DBA - Saks Inc.

>From: [login to unmask email]
>Reply-To: DB2 Data Base Discussion List <[login to unmask email]>
>To: [login to unmask email]
>Subject: Re: Archlog copy from tape to disk
>Date: Fri, 8 Oct 1999 08:55:54 +0800
>
>Roy/Eric,
>
>You have to have the same BLKSIZE. If they are different, DB2 will
>have difficulty finding some (but not all!) log records. We had
>problems with this ages ago in a DR test. DB2 kept giving an error
>message along the lines of "can't find log/archlog blah blah..."
>and would not complete the recover. But only for one or two logs
>in one or two jobs....very odd.
>
>We recopied them from tape to disk with the DCB override, and
>everything was fine. I did find an entry in IBMLINK regarding
>the logs & blksize - unfortunately, I no longer have that entry
>number to give you.
>
>This may have changed in newer versions of DB2 (that was V3 or V4
>when we had problems) but I wouldn't count on it....
>
>
>Greg Palgrave
>Database Administration Group
>Bank of Western Australia
>
>
>
>Roy Brickley <[login to unmask email]> on 07/10/99 05:58:14
>
>Please respond to DB2 Data Base Discussion List <[login to unmask email]>
>
>To: [login to unmask email]
>cc: (bcc: Greg Palgrave/SDG/SS/BankWest)
>
>Subject: Re: Archlog copy from tape to disk
>
>
>
>
> Eric,
>
> I've seen two posts that have the DCB with BLKSIZE=28672, and I
> recall having to do that for DB V3 D/R test, so it would match the
> tape blocksize. When I copy this to a 3393 RAID device, it used many
> extents. When I copied it with no DCB on the SYSUT2 dataset, the
> IEBGENER ran fine and I got a BLKSIZE=24576 on the DASD file and much
> less DASD space (300 cylinders compared to 470+ cylinders for 28672).
>
> I didn't get the chance to have the D/R test use these DASD
>archive
> logs, as my RBA info was offset in the DSNJU003 and the only hours I
> had to do this were between midnight and 6 AM - I just couldn't get
> all those RBA's straight! I even used a REXX program to read the
> DSNJU004 logmap output to set up the RBA's - I found out the hard way
> that DSNJU004 output changes from DB2 V3 to DB2 V4 (and probably
>every
> release!).
>
> So, if I let IEBGENER determine the best blocksize for the DASD
> copy, will DB2 be able to read the archive log? I ran DSN1LOGP
>against
> both versions without problems.
>
> Thanks,
>
> Roy Brickley
> Systems Programmer
> ACS, Inc.
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: Re: Archlog copy from tape to disk
>Author: DB2 Data Base Discussion List <[login to unmask email]> at INTERNET-GATEWAY
>Date: 10/06/1999 2:25 PM
>
>
>I too have done this. No timestamp problems. But you have to let DB2
>know that the device changed. Here's a sample of DSNJU003. I included
>the delete and registration of the active logs, in case anyone was
>interested.
>
>//DB2UHOH JOB (98060),'DB2-DISASTER RCVY',CLASS=A,
>// NOTIFY=HARPERE,MSGCLASS=X,TIME=1439,REGION=4M
>//*
>//* ========
>//* ==== I N S T R U C T I O N S ====
>//* ==== ====
>//* ==== 1. CHG '*_*' 1 OR 2, FOR LOG COPY USED. ====
>//* ==== 2. CHG DASDC? TO VOLUME FOR CURRENT ARCHLOG ====
>//* ==== PLACEMENT. ====
>//* ==== 3. CHG DASDP? TO VOLUME FOR PREVIOUS ARCHLOG ====
>//* ==== PLACEMENT. ====
>//* ==== 4. CHG 'C00????' TO GDG FOR CURRENT ARCHLOG. ====
>//* ==== 5. CHG 'P00????' TO GDG FOR PREVIOUS ARCHLOG. ====
>//* ==== 6. CHG 'C#####' TO VOLSER FOR CURRENT LOG TAPE====
>//* ==== 7. CHG 'P1####' TO VOLSER FOR PREV LOG TAPE ====
>//* ==== COPY 1. ====
>//* ==== 8. CHG 'P2####' TO VOLSER FOR PREV LOG TAPE ====
>//* ==== COPY 2. ====
>//* ==== .9. CHG THE RBAS AS IN THE PROCEDURES. ====
>//* ========
>//*
>//*
>//*========
>//ARCHLOG1 EXEC PGM=IEBGENER ====
>//*========
>//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AC00????,
>// UNIT=TAPE,
>// VOL=SER=C#####,
>// LABEL=(2,SL,,,EXPDT=98000),
>// DISP=SHR
>//*
>//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,
>// UNIT=DISK,VOL=SER=DASDC?,
>// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
>// SPACE=(CYL,(200,50),RLSE),
>// DISP=(NEW,CATLG,DELETE)
>//SYSPRINT DD SYSOUT=*
>//SYSIN DD DUMMY
>//*
>//*========
>//ARCHLOG2 EXEC PGM=IEBGENER ====
>//*========
>//SYSUT1 DD DSN=DBA2PDB2.DB2P.ARCHLOG*_*.AP00????,
>// UNIT=TAPE,
>// VOL=SER=P*_*####,
>// LABEL=(2,SL,,,EXPDT=98000),
>// DISP=SHR
>//*
>//SYSUT2 DD DSN=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,
>// UNIT=DISK,VOL=SER=DASDP?,
>// DCB=(LRECL=4096,BLKSIZE=28672,RECFM=FB),
>// SPACE=(CYL,(200,50),RLSE),
>// DISP=(NEW,CATLG,DELETE)
>//SYSPRINT DD SYSOUT=*
>//SYSIN DD DUMMY
>//*
>//*
>//* .... USE CHANGE LOG INVENTORY TO 'ZAP' IN CRCR RECORD ....
>//*
>//*=============
>//CHGLGINV EXEC PGM=DSNJU003 ====
>//*=============
>//*
>//SYSUT1 DD DSN=DBA2PDB2.DB2P.BSDS01,DISP=SHR
>//SYSUT2 DD DSN=DBA2PDB2.DB2P.BSDS02,DISP=SHR
>//SYSIN DD *
>DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG1.AP00????,COPY1VOL=P1####
>DELETE DSNAME=DBA2PDB2.DB2P.ARCHLOG2.AP00????,COPY2VOL=P2####
>NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AP00????,CATALOG=YES,
> COPY1VOL=DASDP?,STARTRBA=PS???000,ENDRBA=PE???FFF,UNIT=WORK
>NEWLOG DSNAME=DBA2PDB2.DB2P.DISK.ARCHLOG.AC00????,CATALOG=YES,
> COPY1VOL=DASDC?,STARTRBA=CS???000,ENDRBA=CE???FFF,UNIT=WORK
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03
>DELETE DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS01,COPY1
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS02,COPY1
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS03,COPY1
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY1.DS04,COPY1
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS01,COPY2
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS02,COPY2
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS03,COPY2
>NEWLOG DSNAME=DBA2PDB2.DB2P.LOGCOPY2.DS04,COPY2
>CRESTART CREATE,ENDRBA=?????000
>//SYSPRINT DD SYSOUT=*
>//*
>
>Later,
>Eric Harper
>Rose International
>[login to unmask email] <mailto:[login to unmask email]>
>(888) 430-7673 x17
>
>
>
>
>
> -----Original Message-----
> From: Alan Dishowitz [mailto:[login to unmask email]
> Sent: Wednesday, October 06, 1999 11:44 AM
> To: [login to unmask email]
> Subject: Re: Archlog copy from tape to disk
>
> Dale,
>
> I've done this a couple of times, and I didn't run into
>any
>timestamp
> issues. Just be sure to run DSNJU003 twice after using
>IEBGENER: once to
> delete the old Archive Log from the BSDS, and again to
>define the DASD copy
> of the Archive Log to the BSDS.
>
> Hope this helps,
>
> Alan Dishowitz, CSC FSG
>
> -----Original Message-----
> > From: PENROD, Dale [SMTP:[login to unmask email]
> > Sent: Wednesday, October 06, 1999 12:16 PM
> > To: [login to unmask email]
> > Subject: Archlog copy from tape to disk
> >
> > I ran into this opportunity at our last Disaster
>Recovery
>exercise, can
> > anyone help me out?
> >
> > After the operating system was restored and the DB2
>system
>was restored
> > successfully, we started the forward recovery of the
>users
>data under DB2.
> > The recovery procedure called in the ARCHLOG which lived
>on tape. You can
> > already see the problem, single threaded recovery.
> >
> > At one time, I was entertaining the idea of doing an
>IEBGENER of the
> > ARCHLOG
> > to DASD, then do the forward recoveries as DISP=SHR
>against the DASD
> > ARCHLOG
> > file. I was told this process would mess with DB2
>timestamps, as DB2
> > would
> > view the IEBGENER copied date as the DB2 timestamp. I
>am
>not a DB2 guru,
> > but this doesn't sound completely right to me. I still
>believe copying
> > the
> > ARCHLOG to DASD is the way to speed up the forward
>recovery process.
> >
> > My question, can anyone share with me a way to get tape
>ARCHLOG data to
> > DASD
> > so DB2 can do forward recovery more efficiently and
>without introducing
> > any
> > timestamp issues?
> >
> > Thanks,
> > Dale Penrod
> > [login to unmask email]
>
>
>
>
>
>_______________________________________________________________________________
>Unencrypted electronic mail is not secure and may not be authentic.
>If you have any doubts as to the contents please telephone to confirm.
>
>This electronic transmission is intended only for those to whom it is
>addressed. It may contain information that is confidential, privileged
>or exempt from disclosure by law. Any claim to privilege is not waived
>or lost by reason of mistaken transmission of this information.
>If you are not the intended recipient you must not distribute or copy this
>transmission and should please notify the sender. Your costs for doing
>this will be reimbursed by the sender.
>_______________________________________________________________________________

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com