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.
This RFE is one of a small group which had apparently been set aside incorrectly years ago and subsequently overlooked. We are sorry for the delay.
We understand the request, and we already had it on our long-term requirement list, but it is very difficult to implement in a useful way, for reasons including the following:
1. At present DSECT has no operands, so any text in the operand field is taken as comments. If it was modified to support operands, this would be incompatible. Even if this was enabled by an option, it would not be compatible with existing system macros and similar that contain DSECT statements. Similar considerations apply to CSECT and LOCTR statements; it would for example have been very useful to be able to specify alignment requirements on all of those statements, but for compatibility reasons that will require some new mechanism.
2. The length of any external section, including an external DSECT (that is, defined with DXD or referenced in a Q-type address constant) is not even determined until link-edit time, where it is the largest of the merged definitions. If the GOFF option is used, a J-type address constant can be used to obtain the length.
3. Any section length can never be resolved until after the first assembler pass (including macro processing) is complete, because it would always be possible to resume it later (unless some new statement is defined that marks a section or location counter as ended, so it cannot be resumed).
4. Symbol lengths are currently represented internally in a 2-byte field, with a maximum value of 65535. This could be changed, but requires major internal changes.
There are also ambiguities about the possible meaning. For example, if a DSECT contains LOCTR sections, the name of the DSECT is also the name of the first LOCTR section. In that case, it is not clear whether the length associated with that name should be the length of the DSECT as a whole or just the length of the first LOCTR section.
The only reasonably compatible suggestion that has been made for implementation of an equivalent function is that the assembler should support a J-type address constant for an internal DSECT, which would be resolved by the assembler rather than by the linkage editor. However, given that the length can be obtained very easily by other means, we do not consider that implementing such a solution would be a good use of our resources at present.
If we find a compatible way to specify section attributes as part of a future enhancement, then we will also take this length requirement into account at the same time.
Jonathan Scott, HLASM
This comment is being added in the hopes that someone at IBM will see it and change the status from simply "Submitted" to something else that indicates it has been considered at all...
See the following for a discussion about this requirement:
https://groups.google.com/forum/#!topic/mainframe-assembler/W3oDT_txPWo
This is originally from a discussion topic "length of DSECT" dated August 6, 2012 on the IBM-MAIN listserv.