Moving DCI Controller on a different LPAR
search cancel

Moving DCI Controller on a different LPAR

book

Article ID: 200383

calendar_today

Updated On:

Products

Dynamic Capacity Intelligence

Issue/Introduction

Currently running Dynamic Capacity Intelligence (DCI) 2.0 Controller on a test LPAR in simulation mode.

Planning to move the Controller to a production LPAR soon (still in simulation). No changes on the Agents side (no new Agent or LPAR).

All the references to the hostname/port will be changed.

As the source and target partitions do not share any DASDs, the following datasets will be moved from the test LPAR to the production one:

hlq.V2R0M0.CFHRDATA  
hlq.V2R0M0.CFHREXEC  
hlq.V2R0M0.CFHRLMD0  
hlq.V2R0M0.CFHRLOAD  
hlq.V2R0M0.CFHRMSG0  
hlq.V2R0M0.CFHRPNL0  
hlq.V2R0M0.CFHRSAMP  
hlq.V2R0M0.CFHRSKL0  
hlq.V2R0M0.CFHRTBL0  
hlq.V2R0M0.MSUDB     
hlq.V2R0M0.TEST.TSTDB     
hlq.V2R0M0.TEST.ZFS


Any possible problem?

Environment

Release : 2.0

Component : CA DYNAMIC CAPACITY INTELLIGENCE

Resolution

As you are moving the Controller only, without any change on Agents and Policies configuration (no LPAR or Agent added or removed), the process is correct, but you should take an additional backup of the DCI USS directory, just to be sure that it can be easily recreated.


Here is a list of additional actions that you should accomplish:

  • APF authorize the CFHRLOAD library on all the LPARs where Controller and Agents run
  • Mount the DCI zFS file on the target LPAR and modify the USSPATH parameter of DCI Controller accordingly
  • Update the ISPF REXX
  • Modify the Web server to use the new USS directories
  • Update the IPPORT and IPSTACK parameters on the Controller JCL
  • Update the IPPORT and IPADDR parameters on the Agents JCL