On Wed, Feb 1, 2012 at 11:30 AM, Charles Mills <[email protected]> wrote: >> the dump title and dump options must respectively be 80 and 255 byte fixed > length character strings > > That's why I am using the IBM leawi.h macros to define them. _CHAR80, for > example, is declared as typedef char _CHAR80 [ 80];
Charles - One thing I noticed in the example (and it probably is insignificant) is that care was taken to init the fields to spaces and to NOT copy the trailing binary zero associated with a "ddddd" string in C/C++. I only mention it because of the grief that you are having over this and hoping that this will get you past it. Sam > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf > Of Sam Siegel > Sent: Tuesday, January 31, 2012 8:34 PM > To: [email protected] > Subject: Re: S0C4 in CEE3DMP > > On Tue, Jan 31, 2012 at 8:17 PM, Don Poitras <[email protected]> wrote: >> Tea leaves are good for making tea. :) I would compile SignalHandler.C >> with the LIST option to see the psuedo assembly output and see from >> the dump where the abend occured and try to figure out what went >> wrong. The message you've given wouldn't lead me to think there was a >> problem in CEEDMP, but rather in the calling code. >> >> >> In article <[email protected]> you wrote: >>> I am getting a S0C4 (apparently - assuming I am reading the tea >>> leaves >>> correctly) calling CEE3DMP from a C linkage signal handler routine in >>> a C++ program under v1.13. I believe the code used to work under >>> V1.10 but I am not absolutely certain that nothing has been changed. >> >>> I am using leawi.h for the declaration of CEE3DMP. Here is my calling >>> sequence: >> >>> _CHAR80 dumpTitle = "My dump title here"; // do not exceed 60 >>> characters per z/OS V1R10.0 Language Environment Programming >>> Reference >>> _CHAR255 dumpOptions = "BLOCKS,REGSTOR(256),FNAME(CZADIAG)"; >>> _FEEDBACK fc; > > > Charles - Look closely that the way dumpTitle and dumpOptions are defined in > your source code. > > The V1R10 LE programming reference (SA22-7562-10) indicates that the dump > title and dump options must respectively be 80 and 255 byte fixed length > character strings. > > > Sam > > > > >> >>> CEE3DMP(dumpTitle, dumpOptions, &fc); >> >>> Here is the SYSOUT output that leads me to believe the problem is > CEE3DMP: >> >>> CEE3204S The system detected a protection exception (System >>> Completion >>> Code=0C4) >>> From compile unit /u/xxxxxx/Source/SignalHandler.C at entry >>> point sigHandler at statement 92 at compile unit >>> offset +0000016A at entry offset +0000016A at address 15383292. >> >> >>> Statement 92 is the CEE3DMP call above. >> >>> The whole situation is a little confusing because the error in >>> question that triggered the Signal is also a S0C4. (It is intentional >>> as part of a test; there is no reason to think that storage in >>> general is corrupted.) >> >>> The CEEDUMP output on DD CZADIAG correctly diagnoses the original S0C4. >> >>> What should I be looking for? Any clues? >> >>> Thanks, >> >>> Charles >> >> -- >> Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus >> Drive [email protected] (919) 531-5637 Cary, NC >> 27513 >> >> ---------------------------------------------------------------------- >> 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 > > ---------------------------------------------------------------------- > 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
