IBM Z Software
This portal is to open public enhancement requests against IBM Z Software 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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
An addition needed to make this work would be to include the activation date in the configurable inputs for "input files".
And I also concluded that we would still need the possibility to manipulate the values after they are parsed from the date variable. e.g. increment <fay/2> by '+4'
The mentioned "
<fad>,<fam>and<fay>for FirstActiveDay, Month and Year" would solve this complication. Would love to see something like this in the future!EKMF supports various date related label placeholders whose function is to add elements of a date (day of month, month, year) to a key label.
This operation means that the label is calculated based on date input, whereas the idea described has the reverse approach in that the date is calculated based on the label. The end goal may however be the same in that a key record is produced with a match between values of the label and the associated key dates.
The current label placeholders for dates that EKMF supports are:
<dd>,<mm>,<yy>,<yyyy>which can be used to include in the key label elements of the date that this key was registered or created in EKMF<lam>,<lay>which will add values for last active month or last active year of a key, so these are based on the expiration date.If there is a requirement to base the label specifically of the activation date, we could extend this list with new placeholders. For example
<fad>,<fam>and<fay>for FirstActiveDay, Month and Year. This could be relevant if your activation dates are different from the EKMF key record creation date and this must be reflected in the label. If the activation dates align with the key record creation date, then the existing placeholders would give the same result.If we imagine the new placeholders being added to EKMF, a key label pattern could be defined as
AES256.DECRYPT.<fay><fam><fad>which in combination with the activation date should produce the expected key label.For the deactivation date, the key templates support setting it to a relative value of the activation date for automated handling.
For import, the use of input formats that include the activation date value will ensure the correct date is automatically set during key import as well, resulting in the automatic calculation of the expected key label and deactivation date.
If there's an aspect of your use case that currently cannot be implemented using the existing functions to handle activation dates and key labels, we would gladly take a look when we understand the details.