Hi Elardus, My responses intermixed below.
Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Elardus Engelbrecht Sent: Wednesday, September 20, 2017 12:14 PM To: [email protected] Subject: Re: superc question Pommier, Rex wrote: > However, it failed at 0-dark-30 this morning with an E37 on the output > statement. Please post the full E37 message and also any other messages too, including any messages from your VTS. Pretty much a standard E37-08 abend. The JCL initially had SPACE(CYL(5,2)) and it blew. He increased it to (CYL(50,20)) and it blew again so in order to make it run, he just changed the OUTDD to VTS. I moved the OUTDD back to disk and onto a different storage group with more space and the OUTDD ended up consuming 2100 cylinders of space so the E37s were valid. He just didn't go big enough on disk before throwing (or trying to throw) it to tape. Here's the output from the job pointing the OUTDD to VTS. Nothing weird, just went into a wait for 2 hours then timed out. 06.39.59 JOB02776 IEF233A M 0561,A44802,,ZCOMPALL,STEP040,TM.LFCZ.LCA0702.G6767V00 06.39.59 JOB02776 IEF233A M 056A,A41477,,ZCOMPALL,STEP040,TM.LFCP.LCA0702.G1059V00 06.39.59 JOB02776 IEF233A M 0515,PRIVAT,SL,ZCOMPALL,STEP040,LFCZ.ZCOMPALL.STEP040 06.39.59 JOB02776 IECTMS9 0515,A45094,ZCOMPALL,OUTDD ,09/25/2017,00001,.ZCOMPALL.STEP040 06.40.00 JOB02776 IEC705I TAPE ON 0515,A45094,SL,COMP,ZCOMPALL,STEP040,LFCZ.ZCOMPALL.STEP040,MEDIA2 08.40.49 JOB02776 IEA995I SYMPTOM DUMP OUTPUT 376 376 SYSTEM COMPLETION CODE=522 376 TIME=08.40.49 SEQ=48972 CPU=0000 ASID=007E 376 PSW AT TIME OF ERROR 078D0000 80CC965E ILC 2 INTC 01 376 NO ACTIVE MODULE FOUND 376 NAME=UNKNOWN 376 DATA AT PSW 00CC9658 - 41101000 0A0147F0 80341812 376 AR/GR 0: 00000000/00000001 1: 00000000/000060A4 376 2: 00000000/00006108 3: 00000000/000060A0 376 4: 00000000/0004405E 5: 00000000/80CC9654 376 6: 00000000/00000085 7: 00000000/00008C3C 376 8: 00000000/00CC95E0 9: 00000000/0000A978 376 A: 00000000/80CEF0BA B: 00000000/00CEF1AC 376 C: 00000000/00006108 D: 00000000/0000A978 376 E: 00000000/80D895B2 F: 01000002/80AF8090 376 END OF SYMPTOM DUMP 08.40.49 JOB02776 IEC537I BLOCK COUNTS: DEVICE=1, DCB=0 08.40.49 JOB02776 IEC210I 214-10,IFG0200Y,ZCOMPALL,STEP040,OUTDD,0515,A45094, 378 378 LFCZ.ZCOMPALL.STEP040 08.40.49 JOB02776 IEC999I IFG0TC0A,IFG0TC0B,ZCOMPALL,STEP040 ,DEB ADDR=AB379C ,DSN = LFCZ.ZCOMPALL.STEP040 08.40.49 JOB02776 IEF450I ZCOMPALL STEP040 - ABEND=S522 U0000 REASON=00000000 380 380 TIME=08.40.49 >That's OK, but what happened next is why I'm posing the question. To rerun >the job, the developer on call simply changed the JCL to point the OUTDD to >the VTS and restarted the job. Ask him why and on what (reason) is that change based? Simple space issue as mentioned above. >The job promptly stopped after mounting the 3 tapes (2 input and the OUTDD) >and did absolutely nothing until it timed out. Any messages from job/VTS? Any other Output? How did it timed out? Do you see any waiting replies or GRS contention? No GRS contention, no console messages, no nothing, just went into a long wait until it got the 522. > So here is my question. Is there a limitation or a problem with sending > ISRSUPC output to a tape based dataset? >I see in the ISPF user guide that " Note: SuperC does not support tape data >sets.", but why would that extend to a simple report output dataset? Yes, I also found that and got this annoying/unflattering advice next to it: "copy the data set to DASD using IEBCOPY, then process the DASD copy". Granted that is for datasets to be compared, not OUTDD, but be gentle with me... ;-) And that's another bizarre thing! After rerunning the job pointing the OUTDD to disk, I copied both of the input datasets being compared from the VTS to disk and reran the job with all 3 datasets on disk. It worked, and took roughly the same wall clock, CPU time, I/Os (adjusting for block size changes from tape to disk) and got the same output. So having the data that I would have expected ISRSUPC to complain about, namely the data being compared, on tape it worked; but the OUTDD caused the job to just hang. >So at this point, my question is more of a "why can't I send the sequential >output to a tape dataset, because that just doesn't make sense to me" type >question. Perhaps, as a workaround, you can send the OUTDD to a temp dsn and then copy in second step the temp dsn to VTS? Actually it doesn't need to be copied to tape, the job just does the SUPERC and if they compare differently, the differences report gets sent to a report archival system. Beside space issues, I know above workaround is a PITA and I hate it to create a new step to bypass a [stupid] problem. >Any thoughts? Paul's reply is more puzzling for me. I need to experiment with his painful scenario about DELTA... Interesting. Perhaps your problem is PMR-able? Perhaps you should go to PMR land and shake big blue awake? Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
