One of the challenges and benefits of LVLT4i is the use of iASP technology for storage of the clients data. For recovery you need to be able to re-direct the apply process for all of the data and objects to a specific ASP Group, this is how LVLT4i works today. JQG4i collects the job queue content from the production system and stores it for replication to a remote recovery system so for LVLT4i we need to allow that data to be stored in the iASP.
The job collection routines are not required to be aware of the iASP technology because all job activity runs in the *SYSBAS ASP, this is one of the reasons even IBM’s Power HA does not store the job queue content in their iASP based replication solution as they cannot replicate anything in the *SYSBAS ASP. However because LVLT4i is going to store the data on the target in an iASP all of the interfaces that need to look at the stored data needed to be updated to allow the iASP to be configured as part of the environment setup. Each client which uses LVLT4i will be assigned a separate iASP for their data, this where we need to store the data that JQG4i has collected from their production system.
JQG4i has 2 types of environments which can be configured, *LOCAL which is where the data is collected and *REMOTE which is where the replication software is to write the collected content. When a *REMOTE environment is created JQG4i will automatically build the library and all of the files, for LVLT4i those objects and library have to be created in a specific iASP not *SYSBAS which would be the norm for other availability solutions.
We started by adding a new field to the environment configuration file which allows the target iASP to be defined, this could be used in all of the programs to identify the iASP for the data viewing and analysis programs. Then we simply updated all of the programs which required the iASP to find the data files to use this new field, we also rebuilt all of the programs which used that file. We do not allow the source data to be stored in an iASP so we added a check which ensures all *LOCAL environments use *SYSBAS as their ASP setting.
After a couple of tests we now have the LVLT4i product replicating and updating the data in the iASP, the interfaces which are used to identify the recovery points in the event of a disaster have been tested and everything looks OK. One of the functions normally available to JQG4i which allows jobs to be re-submitted has been disabled for any environment which is not stored in *SYSBAS, this stops anyone from launching a job because the job would run in the *SYSBAS ASP and could cause lots of issues.
JQG4i is a vital part of any recovery which needs to be aware of the job status on a lost production system, without it you cannot know which jobs were running and which had ended abnormally in the event of a disaster. The problem is most companies test their recovery solution using what is called a planned switch, this means they know everything has been ended correctly and that no jobs are likely to be running that would affect the recovery of the applications. Unfortunately when a Disaster strikes that will not be the case! We have added the iASP capability to JQG4i because the main purpose of using LVLT4i is to allow recovery in the even of a Disaster, knowing the job queue status is a very important piece of the recovery puzzle.
If you need more information about LVLT4i or JQG4i visit our website where we you can download the literature or call us and we will be happy to discuss your needs. We will be attending the i-UG meeting in the UK September 9th/10th and have a booth where we can discuss our products and how they address your needs for High Availability and Disaster Recovery. Stop by, you will be surprised at just how affordable and effective our solutions are.