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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
See this idea on ideas.ibm.com
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
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 |
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.
perhaps as an interim solution, enhance the user-defined atttribute field from 10 characters to 100 characters?
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?
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.
Yes, user defined attributes also need to be saved and restored.
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?
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.
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.
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
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.