What if my code is not wrong, but someone else's? That is, when customization runs into a software-stack bug.

When a fix-pack is released, I often take a look at the bugs it fixes. Sometimes they are very specific issues, but others seem so pervasive from the description that you feel lucky to have never had a significant impact. For example, last December APAR IJ49377 was published, which found that automation scripts in JavaScript failed to share global objects, apparently causing out-of-memory errors in the system. From the description it seems to be related to a bug in Nashorn, the JS interpreter included in Java8 and thus used by Maximo since version 7.6.1 (before that the JS code was executed by Mozilla Rhino).

This immediately reminded me of an old problem we had with a very important customer of ours shortly after they upgraded to version 7.6.1. IBM technical support worked on it for over a year, but never identified the original cause of the instability that caused the memory used to increase dramatically until the WAS hang. The idea that it had something to do with the automation scripts made things very complicated because support rightly did not answer for the customizations, but it was also true that the same scripts had not caused any problems of this kind until the upgrade.

Fast-forward: As I read the APAR, I thought about how difficult it is sometimes to draw a clear line between software-stack issues and customizations. Maybe it had nothing to do with the problem I encountered, but I certainly breathed a sigh of relief when I read that it would be solved. Unfortunately, after checking with IBM systems, it seems that it has only been fixed in MAS v9 (link). While waiting for the fix to be released for Maximo EAM and MAS 8.11, what can be done? Fortunately, the APAR description also contains the solution to wrap the JS script with an anonymous function so that it does not actually declare the global variables that lead to our-of-memory. Crude but effective!

So, if you have JS automation scripts executed by Nashorn of the type:

var kv = {}; 
var woSet;
try {
   woSet = service.getMboSet("WORKORDER", userInfo);  
   kv[wo.getString("wonum")] = wo.getString("description");
} 
finally {
   woSet.cleanup();
   woSet.clear();
}
// then do something with kv...        

you should encapsulate all your code this ways:

(function(){

var kv = []; 
var woSet;
try {
   woSet = service.getMboSet("WORKORDER", userInfo);  
   kv[wo.getString("wonum")] = wo.getString("description");
} 
finally {
   woSet.cleanup();
   woSet.clear();
}
// then do something with kv...

})();        

function main() {
    var kv = []; 
    var woSet;
    try {
       woSet = service.getMboSet("WORKORDER", userInfo);  
       kv[wo.getString("wonum")] = wo.getString("description");
    } 
   finally {
       woSet.cleanup();
       woSet.clear();
    }
    // then do something with kv...
}

main();        

With the first, you can apply the hand-made fix in a massive way. The second is more of a coding style that requires some refactoring.

My final advice is to do the migration to the amazing MAS v9 as soon as possible... and don't blindly trust the software stack ??

PS: similar troubles could and will happen with any language, because at the end of the day, even the developers of the interpreters make mistakes; so write as few customizations as possible, in the smallest and cleanest code possible (KISS principle) and cross your fingers.