Welcome at the SAP on IBM i update! This time we will focus on the permanently running job SAPILED:
Did you ever wonder what the job SAPILED in subsystem QUSRWRK does?
Looking at the joblog, you will notice that the job iterates over all SAP systems on the LPAR every few minutes to check if the timestamp or the checksum of file ILE_TOOLS has changed. If so, a new job named SAPILEDX is launched to update the kernel library of SAP system <SID>.
What is going on here?
Whereas in kernel releases prior to 7.10 we primarily patched the kernel library and propagated this library to the application servers, we now primarily patch the file system, i.e. the /sapmnt/<SID>/exe tree. Because this file system tree is mounted on all application servers, the patch is immediately visible everywhere; but only the file system part of the kernel. What about the kernel library SAP<SID>IND? If the patch contains a newer version of ILE_TOOLS, the kernel library must be updated afterwards from this file.
Doing this automatically and transparently under the covers is the job of SAPILED. By the way, this feature also enables a pure sapcar patch apply capability on our platform. Without this SAPILED demon job, the administrator would have to call a tool interactively on every application server in order to create the kernel library after the administrator applied the patches to the kernel directory.
If you use sapcpe, the instance libraries SAP<SID>I<nn> (which are belonging to the instance kernel directories) are maintained by sapcpe and not by SAPILED.
For more information, please see SAP Note 1637588 ‘IBM i: Description of the program SAPILED’.
Stay tuned...
As the development team intends to maintain a consistent format, editions of the series will continue to be published. Set feeds accordingly if you are interested in following the series
