Thanks, Sam. It makes it through 20 or so pages of the dump so I am going to guess the '\0' in the title is not the problem.
The plot thickens. I *still* can't test (mostly to see if the problem is solved by different CEERUN libraries) due to an unrelated bit of sysprog foolishness on my V1R11 and V1R12 systems, but the problem goes away if I compile with OPT(2) INLINE NOTEST NOGONUMBER (my standard release options) rather than OPT(0) NOINLINE TEST GONUMBER (my standard test options) I guess because CEE3DMP can't do the variable displays that it is trying to do when it blows up. I said in the OP that I thought it had worked under V1R10 but I was not sure if something had changed; perhaps what changed is that my original testing was with the release options, I don't know. Seeing as having this code work at customer sites is what is important to me (the error is annoying but does not really hurt anything on a test system) I think I am going to declare a victory. Thanks, all. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, February 01, 2012 12:14 PM To: IBM-MAIN@bama.ua.edu Subject: Re: S0C4 in CEE3DMP On Wed, Feb 1, 2012 at 11:30 AM, Charles Mills <charl...@mcn.org> 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++. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
