This is the public portal for all IBM Z Hardware and Operating System related offerings. 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.
The intent of this idea is to make DFSORT easier to code. When I Browse or View a dataset I use the COLS command to get the start position of each field. The values shown are without the 4 bytes for the RDW. The first character shows as position 1 not 5.
By specifying VLRDW=YES then the user can treat the record as if it was fixed length. It would force options VLSCMP,VLSHRT. The sort messages to SYSOUT/DFSMSG would show the same values as coded in the SYSIN ie. without the +4 bytes for RDW.
This assumes the user does not want to change the length of a record. When SORT outputs the record it would keep the RDW that was on the input.
As a final note I have at times resorted to doing a copy/convert of a dataset from variable to fixed length and then running an ICETOOL/SORT against the fixed file. More CPU & IO cost but easier to code.
INCLUDE/OMIT
SORT FIELDS
MERGE FIELDS
INREC
OUTREC
E15/E33/E35/E61 EXITS
OUTFIL
If DFSORT is to internally modify the fields, how does the application programmer know if he got the right results?. The sysout shows a different positions for sorting and the actual sort is done on fields by adding the RDW which is different. Auditing such jobs would be difficult. The same goes for all other statements. We cannot change the control cards dynamically and print them out in sysout.
The usage of symbols would resolve this issue. DFSORT symbols provide you a mechanism where you do not have to type in the position of the field and it automatically calculates the offset of the position based on the length of fields. Please let us know if you are interested about this approach.
keeping in mind the above criteria this idea is unlikely to be given high enough priority to be placed into the product plan. So I respectfully have to decline this Idea.