IBM Mainframe Forum

I'm interested to see if anyone on here has an idea of why the solution, at least temporary solution, we came up with is working more so than a solution to the backup data set causing an ABEND.

The JCL code below is part of a PROC and then a splitter that takes a large (by my standards so far) amount of data and sends it to an application to display the data as a report. The report ends up being just under 10,000 pages with each page being 56 lines. I only changed the name of the OUTPUT before DD in the PROC, both DSN names, and the RPT name to post it here. Let me be clear, this works right now because I have the BACKUP commented out. In order to have a copy of the data as a backup, I changed the DISP of INPUT01 to OLD,KEEP,KEEP. Normally I wouldn't keep INPUT01 after the splitter runs. An ABEND occurs when the BACKUP is not commented out.

First, a code snippet from the PROC output that creates the GDG which will be used by the splitter:


Here is the splitter code:


Here is a relevant portion of the JESYSMSG:


Here is Data Set Information for the INPUT01 GDG (I think the block size is relevant, but am very new to mainframe so I could just be spinning my wheels):
Data class . . . . . : DCDATAX
Organization . . . : PS
Record format . . . : FBA
Record length . . . : 186
Block size . . . . : 27900
1st extent cylinders: 9
Secondary cylinders : 9
Data set name type :
SMS Compressible. . : NO

And here is an explanation of the ABEND:
S002 - 18 - AN INVALID RECORD WAS ENCOUNTERED ON A PUT OPERATION;
THE DATASET USES THE VARIABLE RECORD FORMAT. THE LENGTH VALUE OF
THE RDW IS EITHER: LESS THAN 4, GREATER THAN 32,767, GREATER THAN
THE BLOCKSIZE SPECIFIED IN THE DCB, OR LESS THAN 5 IF ASA CONTROL
CHARACTERS ARE BEING USED.

My thinking is that the data set is just too large because of the 32,767 limit, but not sure how this can be the case since the block size of the data set that is created in the PROC is 27900. There is no real necessity for this BACKUP issue to be fixed as it is only going to be running in a testing environment and my workaround for the backup does the job, but for educational purposes I was curious as to what a possible solution could be. I have asked some senior developers around my office and no one can figure it out, though no extensive amount of time has been put into this problem by anyone other than me.

Any ideas?

I don't see an option to edit my post. Both the output from the proc and the input in the splitter are the exact same data set name, I forgot to change one of them when I posted it here. Not sure why I wanted to change the names of them anyway, but they are, indeed, identical.

The first problem I see is the IEC036I message does not seem to match the JCL you are showing us.

IEC036I 002-18,IGC0005E,QPMSSUSP,JS10,BACKUP,17A3,D20018,...

The BACKUP text in the message represents the DD name of the DD statement that specifies the data set that is being processed, but the JCL you show has the DD statement commented: it cannot be the DD statement.

The other issue is the DCB attributes you are showing us show RECFM=FB. You cannot present a fixed length record as though it were a variable length record. That will definitely cause an S002 ABEND.

This is not to say you cannot copy a data set containing fixed length records to a data set containing variable length records, but the copy program must insert an RDW (Record Descriptor Word). An RDW for a record with 186 bytes of data will show a record length of 190, 186 data bytes + 4 bytes for the RDW. This means the LRECL must be 190, not 186. If the copy program is creating a valid RDW, that may be the cause of S002 ABEND.

Not quite 25 years ago I wrote a copy utility that would copy FB to VB. It would have gotten the S002 ABEND. I no longer have the program; it might have been smart enough to truncate the record to 182 data bytes or just not copy the record. After 25 years I no longer remember, and obviously I can not look at the 25 year old program!

Another thought: a program copying FB to VB may be trimming trailing blanks - if any - from the output, which will mean many records will be shorter than 190 bytes. I'm pretty sure my 25 year old program did that.

Well, that's all the analysis I can do with the little information we have. Good luck.

These users thanked the author steve-myers for the post:

Shmohawk (Tue Jun 02, 2015 5:23 pm)

As I always tell people here when I make a stupid mistake, "Please be patient, God isn't finished with me yet."

Had some more pressing issues come up and wasn't able to get back to this until yesterday, but it's annoying when people don't post a conclusion to their threads.

I wasn't clear enough with the code I posted. The BACKUP portion was not commented out when the job ran and abended with "IEC036I 002-18,IGC0005E,QPMSSUSP,JS10,BACKUP,17A3,D20018,...". I commented out the BACKUP portion of the code and kept (KEEP) the INPUT01 coming into the splitter so that I would have a backup of the report (since the BACKUP portion of the code was causing the ABEND and had to be commented out in order to successfully run).

I tried changing VB to FB for the BACKUP this morning and the ABEND was the same. I then increased LRECL and BLKSIZE to 190 and 28500 respectively. I know that Steve said I would need 4 bytes for the RDW if RECFM=VB, but I went ahead and tried increasing the size anyway. It works. I just spoke with someone here at work who has far more experience than I do and he said all he could think of was that there is so much hard code in WAAPSPLT, that it may have needed the extra LRECL and BLKSIZE for something completely unrelated to RDW, because the output is still coming out with 186 bytes. I don't know, I just know it works.

Here is the code that currently works:



I can obviously change the disposition of TEST.AMCQ.ADPLSUSP now since I don't need to keep that as a backup. Still not sure why the extra space was needed for the BACKUP (LRECL, BLKSIZE) since the output file is still only showing a record length of 186, but it's working so I'm going to continue backing away slowly.

Thanks so much for the help, Steve.

Cheers.

1. I think ordinary forum members have 10 minutes to edit a post; then they're stuck with the post. I know from experience this can be terribly frustrating, especially if you were allowed to start the update, but the 10 minutes expired before you were finished.
2. It appears WAAPSPLT alters the RECFM to VB. There are at least 2 ways this can be done, though it should warn you. To my mind this means the WAAPSPLT BACKUP data set is not a true backup since the RECFM and the data records have been altered.