Good point Jon about maintaining a consistent counter value for a meld to be feasible and correct. That would argue for an “independent” counter like the monotonically increasing real-time clock to be the “tie breaker” value. It may also depend on the circumstances that require a meld; for instance, if the “keys” for the heap to be attached were guaranteed by the application design and implementation not to have any of the keys in the heap to which it is being attached, just keeping the highest counter value would be sufficient. But I concede that is an edge case.
In the more general case, how do we get away from needing to use assembler to write COBOL? Using CS, CDS, CDSG, PLO, ENQ, etc. to maintain a consistent non-timer counter value would all need to be invoked from assembler (or possibly MetalC using “builtins.h”). That was the impetus for my original question, avoiding in-house “other language” commitments. Mind you, I am far from one to shy away from assembler, I am very comfortable with it. Management is not much of a fan though, and that’s the key issue. Or maybe the real issue is the lack of existing support in COBOL for data structures like heaps and queues and lists and maps and sets that are so common elsewhere in the programming language universe. I guess COBOL programmers aren’t supposed to be that “sophisticated” . . . Peter From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jon Perryman Sent: Tuesday, February 20, 2024 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? On Mon, 19 Feb 2024 23: 21: 49 -0600, Peter Farley <peter. farley@ BROADRIDGE. COM> wrote: >The only drawback is that if I ever need to meld two heaps >the meld logic would have to pick the largest heap counter >as the result counter On Mon, 19 Feb 2024 23:21:49 -0600, Peter Farley <peter.far...@broadridge.com<mailto:peter.far...@broadridge.com>> wrote: >The only drawback is that if I ever need to meld two heaps >the meld logic would have to pick the largest heap counter >as the result counter value in the merged heap. Merging heaps would require that you maintain a single counter because multiple separate counters are not coordinated sequencing. In other words, you don't know if 7 on heap 1 is before / after in time of 5 on heap 2. Depending on your needs, you could serialize the single counter between all heaps using CS, CSD, PLO, ENQ, coupling facility or something I haven't mentioned. Instead of the counter being in the heap definition, you would each one point to a common shared counter. -- 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
