Maximo

MAM 7.6.1.2; clustered:

We want to extend the default 30-minute timeout setting in Maximo to 60 minutes -- so that users don't loose unsaved edits while driving between sites (yes, I know, training should solve that issue, but it hasn't so far).

Unfortunately, the process for extending the timeout setting in Maximo is more involved than we can handle right now, since it involves rebuilding the EAR.

Are there any workarounds we can use to avoid Maximo automatically timing out after 30 mins? We tried updating the timeout setting through the back-end, but that seems to have only applied to one of our UI JVMs, not all of them.
#AssetandFacilitiesManagement
#Maximo

I'd test it in a non-production environment to see if it's fast enough for your deployment, but I've used WebSphere's process to update a single file inside the EAR before (such as the maximo.properties) and preferred that as a full resync or other WebSphere event would have the updated EAR in its configuration. Otherwise we occasionally would have changes get lost which is bad. I haven't used it for the web.xml specifically and the web.xml is a bit unusual because the active copy is actually moved to a separate location but I assume it'd work. You can see the documentation on how to update a single file here: https://www.ibm.com/docs/en/was/9.0.5?topic=files-preparing-application-update-settings

If not, the other option is to go to each server and modify the active web.xml: https://www.ibm.com/support/pages/did-you-know-you-can-update-webxml-files-without-rebuildingredeploying-maximoear . My concern with this approach of course is that the change might get lost.

------------------------------
Steven Shull
------------------------------

Original Message:
Sent: Sat December 18, 2021 11:09 AM
From: User1971
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

MAM 7.6.1.2; clustered:

We want to extend the default 30-minute timeout setting in Maximo to 60 minutes -- so that users don't loose unsaved edits while driving between sites (yes, I know, training should solve that issue, but it hasn't so far).

Unfortunately, the process for extending the timeout setting in Maximo is more involved than we can handle right now, since it involves rebuilding the EAR.

Are there any workarounds we can use to avoid Maximo automatically timing out after 30 mins? We tried updating the timeout setting through the back-end, but that seems to have only applied to one of our UI JVMs, not all of them.
#Maximo
#AssetandFacilitiesManagement

The below doesn't help with your specific circumstance but there are a few tips I have used a few times that are worth sharing. This can make many changes and deployments faster in a lot of scenarios.  <rant> Its always bugged me that simple things like the timeouts aren't set as a property somwherein WAS or Maximo.properties.  You shouldn't have to redeploy for somthing as common place as this </rant>.      

1) Speed up deployment by adding extra memory to the deployment process.  The simplest way to do that is to modify the ejbdeploy.bat/sh script in your envirionment.
scroll to the bottom of this IBM Doc for more details. We have seen some significant performance improvements in some environments with this change.  Start with Xms (initial size) and  Xmx (Max size) both at 1024m as a starting point and grow from there as your memory allocaiton allows.  Settign both the same will simply create a 1 GB block of memory and it wont grow in time as the deployment runs.   You should see an decrease in deployment time as a result.  https://www.ibm.com/support/pages/increasing-maximum-heap-application-deployments-websphere


2) Move the Maximo properties out of the ear altogether by using the Dmxe.properties.overridepath property for the JVM.  This allows you to make changes but you need to remember to validate your Maximo.propoerties file after upgrades and changes so that the version specified in the override path has any updated values as well.  Also if you are in an environment with lots of JVM's make sure you use a good naming convention so you know which Maximo.properties files belong to which application Server.  I usually use <WAS AppServerName>.maximo.properties and keep them in the same directory
more info in this document here about how to move maximo properties https://www.ibm.com/docs/en/cdfsp/7.6.1?topic=SSANHD_7.6.1/com.ibm.mbs.doc/user/t_change_password_live_refresh.html


------------------------------
Michael Kasteel
Director
ISW
0402830412
------------------------------

Original Message:
Sent: Sat December 18, 2021 11:09 AM
From: User1971
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

MAM 7.6.1.2; clustered:

We want to extend the default 30-minute timeout setting in Maximo to 60 minutes -- so that users don't loose unsaved edits while driving between sites (yes, I know, training should solve that issue, but it hasn't so far).

Unfortunately, the process for extending the timeout setting in Maximo is more involved than we can handle right now, since it involves rebuilding the EAR.

Are there any workarounds we can use to avoid Maximo automatically timing out after 30 mins? We tried updating the timeout setting through the back-end, but that seems to have only applied to one of our UI JVMs, not all of them.
#Maximo
#AssetandFacilitiesManagement

Interesting. Thanks!

RFE:
Change timeout setting without rebuilding EAR
https://ibm-ai-apps.ideas.ibm.com/ideas/MASM-I-748

Original Message:
Sent: Tue December 21, 2021 09:30 PM
From: Michael Kasteel
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

The below doesn't help with your specific circumstance but there are a few tips I have used a few times that are worth sharing. This can make many changes and deployments faster in a lot of scenarios.  <rant> Its always bugged me that simple things like the timeouts aren't set as a property somwherein WAS or Maximo.properties.  You shouldn't have to redeploy for somthing as common place as this </rant>.      

1) Speed up deployment by adding extra memory to the deployment process.  The simplest way to do that is to modify the ejbdeploy.bat/sh script in your envirionment.
scroll to the bottom of this IBM Doc for more details. We have seen some significant performance improvements in some environments with this change.  Start with Xms (initial size) and  Xmx (Max size) both at 1024m as a starting point and grow from there as your memory allocaiton allows.  Settign both the same will simply create a 1 GB block of memory and it wont grow in time as the deployment runs.   You should see an decrease in deployment time as a result.  https://www.ibm.com/support/pages/increasing-maximum-heap-application-deployments-websphere


2) Move the Maximo properties out of the ear altogether by using the Dmxe.properties.overridepath property for the JVM.  This allows you to make changes but you need to remember to validate your Maximo.propoerties file after upgrades and changes so that the version specified in the override path has any updated values as well.  Also if you are in an environment with lots of JVM's make sure you use a good naming convention so you know which Maximo.properties files belong to which application Server.  I usually use <WAS AppServerName>.maximo.properties and keep them in the same directory
more info in this document here about how to move maximo properties https://www.ibm.com/docs/en/cdfsp/7.6.1?topic=SSANHD_7.6.1/com.ibm.mbs.doc/user/t_change_password_live_refresh.html


------------------------------
Michael Kasteel
Director
ISW
0402830412

Original Message:
Sent: Sat December 18, 2021 11:09 AM
From: User1971
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

MAM 7.6.1.2; clustered:

We want to extend the default 30-minute timeout setting in Maximo to 60 minutes -- so that users don't loose unsaved edits while driving between sites (yes, I know, training should solve that issue, but it hasn't so far).

Unfortunately, the process for extending the timeout setting in Maximo is more involved than we can handle right now, since it involves rebuilding the EAR.

Are there any workarounds we can use to avoid Maximo automatically timing out after 30 mins? We tried updating the timeout setting through the back-end, but that seems to have only applied to one of our UI JVMs, not all of them.
#Maximo
#AssetandFacilitiesManagement

For what it's worth, this was done in MAS 8.6 as a global setting that impacts all the underlying products (Manage, Monitor, Health, etc.). This was done to ensure that users get logged out in a timely manner if they forget to sign out so that their app points are returned to the pool. I realize not everyone will be able to make the switch to MAS yet but I figured I'd share.

------------------------------
Steven Shull
------------------------------

Original Message:
Sent: Tue December 21, 2021 11:24 PM
From: User1971
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

Interesting. Thanks!

RFE:
Change timeout setting without rebuilding EAR
https://ibm-ai-apps.ideas.ibm.com/ideas/MASM-I-748

Original Message:
Sent: Tue December 21, 2021 09:30 PM
From: Michael Kasteel
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

The below doesn't help with your specific circumstance but there are a few tips I have used a few times that are worth sharing. This can make many changes and deployments faster in a lot of scenarios.  <rant> Its always bugged me that simple things like the timeouts aren't set as a property somwherein WAS or Maximo.properties.  You shouldn't have to redeploy for somthing as common place as this </rant>.      

1) Speed up deployment by adding extra memory to the deployment process.  The simplest way to do that is to modify the ejbdeploy.bat/sh script in your envirionment.
scroll to the bottom of this IBM Doc for more details. We have seen some significant performance improvements in some environments with this change.  Start with Xms (initial size) and  Xmx (Max size) both at 1024m as a starting point and grow from there as your memory allocaiton allows.  Settign both the same will simply create a 1 GB block of memory and it wont grow in time as the deployment runs.   You should see an decrease in deployment time as a result.  https://www.ibm.com/support/pages/increasing-maximum-heap-application-deployments-websphere


2) Move the Maximo properties out of the ear altogether by using the Dmxe.properties.overridepath property for the JVM.  This allows you to make changes but you need to remember to validate your Maximo.propoerties file after upgrades and changes so that the version specified in the override path has any updated values as well.  Also if you are in an environment with lots of JVM's make sure you use a good naming convention so you know which Maximo.properties files belong to which application Server.  I usually use <WAS AppServerName>.maximo.properties and keep them in the same directory
more info in this document here about how to move maximo properties https://www.ibm.com/docs/en/cdfsp/7.6.1?topic=SSANHD_7.6.1/com.ibm.mbs.doc/user/t_change_password_live_refresh.html


------------------------------
Michael Kasteel
Director
ISW
0402830412

Original Message:
Sent: Sat December 18, 2021 11:09 AM
From: User1971
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

MAM 7.6.1.2; clustered:

We want to extend the default 30-minute timeout setting in Maximo to 60 minutes -- so that users don't loose unsaved edits while driving between sites (yes, I know, training should solve that issue, but it hasn't so far).

Unfortunately, the process for extending the timeout setting in Maximo is more involved than we can handle right now, since it involves rebuilding the EAR.

Are there any workarounds we can use to avoid Maximo automatically timing out after 30 mins? We tried updating the timeout setting through the back-end, but that seems to have only applied to one of our UI JVMs, not all of them.
#AssetandFacilitiesManagement
#Maximo

Original Message:
Sent: Sat December 18, 2021 11:09 AM
From: User1971
Subject: Workarounds for MAM timeout to avoid rebuilding EAR

MAM 7.6.1.2; clustered:

We want to extend the default 30-minute timeout setting in Maximo to 60 minutes -- so that users don't loose unsaved edits while driving between sites (yes, I know, training should solve that issue, but it hasn't so far).

Unfortunately, the process for extending the timeout setting in Maximo is more involved than we can handle right now, since it involves rebuilding the EAR.

Are there any workarounds we can use to avoid Maximo automatically timing out after 30 mins? We tried updating the timeout setting through the back-end, but that seems to have only applied to one of our UI JVMs, not all of them.
#AssetandFacilitiesManagement
#Maximo