Couldn't you use a GTF trace with the trace=slip operand and set an IF or SB SLIP ACTION=TRACE with the limits being in your program? Setting TRDATA=(STD,REGS) should show you where the branch is occurring and where it is branching to.
Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Monday, August 28, 2006 2:38 PM To: [email protected] Subject: Re: SLIP trap for "wild branch"? > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf Of Thompson, Steve (SCI TW) > > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf Of Chase, John > > Might be worth a shot. I initially dismissed this as a possibility > because the application is CICS/COBOL, and those kinds of programs > "normally" don't visit the PSA (indeed, not many of them even know > there > *is* a PSA, let alone where to find it). > <snip> > > This is exactly where I would expect things to go south when you jump > from 31 bit Architecture machines to z/ARCH machines (error recovery > and changing of some anchor in PSA). But there remains the fact that the program runs correctly in ONE of the three CICSes -- and all three CICSes share the same physical load library. > If you can, try setting the ARCHLEVEL to 1 in the PARMLIB of one of > the > z/9 machines (I trust, not having looked at the functional > characteristics manuals that this is possible -- that is, that the > machine won't cause NIP, IRIM, NUC to choke during IPL -- and you must > be at z/OS 1.4 or earlier to run on a non-z/ARCH machine, right?). No can do -- (1) we're running z/OS 1.5, and (2) we didn't buy the "bi-modal accommodation feature", which was offered only for z/OS 1.2 - 1.4 anyway. z/OS 1.5 is the last release that can run on non-z/Arch. machines. > IF the problem magically stops, then it would appear that there is > some error recovery code (this is my assumption) that can't handle the > difference between a single page PSA and a dual page PSA. >From what is visible via CEDF, there aren't any errors from which to recover -- until the EXEC CICS ENDBR command that doesn't exist in the program under examination, and it appears arrival there was just "blind luck". Unfortunately I have no way of knowing how many instructions are executed between the previous EXEC command and the "bogus" ENDBR (I've "disassembled" only about 80 bytes worth of the code following the last successful EXEC command so far, and found nothing amiss), but the CEDF interval is not noticeably slower than the intervals between other EXEC commands. -jc- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ----------------------------------------- This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
