Re: Moving JRN/JRNRCVR

At 09:07 AM 10/13/98 -0700, you wrote:
>Several months ago I discovered our main jrn was going to ASP1. I created
>the next jrnrcvr in ASP2 and attached it. All has been well.
>
>BACKGROUND
>This weekend we are doing a disk upgrade. 1 of our goals as part of this
>upgrade is to  isolate ASP1 from other ASPs in the RAID sets. A RAID set
>will not have both user and system asp data. We currently have 2gb drives,
>and room for 6 more internals. Do to this arrangement(2 internals on 1 iop
>and 4 on another) we will pull 2 more 2gb drives out and move others so we
>end up with 8-4gb drives in ASP3 and NO ASP2.
>
>QUESTION
>I need to move the jrn lib from ASP1 to ASP3. I see the simple way of
>BACKUP/DELETE/RESTORE to ASP3. If I do this in a restricted state what
>impact on journalling in general?? Is there a better way??
>
>I don't want to use a whole 4gb for journal.

I presume that you want to retain the name of the journaling library,
JRNLIB.  Furthermore you don't want to move the journal to the ASP.  (For
new ASPs [ those defined by library], the journal must reside in the same
ASP as the database files being journaled.)  The advice that IBM gave with
CPF Release 8.0
to put the journal object in the same User ASP as the receivers was bad
advice!

Steps to move the receiver only: 

Create the ASP.

Then create a dummy library, DUMMY.

Then create, by hand, the new receiver in DUMMY, and redirect journaling to
the new receiver in DUMMY.

Save JRNLIB or whatever else you want to do to it.  I presume that all it
has is journal receivers.

Assuming that it has nothing else, delete it.  On the other hand, if it has
stuff you want, save it to tape, then delete it.

Recreate the library, or restore it from tape into the intended ASP.

Then create, by hand, the new receiver in JRNLIB, and redirect journaling
to the new receiver in JRNLIB.

Save DUMMY or whatever else you want to do with it, and then delete it.

There is no reason why any of this stuff must be done in a restricted state
(with the exception of creating the ASP), except for the fact that the
execution of the CHGJRN can be a major database event, which could cause
performance contention with other operations.

Al





+--------------------------------------------------+
| Please do not send private mail to this address. |
| Private mail should go to barsa@ibm.net.         |
+--------------------------------------------------+

Al Barsa, Jr. - Account for Midrange-L
Barsa Consulting, LLC.  
400 > 390

Phone:  914-251-9400
Fax:    914-251-9406


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---