Can PER trap on a mask setting? Charles
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bill Woodger Sent: Tuesday, November 29, 2016 7:08 PM To: [email protected] Subject: Re: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP) Are you running LE with TRAP(OFF)? That's the only way I know, yet, of getting the S0CA from a COBOL program. See the discussion here: https://www.ibm.com/developerworks/community/forums/html/topic?id=a639cb05-5604-42ab-95da-2a77dfccadbf&ps=25. There was an RFE raised, which is currently an "Uncommitted Candidate", meaning it is a possible thing for the future, for a compiler option to provide the S0CA, during development, for instance. However, would that, even if available, help you find the errant C/C++ program(s)? If the first C/C++ program set the bit and only the 300th COBOL program actually had an overflow? Are you, ideally, looking for a list of the C/C++ programs which have already been "used" in the run-unit so that you can manually inspect them for the setting? That, as you are probably aware, won't give you anything for C/C++ program which just haven't been loaded yet, but will be. How are the C/C++ programs setting the program mask? Do they use CEE3SPM, or some other method? If CEE3SPM, it shouldn't be too difficult to identify modules using that, although if you have 30,000 C/C++, 200 used (potentially) in your run-unit, and only four actually do the nasty of out 1,500 doing it in total... There is an LE User Exit, CEEBINT, but since that is executed at the start of a program, even trying to check there won't quickly lead to the C/C++ program(s). Prog Z is CALLed by a chain of 25 other COBOL programs (try to guess what they are each named), Z CALLs a C/C++ program, which sets the mask, but no ill effect on Z (immediately, at least) and then a few GOBACKs and it arrives at Prog E, which then CALLs E1 which starts another huge chain, and eventually E1431A gets a S0CA. No help at all. Even if there is a handy "table" of modules with their entry-points, you'll still miss those that have not yet been CALLed. Because the mask can be set and, if coded like that, it sticks, and COBOL "ignores" it, unless you use TRAP(OFF), yet COBOL (actually LE) consumes time ignoring it when it occurs, any C/C++ which is used by COBOL just has to "set it back" (can be PUSH, SET, POP for if the C/C++ may also be used by C/C++ or something else which likes S0CA) it is tricky. Getting COBOL to do the PUSH, SET, POP (either manually or by compiler change) would be "overhead" that would be paid for on every CALL. Perhaps contact IBM. At least if there is a handy LE table of module/entry-point, you could look at that at the end of the run and get something from there to prioritise a list. And bear in mind that any one run may not have exercised all the C/C++ programs that can potentially be CALLed. If it is not directly documented that for COBOL to C/C++ the C/C++ mustn't return to COBOL with the mask on, then perhaps that could be addressed as well. But, for your C/C++ programs, identify (all), prioritise (yours, if you can work it out), fix source and recompile. More information may lead to some more targeted suggestions, but at the moment it seems like (another) sticky issue for you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
