Completing the solution

If you have been following the recent posts you will have seen a number of new products being released by Shield Advanced Solutions and wondered why the shift into different areas. High Availability has been the bread and butter for Shield Advanced Solutions since its inception over 24 years ago (yes we are nearly 25 years young..) with a number of notable products such as JT4i, DR4i and HA4i. So why the new products you may ask?

High Availability for IBM i is not a single product, its a collection of tools that fit together to provide a solution to meet the customers needs for system availability. Every customer has a different set of requirements and therefore needs a different set of tools to create the solution. So the question is what do we have and where does each tool fit into a High Availability solution.

DR4i Data Replication

DR4i is just about Data Replication, we took the same apply process developed for the HA4i product and created a separate product just for applying the remote journal data. The main purpose was to reduce the RPO for those customers who did not need a fully functional HA solution but still wanted to have no loss of data when they carried out their recovery even if it took hours to bring the applications back on line. We have also seen it used as a method of providing a full backup where a backup window was not available on the production server due to constant object locks, the data is replicated to another LPAR and the saves can be carried out without any locking issues etc.

HA4i High Availability

HA4i is a true High Availability solution that provides all of the features you would expect from a one to one system replication solution. The roots were formed when we built the RAP/400 product which used the APYCHGJRN(X) commands to replicate the data from the remote journals and a bespoke object replication process to replicate everything else. We found that the APYJRNCHG technology left a number of gaps and wasn’t really good enough for a fast roleswap that was required by many customers hence the new bespoke apply process HA4i uses today. We have a number of new enhancements in the works for the product but have found that the product meets the needs of the customers running it today so the multi-node support and other related features are not being pushed as a priority. Maybe one day they will move up the priority list?

JT4i Job Tracking

JT4i provides the ability to track jobs as they go through their life cycle, the data collected can be replicated between the production and back up system so the job information can be used for identification and recovery of jobs that did not complete. The jobs are not replicated to the target job queues but the data they generate is stored in database files. In the event of a production system failure you have all of the information required to determine what jobs were running (*ACTIVE) at the time of the failure, how each job ran and if it ended in a failure plus all of the attributes for that job. With this information on hand you can decide what jobs to reload to the job queues (this can be automated with commands provided) and what data (if any) has to be removed from the database before the jobs can be resubmitted.

The product works with any High Availability Replication solution including Power HA (Power HA does not replicate *SYSBAS objects which is where job queue content is stored) and provides a significant benefit when carrying out a role swap between systems.

Note: We have seen some customers running High Availability solutions that do not provide this capability, they struggle to carry out a *PLANNED role swap because the job queue content cannot not be rebuilt in the allotted time. Waiting for the job queues to clear would also impact the role swap in such a manner that it would not allow the role swap to complete in time.

Single System to iASP replication

Some time ago we developed a product that would allow a running system to be replicated to a remote iASP for recovery, we felt it would be a big opportunity for Cloud providers to give the smaller customers a Recovery Point Objective of near zero while not requiring a full host to be provisioned for each customer. We saw a number of benefits for such a technology in the SMB market space where saving money yet still having a recovery position that would allow no data loss but an extended recovery time would be acceptable. Once the customer required access to the system the data would be restored to an active system and using tools provided by the product the profiles, system values etc could be rebuilt so the system would be in the same state as the customers system was. Its not High Availability solution but it does allow RPO of near to zero to be achieved. However at this time we have seen little interest from the Cloud providers so have shelved the project for now.

This gives us a pretty good coverage where customers needed an Availability solution as we said above we are still seeing as gaps in many of the installations we have been involved with.

NG4i Nagios Monitoring for IBM i

During the recent pandemic we saw a number of instances where the High Availability solution may not have provided the recovery the customer should expect. The customers staff were not working on site and remote access was intermittent at best. One customer we spoke with noticed the target system had gone off line due to a power problem, no one had noticed for days because they never signed onto the system to check it was OK. The fact the target system had gone off line did not affect the business because the production system was still running.

HA4i provides a number of recovery options that would have picked up the issue but they had not been running due to other influences. If the production system had failed the role swap to the target system would not be possible because it was not running and the data replication was days behind. Once the system was back up and running it did not take long for the replication to catch up and the protections provided to be back in place, but the exposure was still there. So the question was how do we negate that in the future?

You will have seen a number of posts recently about a new product we have been developing that provides Nagios monitoring capabilities to the IBM i. The initial reason we started the development of the product was so our customers could monitor HA4i, this has since expanded significantly and will continue to be improved as we see more touch points that users need to monitor.

EM4i Message monitoring and notification

Message monitoring is a key part of any High Availability solution, if a job is held waiting for a response to a message any users waiting for the data produced by that program would be affected. There are plenty of message monitoring solutions out there so why did we come up with our EM4i product? Due to staff not working onsite during the pandemic, a customer approached us asking if we had something that would allow them to receive notifications via a mobile device or browser that messages were waiting for a response and be able to respond to those messages without having to sign onto the IBM i.

The IBM i would not be allowed to accept any incoming requests from outside their network, the notification was being sent outside the network so we had to come up with something that did not rely on the outside device contacting the IBM i directly. Security is a high priority for customers in today’s environment, so keeping control of who access the IBM i and the data it holds was a key factor.

The customer had seen jobs held waiting for a message response for hours because no one was monitoring their system, getting immediate notifications would resolve that issue. The program also stopped later jobs from running which caused even more problems not related to that single program.

EM4i provides immediate notifications via a number of channels that allow the user to see the message sent and take an appropriate response. The response is stored outside of the users network and retrieved via a process instigated by the IBM i which means any communication is made from the IBM i and not to it. The connection can be made via non secure transport or SSL which adds a further level of security.

We feel this rounds out the portfolio of products by providing the following features :

  • Replicate the objects and data between systems
  • Provide job recovery in the event of a system failure
  • Allow job queues to be reloaded on a roleswap
  • Provide instant message responses
  • Monitor the system with notifications of issues

All of the products supplied by Shield are shipped as IBM LPP’s (use the same commands and license management as the OS) which makes them easy to install and manage. We have also used UIM as the language of choice for developing the 5250 interfaces for all of the products, this means the screen scraping modernization products out there should have little work adding a new interface over the screens (they are all CUA compliant by default and do not use the DDS features that cause problems when converting the screens).

If you need to see a demo of any of the products or speak to us about competitive replacements get in touch using the contact form on our website. We are a small and independent IBM i ISV, pricing is fair and reasonable and always negotiable, that does not mean we have lower quality products or support. Our customers regularly tell us how much they appreciate our commitment to the products and the level of support we provide.

Keep watching this Blog, we have new announcements coming up that will be of interest.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.