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 could then use a dynamic allocation "return information" to get all the DSNs in the concatenation and use the relative counter to get to the one which actually got the error. Note that this is just a "swag" on my part since I've never actually done it. If someone knows for sure, I'd appreciate some real world knowledge on this. -- Klein bottle for rent -- inquire within. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
