On Mon, 9 Jan 2012 12:49:52 +0800 Ron Hesketh <[email protected]> wrote:
:>Hi Steve, :> Sorry I pressed send too soon ... :> I think program B has to update the DCB with its own EODAD address :>which exists in program B. :> Quoting an old MVS /XA data Administration Guide.... Not required - it is merely a address. :> "The EODAD routine is not a subroutine,but rather a continuation of the :>routine that issued the CHECK,GET or FEOV macro." It is a sort of subroutine, as BR 14 will return to the instruction after the GET/CHECK. It isn't, as the R13 save area is in use and R2-R13 are the same as the GET instruction. :>From: Steve Comstock <[email protected]> :>To: [email protected] :>Date: 09/01/2012 09:28 AM :>Subject: EODAD mystery :>Sent by: IBM Mainframe Assembler List <[email protected]> :>I think I may be missing something here, but I can't :>pin it down. :>Program A contains DCB/DCBE for a file; the DCBE has :> EODAD=ENDIFILE :>The routine called ENDIFILE contains just this: :> oiy flags,endInfile More precisely, the object code that instantiates the instruction assuming the same base register. :> br r14 :>Program A opens the file and later links (linkx) to :>Program B, passing the dcb; Program B does GETs; :>after each GET, Program B checkd if the end of file :>flag is set. :>I have verified that both programs are accessing the :>same byte / bit and that the end of file flag is, indeed, :>set. :>But, control does _not_ return to PROGRAM B from the :>EODAD routine in PROGRAM A. Instead I get :>IEC020I 001-5,TESTF005,STEP1,TTFIN,0D30,VPWRKA, :>IEC020I SCOMSTO.B625.NEW.FOLKS :>IEC020I GET ISSUED AFTER END-OF-FILE <=== :>and an abend. :>All the reading I've done seems to indicate my logic :>is viable, but it's not working. :>Any suggestions? Here are two: "flags" has a different base/displacement in the subroutine. The DCBE was not accepted. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
