Find the number of times an SQL Index had been used

When you are building SQL DDL Indexes to improve performance it is also imperative to find Indexes that are not being used. Having identified those a decision can be made on whether to delete these unused indexes, or not.

Finding this information introduced me to a SQL View I had not used before: SYSTABLEINDEXSTAT

SYSTABLEINDEXSTAT contains the columns I want, the number of times the index has been used and the date it was last used. Alas, the view SYSINDEXES does not contain that information.

I always recommend that, on the partition you use, you run the following statement at least once to see all of the information that is available to you:

SELECT * FROM QSYS2.SYSTABLEINDEXSTAT
LIMIT 10 ;
Read more »

Putting the CT in your CI/CD pipeline

By Alan Ashley | Aug 30th 2022

We have all heard about the CI/CD pipeline in DevOps. This is the standard phrase. But what is often left out of this is the CT — the Continuous Testing aspect. This could be Code Quality and Security, Unit Testing, or Regression Testing.  These tests are the steps needed to “Shift Left” or “Fail Fast” in the pipeline and the use of automation in the CT phase can make the process seamless and reduce the time needed for testing. Granted, your developers may be testing as they develop.  

Are they testing to get the code compiled? 

Are they testing to validate that the changes are not impacting the bigger picture? 
After that, is a QA validation or peer review run? In larger shops, this can be covered by the volume of the team, however in smaller shops, these tests may be skipped just due to resources.  

In all cases, automation of the testing is vital to the success of the CI/CT/CD pipeline and with the Arcad testing suite of tools, we fit right in with the use of automation, regardless of the pipeline used.  

Let us step back for a minute before we jump all the way through the pipeline. For your organization, define what testing needs to occur and why. As I mentioned earlier, we have code quality, unit testing, and regression testing. Now let’s dive in to identify what you may be missing.  

Code Quality and Security 

This is the start of the SEC in DevSecOps, but truly you can never really finish when it comes to quality and security of your code. It is forever ongoing. But why? To start, here are a few areas that you need to ask about when it comes to quality and security. As you will see, it’s more than those two topics. 

Developers need to ensure they are following best coding practice for the company and the larger global community. The side benefit to this, any new developer to your organization will immediately notice the similarities in the style of coding. This reduces the onboarding time and improve the ROI for new employees.  

Have you recently decided to or rather forced to quality and security check all your code? Then this process can be slid right into the development cycle and used by developers as they update code or it can be incorporated in a pipeline to kick off a process to review older code to make sure it meets current standards.  
Maybe you have acquired a new company and the code is a mess. How do you go about finding and fixing the flaws? This could be a monumental task. 

This is where Arcad’s Code Checker steps in. Our product comes packaged with nearly 100 rules (such as check for GO TOs, DUMPs, etc.) that have been gathered from industry standards and well as security CVEs (Common Vulnerabilities and Exposures) as it relates to the IBM i. If those rules don’t cover what you need, it has a user-defined option to add even more to meet your company’s needs. For example, this could be the need to validate that the copyright has been added to every source member.

With Code Checker, it is just a right click away in RDI when using the Arcad DevOps Suite, or it can be a stand-alone install with an eclipse client. Regardless, the functions stay the same, with the server running on IBM i or Windows.  

Before moving on to unit testing, just a few more key points on Code Checker:  

Supports multiple IBM i languages such as the RPG’s, COBOL, CL, and SQL Support 
Pipeline and automation friendly 

Loaded with preconfigure rules to get you start 
Lastly, check out the 30-day trial of Code Checker here. 

I know, code quality may not fall under the true definition of testing, although it plays an integral part to ensure you have a solid code foundation but security violation checking does since the impact to Production can be enormous.  

Unit Testing 

Arcad’s iUnit for unit testing again slides right into the Shift Left, Fail Fast methodology. This allows your developers to test the modules and procedures without having completed the entire program. So, whether you code in RPG, COBOL, or even CL, iUnit has you covered. With its automatic discovery of simple or complex parameters in RPG or its mocking capabilities or the inheritance of JUnit features, it has what you need.  

Some of the areas that can be tested include Functions, procedures, Programs, service programs as well as SQL procedures. All this function is available right from RDi and coming soon — a deeper integration into the Skipper Plugin found in the DevOps Suite. This new feature will allow right click access to unit testing. 

With the inheritance of JUnit features, this is yet another way Arcad encourages new developers from the Open System world to step into the RPG world and the IBM i. Since it has the JUnit feel, it also hooks right into the automation pipeline with Jenkins, if so desired. Personally, I find that being able to test modules on the fly to be the best result for fast results.  

As with Code Checker, iUnit, comes with a free trial that can be found here –  

Regression Testing with Verifier 

To round out the testing phase comes regression testing. How do you ensure that previously developed and testing applications still performs the same after a change?  This testing usually falls on a QA department or just as often falls on whomever is available. With Arcad’s Verifier, you can run both manual or automated tests across a single scenario or a campaign to handle multiple areas. The question comes around, which scenario do you run? With Verifier, it builds an ongoing cross-reference repository to determine which scenario to run. If you change program PGM001, any scenario and campaign that runs against that program will be highlighted or selected to run. This feature alone can save you time, which will save you money in the end. Verifier handles both 5250 and Spooled File comparisons, which is nice, but it digs into the DB2 on IBM i to show file and field level differences. With the DB2 on IBM i review, the use of tools like Selenium can be used to ensure that the data entered and processed at the web entry is what is expected within the backend DB2 database. You can even compare a 5250 entry to a Selenium captured entry just to help identify any errors in the processing aspect of the application. In addition, it tests for differences in the UI as well.  And its supports both batch and interactive jobs.  As the pipeline flows closer to deployment, regression testing will be that last line of defense against any defects making it into production, including finding issues because of a modernization project.  

The final word: CT in the CI/CD 

The main objectives to incorporating Continuous Testing in CI/CD workflow: 

“Shift left’ and find issues as early as possible.  
Move from a manual to an automated process to ensure consistency, auditability, and scalability. 
Drive an agile development process.  

We have discussed three major areas to the testing pipeline each of which is covered by an Arcad solution. The ‘bonus’ here is these products can function in an existing Arcad DevOps pipeline or be added to existing development pipeline as stand-alone installations. 

If you are looking at this and wondering, where do I start, the easiest answer is what need do you have? You don’t need to implement in a specific order.  Find the problem area and we can help map a solution.  Happy Testing! 

And you thought we were done. Did you know you can also pull information from these tools to reflect in a Dashboard? Sometimes this can help see the larger picture. Below are just a few samples of what can be derived from the Arcad VSM Dashboard in conjunction with the testing suite of tools. 


Figure
1 – Code Checker via Dashboard 

Figure 2 – Verifier via Jenkins and Dashboard 

Now feel free to run off and test, test, and test. 

Download this datasheet to learn how ARCAD for DevOps helps IT managers to control costs and accelerate software delivery on IBM i.

Alan Ashley

Solution Architect, ARCAD Software

Alan has been in support and promotion of the IBM i platform for over 30 years and is the Presales Consultant for DevOps on IBM i role with ARCAD Software. Prior to joining ARCAD Software, he spent many years in multiple roles within IBM from supporting customers through HA to DR to Application promotion to migrations of the IBM i to the cloud. In those roles, he saw first hand the pains many have with Application Lifecycle Management, modernization, and data protection. His passion in those areas fits right in with the ARCAD suite of products.

The post Putting the CT in your CI/CD pipeline appeared first on ARCAD Software.

How IBM i Modernization Companies Can Reduce Technical Debt

We often hear that ‘change is the only constant’. This is certainly true in the world of software development. New products constantly come on stream and managers must make decisions on which of these to implement. Often they simply wait. The result can be ‘technical debt’. The purpose of this article is to explain the concept of technical debt. We will also look at how IBM i modernization can assist in dealing with it.

What is Technical Debt?

Let’s begin with a definition: Technical debt is the cost to the organization that builds up when important applications, infrastructure, and systems are not updated at optimal times. As systems get older, it costs more and more to update them. Businesses in technical debt also face increased risks, including security vulnerabilities and a lack of competitiveness. Fortunately, IBM i modernization is a cost effective and efficient strategy for dealing with the challenges posed by technical debt.

Why Does Technical Debt Occur?

Here are some of the main reasons behind technical debt:

Time pressures: It is often too easy to just use what we are used to. Especially because investigating new solution can be time consuming in itself.

Overly complex system design: It can be challenging to update very intricate systems. Yet, many developers opt for complex designs, often at the request of special interest groups within the company. Hence, technical debt can sometimes be imposed from outside the developer team.

Disregarding of standards: Many companies have strong policies in place to ensure that IT assets are at least somewhat future-proof. Unfortunately these can all too easily be ignored sometimes.

Lack of developer skill: Some developers can be very unsure about whether they will be able to effectively use new systems. This can easily turn them into activists for hanging on to legacy code and applications.

Insufficient testing and onboarding: Very often development teams only scratch the surface of what certain products can contribute. That means that all functionalities are not tested and developers are not trained to be optimally productive.

What Are Some of the Consequences of Technical Debt?

As with financial debt, it is a very bad idea to ignore technical debt in the hope that it will simply go away. It won’t. Instead it can lead to significant negative outcomes. Including the following:

Technical debt can make it harder to come up with new ideas and put them into action. When you put time and money into fixing something old, it’s hard to try something new.
It can be harder to respond to threats from competitors when you have technical debt. Your technical debt limits how quickly you can change and adapt to stay competitive.
Technical debt can make it difficult to find the right people for projects. It can be hard to find developers who are willing to work with older technologies when they can work for your competitors on cutting-edge technologies.

Over the next few sections we will look at how we can effectively deal with technical debt.

Step #1 – Acknowledge the Issue

The first step in dealing with technical debt, is to acknowledge the issue and to draw up a workable roadmap for getting back in the clear.

This can be challenging in some settings as managers will often baulk at what they believe will be significant cost blowouts. However, as we shall see, technical debt reduction need not break the bank. Especially, if it is done on the back of a well thought out IBM i modernization program.

Step #2 – Identify Signs of Indebtedness

An effective response is only possible if we are totally clear what we are responding to. It is, therefore, important to accurately measure the current state of indebtedness.

Measurement can include gauging how long it is taking tasks, how much remedial work is necessary and how much developer time is spent on keeping systems running. This should then be compared to what would have been possible in a modernized setting.

Accurate measurement can be difficult, and even painful, exercise. However, it is important that this step is done honestly so that any later actions are based on accurate information.

Step #3 – Set Priorities

A key outcome of the assessment process will be to indicate where the most pressing needs are. This will typically be the contexts in which you are losing the most money or where efficiency is most impacted.

A plan to ‘pay down’ technical debt should, obviously, ensure that the most pressing needs are dealt with first. Getting these on a list of priorities is a good step towards ensuring that technical debt is addressed in the most efficient and cost effective manner.

It is important to remember that setting priorities involves long term thinking. This means that we do not simply respond to what seems most urgent at the moment (the proverbial squeaky wheel). Instead we should take care to focus interventions in areas where they will make the most long term difference.

One way to ensure that priorities reflect long-term thinking is to ensure that people from across the enterprise are involved in setting the agenda.

Step #4 – Find Solutions

It is important to remember that there are probably many different ways of dealing with the particular combination of technical debts that you are dealing with.

In situations where you have a problem to solve it can be all to easy to simply reach for the ‘latest thing’. However, feverishly trying to stay on the cutting edge can sometimes have the perverse effect of entrenching technical debt even more. Yes, in some cases products may be necessary but this is not always the case.

In this instance, creative problem solving may involve finding ways to bring existing products or repurposing them. This is where IBM i modernization be a very valuable strategy (as will be explained below).

Step #5 – Plan to Remain ‘Debt Free’

Most of us are very aware of the perils of the ‘debt cycles’ where people, or companies, move in and out of debt, despite their best efforts to remain debt free. Any debt reduction strategy must, therefore, contain clear thinking about remaining debt free.

In the world of information technology the keys to remaining ‘debt free’ is to schedule regular reviews and testing. This will ensure that products are working as they should and will help in identifying areas where current configurations are falling behind.

How Can IBM i Modernization Help?

A significant proportion of the modern economy runs on aging IBM i infrastructure. This can be described as a massive instance of technical debt.

It may seem like the solution to this situation might be to ‘rip it all out’ and starting over. However, this approach brings the risk of cost-blowouts, relying on untested technologies and business disruption. It should also be remembered that constantly upgrading to unfamiliar products can impose a significant learning curve on developers, which is a kind of technical debt in itself.

The basic premise behind IBM i modernization is to bring IBM i assets ‘into the modern world’ by retaining their strengths and adding modern functionalities.

One might say that IBM i modernization involves a best-of-both-worlds approach. It can help companies to hang on to what is best about their current assets and making sure that it can deal with the latest technical demands.

The best modernization strategies will focus on delivering upgrades in a user-friendly way that will not be reliant on deep technical knowledge or superior coding ability. In fact, for a an upgrading strategy to be successful, it should major on bringing controls and interfaces into environments that modern developers are most comfortable with.

It should be obvious that there could be significant cost benefit associated with making use of IBM i modernization. It also has the advantage of keeping disruption to a minimum (since you will still be relying on the same underlying infrastructure). This is obviously invaluable from a business continuity perspective.

Ready to get started taking care of technical debt?

While paying of technical debt may seem like a daunting prospect, there are ways to ease the pain. A tried an tested method is through the use of IBM i modernization. This is where LANSA comes in.

Over the years LANSA developed a suite of resources that can take much of the pain out IBM i modernization. This includes the ability to bring legacy applications into new web and app based environments. LANSA products have been designed with ease-of-use in mind. A key feature is the fact that LANSA prides itself on making low-code solutions available. This means that developers can be brought up to speed very quickly and can do updating tasks without having to write complex code.

We would like to strongly encourage you to check out how LANSA can help your company pay down technical debt through IBM I modernization. You can start the journey by going to https://lansa.com

The post How IBM i Modernization Companies Can Reduce Technical Debt appeared first on LANSA.

Robot | Sizing Power10 Correctly with Performance Navigator

If you’re interested in learning more about Performance Navigator, sign up for a free trial here: https://www.helpsystems.com/products/capacity-planning-and-performance-analysis-software/download-trial

IBM Power10 technology is here for scale-out and scale-up servers running IBM i, AIX and Linux on Power. Performance Navigator is ready to help you plan your move to your next Power Server, whether it’s on-premises, dynamic capacity on-premises (PEP2), or in the cloud.

Performance Navigator is the only tool that can predict the exact model, processor, memory, storage, and VIOS needs for IBM Power10. Spend 30 minutes with HelpSystems Power Systems experts Randy Watson and Tom Huntington as they discuss:

-What is available for Power10 planning
-What you need to provide our HelpSystems or IBM Techline team to size properly
-How this service is used by most IBM resellers around the globe

You will learn the steps for proper capacity planning in a live demonstration and how this will save you in the future!

Watch now!

Verified by MonsterInsights