I would THINK that if an object on a heap is deleted, then a second delete request for that same object SHOULD return an error (invalid object address at least), which of course the programmer should be checking . . . but regardless of checked or not checked, the effect of a second delete SHOULD not cause any storage error in any rational heap system of which I can conceive.
Was this a custom heap library or some existing standard heap library? Peter From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Charles Mills Sent: Friday, June 20, 2025 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for clues on out-of-storage at end-of-jobstep On Thu, 19 Jun 2025 11:46:18 -0700, Leonard D Woren <ibm-main...@ldworen.net<mailto:ibm-main...@ldworen.net>> wrote: >Charles Mills wrote on 6/18/2025 1:19 PM: >> Well, it looks like the worst possible outcome. The problem simply went away. > >"Problems that go away by themselves come back by themselves." -- >very old saying. Indeed. Further update. The problem did not totally go away. But it moved from this horrible gigantic incomprehensible dump to a manageable S0C1. Not easy to get a S0C1 in a higher level language but it turned out that a storage overlay was corrupting the function table that lets code invoke an object's methods, leading to the S0C1. It took a while to find the cause of the storage overlay, but it turned out to be -- of course -- stupid programmer error. I was double deleting -- deleting twice -- an object on the heap. Now if would be nice if a higher-level language running in a debug sort of mode would diagnose a double-delete rather than overlaying unrelated storage ... but there are many things in this world that would be nice. Thanks again all for your suggestions. Charles -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
