General iDash Installation Questions

Products

• iDash Workload Automation

Issue/Introduction

Q1:  When installing iDash in HA with two app servers, can the $IDASH_HOME/log/sla directory be located on a shared drive that both servers can write to? The idea is to remove the need to manually copy of files in the event one of the servers goes down.

Q2:  For Autosys, the DB user requires write access to the ujo_alarm table. Does the CA7 user require write access at all?

Q3:  We have installed JFM and are seeing CPU spikes - Is there an expectation that JFM for use with iDash will cause a significant CPU increase? Are there any tuning parameters that they can look at to help mitigate this?

Resolution

A1:  No, the two iDash servers will be predicting separately, and their logs should be kept separate. If they begin to diverge in their predictions, Support would want to look at those logs to find out why.

A2:  The CA 7 SLAs send a WTO request to the CA 7 Server for iDash task since CA 7 doesn’t have the same type of alarm set up Autosys has.  In a mixed environment, with both Autosys and CA 7 SLAs, the actions remain the same.  CA 7 SLAs will never attempt to write an alarm to the Autosys tables.

A3:  JFM is the older program, and definitely uses more CPU for iDash. CA 7 Server for iDash is newer and far more optimized. You should be using that.  Even with that, there is an initial spike in CPU when they first connect iDash to the CA 7 instance, as the task creates the seed data file with job definitions.  JFM is a prerequisite for configuring CA 7 to iDash. Here are the instructions to Implement CA7 with iDash.  CPU will spike any time the event subscription enters recovery.  If the customer sees a seed file on their iDash server, and the subscription is not in recovery, CPU usage should be pretty small.  If you're having concerns about that, we’ll need to involve the CA 7 team to investigate.