Maximo Concepts

Auto Restart Websphere JVM after a Crash

Auto-restarting the WebSphere JVM after a crash can be a useful feature for ensuring uptime and minimizing downtime. In this blog post, we will discuss how to enable the auto-restart setting in WebSphere.

First, navigate to the Monitoring Policy under Java and Process Management section for the Application Server in the WebSphere administrative console. In the Monitoring Policy, you will find the option to set the Node Restart State. Change this setting to “Running” for the JVM in question.

It’s worth noting that this setting will also bring the JVM up when the node is started, ensuring that your application is always running and available.

Additionally, it is recommended to monitor the JVM logs, and in case the JVM crashes frequently, it’s best to investigate the root cause of the crash.

For more information, refer to the following link: https://www.ibm.com/support/pages/automatic-restarting-websphere-services

In conclusion, auto-restarting the WebSphere JVM after a crash can be a useful feature that helps to ensure uptime and minimize downtime. By following the steps outlined in this post and the reference link provided, you can easily enable the auto-restart setting in WebSphere and keep your application running smoothly.

DBC Technical Reference

Well, reference documents vanishing from IBM site is no new news. This is what happened with the DBC Technical Reference Guide that was available on the IBM site till last year. I was looking for it a few days ago but couldn’t find it on the IBM site. I thought it was gone along with all the other developerworks articles.

But thanks to Cezar Tipa who had an offline copy and Biplab Das Choudhury who shared it on Linkedin a copy of it is still available.

I downloaded a copy and uploaded it here. You can find a link to the document below.

DBC XML Format for Technical Consultants

Update JAVA_HOME in Websphere

This is for an old version but helpful.

e.g. –

Unix: JAVA_HOME=/usr/local/java/jdk1.4.0_13

Windows: JAVA_HOME=C:\j2sdk1.4.2_14

Update the JAVA_HOME variable to point to the location where the JDK is installed. Restart WebSphere Application Server for the changes to take effect.

reference: https://community.microstrategy.com/s/article/KB16159-How-to-change-the-location-of-the-Java-JDK-JAVA-HOME?language=en_US

File Deployment From WebSphere Console

Have you ever come across a situation where your development environment WebSphere is on Linus/Unix and you don’t have access to the filesystem to hot deploy your class changes for testing? Well it’s pretty common if you are working for a big company which has lot of security policies in place. But what do you do? Do you go through all the pain of building the EAR and deploying it to WebSphere only to realize that there was a small piece of code that you missed and that you have to build and deploy all over again! Isn’t that really frustrating!

What I am going to tell you is not as quick a fix as doing a hot deployment, but it does save some deployment time. With this, you won’t need to build the EAR all over again, just have to do the deployment which takes half the time of a full EAR deployment.

This functionality in WebSphere lets you deploy delta changed to an application. All you have to do is 1 – select the application you want to deploy the changes to, 2 – select the path where the file has to be placed inside the application and 3 – select the file on the local filesystem which has to be uploaded and WebSphere will deploy that file for you.

Lets take an example – I want to deploy a class – abc.class in businessobjects.jar at the this path – com\pk\cron. Under the enterprise applications section in WebSphere, there is an option called Update which will let you upload/update this file in the businessobjects.jar. With this you can upload new files or update existing files.

Follow along with the screenshots, it pretty much self explanatory. Only thing you have to be careful about is the path inside the application EAR, that should be correct or WebSphere will place the file in wrong path. If you are not sure about the path, open the EAR, navigate through to the folder where you want to deploy the file and copy that path.

In this case the path is – businessobject.jar\com\pk\cron\abc.class

businessobjects.jar BEFORE uploading the file –

businessobjects.jar AFTER uploading the file –

Until next time!

Maximo Concepts Has Been Moved!

Welcome to Maximo Concepts.

This blog has been moved from maximoconcepts.wordpress.com to maximoconcepts.com.

What that means is I wouldn’t be updating or publishing blogs on maximoconcepts.wordpress.com anymore, I would be doing it here from now on. From the looks and feel prospective, nothing has changed, your experience would remain the same.

Unfortunately, people who had subscribed to my old blog will have to subscribe again here. I would do my best to subscribe them myself, if you get a subscription confirmation request from this blog, please accept it.

So for the latest updates you are at the right place. There is a whole new section on the right panel for subscribing so don’t forget to subscribe!

Cheers!

Load Balancing Using IHS – 101

How does IHS load balancing work?

IHS or the IBM HTTP Server is an apache HTTP server implementation with a topping of IBM configuration. IHS is not a part of WebSphere but you can install it separately and add it to WebSphere, that way you can manage it using the WebSphere console.

In addition to all the function of a webserver, IHS can also be used to as a load balancer which means you can use IHS to spread the traffic evenly across all your JVMs and in case a JVM crashes or is otherwise down, traffic won’t be routed to that JVM.

For IHS to do the load balancing it should have the understanding of the clusters, JVMs that are there in those clusters, virtual hosts, context roots, etc. and since IHS is not a part of WebSphere there needs to be a way for it to do that, this is where the plugin comes in. The plugin is basically an xml file that has details of the clusters and it members, virtual hosts associated to the applications on the clusters and a lot of other details. By default this file is updated every minute to keep the latest configurations updated.

The plugin has to be installed separately and should be linked to the IHS. If you use the launch pad to install the plugin, it takes care of associating the plugin to the IHS, if you are installing it manually you need to make sure you link it to the IHS.

That’s it for today!

Until next time!

Things You Must Know Before Using Migration Manager

Migration manager is a really great tool for migrating configurations from one Maximo instance to another. It does all the validations and tells you of any dependency that you may have missed in the package. Unfortunately it doesn’t tell you that while creating the package but does it while the package is being deployed and I wouldn’t blame migration manager for that. When the package is being created in the source environment, it doesn’t really know where it’s going to be deployed and whether the target environment had all dependencies or not. It’s when the package is being deployed that the migration manager gets to know that the dependencies don’t exist in the target environment and the package errors out. I’ll take an example and explain.

Let say you want to migrate an object from one environment to another. You create a migration manager package for that object which includes all its attributes but not the domains that are associated with those attributes. When you deploy this package to the target environment, it would fail if those domains don’t exist there.

Migration Manager has its own section for mentioning dependencies and most the out of the box migration groups have dependencies already specified.

2017-11-06 13_48_22-Migration Groups

2017-11-07 09_58_25-Migration Groups

But I don’t prefer using this dependency functionality of Maximo and here’s why – If you see the images above, Data Dictionary is one of the dependencies for the application migration group which should be the case but what this would do is take the entire data dictionary from the source environment and deploy it in the target environment.

You really wouldn’t want to do that because

If a developer has created any attribute or domain for testing some functionality and didn’t delete those, they would be migrated too. Worst, if someone changed or removed a class from an OOB attribute or removed the domain associated to it, that would be migrated too. This could break existing functionality.
And if not any of that, it would unnecessarily take a lot of time for deploying the package since there would be the entire data dictionary from the source that would have to be compared to the existing data dictionary of the target for changes.

Unfortunately if you don’t know about this feature of Migration Manager or you are not careful about it, you might unknowingly migrate certain configuration that were not required.

So it’s better to maintain dependencies by you yourself then having Maximo maintain it for you.

Have a great day!

Cheers!

Why isn’t That Cron Task Running!

All of them are running, running and running, the long, never ending marathon but what is it with that one lone runner, why isn’t he running?

It’s a rare occurrence but you may come across such cron task that is sitting there not executing at all while all the other cron tasks are running just fine! You would see that though it is set to active and the history logs tell you that it started successfully or it was working fine till a certain point but after that there hasn’t been any action.

What is it with this cron task?

It cannot be the admin mode since other cron tasks are running fine. It could be the mxe.crontask.donotrun property but in that case it wouldn’t have started or actioned at all. But better to still double check.

Rare but not impossible, this may be caused by incorrect entry in the task scheduler table.

What is Task Scheduler Table?

The TASKSCHEDULER table is used by Maximo to control the schedule of cron tasks.

Before a cron task runs, Maximo gets the last run information from TASKSCHEDULER table, and if no information is found, it will insert a new record in TASKSCHEDULER table if needed.

For more information about task scheduler table check this post.

What’s the issue with the Task Scheduler?

As I mentioned earlier, the issue may be caused by incorrect entry in the task scheduler table, especially when the LASTRUN is greater than the LASTEND which means the cron task is running or atleast the system thinks that the cron task is running and wouldn’t invoke it again.

TaskScheduler

This could be because the JVM crashed while the cron task was running and the execution couldn’t complete and so the last run was not updated. It is also possible that the cron task actually got into a hung state during execution.

Another possibility is that there are two entries for the same cron task in the task scheduler table which confuses the system. May be the cron task is running too quickly and it sends an entry twice to the task scheduler, because it didn’t have enough time to complete the first execution. Cron task running on multiple JVM in a clustered environment could also be the cause.

How to fix it?

Delete the entries for the cron task from the task scheduler table. The cron task manager would see that the cron task is active but doesn’t have entry in the taskscheduler so it would create an entry and wait till the next schedule and to run the cron task.

If you want to understand the sequence of events that happens when the cron task starts and shuts down, you can check this post.

Until next time!

Cheers!

Adding a Field to an Existing Interaction in Maximo

If you have ever worked on interactions in Maximo, you would know how easy it is to set up one and start fetching data from a webservice. It helps you avoid the hassle of writing and maintaining custom code with just a few configuration steps. Practically it does all the work for you – from creating objects and relationships to setting up the dialog box and sigoption to display the data.

But when it comes to adding a new attribute to be fetched and displayed from the webservice, it requires the entire thing to be created again. This means the interaction and all its configurations have to be scrapped and recreated with the new set of attributes. That’s a lot for just a field addition.

So I thought what if we manually add this attribute to the objects and to other configurations and see if it works out.

To explain this better, I have an interaction that fetches all the football matches that have been played in the city (which is the location record in Maximo). The data is just fetched from the webservice for display and not inserted or committed anywhere.

Now I want to show the ‘Result’ field in the dialog box from the webservice response but the problem is – this field was not initially selected while creating the interaction so it’s not present in the object that handles the webservice response. So to show this field in the dialog I did the following –

Added the new attribute to the response object – The attribute name and the data type must be the same as that of the field in the webservice. The description of the attribute must be the path of the field in the response XML. This is what the description of my field looks like –ns0:GamesPerCityResponse/ns0:GamesPerCityResult/ns0:tGameInfo/ns0:sResult
Included the new attribute to the response object structure
Added the new attribute to the dialog in the app designer

But I noticed that still the data was not being fetched and shown in the field. So I did some more research and found that there is an OBP (Object Blue Print) field in the MAXINTERACTION table that keeps the xml schema of the request and response for the interaction. The new field needs to be added to that schema for it to work. So I updated the schema and Voila! it worked!

2017-04-25 22_59_21-Locations

Please note that this solution is applicable only if the field already exists in the webservice schema and only needs to be displayed in Maximo.

Enjoy!

Until next time!

Meter Change Out in Maximo for Transportation

I recently came across a feature in Maximo that can be really useful in scenarios where meter reset/meter changes are not so rare occurrences.

You may come across several scenarios where the meter on an asset is either replaced or reset due to certain maintenance activities. These maintenance activities could either be a scheduled maintenance like overhaul or be an unscheduled corrective maintenance due to a component or meter failure. In either case the meter reading of the meter in Maximo would have to be reset to a new value.

First thing that would strike you would be to enter the new reading on the asset through the enter meter reading option. But that wouldn’t work for continuous meters since if the new reading is less than the old reading, the meter reading will actually rollover and the life to date reading will show incorrect value. And if the new meter reading is more than the old reading, Maximo will accept the new meter reading but the life to date reading will still be incorrect.

2017-01-16-21_02_29-assets-tr 2017-01-16-21_02_36-assets-tr

This is where the meter change out feature of the Asset(tr) application comes into picture. The meter change out functionality updates the last meter reading of the meter with the new reading and also maintains the life to date reading. You also have the option to update the life to date reading while performing the meter change. See how it works –

2017-01-16-23_44_28-assets-tr 2017-01-16-23_44_33-assets-tr 2017-01-16-23_45_15-assets-tr 2017-01-16-23_46_04-assets-tr

Until next time!