Hi, I once had a PMR open, where COBOL called a COBOL DLL and the program mask changed. Which was annoying for the assembler that later was called and depended on the exception bits in the PSW. The outcome was: 1. Language Environment neithersaves nor restores the program mask setting across calls to Language Environment servicesor calls within the Language Environment environment. http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceev100/pgmask.htm 2. The call from NODLL Cobol to the DLL COBOL was treated as new language (causing IGZCFCC calling CEEBADDM service to add a new member). The maskable program exceptions are enabled for all member languagesrepresented in the root or main load module during Language Environment initialization.Each member language informs Language Environment of itsprogram mask requirements, and Language Environment ORs allof the requirements together and sets the program mask during initialization.During termination, the program mask is reset by Language Environment to itsvalue upon entry to Language Environment initialization. 3. While the enclave is running, the program mask is influenced bythe callable service, CEE3SPM, and by members' requirements that arenewly-added as a result of a dynamic call or fetch; this is handledby the CWI service CEE3ADDM. 4. If a program expects to work with a specific program mask, it needs to set it to the values it requires and reset it back, because of 1.
This basically means, in an unlucky mix or with new compilers/languages, the program mask might be different than it was before. Hope that helps. Denis. -----Original Message----- From: Peter Hunkeler <p...@gmx.ch> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Wed, Nov 30, 2016 1:38 pm Subject: AW: Re: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP) Bill,Thanks a zillion for this information and the pointers in there. While it does not represent a solution to my question, it does give me most valuable to the problem at hand. I'll have to discuss this with the people responsible for the Cobol V5 migtation here. I'm kind of alerted by the statement "Cobol V5 always uses C". That means the decimal overflow mask will always be set after the first (internal) call to C code? Can you be more specific on it means that "Cobol V5 always uses C"? The 000A exception causes us problems, I understand so far, in context of programs running under control of Smart/Restart. Smart/Restart installs its own error handlers, which are obviously not supposed (or prepared) to handle an 000A exception in Cobol context. It has something to do with S/R rolling back the DB changes and LE then ignoring the error giving contol back to the Cobol code. Later, a next DB call will fail with, mostly, a 0004 exception often in DSNHLI, because cursors are no longer open. (Note that this is only vague information at this time. I'll have to understand what really happens. I have just gotten involved in this.) -- Peter Hunkeler Von: Bill Woodger <bill.wood...@gmail.com> An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP) Datum: 30.11.16, 04:07 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
