Here is an update on this issue. We were able to recreate the I/O error on our test development system. Only this time, we received an ECBCC X'41' track overrun and were able to identify the failing code. The ECBREPRG was received at our z/OS 1.9 production site. Our test development system is running z/OS 1.11 and uses Hitachi disk.
Thanks to all that replied. Regards, John K From: John P Kalinich/DEF/c...@csc To: [email protected] Date: 05/29/2010 07:42 AM Subject: Re: ECBREPRG EQU X'48' - REQUEST ELEMENT FOR CHANNEL PROGRAM HAS BEEN MADE AVAILABLE AFTER IT HAS BEEN PURGED Thanks, David. First a little background information. The EXCP program in question was created in 1968 by a team of IBM contract programmers who developed a data base system not unlike IMS in structure and design. My data base programmer who was involved with IBM in the initial stages of the project informed me that the program is issuing a single EXCP request and before each EXCP is issued for a buffer, the IOBUNREL flag is turned on. As a side note, we had an issue in z/OS 1.9 where DASD error recovery was zeroing out the IOBCSW when we crossed a track boundary. In this case, the channel program was formating an entire work file with one EXCP. IBM supplied us a fix for that problem. Regards, John K Re: ECBREPRG EQU X'48' - REQUEST ELEMENT FOR CHANNEL PROGRAM HAS BEEN MADE AVAILABLE AFTER IT HAS BEEN PURGED David Bond to: ASSEMBLER-LIST 05/28/2010 08:25 AM Sent by: IBM Mainframe Assembler List <[email protected]> Please respond to IBM Mainframe Assembler List I don't know how anyone can use EXCP without a copy of: MVS/ESA Component Diagnosis and Logic: EXCP Processor (LY28-1477) or similar. The level of detail in DFSMS Advanced Services is, to my mind, almost useless. And since the logic manuals are no longer published, I don't know how anyone can get started using any of the z/OS low-level services. <rant> If you need to know what is going on at a deeper level, you need the IOS Logic manuals (LY28-1487 and LY28-1488). These are really important if you want to use STARTIO instead of EXCP. STARTIO is not even mentioned in DFSMS Advanced Services. Apparently IBM thinks that STARTIO should not be used by mere mortals. But the lack of usable EXCP documentation suggests they feel the same way about it too. EXCP Related Requests absolutely fundamental and if not understood will cause problems like John Kalinich encountered. You have to know that you either need to set the IOBs to be unrelated or you need to know that you have to reset the error bits in the DCB after an error. And you probably can't get good performance out of EXCP unless you know about the three different Related Request types. If you aren't using EXCP to get high performance, then why are you using it? So why isn't this basic information in DFSMS Advanced Services? Why do we need to hang on to 20 year old logic manuals to find out how to use a basic service like EXCP? And the biggest problem is the lack of device documentation. None of the I/O interfaces to modern tape, DASD or communication devices are documented. So what good is EXCP or STARTIO? If you try to use EXCP or STARTIO but you don't know how to build a modern channel program, then your I/O will be slower than the access methods - so what is the point? I was lucky enough to start in this business before Object Code Only. I grew up reading the DOS/VS Supervisor listing and the VM CP source code. Those were my mentors. Later I was able to learn from a base of code already written to these interfaces. And I saved most of the MVS logic manuals (unfortunately not all of them). OCO and the lack of complete documentation is a huge barrier to those who want to enter our field. I think it is impossible for anyone, no matter how brilliant, to learn to write mainframe assembler programs now without human mentors. As long as experienced people are willing to help on this list and others, new people have a fighting chance. This includes people who are new to the entire field and more experience people who have just never used a specific service. </rant> The Related Request types, summarized from EXCP Logic: Type 1 will not start any processing until the prior EXCPs are complete. No page-fixing nor allocation of IOS storage (other than the RQE). Type 2 will do all of the processing up to the STARTIO and will issue the STARTIO when the channel-end/abnormal-end appendages for the prior EXCP complete. Type 3 will do all of the processing up to the STARTIO and will issue the STARTIO as soon as the DIE for the prior EXCP completes as long as there are no errors. If there are any errors, it acts like type 2. The fact that there can be one active EXCP and 4 prepared type 2 or 3 EXCPs may be the reason that QSAM generally prefers 5 buffers. But this is just a guess on my part. David Bond On Fri, 28 May 2010 09:14:16 +0100, Mike Kerford-Byrnes wrote: >David > >Very helpful > >Apart from this, and a few words in DFSMS Advanced services, is there any >further information on the use of these flags? > >How did you find out!? > >Mike Kerford-Byrnes
