Hmmm. To me, that strategy seems appropriate for a report program ("this
field is not relevant to this type of transaction so print blanks or
asterisks") but not for a dump program. Isn't a dump -- consider the name --
supposed to be "here it all is, as it all is, you figure out what is
relevant"?Is not the contents of an "irrelevant" register save area sometimes the very clue you need? "Look at that -- it looks like part of one of my error diagnostics -- I must be overlaying storage with the message" or "look, R2 is pointing to my widget table. I must have come through the widget lookup routine after all." I know, my comment is fundamentally irrelevant. LE's dump program works the way it works, and they are not going to change it because of a comment on IBM-MAIN, at least not in time to help @Janet. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Relson Sent: Sunday, August 28, 2016 5:27 PM To: [email protected] Subject: Re: Dump in 64 bit mode "Storage around GPR2 is invalid." The LE folks indicate that the message really does not have much to do with the display of asterisks for that register. For performance reasons, the C/C++ compiler may choose not to save specific registers. If register contents were not saved, then the data for that register is residual information that CEEDUMP considers not to be meaningful to the owning routine. CEEDUMP suppresses that residual information, replacing it with the asterisks. I do not know why they would both do that and also attempt to dump storage around that register and display a message when that storage is not available to be dumped. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
