ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

Unnecessary validate conflict prompt during deployment.

book

Article ID: 18246

calendar_today

Updated On:

Products

Compress Data Compression for MVS Compress Data Compression for Fujitsu Datacom DATACOM - AD Mainframe Software Manager (Chorus Software Manager) MICS Resource Management CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services CA ecoMeter Server Component FOC EASYTRIEVE REPORT GENERATOR FOR COMMON SERVICES INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA On Demand Portal CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware 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: