IBM Z Hardware and Operating Systems Ideas Portal


This is the public portal for all IBM Z Hardware and Operating System related offerings. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Future consideration
Workspace z/OS
Categories DFSMS DSS
Created by Guest
Created on Jan 17, 2019

RELATED IDEAS

SMS Allocation rules prevents data set copies from restored volume backups

We perform full volume backups and restores from an MVS system. When the original SMS managed volume and the restored volume (using a different VOLSER) label are brought online to the same system where the original volumes data sets are also cataloged, we are unable to copy data residing in same name PDS/E data sets from the restored volume to the original volume. SMS allocation routines do not allow the copy to occur because the data set is cataloged on the original volume but we are trying to copy data from the restored volume using the same data set name. SMS complains that there is a cataloged volume mis-match.

Would like this restriction relaxed, possibly through an additional RACF profile?

Idea priority Medium
  • Guest
    Reply
    |     Dec 15, 2023

    You have some other possible approaches to this. This all assumes you're using the DFSMSdss utility. One is to do Logical DUMP's with NEWNAMEU so the datasets on the backup are different to the original names. This is a bit more hassle because it uses the UIM so requires additional RACF set up. But the restored names would be different to the originals so no catalog conflict, and you can COPY data from the restored newnamed datasets to your originals either with DSS or other utilities. Depending on your SMS ACS set up these could be restored to the same or a separate STORGRP.

    Or you can do logical RESTORE's of the original named datasets from your backups with RENAMEU to rename them to another unique name.

    With either approach you also have the option to do the RESTORE's with REPLACEU to overlay the entire target datasets if you wanted to as long as you also specify RENAMEU to match the source and target names correctly. If you only want to do this for selected datasets you have to be careful to specify those names in the DS(INC( - ) or the DS(FDD(-)) with a FILTERDD specifying the names. Using BY(DSORG EQ (PDS,PDSE)) ensures only PDS's are restored. Otherwise any unmatched names will be restored to the names they have on the backup.
    Beware target datasets cannot be in use when doing this.

    If you RESTORE the datasets to the new names so they're unique, you then have the option to COPY source to target with REPLACEU as well, with the same restrictions as for RESTORE above. Or you can copy individual datasets using other utilities such as IEBCOPY.



  • Guest
    Reply
    |     Apr 19, 2022

    You're trying to break fundamental rules of Z/OS with this. Without an OEM product to 'condition' your restored volumes (e.g. Mainstar/Rocket VCR, or Catalog Recovery Plus) to rename the volumes and datasets after the restore this could never work if being restored to the same sysplex as the original volumes.

    You cannot have duplicate named datasets if they're SMS managed as the catalog structure doesn't allow for it, even if using multi level Usercatalog aliases.

    If your restored new named SMS format volume names are not included as definitions in an SMS Storgrp (even as DISNEW) then datasets on them are not accessible.

    You really need to move away from physical to logical volume or dataset DUMP's, then you can do RESTORE's with RENAMEU of your PDS/PDSE's to new names. Where they get restored depends on their new names and how the ACS routines in your SMS configuration are set up.

  • Guest
    Reply
    |     Apr 15, 2019

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - z Systems Software
    Product - z/OS
    Component - DFSMS DSS
    Operating system - IBM z/OS
    Source - None

    For recording keeping, the previous attributes were:
    Brand - Servers and Systems Software
    Product family - z Systems Software
    Product - z/OS
    Component - DFSMS General/Unknown
    Operating system - IBM z/OS
    Source - None

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.