Day: May 25, 2021

Throwback Thursday: Hidden Gems in IBM’s QMGTOOLS Utility Library

Throwback Thursday: Hidden Gems in IBM’s QMGTOOLS Utility Library


On-Demand

[ Watch Now ]

If you have ever had a complex support case with the IBM i support team in Rochester, they may have instructed you to install the “QMGTOOLS” system utility to gather and also possibly send critical problem-solving information to them to help resolve your system’s issue.

The “MG” in “QMGTOOLS” stands for “Must Gather” as the genesis of the tool was a requirement to package a bunch of commands that collect information that “must be gathered” to resolve certain kinds of support issues.

For many of you, working with QMGTOOLS to provide info to IBM on a technical problem may have been the first time that you’ve ever dealt with the QMGTOOLS utility package, and for many of you who have only worked with QMGTOOLS at IBM’s direction on a support case, or, never even heard of it.

Join Marc as he covers hidden gems in QMGTOOLS.

May 2021 Newsletter

This newsletter includes:

As you read this newsletter, we will have done our first in-person conference in over 18 months: COMMON’s NAViGATE in Columbus, Ohio.  I am sure looking forward to getting back to the new normal, and meeting customers, prospects, individuals, and — well, just everyone. I’ve been cooped up way too long, and now that I am fully vaccinated, I am ready to get back to life.  It will be interesting, and Laurie and I plan to do a podcast and video clips on the conference to show you what the conference is like. While I understand the in-person is on the lighter side (as we would have expected), the virtual conference has quite a few attendees.…

What Do I Need To Do Full System FlashCopy Backups?

Full System FlashCopy (FSFC) Toolkit is a tool developed by IBM to allow you to capture full backups of your entire system with little to no downtime. It is becoming very popular for shops that are running 24/7, where any downtime to the system becomes very costly. You may be considering using this option for backups on your system, but you have no idea what you need to get to implement it.

Listed here are the key items you need to have:

  • Be on at least IBM i 7.2.
  • Have available CPU, memory, and disk resources for two LPARs:
    • A “Controlling” LPAR where the toolkit begins running.
      • Can be a Dev/UAT partition. Any partition you don’t plan to use Full System FlashCopy with.
      • If you need to create one, you will need the following resources:
        • 05 CPU
        • 6 GB RAM
        • 400 GB of storage
        • Physical adapters for Ethernet, Disk, and Tape or virtualized through Virtual I/O Server.
      • A target LPAR for the FlashCopy disks to attach to.
        • Hardware requirements:
          • 05 CPU
          • 8 GB RAM
          • Target disks can be thin provisioned. Storage used increases the longer the FlashCopy lasts as bits get copied over from the Source. Expect to need around 10% of the size of the source disks.
          • Physical adapters for Ethernet, Disk, and Tape or virtualized through Virtual I/O Server.
        • You may have to do some shuffling to get the necessary CPU and memory resources. If you need to buy an additional IBM i license, it can greatly affect the price of implementation.
        • Licenses for the following licensed programs (only on the Controlling LPAR):
          • License for PowerHA Standard or Enterprise.
          • License for HA Switchable Resources
        • A Hardware Management Console (HMC). Can be physical or virtual.
        • A Storwize, FlashSystem, or DS8000 SAN that is licensed for FlashCopy.
        • SAN switches for zoning disks and tape.

If you are coming from a single partition system, the requirements for FSFC are very steep. In many situations, it can be costly to implement, but you have to consider the cost of bringing down the system for backups. Run the numbers to see if the cost of downtime is greater than the cost to implement.

Also, consider your current backup strategy and what you’re able to capture while the system is up. I will wrap this up with a question:  If your production system becomes compromised, do you want your last save to contain EVERYTHING

Why Sharing the /QDLS Directory in NetServer Should Be Avoided

Many IBM i installations use the NetServer facility of the operating system to present directories in their system’s IFS as standard SMB file shares on their network, shares that can be accessed by Windows client PCs and any other SMB clients that may need to access IFS directories.  It is very common in many shops for customers to have a share directly on the /QDLS folder, but what many don’t know is that directly accessing files in /QDLS via a standard NetServer file share can be problematic.

Why is it not a good idea to share /QDLS as a NetServer file share?

It is because of multithreading.  NetServer by default is shipped as a multithreaded facility for optimal performance, and because /QDLS is a very old directory technology that cannot support multithreading, any file share connections to /QDLS must be single-threaded.  If an SMB client (e.g. a Windows PC) makes its initial SMB connection to the system via a share on /QDLS then the NetServer server-side connection will be a single-threaded job, and any additional accesses to other IFS directories (e.g. outside of /QDLS) will also be funneled through that single-threaded connection.  If an SMB client makes its initial SMB connection to the system via a share on a normal IFS share (“normal” = a share on a directory outside of /QDLS) then the NetServer server-side connection will be a multithreaded job and any requests to access /QDLS after that initial connection will fail, and therein lies the fundamental problem with /QDLS NetServer shares.

So, how do you avoid encountering these connectivity issues with shares on /QDLS?

The best practice approach is to not have a share on /QDLS in the first place.  If you have code running on your system now that requires the use of the /QDLS folder (e.g. you may have a population of old applications that execute CPYTOPCD commands to create ASCII files of database files in /QDLS), then a good workaround is to still use the /QDLS folder but then after you place files in that folder then have your application take the additional step of moving those files from /QDLS to a normal IFS directory (outside of /QDLS) that can then be accessed via its own SMB share that will be serviced by a multithreaded connection on the server-side.

If you must continue to use a share on /QDLS for whatever technical/application reasons and …

OpenJDK Disables Legacy TLS Versions

Beginning on April 20th, 2021, the OpenJDK releases of Java 8, Java, 11, and Java 16 are shipped with TLS v1.0 and TLS v1.1 disabled. If you are using one of these updated OpenJDK Java releases with IBM i Access Client Solutions, this change may cause issues when attempting to connect securely to systems running older operating systems. In particular, while IBM i 7.1 did gain TLS v1.2 support at TR6, the SSL Control system values only enable TLS 1.0 by default. Connecting to one of these systems will produce an error in ACS:

MSGSSL002 -“IBMi server application is not trusted for secure socket connection.”

If you need to establish an ACS connection using TLS 1.0 or TLS 1.1, these protocols can be re-enabled by altering a Java configuration file. First, make sure all Java instances are closed, then locate the Java security file deep inside the Java installation directory, under conf > security > java.security. The file can be edited in Notepad or any other text editor. Search for the jdk.tls.disabledAlgorithms property and remove TLSv1 and/or TLSv1.1 from the list, save the file, then restart ACS.

Keep in mind that the reason that these protocols have been disabled is because they are now insecure by modern standards. Re-enabling them means you are intentionally using an unsecure connection method, so if you need to do this to get connected to your systems then it is time to review the security on your system.

More from this month: