The client has WebSphere (WAS) commands so long, that they are not 100% captured when creating the WebSphere SI. The last bit falls off. This is just the bit with the cell/node info in it, so my BAI pattern is not triggered. Can you fix it in the next TKU?

Are the command line arguments fully captured in the DiscoveredProcess.args attribute in the DDD?

Usually truncated arguments are due to the host OS, most commonly in Solaris.

No, I don’t think the arguments are fully captured in the DDD.
Somebody helped us out by changing the WAS pattern a while ago so it would run an extra ps command to get the full string.
Starting from line 121, this:

      // Extract the Server, Node and Cell names from the arguments
      args := process.args;

Was changed to this:

    // Extract the Server, Node and Cell names from the arguments
      ran_cmd := discovery.runCommand(process, ‘ps -o args -p &#xpr;ocess.pid% | cat’);
      if ran_cmd then
      args := ran_cmd.result;
      else
      args := process.args;
      end if;
      log.info(‘Args are: “ r;gs%“‘);

This change took care of our problem and I would like it to be part of an official TKU because I have to apply the change over and over when installing new TKUs.

Edwin van den Berg - 24 September 2008 10:04 AM

I would like it to be part of an official TKU because I have to apply the change over and over when installing new TKUs.

You can make this process a little simpler by using an override pattern. This means you could apply the stock TKU (and updates) and your version of the pattern would automatically disable the TKU one.

To do this you need to put an override statement in your pattern overview section (link to our TPL notes)

So the overview of your pattern would look something like:

Edwin van den Berg - 24 September 2008 10:04 AM

No, I don’t think the arguments are fully captured in the DDD.
Somebody helped us out by changing the WAS pattern a while ago so it would run an extra ps command to get the full string.
....
This change took care of our problem and I would like it to be part of an official TKU because I have to apply the change over and over when installing new TKUs.

Edwin,

Just to add to what Charles was saying…

Note that you should create a copy of the pattern module, and then rename it (e.g.

)

Then add to this module the ‘import’ and ‘override’ statements as described by Charles.

My comments regarding incorporating your solution into a TKU release:
TPL provides us with ability to drive Discovery in order to obtain additional information within patterns. However, it would not really be appropriate to try and solve issues that may exist in a Discovery script by adding a workaround within a pattern, especially if this workaround ends up trying to obtain the information Discovery is meant to feed into the data model in the first place.

Your solution solves the problem in the short term and through the use of overrides feature that Charles outlined, you will not need to keep editing the pattern every time a new TKU is released. The only time your custom pattern would need to be updated is if the major version of the TKU pattern in question is incremented, i.e. if it goes from 1.x to 2.0.

With regards to solving the actual issue you seem to be experiencing, it would be greatly appreciated if you could raise a case with our Customer Support and provide them with the information as to which platform you have experienced this issue on.
This will enable our Engineering team to investigate the issue properly and solve it in the future releases of the product.

Regards,

Nik.