Interloc Solutions Blog

Part One - Why is an RFP or tender process usually the worst way to select a mobility solution?

A while ago, I wrote an article on my personal blog on how Use Ant to Deploy Automation Scripts. In the article, I walked through configuring a Publish Channel to export and an Enterprise Service to import Script and LaunchPoint information. I then provided an Ant script that could post data to the Enterprise Service. The reason for this script is to make it easy to deploy Automation Scripts from a source control repository like SVN or Git. While Migration Manager make it easy to migrate changes from one environment to another, it does not integrate nicely with a source control tool.

I recently needed to diagnose out of memory problems with Maximo. There is some information in the Maximo logs that can help. Maximo can display mbo counts and free memory information. Maximo will also log the number of active users and when crons execute.

We’ve all seen the dreaded “Record has been updated by another user. Refetch and try again.” It can happen when the record has been updated by another user, but it can also happen when the record is updated by the same user more than once. In memory, an MboSet owns zero or more MBOs. Each of those MBOs can have zero or more MboSets which in turn own zero or more MBOs. Naturally, if your MboSets contain zero MBOs you won’t have problems with records updated by another user. Problems will arise if two different MBOs reference the same database record and both MBOs attempt to update data. In memory, these MBOs will be represented as separate Java objects and will be owned by different MboSets. If only one MBO is updated, it won’t be a problem. If both MBOs are updated, the first will update the database record and change the ROWSTAMP value. The second will attempt to update the record but will fail because the ROWSTAMP doesn’t match. This will trigger an MXRowUpdateException.