Skip to Main Content
IBM Power Ideas Portal

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:

Post your ideas

Start by posting ideas and requests to this portal to enhance a Power product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas and add comments to ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The Power teams will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.


Specific link you will want to bookmark for future use

IBM Unified Ideas Portal - https://ideas.ibm.com/ - Use this site to create or search for existing Ideas across all IBM products that are outside of Power, and track all of your personal interactions with all Ideas.

Status Under review
Workspace AIX
Created by Guest
Created on Jun 15, 2022

Harmonize procedure of managing configfiles during update of filesets

From an old case we noticed, that procedure how config files are treated during update is fileset-specific. Procedure should be same for each and every config file and it should be easy to check what was done with the config file. It should cover three possible cases, e.g. copying it to /lpp/save.config like:

  1. Old config file was not changed and replaced by new file

  • <name>.save

  1. Old config file was changed and content was merged with new file

  • <name>.save +

  • <name>.merge (content of new file from fileset)

  1. Old config file was changed, but overwritten with new file without merge

  • <name>.save +

  • < name>.overwritten

Such a clear convention would make it easy to identify candidates which could cause problems after update.

In addition:

  • Deleted config files should not be restored during update (e.g. /etc/hosts.equiv)

Idea priority Medium