Unnecessary validate conflict prompt during deployment.

book

Article ID: 18246

calendar_today

Updated On:

Products

CA Compress Data Compression for MVS CA Compress Data Compression for Fujitsu CA Datacom - DB CA Datacom CA Datacom - AD CA Datacom - Server CA Mainframe Software Manager (Chorus Software Manager) CA MICS Resource Management CA CIS CA Common Services for z/OS CA 90s Services CA Database Management Solutions for DB2 for z/OS CA Common Product Services Component CA Common Services CA ecoMeter Server Component FOC CA Easytrieve Report Generator for Common Services CA Infocai Maintenance CA IPC Unicenter CA-JCLCheck Common Component CA Mainframe VM Product Manager CA Chorus Software Manager CA On Demand Portal CA Service Desk Manager - Unified Self Service CA PAM Client for Linux for zSeries CA Mainframe Connector for Linux on System z CA Graphical Management Interface CA Web Administrator for Top Secret CA CA- Xpertware CA Datacom/AD

Issue/Introduction

Description:

The first time you perform a deployment to an LPAR it goes successfully without getting a validate conflict prompt for dataset names. Performing a second deployment for the same product, using the same methodology to a different LPAR that is not sharing DASD with the first LPAR results in a validate conflict prompt for the datasets name.

Is this okay, why should it prompt for a possible overlay when the second deployment is to a different LPAR that doesn't share DASD with the first LPAR?

Solution:

The deployment will always prompt in this situation whether the LPARs are sharing DASD or not. This is just to get the user to acknowledge that there is a potential for a overlay even if the LPARs are not sharing DASD. In fact, CSM doesn't check to see whether they are sharing DASD or not.

Environment

Release: MSMNGR00200-5.1-Chorus Software Manager
Component: