开云体育

Understanding COBOL S013 U0000 ABEND while accesing variable length records dataset.

Alejandro olivan Alvarez All Messages By This Member #4621 Hi again folks. ? I'm getting S013 U0000 abend at the GO step of a COBOL program. ? The COBOL program is not the problem (I'm studying Jay Moseley's materials... this ona came from : ) but the JCL calling it. For the shake of practice/learning, I do not 'just run' the examples, but rather adapt to my 'shop' and, with this particular one, which came with source code and sample data all inline on the JCL itself, I've separated source code into my COBOL VSAMIO sample sources PDS, the sample data in its dataset, and the actual JCL as a member of my CNTL VSAMIO sample dataset... so far, so good... But I think I'm failing on getting data into my program from the sample data dataset. ? This is the offending JCL segment from the printing: ? ?27 XXGO EXEC PGM=.LKED.SYSLMOD,COND=((5,LT,COB),(5,LT,LKED)) 00001900 ?28 //GO.SYSPRINT DD SYSOUT=A ?29 //GO.SYSOUT DD SYSOUT=A ?30 //GO.SYSUDUMP DD SYSOUT=A ?31 //GO.SYSUT1 DD DSN=ALEX.COBOL.VSAMIO.TESTDAT1,DISP=SHR, ?// DCB=(LRECL=84,BLKSIZE=4096,RECFM=VB), ?// SPACE=(TRK,(1)) ?32 //GO.SYSUT2 DD DISP=(NEW,PASS),DSN=&&JOINED,UNIT=SYSDA, ?// DCB=(LRECL=148,BLKSIZE=1480,RECFM=FB), ?// SPACE=(TRK,(50)) ? Originally, GO.SYSUT1 DD was simply inline data, so DD ? ... STUFF ... /* ? I have kept the original length and format, 84, VB on the dataset holding de sample data, since that was the allocation I had from the original file. At this step, the COBOL program joinrec joins variable length records into a fixed length one but it fails ? 12.38.24 JOB 1079 IEF450I ESDSAIXD GO COBUCLG1 - ABEND S013 U0000 - TIME=12.38.24 12.38.24 JOB 1079 ESDSAIXD COBUCLG1 GO PGM=*.DD AB S013 ? There should be a way to have the data outside of the JCL regardless of its format being different (that's in my understanding what the COBOL program is handling). OR maybe I'm missing it completely? any clues? ? -- Alejandro Olivan. Spain.
M Verpelli All Messages By This Member #4622 I could be wrong but to me that dataset looks like it's 80 FB. ? Marco
[email protected] All Messages By This Member #4623 Somewhere there might be a reason code (in Register 15). An IEC141I message, perhaps What LRECL and RECFM does the program expect SYSUT1 to have? If "Originally, GO.SYSUT1 DD was simply inline data, so DD ? ... STUFF ... /" , then it probably expected 80, F (or FB). The JCL below has "DCB=(LRECL=84,BLKSIZE=4096,RECFM=VB)". Did you change the program to expect variable length records? Even though all the records might be 80 bytes, there are differences in the way F and V records are processed. If all the records are 80 bytes ( ALL records), you could probably convert them // EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * REPRO INFILE(IN) OUTFILE(OUT) //IN DD DSN=ALEX.COBOL.VSAMIO.TESTDAT1,DISP=SHR //OUT DD DSN=&&T,DISP=(,PASS), // DCB=(LRECL=80,RECFM=FB,BLKSIZE=4000), // UNIT=SYSDA,SPACE=(TRK,(50,1),RLSE) ... //GO.SYSUT1 DD DSN=&&T,DISP=OLD I've dropped the DCB and SPACE information on input datasets, because they should be picked up from the actual DCB information on the datasets. James Campbell toggle quoted message Show quoted text On 1 Aug 2024 at 1:10, Alejandro olivan Alvarez via groups.io wrote: Hi again folks. I'm getting S013 U0000 abend at the GO step of a COBOL program. The COBOL program is not the problem (I'm studying Jay Moseley's materials... this ona came from : ) but the JCL calling it. For the shake of practice/learning, I do not 'just run' the examples, but rather adapt to my 'shop' and, with this particular one, which came with source code and sample data all inline on the JCL itself, I've separated source code into my COBOL VSAMIO sample sources PDS, the sample data in its dataset, and the actual JCL as a member of my CNTL VSAMIO sample dataset... so far, so good... But I think I'm failing on getting data into my program from the sample data dataset. This is the offending JCL segment from the printing: 27 XXGO EXEC PGM=.LKED.SYSLMOD,COND=((5,LT,COB),(5,LT,LKED)) 00001900 28 //GO.SYSPRINT DD SYSOUT=A 29 //GO.SYSOUT DD SYSOUT=A 30 //GO.SYSUDUMP DD SYSOUT=A 31 //GO.SYSUT1 DD DSN=ALEX.COBOL.VSAMIO.TESTDAT1,DISP=SHR, // DCB=(LRECL=84,BLKSIZE=4096,RECFM=VB), // SPACE=(TRK,(1)) 32 //GO.SYSUT2 DD DISP=(NEW,PASS),DSN=&&JOINED,UNIT=SYSDA, // DCB=(LRECL=148,BLKSIZE=1480,RECFM=FB), // SPACE=(TRK,(50)) Originally, GO.SYSUT1 DD was simply inline data, so DD ? ... STUFF ... /* I have kept the original length and format, 84, VB on the dataset holding de sample data, since that was the allocation I had from the original file. At this step, the COBOL program joinrec joins variable length records into a fixed length one but it fails 12.38.24 JOB 1079 IEF450I ESDSAIXD GO COBUCLG1 - ABEND S013 U0000 - TIME=12.38.24 12.38.24 JOB 1079 ESDSAIXD COBUCLG1 GO PGM=*.DD AB S013 There should be a way to have the data outside of the JCL regardless of its format being different (that's in my understanding what the COBOL program is handling). OR maybe I'm missing it completely? any clues? -- Alejandro Olivan. Spain.
Alejandro olivan Alvarez All Messages By This Member #4624 Hi! ? I checked the actual lenght of the sample data, variable length records and, as pointed by RFE/ISPF, they're actually 84 charcaters long. Records are of variable length or split accross several 'lines' (I have not very much experience with variable length records), including empty ones. But there're many records/lines spanning 84 chars long, so, originally, the inline data should have been indeed 84, and matches that LRECL of the original JCL file as reported by RFE/ISPF at 84 (weirder to me is its 4096 block size though... not an 84 multiple) As I understand, the first COBOL program on the demo is tasked, precissely, to assemble 148 fixed length records before further processing.? ? Also, I initially got stuck with JCL error when I initially tried to omit DCB/SPACE DD parameters, and go just DSN and DISP. I forgot to mention here that I'm on TK5, so the JCL and COBOL syntax may be tricky here. ? Cheers. -- Alejandro Olivan. Spain.
Joe Monk All Messages By This Member #4625 Can you post the full output of the job? Joe On Thu, Aug 1, 2024 at 4:21?AM Alejandro olivan Alvarez via <alejandro.olivan.alvarez=[email protected]> wrote: toggle quoted message Show quoted text Hi! ? I checked the actual lenght of the sample data, variable length records and, as pointed by RFE/ISPF, they're actually 84 charcaters long. Records are of variable length or split accross several 'lines' (I have not very much experience with variable length records), including empty ones. But there're many records/lines spanning 84 chars long, so, originally, the inline data should have been indeed 84, and matches that LRECL of the original JCL file as reported by RFE/ISPF at 84 (weirder to me is its 4096 block size though... not an 84 multiple) As I understand, the first COBOL program on the demo is tasked, precissely, to assemble 148 fixed length records before further processing.? ? Also, I initially got stuck with JCL error when I initially tried to omit DCB/SPACE DD parameters, and go just DSN and DISP. I forgot to mention here that I'm on TK5, so the JCL and COBOL syntax may be tricky here. ? Cheers. -- Alejandro Olivan. Spain.
Alejandro olivan Alvarez All Messages By This Member #4626 Absolutely no problem on my part, the problem I guess is the sheer length of the output: it includes not only the source code of the COBOL programs, but add to it it copies the VSAMIO stuff. Add also the dump... and it is 55 pages long output. ? From the output I see the job ran until compilation and linking, I got the compiler output and the linker output, but abended in the execution. I haven't tried before attaching documents on replies, I'll try? ? Cheers. -- Alejandro Olivan. Spain. virtual1403_J1079_ESDSAIXD-2024-07-30T11.pdf virtual1403_J1079_ESDSAIXD-2024-07-30T11.pdf
M Verpelli All Messages By This Member #4627 I insist: the original input dataset is 80 F , if you extract in and put it in a 84 V but ln the COBOL source it is declared 80 F you will always get ABEND. ? Marco
Rene BRANDT All Messages By This Member #4628 Hi Alejandro, The program JOINREC has not the definition for your file. SYSUT1 is a FB 80. You have to define the SYSUT1 with VARIABLE definitions. For the next step you use the JOINREC output with 148 record length but IDCAMS reads only 80 bytes if i remember correctly. Next question why to put 2 lines from input to create a file IDCAMS will not be able to use ? 搁别苍é Le jeudi 1 ao?t 2024 à 12:41:05 UTC+2, Alejandro olivan Alvarez <alejandro.olivan.alvarez@...> a écrit : Absolutely no problem on my part, the problem I guess is the sheer length of the output: it includes not only the source code of the COBOL programs, but add to it it copies the VSAMIO stuff. Add also the dump... and it is 55 pages long output. ? From the output I see the job ran until compilation and linking, I got the compiler output and the linker output, but abended in the execution. I haven't tried before attaching documents on replies, I'll try? ? Cheers. -- Alejandro Olivan. Spain.
Rob Prins All Messages By This Member #4629 I haven't tried before attaching documents on replies, I'll try? Please zip the document and place this file in the Files section. ? Cheers, Rob ? ?
Alejandro olivan Alvarez All Messages By This Member #4630 Ahhhhh I see it! you're right! the program input record is expecting 80 LRECL. ? What a funny thing!!! I guess this is because I sent the original file using NJE38!!! ? I have to check that out again. ? Thank you! -- Alejandro Olivan. Spain.
Ronald Hahn All Messages By This Member #4631 Your SYSUT1 input dataset to you Cobol program must be RECFM=FB,LRECL=80,BLKSIZE=...blocksize that is a multiple of 80, perhaps 8000. toggle quoted message Show quoted text On 08/01/2024 7:13 AM EDT Alejandro olivan Alvarez <alejandro.olivan.alvarez@...> wrote: ? ? Ahhhhh I see it! you're right! the program input record is expecting 80 LRECL. ? What a funny thing!!! I guess this is because I sent the original file using NJE38!!! ? I have to check that out again. ? Thank you! -- Alejandro Olivan. Spain.
Alejandro olivan Alvarez All Messages By This Member #4632 Thank you all guys. As soon as I had the sample data in a correct, 80 length, dataset, everything lined up with correct/consistent DCB and all steps ran CC 0000 ? Cheers. -- Alejandro Olivan. Spain.
M Verpelli All Messages By This Member #4633 If you want you can try the same simplified example, only one IDCAMS "block" and only one COBOL program. CNTL is the JCL DATA must be uploaded with fixed record length = 148 COBOL it the program Have fun Marco EXAMPLE.zip EXAMPLE.zip
Jeff Bassett All Messages By This Member #4634 开云体育 Alejandro, In your COBOL program – the file section specified as FIXED – LRECL 80 ? So this makes perfect sense – when you were using Variable records – this caused a mis-match ? ? -J- ? Jeff Bassett Bassettj@... (301) 424-3362 (office) (240) 388-7148 Cell ? Time spent flying? - is NOT deducted from one’s lifespan ? toggle quoted message Show quoted text From: [email protected] <[email protected]> On Behalf Of Alejandro olivan Alvarez via groups.io Sent: Thursday, August 1, 2024 10:18 AM To: [email protected] Subject: Re: [H390-MVS] Understanding COBOL S013 U0000 ABEND while accesing variable length records dataset. ? Thank you all guys. As soon as I had the sample data in a correct, 80 length, dataset, everything lined up with correct/consistent DCB and all steps ran CC 0000 ? Cheers. -- Alejandro Olivan. Spain.

Previous Topic Next Topic