IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. 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 IBM i
Categories Core OS
Created by Guest
Created on Feb 8, 2017

RELATED IDEAS

Add more user defined attributes/object information to an object

At the moment the user can only add one additional information to an object, f. e. via the system API QLICOBJD. But as different applications/tools need to add their own information to the object the previously set information will be overridden.

The user should have the ability to add more than one additional data to an object via API and should be able to query this additional information.

The new API should contain the following features:
- set additional information on the object: key, value
- retrieve information by key from the object
- get a list of keys of the object
- delete additional information from the object by key

Key / value examples could be:
Git commit id: GIT:1844f76071f54c741c7a556fdabd2a98845b7c7c
Hudsion build id: Hudson:256
Unit test tag: UnitTest:ILEUnit


Use Case:

For example a build server may add the source code version to the object and a build version. This would ensoure that the installed object is really from a specific build and has a specific source code version. This would make it possible to implement a more mainstream like approach to build applications for IBM i using ILE languages.

And if the object is a unit test (see RPGUnit or ILEUnit) it should also be tagged as such so that the frontend (like RPG Next Gen Editor or MiWorkplace or RDi with the iSphere plugins) can react on that information and present the user an action to run a unit test.


Idea priority High
  • Guest
    Reply
    |     Aug 24, 2022

    perhaps as an interim solution, enhance the user-defined atttribute field from 10 characters to 100 characters?

  • Guest
    Reply
    |     May 21, 2021

    i propose to spread this interesting RFE into public discussion to check out public interest, then we can discuss with IBM possible efforts on system development...
    any comments?

  • Guest
    Reply
    |     Dec 2, 2020

    Thank you for submitting your request. While we agree this would be a nice feature, it did not make it into our current development plan.

  • Guest
    Reply
    |     Apr 28, 2020

    Yes, user defined attributes also need to be saved and restored.

  • Guest
    Reply
    |     Apr 27, 2020

    Thank you for the information.

    Most object attributes are saved with SAVLIB/SAVOBJ and restored with RSTLIB/RSTOBJ.
    Did you want the user defined attributes to be saved and restored?

  • Guest
    Reply
    |     Apr 25, 2020

    Each user defined attribute should consist of a key, a value and the length of the value. The key can be of fixed length. That should work.

    Setting and querying the value(s) via API would be enough. Commands can be self made as needed.

    Using "object control level attribute" and "build identifier attribute" ... I don't think that this will suffice. When multiple software packages are used for a single object then multiple entries need to be supported. 2 or 3 entries are not enough. Especially when we have to save the key with the value in those small storages because you will want to know what those values mean. So storing the value alone is no good.

  • Guest
    Reply
    |     Apr 15, 2020

    We have a couple of questions about the change that you requested.

    For each user-defined attribute, you want to be able to define:
    the name of the attribute, length of the data and the attribute data.
    Is that correct?

    Do you want the object attributes to be changed and retrieved only thru APIs?
    How did you want to be able to query the information?

    Our object attributes are currently returned on the following object interfaces:
    Display Object Description (DSPOBJD) cmd (display/print/outfile)
    RTVOBJD (Retrieve Object Description) cmd
    QUSLOBJ (List Objects in Library(ies) API
    QUSROBJD (Retrieve Object Description) API
    QGYOLOBJ (Open List of Objects) API

    These are returning a defined list of attributes and each attribute is a fixed-length. These APIs would probably not be able to return the user defined attributes.

    For the example you described in your "use case":
    We have an 8-byte object control level attribute which you could use for a source code version.

    There is a 16-byte build identifier attribute which you could use for a build version. The build identifier can currently be retrieved
    only with the Open List of Objects (QGYOLOBJ) API. We are adding the object attribute to additional interfaces in the future.

    Both the object control level attribute and the build identifier attribute can be changed with the Change Object Description (QLICOBJD) API. The attributes are fixed-length.

  • Guest
    Reply
    |     Jul 18, 2017

    The CAAC has reviewed this requirement and recommends that IBM view this as a medium priority requirement that should be addressed.

    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.

    For more information about CAAC, see www.common.org/caac

    For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/

    Dawn May - CAAC Program Manager

  • Guest
    Reply
    |     Feb 9, 2017

    This is something many of us have talked about in regard to supporting more effective object change management in this era of modern tooling coming to the IBM i platform in #IBMiOSS.

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.