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

[Peter Hunkeler]

>Thanks a lot, that's useful to know. A genuine moment for me to say "thank you 
>for sharing".


I'll second that statement!


-
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Bill Woodger]

Thinking a bit more, even though there may be parts, bits and pieces of C/C++ 
code to do with the COBOL program (and supporting routines) anything in the 
COBOL program is of course "COBOL" and any "COBOL routines" I'd imagine would 
also be treated as "COBOL" by LE. 

So I think it reasonable to postulate that the problem only arises with 
user-written C/C++ code, and that the "first" C/C++ user-written code gets the 
mask set, as described. With LE TRAP(ON) the issue just may not be apparent.

Perhaps an initial deliberate CALL to a C/C++ program which uses CEE3SPM to 
turn off that in the mask? LE fires it up as a "new language", sets the mask 
bit, transfers control to the C/C++ program, which then immediately turns it 
off and simply returns to the COBOL caller. As each new C/C++ program is 
CALLed, the mask bit is off, and remains unchanged.

I think that should work, whatever Smart/Restart is doing.

Test with the simple COBOL program (yet to be provided...)  doing the CALL and 
not doing the CALL, with TRAP(ON) and TRAP(OFF), both "inside" and "outside" 
Smart/Restart. Ah. Not so easy to replicate the actual issue you have with 
Smart/Restart and the DB and the 0008. So just do it "outside", and if it 
behaves as expected (S0CA without the CALL and with TRAP(OFF), no S0CA 
otherwise) then try it in the actual system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Bill Woodger]

>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"? 

Interesting questions. I don't have access to V5+, so can't experiment. I would 
expect that "COBOL functionality" that happens to be in C/C++ would be aware of 
the issue for COBOL and would turn off that bit... but is that so?

I'll try to post a simple COBOL program to carry out an experient later. I'll 
have to second-guess the new optimizer, because it is much more clever than up 
to V4. 

Here's an extract from a small V5.2 program I was sent:

E X T E R N A LS Y M B O LD I C T I O N A R Y

TYPE   ID   ADDR   LENGTHNAME

SD 1  00  00MAIN
ED 2  00  00C_CEESG003
ED 3  00  000808C_CODE
LD 4  00  00MAIN#C
ER 5  00  00CEESTART
ER 6  00  00CEEBETBL
ED 7  00  00C_WSA
PR 8  00  000114MAIN#S
ED 9  00  22B_IDRL
ER10  00  00IGZXBST1
ER11  00  00MAIN
ER12  00  00IGZXPRS
ER13  00  00IGZXCMSG
ER14  00  00IGZXDSP
ER15  00  00IGZXRTN
ER16  00  00IGZXTREN
ER17  00  00IGZXRT1
LD18  00  00MAIN
ER19  00  00CEESG004
ED20  00  00C_@@PPA2
PR21  00  08
ED22  00  00C_@@CSINIT
PR23  00  04

There is no direct equivalent of this on a pre-V5 compile listing, and the 
there's "evidence" there. When I'm home I'll try to futher locate something 
mentioning this from someone at IBM. Search-engineing for languages whose name 
consist of only one alphabetic character is... less than pleasant.

Have you looked at the setting for LE's TRAP? If it is ON, LE will deal with 
the 0008 transparently to the COBOL programs and they will not give a S0CA. At 
least TRAP(OFF) is the only way I know of (in interaction with the mask being 
on) to get a S0CA from COBOL. There may be some unintended interaction with the 
Smart/Restart, but knowing if the LE TRAP is ON or OFF is worthwhile.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Peter Hunkeler]

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

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

[Peter Hunkeler]

>Try in IPCS VERBX LEDATA 'TCB(00xx) CEEDUMP' where the TCB is the one
that abended and you should get the LE trace-back, similar to what you would
get in SYSOUT CEEDUMP.




Yes, I know that. The problem is that the module I'm looking for is not in the 
current call chain. So this is of no help.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Peter Hunkeler]

>If you want the layout, I can post it. No secret - it's in the LE books.



I'm not as used to LE control blocks as you might think. So, please, yes, post 
it. Would save me some work, and will be most appreciated.


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Peter Hunkeler]

>Are these programs managed by a source managers?  Change man, Endevor, etc...?


Yes, but it means looking up some 370+ single modules (the previous 500+ had 
some module duplicate).


>I do not think the dump will be much help in this.  When a C program (any
flavor) is compiled, it will contain LE and EDC modules.  Add to that the Cobol
Program with IGZ and you have a big haystack to find the needles.  But I am not
sure there is a "header" in the main routine (MYPGM) that say "Hey I am a C
Program"


Not there is no common header. And even if there was, looking up 370+ header 
manually is not what I'm looking for.



>If the LE took the dump (CEEDUMP) then that might be more helpful.  See if
either a dataset or sysout was created for your abend.


I had LE take a dump to SYSMDUMP, not a formatted CEEDUMP. But I can format 
everythink alike with the VERBX LEDATA IPC command.


I doubt there is something that I could execute an IPCS  RUNCHAIN and get a 
list. But I thought I'd ask before giving up and going to CMAN 




--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Peter Hunkeler]

>The CSECTs of the modules are identified by the prefix like CEE (for LE 
>modules), IGZ (for COBOL). I don't know what is the prefix for C/C++.


It's about my installations own code, not the LE runtime modules.


>How are these modules compiled? Were they compiled into one big module or are 
>they called dynamically during runtime?


Dynamically loaded.




>AMBLIST? I know it is a PITA for 500+ modules. I believe there is a sample 
>utility in the CBT tapes. Perhaps you can ask Sam Golob for help?
>Alternatively, scan the modules for product names used for compiling the 
>modules, like this 5655S71 for COBOL compiler.


Not the solution I'm looking for..


>Of course, it depends how your dump is written out.



SYSMDUMP, as mentioned in the subject.




--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN