Your Output shows the contents from position 10. is your Input a VB file? or FB file?
As Bill points out it is an elementary task.
If you're not familiar with DFSORT and DFSORT's ICETOOL, I'd suggest reading through "z/OS DFSORT: Getting Started". It's an excellent tutorial, with lots of examples, that will show you how to use DFSORT, DFSORT's ICETOOL and DFSORT Symbols. You can access it online, along with all of the other DFSORT books, from:
ICE250I 0 VISIT http://www.ibm.com/storage/dfsort FOR DFSORT PAPERS, EXAMPLES A
ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R12 - 06:47 ON THU A
ICE043A 3 INVALID DATA SET ATTRIBUTES: SORTOUT RECFM - REASON CODE IS 08
ICE150I 0 VLSHRT NOT USED FOR SORT, MERGE, INCLUDE, OMIT OR SUM STATEMENT FIELD
Joined: 09 Mar 2011 Posts: 7312 Location: Inside the Matrix
The less data which goes into the actual SORT, the better. Unless dependent on the sorted order (like the need to use WHEN=GROUP, or similar), "cutting down" a record should be done with INREC.
BUILD would never need "1:", as this is the default. Columns in BUILD can lead to spaces in between fields, which may be the design, or not. Can also lead to "overlapping" fields, which is not allowed on BUILD.
I thing the problem is that the input is variable, requiring the input RDW (position one for length of four) to be included in the INREC record.
I avoid using FIELDS= in such situations. It is equivalent to BUILD, and is there for "backwards compatibility" for Sort Control Decks written many years ago. FIELDS is very "overloaded" (the same word meaning different things in different contexts, like SUM, SORT, INCLUDE/OMIT), so just because you can, doesn't mean it is a good idea to do so.
If you can clear up the variable/fixed question for your input and output, we can finish this off.