Remote Journal on i5/OS – Are You Selecting the Right Type?
Web Doc
Note: This is publication is now archived. For reference only.
Abstract
Remote journaling can be used in a variety of ways, from simply routing journal receivers to a distant electronic vault to helping achieve high availability.
When defining and creating a remote journal, you face an important choice regarding which type of remote journal should be selected. The remote journal option names themselves (*TYPE1 and *TYPE2) are part of the problem, for they are not too descriptive and there has often been confusion between the two choices.
In a nutshell, the type of remote journal that you choose impacts the subsequent interchangeability of resulting journal receivers. This technote attempts to make that distinction clearer and provides examples of various uses for remote journaling which in turn helps provide some guidelines and rules of thumb for deciding which remote journal type to choose.
If you choose wisely you’ll have versatility matched to your particular needs. If you choose haphazardly you might end up disappointed and wondering why you feel limited in achieving the versatility you yearn for.
Written by Peg Levering and Christopher Kundinger
Contents
Library redirection in a remote journal environment – what is it?
A useful paradigm when thinking about remote journal receivers is to view them as though they were a copy of the local journal receivers that had been somehow saved instantaneously from a production system and then restored to a remote system.
The resulting remote copy of the journal receivers is nearly identical to the local journal receivers and can be used in similar ways. For example, the remote journal receivers can be used for debug, to maintain a replica copy of some objects on the remote system, or simply as a backup copy of the local journal receivers. The corresponding journal entries residing within the remote journal receiver provide the audit trail of activity, revealing what ensued on the source system.
Normally journal receivers come with a lot of restrictions and rules they must obey. For example, they cannot be saved from one library and restored into a different library, or moved to any library other than the original library in which they were created. Remote journaling, however, allows you bend the ordinary rules a bit. You do this by specifying an alternate library to contain the journal receivers on the remote system through a mechanism which is referred to as library redirection.
This alternate library approach is specified using the RMTRCVLIB parameter when the remote journal connection is defined via the ADDRMTJRN command. Thinking back to our virtual save/restore paradigm, it is almost as if you had gotten away with saving the local production journal receivers from library1 and then hadn’t had your hands slapped when you tried to restore these same receivers as remote receivers in library2. Library redirection is the trick which helps make this possible.
In some remote journal scenarios this ability to store a journal and/or journal receiver in an alternate library (one that is not named the same as the library from which it originated on the source side) is essential. We are going to explore some of those.
Scenarios when this is library movement/redirection might be desirable include:
Let us look at some examples.
Example #1: I simply need a High Availability Backup System
In this example, imagine that you want to maintain a high availability backup system. You will switch to this backup system in the event that your primary system has a failure or perhaps when you need to perform routine maintenance like applying PTFs to your production system.
When you perform a role swap and switch from the production to the backup system, you will obviously want the backup/target system to look and act like the original production system. Hence, you will be running your SAME applications on that system.
Assume that you are a bank and, to ensure transaction integrity, you use commitment control in your banking application. When you switch to your backup system you will want to still use commitment control. To use commitment control your objects must be journaled, and therefore your replica objects on the backup system will need to be journaled as well. To run your application on either system you will have similarly named objects (including journals and journal receivers) on each system as shown in the following diagram:
Figure 1: High Availability Backup System
The LOCAL journal receiver on your production system in our example is named RCV01. The matching REMOTE journal receiver will also be named RCV01 and could be placed in the same named library on the target system. However doing so can be problematic. Why?
The problem (name collision) comes about because our application expects a LOCAL journal receiver on the target system with the same receiver name (RCV01) and the same library name as it employed on the source system. In this scenario you cannot and should not maintain your REMOTE journal and the matching remote journal receivers on the target machine in a library, which match the name you used for LOCAL journal receivers on the source side. Why?, because you need to keep that name free for use as the LOCAL journal and receiver on the target when a role swap ensues. Consequently, you need to employ one library name for housing the local journals and receivers on the source and a differing library name for housing the remote journal and receivers. The library redirection facility lets you accomplish this. It lets you bend the rules.
To allow you to establish your remote journal in this scenario without incurring name conflicts, you need the ability to place the REMOTE journal and remote journal receivers in a uniquely named library on the high availability backup system. That is precisely what the library redirection feature does. Returning to our virtual save/restore paradigm, it is as if we have, in effect, saved from PRODLIB on the source machine and restored that receiver into a different library (RMTLIB) on the target system.
If you have replication software that reads the changes from the remote journal and replays them (and most High Availability vendor software does precisely that), you would then have objects as illustrated below where the remote journal and remote journal receiver are redirected to library RMTLIB; but the journaled objects (such as your database files) remain in PRODLIB on both systems. That is, your database objects do not change libraries, only your remote journals do.
Figure 2: High Availability Backup system with replication software
Example #2: Central backup site
We have seen one example in which the ability to redirect the remote journal, such that it changes libraries, was crucial. How about another scenario?
In this second scenario, imagine that you have multiple branch offices all running the same software and that you want to backup the journal receivers for all of these branches to a central site. Do you see the problem?
If you were not allowed to place the remote journal receivers into uniquely named libraries when they reach the central site, then you would have name collisions between the multiple remote instances of the journal and journal receivers. We can avoid such name collisions by instructing each branch office to redirect both its remote journals and journal receivers to a library name unique to that branch on the central backup machine thereby avoiding name collisions as illustrated below in Figure #3.
Notice that both the branch machine in Minnesota (MN branch) and the branch machine in California (CA branch) keep their production journal and its journal receivers in the COREAPP library. If neither elected to capitalize on the library redirection feature, we would have name conflicts on the central backup machine. To avoid the name collisions, both branch offices use the library redirection feature when defining their respective remote journals. Hence, library redirection is a means to achieve harmony.
Figure 3: Central backup site
Example #3: High Availability Backup System and Disaster Recovery Site
Two examples down, one to go. Here’s a final example illustrating the need for library redirection.
In this last example imagine that you have a nearby high availability backup system as illustrated in Figure 2, but you also want to have a distant disaster recovery site across the country. That is, you have two remote copies of your journal receivers - one near and one far.
To further illustrate the point and also to imagine saving costs, you do not own either the distant site nor even the machine at that site. Instead, you are going to contract with another company (maybe a service bureau, maybe just a friendly firm) to rent some space on their host system across the country to house your remote journal and journal receivers.
Since you are contracting with another company chances are they have restrictions on what library you can place your data in. The library for your remote journal and remote journal receivers on this (owned by others) disaster recovery site is not going to be named the same as the library for your remote journal and remote journal receiver on your (owned by you) high availability backup system. The following diagram illustrates this scenario. Notice that the library names are all different. That is, you need a lot of renaming versatility for your library redirection scheme.
Figure 4: High availability backup system and disaster recovery site
Remote journal types
Why have we told you all this and laid out these three different scenarios? Answer: You face an important decision when you initially set up your remote journal connections. The initial choice you make impacts your future versatility. It is versatility that affects not only library redirection but other factors as well.
When you add a remote journal, you have a choice of two different remote journal types (*TYPE1 and *TYPE2). Which one should you select? It is important for you to understand the characteristics of each type so that you can choose the appropriate type for what you need to accomplish.
Let us explore the characteristics afforded by each type.
Receiver interchangeability
One difference between the two remote journal types has to do with the ability to interchange journal receivers between your REMOTE journal environment (the target) and your LOCAL journal environment (the source). Full journal receiver interchangeability gives you the liberty to save your remote journal receivers from a REMOTE system (where doing so is probably less disruptive) and restore them when needed to your LOCAL system and then to take a very important secondary step known as “associating” them with a local journal or vice versa.
Since the entries residing within a journal receiver cannot be accessed until the journal receiver is “associated” with a journal, assuring interchangeability (or the lack thereof) becomes an important decision. It assures that the association you want can be achieved.
Ideally you want to save either your LOCAL journal receivers or your REMOTE journal receivers, but not both of them since they contain nearly identical information. Why burn twice the media to save both copies? Yet you want to save at least one copy of your journal receivers for some period of time to allow for auditing, debug, or disaster recovery. The manner in which you initially define your remote journal (Type1 or Type2) impacts the flexibility you have for journal receiver interchangeability and “association”. It is an important decision!
Type1 remote journals and receiver interchangeability
The first remote journal type (*TYPE1) allows for maximum flexibility for interchanging journal receivers. With this type of remote journal you can save the journal receivers that are associated with the LOCAL journal or the journal receivers that are associated with the REMOTE journal and have the ability to restore the saved version and “associate” it with either the local or remote journal on any of your systems. You have a lot of versatility! Hence, if you truly need a lot of versatility, Type1 is an attractive choice.
This is because the actual library name of both the redirected library and the name of the original (local) receiver library is saved within every journal receiver along with both the remote and local journal names. That is, once you select Type1, four important pieces of information needed at “association” time to match up and allow linkages have been tucked away (the journal names on both sides and the library names on both sides). The receiver carries these four critical pieces of information out to media with them. For a Type1 connection, all of this information is tucked away at detach time (when the journal receiver is detached from the journal in order to make way for a new receiver).
Hence, once detached, the journal receiver knows and retains this set of Type1 redirection library name information. This is key. It means that when the saved journal receiver is restored to the LOCAL library then (based upon the information it tucked away) it will look for a corresponding LOCAL journal with which to associate itself. If that same journal receiver is restored to a REMOTE (or redirected) library, then it will look for a corresponding remote journal with which to associate itself. This is, it has two potential connection targets and remembers the name of each. You can think of it as a very smart journal receiver with an excellent memory.
As a consequence, a Type1 remote journal is an excellent choice for a high availability backup system as illustrated in Figure 2, because it allows the journal receivers to be interchanged between the two systems quite easily. Both sides know the names used on the other machine and are comfortable at restore time “associating” themselves with either. This gives you the ability to debug or audit from whichever system is more convenient at the time. It also means if either machine goes down, that you need not wait for it to come back up before you can restore and use the journal receiver. The Type1 journal receiver is very versatile.
You might be tempted at this point to think that Type1 is the only way to go since it provides such rich and liberal interchangeability rules. Is there really a role for Type2 remote journals? Yes!
Type2 remote journals and receiver interchangeability
It is true that the second remote journal type (*TYPE2) limits the flexibility for interchanging journal receivers. With this type of remote journal, if you save the journal receivers associated with the LOCAL journal, then you can only restore and associate the saved version with the LOCAL journal. That is, do not even think about moving it to a target machine which has elected to employ library redirection. This is because the LOCAL journal receivers have no knowledge of the Type2 redirected library associated with the REMOTE journal. At detach time, no such information was tucked away within the LOCAL journal receiver like it would have been for Type1 receivers.
That is not to say that you have no interchangeability for Type2 receivers, only that the choices are limited. For example, if you are using Type2 and save the journal receivers associated with the REMOTE journal you certainly can restore and associate them with a remote journal on the system they were saved from (because doing so does not mandate a library name change) or your could even associate them with a LOCAL journal if they are restored to a library with the SAME name as the local library. This is because the saved version of the REMOTE journal receiver knows its redirected library and associated remote journal name as well as the original LOCAL receiver library and journal name. Hence, Type2 journal receivers know enough to form some bonds but are not as comfortable as Type1 when it comes to meeting new journal receivers.
As a consequence, a Type2 remote journal would be a good choice in Figure 4 for the disaster recovery site, where you will not need to interchange journal receivers between that site and the main production site.
Are there other differences between Type1 and Type2?
While receiver interchangeability is a major difference between the two different remote journal types, it is not the only difference. Let us explore some of the other differences.
In a remote journal configuration in which the local journal ends up being sent to multiple target machines, all subsequent Type1 remote journals associated with this LOCAL journal MUST specify the same library redirection values for both the REMOTE journal and the remote journal receivers. That is, all targets must look identical. By contrast, if you use Type2 when setting up your LOCAL journal, then every down-stream REMOTE journal associated with this LOCAL journal can elect to use a customized redirected library rule. That is, not all target machines must follow suit. Rather, each can employ unique library redirection values. This liberty can make Type2 especially attractive in some environments.
Let us look at an example of this rule in action. If both remote journals illustrated in Figure 4 were Type1, then our hands would be tied and the same library name would have had to have been used to house the remote journal and remote journal receivers on the high availability backup system and at the disaster recovery site. That would have been a very restrictive constraint. Because we wanted to avoid this kind of lock-step naming restriction and have greater versatility at our disaster site (need not use the same names used for the failover site), we deliberately elected to employ a Type2 remote journal connection. Type2 is the only variety which allows us sufficient liberty to place our disaster recovery site's remote journal and its associated remote journal receivers in libraries which do not need to match the naming convention employed for redirection on the failover machine.
But that is not the only difference between the two types of remote journals.
Another difference between the two remote journal types is the influence it has on which library on the target system will be used to house the remote receivers.
Because every LOCAL journal receiver saves (and locks in) the Type1 library redirection values at detach time, that is the information that influences where the matching REMOTE journal receiver is placed later when it is actually created on the remote system.
If, for example, you designate the remote journal as Type1 and elect to provide no redirection information at the time the journal receiver is attached, then you cannot change your mind later! Since you have chosen Type 1, the remote journal mechanism is locked in, it only knows about the LOCAL journal receiver library and hence all remote journal traffic will be replicated to the remote system and placed into a library with the SAME name as the local journal receiver. Once you passed up the redirection choice, you’ve gone down a one-way street. You cannot easily change your mind.
By contrast when activating a Type2 remote journal, the current value for the Type2 library redirection is used. That is, each new “activation” lets you change your mind. You are not locked in. This allows you to CHANGE the remote journal receiver library by simply removing the Type2 remote journal, re-adding it with the new redirection information, and reactivating remote journal.
In short, Type2 lets you change your mind. You are not locked in.
A final difference between a Type1 remote journal and a Type2 remote journal involves object naming versatility. For example the remote JOURNAL NAME for a Type1 REMOTE journal must be the same as the LOCAL journal name (only the library name can be different via redirection, NOT the name of the journal itself). That is a very restrictive rule. By contrast, Type 2 remote journals are not as picky about name matches. Thus, if you elect to employ a Type2 remote journal, BOTH the library name and (if you so choose) even the actual remote JOURNAL name can differ from the names selected for the LOCAL journal. In short, Type2 affords more object name versatility.
With all these differences between Type1 and Type2 your head might be swimming at this point as you wonder: Which type should I use?
What type should be used?
We offer some general guidelines:
There is a lot to think about here, and there are certainly advantages and disadvantages that accompany both choices (Type1 or Type2). We hope that by laying out some of the differences, side by side above, you now have some criteria to use in selecting which liberties you need and which restrictions that you are willing to live with in order to gain other advantages.
A useful paradigm when thinking about remote journal receivers is to view them as though they were a copy of the local journal receivers that had been somehow saved instantaneously from a production system and then restored to a remote system.
The resulting remote copy of the journal receivers is nearly identical to the local journal receivers and can be used in similar ways. For example, the remote journal receivers can be used for debug, to maintain a replica copy of some objects on the remote system, or simply as a backup copy of the local journal receivers. The corresponding journal entries residing within the remote journal receiver provide the audit trail of activity, revealing what ensued on the source system.
Normally journal receivers come with a lot of restrictions and rules they must obey. For example, they cannot be saved from one library and restored into a different library, or moved to any library other than the original library in which they were created. Remote journaling, however, allows you bend the ordinary rules a bit. You do this by specifying an alternate library to contain the journal receivers on the remote system through a mechanism which is referred to as library redirection.
This alternate library approach is specified using the RMTRCVLIB parameter when the remote journal connection is defined via the ADDRMTJRN command. Thinking back to our virtual save/restore paradigm, it is almost as if you had gotten away with saving the local production journal receivers from library1 and then hadn’t had your hands slapped when you tried to restore these same receivers as remote receivers in library2. Library redirection is the trick which helps make this possible.
In some remote journal scenarios this ability to store a journal and/or journal receiver in an alternate library (one that is not named the same as the library from which it originated on the source side) is essential. We are going to explore some of those.
Scenarios when this is library movement/redirection might be desirable include:
- When you want to maintain a high availability backup system
- When you have multiple branch offices all sending their journal receivers to one central backup site
- When you want to maintain both a highly available backup system and a separate disaster recovery site concurrently.
Let us look at some examples.
Example #1: I simply need a High Availability Backup System
In this example, imagine that you want to maintain a high availability backup system. You will switch to this backup system in the event that your primary system has a failure or perhaps when you need to perform routine maintenance like applying PTFs to your production system.
When you perform a role swap and switch from the production to the backup system, you will obviously want the backup/target system to look and act like the original production system. Hence, you will be running your SAME applications on that system.
Assume that you are a bank and, to ensure transaction integrity, you use commitment control in your banking application. When you switch to your backup system you will want to still use commitment control. To use commitment control your objects must be journaled, and therefore your replica objects on the backup system will need to be journaled as well. To run your application on either system you will have similarly named objects (including journals and journal receivers) on each system as shown in the following diagram:
Figure 1: High Availability Backup System
The LOCAL journal receiver on your production system in our example is named RCV01. The matching REMOTE journal receiver will also be named RCV01 and could be placed in the same named library on the target system. However doing so can be problematic. Why?
The problem (name collision) comes about because our application expects a LOCAL journal receiver on the target system with the same receiver name (RCV01) and the same library name as it employed on the source system. In this scenario you cannot and should not maintain your REMOTE journal and the matching remote journal receivers on the target machine in a library, which match the name you used for LOCAL journal receivers on the source side. Why?, because you need to keep that name free for use as the LOCAL journal and receiver on the target when a role swap ensues. Consequently, you need to employ one library name for housing the local journals and receivers on the source and a differing library name for housing the remote journal and receivers. The library redirection facility lets you accomplish this. It lets you bend the rules.
To allow you to establish your remote journal in this scenario without incurring name conflicts, you need the ability to place the REMOTE journal and remote journal receivers in a uniquely named library on the high availability backup system. That is precisely what the library redirection feature does. Returning to our virtual save/restore paradigm, it is as if we have, in effect, saved from PRODLIB on the source machine and restored that receiver into a different library (RMTLIB) on the target system.
If you have replication software that reads the changes from the remote journal and replays them (and most High Availability vendor software does precisely that), you would then have objects as illustrated below where the remote journal and remote journal receiver are redirected to library RMTLIB; but the journaled objects (such as your database files) remain in PRODLIB on both systems. That is, your database objects do not change libraries, only your remote journals do.
Figure 2: High Availability Backup system with replication software
Example #2: Central backup site
We have seen one example in which the ability to redirect the remote journal, such that it changes libraries, was crucial. How about another scenario?
In this second scenario, imagine that you have multiple branch offices all running the same software and that you want to backup the journal receivers for all of these branches to a central site. Do you see the problem?
If you were not allowed to place the remote journal receivers into uniquely named libraries when they reach the central site, then you would have name collisions between the multiple remote instances of the journal and journal receivers. We can avoid such name collisions by instructing each branch office to redirect both its remote journals and journal receivers to a library name unique to that branch on the central backup machine thereby avoiding name collisions as illustrated below in Figure #3.
Notice that both the branch machine in Minnesota (MN branch) and the branch machine in California (CA branch) keep their production journal and its journal receivers in the COREAPP library. If neither elected to capitalize on the library redirection feature, we would have name conflicts on the central backup machine. To avoid the name collisions, both branch offices use the library redirection feature when defining their respective remote journals. Hence, library redirection is a means to achieve harmony.
Figure 3: Central backup site
Example #3: High Availability Backup System and Disaster Recovery Site
Two examples down, one to go. Here’s a final example illustrating the need for library redirection.
In this last example imagine that you have a nearby high availability backup system as illustrated in Figure 2, but you also want to have a distant disaster recovery site across the country. That is, you have two remote copies of your journal receivers - one near and one far.
To further illustrate the point and also to imagine saving costs, you do not own either the distant site nor even the machine at that site. Instead, you are going to contract with another company (maybe a service bureau, maybe just a friendly firm) to rent some space on their host system across the country to house your remote journal and journal receivers.
Since you are contracting with another company chances are they have restrictions on what library you can place your data in. The library for your remote journal and remote journal receivers on this (owned by others) disaster recovery site is not going to be named the same as the library for your remote journal and remote journal receiver on your (owned by you) high availability backup system. The following diagram illustrates this scenario. Notice that the library names are all different. That is, you need a lot of renaming versatility for your library redirection scheme.
Figure 4: High availability backup system and disaster recovery site
Remote journal types
Why have we told you all this and laid out these three different scenarios? Answer: You face an important decision when you initially set up your remote journal connections. The initial choice you make impacts your future versatility. It is versatility that affects not only library redirection but other factors as well.
When you add a remote journal, you have a choice of two different remote journal types (*TYPE1 and *TYPE2). Which one should you select? It is important for you to understand the characteristics of each type so that you can choose the appropriate type for what you need to accomplish.
Let us explore the characteristics afforded by each type.
Receiver interchangeability
One difference between the two remote journal types has to do with the ability to interchange journal receivers between your REMOTE journal environment (the target) and your LOCAL journal environment (the source). Full journal receiver interchangeability gives you the liberty to save your remote journal receivers from a REMOTE system (where doing so is probably less disruptive) and restore them when needed to your LOCAL system and then to take a very important secondary step known as “associating” them with a local journal or vice versa.
Since the entries residing within a journal receiver cannot be accessed until the journal receiver is “associated” with a journal, assuring interchangeability (or the lack thereof) becomes an important decision. It assures that the association you want can be achieved.
Ideally you want to save either your LOCAL journal receivers or your REMOTE journal receivers, but not both of them since they contain nearly identical information. Why burn twice the media to save both copies? Yet you want to save at least one copy of your journal receivers for some period of time to allow for auditing, debug, or disaster recovery. The manner in which you initially define your remote journal (Type1 or Type2) impacts the flexibility you have for journal receiver interchangeability and “association”. It is an important decision!
Type1 remote journals and receiver interchangeability
The first remote journal type (*TYPE1) allows for maximum flexibility for interchanging journal receivers. With this type of remote journal you can save the journal receivers that are associated with the LOCAL journal or the journal receivers that are associated with the REMOTE journal and have the ability to restore the saved version and “associate” it with either the local or remote journal on any of your systems. You have a lot of versatility! Hence, if you truly need a lot of versatility, Type1 is an attractive choice.
This is because the actual library name of both the redirected library and the name of the original (local) receiver library is saved within every journal receiver along with both the remote and local journal names. That is, once you select Type1, four important pieces of information needed at “association” time to match up and allow linkages have been tucked away (the journal names on both sides and the library names on both sides). The receiver carries these four critical pieces of information out to media with them. For a Type1 connection, all of this information is tucked away at detach time (when the journal receiver is detached from the journal in order to make way for a new receiver).
Hence, once detached, the journal receiver knows and retains this set of Type1 redirection library name information. This is key. It means that when the saved journal receiver is restored to the LOCAL library then (based upon the information it tucked away) it will look for a corresponding LOCAL journal with which to associate itself. If that same journal receiver is restored to a REMOTE (or redirected) library, then it will look for a corresponding remote journal with which to associate itself. This is, it has two potential connection targets and remembers the name of each. You can think of it as a very smart journal receiver with an excellent memory.
As a consequence, a Type1 remote journal is an excellent choice for a high availability backup system as illustrated in Figure 2, because it allows the journal receivers to be interchanged between the two systems quite easily. Both sides know the names used on the other machine and are comfortable at restore time “associating” themselves with either. This gives you the ability to debug or audit from whichever system is more convenient at the time. It also means if either machine goes down, that you need not wait for it to come back up before you can restore and use the journal receiver. The Type1 journal receiver is very versatile.
You might be tempted at this point to think that Type1 is the only way to go since it provides such rich and liberal interchangeability rules. Is there really a role for Type2 remote journals? Yes!
Type2 remote journals and receiver interchangeability
It is true that the second remote journal type (*TYPE2) limits the flexibility for interchanging journal receivers. With this type of remote journal, if you save the journal receivers associated with the LOCAL journal, then you can only restore and associate the saved version with the LOCAL journal. That is, do not even think about moving it to a target machine which has elected to employ library redirection. This is because the LOCAL journal receivers have no knowledge of the Type2 redirected library associated with the REMOTE journal. At detach time, no such information was tucked away within the LOCAL journal receiver like it would have been for Type1 receivers.
That is not to say that you have no interchangeability for Type2 receivers, only that the choices are limited. For example, if you are using Type2 and save the journal receivers associated with the REMOTE journal you certainly can restore and associate them with a remote journal on the system they were saved from (because doing so does not mandate a library name change) or your could even associate them with a LOCAL journal if they are restored to a library with the SAME name as the local library. This is because the saved version of the REMOTE journal receiver knows its redirected library and associated remote journal name as well as the original LOCAL receiver library and journal name. Hence, Type2 journal receivers know enough to form some bonds but are not as comfortable as Type1 when it comes to meeting new journal receivers.
As a consequence, a Type2 remote journal would be a good choice in Figure 4 for the disaster recovery site, where you will not need to interchange journal receivers between that site and the main production site.
Are there other differences between Type1 and Type2?
While receiver interchangeability is a major difference between the two different remote journal types, it is not the only difference. Let us explore some of the other differences.
In a remote journal configuration in which the local journal ends up being sent to multiple target machines, all subsequent Type1 remote journals associated with this LOCAL journal MUST specify the same library redirection values for both the REMOTE journal and the remote journal receivers. That is, all targets must look identical. By contrast, if you use Type2 when setting up your LOCAL journal, then every down-stream REMOTE journal associated with this LOCAL journal can elect to use a customized redirected library rule. That is, not all target machines must follow suit. Rather, each can employ unique library redirection values. This liberty can make Type2 especially attractive in some environments.
Let us look at an example of this rule in action. If both remote journals illustrated in Figure 4 were Type1, then our hands would be tied and the same library name would have had to have been used to house the remote journal and remote journal receivers on the high availability backup system and at the disaster recovery site. That would have been a very restrictive constraint. Because we wanted to avoid this kind of lock-step naming restriction and have greater versatility at our disaster site (need not use the same names used for the failover site), we deliberately elected to employ a Type2 remote journal connection. Type2 is the only variety which allows us sufficient liberty to place our disaster recovery site's remote journal and its associated remote journal receivers in libraries which do not need to match the naming convention employed for redirection on the failover machine.
But that is not the only difference between the two types of remote journals.
Another difference between the two remote journal types is the influence it has on which library on the target system will be used to house the remote receivers.
Because every LOCAL journal receiver saves (and locks in) the Type1 library redirection values at detach time, that is the information that influences where the matching REMOTE journal receiver is placed later when it is actually created on the remote system.
If, for example, you designate the remote journal as Type1 and elect to provide no redirection information at the time the journal receiver is attached, then you cannot change your mind later! Since you have chosen Type 1, the remote journal mechanism is locked in, it only knows about the LOCAL journal receiver library and hence all remote journal traffic will be replicated to the remote system and placed into a library with the SAME name as the local journal receiver. Once you passed up the redirection choice, you’ve gone down a one-way street. You cannot easily change your mind.
By contrast when activating a Type2 remote journal, the current value for the Type2 library redirection is used. That is, each new “activation” lets you change your mind. You are not locked in. This allows you to CHANGE the remote journal receiver library by simply removing the Type2 remote journal, re-adding it with the new redirection information, and reactivating remote journal.
In short, Type2 lets you change your mind. You are not locked in.
A final difference between a Type1 remote journal and a Type2 remote journal involves object naming versatility. For example the remote JOURNAL NAME for a Type1 REMOTE journal must be the same as the LOCAL journal name (only the library name can be different via redirection, NOT the name of the journal itself). That is a very restrictive rule. By contrast, Type 2 remote journals are not as picky about name matches. Thus, if you elect to employ a Type2 remote journal, BOTH the library name and (if you so choose) even the actual remote JOURNAL name can differ from the names selected for the LOCAL journal. In short, Type2 affords more object name versatility.
With all these differences between Type1 and Type2 your head might be swimming at this point as you wonder: Which type should I use?
What type should be used?
We offer some general guidelines:
- If the remote journal is being added as part of providing SIMPLE high availability as illustrated in Example #1, then Type1 is probably the best option because it allows for more flexible receiver interchangeability.
- If you need the ability to place an additional remote journal in a uniquely named library, it would make sense for this second remote journal to be a Type2 remote journal. This especially would make sense if your disaster recovery site is hosted by some third party as was illustrated in Figure 4. Chances are in this scenario that the third party will have some restrictions on what libraries you can use on their system.
There is a lot to think about here, and there are certainly advantages and disadvantages that accompany both choices (Type1 or Type2). We hope that by laying out some of the differences, side by side above, you now have some criteria to use in selecting which liberties you need and which restrictions that you are willing to live with in order to gain other advantages.
Special Notices
The material included in this document is in DRAFT form and is provided 'as is' without warranty of any kind. IBM is not responsible for the accuracy or completeness of the material, and may update the document at any time. The final, published document may not include any, or all, of the material included herein. Client assumes all risks associated with Client's use of this document.