IBM Support

More Musings About mxe.crontask.donotrun and mxe.crontask.dorun

Technical Blog Post


Abstract

More Musings About mxe.crontask.donotrun and mxe.crontask.dorun

Body

Hiya,

A recent PMR made me do a bit of thinking and I wish to share my musings.

 

System Properties mxe.crontask.donotrun and mxe.crontask.dorun

The use of System Properties mxe.crontask.donotrun and mxe.crontask.dorun (for Maximo 7.6 only) to isolate functionality across several JVMs is documented in a number of blogs, technotes and the Knowledge Centre (Wink), so I won't go into massive detail.
Suffice to say that these poperties are a comma-separated list of cron tasks that we do not want to run (or do want to run) on a specific JVM.

 

The Challenges

This can involve a lot of fiddly tpyping which we are all capable of getting rwong.

At Maximo 7.5 and below, we just had mxe.crontask.donotrun
One of the many goodies delivered at Maximo 7.6 is the inverse: mxe.crontask.dorun. This list is potentially a lot shorter, so less scope for erro.

These lists have to fit into a finite space somewhere in the depths of the Maximo database and it is possible to run out of room.
Consider a list of escalations: ESCALATION.<some name that makes sense> , ESCALATION.<some other name that makes sense> That list could grow very large very quickly.
We give hints about how to fix this, but, to my mind at least, not enough detail.

 

How big can these properties be and how do we make them bigger?

How big is easy: They are stored in the PROPVALUE attribute of the MAXPROPVALUE object in the database which is ALN 512

If you are using instance properties (as is quite likely), we need to be looking at PROPVALUE in MAXPROPINSTANCE, which is the same size.
At first glance, that seems quite big, but every document that I could find lists <taskname>.<instance>, so those 512 bytes can get chewed up surprisingly quickly.

How do make them bigger?

Use Database Configuration, of course.

Object: MAXPROPVALUE

Attribute: PROPVALUE

(This will also change PROPVALUE in MAXPROPINSTANCE because they are all defined to be Same as MAXPROP.MAXIMODEFAULT)

How big can we make them?

DB2: 32672 characters (*)
Oracle: 4000 characters
SQL Server: 8000 characters

The above is rather academic because 4000 characters would be a whole world of pain to try to manage. 512 is bad enough.

* Before anyone tries 32672 for DB2, a word to the wise: DON'T. It will end in tears because you will hit the maximum row size when this is somewhere between 15,0000 and 20,000. At this point, life gets interesting. As in "refer to technote" or "open a PMR". I know because I tried.
My tests showed that 4000 is achievable for Oracle
Having burnt my fingers with breaking Maximo with a massive DB2 row size, I have not been brave enough to try with SQL Server.

How do we manage a long list?

The answer is not Blowin' in the Wind

The answer is actually very simple. If we look at the description of mxe.crontask.donotrun in System Properties, we find  "Cron tasks that should not be run (comma-delimited)". Note this says "Cron tasks" NOT "Cron task instances"
Unless you are actually trying to restrict which instance of a cron task runs (or does not run) where, just specify the cron task name.
That long list of escalations now becomes the single word: ESCALATION.
Leaving off the instance name means our troubles are now far away because we are not going to bump into the limit, we don't have to worry about typing (unless you can't spell ESCALTION properly) and the list is now self-maintaining. 3 birds with one stone.

NB: This applies to all cron tasks

And now to finish on a song...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[{"Business Unit":{"code":"BU005","label":"IoT"}, "Product":{"code":"SSLKT6","label":"Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":""}]

UID

ibm11113027