Code Comments
Programming Forum and web based access to our favorite programming groups.Im getting a U0016 ABEND that says.. OUTREC - SHORT RECORD SORT FIELDS=(19,7,PD,A, 128,8,CH,A, 136,8,CH,A) SUM FIELDS=(255,9,PD, 488,4,PD, 629,8,PD, 653,6,PD, 765,4,ZD, 769,2,ZD, 772,1,ZD) OUTREC FIELDS=(1:1,63,64:X'9999999999C',70:70,5 003) My file is a variable block file and the above code is running successfully.. but for a particular file, it is abending.. i tried removing the OUTREC FIELDS line.. and my job run successfully. The outrec overrides the value in position 60 with +99999999999. ( the field is defined as comp-3, that's why it only takes up 6 bytes) -- posted via MFF : http://www.MainFrameForum.com - USENET Gateway
Post Follow-up to this messagesdsf wrote: > Im getting a U0016 ABEND that says.. OUTREC - SHORT RECORD > > SORT FIELDS=(19,7,PD,A, 128,8,CH,A, 136,8,CH,A) > > SUM FIELDS=(255,9,PD, 488,4,PD, 629,8,PD, 653,6,PD, 765,4,ZD, 769,2,ZD, > 772,1,ZD) OUTREC FIELDS=(1:1,63,64:X'9999999999C',70:70,5 003) > > My file is a variable block file and the above code is running > successfully.. but for a particular file, it is abending.. i tried > removing the OUTREC FIELDS line.. and my job run successfully. The > outrec overrides the value in position 60 with +99999999999. ( the field > is defined as comp-3, that's why it only takes up 6 bytes) It would be better to post sort questions in the ibm-main list or on one of the help boards (www.mvshelp.com, www.mvsforums.com), rather than in the COBOL list, but ... You specified 70,5003 in the OUTREC statement. This says that each record must be at least 5072 bytes long. The message tells you that one or more of your variable-length records is not that long. If you're just trying to copy the bytes from 70 to the end of the record, then you can use: OUTREC FIELDS=(1:1,63,64:X'09999999999C',70:70) This says that each record must be at least 69 bytes long, which I suspect they are. Frank Yaeger - DFSORT Team (IBM) - yaeger@us.ibm.com Specialties: ICETOOL, OUTFIL, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Post Follow-up to this messagesdsf <member@mainframeforum.com> wrote in message news:<XLAUc.27251$kC6.5758@cyclops.nntpse rver.com>... > Im getting a U0016 ABEND that says.. OUTREC - SHORT RECORD > > SORT FIELDS=(19,7,PD,A, 128,8,CH,A, 136,8,CH,A) > > SUM FIELDS=(255,9,PD, 488,4,PD, 629,8,PD, 653,6,PD, 765,4,ZD, 769,2,ZD, > 772,1,ZD) OUTREC FIELDS=(1:1,63,64:X'9999999999C',70:70,5 003) > > My file is a variable block file and the above code is running > successfully.. but for a particular file, it is abending.. i tried > removing the OUTREC FIELDS line.. and my job run successfully. The > outrec overrides the value in position 60 with +99999999999. ( the field > is defined as comp-3, that's why it only takes up 6 bytes) You don't say whether you are using SYNCSORT or DFSORT or ICESORT, though I doubt that it makes any difference. It would also be good practice to say what hardware and operating system you are using. However, it seems to me that you have probably not properly followed the rules for handling variable length records and that you have probably not allowed for the 4 byte descriptor field when you should, you will have to check the manual. I also note that your hex field has an odd number of characters, I don't know what effect that would have, but I think it is probably a mistake. Regards, Robert
Post Follow-up to this messagesdsf wrote: > Im getting a U0016 ABEND that says.. OUTREC - SHORT RECORD > > SORT FIELDS=(19,7,PD,A, 128,8,CH,A, 136,8,CH,A) > > SUM FIELDS=(255,9,PD, 488,4,PD, 629,8,PD, 653,6,PD, 765,4,ZD, 769,2,ZD, > 772,1,ZD) OUTREC FIELDS=(1:1,63,64:X'9999999999C',70:70,5 003) > > My file is a variable block file and the above code is running > successfully.. but for a particular file, it is abending.. i tried > removing the OUTREC FIELDS line.. and my job run successfully. The > outrec overrides the value in position 60 with +99999999999. ( the field > is defined as comp-3, that's why it only takes up 6 bytes) It would be better to post sort questions in the ibm-main list or on one of the help boards (www.mvshelp.com, www.mvsforums.com), rather than in the COBOL list, but ... You specified 70,5003 in the OUTREC statement. This says that each record must be at least 5072 bytes long. The message tells you that one or more of your variable-length records is not that long. If you're just trying to copy the bytes from 70 to the end of the record, then you can use: OUTREC FIELDS=(1:1,63,64:X'09999999999C',70:70) This says that each record must be at least 69 bytes long, which I suspect they are. Frank Yaeger - DFSORT Team (IBM) - yaeger@us.ibm.com Specialties: ICETOOL, OUTFIL, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Post Follow-up to this messagesdsf <member@mainframeforum.com> wrote in message news:<XLAUc.27251$kC6.5758@cyclops.nntpse rver.com>... > Im getting a U0016 ABEND that says.. OUTREC - SHORT RECORD > > SORT FIELDS=(19,7,PD,A, 128,8,CH,A, 136,8,CH,A) > > SUM FIELDS=(255,9,PD, 488,4,PD, 629,8,PD, 653,6,PD, 765,4,ZD, 769,2,ZD, > 772,1,ZD) OUTREC FIELDS=(1:1,63,64:X'9999999999C',70:70,5 003) > > My file is a variable block file and the above code is running > successfully.. but for a particular file, it is abending.. i tried > removing the OUTREC FIELDS line.. and my job run successfully. The > outrec overrides the value in position 60 with +99999999999. ( the field > is defined as comp-3, that's why it only takes up 6 bytes) You don't say whether you are using SYNCSORT or DFSORT or ICESORT, though I doubt that it makes any difference. It would also be good practice to say what hardware and operating system you are using. However, it seems to me that you have probably not properly followed the rules for handling variable length records and that you have probably not allowed for the 4 byte descriptor field when you should, you will have to check the manual. I also note that your hex field has an odd number of characters, I don't know what effect that would have, but I think it is probably a mistake. Regards, Robert
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.