Day: September 29, 2022

Five costly mistakes that IBM i companies make

Five Costly Mistakes That IBM i Companies Make

IBM Power Systems are the most reliable, available, and securable systems in the world, and IBM i is hands down the best Operating System. This is why the IBM i is the backbone of many critical business processes, including financials, payroll, warehousing, distribution, and logistics, to name a few. Yet despite being responsible for running the world, the IBM i is often neglected, leading to costly mistakes.

Just because the hardware and software can run for a long time without any maintenance doesn’t mean you should let it. You know the saying, “the squeaky wheel gets the grease,” well, since the platform is so stable and reliable, it rarely squeaks. For this reason, some companies tend to ignore their IBM i. Chatty Windows environments get all the time and attention because, without it, they fail.

You’re better off spending some time and money to keep your IBM i system more current as this will help you avoid these common, costly mistakes that IBM i companies make.

#1 Assume their IBM i Secure

One of the top concerns for CIOs continues to be security year after year. The threat from ransomware and viruses continues to grow. iTech has helped over twenty companies recover from Ransomware attacks on their IBM i over the past year and a half. All these companies had one thing in common, a false sense of security regarding their IBM i platform.

This false sense of security is the biggest threat to IBM i shops because they assume they are not a risk. We know the IBM i can’t execute a program, which means you can’t infect your DB2 database with a virus, but IFS file shares can expose your IBM i OS to ransomware attacks that can encrypt your data. Users with default passwords expose your system to a potential breach and combine that with users with excess authority, and your system is a hacker’s dream.

Just because your system was secure ten years ago doesn’t mean it is today. We can no longer assume our IBM i is secure. Like your network and other platforms, you should review your IBM i security controls regularly to ensure they are still adequate.

#2 Lack of Disaster Recovery Testing

Given the increased level of threats of ransomware on IBM i, you need to have a good disaster recovery plan in place. Not only do you have to have a …

System Cleanup My QUSRBRMQA1ALI2 File is Large

System Cleanup: My QUSRBRM/QA1ALI2 File is Large

Backup, Recovery, and Media Services (BRMS) is a great tool for backing up your system and keeping track of what data lives on what backup media. You can quickly look up libraries that you have backed up, see what day they were backed up on, what time, and the volume number they are on. As well, you can look up the times that you’ve backed up the Integrated File System (IFS), and if you tell BRMS to do so, it will keep track of all the objects you have backed up – every single one of them! While being able to look at every backup and drill down to a specific IFS object for a restore sounds FANTASTIC… it does come at a cost:  disk space.

Each day, your system should be running BRMS maintenance, which expires any volumes that have reached their expiration date.

When volumes expire, BRMS deletes the records it was keeping on that now expired volume. Because of this, you should also be running BRMS maintenance with a file reorganization as least once a week and at most once a day alongside maintenance (RGZBRMDB parameter in the STRMNTBRM command). The file reorganization will remove deleted records from the BRMS database files, which will return space back to your system.

Where BRMS can often chew away at your disk space is when you have a BRMS backup that runs often, backs up the entirety of the IFS, and then retains that data for a long time due to a long expiration date. Over time, this can cause your BRMS IFS database file (QUSRBRM/QA1ALI2) to swell to an enormous size. To control whether or not BRMS keeps information on IFS backups, you must look in your control groups you are using. Find all the items in your backups that are *LINK (all of IFS) or have a List Type of *LNK (often a subset of IFS data). Take a look at the Retain Object Detail column. If this is set to *YES for these items, then BRMS, by default, is keeping track of everything backed until it is cleaned up during maintenance. This adds up to hundreds of thousands to multiple millions of records per backup.

System Cleanup: My QUSRBRM/QA1ALI2 File is Large

Retain object detail inside a BRMS control group. A copy of the *SYSTEM control group will have this set to *YES by default.

My recommendation for anyone that has lengthy retentions of …

Obtaining Your Last IPL Details

Sometimes, I’ve found myself needing to check the last time a system has done an IPL. That information can be obtained a few ways – by checking the start date and time of the SCPF job, or by looking at the QCTL subsystem. This doesn’t necessarily show you the full details though.

IBM has a neat little program, which gives you the last time the system performed an IPL, along with how long each step of the IPL took. This information is produced in a relatively small spool file. It can be a little intimidating to look at but is relatively straightforward. This data can be beneficial for maintenance planning, or after an abnormal system shutdown.

To generate the report, enter the following on the command line:

CALL PGM(QWCCRTEC)

The spool file produced by the QWCCRTEC program is called QPSRVDMP. The first 85 characters are a hexadecimal presentation of the data that we are looking for. Just to the right of that, starting at column 90, are the details are we are after. In this example, you can see when the power down of the system began – as indicated by ‘XPF PWRDWN’, as well as when the power down was completed, ‘End PWRDWN’.

Obtaining Your Last IPL Details

Further along, we can see all the details of our last IPL on this system. The beginning of the IPL is marked with ‘XPF IPL’, and the end is marked with ‘End of IPL’. Each step of the IPL is listed in between, using the same C6xx and C9xx status codes that you would find on an HMC, front operations panel, or LAN Console during the IPL process. These codes can be referenced on IBM’s reference codes site. Note that the exact link to this reference material will vary depending on your Power System model.

From this report, we can tell that the last IPL on this system was rather quick, with a power down at 11:01 and the IPL finishing at almost 11:05.

Obtaining Your Last IPL Details

Obtaining Your Last IPL Details

If you want to find the type of IPL performed (unattended, attended, after abnormal system end), you can find that information in the system log. Rather than scroll through several pages of the system log, I’ve found a simple SQL query will do the trick.

 

SELECT MESSAGE_TIMESTAMP,MESSAGE_ID, MESSAGE_TEXT

FROM TABLE(QSYS2.HISTORY_LOG_INFO(‘2022-09-11-11.00.00.000000’,

‘2022-09-11-11.30.00.000000’))

WHERE MESSAGE_ID IN (‘CPF0903′,’CPF0905′,’CPF0997′,’CPF0998’)

More from this month:

iTech Newsletter September 2022

September 2022 Newsletter

This newsletter includes:

I guess it was just a matter of time as we all knew it was coming, eventually.  IBM i 7.3 is going out of support next year, Sept 30, 2023.  I guess the handwriting was on the wall when IBM came out with 7.5 in the spring, as they don’t normally support 3 releases of the operating system at once.  Quite honestly, I was a little surprised they kept the support that long, as I had expected once 7.5 was announced that they would drop the support for 7.3.…