This portal is to open public enhancement requests against the products and services belonging to IBM Sustainability Software. 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
We want to be able to use variables in dataset- and language definitions and in translators. At SVB we do have several systems build in COBOL and other languages, they all have one character to identify everything belonging to that system. F.i. system Elderly Pensions (AOW) has the character H.
All required datasets do have this character in the name-part. F.i. COBOL-sources will be stored in xCOBB. The HLQ comes from the build-engine. This also sets the variable $system. In my translators, all systemdependent datasets have this variable in the definition, so a datasetdefinition $systemCOBB will exist. During execution of the AOW-build-engine $system will be substituted by H, so the datasetname will become HCOBB. With the HLQ, for the O-environment the dataset RTC01.O.HCOBB will be used.
When I use the same translator for the system crosstest, which has the character X, the X-test-build-engine will substitute to RTC01.O.XCOBB.
I don't have to define the whole set of translators and dataset-definitions for each system. Only by using a variable I can reuse translators and dataset-definitions. Maintanance will be easier.
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.
There are four types of data sets in Enterprise extensions and three of them can not support properties:
4 - Temporary data sets - If property support was added to temp data sets it would invalidate keep logic.
3 - Existing data sets - It might be possible to support properties for existing data sets, but that would not satisfy the requirements and leave us with a one off solution that is difficult to maintain.
2 - Build output data sets - Build output data sets have an existing check to make sure that properties are not injected into the data set definition. This is in part to support Packaging and Promotion manifest generation and usage.
1 - zFolder data sets - zFolder data sets are processed by the FileManager and the FileManager is not limited to running in an Ant environment, and therefore, has no support for properties or property resolution.
Therefore it has been decided to decline this request.
There already exists the feature that allows for dataset build properties - a property that contains the UUID of a dataset definition and represents that data set within the build in which it is defined, which might partially satisfy the requirement.
We are implementing property support for data set definitions in 7.0.3 which I believe satisfies this requirement. You would create a data set definition with an imbedded build property, then furnish the value of that property in the build.
this RFE may be closed, we do have an other solution by setting the HLQ in the build-definition and use standard names for various types, so the datasetname for O will be RTC01.O.H.COBB and for X it is RTC01.X.H.COBB, RTC01.*.H is the HLQ set in the build-def.
After reviewing this RFE we are rejecting this as we do not expect to deliver in releases within the next 18-24 months. If the RFE remains important to you please resubmit after this time.
Hi Team,
We want to be flexible on input- as well as on output-datasets. Reason is that we do have several COBOL-systems which are separated. Input is separated, output as well. Only the loadlibs are common, so we do keep control on what get's to be run in every level.
Could you clarify if your request is just for sources (inputs) or also for binaries produced by the build (outputs) ?
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Internet of Things
Product family - Software and Systems engineering / ALM (CLM & CE)
Product - Rational Team Concert (RTC)
Component - Build
Operating system - IBM z/OS
Source - None
For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - Developer for System z
Component - Other/Unknown
Operating system - Multiple
Source - None