Here's why I suggest a SLIP trap. Except in the simplest of environments, I don’t trust SYSUDUMP necessarily to capture the first error. I mentioned here before how I once used SLIP trap to diagnose a COBOL S0C4 that actually started out as a S0C7 that got screwed up by a bad STAE routine. In the case of SLIP, you'll most likely capture the original error before LE has had its way with environment.
Second, I would want to use IPCS. That means an unformatted dump in a data set. You could do that with SYSMDUMP and a DASD allocation, but really, why not let the system do it for you? You pay the same MLC either way. ;-) . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Woodger Sent: Tuesday, February 07, 2017 3:03 PM To: [email protected] Subject: (External):Re: Program now working, but why? "Rather than trying to infer the cause by tweaking everything in sight, how about this: Set a SLIP PER trap to catch an SVC dump for the first abend of any kind, S0C4 or otherwise. That dump may tell you the exact cause far more quickly than trial-and-error with recompiles/reassemblies/logic-changes." Isn't there already a dump? If there isn't, I absolutely agree. Todge about with things, and you change things. Program A CALLs Program B. Program B goes into a Big Fat Loop. LOOP. do some stuff IF loopcounter NOT GREATER THAN +5 ADD 1 TO loopcounter GO TO LOOP. Programmer "adds a DISPLAY" to B. No loop. Programmer removes added DISPLAY. Loop. Programmer adds DISPLAY to A. No loop. Programmer removes added DISPLAY. Loop. Programmer adds DISPLAY to both programs (yes, they did) No loop. Faffing-about continues for a couple of days, but the only time it loops is with the programs unchanged. Comes to me with a big smile and "I've found a compiler bug ". I looked at the above code, and ask what was the last code change he'd made before the first loop. He showed me in Program A. Utterly wild subscript, MOVEing LOW-VALUES to a one-byte field within a large group item subordinate to an OCCURS, conditionally. Just happened to hit the low-order part of the binary one in the Literal Pool of Program B. So, adding the "constant" literal value one, was actually adding zero, so the loop could never terminate. A handful of other scattered single-byte binary-zeros had had no obvious affect amongst all his "compiler bug" hunting. But. Put in a DISPLAY, with a nice literal, prior to the use of +1, and the location of the +1 is changed (OS/VS COBOL doesn't define literals in reverse order), so now, for the loop, it is +1. Add a DISPLAY to Program A, and the Program B code "moves", and again the +1 in the literal pool is preserved. Cancel, with a dump. Look at the dump. Look at the code for the loop, and there's X'0000' where X'0001' should be in the Literal Pool of Program B. If ever overwiting of executable code is suspected, adding code in front of the problem is going to shift it at best, and mask it at worse. Bust that dump. Guessing and DISPLAY I find of little value. Obtaining all the information possible, and going forward with what matches all the information (cue various Sherlock Holmes quotes) I find of great value. A dump (and for sure a full one) mostly has all the information needed. Having said that, something that happens with record 17, which causes a failure when record 291,347 is reached, is more problematic - except that deduction leads you there, and at times surprisingly fast. The information available so far does not indicate that this can be an addressing problem due to 31/24. The AMBLIST Module Summaries are the same. OK, if Peter Ten Eyck remains quiet on the subject from now on, there's that outside possibility that the same report was compared to itself, and the actual new report reveals exactly what people have been suggesting is possible :-) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
