Skip to Main Content
Cloud Management and AIOps


This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps 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.

Status Not under consideration
Created by Guest
Created on Feb 27, 2023

twsinst efficiency improvements

Ref: TS011706916

We've noted when upgrading from 9.4 to 9.5, and also when applying fixpacks to 9.5, that twsinst is performing "copy" operations on all the files in the stdlist directory instead of "move" operations. This has led to two issues during our upgrade/patch cycles:

First, by copying, additional storage is required. The process twsinst appears to follow is to:

  1. Rename (or "move") the stdlist directory to a temporary name.

  2. Recreate the stdlist directory.

  3. Copy the contents from the original (now temporary) directory structure back to the newly created stdlist directory.

  4. Remove the temporary directory.

This leads to a requirement for double the size of the stdlist directory during the upgrade/patch activity. Unfortunately, twsinst does not perform a sufficiently robust check to verify it has enough storage for this, and has caused us to lose log files as a result.

The second side issue is that the "copy" operations take significantly more time than a "move" would. For systems running a small number of batches this is an insignificant improvement, but we have systems that run 20k batches per day and we're keeping 45 days of log history on the server, which creates a significant delay in the patching activity.

As all of this is being done as "root", as required by twsinst operations, there is no benefit to having this being done as a copy. It should be changed to operate as a "move" instead.


Idea priority High
  • Guest
    Reply
    |
    Dec 6, 2023

    If this is not to be implemented as requested, then you MUST update the storage checks performed by twsinst to correctly calculate the required space for this rename/copy operation. As as this can lead to not only physical space constraints but also the number of inodes available on the file system, that check needs to be comprehensive.

    I would argue that the "safety" you tout is not there currently, due to the insufficient space checks. Also, you have no trouble using "move" to rename the stdlist directory in the first place, so the logic isn't fully consistent.

  • Admin
    Marco Cardelli
    Reply
    |
    Dec 6, 2023

    Hello there, we believe that it is safer although more expensive to use a "copy" rather than a "move" in this installation procedure. So we cannot accept this requirement.