IBM System Storage Ideas Portal


This portal is to open public enhancement requests against IBM System Storage products. 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 Not under consideration
Workspace Storage Protect Family
Categories Spectrum Protect (Server)
Created by Guest
Created on Jun 14, 2012

RELATED IDEAS

Using TSM Server in a Library Manager role

This RFE is opened to request a design change for the TSM Server acting in a role of the dedicated library manager (LM) for either physical and/or logical tape library or libraries.
.
In a large environment consisting of multiple physical and/or virtual SCSI tape libraries it is typically desired to separate the LM and Library Client (LC) functionalities to allow multiple TSM Servers & Storage Agent to access a pool of the shared tape resources and have a single point of control for the said resources.
.
Current design requires that the TSM Server performing a role of the LM has R/W access to each tape drive in the environment. This requirement results in the hundreds of tape logical devices configured on the LPAR where LM is running. The number of these devices increase dramatically when multiple paths, VTLs and other conditions exists (eg multiple sites, clustering). This not only brings the overall number of tape logical devices close tp 1024 ATAPE limit, but also makes device discovery & configuration tasks in AIX very time consuming.
.
Please consider changing the TSM Server LM design to not require RW access to the tape drives by the LM. LM would need to have access to the library control device only while LC systems will be responsible for checking/writing labels and communicating with the LM to update inventory. LM would still be managing scratch pool.

Idea priority Medium
  • Guest
    Reply
    |     Jun 12, 2015

    Due to processing by IBM, this request was reassigned to have the following updated attributes:
    Brand - Servers and Systems Software
    Product family - Storage
    Product - Tivoli Storage Manager (TSM) Family

    For recording keeping, the previous attributes were:
    Brand - Tivoli
    Product family - Storage
    Product - Tivoli Storage Manager (TSM) Family

  • Guest
    Reply
    |     Sep 5, 2012

    Thank you for submitting a RFE request on TSM. Here are the comments from our development team on this particular request:

    ====
    I guess this could be done, I wouldn't recommend it.  It should also be noted that if this were implemented and allowed, the customer wouldn't be able to LABEL any new volumes, as the LM wouldn't have access to the drives and LC don't have that capability (nor could the LM do the AUDIT LIBRARY, CHECKIN/CHECKOUT LIBVOL commands with CHECKLABEL=YES).

    That said, I don't think the justification below for this change is valid.  The main complaint here is the number of tape devices hitting the Atape limit of 1024.  However, the LM would only ever use the number associated with the actual drives in the library.  So, if the library has X drives (less than 1024), there would only be X paths that are actually used by the LM.  All other path definitions are only there to store information for the each LC, and don't have actual device special files on the local LM host.  The description below, I believe, is trying to imply that the LM would need X * (Y+1) devices on the host (where Y is the number of LC/STAs the LM services, note the "+1" is for the LM itself).  There would X * (Y+1) paths defined on the LM as rows in the TSM database, but only X paths would ever be used and defined locally in the host device special files. 

    Furthermore, the request makes reference to the overall maintenance of the number of paths....  But implementing this change would only reduce the number of paths from X * (Y+1) to X * Y which won't be significant to the overall number of paths...  So, I think you get very little bang for your buck with the change, especially given the PERFORM LIBACTION enhancement that helps with drive and drive path definitions for VTL and large drive environments in 6.3.0 and above.

    Thanks,

    Kai A.
    TSM Server Development

  • Guest
    Reply
    |     Sep 5, 2012

    Thank you for submitting a RFE request on TSM. Here are the comments from our development team on this particular request:

    ====
    I guess this could be done, I wouldn't recommend it.  It should also be noted that if this were implemented and allowed, the customer wouldn't be able to LABEL any new volumes, as the LM wouldn't have access to the drives and LC don't have that capability (nor could the LM do the AUDIT LIBRARY, CHECKIN/CHECKOUT LIBVOL commands with CHECKLABEL=YES).

    That said, I don't think the justification below for this change is valid.  The main complaint here is the number of tape devices hitting the Atape limit of 1024.  However, the LM would only ever use the number associated with the actual drives in the library.  So, if the library has X drives (less than 1024), there would only be X paths that are actually used by the LM.  All other path definitions are only there to store information for the each LC, and don't have actual device special files on the local LM host.  The description below, I believe, is trying to imply that the LM would need X * (Y+1) devices on the host (where Y is the number of LC/STAs the LM services, note the "+1" is for the LM itself).  There would X * (Y+1) paths defined on the LM as rows in the TSM database, but only X paths would ever be used and defined locally in the host device special files. 

    Furthermore, the request makes reference to the overall maintenance of the number of paths....  But implementing this change would only reduce the number of paths from X * (Y+1) to X * Y which won't be significant to the overall number of paths...  So, I think you get very little bang for your buck with the change, especially given the PERFORM LIBACTION enhancement that helps with drive and drive path definitions for VTL and large drive environments in 6.3.0 and above.

    Thanks,

    Kai A.
    TSM Server Development

  • Guest
    Reply
    |     Sep 5, 2012

    Thank you for submitting a RFE request on TSM. Here are the comments from our development team on this particular request:

    ====
    I guess this could be done, I wouldn't recommend it.  It should also be noted that if this were implemented and allowed, the customer wouldn't be able to LABEL any new volumes, as the LM wouldn't have access to the drives and LC don't have that capability (nor could the LM do the AUDIT LIBRARY, CHECKIN/CHECKOUT LIBVOL commands with CHECKLABEL=YES).

    That said, I don't think the justification below for this change is valid.  The main complaint here is the number of tape devices hitting the Atape limit of 1024.  However, the LM would only ever use the number associated with the actual drives in the library.  So, if the library has X drives (less than 1024), there would only be X paths that are actually used by the LM.  All other path definitions are only there to store information for the each LC, and don't have actual device special files on the local LM host.  The description below, I believe, is trying to imply that the LM would need X * (Y+1) devices on the host (where Y is the number of LC/STAs the LM services, note the "+1" is for the LM itself).  There would X * (Y+1) paths defined on the LM as rows in the TSM database, but only X paths would ever be used and defined locally in the host device special files. 

    Furthermore, the request makes reference to the overall maintenance of the number of paths....  But implementing this change would only reduce the number of paths from X * (Y+1) to X * Y which won't be significant to the overall number of paths...  So, I think you get very little bang for your buck with the change, especially given the PERFORM LIBACTION enhancement that helps with drive and drive path definitions for VTL and large drive environments in 6.3.0 and above.

    Thanks,

    Kai A.
    TSM Server Development

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.