I guess one answer is that they should not report the member name. The software knows or could know the allocation is concatenated. It should just say "I/O error on the allocation, somewhere." I/O error on //DD:ASSEMOBJ.
Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, August 08, 2016 6:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Interesting C library file open mis-diagnosis On Mon, Aug 8, 2016 at 4:01 PM, Charles Mills <charl...@mcn.org> wrote: > > Was there a job log message, S213-rc identifying the catenand? > > Yes, > > 15.52.57 JOB01527 IEC141I 013-18,IGG0191B,xxxxxxPL, > PLKED,ASSEMOBJ-0009,1D41,LS050A, 325 > 325 DATASET.NAME(CZAISAUT) > > When I spotted that I figured out the problem. But I started out > looking at the program (PLINK) listing. When a program says "this is > my problem" it ought to know what it's talking about, right? > > Charles > > I would generally agree with your statement. I will also say that I'd bet that the data in the error message came from the results of a RDJFCB, or equivalent, service. Unfortunately, this service's handling of concatenated DDs is rather poor. Also (I'm fairly sure), when I/O is done against a DD, unless an "EOV exit" ( https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/eefsds.htm) is specified, there is no feedback as to which DSN in the concatenation actually had the I/O error. The aforementioned exit does cause this information to be fed back, but can be used to know when the program "switches" (goes to end-of-data) on one DSN to another to update a counter in the program. The program with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
