date:20161129

Re: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)

2016-11-29 Thread Charles Mills

Can PER trap on a mask setting?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Tuesday, November 29, 2016 7:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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=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

Re: How to Identify modules as C/C++ or Cobol, or ASM from dump (SYSMDUMP)

2016-11-29 Thread Bill Woodger

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=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.

50 matches

Mail list logo