WebSphere arguments too long to capture

       
 
Sep 23, 2008 03:26pm
Avatar
Edwin van den Berg
Newbie
Total Posts: 25

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?

     
Sep 23, 2008 03:30pm
Avatar
Charles Oldham
Administrator
Total Posts: 107

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.

     
Sep 24, 2008 10:04am
Avatar
Edwin van den Berg
Newbie
Total Posts: 25

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.

     
Sep 30, 2008 12:50pm
Avatar
Charles Oldham
Administrator
Total Posts: 107
Edwin van den Berg - Sep 24, 2008 10:04am

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:

tpl 1.0 module ForumExample.WebsphereApplicationServerExtended;


// We need to import the ApplicationServer so we can override it
from IBM.WebSphereApplicationServer import ApplicationServer 1.1;

// We the extended pattern for the application server
pattern ApplicationServerExtended 1.0
'''
        Pattern for WebSphere Application Server.

         This pattern overrides the standard TKU one to run an additional PS command
         to capture arguments where this fails.
'''

  overview
    tags ForumExample, Override;
    // Override the TKU ApplicationServer
    overrides ApplicationServer;
  end overview;
  
  ...
  
end pattern;

     
Oct 01, 2008 04:57pm
No Avatar
Nikola Vukovljak
Newbie
Total Posts: 3
Edwin van den Berg - Sep 24, 2008 10:04am

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.

tpl 1.0 module Custom_IBM.WebSphereApplicationServer

)

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.