Setting value to Null for a Field

 Setting value to Null for a Field in Maximo

if mbo.getString("ATTRIBUTENAME") is not None:

    mbo.setValueNull("ATTRIBUTENAME")

Concatenate the modified Location specification for a location

Concatenate the modified Location specification for a location and send mail.

Create a non Persistent Field LocStore with ALN type  LOCSPEC

  

from psdi.util.logging import MXLoggerFactory

from psdi.plust.app.location import PlusTLocation as Location

from psdi.util.logging import MXLogger

from java.util import Properties

from psdi.server import MXServer

logger = MXLoggerFactory.getLogger("maximo.script")

logger.debug("LOCSPEC=> Executing Script")

classsMboSet = mbo.getMboSet("CLASSSTRUCTURE")

if classsMboSet.isEmpty() == False:

    classMbo  = classsMboSet.getMbo(0)

    classificationid = classMbo.getString("CLASSIFICATIONID")

    if classificationid == 'AIRPORT':

        mbo.isModified("ALNVALUE")

        VALUE=mbo.getString("ALNVALUE")

        if VALUE is None:

         VALUE=mbo.getString("NUMVALUE")

        locspec_owner = mbo.getOwner()

        if isinstance(locspec_owner,Location):

          locspec_owner.setValue("LOCSPEC",locspec_owner.getString("LOCSPEC") +"<br> </br>" +str(mbo.getString("ASSETATTRID")) +" : "+ VALUE  )

  commTemplateSet = MXServer.getMXServer().getMboSet("COMMTEMPLATE",MXServer.getMXServer().getSystemUserInfo())

  commTemplateSet.setWhere("templateid='TEMPLATENAME'")

  commTemplateSet.reset()

  commTemplateSet.getMbo(0).sendMessage(mbo, mbo)

Database Error 2601 BMXAA4211E during Workorder Creation

Problem:

Getting Database Error BMXAA4211E While trying to save a work order

Steps to reproduce:

1) Create a new work order.

2) Enter the required information.

3) Save the work order.

The result is that following error is displayed:

"Database error occurred when operating on Workview : Record *** Class = *** and Site = ***. Report Error to the owner of deployment."

Cause

This is happening because there may already be existing records within the database that Maximo is unaware of. This can be very old data, and it can be data that was not used. The reason this error occurs is because Maximo is trying to write to the database and that record (the primary key value) already exists.

Resolving the problem

To resolve this issue, we suggest that you proceed to archive your data, and when doing so, you should select the option to remove the data that is being archived from the current database. When this is done, you should able to store the newly created work orders.

Process to remove the error message, "Actual Dates May Not Be In The Future"

Question :

Is it possible to remove the error message, "Actual Dates May Not Be In The Future" ?

Cause:

The time zone of the database determines the timestamp for a record update. A routine is run when an update is executed to determine if the time-based fields for Labor Actual records are not in the future. In version 7.5 and greater, there is a tolerance setting for this in the Organizations application.

Answer:

In the table MAXVARS, in the VARNAME field, you can set the value to 1 where the varname is SUPPRESSACTCHECK. The result of this is that it will suppress a routine that checks for the actual date and time, so that the error message will not be presented to screen in a scenario whereby the client PC is in a time zone that is at least one hour ahead of the database which is being updated from the client.

The default setting of Maximo is to display this error message. With maxvar SUPPRESSACTCHECK set to 1 and when the database and application server are set to a time zone that is earlier than the time zone of the currently logged-in user, you should be able to enter actual start times and end times in the current Time Zone without getting that error message which actual dates being in the future.

At a database prompt you can run an update SQL query similar to:

update maxvars

set varvalue = 1 where varname = 'SUPPRESSACTCHECK';

commit;

You will have to stop and restart the Maximo server for this change to become persistent.
Please note that this configuration will not prevent the entry of future times in the current Time Zone. This is currently a known limitation of Maximo functionality.

Reference :http://www-01.ibm.com/support/docview.wss?uid=swg21391274

Reporting Actual Labor Usage Due to Timezone Difference.

Aim:  To to complete work orders if the user and server are located in different timezones

If the server/client machines are in different time zones and the labor reporting tolerance is set to not allow future date/time, then it is not possible to change the status of work orders to complete.

ENVIRONMENT: The server is in Central time and the user is in Eastern Standard time.

MAXVARS.SUPPRESSACTCHECK suppresses the check for past or future time when entering actual labor hours

MAXVARS.LABTRANSTOLERANCE allows future Labor Transaction Tolerance in Hours when reporting into the future

MAXVARS.USECLIENTTIMEZONE allows user time zone to be taken into account (as per the timezone defined in the user's default profile or users application)

STEPS:
Bring up an approved work order, go to the Actuals tab, Labor sub-tab.
Enter start time, end time, and regular hours.
Then try to complete the work order.
Get error: BMXAA4590E - Could not change Work Order 1006 status to COMP.
BMXAA4494E - Specify actual dates that are in the past.


SCENARIO 1:

With the MAXVARS.SUPPRESSACTCHECK set to 0, the user cannot complete the work order.
With MAXVARS.SUPPRESSACTCHECK set to 1 and labor tolerance set to 1 hour, the user can complete the work order. However, this workaround is not acceptable because it allows the user to enter future time.

For example, the current time on a machine is 12:45pm EST, the user can enter 1pm EST as the start time and complete the work order.

SCENARIO 2: 

With MAXVARS.SUPPRESSACTCHECK SET TO 0 and labor tolerance MAXVARS.LABTRANSTOLERANCE set to 1 hour.

If the current time on a machine is 1:07pm EST, the user receives the following message when trying to complete the work order:

BMXAA4590E - Could not change Work Order 1006 status to COMP.
BMXAA4494E - Specify actual dates that are in the past.

Server time converts the time to 12:07 pm CST and users cannot complete the work order due to the error message.

Cause

Timezone difference between server and client machine

Resolving the problem

Unable to report actual labor problem has been tracked as APAR IZ90431 and has been addressed in 7.5.0.4 fixpack and above. i.e. Users should be able to report actual labor and complete work orders.

For the fix to work properly, the following configuration settings must be in place.

Run the queries below to check the database settings:

SELECT varname ,varvalue , orgid,siteid,maxvarsid from maxvars where varname ='USECLIENTTIMEZONE';

SELECT varname ,varvalue , orgid,siteid,maxvarsid from maxvars where varname ='SUPPRESSACTCHECK';

SELECT varname ,varvalue , orgid,siteid,maxvarsid FROM MAXVARS WHERE VARNAME ='LABTRANSTOLERANCE' AND orgid='EAGLENA';

NOTE: the labor tolerance (maxvars.labtranstolerance) can be also set in the Organizations application, "Select Action", "Future Labor Transaction Tolerance in Hours", and enter 0:00 for the tolerance.

If the maxvars have not been set, run the update statements to set the varvalues:

update maxvars set varvalue =1 where varname ='USECLIENTTIMEZONE'
update maxvars set varvalue =0 where varname ='SUPPRESSACTCHECK'
update maxvars set varvalue ='0:00' where varname ='LABTRANSTOLERANCE'


output:


Restart the application server for the new maxvars settings to take effect.

To verify the fix actually addressed the problem:

For example, the current time is 5:38PM EST on a remote laptop and the server is running on CST time.

1. Log in to Maximo, set the default user profile to use US/Eastern.
2. Bring up an approved work order, go to the Actuals tab, Labor sub-tab.
3. Enter a valid labor code.
4. Enter the actual start time and the end time when the work has been completed.

You should now be able to save / complete the work order without issue.

In addition, the fix should prevent the user from entering future dates and time:

For example, if a future date is entered, you will receive the following error:

BMXAA2641E - You cannot enter actual labor with future dates and times.




If I enter a future time, the following error will be received:

BMXAA2641E - You cannot enter actual labor with future dates and times.

Reference: http://www-01.ibm.com/support/docview.wss?uid=swg21621991

Setup an escalation to be notified of a status change on a work order

Create an escalation and fill in the following fields:

Applies to :WORKORDER
Condition: STATUS='APPR' and STATUSDATE >=(sysdate -1/1440) (USE this is on Oracle DB)
Condition: STATUS='APPR' and STATUSDATE >= dateadd(mi, -1, getdate()) (USE this if on SQL Server DB)
Schedule: 1 minute

Escalation Point section:

Elapsed Time Attribute: STATUSDATE
Escalation Point condition: 1=1
Check Repeats Box


Attached a Communication Template to my Notification Section

Communication Template specifics;

Applies to : WORKORDER
Accessible From: ALL
To: Role you choose
Send From: Maximo Administrator
Subject: :WONUM has changed status 
Message: The :WONUM has been changed status to :STATUS on :STATUSDATE

****NOTE: The REPEATS needs to be checked in order for it to notify you on the same work order being changed to APPR back to WAPPR back to APPR.....

The following query STATUSDATE >=(sysdate -1/1440)

this will check when a STATUSDATE is changed within that last minute...

Sysdate means it checks the Date on the Server

-1 means it will check for any changes to the STATUSDATE within the last minute the crontask was running as the schedule is every minute

1440 is the following calculation

1440 divided by 60 Seconds ( 1minute)= 24 HOURS

24 Hours X 60 Seconds= 1440

The Crontask runs every minute...but only will send an email when a work order's STATUSDATE is changed within the last time it ran and the work order is changed to APPR.

Reference :http://www-01.ibm.com/support/docview.wss?uid=swg21319721

Decreasing the downtime when upgrading Maximo 7.5.0.8 to Maximo 7.6.0.1

With the release of Maximo Fix Pack 7.6.0.1, among other things, it offers the new feature that you will be able to reduce downtime when running updatedb.

The link below contains the steps in how to take advantage of this new feature:

http://www-01.ibm.com/support/docview.wss?uid=swg21902458

 

But if you go through the steps of the scenario described there, the first problem that you could face is that the Step 2 won't work when you are coming from a 7.5.0.8 version. This is because when you perform the upgrade from Maximo 7.5.0.8 to Maximo 7.6.0.1, the first thing that you must to do is to install Maximo 7.6, followed by Maximo 7.6.0.1 and any other IS/PMP that your previous environment had, all that in a new folder, not installing over your previous 7.5.0.8 folder.

(For more details about the supported upgrade process from Maximo 7.5 to 7.6 versions, check the guide available at this page:

http://www-01.ibm.com/support/docview.wss?rs=3224&context=SSLL2E&dc=DB520&dc=DB560&uid=swg21266217&loc=en_US&cs=UTF-8&lang=en&rss=ct3224tivoli)

Which means that your new 7.6.0.1 folder has not yet a maximo.properties file pointing to your database to be upgraded, when those installations are completed. In the standard upgrade process it will be created when you use the config tool, after such installations, setting through it the database parameters and finally performing the updatedb, the rebuild and redeploy the EAR files, all that through the config tool.

 

When running the upgrade approach from a English-only Maximo 7.5.0.8 version to 7.6.0.1 in the mode to decrease the downtime, you should follow these steps instead:

 

1-) Perform the installation of Maximo 7.6, Maximo 7.6.0.1 (and any IS/PMP) - follow the instructions available in the upgrade guide to perform these steps.

2-) Copy the maximo.properties file of your previous Maximo 7.5 folder to your new Maximo 7.6.0.1 folder. The file should be put in the same location in the 7.6.0.1 folder: <maximo_folder>\applications\maximo\properties.

3-) Now, with your folder having the maximo.properties file with the information pointing to your database to be upgraded, open a command prompt and run the updatedblitepreprocessor command, located in the <Maximo_Home>\tools\maximo\ directory of your Maximo 7.6.0.1 folder.

<Maximo_Home>\tools\maximo\updatedblitepreprocessor.[bat|sh]

4) Build the application EAR files.

WebLogic:
< Maximo_Home>\deployment\buildmaximoear.[cmd|sh]
< Maximo_Home>\deployment\buildmxiehsear.[cmd|sh]

WebSphere 8.x:
< Maximo_Home>\deployment\buildmaximoearwas8.[cmd|sh]
< Maximo_Home>\deployment\buildmxiehsear.[cmd|sh]

5) Stop the Maximo Asset Management application server.

6) Run the updatedblite command, located in the <Maximo_Home>\tools\maximo\ directory.

<Maximo_Home>\tools\maximo\updatedblite.[bat|sh]

7) Deploy the maximo.ear and maximoiehs.ear application EAR files through the WebLogic Server Administration Console or the WebSphere Application Server Administrative Console

8) Restart the Maximo Asset Management application server.

 

The second problem that you could face is for a non-english Maximo 7.5.0.8 database (and/or multi-language) , in case of following the instructions of the scenario described at this link: http://www-01.ibm.com/support/docview.wss?uid=swg21902458 

In this case, besides the step of copying the old maximo.properties file to your new folder,  you won't be able to perform the step  "7) Run the TDToolkit command.", because in that point, in the upgrade scenario of 7.5.0.8 to 7.6.0.1, the files which for tdtoolkit uses to perform his actions successfully are not there yet in your new 7.6.0.1 folder. They are only added through the config tool.

 

So, at this case, you should follow these steps:

 

1-) Perform the installation of Maximo 7.6, Maximo 7.6.0.1 (and any IS/PMP) - follow the instructions available in the upgrade guide to perform these steps.

2-) Copy the maximo.properties file of your previous Maximo 7.5 folder to your new Maximo 7.6.0.1 folder. The file should be put in the same location in the 7.6.0.1 folder: <maximo_folder>\applications\maximo\properties.

3-) Now, with your folder having the maximo.properties file with the information pointing to your database to be upgraded, open a command prompt and run the updatedblitepreprocessor command, located in the <Maximo_Home>\tools\maximo\ directory of your Maximo 7.6.0.1 folder.

<Maximo_Home>\tools\maximo\updatedblitepreprocessor.[bat|sh]

4) Build the application EAR files.

WebLogic:
< Maximo_Home>\deployment\buildmaximoear.[cmd|sh]
< Maximo_Home>\deployment\buildmxiehsear.[cmd|sh]

WebSphere 8.x:
< Maximo_Home>\deployment\buildmaximoearwas8.[cmd|sh]
< Maximo_Home>\deployment\buildmxiehsear.[cmd|sh]

5) Stop the Maximo Asset Management application server.

6) Run the updatedblite command, located in the <Maximo_Home>\tools\maximo\ directory.

<Maximo_Home>\tools\maximo\updatedblite.[bat|sh]

7) Delete the maximo.properties file of your 7.6.0.1 folder (This is necessary because you will need to run the Config Tool and in case of having the 7.5.0.8 version of the maximo.properties in the folder, the tool won't run. Don't worry, the config tool will create the file again).

8) Run the Maximo 7.6 launchpad, click in the Configure Product, "Reload the Installation Locations" and finally in the Launch the Tivoli's Process Automation Suite configuration program option.

9) Click in Configure a New Deployment.

10) Perform these steps following the same approach described in the Upgrade Guide (http://www-01.ibm.com/support/docview.wss?rs=3224&context=SSLL2E&dc=DB520&dc=DB560&uid=swg21266217&loc=en_US&cs=UTF-8&lang=en&rss=ct3224tivoli) as if you were running the standard upgrade process. The only difference is that in the last screen, "Apply Deployment Operations", you will have to uncheck the "Build the selected EAR files" checkbox (then, the other checkboxes related, "Build the application EAR file" and "Build the help EAR file" will be unchecked automatically).

11) Click in the Finish button. The maximo.properties file will be created again and all the steps related to translating Maximo will be done. The traditional updatedb will be skipped automatically because it will detect that the database was already updated previously, in our scenario, through updatedblite.

12) When completed, a message asking if you want to continue the configuration is displayed. Answer No.

13) Deploy the maximo.ear and maximoiehs.ear application EAR files through the WebLogic Server Administration Console or the WebSphere Application Server Administrative Console

14) Restart the Maximo Asset Management application server.

Reference:

https://www.ibm.com/developerworks/community/blogs/a9ba1efe-b731-4317-9724-a181d6155e3a/entry/Maximo_Upgrade_Tips_Decreasing_the_downtime_when_upgrading_Maximo_7_5_0_8_to_Maximo_7_6_0_1?lang=en