The sayings are “practice what you preach” or the more down to earth expression “eat you own dogfood”. Eating your own dog food is a phrase that refers to the internal use of a company’s own products or services in its day-to-day operations. So over the years I have been advising customers to purchase a license to use Db2 Symmetric Multiprocessing (SMP). One customer was able to cancel his purchase of an extra IBM i core entitlement after implementing SMP. Apart from the initial purchase price of Db2 Symmetric Multiprocessing, it did not bring along an additional maintenance fee as it was part of the annual software maintenance. With this initial extra cost gone, my last article encourages everyone running IBM i to start using the power of SMP. Why hesitate right?

Over the years I have never seen a customer running into trouble making the move to implement SMP. That changed last month, please allow me to tell what happened.

In order to understand why this problem was not detected when testing, here’s some background information.

Some small customers today still have no separate LPAR for testing, when making a change on a system level this always carries a risk. Customers who do have a LPAR for testing are unable to test all their applications on that environment especially when we are dealing with application with outbound communication.

After activating SMP at 13:00 hours that day, a problem was reported half an hour later. The command CPYTOIMPF which had been used in an application for years, ran into an error. CPF2817:Copy command ended because of error followed by CPFA0D4: File system error occurred. Error number 3524. 

The second level text helped by showing where to look for the error number 3524  – Displayed the following file contained descriptions of error numbers: QSYSINC/SYS, member ERRNO.                                                

In order to have this QSYSINC library on your system, you need to have 5770SS1 option 13 – System Openness Includes” installed on your box. When looking there the text behind error number 3524 was “#define ENOTSAFE  3524 /* Function not allowed.” A quick search for ENOTSAFE, resulted in the link Errno Values for UNIX-Type Functions with the details behind “Function not allowed”: Function is not allowed in a job that is running with multiple threads.

When examining the CL command, we immediately noticed that the QDLS was in play. The File system QDLS leaves no doubt about it being threadsafe, it is not. The table File system comparison will tell you. Another knowledge base document of IBM is titled Comparison of the QDLS and “Root” File Systems for Storing User Documents and Other PC Files, containing the section shown below:

“QDLS is an old file system, dating from the System/36 and System/38 days. It is maintained mostly for compatibility with earlier versions. Some applications are hardcoded to store and access files in the QDLS file system. Companies that use those applications are required to use the QDLS file system, upgrade to a newer version of the application, or to migrate to a different application.”

The software version this knowledge base document is referring to is V7R1M0 which was announced in April 2010. So 12 years ago QDLS was already seen as old and the advice was to move away from it!

The fact is that IBM i is developed with the idea behind it, not to break old code. So QDLS can and is still being used today, but it has it’s limitations.

In order work our way around using SMP and not to have trouble with the CPYTOIMPF to QDLS I have prepared a little SQL script to give this a try yourself.

1. We first start by checking if we are not already using SMP:

select  * from (values(current degree));
A number higher than one is telling us we are already using SMP, so we can skip the next step.

2. When activating SMP in our job:
   set current degree=’2′;
3. When execute the CPYTOIMPF command:
   CL:CPYTOIMPF FROMFILE(QIWS/QCUSTCDT) TOSTMF(‘/QDLS/QIWSADM/test.txt’) MBROPT(REPLACE) STMFCCSID(PCASCII) RCDDLM(CRLF) STRDLM(NONE);

The folder QIWSADM should be available on your system.

4: This could result in the error messages:
CPFA0D4: File system error occurred. Error number 3524.
CPF2817: Copy command ended because of error.

If it runs fine, you are running only one thread in your current job as shown below:

How long idle threads stay available in your job is something I do not know. Yes after a while they disappear, but in this case they are a stand in the way and for that reason I would like to help them a hand and end them, just in case they are still out there.

5. Check how many threads your job is using. Just having them active is enough for the CPYTOIMPF command to crash, using the statement below:
   SELECT x.JOB_NAME, x.THREAD_COUNT
   FROM TABLE (ACTIVE_JOB_INFO(JOB_NAME_FILTER => ‘*’)) x;

6: Force trying to using more threads in your current job by running the SQL statement:

select * from qiws.qcustcdt where ZIPCOD<>21;
As mentioned in my previous article, the number two above the double arrows after the table scan indicate the SMP level used.

7. IBM i has the capability to end idle threads as document in the knowledge base document:
   https://www.ibm.com/support/pages/node/684991. This can be done by running the SQL statement:
   CALL QSYS2.END_IDLE_SQE_THREADS();

What can we take from this article are in fact two simple things. First of all stop using QDLS as it is limiting you in many ways. Not being able to use SMP could be one of them. The second thing is, whenever you use a command using QDLS remember to run the CL as shown below, ending all idle threads: RUNSQL SQL(‘CALL QSYS2.END_IDLE_SQE_THREADS()’) COMMIT(*NONE) NAMING(*SQL).

With that I can end this article with the same sentence as in my first article telling about Db2 Symmetric Multiprocessing: Why not get start using SMP today?